peaks-loop 4.0.0-beta → 4.0.0-beta.2

package/skills/peaks-code/references/openspec-workflow.md

@@ -1,6 +1,6 @@
-# OpenSpec Lifecycle for Peaks Solo
+# OpenSpec Lifecycle for Peaks Code
 
-Peaks Solo orchestrates RD, QA, and SC. When the target repository uses OpenSpec, Solo must drive the full lifecycle through the Peaks CLI so each role works against the same stable surface.
+Peaks Code orchestrates RD, QA, and SC. When the target repository uses OpenSpec, Code must drive the full lifecycle through the Peaks CLI so each role works against the same stable surface.
 
 > **Slice #016 (2026-06-09)**: this document used to live at `openspec-mcp-workflow.md` and contained a section on the `peaks mcp *` lifecycle. The MCP subsystem was retired in slice #016; that section is gone. The OpenSpec lifecycle described below is unchanged.
 
@@ -8,19 +8,19 @@ Peaks Solo orchestrates RD, QA, and SC. When the target repository uses OpenSpec
 
 ```text
 peaks openspec render   →  RD authors a change pack (dry-run, then --apply)
-peaks openspec validate →  Solo gates RD output before slicing starts
+peaks openspec validate →  Code gates RD output before slicing starts
 peaks openspec show     →  any role reads parsed proposal/tasks state
 peaks openspec to-rd    →  RD projects the pack into refactor slice input
                           SC projects it into commit boundary candidates
 peaks openspec validate →  QA gates the final state before sign-off
-peaks openspec archive  →  Solo moves the change under changes/archive/<id>/
+peaks openspec archive  →  Code moves the change under changes/archive/<id>/
 ```
 
-Rules Solo applies:
+Rules Code applies:
 
 - `render --apply` is the only Peaks-managed way to write a change pack. Other roles must not hand-edit `openspec/changes/**`.
 - `validate` is run twice per change in a refactor flow: once before slicing (RD entry gate) and once before archive (QA exit gate). Both must end with `data.valid === true`.
-- `archive --apply` is the lifecycle terminator; Solo only invokes it after QA acceptance and SC commit.
+- `archive --apply` is the lifecycle terminator; Code only invokes it after QA acceptance and SC commit.
 
 ## Refactor workflow wiring
 
@@ -35,27 +35,27 @@ If the consuming LLM needs an MCP server for docs lookup or research (e.g. Conte
 
 ## Boundary
 
-Solo must not write `openspec/changes/**` or `~/.claude/settings.json` directly. Every mutation goes through the CLI commands above. The CLI returns stable envelopes; Solo captures them as artifact links rather than re-explaining their content in the handoff.
+Code must not write `openspec/changes/**` or `~/.claude/settings.json` directly. Every mutation goes through the CLI commands above. The CLI returns stable envelopes; Code captures them as artifact links rather than re-explaining their content in the handoff.
 
 ---
 
 # Step 0.5 — OpenSpec first-run opt-in (conditional)
 
-> Body of `### Peaks-Loop Step 0.5`. After the workspace is anchored, before project scan, Solo checks whether
+> Body of `### Peaks-Loop Step 0.5`. After the workspace is anchored, before project scan, Code checks whether
 the project already has an `openspec/` directory. The lifecycle
 (`render → validate → show → to-rd → validate → archive`) only applies
 when `openspec/` exists; without it, RD/QA/SC silently skip the
 openspec-aware paths and you lose change-proposal tracking, commit
 boundaries from `tasks.md`, and the historical archive.
 
-To make that opt-in visible instead of silent, Solo runs:
+To make that opt-in visible instead of silent, Code runs:
 
 ```bash
 # 1. Detect whether the project already has openspec/.
 ls <repo>/openspec/changes 2>&1
-# 2. If absent, ask the user once — only on the first Solo run in this
+# 2. If absent, ask the user once — only on the first Code run in this
 #    project. The decision is sticky: write it to .peaks/.peaks-openspec-opt-in.json
-#    so subsequent Solo invocations do not re-ask.
+#    so subsequent Code invocations do not re-ask.
 test -f <repo>/.peaks/.peaks-openspec-opt-in.json || \
   echo "{\"enabled\": <bool>}" > <repo>/.peaks/.peaks-openspec-opt-in.json
 ```
@@ -65,11 +65,11 @@ file is missing):
 
 | Option | What it does |
 |---|---|
-| Enable OpenSpec for this project (Recommended) | Run `peaks openspec init --project <repo> --apply`. After that, every Solo run uses the change-proposal lifecycle for the same project. |
-| Skip for now | Do nothing. Solo proceeds without openspec; the question is re-asked on the next first-run detection. |
-| Never ask again for this project | Write `{enabled: false, sticky: true}`. Solo stops asking. The user can re-enable later by removing `.peaks/.peaks-openspec-opt-in.json` and re-running. |
+| Enable OpenSpec for this project (Recommended) | Run `peaks openspec init --project <repo> --apply`. After that, every Code run uses the change-proposal lifecycle for the same project. |
+| Skip for now | Do nothing. Code proceeds without openspec; the question is re-asked on the next first-run detection. |
+| Never ask again for this project | Write `{enabled: false, sticky: true}`. Code stops asking. The user can re-enable later by removing `.peaks/.peaks-openspec-opt-in.json` and re-running. |
 
-The first option is the recommended default because it gives Solo the
+The first option is the recommended default because it gives Code the
 full change-proposal lifecycle (proposal / tasks / design / specs
 deltas, archive on ship, commit boundaries from `tasks.md`). It costs
 only a single scaffolded directory and pays back the first time the
