Skip to content

cruise: 起動時に、不在の間にどこまで進めるかと止まる要因(マージの線・依存・衝突・判断待ち)を必ず点検して見せる #490

Open

Description

@hdknr

何が起きたか(2026-10-28・cruise #474 の再開)

/dev-loop:cruise 474 --absent を再開したとき、この cruise が不在の間にどこまで進めるかを、起動時の点検は何も言わなかった。利用者に「停止するリスク」を訊かれて、親が手で調べて初めて次が分かった:

  1. マージ の線がこのリポジトリでは効かない——台帳の線は マージ = 関門を通ればマージ だが、main へのマージがプラグインの配布を起こすので、各周は PR で止まる(dev-loop: マージがドキュメントのサイトの再デプロイしか起こさないリポジトリでも、不在の線「マージ = 関門を通ればマージ」が効かない #476 の決定。続きは dev-loop: プラグインの配布を起こすマージを、不在の周でマージしてよい反映に入れるかを決める #489)
  2. その結果、依存する周がいつまでも始まらない——マージ待ちの 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 が増えて終わる
  3. 既存の 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)。不在の周はこれを直しに戻らない
  4. マージの前に人間の判断が要る 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

Activity

  1. hdknr commented on Oct 28, 2026

    @hdknr
    OwnerAuthor

    実例の追加(2026-10-28・cruise #474)

    #499 の周の担当(サブエージェント)が、周の途中の課題 3 件を gh issue create で起票しようとして、自動モード(auto mode)の権限で拒否された。

    点検に入れるなら、「周の途中の課題 = 台帳に足して直す」「仕様の穴 = 推奨で決めて起票」の線があるとき gh issue create を周で使う操作として名指しし、利用者が居るうちに許可を足してもらう(または利用者が打つ操作にする)形が考えられる。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions