@chorus-aidlc/chorus 0.14.5 → 0.14.6

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -20,7 +20,7 @@ Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) a
 The standard AI-DLC flow ensures quality through structured planning, but adds overhead that slows down small tasks. Quick Dev provides a lightweight alternative:
 
 ```
-[check admin role] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify if admin] → done
+check explicit task:admin permission → create/claim → implement → self-check AC → submit → independent task review → verify or hand off
 ```
 
 **Use Quick Dev when:**
@@ -40,13 +40,11 @@ For complex work, use `/idea` + `/proposal` instead.
 
 ---
 
-## Pre-Flight: Admin Self-Verify Check
+## Pre-Flight: Permission Check
 
-**Before creating tasks**, if `chorus_checkin().agent.permissions.task` includes `"admin"`, ask the user:
+Call `chorus_checkin` and inspect the active agent's effective permissions. Set `canVerifyTask` to true **only** when `chorus_checkin().agent.permissions.task` explicitly contains `"admin"` (the `task:admin` permission).
 
-> "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
-
-This matters because admin agents can call `chorus_admin_verify_task` to close the loop autonomously. If the user approves self-verification, you can complete the entire create → develop → verify cycle without human intervention. Record the decision and apply it in Step 7.
+Never infer verification authority from the agent's name, persona, preset/role label, task ownership, or tool availability. Do not ask whether to self-verify: the explicit permission determines the terminal path.
 
 ---
 
@@ -145,7 +143,7 @@ chorus_report_criteria_self_check({
 })
 ```
 
-### Step 7: Submit for Verification (or Self-Verify)
+### Step 7: Submit and Run Independent Review
 
 ```
 chorus_submit_for_verify({
@@ -154,13 +152,19 @@ chorus_submit_for_verify({
 })
 ```
 
-**Admin self-verification:** If you have `task: ["admin"]` in `permissions` and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
+Submitting is not final verification. Spawn the required independent task-reviewer sub-agent as described in `/develop`, wait for it, and read the newest `VERDICT:` Task comment. `PASS` and `PASS WITH NOTES` continue. On `FAIL`, do not verify or hand off: fix every unresolved BLOCKER, repeat AC self-check and submission, then run a fresh independent task review.
+
+### Step 8: Permission-Aware Verification
+
+With explicit `task:admin`, after every required AC self-check passes and independent review has no unresolved BLOCKER, verify and continue autonomously:
 
 ```
 chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
 ```
 
-This completes the full autonomous cycle: create → develop → verify → done.
+Without explicit `task:admin`, do not call the admin tool. Post an evidence-rich comment on the Task containing AC results, test evidence, the latest independent-review verdict, and the exact requested action. @mention the responsible human (prefer `chorus_checkin().agent.owner`) to perform admin verification, then end the current turn.
+
+This handoff applies in interactive and headless daemon sessions. Do not use an interactive prompt, poll for the human response, or rely only on generic notifications.
 
 ---
 
@@ -181,7 +185,7 @@ Quick Tasks work with Claude Code Agent Teams just like proposal-based tasks:
 - Use `chorus_update_task` to refine tasks (including AC) after creation rather than deleting and recreating
 - Pass `proposalUuid` to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG
 - Quick Tasks show up in the same project task list and DAG as proposal-based tasks
-- Admin agents can run the full lifecycle autonomously (create → develop → self-verify) — but always confirm with the user first
+- Agents with explicit `task:admin` continue autonomously after AC and independent review pass; all others use the evidence-rich asynchronous human handoff
 
 ---
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -220,7 +220,7 @@ Spawn `chorus:task-reviewer` per the [Review Strategy](#review-strategy) above
 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`.
+- **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). 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. 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).
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -465,7 +465,7 @@ comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" }
 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).
+- **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. Group related small BLOCKERs into one cohesive task by default; split only materially large or independently testable fixes. Drive every fix task through Phase 3 → Phase 4, including AC self-check, independent task review, and admin verification. Re-spawn the code-reviewer only after every fix task is successfully `done`; a failed or cancelled fix task, stop the automatic loop and escalate. Loop bounded by `maxCodeReviewRounds` (plugin config, default 3; 0 = unlimited).
 
 ```
 # Max rounds escalation

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.14.5"
+  version: "0.14.6"
   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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -237,7 +237,7 @@ Find the most recent comment containing `VERDICT:` and act on it:
 
 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.
 
-> **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), then re-run the gateway. 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 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.
 
 ### Step 9: Handle Review Feedback
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---

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

@@ -4,7 +4,7 @@ description: Opt-in OpenSpec-mode authoring for Chorus PM workflows in Kiro CLI.
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---

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

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -20,7 +20,7 @@ Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) a
 The standard AI-DLC flow ensures quality through structured planning, but adds overhead that slows down small tasks. Quick Dev provides a lightweight alternative:
 
 ```
