同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（issue-upkeep の判定「ルートコーズ」）。再現手順と観測は各子 issue にある。
修正レイヤー
cross-review が GitHub と git へ行う書き込み（レビューの投稿・修正の push・サマリの投稿）の置き場所。
- いまは担当が行う。レビューは担当の CLI が
gh api で直接投稿し（plugins/ndf/skills/cross-review/scripts/launch-reviewer.sh:95）、修正は担当のサブエージェントが git push origin {HEAD_BRANCH} で送る（docs/02-fix-and-rotation.md:104）
- 進行側の
scripts/state.py は結果ファイルを読むだけで、実物と照合しない（_merge_fix_records 3945 行目、cmd_verify_sweep 4187 行目）
- 投稿の待ち行列
plugins/ndf/scripts/lib/post_queue.py は進行側にあるが、担当の投稿は通らない
- 書き込みと、進行側が読む記録を担当が別々に行うため、打ち切り・detach の作業ツリー・書き忘れのどれでも、記録と実物が食い違う
採る手
移動（move_responsibility）。cross-refactoring の「公開するのは進行側だけ」と同じ形にする。担当は結果ファイルだけを書く。進行側は結果ファイル（レビューの payload は path / line / body / severity を既に持つ）から post_queue.py を通して投稿し、修正は HEAD:<head> で push し、サマリも投稿する。
直すときは、既存の決定 docs/03-review-output.md:86（AI 直接投稿）と SKILL.md:52（メインはペイロードを保持しない）を改める。
進行側の投稿は、結果ファイルのパスを post_queue.py へ渡す形にする。 cross-review/references/context-budget.md（v10.15.0）は「メイン」を収束ループを駆動している supervisor と定め、その context window に diff を載せないと決めている。進行側が投稿を持つとき、payload の本文を supervisor の応答へ載せず、スクリプトがファイルから読んで送る。
子 issue
| 子 issue |
現象レイヤー |
観測 |
| #548 |
結果の読み取り（_verify_declared_comments） |
レビュー本文だけに指摘を書いた担当が「結果なし」と扱われ、収束が止まる |
| #583 |
起動し直しの分岐 |
投稿の後に打ち切られた担当の指摘が記録されず、起動し直した担当が同じ指摘を重ねて投稿する |
| #350 |
担当と fix の投稿 |
待ち行列を素通りし、上限の間に失われる |
| #585 |
修正のサブエージェントの完了報告 |
push の報告と実物が食い違う。detach の作業ツリーでブランチ名を push すると、終了コード 0 で何も送らない |
| #676 |
PR の Conversation |
修正ラウンドと最終スイープのまとめが残らない回が多い。v10.15.0 の 3 層の運転（修正は worker）でも PR #740 / #742 で 0 件 |
完了条件
- 担当は結果ファイルだけを書き、レビューの投稿・修正の push・サマリの投稿は
state.py が行う
- 「投稿済みで記録なし」「push したと報告して実物なし」の状態が起きないことを検査が確かめる
fix を単独で使う経路（返信と Resolve）の扱いを決める- 各子 issue の再現手順を実行し、現象が出ないことを確かめる（子 issue はその時点の棚卸が「閉じてよい」で閉じる）
進行
モード: standard / 作業ツリー: .worktrees/feat/issue-730-writes-to-conductor
閉じた理由
PR #801 で直り、ndf 10.16.0（2026-09-22、main / タグ ndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。
振り返り: #810 (comment)
同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（
issue-upkeepの判定「ルートコーズ」）。再現手順と観測は各子 issue にある。修正レイヤー
cross-review が GitHub と git へ行う書き込み（レビューの投稿・修正の push・サマリの投稿）の置き場所。
gh apiで直接投稿し（plugins/ndf/skills/cross-review/scripts/launch-reviewer.sh:95）、修正は担当のサブエージェントがgit push origin {HEAD_BRANCH}で送る（docs/02-fix-and-rotation.md:104）scripts/state.pyは結果ファイルを読むだけで、実物と照合しない（_merge_fix_records3945 行目、cmd_verify_sweep4187 行目）plugins/ndf/scripts/lib/post_queue.pyは進行側にあるが、担当の投稿は通らない採る手
移動（
move_responsibility）。cross-refactoring の「公開するのは進行側だけ」と同じ形にする。担当は結果ファイルだけを書く。進行側は結果ファイル（レビューの payload はpath/line/body/severityを既に持つ）からpost_queue.pyを通して投稿し、修正はHEAD:<head>で push し、サマリも投稿する。直すときは、既存の決定
docs/03-review-output.md:86（AI 直接投稿）とSKILL.md:52（メインはペイロードを保持しない）を改める。進行側の投稿は、結果ファイルのパスを
post_queue.pyへ渡す形にする。cross-review/references/context-budget.md（v10.15.0）は「メイン」を収束ループを駆動している supervisor と定め、その context window に diff を載せないと決めている。進行側が投稿を持つとき、payload の本文を supervisor の応答へ載せず、スクリプトがファイルから読んで送る。子 issue
_verify_declared_comments）fixの投稿完了条件
state.pyが行うfixを単独で使う経路（返信と Resolve）の扱いを決める進行
モード: standard / 作業ツリー:
.worktrees/feat/issue-730-writes-to-conductor閉じた理由
PR #801 で直り、ndf 10.16.0（2026-09-22、
main/ タグndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。振り返り: #810 (comment)