peaks-loop 3.1.1 → 4.0.0-beta

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

@@ -41,7 +41,7 @@ On completion:
 ### Main LLM reducer view (G7.4.e)
 
 ```
-[peaks-solo] batch 3/3 done in 47.3s
+[peaks-code] batch 3/3 done in 47.3s
 - rd → .peaks/_sub_agents/2026-06-06-session-5b1095/artifacts/003-rd-001.md (12KB, sha256:abc123) summary: "wrote RD tech-doc with 4 sub-roles and dispatcher interface"
 - qa-business → .../artifacts/003-qa-business-001.md (8KB, sha256:def456) summary: "wrote 12 API test cases covering happy + 3 error paths"
 - qa-perf → .../artifacts/003-qa-perf-001.md (5KB, sha256:ghi789) summary: "wrote perf baseline; p95 latency target ≤ 200ms"
@@ -165,7 +165,7 @@ PROTOCOL (mandatory):
 
 Main LLM view format (G7.4.e):
 ```
-[peaks-solo] batch 3/3 done in 47.3s
+[peaks-code] batch 3/3 done in 47.3s
 - rd → .peaks/_sub_agents/2026-06-06-session-5b1095/artifacts/003-rd-001.md (12KB, sha256:abc123) summary: "wrote RD tech-doc with 4 sub-roles"
 - qa-business → .../artifacts/003-qa-business-001.md (8KB, sha256:def456) summary: "wrote 12 API test cases"
 - qa-perf → .../artifacts/003-qa-perf-001.md (5KB, sha256:ghi789) summary: "p95 latency target ≤ 200ms"

package/skills/{peaks-solo → peaks-code}/references/frontend-only-mode.md

@@ -1,6 +1,6 @@
 # Peaks-Loop Frontend-only development mode
 
-> Extracted from `skills/peaks-solo/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Frontend-only development mode section that was previously inline; nothing was paraphrased, just relocated.
+> Extracted from `skills/peaks-code/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Frontend-only development mode section that was previously inline; nothing was paraphrased, just relocated.
 
 When the project has no live backend (no swagger.json, no API server), Solo must activate frontend-only mode.
 

package/skills/{peaks-solo → peaks-code}/references/local-artifact-workspace.md

@@ -28,7 +28,7 @@ The workspace initialization creates this structure under `.peaks/`:
 # --active --json` (and the matching read-only primitives for the
 # other two) to discover session-id / active-skill / sop-state.
 .peaks/_runtime/
-├── active-skill.json   # orchestrator presence marker (peaks-solo / -rd / -qa / -ui / -sc / -sop / -txt)
+├── active-skill.json   # orchestrator presence marker (peaks-code / -rd / -qa / -ui / -sc / -sop / -txt)
 ├── session.json        # project → session binding (the only single-session source of truth)
 └── sop-state/          # current phase + history; definitions live globally in ~/.peaks
 

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

@@ -95,7 +95,7 @@ peaks slice check [--rid <rid>] [--project <path>] [--json]
 
 4 个 check 全绿 + verify-pipeline pass → 才进 `peaks request transition --state qa-handoff`，让 peaks-qa 接管。
 
-> **新增 run 017（2026-06-09）**：边界默认走 changed-only suite，原来的全 suite 行为移到 `--run-tests` opt-in。`peaks-solo-test` skill 仍然是手动跑全量的入口。rationale: 全量 30s+ 严重拖慢 workflow；changed-only 命中 99% 真正回归。详见 PRD `.peaks/_runtime/2026-06-07-session-84feb7/prd/requests/002-017-2026-06-09-remove-auto-full-vitest-from-slice-check.md`。
+> **新增 run 017（2026-06-09）**：边界默认走 changed-only suite，原来的全 suite 行为移到 `--run-tests` opt-in。`peaks-test` skill 仍然是手动跑全量的入口。rationale: 全量 30s+ 严重拖慢 workflow；changed-only 命中 99% 真正回归。详见 PRD `.peaks/_runtime/2026-06-07-session-84feb7/prd/requests/002-017-2026-06-09-remove-auto-full-vitest-from-slice-check.md`。
 
 ## Micro-cycle → 边界 check → QA 的串联
 
