peaks-loop 3.1.2 → 4.0.0-beta.2

package/skills/{peaks-solo → peaks-code}/references/runbook.md

@@ -1,11 +1,11 @@
 # Peaks-Loop Default Runbook (orchestrator, full-auto profile)
 
-> **Maintenance**: The numbered workflow list in `skills/peaks-solo/SKILL.md` (steps 0-11) is the canonical phase sequence. This runbook is the executable CLI transcription. When updating, keep both in lockstep — a change to one must be reflected in the other.
+> **Maintenance**: The numbered workflow list in `skills/peaks-code/SKILL.md` (steps 0-11) is the canonical phase sequence. This runbook is the executable CLI transcription. When updating, keep both in lockstep — a change to one must be reflected in the other.
 >
 > **Why this is a reference, not inline**: the runbook is a stable, copy-pasteable shell (~150 lines of bash) that does not change between skill runs. Inlining it bloats the orchestrator skill body past the 800-line cap (per `common/coding-style.md`). Extracting it here keeps SKILL.md focused on flow / decisions / contracts, while the runbook stays as the canonical place for the CLI sequence.
 >
 > **How peaks-loop tooling reads this file**:
-> - `peaks skill runbook peaks-solo` (CLI) reads the `## Default runbook` section in either SKILL.md or `references/runbook.md` (whichever has the bash code).
+> - `peaks skill runbook peaks-code` (CLI) reads the `## Default runbook` section in either SKILL.md or `references/runbook.md` (whichever has the bash code).
 > - The test in `tests/unit/skill-default-runbook.test.ts` looks for `## Default runbook` in SKILL.md first, then falls back to `references/runbook.md` here.
 
 ## Default runbook — CLI sequence
@@ -22,7 +22,7 @@ peaks sub-agent dispatch <role> --prompt "<body>" --request-id <rid> --batch-id
 # 0. Peaks-Loop Snapshot + 0.5 Peaks-Loop Workspace + 0.6 Peaks-Loop Project scan + 0.7 Peaks-Loop Existing-system extraction
 peaks doctor --json
 peaks project dashboard --project <repo> --json
-peaks skill runbook peaks-solo --json
+peaks skill runbook peaks-code --json
 peaks workspace init --project <repo> --json
 peaks workspace reconcile --project <repo> --json
 peaks scan archetype --project <repo> --json
@@ -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,12 +75,12 @@ 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-solo --project <repo> --mode <mode> --gate swarm-fan-out
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-fan-out
 # for each role in swarm-plan.subAgents:
 # peaks request init --role ui --id <rid> --project <repo> --apply --type <type> --json
 # peaks request init --role rd --id <rid> --project <repo> --apply --type <type> --json
@@ -88,7 +88,7 @@ peaks skill presence:set peaks-solo --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,8 +98,8 @@ peaks skill presence:set peaks-solo --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):
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-converged
+# 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
 # bugfix             → ls .peaks/_runtime/<sid>/rd/bug-analysis.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-solo → peaks-code}/references/skill-presence-and-title.md

@@ -7,7 +7,7 @@
 Step 0 already set presence with no mode. Now that the mode is known (user selected or explicitly named), re-run presence:set so the header/status line shows the profile:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode-value> --gate startup
+peaks skill presence:set peaks-code --project <repo> --mode <mode-value> --gate startup
 ```
 
 On the first presence:set in a project, ensure the out-of-band status bar is installed so the user can see at a glance that Peaks is orchestrating — it renders the active skill in Claude Code's terminal status line, independent of model output:
@@ -16,9 +16,9 @@ On the first presence:set in a project, ensure the out-of-band status bar is ins
 peaks statusline install --project <repo>   # idempotent; skips if already installed
 ```
 
-Then display the compact status header: `Peaks-Loop Skill: peaks-solo | Peaks-Loop Gate: startup | Next: <one short action>`. Display this header on EVERY turn while the skill is active.
+Then display the compact status header: `Peaks-Loop Skill: peaks-code | Peaks-Loop Gate: startup | Next: <one short action>`. Display this header on EVERY turn while the skill is active.
 
-Update with `peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <gate>` when gates change. The presence file persists across the full workflow lifecycle — do NOT clear it at workflow end.
+Update with `peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <gate>` when gates change. The presence file persists across the full workflow lifecycle — do NOT clear it at workflow end.
 
 ## Step 2.5 — Set session title
 

package/skills/{peaks-solo → peaks-code}/references/standards-preflight.md

@@ -13,7 +13,7 @@ Use `standards init` for first-time creation and `standards update` for existing
 
 Do not hand-write standards file mutations inside the skill.
 
