@chorus-aidlc/chorus 0.17.2 → 0.18.0

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.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -51,6 +51,8 @@ Full-auto AI-DLC pipeline. User provides a prompt; agent drives the entire lifec
   Done. Report summary.
 ```
 
+**First-principles alignment (a stage-tailored instruction in every reviewer).** The proposal-, task-, and code-reviewer each also verify, top-down, that the work still serves the *original Idea's intent* — building the intent baseline from the Idea it resolves from the entity under review — via the existing `chorus_get_idea` + `chorus_get_elaboration` + `chorus_get_comments`, counting **human-authored** content only — and flagging scope creep, requirement loss/shrink, or semantic drift. Unauthorized drift is a **BLOCKER → FAIL / reject**, downgraded to a NOTE only when traceable to a **human-originated** authorization (a human-authored Idea comment, a human-answered elaboration, or an explicit human override) — an agent's own comment never authorizes. In `/yolo` there is no human at the gate, so a self-generated (agent-authored) elaboration or comment does NOT clear alignment drift: fix the drift (reject/reopen + revise) rather than rationalizing it.
+
 **Escape hatch:** Ctrl+C at any time. All created entities (project, idea, proposal, tasks) persist in Chorus. Resume manually via `/develop` or `/review`.
 
 ---
@@ -188,20 +190,16 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
 
 #### Step 1.4: Create Proposal
 
-1. **Detect OpenSpec mode.** Load the `openspec-aware` skill at `.claude/skills/openspec-aware/SKILL.md` and run its §1 detection contract. The result determines how the rest of this step authors documents:
-
-   - `CHORUS_OPENSPEC_ACTIVE=1` → spec-driven branch (sub-step 2a below).
-   - `CHORUS_OPENSPEC_ACTIVE=0` → free-form branch (sub-step 2b below).
-
-   This is mandatory — yolo runs unattended, so silently picking the wrong mode is exactly the failure scenario the detection contract exists to prevent.
+1. **Read the spec mode (already computed).** The SessionStart hook (`bin/resolve-spec-mode.sh`) has already resolved it — do NOT re-derive. Read the `## Spec Mode` section: it states `CHORUS_SPEC_MODE=<lite|openspec|off>` + a routing note. (Spawned without that context? Source the *same* `bin/resolve-spec-mode.sh` for `SPEC_MODE`/`SPEC_FAIL` — never hand-roll the rule.) Act on that value: `openspec` → **2a**, `off` → **2b**, `lite` → **2c**. If the section says the mode **cannot be honored** (e.g. explicit `openspec` but unusable — it prints the config-conflict or install-hint reason), **halt** and surface it; do NOT silently fall back or enter 2a with no OpenSpec to author. (This matters because yolo runs unattended — the hook, not the agent, is the single source of the decision.)
 
-2. **Create the empty proposal container.** In OpenSpec mode, the `description` MUST contain the literal line `OpenSpec change slug: <slug>` (use the `$SLUG` you'll pick in 2a); in free-form mode, omit that line.
+2. **Create the empty proposal container.** In OpenSpec mode the `description` MUST contain `OpenSpec change slug: <slug>`; in spec-lite mode the locator line `Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/` (use the `$SLUG` you'll pick in 2a / 2c); in free-form mode omit any slug line.
 
    ```
    chorus_pm_create_proposal({
      projectUuid: "<project-uuid>",
      title: "<feature name>",
-     description: "<summary>\n\nOpenSpec change slug: <slug>",   // OpenSpec mode
+     description: "<summary>\n\nSpec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/",  // spec-lite mode
+     // description: "<summary>\n\nOpenSpec change slug: <slug>", // OpenSpec mode
      // description: "<summary>",                                 // free-form mode
      inputType: "idea",
      inputUuids: ["<idea-uuid>"]
@@ -210,7 +208,7 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
 
    Then branch:
 
-   **2a. OpenSpec mode (`CHORUS_OPENSPEC_ACTIVE=1`).** Follow `openspec-aware` §3 end-to-end:
+   **2a. OpenSpec mode (resolved mode = openspec; `CHORUS_OPENSPEC_ACTIVE=1`).** Follow `openspec-aware` §3 end-to-end:
    - Pick `$SLUG`, run `openspec new change "$SLUG"` (§3.1–§3.2).
    - Author `proposal.md`, `design.md`, and one `specs/<capability>/spec.md` per capability locally on disk (§3.3). ADDED Requirements only; per-spec fallback to free-form Markdown if MODIFIED/REMOVED is needed.
    - Define the `chorus_check_response` helper (§6); prefer `chorus mcp call … --arg-file content=<file>` for mirrors (§3.4/§3.6) — the bash-wrapper fallback's `$API` + `json_encode_file` are only needed when `chorus` is not on `PATH`.
@@ -220,7 +218,7 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
 
    Then continue to step 3 (task drafts).
 
-   **2b. Free-form mode (`CHORUS_OPENSPEC_ACTIVE=0`).** Add a tech design document draft directly via MCP, content authored inline:
+   **2b. Free-form mode (resolved mode = free-form).** Only when step 1 resolved to free-form — i.e. explicit `CHORUS_SPEC_MODE=off`. (Unset never resolves here — it resolves to OpenSpec when usable, else spec-lite.) Add a tech design document draft directly via MCP, content authored inline:
 
    ```
    chorus_pm_add_document_draft({
@@ -231,6 +229,8 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
    })
    ```
 
+   **2c. spec-lite mode (resolved mode = lite).** Load the `spec-lite` skill (`skills/spec-lite/SKILL.md`) and follow it: pick `$SLUG` (a **capability/feature** name — `.chorus/specs/<slug>/` holds the durable local spec `spec.md`, edited in place across changes, not one folder per change). Ensure the durable `spec.md` exists, using the `spec-lite` skill's inline durable-spec template the first time this capability is specced — local-only, **no Chorus ids**: Intent / plain-prose Requirements + `- [ ]` acceptance points / Non-goals — and update it in place to the new truth. Create this change's **dated folder** `.chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/` and write its **synced** Chorus-typed docs (shape = the `spec-lite` skill's inline dated-folder document template) — `prd.md` (primary), plus `tech_design.md` etc. only if warranted. The proposal `description` MUST carry the literal locator line `Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/` (the deterministic link develop uses). Mirror **each** dated-folder `<type>.md` to its persistent Document byte-exact — first time a doc is authored e.g. `chorus mcp call chorus_pm_add_document_draft "{\"proposalUuid\":\"<uuid>\",\"type\":\"prd\",\"title\":\"PRD: <feature>\"}" --arg-file content=.chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/prd.md`, later edits via `chorus_pm_update_document` against the recorded `documentUuid`. **`spec.md` is never mirrored.** No `OpenSpec change slug:` line and no `openspec/changes/` scaffold; there is no `tasks.md`. Then continue to step 3 for task drafts.
+
 3. **Add task drafts incrementally** (use returned `draftUuid` for dependency chaining). `acceptanceCriteriaItems` is **required** on every draft — at least one non-blank criterion, or the call is rejected:
    ```
    # First task
@@ -268,19 +268,33 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
    ```
    chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
    ```
-   After this call, the PostToolUse hook injects context instructing you to spawn `chorus:proposal-reviewer`. You MUST spawn it yourself in **foreground** (do NOT set `run_in_background`) — it is NOT auto-launched.
+   After this call, the PostToolUse hook injects context instructing you to spawn `chorus:proposal-reviewer`. You MUST spawn it yourself — it is NOT auto-launched — and wait for it to complete before approving.
+
+---
+
+### Reviewer contract (applies to every review gate below)
+
+Every gate in Phases 2, 4 and 4.5 follows the same three steps. They are written once here; the phases below only name their entity and their stage-specific actions.
+
+1. **Spawn and wait.** Spawn the reviewer as a read-only sub-agent, then wait for it using this harness's waiting mechanism — in Claude Code, the sub-agent's completion notification. The launch result is not the verdict: these reviewer subagent types report an async launch regardless of the flag you pass.
+2. **Read THIS round's VERDICT.** Call `chorus_get_comments` on the entity and find the `VERDICT:` comment posted **after your dispatch**, not an older round's. Do not advance the gate before you have read it.
+3. **No VERDICT for this round?** Check what the reviewer *did* post:
+   - **A reported round limit, or any other explicit refusal to review** — a deliberate escalation to a human. STOP: do not respawn, do not self-review, do not post a VERDICT of your own.
+   - **Nothing at all** — respawn ONCE, telling it to stay within its turn budget and reserve its last turns for the VERDICT, then apply this same check again to what the retry posts. An explicit refusal from the retry still means STOP; only a second true silence lets you review the entity yourself as a read-only pass and POST the VERDICT, then proceed on what you posted rather than looping forever.
+
+**Absence is never a PASS**, and a round limit reached by someone else is never yours to clear.
 
 ---
 
 ### Phase 2: Proposal Review Loop
 
-After `chorus_pm_submit_proposal`, the PostToolUse hook injects context instructing you to spawn `chorus:proposal-reviewer`. You MUST manually spawn it as a read-only sub-agent in **foreground** (do NOT set `run_in_background`). Wait for it to complete, then:
+After `chorus_pm_submit_proposal`, the PostToolUse hook injects context instructing you to spawn `chorus:proposal-reviewer`. Apply the **Reviewer contract** above with the proposal as the entity. Then:
 
-1. **Read the reviewer's VERDICT:**
+1. **Read THIS round's VERDICT:**
    ```
    chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
    ```
-   Look for the most recent comment containing `VERDICT:`.
+   Look for the `VERDICT:` comment posted **after your dispatch** — not an older round's. Do not approve or reject before you have read it.
 
 2. **Act on the VERDICT:**
 
@@ -314,15 +328,15 @@ After `chorus_pm_submit_proposal`, the PostToolUse hook injects context instruct
           Proposal UUID: <uuid>"
    ```
 
-4. **No new VERDICT comment after reviewer returns?** The reviewer exhausted its `maxTurns` budget. Respawn it ONCE with a concise-budget hint: *"Stay within turn budget. Skip deep source verification. Fetch proposal + comments + idea only, skim for obvious BLOCKERs, and post your VERDICT within the first 10 turns."* If the second attempt still produces no VERDICT, treat the proposal as PASS WITH NOTES and proceed — the pipeline cannot loop forever on a silent reviewer.
+4. **No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the proposal yourself if the reviewer stays silent.
 
 ---
 
 ### Phase 3: Task Execution (Wave-Based)
 
-After proposal approval, tasks exist in `open` status. Execute them in dependency-ordered waves using Agent Teams. If team creation fails, fall back to main agent execution.
+After proposal approval, tasks exist in `open` status. Execute them in dependency-ordered waves: one sub-agent per unblocked task, the whole wave dispatched in a single message. If sub-agent dispatch is unavailable or sub-agents fail repeatedly, fall back to main agent execution.
 
-#### Primary: Agent Team (parallel)
+#### Primary: one sub-agent per task, whole wave in a single message (parallel)
 
 ```
 wave = 1
@@ -338,22 +352,21 @@ loop:
     # Stuck -- tasks failed review and can't proceed
     break with escalation report
 
-  # 2. Try to create team for this wave
-  TeamCreate({ team_name: "yolo-wave-{wave}" })
-
-  # 3. Spawn a sub-agent for each unblocked task
+  # 2. Dispatch ONE sub-agent per unblocked task, issuing the whole wave
+  #    in a SINGLE message — that is what makes them run in parallel.
+  #    There is no team or group object to create first.
   for each task in unblocked:
     Agent({
       name: "task-{short-title}",
       prompt: "Your Chorus task UUID: {task.uuid}\nProject UUID: {project-uuid}\n\nImplement the task per its description and acceptance criteria. Read the task, proposal, and project documents for context."
     })
 
-  # 4. Wait for all sub-agents to complete
+  # 3. Wait for all sub-agents to complete
   #    Each sub-agent follows the /develop workflow:
   #    claim -> in_progress -> develop -> report -> self-check AC -> submit_for_verify
   #    PostToolUse hook injects context — main agent must spawn task-reviewer after submit_for_verify
 
-  # 5. Proceed to Phase 4 (verification) for this wave
+  # 4. Proceed to Phase 4 (verification) for this wave
   wave += 1
 ```
 
@@ -364,7 +377,7 @@ loop:
 
 #### Fallback: Main Agent (sequential)
 
-If `TeamCreate` fails (e.g., Agent Teams not available, permission denied, or sub-agents crash repeatedly), fall back to executing tasks sequentially as the main agent:
+If sub-agent dispatch is unavailable (no sub-agent primitive, permission denied) or sub-agents fail repeatedly, fall back to executing tasks sequentially as the main agent:
 
 ```
 for each task in unblocked:
@@ -399,13 +412,14 @@ for each task in wave_tasks:
     # Sub-agent may have failed; skip or handle
     continue
 
-  # 2. Spawn task-reviewer in FOREGROUND (hook injects context — you must spawn it yourself)
-  #    Do NOT set run_in_background — you need the VERDICT before proceeding
+  # 2. Spawn task-reviewer (hook injects context — you must spawn it yourself),
+  #    then wait for its completion notification. The launch result is NOT the
+  #    verdict — the dispatch reports an async launch whatever flag you pass.
   Agent({ subagent_type: "chorus:task-reviewer", prompt: "Review task <task-uuid>..." })
 
-  # 3. Read task-reviewer VERDICT
+  # 3. Read THIS round's task-reviewer VERDICT — the comment posted after your
+  #    dispatch, not an older round's. Do not verify or reopen before you have it.
   comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
-  # Find the most recent comment containing "VERDICT:"
 
   # 4. Act on VERDICT — three possible outcomes:
   if VERDICT is "PASS":
@@ -443,13 +457,13 @@ ESCALATE: "Task '{title}' failed review after {maxRounds} rounds.
 
 Continue with remaining tasks -- do not halt the entire pipeline for one stuck task.
 
-**No new VERDICT comment after the task-reviewer returns?** It exhausted its `maxTurns` 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 also produces no VERDICT, treat as PASS WITH NOTES and proceed — do not loop indefinitely.
+**No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the task yourself if the reviewer stays silent.
 
 ---
 
 ### 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`).
+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, wait for its completion notification, then read THIS round's `VERDICT` comment on the idea and act on what it says.
 
 ```
 # Spawn the code-reviewer for the IDEA (not a task). Determine the round
@@ -457,9 +471,10 @@ Once **every** task of the idea's proposal is verified (`done`) — i.e. Phase 3
 Agent({ subagent_type: "chorus:code-reviewer",
         prompt: "Review the aggregate code for idea <idea-uuid>. Round: N." })
 
-# Read its VERDICT on the idea
+# Wait for its completion notification, then read THIS round's VERDICT on the idea
 comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" })
-# Find the most recent comment containing "VERDICT:"
+# Find the "VERDICT:" comment posted after your dispatch, not an older round's.
+# Do not declare the feature shippable before you have read it.
 ```
 
 Act on the VERDICT:
@@ -473,7 +488,7 @@ 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.
+**No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the idea's aggregate change yourself if the reviewer stays silent.
 
 > 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.
 

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-code-reviewer.json

@@ -6,5 +6,5 @@
     "@chorus"
   ],
   "includeMcpJson": true,
-  "prompt": "You are the final code-review gateway before a feature ships. Your job is not to confirm the feature works — it is 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.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit/create/delete files in the project, run git, install packages, or execute build/test commands. You review by reading the aggregate diff and the task work reports and by reasoning across them; where you would normally run the feature's build/test, instead require the developers' run evidence (build/test output quoted in their work reports) and treat a broken/failing build reported there — or the absence of any run evidence for a risky change — accordingly (see classification). Your entire output is one comment posted via chorus_add_comment on the IDEA.\n\nEach task was implemented and verified in isolation by an LLM. Per-task review already happened. Your distinct value is the AGGREGATE view: tasks that each pass alone but don't integrate, an 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-coverage gaps between the tasks.\n\nTwo failure patterns to avoid. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS.\" **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.\n\n=== WHAT YOU RECEIVE ===\nYou will receive an ideaUuid and (in Round 2+) the current review round number. Fetch the Idea, its proposals, the proposal documents, and the tasks, then review the aggregate code change behind the whole Idea.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: gather ALL context first, then review. Batch tool calls.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_idea({ ideaUuid })\n  chorus_get_comments({ targetType: \"idea\", targetUuid: ideaUuid })   // prior code-review verdicts -> your round number\n  chorus_get_proposals({ projectUuid, status: \"approved\" })\n  chorus_get_proposal({ proposalUuid, section: \"full\" })              // docs + task drafts\n  chorus_list_tasks({ projectUuid, proposalUuids: [approved] })\nRead each task's work report (in its comments) — the developers describe what they changed and quote their run evidence; that is your map into the diff.\n\nStep 2 — Determine the aggregate change scope yourself. There is NO fixed branch convention. Infer the scope of \"this Idea's code change\" from the task work reports (files/commits/PRs they name) plus the current tree you can read. STATE the scope you settled on in your comment (e.g. \"Reviewed the aggregate of tasks T1-T5 touching src/services/*, per their work reports\"). If you cannot pin an exact range, say so and review what the reports + readable tree support.\n\nStep 3 — Review the whole-feature dimensions (per-task review structurally cannot catch these; cover each):\n1. Cross-task integration / contract consistency — do the tasks actually wire together? interface contracts, return formats, error patterns, call points consistent across module boundaries different tasks built?\n2. Architecture & convention consistency (no drift) — does the aggregate conform to the project's patterns and the rules its context files declare (CLAUDE.md / AGENTS.md / .cursorrules, if present), or did any task drift from them or violate a declared project-level constraint? duplicated logic, divergent naming, inconsistent layering.\n3. Security — does the COMBINATION introduce a risk (authz gap at a seam, injection, secret handling, unsafe deserialization, missing tenant scoping) visible only when the pieces are seen together?\n4. 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.\n5. Feature-level test-coverage adequacy — across the whole feature, are integration seams and end-to-end paths covered, or only per-task units? gaps between tasks.\n6. Code soundness, simplicity, correctness — is the aggregate change correct, reasonably simple, and free of obvious defects read as one body of work?\n\nStep 4 — Use the developers' build/test evidence. You cannot run the suite. Rely on the run evidence quoted in the task work reports. A reported broken build or failing test across the feature is an automatic FAIL. If a risky aggregate change has no run evidence anywhere, flag it as a NOTE (or BLOCKER if it plainly breaks an integration seam).\n\nHallucination check: flag anything LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks ship): build/test failure reported across the feature; broken cross-task integration / contract mismatch causing wrong behavior; security hole introduced by the change; regression in untouched areas; feature-level requirement (from idea/docs) not covered by the aggregate; edge cases causing runtime errors at integration seams.\nNOTE (does not block): style/naming/minor duplication; cross-document wording differences; pseudocode signature mismatch; hallucination-risk specifics; missing run evidence on a low-risk change.\nRules: style and cross-doc wording -> always NOTE. Only functional/security/integration/regression issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nRead prior code-review VERDICT comments on the idea to establish your round number.\n- Round 1: full aggregate review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"Every task passed its review, so the feature is fine\" — the whole can break when every part passed.\n- \"The code looks correct based on my reading\" — reading is a start; demand the developers' run evidence.\n- \"Integration probably works\" — probably is not verified. Find the seam and trace it in the code.\n- \"No security issue is obvious\" — look specifically at seams between tasks, authz, and tenant scoping.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Code Review — Idea <short title> (Round N)\n\n**Scope reviewed:** <tasks / files / commits you inferred>\n\n**PASS (N):** integration, architecture, security, regression, coverage, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 1000 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment ON THE IDEA:\n  chorus_add_comment({ targetType: \"idea\", targetUuid: ideaUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL. Your verdict is advisory — it informs the ship decision (the human in /chorus-review, or the agent in /chorus-yolo); it does not by itself change the Idea's stored status."
+  "prompt": "You are the final code-review gateway before a feature ships. Your job is not to confirm the feature works — it is 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.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit/create/delete files in the project, run git, install packages, or execute build/test commands. You review by reading the aggregate diff and the task work reports and by reasoning across them; where you would normally run the feature's build/test, instead require the developers' run evidence (build/test output quoted in their work reports) and treat a broken/failing build reported there — or the absence of any run evidence for a risky change — accordingly (see classification). Your entire output is one comment posted via chorus_add_comment on the IDEA.\n\nEach task was implemented and verified in isolation by an LLM. Per-task review already happened. Your distinct value is the AGGREGATE view: tasks that each pass alone but don't integrate, an 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-coverage gaps between the tasks.\n\nTwo failure patterns to avoid. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS.\" **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.\n\n=== WHAT YOU RECEIVE ===\nYou will receive an ideaUuid and (in Round 2+) the current review round number. Fetch the Idea, its proposals, the proposal documents, and the tasks, then review the aggregate code change behind the whole Idea.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: gather ALL context first, then review. Batch tool calls.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_idea({ ideaUuid })\n  chorus_get_comments({ targetType: \"idea\", targetUuid: ideaUuid })   // prior code-review verdicts -> your round number\n  chorus_get_proposals({ projectUuid, status: \"approved\" })\n  chorus_get_proposal({ proposalUuid, section: \"full\" })              // docs + task drafts\n  chorus_list_tasks({ projectUuid, proposalUuids: [approved] })\nRead each task's work report (in its comments) — the developers describe what they changed and quote their run evidence; that is your map into the diff.\n\nStep 2 — Determine the aggregate change scope yourself. There is NO fixed branch convention. Infer the scope of \"this Idea's code change\" from the task work reports (files/commits/PRs they name) plus the current tree you can read. STATE the scope you settled on in your comment (e.g. \"Reviewed the aggregate of tasks T1-T5 touching src/services/*, per their work reports\"). If you cannot pin an exact range, say so and review what the reports + readable tree support.\n\nStep 3 — Review the whole-feature dimensions (per-task review structurally cannot catch these; cover each):\n1. Cross-task integration / contract consistency — do the tasks actually wire together? interface contracts, return formats, error patterns, call points consistent across module boundaries different tasks built?\n2. Architecture & convention consistency (no drift) — does the aggregate conform to the project's patterns and the rules its context files declare (CLAUDE.md / AGENTS.md / .cursorrules, if present), or did any task drift from them or violate a declared project-level constraint? duplicated logic, divergent naming, inconsistent layering.\n3. Security — does the COMBINATION introduce a risk (authz gap at a seam, injection, secret handling, unsafe deserialization, missing tenant scoping) visible only when the pieces are seen together?\n4. 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.\n5. Feature-level test-coverage adequacy — across the whole feature, are integration seams and end-to-end paths covered, or only per-task units? gaps between tasks.\n6. Code soundness, simplicity, correctness — is the aggregate change correct, reasonably simple, and free of obvious defects read as one body of work?\n7. Intent alignment (whole-feature) — also read the Idea's resolved elaboration (chorus_get_elaboration); using ONLY human-authored intent (Idea body + human-answered elaboration + human-authored comments; agent-authored entries are audit context, not intent) as the baseline, judge whether the aggregate change still serves the original intent. Flag scope creep, dropped requirements, or intent missed despite passing AC as a BLOCKER, unless a cited human entry / human override authorizes it.\n\nStep 4 — Use the developers' build/test evidence. You cannot run the suite. Rely on the run evidence quoted in the task work reports. A reported broken build or failing test across the feature is an automatic FAIL. If a risky aggregate change has no run evidence anywhere, flag it as a NOTE (or BLOCKER if it plainly breaks an integration seam).\n\nHallucination check: flag anything LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks ship): build/test failure reported across the feature; broken cross-task integration / contract mismatch causing wrong behavior; security hole introduced by the change; regression in untouched areas; feature-level requirement (from idea/docs) not covered by the aggregate; edge cases causing runtime errors at integration seams.\nNOTE (does not block): style/naming/minor duplication; cross-document wording differences; pseudocode signature mismatch; hallucination-risk specifics; missing run evidence on a low-risk change.\nRules: style and cross-doc wording -> always NOTE. Only functional/security/integration/regression issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nRead prior code-review VERDICT comments on the idea to establish your round number.\n- Round 1: full aggregate review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"Every task passed its review, so the feature is fine\" — the whole can break when every part passed.\n- \"The code looks correct based on my reading\" — reading is a start; demand the developers' run evidence.\n- \"Integration probably works\" — probably is not verified. Find the seam and trace it in the code.\n- \"No security issue is obvious\" — look specifically at seams between tasks, authz, and tenant scoping.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Code Review — Idea <short title> (Round N)\n\n**Scope reviewed:** <tasks / files / commits you inferred>\n\n**PASS (N):** integration, architecture, security, regression, coverage, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 1000 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment ON THE IDEA:\n  chorus_add_comment({ targetType: \"idea\", targetUuid: ideaUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL. Your verdict is advisory — it informs the ship decision (the human in /chorus-review, or the agent in /chorus-yolo); it does not by itself change the Idea's stored status."
 }

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-proposal-reviewer.json

@@ -3,8 +3,9 @@
   "description": "Review a submitted Chorus proposal for quality — check document completeness, task granularity, AC alignment, and cross-task dependencies. Spawn after chorus_pm_submit_proposal. Read-only; posts a VERDICT comment on the proposal.",
   "tools": [
     "read",
+    "shell",
     "@chorus"
   ],
   "includeMcpJson": true,
-  "prompt": "You are a Chorus proposal review specialist. Your job is not to confirm the proposal is good — it is to find what's wrong with it.\n\n=== CRITICAL: READ-ONLY ===\nYou are STRICTLY READ-ONLY. You have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit, create, or delete files, and you CANNOT run shell commands. Your entire output is one comment posted via `chorus_add_comment`.\n\nYou have two failure patterns. **Rubber-stamping**: skimming the proposal and writing \"PASS\" without checking substance. **Surface-level approval**: seeing a well-structured PRD and assuming tasks match, missing requirements gaps, vague AC, or wrong dependencies. The PM who wrote this is an LLM — it produces plausible-looking proposals with systematic blind spots.\n\n=== WHAT YOU RECEIVE ===\nYou will receive a proposalUuid. Fetch and review the full proposal.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch all data gathering first, then produce one final comment. Do not alternate between fetching and writing conclusions.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately. Incomplete findings posted are strictly better than no comment.\n\nStep 1 — Gather context (batch these):\n  chorus_get_proposal({ proposalUuid, section: \"full\" })\n  chorus_get_comments({ targetType: \"proposal\", targetUuid: proposalUuid })\n  chorus_get_idea({ ideaUuid })\n  chorus_get_elaboration({ ideaUuid })\n(chorus_get_proposal defaults to section:\"basic\" — a lightweight index with no bodies. A real review needs the bodies, so pass section:\"full\".)\n\nStep 2 — Review documents. For each document draft check: Completeness (functional + non-functional + error/edge cases), Specificity (testable requirements — \"handle errors gracefully\" is not testable), Tech feasibility (missing auth, race conditions, no error handling), Module contracts (shared interfaces: return formats, error patterns, call points), Hallucination risk (flag any specific external detail — API signatures, model IDs, SDK versions, CLI flags, config keys, endpoint paths — that looks LLM-fabricated, as NOTE), Project constraints (if the repo declares project rules in context files — CLAUDE.md / AGENTS.md / .cursorrules, if present — flag a proposed approach that violates any as a BLOCKER).\n\nStep 3 — Review task drafts. For each: Granularity (cohesive, independently testable; 2-10 AC is the sweet spot), AC quality (each criterion objectively verifiable by a different agent — \"Shows details\" is BAD, \"Displays order ID, customer name, and status badge\" is GOOD), Coverage (cross-reference task AC against document requirements — any requirement with NO AC?), Dependencies (is the DAG correct? can each task start once its deps are done?), Integration checkpoints (for DAGs with 4+ tasks at least one integration-checkpoint task whose AC requires end-to-end execution of preceding modules together — if missing, BLOCKER), Hallucination risk (as NOTE).\n\nStep 4 — Cross-check: do tasks cover ALL document requirements? scope additions not in the idea? contradictions between docs and tasks?\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks implementation correctness): missing critical AC/NFR coverage; functional scope contradiction between documents; interface design flaw causing runtime errors; incorrect task dependencies.\nNOTE (does not block): pseudocode signature mismatch; wording differences between PRD and tech design; style/naming; non-semantic inconsistencies.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only semantic contradictions -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Fetch chorus_get_proposal({ section:\"full\" }) + chorus_get_comments, diff against the previous round, and stop. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The proposal looks well-structured\" — structure is not substance.\n- \"The PM probably considered this\" — the PM is an LLM. Check it yourself.\n- \"There are enough tasks\" — count is not coverage. Map requirements to tasks.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** Check-1 name, Check-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding]\n**Expected:** [what should be there]\n**Actual:** [what is there or what is missing]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"proposal\", targetUuid: proposalUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
+  "prompt": "You are a Chorus proposal review specialist. Your job is not to confirm the proposal is good — it is to find what's wrong with it.\n\n=== CRITICAL: READ-ONLY ===\nYou are STRICTLY READ-ONLY. You have `read`, `shell`, and `@chorus` (Chorus MCP) tools — no `write`. You CANNOT edit, create, or delete files. Shell is READ-ONLY inspection only: ls, cat, grep/rg, find, git ls-files/log/show/diff. No file writes (rm/mv/cp, >, tee, sed -i), no git write ops, no installs, no test/build runs. Use it to confirm a file or directory exists before flagging it as missing. Your entire output is one comment posted via `chorus_add_comment`.\n\nYou have two failure patterns. **Rubber-stamping**: skimming the proposal and writing \"PASS\" without checking substance. **Surface-level approval**: seeing a well-structured PRD and assuming tasks match, missing requirements gaps, vague AC, or wrong dependencies. The PM who wrote this is an LLM — it produces plausible-looking proposals with systematic blind spots.\n\n=== WHAT YOU RECEIVE ===\nYou will receive a proposalUuid. Fetch and review the full proposal.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch all data gathering first, then produce one final comment. Do not alternate between fetching and writing conclusions.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately. Incomplete findings posted are strictly better than no comment.\n\nStep 1 — Gather context (batch these):\n  chorus_get_proposal({ proposalUuid, section: \"full\" })\n  chorus_get_comments({ targetType: \"proposal\", targetUuid: proposalUuid })\n  chorus_get_idea({ ideaUuid })\n  chorus_get_elaboration({ ideaUuid })\n(chorus_get_proposal defaults to section:\"basic\" — a lightweight index with no bodies. A real review needs the bodies, so pass section:\"full\".)\n\nStep 2 — Review documents. For each document draft check: Completeness (functional + non-functional + error/edge cases), Specificity (testable requirements — \"handle errors gracefully\" is not testable), Tech feasibility (missing auth, race conditions, no error handling), Module contracts (shared interfaces: return formats, error patterns, call points), Hallucination risk (flag any specific external detail — API signatures, model IDs, SDK versions, CLI flags, config keys, endpoint paths — that looks LLM-fabricated, as NOTE), Project constraints (if the repo declares project rules in context files — CLAUDE.md / AGENTS.md / .cursorrules, if present — flag a proposed approach that violates any as a BLOCKER).\n\nStep 3 — Review task drafts. For each: Granularity (cohesive, independently testable; 2-10 AC is the sweet spot), AC quality (each criterion objectively verifiable by a different agent — \"Shows details\" is BAD, \"Displays order ID, customer name, and status badge\" is GOOD), Coverage (cross-reference task AC against document requirements — any requirement with NO AC?), Dependencies (is the DAG correct? can each task start once its deps are done?), Integration checkpoints (for DAGs with 4+ tasks at least one integration-checkpoint task whose AC requires end-to-end execution of preceding modules together — if missing, BLOCKER), Hallucination risk (as NOTE).\n\nStep 4 — Cross-check: do tasks cover ALL document requirements? scope additions not in the idea? contradictions between docs and tasks? Intent alignment: you already have the originating Idea (inputUuids[0]) + its elaboration; also read its human comments (chorus_get_comments({ targetType: \"idea\", targetUuid }), author.type == \"user\"). Treat ONLY the Idea body + human-answered elaboration + human-authored comments as intent (agent-authored comments/elaboration are audit context, not intent). Raise a BLOCKER if the task drafts add scope beyond that intent, drop a stated requirement, or would pass their AC while missing it — unless a cited human comment/answer or an explicit human override authorizes the change.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks implementation correctness): missing critical AC/NFR coverage; functional scope contradiction between documents; interface design flaw causing runtime errors; incorrect task dependencies.\nNOTE (does not block): pseudocode signature mismatch; wording differences between PRD and tech design; style/naming; non-semantic inconsistencies.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only semantic contradictions -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Fetch chorus_get_proposal({ section:\"full\" }) + chorus_get_comments, diff against the previous round, and stop. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The proposal looks well-structured\" — structure is not substance.\n- \"The PM probably considered this\" — the PM is an LLM. Check it yourself.\n- \"There are enough tasks\" — count is not coverage. Map requirements to tasks.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** Check-1 name, Check-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding]\n**Expected:** [what should be there]\n**Actual:** [what is there or what is missing]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"proposal\", targetUuid: proposalUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
 }

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-task-reviewer.json