-[check admin role] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify if admin] → done
+check explicit task:admin permission → create/claim → implement → self-check AC → submit → independent task review → verify or hand off
 ```
 
 **Use Quick Dev when:**
@@ -40,13 +40,11 @@ For complex work, use `/chorus-idea` + `/chorus-proposal` instead.
 
 ---
 
-## Pre-Flight: Admin Self-Verify Check
+## Pre-Flight: Permission Check
 
-**Before creating tasks**, if `chorus_checkin().agent.permissions.task` includes `"admin"`, ask the user (a clear interactive question, wait for the answer):
+Call `chorus_checkin` and inspect the active agent's effective permissions. Set `canVerifyTask` to true **only** when `chorus_checkin().agent.permissions.task` explicitly contains `"admin"` (the `task:admin` permission).
 
-> "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
-
-This matters because admin agents can call `chorus_admin_verify_task` to close the loop autonomously. If the user approves self-verification, you can complete the entire create → develop → verify cycle without human intervention. Record the decision and apply it in Step 7.
+Never infer verification authority from the agent's name, persona, preset/role label, task ownership, or tool availability. Do not ask whether to self-verify: the explicit permission determines the terminal path.
 
 ---
 
@@ -145,7 +143,7 @@ chorus_report_criteria_self_check({
 })
 ```
 
-### Step 7: Submit for Verification (or Self-Verify)
+### Step 7: Submit and Run Independent Review
 
 ```
 chorus_submit_for_verify({
@@ -154,13 +152,19 @@ chorus_submit_for_verify({
 })
 ```
 
-**Admin self-verification:** If you have `task: ["admin"]` in `permissions` and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
+Submitting is not final verification. Spawn the required native task-reviewer subagent as described in `/chorus-develop`, wait for it, and read the newest `VERDICT:` Task comment. `PASS` and `PASS WITH NOTES` continue. On `FAIL`, do not verify or hand off: fix every unresolved BLOCKER, repeat AC self-check and submission, then run a fresh independent task review.
+
+### Step 8: Permission-Aware Verification
+
+With explicit `task:admin`, after every required AC self-check passes and independent review has no unresolved BLOCKER, verify and continue autonomously:
 
 ```
 chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
 ```
 
-This completes the full autonomous cycle: create → develop → verify → done.
+Without explicit `task:admin`, do not call the admin tool. Post an evidence-rich comment on the Task containing AC results, test evidence, the latest independent-review verdict, and the exact requested action. @mention the responsible human (prefer `chorus_checkin().agent.owner`) to perform admin verification, then end the current turn.
+
+This handoff applies in interactive and headless daemon sessions. Do not use an interactive prompt, poll for the human response, or rely only on generic notifications.
 
 ---
 
@@ -181,7 +185,7 @@ Quick Tasks work with Kiro subagents just like proposal-based tasks:
 - Use `chorus_update_task` to refine tasks (including AC) after creation rather than deleting and recreating
 - Pass `proposalUuid` to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG
 - Quick Tasks show up in the same project task list and DAG as proposal-based tasks
-- Admin agents can run the full lifecycle autonomously (create → develop → self-verify) — but always confirm with the user first
+- Agents with explicit `task:admin` continue autonomously after AC and independent review pass; all others use the evidence-rich asynchronous human handoff
 
 ---
 

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -220,7 +220,7 @@ Spawn the `chorus-task-reviewer` per the [Review Strategy](#review-strategy) abo
 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 the `chorus-code-reviewer`. 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`.
+- **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). 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. 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).
 

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -465,7 +465,7 @@ comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" }
 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 (`/chorus-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` (default 3; 0 = unlimited).
+- **FAIL** — do NOT ship. Read the BLOCKERs, then fix them via the **quick-dev** workflow (`/chorus-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. Group related small BLOCKERs into one cohesive task by default; split only materially large or independently testable fixes. Drive every fix task through Phase 3 → Phase 4, including AC self-check, independent task review, and admin verification. Re-spawn the code-reviewer only after every fix task is successfully `done`; a failed or cancelled fix task, stop the automatic loop and escalate. Loop bounded by `maxCodeReviewRounds` (default 3; 0 = unlimited).
 
 ```
 # Max rounds escalation

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

@@ -217,7 +217,7 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_search` | Search across tasks, ideas, proposals, documents, projects, and project groups |
+| `chorus_search` | Search compact summaries across tasks, ideas, proposals, documents, projects, and project groups; canonical UUIDs use exact lookup |
 
 **Parameters:**
 - `query`: Search query string
@@ -225,6 +225,8 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 - `scopeUuid`: Project group UUID (when scope=group) or project UUID (when scope=project)
 - `entityTypes`: Array of entity types to search (default: all types)
 
+Prefer `chorus_search` for discovery, including exact UUID lookup. Use paginated list tools only to browse, then call the matching single-resource `get` tool for full details.
+
 ### Notifications
 
 | Tool | Purpose |

package/.next/standalone/public/kiro-plugin/bin/chorus-api.sh

@@ -240,7 +240,7 @@ cmd_mcp_tool() {
     # Step 1: Initialize MCP session
     local init_payload
     init_payload=$(cat <<JSONEOF
-{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"chorus-hook","version":"0.14.5"}}}
+{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"chorus-hook","version":"0.14.6"}}}
 JSONEOF
 )
 