-For project-analysis requests such as "分析项目" / "分析下这个项目", Step 0 still applies: the workspace is initialized and `peaks-solo` presence is set before any analysis output. These requests run the lightweight analysis branch (project scan + standards dry-run) rather than the full RD/QA pipeline, but they never skip workspace anchoring or exit the workflow. The handoff must include an explicit **Standards increment** section. Report the current `CLAUDE.md` and `.claude/rules/**` status from the dry-run output as incremental deltas, not just a generic preflight note:
+For project-analysis requests such as "分析项目" / "分析下这个项目", Step 0 still applies: the workspace is initialized and `peaks-code` presence is set before any analysis output. These requests run the lightweight analysis branch (project scan + standards dry-run) rather than the full RD/QA pipeline, but they never skip workspace anchoring or exit the workflow. The handoff must include an explicit **Standards increment** section. Report the current `CLAUDE.md` and `.claude/rules/**` status from the dry-run output as incremental deltas, not just a generic preflight note:
 
 - whether `CLAUDE.md` is missing, existing, planned, skipped, appended, or review-only;
 - which `.claude/rules/**` files are planned, existing, skipped, appended, or review-only;

package/skills/{peaks-solo → 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
 
@@ -8,9 +8,9 @@ The peaks-loop 1.x → 2.0 closeout ships:
 
 1. A postinstall that auto-detects 1.x state and dispatches the upgrade (slice 1, commit `b6e34e6`).
 2. A standards-migrate path that thins `.claude/rules/**/*.md` and scaffolds `.peaks/standards/` (slice 2, commit `33dd392`).
-3. **THIS STEP** — a peaks-solo startup sequence probe that detects 1.x state when the user invokes `/peaks-solo` directly in a 1.x consumer project, and prompts the user to upgrade.
+3. **THIS STEP** — a peaks-code startup sequence probe that detects 1.x state when the user invokes `/peaks-code` directly in a 1.x consumer project, and prompts the user to upgrade.
 
-The 1.x user experience is: "I just typed /peaks-solo. Why is it not working in 2.0 mode?" Step 0.55 catches this case and surfaces an `AskUserQuestion` with a one-click upgrade.
+The 1.x user experience is: "I just typed /peaks-code. Why is it not working in 2.0 mode?" Step 0.55 catches this case and surfaces an `AskUserQuestion` with a one-click upgrade.
 
 ## Detection algorithm
 
@@ -35,7 +35,7 @@ The CLI returns:
   },
   "warnings": [],
   "nextActions": [
-    "Detected 1.x state. peaks-solo Step 0.55 should present an AskUserQuestion to invoke `peaks upgrade --to 2.0 --auto --project /path/to/project`."
+    "Detected 1.x state. peaks-code Step 0.55 should present an AskUserQuestion to invoke `peaks upgrade --to 2.0 --auto --project /path/to/project`."
   ]
 }
 ```
@@ -52,8 +52,8 @@ The TS mirror in `src/services/upgrade/1x-detector-service.ts` is the canonical
 
 | Option | What it does |
 |---|---|
-| Run `peaks upgrade --to 2.0 --auto --project <root>` (Recommended) | Invokes the umbrella. The user sees the 6 sub-step results in the terminal. After the upgrade, re-run peaks-solo with the standing 2.0 layout. Persist `autoUpgradePrompt: opt-in` to `.peaks/preferences.json`. |
-| Skip for this session | Continue with the standing 1.x layout. Persist `autoUpgradePrompt: skip-this-session` to `.peaks/preferences.json`. The next time the user invokes peaks-solo in this project, the question re-asks. |
+| Run `peaks upgrade --to 2.0 --auto --project <root>` (Recommended) | Invokes the umbrella. The user sees the 6 sub-step results in the terminal. After the upgrade, re-run peaks-code with the standing 2.0 layout. Persist `autoUpgradePrompt: opt-in` to `.peaks/preferences.json`. |
+| Skip for this session | Continue with the standing 1.x layout. Persist `autoUpgradePrompt: skip-this-session` to `.peaks/preferences.json`. The next time the user invokes peaks-code in this project, the question re-asks. |
 | Never ask again for this project | Persist `autoUpgradePrompt: skip-forever` to `.peaks/preferences.json`. Step 0.55 becomes a no-op for this project from now on. The user can re-enable later by removing the `autoUpgradePrompt` key from preferences.json. |
 
 ## Persistence contract

package/skills/{peaks-solo → 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-solo → peaks-code}/references/sub-agent-dispatch.md

@@ -1,7 +1,7 @@
 # sub-agent-dispatch.md — peaks sub-agent dispatch orchestrator contract
 
 > **Slice**: 2026-06-07-sub-agent-dispatch-decouple (G3 + G6)
-> **Audience**: SKILL.md authors and LLM readers of peaks-solo / peaks-rd / peaks-qa
+> **Audience**: SKILL.md authors and LLM readers of peaks-code / peaks-rd / peaks-qa
 > **Status**: stable
 
 This reference is the orchestrator-side contract for sub-agent dispatch.
@@ -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-solo, 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) |
 
@@ -157,7 +157,7 @@ system is dead. G6 is the rule that says: **no**.
 | Layer | Who | What | Cadence |
 |---|---|---|---|
 | **Sub-agent writes** | The sub-agent itself | Calls `peaks sub-agent heartbeat --record <dispatchRecordPath> --status <state> --progress <pct> --note "<text>"` to append a heartbeat | 30 s default; SKILL.md can override via `heartbeatIntervalSec: 15` |
-| **Dispatcher reads** | peaks-solo main loop, during the batch-sync wait | In-process async poller (`BatchHeartbeatPoller`) reads `heartbeats[]` + `lastBeatAt` from each record, emits a single-line status per G6.5 | 10 s (offset from 30 s to avoid jitter) |
+| **Dispatcher reads** | peaks-code main loop, during the batch-sync wait | In-process async poller (`BatchHeartbeatPoller`) reads `heartbeats[]` + `lastBeatAt` from each record, emits a single-line status per G6.5 | 10 s (offset from 30 s to avoid jitter) |
 | **User / CLI reads** | Anyone, anytime | `peaks sub-agent list --session-id <sid> --json` (G5 RL-10, future slice) | manual |
 
 ### Sub-agent prompt template (heartbeat-aware + MCP-decoupled)
@@ -207,10 +207,10 @@ add it explicitly.
 Single line, 80-120 chars:
 
 ```
-[peaks-solo] swarm 3/3 running | rd-planning 45% (12s ago) | qa-test-cases 30% (5s ago) | ui-design 20% (2s ago)
-[peaks-solo] swarm 3/3 running | rd-planning 70% (8s ago) | qa-test-cases 50% (3s ago) | ui-design 30% (6s ago)
+[peaks-code] swarm 3/3 running | rd-planning 45% (12s ago) | qa-test-cases 30% (5s ago) | ui-design 20% (2s ago)
+[peaks-code] swarm 3/3 running | rd-planning 70% (8s ago) | qa-test-cases 50% (3s ago) | ui-design 30% (6s ago)
 ...
-[peaks-solo] swarm 3/3 done
+[peaks-code] swarm 3/3 done
 ```
 
 If a sub-agent has not written a heartbeat in 5 minutes, the poller
@@ -231,7 +231,7 @@ once the poller has read them.
 
 - AC-33 `peaks sub-agent heartbeat` CLI primitive (implemented)
 - AC-34 Dispatch record schema upgrade (`heartbeats[]` + `lastBeatAt` + `status` aggregate, backward-compat defaults)
-- AC-35 peaks-solo main loop batch-sync poller (10 s cadence, 5 min stale)
+- AC-35 peaks-code main loop batch-sync poller (10 s cadence, 5 min stale)
 - AC-36 SKILL.md fan-out sections include heartbeat instruction
 - AC-37 G6 E2E dogfood (3 heartbeats, 101 → truncated, stale simulation)
 
@@ -243,7 +243,7 @@ once the poller has read them.
 - AC-10: dispatch CLI unit tests
 - AC-11 / AC-11b / AC-11c: E2E dogfood on the live repo
 - AC-12: `peaks --help` byte-level delta is `+1` line (`sub-agent <cmd>`)
-- AC-13..AC-19: SKILL.md fan-out rewrites (peaks-solo 5 spots, peaks-rd 2, peaks-qa 3-way, peaks-ui 1; this reference is the canonical contract)
+- AC-13..AC-19: SKILL.md fan-out rewrites (peaks-code 5 spots, peaks-rd 2, peaks-qa 3-way, peaks-ui 1; this reference is the canonical contract)
 - AC-22..AC-24: R-2 path guard, prompt size limit, atomic write
 - AC-25..AC-32: G5 resource lifecycle (RL-1 batch counter, dispatch record schema, reducer dispose, slice archive, cancel dispose)
 - AC-33..AC-37: G6 heartbeat CLI, schema, poller, status line, E2E
@@ -271,14 +271,14 @@ When writing a SKILL.md that fans out sub-agents:
 - RD request #009 in-scope files (implementation contract)
 - `.peaks/memory/sub-agent-resource-lifecycle-red-line.md` (G5 red line)
 - `.peaks/memory/sub-agent-heartbeat-progress-red-line.md` (G6 red line)
-- `skills/peaks-solo/references/swarm-dispatch-contract.md` (predecessor contract)
+- `skills/peaks-code/references/swarm-dispatch-contract.md` (predecessor contract)
 - `skills/peaks-qa/references/qa-fanout-contract.md` (QA-specific fan-out)
 
 ---
 
 ### 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,8 +327,8 @@ 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-solo --project <repo> --mode <mode> --gate swarm-converged
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged
 ```

package/skills/{peaks-solo → peaks-code}/references/swarm-dispatch-contract.md