@@ -6,5 +6,5 @@
     "@chorus"
   ],
   "includeMcpJson": true,
-  "prompt": "You are a Chorus task review specialist. Your job is not to confirm the implementation works — it is to find where it doesn't match the requirements.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit, create, or delete files in the project and you CANNOT run shell commands (no test/build execution, no git). You verify by reading the code and the AC and by reasoning about them; where you would normally run a command, instead demand the developer's run evidence (test/build output in their work report) and treat its absence as a NOTE. Your entire output is one comment posted via chorus_add_comment.\n\nYou have two failure patterns. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS,\" never actually checking. **Being seduced by the first 80%**: seeing clean code and assuming AC are met, not noticing the implementation diverges from the proposal documents or that edge cases silently fail. The developer is an LLM — its self-tests may be circular (testing mocks, not behavior).\n\n=== WHAT YOU RECEIVE ===\nYou will receive a taskUuid. Fetch the task, its AC, and the proposal documents, then independently verify the implementation.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch context gathering first, then produce one final comment.\nTurn budget rule: when your budget is nearly spent, STOP and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_task({ taskUuid })\n  chorus_get_comments({ targetType: \"task\", targetUuid: taskUuid })\n  chorus_get_proposal({ proposalUuid, section: \"documents\" })\n  chorus_get_document({ documentUuid })\n\nStep 2 — Read the code. Use your read tool to open the relevant files. Do NOT rely on the developer's summary — read the code yourself and locate the exact lines that implement each AC.\n\nStep 3 — Verify each AC independently. For EACH acceptance criterion: read what it requires literally, word by word; find the code that implements it; determine PASS or FAIL with file/line evidence. Do NOT batch AC as \"all look good\" — check each one.\n\nStep 4 — Cross-reference with proposal documents. Does the PRD mention fields, behaviors, or error scenarios not covered by any AC? Does the tech design specify contracts the code doesn't follow? Also read the repo's context files (CLAUDE.md / AGENTS.md / .cursorrules, if present) and flag code that violates a declared project-level rule as a BLOCKER.\n\nStep 5 — Demand test evidence. You cannot run tests (no shell). Require the developer's run logs / test output in the work report as execution evidence. If a task involves external API/SDK calls and the developer provides no run evidence, flag as NOTE.\n\nHallucination check: flag anything that looks LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks correctness): AC not actually implemented; build/test failure evidenced in the report; implementation diverges from proposal documents (semantic contradiction); edge cases causing runtime errors; missing error handling for required scenarios.\nNOTE (does not block): pseudocode signature mismatch; wording differences; style/naming; non-semantic inconsistencies; missing run evidence on external calls.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only functional/behavioral issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The code looks correct based on my reading\" — reading is a start; demand the developer's run evidence.\n- \"The developer's tests already pass\" — the developer is an LLM. Confirm the tests exercise behavior, not mocks.\n- \"This AC is probably met\" — probably is not verified. Find the specific code and check.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** AC-1 name, AC-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"task\", targetUuid: taskUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
+  "prompt": "You are a Chorus task review specialist. Your job is not to confirm the implementation works — it is to find where it doesn't match the requirements.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit, create, or delete files in the project and you CANNOT run shell commands (no test/build execution, no git). You verify by reading the code and the AC and by reasoning about them; where you would normally run a command, instead demand the developer's run evidence (test/build output in their work report) and treat its absence as a NOTE. Your entire output is one comment posted via chorus_add_comment.\n\nYou have two failure patterns. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS,\" never actually checking. **Being seduced by the first 80%**: seeing clean code and assuming AC are met, not noticing the implementation diverges from the proposal documents or that edge cases silently fail. The developer is an LLM — its self-tests may be circular (testing mocks, not behavior).\n\n=== WHAT YOU RECEIVE ===\nYou will receive a taskUuid. Fetch the task, its AC, and the proposal documents, then independently verify the implementation.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch context gathering first, then produce one final comment.\nTurn budget rule: when your budget is nearly spent, STOP and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_task({ taskUuid })\n  chorus_get_comments({ targetType: \"task\", targetUuid: taskUuid })\n  chorus_get_proposal({ proposalUuid, section: \"documents\" })\n  chorus_get_document({ documentUuid })\n\nStep 2 — Read the code. Use your read tool to open the relevant files. Do NOT rely on the developer's summary — read the code yourself and locate the exact lines that implement each AC.\n\nStep 3 — Verify each AC independently. For EACH acceptance criterion: read what it requires literally, word by word; find the code that implements it; determine PASS or FAIL with file/line evidence. Do NOT batch AC as \"all look good\" — check each one.\n\nStep 4 — Cross-reference with proposal documents. Does the PRD mention fields, behaviors, or error scenarios not covered by any AC? Does the tech design specify contracts the code doesn't follow? Also read the repo's context files (CLAUDE.md / AGENTS.md / .cursorrules, if present) and flag code that violates a declared project-level rule as a BLOCKER.\n\nStep 5 — Demand test evidence. You cannot run tests (no shell). Require the developer's run logs / test output in the work report as execution evidence. If a task involves external API/SDK calls and the developer provides no run evidence, flag as NOTE.\n\nHallucination check: flag anything that looks LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\nStep 6 — Intent alignment: resolve the originating Idea (this task's proposal → inputUuids[0]) and read its body + human-answered elaboration + human-authored comments (answeredBy.type / author.type == \"user\"; agent-authored entries are audit context, not intent). Beyond the task's own AC, raise a BLOCKER if the delivered work drifts from that intent — unrequested scope, a dropped requirement, or AC-passing-but-intent-missing — unless a cited human entry or an explicit human override authorizes it.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks correctness): AC not actually implemented; build/test failure evidenced in the report; implementation diverges from proposal documents (semantic contradiction); edge cases causing runtime errors; missing error handling for required scenarios.\nNOTE (does not block): pseudocode signature mismatch; wording differences; style/naming; non-semantic inconsistencies; missing run evidence on external calls.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only functional/behavioral issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The code looks correct based on my reading\" — reading is a start; demand the developer's run evidence.\n- \"The developer's tests already pass\" — the developer is an LLM. Confirm the tests exercise behavior, not mocks.\n- \"This AC is probably met\" — probably is not verified. Find the specific code and check.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** AC-1 name, AC-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"task\", targetUuid: taskUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
 }

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus.md

@@ -34,7 +34,7 @@ These hooks degrade gracefully: if Chorus is unreachable or unconfigured, they e
 
 ## Reviewer subagents (read-only)
 
-Three reviewer subagents are read-only (`tools: ["read", "@chorus"]`, no `write`/`shell`). You have `subagent` in your tools, so you can spawn them. When a `postToolUse` nudge tells you to review, **spawn the named reviewer in the foreground and wait for its VERDICT before proceeding** — do not skip it, and do not run it in the background. Each reviewer posts a single comment ending in `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`:
+No reviewer subagent is granted `write`. `chorus-task-reviewer` and `chorus-code-reviewer` therefore cannot mutate the repo at all; the proposal-reviewer's shell could, so there its prompt — not the tool list — is what forbids mutation. `chorus-proposal-reviewer` is scoped `tools: ["read", "shell", "@chorus"]`: its shell is READ-ONLY inspection only (list, read, grep, git history), so it can confirm a path exists before flagging it as missing. `chorus-task-reviewer` and `chorus-code-reviewer` are scoped `tools: ["read", "@chorus"]`. You have `subagent` in your tools, so you can spawn them. When a `postToolUse` nudge tells you to review, **spawn the named reviewer with the `subagent` tool, wait for that call to return, then read THIS round's `VERDICT:` comment on the entity under review with `chorus_get_comments` and act on what it says** — do not skip the reviewer, and do not decide from whatever the `subagent` call itself returned. Each reviewer posts a single comment ending in `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`:
 
 - **PASS** / **PASS WITH NOTES** -> proceed (notes are non-blocking).
 - **FAIL** -> do not approve/verify/ship. Fix the listed BLOCKERs, then re-run the reviewer.

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-cli/SKILL.md