@@ -77,5 +77,5 @@ project needs a real review trail.
 
 If the user picks "Enable", the only required follow-up is to make
 sure `openspec/changes/` is added to git (it is part of the project
-repo, not a tool-managed artefact). Solo does not run `git add` for
+repo, not a tool-managed artefact). Code does not run `git add` for
 the user; that is the user's commit boundary.

package/skills/peaks-code/references/periodic-checkpoint.md

@@ -27,7 +27,7 @@ checkpoint as often as it wants.
 > does **not** expose a `--periodic-every <n>` override flag — the
 > cadence is owned by the skill, not the CLI. Any patch that relaxes
 > this must update both files in lockstep or fail the
-> `tests/unit/solo/checkpoint-periodic-frequency.test.ts` guard.
+> `tests/unit/code/checkpoint-periodic-frequency.test.ts` guard.
 
 ## Checkpoint CLI contract
 
@@ -72,10 +72,10 @@ This step is strictly IDE-agnostic. The LLM calls the peaks CLI; no IDE-specific
 
 ## Companion surface — auto-compact (zero-pause)
 
-When the runner crosses the v2.13.0 auto-compact thresholds (0.85 pre-compact / 0.95 red-line), `peaks session checkpoint` is NOT enough on its own — the LLM must also fire `peaks solo auto-compact --execute` (or wait for the in-band PreToolUse hook at ratio ≥ 0.95 to compact the runner itself). See:
+When the runner crosses the v2.13.0 auto-compact thresholds (0.85 pre-compact / 0.95 red-line), `peaks session checkpoint` is NOT enough on its own — the LLM must also fire `peaks code auto-compact --execute` (or wait for the in-band PreToolUse hook at ratio ≥ 0.95 to compact the runner itself). See:
 
-- `peaks solo auto-compact --execute` — orchestrator that writes the convergence plan + dispatches the compact pathway
+- `peaks code auto-compact --execute` — orchestrator that writes the convergence plan + dispatches the compact pathway
 - `peaks session auto-compact-hook` — the PreToolUse hook entrypoint fired by `.claude/settings.local.json` (slice 2026-07-02-auto-compact-zero-pause)
 - `.peaks/memory/2026-06-27-auto-compact-design.md` — zero-human-intervention design rationale
 
-The two surfaces compose: `peaks session checkpoint` persists the context state, `peaks solo auto-compact` collapses the runner's window. The LLM fires both in the 0.85–0.95 zone; the hook fires alone at ≥ 0.95.
+The two surfaces compose: `peaks session checkpoint` persists the context state, `peaks code auto-compact` collapses the runner's window. The LLM fires both in the 0.85–0.95 zone; the hook fires alone at ≥ 0.95.

package/skills/peaks-code/references/quality-gate-cheatsheet.md

@@ -7,7 +7,7 @@
 | `peaks request lint <rid> --role <role> --project <path>` | Scan artifact body for unfilled `<placeholder>`, bare `- ...` bullets, TBD/TODO markers | Before every transition out of `draft` / before role handoff | Any `error`-severity finding (unfilled placeholder, bare-dot bullet) |
 | `peaks request repair-status <rid> --project <path>` | Count RD↔QA repair cycles from `--reason` transition notes ("QA cycle N: ...") | Before every RD repair iteration in step 7 | Cycle count reached the 3-cycle cap |
 | `peaks scan request-type-sanity --project <path> --type <type>` | Cross-verify declared `--type` against the actual `git diff` file mix (catches "feature mis-declared as docs" workflow violations) | After PRD type lock-in AND after each RD repair iteration | Declared type disagrees with the file mix |
-| `peaks scan libraries --project <path>` | Enumerate every dependency + devDependency + peerDependency + optionalDependency with parsed major version; output goes to `## Library versions` in `rd/project-scan.md`. Read-only. | At Solo step 0.6 (alongside `peaks scan archetype`) | Always exits 0 (warnings in JSON envelope; never blocks) |
+| `peaks scan libraries --project <path>` | Enumerate every dependency + devDependency + peerDependency + optionalDependency with parsed major version; output goes to `## Library versions` in `rd/project-scan.md`. Read-only. | At Code step 0.6 (alongside `peaks scan archetype`) | Always exits 0 (warnings in JSON envelope; never blocks) |
 | `peaks slice check [--rid <rid>] [--project <path>]` | 4-stage slice 边界 check (typecheck + unit-tests + review-fanout + gate-verify-pipeline). Aggregate pass/fail; non-zero exit if any stage fails. See "Slice 边界 check" below for usage rules (boundary only, never inside a micro-cycle). | At slice 边界（post-micro-cycle, pre-peaks-qa）| Any stage fails |
 
 Together with `peaks request transition` (which already CLI-enforces per-type artifact prerequisites), these five commands form the runtime quality net. SKILL.md prose is descriptive; the CLI is what physically blocks bad workflows.

package/skills/peaks-code/references/refactor-mode.md

@@ -1,4 +1,4 @@
-# Peaks Solo Refactor Mode
+# Peaks Code Refactor Mode
 
 `peaks-code refactor` is the primary MVP path.
 

package/skills/peaks-code/references/runbook.md

@@ -60,7 +60,7 @@ peaks request transition <rid> --role prd --state confirmed-by-user --project <r
 peaks request transition <rid> --role prd --state handed-off --project <repo> --json
 
 # 3. Peaks-Loop Default sub-agent fan-out (slice 5 contract)
-#    Solo computes the swarm plan from --type + frontendOnly + frontend-keyword scan,
+#    Code computes the swarm plan from --type + frontendOnly + frontend-keyword scan,
 #    writes it to .peaks/_runtime/<sid>/sc/swarm-plan.json, then writes the slice
 #    DAG to .peaks/_runtime/<sid>/sc/slice-dag.json and launches ONE
 #    `peaks sub-agent dispatch --from-dag <dag-file>` call. The CLI's
@@ -75,10 +75,10 @@ peaks request transition <rid> --role prd --state handed-off --project <repo> --
 #    `peaks sub-agent dispatch <role>` calls in N separate messages when a fan-out
 #    shape exists — `--from-dag` is the only path that exercises the orchestrator.
 #
-# 3a. Pre-fan-out: Solo initialises every role's request artefact slot in the main
+# 3a. Pre-fan-out: Code initialises every role's request artefact slot in the main
 #     loop so sub-agents find a stable rid <-> artefact binding. Each role's
 #     sub-agent may also call peaks request init itself (idempotent on the same rid);
-#     Solo's call here is the source of truth. Only init roles that are in the
+#     Code's call here is the source of truth. Only init roles that are in the
 #     swarm plan — roles not in the plan do not get a slot yet.
 peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-fan-out
 # for each role in swarm-plan.subAgents:
@@ -88,7 +88,7 @@ peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-
 # e.g. if plan = [ui, rd, qa]: run init for ui, rd, qa.
 # If plan = [rd, qa]: run for rd, qa only.
 # If plan = [] (config|docs|chore skip): no inits here, jump to step 4 directly.
-# 3b. Solo writes the slice DAG to a JSON file then issues ONE
+# 3b. Code writes the slice DAG to a JSON file then issues ONE
 #     `peaks sub-agent dispatch --from-dag <dag-file> --batch-id <id>` call.
 #     The CLI envelope returns N parallel buildToolCall descriptors
 #     (dispatchCount = len(swarm-plan.subAgents) when the DAG has >= 2
@@ -98,7 +98,7 @@ peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-
 #     concurrently, so wall-time approximates max(per-leaf time), not sum.
 peaks sc build-dag --change-id <cid> --project <repo> --json > .peaks/_runtime/<sid>/sc/slice-dag.json
 peaks sub-agent dispatch --from-dag .peaks/_runtime/<sid>/sc/slice-dag.json --batch-id <id> --project <repo> --json
-# 3c. After fan-out, Solo restores presence once and runs Gate B (ls checks):
+# 3c. After fan-out, Code restores presence once and runs Gate B (ls checks):
 peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged
 ls .peaks/_runtime/<sid>/prd/requests/<rid>.md                # PRD artefact must exist (Gate B hard)
 # feature / refactor → ls .peaks/_runtime/<sid>/rd/tech-doc.md
@@ -174,7 +174,7 @@ peaks workspace reconcile --project <repo> --apply --older-than 7
 #       (c) Skip for now — blocks stay in the handoff only, no .peaks/memory/ write"
 #      If 10a returned 0 AND the session surfaced a stable project fact
 #      (decision / convention / approved refactor), STOP — peaks-txt must go
-#      back and embed at least one block before Solo can advance.
+#      back and embed at least one block before Code can advance.
 
 # 10c. After the user picks (a) or (b), run:
 peaks memory extract --project <repo> --artifact .peaks/_runtime/<id>/txt/handoff.md --apply --json
@@ -195,13 +195,13 @@ Repair loop details: see `## Mandatory RD QA repair loop` in SKILL.md for the fu
 # Step 0.8 (BLOCKING): LLM judges Job-shape, CLI records it.
 # This is a RECORDER, not a detector. The LLM supplies --is-job + --rationale;
 # the CLI writes .peaks/_runtime/<sid>/job-shape.json. Downstream steps call
-# `peaks solo read-job-shape` to enforce the decision exists.
+# `peaks code read-job-shape` to enforce the decision exists.
 
 # (The LLM does the semantic judgement, e.g.:)
 #   "The user named N=35 parallel app/ subdirs, said 'continue until all done',
 #    and disavowed cost. isJob=true, rationale=..., suggestedJobId=app-ut-batch,
 #    suggestedStrategy=rotating, confidence=high."
-peaks solo detect-job \
+peaks code detect-job \
   --is-job true \
   --rationale "35 parallel app/ subdirs + 'until all done' + '不用考虑费用'" \
   --suggested-job-id app-ut-batch \
@@ -209,7 +209,7 @@ peaks solo detect-job \
   --confidence high
 
 # Step 0.81-init: if Job-shaped, init BEFORE Step 1.
-DECISION=$(peaks solo read-job-shape --json)
+DECISION=$(peaks code read-job-shape --json)
 if [ "$(echo "$DECISION" | jq -r '.data.decision.isJob')" = "true" ]; then
   JID=$(echo "$DECISION" | jq -r '.data.decision.suggestedJobId')
   STRATEGY=$(echo "$DECISION" | jq -r '.data.decision.suggestedStrategy')
@@ -232,18 +232,18 @@ peaks job subagent-cleanup --job-id <jid> --batch-id <bid> --force   # Step 0.87
 
 # v3.1.2 size-fear ban: refuse to emit a final handoff while remaining > 0.
 # The LLM cannot bypass this; --force-under-job requires explicit user approval.
-peaks solo emit-handoff --project <repo> --job-id <jid> --json
+peaks code emit-handoff --project <repo> --job-id <jid> --json
 
 # v3.1.2 forced auto-compact: when --enforce-job-mode is set OR
 # job-shape.json says isJob=true, ≥0.85 is MANDATORY auto-compact.
