cc-codeconductor 1.5.1 → 1.6.1

package/presets/cursor/skills/openspec/SKILL.md

@@ -16,7 +16,7 @@ gates, not a reference doc. Specs describe WHAT; `design.md` describes HOW.
 
 ## When to Use
 
-- `/cc-openspec` or `openspec next` / `plan` / `done` / `archive`
+- `/cc-openspec` or `openspec plan` / `next` / `done` / `sync` / `verify` / `archive`
 - An item is `READY` or later and must move through the state machine
 
 **NOT** for creating `BACKLOG.md` (use skill `backlog`) or for stack-specific
@@ -26,22 +26,43 @@ coding rules.
 
 Local CLI is `bun run dev`. Published package is `npx cc-codeconductor`.
 
-1. `openspec validate` — must pass before delivery.
-2. `openspec plan BC-xxx` if the item is not yet `PLANNED`.
-3. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
-4. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
+1. `openspec validate` — must pass before delivery. If you reached this
+   workflow on your own (the user did not ask for OpenSpec) and there is no
+   `BACKLOG.md` / `openspec/` root, answer normally instead — never scaffold
+   one as a side effect.
+2. `openspec plan BC-xxx` if the item is not yet `PLANNED`. Planning only: it
+   writes TaskCards plus proposal/design/tasks/specs under
+   `openspec/changes/<slug>/` and stops. Never implement in this step.
+3. Review the plan before `start`: read proposal → delta specs → tasks, in that
+   order, and confirm intent, scope, testable FR/SC, and edge-case scenarios.
+   Fix the Markdown directly or ask for revisions — code comes later.
+4. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
+5. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
    implement (`implementer`) → review (`reviewer`). If Global `TDD required: yes`,
