@cloverleaf/reference-impl 0.12.0 → 0.13.0

package/skills/cloverleaf-run/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cloverleaf-run
-description: End-to-end orchestrator. Reads task.risk_class to dispatch fast lane (implement → review → merge) or full pipeline (implement → document → review → [ui-review?] → qa → final-merge). Per-agent bounce counters (max 3 each). Usage — /cloverleaf-run <TASK-ID>.
+description: End-to-end orchestrator. Drives every task through one universal delivery council — implement → documenting → council → final-gate/implementing/escalated. The lane is a risk_class profile selector (delivery-fast / delivery-full); security, UI, and QA are council members. Usage — /cloverleaf-run <TASK-ID>.
 ---
 
 # Cloverleaf — run (orchestrator)
@@ -11,128 +11,71 @@ description: End-to-end orchestrator. Reads task.risk_class to dispatch fast lan
 
 Do NOT `git checkout main` from a walker worktree — main is held by the primary repo. To compare against main, use `git diff main..HEAD` or `git show main:<path>`. Sub-skills run from the worktree's current branch and stay on it; the walker (in the primary repo) does the final merge to main itself after all tasks reach final-gate.
 
-## Per-agent bounce budget
+## Bounce budget
 
-```
-MAX_REVIEWER_BOUNCES    = 3
-MAX_UI_REVIEWER_BOUNCES = 3
-MAX_QA_BOUNCES          = 3
-MAX_SECURITY_BOUNCES    = 3
-```
+The delivery council owns the loop. `council_bounces` (max 3) counts council bounces back to the Implementer; `plan_review_bounces` (max 3) counts decisive plan-review bounces. On either cap, escalate (section 6). Security, UI, and QA are **council members**, not separate gates — there is no per-agent counter.
 
 These counters live in-session (not persisted). Rerunning `/cloverleaf-run` resets.
 
-## Security gate (both lanes)
-
-Run this immediately after the task reaches `automated-gates` (Reviewer passed) and BEFORE the lane's next move (fast lane: merge; full pipeline: detect-ui-paths). Initialize `security_bounces = 0` at orchestrator start (alongside the other bounce counters).
-
-```bash
-cloverleaf-cli classify-security <repo_root> <TASK-ID> --branch cloverleaf/<TASK-ID>
-```
-
-Parse the JSON. If `classify-security` exits non-zero or emits unparseable output, do NOT silently skip security review (fail-open is unsafe for a security gate). Warn to the user and treat the task as `effective: "high"` — i.e. proceed into security-review anyway (fail toward more scrutiny). If `/cloverleaf-security-review` then cannot run either (e.g. branch/tooling broken), surface the failure and stop rather than merging unreviewed.
-
-If `effective == "low"` → skip the gate, proceed with the lane.
-
-If `effective == "high"`:
-- If `declared == "low"` (under-classification: `diff_detected` true), you may proactively run `classify-security` to confirm, but the writeback to `security_class: "high"` is now mechanical — the CLI handles it automatically when `advance-status` moves the task to `security-review`. No manual scripting of the writeback is required.
-- `cloverleaf-cli advance-status <repo_root> <TASK-ID> security-review agent`; commit.
-- Inline `/cloverleaf-security-review <TASK-ID>` steps. Reload the task:
-  - `status == "automated-gates"` → security review passed; proceed with the lane.
-  - `status == "implementing"` → bounced. `security_bounces += 1`. If `security_bounces >= MAX_SECURITY_BOUNCES`, escalate (section 6). Else re-enter the implement→review loop (fast lane section 4 / full pipeline section 5.1), which re-runs the security gate on its next pass.
-  - `status == "escalated"` → the security reviewer found a blocker; stop and surface to the user (a human must review `.cloverleaf/feedback/`). This is the security reviewer's own escalation, distinct from a bounce-budget exhaustion.
-
-### Refusal and recover
-
-In v0.8.1, `advance-status` from `automated-gates` to any post-gate state (`ui-review`, `qa`, `merged`) may exit with **exit code 2** when the task is high-security and has no pass verdict recorded (`security_review_verdict` is absent or not `"pass"`). This is a **security-gate refusal** — the CLI is enforcing that high-security tasks must pass security review before proceeding.
-
-Recovery sequence:
-1. Advance the task to `security-review` first: `cloverleaf-cli advance-status <repo_root> <TASK-ID> security-review agent`; commit.
-2. Run `/cloverleaf-security-review <TASK-ID>` to execute the security review.
-3. Retry the original `advance-status` call. If the review passed, the CLI will now allow the transition.
-
 ## Steps
 
-1. Capture TASK-ID.
-
-2. Load task: `cloverleaf-cli load-task <repo_root> <TASK-ID>`. Verify `status === "pending"`. If not, report and stop.
-
-3. **Council gate detection (opt-in).** Run `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.review` and parse the JSON plan. If `plan.source === "consumer"` **and** `plan.profile !== null`, the project has opted into a configured review council — drive the review phase via **section 7 (Council review path)** instead of the hardcoded reviewer/security/ui/qa steps in sections 4/5. Otherwise (`source: "default"`, or no `task.review` binding) proceed exactly as today:
-   - `task.risk_class === "low"` → section 4 (Fast Lane)
-   - `task.risk_class === "high"` → section 5 (Full Pipeline)
-
-   When the council path is active it still uses the Implementer (and, for the full pipeline, the Documenter) to produce the branch; only the review→merge portion is council-driven.
-
-### 4. Fast Lane
-
-Initialize `reviewer_bounces = 0`, `security_bounces = 0`.
+1. Capture TASK-ID. Initialize `council_bounces = 0`, `plan_review_bounces = 0`.
 
