peaks-loop 3.1.2 → 4.0.0-beta.2

package/skills/peaks-doctor/SKILL.md

@@ -22,7 +22,7 @@ The doctor workflow is read-only by design. It produces:
 - `peaks doctor` report (69 checks: 68 pass, 1 fail — L3:l3-memory-health)
 - Optional OpenSpec change records via `peaks openspec from-doctor`
 
-If a doctor finding requires a code change, the workflow hands off to `peaks-rd` (or `peaks-solo` for the full pipeline). The doctor itself does NOT modify code.
+If a doctor finding requires a code change, the workflow hands off to `peaks-rd` (or `peaks-code` for the full pipeline). The doctor itself does NOT modify code.
 
 ## Workflow (5 steps)
 

package/skills/peaks-doctor/references/doctor-check-catalog.md

@@ -24,7 +24,7 @@ Slice L3.2 ships 69 doctor checks. The most user-relevant ones:
 
 ## Skills
 
-- **`skill:<required-skill>`** — each required skill (peaks-ide, peaks-prd, peaks-rd, peaks-qa, peaks-sc, peaks-solo, peaks-sop, peaks-txt, peaks-ui, peaks-doctor) must be installed in the bundled skills dir
+- **`skill:<required-skill>`** — each required skill (peaks-ide, peaks-prd, peaks-rd, peaks-qa, peaks-sc, peaks-code, peaks-sop, peaks-txt, peaks-ui, peaks-doctor) must be installed in the bundled skills dir
 
 ## Doctor self
 

package/skills/peaks-final-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: peaks-final-review
-description: Final-review skill for Peaks. Use when a workflow needs to assemble 4-dimension business-review evidence (functional-completeness, problem-resolution, no-new-bugs, existing-functionality-intact) for human acceptance at the end of an autonomous slice. Triggers on "/peaks-final-review", "prepare final review", "4-dim review", or peaks-solo end-of-workflow handoff.
+description: Final-review skill for Peaks. Use when a workflow needs to assemble 4-dimension business-review evidence (functional-completeness, problem-resolution, no-new-bugs, existing-functionality-intact) for human acceptance at the end of an autonomous slice. Triggers on "/peaks-final-review", "prepare final review", "4-dim review", or peaks-code end-of-workflow handoff.
 ---
 
 ## Single-scope-axis naming convention
@@ -66,7 +66,7 @@ If any precondition is missing, **STOP** and route back to the responsible skill
 ### Current call path (today, until a CLI wrapper is built)
 
 ```ts
-// peaks-solo end-of-workflow, peaks-txt, or any other hand-rolled caller
+// peaks-code end-of-workflow, peaks-txt, or any other hand-rolled caller
 import { prepareFinalReview } from './src/services/final-review/final-review-service.js';
 import { auditGoalLlmRunner } from './src/services/audit/llm-runner.js'; // or your provider
 
@@ -85,7 +85,7 @@ const out = await prepareFinalReview('<rid>', {
 peaks prepare-final-review --rid <rid> [--session-id <sid>] --json
 ```
 
-`--rid` is required and resolves to `.peaks/_runtime/<sessionId>/audit-goal/<rid>.json`. `--json` is required for machine consumption (peaks-solo, peaks-txt, downstream CI). The wrapper will resolve `--session-id` from `.peaks/_runtime/current-change` when omitted, matching the workspace binding pattern used by `peaks request *`.
+`--rid` is required and resolves to `.peaks/_runtime/<sessionId>/audit-goal/<rid>.json`. `--json` is required for machine consumption (peaks-code, peaks-txt, downstream CI). The wrapper will resolve `--session-id` from `.peaks/_runtime/current-change` when omitted, matching the workspace binding pattern used by `peaks request *`.
 
 ## Output
 

package/skills/peaks-final-review/references/4-dimensions.md

@@ -107,7 +107,7 @@ A pre/post baseline diff shows no unintended drift in the test surface, public A
 The service contract (`src/services/final-review/final-review-service.ts:23-31` and `:88-93`):
 
 - `allPass === true` iff every dimension's `verdict === 'pass'`.
-- `needsAttention` is the list of dimension names whose verdict is `fail` or `inconclusive`. The LLM does NOT need to populate it — the service enforces presence of all 4 dimensions and the human-facing summarizer (in peaks-solo or peaks-txt) computes `needsAttention` for display.
+- `needsAttention` is the list of dimension names whose verdict is `fail` or `inconclusive`. The LLM does NOT need to populate it — the service enforces presence of all 4 dimensions and the human-facing summarizer (in peaks-code or peaks-txt) computes `needsAttention` for display.
 - An `IncompleteFinalReviewError` is thrown when JSON is malformed or any required dimension is missing. That is a **gate failure**, not a `fail` verdict — the LLM call is invalid and must be re-prompted, not surfaced to the human.
 
 ## Confidence and what it means