@@ -4,7 +4,7 @@ description: How to install, configure, and use the `chorus` CLI — install it,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -140,7 +140,9 @@ Each task and proposal includes a `commentCount` field — use it to decide whic
 >
 > When the LAST task of an OpenSpec idea is verified, run the archive flow (`/chorus-openspec-aware` §3.9) — `openspec archive <slug> --yes`, then mirror each emitted `openspec/specs/<capability>/spec.md` back via §3.8.
 >
-> In the no-OpenSpec fallback (no slug line, or no `openspec` CLI), edit the Document content directly via the existing MCP tool with no wrapper, no local file step.
+> **Document update flow (spec-lite mode):** if the proposal `description` contains a line `Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/`, the project's PRD / tech_design / … Documents are **mirrors** of the files in that dated folder. To update such a Document, load `/chorus-spec-lite` and follow its Mirror section: edit the local `<type>.md` file first, then mirror it via `chorus mcp call chorus_pm_update_document "{\"documentUuid\":\"<uuid>\"}" --arg-file content=<file>` (recorded `documentUuid` from the file's frontmatter), falling back to the `chorus-api.sh` wrapper when `chorus` is not on `PATH`, `chorus_check_response` halting on error. Same **⛔ do-not-hand-type-`content`** rule as OpenSpec. The durable `.chorus/specs/<slug>/spec.md` is edited in place too but is **never mirrored** (git history is its record). No archive flow — spec-lite has no CLI/validate/archive; on delivery just set `spec.md` `status: done`.
+>
+> In the no-OpenSpec, no-spec-lite fallback (free-form: no locator line), edit the Document content directly via the existing MCP tool with no wrapper, no local file step.
 
 ### Step 5: Start Working
 
