duck-tape

セッションメモリ管理 🦆📼。コンテキストの整理、永続メモリ、セッション状態の引き継ぎ。

目的

アクティブなセッション向けの2層メモリ管理です。

• Tier 1（永続）： cwd にある CONTEXT.md。長期的に保持され、リポジトリで追跡されます。固定の7セクションで、決定論的にマージされます。
• Tier 2（作業用）： .duck-tape/<session_id>.state.md。短期用で、コミットされません。Agent State スキーマに準拠します。CONTEXT.md へのマージ用のステージング入力です。

情報の忠実性を保ち、中断を最小限に抑えます。

哲学上のガードレール（スキル固有）

references/GUARDRAILS.md の共通ガードレールを継承します。

• コンテキストが不足している場合は、焦点を絞った確認質問を1～3個行います
• 根拠が不足している場合は、前提を明示します

スキル固有の追加ルール：

• 永続アーティファクトの安全性：CONTEXT.md は長期的に保持され、コミットされる可能性が高いファイルです。書き込む前に必ず編集して機密情報を除去してください。
• セッション状態の安全性：.duck-tape/<id>.state.md はワークスペース内に保存されますが、次のエージェントが読む可能性があります。ここにも機密情報の編集が適用されます。
• 翻訳の境界：状態ファイルには復旧に必要なセッションの詳細を保持します。CONTEXT.md に書き込む前に、長期的に有効な決定事項、制約、慣例、事実、負債、未解決の質問のみを残してください。
• 開発時の説明、却下したアプローチ、最近の変更に関するコンテキスト、セッション限定の承認フラグ、作業の進め方を示すだけのレビュー／テスト／セッション参照は翻訳しないでください。
• CONTEXT.md にテストまたはレビューの参照を残すのは、長期的に有効な検証要件を示す場合に限ります。過去の判断理由は通常の CONTEXT.md エントリーではなく、ADR または変更履歴に残してください。
• ローテーション上限：.duck-tape/ 内の状態ファイルは最大10個です。削除の優先順位は、まず auto、次に recovered、最後に manual です。
• 圧縮前マーカー（.duck-tape/.last-compact）はハーネスが書き込むもので、意味的な情報は持ちません。マーカーの書き込みに承認は不要です。

有効化

状態のみ（デフォルト）：セッション状態ファイルを書き込みます。合図：/duck-tape、「セッション状態を保存」、「セッションをチェックポイントに保存」。

マージ（CONTEXT.md）：状態ファイルを書き込み、CONTEXT.md にもマージします。合図：「セッションを圧縮」、「CONTEXT.md を更新」、「メモリを永続化」、/duck-tape merge。

再開：圧縮を検出し、チェックポイントを再読み込みします。合図：/duck-tape resume、「セッションを再開」。手動チェックポイントが存在する場合は読み取り専用です。auto チェックポイントしかない場合、または状態ファイルがない場合は、LLM 支援による復旧を実行し、-recovered.state.md を書き込みます（承認が必要）。

方法

1. 入力内容の機密情報を編集

セッション内容に秘密情報／個人情報（PII）が含まれていないか確認します：API キー、パスワード、トークン、接続文字列、環境変数の値、個人を特定できる情報。検出した場合は、該当内容を拒否し、検出内容を報告して、元の内容を編集するか、該当箇所を <REDACTED> に置き換えるかをユーザーに確認します。書き込み内容に未編集の秘密情報が含まれる場合は、書き込みを拒否します。マスク済みの内容を書き込めるのは、ユーザーの確認後のみです。両方の層に適用されます。

2. セッション状態ファイルを書き込む

Agent State スキーマを使用して .duck-tape/<session_id>.state.md に書き込みます。セッション ID の形式は <YYYY-MM-DD-HHMM> です。完全なスキーマは references/STATE_SCHEMA.md、出力形式は references/OUTPUT_SCHEMA.md、サンプルは examples/STATE.md にあります。.duck-tape/.gitignore がない場合は、内容を * として自動作成します。

セッション ID の処理：

• デフォルト：/duck-tape および /duck-tape merge では、<YYYY-MM-DD-HHMM> を自動生成し、通知しません。
• ユーザーがカスタム ID を明示的に要求した場合に限り、セッション ID を尋ねます。
• カスタム ID が指定され、それが無効な場合は、必要な形式を示す修正依頼の質問を1つ行ってから続行します。

