棚卸し: 自動の前倒しを退けると同じ rank で順位の表を書けず、先に打った反映で境界が動くと却下が効かない #2077

何を見つけたか

upkeep.py rank が扱い「自動」で返した前倒しを人が退けると、その rank の結果では順位の表を書けない。2026-10-19 の棚卸しの反映で次の 4 回が要った。

• upkeep_rank_cmd.py の RankPlan.unmoved は、扱いが「自動」の移動を順位の表が移したものとして置く。plan の rejected に書いても移さないため tables_withheld に入り、表は書かれない
• move_digest は切り出しの境界（番号・要約値・CoD）を含む（upkeep_rank.py の _candidates の base）。同じ回で閉じる・マイルストーンを移す反映を先に打つと境界が動き、却下が新しい候補と一致しなくなる
• 3 回目の後の rank では、前倒しが無くなったため後ろ倒しの 言語別の整形・静的解析の規約を NDF が Skill のリファレンスで持ち、規約の無いリポジトリへ移植する #1691 が rejected_stale に入り、apply が却下の記録から消した。後で前倒しが出れば 言語別の整形・静的解析の規約を NDF が Skill のリファレンスで持ち、規約の無いリポジトリへ移植する #1691 の後ろ倒しはもう一度提示される

どこで見つけたか

plugins/ndf/skills/backlog-refinement/SKILL.md の「手順 3: 反映する」（順位の表と前倒し・後ろ倒しの段落）。手順は「人が退けた移動は plan の rejected に書く」とだけ書き、自動の移動を退けたときに表を書くまでの順序（却下の記録 → rank の打ち直し → 表の反映）と、構造の変わる反映を却下より先に打つと却下が効かなくなることを書いていない。

なぜこの変更の範囲外なのか

この工程は棚卸しの案を反映して完了報告を出すまでで、upkeep.py と Skill の本文を直すことは含まない。根拠: NDF の共通原則の優先順位（効率は最下位。手順の不足で人の却下が効かなくなるのは利用者の承認の扱いに当たる）（MVV なし）

直さないと何が起きるか

• 自動の前倒しを退けるたびに、反映の担当が apply と rank を手順に無い順序で打ち直す。順序を知らない担当は tables_withheld で止まるか、却下が効かないまま表を書けない
• 却下を退けた時の rank と別の rank で記録すると、人が退けた移動がもう一度提示される

起票者の推定

• 直し方は 2 つありうる: 手順 3 に順序を書く（構造の変わる反映 → rank → 却下だけの apply → rank → 表の apply）か、apply が rejected を受けた自動の移動を unmoved から外して同じ回で表を書く（推した出所: upkeep_rank_cmd.py の RankPlan.unmoved・_placed_moves）
• rejected_stale で後ろ倒しの却下が消えるのは設計どおり（状況が変われば提示し直す）であり、不具合ではない（推した出所: upkeep_rank.py の _stale_rejections）

由来

issue #2065