@@ -131,21 +131,21 @@ verdict=return-to-rd → RD 修 (new slice 内部走 micro-cycle)
 
 | 阶段 | 谁负责 | 节奏 |
 |---|---|---|
-| RD slice 内部 | peaks-solo (main loop) | micro-cycle（5-10s 一个） |
-| RD slice 边界 | peaks-solo 调用 `peaks slice check` | 一次 |
+| RD slice 内部 | peaks-code (main loop) | micro-cycle（5-10s 一个） |
+| RD slice 边界 | peaks-code 调用 `peaks slice check` | 一次 |
 | QA test execution | peaks-qa (sub-agent or inline) | slice 级 |
 | 3-way fan-out (CR + sec + perf) | peaks-rd (sub-agent) | slice 级（RD 内部一次 + 边界 check 一次） |
 | TXT handoff | peaks-txt | slice 级 |
 | SC commit-boundaries | peaks-sc | slice 级 |
 
-## 为什么这套比当前 peaks-solo 的设计合理
+## 为什么这套比当前 peaks-code 的设计合理
 
 - **快**：micro-cycle ~100ms（vs 30s 全 suite），改 10 个 bug 从 5 分钟降到 30 秒
 - **稳**：边界 check 不省，4 项检查（tsc + vitest run --changed + 3-way + verify-pipeline）一次全跑；changed-only 模式 1-3s 内出结果，全量用 `--run-tests` opt-in
 - **清晰**：LLM 看到一个 explicit "禁止" 列表 + 强制 sequence，比"建议"更不容易越界
 - **可观测**：micro-cycle 走单测 → 边界跑 verify-pipeline，每步都有 JSON envelope 验证
 
-## 跟 peaks-solo SKILL.md 的对账
+## 跟 peaks-code SKILL.md 的对账
 
 - `peaks slice check` = 边界命令
 - micro-cycle = slice 内部