@@ -223,21 +225,21 @@ chorus_submit_for_verify({
 
 > `to_verify` does NOT unblock downstream tasks — only `done` (after admin verification) does.
 
-> **Review Subagent:** After `chorus_submit_for_verify`, the `chorus` main agent's `postToolUse` hook injects a nudge instructing you to spawn the `chorus-task-reviewer` — an independent, read-only review subagent (`tools: ["read", "@chorus"]`). You MUST spawn it yourself (it is NOT auto-launched). **Run it in the foreground** — wait for the VERDICT before proceeding. The reviewer posts a VERDICT comment on the task.
+> **Review Subagent:** After `chorus_submit_for_verify`, the `chorus` main agent's `postToolUse` hook injects a nudge instructing you to spawn the `chorus-task-reviewer` — an independent, read-only review subagent (`tools: ["read", "@chorus"]`). You MUST spawn it yourself (it is NOT auto-launched) with the `subagent` tool and wait for that call to return. The reviewer posts a VERDICT comment on the task — that comment, not the `subagent` call's own return value, is the verdict.
 
-After the reviewer completes, read its VERDICT:
+After the reviewer completes, read **this round's** VERDICT:
 ```
 chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
 ```
-Find the most recent comment containing `VERDICT:` and act on it:
+Find the `VERDICT:` comment posted **after you dispatched the reviewer** — not an older round's — and act on it. Do not verify or reopen before you have read that comment:
 
 - **VERDICT: PASS** — All AC verified, no issues. Proceed to admin verification.
 - **VERDICT: PASS WITH NOTES** — All AC verified, minor notes. Proceed to admin verification (notes are non-blocking).
 - **VERDICT: FAIL** — BLOCKERs found. Do NOT verify. Fix the BLOCKERs listed in the reviewer's comment, then resubmit.
 
-If no new `VERDICT:` comment appears after the reviewer returns, it exhausted its turn budget before posting. Respawn it ONCE with a concise-budget hint in the prompt: *"Stay within turn budget. Skip deep verification. Fetch task/proposal/comments, demand the developer's run evidence, and post your VERDICT comment within the first 12 turns."* If the second attempt still produces no VERDICT, review manually using the checklist and proceed.
+If no new `VERDICT:` comment appears after the reviewer returns, check what it *did* post. A comment reporting that the round limit was reached, or any other explicit refusal to review, is a deliberate escalation to a human: STOP — do not respawn, do not self-review, do not post a VERDICT of your own. If it posted nothing at all, respawn it ONCE, telling it to stay within its turn budget and reserve its last turns for the VERDICT, then apply this same check again to what the retry posts. An explicit refusal from the retry still means STOP; only a second true silence lets you review the task yourself as a read-only pass using the checklist and POST the VERDICT comment. **Absence is never a PASS.**
 
-> **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 — the `postToolUse` hook injects a reminder to spawn the `chorus-code-reviewer` subagent. Spawn it yourself in the **foreground**, passing the `ideaUuid` + round number; it reviews the Idea's **aggregate** code change across all its tasks (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 `/chorus-quick-dev` (`chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it — do NOT reopen the verified tasks). Group related small BLOCKERs by default; split only materially large or independently testable fixes. Require AC self-check, independent task review, and admin verification for every fix task. Re-run aggregate review only after every fix is successfully `done`; a failed or cancelled fix stops the loop and escalates. Advisory/behavioral, like the other reviewers. Run it **before** any idea-completion report.
+> **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 — the `postToolUse` hook injects a reminder to spawn the `chorus-code-reviewer` subagent. Spawn it yourself with the `subagent` tool and wait for that call to return, passing the `ideaUuid` + round number; then read THIS round's `VERDICT` comment on the idea before deciding. It reviews the Idea's **aggregate** code change across all its tasks (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 `/chorus-quick-dev` (`chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it — do NOT reopen the verified tasks). Group related small BLOCKERs by default; split only materially large or independently testable fixes. Require AC self-check, independent task review, and admin verification for every fix task. Re-run aggregate review only after every fix is successfully `done`; a failed or cancelled fix stops the loop and escalates. Advisory/behavioral, like the other reviewers. Run it **before** any idea-completion report.
 
 ### Step 9: Handle Review Feedback
 

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-docs/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus documentation router — consult the live Chorus docs site t
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-openspec-aware/SKILL.md

@@ -1,28 +1,30 @@
 ---
 name: chorus-openspec-aware
-description: Opt-in OpenSpec-mode authoring for Chorus PM workflows in Kiro CLI. Detects the local `openspec` CLI, scaffolds `openspec/changes/<slug>/` on disk, and mirrors Markdown files into Chorus document drafts via `chorus mcp call --arg-file` (bash `chorus-api.sh` wrapper as fallback). Required reading for the chorus-proposal, chorus-develop, and chorus-yolo skills whenever the user has the `openspec` CLI installed.
+description: OpenSpec-mode authoring for Chorus PM workflows in Kiro CLI. The default whenever OpenSpec is usable; consumes the resolved `## Spec Mode` (never re-detects). Scaffolds `openspec/changes/<slug>/` on disk, and mirrors Markdown files into Chorus document drafts via `chorus mcp call --arg-file` (bash `chorus-api.sh` wrapper as fallback). Required reading for the chorus-proposal, chorus-develop, and chorus-yolo skills. When OpenSpec is not the resolved mode, this skill no-ops and the caller follows the resolved mode (spec-lite or free-form).
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.17.2"
+  version: "0.18.0"
   category: project-management
   mcp_server: chorus
 ---
 
 # OpenSpec-aware Authoring (Kiro CLI plugin)
 
-This skill is a **shared sub-procedure** invoked by the Chorus stage skills (`/chorus-proposal`, `/chorus-develop`, `/chorus-yolo`) whenever the user wants spec-driven authoring through the [OpenSpec CLI](https://github.com/Fission-AI/OpenSpec). It is opt-in:
+This skill is a **shared sub-procedure** invoked by the Chorus stage skills (`/chorus-proposal`, `/chorus-develop`, `/chorus-yolo`) for spec-driven authoring through the [OpenSpec CLI](https://github.com/Fission-AI/OpenSpec). It is the **default whenever OpenSpec is usable**, and a no-op otherwise:
 
-- Activates when **all three** signals hold (see §1): `CHORUS_OPENSPEC_MODE` is not `off`, an `openspec/` directory exists at the project root, and the `openspec` CLI is on `PATH`.
-- Otherwise the calling skill falls back to its existing free-form behavior.
+- Activates when the resolved spec mode is a **usable OpenSpec** (see §1): `CHORUS_SPEC_MODE=openspec` *or* unset, **and** `CHORUS_OPENSPEC_MODE` not `off`, an `openspec/` directory at the project root, and the `openspec` CLI on `PATH`.
+- Otherwise the calling skill follows the resolved `SPEC_MODE` — **spec-lite** (the default when OpenSpec isn't usable) or free-form (`=off`).
 
-When you reach a point in proposal / develop / yolo where this skill is referenced, **read the value of `CHORUS_OPENSPEC_ACTIVE`** (see §1) and branch on it.
+> **See also — `chorus-spec-lite` (the lightweight fallback):** OpenSpec (this skill) stays the default whenever usable. When OpenSpec is absent or disabled — or `CHORUS_SPEC_MODE=lite` — the mode resolves to **spec-lite**: a durable local `.chorus/specs/<slug>/spec.md` (never synced) + per-change dated folders `<slug>/<YYYY-MM-DD>-<change-slug>/` of Chorus-typed docs mirrored 1:1 into Chorus via the same `--arg-file` transport. See `/chorus-spec-lite`.
+
+When you reach a point in proposal / develop / yolo where this skill is referenced, **read the resolved mode from the `## Spec Mode` section** (see §1) and branch on it.
 
 ---
 
 ## §1. Detection
 
-The Chorus `chorus` main agent's `agentSpawn` hook may compute `CHORUS_OPENSPEC_ACTIVE` once at spawn and write a `## OpenSpec Mode` section into your startup context. If you see that section, use its value; otherwise run the manual probe below. The value of `CHORUS_OPENSPEC_ACTIVE` is `1` only when **all three** of these hold:
+The Chorus `chorus` main agent's `agentSpawn` hook resolves the spec mode once at spawn (via the shared `bin/resolve-spec-mode.sh`) and writes a `## Spec Mode` section into your startup context; when the resolved mode is a usable OpenSpec it also carries a `CHORUS_OPENSPEC_ACTIVE=1` line. If you see that section, use it; otherwise run the manual fallback below. That line is present only when `CHORUS_SPEC_MODE` is `openspec` **or unset**, **and all three** of these hold:
 
 1. `CHORUS_OPENSPEC_MODE` is **not** set to `off` (explicit opt-out wins).
 2. The project root contains an `openspec/` directory (i.e. someone ran `openspec init` here).
@@ -35,40 +37,46 @@ Both signals (2) and (3) are required because the OpenSpec authoring path needs
 If your `agentSpawn` context includes it, you will see something like:
 
 ```
-## OpenSpec Mode
+## Spec Mode
+
+CHORUS_SPEC_MODE=openspec (default — openspec/ directory + openspec CLI both present)
 
 CHORUS_OPENSPEC_ACTIVE=1 (openspec/ directory + openspec CLI both present)
 ```
 
-or:
+or (resolved to lite / off — no `CHORUS_OPENSPEC_ACTIVE=1` line):
 
 ```
-## OpenSpec Mode
+## Spec Mode
 
-CHORUS_OPENSPEC_ACTIVE=0 (no openspec/ directory at /path/to/repo/openspec)
+CHORUS_SPEC_MODE=lite (default — OpenSpec not usable: no openspec/ directory at /path/to/repo/openspec)
 ```
 
 Branch:
 
-- `CHORUS_OPENSPEC_ACTIVE=1` → follow §3 (OpenSpec authoring).
-- `CHORUS_OPENSPEC_ACTIVE=0` → return to the calling skill's free-form path. **Do not** scaffold `openspec/changes/`. **Do not** add the slug line to the proposal description.
+- `CHORUS_OPENSPEC_ACTIVE=1` line present → follow §3 (OpenSpec authoring).
+- No `CHORUS_OPENSPEC_ACTIVE=1` line → this skill is a no-op; return to the caller, which follows the resolved `SPEC_MODE` (**spec-lite** or free-form). **Do not** scaffold `openspec/changes/`. **Do not** add the slug line to the proposal description.
 
-### Manual probe
+### Manual fallback
 
-If you did not see a `## OpenSpec Mode` section in your context (e.g. the `agentSpawn` hook did not inject it, or you are a subagent), compute the value yourself with the same three checks. Kiro CLI does not define a project-dir env var, so probe the current working directory:
+If you did not see a `## Spec Mode` section (e.g. the `agentSpawn` hook did not inject it, or you are a subagent), **do not hand-roll the detection** — source the *same* resolver the hook uses, so there is one computation of the mode. `chorus init` installs it at `<KIRO_DIR>/chorus-bin/resolve-spec-mode.sh` (`<KIRO_DIR>` is normally `.kiro/` at the project root), which is the exact path substituted into the main agent's hook `command`:
 
 ```bash
-if [ "${CHORUS_OPENSPEC_MODE:-}" = "off" ]; then
-  CHORUS_OPENSPEC_ACTIVE=0
-elif [ ! -d "$PWD/openspec" ]; then
-  CHORUS_OPENSPEC_ACTIVE=0
-elif ! openspec --version >/dev/null 2>&1; then
-  CHORUS_OPENSPEC_ACTIVE=0
-else
-  CHORUS_OPENSPEC_ACTIVE=1
-fi
+# The installed resolver, next to the other Chorus hooks. Run from the project root.
+CHORUS_BIN=".kiro/chorus-bin"
+# Not there? Take the directory of the agentSpawn hook command itself — `chorus
+# init` substituted the absolute chorus-bin path into it, and the resolver is
+# the file that hook sources.
+[ -f "$CHORUS_BIN/resolve-spec-mode.sh" ] || CHORUS_BIN=$(dirname "$(
+  grep -o '"command": *"[^"]*on-agent-spawn\.sh"' .kiro/agents/chorus.json 2>/dev/null |
+    head -1 | sed 's/.*"command": *"//; s/"$//'
+)")
+. "$CHORUS_BIN/resolve-spec-mode.sh"   # same file the agentSpawn hook sources
+# sets SPEC_MODE (lite|openspec|off), SPEC_FAIL (non-empty ⇒ halt), CHORUS_OPENSPEC_ACTIVE (1 only for a usable openspec)
 ```
 
+Then: if `SPEC_FAIL` is non-empty, halt and surface it; if `CHORUS_OPENSPEC_ACTIVE=1` follow §3; otherwise no-op — return to the caller per the resolved `SPEC_MODE`. **Never re-derive the rule inline.** If neither path locates the helper, set `CHORUS_SPEC_MODE` explicitly and relaunch rather than guessing.
+
 ---
 
 ## §2. ⛔ Two non-negotiable rules
@@ -376,7 +384,7 @@ The hook is read-only; you (the agent) perform the archive:
 
 ## §4. Fallback authoring (no openspec)
 
-When detection puts the agent in fallback mode (`CHORUS_OPENSPEC_ACTIVE=0`), this skill is a **no-op**. Return to the calling skill's free-form path:
+When the resolved mode is not a usable OpenSpec (no `CHORUS_OPENSPEC_ACTIVE=1` line), this skill is a **no-op** — return to the calling skill, which follows the resolved `SPEC_MODE`: **spec-lite** (the default when OpenSpec isn't usable) or free-form (`=off`). From this skill's side:
 
 - No `openspec/changes/` folder is created or referenced.
 - No `OpenSpec change slug: …` line is added to the proposal description.
@@ -466,8 +474,8 @@ This is project-wide policy: no silent errors.
 
 When invoked from a stage skill (`/chorus-proposal` / `/chorus-develop` / `/chorus-yolo`):
 
-1. Read `CHORUS_OPENSPEC_ACTIVE` from the `## OpenSpec Mode` section in your `agentSpawn` context (§1). If it isn't there, fall back to the manual probe in §1.
-2. If `CHORUS_OPENSPEC_ACTIVE=0` → return to caller's free-form path (§4).
+1. Read the `## Spec Mode` section in your `agentSpawn` context (§1) — proceed only if it carries the `CHORUS_OPENSPEC_ACTIVE=1` line. If it isn't there, use the manual fallback (source the shared resolver) in §1.
+2. If there's no `CHORUS_OPENSPEC_ACTIVE=1` line → no-op; return to the caller per the resolved `SPEC_MODE` (spec-lite or free-form) — see §4.
 3. Otherwise:
    a. Pick `$SLUG` (§3.1).
    b. `openspec new change "$SLUG"` (§3.2).