@chorus-aidlc/chorus-openclaw-plugin 0.11.0 → 0.11.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chorus-aidlc/chorus-openclaw-plugin",
-  "version": "0.11.0",
+  "version": "0.11.1",
   "description": "OpenClaw plugin for Chorus AI-DLC collaboration platform — native MCP + SSE real-time events",
   "license": "MIT",
   "type": "module",

package/skills/brainstorm/SKILL.md

@@ -4,7 +4,7 @@ description: Optional divergent-then-convergent dialogue for fuzzy ideas. Invoke
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus AI Agent collaboration platform — overview, common tools,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---
@@ -306,11 +306,11 @@ The table below shows default tool availability for each preset (no custom permi
 
 ### 5. Review Skills
 
-The plugin bundles two independent **review skills**: `/proposal-reviewer` and `/task-reviewer`. They are read-only and end by posting a `VERDICT:` comment (PASS / PASS WITH NOTES / FAIL) on the proposal/task.
+The plugin bundles three independent **review skills**: `/proposal-reviewer`, `/task-reviewer`, and `/code-reviewer`. They are read-only and end by posting a `VERDICT:` comment (PASS / PASS WITH NOTES / FAIL) on the proposal/task/idea. `/code-reviewer` is the **final ship-time gateway**: after an Idea's last task is verified it reviews the Idea's **aggregate code change** (the whole feature across all its tasks) and posts its VERDICT on the **idea**.
 
-**How review runs on OpenClaw.** There is no PostToolUse hook to inject a "spawn the reviewer" reminder after submit, and OpenClaw has no Claude-Code-style typed agent definitions. Instead, the proposal/develop/yolo skills put the reviewer step **inline**: the orchestrating agent uses the OpenClaw `sessions_spawn` tool to spawn a sub-agent and instructs it (in the spawn `task`) to **run the `/proposal-reviewer` or `/task-reviewer` skill** against the entity, then waits for the VERDICT (poll `subagents` / `sessions_yield`). Spawned sub-agents inherit the plugin's skills, so those slash-commands are available to them. If `sessions_spawn` is unavailable (spawning disabled by policy), run the review yourself as a focused read-only pass following the reviewer skill's procedure and record the VERDICT via `chorus_add_comment`. See the relevant stage skill for the exact procedure.
+**How review runs on OpenClaw.** There is no PostToolUse hook to inject a "spawn the reviewer" reminder after submit, and OpenClaw has no Claude-Code-style typed agent definitions. Instead, the proposal/develop/yolo skills put the reviewer step **inline**: the orchestrating agent uses the OpenClaw `sessions_spawn` tool to spawn a sub-agent and instructs it (in the spawn `task`) to **run the `/proposal-reviewer`, `/task-reviewer`, or `/code-reviewer` skill** against the entity (passing the `ideaUuid` for code review), then waits for the VERDICT (poll `subagents` / `sessions_yield`). Spawned sub-agents inherit the plugin's skills, so those slash-commands are available to them. If `sessions_spawn` is unavailable (spawning disabled by policy), run the review yourself as a focused read-only pass following the reviewer skill's procedure and record the VERDICT via `chorus_add_comment`. See the relevant stage skill for the exact procedure.
 
-Results are advisory — they do not hard-block approval or verification, but you should act on a FAIL by fixing the listed BLOCKERs before proceeding.
+Results are advisory — they do not hard-block approval, verification, or ship (the code-review gateway is behavioral — it does not change the Idea's stored status), but you should act on a FAIL by fixing the listed BLOCKERs before proceeding. For a code-review FAIL, fix it via the **quick-dev** workflow (`/quick-dev`): `chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it (do not reopen old tasks), then execute → verify and re-run.
 
 ---
 

package/skills/code-reviewer/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: code-reviewer
+description: Final ship-time review of an Idea's aggregate code change — the whole feature across all its tasks, not one task. Read the integrated code, check cross-task integration / architecture / security / regression / coverage, run tests. Invoke after the last task of an idea-rooted proposal is verified; ends with a VERDICT comment on the Idea.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.11.1"
+  category: project-management
+  mcp_server: chorus
+---
+
+# Code Reviewer Skill
+
+You have been asked to perform the **final ship-time code review of a whole Chorus Idea**. Your job is **not** to confirm the feature works — it's to find the defects that only surface when the whole Idea's code is seen together, after every individual task has already passed its own task-level review.
+
+> **How you were invoked.** A developer/orchestrator agent spawned you (via the OpenClaw `sessions_spawn` tool) and told you to run this skill against a specific `ideaUuid`. Read it from your task prompt. When you finish, you post one `VERDICT:` comment back to the Idea — that comment IS your deliverable; the parent reads it.
+
+> **Tool namespace.** Chorus tools come from the connected MCP server under a `chorus__` prefix (e.g. `chorus__chorus_get_idea`, `chorus__chorus_add_comment`). Bare names are used below for readability — prepend `chorus__` when invoking.
+
+> **Your distinct role.** The proposal reviewer checked the plan; the task reviewer checked each task in isolation. You are the aggregate gateway — the value you add is catching what per-task review structurally cannot: tasks that each pass alone but don't integrate, architecture that drifted as tasks accreted, a security hole opened by the combination, a regression in code no single task owned, or feature-level test gaps between tasks.
+
+## Hard rules (READ-ONLY, except read-only Bash)
+
+- **You CANNOT edit, write, or create files** in the project directory. Do NOT modify any entity except posting your one review comment.
+- **Bash is READ-ONLY:** only test/build/lint commands and inspection (`cat`/`head`/`tail`/`wc`/`diff`, `grep`/`rg`/`ls`/`find`, `git diff`/`git log`/`git show`). **Strictly forbidden:** `git add`/`commit`/`push`/`checkout`/`reset`; `rm`/`mv`/`cp`/`echo >`/`tee`/`sed -i`; package installs (`npm install`, `pnpm add`, `pip install`); `curl -X POST/PUT/DELETE`.
+- **Keep your comment under 1000 characters.** PASS items: names only. NOTE items: one-line. BLOCKER items: command + output + evidence.
+- **Classify every finding** as BLOCKER (blocks ship: build/test failure, broken cross-task integration, security hole, regression, feature-level coverage gap) or NOTE (non-blocking: style, minor inconsistency, hallucination-risk specifics).
+- **Post your comment on the IDEA** (`targetType: "idea"`) and **end with a single line beginning `VERDICT:`** — exactly one of `PASS`, `PASS WITH NOTES`, `FAIL`. Has BLOCKERs → FAIL. Only NOTEs → PASS WITH NOTES. Nothing → PASS.
+- **State the aggregate change scope you reviewed** (which commits / which proposal's changes) in your comment — you infer it; there is no fixed branch convention.
+- **Round 2+:** focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs.
+- **Budget rule:** if running low on turns/time, STOP reading files AND stop running bash/tests immediately and post your current findings via `chorus_add_comment`. Incomplete findings posted beat no comment.
+- **Do NOT confirm — find what's wrong at the feature level.** Batch data gathering, then one final comment.
+
+You have two failure patterns. **Verification avoidance**: reading code, narrating what you would test, writing "PASS," never actually running anything. **Being seduced by green per-task reviews**: assuming that because every task passed, the feature is sound. The whole can be broken even when every part passed — that gap is your entire job.
+
+## What you receive
+
+An `ideaUuid` (in your task prompt). Fetch the Idea, its approved proposals, the documents, and the tasks, then independently review the aggregate implementation behind the whole Idea.
+
+## Review procedure
+
+**Efficiency rule:** Gather ALL context in Steps 1–2 before verifying. Batch tool calls — do not alternate between fetching and concluding.
+
+**Step 1: Gather context**
+```
+chorus_get_idea({ ideaUuid: "<uuid>" })
+chorus_get_comments({ targetType: "idea", targetUuid: "<uuid>" })          # prior code-review verdicts → your round number
+chorus_get_proposals({ projectUuid: "<idea.projectUuid>", status: "approved" })
+chorus_get_proposal({ proposalUuid: "<approved>", section: "full" })
+chorus_list_tasks({ projectUuid: "<...>", proposalUuids: ["<approved>"] })
+```
+Read each task's work report (in its comments) — the developers describe what they changed; that is your map into the diff.
+
+**Step 2: Determine the aggregate diff scope yourself.** No fixed branch convention. Infer scope from task work reports + repo state (`git log --oneline -n 50`, `git diff <base>...HEAD --stat`, `git show <commit>`). State the scope you settled on in your comment; if you cannot pin an exact range, say so and review what the reports + current tree support.
+
+**Step 3: Review the whole-feature dimensions** (what per-task review cannot catch — cover each):
+
+1. **Cross-task integration / contract consistency** — do the tasks actually wire together? Interface contracts, return formats, error patterns, call points across module boundaries different tasks built.
+2. **Architecture & convention consistency (no drift)** — does the aggregate conform to project patterns, or did tasks each invent their own approach? Duplicated logic, divergent naming, inconsistent layering.
+3. **Security** — does the combination introduce a security risk (authz gaps at a seam, injection, secret handling, unsafe deserialization, missing tenant scoping) — especially risks visible only when the pieces are seen together.
+4. **Regression risk / impact on untouched areas / performance** — does the change break or degrade code no single task owned? N+1s, hot-path cost, shared-state contention.
+5. **Feature-level test coverage adequacy** — across the whole feature, are integration seams and end-to-end paths tested, or only per-task units? Gaps between tasks.
+6. **Code soundness, simplicity, correctness** — is the aggregate change correct, reasonably simple, free of obvious defects read as one body of work.
+
+**Step 4: Run feature-level build/test.** Run the project's declared commands. A broken build or failing tests is an automatic FAIL. Record command + exit code + relevant output. Results are context — verify each dimension independently.
+
+**Hallucination check:** Flag anything that looks LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.
+
+## Finding classification
+
+**BLOCKER** — blocks ship: build/test failures across the feature; broken cross-task integration / contract mismatch causing wrong behavior; security hole introduced by the change; regression in untouched areas; a feature-level requirement (from the idea/docs) not actually covered by the aggregate; edge cases causing runtime errors at integration seams.
+
+**NOTE** — does not block: style / naming / minor duplication; cross-document wording differences; pseudocode signature mismatch; hallucination-risk specifics (SDK versions, API paths, CLI flags, model IDs).
+
+Rules: Style and cross-doc wording → always NOTE. Only functional/security/integration/regression issues → BLOCKER. VERDICT: has BLOCKERs → FAIL; only NOTEs → PASS WITH NOTES; nothing → PASS.
+
+## Round awareness
+
+Read your prior verdict comments on the Idea to establish the round.
+
+- **Round 1**: full aggregate review, normal strictness.
+- **Round 2+**: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on unflagged areas. If all previous BLOCKERs resolved → VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Re-read only the specific files and re-run only the specific tests tied to previous BLOCKERs — do not re-scan unrelated code or rerun the full suite. Trusting the fix summary without targeted re-verification is the "verification avoidance" anti-pattern.
+
+## Recognize your own rationalizations
+
+- "Every task passed its review, so the feature is fine" — the whole can break when every part passed. That gap is your entire job.
+- "The code looks correct based on my reading" — reading is not verification. Run it.
+- "Integration probably works" — probably is not verified. Find the seam and exercise it.
+- "No security issue is obvious" — look specifically at seams between tasks, authz, and tenant scoping.
+
+## Output format (required)
+
+```
+### Code Review — Idea <short title> (Round N)
+
+**Scope reviewed:** <commits / proposal changes you inferred>
+
+**PASS (N):** integration, architecture, security, regression, coverage, ...
+
+**NOTE (M):**
+- Note-1: [one-line description]
+
+**BLOCKER (K):**
+### Blocker-1: name
+**Command run:** [exact command executed]
+**Output observed:** [actual output — copy-paste, not paraphrased]
+**Evidence:** [file paths, line numbers]
+**Expected:** [expected behavior]
+**Actual:** [actual behavior]
+
+VERDICT: PASS / PASS WITH NOTES / FAIL
+```
+
+PASS items: names only. NOTE items: one-line. BLOCKER items: full command/output/evidence. Total under 1000 chars. No preamble. The final line MUST start with `VERDICT:`.
+
+## Post results
+
+Post the full review as a single comment on the **Idea**, then you are done:
+```
+chorus_add_comment({
+  targetType: "idea",
+  targetUuid: "<idea-uuid>",
+  content: "<your review>"
+})
+```
+
+On a FAIL verdict, the orchestrator creates new fix tasks on the existing approved proposal (it does NOT reopen old tasks); once those are done, you are re-run for the next round, bounded by the configured max review rounds.

package/skills/develop/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, manage se
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---
@@ -257,6 +257,8 @@ Obtain an independent VERDICT before the task is verified:
 
 If you spawned a sub-agent and no new `VERDICT:` comment appears after it returns, it exhausted its turn budget. Respawn it ONCE with a concise-budget hint: *"Stay within turn budget. Skip deep verification. Fetch task/proposal/comments, run only the core tests, and post your VERDICT within the first 12 turns."* If the second attempt still produces no VERDICT, fall back to reviewing manually (Step 8.5 fallback) and post the VERDICT yourself.
 
+> **Final code-review gateway (after the Idea's LAST task is verified):** when the task you just verified is the **last** task of its idea-rooted proposal, the feature is about to ship — run the ship-time code-review gateway before declaring the Idea done. Inline (no hook on OpenClaw), same mechanism as Step 8.5: spawn a sub-agent via `sessions_spawn` whose `task` tells it to **invoke the `/code-reviewer` skill** against the idea (pass the `ideaUuid` + round number), and wait for it; fallback is a read-only self-review following the `/code-reviewer` procedure. It reviews the Idea's **aggregate** code change (cross-task integration, architecture, security, regression, feature-level coverage) and posts one `VERDICT:` comment on the **idea**. `PASS` / `PASS WITH NOTES` → ship; `FAIL` → fix via the **quick-dev** workflow (`/quick-dev`): `chorus_create_tasks` with `proposalUuid` set to the **current approved proposal** so the fix tasks attach to it (do not reopen old tasks), then execute → verify and re-run the gateway. Advisory/behavioral. Run it **before** any idea-completion report.
+
 ### Step 9: Handle Review Feedback
 
 If the reviewer returns **FAIL**, or the task is reopened after verification:

package/skills/idea/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Idea workflow — claim ideas, run elaboration rounds, and p
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/openspec-aware/SKILL.md

@@ -4,7 +4,7 @@ description: Opt-in OpenSpec-mode authoring for Chorus PM workflows on OpenClaw.
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/proposal-reviewer/SKILL.md

@@ -4,7 +4,7 @@ description: Adversarial read-only review of a submitted Chorus proposal — doc
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/quick-dev/SKILL.md

@@ -4,7 +4,7 @@ description: Quick Task workflow — skip Idea→Proposal, create tasks directly
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/review/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---
@@ -64,16 +64,16 @@ Key responsibilities:
 
 ## Review Strategy
 
-When reviewing proposals or tasks, get an independent VERDICT before approving/verifying. On OpenClaw there is **no PostToolUse hook** to remind you — invoke the review yourself, inline.
+When reviewing proposals, tasks, or an Idea's final aggregate code change, get an independent VERDICT before approving/verifying/shipping. On OpenClaw there is **no PostToolUse hook** to remind you — invoke the review yourself, inline.
 
-1. **Preferred — spawn a reviewer sub-agent.** Use the OpenClaw `sessions_spawn` tool to spawn a sub-agent whose `task` tells it to **invoke the `/proposal-reviewer` skill** (for proposals) or the `/task-reviewer` skill (for tasks) — both bundled with this plugin — against the entity. Wait for it (poll the `subagents` tool or use `sessions_yield` — do NOT detach; you must have the VERDICT before proceeding). The sub-agent inherits the plugin skills, so the reviewer skill is available to it; it posts a VERDICT comment with detailed findings. Example task prompt: `Run the /proposal-reviewer skill to review proposalUuid <uuid>; post your VERDICT comment when done.`
+1. **Preferred — spawn a reviewer sub-agent.** Use the OpenClaw `sessions_spawn` tool to spawn a sub-agent whose `task` tells it to **invoke the `/proposal-reviewer` skill** (for proposals), the `/task-reviewer` skill (for tasks), or the `/code-reviewer` skill (the final ship-time gateway over an Idea's aggregate code change, after its last task is verified — pass the `ideaUuid`; it posts its VERDICT on the **idea**) — all bundled with this plugin — against the entity. Wait for it (poll the `subagents` tool or use `sessions_yield` — do NOT detach; you must have the VERDICT before proceeding). The sub-agent inherits the plugin skills, so the reviewer skill is available to it; it posts a VERDICT comment with detailed findings. Example task prompt: `Run the /proposal-reviewer skill to review proposalUuid <uuid>; post your VERDICT comment when done.`
 2. **Read the VERDICT.** After the reviewer completes, call `chorus_get_comments` and find the most recent comment containing `VERDICT:`. There are exactly three possible outcomes:
    - **VERDICT: PASS** — No issues found. Approve (proposals) or mark AC passed and verify (tasks).
    - **VERDICT: PASS WITH NOTES** — Minor non-blocking notes. Still approve/verify. Notes are informational.
-   - **VERDICT: FAIL** — BLOCKERs found. Reject (proposals) or reopen (tasks). Fix the specific BLOCKERs listed in the comment before resubmitting.
+   - **VERDICT: FAIL** — BLOCKERs found. Reject (proposals) or reopen (tasks). For a **code-review gateway** FAIL, do not reopen the verified tasks — instead fix via the **quick-dev** workflow (`/quick-dev`): `chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it, then execute → verify and re-run the gateway. Fix the specific BLOCKERs listed in the comment before resubmitting.
 3. **No new VERDICT comment?** The sub-agent exhausted its turn budget before posting. Respawn it ONCE with an explicit prompt like: *"Stay within your turn budget. Skip deep source verification — batch all MCP fetches up front, skim for obvious BLOCKERs only, and reserve your last few turns to post the VERDICT comment."* If the second attempt also fails to post, review manually (step 5).
 4. **Track rounds.** Count existing VERDICT comments before spawning. After 3 rounds of FAIL on the same item, stop the loop and escalate to human review.
-5. **Fallback — review it yourself (no `sessions_spawn` on the host).** If spawning is unavailable (disabled by policy, or the spawn fails), perform the review yourself as a **focused, read-only pass** using the quality checklists in the workflows below: read the entity, its comments, and the relevant documents/code, run read-only test/build commands where applicable, and do NOT modify anything. Then record your VERDICT via `chorus_add_comment` ending with a `VERDICT:` line (PASS / PASS WITH NOTES / FAIL), classifying every finding as BLOCKER or NOTE. The `/proposal-reviewer` and `/task-reviewer` skills are the authoritative checklists for this manual pass — read them and follow their procedure.
+5. **Fallback — review it yourself (no `sessions_spawn` on the host).** If spawning is unavailable (disabled by policy, or the spawn fails), perform the review yourself as a **focused, read-only pass** using the quality checklists in the workflows below: read the entity, its comments, and the relevant documents/code, run read-only test/build commands where applicable, and do NOT modify anything. Then record your VERDICT via `chorus_add_comment` ending with a `VERDICT:` line (PASS / PASS WITH NOTES / FAIL), classifying every finding as BLOCKER or NOTE. The `/proposal-reviewer`, `/task-reviewer`, and `/code-reviewer` skills are the authoritative checklists for this manual pass — read the relevant one and follow its procedure.
 
 ---
 

package/skills/task-reviewer/SKILL.md

@@ -4,7 +4,7 @@ description: Adversarial verification of a submitted Chorus task against its AC
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/skills/yolo/SKILL.md

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — from prompt to done. Automates the en
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---
@@ -433,6 +433,29 @@ Continue with remaining tasks -- do not halt the entire pipeline for one stuck t
 
 ---
 
+### Phase 4.5: Code-Review Gateway (mandatory pre-ship)
+
+Once **every** task of the idea's proposal is verified (`done`) — Phase 3 finds no more unblocked tasks and none remain non-terminal — run the final ship-time code-review gateway **before** the Phase 5b completion report. It reviews the **whole Idea's aggregate code change** across all tasks (not a single task) and posts its verdict on the **idea**. Inline (no hook on OpenClaw), same mechanism as Phase 4:
+
+- **Preferred — spawn a reviewer sub-agent.** Use `sessions_spawn` to spawn a sub-agent whose `task` tells it to **invoke the `/code-reviewer` skill** against the idea, then wait for it (poll `subagents` / `sessions_yield` — do NOT detach). Example task prompt: `Run the /code-reviewer skill to review the aggregate code for ideaUuid <uuid> (round <N>); post your VERDICT comment on the idea when done.`
+- **Fallback — review it yourself.** If `sessions_spawn` is unavailable, perform the review as a focused read-only pass following the `/code-reviewer` procedure (read the idea, its approved proposals + documents + tasks; infer the aggregate diff from task reports + `git log/diff`; review cross-task integration, architecture, security, regression, feature-level coverage; run the project build/test) and post the `VERDICT:` comment on the idea yourself.
+
+Act on the VERDICT:
+
+- **PASS** / **PASS WITH NOTES** — the feature is cleared to ship. Proceed to Phase 5 / 5b.
+- **FAIL** — do NOT ship. Read the BLOCKERs, then fix them via the **quick-dev** workflow (`/quick-dev`): call `chorus_create_tasks` with `proposalUuid` set to the **current approved proposal** so the fix tasks attach to it — do **not** reopen the already-verified tasks. Drive them through Phase 3 → Phase 4, then re-run the gateway for the next round. Loop bounded by `maxCodeReviewRounds` (default 3; 0 = unlimited).
+
+```
+ESCALATE: "Idea '{title}' failed code review after {maxCodeReviewRounds} rounds.
+           Last BLOCKERs: <list>. Manual intervention needed. Idea UUID: <uuid>"
+```
+
+**No VERDICT comment after the code-reviewer returns?** It exhausted its turn budget (larger than the task-reviewer's because it reviews the whole feature). Respawn ONCE with a concise-budget hint; if still silent, fall back to a manual read-only pass and post the VERDICT yourself.
+
+> The gateway is **behavioral** like the other two reviewers: its verdict is advisory and does not change the Idea's stored status; the orchestrator honors it. It runs **before** the completion report so the report is never written while a FAIL is outstanding.
+
+---
+
 ### Phase 5: Report
 
 After all waves complete, output a markdown summary:
@@ -464,6 +487,8 @@ After all waves complete, output a markdown summary:
 
 A successful `/yolo` run always finishes the Idea — call `chorus_create_report` once with `proposalUuid` set to the last verified proposal. The tool's description carries the section template; follow it. Surface the returned `documentUuid` in the Phase 5 summary. Skipping is a protocol violation.
 
+> **Order:** write the completion report only **after** the Phase 4.5 code-review gateway returns PASS / PASS WITH NOTES — never while a code-review FAIL is outstanding.
+
 > **OpenSpec archive:** if you ran in OpenSpec mode (Step 1.4 branch 2a), the last verified task also triggers the archive flow. OpenClaw has no PostToolUse hook to remind you — after verifying the final task, run `openspec-aware` §3.9 yourself (`openspec archive <slug> --yes`, then mirror each emitted `openspec/specs/<capability>/spec.md` back via §3.8).
 
 ---