@chorus-aidlc/chorus 0.17.2 → 0.18.0

package/.next/standalone/public/kiro-plugin/bin/on-post-submit-proposal.sh

@@ -64,13 +64,13 @@ Max review rounds: ${MAX_ROUNDS} (0 = unlimited).
 
 ACTION REQUIRED: spawn the read-only \`chorus-proposal-reviewer\` subagent to perform an independent quality review before admin approval.
 
-In Kiro, hand the reviewer this task (it is auto-selected by its description; you can also invoke it as /chorus-proposal-reviewer): \"Review proposal ${PROPOSAL_UUID}. Max review rounds: ${MAX_ROUNDS}. First, read existing comments to count previous VERDICTs and determine your round number. If max > 0 and your round exceeds max, skip the review and post a comment saying the limit was reached — human decision needed. Otherwise, proceed with the review and post your VERDICT as a comment on the proposal.\"
+In Kiro, hand the reviewer this task (it is auto-selected by its description; you can also invoke it as /chorus-proposal-reviewer): \"Review proposal ${PROPOSAL_UUID}. Max review rounds: ${MAX_ROUNDS}. First, read existing comments to count previous VERDICTs and determine your round number. If max > 0 and your round exceeds max, skip the review and post a comment saying the round limit was reached and a human decision is needed, and post no VERDICT (this tells the main agent to stop rather than substitute its own verdict). Otherwise, proceed with the review and post your VERDICT as a comment on the proposal.\"
 
-The reviewer is read-only (tools: read + @chorus) and posts its VERDICT as a comment on the proposal. After it completes, read comments and act on the most recent \`VERDICT:\` line:
+The reviewer is read-only (tools: read + @chorus) and posts its VERDICT as a comment on the proposal. Wait for the \`subagent\` call to return, then read this round's \`VERDICT:\` comment with chorus_get_comments — on THIS proposal, posted after you dispatched the reviewer. Do not settle for an older VERDICT from a previous round:
 - VERDICT: PASS — no issues. Proceed to approve (chorus_admin_approve_proposal).
 - VERDICT: PASS WITH NOTES — minor non-blocking notes. Still proceed to approve.
 - VERDICT: FAIL — BLOCKERs found. Do NOT approve. Reject (chorus_pm_reject_proposal), fix the BLOCKERs, and resubmit.
 
-IMPORTANT: run the reviewer synchronously and wait for its VERDICT before proceeding."
+IMPORTANT: the \`subagent\` call's own return value is not the verdict — base the decision on the comment. Do NOT approve or reject before you have read this round's VERDICT comment. If it is missing, check what the reviewer did post: a comment reporting the round limit was reached, or any other explicit refusal to review, is a deliberate escalation — STOP: do not respawn, do not self-review, do not post a VERDICT of your own; leave it pending the human's decision. If it posted nothing at all, respawn once and apply this same check again to what the retry posts — an explicit refusal still means STOP; only a second true silence lets you review the proposal yourself as a read-only pass and post the VERDICT. Absence is never a PASS."
 
 exit 0

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

@@ -109,8 +109,8 @@ All tasks of idea-rooted proposal ${PROPOSAL_UUID} are now verified. This is the
 
 ACTION REQUESTED: spawn the read-only \`chorus-code-reviewer\` subagent for this idea — an independent review of the idea's AGGREGATE code change (the whole feature across all its tasks), not a single task. It is auto-selected by its description; you can also invoke it as /chorus-code-reviewer.
 
-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\").
+1. Spawn the code-reviewer and wait for the \`subagent\` call to return, 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 THIS round's VERDICT on the idea (chorus_get_comments targetType=\"idea\") — the comment posted after your dispatch, not an earlier round's. The \`subagent\` call's own return value is not the verdict; do not declare the feature shippable before you have read that comment. If it is missing, check what the reviewer did post: a comment reporting the round limit was reached, or any other explicit refusal to review, is a deliberate escalation — STOP: do not respawn, do not self-review, do not post a VERDICT of your own; leave it pending the human's decision. If it posted nothing at all, respawn once and apply this same check again to what the retry posts — an explicit refusal still means STOP; only a second true silence lets you review the idea's aggregate change yourself as a read-only pass and post the VERDICT. Absence is never a PASS.
 3. VERDICT: PASS / PASS WITH NOTES — the feature may ship.
 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.

package/.next/standalone/public/kiro-plugin/bin/resolve-spec-mode.sh

@@ -0,0 +1,107 @@
+#!/usr/bin/env bash
+# resolve-spec-mode.sh — resolve the active Chorus spec mode for a repo.
+#
+# Pure (env + filesystem only; no network). Sourced by on-session-start.sh and
+# driven directly by tests/test-spec-mode-resolution.sh. Bash 3.2 compatible.
+#
+# Inputs (env):
+#   CHORUS_SPEC_MODE                    explicit override: lite | openspec | off (else unset)
+#   CHORUS_OPENSPEC_MODE                legacy opt-out: "off" disables OpenSpec
+#   CLAUDE_PLUGIN_OPTION_ENABLEOPENSPEC plugin toggle: "false" disables OpenSpec (default "true")
+#   PROJECT_ROOT                        repo root to probe for openspec/ (defaults to $PWD)
+#   command -v openspec                 OpenSpec CLI presence on PATH
+#
+# Outputs (vars set in the caller's shell when sourced):
+#   SPEC_MODE              lite | openspec | off      (value surfaced to Claude)
+#   SPEC_REASON            human-readable one-liner
+#   SPEC_FAIL              non-empty => stage skill MUST halt (unsatisfiable explicit openspec)
+#   OPENSPEC_USABLE        1 | 0
+#   OPENSPEC_USABLE_REASON human-readable
+#   OPENSPEC_HINT          install hint when OpenSpec is merely missing (else empty)
+#   CHORUS_OPENSPEC_ACTIVE 1 only when the resolved mode is a USABLE openspec
+#
+# Resolution (per owner): an explicit CHORUS_SPEC_MODE wins; when UNSET, OpenSpec
+# stays the default whenever it is usable (openspec/ dir + CLI, not disabled), and
+# lite is the fallback only when OpenSpec is absent or disabled.
+
+: "${PROJECT_ROOT:=$PWD}"
+
+# --- Is OpenSpec usable? (needs openspec/ dir + CLI on PATH + not disabled) ---
+OPENSPEC_DISABLED=0
+OPENSPEC_DISABLED_REASON=""
+if [ "${CLAUDE_PLUGIN_OPTION_ENABLEOPENSPEC:-true}" != "true" ]; then
+  OPENSPEC_DISABLED=1
+  OPENSPEC_DISABLED_REASON="enableOpenSpec userConfig=false (plugin-level opt-out)"
+elif [ "${CHORUS_OPENSPEC_MODE:-}" = "off" ]; then
+  OPENSPEC_DISABLED=1
+  OPENSPEC_DISABLED_REASON="CHORUS_OPENSPEC_MODE=off (legacy opt-out)"
+fi
+
+OPENSPEC_USABLE=0
+OPENSPEC_USABLE_REASON=""
+OPENSPEC_HINT=""
+if [ "$OPENSPEC_DISABLED" = "1" ]; then
+  OPENSPEC_USABLE_REASON="$OPENSPEC_DISABLED_REASON"
+elif [ ! -d "${PROJECT_ROOT}/openspec" ]; then
+  OPENSPEC_USABLE_REASON="no openspec/ directory at ${PROJECT_ROOT}/openspec"
+  OPENSPEC_HINT="npm i -g @fission-ai/openspec && openspec init"
+elif ! command -v openspec >/dev/null 2>&1; then
+  OPENSPEC_USABLE_REASON="openspec/ directory present but \`openspec\` CLI not on PATH"
+  OPENSPEC_HINT="npm i -g @fission-ai/openspec"
+else
+  OPENSPEC_USABLE=1
+  OPENSPEC_USABLE_REASON="openspec/ directory + openspec CLI both present"
+fi
+
+# --- Resolve CHORUS_SPEC_MODE ---
+SPEC_FAIL=""
+case "${CHORUS_SPEC_MODE:-}" in
+  lite)
+    SPEC_MODE="lite"
+    SPEC_REASON="explicit — Chorus-native lightweight specs in .chorus/specs/<slug>/"
+    ;;
+  off)
+    SPEC_MODE="off"
+    SPEC_REASON="explicit — free-form, no spec artifact"
+    ;;
+  openspec)
+    SPEC_MODE="openspec"
+    if [ "$OPENSPEC_USABLE" = "1" ]; then
+      SPEC_REASON="explicit; ${OPENSPEC_USABLE_REASON}"
+    elif [ "$OPENSPEC_DISABLED" = "1" ]; then
+      SPEC_REASON="explicit, but OpenSpec is disabled: ${OPENSPEC_USABLE_REASON}"
+      SPEC_FAIL="config conflict — CHORUS_SPEC_MODE=openspec vs OpenSpec disabled (${OPENSPEC_USABLE_REASON}); re-enable OpenSpec or set CHORUS_SPEC_MODE=lite"
+    else
+      SPEC_REASON="explicit, but OpenSpec is not installed: ${OPENSPEC_USABLE_REASON}"
+      SPEC_FAIL="OpenSpec not usable (${OPENSPEC_USABLE_REASON})"
+    fi
+    ;;
+  "")
+    # Unset: OpenSpec is the default when usable; lite is the fallback otherwise.
+    if [ "$OPENSPEC_USABLE" = "1" ]; then
+      SPEC_MODE="openspec"
+      SPEC_REASON="default — ${OPENSPEC_USABLE_REASON}; set CHORUS_SPEC_MODE=lite for Chorus-native specs, =off to disable"
+    else
+      SPEC_MODE="lite"
+      SPEC_REASON="default — OpenSpec not usable (${OPENSPEC_USABLE_REASON}); using Chorus-native lightweight specs in .chorus/specs/<slug>/"
+    fi
+    ;;
+  *)
+    # Unrecognized value: treat like unset (OpenSpec-if-usable, else lite).
+    if [ "$OPENSPEC_USABLE" = "1" ]; then
+      SPEC_MODE="openspec"
+      SPEC_REASON="CHORUS_SPEC_MODE='${CHORUS_SPEC_MODE}' unrecognized; falling back to default (${OPENSPEC_USABLE_REASON})"
+    else
+      SPEC_MODE="lite"
+      SPEC_REASON="CHORUS_SPEC_MODE='${CHORUS_SPEC_MODE}' unrecognized; OpenSpec not usable, defaulting to lite"
+    fi
+    ;;
+esac
+
+# Back-compat flag for the openspec-aware skill: active only when the resolved
+# mode is a USABLE openspec.
+if [ "$SPEC_MODE" = "openspec" ] && [ -z "$SPEC_FAIL" ]; then
+  CHORUS_OPENSPEC_ACTIVE=1
+else
+  CHORUS_OPENSPEC_ACTIVE=0
+fi

package/.next/standalone/public/kiro-plugin/manifest.txt

@@ -24,6 +24,7 @@ skill chorus-review
 skill chorus-quick-dev
 skill chorus-brainstorm
 skill chorus-openspec-aware
+skill chorus-spec-lite
 skill chorus-orchestrate
 skill chorus-docs
 skill chorus-cli
@@ -38,5 +39,6 @@ hook on-post-submit-proposal.sh
 hook on-post-submit-for-verify.sh
 hook on-post-verify-task.sh
 hook chorus-api.sh
+hook resolve-spec-mode.sh
 hook verify-document-roundtrip.sh
 hook test-syntax.sh

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

@@ -449,9 +449,19 @@ This is the **single canonical description** of the reviewer pattern. The `devel
 
 > 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.
 
