棚卸しで上限を超えて持ち越した候補が、次のスプリントの棚卸しへ渡らない #1640

何を見つけたか

upkeep.py candidates --limit N は、上限を超えた候補を metrics.deferred に番号だけ並べて終了コード 20 で返す（plugins/ndf/skills/backlog-refinement/scripts/upkeep.py の _candidate_result、141 行。deferred を作るのは 148 行、返すのは 232 行）。この番号を次の棚卸しへ渡す置き場が無い。

• 候補の記録（candidates.json）は $NDF_UPKEEP_STATE_DIR（既定は一時ディレクトリの ndf/backlog-refinement/。upkeep.py 123〜124 行の _state_dir）に置かれ、マシンをまたぐと残らない
• 次の candidates は持ち越しを自分では拾わない。拾われるのは、no-milestone と unscored の経路にもう一度掛かった課題だけである。差分の経路（diff-path / diff-identifier）で入った課題は、次の --since-ref の範囲に差分が無ければ候補へ戻らない
• 記録の PR のコメントを本文で検索する経路は当てにならない。gh api search/issues -f q='repo:devbasex/ai-plugins is:pr "配布の記録" in:comments' は 6 件しか返さなかった（2026-10-02 に実測）

今の回避は手作業の受け渡しである。plugins/ndf/skills/backlog-refinement/SKILL.md:183 が「持ち越しは完了報告に載せ、次の回に --add で渡す」と定め、upkeep.py 198 行の案内も「次の回に --add で渡すか --limit を上げる」と出す。

どこで見つけたか

#842 の設計（確定仕様 docs/specifications/ndf-backlog-refinement-stage.md ）。その「決定と理由」の 57 行が「持ち越しは報告に載せるまでにする」「受け渡しの置き場は #1640 が持つ」と定めている。#842 の要求の前提 5 は「上限を超えた候補は次のスプリントの棚卸しで --add で拾われる」としているが、--add へ渡す番号をどこから読むかは決めていない。

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

#842 の対象範囲は、棚卸しを工程表の行にすることと、1 回の件数に上限を置くことである。「含まない」に「upkeep.py の候補の集め方（5 つの経路・--all の基準）の変更」がある。持ち越しを自動で拾うには、候補の集め方か記録の置き場を変える必要がある。根拠: Value 1 / Value 6（MVV 版 2）

直さないと何が起きるか

open の課題が上限（既定 10 件）より多いリポジトリでは、差分の経路で入って持ち越された課題が、次の棚卸しで見直されないまま残る。拾えるのは、人が前の報告を読んで --add で渡したときか、--all で全件を見たときだけである。

直す場所

• 現象レイヤー: 次のスプリントの upkeep.py candidates が持ち越しを拾わない
• 修正レイヤー: upkeep の状態の置き場（upkeep.py 123〜124 行の _state_dir の既定が一時ディレクトリであること）と、candidates が前回の持ち越しを読まないこと
• 修正方針: 移動と新設。持ち越し（deferred）と backlog-refinement: apply が plan の rejected を依存先として一致した別の候補の値で記録し、却下が効かない #1595 の関連 (1) の却下（rejected.json）を、マシンをまたいで残る置き場へ移し、candidates がそこから前回の持ち越しを読む経路を足す。これで両方の「再起動・別マシンで判断や持ち越しが消える」が同じ形で直る

由来

#842 の設計（2026-10-02）

関連: #842 （閉じている）、#1595 （同じ置き場に却下の記録を持つ）