-Loop:
-  a. Inline `/cloverleaf-implement <TASK-ID>` steps.
-  b. Inline `/cloverleaf-review <TASK-ID>` steps.
-  c. Reload task. If `status === "automated-gates"`: pass! Break loop.
-  d. If `status === "implementing"`: Reviewer bounced. `reviewer_bounces += 1`. If `reviewer_bounces >= MAX_REVIEWER_BOUNCES`, escalate (section 6). Else continue loop.
-  e. Else: unexpected state. Report and stop.
+2. Load task: `cloverleaf-cli load-task <repo_root> <TASK-ID>`. Verify `status === "pending"`. If not, report and stop. **Preflight:** `load-task` does not schema-validate. Before dispatching any agent, confirm the task document is schema-valid: `context.rfc` is present, and `risk_class` / `security_class` are `low` or `high`. An invalid task otherwise clears every precondition and fails at its first real transition — after the Implementer has already produced a branch and commits.
 
-After loop (status `automated-gates`): run the **Security gate (both lanes)** (above). Then inline `/cloverleaf-merge <TASK-ID>`.
+   If any `advance-status` later fails with `orphan event written to … but task save failed`, the event file it names records a transition that did not happen: delete that file before retrying, or the retry will number the next event around it.
 
-### 5. Full Pipeline
+3. **Tactical plan (+ optional decisive plan-review).**
+   a. `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.plan_review`. **A decisive `task.plan_review` is not currently wired — do not bind one.** `/cloverleaf-implement <TASK-ID>` always completes both advances (`pending → tactical-plan → implementing`) in a single dispatch and stops at `implementing`; there is no point at which a plan-review verdict can be applied. If a consumer's `.cloverleaf/config/council.json` bound `plan.mode === "decisive"` for this gate anyway, §3b's `cloverleaf-cli apply-council-verdict <repo_root> <TASK-ID> task.plan_review '<verdict>'` would fail — it requires the task to still be at `tactical-plan`, and by the time `/cloverleaf-implement` returns it is already at `implementing`. The shipped default binds no profile to `task.plan_review` (`plan.profile` is always `null` here), so this limitation does not affect the packaged pipeline; it is tracked as a follow-up, not built in this fix. Otherwise (no decisive plan-review bound — the shipped default) simply inline `/cloverleaf-implement <TASK-ID>`, which walks `pending → tactical-plan → implementing` and stops at `implementing`.
+   b. **Reserved — not reachable today.** Applying a decisive `task.plan_review` verdict requires the task to still be at `tactical-plan`, and 3a never leaves it there under the current `/cloverleaf-implement`, so skip 3b unconditionally and continue to 3c. The bullets below record the intended reload logic for when a real stop-at-`tactical-plan` mode exists:
+      - `implementing` (pass) → continue to 3c.
+      - `pending` (bounce) → `plan_review_bounces += 1`; if `>= 3` escalate (section 6); else return to 3a.
+      - `escalated` → stop and surface.
+   c. Finish the Implementer (task at `implementing`), then reach `documenting` for **every** `risk_class`:
+      - `risk_class: "high"` → run `/cloverleaf-document <TASK-ID>` (the Documenter adds doc commits and advances `implementing → documenting`).
+      - `risk_class: "low"` (no docs) → the **runner** advances the state itself: `cloverleaf-cli advance-status <repo_root> <TASK-ID> documenting agent`, then commit (`git add .cloverleaf/ && (git diff --cached --quiet || git commit -m "cloverleaf: <TASK-ID> → documenting")`).
 
-Initialize `reviewer_bounces = 0`, `ui_reviewer_bounces = 0`, `qa_bounces = 0`, `security_bounces = 0`.
+      Either way the task reaches `documenting` before §4a advances `documenting → council`.
 
-5.1. **Implementer → Documenter → Reviewer loop:**
+4. **Delivery council.**
+   a. Enter the phase: `cloverleaf-cli advance-status <repo_root> <TASK-ID> council agent`. Commit. (Council entry classifies security — a sensitive diff upgrades `security_class` to `high` so the blocking security member runs.)
+   b. `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.review`. The plan always carries a profile: the shipped default binds `task.review` to `delivery-fast` (`risk_class: low`) / `delivery-full` (`risk_class: high`); a consumer `.cloverleaf/config/council.json` overrides.
+   c. Run the council members (section 7.2), reach the verdict (7.3 chair / 7.4 deterministic), and — **before** applying it — run the **baselines-hold check (section 4.1)**. Then, once cleared, `cloverleaf-cli apply-council-verdict <repo_root> <TASK-ID> task.review '<verdict>'`. Commit the remainder: `git add .cloverleaf/ && (git diff --cached --quiet || git commit -m "cloverleaf: <TASK-ID> council review (<verdict>)")`.
 
