fleet-commander-ai 0.0.1

package/templates/workflow.md

@@ -0,0 +1,513 @@
+<!-- Fleet Commander workflow template. Installed by Fleet Commander into your project. -->
+<!-- Placeholders {{PROJECT_NAME}}, {{project_slug}}, {{BASE_BRANCH}}, {{ISSUE_NUMBER}} are replaced during installation. -->
+
+# Diamond Workflow — {{PROJECT_NAME}}
+
+## About Fleet Commander
+
+Fleet Commander (FC) is the orchestration layer that manages your team. Key facts:
+
+- **Hooks** — FC monitors agent activity via hooks installed in the repo. Every tool use, session start/end, notification, and error is reported automatically. You do not need to report progress manually.
+- **CI/PR updates via stdin** — FC watches GitHub for CI results and PR status. When something changes, FC sends a message directly to the Team Lead (TL) via stdin. No PR Watcher agent is needed.
+- **Dashboard** — The PM watches all teams from the FC dashboard. They can see your state (Analyzing, Implementing, Reviewing, PR, Done, Blocked), recent events, and output in real time.
+- **Messages from FC** — FC may send structured messages to the TL (see "FC Messages" section below). These arrive as stdin messages and should be acted on promptly.
+- **Idle/Stuck thresholds** — FC marks agents idle after 3 minutes of inactivity and stuck after 5 minutes. Agents waiting for peer messages are expected to be idle — this is normal. TL should only intervene when stuck.
+
+## Worktree Awareness
+
+You are running inside a **git worktree**, not the main repository checkout. This has critical implications:
+
+- **NEVER run `git checkout {{BASE_BRANCH}}`** — the base branch is already checked out in the main worktree. Attempting to check it out here will fail with "already used by worktree."
+- **Use `git fetch origin {{BASE_BRANCH}}` and reference `origin/{{BASE_BRANCH}}`** whenever you need the latest base branch state. Do not try to switch to it.
+- **Your branch is your branch.** Create it, work on it, push it. Never switch away from it to {{BASE_BRANCH}}.
+- This applies to ALL agents (planner, dev, reviewer) — none of them should ever attempt to checkout {{BASE_BRANCH}}.
+
+## Entry Point
+
+```
+User: claude --worktree {{project_slug}}-{N}
+(prompt is sent via stdin from Fleet Commander's prompt file)
+```
+
+**Role of TL (main agent = You):**
+1. Read this workflow and understand the team structure
+2. **Phase 0: Spawn `fleet-planner` only** — planner analyzes the issue and produces a plan
+3. **Wait for planner's plan** — it arrives via `SendMessage` from the planner
+4. **Phase 1: Spawn `fleet-dev` with the plan context** — dev starts implementing immediately
+5. **Wait for dev to report "ready for review"** — dev sends a message when implementation is complete
+6. **Phase 2: Spawn `fleet-reviewer`** — reviewer starts reviewing immediately
+7. Let dev and reviewer communicate peer-to-peer — DO NOT relay messages between them
+8. Only intervene if: escalation after 3 review rounds, agent stuck (5min idle), or final PR creation
+9. When review passes: rebase, create PR, set auto-merge
+10. Respond to FC messages (ci_green, ci_red, pr_merged, nudge_idle, nudge_stuck)
+11. On pr_merged: close issue, shut down agents, finish
+
+## Team Composition — Diamond (3 Agents)
+
+| Agent | subagent_type | name | Role | Spawn |
+|-------|---------------|------|------|-------|
+| **Planner** | `fleet-planner` | `planner` | Analyzes issue + codebase, produces structured plan with guidebook paths. Sends plan to TL. Stays alive for p2p questions from dev and reviewer. | Phase 0 (immediate) |
+| **Dev** | `fleet-dev` | `dev` | Receives planner's plan at spawn, implements code, writes tests, pushes commits. Communicates with reviewer directly during review. Can ask planner questions via p2p. | Phase 1 (after plan) |
+| **Reviewer** | `fleet-reviewer` | `reviewer` | Spawned after dev reports ready. Two-pass code review. Sends feedback directly to dev. Reports final verdict to TL. Can ask planner questions via p2p. | Phase 2 (after dev ready) |
+
+There is NO coordinator agent. The TL orchestrates all three agents directly.
+
+All agents use `model: inherit` — they run on the same model as the TL.
+
+### Agent Lifecycle
+
+- **Agents are spawned sequentially** as each phase completes. This gives each agent the context it needs to start working immediately.
+- **Planner** is spawned first (Phase 0). It analyzes the issue, produces the plan, sends it to TL, and **stays alive** — available for p2p questions from dev and reviewer throughout the workflow.
+- **Dev** is spawned after the plan arrives (Phase 1). The TL includes the planner's plan in the dev's task prompt, so dev can start implementing immediately — no waiting.
+- **Reviewer** is spawned after dev reports ready (Phase 2). The TL includes the branch name and context in the reviewer's task prompt, so reviewer can start reviewing immediately — no waiting.
+- Once spawned, **agents stay alive** until the team is done. Planner persists as a knowledge resource. Dev persists through review rounds and CI fixes. Reviewer persists through all review rounds.
+- Dev and Reviewer communicate **peer-to-peer** — TL does not relay messages between them.
+
+### TYPE to Guidebook Mapping
+
+All implementation work is assigned to the single `fleet-dev` agent. The Planner's TYPE and Guidebooks fields tell the dev which guidebooks to read for domain-specific conventions.
+
+| TYPE in plan | Guidebooks to read |
+|---------------|-------------------|
+| C# / .NET | `csharp-conventions.md` |
+| F# | `fsharp-conventions.md` |
+| TypeScript / JS | `typescript-conventions.md` |
+| Python | `python-conventions.md` |
+| Infrastructure / CI | `devops-conventions.md` |
+| Generic / unknown | CLAUDE.md only (no language-specific guidebook) |
+| Mixed (A + B) | Multiple guidebooks — dev reads all relevant ones |
+
+## Workflow State Machine
+
+```mermaid
+stateDiagram-v2
+    [*] --> Setup : start (spawn planner)
+    Setup --> Analyzing : planner spawned
+    Analyzing --> Implementing : plan OK (TL spawns dev with plan)
+    Analyzing --> Blocked : BLOCKED in plan
+    Implementing --> Reviewing : dev reports ready (TL spawns reviewer)
+    Reviewing --> Implementing : REJECT (dev fixes, max 3 rounds)
+    Reviewing --> PR : APPROVE (TL creates PR)
+    PR --> Done : CI GREEN + merge
+    PR --> Implementing : CI RED (dev fixes, pushes)
+    Implementing --> Blocked : escalation
+    Reviewing --> Blocked : 3x REJECT
+    PR --> Blocked : 3 unique CI failure types
+    Done --> [*]
+```
+
+**Agents are spawned sequentially as phases complete.** Phase transitions represent when agents are spawned and which agent is actively doing primary work.
+
+**Blocked can be entered from any active state** when the team cannot proceed (missing info, unresolvable conflicts, repeated failures).
+
+---
+
+## Phase 0 — Setup (Spawn Planner)
+
+1. **TL spawns `fleet-planner`** with the issue number and project context.
+2. TL enters the Active Monitoring Loop (see below) while waiting for the plan.
+3. Planner analyzes the issue, explores the codebase, discovers guidebooks, and produces a structured plan.
+4. Planner sends the plan to TL via `SendMessage`. Planner stays alive for p2p questions from dev and reviewer.
+
+---
+
+## Active Monitoring Loop
+
+After spawning the first agent, the TL enters a continuous monitoring loop that runs throughout the entire workflow. This prevents the TL from going silent between phases.
+
+### Monitoring Rules
+
+1. **Run `TaskList` every 30-60 seconds** to check the status of all spawned agents. This is your heartbeat — never go more than 60 seconds without checking.
+2. **If any agent exits unexpectedly** (SubagentStop without sending expected output), **respawn immediately** — do not wait for the stuck detector's 5-minute threshold. However, observe the **respawn budget** (see below).
+3. **Between phases** (e.g., planner done, waiting for dev), actively verify the next agent is alive via `TaskList`. If the agent is gone, respawn it (within the respawn budget).
+4. **After each subagent phase completes, immediately proceed** to the next action:
+   - **Planner done** — validate the plan — spawn dev with the plan context
+   - **Dev done** — check dev output for completeness — spawn reviewer with branch context
+   - **Reviewer done** — immediately proceed to PR creation (rebase, `gh pr create`, auto-merge)
+5. **Never passively wait** — if you have nothing to do, run `TaskList` to confirm all agents are healthy.
+
+### What To Do When An Agent Is Missing
+
+If `TaskList` shows an agent is no longer running:
+1. Check the last output/events from that agent
+2. If the agent completed its work (sent its deliverable), proceed to the next phase
+3. If the agent exited without delivering, respawn it with the same task plus any additional context from the failed attempt
+
+### Respawn Budget
+
+**Maximum 5 total subagent spawns per team run.** This includes all initial spawns and all respawns across all agent types (planner, dev, reviewer).
+
+- Track your spawn count. Each `TaskCreate` call increments the count.
+- If you reach 5 spawns and an agent exits without delivering, **do NOT respawn**. Instead:
+  1. Take over the agent's role yourself (TL fallback).
+  2. If the role is too complex to take over (e.g., full implementation), report BLOCKED to FC.
+- This budget prevents respawn storms that waste time and resources without making progress.
+
+---
+
+## Phase 1 — Analysis
+
+1. Planner (spawned in Phase 0) reads the issue, explores the codebase, discovers guidebooks, and produces a structured plan
+2. **Planner sends the plan to TL via `SendMessage`**
+3. TL validates the plan has all required fields (see format below)
+4. TL evaluates the plan:
+   - `BLOCKED=yes` → state Blocked, comment on issue, STOP
+   - `BLOCKED=no` → proceed to Phase 2 (spawn dev with the plan)
+   - Missing required fields → ask Planner to redo with specific gaps identified
+
+### Plan Format
+
+The Planner produces a plan in this format:
+
+```
+## Plan for Issue #{N}
+
+### Language/Framework
+{primary language} / {framework(s)}
+
+### Guidebooks
+- {path/to/guidebook1.md}
+- {path/to/guidebook2.md}
+- (none found)
+
+### Type
+{single | mixed} — {developer mapping}
+
+### Key Files
+- {path} — {what changes and why}
+
+### What Needs to Change
+{Detailed analysis with implementation approach}
+
+### Risks
+- {specific risk or edge case}
+
+### Blocked
+no | yes — {reason}
+```
+
+### Edge Case: Planner Fails
+
+If the Planner is unresponsive for >5 minutes or produces an unusable plan:
+1. TL performs a quick analysis directly: read `CLAUDE.md`, scan the issue, identify key files
+2. Produce a minimal plan (Key Files + What Needs to Change + Type is enough)
+3. Proceed to Phase 2 — spawn dev with the TL-produced plan
+4. Do NOT spend more than a few minutes on this — a good-enough plan is better than a perfect one
+
+---
+
+## Phase 2 — Implementation
+
+1. **TL spawns `fleet-dev`** with the planner's plan included in the task prompt (see Dev Task Format below)
+2. Dev starts implementing immediately — it has the plan, guidebook paths, and all context it needs
+3. Dev implements, tests locally, commits atomically
+4. **Dev sends review request directly to TL** via `SendMessage`: "Ready for review. Branch: `{branch}`"
+5. TL transitions to Phase 3 — spawns reviewer
+
+### Dev Task Format (sent via TaskCreate at spawn)
+
+```
+ISSUE: #{N} {title}
+BRANCH: {feat|fix|test}/{N}-{short-desc}
+BASE: {{BASE_BRANCH}}
+
+PLAN:
+{paste the full planner's plan here}
+
+GUIDEBOOKS (read these before implementing):
+{list of guidebook paths extracted from the plan}
+
+INSTRUCTIONS:
+1. Read CLAUDE.md in the project root
+2. Read each guidebook file listed above
+3. Parse the planner's plan for implementation details
+4. Implement the changes described in the plan
+5. Follow conventions from CLAUDE.md and guidebooks
+6. Run build + tests locally before reporting ready
+7. Commit atomically: "Issue #{N}: {description}"
+8. Push the branch and report "Ready for review. Branch: {branch}" to TL
+```
+
+### Mixed-Language Work
+
+For mixed-type issues (e.g., C# backend + TypeScript frontend):
+1. Spawn the primary dev first (larger scope)
+2. When primary dev completes, spawn secondary dev with `blockedBy` dependency
+3. Wait for both to complete before review
+
+### Edge Case: Dev Gets Stuck
+
+- FC's stuck detector will nudge TL if the team is idle too long
+- TL checks if the dev agent is still active (TaskList)
+- If dev is stuck: send a message with more context, hints, or simplified scope
+- If dev is unresponsive after nudge: stop the dev agent, spawn a fresh one with additional context from the failed attempt
+
+---
+
+## Phase 3 — Review (Peer-to-Peer)
+
+1. **TL spawns `fleet-reviewer`** with the branch name, issue context, and guidebook paths (see Reviewer Task Format below)
+2. Reviewer starts reviewing immediately — it has all the context it needs
+3. **Dev and reviewer already know each other's names** (set at spawn time). No TL introduction needed.
+4. **TL steps back.** The dev-reviewer loop runs peer-to-peer:
+   - Reviewer performs two-pass review (code quality + acceptance)
+   - **REJECT** → reviewer sends actionable feedback directly to dev → dev fixes and re-requests review from reviewer directly
+   - **APPROVE** → reviewer notifies TL with the final verdict
+5. TL monitors but does NOT intervene unless:
+   - **3 review rounds exhausted** → TL arbitrates (see Error Handling)
+   - **Agent stuck** (5min idle) → TL sends a nudge
+   - **Escalation request** from either agent → TL steps in
+
+### Reviewer Task Format (sent via TaskCreate at spawn)
+
+```
+ISSUE: #{N} {title}
+BRANCH: {branch_name}
+BASE: {{BASE_BRANCH}}
+
+GUIDEBOOKS (read these to verify compliance):
+{list of guidebook paths from the plan}
+
+INSTRUCTIONS:
+1. Read CLAUDE.md in the project root
+2. Read each guidebook file listed above
+3. Review the changes on the branch against the base branch
+4. Two-pass review: code quality + acceptance criteria from the issue
+5. Send rejection feedback DIRECTLY to dev via SendMessage
+6. Send final APPROVE or REJECT verdict to TL (me)
+
+PEERS:
+- Dev agent name: dev
+- Send rejection feedback DIRECTLY to dev via SendMessage
+- Send final APPROVE or REJECT verdict to TL (me)
+
+If you reject, include a numbered list of specific, actionable fixes with file:line references.
+Dev will fix and message you directly when ready for re-review.
+Max 3 review rounds total (initial + 2 re-reviews).
+After 3rd rejection, report BLOCKED to TL.
+```
+
+### TL Non-Intervention Rules
+
+During the dev↔reviewer loop, TL MUST NOT:
+- Relay messages between dev and reviewer (they talk directly)
+- Ask "how's it going?" before an agent is stuck (5min)
+- Override reviewer's verdict (until round 3 escalation)
+- Tell dev to skip fixing a review comment
+- Inject new requirements not in the original issue
+
+TL MAY:
+- Respond to FC messages (ci_red, nudge_stuck, etc.)
+- Intervene on escalation from either agent
+- Arbitrate after 3 failed review rounds
+- Nudge an agent that has been idle for 5+ minutes
+
+---
+
+## Phase 4 — PR
+
+After reviewer sends APPROVE to TL:
+
+1. **Branch freshness check** (MANDATORY):
+   ```bash
+   git stash --include-untracked && git fetch origin {{BASE_BRANCH}} && git rebase origin/{{BASE_BRANCH}} && git stash pop && git push --force-with-lease
+   ```
+   The `git stash --include-untracked` is required because the CC runtime may leave unstaged changes (e.g., `.claude/settings.json`) that block rebase.
+   If rebase fails (conflicts) → state Blocked.
+
+2. **TL creates PR**:
+   ```bash
+   gh pr create --base {{BASE_BRANCH}} --title "Issue #{N}: {description}" --body "Closes #{N}"
+   ```
+
+3. **Set auto-merge immediately** (mandatory, no exceptions):
+   ```bash
+   gh pr merge {PR} --auto --squash --delete-branch
+   ```
+
+4. Wait for FC to send CI status via stdin:
+   - `ci_green` → auto-merge handles merge → wait for `pr_merged`
+   - `ci_red` → TL forwards failure details to dev → dev fixes and pushes
+   - After 3 unique CI failure types → state Blocked (FC sends `ci_blocked`)
+   - `pr_merged` → state Done
+
+---
+
+## Phase 5 — Done
+
+1. Close issue: `gh issue close {N} --comment "Closed. PR #{PR} merged."`
+2. **Explicit shutdown sequence** (MANDATORY):
+   a. Run `TaskList` to identify all active subagents.
+   b. For each active subagent, send `shutdown_request` via `TaskUpdate`.
+   c. Run `TaskList` again to verify all subagents have exited.
+   d. If any subagent is still running after shutdown_request, send a second shutdown_request, then proceed regardless.
+3. TL finishes
+
+---
+
+## BLOCKED State
+
+Entered from any phase when the team cannot proceed:
+1. Comment on the issue explaining what blocks progress
+2. Report blocker details to FC (visible in dashboard)
+3. STOP all work — wait for PM instructions from FC dashboard
+
+---
+
+## FC Messages
+
+Fleet Commander sends these messages directly to the TL via stdin. They arrive automatically — no polling needed.
+
+| Message ID | When | Content |
+|------------|------|---------|
+| `ci_green` | CI passes on PR | "CI passed on PR #{PR}. All checks green. Auto-merge is {status}." |
+| `ci_red` | CI fails on PR | "CI failed on PR #{PR}. Failing checks: {details}. Fix count: {N}/{max}." |
+| `ci_blocked` | Too many CI failures | "STOP. {N} unique CI failure types on PR #{PR}. Wait for instructions." |
+| `pr_merged` | PR is merged | "PR #{PR} merged. Close the issue, clean up, and finish." |
+| `nudge_idle` | Team idle 3+ min | "FC status check: You've been idle for {N} minutes. If waiting for subagents, run TaskList to verify they are still active. If a phase just completed, proceed to the next step." |
+| `nudge_stuck` | Team stuck 5+ min | "You appear stuck. Report status or ask for help." |
+
+### TL Response to FC Messages
+
+**On `ci_green`**: Auto-merge will handle the merge. Acknowledge and wait for `pr_merged`.
+
+**On `ci_red`**: Forward failure details to dev. Dev fixes and pushes. This counts toward the failure limit.
+
+**On `ci_blocked`**: STOP all work. Wait for PM instructions from the dashboard.
+
+**On `pr_merged`**: Close the issue, shut down agents (`shutdown_request` to all), finish.
+
+**On `nudge_idle`**: Run `TaskList` to verify all subagents are alive. If any agent is missing or crashed, respawn it. Report current status to FC.
+
+**On `nudge_stuck`**: Check which agent is stuck. Send a targeted nudge. If no progress after nudge, escalate to FC by reporting status.
+
+---
+
+## Error Handling
+
+### Agent Spawn Failure
+
+If spawning any agent fails:
+1. **Retry once** — wait 5 seconds, attempt spawn again
+2. **If retry fails** — TL takes over that agent's role:
+   - Planner fails → TL does the analysis themselves
+   - Dev fails → TL implements the code themselves
+   - Reviewer fails → TL reviews the code themselves (still two-pass)
+3. Log the failure for FC visibility (FC sees it via hooks)
+
+### Test Failure During Implementation
+
+1. Dev runs tests locally before reporting "ready for review"
+2. If tests fail → dev fixes and re-runs until green
+3. Dev does NOT report "ready for review" with failing tests
+4. If dev cannot fix tests after reasonable effort → dev reports blocker to TL → TL may assist or escalate
+
+### Review Loop Stuck (3 Rounds Exhausted)
+
+After 3 review rounds (initial + 2 fix rounds) with REJECT:
+1. Reviewer sends `BLOCKED — 3 review rounds exhausted` to TL
+2. TL reads the latest rejection feedback and the current code
+3. TL arbitrates:
+   - If remaining issues are minor nits → TL overrides and proceeds to PR
+   - If remaining issues are substantive → TL sends specific guidance to dev for one final attempt
+   - If fundamentally broken → state Blocked, comment on issue
+
+### Dev and Reviewer Disagree
+
+If the same issue bounces back and forth between dev and reviewer:
+- After round 2, if the same point is still contested, reviewer escalates to TL
+- TL reads the diff and the reviewer's feedback
+- TL arbitrates: either side with the reviewer (dev must fix) or override the reviewer (approve with noted exception)
+
+### CI Failure Handling
+
+1. `ci_red` received → TL forwards failure details to dev
+2. Dev fixes the failing tests/checks and pushes
+3. Progress on the same failure type does NOT count as a new unique failure
+4. After 3 unique failure types → state Blocked (FC sends `ci_blocked`)
+
+### Rebase Conflict
+
+1. If `git stash --include-untracked && git rebase origin/{{BASE_BRANCH}}` fails with conflicts → state Blocked
+2. Comment on issue explaining the conflict
+3. STOP — do not attempt manual conflict resolution across worktrees
+
+---
+
+## Branch Naming
+
+The TL determines the branch name based on the issue type and provides it to the dev in the task prompt:
+
+| Prefix | Use |
+|--------|-----|
+| `feat/{N}-{desc}` | New feature |
+| `fix/{N}-{desc}` | Bug fix |
+| `test/{N}-{desc}` | Test-only changes |
+
+### Commit Format
+
+```
+Issue #{N}: {description}
+```
+
+Atomic commits — each commit should be a logical unit.
+
+### Build Before Review
+
+**MANDATORY before reporting "ready for review"**: dev must run the project build and any new tests locally. This prevents unnecessary review iteration.
+
+---
+
+## Rules
+
+- **One issue at a time** — atomic changes only
+- **CI must be green** — PR CANNOT be merged with red CI
+- **Branch from {{BASE_BRANCH}}** — NEVER commit directly to {{BASE_BRANCH}}
+- **TL creates the PR** — dev pushes code, TL creates the PR and sets auto-merge
+- **P2P for review** — dev and reviewer talk directly, TL does not relay
+- **Idle = normal** — agents waiting for messages are expected to be idle
+- **TL intervenes only on escalation, stuck, or PR** — do not micromanage the dev↔reviewer loop
+- **Respond to FC messages promptly** — FC messages arrive via stdin and require action
+- **TL does not implement** — spawn subagents for all work (except planner fallback)
+- **Planner failure is not fatal** — TL can produce a minimal plan if planner fails
+
+## Anti-Patterns
+
+| Wrong | Right |
+|-------|-------|
+| TL relays messages between dev and reviewer | Dev and reviewer talk directly (p2p) |
+| TL asks "how's it going?" every minute | Wait for report or 5min stuck threshold |
+| TL implements code while dev is active | Let dev do the implementation |
+| TL overrides reviewer without reading feedback | Read feedback, arbitrate only after 3 rounds |
+| Dev pushes without local tests | Build + tests locally BEFORE reporting ready |
+| Dev pushes without rebase | ALWAYS stash + rebase on {{BASE_BRANCH}} before push |
+| Respawning agents endlessly | Max 5 total spawns — then TL takes over or reports BLOCKED |
+| Checking out {{BASE_BRANCH}} in a worktree | NEVER checkout {{BASE_BRANCH}} — use `origin/{{BASE_BRANCH}}` as reference |
+| Dev creates the PR | TL creates the PR after APPROVE |
+| Spawning a coordinator / 4th agent | Diamond team is exactly 3 agents: planner, dev, reviewer |
+| Spawning all 3 agents at once before analysis is done | Spawn sequentially: planner first, then dev with plan, then reviewer after dev ready |
+| Ignoring FC messages | Always respond to ci_green, ci_red, pr_merged, nudges |
+| Respawning agent after 2 min idle | Idle is normal — only act at 5min stuck threshold |
+| TL monitors CI manually | FC handles CI monitoring and sends updates via stdin |
+| TL goes idle after spawning agents without monitoring | TL runs active monitoring loop between phases |
+
+## Decision Summary
+
+```
+Phase 0: TL → spawn planner only
+Phase 1: Planner analyzes → sends plan to TL → planner stays alive for p2p questions
+         TL validates plan → spawns dev WITH the plan context
+Phase 2: Dev implements immediately (has plan) → reports "ready for review" to TL
+         TL spawns reviewer WITH branch context
+Phase 3: Reviewer reviews immediately (has branch) → dev + reviewer iterate p2p → reviewer reports verdict to TL
+Phase 4: TL → rebase → create PR → set auto-merge → FC monitors CI
+Phase 5: TL → close issue → shutdown agents → finish
+```
+
+Edge cases:
+- Planner fails → TL does quick analysis, produces plan, spawns dev with it
+- Planner declares BLOCKED → TL reports blocked, STOP
+- Dev stuck → TL nudges, then restarts with more context
+- 3 rejections → TL arbitrates: simplify, override nits, restart dev, or abort
+- Dev/Reviewer disagree → TL arbitrates after round 2
+- CI blocked → STOP, wait for PM