+### First-Principles Alignment (a stage-tailored instruction in all three reviewers)
+
+Beyond their local checks, every reviewer also verifies **top-down** that the work still serves the *original Idea's intent*. Each one first **resolves the Idea** from the entity it is reviewing — proposal-reviewer → the proposal's `inputUuids[0]`; task-reviewer → `chorus_get_task`, then that task's proposal's `inputUuids[0]`; code-reviewer → the `ideaUuid` it was given (skip the dimension if there is no attached Idea) — then reads it with the **existing** reads: `chorus_get_idea` (content), `chorus_get_elaboration` (resolved decisions, each carrying `answeredBy.type`), and `chorus_get_comments({ targetType: "idea" })` (each comment carrying `author.type`). It builds the authoritative **baseline** of original intent from **human input alone**: the Idea content + elaboration answers where `answeredBy.type == "user"` + comments where `author.type == "user"`. Agent-answered elaboration and agent-authored comments are **audit context only** — they can never expand, shrink, or override the baseline, so a drifting agent cannot self-authorize by self-answering a YOLO elaboration or posting its own Idea comment. The work under review is checked against that baseline for three drift types:
+
+- **Scope creep** — work beyond the original intent.
+- **Requirement loss / shrink** — intent the baseline states, quietly dropped or reduced.
+- **Semantic drift** — the work passes its acceptance criteria but misses the baseline's point.
+
+Any drift is a **BLOCKER → `VERDICT: FAIL` / reject** — **unless** it is traceable to a **human** authorization: a comment with `author.type == "user"`, an elaboration decision with `answeredBy.type == "user"`, or an explicit **human override** at the gate. **An agent-authored or agent-answered entry never authorizes** — a drifting agent cannot self-clear by posting its own comment. When a reviewer downgrades a deviation on this escape hatch, it downgrades to a `NOTE` and **cites the specific human entry** it relied on, so the decision is human-auditable. If the entity has no attached Idea (e.g. a document-input proposal), the alignment dimension is skipped. This is one labeled part of the existing VERDICT — not a separate report.
+
 ### Spawn Mechanism Is Harness-Specific
 