-Loop:
-  a. Inline `/cloverleaf-implement <TASK-ID>` steps.
-  b. Inline `/cloverleaf-document <TASK-ID>` steps.
-  c. Inline `/cloverleaf-review <TASK-ID>` steps.
-  d. Reload task. If `status === "automated-gates"`: pass! Exit this loop.
-  e. If `status === "implementing"`: Reviewer bounced. `reviewer_bounces += 1`. If `reviewer_bounces >= MAX_REVIEWER_BOUNCES`, escalate. Else continue loop.
-  f. Else: unexpected. Report and stop.
+### 4.1 Baselines hold (before applying a council pass)
 
-**Security gate.** Run the **Security gate (both lanes)** (above) now, before UI-path detection. Then continue to 5.2.
-
-5.2. **UI-path detection and conditional UI Review:**
+The collapse removed the old `ui-review → qa` hold that `baselines_pending` guarded; the hold moves to **council pass**. After the members run (the `ui` member captures baselines and, on new/resized baselines, sets `baselines_pending=true` via `write-ui-review-state` — that mechanism is unchanged), and **before** applying a council `pass` that would advance `council → final-gate`, read the ui-review state:
 
 ```bash
-cloverleaf-cli detect-ui-paths <repo_root> <TASK-ID>
+cloverleaf-cli read-ui-review-state <repo_root> <TASK-ID>
 ```
 
-If output is `true`:
-  - Advance: `cloverleaf-cli advance-status <repo_root> <TASK-ID> ui-review agent --path=full_pipeline`. Commit.
-  - UI-review loop:
-    a. Inline `/cloverleaf-ui-review <TASK-ID>` steps.
-    b. Reload task. If `status === "qa"`: pass! Exit UI-review loop.
-    c. If `status === "implementing"`: UI Reviewer bounced. `ui_reviewer_bounces += 1`. If `>= MAX_UI_REVIEWER_BOUNCES`, escalate. Else return to section 5.1 (Implementer re-runs, which then re-documents, re-reviews).
-    d. Else: unexpected. Report and stop.
-
-If output is `false`: skip UI review. Advance: `cloverleaf-cli advance-status <repo_root> <TASK-ID> qa agent --path=full_pipeline`. Commit.
-
-5.3. **QA loop:**
+- If the council verdict is `pass` **and** `baselines_pending` is `true`: do **NOT** apply the verdict. Surface to the human: "⏸ `<TASK-ID>` — new visual baselines need approval. Inspect the captured baseline images, then run `/cloverleaf-approve-baselines <TASK-ID>` (which clears `baselines_pending`) and re-run `/cloverleaf-run <TASK-ID>` — the `ui` member now passes and the council pass applies." Stop here (leave the task at `council`); the re-run re-dispatches the council with `baselines_pending=false`.
+- Otherwise (`baselines_pending` is `false`, or the verdict is `bounce` / `escalate`): proceed to apply the verdict (step 4c). This is a runner **convention** — no FSM change, exactly as the old `ui-review → qa` hold was a convention. `/cloverleaf-approve-baselines` and the `write-baseline` guard are unchanged.
 
-Loop:
-  a. Inline `/cloverleaf-qa <TASK-ID>` steps.
-  b. Reload task. If `status === "final-gate"`: pass! Exit loop.
-  c. If `status === "implementing"`: QA bounced. `qa_bounces += 1`. If `qa_bounces >= MAX_QA_BOUNCES`, escalate. Else return to section 5.1.
-  d. Else: unexpected. Report and stop.
-
-5.4. **Final merge:** First run the **Advisory `final_gate` council** (§7.6) if a consumer has bound `task.final_gate`. Inline `/cloverleaf-merge <TASK-ID>` steps (branches to full-pipeline gate per state).
+5. **Branch on the task's new status** (reload with `load-task`):
+   - `final-gate` (pass) → run the advisory `final_gate` council (section 7.6) if bound, then inline `/cloverleaf-merge <TASK-ID>`.
+   - `implementing` (bounce) → `council_bounces += 1`. If `>= 3`, escalate (section 6). Else return to 3c (re-implement; the batched council feedback is in `.cloverleaf/feedback/`).
+   - `escalated` → stop and surface (`.cloverleaf/feedback/` + `.cloverleaf/runs/<TASK-ID>/council/task.review.json`).
 
 ### 6. Escalation
 
 - `cloverleaf-cli advance-status <repo_root> <TASK-ID> escalated agent`
 - Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> escalated (bounce budget exhausted)"`.
-- Report: "✗ Escalated `<TASK-ID>`. Review `.cloverleaf/feedback/` and either refine the task or take over manually. Counters: reviewer=<N>, ui_reviewer=<N>, qa=<N>, security=<N>."
+- Report: "✗ Escalated `<TASK-ID>`. Review `.cloverleaf/feedback/` and either refine the task or take over manually. Counters: council_bounces=<N>, plan_review_bounces=<N>."
 
-### 7. Council review path (opt-in; active when council-plan source is "consumer")
+## 7. Delivery council mechanics
 