-# Solo MUST call this without confirmation under Job mode.
-peaks solo context-now --project <repo> --enforce-job-mode --json
+# Code MUST call this without confirmation under Job mode.
+peaks code context-now --project <repo> --enforce-job-mode --json
 peaks session auto-compact --execute --project <repo> --json
 
 # v3.1.2 PreToolUse gate (installed by `peaks workspace init`):
-# every Bash tool call runs `peaks solo gate-step-08` automatically.
+# every Bash tool call runs `peaks code gate-step-08` automatically.
 # Exit 0 = allow (with optional Next: slice #N+1 of M line when
 # progress.json exists). Exit 2 = BLOCKED; LLM must call
-# `peaks solo detect-job` first.
-peaks solo gate-step-08 --project <repo> --json
+# `peaks code detect-job` first.
+peaks code gate-step-08 --project <repo> --json
 ```

package/skills/peaks-code/references/step-0-55-1x-detection.md

@@ -1,6 +1,6 @@
 # Step 0.55 — 1.x → 2.0 detection reference
 
-> Body of `### Peaks-Loop Step 0.55`. Slice: 2026-06-12-solo-step-0-55-1x-detection.
+> Body of `### Peaks-Loop Step 0.55`. Slice: 2026-06-12-code-step-0-55-1x-detection.
 
 ## Why this step exists
 

package/skills/peaks-code/references/step-0-8-gate.md

@@ -1,10 +1,10 @@
-# Peaks-Loop Solo — Step 0.8 (v3.1.1 + v3.1.2) Gate Deep-Dive
+# Peaks-Loop Code — Step 0.8 (v3.1.1 + v3.1.2) Gate Deep-Dive
 
 > Read alongside `SKILL.md` Step 0.8. The SKILL.md header is the LOCKED CONTRACT; this file is the mechanics.
 
-## Recorder contract (`peaks solo detect-job`)
+## Recorder contract (`peaks code detect-job`)
 
-The CLI does NOT judge whether the request is Job-shaped — that is the LLM's job. Keyword regexes are wrong here (too brittle, miss natural-language variants, shift the LLM's semantic understanding into code). The CLI is a **recorder and gate**: the LLM makes the judgement, writes it via `peaks solo detect-job`, and downstream steps refuse to proceed until the decision file exists.
+The CLI does NOT judge whether the request is Job-shaped — that is the LLM's job. Keyword regexes are wrong here (too brittle, miss natural-language variants, shift the LLM's semantic understanding into code). The CLI is a **recorder and gate**: the LLM makes the judgement, writes it via `peaks code detect-job`, and downstream steps refuse to proceed until the decision file exists.
 
 ### LLM judgement criteria (read once, then call the recorder)
 
@@ -16,40 +16,40 @@ The CLI does NOT judge whether the request is Job-shaped — that is the LLM's j
 ### Action sequence
 
 1. LLM reads the user prompt and applies judgement → `isJob: boolean + rationale + suggestedJobId + suggestedStrategy + confidence`.
-2. LLM calls `peaks solo detect-job --is-job <bool> --rationale <text> --suggested-job-id <jid> --suggested-strategy <single|rotating> --confidence <high|medium|low> [--force]`.
+2. LLM calls `peaks code detect-job --is-job <bool> --rationale <text> --suggested-job-id <jid> --suggested-strategy <single|rotating> --confidence <high|medium|low> [--force]`.
 3. CLI records to `.peaks/_runtime/<sessionId>/job-shape.json`.
 4. If `isJob: true` → `peaks job init --job-id <jid> --slice-list <...> --main-loop-strategy <strategy> --rotate-every 3` (BEFORE Step 1).
 5. Downstream steps (Step 1, Step 0.81, etc.) call `read-job-shape` to refuse if missing.
 
 ### Hard rule (v3.1.1 red-line #10)
 
-LLM MUST NOT skip `peaks solo detect-job` even when the trigger is obvious from context. If the next step's `read-job-shape` throws `JOB_SHAPE_NOT_DECIDED`, Solo MUST record a decision before proceeding. Keyword-based "I already know it's a Job" is not a substitute.
+LLM MUST NOT skip `peaks code detect-job` even when the trigger is obvious from context. If the next step's `read-job-shape` throws `JOB_SHAPE_NOT_DECIDED`, Code MUST record a decision before proceeding. Keyword-based "I already know it's a Job" is not a substitute.
 
 ## v3.1.2 mechanical gates
 
 The recorder-only design was bypassed twice under load; the gate must be un-bypassable.
 
-### 1. PreToolUse hook — `peaks solo gate-step-08`
+### 1. PreToolUse hook — `peaks code gate-step-08`
 
-`peaks workspace init` installs the `Bash` matcher `peaks solo gate-step-08 --project .` in `.claude/settings.local.json` (alongside the existing Write|Edit|MultiEdit matcher). The hook runs before every Bash call:
+`peaks workspace init` installs the `Bash` matcher `peaks code gate-step-08 --project .` in `.claude/settings.local.json` (alongside the existing Write|Edit|MultiEdit matcher). The hook runs before every Bash call:
 
 | Condition | Exit | Behaviour |
 |---|---|---|
 | `job-shape.json` exists | 0 (allow) | allow + emit decision; if `progress.json` exists, add `Next: slice #N+1 of M (<currentSlice>)` |
-| `job-shape.json` missing AND prompt matches the fail-closed backup regex | 2 (BLOCKED) | LLM must call `peaks solo detect-job` before retrying |
+| `job-shape.json` missing AND prompt matches the fail-closed backup regex | 2 (BLOCKED) | LLM must call `peaks code detect-job` before retrying |
 | `job-shape.json` missing AND no regex match | 0 (allow) | allow, no Job trigger |
 