-How you spawn the read-only sub-agent depends on your agent harness — give it the reviewer skill plus the target UUID and instruct it to post a single VERDICT comment. Concrete examples:
+How you spawn the read-only sub-agent depends on your agent harness — give it the reviewer skill plus the target UUID and instruct it to post a single VERDICT comment. Then wait for it using your harness's own waiting mechanism, and read THIS round's `VERDICT:` comment for the entity under review with `chorus_get_comments` — the comment posted after your dispatch, not an older round's. Do not advance the pipeline before you have read that comment. Concrete examples:
 
 - **Claude Code** — use the Task / Agent tool to launch a sub-agent that loads `task-reviewer-chorus` (or `proposal-reviewer-chorus` / `code-reviewer-chorus`) and pass the `taskUuid` / `proposalUuid` / `ideaUuid`.
 - **Codex** — use `spawn_agent` with the reviewer skill and the target UUID.

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

@@ -102,6 +102,7 @@ These are the dimensions that per-task review structurally cannot catch. Cover e
 4. **Regression risk / impact on untouched areas / performance** — Does the change break or degrade code no single task owned? N+1s, hot-path cost, shared-state contention introduced by the aggregate.
 5. **Feature-level test coverage adequacy** — Across the whole feature, are the integration seams and end-to-end paths tested, or only per-task units? Gaps between tasks.
 6. **Code soundness, simplicity, correctness** — Is the aggregate change correct, reasonably simple, and free of obvious defects when read as one body of work?
+7. **Intent alignment (whole-feature)** — Also read the Idea's resolved elaboration (`chorus_get_elaboration`); using ONLY human-authored intent (Idea body + human-answered elaboration + human-authored comments; agent-authored entries are audit context, not intent) as the baseline, judge whether the aggregate change still serves the original intent. Flag scope creep, dropped requirements, or intent missed despite passing AC as a **BLOCKER**, unless a cited human entry / human override authorizes it.
 
 ### Step 4: Run Feature-Level Build / Test
 

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

@@ -182,7 +182,7 @@ chorus_submit_for_verify({
 
 > `to_verify` does NOT unblock downstream tasks — only `done` (after admin verification) does.
 
-> **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.
+> **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 THIS round's verdict comment — the one posted after your dispatch, not an older round's — with `chorus_get_comments` and act on it. 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. 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.
 

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

@@ -77,7 +77,9 @@ Chorus uses three read-only adversarial reviewers as quality gates. As orchestra
 | `task-reviewer-chorus` | a task is submitted for verify | one task vs its acceptance criteria (VERDICT on the task) |
 | `code-reviewer-chorus` | the idea's last task is verified | the idea's **aggregate** code change — the final ship gateway (VERDICT on the idea) |
 
-Spawn a read-only sub-agent that loads the matching reviewer skill and the target UUID (pass the `ideaUuid` for code review); if your harness has no sub-agent primitive, run the reviewer's procedure inline yourself. Each posts exactly one `VERDICT: PASS` / `PASS WITH NOTES` / `FAIL` comment. Verdicts are **advisory** — they do not auto-approve, auto-verify, or hard-block; you read the BLOCKERs and decide. A `FAIL` means route the BLOCKERs back for a fix before advancing (for a code-review FAIL, add fix tasks to the *approved* proposal via `quick-dev-chorus` and re-run once they are `done`). The **Independent Review** section of the core `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`) is the canonical description of this pattern.
+Spawn a read-only sub-agent that loads the matching reviewer skill and the target UUID (pass the `ideaUuid` for code review); if your harness has no sub-agent primitive, run the reviewer's procedure inline yourself. Wait for it with your harness's own waiting mechanism, then read THIS round's `VERDICT:` comment for the entity under review with `chorus_get_comments` — posted after your dispatch, not an older round's — before advancing. Each posts exactly one `VERDICT: PASS` / `PASS WITH NOTES` / `FAIL` comment. Verdicts are **advisory** — they do not auto-approve, auto-verify, or hard-block; you read the BLOCKERs and decide. A `FAIL` means route the BLOCKERs back for a fix before advancing (for a code-review FAIL, add fix tasks to the *approved* proposal via `quick-dev-chorus` and re-run once they are `done`). The **Independent Review** section of the core `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`) is the canonical description of this pattern.
+
+**First-principles alignment (a stage-tailored instruction in each reviewer).** Every one of the three reviewers also checks, top-down, that the work still serves the *original Idea's intent* — it resolves the Idea from the entity under review, reads it via the existing `chorus_get_idea` + `chorus_get_elaboration` + `chorus_get_comments`, builds the intent baseline from **human-authored** content only, and flags **scope creep**, **requirement loss / shrink**, or **semantic drift**. Unauthorized drift is a **BLOCKER → FAIL / reject**, downgraded to a cited NOTE only when traceable to a **human-originated** authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override at the gate) — an agent's own comment never authorizes, so a drifting agent cannot self-clear. As orchestrator, route an alignment FAIL back for a fix like any other BLOCKER, or record the human override at the gate.
 
 ---
 
@@ -104,6 +106,14 @@ Guidance: start narrow. If a single owner can hold the whole feature in their he
 
 ---
 
+## Replying to the agent who woke you (advisory)
+
+When an agent wakes a peer on a shared idea or task — an orchestrator dispatching a worker, or any agent `@mention`-ing another — the wake surfaces the **waker's live session anchor**: a note naming the waking agent and telling the woken peer that the waker has an open conversation on this idea. If you are the woken peer, **reply on the same idea/task resource** (comment there rather than opening a brand-new session) and your reply lands back in the waker's existing live session, keeping the collaboration on one thread instead of scattering into a fresh one.
+
+This is **advisory, not routing.** There is no automatic server subscription and nothing is force-delivered — replying on the shared resource is simply *where a reply lands* (via the existing return path), not a guaranteed channel. When the waker's origin is **offline** at wake time, no live anchor is surfaced and the exchange degrades to **notify-only**: the reply reaches the waker as an ordinary notification it picks up on its next turn. Only idea/theme-anchored wakes carry this anchor; ad-hoc wakes with no shared idea do not.
+
+---
+
 ## Reversed-Conversation gates (you never auto-ship)
 
 Chorus is **AI proposes, humans verify**. As orchestrator you enforce that, you do not bypass it:

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

@@ -27,10 +27,12 @@ Two failure patterns to avoid:
 You are **strictly prohibited** from:
 
 - Creating, modifying, or deleting any files.
-- Running any shell commands.
+- Any shell command beyond read-only inspection (see the rule below).
 - Installing dependencies or packages.
 
-Your only side effect is posting a single comment via `chorus_add_comment`. Everything else is read-only MCP queries. Do **not** modify the project in any way.
+Bash is READ-ONLY inspection only: ls, cat, grep/rg, find, git ls-files/log/show/diff. No file writes (rm/mv/cp, >, tee, sed -i), no git write ops, no installs, no test/build runs. Use it to confirm a file or directory exists before flagging it as missing.
+
+Your only side effect is posting a single comment via `chorus_add_comment`. Everything else is read-only — MCP queries and shell inspection. Do **not** modify the project in any way.
 
 ---
 
@@ -86,6 +88,7 @@ For each task draft, check:
 - Each task AC → traceable back to a requirement.
 - No orphan tasks, no orphan requirements.
 - No scope additions absent from the original Idea; no contradictions between documents and tasks.
+- **Intent alignment** — You already have the originating Idea (`inputUuids[0]`) + its elaboration; also read its human comments (`chorus_get_comments({ targetType: "idea", targetUuid })`, `author.type == "user"`). Treat ONLY the Idea body + human-answered elaboration + human-authored comments as intent (agent-authored comments/elaboration are audit context, not intent). Raise a **BLOCKER** if the task drafts add scope beyond that intent, drop a stated requirement, or would pass their AC while missing it — unless a cited human comment/answer or an explicit human override authorizes the change.
 
 ---
 

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

@@ -146,7 +146,7 @@ chorus_submit_for_verify({
 })
 ```
 
-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.
+Submitting is not final verification. Invoke the required independent task reviewer with the host agent's sub-agent mechanism, wait for it, and read THIS round's `VERDICT:` Task comment — the one posted after your dispatch, not an older round's. `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
 

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

@@ -24,6 +24,8 @@ Key responsibilities:
 - **Task verification** — verify or reopen Tasks submitted by Developer Agents (see `develop-chorus` skill at `<BASE_URL>/skill/develop-chorus/SKILL.md`)
 - **Project governance** — create projects/ideas, manage groups, close/delete entities
 
+> **First-principles alignment (a stage-tailored instruction in all three reviewers).** The proposal-, task-, and code-reviewer each also verify, top-down, that the work still serves the *original Idea's intent* — resolving the Idea from the entity under review and reading it via the existing `chorus_get_idea` + `chorus_get_elaboration` + `chorus_get_comments` (intent counts **human-authored** content only) and flagging **scope creep**, **requirement loss / shrink**, or **semantic drift**. Unauthorized drift is a **BLOCKER → `VERDICT: FAIL` / reject**, downgraded to a cited NOTE only when traceable to a **human-originated** authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override at the gate) — an agent's own comment never authorizes. So a review `FAIL` may come from intent drift, not just a local defect: treat it the same way — reject/reopen and fix, or record a human override. See the canonical **Independent Review** section in the `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`) for the full rule.
+
 ---
 
 ## Tools
@@ -130,7 +132,7 @@ chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
 
 #### A3.5: Independent Review
 
-Before approving, run an independent review of the proposal. Spawn a read-only sub-agent that loads the `proposal-reviewer-chorus` skill (`<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md`), pass it the `proposalUuid`, and let it adversarially audit document quality, task granularity, AC alignment, and the dependency DAG. It posts a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the proposal; read it with `chorus_get_comments` before deciding.
+Before approving, run an independent review of the proposal. Spawn a read-only sub-agent that loads the `proposal-reviewer-chorus` skill (`<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md`), pass it the `proposalUuid`, and let it adversarially audit document quality, task granularity, AC alignment, and the dependency DAG. It posts a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the proposal; read THIS round's verdict comment — the one posted after your dispatch, not an older round's — with `chorus_get_comments` before deciding.
 
 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.
 
@@ -199,7 +201,7 @@ chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
 
 #### B2.5: Independent Review
 
-Before marking acceptance criteria and verifying, run an independent review of the task. 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 independently verify the implementation against the acceptance criteria and proposal documents. It posts a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the task; read it with `chorus_get_comments` before deciding.
+Before marking acceptance criteria and verifying, run an independent review of the task. 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 independently verify the implementation against the acceptance criteria and proposal documents. It posts a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the task; read THIS round's verdict comment — the one posted after your dispatch, not an older round's — with `chorus_get_comments` before deciding.
 
 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.
 
@@ -207,7 +209,7 @@ The spawn mechanism is harness-specific, and an inline self-review fallback exis
 
 #### B2.6: Final Code-Review Gateway (after an Idea's LAST task is verified)
 
-When the task you just verified is the **last** task of its idea-rooted proposal, run the ship-time code-review gateway before the Idea's code is considered shipped. Spawn a read-only sub-agent that loads the `code-reviewer-chorus` skill (`<BASE_URL>/skill/code-reviewer-chorus/SKILL.md`), pass it the `ideaUuid` + round number, and let it review the Idea's **aggregate** code change across all its tasks — cross-task integration, architecture/convention consistency, security, regression/performance, and feature-level test coverage — dimensions a single-task review cannot see. It posts one `VERDICT` comment on the **Idea**; read it with `chorus_get_comments({ targetType: "idea", targetUuid })` before deciding.
+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 THIS round's verdict comment on the Idea — posted after your dispatch, not an earlier round's — 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 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`.

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

@@ -107,6 +107,10 @@ Pick 2-3 probes that fit the specific task — boundary values, missing fields,
 
 **Hallucination check:** Flag anything that looks LLM-fabricated as a **NOTE** — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names, or any external detail the developer likely wrote from memory rather than referencing docs.
 
+### Step 6: Intent Alignment
+
+Resolve the originating Idea (this task's proposal → `inputUuids[0]`) and read its body + human-answered elaboration + human-authored comments (`answeredBy.type` / `author.type == "user"`; agent-authored entries are audit context, not intent). Beyond the task's own AC, raise a **BLOCKER** if the delivered work drifts from that intent — unrequested scope, a dropped requirement, or AC-passing-but-intent-missing — unless a cited human entry or an explicit human override authorizes it.
+
 ---
 
 ## Recognize Your Own Rationalizations

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

@@ -54,6 +54,8 @@ Code-Review Gateway  (all tasks done; up to maxCodeReviewRounds, default 3)
 Done  -->  Report summary + mandatory Idea Completion Report
 ```
 