-Initialize `council_bounces = 0`.
+The council member-dispatch, verdict, and apply steps referenced by steps 3b / 4c / 5.
 
-7.1 **Produce the branch.** Run the Implementer (`/cloverleaf-implement <TASK-ID>` steps); for `risk_class: "high"` also run the Documenter (`/cloverleaf-document <TASK-ID>` steps). The task reaches `review`.
+7.2 **Run the council members (verdict-only).** Re-run `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.review` to get `plan.rounds`, `plan.aggregation`, `plan.on_round_bounce`, and (for a chair profile) `plan.chair`. For each round **in order**: dispatch **all active members in the round concurrently** — issue their Task-tool calls **in a single message** so the harness runs them in parallel — and capture each member's `{verdict, summary, findings}` envelope. Do **not** advance state (the task stays at `council` until you apply the verdict at step 4c). Rounds still run in sequence; only members *within* a round are concurrent. (Built-in members resolve to the shipped `reviewer`/`security-reviewer`/`ui-reviewer`/`qa` prompts by their `promptPath`; a custom role resolves to `.cloverleaf/prompts/<file>.md`.)
 
-7.2 **Run the council members (verdict-only).** Re-run `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.review` to get `plan.rounds`, `plan.aggregation`, `plan.on_round_bounce`, and (for a chair profile) `plan.chair`. For each round **in order**: dispatch **all active members in the round concurrently** — issue their Task-tool calls **in a single message** so the harness runs them in parallel — and capture each member's `{verdict, summary, findings}` envelope. Do **not** advance state. Rounds still run in sequence; only members *within* a round are concurrent. (Built-in members resolve to the shipped `reviewer`/`security-reviewer`/`ui-reviewer`/`qa` prompts; a custom role resolves to `.cloverleaf/prompts/<file>.md`.)
+   **Dispatch conventions:** invoke the Task tool in foreground (default — never `run_in_background`); do not poll with foreground `sleep`. Substitute the five base tokens, plus every entry in that member's `substitutions` map from the plan:
+   - `{{task}}`, `{{branch}}` (`cloverleaf/<TASK-ID>`), `{{base_branch}}` (`main`), `{{repo_root}}`, `{{diff}}` (`git diff main..cloverleaf/<TASK-ID> -- ':(exclude).cloverleaf/'`) — the five base tokens, always present.
+   - `{{<key>}}` for every key in `substitutions`: `council-plan` resolves each member's extra tokens beyond the five base ones (e.g. `test_rules` for `reviewer`, `qa_rules` for `qa`, `affected_routes` / `ui_review_config` / `taskId` for `ui`; `security`'s map is empty — its prompt needs no extra tokens).
+   - **`{{preview_port}}` — the one exception.** `ui-reviewer.md` declares it, but it is deliberately NOT in the plan's `substitutions`: planning must stay side-effect free and cannot allocate a port without one. When dispatching the `ui` member, the runner must allocate a free port itself and substitute `{{preview_port}}` before dispatch — the same way the standalone `cloverleaf-ui-review` skill does: `PREVIEW_PORT=$(node -e "const net=require('net');const s=net.createServer();s.listen(0,()=>{console.log(s.address().port);s.close()})")`.
 
-   **Dispatch conventions:** invoke the Task tool in foreground (default — never `run_in_background`); do not poll with foreground `sleep`. Substitute `{{task}}`, `{{branch}}` (`cloverleaf/<TASK-ID>`), `{{base_branch}}` (`main`), `{{repo_root}}`, `{{diff}}` (`git diff main..cloverleaf/<TASK-ID> -- ':(exclude).cloverleaf/'`).
+   Never dispatch a member with an unresolved `{{…}}` token. The three bullets above are the complete set of substitution sources: the five base tokens, every key in that member's `substitutions`, and — for `ui` only — `{{preview_port}}`. Apply all three, then scan the filled prompt text; if any `{{…}}` remains, stop and report rather than letting the member improvise. (Nothing should: `tests/council.test.ts` pins every built-in prompt's declared tokens against exactly those three sources, so a leftover means the prompt and `MEMBER_TOKENS` have drifted.)
 
    Persist each member's envelope: `echo '<envelope>' > /tmp/clv-council-<member>.json && cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/clv-council-<member>.json --prefix=<prefix>`, where `<prefix>` is `r`/`s`/`u`/`q` for the built-ins and the **member id** for a custom role. Collect a members array `[{ "member": "<id>", "verdict": "<pass|bounce|escalate>", "blocking": <plan member blocking>, "weight": <plan member weight> }]`.
 
@@ -145,28 +88,24 @@ Initialize `council_bounces = 0`.
      - Otherwise (a blocking member bounced; no member escalated) **dispatch the chair.** Build enriched inputs `[{ "member", "verdict", "blocking", "weight", "envelope": <the member's /tmp/clv-council-<member>.json object> }]`; run `context=$(cloverleaf-cli chair-context '<enriched-inputs-json>')`. Dispatch the chair prompt at `plan.chair.promptPath` as a **read-only** foreground subagent, substituting `{{task}}`, `{{repo_root}}`, and `{{member_verdicts}}` = `$context`; capture its `{verdict, rationale, forward}` output. Then run `cloverleaf-cli chair-verdict '<chair-raw-json>' '<members-json>'` and capture the council verdict JSON.
    - **Else (deterministic):** map `plan.aggregation` to the CLI rule (a string passes through; `{ "quorum": k }` → `quorum:k`) and run `cloverleaf-cli aggregate-verdicts '<members-json>' <rule>`; capture the council verdict JSON.
 
-7.4 **Apply.** Run `cloverleaf-cli apply-council-verdict <repo_root> <TASK-ID> task.review '<council-verdict-json>'`. The FSM walk may self-commit some transitions (e.g. `security_class → high`, the rework verdict-reset), so the wrap-up commit can find nothing staged — that is expected. Commit the remainder: `git add .cloverleaf/ && (git diff --cached --quiet || git commit -m "cloverleaf: <TASK-ID> council review (<verdict>)")`.
-
-7.5 **Branch on the task's new status (reload with `load-task`):**
-   - `automated-gates` (fast lane pass) or `final-gate` (full pipeline pass) → proceed to the merge: inline `/cloverleaf-merge <TASK-ID>`.
-   - `implementing` (bounce) → `council_bounces += 1`. If `council_bounces >= 3`, escalate (section 6). Else return to 7.1.
-   - `escalated` → stop and surface to the user (review `.cloverleaf/feedback/` and `.cloverleaf/runs/<TASK-ID>/council/task.review.json`).
+7.4 **Apply.** After the baselines-hold check (section 4.1) clears, run `cloverleaf-cli apply-council-verdict <repo_root> <TASK-ID> task.review '<council-verdict-json>'`. The FSM walk may self-commit some transitions (e.g. `security_class → high`, the rework verdict-reset), so the wrap-up commit can find nothing staged — that is expected. Commit the remainder: `git add .cloverleaf/ && (git diff --cached --quiet || git commit -m "cloverleaf: <TASK-ID> council review (<verdict>)")`. The verdict drives the FSM: `pass` → `council → final-gate`; `bounce` → `council → implementing`; `escalate` → `council → escalated` (branch per step 5).
 
 On a chair **bounce**, the result artifact's `forward` array names the members whose feedback the Implementer should prioritize; the chair `rationale` frames them. The council result artifact at `.cloverleaf/runs/<TASK-ID>/council/task.review.json` records per-member verdicts, the aggregate (or chair) verdict, `forward` (for a chair bounce), and the security basis (incl. an omitted or out-voted `security` member). On any member-dispatch failure or unparseable envelope, stop and report — never treat a failed member as a pass.
 
-### 7.6 Advisory `final_gate` council (opt-in; full pipeline only)
+### 7.6 Advisory `final_gate` council (opt-in)
 
-`final-gate` is reached only in the full pipeline and is already the human merge pause. Before inlining `/cloverleaf-merge <TASK-ID>` at a full-pipeline final gate (both here at 7.5 and at §5.4), check for an advisory council:
+`final-gate` is the human merge pause. Before inlining `/cloverleaf-merge <TASK-ID>` at the final gate (step 5), check for an advisory council:
 
 1. `cloverleaf-cli council-plan <repo_root> <TASK-ID> task.final_gate`.
 2. If `plan.source !== "consumer"` or `plan.profile === null`, skip — proceed to the plain human merge (today's behavior).
 3. Otherwise dispatch `plan.rounds` per §7.2 (parallel within a round), reviewing `{{diff}}` = `git diff main..cloverleaf/<TASK-ID> -- ':(exclude).cloverleaf/'`, and reach a verdict per §7.3 (chair) or §7.4-style `aggregate-verdicts` (deterministic). Then `cloverleaf-cli apply-council-verdict <repo_root> <TASK-ID> task.final_gate '<council-verdict-json>'`. This **posts** the advisory result to `.cloverleaf/runs/<TASK-ID>/council/task.final_gate.json` + a feedback envelope and **drives no transition** (the task stays at `final-gate`). Commit: `git add .cloverleaf/ && (git diff --cached --quiet || git commit -m "cloverleaf: <TASK-ID> advisory final_gate council (<verdict>)")`.
 4. Surface the council verdict + rationale to the human at the merge confirmation. The human still drives `/cloverleaf-merge` (merge) or reject; the advisory council never merges.
 
-The **fast lane's** `human_merge` (`automated-gates → merged`) is not a council gate. `task.plan_review` (advisory, at `tactical-plan`) is supported at the CLI/library level (`council-plan task.plan_review`, `apply-council-verdict task.plan_review`) for a consumer with a human checkpoint at `tactical-plan`; it is not auto-inserted into this autonomous runner.
+`task.plan_review` (decisive, at `tactical-plan`) is **not currently wired** (see §3a/§3b); `task.final_gate` is advisory-only and post-only.
 
 ## Rules
 
-- Each agent has its own 3-bounce budget. Bounces from different agents do NOT share counters.
-- On any sub-skill error or escalation, orchestrator stops with clear message.
+- The delivery council owns the bounce loop: `council_bounces` (max 3) and `plan_review_bounces` (max 3). There is no per-agent counter — security, UI, and QA are members.
+- On any sub-skill error or escalation, the orchestrator stops with a clear message.
 - Human merge gate is NOT skipped; confirmation is still required at merge time.
+- The baselines-hold is a convention: a council `pass` is held at `baselines_pending` until `/cloverleaf-approve-baselines <TASK-ID>` clears it and the council is re-run.

package/skills/cloverleaf-run-plan/SKILL.md

@@ -162,7 +162,7 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
 
       - **`tool_decision_required`** → let the walker policy decide (auto-approve per rules, defer to user for anything not covered).
 
-      - **`turn_completed [DONE]`** → the session has finished its current turn with a `[DONE]` terminal token. If the on-disk task status is `final-gate` or `automated-gates`, push onto the final-gate queue. Otherwise continue monitoring.
+      - **`turn_completed [DONE]`** → the session has finished its current turn with a `[DONE]` terminal token. If the on-disk task status is `final-gate`, push onto the final-gate queue. Otherwise continue monitoring.
 
       - **`turn_completed [NEEDS-INPUT]`** → the session is paused waiting for a user reply. Surface the assistant's last message to the driver and send the user's response via `mcp__claw-drive__send_turn`.
 
@@ -179,7 +179,7 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
       ```
       This covers transient API errors (e.g. HTTP 503, `API Error: 503`) and the `temporarily unavailable` service message without requiring a Session A nudge from the human.
 
-   e. **Drain the final-gate queue serially and merge on main.** Session B does NOT invoke `/cloverleaf-merge` — it stops at automated-gates (fast lane) or final-gate (full pipeline) and reports. The walker performs the merge on main in the primary repo. For each queued task:
+   e. **Drain the final-gate queue serially and merge on main.** Session B does NOT invoke `/cloverleaf-merge` — it stops at final-gate and reports. The walker performs the merge on main in the primary repo. For each queued task:
 
       **Scope check (BEFORE the y/N prompt).** Run `cloverleaf-cli check-scope` and capture its output and exit code:
 
@@ -204,10 +204,10 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
 
       1. Print a full summary to the driver:
          ```
-         ⏵ <TASK-ID> ready to merge (<fast lane | full pipeline>)
+         ⏵ <TASK-ID> ready to merge
            Reviewer: <summary>
            UI Reviewer: <summary or "skipped">
-           QA: <summary or "n/a for fast lane">
+           QA: <summary or "skipped">
            Session <session_id>, worktree <worktree_path>
 
            Confirm merge? (y/N, or ask a question)
@@ -224,7 +224,7 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
            echo "$CHANGED_FILES" | xargs grep -l -E '^(<{7}|={7}|>{7})' 2>/dev/null
            # Do NOT proceed; mark task escalated and surface to user
          else
-           git -C <repo_root> merge --no-ff cloverleaf/<TASK-ID> -m "cloverleaf: <TASK-ID> merged (<fast_lane | full_pipeline>)"
+           git -C <repo_root> merge --no-ff cloverleaf/<TASK-ID> -m "cloverleaf: <TASK-ID> merged"
          fi
          ```
 
@@ -232,12 +232,8 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
 
          After a **successful** `git merge --no-ff`, advance state and commit:
          ```bash
-         # Fast lane:
-         cloverleaf-cli emit-gate-decision <repo_root> <TASK-ID> human_merge approve human
-         cloverleaf-cli advance-status <repo_root> <TASK-ID> merged human human_merge fast_lane
-         # Full pipeline (task is already at final-gate):
          cloverleaf-cli emit-gate-decision <repo_root> <TASK-ID> final_approval_gate approve human
-         cloverleaf-cli advance-status <repo_root> <TASK-ID> merged human final_approval_gate full_pipeline
+         cloverleaf-cli advance-status <repo_root> <TASK-ID> merged human final_approval_gate
          ```
          ```bash
          git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> merged"
@@ -350,32 +346,29 @@ stay on the worktree's current branch (`cloverleaf/<TASK-ID>`).
 
 Plan: invoke `/cloverleaf-run <TASK-ID>`.
 
-**DO NOT invoke `/cloverleaf-merge`**. Fast lane stops after `/cloverleaf-review`
-lands the task at `automated-gates`. Full pipeline stops after QA/UI-Review
-lands the task at `final-gate`. Report status + summaries at that point and
-exit cleanly. The walker runs in the primary repo on `main` and performs the
-real `git merge --no-ff` itself after human approval — the worktree's main
-branch can't be checked out concurrently, which is why the walker owns the
-merge. If `/cloverleaf-run` would normally invoke `/cloverleaf-merge`
-internally (fast-lane orchestrator), interrupt before that step and exit.
-
-All four v0.5.2+v0.5.3+v0.5.4+v0.5.5 dogfood fixes are in place:
-- /cloverleaf-merge actor: human final_approval_gate full_pipeline.
+**DO NOT invoke `/cloverleaf-merge`**. Delivery lands the task at `final-gate`; do NOT invoke `/cloverleaf-merge`; report status + summaries at that point and exit cleanly. The walker runs in the primary repo on `main` and performs the real `git merge --no-ff` itself after human approval — the worktree's main branch can't be checked out concurrently, which is why the walker owns the merge.
+
+All v0.5.2+v0.5.3+v0.5.4+v0.5.5 dogfood fixes are in place:
+- /cloverleaf-merge actor: human final_approval_gate.
 - cloverleaf-cli prep-worktree is idempotent.
 - Documenter runs `git status --porcelain` and stages every modified doc.
 - cloverleaf-ui-review uses /cloverleaf-approve-baselines (fully-qualified).
 
-Expected: zero interventions until you reach automated-gates / final-gate,
-then exit.
+Expected: zero interventions until you reach final-gate, then exit.
 
 Do not push. Do not publish. Report merge + state commit SHAs on completion.
 ```
 
 ## Walker policy
 
-The walker spawns each Session B with a conservative auto-approve policy (Read/Glob/Grep, git-read, cloverleaf-cli, npm/npx/node, common compound scripts, prep-worktree, mkdir -p, etc.) and an auto-reject list covering sudo, `rm -rf /`, git push, npm publish, destructive disk ops. Anything else escalates to the walker for human-in-the-loop handling.
+The walker spawns each Session B with a conservative policy resolving every tool call to one of four outcomes:
+
+- **auto-approve** — Read/Glob/Grep, git reads (including `git -C <path> …`), `npm`/`npx`, `node <script>`, `cloverleaf-cli` anywhere in a compound script, and the usual `set -e` / `cd` / `export` / `source` prefixes.
+- **auto-defer** — pauses for a human: `sudo`/`su`, and anything that runs code the command regex cannot inspect (`node -e`/`-p`, `python -c`, `perl -e`, `sh -c`, `eval`), plus `chmod -R 777`, `chown -R`, `truncate`, `systemctl stop`.
+- **auto-reject** — recursive `rm`, `git push`, `git reset --hard`, `npm publish`, `curl … | bash`, disk-destructive ops (`dd if=`, `mkfs`, `shred`, `fdisk`), writes to real block devices, and writes to claw-drive's own policy file or `.claw-drive/` runtime state.
+- **escalate** — everything else goes to the walker for human-in-the-loop handling.
 
-The concrete policy JSON is the same one used during the CLV-16..CLV-20 dogfood runs; see `.cloverleaf/claw-drive-policy.json` in the repo for the starting template.
+The concrete policy is `.cloverleaf/claw-drive-policy.json` in this repo — a starting template, not a guarantee; tune it for your own project. It tracks claw-drive's shipped starter with a few deliberate divergences, each recorded in the file's own `_comment`. After editing it, run `node .cloverleaf/policy-check.mjs`, which asserts the decision for every command in `.cloverleaf/policy-probes.tsv` and exits non-zero on a regression.
 
 ## Rules
 
@@ -395,4 +388,4 @@ The concrete policy JSON is the same one used during the CLV-16..CLV-20 dogfood
 
 **RFC-direct task participation in RFC auto-advance.** Tasks with no `parent` field but with `context.rfc` set (created via `/cloverleaf-new-task --rfc=<RFC-ID>`) are *first-class* participants in the `can_auto_advance_rfc` check. They block the advance when in-flight; they count toward delivery when merged. See `cloverleaf-cli rfc-tasks <repo_root> <RFC-ID>` for the categorized view this dispatch reads from, or `reference-impl/README.md` § "Plans vs RFC-direct tasks" for the user-facing pattern docs.
 
-**Security-review escalations.** When a task's effective `security_class` is high, `/cloverleaf-run` routes it through `security-review` off the automated-gates hub. A `blocker` finding (e.g. a leaked credential) advances the task to `escalated`, which surfaces through the walker's existing escalation path — expect and surface these like any other escalation; do not auto-retry a security blocker.
+**Security-review escalations.** When a task's effective `security_class` is high, `/cloverleaf-run` routes it through `security-review` as a council member. A `blocker` finding (e.g. a leaked credential) advances the task to `escalated`, which surfaces through the walker's existing escalation path — expect and surface these like any other escalation; do not auto-retry a security blocker.

package/skills/cloverleaf-security-review/SKILL.md

@@ -1,9 +1,18 @@
 ---
 name: cloverleaf-security-review
-description: Run the Security Reviewer agent on a task in the `security-review` state. Hybrid two-pass (deterministic secret scan + LLM vulnerability judgment); emits a feedback envelope; advances to automated-gates (pass), implementing (bounce), or escalated (blocker). Usage — /cloverleaf-security-review <TASK-ID>.
+description: Run the Security Reviewer council member on a task's feature branch as a standalone one-off. Hybrid two-pass (deterministic secret scan + LLM vulnerability judgment). Emit-only — it records the `security_review_verdict`, writes a feedback envelope, and reports the verdict (pass/bounce/escalate) for the delivery council or a human to apply. It does NOT advance the task FSM. Usage — /cloverleaf-security-review <TASK-ID>.
 ---
 
-# Cloverleaf — security review
+# Cloverleaf — security review (emit-only council member)
+
+The delivery states `security-review`/`automated-gates` no longer exist — the `@cloverleaf/standard` task FSM
+collapsed them into a single `council` phase (Council Slice 4). The Security Reviewer is now a **council member**
+that the runner (`/cloverleaf-run`) dispatches; its blocking verdict gates the aggregated council result. A single
+member cannot drive the multi-member council to merge, so this standalone skill is **emit-only**: it runs the two
+passes against the task's branch, records the `security_review_verdict`, emits the feedback envelope, and reports
+the verdict. **It does not advance the FSM** — the council or a human applies the aggregated verdict via
+`apply-council-verdict` (which is what advances `council → final-gate`/`implementing`/`escalated` and records the
+authoritative security backstop for high-security tasks).
 
 ## Steps
 
@@ -14,7 +23,7 @@ description: Run the Security Reviewer agent on a task in the `security-review`
 
 1. Capture the TASK-ID argument.
 
-2. Load the task: `cloverleaf-cli load-task <repo_root> <TASK-ID>`. Verify `status === "security-review"`. If not, report the current status and stop.
+2. Load the task: `cloverleaf-cli load-task <repo_root> <TASK-ID>`. Light guard only: confirm the task exists and is not terminal (`merged`/`rejected`/`escalated`). Do NOT hard-require any particular state — this skill reviews the branch, not a specific FSM state. If the task is terminal, report the current status and stop.
 
 3. Confirm the branch `cloverleaf/<TASK-ID>` exists: `git rev-parse --verify cloverleaf/<TASK-ID>`. If missing, report the discrepancy and stop. Compute the diff for the subagent (do NOT check out): `git diff main..cloverleaf/<TASK-ID>`.
 
@@ -38,43 +47,39 @@ description: Run the Security Reviewer agent on a task in the `security-review`
    - else any `error` or `warning` → `verdict: "bounce"`
    - else (only `info`, or none) → `verdict: "pass"`
 
-7. **Branch on verdict:**
+7. **Emit the verdict + envelope (no FSM advance).**
+
+   Record the member's `security_review_verdict` on the task (a live field the council's `council → final-gate` backstop reads for high-security tasks), then emit the merged feedback envelope. **Never call `advance-status`** — the council/human applies the aggregated verdict.
 
    **Pass:**
    ```bash
    cloverleaf-cli set-task-field <repo_root> <TASK-ID> security_review_verdict pass
    git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security_review_verdict → pass"
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> automated-gates agent
-   git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security review passed → automated-gates"
    ```
-   Report: "✓ Security review passed. State → automated-gates."
+   Report: "✓ Security Reviewer verdict: **pass**. Recorded `security_review_verdict=pass`. This is one council member's verdict — the delivery council (`/cloverleaf-run <TASK-ID>`) or a human applies the aggregated verdict (`apply-council-verdict`); this skill does not advance the FSM."
 
    **Bounce:**
    ```bash
    echo '<merged-envelope-json>' > /tmp/cloverleaf-fb-s.json
-   cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-s.json
+   cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-s.json --prefix=s
    git -C <repo_root> add .cloverleaf/feedback/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security review feedback"
    cloverleaf-cli set-task-field <repo_root> <TASK-ID> security_review_verdict bounce
    git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security_review_verdict → bounce"
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent
-   git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security review bounced → implementing"
    ```
-   Report: "✗ Security review bounced. Findings: <summarize by severity>. State → implementing."
+   Report: "✗ Security Reviewer verdict: **bounce**. Findings: <summarize by severity>. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-s<N>.json`. The delivery council or a human applies the verdict (a council bounce loops the task back to `implementing`); this skill does not advance the FSM."
 
    **Escalate (blocker found):**
    ```bash
    echo '<merged-envelope-json>' > /tmp/cloverleaf-fb-s.json
-   cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-s.json
+   cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-s.json --prefix=s
    git -C <repo_root> add .cloverleaf/feedback/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security review feedback"
    cloverleaf-cli set-task-field <repo_root> <TASK-ID> security_review_verdict escalate
    git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security_review_verdict → escalate"
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> escalated agent
-   git -C <repo_root> add .cloverleaf/ && git -C <repo_root> commit -m "cloverleaf: <TASK-ID> security review escalated (blocker finding)"
    ```
-   Report: "⚠ Security review found a BLOCKER. State → escalated. A human must review `.cloverleaf/feedback/` before this can proceed."
+   Report: "⚠ Security Reviewer verdict: **escalate** — a BLOCKER was found. Recorded `security_review_verdict=escalate` and emitted feedback to `.cloverleaf/feedback/<TASK-ID>-s<N>.json`. A human MUST review `.cloverleaf/feedback/` before this can proceed. The council or a human applies the verdict (a council escalate is un-lowerable → `escalated`); this skill does not advance the FSM."
 
 ## Rules
 
 - Never push. Read-only on source — the security reviewer does not modify code.
-- A `blocker` (e.g. a leaked credential) ALWAYS escalates to a human; never let the bounce loop silently "fix" it.
-- On illegal state transition, report and stop without partial commits.
+- A `blocker` (e.g. a leaked credential) ALWAYS yields an `escalate` verdict; never let a bounce loop silently "fix" it. The council/human enforces the terminal escalation.
+- Emit-only: never call `advance-status`. This is one council member's verdict; the council/human applies it.