## 何が起きたか 利用側のリポジトリのスプリント(devbase の m7c)で、課題の要求の検証手段に「手動確認(マージ前): arm64 で base と派生を建てて受け入れ条件 1〜6・8・9 を確かめる」があった。 実装のプランの担当は、非対話のセッションで Docker の取得が失敗して base を建てられなかった。それでも作業の報告は次の形で返った。 ```text - 作業: 実装 - 結果: 完了 - 見つけたもの: 1 件。…base を建てられず、大きさも測れていません - 次にすること: 対話できる端末で base を arm64・amd64 で建て、…受け入れ条件 1〜6・8・9 を確かめて PR に記録する ``` フェーズの報告も `結果: 完了`・`関門: 無し` で、実装のプランはスプリントブランチへマージまで進んだ。conductor が手動確認の残りを知ったのは、4 本の実装が入った後の検査のプラン(`6-check`)の merge-gate(exit 10「手動確認(マージ前)に確認の済んでいない行が 2 行ある」)だった。そこから確認を始めたため、スプリント PR のマージがその分遅れた。 ## 問題 - 担当が要求の手動確認を行えなかったことを自分で書いているのに、結果が「完了」になる - 実装のプランのフェーズの報告に「手動確認が残っている」が出ないため、conductor が次の実装と並行して確認を始められない。merge-gate が止めるのは正しいが、気づくのが最後になる ## 期待する振る舞い - 実装のプランのフェーズの報告に、その課題の「手動確認(マージ前)」の行と、担当が済ませたかどうかを出す(済んでいなければ conductor 向けの知らせにする) - 担当が要求の手動確認を行えなかったときは、結果を「完了」ではなく「判断が要る」か、少なくとも「残りあり」として返す ## 関連 - #1675(「無し」と書いた行を未確認として数える。こちらは中身のある行が実装の段階で見えない件) ndf 10.17.56 ## 再発(2026-10-06、スプリント m653・PR #1780) #653 の要求の手動確認(マージ前)「実装の Pull Request の `gh pr checks` に改名後の 3 つの名前と突き合わせのチェックが出る(AC2)」が、実装のプラン(PR #1776)では確かめられないまま「完了」で返り、検査のプランの merge-gate(exit 10)で初めて見えた。conductor が `gh pr checks` で 4 つのチェックの pass を確かめ、PR #1780 の本文にチェックを付けて `run --from merge-gate` で再開した。 今回の行は **コマンド 1 本で確かめられる中身**(チェック名の有無)だった。手動確認の行のうちコマンドで判定できるものは、実装のプランの中で worker が打って結果を本文へ書けば、merge-gate で止まらずに済む。後続の配布のプランが流れず、プランの複製(`7-release-r2.json`・`6-check-r2.json`)が要った(#1426 の表の 5)。 ## 追記(2026-10-11、スプリント m1683 の振り返り) 同じ形の残りがもう 1 つあった。#1661 の受け入れ条件 3 は「決めた理由を Pull Request の本文に書く」を求めていたが、実装のプランの PR #1898 の本文は消したことだけを書いて完了で返り、検査でも拾われず、本番 10.17.70 のリリース後テストで初めて不合格として見つかった(PR 本文へ理由を追記して合格にした)。この課題を直すときは、要求の手動確認に加えて、受け入れ条件が PR 本文へ書くことを求める項目も、実装のプランが完了で返る前に照らす対象へ入れる。
Activity
takemi-ohama commentedon Oct 11, 2026
同じ事象を PR #1906 の作業中に確認した。