+**First-principles alignment (a stage-tailored instruction in every reviewer).** The proposal-, task-, and code-reviewer each also verify, top-down, that the work still serves the *original Idea's intent* — building the intent baseline from the directly-attached Idea it resolves from the entity under review — via the existing `chorus_get_idea` + `chorus_get_elaboration` + `chorus_get_comments`, counting **human-authored** content only — and flagging **scope creep**, **requirement loss / shrink**, or **semantic drift**. Unauthorized drift is a **BLOCKER → FAIL / reject**, downgraded to a cited NOTE only when traceable to a **human-originated** authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override) — an agent's own comment never authorizes. **In `/yolo` there is no human at the gate, so a self-generated (agent-authored) elaboration or comment does NOT clear alignment drift**: fix the drift (reject/reopen + revise) rather than rationalizing it away.
+
 **Escape hatch:** Interrupt at any time. Every created entity (project, idea, proposal, tasks, comments) persists in Chorus. Resume manually via `develop-chorus` or `review-chorus`.
 
 > **Base URL:** Skill files are hosted under `<BASE_URL>/skill/`. The user provides the Chorus access URL (e.g. `https://chorus.acme.com` or `http://localhost:8637`), referred to as `<BASE_URL>` below. See `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`) for platform overview and shared tools.
@@ -279,6 +281,20 @@ In yolo mode you generate the elaboration questions AND answer them yourself —
 
 ---
 
+### Reviewer contract (applies to every review gate below)
+
+Every gate in Phases 2, 4 and 4.5 follows the same three steps. They are written once here; the phases below only name their entity and their stage-specific actions.
+
+1. **Spawn and wait.** Spawn the reviewer as a read-only sub-agent, then wait for it: use your harness's waiting mechanism (the Independent Review pattern below lists the per-harness calls). Your spawn call's return value is not the verdict — the verdict is the `VERDICT:` comment the reviewer posts.
+2. **Read THIS round's VERDICT.** Call `chorus_get_comments` on the entity and find the `VERDICT:` comment posted **after your dispatch**, not an older round's. Do not advance the gate before you have read it.
+3. **No VERDICT for this round?** Check what the reviewer *did* post:
+   - **A reported round limit, or any other explicit refusal to review** — a deliberate escalation to a human. STOP: do not respawn, do not self-review, do not post a VERDICT of your own.
+   - **Nothing at all** — respawn ONCE, telling it to stay within its turn budget and reserve its last turns for the VERDICT, then apply this same check again to what the retry posts. An explicit refusal from the retry still means STOP; only a second true silence lets you review the entity yourself as a read-only pass and POST the VERDICT, then proceed on what you posted rather than looping forever.
+
+**Absence is never a PASS**, and a round limit reached by someone else is never yours to clear.
+
+---
+
 ### Phase 2: Proposal Review Loop
 
 Run an adversarial review on the submitted proposal using the **Independent Review pattern** (see below). Loop until the verdict allows approval or you exhaust `maxProposalReviewRounds`.
@@ -302,9 +318,9 @@ loop:
   # 1. Spawn the reviewer (Independent Review pattern above) with proposalUuid + round.
   #    Fallback: inline self-review as the main agent.
 
-  # 2. Read the latest VERDICT comment.
+  # 2. Read THIS round's VERDICT comment — posted after your dispatch, not an older round's.
   comments = chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
-  # Find the most recent comment containing "VERDICT:".
+  # Find THIS round's "VERDICT:" comment — the one posted after your dispatch, not an older round's.
 
   # 3. Act on the verdict (three outcomes).
 ```
@@ -340,7 +356,7 @@ loop:
           Human review needed. Proposal UUID: <proposal-uuid>."
    ```
 
-4. **No VERDICT comment after the reviewer returns?** The reviewer likely exhausted its turn budget. **Respawn it once** with a concise-budget hint: *"Stay within turn budget. Fetch the proposal + comments + idea only, skim for obvious BLOCKERs, and post your VERDICT within the first ~10 turns."* If the second attempt still posts no VERDICT, treat the proposal as **PASS WITH NOTES** and proceed — the pipeline must not loop forever on a silent reviewer.
+4. **No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the proposal yourself if the reviewer stays silent.
 
 ---
 
@@ -419,7 +435,7 @@ for each task in wave_tasks:
   # Fallback: inline self-review.
 
   comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
-  # Find the most recent comment containing "VERDICT:".
+  # Find THIS round's "VERDICT:" comment — the one posted after your dispatch, not an older round's.
 ```
 
 Act on the verdict — three outcomes:
@@ -451,7 +467,7 @@ ESCALATE: "Task '<title>' failed review after 3 rounds. Last BLOCKERs: <list>.
            Manual intervention needed. Task UUID: <task-uuid>."
 ```
 
-**No VERDICT comment after the reviewer returns?** It exhausted its turn budget. **Respawn it once** with a concise-budget hint: *"Stay within turn budget. Fetch the task/proposal/comments, run only the core tests, and post your VERDICT within the first ~12 turns."* If the second attempt still posts no VERDICT, treat as **PASS WITH NOTES** and proceed — do not loop indefinitely.
+**No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the task yourself if the reviewer stays silent.
 
 After verifying every task in the wave, return to **Phase 3** and re-run `chorus_get_unblocked_tasks` for newly unblocked tasks. Repeat until no tasks remain.
 
@@ -478,7 +494,7 @@ ESCALATE: "Idea '<title>' failed code review after 3 rounds. Last BLOCKERs: <lis
            Manual intervention needed. Idea UUID: <idea-uuid>."
 ```
 
-**No VERDICT comment after the code-reviewer returns?** It exhausted its turn budget (it carries a larger budget than the task-reviewer because it reviews the whole feature). Respawn it once with a concise-budget hint; if still none, treat as **PASS WITH NOTES** and proceed — do not loop forever.
+**No new VERDICT for this round?** Apply step 3 of the **Reviewer contract**, reviewing the idea's aggregate change yourself if the reviewer stays silent.
 
 > The gateway is **behavioral**, consistent with the other two reviewers: its verdict is advisory and does not change the Idea's stored status; the orchestrator honors it. It runs **before** the completion report so the report is never written while a FAIL is outstanding.
 
@@ -537,7 +553,7 @@ result = chorus_create_report({
 | Proposal review FAILs after `maxProposalReviewRounds` (3) | Stop the pipeline; report the persisting BLOCKERs; recommend manual review of the proposal. |
 | Task review FAILs after `maxTaskReviewRounds` (3) | Flag the task as escalation-needed; continue with the other tasks. |
 | Code-review gateway FAILs after `maxCodeReviewRounds` (3) | Stop before ship; escalate the persisting feature-level BLOCKERs to a human (Idea UUID); do not write the completion report. |
-| Reviewer returns no VERDICT | Respawn the reviewer once with a concise-budget hint; if still none, treat as PASS WITH NOTES and proceed. |
+| Reviewer returns no VERDICT | Apply step 3 of the **Reviewer contract**: an explicit refusal or reported round limit is an escalation — STOP; genuine silence — respawn once and re-check what the retry posts, and only on a second true silence review the entity yourself and POST the VERDICT. |
 | Worker crashes / never submits | Log it, leave the task non-`to_verify`; re-pick it in a later wave or escalate if it stays stuck. |
 | No unblocked tasks but some not done | Stuck DAG (failed reviews or bad dependencies). Break with an escalation report; do not loop. |
 | Sub-agents unavailable | Use the inline self-review fallback (reviews) and the sequential main-agent fallback (execution). |

package/README.ja.md

@@ -38,6 +38,8 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 ## 最近の更新
 
+**[v0.18.0](https://chorus-ai.dev/blog/chorus-v0.18.0-release/)** — OpenSpec を補う、軽量で Git ネイティブなローカル Spec 管理として `spec-lite` を内蔵しました。live session anchor により、デーモンエージェントからの返信が、起点となったエージェントの既存 Idea セッションへ戻ります。
+
 **[v0.17.2](https://chorus-ai.dev/blog/chorus-v0.17.2-release/)** — Pi が正式配布とデーモンウェイクに対応し、`chorus agents run` でローカルのエージェントプロファイルをすぐ切り替えられます。
 
 **[v0.17.0–0.17.1](https://github.com/Chorus-AIDLC/Chorus/releases/tag/v0.17.1)** — 1 つの CLI で各コーディングエージェントに Chorus を導入・更新できるようになりました。Tracker、Graph、Idea 詳細ではデーモンの活動をリアルタイムに確認できます。
@@ -52,8 +54,6 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 **[v0.14.1](https://chorus-ai.dev/blog/chorus-v0.14.1-release/)** — Amazon Kiro CLI が 4 つ目の接続方法になりました（Kiro CLI v2）：`chorus agents add` によるワンコマンドの Kiro プラグイン導入と `--agent kiro` デーモンバックエンド、加えていくつかのデーモン修正。
 
-**[v0.14.0](https://chorus-ai.dev/blog/chorus-v0.14.0-release/)** — アプリ全体のダークモード（ライト / ダーク / システム）。参考資料をあらゆる着想・提案・課題に添付でき、インラインでも MCP 経由でも読み取れます。韓国語と日本語を追加（韓国語はコミュニティによる貢献）。グループ化のための**テーマ**着想、デーモンの「開発を開始」/「Yolo」ボタン、対話式の着想入力、クラッシュからの再開、`chorus daemon install`。
-
 > 完全な変更履歴：[CHANGELOG.md](CHANGELOG.md)
 
 ---
@@ -63,7 +63,7 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 2 つのコマンドだけです — データベースも Docker も設定ファイルも不要です。
 
 ```bash
-npm install -g @chorus-aidlc/chorus@0.17.1
+npm install -g @chorus-aidlc/chorus@0.18.0
 chorus
 ```
 

package/README.ko.md

@@ -38,6 +38,8 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 ## 최근 업데이트
 
+**[v0.18.0](https://chorus-ai.dev/blog/chorus-v0.18.0-release/)** — OpenSpec을 보완하는 가볍고 Git 친화적인 로컬 Spec 관리 방식으로 `spec-lite`를 내장했습니다. live session anchor를 통해 데몬 에이전트의 응답이 작업을 시작한 에이전트의 기존 Idea 세션으로 돌아갑니다.
+
 **[v0.17.2](https://chorus-ai.dev/blog/chorus-v0.17.2-release/)** — Pi를 정식 패키지와 데몬 웨이크로 사용할 수 있으며, `chorus agents run`으로 로컬 에이전트 프로파일을 빠르게 전환할 수 있습니다.
 
 **[v0.17.0–0.17.1](https://github.com/Chorus-AIDLC/Chorus/releases/tag/v0.17.1)** — 하나의 CLI로 여러 코딩 에이전트에 Chorus를 설치하고 업데이트할 수 있습니다. 이제 Tracker, Graph, Idea 상세 화면에서 데몬 활동도 실시간으로 확인할 수 있습니다.
@@ -52,8 +54,6 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 **[v0.14.1](https://chorus-ai.dev/blog/chorus-v0.14.1-release/)** — Amazon Kiro CLI가 네 번째 연결 방식이 되었습니다(Kiro CLI v2): `chorus agents add` 명령 한 줄로 설치하는 Kiro 플러그인과 `--agent kiro` 데몬 백엔드, 여기에 몇 가지 데몬 수정.
 
-**[v0.14.0](https://chorus-ai.dev/blog/chorus-v0.14.0-release/)** — 앱 전체 다크 모드(라이트 / 다크 / 시스템). 참고 자료를 어떤 아이디어·제안·작업에도 첨부할 수 있고, 인라인으로도 MCP를 통해서도 읽을 수 있습니다. 한국어와 일본어 추가(한국어는 커뮤니티 기여). 그룹화를 위한 **테마** 아이디어, 그리고 데몬의 개발 시작 / Yolo 버튼, 대화식 아이디어 입력, 크래시 복구, `chorus daemon install`.
-
 > 전체 변경 이력: [CHANGELOG.md](CHANGELOG.md)
 
 ---
@@ -63,7 +63,7 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 두 개의 명령이면 됩니다. 데이터베이스도, Docker도, 설정 파일도 필요 없습니다.
 
 ```bash
