通過工程の控えを記録のスクリプト自身が積むようにし、控えの取りこぼしと食い違いを根本原因の場所で直す

[takemi-ohama]

同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（issue-upkeep の判定「ルートコーズ」）。再現手順と観測は各子 issue にある。

修正レイヤー

通過工程の控えを積む責務の置き場所。

• いまは PreToolUse の hook（plugins/ndf/skills/development-workflow/scripts/workflow-guard.sh → lib/workflow-common.sh の wf_is_candidate / wf_parse_sync）が、実行されるコマンドの文字列から「記録のスクリプトが呼ばれた」ことを推測して控えを積む（references/stage-completeness.md）
• 記録を実際に行うスクリプト（plugins/ndf/scripts/progress-record.sh / projects-sync.sh）は、控えを積まない（grep -n stage-check → 0 件）
• 推測なので、スクリプトの呼び方（並べる・番号を変数で書く・例として文字列に書く・片方だけを呼ぶ）と、hook が動く版（配布済みの版の工程名の一覧）によって、本文と控えが食い違う

採る手

移動（move_responsibility）。記録のスクリプトが、盤面の宣言の有無を見る前（projects-sync.sh の pj_declaration || exit 0 より前）に stage-check.sh record を自分で呼ぶ。hook がコマンドの文字列から控えを積む形は外す。

マージの関門のように、外部のコマンドを観測するしかない判定は残る。その字句解析は #724 が持つ。

子 issue

子 issue	現象レイヤー	観測
#452	progress-tracking の呼び方（本文の記録と控えの 2 本）	課題の本文と控えが食い違っても、どちらも気づかない
#487	控えを積む hook（wf_parse_sync）	1 回の実行につき 1 件しか積まれず、番号を変数で書くと 1 件も積まれない
#580	控えを積む hook（wf_parse_sync）	ヒアドキュメントやコメントに書いた例が、実行していない工程として積まれる
#459	控えを積む hook（配布済みの版の工程名の一覧）	開発中の版で記録した工程名が、配布済みの版の hook に無く黙って捨てられる

完了条件

• 記録のスクリプトが自分で控えを積み、hook はコマンドの文字列から控えを積まない
• 複数の記録を並べる・番号を変数で書く・例として文字列に書く・片方のスクリプトだけを呼ぶ、のどの形でも本文と控えが一致することを検査が確かめる
• 盤面の宣言が無いリポジトリでも控えが積まれる
• 各子 issue の再現手順を実行し、現象が出ないことを確かめる（子 issue はその時点の棚卸が「閉じてよい」で閉じる）
• progress-tracking の「工程の単位と記録する課題」にある「後片付けまでの記録は課題ごとに 1 回の実行にする」の制約を外す（回避が要らなくなるため）

他の課題との関係

• Skill の主体をスクリプトへ移し、LLM は呼び出し・結果の解釈・判断だけを持つ（全 Skill の改善の親） #845 の「development-workflow との接点」2 項と progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856 の前提が、この完了条件と食い違う。 接点 2 項は「後片付けまでの進行の記録は『1 実行に 1 件』のまま」とし、progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856（bundle-close）もそれを前提に「複数の課題へ書くのは後片付けより後だけ」とする。この issue は完了条件でその制約を外す。この issue が先に入れば progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856 / merged: 後片付けの手順 1〜8 をスクリプトにし、LLM は止まった対象の同意だけを扱う #857 の前提を緩められる。後なら両者を直す手間が出る
• 設計: 待つ間の問い合わせを hook で止め、conductor の会話を工程の切れ目で切る（#829 #830） #843 の設計は控えを正として読む。 issues/issue-829-830-design.md 235 行は stage-check.sh report <番号> を「本文と食い違えば控えを正とする」として読む。控えの取りこぼしが、待ちの問い合わせと長い conductor の工程の起動を hook で止める（#829 #830） #844 の新しい hook の判定にも波及する
• コマンド単位の字句解析は 1 回の実行をコマンド単位で字句解析・列挙する層を置き、関門の観測の取りこぼしと誤検出を根本原因の場所で直す #724 が持つ（進行の記録の例をヒアドキュメントやコメントに書くと、実行していない工程が控えに積まれる #580 を共有する）

判断が要ること

• この issue を progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856（マイルストーン「23 配布の記録と課題系 Skill」）より前に置くか、Skill の主体をスクリプトへ移し、LLM は呼び出し・結果の解釈・判断だけを持つ（全 Skill の改善の親） #845 の接点 2 項を改めるか。 前に置くなら progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856 の前提はそのまま外せる。接点 2 項を改めるなら、この issue が入るまで progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856 / merged: 後片付けの手順 1〜8 をスクリプトにし、LLM は止まった対象の同意だけを扱う #857 は「1 実行に 1 件」の制約の下で作り、入った後に緩める

関連

• Skill の主体をスクリプトへ移し、LLM は呼び出し・結果の解釈・判断だけを持つ（全 Skill の改善の親） #845 — Skill の主体をスクリプトへ移す親（「development-workflow との接点」2 項）
• progress-tracking: 「まとまりを閉じる」をスクリプト 1 本（bundle-close）にする #856 — progress-tracking の「まとまりを閉じる」をスクリプトにする（bundle-close）
• merged: 後片付けの手順 1〜8 をスクリプトにし、LLM は止まった対象の同意だけを扱う #857 — merged の後片付けをスクリプトにする
• 設計: 待つ間の問い合わせを hook で止め、conductor の会話を工程の切れ目で切る（#829 #830） #843 / 待ちの問い合わせと長い conductor の工程の起動を hook で止める（#829 #830） #844 — 待つ間の繰り返し問い合わせ（sleep ループ・出力ファイルの読み直し）をやめ、完了通知か Monitor で待つ #829 / conductor の会話を工程の切れ目で切ることを hook で強制する #830 の設計と実装（控えを正として読む）
• 1 回の実行をコマンド単位で字句解析・列挙する層を置き、関門の観測の取りこぼしと誤検出を根本原因の場所で直す #724 — 1 回の実行をコマンド単位で字句解析・列挙する層