package/.next/standalone/public/kiro-plugin/bin/on-post-verify-task.sh

@@ -112,7 +112,8 @@ ACTION REQUESTED: spawn the read-only \`chorus-code-reviewer\` subagent for this
 1. Spawn the code-reviewer synchronously, passing ideaUuid=\"${IDEA_UUID}\" and the review round number (read prior code-review VERDICT comments on the idea to determine it). It reviews cross-task integration, architecture/convention consistency, security, regression/performance, feature-level test coverage, and overall soundness, then posts ONE VERDICT comment on the idea.
 2. Read its VERDICT on the idea (chorus_get_comments targetType=\"idea\").
 3. VERDICT: PASS / PASS WITH NOTES — the feature may ship.
-4. VERDICT: FAIL — create new fix tasks on this approved proposal (chorus_create_tasks) targeting the BLOCKERs; do NOT reopen old tasks. When the fix tasks are done, re-run the code-reviewer (next round).
+4. VERDICT: FAIL — the orchestrator invokes Quick Dev to create new tasks on the original approved proposal; never reopen completed tasks or apply untracked fixes. Group related small BLOCKERs by default and split only materially large or independently testable fixes.
+5. Re-run only after every fix task passes AC self-check, independent task review, and admin verification to done. A failed or cancelled fix stops the loop and escalates. Keep maxCodeReviewRounds authoritative.
 
 Run this code-review gateway BEFORE writing any idea-completion report — the report must not be written while a FAIL verdict is outstanding."
 

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.14.5"
+  version: "0.14.6"
   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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -270,7 +270,7 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_search` | Search across tasks, ideas, proposals, documents, projects, and project groups |
+| `chorus_search` | Search compact summaries across tasks, ideas, proposals, documents, projects, and project groups; canonical UUIDs use exact lookup |
 
 **Parameters:**
 - `query`: Search query string
@@ -278,6 +278,8 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 - `scopeUuid`: Project group UUID (when scope=group) or project UUID (when scope=project)
 - `entityTypes`: Array of entity types to search (default: all types)
 
+Prefer `chorus_search` for discovery, including exact UUID lookup. Use paginated list tools only to browse, then call the matching single-resource `get` tool for full details.
+
 ### Notifications
 
 | Tool | Purpose |
@@ -425,7 +427,7 @@ This is the **single canonical description** of the reviewer pattern. The `devel
 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 / 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.
+   - `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 group related small BLOCKERs by default and split only materially large or independently testable fixes. Never reopen completed tasks or apply untracked fixes. Require AC self-check, independent task review, and admin verification for every fix; re-run aggregate review only after all are successfully `done`. A failed or cancelled fix stops the loop and escalates, while `maxCodeReviewRounds` remains authoritative.
 
 > 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.
 

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

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus code-review gateway — independently
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -214,7 +214,7 @@ chorus_add_comment({
 })
 ```
 
-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.
+On FAIL, remain read-only. The orchestrator, not the reviewer, invokes Quick Dev to create new fix tasks on the original approved proposal; it never reopens completed tasks or applies untracked fixes. It groups related small BLOCKERs by default and splits only materially large or independently testable work. Every fix task must pass AC self-check, independent task review, and admin verification. You are re-run only after all fix tasks are successfully `done`; a failed or cancelled fix stops the loop and escalates. The configured maximum review rounds remains authoritative.
 
 ---
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -184,7 +184,7 @@ 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.
+> **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. 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. 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
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chorus-skill",
-  "version": "0.14.5",
+  "version": "0.14.6",
   "description": "Chorus AI Agent collaboration platform skill. Supports PM, Developer, and Admin roles via MCP tools for the Idea-Proposal-Task workflow.",
   "author": "chorus",
   "license": "AGPL-3.0",

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---

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.14.5"
+  version: "0.14.6"
   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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -20,7 +20,7 @@ Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) a
 The standard AI-DLC flow ensures quality through structured planning, but adds overhead that slows down small tasks. Quick Dev provides a lightweight alternative:
 
 ```