@@ -187,10 +187,10 @@ After RD completes (whether inline or sub-agent), Solo does not stop — it must
 **Presence restoration after RD/QA work returns (MANDATORY):** In v1.x, role skills called `peaks skill presence:set <role>` internally and stomped on `.peaks/.active-skill.json`. From v1.3 onward, sub-agents in the Swarm path are forbidden from calling `peaks skill presence:set` (see "Sub-agent dispatch" in each role's SKILL.md), so the main loop's presence file is preserved across the fan-out window by construction. The one place Solo still has to actively restore presence is **once after the fan-out returns** (gate=swarm-converged) and again **after each RD↔QA repair iteration** (gate=repair-cycle-<N>). Use the same command from Step 2 with the current mode and the gate that has just advanced:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <current-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <current-gate>
 ```
 
-This keeps the CLAUDE.md status header accurate (`Peaks-Loop Skill: peaks-solo`) instead of showing a stale role name. Use the current mode and gate values; the gate may have advanced since startup. Skipping this step causes the header to display the last-known gate permanently.
+This keeps the CLAUDE.md status header accurate (`Peaks-Loop Skill: peaks-code`) instead of showing a stale role name. Use the current mode and gate values; the gate may have advanced since startup. Skipping this step causes the header to display the last-known gate permanently.
 
 **Full-auto auto-proceed rule**: In the `full-auto` profile, when RD transitions to `qa-handoff`, Solo immediately drives QA — by launching a `peaks sub-agent dispatch qa` sub-agent carrying the `peaks-qa` body (swarm path), then executing the returned toolCall, or by running QA inline in the main loop (assisted/strict path). Do not pause, do not ask the user, do not summarize RD results as if they were final. The only valid reason to skip QA is when `--type` is `docs` or `chore` (no acceptance surface).
 
@@ -217,7 +217,7 @@ When `peaks-qa` returns `verdict=return-to-rd`, Solo does NOT manually rewrite R
 6. Repeat steps 1-5 until QA returns `verdict=pass`, or the cap below fires.
    **After each repair iteration** (after peaks-rd and peaks-qa both return), Solo MUST restore presence:
    ```bash
-   peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate repair-cycle-<N>
+   peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate repair-cycle-<N>
    ```
 
 **Repair cycle cap**: After 3 repair cycles without a passing QA verdict, emit a blocked TXT handoff regardless of remaining issues. Do not loop indefinitely. If a specific issue cannot be resolved within 3 cycles, mark it as a known blocker in the TXT handoff and proceed to the SC phase.
@@ -297,7 +297,7 @@ reasons array preserved verbatim.
 
 ### Runbook integration
 
-When the peaks-solo main loop sees `qa verdict != pass` or any audit
+When the peaks-code main loop sees `qa verdict != pass` or any audit
 prereq missing, the runbook now does:
 
 1. Call `aggregateVerdict({ security, perf, karpathy, mut, qa })` with

package/skills/{peaks-solo → peaks-code}/references/mode-selection-with-stale-presence.md

@@ -8,19 +8,19 @@
 
 Defect A (from PRD-002, 2026-06-28 session 88b27d):
 
-1. session A runs in `full-auto` → `peaks skill presence:set peaks-solo --mode full-auto --gate startup` stamps
+1. session A runs in `full-auto` → `peaks skill presence:set peaks-code --mode full-auto --gate startup` stamps
    `.peaks/_runtime/active-skill.json` with `outerSessionId=outer-A`.
 2. session A closes (Claude window quit).
 3. session B opens (a new Claude window, `outerSessionId=outer-B`).
 4. `peaks skill presence:get --project <path>` still returns `mode=full-auto` because the file is on disk.
-5. peaks-solo Step 1 reads the presence, sees `mode=full-auto`, **skips** AskUserQuestion.
+5. peaks-code Step 1 reads the presence, sees `mode=full-auto`, **skips** AskUserQuestion.
 6. The user never picked `full-auto` for THIS session — the mode was sticky from the previous one.
 
 The fix: presence is only authoritative when its `outerSessionId` matches the current outer session. Otherwise Step 1 must re-ask.
 
 ## Detection protocol
 
-Before deciding to skip Step 1's AskUserQuestion, the LLM driver (or any peaks-solo caller) MUST run:
+Before deciding to skip Step 1's AskUserQuestion, the LLM driver (or any peaks-code caller) MUST run:
 
 ```bash
 peaks skill presence:check-stale --project <path> --json
@@ -35,7 +35,7 @@ The CLI returns a JSON envelope of shape:
   "data": {
     "stale": true,
     "reason": "outer-session-mismatch",
-    "presence": { "skill": "peaks-solo", "mode": "full-auto", "outerSessionId": "outer-A", ... },
+    "presence": { "skill": "peaks-code", "mode": "full-auto", "outerSessionId": "outer-A", ... },
     "currentOuterSessionId": "outer-B",
     "recordedOuterSessionId": "outer-A"
   },
@@ -79,11 +79,11 @@ Returns the same `stale` / `reason` / `currentOuterSessionId` / `recordedOuterSe
 }
 ```
 
-The hard-pause on `step-1-mode-select` is preserved for ALL modes (defect #1 fix from slice 2026-06-28-solo-mode-bypass-fix). Stale-presence is an additional reason — even when the user names a profile explicitly, peaks-solo can still surface the staleness for visibility.
+The hard-pause on `step-1-mode-select` is preserved for ALL modes (defect #1 fix from slice 2026-06-28-solo-mode-bypass-fix). Stale-presence is an additional reason — even when the user names a profile explicitly, peaks-code can still surface the staleness for visibility.
 
 ## Auto-clear on session rotation
 
-`peaks workspace init` now calls `clearStalePresenceOnRotation` whenever an `outer-session-mismatch` rotation fires. This means in the COMMON path (user reopens Claude → peaks-solo auto-runs `peaks workspace init` → rotation clears the stale presence → Step 1 reads no-presence → re-ask). The check-stale CLI is the safety net for the rare case where rotation was suppressed (`--no-rotate-on-outer-mismatch`).
+`peaks workspace init` now calls `clearStalePresenceOnRotation` whenever an `outer-session-mismatch` rotation fires. This means in the COMMON path (user reopens Claude → peaks-code auto-runs `peaks workspace init` → rotation clears the stale presence → Step 1 reads no-presence → re-ask). The check-stale CLI is the safety net for the rare case where rotation was suppressed (`--no-rotate-on-outer-mismatch`).
 
 The auto-clear respects two guards so it never destroys a user-explicit mode:
 
@@ -92,17 +92,17 @@ The auto-clear respects two guards so it never destroys a user-explicit mode:
 
 ## Worked example (the 88b27d defect)
 
-Session A: `peaks skill presence:set peaks-solo --mode full-auto` (outer A).
+Session A: `peaks skill presence:set peaks-code --mode full-auto` (outer A).
 Session A closes. Session B starts (outer B).
 
 ```bash
-# 1. Run init (the common entry into peaks-solo).
+# 1. Run init (the common entry into peaks-code).
 peaks workspace init --project . --json
 # → auto-rotates session binding AND auto-clears stale presence
 #   nextActions: ["Auto-cleared stale skill presence ..."]
 #   data.rotation: { previousSessionId: "session-A", reason: "outer-session-mismatch" }
 
-# 2. peaks-solo Step 1 (was: skip AskUserQuestion because presence.mode=full-auto).
+# 2. peaks-code Step 1 (was: skip AskUserQuestion because presence.mode=full-auto).
 # Now: presence is gone → no-presence → AskUserQuestion fires.
 
 peaks skill presence:check-stale --project . --json
@@ -112,7 +112,7 @@ peaks solo should-pause --step step-1-mode-select --mode full-auto --json
 # → { shouldPause: true, reason: "step=step-1-mode-select is a mode/context-selection step → always pause" }
 
 # 3. User picks a profile (or repeats "full-auto"). Then:
-peaks skill presence:set peaks-solo --mode full-auto --gate startup
+peaks skill presence:set peaks-code --mode full-auto --gate startup
 # → re-stamps with outer=B. Future sessions that read this presence
 #   see outerSessionId=outer-B matching THEIR outer=B → not stale.
 ```
@@ -120,5 +120,5 @@ peaks skill presence:set peaks-solo --mode full-auto --gate startup
 ## ACL — what NOT to do
 
 - **NEVER** skip Step 1 just because `.peaks/_runtime/active-skill.json` shows a `mode` field. Run `presence:check-stale` first.
-- **NEVER** call `peaks skill presence:clear` from peaks-solo to "fix" a stale mode. The auto-clear path is `peaks workspace init`'s job; manual clears destroy user-explicit mode choices that may belong to another live outer session.
-- **NEVER** set the presence `mode` field from inside a sub-agent (peaks-rd, peaks-qa, etc.). Sub-agents may read presence to honour the user's chosen mode but the write authority for Step 1 belongs to the peaks-solo driver.
+- **NEVER** call `peaks skill presence:clear` from peaks-code to "fix" a stale mode. The auto-clear path is `peaks workspace init`'s job; manual clears destroy user-explicit mode choices that may belong to another live outer session.
+- **NEVER** set the presence `mode` field from inside a sub-agent (peaks-rd, peaks-qa, etc.). Sub-agents may read presence to honour the user's chosen mode but the write authority for Step 1 belongs to the peaks-code driver.

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

@@ -18,4 +18,4 @@ Map the user's selection to the `--mode` flag value (used by `peaks skill presen
 
 > Note: `peaks workflow route --mode solo|team` is a **different** CLI dimension (solo developer vs team flow) and is unrelated to the profile choice here. Do not conflate them.
 
-If the user already names a profile in their invocation (e.g. `/peaks-solo --full-auto`, "用全自动模式"), skip this question and use the named profile directly.
+If the user already names a profile in their invocation (e.g. `/peaks-code --full-auto`, "用全自动模式"), skip this question and use the named profile directly.

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

@@ -24,7 +24,7 @@ Rules Solo applies:
 
 ## Refactor workflow wiring
 
-For `peaks-solo refactor` runs against a repository with `openspec/`:
+For `peaks-code refactor` runs against a repository with `openspec/`:
 
 1. RD entry gate — `peaks openspec validate <id>` must pass and `peaks openspec to-rd <id>` must return `acceptance.length > 0`.
 2. Each slice must reference one OpenSpec tasks section as its commit boundary (per `references/openspec-commit-boundaries.md` in peaks-sc).

package/skills/{peaks-solo → peaks-code}/references/project-scan-checklist.md

@@ -1,6 +1,6 @@
 # Peaks-Loop Pre-RD project scan checklist
 
-> Extracted from `skills/peaks-solo/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Pre-RD project scan checklist that was previously inline; nothing was paraphrased, just relocated.
+> Extracted from `skills/peaks-code/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Pre-RD project scan checklist that was previously inline; nothing was paraphrased, just relocated.
 
 Before handing off to `peaks-rd`, scan the project and record findings to `.peaks/_runtime/<sessionId>/rd/project-scan.md`. RD and UI roles read this before starting work. **project-scan.md is a session-scoped singleton** — check if it already exists before regenerating (e.g. via `ls .peaks/_runtime/<sessionId>/rd/project-scan.md`). If it exists and is complete (has `## Archetype` and `## Project mode` sections), reuse it. Only regenerate if missing or incomplete.
 

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

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

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

@@ -60,4 +60,4 @@ done
 **Strict quality guarantee (per user's hard rule: "严格要保证不能比当前的效果差")**:
 - If no in-flight slice is detected, this step is a no-op: zero extra commands beyond the existing Step 0 probe, zero extra token cost.
 - If an in-flight slice is detected, the cost is one `find` + one `grep` loop (sub-millisecond) + one `AskUserQuestion` (one round-trip). The savings are 3-5k tokens (the cost of manually re-reading 3-5 artifact files).
-- The dogfood test in `tests/unit/skill-resume-mode.test.ts` (8 cases, bash-fixture shim — the legacy interface used by `skills/peaks-solo-resume`) and `tests/unit/services/skill/resume-detector.test.ts` (24 cases, the canonical TypeScript classifier at `src/services/skill/resume-detector.ts`) together cover: (a) fresh / complete / resume:rd-planning / resume:qa-validation / resume:txt-handoff state-based classifications, (b) the "Other resume triggers" overrides (missing `rd/tech-doc.md` → `rd-planning`; missing `rd/code-review.md` or `rd/security-review.md` → `rd-review-fanout`; missing `qa/test-reports/<rid>.md` → `qa-execution`), (c) the mid-implementation distinction (`spec-locked` / `implemented` / `running` / `blocked` all return `in-flight:<state>`), (d) the primary-vs-abandoned filter (multiple RDs → spec-locked wins; single blocked RD stays primary; 2+ all-abandoned → fresh), (e) the legacy `.peaks/_runtime/<sessionId>/` path fallback, and (f) determinism across two invocations on the same fixture.
+- The dogfood test in `tests/unit/skill-resume-mode.test.ts` (8 cases, bash-fixture shim — the legacy interface used by `skills/peaks-resume`) and `tests/unit/services/skill/resume-detector.test.ts` (24 cases, the canonical TypeScript classifier at `src/services/skill/resume-detector.ts`) together cover: (a) fresh / complete / resume:rd-planning / resume:qa-validation / resume:txt-handoff state-based classifications, (b) the "Other resume triggers" overrides (missing `rd/tech-doc.md` → `rd-planning`; missing `rd/code-review.md` or `rd/security-review.md` → `rd-review-fanout`; missing `qa/test-reports/<rid>.md` → `qa-execution`), (c) the mid-implementation distinction (`spec-locked` / `implemented` / `running` / `blocked` all return `in-flight:<state>`), (d) the primary-vs-abandoned filter (multiple RDs → spec-locked wins; single blocked RD stays primary; 2+ all-abandoned → fresh), (e) the legacy `.peaks/_runtime/<sessionId>/` path fallback, and (f) determinism across two invocations on the same fixture.

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
@@ -80,7 +80,7 @@ peaks request transition <rid> --role prd --state handed-off --project <repo> --
 #     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
 #     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
@@ -99,7 +99,7 @@ peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-
 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
+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
@@ -219,6 +219,9 @@ fi
 
 # After Step 7 (RD+QA commit) lands AND Step 0.8 fired (state.json exists):
 peaks job checkpoint --slice-id <rid> --state done --commit-sha $(git rev-parse HEAD)
+# v3.1.2: `peaks job checkpoint --state done` ALSO writes
+# .peaks/_runtime/<sid>/job/<jid>/progress.json. Read it on resume:
+peaks job progress --job-id <jid> --json
 peaks job status --job-id <jid> --json
 peaks job subagent-cleanup --job-id <jid> --batch-id <bid> --force   # Step 0.87 gate
 # Loop control:
@@ -226,4 +229,21 @@ peaks job subagent-cleanup --job-id <jid> --batch-id <bid> --force   # Step 0.87
 #   remaining == 0 → Step 8/9/10/11 (original tail)
 #   blocked (strict) → peaks job block + STOP
 # Rotating-mode: every rotateEvery slices → Step 0.86 (peaks session rotate + resume)
+
+# 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
+
+# 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
+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.
+# 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
 ```

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

@@ -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-code/references/step-0-8-gate.md

@@ -0,0 +1,60 @@
+# Peaks-Loop Solo — 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`)
+
+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.
+
+### LLM judgement criteria (read once, then call the recorder)
+
+- N parallel targets (`app/components/*`, `app/modules/*`, `for each subdir`, "以目录为维度", "把剩下的也跑了").
+- Completion phrase implying batch continuation (`until all done`, "继续执行下个 slice", "全部添加完", "all of them").
+- Cost / length disavowal (`不用考虑费用`, "don't worry about cost", "一直跑").
+- Explicit slice count (`25 slices`, "切分成 N 段", "拆成 N 块").
+
+### 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]`.
+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.
+
+## 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`
+
+`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:
+
+| 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 no regex match | 0 (allow) | allow, no Job trigger |
+
+### 2. Size-fear ban — `peaks solo 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.
+
+### 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".
+
+## Backup regex rationale
+
+The fail-closed backup regex (mentioned above) exists so the gate has defense in depth: even if the recorder's downstream enforcement is bypassed, the hook catches obvious Job-shaped prompts. The regex is intentionally narrow — it MUST miss benign prompts and MUST hit obvious batches — so the LLM-side judgement remains primary.
+
+## Hook wiring
+
+`peaks workspace init` writes both matchers (Bash + Write|Edit|MultiEdit) atomically; if either fails the whole init fails. `peaks workspace init --remove-hooks` reverses both. The Bash matcher is required for Step 0.8; the Write|Edit|MultiEdit matcher pre-existed (Step 0 [Fact-Forcing Gate]).

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 Solo / 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,7 +271,7 @@ 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)
 
 ---
@@ -330,5 +330,5 @@ The role's required artefact paths (also see peaks-ui/rd/qa SKILL.md and `refere
 After every sub-agent dispatch returns, Solo **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 Solo launches sub-agents, what the sub-agent prompt must contain, what the sub-agent must return, and how Solo 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
@@ -31,7 +31,7 @@ The previous "Swarm" used `Skill(skill="peaks-rd")` calls. That is **single-stac
 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.
 
 ```
-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.
 
@@ -150,7 +150,7 @@ After all sub-agent dispatch calls return and the LLM has invoked the toolCalls,
 
 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,20 +158,20 @@ 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. 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.
 
 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.
 
 ## 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/`.
 
 ---
 

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 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.
 >
 > **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`)
@@ -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-doctor/SKILL.md

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