package/skills/peaks-ide/SKILL.md

@@ -128,7 +128,7 @@ The audit log is **machine-readable** (so `peaks project dashboard` can read it
 - introduce new `peaks <cmd>` CLI commands (dev-preference red line: "Default-no on new CLI commands")
 - bypass the user's confirmation on destructive paths (Switch / Uninstall)
 - write the settings.json directly (the CLI primitives own that)
-- run other peaks skills (peaks-solo, peaks-qa, etc.) — those are separate skills with their own scopes
+- run other peaks skills (peaks-code, peaks-qa, etc.) — those are separate skills with their own scopes
 - handle multi-IDE scenarios in slice #2 (e.g. "I use Claude at work and Trae at home" — the registry is single-IDE per session; a future slice could add multi-IDE)
 
 ## Reference: the CLI primitives the skill composes

package/skills/{peaks-solo-resume → peaks-resume}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-resume
-description: Resume an in-flight peaks-solo slice in the current session. Use when the user says "continue the unfinished work", "继续完成", "把刚才没做完的收尾", or invokes `/peaks-solo-resume` directly. Detects the current session's deepest completed gate (via the Step 0.7 detection script at `tests/fixtures/skill-resume-mode-detect.sh`) and surfaces a resume option via `AskUserQuestion`. Triggers on `/peaks-solo-resume`, "继续完成刚才的", "resume the unfinished slice", "把刚才没做完的收尾".
+name: peaks-resume
+description: Universal resume primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Detects the current session's deepest completed gate and surfaces a resume option via AskUserQuestion. Use when ANY bee (peaks-code, future peaks-research, future peaks-content, …) needs to recover from /compact or session interruption. Triggers on "/peaks-resume", "continue the unfinished work", "继续完成", "把刚才没做完的收尾". (Replaces peaks-resume as a top-level primitive.)
 ---
 
-# Peaks-Loop Solo Resume (wrapper)
+# Peaks-Loop Code Resume (wrapper)
 
-Peaks-Loop Solo Resume is a thin wrapper that handles the **most common high-frequency request shape**: "I was in the middle of something, continue it." It detects the current session's deepest completed gate, surfaces a resume option, then yields to the main `peaks-solo` skill (which runs the actual workflow from the matching gate onwards).
+Peaks-Loop Code Resume is a thin wrapper that handles the **most common high-frequency request shape**: "I was in the middle of something, continue it." It detects the current session's deepest completed gate, surfaces a resume option, then yields to the main `peaks-code` skill (which runs the actual workflow from the matching gate onwards).
 
-**This is a transparent wrapper.** The user does not stay in this skill — once the resume option is confirmed, control hands off to `peaks-solo`. The wrapper exists only to (a) detect the in-flight slice without the LLM re-reading 3-5 artifact files, and (b) surface the resume option as a `AskUserQuestion` before the main loop skips ahead.
+**This is a transparent wrapper.** The user does not stay in this skill — once the resume option is confirmed, control hands off to `peaks-code`. The wrapper exists only to (a) detect the in-flight slice without the LLM re-reading 3-5 artifact files, and (b) surface the resume option as a `AskUserQuestion` before the main loop skips ahead.
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-resume --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-resume --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -32,15 +32,15 @@ bash tests/fixtures/skill-resume-mode-detect.sh "$sid" .peaks
 
 ## Step 2: Branch on the detection
 
-**If `fresh`**: no in-flight slice. Tell the user "No in-flight slice in this session." Then hand off to `peaks-solo` for a fresh start (set presence back, then run `peaks workspace init --project <repo> --json` and continue with Step 1 of `peaks-solo`).
+**If `fresh`**: no in-flight slice. Tell the user "No in-flight slice in this session." Then hand off to `peaks-code` for a fresh start (set presence back, then run `peaks workspace init --project <repo> --json` and continue with Step 1 of `peaks-code`).
 
-**If `complete`**: the workflow is already done. Tell the user "This session is complete — your previous slice already shipped." Then suggest a fresh start (`peaks-solo`) or close-out.
+**If `complete`**: the workflow is already done. Tell the user "This session is complete — your previous slice already shipped." Then suggest a fresh start (`peaks-code`) or close-out.
 
 **If `resume:<gate>`**: surface a resume option via `AskUserQuestion`:
 
 | Option | What it does |
 |---|---|
-| Resume from `<gate>` (Recommended) | Hand off to `peaks-solo` with the gate already at the matching point. The main loop skips ahead; the existing artifacts are preserved as-is. |
+| Resume from `<gate>` (Recommended) | Hand off to `peaks-code` with the gate already at the matching point. The main loop skips ahead; the existing artifacts are preserved as-is. |
 | Start a fresh slice | Treat the current request as a new slice (new `rid`). Existing artifacts are preserved but not auto-resumed. |
 | Abandon the in-flight slice | Mark the in-flight slice as `deferred` (`peaks request transition <rid> --role rd --state deferred --reason "user abandoned"`) and start fresh. |
 
@@ -50,21 +50,21 @@ bash tests/fixtures/skill-resume-mode-detect.sh "$sid" .peaks
 
 Use `AskUserQuestion` with a single option (Confirm and resume from `<state>`). Do NOT auto-resume mid-implementation.
 
-## Step 3: Hand off to peaks-solo
+## Step 3: Hand off to peaks-code
 
-After the user confirms, **re-assert `peaks-solo` presence** so the status header reads correctly for the rest of the run:
+After the user confirms, **re-assert `peaks-code` presence** so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <matching-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <matching-gate>
 ```
 
-Then tell the user: "Resuming from `<gate>`. The main peaks-solo skill will take over from there." and yield control. The user's next message will land in the `peaks-solo` main loop, which will pick up the workflow from the matching gate.
+Then tell the user: "Resuming from `<gate>`. The main peaks-code skill will take over from there." and yield control. The user's next message will land in the `peaks-code` main loop, which will pick up the workflow from the matching gate.
 
 ## Hard rules (do NOT skip)
 
 - **Never silently auto-resume.** Always use `AskUserQuestion` first. The detection is a discovery; the user's confirmation is the gate.
 - **Never auto-resume mid-implementation.** For `in-flight:<state>`, the only valid option is "Confirm and resume from `<state>`" — never "Start a fresh slice" or "Abandon" without the user's explicit choice.
-- **Never write code or modify files in this skill.** This is a wrapper. The actual work (PRD, RD, QA, SC, TXT) is the main `peaks-solo` skill's job.
+- **Never write code or modify files in this skill.** This is a wrapper. The actual work (PRD, RD, QA, SC, TXT) is the main `peaks-code` skill's job.
 - **Never add a new `peaks <cmd>`.** Use the existing CLI primitives: `peaks workspace init`, `peaks project dashboard`, `peaks session list`, `peaks skill runbook`, `peaks skill doctor`, `peaks scan archetype`, `peaks request transition`. The detection script (`tests/fixtures/skill-resume-mode-detect.sh`) is the only executable this skill invokes.
 
 ## Anti-patterns (do NOT do)
@@ -77,5 +77,5 @@ Then tell the user: "Resuming from `<gate>`. The main peaks-solo skill will take
 ## Cross-references
 
 - The detection logic is canonical at `tests/fixtures/skill-resume-mode-detect.sh` (added in slice 003). The 8 vitest cases in `tests/unit/skill-resume-mode.test.ts` cover all classification outcomes.
-- The SKILL.md prose at `skills/peaks-solo/SKILL.md` Step 0.7 (added in slice 003) is the same logic, written for LLM consumption. This wrapper reuses the same script — there is no parallel implementation.
+- The SKILL.md prose at `skills/peaks-code/SKILL.md` Step 0.7 (added in slice 003) is the same logic, written for LLM consumption. This wrapper reuses the same script — there is no parallel implementation.
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent for this wrapper.

package/skills/peaks-sop/SKILL.md

@@ -39,7 +39,7 @@ real process.
 
 If the user invoked this skill directly ("peaks-sop") without mentioning a
 specific project, assume `--project .` (current directory). If they are NOT in
-the middle of a multi-skill peaks-solo/prd/rd/qa pipeline, skip `statusline
+the middle of a multi-skill peaks-code/prd/rd/qa pipeline, skip `statusline
 install` — the status bar is for long-running orchestrations; a standalone SOP
 authoring session does not need it.
 

package/skills/{peaks-solo-status → peaks-status}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-status
-description: Show the current state of the peaks-solo orchestrator in a compact summary. Use when the user says "what's the current state", "现在到哪了", "where are we", or invokes `/peaks-solo-status` directly. Reads the existing CLI primitives (`peaks skill presence`, `peaks session list`, `peaks project dashboard`, `peaks request show`) and renders a 1-screen status table. Triggers on `/peaks-solo-status`, "现在到哪了", "what is the current state", "show me the dashboard", "where are we".
+name: peaks-status
+description: Universal status primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Reads the existing CLI primitives (peaks skill presence, peaks session list, peaks project dashboard, peaks request show) and renders a 1-screen status table. Use when the user asks "where are we", "现在到哪了", "what's the current state" for ANY bee (peaks-code, future peaks-research, …). Triggers on "/peaks-status", "现在到哪了", "what is the current state", "show me the dashboard". (Replaces peaks-status as a top-level primitive.)
 ---
 
-# Peaks-Loop Solo Status (wrapper)
+# Peaks-Loop Code Status (wrapper)
 
-Peaks-Loop Solo Status is a thin wrapper that renders a compact status table for the current peaks-solo orchestrator state. It is the answer to "I just want to know where we are" — no PRD, no RD, no QA, no full peaks-solo orchestration. Just read the existing CLI state and render a 1-screen summary.
+Peaks-Loop Code Status is a thin wrapper that renders a compact status table for the current peaks-code orchestrator state. It is the answer to "I just want to know where we are" — no PRD, no RD, no QA, no full peaks-code orchestration. Just read the existing CLI state and render a 1-screen summary.
 
-**This is a transparent wrapper.** The user does not stay in this skill — the status table is rendered, and control hands off (back to the user, or to `peaks-solo` if the user wants to act on the status).
+**This is a transparent wrapper.** The user does not stay in this skill — the status table is rendered, and control hands off (back to the user, or to `peaks-code` if the user wants to act on the status).
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-status --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-status --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -51,9 +51,9 @@ All 6 calls are read-only. Total cost: sub-second. (The original draft said "5 c
 Compact 1-screen format:
 
 ```
-=== peaks-solo status ===
+=== peaks-code status ===
 Session:   2026-06-04-session-b60252
-Active:    peaks-solo (mode: full-auto, gate: qa-validation)
+Active:    peaks-code (mode: full-auto, gate: qa-validation)
 Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 | Role | State          | Artifact                |
@@ -72,9 +72,9 @@ Health: skill-doctor 35/35 pass
 If the session is fresh (no in-flight slice), render a different layout:
 
 ```
-=== peaks-solo status ===
+=== peaks-code status ===
 Session: 2026-06-04-session-b60252
-Active:  peaks-solo (mode: full-auto, gate: startup)
+Active:  peaks-code (mode: full-auto, gate: startup)
 Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 No in-flight slice. Ready for a new request.
@@ -85,16 +85,16 @@ Health: skill-doctor 35/35 pass
 
 | Option | What it does |
 |---|---|
-| Continue from the current gate | Hand off to `peaks-solo` with the gate already at the current state. Existing artifacts are preserved. |
+| Continue from the current gate | Hand off to `peaks-code` with the gate already at the current state. Existing artifacts are preserved. |
 | Open a new slice in this session | Keep the workspace, treat the current request as a new slice (new `rid`). |
 | Just summarize and exit | No further action; the user will decide later. |
 
 ## Step 4: Hand off (if user picked option 1 or 2)
 
-Re-assert `peaks-solo` presence so the status header reads correctly for the rest of the run:
+Re-assert `peaks-code` presence so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <matching-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <matching-gate>
 ```
 
 Then yield control.
@@ -116,5 +116,5 @@ Then yield control.
 ## Cross-references
 
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent.
-- `peaks-solo-resume` (P2.1) and `peaks-solo-test` (P2.2) are the sibling wrappers. `peaks-solo-resume` focuses on workflow-state introspection + resume decision; `peaks-solo-status` is the broader 5-CLI snapshot. The two are complementary, not redundant.
+- `peaks-resume` (P2.1) and `peaks-test` (P2.2) are the sibling wrappers. `peaks-resume` focuses on workflow-state introspection + resume decision; `peaks-status` is the broader 5-CLI snapshot. The two are complementary, not redundant.
 - The "read 5 CLI primitives, render 1 table" pattern is intentionally minimal — the wrapper does NOT add a new status-introspection CLI command (would violate the dev-preference.md "default-no on new CLI" rule).

package/skills/{peaks-solo-test → peaks-test}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-test
-description: Run the project's test suite on the current repo and report results. Use when the user says "run the tests", "跑一下 test", "跑测试", or invokes `/peaks-solo-test` directly. Runs `pnpm vitest run` (or the project's equivalent test command), captures pass/fail counts and any failures, and surfaces a compact summary. Triggers on `/peaks-solo-test`, "跑一下 test", "跑测试", "run the tests", "test now".
+name: peaks-test
+description: Universal test-runner primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Runs the project's test suite on the current repo and reports results. Use when the user asks "run the tests", "跑一下 test", "跑测试" for ANY bee (peaks-code, future peaks-research, …). Triggers on "/peaks-test", "跑一下 test", "跑测试", "run the tests", "test now". (Replaces peaks-test as a top-level primitive.)
 ---
 
-# Peaks-Loop Solo Test (wrapper)
+# Peaks-Loop Code Test (wrapper)
 
-Peaks-Loop Solo Test is a thin wrapper that runs the project's test suite on the current repo and reports results. It is the answer to "I just want to see if the tests pass" — no PRD, no RD, no QA, no full peaks-solo orchestration. Just `pnpm vitest run` and a compact summary.
+Peaks-Loop Code Test is a thin wrapper that runs the project's test suite on the current repo and reports results. It is the answer to "I just want to see if the tests pass" — no PRD, no RD, no QA, no full peaks-code orchestration. Just `pnpm vitest run` and a compact summary.
 
-**This is a transparent wrapper.** The user does not stay in this skill — the test command runs, the result is summarized, and control hands off (back to the user, or to `peaks-solo` if the user wants to act on the result).
+**This is a transparent wrapper.** The user does not stay in this skill — the test command runs, the result is summarized, and control hands off (back to the user, or to `peaks-code` if the user wants to act on the result).
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-test --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-test --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -50,23 +50,23 @@ Then ask the user what they want to do next via `AskUserQuestion`:
 | Option | What it does |
 |---|---|
 | Show the full failure list | Print all failing test names + messages (not just the first 5-10) |
-| Open a slice to fix the failures | Hand off to `peaks-solo` with the failing tests as the slice's "acceptance criteria" |
+| Open a slice to fix the failures | Hand off to `peaks-code` with the failing tests as the slice's "acceptance criteria" |
 | Just summarize and exit | No further action; the user will decide later |
 
 ## Step 4: Hand off (if user picked option 2)
 
-Re-assert `peaks-solo` presence so the status header reads correctly for the rest of the run:
+Re-assert `peaks-code` presence so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate qa-validation
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate qa-validation
 ```
 
-Then yield control. The user's next message will land in `peaks-solo` (in QA validation phase, since the failing tests are the validation surface).
+Then yield control. The user's next message will land in `peaks-code` (in QA validation phase, since the failing tests are the validation surface).
 
 ## Hard rules (do NOT skip)
 
 - **Never silently fix test failures.** The user must choose what to do via `AskUserQuestion`. Silently "auto-fix"ing a failing test would mask the failure.
-- **Never modify source code in this skill.** This is a wrapper. The actual fix (if the user wants one) is `peaks-solo`'s job.
+- **Never modify source code in this skill.** This is a wrapper. The actual fix (if the user wants one) is `peaks-code`'s job.
 - **Never add a new `peaks <cmd>`.** Use only existing primitives: `peaks skill presence:set`, `peaks project memories`, `peaks workspace init` (for the handoff), `peaks request transition` (if going to QA-validation). The actual test command is the project's existing test runner, not a `peaks <cmd>`.
 - **Never trust the test runner's exit code as the only signal.** Some failures print partial success (e.g. 100 passed + 1 failed); the wrapper must show the failures, not just say "exit 0".
 
@@ -80,5 +80,5 @@ Then yield control. The user's next message will land in `peaks-solo` (in QA val
 ## Cross-references
 
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent.
-- `peaks-solo-resume` (sibling wrapper, P2.1) is the workflow-state introspection variant; `peaks-solo-test` is the test-execution variant.
+- `peaks-resume` (sibling wrapper, P2.1) is the workflow-state introspection variant; `peaks-test` is the test-execution variant.
 - The "harness a project-native test runner" pattern is intentionally minimal — the wrapper should NOT add a new CLI for running tests (would violate the dev-preference.md "default-no on new CLI" rule + the user's explicit ask for "skill-first, CLI-auxiliary").

package/skills/peaks-solo/references/command-migration.md

@@ -1,3 +0,0 @@
-# command-migration.md
-
-This reference documents command-migration.md for peaks-solo.