@cloverleaf/reference-impl 0.12.0 → 0.13.1

package/skills/cloverleaf-discover/SKILL.md

@@ -68,6 +68,8 @@ Each sub-skill runs from `main`. Between steps, confirm branch is `main` before
    cloverleaf-cli advance-rfc <repo_root> $RFC_ID gate-pending agent rfc_strategy_gate
    ```
 
+   **Advisory council (opt-in).** Run `cloverleaf-cli council-plan <repo_root> $RFC_ID rfc.strategy_gate`. If `plan.source === "consumer"` and `plan.profile !== null`, dispatch `plan.rounds` (each member reviews the RFC per its custom-role prompt), reach a verdict, then `cloverleaf-cli apply-council-verdict <repo_root> $RFC_ID rfc.strategy_gate '<verdict>'`. This **posts** the advisory verdict + a feedback envelope and drives NO transition (the RFC stays at `gate-pending`). Surface the verdict + rationale to the human below. The human still decides approve/reject/revise — the council never auto-approves. A repo with no such binding sees `plan.profile === null` → the pre-step is skipped and today's behavior is unchanged.
+
    Prompt human (blocking readline):
    ```
    RFC $RFC_ID at rfc_strategy_gate: approve / reject / revise [reason]? > _
@@ -80,7 +82,11 @@ Each sub-skill runs from `main`. Between steps, confirm branch is `main` before
 
 7. **Plan breakdown** — invoke `/cloverleaf-breakdown $RFC_ID`. Per-invocation bounce budget (3 bounces inside breakdown). Capture `$PLAN_ID`. On bounce exhaustion: dump state and halt.
 
-8. **Gate: task_batch_gate** — Plan is already in `gate-pending` (set by breakdown). Prompt:
+8. **Gate: task_batch_gate** — Plan is already in `gate-pending` (set by breakdown).
+
+   **Advisory council (opt-in).** Run `cloverleaf-cli council-plan <repo_root> $PLAN_ID plan.task_batch`. If `plan.source === "consumer"` and `plan.profile !== null`, dispatch `plan.rounds` (each member reviews the Plan per its custom-role prompt), reach a verdict, then `cloverleaf-cli apply-council-verdict <repo_root> $PLAN_ID plan.task_batch '<verdict>'`. This **posts** the advisory verdict + a feedback envelope and drives NO transition (the Plan stays at `gate-pending`). Surface the verdict + rationale to the human below. The human still decides approve/reject — the council never auto-approves. A repo with no such binding sees `plan.profile === null` → the pre-step is skipped and today's behavior is unchanged.
+
+   Prompt:
    ```
    PLN $PLAN_ID at task_batch_gate: approve / reject [reason]? > _
    ```

package/skills/cloverleaf-document/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cloverleaf-document
-description: Run the Documenter agent on a task in the `implementing` state (full pipeline only). Dispatches a subagent to add doc-only commits to the feature branch, then advances implementing → documenting → review. Usage — /cloverleaf-document <TASK-ID>.
+description: Run the Documenter agent on a task in the `implementing` state (high-risk delivery only). Dispatches a subagent to add doc-only commits to the feature branch, then advances implementing → documenting (stops at documenting). Usage — /cloverleaf-document <TASK-ID>.
 ---
 
 # Cloverleaf — document
