fix(chief-loop): author follow-up tickets instead of routing to chief-plan Phase 3

[mildronize]

Summary

chief-loop's own rule says it never stops for human input, but its documented fallback for
"frontier empty, goal not yet met" sent it to chief-plan Phase 3 — which has a hard
**STOP.** Wait for explicit approval before delegating to /chief-build. That silently
violated the never-stop rule the moment planning turned out incomplete.

Confirmed against a real run: tickets 6-13 resolved and verified, ticket 14 technically
unblocked, but two gaps tickets 7/11 had already flagged in their own reports meant attempting
it would fail — and the loop paused to ask instead of continuing.

Change 1: chief-loop authors its own follow-up tickets

• chief-loop Step 3 ("Check for story completion"): when the goal isn't met after the
  frontier empties, it now authors the missing ticket(s) itself — same shape chief-plan
  Phase 3 already uses (vertical-slice, Blocked by wiring, numbered continuing from the
  existing sequence) — instead of routing back to Phase 3's approval gate.
• Clarified chief-loop still doesn't originate a story's first ticket batch from nothing —
  only follow-up tickets once real execution reveals a gap in an existing batch.
• Added two explicit rules: never route a goal-not-met finding back to Phase 3, and no cap /
  no other in-loop convergence check on self-authored tickets — whether a story is
  well-specified enough to run this way unattended is loop-readiness's question to answer
  before starting, not something this skill re-litigates mid-run.
• Handling Ambiguity (mid-ticket decisions) is unchanged — evidence from the same real run
  shows a ticket that hits a gap but can still finish its own scope should just finish and note
  the gap in its report, not trigger this new path itself.

Change 2: loop-readiness checks for human-required steps

Designing change 1 surfaced a gap: loop-readiness (generic, no chief-specific knowledge by
design) had no dimension asking whether a plan has a step that needs a human present/deciding,
independent of environment-safety. Its closest existing check (real-environment write-scoping
under Feedback) wouldn't catch a step like ticket 14 — human-supervised by contract, but only
ever writing to a copy of real state, so it could pass that check anyway.

Added to DoR (2.1) and Step 3's recommendation examples, kept fully generic (no
chief/ticket-specific vocabulary in the file itself): if such a step exists, recommend keeping
it outside whatever mechanism the loop uses to select its own work automatically — a note that
"a human should be involved" has no effect once the loop is running unattended unless the step
is structurally excluded from what the loop can pick up on its own. (Chief's own concrete
application of this — not converting that step into a Type: implementation ticket — is
deliberately not written into this generic skill.)

🤖 Generated with Claude Code

https://claude.ai/code/session_0114nFLVGyyskAhCZEQV5BrH