ローテーション上限を適用します：状態ファイルは最大10個です。削除の優先順位は、まず auto（auto のうち最も古いもの）、次に recovered、最後に manual です。

状態ファイルのパス .duck-tape/<session_id>.state.md を報告します。ユーザーはこのパスを使用して、後でセッション状態を再読み込みできます。

3. CONTEXT.md にマージする（条件付き）

マージのシグナルがある場合のみ実行します。state-only モードではスキップしてください。

ブートストラップ（CONTEXT.md がない場合）：references/STATE_SCHEMA.md の厳格なマッピングに従って、状態ファイルの翻訳済みコンテンツを使って CONTEXT.md を作成します。空のセクションには examples/bootstrap-CONTEXT.md のひな形を使用します。タイトルの下に8つのセクション見出しを使って目次を生成します。出力形式は references/OUTPUT_SCHEMA.md を参照してください。サンプルは examples/CONTEXT.md にあります。Goals または Conventions の項目がない場合は、推測せず空のままにします。

マージ（CONTEXT.md がある場合）：厳格なマッピングに従い、セッション状態ファイルから翻訳します。セクションごとのマージルールを適用する前に、永続的なコンテキストの粒度（コミット単位ではなく、意思決定単位）に要約してから、永続的コンテキストのフィルターを適用します。## セクション見出しの集合が変わった場合にのみ、目次を更新します。セクションごとのマージルールは references/SCHEMA.md を参照してください。概要：

• Goals／Decisions／Conventions／Glossary：キーで重複を除去し、競合時は置き換え、新規項目を追加します
• Deferred-Debt：ステータスマーカーを付けて追記のみ
• Open-Questions：新規項目を追加し、テキストで重複を除去します
• Notes：タイムスタンプ付きで追記のみ。書き換えません。
• Re-derivation + Suggested Skills：状態ファイル内に限定し、CONTEXT.md には翻訳しません
• Position.Current + Position.Done：状態ファイル内に限定し、翻訳しません。次のエージェントは再開時に状態ファイルを読みます。
• 開発の説明、却下したアプローチ、最近の変更に関するコンテキスト、セッション限定のフラグ、過去の本番環境への参照は CONTEXT.md に含めません。永続的な意思決定や制約の根拠がある場合は、その根拠を保持します。

references/OUTPUT_SCHEMA.md に従って変更履歴を出力します。サンプルは examples/CHANGELOG.md にあります。

• Added: <section> <key>
• Superseded: <section> <key> (<old> -> <new>)
• Dropped: <section> <key> (<reason>)

削除には明示的な理由が必要です。黙って削除しないでください。

4. 実行承認

ワークスペースを変更するアクション（変更の種類に応じて承認が必要です）：

セマンティックな変更（完全な実行承認が必要です）：

• コード／ロジックの変更
• ドキュメント／計画の変更（README、Markdown ドキュメント、ADR、CONTEXT.md、ランブック、設計メモ）。ただし、コード以外のテキストファイルの誤字のみの修正は除きます
• 設定／スキーマの変更（設定、環境変数、ビルド設定）
• 依存関係の変更（package.json、requirements.txt など）
• ファイル操作（作成、削除、移動）
• 変更を伴うコマンド（git commit、install、build、deploy）
• 実装／パッチ適用のタスク委任

外観上の変更（簡易確認が必要です）：

• 書式／空白のみの変更
• コード以外のテキストファイルの誤字修正
• 確認文：「[formatting change/typo fix] を進めてもよいですか？」

例外事項：

• コードファイル内の JSDoc／docstring の変更はセマンティックな変更です（生成されるドキュメントやコードの契約に影響します）
• コード内のロジックを説明するコメントはセマンティックな変更です（保守性に関する理解に影響します）
• 設定ファイルのコメントはセマンティックな変更です（解釈に影響します）
• ドキュメントの更新（ADR、CONTEXT.md）はセマンティックな変更です
• README 内のコードスニペットの例はセマンティックな変更です（ユーザーがコピー＆ペーストするため）

承認ワークフロー： セマンティックな変更を行う前に、実行承認を得てください。

1. 事前確認（承認を求める際は毎回必須です。項目が不足している場合は、確認の質問を1つしてください。）
   • 対象フェーズ：
     • フェーズ 1：スタブ／スケルトン／インターフェイス
     • フェーズ 2：配線／統合
     • フェーズ 3：具体的な実装
   • フェーズ適合の説明（この差分がフェーズの制約に合致する理由）
   • 対象ファイル（選択したフェーズに応じて範囲を限定）
   • 期待される動作の変更
   • 最小限の検証チェック