-### 2. Size-fear ban — `peaks solo emit-handoff`
+### 2. Size-fear ban — `peaks code emit-handoff`
 
 Refuses to emit a final handoff while `remaining > 0` under Job mode. Pass `--force-under-job` only with explicit user approval.
 
 ### 3. Forced auto-compact — `--enforce-job-mode`
 
-`peaks solo context-now --enforce-job-mode` (auto-enabled when `job-shape.json` says `isJob=true`) returns `action: 'auto-compact-now'` at ≥ 0.85; Solo MUST call `peaks session auto-compact --execute` without confirmation.
+`peaks code context-now --enforce-job-mode` (auto-enabled when `job-shape.json` says `isJob=true`) returns `action: 'auto-compact-now'` at ≥ 0.85; Code MUST call `peaks session auto-compact --execute` without confirmation.
 
 ### 4. On-disk slice progress — `progress.json`
 
-`peaks job checkpoint --state done` writes `progress.json`. `peaks job progress --job-id <jid> [--allow-missing]` is the canonical reader; `peaks solo gate-step-08` also surfaces it on every Bash call so the LLM cannot "wake up cold".
+`peaks job checkpoint --state done` writes `progress.json`. `peaks job progress --job-id <jid> [--allow-missing]` is the canonical reader; `peaks code gate-step-08` also surfaces it on every Bash call so the LLM cannot "wake up cold".
 
 ## Backup regex rationale
 

package/skills/peaks-code/references/sub-agent-dispatch.md

@@ -20,7 +20,7 @@ the skills compose. For sub-agent dispatch the relationship is:
 
 | Surface | Who owns | What it does | Who calls it |
 |---|---|---|---|
-| SKILL.md (主面) | peaks-code, peaks-rd, peaks-qa | Tells the LLM when and why to dispatch a sub-agent; what prompt to pass; what artifacts to expect back | LLM (during normal Solo / RD / QA flow) |
+| SKILL.md (主面) | peaks-code, peaks-rd, peaks-qa | Tells the LLM when and why to dispatch a sub-agent; what prompt to pass; what artifacts to expect back | LLM (during normal Code / RD / QA flow) |
 | CLI (副 / 原子) | `peaks sub-agent dispatch` | Validates the role, looks up the current IDE's `subAgentDispatcher`, returns a per-IDE tool-call descriptor + writes a dispatch record | LLM (read from the SKILL.md) |
 | Dispatcher 抽象 (per-IDE) | `src/services/dispatch/sub-agent-dispatcher.ts` | Encapsulates the IDE-private tool name (claude-code: `Task`, trae: UNVERIFIED placeholder) and arg shape | CLI (called by the CLI) |
 
@@ -278,7 +278,7 @@ When writing a SKILL.md that fans out sub-agents:
 
 ### Sub-agent mechanism (IDE-agnostic dispatch, NOT Skill tool)
 
-> Body of `### Sub-agent mechanism`. **Solo is itself a skill running in the current session. To invoke a role in the Swarm, Solo MUST call the IDE-agnostic dispatch primitive `peaks sub-agent dispatch <role>` — NOT the `Skill` tool, NOT any IDE-private sub-agent literal.** The `Skill` tool is single-stack and blocking; using it for "parallel" work was the v1.x illusion of concurrency. The dispatch CLI is the only mechanism that keeps SKILL.md free of IDE-private tool names and lets the same prompt work on every registered IDE.
+> Body of `### Sub-agent mechanism`. **Code is itself a skill running in the current session. To invoke a role in the Swarm, Code MUST call the IDE-agnostic dispatch primitive `peaks sub-agent dispatch <role>` — NOT the `Skill` tool, NOT any IDE-private sub-agent literal.** The `Skill` tool is single-stack and blocking; using it for "parallel" work was the v1.x illusion of concurrency. The dispatch CLI is the only mechanism that keeps SKILL.md free of IDE-private tool names and lets the same prompt work on every registered IDE.
 
 Each sub-agent dispatch call looks like:
 
@@ -304,21 +304,21 @@ The role's required artefact paths (also see peaks-ui/rd/qa SKILL.md and `refere
 | `rd-planning` | `.peaks/_runtime/<sessionId>/rd/tech-doc.md` (feature/refactor) or `.peaks/_runtime/<sessionId>/rd/bug-analysis.md` (bugfix) | PRD body, project-scan, existing-system, codegraph |
 | `qa-test-cases` | `.peaks/_runtime/<sessionId>/qa/test-cases/<rid>.md` | PRD body, RD planning artefact, project-scan, codegraph |
 
-**Solo launches all sub-agents in the swarm plan in a single message (multiple `peaks sub-agent dispatch` calls in parallel, each followed by execution of the returned toolCall)** — this is what gives real concurrency. Do not sequentialize them. The CLI returns N toolCall descriptors; the LLM fires all N in the same message; the IDE dispatches them concurrently; Solo then waits for all to return, runs `ls` checks against the paths above (Peaks-Loop Gate B), and only then advances to RD implementation.
+**Code launches all sub-agents in the swarm plan in a single message (multiple `peaks sub-agent dispatch` calls in parallel, each followed by execution of the returned toolCall)** — this is what gives real concurrency. Do not sequentialize them. The CLI returns N toolCall descriptors; the LLM fires all N in the same message; the IDE dispatches them concurrently; Code then waits for all to return, runs `ls` checks against the paths above (Peaks-Loop Gate B), and only then advances to RD implementation.
 
 **Hard prohibitions on sub-agents** (also passed in each dispatch prompt):
 
 - Do NOT call `Skill(skill="...")` — sub-agents must not recursively activate skills, that defeats the fan-out.