-   test runs before implement.
-5. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
-   evidence JSON is rejected.
-6. `scorecard create --task BC-xxx --from-diff` then record a verdict.
-7. `openspec archive` only after human review when `Review required: yes` and
-   the scorecard is PASS.
+   test runs before implement. Discover is read-only: it never writes code.
+6. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
+   evidence JSON is rejected. The implementer ticks `tasks.md` boxes
+   (`- [ ]` → `- [x]`) as each FR lands; only `x`/`X` counts as done.
+7. When implementation reveals a design problem, pause and reconcile the planning
+   artifacts first — in any direction (a later artifact may force revising an
+   earlier one). Planning artifacts only in that step, never code; confirm each
+   edit. If the item's intent changed rather than its details, open a fresh item
+   with `/cc-backlog` (`/cc:backlog`) instead of warping this one.
+8. `openspec verify --output json` — advisory pre-archive checklist
+   (`archiveReady` plus Completeness/Correctness/Coherence issues). Optional:
+   `openspec sync` merges delta specs into `openspec/specs/` without closing.
+9. `scorecard create --task BC-xxx --from-diff` then record a verdict.
+10. `openspec archive` only after human review when `Review required: yes` and
+    the scorecard is PASS. Archive re-checks planning artifacts and analyze
+    CRITICALs, and warns on unchecked `tasks.md` boxes.
 
 Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE`
 → Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
 `IN_PROGRESS`.
 
+`openspec status --output json` also reports artifact presence, `tasks.md`
+checkbox progress, and `nextSteps` for the next CLI call.
+
 ## Web interface scope
 
 When the task concerns web layout, component states, feedback, motion, or a
@@ -70,17 +91,24 @@ delivery read-only and record unavailable visual or emulator evidence as pending
 | I'll add tests after green | Global TDD required means tester before implementer. |
 | I'll write the evidence JSON myself | Handmade TDD JSON is rejected. Use the verification runner. |
 | The item is small; skip analyze | `openspec analyze` CRITICAL still stops implement. |
+| The plan is generated; skip reading it | Read proposal → specs → tasks before `start`. Generated is not reviewed. |
+| I'll fix the spec after shipping | Reconcile planning artifacts before continuing to implement. |
 
 ## Red Flags
 
 - Implementing while analyze reports CRITICAL
+- Starting cards before reading the generated plan
 - Archive without a PASS scorecard when review is required
+- Archive while `openspec verify` reports CRITICAL
 - Acceptance like "improve UX" with no measurable check
 
 ## Verification
 
 - [ ] `openspec validate` exit 0
+- [ ] Plan reviewed (proposal → specs → tasks) before `start`
 - [ ] `openspec analyze --output json` has no CRITICAL
 - [ ] TDD evidence from the runner when TDD is required
+- [ ] `tasks.md` boxes ticked as FRs land
+- [ ] `openspec verify --output json` checked before archive
 - [ ] `scorecard create --from-diff` recorded
 - [ ] Suite check (optional): `bun run dev scorecard suite-run --suite workflow-gates`

package/presets/gemini/commands/cc/council.toml

@@ -1,90 +1,9 @@
 description = "Council-driven workflow with CCEP-1 bootstrap"
 
 prompt = """
-# Council-Driven Workflow
-
-Task request: {{args}}
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/render-agent-commands.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "{{args}}" --view prompt --output json`
-3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `{{args}}` to planners.
-
----
-
-## Step 1 — Wayfinding (repo-explorer)
-
-If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (and
-`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
-to map impact radius before deliberation. Do not write code in this step.
-
----
-
-## Step 2 — Deliberation & Specification (SDD)
-
-Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
-
-The council must:
-1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
-2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
-3. Draft a Task Card & Technical Plan (The Specification).
-
-**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
-CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
-answers. Show the agreed Task Card & Technical Plan and wait for confirmation
-before continuing.
-
----
-
-## Step 3 — Test Definition (TDD)
-
-Invoke `tester` with the approved Task Card & Technical Plan.
-
-tester must:
-1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
-2. Confirm the tests fail as expected (Red state).
-
-**Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
-
----
-
-## Step 4 — Surgical Implementation
-
-Invoke `implementer` with the failing tests and the Technical Plan.
-
-implementer must:
-1. Write the minimal code required to pass the tests.
-2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
-3. NOT refactor adjacent code, change existing styles, or build speculative features.
-4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state).
-
----
-
-## Step 5 — Multi-Perspective Council Review
-
-Invoke the `council` skill on the generated diff to perform the final review phase.
-
-The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
-
-If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
-- The Review Report status is **BLOCKED**.
-- Return to Step 4 with the feedback.
-
-If APPROVED (no CRITICAL findings):
-- Deliver the final Council Verdict and the diff summary.
-
----
-
-## Completion
-
-Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `/cc:fix` or `/cc:feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.
 """

package/presets/gemini/commands/cc/openspec.toml

@@ -116,6 +116,13 @@ Show:
 
 Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs
+and stops. Before Step 5, review the plan in this order — proposal → delta
+specs → tasks — and confirm: intent is right, no scope creep, every FR is
+testable with a scenario that exercises it, edge/error cases are covered, and
+each task traces to an FR/SC. Fix the Markdown directly or ask for revisions.
+Do not `start` any card until the plan reads correctly.
+
 ---
 
 ## Drive card status (CLI)
@@ -126,10 +133,12 @@ Do not edit `.codeconductor/openspec-state.json` by hand.
 npx cc-codeconductor openspec start <cardId>
 npx cc-codeconductor openspec done <cardId>
 npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec sync <itemId>
+npx cc-codeconductor openspec verify <itemId>
 npx cc-codeconductor openspec archive <itemId>
 ```
 
-`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `sync` merges delta specs into `openspec/specs/` without closing the item (optional before archive). `verify` is the advisory pre-archive checklist: exit 0 with `archiveReady` plus Completeness/Correctness/Coherence issues. `archive` requires all cards done (and review evidence when Global review is required), re-checks planning artifacts and analyze CRITICALs, warns on unchecked `tasks.md` boxes, then moves `openspec/changes/<slug>` to `archive/`.
 
 For test and implementation cards, `done` also requires a current RDD-backed
 RED or GREEN receipt respectively. Do not reuse evidence after candidate files
@@ -170,6 +179,14 @@ After each phase:
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 
+Discover is read-only: `repo-explorer` never writes code. The implementer ticks
+`tasks.md` boxes (`- [ ]` → `- [x]`) as each FR lands — only `x`/`X` counts as
+done. If implementation reveals a design problem, pause and reconcile the
+planning artifacts first (any direction: a later artifact may force revising an
+earlier one). Planning artifacts only in that step — never code — and confirm
+each edit. If the item's intent changed rather than its details, open a fresh
+item with `/cc:backlog` instead of warping this one.
+
 ---
 
 ## Step 6 — Review gate
@@ -195,6 +212,8 @@ If **approved**: proceed to Step 6.
 
 ## Step 7 — Scorecard and update backlog
 
+First run the advisory pre-archive check (`npx cc-codeconductor openspec verify <BC-id> --output json`): confirm `archiveReady` and clear any Completeness/Correctness/Coherence issues. Optionally run `openspec sync <BC-id>` to merge delta specs into `openspec/specs/` without closing the item. Then:
+
 1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
 2. Complete criteria; `scorecard record` with verdict and optional cost/tokens
 3. Set item `Progress: 100%`, `Status: DONE` if PASS

package/presets/muse/AGENTS.md

@@ -0,0 +1,46 @@
+<!-- CODECONDUCTOR:BEGIN managed -->
+
+# CodeConductor — Muse Preset
+
+This file configures CodeConductor for **Muse** (Meta's coding-agent CLI,
+binary `muse`). It lives at the project root (`AGENTS.md`) so Muse's
+context-file loader picks it up automatically.
+
+## Behavioral Discipline
+
+1. **Think Before Coding** — state assumptions; ask if uncertain; present
+   alternatives instead of picking silently.
+2. **Simplicity First** — minimum code that solves the problem; no
+   speculative abstractions.
+3. **Surgical Changes** — touch only what the task requires; match existing
+   style; remove only what your own change made unused.
+4. **Goal-Driven Execution** — turn the task into a verifiable goal with a
+   success check; loop until it passes.
+
+## Commands
+
+CodeConductor ships its workflows as Muse skills under `.agents/skills/`,
+invoked as `/cc:<name>` (e.g. `/cc:feature`, `/cc:review`). Run `/cc:ask
+"<problem>"` when unsure which one applies — it recommends exactly one and
+stops; it does not start the workflow.
+
+Skills live under `.agents/skills/` (Muse discovers skills there natively,
+per its own docs). Read `.agents/skills/using-cc-skills/SKILL.md` first —
+it maps intent to the right slash command.
+
+Where a step says "adopt the `X` role", read the matching skill under
+`.agents/skills/` and act as that role for the rest of the step.
+
+## What never changes
+
+- Do not invoke the Implementer without an accepted Technical Plan.
+- Do not skip the Reviewer step for medium- or high-risk changes.
+- Do not store secrets in any file loaded by Muse.
+
+## Receipt integrity
+
+- For any implementation, test, review, handoff, or delivery decision, capture or verify the current RDD receipt with `bun run dev rdd`.
+- A receipt is valid only for its exact candidate. If code, tests, contracts, or runner configuration changed, repeat the affected verification.
+- TDD and Mutation Testing retain their existing gates; RDD verifies that their observed evidence still belongs to the current candidate.
+
+<!-- CODECONDUCTOR:END managed -->

package/presets/muse/hooks.json

@@ -0,0 +1,30 @@
+{
+  "safety-gate": {
+    "enabled": true,
+    "PreToolUse": [
+      {
+        "matcher": ".*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node -e \"const fs=require('fs');const c=['.muse/hooks/invoke-hook.cjs'];const p=c.find(f=>fs.existsSync(f));if(p){require(require('path').resolve(p));}else{process.exit(0);}\" pre-tool --format=muse"
+          }
+        ]
+      }
+    ]
+  },
+  "code-formatter": {
+    "enabled": true,
+    "PostToolUse": [
+      {
+        "matcher": ".*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node -e \"const fs=require('fs');const c=['.muse/hooks/invoke-hook.cjs'];const p=c.find(f=>fs.existsSync(f));if(p){require(require('path').resolve(p));}else{process.exit(0);}\" post-tool --format=muse"
+          }
+        ]
+      }
+    ]
+  }
+}

package/presets/opencode/commands/cc-council.md

@@ -2,89 +2,8 @@
 description: Council-driven workflow with CCEP-1 bootstrap
 ---
 
-# Council-Driven Workflow
-
-Task request: $ARGUMENTS
+<!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/inject-ccep-bootstrap.ts — DO NOT EDIT. -->
 
 ## Step 0 — CCEP Bootstrap
 
-Command: `council` (fixed for this workflow — do not infer from user text)
-command: council
-
-1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
-2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
-3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
-
----
-
-## Step 1 — Wayfinding (repo-explorer)
-
-If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
-`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
-to map impact radius before deliberation. Do not write code in this step.
-
----
-
-## Step 2 — Deliberation & Specification (SDD)
-
-Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
-
-The council must:
-1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
-2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
-3. Draft a Task Card & Technical Plan (The Specification).
-
-**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
-CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
-answers. Show the agreed Task Card & Technical Plan and wait for confirmation
-before continuing.
-
----
-
-## Step 3 — Test Definition (TDD)
-
-Invoke `tester` with the approved Task Card & Technical Plan.
-
-tester must:
-1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
-2. Confirm the tests fail as expected (Red state).
-
-**Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
-
----
-
-## Step 4 — Surgical Implementation
-
-Invoke `implementer` with the failing tests and the Technical Plan.
-
-implementer must:
-1. Write the minimal code required to pass the tests.
-2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
-3. NOT refactor adjacent code, change existing styles, or build speculative features.
-4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state).
-
----
-
-## Step 5 — Multi-Perspective Council Review
-
-Invoke the `council` skill on the generated diff to perform the final review phase.
-
-The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
-
-If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
-- The Review Report status is **BLOCKED**.
-- Return to Step 4 with the feedback.
-
-If APPROVED (no CRITICAL findings):
-- Deliver the final Council Verdict and the diff summary.
-
----
-
-## Completion
-
-Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.
-
-## Next
-
-Approved: merge. Blocked: return the findings to `/cc-fix` or `/cc-feature`.
+command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.

package/presets/opencode/commands/cc-openspec.md

@@ -80,7 +80,9 @@ Use `$ARGUMENTS` BC-id or `npx cc-codeconductor openspec status` for next READY
 
 Run `npx cc-codeconductor openspec plan <BC-id>`. Show TaskCards and `openspec/changes/` path.
 
-Drive status with CLI (do not edit openspec-state.json): `openspec start <cardId>`, `openspec done <cardId>`, `openspec block <cardId> --reason "…"`, `openspec archive <itemId>`.
+`plan` is planning-only: it writes TaskCards plus proposal/design/tasks/specs and stops. Before Step 4, review the plan in order — proposal → delta specs → tasks — and confirm intent, scope, testable FR/SC, and edge-case scenarios. Do not `start` any card until the plan reads correctly.
+
+Drive status with CLI (do not edit openspec-state.json): `openspec start <cardId>`, `openspec done <cardId>`, `openspec block <cardId> --reason "…"`, `openspec sync <itemId>` (merge specs without closing, optional), `openspec verify <itemId>` (advisory pre-archive checklist), `openspec archive <itemId>` (re-checks artifacts and analyze CRITICALs).
 
 ---
 
@@ -94,7 +96,7 @@ For each pending card: `npx cc-codeconductor openspec next`, then invoke the lis
 - implement → `implementer`
 - review → `reviewer`
 
-Run each phase as a subagent with isolated context. Implementer uses a git worktree.
+Run each phase as a subagent with isolated context. Implementer uses a git worktree. Discover is read-only (never writes code); implementer ticks `tasks.md` boxes (`- [ ]` → `- [x]`, only `x`/`X` counts). If implementation reveals a design problem, pause and reconcile planning artifacts first (any direction, planning-only, confirm each edit); if the intent changed, open a fresh item with `/cc-backlog`.
 
 ---
 
@@ -106,6 +108,6 @@ Reviewer approves or rejects against acceptance criteria. Reject → `IN_PROGRES
 
 ## Step 6 — Update
 
-Mark DONE with `openspec archive <itemId>` (all cards must be done), then run `openspec scan`.
+First `openspec verify <itemId> --output json` (advisory: confirm `archiveReady`). Mark DONE with `openspec archive <itemId>` (all cards must be done), then run `openspec scan`.
 
 Apply skill `openspec` for format and state rules.

package/presets/opencode/skills/openspec/SKILL.md

@@ -16,7 +16,7 @@ gates, not a reference doc. Specs describe WHAT; `design.md` describes HOW.
 
 ## When to Use
 
-- `/cc-openspec` or `openspec next` / `plan` / `done` / `archive`
+- `/cc-openspec` or `openspec plan` / `next` / `done` / `sync` / `verify` / `archive`
 - An item is `READY` or later and must move through the state machine
 
 **NOT** for creating `BACKLOG.md` (use skill `backlog`) or for stack-specific
@@ -26,22 +26,43 @@ coding rules.
 
 Local CLI is `bun run dev`. Published package is `npx cc-codeconductor`.
 
-1. `openspec validate` — must pass before delivery.
-2. `openspec plan BC-xxx` if the item is not yet `PLANNED`.
-3. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
-4. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
+1. `openspec validate` — must pass before delivery. If you reached this
+   workflow on your own (the user did not ask for OpenSpec) and there is no
+   `BACKLOG.md` / `openspec/` root, answer normally instead — never scaffold
+   one as a side effect.
+2. `openspec plan BC-xxx` if the item is not yet `PLANNED`. Planning only: it
+   writes TaskCards plus proposal/design/tasks/specs under
+   `openspec/changes/<slug>/` and stops. Never implement in this step.
+3. Review the plan before `start`: read proposal → delta specs → tasks, in that
+   order, and confirm intent, scope, testable FR/SC, and edge-case scenarios.
+   Fix the Markdown directly or ask for revisions — code comes later.
+4. `openspec analyze --output json` — CRITICAL findings exit 1. Do not implement.
+5. Phases: discover (`repo-explorer`) → design (`architect`) → test (`tester`) →
    implement (`implementer`) → review (`reviewer`). If Global `TDD required: yes`,
-   test runs before implement.
-5. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
-   evidence JSON is rejected.
-6. `scorecard create --task BC-xxx --from-diff` then record a verdict.
-7. `openspec archive` only after human review when `Review required: yes` and
-   the scorecard is PASS.
+   test runs before implement. Discover is read-only: it never writes code.
+6. `openspec done` on test/implement requires `captureTddSuiteEvidence`. Handmade
+   evidence JSON is rejected. The implementer ticks `tasks.md` boxes
+   (`- [ ]` → `- [x]`) as each FR lands; only `x`/`X` counts as done.
+7. When implementation reveals a design problem, pause and reconcile the planning
+   artifacts first — in any direction (a later artifact may force revising an
+   earlier one). Planning artifacts only in that step, never code; confirm each
+   edit. If the item's intent changed rather than its details, open a fresh item
+   with `/cc-backlog` (`/cc:backlog`) instead of warping this one.
+8. `openspec verify --output json` — advisory pre-archive checklist
+   (`archiveReady` plus Completeness/Correctness/Coherence issues). Optional:
+   `openspec sync` merges delta specs into `openspec/specs/` without closing.
+9. `scorecard create --task BC-xxx --from-diff` then record a verdict.
+10. `openspec archive` only after human review when `Review required: yes` and
+    the scorecard is PASS. Archive re-checks planning artifacts and analyze
+    CRITICALs, and warns on unchecked `tasks.md` boxes.
 
 Status machine: `TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE`
 → Archive. `BLOCKED` returns to `READY`. Reviewer rejection: `REVIEW` →
 `IN_PROGRESS`.
 
+`openspec status --output json` also reports artifact presence, `tasks.md`
+checkbox progress, and `nextSteps` for the next CLI call.
+
 ## Web interface scope
 
 When the task concerns web layout, component states, feedback, motion, or a
@@ -70,17 +91,24 @@ delivery read-only and record unavailable visual or emulator evidence as pending
 | I'll add tests after green | Global TDD required means tester before implementer. |
 | I'll write the evidence JSON myself | Handmade TDD JSON is rejected. Use the verification runner. |
 | The item is small; skip analyze | `openspec analyze` CRITICAL still stops implement. |
+| The plan is generated; skip reading it | Read proposal → specs → tasks before `start`. Generated is not reviewed. |
+| I'll fix the spec after shipping | Reconcile planning artifacts before continuing to implement. |
 
 ## Red Flags
 
 - Implementing while analyze reports CRITICAL
+- Starting cards before reading the generated plan
 - Archive without a PASS scorecard when review is required
+- Archive while `openspec verify` reports CRITICAL
 - Acceptance like "improve UX" with no measurable check
 
 ## Verification
 
 - [ ] `openspec validate` exit 0
+- [ ] Plan reviewed (proposal → specs → tasks) before `start`
 - [ ] `openspec analyze --output json` has no CRITICAL
 - [ ] TDD evidence from the runner when TDD is required
+- [ ] `tasks.md` boxes ticked as FRs land
+- [ ] `openspec verify --output json` checked before archive
 - [ ] `scorecard create --from-diff` recorded
 - [ ] Suite check (optional): `bun run dev scorecard suite-run --suite workflow-gates`

package/src/presets/manifests/muse.yml

@@ -0,0 +1,18 @@
+target: muse
+entries:
+  - src: muse/AGENTS.md
+    dest: AGENTS.md
+    strategy: merge-managed
+    globalStrategy: skip
+    template: true
+  - src: opencode/skills
+    dest: .agents/skills
+    strategy: overwrite
+  - src: muse/hooks.json
+    dest: .muse/hooks.json
+    strategy: overwrite
+    globalStrategy: skip
+  - src: shared/invoke-hook.cjs
+    dest: .muse/hooks/invoke-hook.cjs
+    strategy: overwrite
+    globalStrategy: skip

package/src/presets/models/muse.yml

@@ -0,0 +1,4 @@
+# Model configuration for Muse preset
+# Agent models and tool-name mappings live in roles.yml; loadModelConfig()
+# merges this file with it. See roles.yml for the shared table.
+target: muse

package/src/presets/models/roles.yml

@@ -16,6 +16,7 @@ agents:
   architect:
     claude: claude-sonnet-5-5
     pi: claude-opus-5
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.1-pro-preview
@@ -25,6 +26,7 @@ agents:
   implementer:
     claude: claude-sonnet-5-5
     pi: claude-sonnet-5
+    muse: muse-spark-1.3
     opencode: opencode-go/mimo-v2.6-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -34,6 +36,7 @@ agents:
   tester:
     claude: claude-sonnet-5-5
     pi: claude-sonnet-5
+    muse: muse-spark-1.3
     opencode: opencode-go/mimo-v2.6-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -43,6 +46,7 @@ agents:
   orchestrator:
     claude: claude-sonnet-5-5
     pi: claude-sonnet-5
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -52,6 +56,7 @@ agents:
   reviewer:
     claude: claude-sonnet-5-5
     pi: claude-opus-5
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.1-pro-preview
@@ -61,6 +66,7 @@ agents:
   docs:
     claude: claude-sonnet-5-5
     pi: claude-haiku-4-5-20251001
+    muse: muse-spark-1.3
     opencode: opencode-go/muse-spark-1.3-contributor
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -70,6 +76,7 @@ agents:
   task-coach:
     claude: claude-haiku-4-5-20251001
     pi: claude-haiku-4-5-20251001
+    muse: muse-spark-1.3
     opencode: opencode-go/glm-5.3-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -79,6 +86,7 @@ agents:
   repo-explorer:
     claude: claude-haiku-4-5-20251001
     pi: claude-haiku-4-5-20251001
+    muse: muse-spark-1.3
     opencode: opencode-go/glm-5.3-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -88,6 +96,7 @@ agents:
   goal-planner:
     claude: claude-haiku-4-5-20251001
     pi: claude-haiku-4-5-20251001
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -97,6 +106,7 @@ agents:
   complexity-auditor:
     claude: claude-sonnet-5-5
     pi: claude-sonnet-5
+    muse: muse-spark-1.3
     opencode: opencode-go/glm-5.3-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -106,6 +116,7 @@ agents:
   security-reviewer:
     claude: claude-sonnet-5-5
     pi: claude-opus-5
+    muse: muse-spark-1.3
     opencode: opencode-go/glm-5.3-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.1-pro-preview
@@ -115,6 +126,7 @@ agents:
   contract-builder:
     claude: claude-sonnet-5-5
     pi: claude-opus-5
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.1-pro-preview
@@ -124,6 +136,7 @@ agents:
   planner:
     claude: claude-haiku-4-5-20251001
     pi: claude-haiku-4-5-20251001
+    muse: muse-spark-1.3
     opencode: opencode-go/deepseek-v4.1-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.7-flash
@@ -133,6 +146,7 @@ agents:
   devil:
     claude: claude-sonnet-5-5
     pi: claude-opus-5
+    muse: muse-spark-1.3
     opencode: opencode-go/glm-5.3-flash
     codex: gpt-6.1-sol
     gemini: gemini-3.1-pro-preview