2. ファイルごとに変更一覧をフォーマット済みの差分として提示
   • ファイルが存在する場合：統合差分（---／+++／@@ のハンク、-／+ のプレフィックス）
   • ファイルが存在しない場合：ファイルパスをヘッダーとしたフェンス付きコードブロックに全内容を記載
   • 差分ブロックはファイルごとに1つ
   • 各変更を説明する注釈を差分のハンクより前に記載
   • フェーズの制約に違反するファイルがある場合は、分割して再提案してから承認を求める
3. 承認の確認：この範囲を承認しますか？（例：approve/ok/confirm）
4. 承認を待つ：ユーザーが明確な承認の意図を示すまで、編集／コマンド／タスクの委任に進まない

ルール：

• ユーザーの承認／確認なしに、ワークスペースを変更する操作を行わない

承認の意図を示すトークン：

• 承認の意図として受け付ける：「approve」、「approved」、「ok」、「go ahead」、「confirm」、「yes」
• 選択肢を参照した承認の文も受け付ける：「ファイル X と Y について、オプション B で進めてください。」「承認します。提案された検証計画を実行してください。」
• 例はすべてを網羅するものではありません。明確な承認の意図があれば受け付けます。
• 承認を伴わない継続の合図は承認として扱わない：「continue」のみ、選択肢の文字のみ（「B」）、または「next」のみ。承認を示す動詞も範囲の指定もない場合は承認ではありません。

範囲のルール：

• フェーズごとの上限（デフォルト）：

  • フェーズ 1（スタブ／スケルトン／インターフェイス）：最大 6 ファイル
  • フェーズ 2（配線／統合）：最大 4 ファイル
  • フェーズ 3（具体的な実装）：最大 2 ファイル

• フェーズの内容に関する制約（厳守）：

  • フェーズ 1（スタブ／スケルトン／インターフェイス）に含めてよいのは、次の内容のみです。
    • ファイル／モジュールの骨組み（フォルダー、エクスポート、セクション構成）
    • 型／インターフェイスの宣言
    • 関数／クラスのシグネチャ
    • プレースホルダーの戻り値／エラー／TODO マーカー
    • ビジネスロジックを含まない最小限の何もしない配線
  • フェーズ 1 に含めてはいけないもの：
    • 完全な機能／ビジネスロジック
    • 副作用を伴うフロー（DB／ネットワーク／認証／ファイル書き込み）
    • プレースホルダーを超える完全な UI の動作
  • フェーズ 2（配線／統合）に含めてよいもの：
    • ルート登録、DI／コンテナーの配線、モジュールの構成、イベントの接続
    • 既存コンポーネント間の適合用の接着コード
  • フェーズ 2 に含めてはいけないもの：
    • 新たな実質的なビジネスロジックのブロック
  • フェーズ 3（具体的な実装）に含めるもの：
    • ビジネスロジック、アルゴリズム、副作用、動作の完全な実装

• 新規ファイルの初期作成ルール：

  • スコープに新しい機能ファイルの追加が含まれる場合、最初の承認ではフェーズ 1 のスタブ／スケルトン／インターフェースのみを対象とします。
  • 本体の実装は、後続のフェーズ 2／3 の承認で行います。
  • 新しいファイルがスタブ／スケルトンの範囲を超える場合は、そのファイルをスタブの作成と実装に分け、順に進めます。

• フェーズが上限を超える場合は、実行前に、より小さく範囲を限定した承認に分割します。

• レビュー疲労の客観的なトリガー：

  • フェーズ 1（スタブ／スケルトン／インターフェース）：
    • 1 回の承認における差分の変更行数（追加＋削除）が合計 180 行を超える場合、現在のフェーズ上限を少なくとも 1 ファイル引き下げます（上限は最低 1 ファイルです）。
    • 1 ファイルの変更行数（追加＋削除）が 90 行を超える場合、そのファイルを個別の承認、またはより小さな逐次編集に分割します。
  • フェーズ 2（配線／統合）：
    • 1 回の承認における差分の変更行数（追加＋削除）が合計 120 行を超える場合、現在のフェーズ上限を少なくとも 1 ファイル引き下げます（上限は最低 1 ファイルです）。
    • 1 ファイルの変更行数（追加＋削除）が 60 行を超える場合、そのファイルを個別の承認、またはより小さな逐次編集に分割します。
  • フェーズ 3（具体的な実装）：
    • 1 回の承認における差分の変更行数（追加＋削除）が合計 80 行を超える場合、現在のフェーズ上限を少なくとも 1 ファイル引き下げます（上限は最低 1 ファイルです）。
    • 1 ファイルの変更行数（追加＋削除）が 40 行を超える場合、そのファイルを個別の承認、またはより小さな逐次編集に分割します。
  • 同じバッチ内の 2 ファイルを超える数についてレビュー担当者から説明を求められた場合、次のバッチの上限を少なくとも 1 ファイル引き下げます。

