close

完了

作業完了の印を付けるだけではなく、正式なクローズ処理を実行します。

入力：

• 完了し、監査済みで、調整済みの実装フェーズ
• すべての指摘が最終状態となり、## Reconciliation Outcome が記録された調整レビュー（RV）（/reconcile を参照）
• 統括対象のスライス ID

プロセス

1. 事前確認：

   • フェーズ終了基準（EX-）と検証（VT-）を満たしていること。集計を確認します。doctrine slice list で、スライスが X/X complete と表示され、ブロック中の !N、異常を示す ?N、未追跡の — がないことを確認します。
   • /reconcile が完了していること（/audit → /reconcile 経由）。RV 台帳が解決済みで、すべてのガバナンス／仕様に関する指摘が処置済みとなり、RV に ## Reconciliation Outcome セクションがあることを確認します。調整の概要が空（何もしない）だった場合は、その結果にその旨が明記されていることを確認します。
   • スライスから得られた永続化すべき指摘は、クローズ前に lib:reference/harvest.md に従って収集するか、意識的に却下します。問題のないスライスでは何も収集しない場合がありますが、クローズ時には意識的な却下が行われたかを確認します。
   • doctrine check gate がグリーンであること。

2. 仕様整合性ゲート — done にする前に調整の完了を確認します： 最終状態への遷移前に、監査の調整概要に含まれるすべての項目が、次の 4 つのいずれかの方法で解決されていることを確認します。

   • REV 完了 — ガバナンス／仕様に関する項目が、done の REV によって対応済みである（revision status REV-N done）。REV の根拠（revision-NNN.md）に調整の経緯が記載されています。
   • 撤回 — RV 内で、根拠を添えて指摘が撤回されている。
   • 許容 — RV 内で、根拠を添えて指摘が許容されている。
   • 設計へエスカレーション — 設計への差し戻しエッジ（reconcile → design）を使って、スライスが design に戻されている。 さらに：
   • スライスごとの直接編集項目がすべて design.md／slice-NNN.md に適用され、## Reconciliation Outcome に記録されている。
   • RV 台帳が解決済み（done · await=none）である。すべての指摘が最終状態であり、かつレビューが終了していること（review conclude RV-NNN --basis …）。すべての指摘が最終状態でも、指摘が 0 件の台帳を含め、起票者が終了を宣言するまでは active · await=raiser と表示されます。終了を宣言してください。トークン指摘を起票してはいけません。未解決のブロッカーがないことが遷移の条件であり、ステータス文字列ではありません（表示用の要約であり、ゲートではありません）。
   • 調整結果が記録されている（REV の根拠および／または RV の ## Reconciliation Outcome）。 根拠のない「却下」という処置は認められません。すべての指摘を、上記の最終状態のいずれかに分類する必要があります。 未解決の項目がある場合は、クローズを拒否し、/reconcile に戻ります。（構造上のクローズ境界は機械的な安全策です。このゲートは実質的な確認であり、コマンドが強制し、スキルが検証します。）