@@ -1,12 +1,12 @@
 # Swarm dispatch contract
 
-> Reference for `peaks-solo` 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)
 
 > **Slice 5 (2026-06-23) + slice 2026-06-23-audit-4th #F3:** the
 > previous "conditional swarm" framing is replaced by the **default
-> fan-out rule** in `skills/peaks-solo/SKILL.md` §"Peaks-Loop Default
+> fan-out rule** in `skills/peaks-code/SKILL.md` §"Peaks-Loop Default
 > sub-agent fan-out". When the slice DAG has ≥ 2 leaves at the same
 > topological level, dispatch goes through
 > `peaks sub-agent dispatch --from-dag` (NOT one-at-a-time). The
@@ -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,10 +28,10 @@ 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-solo. You are NOT the main Claude session.
+You are a sub-agent invoked by peaks-code. You are NOT the main Claude session.
 Your job: execute ONE role from the peaks skill family and write its artefact(s).
 Return a compact JSON envelope — do not write prose.
 
@@ -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,13 +144,13 @@ 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):
    ```
-   peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-converged
+   peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged
    ```
 2. Runs `ls` checks against `sc/swarm-plan.json` — every promised artefact must exist (Gate B hard). If any are missing, apply the degradation rules in "Degradation when swarm roles fail or are absent" (main SKILL.md).
 3. Updates `sc/swarm-plan.json` with the final status of each sub-agent (ok / blocked / skipped / error).
@@ -158,26 +158,26 @@ 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-solo | 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?
 
-A skill cannot itself trigger sub-agents — the Skill tool runs in the main loop. The orchestrator (peaks-solo) has to be in the main loop and has to call `peaks sub-agent dispatch` directly. Putting swarm logic into a separate skill would either re-introduce the "single-stack blocking" anti-pattern or require a custom slash command that bypasses the Skill tool. The current design keeps swarm control in peaks-solo where it belongs.
+A skill cannot itself trigger sub-agents — the Skill tool runs in the main loop. The orchestrator (peaks-code) has to be in the main loop and has to call `peaks sub-agent dispatch` directly. Putting swarm logic into a separate skill would either re-introduce the "single-stack blocking" anti-pattern or require a custom slash command that bypasses the Skill tool. The current design keeps swarm control in peaks-code where it belongs.
 
 ## 7. Tests / dogfood
 
 - `peaks scan archetype --project <repo> --json` must keep emitting `frontendOnly` and `frontendOnlyReason`. Both fields are read here and by the existing pre-RD scan contract.
 - `peaks request show <rid> --role prd --json` must surface the `--type` chosen at `peaks request init`. Sub-agents pass it through unchanged.
 - `peaks skill presence:set` must remain single-writer-friendly (the sub-agents do not call it).
-- Smoke test: a full-auto peaks-solo run on a `legacy-frontend` project with a UI-affecting PRD should produce `sc/swarm-plan.json` containing all three sub-agents and three corresponding artefacts in `ui/`, `rd/`, `qa/`.
+- Smoke test: a full-auto peaks-code run on a `legacy-frontend` project with a UI-affecting PRD should produce `sc/swarm-plan.json` containing all three sub-agents and three corresponding artefacts in `ui/`, `rd/`, `qa/`.
 
 ---
 
 ### 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-solo → peaks-code}/references/workflow-gates-and-types.md

@@ -1,11 +1,11 @@
 # 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-solo 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.
 >
 > **How peaks-loop tooling reads this file**:
-> - `peaks skill runbook peaks-solo` (CLI) and the in-line LLM reading the SKILL.md should reference this file when the gate-machine or type-classification contract is in play.
+> - `peaks skill runbook peaks-code` (CLI) and the in-line LLM reading the SKILL.md should reference this file when the gate-machine or type-classification contract is in play.
 > - The test `tests/unit/skill-default-runbook.test.ts` does NOT check this file (it only checks the runbook). Future tests can add a similar fallback for the gates-and-types contract.
 
 ## Peaks-Loop Request type classification (MANDATORY before `peaks request init`)
@@ -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;
@@ -170,7 +170,7 @@ find . -maxdepth 1 -name "*.png" -o -name "*.jpg" -o -name "qa-*.js" -o -name "m
 ```bash
 # After `peaks standards init/update --apply`, verify the files actually landed
 # at the project root. The CLAUDE.md and rules files are required so that
-# subsequent peaks-rd / peaks-qa / peaks-solo runs perform the project-local
+# subsequent peaks-rd / peaks-qa / peaks-code runs perform the project-local
 # preflight described in CLAUDE.md (read coding-style.md, code-review.md, security.md).
 ls <repo>/CLAUDE.md
 # "No such file" → BLOCKED. Run `peaks standards init --project <repo> --apply --json`

package/skills/{peaks-solo → 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