• 複雑さやレビュー疲労が増した場合は、上限をさらに引き下げ、より小さなバッチで続行します。

• 目標が変わらない場合でも、フェーズ間で実行承認を再取得します。

• 承認後にスコープが変わった場合は、続行する前にスコープの確認を再度行います。

• フェーズの例（適用例）：

  • フェーズ 1 の例：5 ファイル、変更行数（追加＋削除）は合計 170 行、単一ファイルの最大変更行数（追加＋削除）は 80 行です。上限としきい値の範囲内のため、1 回の承認で進められます。
  • フェーズ 2 の例：4 ファイル、変更行数（追加＋削除）は合計 130 行です。フェーズ全体のしきい値を超えるため、実行前に 2 回の承認に分割します。
  • フェーズ 3 の例：2 ファイルのうち 1 ファイルの変更行数（追加＋削除）が 45 行です。単一ファイルのしきい値を超えるため、より小さな逐次編集に分割します。

操作ごとの事前確認：

状態のみ：

• 対象ファイル：.duck-tape/<id>.state.md、.duck-tape/.gitignore（存在しない場合）
• 予定内容：Agent State スキーマに従って状態ファイルを書き込みます
• 検証：状態ファイルを再読み込みし、Agent State のセクションが存在することを確認します

マージ：

• 対象ファイル：.duck-tape/<id>.state.md、.duck-tape/.gitignore（存在しない場合）、CONTEXT.md
• 予定内容：状態ファイルを書き込み、スキーマのルールに従って翻訳済みの状態を CONTEXT.md にマージします
• 検証：両方のファイルを再読み込みし、変更履歴が CONTEXT.md の差分と一致することを確認します

ハーネスとの統合

コンテキストがコンパクションされる前に、コンパクション前トリガーが .duck-tape/.last-compact マーカーと .duck-tape/<id>-auto.state.md 状態ファイルを書き込みます。状態ファイルは、セッショントランスクリプト（Claude Code、Copilot）から自動抽出されるか、SDK（opencode）経由で取得されます。トリガーは、LLM のコンテキスト外でシェルスクリプトまたはプラグインとして実行されます。

マーカーの形式：<timestamp> | cwd: <path> | latest-state: <file> | transcript: <path>。transcript フィールドには、ソースとなるトランスクリプトのパス（Claude Code、Copilot）または opencode のスナップショットパス（<id>-transcript.json）が記録されます。Angle B より前に書き込まれた古いマーカーには、このフィールドはありません。

状態ファイル（<id>-auto.state.md）には、自動抽出された Approved Workflow、Position（ツール呼び出しと最後のアシスタントのテキスト）、Decision Log（パターンマッチングで抽出し、重複を排除した直近10件）が含まれます。これは忠実度の低い復旧用フォールバックです。パターンマッチングでは明示的な決定（APPROVED／DECIDED／CHOSE）は検出できますが、暗黙的な決定は見逃します。手動の /duck-tape チェックポイントでは、より忠実度の高い状態が生成されます。LLM 支援型の復旧（Angle B）を使う /duck-tape resume では、意味に基づいて決定を抽出した -recovered.state.md が生成されます。忠実度は、自動生成の状態と手動生成の状態の中間です。

失敗した場合、トリガーはマーカーのみの出力にフォールバックします：jq がない（bash）、トランスクリプトがない、形式が不明、抽出対象がない、SDK エラー（opencode）。pre-compact.sh／.ps1 は、マーカーのみを出力するフォールバック用スクリプトとして保持されています。

コンパクション後の再開： 下記の ## Resume を参照してください。自動ではなく、/duck-tape resume によって実行されます。

ガイド付きインストール： 下記の ## Init セクションを参照してください。手動インストールとトラブルシューティングについては、references/HOOKS_GUIDE.md を参照してください。

