reconcile

Reconcile

あなたは、調整された真実を明示的に書く唯一の担当者、つまり audit → reconcile → close の連携部分における書き手です。Audit は 変更点を特定し、調整ブリーフを作成します。あなたはそれを受け取り、変更を書き込み、 実施した内容を記録します。Close は、終端への遷移の前に結果を確認します。

異なる仕組みを使う2 つの対象に書き込みます。

対象	仕組み
スライスごとの成果物（design.md、slice-NNN.md）	ユーザーの合意を得て直接編集
ガバナンス／仕様の真実（ADR、仕様、要件、ポリシー、標準）	REV 種別（doctrine revision）— 型付きの [[change]] 行、承認チェックポイント、適用パス

.doctrine/ 以外にあるプロジェクト固有のドキュメントは、Doctrine の機能カテゴリではありません。スライスごとの成果物と同様に、プロジェクト内のほかのファイルと同じ方法で直接編集します。

1 回の reconcile で両方の対象を使うことがあります。たとえば、design.md を直接更新し、さらに ADR の改訂用 REV を作成します。各変更をどこに反映するかは、推測で決めるのではなく、調整ブリーフに従います。

ブリーフの項目で、あなたが書き込まない対象が指定されることもあります。 plan.toml の基準 （EN-/EX-/VT-、PHASE-NN）は追記のみが可能であり（ブートルール）、reconcile の対象ではありません。ブリーフの項目で計画基準の編集を求められた場合は、編集せず、設計／計画のエスカレーションとして /audit または /consult に差し戻してください。また、適合性／ 「根拠のない未配信」の項目は、セレクターレジストリ（決定的な操作である doctrine slice selector rm／add）で修正します。design.md §6 の文章だけを編集しても解決しません（§6 はミラーにすぎず、slice conformance は slice-NNN.toml のレジストリを読み取ります）。文章だけを編集しても、適合性は赤のままです。

CLI の動詞はありません。 doctrine slice reconcile はまだ実装されていません（延期中）。 既存の動詞（doctrine revision *、ファイルの直接編集）を手作業の規律として使います。現在の /audit と同じ方針です。

調査はしても、再監査はしないでください。 適用可能性の検証、編集箇所の特定、監査後のドリフト検出のために、対象の成果物を調査します。ただし、新たな問題の発見は行いません。ブリーフにない新しいギャップを見つけた場合、ここで新たな所見を追加せず、/audit に差し戻すか、/consult に相談してください。この分担を保つため、問題の発見は audit が担い、書き込みはあなたが担います。

入力：

• RV 台帳 — review-NNN.toml（所見の状態）＋ review-NNN.md（レビューの Markdown。調整ブリーフを含みます）

• review-NNN.md 内の ## Reconciliation Brief セクション — audit からの構造化された引き継ぎです。所見を対象の成果物に対応づけ、スライスごと（直接編集）とガバナンス／仕様（REV）の項目に分けます。形式は次のとおりです。

  ## Reconciliation Brief
  
  ### Per-slice (direct edit)
  - design.md §3: the eviction model changed … update prose
  
  ### Governance/spec (REV)
  - ADR-NNN: branch-point staleness description is wrong → REV modify
  - REQ-NNN: cordage scale target verified at 50k nodes → REV status active
  

ブリーフは、audit の締めくくりを記述する ## Synthesis とは別の専用セクションにあります。

人間向けの調整

重大な変更を提案する場合、既存の確認または REV の承認を求める前に、現在の記述、提案する記述、将来の作業への影響がわかるようにしてください。変更を判断するのに十分な背景情報と、重大な Doctrine ソースに対する正確な doctrine <kind> show <ID> コマンドを提示してください。役立つ場合は、記述とその影響を /walkthrough で確認できるよう案内してください。残るリスクや意図についての回答によって提案が改善される場合は、その内容を変更に反映してください。これは以下の確認手順と組み合わせて行います。二度目の承諾を求めたり、理解したことを人間に証明させたりしないでください。プロジェクトの標準的な関与方針と、人間の口頭での変更を尊重してください。

プロセス

1. 入力を読む

review-NNN.md の ## Reconciliation Brief セクションを読みます。doctrine review show RV-NNN --open で指摘のステータスを読み、すべての指摘が終端状態（verified／withdrawn）であること（インデックスが findings: 0 of N と表示すること）と、レビューが終了していること（doctrine review status RV-NNN が done · await=none と表示すること）を確認します。指摘がまだ open／answered／ contested の場合、またはレビューが終了していない場合は監査が未完了です。作業を停止し、/audit に引き継いでください。

指摘は verified のままにします。修正内容は、指摘の処置を変更するのではなく、別途あなたが記録します。RV ID と、対応するブリーフ項目を記録します。

2. 変更なしのゲート

調整ブリーフが空の場合（すべての指摘が、書き込み不要で撤回または容認された場合）、review-NNN.md に ## Reconciliation Outcome セクションを追記して、変更なしであることを確認し、/close に引き継ぎます。

## Reconciliation Outcome

All findings were withdrawn or tolerated with rationale. No writes needed.
Reconcile pass complete — handoff to /close.

3. スライスごとの編集

ブリーフにある直接編集項目ごとに、次の手順を行います。