3. クリーンにコミットする： .doctrine/** のワークフロー成果物は、蓄積させず、スライス ID を付けた小規模で明確な従来形式のコミットとして反映します。コードとワークフローの編集は、先にクリーンにコミットできる方に合わせて、同時にコミットしても個別にコミットしてもかまいません。

   スラッグのシンボリックリンクもステージします。 */new 動詞は <kind>/NNN/ と兄弟となるスラッグのシンボリックリンク <kind>/NNN-slug -> NNN（slice、review、revision、rec など）を作成します。 git add <kind>/NNN/ のようにパスを指定するとディレクトリはステージされますが、シンボリックリンクは対象外となり、未コミットのまま残ります。両方をステージするには git add <kind>/NNN* を使うか、シンボリックリンクを明示的に追加します。最終コミットの前に git status を確認し、宙に浮いた NNN-slug がないことを確かめてください。 3a. ディスパッチされたスライス — 承認済み OID を取り込みます（監査後のみ）。 スライスが /dispatch によって進められた場合、監査済みの単位をここでプロジェクトに反映します。

   # 0. Resolve the trunk delivery ref once (config-driven; default refs/heads/main):
   trunk=$(doctrine dispatch deliver-to)
   
   # 1. Admit a close_target candidate (if not already done during /reconcile):
   doctrine dispatch candidate create --slice <N> --label close-001 \
     --role close_target --payload code --base "$trunk" \
     --source refs/heads/review/<N>
   doctrine dispatch candidate admit --slice <N> --role close_target \
     --candidate refs/heads/candidate/<N>/close-001 --review RV-NNN
   
   # 2. Project onto trunk (--trunk is REQUIRED; omitting it is a dry run):
   doctrine dispatch sync --slice <N> --integrate --trunk "$trunk"
   

   候補ワークフローがアクティブな場合、これは高速フォワードのみの CAS 行のもとで、不変の 許可済み close_target OID（および --edge は許可済み review_surface OID）を対象とします。生の phase/*／review/* の先端や 変更可能な候補 ref は決して対象にせず、クローズ時のマージも行いません。 trunk が移動していた場合は拒否されます（新しいベースで、クローズターゲット候補を上書きして許可してください）。--integrate を実行するのはここだけです。/dispatch の conclude では実行せず、監査後のここでのみ実行します。

   検証（ツリーが一致していること）。 --integrate --trunk の後、以下の両方のチェックに 合格する必要があります。合格するまで手順 4 に進まないでください。

   # (a) No phantom reverse-diff: the tracked working tree matches HEAD. A nonzero
   #     exit means integrate advanced the ref but desynced the live checkout — STOP.
   git diff --quiet HEAD
   
   # (b) The projected delta genuinely landed (not a silent dry-run): the committed
   #     journal's trunk row holds the planned tip; it must equal the trunk ref.
   trunk=$(doctrine dispatch deliver-to)
   planned=$(doctrine dispatch sync --slice <N> --show-journal-trunk-oid \
     --trunk "$trunk")
   git diff --quiet "$planned" "$trunk"
   

   (a) ファントム逆差分検出器です。パスを限定せず、追跡対象のツリー全体を確認します （ファントム逆差分は、スライスで投影された任意のファイルにまたがる可能性があり、 src/ だけとは限りません）。 (b) コミット済みの dispatch/<N> ジャーナルから trunk 行の planned_new_oid を読み取り （このチェックアウトから安定して読み取れるツリー読み取り）、解決済みの trunk 配信 ref（doctrine dispatch deliver-to、デフォルトは refs/heads/main）と比較します。不一致の場合、trunk に投影された先端が含まれていないため、 統合は反映されていません。

3b. 系譜の分離 — ペイロードが trunk に別経路で到達した （--record-integration）。 lib:reference/dispatch-mechanics.md の「系譜の分離 — すでに反映されたペイロードを記録し、trunk を進めない」を参照してください。 クローズゲートは引き続き done を拒否します（「dispatch 済みだが trunk 行がない」）。journal.toml を手動編集する代わりに、獲得した行を記録してください。

trunk=$(doctrine dispatch deliver-to)
doctrine dispatch sync --slice <N> --record-integration --trunk "$trunk"

lib:reference/dispatch-mechanics.md の「系譜の分離」にあるとおり、 --record-integration はペイロードがすでに trunk の祖先であることを確認し、検証済み trunk 行を 1 つコミットします。その後、slice status <N> done は その行を読み取り、成功します。これは手書きのジャーナル行に代わる 認められた方法です。ペイロードは git merge --no-ff phase/<N>-NN（または 許可済み候補）で別経路から反映し、review/<N> は使わないでください。

4. ライフサイクルの遷移： スライスが reconcile にあることを確認します（/audit で切り替わっていなければ doctrine slice status <id> reconcile で切り替えます）。続けて doctrine slice status <id> done を実行します（<id> は 40 などの数値のみです）。 クローズ境界では順序が強制され、スライスを対象とする未解決のブロッカーを持つ RV がある場合は拒否されます。doctrine slice list を再実行し、 ⚠ の乖離マーカーが消えたことを確認します。記述されたステータスがロールアップと一致するようになります。（終端状態は {done, abandoned} です。ここでのクローズは done への遷移です。スライスの放棄は別の判断であり、このスキルの対象ではありません。）
5. 起点となったバックログ項目をクローズする： バックログ項目（ISS/IMP/CHR/RSK）がこのスライスを生成した場合、その項目も遷移させます。doctrine backlog edit <ID> --status resolved --resolution fixed（または適切な解決理由）を実行します。起点となる項目が未解決のままスライスをクローズすると、整理上の負債になります。
6. ブロッキング指摘事項が未解決のまま残っている場合は、クローズせずに /reconcile に戻ります。重大なトレードオフを伴う許容済みの乖離に依存してクローズする場合は、それを標準化する前に /consult を行ってください。

乖離を解消する手順

slice status <id> done が 未解消の残存乖離 を理由に拒否された場合、フラグが付いた各要件には、以下 3 つの条件をすべて満たす、クローズ対象のスライスが所有する accept REC が必要です。

• (a) move = accept であること — revise／redesign ではなく、肯定を表します。
• (b) 要件を指定し、その to が現在記述されているステータス（拒否メッセージに表示されるステータス）と一致する [[status_delta]] があること。
• (c) REC の [[evidence_ref]] セットが、その要件の複合値に影響するすべての異なるカバレッジキーを包含していること。これにより、新たに得られた矛盾する証拠を古い REC で正当化できないようにします。

作成後、2 つのテーブルを手動編集します。

doctrine rec new --move accept --owning-slice SL-NNN --title "accept REQ-NNN"
# then hand-author the [[status_delta]] and [[evidence_ref]] tables

完全な述語、根拠、実例については、 doctrine memory show mem.pattern.doctrine.close-drift-discharge-rec を参照してください。

成果

• スライスが done になっており、集計結果と一致しています。
• 起点となったバックログ項目がある場合は、解決済みです。
• 長期的に有用なガイダンスがメモリに記録されているか、意識的に採用しない判断がされています。
• 作業ツリーはクリーンで、ワークフローの成果物がコミットされています。