codex-directorの既定をlunaへ移し、検収手段と記述量を整える

.claude/skills/codex-director/references/delegation-template.md

@@ -45,6 +45,26 @@ Codex を呼ぶ前に次を明確にする。情報が足りなくても、コ
 </report>
 ```
 
+## 報告前の裏取りを依頼文で要求する
+
+依頼文に「報告前の裏取り（必須）」の節を置くと、報告の質が上がる。実運用では、この節を入れて以降、報告の全項目が行番号つきになり、移し漏れの照合が1件ずつ根拠つきで返ってくるようになった。Codex は求められなければ、自分の作業を成功した前提で要約する。
+
+次をそのまま `<report>` の直前に置く。
+
+```text
+<self_check>
+報告を書く前に、次を実行する。省略しない。
+
+1. 報告に書こうとしている主張を、実際のコードで確認する。ファイル名と行番号を添える
+2. `git diff` を最初から最後まで通しで読む。依頼していない変更が混ざっていないか確認する
+3. この依頼文が「保存すべき挙動」として挙げた項目を1つずつ照合し、各項目が満たされている根拠を示す
+4. 追加・変更したテストが、変更前の実装でも通ってしまわないか確かめる。通るなら、そのテストは変更を検証していない
+5. 確認できていないことを「確認済み」と書かない。未確認は未確認と明示する
+</self_check>
+```
+
+この節は検収を置き換えない。裏取りを求めても、実装AIが自分の作業を検証しきれない領域は残る（テスト網羅の不足、サンドボックスで走らない検査、完了誤認）。ディレクター側の検収は同じだけ行う。
+
 ## 依頼文に必ず含める指示
 
 Codex がこの Skill の基本規則に沿って動くよう、依頼文（主に `<constraints>`）へ次を織り込む。
@@ -61,6 +81,18 @@ Codex がこの Skill の基本規則に沿って動くよう、依頼文（主
 
 `<acceptance_criteria>` は、目的を満たす実装が複数ありうるなら許容範囲まで書く。実運用では、判定条件を1つの数値に絞った依頼文のせいで、正しく動く実装を差し戻す無駄が発生した。検証したい振る舞いを書き、実装の選び方まで決めつけない。
 
+## 検証できない実装詳細を受入条件に書かない
+
+サンドボックスの外でしか確かめられない詳細を `<acceptance_criteria>` に書くと、Codex は確認できないまま従い、実行段階で落ちる。差し戻しの往復がそのまま増える。
+
+実運用では、本番 D1 からローカル D1 へデータを移す実装で2回続けて起きた。「除外するのは `sqlite_%` と `d1_migrations`」と書いたら内部テーブル `_cf_KV` を拾って rowid 不在で落ち、「`BEGIN` / `COMMIT` を維持する」と書いたらローカル D1 が SQL のトランザクション文を拒否して落ちた。どちらもネットワークが要るため Codex 側では検証できない。
+
+判断の順は次のとおり。
+
+1. その詳細をディレクター側で確かめられるなら、先に実行して確認し、結果を `<context>` に貼る。
+2. 確かめられないなら書かない。目的と満たすべき振る舞いだけを渡し、実装の詳細は Codex に決めさせる。
+3. どうしても方針を指定するなら「未検証の想定」と明示し、違っていたら報告するよう頼む。
+
 ## 検査コマンドの書き方
 
 `<verification>` には、その環境で実際に使う検査コマンドを具体的に書く（例: 型チェック・lint・テストの各コマンド）。何を実行し、何が通れば完了かを Codex 側だけで判定できるようにする。書く前に次を確認する。

.claude/skills/codex-director/references/execution.md

@@ -1,6 +1,21 @@
-# 実行経路の詳細と復旧手順
+# 実行経路のトラブルと復旧
 
-既定経路（Bash から companion を `run_in_background: true` で実行）で問題が起きたとき、またはユーザーが `/codex:rescue` の使用を明示したときに読む。
+既定経路（Bash から companion を `run_in_background: true` で実行）で発注が通らないとき、報告を回収できないとき、またはユーザーが `/codex:rescue` の使用を明示したときに読む。
+
+## 発注が即失敗する
+
+`Task <id> is still running. Use /codex:status before continuing it.` で止まったら、中断したジョブの記録が `running` のまま残っている。ハーネス側で止めても companion の状態は更新されない。
+
+```bash
+node "$P/scripts/codex-companion.mjs" status --all
+node "$P/scripts/codex-companion.mjs" cancel <job-id>
+```
+
+cancel 後の `--resume-last` は、まず `completed` のジョブ記録を探す。見つからなければ Codex のスレッド一覧を更新時刻順に辿るため、cancel したスレッドを再開することがある。中断分を捨てて出し直すなら `--resume-last` を外して新規タスクとして発注する。
+
+## 出力の冒頭に `command not found` が並ぶ
+
+依頼文がシェルに食われている（バックティックがコマンド置換として実行された）。Codex を止め、依頼文をファイルへ書いてから渡す方式で出し直す。副作用で起動したプロセスが残っていないかも確認する。
 
 ## なぜ Skill 経由を既定にしないか