開発ループ: 出し直しの周回の設計のプランが古い手元のブランチから始まり、push が拒まれて止まる #2503

正本: #2489 に統合した（同じ現象と期待を #2489 が持つ）

何が起きたか

開発ループ lroot3 の周回 8 で、利用者が「直して出し直す」（loop answer --revise）と答えた #2338 を選び、設計のプランを流した（2026-11-05 JST）。

1. 作業場所 .worktrees/design/issue-2338 は周回 4 の時の手元のブランチを使い回した。手元の先頭は d44b4fc（周回 4 の組み直し）で、周回 4 のクロスレビューの修正 2 コミット（670a3ac91・215950750）はリモートの design/issue-2338 にだけあった
2. design のステップは新しいコミットを作らず（指摘を反映していない）、rebuild のステップだけが 567e2e891 を足した
3. pr のステップの push が non-fast-forward で拒まれ、プランは「止まった」で終わった（記録: .ndf/loop/lroot3/lap-8/sprint/1-design-2338-state/05-pr.out）

手で 567e2e891 をリモートの先頭へ載せ直すと、設計文書が衝突した。

期待

• 出し直しの周回の設計のプランは、開いている設計 PR のブランチ（リモート）の先頭から始める
• design のステップは課題の本文の指摘の節を読み、反映したコミットを作る。作らなければ止まる

再現

1. 設計 PR を出した課題に loop answer <名> <課題> --revise --note <ファイル> で答える
2. 手元に古い worktree を残したまま、次の周回で loop sprint → queue
3. pr のステップの push が non-fast-forward で拒まれる

範囲

supervise.py new sprint の設計のプランの作業場所の用意（既存の worktree・ブランチの扱い）と、出し直しの指摘の渡し方。

根本原因の束（2026-11-06）

carul から届いた課題を根本原因で束ねた（利用者の指示「ひとつづつ直すのではなく根本原因を見つけて対処してください」）。この課題は #2648（束 B） に入る。1 件ずつ直さず、束の根本原因を直した後に、この課題の再現の手順を 1 回通して閉じるか残すかを決める。