-[check admin role] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify if admin] → done
+check explicit task:admin permission → create/claim → implement → self-check AC → submit → independent task review → verify or hand off
 ```
 
 **Use Quick Dev when:**
@@ -40,13 +40,11 @@ For complex work, consider using the idea and proposal skills instead.
 
 ---
 
-## Pre-Flight: Admin Self-Verify Check
+## Pre-Flight: Permission Check
 
-**Before creating tasks**, if `chorus_checkin().agent.permissions.task` includes `"admin"`, ask the user:
+Call `chorus_checkin` and inspect the active agent's effective permissions. Set `canVerifyTask` to true **only** when `chorus_checkin().agent.permissions.task` explicitly contains `"admin"` (the `task:admin` permission).
 
-> "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
-
-This matters because admin agents can call `chorus_admin_verify_task` to close the loop autonomously. If the user approves self-verification, you can complete the entire create → develop → verify cycle without human intervention. Record the decision and apply it in Step 7.
+Never infer verification authority from the agent's name, persona, preset/role label, task ownership, or tool availability. Do not ask whether to self-verify: the explicit permission determines the terminal path.
 
 ---
 
@@ -139,7 +137,7 @@ chorus_report_criteria_self_check({
 })
 ```
 
-### Step 7: Submit for Verification (or Self-Verify)
+### Step 7: Submit and Run Independent Review
 
 ```
 chorus_submit_for_verify({
@@ -148,13 +146,19 @@ chorus_submit_for_verify({
 })
 ```
 
-**Admin self-verification:** If you have `task: ["admin"]` in `permissions` and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
+Submitting is not final verification. Invoke the required independent task reviewer with the host agent's sub-agent mechanism, wait for it, and read the newest `VERDICT:` Task comment. `PASS` and `PASS WITH NOTES` continue. On `FAIL`, do not verify or hand off: fix every unresolved BLOCKER, repeat AC self-check and submission, then run a fresh independent task review.
+
+### Step 8: Permission-Aware Verification
+
+With explicit `task:admin`, after every required AC self-check passes and independent review has no unresolved BLOCKER, verify and continue autonomously:
 
 ```
 chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
 ```
 
-This completes the full autonomous cycle: create → develop → verify → done.
+Without explicit `task:admin`, do not call the admin tool. Post an evidence-rich comment on the Task containing AC results, test evidence, the latest independent-review verdict, and the exact requested action. @mention the responsible human (prefer `chorus_checkin().agent.owner`) to perform admin verification, then end the current turn.
+
+This handoff applies in interactive and headless daemon sessions. Do not use an interactive prompt, poll for the human response, or rely only on generic notifications.
 
 ---
 
@@ -165,7 +169,7 @@ This completes the full autonomous cycle: create → develop → verify → done
 - Use `chorus_update_task` to refine tasks (including AC) after creation rather than deleting and recreating
 - Pass `proposalUuid` to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG
 - Quick Tasks appear in the same project task list and DAG as proposal-based tasks
-- Admin agents can run the full lifecycle autonomously (create → develop → self-verify) — but always confirm with the user first
+- Agents with explicit `task:admin` continue autonomously after AC and independent review pass; all others use the evidence-rich asynchronous human handoff
 
 ---
 

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.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -210,7 +210,7 @@ The spawn mechanism is harness-specific, and an inline self-review fallback exis
 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`.
+- `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 and verify them. 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 (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.
 

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

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus task reviewer — independently verifi
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---

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

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — drive a single prompt from Idea throu
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.5"
+  version: "0.14.6"
   category: project-management
   mcp_server: chorus
 ---
@@ -471,7 +471,7 @@ Once **every** task of the idea's proposal is verified (`done`) — Phase 3 find
 Act on the verdict:
 
 - **`VERDICT: PASS` / `PASS WITH NOTES`** — the feature is cleared to ship. Proceed to Phase 5 / 5b.
-- **`VERDICT: FAIL`** — do NOT ship. Read the BLOCKERs, then fix them via 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) — do **not** reopen the already-verified tasks. Drive the fix tasks through Phase 3 → Phase 4, then re-spawn the code-reviewer for the next round. Loop bounded by `maxCodeReviewRounds` (default **3**; 0 = unlimited).
+- **`VERDICT: FAIL`** — do NOT ship. Read the BLOCKERs, then fix them via 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) — do **not** reopen the already-verified tasks. Group related small BLOCKERs into one cohesive task by default; split only materially large or independently testable fixes. Drive every fix task through Phase 3 → Phase 4, including AC self-check, independent task review, and admin verification. Re-spawn the code-reviewer only after every fix task is successfully `done`; a failed or cancelled fix task, stop the automatic loop and escalate. Loop bounded by `maxCodeReviewRounds` (default **3**; 0 = unlimited).
 
 ```
 ESCALATE: "Idea '<title>' failed code review after 3 rounds. Last BLOCKERs: <list>.