retrospective が最後に issue-upkeep を呼ぶが、その作業は工程表にも持ち場にも無く、範囲と費用の上限が無い

[takemi-ohama]

何を見つけたか

retrospective は最後に issue-upkeep を呼ぶよう指示しているが、その作業は development-workflow の工程表にも持ち場の表にも無い。 3 層で通すとき、supervisor は skill の指示に従って工程表に無い作業へ入り、範囲と費用の上限が無いまま進む。

文書	記述
retrospective/SKILL.md:332	「まとまりを閉じる」の後に /ndf:issue-upkeep を呼ぶ。
retrospective/SKILL.md:348	/ndf:issue-upkeep — 蓄積した課題の手入れ（この工程の最後に呼ぶ）
development-workflow/SKILL.md の「モードごとに起動する Skill」	issue-upkeep の行が無い（grep -n issue-upkeep が 0 件）
development-workflow/references/agent-layers.md の持ち場の表	仕上げ = 配布（本番）/ リリース後テスト / 振り返り。終わりの条件は「振り返りの記録を投稿した」。issue-upkeep は現れない

supervisor から見ると、持ち場の終わりの条件を満たした後に、skill が次の作業を指示している状態になる。どちらに従っても、もう一方の文書に反する。

観測（devbase v3.7.0、2026-09-23）

仕上げの持ち場の担当が、振り返りの記録を投稿した後に、開いている 21 件すべての棚卸しへ入った。

時刻（JST）	出来事
08:18	振り返りを配布の Pull Request へ投稿（持ち場の終わりの条件を満たした）
08:18〜08:38	取りこぼしの起票（6 件）に続けて、open 21 件の判定・本文の書き換え・ラベル付け・マイルストーンの操作
08:38	進行側（conductor）が範囲外と判断して打ち切り

打ち切りまでに外部へ書かれていたもののうち、このまとまりと関係のない課題への書き込みが 5 件あった（他リポジトリの課題 4 件の本文の書き換えと追記、1 件の書き直し）。ほかにラベル 2 件、マイルストーンのクローズ 1 件。

担当は指示に従っただけである。 retrospective を最後まで読めばこの動きになる。

なぜ問題か

1. 持ち場の終わりの条件と、skill の指示が食い違う。 supervisor は「報告を返す」か「skill を最後まで通す」かを選ばされる
2. 費用に上限が無い。 対象は「変更をまたいで溜まった課題そのもの」で、件数はリポジトリの状態で決まる。1 回の変更の工程としては、かかる費用が事前に読めない。今回の担当は 368k トークン / 277 回のツール実行を使い、その最後の 20 分がこの作業だった
3. 進行側（conductor）に止める材料が無い。 conductor は工程表と持ち場の表を基準に持ち場を組む。工程表に無い作業が始まっても、それが正しい手順なのか逸脱なのかを判定できない
4. 取り消しにくい書き込みが混ざる。 課題の本文の書き換え・ラベル・マイルストーンは、まとまりの外の課題に対して行われる。レビューを通らない

修正レイヤー

現象レイヤー: retrospective/SKILL.md の「蓄積した課題を手入れする」の節。

修正レイヤー: 工程の境界を決めている development-workflow。issue-upkeep を工程として扱うかどうかは、工程表と持ち場の表が唯一の基準である（development-workflow/SKILL.md の「判定基準を持つのはこの Skill だけである」）。retrospective の側だけを直すと、同じ食い違いが別の skill で再発する。

retrospective は既に、境界そのものは正しく述べている（:333-335）。

振り返りが拾うのは、この変更から出た取りこぼしである。変更をまたいで溜まった課題そのものは対象にしていない。

対象が違うと書きながら、同じ節で呼び出しを指示しているのが食い違いの本体である。

決めること

• issue-upkeep を工程表の行にするか。するなら単位は何か（まとまりではない。リポジトリ単位で、配布とは別の周期になるはず）
• 工程にしないなら、retrospective の「この工程の最後に呼ぶ」を落とし、人が別に起動するものとして書き直すか
• 3 層で通すとき、skill が持ち場の終わりの条件の先を指示していたらどうするかの規約を置くか（supervisor は報告を優先する、など）
• issue-upkeep に、このまとまりに関係する課題だけを対象にする入口を設けるか（振り返りから呼ぶ経路に上限を与える）

#863 の書き換えの前に決める。 #863 は retrospective をスクリプト化し、SKILL.md を書き換える。決める前に
書き換えると、新しい本文へ同じ呼び出しの指示が写される。

上限の入口は #864 の upkeep.py candidates の件数の上限である。 #864 の受け入れ条件は「候補の件数で 1 回の
費用に上限を置ける」を持つ。振り返りから呼ぶ経路に上限を与えるなら、ここを使う。

development-workflow の工程表と持ち場の表は #845 の子 issue の対象外で、#827 の子と #843 が扱う。この決定は
#845 の接点 1〜3（工程名・工程表の正本・worker は記録しない）に触れる。

関連

• retrospective: 記録先の決定・PR の特定・由来の検索・投稿をスクリプトにする #863 — retrospective のスクリプト化
• issue-upkeep: 候補の収集と反映（照合・待ち行列つき）をスクリプトにし、LLM は判定だけを持つ #864 — issue-upkeep のスクリプト化（upkeep.py candidates）
• development-workflow: トークン消費の実測と削減（supervisor をスクリプトで駆動し、判断は最小構成の claude -p に任せる） #827 — supervisor の駆動と費用の削減

由来

devbase v3.7.0（マイルストーン 4 / 8 課題）の仕上げの持ち場。devbasex/devbase の配布の Pull Request は devbasex/devbase#212。