移植性： トリガーの動作は、3つすべてのハーネスで同一です。しきい値検出はありません。コンテキストの再注入もありません。状態ファイルとマーカーのみです。

再開

/duck-tape resume — コンパクションを検出し、チェックポイントを再読み込みします。

1. .duck-tape/.last-compact を確認します。存在しない場合は、コンパクションは発生していません。「no compaction marker found」と報告して終了します。
2. マーカーのタイムスタンプをセッション開始時刻と比較します。マーカーがセッション開始より古い場合は、「no compaction in this session — marker from a previous session」と記録します。チェックポイントはセッション間の引き継ぎ地点なので、手順 3 に進んで再読み込みします。
3. マーカーのフィールド cwd、latest-state、transcript（トランスクリプトのパスまたは OpenCode のスナップショットパス。古いマーカーでは存在しない場合があります）を読み取ります。
4. 優先順位 manual > recovered > auto に従って状態ファイルを選択します。 a. 手動チェックポイント（サフィックスなし）が存在し、最新の自動チェックポイントより新しい場合は、手動チェックポイントを使用します。そこから位置を報告し、手順 6 に進みます。 b. 自動チェックポイント（-auto サフィックス）のみが存在する場合、または状態ファイルがまったく存在しない場合は、LLM 支援による復元（手順 5）を実行します。
5. LLM 支援による復元（Angle B）。トランスクリプトの内容を意味的に統合することで、自動チェックポイントより忠実度の高い状態ファイルを生成します。
   • トランスクリプトのパス：マーカーに transcript フィールドがあれば、その値を使用します。ない場合は復元できません。「compaction occurred but no transcript path in marker」と報告し、新たにチェックポイントを作成するため /duck-tape の実行を提案します。
   • hooks/extract-raw.sh <transcript_path>（bash）または hooks/extract-raw.ps1 <transcript_path>（Windows では PowerShell）を実行して、元データを取得します。スクリプトは、ユーザープロンプト、ツール呼び出し、直近 10 件のアシスタントメッセージ、判断の可能性がある箇所（パターンで抽出し、重複を除去）、失敗したツールの結果、セッションのメタデータを含む構造化された Markdown を出力します。
   • 元データの出力を読み取ります。
   • 元データからエージェント状態ファイルを統合して作成します。判断はパターン照合（Angle A のような方式）ではなく、意味に基づいて抽出します。「X の理由でオプション 2 にする」といった内容は、そのキーワードがなくても判断に該当します。アシスタントのメッセージとツール呼び出しから、現在の作業位置（現在／完了／残り）を抽出します。ツールの結果とユーザーの確認から、確定した事実を抽出します。
   • 状態ファイルを .duck-tape/<YYYY-MM-DD-HHMM>-recovered.state.md として書き込みます。
   • ローテーション：-recovered ファイルは、手動および自動のファイルと合わせて上限 10 件を共有します。削除時の優先順位は、自動、復元済み、手動の順です。
   • 新しいファイルから位置を報告します。
6. CONTEXT.md が存在する場合は読み取ります。
7. コンパクションのタイムスタンプ、セッション状態の位置（現在／完了／残り）、および現在の作業に関連する CONTEXT.md の判断を報告します。
8. 状態ファイルの書き込み（手順 5 のみ）には承認が必要です。読み取り専用の再開（手順 1～4、6～7）では書き込みは行いません。

状態ファイルが存在せず、マーカーにトランスクリプトのパスもない場合は、「compaction occurred but no recoverable state」と報告し、新たにチェックポイントを作成するため /duck-tape の実行を提案します。

Init

/duck-tape init — ガイド付きのフックインストールです。オプトイン方式です。

1. ユーザーに使用するハーネス（opencode、Claude Code、Copilot）を尋ねます。
2. 選択に基づいて、該当するフック設定スニペットを特定します。
   • opencode：hooks/opencode.plugin.js
   • Claude Code（unix）：hooks/claude-code.hooks.json
   • Claude Code（Windows）：hooks/claude-code.hooks.windows.json
   • Copilot：hooks/copilot.hooks.json
3. ハーネスに対応するインストール先のパスをユーザーに示します。
   • opencode：.opencode/plugins/duck-tape.js
   • Claude Code：リポジトリローカルの .claude/settings.local.json（推奨）または .claude/settings.json の hooks キーにマージします
   • Copilot：.github/hooks/duck-tape.json
4. ファイルへの書き込みをスキルに任せるか、手動で配置できるようにスニペットを表示するかをユーザーに尋ねます。
5. 書き込む場合：ユーザーにインストール先のパスを確認します（承認が必要です。ファイルを作成します）。ファイルを書き込み、成功したことを報告します。
6. 表示する場合：スニペットと配置手順を表示します。トラブルシューティングについては references/HOOKS_GUIDE.md を参照するよう案内します。
7. hooks/extract-state.sh（unix）または hooks/extract-state.ps1（Windows）がプロジェクト内にあることを確認します。opencode では、プラグインが SDK 経由で取得するため、シェルスクリプトは不要です。また、/duck-tape resume での LLM 支援による復元に必要な hooks/extract-raw.sh／.ps1 があることも確認します。

事前確認：

• 対象ファイル：ハーネス固有の設定パス（最大 1 ファイル）
• 期待される動作：フック設定スニペットをハーネスのインストール先に書き込む
• 検証：書き込んだファイルを再読み込みし、有効な JSON または JS の構文であることを確認する

Prune

/duck-tape prune — 手動で実行します。Notes セクションのみが対象です。

1. Notes の項目をタイムスタンプとともに一覧表示します。
2. ユーザーが削除する項目を選びます。
3. 削除を反映したファイルを書き込み、削除した内容を報告します。

事前確認：

• 対象ファイル：CONTEXT.md（Notes セクションのみ）
• 期待される動作：ユーザーが選択した Notes の項目を削除し、固定スキーマのセクションには手を加えない
• 検証：CONTEXT.md を再読み込みし、Notes のみが変更され、選択された項目が削除されていることを確認する

項目を削除する際は、固定スキーマのセクションには手を加えないでください。

Migrate

/duck-tape migrate — 既存の CONTEXT.md をスキーマに合わせて再構成します。自由形式のコンテンツをセクションに分類し、不足している見出しを追加します。一致しないコンテンツはスキーマの上に残します。

1. 既存の CONTEXT.md を読み込みます。
2. 7 つのスキーマセクションのうち、存在するものと不足しているものを特定します。
3. 自由形式のコンテンツ（スキーマの ## 見出しの下にないブロック）を解析します。
4. 各自由形式ブロックを、最も適切なスキーマセクションに分類します。
   • Goals：最適化の対象、優先事項、北極星となる方針
   • Decisions：承認または却下された選択、その理由、日付付きの決定事項
   • Conventions：命名規則、ファイル構成、スタイル、ツールの選択
   • Glossary：用語の定義、ドメイン用語、頭字語の展開
   • Deferred-Debt：TODO／FIXME／HACK の項目、先送りされた作業
   • Open-Questions：未解決の質問、保留中の確認事項
   • Open-Questions：未解決の質問、保留中の確認事項
   • Notes：その他すべて、自由形式の所見
5. 再構成案をユーザーに提示します。対応関係（既存のブロック -> 対象セクション）を示し、確度の低い配置には印を付けます。一致しないブロックはスキーマの上に列挙したままにします。
6. 承認を得てから、再構成を実行します。8 つのセクション見出しからタイトルの下に目次を生成します。移動した内容とスキーマの上に残した内容を報告します。

事前確認：

• 対象ファイル：CONTEXT.md
• 期待される動作：自由形式のコンテンツをスキーマセクションに分類し、不足している見出しを追加し、一致しないコンテンツはスキーマの上に残す
• 検証：CONTEXT.md を再読み込みし、7 つの見出しがすべて存在すること、および元のコンテンツがすべて反映されていること（移動済み、またはスキーマの上に残っている）を確認する

境界

• デフォルトモードは状態のみです。CONTEXT.md はマージの合図があった場合にのみ書き込みます。
• CONTEXT.md、.duck-tape/<id>.state.md、.duck-tape/<id>-recovered.state.md、.duck-tape/<id>-transcript.json、.duck-tape/.gitignore、.duck-tape/.last-compact マーカーのみを書き込みます。
• 既存の CONTEXT.md の構成を尊重します。ファイルにスキーマのセクションがない場合は、最初のマージの前に移行するようユーザーに促します。
• ブートストラップに Goals または Conventions の項目がない場合は、明示的なユーザーの決定に基づくもののみを追加し、推測で補いません。
• 書き込み時に Note を変更する必要がある場合は、あいまいな書き換えをせず追記します。
• 項目を削除する場合は、変更履歴に理由を記録します。黙って削除してはいけません。