Repository navigation
cruise: 起動時に、不在の間にどこまで進めるかと止まる要因(マージの線・依存・衝突・判断待ち)を必ず点検して見せる #490
Copy link
Copy link
Open
Description
何が起きたか(2026-10-28・cruise #474 の再開)
/dev-loop:cruise 474 --absent を再開したとき、この cruise が不在の間にどこまで進めるかを、起動時の点検は何も言わなかった。利用者に「停止するリスク」を訊かれて、親が手で調べて初めて次が分かった:
マージの線がこのリポジトリでは効かない——台帳の線はマージ = 関門を通ればマージだが、main へのマージがプラグインの配布を起こすので、各周は PR で止まる(dev-loop: マージがドキュメントのサイトの再デプロイしか起こさないリポジトリでも、不在の線「マージ = 関門を通ればマージ」が効かない #476 の決定。続きは dev-loop: プラグインの配布を起こすマージを、不在の周でマージしてよい反映に入れるかを決める #489)- その結果、依存する周がいつまでも始まらない——マージ待ちの PR が 5 本(check-signoff.py: 照合の範囲を 2 つの承認が見た中身(shared/・requirements/・spec/・removed.csv)に広げる(#375) #479・雛形のフック: 素の URL の中の番号を書き換えない・decision_table の印で決定表を描く(#376) #481・scaffold.py: 中間表現のケースの ref(仕様の中の番号)が原文に在るかを生成と --check で見る(#465) #483・build-proposal.py: 出力の名前で拒むのは前後の空白だけだと文言を直す(#442) #485・spec-loop: 想定外の例外を 2(判定していない)に寄せ、読めなさの原因を取り違えない(#286) #486)、spec-loop: macOS で Removed.csv・Shared/ の扱いがスキルの差分と提案書で食い違う #276・spec-loop: #217〜#219 の狭いパスで素通りした変異に試料を足す #291 は spec-loop: 想定外の例外がトレースバックで 1 になり、1(違反)と 2(検査していない)の区別が崩れる #286(PR spec-loop: 想定外の例外を 2(判定していない)に寄せ、読めなさの原因を取り違えない(#286) #486)のマージ待ち。不在で回しても進むのは着手できる 3 件(spec-loop: proposal の SKILL.md と tree.md が、0.25.0 の出力が失敗の経路で残ることを書いていない #441・cruise: 文脈で止まった親がタイマーで空回りし、/clear 後も最後の周の worktree に閉じ込められて再開できない #484・dev-loop: プラグインの配布を起こすマージを、不在の周でマージしてよい反映に入れるかを決める #489)だけで、PR が増えて終わる
- 既存の PR が main と衝突している——check-signoff.py: 照合の範囲を 2 つの承認が見た中身(shared/・requirements/・spec/・removed.csv)に広げる(#375) #479・雛形のフック: 素の URL の中の番号を書き換えない・decision_table の印で決定表を描く(#376) #481・scaffold.py: 中間表現のケースの ref(仕様の中の番号)が原文に在るかを生成と --check で見る(#465) #483 が
CONFLICTING(gh pr viewを待って読み直して判明。最初はUNKNOWN)。不在の周はこれを直しに戻らない - マージの前に人間の判断が要る PR がある——台帳のメモに「P1 はマージ前に人間が判断」(scaffold.py: 中間表現のケースの ref(仕様の中の番号)が原文に在るかを生成と --check で見る(#465) #483)。マージの線があっても進めない
あわせて、check-unattended-env.py --cruise が出した「通知が未設定(要対処)」も、止まったことに気づけない要因として同じ場で並べたかった。
SKILL.md §1・§2 は「マージ の線がこのリポジトリで効くかを判定して添える」と書いているが、判定は親の散文の判断で、どの周がそれで止まるか(到達できる範囲)までは出さない。2〜4 はどこにも点検が無い。
求めること
cruise の起動時(新規・再開の両方、--absent の有無に依らず)に、止まる要因(ストッパー)の点検を必ず行い、利用者が離れる前に見せる。
- 少なくとも上の 1〜4 を出す。とくに 「台帳の線とリポジトリの性質のもとで、不在の間に着手・マージまで進める周」と「止まる周と、その理由」 を周ごとに出す(到達できる範囲)
- 判定は親の散文ではなくスクリプトで出す(
check-unattended-env.py --cruiseかparent-issue.py、または別の 1 本)。判定できない項目は「判定できない」と出し、通過と読まない - 再開の
--absent(タイマー越し)でも出す——訊きはしないが、6 で終えるときに渡す
受入基準(案)
- cruise spec-loop: 残課題を cruise で回す(親 Issue) #474 の今の台帳と実物(2026-10-28 時点)を入力にすると、上の 1〜4 がすべて出る
- 衝突・判断待ちが無く、マージの線が効くリポジトリでは、止まる要因を出さない(偽陽性が無い)
mergeableがUNKNOWNのまま読めないときは「判定できない」と出す
元の周: cruise #474(2026-10-28)。関係: #466(起動時の権限の点検)・#476・#484・#489
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
hdknr commentedon Oct 28, 2026
実例の追加(2026-10-28・cruise #474)
#499 の周の担当(サブエージェント)が、周の途中の課題 3 件を
gh issue createで起票しようとして、自動モード(auto mode)の権限で拒否された。check-unattended-env.py --cruise)はこれを事前に捕まえていない——分類器による拒否は settings に現れないので、「止まりうる操作」として訊く対象に入っていなかったgh issue createを通せていた(要確認: #291 で、読めた仕様がどれも中身が空なら check-spec-exit.py を 2 にした(空のファイルが混ざるだけなら止めない。推奨で決めた) #510・spec-loop: 置き場所の中の構造ファイルの綴り違い(shared/QA.csv)を、重ねた出力を読む側が区別しない FS でだけ構造ファイルとして読む #511・absent-lines: 「訊く場面」の割り目の項で太字が崩れている(**「このまま続ける」**)(#496 の残課題) #516・dev-loop: 他のファイルにも描画で太字が崩れる行が残る(SKILL.md ほか 30 行)(#516 の残課題) #519・dev-loop: SKILL.md 301 行の入れ子のバッククォートで、コードスパンが崩れて描かれる(#519 の残課題) #522〜spec-loop: 描画で崩れる太字が agents と SKILL.md ほかに残る(#523 の /code-review 1 パス目) #527 など)。同じ操作が周によって通ったり拒まれたりする点検に入れるなら、「周の途中の課題 = 台帳に足して直す」「仕様の穴 = 推奨で決めて起票」の線があるとき
gh issue createを周で使う操作として名指しし、利用者が居るうちに許可を足してもらう(または利用者が打つ操作にする)形が考えられる。