• 提示：提案する編集内容をユーザーに提示します。正確な場所、変更前のテキスト、変更後のテキストを示し、書き込む前に確認を得ます。
• 書き込み：design.md および／または slice-NNN.md に編集内容を書き込みます（実装中にスコープが変わった場合）。
• 記録：何を編集したか、また、その変更の根拠となった指摘を、進行中の調整結果に記録します。手順6でこれをRVのMarkdownに追記します。

4. REV の作成

ブリーフにあるガバナンス／仕様項目ごとに、REVの変更を作成します。複数のガバナンス項目は、デフォルトでスライスごとに1つのREVにまとめられます（複数の [[change]] 行を含む1つの reconcile SL-NNN REV）。項目ごとに個別の議論が必要な場合は、別々のREVに分けます（以下の分割ルールを参照）。

4a. REV を見つけるか作成する

ブリーフにREV IDが記録されている場合は、それを使います。

doctrine revision show REV-N

それ以外の場合は、慣例に従って作成します。

doctrine revision new "reconcile SL-NNN" --slug reconcile-sl-NNN

REVは、変更行がない proposed 状態で始まります。行を追加する前に、started に遷移させます。

doctrine revision status REV-N started

4b. 競合ガード

reconcile-sl-NNN スラッグがすでに存在する場合は、再利用する前に確認します。

doctrine revision show REV-N

• 関連がある場合（同じスライス、同じ種類の変更）→再利用し、新しい [[change]] 行を追加します。
• 関連がない場合（スラッグが異なるスライスや意図と衝突している）→別のスラッグを作成するか、ユーザーに判断を求めます。無関係な変更を1つのREVに黙って混在させてはいけません。

4c. [[change]] 行を追加する

ガバナンス／仕様項目ごとに、型付きの行を追加します。

doctrine revision change add REV-N --action <action> [--target <T>] [--to-status <S>] [--new-label <L> --member-of <SPEC>] [--primary]

--action の値とそのフラグについては、doctrine revision change add --help を参照してください。

どの --action の値が自動で反映され、どれが手動反映用として提示されるかについては、doctrine revision apply --help を参照してください。

4d. 調整の経緯を記録する

調整の根拠（変更内容、理由、変更の根拠となったRVの指摘へのリンク）を revision-NNN.md に記載します。例：

## Reconcile narrative

- [RV-NNN finding F-3]: the branch-point staleness description was wrong.
  Updated to match the CAS row semantics from the coordination slice.
- [RV-NNN finding F-5]: the scale requirement verified at 50k nodes. Status moved to `active`.

4e. 分割ルール

個別の議論が必要と分かっている行、またはこのレビューで反映されない行がある場合は、承認／適用の前に、それを個別のREVに分割します。1行が滞留してクローズを妨げるような、部分適用の包括的なREVを作成してはいけません。すべての行が反映されるまで、REVは started のままです。包括的なREVで1行でも滞留すると、スライス全体がブロックされます。

5. 承認と適用

すべての [[change]] 行を記述し、経緯の説明を完成させたら、次の手順を実行します。

doctrine revision approve REV-N
doctrine revision apply REV-N

• approve は直交する承認を記録します。承認なしでは apply は拒否されます（実行者を問わない方式のため、単独で作業する開発者は自分で承認します）。
• apply は status 行を自動で反映し、modify／create／introduce／move／retire／prose 行を手動反映用として提示します。適用前の from ガードでは、変更案の作成後に対象が移動していた場合、適用全体が中止されます。これが発動した場合は、影響を受ける対象を再確認してから再試行します。
• 自動反映された行と、手動反映用として提示された行を記録します。

6. 手動で文章を反映する

手動対応として提示された行については、作成者の意図を正とするモデルに従って、手作業で編集します。REVは変更内容を示すものであり、実際のファイル編集はご自身で行います。

提示されたすべての行を反映したら：

doctrine revision status REV-N done

次に、RVに調整結果を記録します。review-NNN.mdに## Reconciliation Outcomeセクションを追記します。

## Reconciliation Outcome

### Direct edits applied
- design.md §3: updated eviction model prose → matches implementation (finding F-2)

### REVs completed
- REV-NNN (`reconcile-<slug>`): done — the staleness description amended, REQ-NNN → active
  (covers findings F-3, F-5). Rationale in revision-nnn.md.

### Withdrawn / tolerated
- Finding F-4: tolerated — drift in error message wording; rationale in finding disposition.

7. エスカレーションの判定

調整中に、単なる個別の不整合ではなく、変更をその範囲内で表現できないモデル自体の不備が判明した場合は、設計に差し戻してエスカレーションします。

doctrine slice status <id> design

これが設計への差し戻しです：reconcile → design。不備と、設計で解決すべき内容をメモ（--noteフラグ）に記載します。適用される設計でサポートされていない解決策を、独自に考案しないでください。

すべての項目を解決し、結果を記録したら、/closeに引き継ぎます。

結果

• 調整の概要に記載されたガバナンス／仕様のすべての項目が解決されています。doneのREVで対応済み、RVに理由を記載して撤回、RVに理由を記載して許容、または設計にエスカレーションされています。
• スライスごとの直接編集項目が、対象ファイルにすべて適用されています。
• RVに、実施内容とその理由を記録した## Reconciliation Outcomeセクションがあります。
• 各REVのrevision-NNN.mdに、調整の経緯が記載されています。
• スライスは/closeに進める状態です。すべての項目が解決されており、適用途中のREVがクローズゲートを妨げていません。