@chorus-aidlc/chorus 0.6.7 → 0.7.0

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

@@ -2,7 +2,7 @@
 description: "Review submitted Chorus tasks — verify implementation against AC and proposal documents. Spawn after chorus_submit_for_verify."
 model: inherit
 color: red
-maxTurns: 20
+maxTurns: 25
 disallowedTools:
   - Agent
   - ExitPlanMode
@@ -16,6 +16,7 @@ criticalSystemReminder_EXPERIMENTAL: >
   Classify every finding as BLOCKER (blocks correctness: build/test failure, AC not implemented, semantic contradiction) or NOTE (non-blocking: pseudocode mismatch, wording difference, style suggestion).
   You MUST end with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL. Has BLOCKERs → FAIL. Only NOTEs → PASS WITH NOTES. Nothing → PASS.
   If this is Round 2+, focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs.
+  Turn budget rule: When ≤3 turns remain in your budget, STOP reading files AND stop running bash/tests immediately and post your current findings as a comment via chorus_add_comment. Incomplete findings posted are strictly better than no comment at all.
   Do NOT confirm — find what's wrong. Be efficient: batch data gathering, then one final comment.
 ---
 
@@ -50,6 +51,8 @@ You will receive a taskUuid. Your job is to fetch the task, its AC, and the prop
 
 **Efficiency rule:** Gather ALL context in Steps 1-2 before verifying. Batch your tool calls — do not alternate between fetching and writing conclusions.
 
+**Turn budget rule:** When ≤3 turns remain in your budget, STOP reading files AND stop running bash/tests immediately and post your current findings as a comment via chorus_add_comment. Incomplete findings posted are strictly better than no comment at all.
+
 **Step 1: Gather context**
 ```
 chorus_get_task({ taskUuid: "<uuid>" })
@@ -111,7 +114,7 @@ VERDICT decision: has BLOCKERs → FAIL. Only NOTEs → PASS WITH NOTES. Nothing
 
 You may receive the current review round number in your context.
 - **Round 1**: Full review, normal strictness.
-- **Round 2+**: Focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged in previous rounds. If all previous BLOCKERs are resolved, VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain).
+- **Round 2+**: Focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged in previous rounds. If all previous BLOCKERs are resolved, VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Round 1 already did the full-depth review. Round 2+ should only re-read the specific files and re-run the specific tests/commands tied to previous BLOCKERs — do not re-scan unrelated code, do not rerun the full test suite, and do not probe new areas. Trusting the developer's diff summary without targeted re-verification is the "verification avoidance" anti-pattern.
 
 === RECOGNIZE YOUR OWN RATIONALIZATIONS ===
 - "The code looks correct based on my reading" — reading is not verification. Run it.

package/.next/standalone/public/chorus-plugin/bin/on-session-start.sh

@@ -46,10 +46,17 @@ if command -v jq >/dev/null 2>&1; then
     "$API" state-set "owner_uuid" "$_OWNER_UUID"
   fi
 
-  # Cache agent roles for TaskCompleted and Stop hooks (e.g. "developer_agent,pm_agent,admin_agent")
-  _ROLES=$(echo "$CHECKIN_RESULT" | jq -r '.agent.roles | join(",") // empty' 2>/dev/null) || true
-  if [ -n "$_ROLES" ]; then
-    "$API" state-set "agent_roles" "$_ROLES"
+  # Cache effective permissions for downstream hooks.
+  # Stored as comma-separated "resource:action" pairs so hooks can substring-match
+  # without re-parsing JSON. Example: "idea:read,idea:write,task:read,task:write,task:admin".
+  _PERMS=$(echo "$CHECKIN_RESULT" | jq -r '
+    .agent.permissions // {}
+    | to_entries
+    | map(.key as $r | .value[] | "\($r):\(.)")
+    | join(",")
+  ' 2>/dev/null) || true
+  if [ -n "$_PERMS" ]; then
+    "$API" state-set "agent_permissions" "$_PERMS"
   fi
 
 fi

package/.next/standalone/public/chorus-plugin/bin/on-subagent-start.sh

@@ -236,7 +236,7 @@ When you finish and return your summary, you MUST end it with:
 Next steps for main agent:
 1. REVIEW — spawn chorus:task-reviewer agent, then read its VERDICT comment
 2. ACT ON VERDICT: PASS/PASS WITH NOTES → mark AC passed + verify task. FAIL → reopen task and fix BLOCKERs.
-3. If no admin_agent role, stop and ask the user to review and verify this task
+3. If you do not have the task:admin permission, stop and ask the user to review and verify this task
 \`\`\`
 This ensures the main agent knows to run review and verification.
 

package/.next/standalone/public/chorus-plugin/bin/on-subagent-stop.sh

@@ -107,13 +107,13 @@ if [ "$CLOSE_OK" = true ] && [ -n "$SESSION_DETAIL" ]; then
       TASK_STATUS=$(echo "$TASK_DETAIL" | jq -r '.status // empty' 2>/dev/null) || true
 
       if [ "$TASK_STATUS" = "to_verify" ]; then
-        AGENT_ROLES=$("$API" state-get "agent_roles" 2>/dev/null) || true
-        IS_ADMIN="false"
-        case ",$AGENT_ROLES," in
-          *,admin_agent,*) IS_ADMIN="true" ;;
+        AGENT_PERMS=$("$API" state-get "agent_permissions" 2>/dev/null) || true
+        CAN_VERIFY_TASK="false"
+        case ",$AGENT_PERMS," in
+          *,task:admin,*) CAN_VERIFY_TASK="true" ;;
         esac
 
-        if [ "$IS_ADMIN" = "true" ]; then
+        if [ "$CAN_VERIFY_TASK" = "true" ]; then
           AC_TOTAL=$(echo "$TASK_DETAIL" | jq -r '.acceptanceSummary.required // 0' 2>/dev/null) || true
           ADMIN_PASSED=$(echo "$TASK_DETAIL" | jq -r '.acceptanceSummary.requiredPassed // 0' 2>/dev/null) || true
 

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

@@ -4,7 +4,7 @@ description: Chorus AI Agent collaboration platform — overview, common tools,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.7.4"
+  version: "0.8.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -35,10 +35,26 @@ creates  analyzes     drafts PRD         codes &      reviews   closes
 
 | Role | Responsibility | MCP Tools |
 |------|---------------|-----------|
-| **PM Agent** | Analyze Ideas, create Proposals (PRD + Task drafts), manage documents | Public + `chorus_pm_*` + `chorus_*_idea` |
+| **PM Agent** | Analyze Ideas, create Proposals (PRD + Task drafts), manage documents | Public + `chorus_pm_*` + `chorus_*_idea` + `task:write` tools (claim/release/submit/report) |
 | **Developer Agent** | Claim Tasks, write code, report work, submit for verification | Public + `chorus_*_task` + `chorus_report_work` |
 | **Admin Agent** | Create projects/ideas, approve/reject proposals, verify tasks, manage lifecycle | Public + `chorus_admin_*` + PM + Developer tools |
 
+### Permissions
+
+Each agent's tool visibility is driven by a **permission set**, not by the role label alone. Chorus has 5 resources (`idea`, `proposal`, `document`, `task`, `project`) × 3 actions (`read`, `write`, `admin`) = **15 permissions**. Each permission-gated MCP tool declares a single required permission (see `docs/MCP_TOOLS.md` for the full table).
+
+**Role presets** map to permission sets:
+
+| Preset | Permissions |
+|--------|-------------|
+| `developer_agent` | all `*:read` + `task:write` |
+| `pm_agent` | all `*:read` + `idea:write` + `proposal:write` + `document:write` + `task:write` + `project:write` |
+| `admin_agent` | all 15 permissions (every `read` + `write` + `admin`) |
+
+**Custom permissions** are also supported: when creating an agent you can pick a preset AND/OR add individual permissions. The effective permission set is the union. Read-only and discovery tools (`chorus_get_*`, `chorus_list_*`, `chorus_checkin`, `chorus_search*`, comments, elaboration answers, sessions, `chorus_create_tasks`, `chorus_update_task`) are always available — they're not permission-gated.
+
+> **Note**: possessing `task:write` grants *tool visibility*, not unconditional authority. Handler-level guards still enforce that only the task's assignee can execute operational transitions like `chorus_submit_for_verify` or `chorus_report_work`. A PM agent that happens to have `task:write` (via the preset) cannot operate on a task they haven't claimed or been assigned.
+
 ---
 
 ## Common Tools (All Roles)
@@ -228,11 +244,14 @@ API Keys must be created manually by the user in the Chorus Web UI.
 **Ask the user to:**
 1. Open the Chorus settings page (e.g., `http://localhost:8637/settings`)
 2. Click **Create API Key**
-3. Enter Agent name, select role (Developer / PM / Admin)
+3. Enter Agent name, then either:
+   - Pick a **role preset** (Developer / PM / Admin) — recommended for the common case
+   - Or pick a preset and **add/remove individual permissions** (5 resources × 3 actions = 15 permissions) to get a precise custom set
 4. Click create and **immediately copy the key** (shown only once)
 
 **Security notes:**
-- Each Agent should have its own API Key with the minimum required role
+- Each Agent should have its own API Key with the minimum required permissions
+- Presets are the fastest path; custom permissions let you grant narrowly (e.g. a dev agent that also needs `idea:write` to file bugs)
 - API Keys should not be committed to version control
 
 ### 2. MCP Server Configuration
@@ -263,19 +282,25 @@ chorus_checkin()
 
 If it fails, check: API Key correct (`cho_` prefix)? URL reachable? Claude Code restarted?
 
-### 4. Role-Specific Tool Access
-
-| Tool Prefix | Developer | PM | Admin |
-|-------------|-----------|------|-------|
-| `chorus_get_*` / `chorus_list_*` | Yes | Yes | Yes |
-| `chorus_checkin` | Yes | Yes | Yes |
-| `chorus_add_comment` / `chorus_get_comments` | Yes | Yes | Yes |
-| `chorus_claim_task` / `chorus_release_task` | Yes | No | Yes |
-| `chorus_update_task` / `chorus_submit_for_verify` | Yes | No | Yes |
-| `chorus_report_work` | Yes | No | Yes |
-| `chorus_claim_idea` / `chorus_release_idea` | No | Yes | Yes |
-| `chorus_pm_*` | No | Yes | Yes |
-| `chorus_admin_*` | No | No | Yes |
+### 4. Tool Access by Preset
+
+The table below shows default tool availability for each preset (no custom permissions). Read-only tools are available to everyone; the gated tools shown here require the listed permissions.
+
+| Tool Group | Required Permission | Developer | PM | Admin |
+|------------|--------------------|-----------|------|-------|
+| `chorus_get_*` / `chorus_list_*` / `chorus_search*` | (public, read) | Yes | Yes | Yes |
+| `chorus_checkin` | (public) | Yes | Yes | Yes |
+| `chorus_add_comment` / `chorus_get_comments` | (public) | Yes | Yes | Yes |
+| `chorus_update_task` (field edits + status) | (public; assignee required for status) | Yes | Yes | Yes |
+| `chorus_claim_task` / `chorus_release_task` / `chorus_submit_for_verify` / `chorus_report_work` / `chorus_report_criteria_self_check` | `task:write` | Yes | **Yes** (0.7.0+) | Yes |
+| `chorus_claim_idea` / `chorus_release_idea` / `chorus_move_idea` / `chorus_pm_create_idea` / `chorus_pm_*_elaboration` | `idea:write` | No | Yes | Yes |
+| `chorus_pm_create_proposal` / `chorus_pm_*_proposal` / `chorus_pm_*_draft` / `chorus_pm_create_tasks` / `chorus_pm_assign_task` / `chorus_*_task_dependency` | `proposal:write` | No | Yes | Yes |
+| `chorus_pm_create_document` / `chorus_pm_update_document` | `document:write` | No | Yes | Yes |
+| `chorus_admin_create_project` / `chorus_admin_*_project_group` / `chorus_admin_move_project_to_group` | `project:write` | No | **Yes** (0.7.0+) | Yes |
+| `chorus_admin_approve_proposal` / `chorus_admin_close_proposal` | `proposal:admin` | No | No | Yes |
+| `chorus_admin_verify_task` / `chorus_admin_reopen_task` / `chorus_admin_close_task` / `chorus_mark_acceptance_criteria` / `chorus_admin_delete_task` | `task:admin` | No | No | Yes |
+| `chorus_admin_delete_idea` | `idea:admin` | No | No | Yes |
+| `chorus_admin_delete_document` | `document:admin` | No | No | Yes |
 
 ### 5. Review Agent Configuration
 
@@ -367,7 +392,7 @@ This is the core overview skill. For stage-specific workflows, use:
 
 1. Call `chorus_checkin()` to learn your role and assignments
 2. Based on your role, use the appropriate skill:
-   - **Full Auto** → `/yolo` — give a prompt, agent handles everything (requires all 3 roles: admin + pm + developer)
+   - **Full Auto** → `/yolo` — give a prompt, agent handles everything (requires Admin-preset permissions: write on every resource + approve/verify admin bits)
    - PM Agent → `/idea` then `/proposal`
    - Developer Agent → `/develop`
    - Admin Agent → `/review` (also has access to all PM and Developer tools)

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

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, manage se
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.7.4"
+  version: "0.8.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -226,6 +226,8 @@ Find the most recent comment containing `VERDICT:` and act on it:
 - **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 `maxTurns` 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, run only the core tests, 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.
+
 ### Step 9: Handle Review Feedback
 
 If the reviewer returns **FAIL**, or the task is reopened after verification:

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

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

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

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.7.4"
+  version: "0.8.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -266,7 +266,7 @@ chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uu
 ```
 
 - Task must be `open` or `assigned`
-- Target agent must have `developer` or `developer_agent` role
+- Target agent must have `task: ["write"]` permission
 
 ---
 

package/.next/standalone/public/chorus-plugin/skills/quick-dev/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: quick-dev
-version: 0.7.4
+version: 0.8.0
 description: Quick Task workflow — skip Idea→Proposal, create tasks directly, execute, and verify.
 ---
 
@@ -37,7 +37,7 @@ For complex work, use `/idea` + `/proposal` instead.
 
 ## Pre-Flight: Admin Self-Verify Check
 
-**Before creating tasks**, if you have the `admin_agent` role, ask the user:
+**Before creating tasks**, if `chorus_checkin().agent.permissions.task` includes `"admin"`, ask the user:
 
 > "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
 
@@ -149,7 +149,7 @@ chorus_submit_for_verify({
 })
 ```
 
-**Admin self-verification:** If you have the `admin_agent` role and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
+**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:
 
 ```
 chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

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.7.4"
+  version: "0.8.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -69,8 +69,9 @@ When reviewing proposals or tasks, prefer spawning an independent reviewer sub-a
    - **VERDICT: PASS** — No issues found. Approve (proposals) or mark AC passed and verify (tasks).
    - **VERDICT: PASS WITH NOTES** — Minor non-blocking notes. Still approve/verify. Notes are informational.
    - **VERDICT: FAIL** — BLOCKERs found. Reject (proposals) or reopen (tasks). Fix the specific BLOCKERs listed in the comment before resubmitting.
-3. **Track rounds.** Count existing VERDICT comments before spawning. After 3 rounds of FAIL on the same item, stop the loop and escalate to human review.
-4. **Fallback.** If the reviewer is unavailable (e.g., agent type not registered, sub-agent spawn fails), review the item yourself using the quality checklists in the workflows below.
+3. **No new VERDICT comment?** The reviewer exhausted its `maxTurns` budget before posting. Respawn it ONCE with an explicit prompt like: *"Stay within your turn budget. Skip deep source verification — batch all MCP fetches up front, skim for obvious BLOCKERs only, and reserve your last few turns to post the VERDICT comment."* If the second attempt also fails to post, review manually using the checklists below.
+4. **Track rounds.** Count existing VERDICT comments before spawning. After 3 rounds of FAIL on the same item, stop the loop and escalate to human review.
+5. **Fallback.** If the reviewer is unavailable (e.g., agent type not registered, sub-agent spawn fails), review the item yourself using the quality checklists in the workflows below.
 
 ---
 

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.7.4"
+  version: "0.8.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -53,28 +53,25 @@ Full-auto AI-DLC pipeline. User provides a prompt; agent drives the entire lifec
 
 ## Prerequisites
 
-**All 3 agent roles are required on the API key:**
+The API key needs write + admin on every resource it touches:
 
-| Role | Why |
+| Needs | Why |
 |------|-----|
-| `pm_agent` | Idea creation, elaboration, proposal management (`chorus_pm_*` tools) |
-| `admin_agent` | Proposal approval, task verification (`chorus_admin_*` tools) |
-| `developer_agent` | Sub-agents claim and execute tasks (`chorus_claim_task`, `chorus_update_task`) |
-
-Sub-agents share the same API key as the main agent. The plugin injects session info into sub-agents, but **roles come from the API key itself**, not from hook injection.
+| `idea: [write]` | Create ideas, run elaboration |
+| `proposal: [write, admin]` | Create proposals; approve them |
+| `task: [write, admin]` | Create, execute, verify tasks |
+| `project: [write]` | Create the project if none is given |
 
 **Check at startup:**
 
 ```
-result = chorus_checkin()
-roles = result.agent.roles
-
-required = ["pm_agent", "admin_agent", "developer_agent"]
-missing = [r for r in required if r not in roles]
+perms = chorus_checkin().agent.permissions
+need = { idea: ["write"], proposal: ["write","admin"],
+         task: ["write","admin"], project: ["write"] }
 
-if missing:
-  ABORT: "Cannot run /yolo. Missing required roles: {missing}. 
-          Your API key must have all 3 roles: pm_agent, admin_agent, developer_agent."
+for resource, actions in need:
+  missing = [a for a in actions if a not in (perms[resource] or [])]
+  if missing: ABORT "/yolo needs {resource}: {missing}. Use an Admin-preset API key."
 ```
 
 ---
@@ -288,6 +285,8 @@ 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.
+
 ---
 
 ### Phase 3: Task Execution (Wave-Based)
@@ -415,6 +414,8 @@ 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.
+
 ---
 
 ### Phase 5: Report
@@ -448,7 +449,7 @@ After all waves complete, output a markdown summary:
 
 | Scenario | Action |
 |----------|--------|
-| Missing roles at startup | Abort with message listing all 3 required roles and which are missing |
+| Missing permissions at startup | Abort with message listing the missing resource/action pairs (see Prerequisites). Recommend an Admin-preset API key. |
 | Project creation fails | Report error, suggest user create project manually and retry with `--project` |
 | Proposal reviewer FAIL after maxRounds | Stop pipeline, report persisting BLOCKERs, suggest manual review |
 | Task reviewer FAIL after maxRounds | Flag task as escalation-needed, continue with other tasks |
@@ -464,7 +465,7 @@ After all waves complete, output a markdown summary:
 - Watch the wave count -- if tasks keep getting reopened, consider Ctrl+C and manually reviewing the feedback
 - All audit trail is preserved: elaboration Q&A, reviewer VERDICTs, work reports. Check Chorus UI for full history
 - For small/simple tasks, consider `/quick-dev` instead -- it skips the Idea->Proposal overhead
-- Sub-agents share your API key; ensure it has all 3 roles before starting
+- Sub-agents share your API key; ensure it has the permissions listed in Prerequisites before starting
 
 ---