-- Do NOT call `peaks skill presence:set` — only the main Solo loop owns `.peaks/.active-skill.json`. Sub-agents write to a per-agent marker file `.peaks/_runtime/<sessionId>/system/sub-agent-<role>.json` if they need to record state, but never the main presence file.
-- Do NOT open interactive user prompts. If a sub-agent needs clarification, it must return a `blocked` verdict in its return string and let Solo handle the user message.
-- Do NOT commit, push, install hooks, or apply settings.json mutations. Only Solo holds those permissions.
+- Do NOT call `peaks skill presence:set` — only the main Code loop owns `.peaks/.active-skill.json`. Sub-agents write to a per-agent marker file `.peaks/_runtime/<sessionId>/system/sub-agent-<role>.json` if they need to record state, but never the main presence file.
+- Do NOT open interactive user prompts. If a sub-agent needs clarification, it must return a `blocked` verdict in its return string and let Code handle the user message.
+- Do NOT commit, push, install hooks, or apply settings.json mutations. Only Code holds those permissions.
   - **Reinforced (2026-06-28 incident):** an RD sub-agent silently auto-committed its own diff during a fix-callerid-leak dispatch (commit `bff4dff`). The orchestrator caught the unauthorized commit on the next turn but the user had to manually re-approve. **Every dispatch prompt MUST copy the verbatim block below into its `--prompt` argument** so the sub-agent sees the rule with full weight:
 
     ```
     ## Commit / push policy (verbatim, mandatory)
     - Do NOT run `git commit`, `git push`, `git tag`, `git checkout -b`, or any
       state-mutating git command. Leave the diff on disk and return the
-      diff summary in your final message. The orchestrator (Solo) owns the
+      diff summary in your final message. The orchestrator (Code) owns the
       commit / push decision; it will run `git status` and `git diff` after
       your return and decide whether to commit.
     - If you believe a commit is urgent (e.g. emergency hotfix), return
@@ -327,7 +327,7 @@ The role's required artefact paths (also see peaks-ui/rd/qa SKILL.md and `refere
     ```
 - **Do write heartbeats** — call `peaks sub-agent heartbeat --record <dispatchRecordPath> --status running --progress <pct> --note "<text>"` at least every 30s (see `references/sub-agent-dispatch.md` §G6 for the full contract). The parent Dispatcher uses these to render the live status line during the wait.
 
-After every sub-agent dispatch returns, Solo **restores presence** once (not per-agent), then continues to Gate B verification:
+After every sub-agent dispatch returns, Code **restores presence** once (not per-agent), then continues to Gate B verification:
 
 ```bash
 peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged

package/skills/peaks-code/references/swarm-dispatch-contract.md

@@ -1,6 +1,6 @@
 # Swarm dispatch contract
 
-> Reference for `peaks-code` Swarm phase and the role sub-agents (`peaks-ui` / `peaks-rd` planning / `peaks-qa` test-cases). Defines the **mechanism** of fan-out: how Solo launches sub-agents, what the sub-agent prompt must contain, what the sub-agent must return, and how Solo reduces the result.
+> Reference for `peaks-code` Swarm phase and the role sub-agents (`peaks-ui` / `peaks-rd` planning / `peaks-qa` test-cases). Defines the **mechanism** of fan-out: how Code launches sub-agents, what the sub-agent prompt must contain, what the sub-agent must return, and how Code reduces the result.
 
 ## Peaks-Loop Swarm parallel phase (sub-agent fan-out, default)
 
@@ -18,7 +18,7 @@
 > `references/fanout-mandatory.md`).
 
 The Swarm phase is the **default** for any DAG with ≥ 2 leaves at
-the same topological level. Solo derives the fan-out set from the
+the same topological level. Code derives the fan-out set from the
 DAG topology — not from a default of "always launch three", and
 not from a strict conditional check. The swarm gate (PRD state +
 request type + frontend touch), mode-driven fan-out shape, and
@@ -28,7 +28,7 @@ degradation rules live in the references file.
 
 The previous "Swarm" used `Skill(skill="peaks-rd")` calls. That is **single-stack and blocking** — there is no concurrency. Three sequential `Skill` calls run in order on the same main loop, not in parallel. The "parallel Agent calls" wording in the old SKILL.md was a v1.x illusion.
 
