@chorus-aidlc/chorus 0.11.0 → 0.12.0

package/.next/standalone/public/chorus-plugin/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/.next/standalone/public/chorus-plugin/skills/openspec-aware/SKILL.md

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

package/.next/standalone/public/chorus-plugin/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
 ---
@@ -283,10 +283,14 @@ Dependencies are validated: same project, no self-dependency, no cycles (DFS det
 
 ```
 chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uuid>" })
+
+# Optional: pin the task to a specific (agent, host, cwd) AgentInstance
+chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uuid>", instanceUuid: "<agent-instance-uuid>" })
 ```
 
 - Task must be `open` or `assigned`
 - Target agent must have `task: ["write"]` permission
+- Pass `instanceUuid` to pin the task to a specific online instance (assigns as `agent_instance`); omit it for a plain `agent` assignment that inherits the root idea's pinned instance at wake time
 
 ---
 

package/.next/standalone/public/chorus-plugin/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/.next/standalone/public/chorus-plugin/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
 ---
@@ -62,9 +62,9 @@ Key responsibilities:
 
 ## Review Strategy
 
-When reviewing proposals or tasks, prefer spawning an independent reviewer sub-agent over reviewing manually:
+When reviewing proposals, tasks, or an Idea's final aggregate code change, prefer spawning an independent reviewer sub-agent over reviewing manually:
 
-1. **Try the reviewer first.** Spawn `chorus:proposal-reviewer` (for proposals) or `chorus:task-reviewer` (for tasks) as a read-only sub-agent. **Run it in foreground** (do NOT set `run_in_background`) — you must wait for the VERDICT before proceeding. It posts a VERDICT comment with detailed findings.
+1. **Try the reviewer first.** Spawn `chorus:proposal-reviewer` (for proposals), `chorus:task-reviewer` (for tasks), or `chorus:code-reviewer` (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**) as a read-only sub-agent. **Run it in foreground** (do NOT set `run_in_background`) — you must wait for the VERDICT before proceeding. It posts a VERDICT comment with detailed findings.
 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.
@@ -215,6 +215,15 @@ Spawn `chorus:task-reviewer` per the [Review Strategy](#review-strategy) above
 - **VERDICT: PASS** or **PASS WITH NOTES** → proceed to B3 (mark AC) and B4 (verify).
 - **VERDICT: FAIL** → skip to B4 and **reopen** the task. Do NOT mark AC as passed.
 
+#### B2.6: Final Code-Review Gateway (after an Idea's LAST task is verified)
+
+When the task you just verified is the **last** task of its idea-rooted proposal, run the ship-time code-review gateway before the Idea's code is considered shipped. The PostToolUse hook injects a reminder to spawn `chorus:code-reviewer` (gated by `enableCodeReviewer`, default on). Spawn it per the [Review Strategy](#review-strategy) — foreground, passing the `ideaUuid` + round number. It reviews the Idea's **aggregate** code change across all its tasks — cross-task integration, architecture/convention consistency, security, regression/performance, feature-level test coverage — dimensions a single-task review cannot see — and posts one `VERDICT` comment on the **idea**.
+
+- **VERDICT: PASS** / **PASS WITH NOTES** → the feature may ship.
+- **VERDICT: FAIL** → do not reopen the verified tasks; instead add new fix tasks to the approved proposal via `/chorus:quick-dev` (`chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it), execute → verify them, then re-run the gateway. Bounded by `maxCodeReviewRounds`.
+
+> **Advisory / behavioral** — the gateway does not change the Idea's stored status; the admin honors its verdict. Run it **before** writing any idea-completion report (the report must not be written while a `FAIL` is outstanding).
+
 #### B3: Mark Acceptance Criteria
 
 Review and mark each criterion:

package/.next/standalone/public/chorus-plugin/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
 ---
@@ -23,6 +23,7 @@ Full-auto AI-DLC pipeline. User provides a prompt; agent drives the entire lifec
 2. **Proposal Review** -- proposal-reviewer adversarial loop
 3. **Execution** -- wave-based Agent Team parallel task dispatch
 4. **Verification** -- task-reviewer adversarial loop + admin verify
+4.5. **Code-Review Gateway** -- code-reviewer reviews the Idea's aggregate change before ship (FAIL → add fix tasks → re-run)
 5. **Report** -- completion summary
 
 ```
@@ -44,6 +45,9 @@ Full-auto AI-DLC pipeline. User provides a prompt; agent drives the entire lifec
   Admin Verify each wave --> unblock next
        |
        v
+  Code-Review Gateway (auto, up to maxCodeReviewRounds)
+       |  PASS --> ship   |   FAIL --> add fix tasks --> re-run
+       v
   Done. Report summary.
 ```
 
@@ -443,6 +447,38 @@ 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`) — i.e. Phase 3 finds no more unblocked tasks and all are terminal — run the final ship-time code-review gateway **before** declaring the Idea done and **before** the Phase 5b completion report. After the last task is verified, the PostToolUse hook injects a reminder to spawn the code-reviewer; you MUST spawn it yourself in **foreground** (do NOT set `run_in_background`).
+
+```
+# Spawn the code-reviewer for the IDEA (not a task). Determine the round
+# number by reading prior code-review VERDICT comments on the idea.
+Agent({ subagent_type: "chorus:code-reviewer",
+        prompt: "Review the aggregate code for idea <idea-uuid>. Round: N." })
+
+# Read its VERDICT on the idea
+comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" })
+# Find the most recent comment containing "VERDICT:"
+```
+
+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 the fix tasks through Phase 3 (execute) → Phase 4 (verify), then **re-spawn the code-reviewer** for the next round. Loop bounded by `maxCodeReviewRounds` (plugin config, default 3; 0 = unlimited).
+
+```
+# Max rounds escalation
+ESCALATE: "Idea '<title>' failed code review after {maxCodeReviewRounds} rounds.
+           Last BLOCKERs: <list>. Manual intervention needed. Idea UUID: <uuid>"
+```
+
+**No new VERDICT comment after the code-reviewer returns?** It exhausted its `maxTurns` budget (the code-reviewer runs with a larger budget than the task-reviewer because it reviews the whole feature). Respawn it ONCE with a concise-budget hint, then if still silent treat as PASS WITH NOTES and proceed — do not loop forever on a silent reviewer.
+
+> The code-review gateway is **behavioral**, consistent with the proposal/task reviewers: its verdict is advisory and does not change the Idea's stored status. The /yolo orchestrator honors it — PASS to ship, FAIL to loop. It runs **before** the completion report so the report is never written for a feature with an outstanding FAIL.
+
+---
+
 ### Phase 5: Report
 
 After all waves complete, output a markdown summary:
@@ -474,6 +510,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:** the completion report is written only **after** the Phase 4.5 code-review gateway returns PASS / PASS WITH NOTES. Never write it while a code-review FAIL is outstanding — the report is a ship-time summary, and the gateway is what clears the feature to ship.
+
 ---
 
 ## Error Handling
@@ -484,6 +522,7 @@ A successful `/yolo` run always finishes the Idea — call `chorus_create_report
 | Project creation fails | Report error, suggest user create project manually and retry with `--project` |
 | Proposal reviewer FAIL after maxRounds | Stop pipeline, report persisting BLOCKERs, suggest manual review |
 | Task reviewer FAIL after maxRounds | Flag task as escalation-needed, continue with other tasks |
+| Code-review gateway FAIL after maxCodeReviewRounds | Stop before ship, escalate the persisting feature-level BLOCKERs to a human (Idea UUID), do not write the completion report |
 | Sub-agent crash / no submit | Log error, skip task, pick it up in next wave if possible |
 | Ctrl+C | All entities persist in Chorus. User can resume via `/develop` or `/review` |
 

package/.next/standalone/public/skill/brainstorm-chorus/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/.next/standalone/public/skill/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
 ---
@@ -34,6 +34,7 @@ Skill files are hosted under the `<BASE_URL>/skill/` path.
 | **brainstorm-chorus** | Optional divergent→convergent dialogue, prelude to elaboration | `/skill/brainstorm-chorus/SKILL.md` |
 | **proposal-reviewer-chorus** | Read-only adversarial proposal reviewer (posts VERDICT) | `/skill/proposal-reviewer-chorus/SKILL.md` |
 | **task-reviewer-chorus** | Read-only adversarial task reviewer (posts VERDICT) | `/skill/task-reviewer-chorus/SKILL.md` |
+| **code-reviewer-chorus** | Read-only adversarial code-review gateway — reviews an Idea's aggregate code change before ship (posts VERDICT on the Idea) | `/skill/code-reviewer-chorus/SKILL.md` |
 | **yolo-chorus** | Full-auto AI-DLC pipeline — prompt to done | `/skill/yolo-chorus/SKILL.md` |
 | **package.json** | Version & download metadata | `/skill/package.json` |
 
@@ -41,7 +42,7 @@ Skill files are hosted under the `<BASE_URL>/skill/` path.
 
 ```bash
 BASE_URL="<BASE_URL>"
-mkdir -p .claude/skills/chorus .claude/skills/idea-chorus .claude/skills/proposal-chorus .claude/skills/develop-chorus .claude/skills/review-chorus .claude/skills/quick-dev-chorus .claude/skills/brainstorm-chorus .claude/skills/proposal-reviewer-chorus .claude/skills/task-reviewer-chorus .claude/skills/yolo-chorus
+mkdir -p .claude/skills/chorus .claude/skills/idea-chorus .claude/skills/proposal-chorus .claude/skills/develop-chorus .claude/skills/review-chorus .claude/skills/quick-dev-chorus .claude/skills/brainstorm-chorus .claude/skills/proposal-reviewer-chorus .claude/skills/task-reviewer-chorus .claude/skills/code-reviewer-chorus .claude/skills/yolo-chorus
 curl -s $BASE_URL/skill/chorus/SKILL.md > .claude/skills/chorus/SKILL.md
 curl -s $BASE_URL/skill/idea-chorus/SKILL.md > .claude/skills/idea-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-chorus/SKILL.md > .claude/skills/proposal-chorus/SKILL.md
@@ -51,6 +52,7 @@ curl -s $BASE_URL/skill/quick-dev-chorus/SKILL.md > .claude/skills/quick-dev-cho
 curl -s $BASE_URL/skill/brainstorm-chorus/SKILL.md > .claude/skills/brainstorm-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-reviewer-chorus/SKILL.md > .claude/skills/proposal-reviewer-chorus/SKILL.md
 curl -s $BASE_URL/skill/task-reviewer-chorus/SKILL.md > .claude/skills/task-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/code-reviewer-chorus/SKILL.md > .claude/skills/code-reviewer-chorus/SKILL.md
 curl -s $BASE_URL/skill/yolo-chorus/SKILL.md > .claude/skills/yolo-chorus/SKILL.md
 curl -s $BASE_URL/skill/package.json > .claude/skills/chorus/package.json
 ```
@@ -59,7 +61,7 @@ curl -s $BASE_URL/skill/package.json > .claude/skills/chorus/package.json
 
 ```bash
 BASE_URL="<BASE_URL>"
-mkdir -p ~/.moltbot/skills/chorus ~/.moltbot/skills/idea-chorus ~/.moltbot/skills/proposal-chorus ~/.moltbot/skills/develop-chorus ~/.moltbot/skills/review-chorus ~/.moltbot/skills/quick-dev-chorus ~/.moltbot/skills/brainstorm-chorus ~/.moltbot/skills/proposal-reviewer-chorus ~/.moltbot/skills/task-reviewer-chorus ~/.moltbot/skills/yolo-chorus
+mkdir -p ~/.moltbot/skills/chorus ~/.moltbot/skills/idea-chorus ~/.moltbot/skills/proposal-chorus ~/.moltbot/skills/develop-chorus ~/.moltbot/skills/review-chorus ~/.moltbot/skills/quick-dev-chorus ~/.moltbot/skills/brainstorm-chorus ~/.moltbot/skills/proposal-reviewer-chorus ~/.moltbot/skills/task-reviewer-chorus ~/.moltbot/skills/code-reviewer-chorus ~/.moltbot/skills/yolo-chorus
 curl -s $BASE_URL/skill/chorus/SKILL.md > ~/.moltbot/skills/chorus/SKILL.md
 curl -s $BASE_URL/skill/idea-chorus/SKILL.md > ~/.moltbot/skills/idea-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-chorus/SKILL.md > ~/.moltbot/skills/proposal-chorus/SKILL.md
@@ -69,6 +71,7 @@ curl -s $BASE_URL/skill/quick-dev-chorus/SKILL.md > ~/.moltbot/skills/quick-dev-
 curl -s $BASE_URL/skill/brainstorm-chorus/SKILL.md > ~/.moltbot/skills/brainstorm-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-reviewer-chorus/SKILL.md > ~/.moltbot/skills/proposal-reviewer-chorus/SKILL.md
 curl -s $BASE_URL/skill/task-reviewer-chorus/SKILL.md > ~/.moltbot/skills/task-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/code-reviewer-chorus/SKILL.md > ~/.moltbot/skills/code-reviewer-chorus/SKILL.md
 curl -s $BASE_URL/skill/yolo-chorus/SKILL.md > ~/.moltbot/skills/yolo-chorus/SKILL.md
 curl -s $BASE_URL/skill/package.json > ~/.moltbot/skills/chorus/package.json
 ```
@@ -402,33 +405,34 @@ approved --> draft  (via revoke — cascade-closes tasks, deletes documents)
 
 ## Independent Review
 
-Chorus uses **independent, read-only adversarial reviewers** at two gates: before a proposal is approved, and before a task is verified. The reviewer's job is to find what is wrong — not to rubber-stamp. Its output is **advisory**: it informs the admin's decision but does not by itself approve, reject, verify, or reopen anything.
+Chorus uses **independent, read-only adversarial reviewers** at three gates: before a proposal is approved, before a task is verified, and before an Idea's code ships (the final aggregate gateway). The reviewer's job is to find what is wrong — not to rubber-stamp. Its output is **advisory**: it informs the orchestrator's decision but does not by itself approve, reject, verify, reopen, or ship anything.
 
 This is the **single canonical description** of the reviewer pattern. The `develop-chorus`, `review-chorus`, and `yolo-chorus` skills all point back here rather than redefining it.
 
 ### The Pattern
 
-1. **Spawn a read-only sub-agent** that loads one of the two reviewer skills:
+1. **Spawn a read-only sub-agent** that loads one of the three reviewer skills:
    - `proposal-reviewer-chorus` (`<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md`) — for reviewing a **proposal** before approval. Pass it the `proposalUuid`.
    - `task-reviewer-chorus` (`<BASE_URL>/skill/task-reviewer-chorus/SKILL.md`) — for reviewing a **task** before verification. Pass it the `taskUuid`.
-2. **The reviewer audits independently** and posts exactly **one** structured `VERDICT` comment on the proposal/task via `chorus_add_comment`. The comment ends with one literal verdict string: `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`.
+   - `code-reviewer-chorus` (`<BASE_URL>/skill/code-reviewer-chorus/SKILL.md`) — the **final ship-time gateway**: reviews an **Idea's aggregate code change** (the whole feature across all its tasks) after its last task is verified, before the code ships. Pass it the `ideaUuid` and the review round number. Posts its VERDICT on the **Idea**.
+2. **The reviewer audits independently** and posts exactly **one** structured `VERDICT` comment on the proposal/task/idea via `chorus_add_comment`. The comment ends with one literal verdict string: `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`.
 3. **Read the verdict and act.** Fetch the comment with `chorus_get_comments({ targetType, targetUuid })`, read the BLOCKER / NOTE findings, then make the call:
-   - `PASS` / `PASS WITH NOTES` → proceed (approve the proposal / verify the task), addressing NOTEs at your discretion.
-   - `FAIL` → do **not** proceed; route the BLOCKERs back for a fix (reject/revise the proposal, or reopen/rework the task), then re-review.
+   - `PASS` / `PASS WITH NOTES` → proceed (approve the proposal / verify the task / ship the feature), addressing NOTEs at your discretion.
+   - `FAIL` → do **not** proceed; route the BLOCKERs back for a fix (reject/revise the proposal, reopen/rework the task, or — for the code-review gateway — **add new fix tasks to the approved proposal** and re-run once they are done), then re-review. The cleanest way to run those code-review fix tasks is the **quick-dev** workflow (`<BASE_URL>/skill/quick-dev-chorus/SKILL.md`): call `chorus_create_tasks` with `proposalUuid` set to the **current approved proposal** so the fix tasks attach to it (not standalone), then execute → verify them like any quick task. Do **not** reopen the already-verified tasks.
 
-> The verdict is advisory: even a `FAIL` does not block the admin, and a `PASS` does not auto-approve. A human/admin makes the final decision.
+> The verdict is advisory: even a `FAIL` does not hard-block, and a `PASS` does not auto-approve. A human/admin (or, under `/yolo`, the automated orchestrator) makes the final decision. The code-review gateway in particular is a **behavioral** gate — it does not change the Idea's stored status; the orchestrator honors its verdict.
 
 ### Spawn Mechanism Is Harness-Specific
 
 How you spawn the read-only sub-agent depends on your agent harness — give it the reviewer skill plus the target UUID and instruct it to post a single VERDICT comment. Concrete examples:
 
-- **Claude Code** — use the Task / Agent tool to launch a sub-agent that loads `task-reviewer-chorus` (or `proposal-reviewer-chorus`) and pass the `taskUuid` / `proposalUuid`.
+- **Claude Code** — use the Task / Agent tool to launch a sub-agent that loads `task-reviewer-chorus` (or `proposal-reviewer-chorus` / `code-reviewer-chorus`) and pass the `taskUuid` / `proposalUuid` / `ideaUuid`.
 - **Codex** — use `spawn_agent` with the reviewer skill and the target UUID.
 - Other harnesses: use whatever sub-agent / sub-task primitive they expose.
 
 ### Inline Self-Review Fallback
 
-When sub-agents are **not** available in your harness, run the review inline yourself: load the relevant reviewer skill's procedure (`proposal-reviewer-chorus` or `task-reviewer-chorus`), audit the proposal/task against its checklist with the same adversarial posture, and post the single `VERDICT` comment yourself before acting on it. A same-agent self-review is weaker than a fresh independent reviewer, but it is far better than skipping the gate.
+When sub-agents are **not** available in your harness, run the review inline yourself: load the relevant reviewer skill's procedure (`proposal-reviewer-chorus`, `task-reviewer-chorus`, or `code-reviewer-chorus`), audit the proposal/task/idea against its checklist with the same adversarial posture, and post the single `VERDICT` comment yourself before acting on it. A same-agent self-review is weaker than a fresh independent reviewer, but it is far better than skipping the gate.
 
 ---
 
@@ -447,6 +451,7 @@ This is the core overview skill. For stage-specific workflows, download and read
 | **Review** | `review-chorus` | `<BASE_URL>/skill/review-chorus/SKILL.md` |
 | **Proposal Review** | `proposal-reviewer-chorus` | `<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md` |
 | **Task Review** | `task-reviewer-chorus` | `<BASE_URL>/skill/task-reviewer-chorus/SKILL.md` |
+| **Code Review (ship gateway)** | `code-reviewer-chorus` | `<BASE_URL>/skill/code-reviewer-chorus/SKILL.md` |
 | **Full-Auto** | `yolo-chorus` | `<BASE_URL>/skill/yolo-chorus/SKILL.md` |
 
 ### Getting Started

package/.next/standalone/public/skill/code-reviewer-chorus/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: code-reviewer-chorus
+description: Read-only adversarial Chorus code-review gateway — independently reviews an Idea's aggregate code change (the whole feature across all its tasks) and posts a single structured 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
+
+This skill is the **read-only adversarial final gateway** before an Idea's code ships. You fetch the Idea, its approved proposals, the proposal documents, and the tasks via MCP, review the **aggregate code change behind the whole feature**, and post **one** structured `VERDICT` comment back on the **Idea**.
+
+You are the last reviewer in the AI-DLC pipeline. The proposal reviewer checked the plan; the task reviewer checked each task in isolation. Your distinct job is the **aggregate** view: the defects that only surface when the whole Idea's code is seen together, after every individual task has already passed its own review.
+
+Each task was implemented and verified in isolation by an LLM. Your value is **not** re-checking single tasks — it 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.
+
+Two failure patterns to avoid:
+
+- **Verification avoidance** — reading code, narrating what you *would* test, writing "PASS," and never actually running anything.
+- **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.
+
+---
+
+## READ-ONLY Posture (Hard Constraints)
+
+You are **strictly prohibited** from modifying the project. Specifically:
+
+- Creating, modifying, or deleting **any** files in the project directory.
+- Installing dependencies or packages.
+- Running git write operations.
+
+Your only side effect is posting a single comment via `chorus_add_comment` on the Idea. Everything else is read-only MCP queries plus read-only Bash.
+
+### Bash Policy (Read-Only)
+
+Bash is allowed **only** for running the project's own test/build/lint commands and for read-only inspection.
+
+**Allowed (read-only + test/build/lint):**
+
+- Project test / build / lint commands (`pnpm test`, `pnpm build`, `pnpm lint`, `pytest`, `make test`, `cargo test`, …).
+- `cat` / `head` / `tail` / `wc` / `diff`.
+- `grep` / `rg` / `ls` / `find`.
+- `git diff` / `git log` / `git show`.
+
+**Strictly forbidden:**
+
+- `git add` / `git commit` / `git push` / `git checkout` / `git reset` (any git write op).
+- `rm` / `mv` / `cp`, output redirection (`>`, `>>`), `tee`, `sed -i` (any file mutation).
+- Package installs (`npm install`, `pnpm add`, `pip install`, `cargo add`, …).
+- `curl` / `wget` mutations.
+
+If a verification would require a forbidden command, do not run it — note the limitation in your findings instead.
+
+---
+
+## What You Receive
+
+An `ideaUuid` (and, in Round 2+, a review round number). Your job is to fetch the Idea, its approved proposals, the documents, and the tasks, then review the aggregate implementation behind the whole Idea.
+
+---
+
+## Review Procedure
+
+**Efficiency rule:** Gather ALL context first (Step 1), then verify. Batch your read calls.
+
+**Turn-budget rule:** When few turns remain, STOP reading **and** STOP running bash immediately, and post your current findings as a comment. Incomplete posted findings are strictly better than no comment at all.
+
+### Step 1: Gather Context (batch these)
+
+```
+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" })       # docs + task drafts
+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
+
+There is **no** fixed branch convention. Infer the scope of "this Idea's code change" from the task work reports plus repository state:
+
+```
+git log --oneline -n 50
+git diff <base>...HEAD --stat     # if reports name a base/branch
+git show <commit>                  # for commits the reports reference
+```
+
+**State the scope you settled on** in your comment (e.g. "Reviewed the aggregate of commits abc1..def9 spanning tasks T1–T5"). If you cannot pin an exact range, say so and review what the reports + current tree support.
+
+### Step 3: Review the Whole-Feature Dimensions
+
+These are the dimensions that per-task review structurally cannot catch. Cover each:
+
+1. **Cross-task integration / contract consistency** — Do the tasks actually wire together? Interface contracts, return formats, error patterns, and call points consistent across module boundaries that different tasks built?
+2. **Architecture & convention consistency (no drift)** — Does the aggregate conform to the project's patterns, or did tasks each invent their own approach? Duplicated logic, divergent naming, inconsistent layering.
+3. **Security** — Does the combination of changes 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 introduced by the aggregate.
+5. **Feature-level test coverage adequacy** — Across the whole feature, are the 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, and free of obvious defects when read as one body of work?
+
+### Step 4: Run Feature-Level Build / Test
+
+Run the project's declared build/test/lint commands across the whole feature. Record the exact command, exit code, and relevant output. A **broken build or failing tests is an automatic `VERDICT: FAIL`**. Results are context — still verify each dimension independently.
+
+**Hallucination check:** Flag anything LLM-fabricated as a **NOTE** — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.
+
+---
+
+## 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.
+
+---
+
+## Finding Classification: BLOCKER vs NOTE
+
+Classify **every** finding as exactly one of:
+
+**BLOCKER** — Blocks ship:
+
+- Build or 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 ship:
+
+- 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.
+
+---
+
+## Round 2+ Awareness
+
+You may receive the current review round number. Read your prior verdict comments on the Idea to establish it.
+
+- **Round 1** — Full aggregate review at normal strictness.
+- **Round 2+** — Focus ONLY on whether the previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged in earlier rounds. Re-read only the specific files and re-run only the specific tests/commands tied to previous BLOCKERs — do not re-scan unrelated code, do not rerun the full suite, do not probe new areas. If all previous BLOCKERs are resolved → `VERDICT: PASS` (or `VERDICT: PASS WITH NOTES` if old NOTEs remain).
+
+---
+
+## VERDICT Contract
+
+You MUST end your comment with exactly one of these three **literal** strings (automation greps for them):
+
+- `VERDICT: PASS`
+- `VERDICT: PASS WITH NOTES`
+- `VERDICT: FAIL`
+
+Mapping:
+
+| Findings | Verdict |
+|----------|---------|
+| Any BLOCKER | `VERDICT: FAIL` |
+| Only NOTEs (no BLOCKER) | `VERDICT: PASS WITH NOTES` |
+| Nothing | `VERDICT: PASS` |
+
+Do NOT invent other verdicts. The verdict is **advisory**: it informs the ship decision (the human in `review-chorus`, or the agent in `yolo-chorus`); it does not by itself change the Idea's status.
+
+---
+
+## Output Format (Required)
+
+Keep total output **under ~1000 characters** — be concise. No preamble, no trailing summary paragraph.
+
+```
+### 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:** [specific finding with file paths, line numbers]
+**Expected:** [what the feature requires]
+**Actual:** [what happened]
+
+VERDICT: PASS
+```
+
+(or `VERDICT: PASS WITH NOTES` / `VERDICT: FAIL` — exact literal, no other variants)
+
+---
+
+## Posting Results
+
+Post the full review as a **single** comment on the **Idea**:
+
+```
+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.
+
+---
+
+## Next
+
+- The orchestrator reads your VERDICT: PASS / PASS WITH NOTES → ship; FAIL → add fix tasks and re-run. See `review-chorus` and `yolo-chorus` skills.
+- For the developer workflow (what produced the code), see `develop-chorus` skill.
+- For platform overview and shared tools, see `chorus` skill.

package/.next/standalone/public/skill/develop-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, self-chec
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---
@@ -184,6 +184,8 @@ chorus_submit_for_verify({
 
 > **Independent Review:** After `chorus_submit_for_verify`, run an independent review of the task before it is verified. Spawn a read-only sub-agent that loads the `task-reviewer-chorus` skill (`<BASE_URL>/skill/task-reviewer-chorus/SKILL.md`), pass it the `taskUuid`, and let it post a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the task; then read it with `chorus_get_comments` and act. The verdict is **advisory** (it does not block verification). The spawn mechanism is harness-specific, and an inline self-review fallback exists when sub-agents are unavailable — see the canonical **Independent Review** section in the `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`) for the full pattern.
 
+> **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. Spawn a read-only sub-agent that loads the `code-reviewer-chorus` skill (`<BASE_URL>/skill/code-reviewer-chorus/SKILL.md`), pass it the `ideaUuid` + round number, and let it review the Idea's **aggregate** code change (cross-task integration, architecture, security, regression, feature-level coverage) and post one `VERDICT` comment on the **Idea**. `PASS` / `PASS WITH NOTES` → ship; `FAIL` → fix via the **quick-dev** workflow (`<BASE_URL>/skill/quick-dev-chorus/SKILL.md`): `chorus_create_tasks` with `proposalUuid` set to the **current approved proposal** so the fix tasks attach to it, execute → verify them, then re-run the gateway. Do **not** reopen the already-verified tasks. The plugin's post-verify hook injects this reminder automatically; the verdict is **advisory** (same canonical pattern). Run it **before** writing any idea-completion report.
+
 ### Step 9: Handle Review Feedback
 
 If reopened (verification failed), **all acceptance criteria are reset to pending**.

package/.next/standalone/public/skill/idea-chorus/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/.next/standalone/public/skill/package.json

@@ -28,6 +28,7 @@
       "brainstorm-chorus/SKILL.md": "/skill/brainstorm-chorus/SKILL.md",
       "proposal-reviewer-chorus/SKILL.md": "/skill/proposal-reviewer-chorus/SKILL.md",
       "task-reviewer-chorus/SKILL.md": "/skill/task-reviewer-chorus/SKILL.md",
+      "code-reviewer-chorus/SKILL.md": "/skill/code-reviewer-chorus/SKILL.md",
       "yolo-chorus/SKILL.md": "/skill/yolo-chorus/SKILL.md"
     },
     "requires": {
@@ -61,6 +62,7 @@
       "brainstorm-chorus/SKILL.md": "/skill/brainstorm-chorus/SKILL.md",
       "proposal-reviewer-chorus/SKILL.md": "/skill/proposal-reviewer-chorus/SKILL.md",
       "task-reviewer-chorus/SKILL.md": "/skill/task-reviewer-chorus/SKILL.md",
+      "code-reviewer-chorus/SKILL.md": "/skill/code-reviewer-chorus/SKILL.md",
       "yolo-chorus/SKILL.md": "/skill/yolo-chorus/SKILL.md"
     },
     "requires": {

package/.next/standalone/public/skill/proposal-chorus/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
 ---
@@ -251,10 +251,14 @@ Dependencies are validated: same project, no self-dependency, no cycles (DFS det
 
 ```
 chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uuid>" })
+
+# Optional: pin the task to a specific (agent, host, cwd) AgentInstance
+chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uuid>", instanceUuid: "<agent-instance-uuid>" })
 ```
 
 - Task should be `open` or `assigned`
 - Target agent must have `task: ["write"]` permission
+- Pass `instanceUuid` to pin the task to a specific online instance (assigns as `agent_instance`); omit it for a plain `agent` assignment that inherits the root idea's pinned instance at wake time
 
 ---
 

package/.next/standalone/public/skill/proposal-reviewer-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus proposal reviewer — audits PRD/task
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.11.0"
+  version: "0.11.1"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/quick-dev-chorus/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/.next/standalone/public/skill/review-chorus/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
 ---
@@ -205,6 +205,17 @@ The spawn mechanism is harness-specific, and an inline self-review fallback exis
 
 > **VERDICT is advisory** — a `FAIL` does not block verification and a `PASS` does not auto-verify. The admin reads the review comment, marks the acceptance criteria, and makes the final decision.
 
+#### B2.6: Final Code-Review Gateway (after an Idea's LAST task is verified)
+
+When the task you just verified is the **last** task of its idea-rooted proposal, run the ship-time code-review gateway before the Idea's code is considered shipped. Spawn a read-only sub-agent that loads the `code-reviewer-chorus` skill (`<BASE_URL>/skill/code-reviewer-chorus/SKILL.md`), pass it the `ideaUuid` + round number, and let it review the Idea's **aggregate** code change across all its tasks — cross-task integration, architecture/convention consistency, security, regression/performance, and feature-level test coverage — dimensions a single-task review cannot see. It posts one `VERDICT` comment on the **Idea**; read it with `chorus_get_comments({ targetType: "idea", targetUuid })` before deciding.
+
+- `PASS` / `PASS WITH NOTES` → the feature may ship.
+- `FAIL` → fix via the **quick-dev** workflow (`<BASE_URL>/skill/quick-dev-chorus/SKILL.md`): `chorus_create_tasks` with `proposalUuid` set to the **current approved proposal** so the fix tasks attach to it, targeting the BLOCKERs — do **not** reopen the already-verified tasks — then execute → verify them and re-run the gateway (next round), bounded by `maxCodeReviewRounds`.
+
+The plugin's post-verify hook injects this reminder automatically on the last-task verify. The spawn mechanism is harness-specific with an inline fallback — see the canonical **Independent Review** section in the `chorus` skill.
+
+> **VERDICT is advisory / behavioral** — the gateway does not change the Idea's stored status; the orchestrator honors its verdict. Run it **before** writing any idea-completion report (the report must not be written while a `FAIL` is outstanding).
+
 #### B3: Mark Acceptance Criteria
 
 Review and mark each criterion: