@chorus-aidlc/chorus-openclaw-plugin 0.5.0 → 0.10.0

package/package.json

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

package/skills/brainstorm/SKILL.md

@@ -4,7 +4,7 @@ description: Optional divergent-then-convergent dialogue for fuzzy ideas. Invoke
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -36,7 +36,7 @@ Only as a sub-step of the idea skill, only after the user has explicitly opted i
 5. **No files written.** Do NOT write any markdown, design doc, scratch file, or any other file to disk. The conversation produces an `ElaborationRound` and nothing else on disk.
 6. **No comments posted.** Do NOT call `chorus_add_comment` from this skill. Comments belong to the idea skill or the user, not to the brainstorm step.
 7. **No design-doc handoff.** Do NOT invoke `writing-plans`, `writing-skills`, or any skill whose purpose is to produce a design document. The brainstorm output is the synthesized round — there is no separate doc.
-8. **No `validate_elaboration` call.** Do NOT call `chorus_pm_validate_elaboration` from this skill. Whether to validate (resolve elaboration) or follow up (issues + followUpQuestions) is the calling idea skill's decision, not this skill's.
+8. **No `validate_elaboration` call.** Do NOT call `chorus_pm_validate_elaboration` from this skill. Whether to resolve the elaboration or open a follow-up round (`chorus_pm_start_elaboration` again) is the calling idea skill's decision, not this skill's.
 
 ---
 
@@ -123,8 +123,8 @@ chorus_answer_elaboration({
 
 Stop here. Do **NOT** call `chorus_pm_validate_elaboration`. The idea skill's caller now decides:
 
-- If the synthesized round answers cover everything → caller validates with `issues: []`.
-- If gaps remain → caller validates with `issues + followUpQuestions` to start a structured Round 2.
+- If the synthesized round answers cover everything → caller obtains human confirmation, then resolves with `chorus_pm_validate_elaboration`.
+- If gaps remain → caller opens a structured Round 2 with `chorus_pm_start_elaboration`.
 
 The depth of any follow-up round is the caller's call, not yours.
 
@@ -157,7 +157,7 @@ Do not do any of the following. Each has a specific failure mode that this skill
 - **Single-summary `customText` blob.** Compressing the entire conversation into one ElaborationQuestion with a long markdown summary in `customText`. The schema is multi-question for a reason — preserve the decision granularity.
 - **Transcript-as-comment.** Posting the raw conversation log as a comment on the idea (or anywhere). The synthesized round IS the artifact. Raw transcripts pollute the audit trail with noise.
 - **File writes.** Writing any markdown, design doc, plan, or scratch file to disk. There is no design doc in this flow. This is a deliberate divergence from the upstream `superpowers/brainstorming` cadence.
-- **`validate_elaboration` calls.** Closing the elaboration phase from this skill. The lifecycle decision belongs to the idea skill. Calling validate here strips the caller of its scheduler role.
+- **`validate_elaboration` calls.** Closing the elaboration phase from this skill. The lifecycle decision belongs to the idea skill. Calling it here strips the caller of its scheduler role.
 - **`writing-plans` / design-doc handoff.** Invoking any skill that produces an implementation plan or design document. The Chorus pipeline already has Proposal → Document Drafts → Task Drafts for that — the brainstorm output feeds them through ElaborationRound, not through external doc skills.
 - **Length-2 binary "yes / no" framings.** Reducing every decision to "do this thing — yes / no". Almost always the genuine alternatives are 3+ approaches with meaningfully different tradeoffs. Length-2 framings often mean the divergent phase ended too early.
 - **Asking multiple questions in one prompt.** The cadence is one question per turn during divergence, then one final convergence prompt with 2-3 options. Combining unrelated questions is a sign you are rushing.

package/skills/chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus AI Agent collaboration platform — overview, common tools,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -137,7 +137,7 @@ A **report** is a short idea-completion summary persisted as a `type="report"` D
 | Tool | Purpose |
 |------|---------|
 | `chorus_get_proposals` | List project Proposals (filterable by status: pending, approved, rejected) |
-| `chorus_get_proposal` | Get a single Proposal's details, including documentDrafts and taskDrafts |
+| `chorus_get_proposal` | Get a single Proposal, sliced by `section` (default `basic`: metadata + lightweight draft index; `documents`/`tasks`/`full` for the draft bodies) |
 
 ### Tasks
 
@@ -295,7 +295,7 @@ The table below shows default tool availability for each preset (no custom permi
 | `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_claim_idea` / `chorus_release_idea` / `chorus_move_idea` / `chorus_pm_create_idea` / `chorus_edit_idea` / `chorus_pm_*_elaboration` | `idea:write` | No | Yes | Yes |
 | `chorus_pm_create_proposal` / `chorus_pm_*_proposal` / `chorus_pm_*_draft` / `chorus_create_tasks` / `chorus_pm_assign_task` / `chorus_update_task` (dependency edits via `addDependsOn`/`removeDependsOn`) | `proposal:write` | No | Yes | Yes |
 | `chorus_pm_create_document` / `chorus_pm_update_document` / `chorus_create_report` | `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 |

package/skills/develop/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, manage se
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -137,8 +137,9 @@ Each task and proposal includes a `commentCount` field — use it to decide whic
 
 4. **Read the originating proposal** for design intent:
    ```
-   chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+   chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "documents" })
    ```
+   (`chorus_get_proposal` defaults to `section: "basic"` — just metadata + a draft index. Pass `section: "documents"` for the design docs, or `section: "full"` for docs + task drafts.)
 
 5. **Read project documents** (PRD, tech design, ADR):
    ```

package/skills/idea/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Idea workflow — claim ideas, run elaboration rounds, and p
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -37,19 +37,20 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_pm_create_idea` | Create a new idea in a project (on behalf of humans) |
+| `chorus_pm_create_idea` | Create a new idea in a project (on behalf of humans). Optional `parentUuid` derives a child idea from an existing same-project idea (single-parent lineage). |
+| `chorus_edit_idea` | Edit an existing idea's title, description, and/or lineage parent. `parentUuid`: another same-project idea to reparent under, `null` to detach to top-level, omit to leave unchanged (cycle-checked + same-project). Single-parent **weak** lineage — a parent shows a read-only `+N derived` rollup but never blocks either idea's flow. Records an "edited" activity and signals presence. |
 | `chorus_claim_idea` | Claim an open idea (open -> elaborating) |
 | `chorus_release_idea` | Release a claimed idea (elaborating -> open) |
-| `chorus_move_idea` | Move an Idea to a different Project. Cascade-migrates the Idea, all linked Proposals (any status), all materialized Documents and Tasks, and all related Activities atomically. Comments, TaskDependency, AcceptanceCriterion, AgentSession, SessionTaskCheckin, Notification history, and Task assignees are NOT modified. Returns `moved: { proposals, documents, tasks, activities }` counts. Requires `idea:write` only — no project-level checks. |
+| `chorus_move_idea` | Move an Idea to a different Project. Cascade-migrates the Idea **and its full lineage subtree** (all descendant Ideas; the moved root is detached from any parent left behind), all linked Proposals (any status), all materialized Documents and Tasks, and all related Activities atomically. Comments, TaskDependency, AcceptanceCriterion, AgentSession, SessionTaskCheckin, Notification history, and Task assignees are NOT modified. Returns `moved: { ideas, proposals, documents, tasks, activities }` counts. Requires `idea:write` only — no project-level checks. |
 
 **Requirements Elaboration:**
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_pm_start_elaboration` | Start an elaboration round with structured questions |
-| `chorus_pm_validate_elaboration` | Validate answers (resolve or create follow-up round) |
+| `chorus_pm_start_elaboration` | Generate an elaboration round (first, follow-up, or appended-after-resolution) |
+| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) |
 | `chorus_pm_skip_elaboration` | Skip elaboration for trivially clear Ideas |
-| `chorus_answer_elaboration` | Submit answers for an elaboration round |
+| `chorus_answer_elaboration` | Submit answers for an elaboration round (`roundUuid` optional — auto-locates the active round) |
 | `chorus_get_elaboration` | Get full elaboration state (rounds, questions, answers) |
 
 **Shared tools** (checkin, query, comment, search, notifications): see `/chorus`
@@ -129,8 +130,8 @@ If the Idea is fuzzy and you'd struggle to enumerate concrete multi-choice quest
 
 When `/brainstorm` returns, you own the lifecycle decision (the brainstorm skill deliberately leaves it to you):
 
-- If the synthesized round answers cover everything → call `chorus_pm_validate_elaboration` with `issues: []` to resolve elaboration.
-- If gaps remain → call `chorus_pm_validate_elaboration` with `issues + followUpQuestions` to start a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
+- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to mark the elaboration complete. (Requires `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset.)
+- If gaps remain → call `chorus_pm_start_elaboration` again to open a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
 
 Either outcome ends Step 4.5; skip Step 5.
 
@@ -151,6 +152,12 @@ chorus_pm_skip_elaboration({
 
 #### Standard/Complex Ideas (run elaboration)
 
+> **Elaboration is a loop, not a straight line.** Steps 2–5 below are **one round**. Keep looping back to `chorus_pm_start_elaboration` (a new round) until every open question is settled, then resolve **once** in Step 6. You re-enter the loop whenever:
+> - the answers to a round **derive new questions** or surface a contradiction/gap, **or**
+> - at the resolve gate (Step 5d / Step 6) the **human raises a new concern or correction** (a plain-text reply on OpenClaw).
+>
+> Each new round is just another `chorus_pm_start_elaboration` call — there is no separate "follow-up" flag, and you do not resolve until the loop is genuinely done. Round cap is 10.
+
 1. **Determine depth** based on idea complexity:
    - `"minimal"` — 2-4 questions (small features, minor enhancements)
    - `"standard"` — 5-10 questions (typical new features)
@@ -211,6 +218,8 @@ chorus_pm_skip_elaboration({
    - **Select an option + add a note**: `selectedOptionId: "a", customText: "additional context"`
    - **Free text (no option matched)**: `selectedOptionId: null, customText: "your answer"` — customText is required when no option is selected
 
+   > `roundUuid` is **optional** on `chorus_answer_elaboration`. Omit it and the service auto-locates the Idea's single active (`pending_answers`) round. Pass it explicitly only when you need to target a specific round.
+
 5. **Review answers and confirm with the owner (@mention flow):**
 
    After answers are submitted, **@mention the answerer** (typically the agent's owner) with a summary of your understanding. This prevents misinterpretation before you validate.
@@ -231,39 +240,32 @@ chorus_pm_skip_elaboration({
 
    c. **Wait for confirmation** via comments.
 
-   d. **Based on the response:**
-      - **Confirmed** — Proceed to validate with empty issues
-      - **Additions/corrections** — Incorporate feedback, optionally start a follow-up round
-      - **Unclear** — Ask clarifying questions via another comment
+   d. **Based on the response — this is the loop decision point:**
+      - **Confirmed, nothing left to discuss** — Treat this as the human confirmation required to resolve; proceed to Step 6 and call `chorus_pm_validate_elaboration`.
+      - **Human raises a new concern / correction / question** — Do **NOT** resolve. Loop back: open a **new round** with `chorus_pm_start_elaboration` capturing the new questions, collect answers (Steps 2–5 again), and re-confirm. Repeat until the human has no remaining concerns.
+      - **The answers themselves derived new questions or a contradiction** — Same as above: loop back to `chorus_pm_start_elaboration` for another round before resolving.
+      - **Unclear** — Ask clarifying questions via another comment, then continue the loop.
 
-6. **Validate the elaboration:**
+6. **Resolve the elaboration (the single commit gate — only when the loop is done):**
 
-   `chorus_pm_validate_elaboration` is the **single commit gate for the entire elaboration phase**, NOT a per-round close. Calling it with `issues: []` resolves the whole elaboration (sets `idea.elaborationStatus = "resolved"`); calling it with `issues + followUpQuestions` opens a new round while keeping elaboration in progress. Do not call validate after every round — call it once when you believe elaboration is done, or when you want to start a follow-up round.
+   Resolving marks the **whole elaboration phase** complete — it sets `idea.elaborationStatus = "resolved"` (Idea → `elaborated`), which is the gating signal that lets a downstream Proposal be submitted. It is an **Idea-level** action (takes only `ideaUuid`, does not target a round). Resolve **once**, only after the Step 5d loop has fully settled — every derived question answered and the human has no remaining concerns. If anything is still open, go back to `chorus_pm_start_elaboration` instead of resolving.
 
-   ```
-   chorus_pm_validate_elaboration({
-     ideaUuid: "<idea-uuid>",
-     roundUuid: "<round-uuid>",
-     issues: [],
-     followUpQuestions: []
-   })
-   ```
+   > **Precondition:** resolve requires the Idea to have at least one round and **every** round to be fully answered (none left in `pending_answers`). If a round still has open questions, answer it (or it'll be rejected).
+
+   > **⚠️ Human confirmation required.** Outside YOLO automation you MUST obtain explicit human confirmation before resolving (a plain-text yes/no prompt is fine on OpenClaw). The "Confirmed" reply in step 5d above counts as that confirmation. Never resolve on your own judgment alone.
+
+   > **Permission (N1): `chorus_pm_validate_elaboration` requires `idea:admin`.** The `pm_agent` preset only grants `idea:write`, so a PM-preset agent **cannot** resolve — it must hand off to an `admin_agent`-preset agent (or an admin-preset API key) to perform the resolve. If your key lacks `idea:admin`, surface this to the human and request the handoff instead of failing silently.
 
-   If issues are found (contradictions, ambiguities, incomplete answers), include them in `issues` and provide `followUpQuestions` for a new round:
+   > **Assignee precondition (N2):** the resolving actor must be the Idea's **assignee**. A separate human reviewer resolving a PM-owned Idea therefore needs **both** `idea:admin` **and** to be assigned the Idea (claim/reassign it first). Admin permission alone is not enough.
 
    ```
    chorus_pm_validate_elaboration({
-     ideaUuid: "<idea-uuid>",
-     roundUuid: "<round-uuid>",
-     issues: [
-       { questionId: "q1", type: "ambiguity", description: "Role-based access selected but no roles defined" }
-     ],
-     followUpQuestions: [
-       { id: "fq1", text: "Which specific roles should have access?", category: "functional", options: [...] }
-     ]
+     ideaUuid: "<idea-uuid>"
    })
    ```
 
+   **Want a follow-up round instead of resolving?** Just call `chorus_pm_start_elaboration` again — there is no separate "open a round" flag. It works while still `elaborating` (a normal follow-up round) and, after you've already resolved, as an **appended round** (`isAppended: true`) that keeps the Idea `elaborated` and never blocks an in-flight Proposal. Per-question issue tagging no longer exists.
+
 7. **Check elaboration status** at any time:
    ```
    chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
@@ -273,7 +275,19 @@ chorus_pm_skip_elaboration({
 
 **Question categories:** `functional`, `non_functional`, `business_context`, `technical_context`, `user_scenario`, `scope`
 
-**Validation issue types:** `contradiction`, `ambiguity`, `incomplete`
+---
+
+## Idea Lineage (derive vs. task)
+
+Ideas can form a **single-parent forest**: an idea may have one parent (`parentUuid`), establishing a weak lineage. "Weak" means the parent only shows a read-only `+N derived` rollup of its **direct** children — it never blocks or alters either idea's elaboration/proposal/task flow, and a parent is always a full first-class idea (it can have its own content, proposals, and tasks).
+
+When a new direction surfaces (during elaboration, brainstorm, or review), decide where it belongs:
+
+- **Derive a child idea** (`chorus_pm_create_idea` with `parentUuid`, or `chorus_edit_idea` with `parentUuid` to reparent an existing idea) when the new direction needs **its own elaboration/proposal lifecycle** — it is an independent AI-DLC pass.
+- **Add a task** to the current idea's proposal when the new work is just *how to implement the current idea*.
+- **Create a plain top-level idea** (no `parentUuid`) when there is no lineage to the current idea.
+
+This is a soft heuristic, not a rule — use judgment. Cycle prevention is automatic: you cannot set a parent that is the idea itself or one of its descendants. Parent and child must be in the same project (cross-project lineage is not supported yet). Deleting a parent re-parents its children to top-level (it never cascades). (Reminder: invoke these as `chorus__chorus_pm_create_idea` / `chorus__chorus_edit_idea` — see the namespace note at the top of the `chorus` skill.)
 
 ---
 
@@ -283,7 +297,7 @@ chorus_pm_skip_elaboration({
 - Elaboration improves Proposal quality — don't skip it unless the requirements are trivially clear
 - Present interactive questions as plain text and collect free-text replies — OpenClaw has no `AskUserQuestion` primitive
 - Record decisions made in conversation as elaboration rounds for auditability
-- Always @mention the owner to confirm understanding before validating
+- Always @mention the owner to confirm understanding before resolving
 
 ---
 

package/skills/openspec-aware/SKILL.md

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

package/skills/proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -127,6 +127,8 @@ chorus_pm_add_document_draft({
 
 Add task drafts one at a time. The response returns the new draft's `draftUuid` — use it directly for `dependsOnDraftUuids` in subsequent drafts.
 
+**`acceptanceCriteriaItems` is required** — every task draft must include at least one item with a non-blank `description`, or the call is rejected. Use the structured `acceptanceCriteriaItems` array (the legacy `acceptanceCriteria` Markdown string does not satisfy the requirement).
+
 ```
 # First task -> response includes { draftUuid, draftTitle }
 chorus_pm_add_task_draft({
@@ -135,7 +137,10 @@ chorus_pm_add_task_draft({
   description: "Detailed description of what to build...",
   priority: "high",
   storyPoints: 3,
-  acceptanceCriteria: "- [ ] Criteria 1\n- [ ] Criteria 2"
+  acceptanceCriteriaItems: [
+    { description: "Criteria 1", required: true },
+    { description: "Criteria 2", required: true }
+  ]
 })
 
 # Second task — depends on first
@@ -145,18 +150,24 @@ chorus_pm_add_task_draft({
   description: "Unit and integration tests...",
   priority: "medium",
   storyPoints: 2,
-  acceptanceCriteria: "- [ ] Test coverage > 80%",
+  acceptanceCriteriaItems: [
+    { description: "Test coverage > 80%", required: true }
+  ],
   dependsOnDraftUuids: ["<draftUuid-from-first-task>"]
 })
 ```
 
+> To edit a draft's criteria later via `chorus_pm_update_task_draft`, pass a non-empty `acceptanceCriteriaItems` to replace them; omit the field to leave them unchanged. The field cannot be used to clear criteria.
+
 **Task priority:** `low`, `medium`, `high`
 
 ### Step 4: Review and Refine Drafts
 
 ```
-# Review current state
-chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+# Review current state. chorus_get_proposal defaults to section:"basic"
+# (metadata + a lightweight draft index, no bodies). Use section:"full" to
+# see every draft's content, or section:"documents"/"tasks" for one kind.
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
 
 # Update a document draft
 chorus_pm_update_document_draft({
@@ -237,7 +248,7 @@ After the reviewer runs (or an Admin reviews), if the VERDICT is **FAIL** or the
 
 1. **Read feedback:**
    ```
-   chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+   chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
    chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
    ```
    Identify BLOCKERs from the reviewer VERDICT or rejection note.
@@ -359,7 +370,7 @@ Potential issues and how to address them.
 
 Good tasks are:
 - **Module-scoped** — One cohesive functional module per task, not a single function or file
-- **Testable** — Clear, cohesive acceptance criteria (max 6 items per task; group related checks into one criterion but list key coverage, e.g. "All tests pass: service layer unit tests, API integration tests, edge case handling")
+- **Testable** — Clear, cohesive acceptance criteria are **required** on every task (at least one non-blank item; max 6; group related checks into one criterion but list key coverage, e.g. "All tests pass: service layer unit tests, API integration tests, edge case handling")
 - **Sized** — 1-8 story points (hours of agent work)
 - **Ordered** — Use `dependsOnDraftUuids` / `dependsOnTaskUuids` to express execution order
 - **Descriptive** — Include enough context for a developer agent to start without questions. For tasks with cross-module dependencies, reference the tech design's Module Contracts in the AC

package/skills/proposal-reviewer/SKILL.md

@@ -4,7 +4,7 @@ description: Adversarial read-only review of a submitted Chorus proposal — doc
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -39,11 +39,12 @@ A `proposalUuid` (in your task prompt). Fetch and review the full proposal.
 
 **Step 1: Gather context**
 ```
-chorus_get_proposal({ proposalUuid: "<uuid>" })
+chorus_get_proposal({ proposalUuid: "<uuid>", section: "full" })
 chorus_get_comments({ targetType: "proposal", targetUuid: "<uuid>" })
 chorus_get_idea({ ideaUuid: "<idea-uuid>" })
 chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
 ```
+> `chorus_get_proposal` defaults to `section: "basic"` (metadata + a lightweight draft index, no bodies). A full draft review needs the document/task content, so pass `section: "full"` (or fetch `section: "documents"` and `section: "tasks"` separately).
 
 **Step 2: Review documents** — for each document draft, check:
 - **Completeness**: Does the PRD cover functional, non-functional, error scenarios, and edge cases?
@@ -76,7 +77,7 @@ Rules: Pseudocode inconsistencies → always NOTE. Cross-document wording differ
 ## Round awareness
 
 - **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 before. If all previous BLOCKERs are resolved → VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Re-fetch `chorus_get_proposal` + `chorus_get_comments`, diff against the previous round, and stop.
+- **Round 2+**: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. If all previous BLOCKERs are resolved → VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Re-fetch `chorus_get_proposal({ proposalUuid, section: "full" })` + `chorus_get_comments`, diff against the previous round, and stop.
 
 ## Recognize your own rationalizations
 

package/skills/quick-dev/SKILL.md

@@ -4,7 +4,7 @@ description: Quick Task workflow — skip Idea→Proposal, create tasks directly
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -70,7 +70,7 @@ This matters because admin agents can call `chorus_admin_verify_task` to close t
 
 ### Step 1: Create a Quick Task
 
-**Always include `acceptanceCriteriaItems`** — these are the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
+**`acceptanceCriteriaItems` is required** — `chorus_create_tasks` rejects any task without at least one non-blank criterion (and rejects the whole batch if any task is missing them). These are also the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
 
 ```
 chorus_create_tasks({
@@ -100,7 +100,7 @@ chorus_claim_task({ taskUuid: "<task-uuid>" })
 
 ### Step 3: Edit Details (if needed)
 
-Use `chorus_update_task` to refine the task after creation. **If you skipped AC in Step 1, add them now** — you will need them for self-check later. Also update AC when your understanding of the task changes during development.
+Use `chorus_update_task` to refine the task after creation. Tasks always have AC (creation requires them), but **update them when your understanding changes during development**. Passing `acceptanceCriteriaItems` **replaces** the task's criteria with the provided non-empty set; omit the field to leave them unchanged (it cannot be used to clear AC).
 
 ```
 chorus_update_task({
@@ -182,7 +182,7 @@ Quick Tasks support sub-agent execution just like proposal-based tasks. **Sessio
 ## Tips
 
 - Keep Quick Tasks small — if you need more than 2-3 tasks, consider using `/proposal`
-- **Always write acceptance criteria at creation time** — they are your self-check contract. Specific, testable AC enables autonomous verification and makes the entire workflow self-contained
+- **Acceptance criteria are required at creation time** — `chorus_create_tasks` rejects tasks without them. They are your self-check contract; specific, testable AC enables autonomous verification and makes the entire workflow self-contained
 - 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

package/skills/review/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -112,10 +112,12 @@ Prioritize: **Proposals first** (they unblock PM and Developer work), then task
 #### A1: Read the Proposal
 
 ```
-chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
 ```
 
-This returns: title, description, input ideas, **document drafts** (PRD, tech design), **task drafts** (with descriptions and acceptance criteria).
+`chorus_get_proposal` defaults to `section: "basic"` — proposal metadata plus a lightweight index of the drafts (uuid, type/title, contentLength, AC count, dependency edges) with **no** document content or full task descriptions. For a review you need the bodies, so pass `section: "full"` to get everything at once (or `section: "documents"` / `section: "tasks"` to read one kind at a time).
+
+The `full` view returns: title, description, input ideas, **document drafts** (PRD, tech design), **task drafts** (with descriptions and acceptance criteria).
 
 #### A2: Quality Checklist
 

package/skills/task-reviewer/SKILL.md

@@ -4,7 +4,7 @@ description: Adversarial verification of a submitted Chorus task against its AC
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -42,7 +42,7 @@ A `taskUuid` (in your task prompt). Fetch the task, its AC, and the proposal doc
 ```
 chorus_get_task({ taskUuid: "<uuid>" })
 chorus_get_comments({ targetType: "task", targetUuid: "<uuid>" })
-chorus_get_proposal({ proposalUuid: "<from-task>" })
+chorus_get_proposal({ proposalUuid: "<from-task>", section: "documents" })
 chorus_get_document({ documentUuid: "<doc-uuid>" })
 ```
 

package/skills/yolo/SKILL.md

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — from prompt to done. Automates the en
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.9.0"
+  version: "0.10.0"
   category: project-management
   mcp_server: chorus
 ---
@@ -142,6 +142,8 @@ chorus_claim_idea({ ideaUuid: "<idea-uuid>" })
 
 In /yolo mode, the agent generates elaboration questions and answers them itself -- **no user interaction at all**. There is no `AskUserQuestion` primitive on OpenClaw, and yolo deliberately does not prompt the user; it self-answers to preserve an audit trail without interrupting the run.
 
+> **Self-elaboration is still a loop.** If answering your own questions surfaces a **new question, contradiction, or gap**, loop back to `chorus_pm_start_elaboration` for another self-answered round before resolving — don't force a resolve over unresolved ambiguity. There is no human gate in YOLO, so the loop exits on **your** judgment that nothing material is left open (round cap 10). Steps 1–2 are one round; repeat them as needed, then resolve once in Step 3.
+
 1. **Generate and submit questions:**
    ```
    chorus_pm_start_elaboration({
@@ -174,15 +176,16 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
    })
    ```
 
-3. **Validate** (no issues in self-mode):
+3. **Resolve** — in YOLO mode the agent resolves elaboration **autonomously, with no human-confirmation gate** (the human-confirmation requirement that applies to the interactive `/idea` flow is explicitly waived under `/yolo` automation):
+
    ```
    chorus_pm_validate_elaboration({
-     ideaUuid: "<idea-uuid>",
-     roundUuid: "<round-uuid>",
-     issues: []
+     ideaUuid: "<idea-uuid>"
    })
    ```
 
+   > `chorus_pm_validate_elaboration` requires `idea:admin`. `/yolo` already mandates an Admin-preset key in Prerequisites, so this is satisfied. To open another self-elaboration round instead of resolving, just call `chorus_pm_start_elaboration` again.
+
 #### Step 1.4: Create Proposal
 
 1. **Detect OpenSpec mode (inline).** Load the `openspec-aware` skill and run its **§1 inline three-check detection** (`CHORUS_OPENSPEC_MODE != "off"`, an `openspec/` directory at the project root, and the `openspec` CLI on `PATH`).
@@ -228,7 +231,7 @@ In /yolo mode, the agent generates elaboration questions and answers them itself
    })
    ```
 
-3. **Add task drafts incrementally** (use returned `draftUuid` for dependency chaining):
+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
    result1 = chorus_pm_add_task_draft({