-This contract (slice #009) replaces the IDE-private sub-agent literal with the IDE-agnostic primitive `peaks sub-agent dispatch <role>`. The CLI returns a JSON `data.toolCall` descriptor; the LLM executes that tool in its own environment. SKILL.md is now free of IDE-private tool names and the same prompt works on every registered IDE. Real concurrent fan-out is achieved by Solo launching N dispatch calls in a single message and the platform scheduling the returned toolCalls concurrently.
+This contract (slice #009) replaces the IDE-private sub-agent literal with the IDE-agnostic primitive `peaks sub-agent dispatch <role>`. The CLI returns a JSON `data.toolCall` descriptor; the LLM executes that tool in its own environment. SKILL.md is now free of IDE-private tool names and the same prompt works on every registered IDE. Real concurrent fan-out is achieved by Code launching N dispatch calls in a single message and the platform scheduling the returned toolCalls concurrently.
 
 ```
 You are a sub-agent invoked by peaks-code. You are NOT the main Claude session.
@@ -43,7 +43,7 @@ Return a compact JSON envelope — do not write prose.
 - Do NOT ask the user interactive questions. If you need clarification, return
   {"status":"blocked","blockedReason":"<text>"} and let the main loop handle it.
 
-## Runtime arguments (provided by Solo)
+## Runtime arguments (provided by Code)
 - project: <repo>            (git repo root, NOT a sub-package)
 - session-id: <sid>          (from .peaks/.active-skill.json or .peaks/.session.json)
 - request-id: <rid>          (PRD id)
@@ -52,7 +52,7 @@ Return a compact JSON envelope — do not write prose.
 - project-scan-path: <path>  (read this for component library / CSS / build tool)
 - existing-system-path: <path>  (legacy projects only)
 - frontendOnly: <bool>       (from project-scan)
-- frontendKeywordHit: <bool> (Solo's PRD scan result)
+- frontendKeywordHit: <bool> (Code's PRD scan result)
 ```
 
 ### 3.2 peaks-ui sub-agent prompt
@@ -82,7 +82,7 @@ Steps:
    }
 
 If you determine the request is non-visual (no UI surface, no design impact),
-return {"status":"skipped","reason":"non-frontend-request"} so Solo can record
+return {"status":"skipped","reason":"non-frontend-request"} so Code can record
 the misfire in sc/swarm-plan.json.
 ```
 
@@ -97,7 +97,7 @@ Steps:
 1. peaks request init --role rd --id <rid> --project <repo> --apply --type <type> --json
 2. peaks request show <rid> --role prd --project <repo> --json
 3. peaks request show <rid> --role ui  --project <repo> --json  (if ui in plan)
-4. Read <project-scan-path>. If absent and Solo did not pre-create it, create it
+4. Read <project-scan-path>. If absent and Code did not pre-create it, create it
    by running `peaks scan archetype --project <repo> --json` and copying the JSON
    into rd/project-scan.md.
 5. Read <existing-system-path> if archetype is legacy-*.
@@ -144,9 +144,9 @@ If --type is docs|chore, return {"status":"skipped","reason":"type=<type>"} —
 no acceptance surface to plan tests for.
 ```
 
-## 4. Reducer (Solo side)
+## 4. Reducer (Code side)
 
-After all sub-agent dispatch calls return and the LLM has invoked the toolCalls, Solo:
+After all sub-agent dispatch calls return and the LLM has invoked the toolCalls, Code:
 
 1. Restores presence ONCE (not per-agent):
    ```
@@ -158,9 +158,9 @@ After all sub-agent dispatch calls return and the LLM has invoked the toolCalls,
 
 ## 5. Presence restoration (single-shot)
 
-Sub-agents are explicitly forbidden from calling `peaks skill presence:set`. That means `.peaks/.active-skill.json` does not move during the fan-out. Solo sets it to `gate=swarm-fan-out` before fan-out and to `gate=swarm-converged` once after all Tasks return. The status header (the `Peaks-Loop Skill: peaks-code | Peaks-Loop Gate: <gate>` line) therefore reads consistently across the fan-out window.
+Sub-agents are explicitly forbidden from calling `peaks skill presence:set`. That means `.peaks/.active-skill.json` does not move during the fan-out. Code sets it to `gate=swarm-fan-out` before fan-out and to `gate=swarm-converged` once after all Tasks return. The status header (the `Peaks-Loop Skill: peaks-code | Peaks-Loop Gate: <gate>` line) therefore reads consistently across the fan-out window.
 
-If a sub-agent is misbehaving and writes to `.peaks/.active-skill.json` anyway, the next Solo presence-set (after fan-out) overwrites it — the bug self-heals on the next gate advance, but the swarm-phase display may be off. The hard prohibition is there to prevent this; Solo should still treat the file as a single-writer resource.
+If a sub-agent is misbehaving and writes to `.peaks/.active-skill.json` anyway, the next Code presence-set (after fan-out) overwrites it — the bug self-heals on the next gate advance, but the swarm-phase display may be off. The hard prohibition is there to prevent this; Code should still treat the file as a single-writer resource.
 
 ## 6. Why not a `peaks-swarm` skill?
 
@@ -177,7 +177,7 @@ A skill cannot itself trigger sub-agents — the Skill tool runs in the main loo
 
 ### Swarm gate (decide BEFORE fan-out)
 
-> Body of `### Swarm gate`. Before launching any sub-agent, Solo must compute the **swarm plan** from three signals:
+> Body of `### Swarm gate`. Before launching any sub-agent, Code must compute the **swarm plan** from three signals:
 
 1. **PRD state** — `prd/requests/<rid>.md` must be in state `confirmed-by-user` or `handed-off`. If not, STOP. The Swarm is downstream of PRD, not a substitute for it.
 2. **Request type** (`--type` from `peaks request init`):
@@ -188,7 +188,7 @@ A skill cannot itself trigger sub-agents — the Skill tool runs in the main loo
    - **AND** scanning the PRD body for frontend keywords: 页面 / 组件 / 表单 / 弹窗 / 表格 / 样式 / 布局 / 交互 / UI / UX / page / component / form / modal / table / styling / layout / interaction
    - UI joins the swarm when (a) is `true` OR (b) matches. Both signals required `false` to skip UI.
 
-Solo records the swarm plan in `.peaks/_runtime/<sessionId>/sc/swarm-plan.json` so SC and TXT can audit what was launched:
+Code records the swarm plan in `.peaks/_runtime/<sessionId>/sc/swarm-plan.json` so SC and TXT can audit what was launched:
 
 ```json
 {
@@ -200,26 +200,26 @@ Solo records the swarm plan in `.peaks/_runtime/<sessionId>/sc/swarm-plan.json`
 }
 ```
 
-Sub-agent presence in this list = Solo launched a Task for it. Absence = the role was skipped with documented reason.
+Sub-agent presence in this list = Code launched a Task for it. Absence = the role was skipped with documented reason.
 
 ### Mode-driven fan-out shape
 
 > Body of `### Mode-driven fan-out shape`.
 
-| Mode | How the swarm plan is decided | What Solo does |
+| Mode | How the swarm plan is decided | What Code does |
 |---|---|---|
 | `full-auto` | Compute plan from signals above, no question to user | Auto-launch all sub-agents in the plan in parallel |
 | `swarm` | Same as `full-auto` | Same as `full-auto` (this profile name is historical — behavior is identical) |
 | `assisted` | `AskUserQuestion` with three options: (a) Full — UI + RD(planning) + QA(test-cases); (b) Backend-only — RD(planning) + QA(test-cases); (c) Sequential — run RD first, then QA, skip UI | Use the user's choice as the plan |
 | `strict` | Same as `assisted` (the question is informational; strict still enforces confirmation gates later) | Same as `assisted` |
 
-In all modes, **the plan must be written to `sc/swarm-plan.json` before any Task call.** Solo updates `.peaks/.active-skill.json` to `gate=swarm-fan-out` at this point.
+In all modes, **the plan must be written to `sc/swarm-plan.json` before any Task call.** Code updates `.peaks/.active-skill.json` to `gate=swarm-fan-out` at this point.
 
 ### Degradation when swarm roles fail or are absent
 
 > Body of `### Degradation when swarm roles fail or are absent`.
 
-| Condition | Solo action | TXT handoff note |
+| Condition | Code action | TXT handoff note |
 |---|---|---|
 | UI sub-agent returns blocked/error | RD continues with PRD visual descriptions | `ui-design-missing` |
 | RD planning sub-agent returns blocked/error | RD continues with PRD-derived planning | `tech-doc-missing` |

package/skills/peaks-code/references/workflow-gates-and-types.md

@@ -1,6 +1,6 @@
 # Peaks-Loop Workflow Order + Request Type Classification + Transition Verification Gates
 
-> **Maintenance**: This reference holds the canonical contract for (a) how Solo sequences the 11 workflow steps, (b) which `--type` to pass to `peaks request init` for which slice shape, and (c) the executable `ls` / `grep` gate commands that physically block progression. SKILL.md keeps the narrative ("what peaks-code does"); this file keeps the contract.
+> **Maintenance**: This reference holds the canonical contract for (a) how Code sequences the 11 workflow steps, (b) which `--type` to pass to `peaks request init` for which slice shape, and (c) the executable `ls` / `grep` gate commands that physically block progression. SKILL.md keeps the narrative ("what peaks-code does"); this file keeps the contract.
 >
 > **Why extracted from SKILL.md**: this content is 165 lines of mostly-tabular + bash-block contract — reference data, not orchestration prose. Inlining it bloats SKILL.md past the 800-line cap (per `common/coding-style.md`). The numbers, gate command shapes, and type-classification rules change rarely; the SKILL.md prose around them (orchestration flow, repair-loop intent, swarm fan-out shape) changes more often.
 >
@@ -25,7 +25,7 @@ Before initializing any role artifact, classify the request into exactly one of
 
 For ambiguous cases (e.g. "improve login flow"), ask the user to clarify before initializing. The cost of one `AskUserQuestion` round is much lower than running the wrong gate matrix for the whole workflow.
 
-When Peaks-Loop Solo coordinates development in a code repository, keep this order explicit:
+When Peaks-Loop Code coordinates development in a code repository, keep this order explicit:
 
 0. **Peaks-Loop Snapshot** — `peaks doctor` + `peaks project dashboard` to capture baseline state before anything else;
 0.5. **Peaks-Loop Workspace initialization** — `.peaks/_runtime/<session-id>/` created, directory structure verified;

package/skills/peaks-code/references/workflow.md

@@ -1,17 +1,17 @@
-# Peaks Solo Workflow
+# Peaks Code Workflow
 
-Peaks Solo is a facade over role skills. It keeps the workflow moving without absorbing role-specific responsibility.
+Peaks Code is a facade over role skills. It keeps the workflow moving without absorbing role-specific responsibility.
 
 ## Modes
 
-- Solo: default, single controller with soft gates.
+- Code: default, single controller with soft gates.
 - Assisted: role skills contribute artifacts without broad swarm execution.
 - Swarm: multiple subagents work in parallel when the CLI-managed profile is enabled.
 - Strict: hook/profile guarded mode for high-risk work.
 
 ## Required code workflow evidence
 
-A code workflow is not complete until Solo has linked or summarized:
+A code workflow is not complete until Code has linked or summarized:
 
 1. standards preflight;
 2. PRD/RD scope and OpenSpec artifacts when required;
@@ -31,7 +31,7 @@ For legacy repositories with pre-existing low UT coverage, do not require histor
 
 ## RD QA loop
 
-Every RD implementation or repair slice must be followed by QA validation. If QA does not fully pass, Solo routes the report back to RD, then repeats RD repair and QA validation until QA is all green or the workflow is blocked. In full-auto mode, Claude Code's `goal` command may be used to keep the controller objective explicit while Peaks artifacts remain authoritative.
+Every RD implementation or repair slice must be followed by QA validation. If QA does not fully pass, Code routes the report back to RD, then repeats RD repair and QA validation until QA is all green or the workflow is blocked. In full-auto mode, Claude Code's `goal` command may be used to keep the controller objective explicit while Peaks artifacts remain authoritative.
 
 ## Capability discovery
 

package/skills/peaks-resume/SKILL.md

@@ -3,9 +3,9 @@ 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-code` 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-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.
 

package/skills/peaks-status/SKILL.md

@@ -3,9 +3,9 @@ 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-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.
+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-code` if the user wants to act on the status).
 

package/skills/peaks-test/SKILL.md

@@ -3,9 +3,9 @@ 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-code 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-code` if the user wants to act on the result).