@@ -49,23 +49,22 @@ description: Run the Documenter agent on a task in the `implementing` state (ful
 
 7. On failure to parse or response with invalid shape: report the response and stop without advancing state.
 
-8. Advance state:
+8. Advance state (stop at `documenting` — the delivery council owns `documenting → council`):
    ```
    cloverleaf-cli advance-status <repo_root> <TASK-ID> documenting agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> review agent
    ```
 
 9. Commit state changes:
    ```bash
    cd <repo_root>
    git add .cloverleaf/
-   git commit -m "cloverleaf: <TASK-ID> documented → review"
+   git commit -m "cloverleaf: <TASK-ID> documented → documenting"
    ```
 
 10. Report:
-    - "✓ Documenter done. `<commits_added>` doc commit(s) added. State → review."
+    - "✓ Documenter done. `<commits_added>` doc commit(s) added. State → documenting."
     - "Files changed: `<comma-separated files_changed>`."
-    - "Next: `/cloverleaf-review <TASK-ID>`."
+    - "Next: the delivery council (`/cloverleaf-run <TASK-ID>` advances `documenting → council`)."
 
 ## Rules
 

package/skills/cloverleaf-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cloverleaf-implement
-description: Run the Implementer agent on a task. Dispatches a subagent to produce code + tests on a new branch, then advances state pending → tactical-plan → implementing → documenting → review. Usage — /cloverleaf-implement <TASK-ID>.
+description: Run the Implementer agent on a task. Dispatches a subagent to produce code + tests on a new branch, then advances state pending → tactical-plan → implementing (stops at implementing for every risk_class). Usage — /cloverleaf-implement <TASK-ID>.
 ---
 
 # Cloverleaf — implement
@@ -15,7 +15,7 @@ The user has invoked this skill with a TASK-ID (e.g., `DEMO-001`).
    ```
    cloverleaf-cli load-task <repo_root> <TASK-ID>
    ```
-   Parse the JSON. Verify `status === "pending"` OR `status === "implementing"` (the second case is a re-run after a Reviewer bounce). If neither, report the current status and ask the user to use the correct command for that state.
+   Parse the JSON. Verify `status === "pending"` OR `status === "implementing"` (the second case is a re-run after a delivery-council bounce). If neither, report the current status and ask the user to use the correct command for that state.
 
 3. Load any outstanding feedback:
    ```
@@ -58,50 +58,44 @@ The user has invoked this skill with a TASK-ID (e.g., `DEMO-001`).
 
    If this fails (uncommitted changes on main, detached HEAD, etc.), report the error and stop without advancing state.
 
-8. Walk the state machine. Read `task.risk_class` (already captured at step 2).
+8. Walk the state machine. The walk is the **same for every `risk_class`** — the collapsed
+   council FSM has a single delivery spine (`pending → tactical-plan → implementing → …`),
+   so the Implementer always ends at `implementing`. `risk_class` still selects the
+   downstream council profile (delivery-fast / delivery-full); it no longer branches the walk.
 
-   **If `risk_class === "low"` (fast lane — v0.1.1 behavior):**
+   The walk still issues **tactical-plan** and **implement** as two distinct `advance-status`
+   calls (below), but both run in this one dispatch with no pause between them — this skill
+   does **not** stop at `tactical-plan`. A decisive `task.plan_review` checkpoint between them
+   is **not currently wired**: see `/cloverleaf-run` §3a/§3b, which document the limitation and
+   do not attempt to bind one against the shipped default.
 
    If the current task status is `pending`:
    ```
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> tactical-plan agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> documenting agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> review agent
+   cloverleaf-cli advance-status <repo_root> <TASK-ID> tactical-plan agent   # produce the tactical plan
+   cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent    # implement; STOP here
    ```
+   Stop at `implementing`. The Documenter (high-risk) or the runner (low-risk) advances
+   `implementing → documenting` next; the delivery council then owns `documenting → council`.
 
-   If the current task status was `implementing` (loop-back after bounce):
-   ```
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> documenting agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> review agent
-   ```
-
-   **If `risk_class === "high"` (full pipeline — new in v0.2):**
-
-   If the current task status is `pending`:
-   ```
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> tactical-plan agent
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent
-   ```
-   Stop here. Documenter runs next (will advance implementing → documenting → review).
-
-   If the current task status was `implementing` (loop-back after Reviewer/UI/QA bounce):
-   No state advance — the bouncing skill already moved state back to `implementing`.
+   If the current task status was `implementing` (loop-back after a council bounce):
+   No state advance — re-implement in place. The council already moved state back to
+   `implementing`, and the batched feedback is in `.cloverleaf/feedback/`. The task stays
+   at `implementing` after this re-run.
 
 9. Commit the state changes:
    ```
    cd <repo_root>
    git add .cloverleaf/
-   git commit -m "cloverleaf: <TASK-ID> → <new-state>"
+   git commit -m "cloverleaf: <TASK-ID> → implementing"
    ```
-   where `<new-state>` is `review` for fast lane (`risk_class === "low"`) or `implementing` for full pipeline (`risk_class === "high"`).
+   (On a loop-back re-run there may be nothing staged — that is expected; skip the commit
+   if `git diff --cached --quiet`.)
 
 10. Report:
-    - "✓ Implementer done. Branch `<branch>`. State → <new-state>."
+    - "✓ Implementer done. Branch `<branch>`. State → implementing."
     - "Files changed: <comma-separated>."
     - "Currently on: `main`."
-    - **If `risk_class === "low"`:** "Next: `/cloverleaf-review <TASK-ID>`."
-    - **If `risk_class === "high"`:** "Next: `/cloverleaf-document <TASK-ID>`."
+    - "Next: `/cloverleaf-document <TASK-ID>` (high-risk docs) — for low-risk the runner advances `implementing → documenting`; the delivery council then runs."
 
 ## Rules
 

package/skills/cloverleaf-merge/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cloverleaf-merge
-description: Human gate for merging a Cloverleaf task. Branches on state — from `automated-gates` (fast lane) via `human_merge`, or from `final-gate` (full pipeline) via `final_approval_gate`. For full-pipeline tasks, performs a real `git merge --no-ff` of the feature branch into main before advancing state. Requires explicit user confirmation. Usage — /cloverleaf-merge <TASK-ID>.
+description: Human gate for merging a Cloverleaf task. Every task merges at `final-gate` via `final_approval_gate`. Performs a real `git merge --no-ff` of the feature branch into main before advancing state. Requires explicit user confirmation. Usage — /cloverleaf-merge <TASK-ID>.
 ---
 
 # Cloverleaf — merge
@@ -19,23 +19,14 @@ description: Human gate for merging a Cloverleaf task. Branches on state — fro
 
 2. Load the task: `cloverleaf-cli load-task <repo_root> <TASK-ID>`. Let `S` = `task.status`.
 
-   - If `S === "automated-gates"`: this is a fast-lane merge. Proceed with section 3A.
-   - If `S === "final-gate"`: this is a full-pipeline merge. Proceed with section 3B.
+   - If `S === "final-gate"`: proceed with section 3.
    - Else: report the current status and stop.
 
-### 3A. Fast-lane confirmation
+### 3. Final approval
 
-3A.1. Show to user:
-> "About to merge `<TASK-ID>` (fast lane). Branch `cloverleaf/<TASK-ID>` has been reviewed and passed. Confirm merge? (y/N)"
+The task is at `final-gate` (the council passed). Confirm with the human, then:
 
-3A.2. On explicit `y`:
-   - `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`
-   - Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> merged (fast lane)"`.
-
-### 3B. Full-pipeline final approval
-
-3B.1. Collect summaries. Read the latest feedback files:
+3.1. Collect summaries. Read the latest feedback files:
    ```bash
    ls <repo_root>/.cloverleaf/feedback/<TASK-ID>-*.json | sort
    ```
@@ -44,14 +35,14 @@ description: Human gate for merging a Cloverleaf task. Branches on state — fro
    - `u*.json` → UI Reviewer
    - `q*.json` → QA
 
-3B.2. Show to user:
-> "About to merge `<TASK-ID>` (full pipeline). Final approval required. Summaries:
+3.2. Show to user:
+> "About to merge `<TASK-ID>`. Final approval required. Summaries:
 > - Reviewer: <summary>
 > - UI Reviewer: <summary or 'not run'>
 > - QA: <summary with results>
 > Confirm merge? (y/N)"
 
-3B.3. On explicit `y`:
+3.3. On explicit `y`:
    - `cloverleaf-cli emit-gate-decision <repo_root> <TASK-ID> final_approval_gate approve human`
    - Verify we are on main with a clean working tree:
      ```bash
@@ -63,7 +54,7 @@ description: Human gate for merging a Cloverleaf task. Branches on state — fro
      If not clean, stop and report.
    - Perform the real merge — brings the feature branch's Implementer commit, ui-review baseline commit, and any feedback commits into main:
      ```bash
-     git merge --no-ff cloverleaf/${TASK_ID} -m "cloverleaf: ${TASK_ID} merged (full pipeline)"
+     git merge --no-ff cloverleaf/${TASK_ID} -m "cloverleaf: ${TASK_ID} merged"
      ```
      If git reports conflicts: abort and escalate.
      ```bash
@@ -71,12 +62,12 @@ description: Human gate for merging a Cloverleaf task. Branches on state — fro
      cloverleaf-cli advance-status <repo_root> ${TASK_ID} escalated agent
      ```
      Exit with a human-readable error explaining the conflict.
-   - Advance task status on main (commits `.cloverleaf/tasks/${TASK_ID}.json` + event). The `final-gate → merged` transition is `allowed_actors: [human]` per the task state machine; the skill passes the gate + path as positional args:
+   - Advance task status on main (commits `.cloverleaf/tasks/${TASK_ID}.json` + event). The `final-gate → merged` transition is `allowed_actors: [human]` per the task state machine:
      ```bash
-     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
      ```
 
-### 4. Common: report
+### 4. Report
 
 Report:
 - "✓ Merged `<TASK-ID>`. Branch `cloverleaf/<TASK-ID>` has been merged into main."
@@ -86,8 +77,8 @@ Report:
 
 - Only proceed on explicit `y/Y/yes/YES`. Anything else is treated as either a decline (`n/N/no/NO`) or a clarifying question (see below).
 - The skill does NOT push the branch or open a PR.
-- Fast lane and full pipeline use distinct gates — the state machine records which path was taken.
-- Full-pipeline merges perform a real `git merge --no-ff` before advancing state — the feature branch's code, baselines, and feedback commits all land on main.
+- Every task merges via `final_approval_gate` — there is a single human approval before merge (no separate fast-lane gate).
+- Merges perform a real `git merge --no-ff` before advancing state — the feature branch's code, baselines, and feedback commits all land on main.
 - If the user declines, no state change and no commit.
 
 ## Clarifying questions at final-gate

package/skills/cloverleaf-new-task/SKILL.md

@@ -32,23 +32,42 @@ The user has invoked this skill with a brief. Your job: turn the brief into a st
      "owner": { "kind": "agent", "id": "implementer" },
      "project": "<project>",
      "title": "<concise title derived from brief>",
-     "context": <see "context.rfc injection" below>,
+     "context": { "rfc": { "project": "<rfc-project-field>", "id": "<RFC-ID>" } },
      "acceptance_criteria": ["<criterion 1>", "<criterion 2>", "..."],
      "definition_of_done": ["<terminal statement of completion>"],
      "risk_class": "low",
-     "security_class": "<see security_class inference below>"
+     "security_class": <see security_class inference below>
+   }
+   ```
+
+   A complete, schema-valid example:
+
+   ```json
+   {
+     "id": "DEMO-002",
+     "type": "task",
+     "status": "pending",
+     "owner": { "kind": "agent", "id": "implementer" },
+     "project": "DEMO",
+     "title": "Add a retry budget to the fetch helper",
+     "context": { "rfc": { "project": "DEMO", "id": "DEMO-001" } },
+     "definition_of_done": ["`fetchWithRetry` retries up to 3 times on 5xx and gives up after that."],
+     "acceptance_criteria": ["`npm test` passes.", "A test asserts the 4th attempt is not made."],
+     "risk_class": "low",
+     "security_class": "low"
    }
    ```
 
    **`context.rfc` injection:**
 
    - If the brief includes `--rfc=<RFC-ID>` (e.g. `/cloverleaf-new-task --rfc=CLV-9 "Brief text..."`), read `<repo_root>/.cloverleaf/rfcs/<RFC-ID>.json` and inject the workItemRef shape:
+     <!-- cloverleaf-schema: task.schema.json#/properties/context -->
      ```json
      "context": { "rfc": { "project": "<rfc-project-field>", "id": "<RFC-ID>" } }
      ```
      The `project` field comes from the loaded RFC document, NOT the task's own project (a task in project FOO may legitimately reference an RFC in project BAR).
    - If `<repo_root>/.cloverleaf/rfcs/<RFC-ID>.json` does not exist, abort and ask the user to verify the RFC ID. Do not write the task file.
-   - If `--rfc=<ID>` is not passed, leave `context` as `{}` — same as pre-v0.7.4 behavior.
+   - `--rfc=<RFC-ID>` is **required**. `task.schema.json` requires `context.rfc`, so a task without it is schema-invalid and will be rejected at its first `advance-status`. If the brief does not name an RFC, stop and ask the user which RFC this task belongs to — do not write the file.
 
    Derive 2-5 acceptance criteria from the brief. Each must be verifiable. Derive one or more Definition of Done strings as an array.
 
@@ -76,7 +95,7 @@ The user has invoked this skill with a brief. Your job: turn the brief into a st
 ## Rules
 
 - Do not guess at acceptance criteria. If the brief is too vague (e.g., "make it faster" with no target), ask the user a clarifying question before writing the file.
-- **`--rfc=<ID>` flag:** When the brief includes `--rfc=<RFC-ID>`, the task's `context.rfc` is populated from the on-disk RFC document (see step 4). This is the canonical way to scaffold an **RFC-direct task** (no Plan parent, no `task_batch_gate`) — used for hotfixes after a Plan has delivered, or for incremental RFC progress without forming a Plan. The walker's RFC auto-advance treats RFC-direct tasks as first-class: an in-flight one blocks RFC completion; a merged one counts toward delivery. See `reference-impl/README.md` § "Plans vs RFC-direct tasks" for the full pattern docs and when to pick this over `/cloverleaf-discover`. If `--rfc` is omitted, `context` is left empty.
+- **`--rfc=<ID>` flag:** When the brief includes `--rfc=<RFC-ID>`, the task's `context.rfc` is populated from the on-disk RFC document (see step 4). This is the canonical way to scaffold an **RFC-direct task** (no Plan parent, no `task_batch_gate`) — used for hotfixes after a Plan has delivered, or for incremental RFC progress without forming a Plan. The walker's RFC auto-advance treats RFC-direct tasks as first-class: an in-flight one blocks RFC completion; a merged one counts toward delivery. See `reference-impl/README.md` § "Plans vs RFC-direct tasks" for the full pattern docs and when to pick this over `/cloverleaf-discover`. `--rfc` is required: every task descends from an RFC. A hotfix with no Plan parent is exactly the RFC-direct pattern described above — pass the RFC it belongs to.
 - **risk_class inference:** `risk_class` determines the Delivery pipeline (`"low"` → fast lane; `"high"` → full pipeline). Rules:
   1. If the user passed `--risk=high` or `--risk=low` as a flag on the skill invocation, honor it.
   2. Otherwise, set `risk_class: "high"` when the brief OR any acceptance criterion matches (case-insensitive) any of these keywords:

package/skills/cloverleaf-qa/SKILL.md

@@ -1,9 +1,17 @@
 ---
 name: cloverleaf-qa
-description: Run the QA agent on a task in the `qa` state (full pipeline only). Dispatches a subagent to run per-package test suites against an isolated worktree; emits feedback envelope with results; advances qa → final-gate on pass or loops back to implementing on bounce. Usage — /cloverleaf-qa <TASK-ID>.
+description: Run the QA council member on a task's feature branch as a standalone one-off. Dispatches a subagent to run per-package test suites against an isolated worktree. Emit-only — it writes a feedback envelope with the test results 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-qa <TASK-ID>.
 ---
 
-# Cloverleaf — qa
+# Cloverleaf — qa (emit-only council member)
+
+The delivery states `qa`/`final-gate` are no longer entered by a standalone QA gate — the `@cloverleaf/standard`
+task FSM collapsed the delivery gates into a single `council` phase (Council Slice 4). QA is now a **council member**
+that the runner (`/cloverleaf-run`) dispatches and aggregates alongside the other members. A single member cannot
+drive the multi-member council to `final-gate` (that would bypass the others' gating), so this standalone skill is
+**emit-only**: it runs the QA prompt against the task's branch, emits the feedback envelope with the test results,
+and reports the verdict. **It does not advance the FSM** — the council or a human applies the aggregated verdict via
+`apply-council-verdict` (a council pass is what advances `council → final-gate`).
 
 ## Steps
 
@@ -19,7 +27,7 @@ description: Run the QA agent on a task in the `qa` state (full pipeline only).
    ```
    cloverleaf-cli load-task <repo_root> <TASK-ID>
    ```
-   Verify `status === "qa"`. If not, report and stop.
+   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 and stop.
 
 3. Confirm feature branch exists: `git rev-parse --verify cloverleaf/<TASK-ID>`.
 
@@ -51,36 +59,29 @@ description: Run the QA agent on a task in the `qa` state (full pipeline only).
 
    **Dispatch conventions:** invoke the Task tool in foreground mode (its default — do NOT pass `run_in_background: true`). The Task tool returns the subagent's final message as a string in the result. Do NOT use Bash `sleep` to poll an output file — the harness blocks foreground `sleep`, and background dispatch is unnecessary here because the foreground Task tool already blocks until the subagent finishes.
 
-8. Parse response: expect `{"verdict": "pass"|"bounce"|"escalate", "summary", "findings", "results"}`.
-
-9. Branch on verdict:
+8. Parse response: expect `{"verdict": "pass"|"bounce"|"escalate", "summary", "findings"}`. There is no separate `results` field — the aggregate test counts are folded into the end of `summary` (e.g., "Test counts: passed 153, failed 0, total 153.").
 
-   **Pass:**
-   ```
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> final-gate agent --path=full_pipeline
-   ```
-   Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> qa passed → final-gate"`.
-   Report: "✓ QA passed (`<passed>/<total>` tests). State → final-gate. Next: `/cloverleaf-merge <TASK-ID>`."
+9. **Emit the envelope + report the verdict (no FSM advance).**
 
-   **Bounce:**
-   1. Write feedback envelope: `echo '<json>' > /tmp/cloverleaf-fb-q.json`
+   Persist the feedback envelope — verdict, summary (including the aggregate test counts), and findings — so the council/human can read it, regardless of verdict:
+   1. Write the feedback envelope: `echo '<json>' > /tmp/cloverleaf-fb-q.json`
    2. `cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-q.json --prefix=q`
-   3. Commit the persisted feedback file (was missing pre-v0.4.1 — bug #3):
+   3. Commit the persisted feedback file:
       ```bash
       cd <repo_root>
       git add .cloverleaf/feedback/
-      git commit -m "cloverleaf: <TASK-ID> qa feedback"
+      git commit -m "cloverleaf: <TASK-ID> qa verdict (emit-only)"
       ```
-   4. `cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent --path=full_pipeline`
-   5. Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> qa bounced → implementing"`.
-   6. Report: "✗ QA bounced. `<failed>/<total>` tests failed. State → implementing. Next: `/cloverleaf-implement <TASK-ID>`."
 
-   **Escalate:**
-   1. `cloverleaf-cli advance-status <repo_root> <TASK-ID> escalated agent`
-   2. Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> qa escalated"`.
-   3. Report: "✗ QA escalated. Review infrastructure and retry manually."
+   Then report the verdict — do **NOT** run `advance-status`:
+
+   **Pass:** "✓ QA verdict: **pass** — `<summary>`. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-q<N>.json`. This is one council member's verdict — the delivery council (`/cloverleaf-run <TASK-ID>`) or a human applies the aggregated verdict (`apply-council-verdict`, a council pass advances `council → final-gate`); this skill does not advance the FSM."
+
+   **Bounce:** "✗ QA verdict: **bounce** — `<summary>`. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-q<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:** "✗ QA verdict: **escalate** (infrastructure issue) — `<summary>`. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-q<N>.json`. The council or a human applies the verdict (a council escalate → `escalated`); this skill does not advance the FSM. Review infrastructure and retry manually."
 
 ## Rules
 
 - Never push. Read-only. Do not modify source.
-- On illegal state transition, report and stop.
+- Emit-only: never call `advance-status`. This is one council member's verdict; the council/human applies it.

package/skills/cloverleaf-review/SKILL.md

@@ -1,9 +1,17 @@
 ---
 name: cloverleaf-review
-description: Run the Reviewer agent on a task in the `review` state. Emits a feedback envelope; advances to `automated-gates` on pass or loops back to `implementing` on bounce. Usage — /cloverleaf-review <TASK-ID>.
+description: Run the Reviewer council member on a task's feature branch as a standalone one-off. Emit-only — it dispatches the reviewer prompt against `main..cloverleaf/<TASK-ID>`, writes a feedback envelope, and reports the verdict (pass/bounce) for the delivery council or a human to apply. It does NOT advance the task FSM. Usage — /cloverleaf-review <TASK-ID>.
 ---
 
-# Cloverleaf — review
+# Cloverleaf — review (emit-only council member)
+
+The delivery states `review`/`automated-gates` no longer exist — the `@cloverleaf/standard` task FSM
+collapsed them into a single `council` phase (Council Slice 4). The Reviewer is now a **council member**
+that the runner (`/cloverleaf-run`) dispatches and aggregates alongside the other members. A single member
+cannot drive the multi-member council to merge (that would bypass the others' gating), so this standalone
+skill is **emit-only**: it runs the reviewer prompt against the task's branch, 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`.
 
 ## Steps
 
@@ -27,7 +35,9 @@ description: Run the Reviewer agent on a task in the `review` state. Emits a fee
    ```
    cloverleaf-cli load-task <repo_root> <TASK-ID>
    ```
-   Verify `status === "review"`. If not, report the current status and stop.
+   Light guard only: confirm the task exists and is not in a terminal status (`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. The Implementer's branch is `cloverleaf/<TASK-ID>`. Confirm it exists: `git rev-parse --verify cloverleaf/<TASK-ID>`. If missing, report the discrepancy and stop. Do NOT check out this branch; stay on main.
 
@@ -56,30 +66,26 @@ description: Run the Reviewer agent on a task in the `review` state. Emits a fee
 
 6. Parse the subagent's response. Expect a feedback envelope JSON of the form `{"verdict": "pass"|"bounce", "summary": "...", "findings": [...]}`. Validate shape: verdict must be `pass` or `bounce`; if `bounce`, findings must have at least one entry with `severity` (one of `blocker|error|warning|info`) and `message`.
 
-7. Branch on verdict:
-
-   **Pass:**
-   ```
-   cloverleaf-cli advance-status <repo_root> <TASK-ID> automated-gates agent
-   ```
-   Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> review passed → automated-gates"`.
-   Report: "✓ Review passed. State → automated-gates. Next: `/cloverleaf-merge <TASK-ID>`."
+7. **Emit the envelope + report the verdict (no FSM advance).**
 
-   **Bounce:**
+   Persist the feedback envelope so the council/human can read it, regardless of verdict:
    1. Write the feedback envelope to a temp file: `echo '<envelope-json>' > /tmp/cloverleaf-fb-r.json`.
    2. `cloverleaf-cli write-feedback <repo_root> <TASK-ID> /tmp/cloverleaf-fb-r.json` — captures the path like `.cloverleaf/feedback/<TASK-ID>-r<N>.json`.
-   3. Commit the persisted feedback file (was missing pre-v0.4.1 — bug #3):
+   3. Commit the persisted feedback file:
       ```bash
       cd <repo_root>
       git add .cloverleaf/feedback/
-      git commit -m "cloverleaf: <TASK-ID> review feedback"
+      git commit -m "cloverleaf: <TASK-ID> reviewer verdict (emit-only)"
       ```
-   4. `cloverleaf-cli advance-status <repo_root> <TASK-ID> implementing agent` — loops back.
-   5. Commit: `git add .cloverleaf/ && git commit -m "cloverleaf: <TASK-ID> review bounced → implementing"`.
-   6. Report: "✗ Review bounced. Findings: <summarize findings by severity>. State → implementing. Next: `/cloverleaf-implement <TASK-ID>`."
+
+   Then report the verdict — do **NOT** run `advance-status`:
+
+   **Pass:** "✓ Reviewer verdict: **pass**. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-r<N>.json`. 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:** "✗ Reviewer verdict: **bounce**. Findings: <summarize findings by severity>. Feedback emitted to `.cloverleaf/feedback/<TASK-ID>-r<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."
 
 ## Rules
 
 - Never push.
 - Do not modify source code — the reviewer is read-only.
-- On illegal state transition, report and stop without partial commits.
+- Emit-only: never call `advance-status`. This is one council member's verdict; the council/human applies it.