-npm install -g @chorus-aidlc/chorus@0.17.1
+npm install -g @chorus-aidlc/chorus@0.18.0
 chorus
 ```
 

package/README.md

@@ -38,6 +38,8 @@ The labels under each stage are the **permissions** an actor needs there — gra
 
 ## What's New
 
+**[v0.18.0](https://chorus-ai.dev/blog/chorus-v0.18.0-release/)** — Built-in `spec-lite` adds a lightweight, Git-native local spec workflow alongside OpenSpec. Live session anchors let daemon agents return replies to the initiating agent's existing Idea session.
+
 **[v0.17.2](https://chorus-ai.dev/blog/chorus-v0.17.2-release/)** — Pi is now a published, wakeable Chorus agent, and `chorus agents run` switches local agent profiles with one command.
 
 **[v0.17.0–0.17.1](https://github.com/Chorus-AIDLC/Chorus/releases/tag/v0.17.1)** — One CLI now installs and refreshes Chorus across your coding agents. Live daemon activity is visible directly on Ideas in Tracker, Graph, and detail views.
@@ -52,8 +54,6 @@ The labels under each stage are the **permissions** an actor needs there — gra
 
 **[v0.14.1](https://chorus-ai.dev/blog/chorus-v0.14.1-release/)** — Amazon Kiro CLI is the fourth way to connect (Kiro CLI v2): a one-command Kiro plugin via `chorus agents add` and a `--agent kiro` daemon backend, plus daemon fixes.
 
-**[v0.14.0](https://chorus-ai.dev/blog/chorus-v0.14.0-release/)** — Dark mode across the app (light / dark / system). Reference artifacts: attach docs, repos, issues, and articles to any idea, proposal, or task, readable inline and over MCP. Korean and Japanese locales (Korean contributed by the community). **Theme** ideas for grouping, plus daemon Start Development / Yolo buttons, conversational idea entry, crash-resume, and `chorus daemon install`.
-
 > Full changelog: [CHANGELOG.md](CHANGELOG.md)
 
 ---
@@ -63,7 +63,7 @@ The labels under each stage are the **permissions** an actor needs there — gra
 Two commands. No database, no Docker, no config files.
 
 ```bash
-npm install -g @chorus-aidlc/chorus@0.17.1
+npm install -g @chorus-aidlc/chorus@0.18.0
 chorus
 ```
 

package/README.zh.md

@@ -29,6 +29,8 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 ## 最近更新
 
+**[v0.18.0](https://chorus-ai.dev/zh/blog/chorus-v0.18.0-release/)** — 内置 `spec-lite`，作为 OpenSpec 之外更轻量、可直接进 Git 的本地 Spec 管理方案。live session anchor 让 daemon Agent 的回复回到发起者已有的 Idea 会话。
+
 **[v0.17.2](https://chorus-ai.dev/zh/blog/chorus-v0.17.2-release/)** — Pi 现在可以正式安装并由 daemon 唤醒，`chorus agents run` 还能一条命令切换本地 Agent profile。
 
 **[v0.17.0–0.17.1](https://github.com/Chorus-AIDLC/Chorus/releases/tag/v0.17.1)** — 一个 CLI 即可为各类编程 Agent 安装和更新 Chorus。现在还能在 Tracker、Graph 和 Idea 详情中直接看到 daemon 的实时活动。
@@ -43,8 +45,6 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 
 **[v0.14.1](https://chorus-ai.dev/zh/blog/chorus-v0.14.1-release/)** — Amazon Kiro CLI 成为第四种接入方式（Kiro CLI v2）：通过 `chorus agents add` 一条命令安装的 Kiro 插件，以及 `--agent kiro` 的 daemon 后端，另有若干 daemon 修复。
 
-**[v0.14.0](https://chorus-ai.dev/zh/blog/chorus-v0.14.0-release/)** — 全应用深色模式（浅色 / 深色 / 跟随系统）。参考资料可挂到任意想法、提案或任务上，行内可读，也能通过 MCP 读写。新增韩语和日语（韩语由社区贡献）。用于归类的**主题**想法，以及 daemon 的「开始开发」/「Yolo」按钮、对话式建想法、崩溃恢复与 `chorus daemon install`。
-
 > 完整更新日志：[CHANGELOG.md](CHANGELOG.md)
 
 ---
@@ -54,7 +54,7 @@ Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Veri
 两条命令即可，无需数据库、无需 Docker、无需配置文件。
 
 ```bash
-npm install -g @chorus-aidlc/chorus@0.17.1
+npm install -g @chorus-aidlc/chorus@0.18.0
 chorus
 ```