peaks-loop 3.1.2 → 4.0.0-beta.2

package/dist/src/skills/peaks-maker/index.d.ts

@@ -0,0 +1,5 @@
+export declare const peaksMakerManifest: {
+    name: string;
+    description: string;
+    body: string;
+};

package/dist/src/skills/peaks-maker/index.js

@@ -0,0 +1,32 @@
+// src/skills/peaks-maker/index.ts
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+import { dirname, join } from "node:path";
+function parseFrontmatter(md) {
+    const m = md.match(/^---\n([\s\S]+?)\n---\n([\s\S]*)$/);
+    if (!m)
+        throw new Error("peaks-maker SKILL.md is missing YAML frontmatter");
+    const fm = {};
+    for (const line of m[1].split("\n")) {
+        const i = line.indexOf(":");
+        if (i > 0)
+            fm[line.slice(0, i).trim()] = line.slice(i + 1).trim();
+    }
+    // The non-null assertions below were unsafe: if `name:` or `description:`
+    // was absent from the frontmatter, `fm[name]` would be `undefined`, which
+    // violates the declared return type and silently leaks a malformed
+    // manifest to every consumer of `peaksMakerManifest`. Validate explicitly
+    // so a missing/empty key surfaces as a clear error at module-load time.
+    const name = fm.name;
+    const description = fm.description;
+    if (typeof name !== "string" || name.length === 0) {
+        throw new Error("peaks-maker SKILL.md is missing name or description in frontmatter");
+    }
+    if (typeof description !== "string" || description.length === 0) {
+        throw new Error("peaks-maker SKILL.md is missing name or description in frontmatter");
+    }
+    return { name, description, body: m[2] };
+}
+const here = dirname(fileURLToPath(import.meta.url));
+const md = readFileSync(join(here, "SKILL.md"), "utf-8");
+export const peaksMakerManifest = parseFrontmatter(md);

package/output-styles/peaks-skill-swarm.md

@@ -4,7 +4,7 @@ description: Peaks 专用输出风格：仅在 peaks skills 工作流中用东
 keep-coding-instructions: true
 ---
 
-This output style is self-gated. Apply the sections below only when the current task explicitly invokes or continues a Peaks-Loop skill workflow, including `/peaks-*`, `skills/peaks-*`, Peaks-Loop PRD/RD/QA/UI/SC/TXT/Solo work, or edits to this repository's `skills/` directory. For unrelated tasks, preserve the default Claude Code behavior and keep responses concise.
+This output style is self-gated. Apply the sections below only when the current task explicitly invokes or continues a Peaks-Loop skill workflow, including `/peaks-*`, `skills/peaks-*`, Peaks-Loop PRD/RD/QA/UI/SC/TXT/Code work, or edits to this repository's `skills/` directory. For unrelated tasks, preserve the default Claude Code behavior and keep responses concise.
 
 ## Peaks-Loop response contract
 
@@ -14,7 +14,7 @@ When active, make the skill transition visually obvious with a light Northeaster
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Peaks-Loop Skill Active: <skill-name> — 整活开工，但不整虚的
 Peaks-Loop Role Chain: <PRD → RD → QA → SC, or single role>
-Peaks-Loop Mode: <Solo | Assisted | Swarm | Strict | Economy>
+Peaks-Loop Mode: <Code | Assisted | Swarm | Strict | Economy>
 Peaks-Loop Current Gate: <confirmation | dry-run | coverage | QA | commit boundary | handoff>
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
@@ -54,7 +54,7 @@ Peaks-Loop Skill: <skill-name> | Peaks-Loop Gate: <current gate> | Next: <one sh
 Structure active Peaks-Loop responses around:
 
 1. **Peaks-Loop Role** — name the active Peaks-Loop role or role chain, for example PRD → RD → QA → SC.
-2. **Peaks-Loop Mode** — state whether the workflow is Solo, Assisted, Swarm, Strict, or Economy.
+2. **Peaks-Loop Mode** — state whether the workflow is Code, Assisted, Swarm, Strict, or Economy.
 3. **Peaks-Loop Current Gate** — show the current required gate: product confirmation, RD dry-run, coverage, QA acceptance, commit boundary, or handoff.
 4. **Action** — describe the immediate next action in one short sentence before tool use.
 5. **Peaks-Loop Evidence** — end with only the evidence that matters: commands, artifacts, changed files, blockers, and next action.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peaks-loop",
-  "version": "3.1.2",
+  "version": "4.0.0-beta.2",
   "description": "Loop Engineering CLI — workflow primitive / loop guards / evaluators / slice orchestration",
   "author": "SquabbyZ",
   "license": "MIT",
@@ -63,16 +63,20 @@
     "typecheck": "tsc -p tsconfig.json --noEmit && vitest run --coverage --coverage.include='src/services/workflow/plan-*.ts' tests/unit/services/workflow/",
     "mut:run": "peaks mut run --project . --out mut-report.json",
     "mut:scan": "peaks mut asserts --in mut-report.json",
-    "audit:prose-ratio": "peaks audit prose-ratio --project ."
+    "audit:prose-ratio": "peaks audit prose-ratio --project .",
+    "dogfood:sediment": "bash scripts/dogfood-sediment-cycle.sh"
   },
   "engines": {
     "node": ">=20.0.0"
   },
   "pnpm": {
-    "onlyBuiltDependencies": []
+    "onlyBuiltDependencies": [
+      "better-sqlite3"
+    ]
   },
   "dependencies": {
     "@colbymchenry/codegraph": "0.7.10",
+    "better-sqlite3": "^12.11.1",
     "commander": "^12.1.0",
     "fzf": "^0.5.2",
     "headroom-ai": "0.22.4",
@@ -92,6 +96,7 @@
     "@stryker-mutator/core": "^8.7.1",
     "@stryker-mutator/typescript-checker": "^8.7.1",
     "@stryker-mutator/vitest-runner": "^8.7.1",
+    "@types/better-sqlite3": "^7.6.13",
     "@types/node": "^22.10.2",
     "@vitest/coverage-v8": "^2.1.8",
     "tsx": "^4.19.2",

package/scripts/install-skills.mjs

@@ -600,14 +600,39 @@ export function installBundledSkills(options = {}) {
   mkdirSync(targetRoot, { recursive: true });
   const validateSkillsRoot = createInstallRootValidator(targetRoot, 'Peaks skills');
 
+  // After the v2.13.0 bee-demote (commit de0872b), the role skills
+  // (peaks-prd, peaks-rd, peaks-qa, peaks-ui, peaks-sc, peaks-txt)
+  // moved under `skills/bee/<role>/` while user-facing helpers stayed
+  // at `skills/<name>/`. Build the install candidate list by walking
+  // top-level entries (user-facing helpers) AND `skills/bee/<role>`
+  // (demoted role skills). Each candidate is installed under its
+  // basename so the postinstall links `~/.claude/skills/peaks-rd`
+  // to `skills/bee/peaks-rd` (rather than `skills/bee`).
+  const beeRoot = join(skillsRoot, 'bee');
+  /** @type {Array<{ skillName: string, sourcePath: string }>} */
+  const candidates = [];
   for (const skillName of readdirSync(skillsRoot)) {
+    if (skillName === 'bee') continue;
     const sourcePath = join(skillsRoot, skillName);
     const skillFile = join(sourcePath, 'SKILL.md');
-    const targetPath = join(targetRoot, skillName);
-
-    if (!lstatSync(sourcePath).isDirectory() || !existsSync(skillFile)) {
-      continue;
+    if (!lstatSync(sourcePath).isDirectory() || !existsSync(skillFile)) continue;
+    candidates.push({ skillName, sourcePath });
+  }
+  if (existsSync(beeRoot) && lstatSync(beeRoot).isDirectory()) {
+    for (const skillName of readdirSync(beeRoot)) {
+      const sourcePath = join(beeRoot, skillName);
+      const skillFile = join(sourcePath, 'SKILL.md');
+      if (!lstatSync(sourcePath).isDirectory() || !existsSync(skillFile)) continue;
+      // De-dupe: a top-level helper with the same name wins (preserves
+      // the existing install contract for any helper that shares a name
+      // with a demoted role skill, e.g. legacy overlap).
+      if (candidates.some((c) => c.skillName === skillName)) continue;
+      candidates.push({ skillName, sourcePath });
     }
+  }
+
+  for (const { skillName, sourcePath } of candidates) {
+    const targetPath = join(targetRoot, skillName);
 
     const current = getPathStats(targetPath);
     if (current) {

package/skills/{peaks-prd → bee/peaks-prd}/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: peaks-prd
-description: Product and requirement skill for Peaks. Use when a workflow needs PRD, refactor goals, non-goals, behavior preservation, acceptance criteria, product change proposals, or user-confirmable product artifacts.
+description: |
+  Product and requirement role for Peaks-Loop (LLM-only internal role; not user-invocable.
+  Triggered by peaks-code via `peaks sub-agent dispatch --role prd`.)
+  Use when a workflow needs PRD, refactor goals, non-goals, behavior preservation,
+  acceptance criteria, product change proposals, or user-confirmable product artifacts.
+visibility: internal
+---
 ---
 
 # Peaks-Loop PRD
@@ -223,7 +229,7 @@ Use gstack as a concrete workflow reference for the product-facing parts of `Thi
 
 ## Authenticated product document workflow
 
-When the source PRD is an authenticated web document such as Feishu/Lark, use the Playwright MCP headed-browser surface rather than unauthenticated fetch tools. Chrome DevTools MCP is a secondary surface that only connects to an already-running Chrome (`--remote-debugging-port=9222`); it does not launch a browser on its own. The canonical browser workflow lives in `peaks-solo/references/browser-workflow.md`; the rules below are the PRD-specific application.
+When the source PRD is an authenticated web document such as Feishu/Lark, use the Playwright MCP headed-browser surface rather than unauthenticated fetch tools. Chrome DevTools MCP is a secondary surface that only connects to an already-running Chrome (`--remote-debugging-port=9222`); it does not launch a browser on its own. The canonical browser workflow lives in `peaks-code/references/browser-workflow.md`; the rules below are the PRD-specific application.
 
 1. Confirm Playwright MCP is installed: check the LLM tool list for any Playwright MCP entry in the LLM tool list. If absent, the user installs via `claude mcp add playwright -- npx @playwright/mcp@latest` (Claude Code) or the IDE-native install command. Do not hand-edit `.claude/settings.json`.
 2. Before navigation, verify the user-provided document URL uses `https:` and belongs to an approved Feishu/Lark tenant domain such as `*.feishu.cn`, `*.larksuite.com`, `*.larksuite.com.cn`, or a project-configured tenant. Reject `file:`, `data:`, `javascript:`, `http:`, localhost, loopback, link-local, private IP, and raw IP hosts unless the user explicitly approves a controlled local test target.

package/skills/{peaks-prd → bee/peaks-prd}/references/workflow.md

@@ -15,7 +15,7 @@ When the product source is an authenticated Feishu/Lark/wiki document:
 7. Do not persist login URLs, redirect URLs, cookies, request or response headers, session tokens, tokens, storage state, QR payloads, raw browser state, raw network logs, browser traces, or screenshots/logs containing PII or SSO/MFA material into artifacts; redact sensitive evidence before writing `.peaks` outputs.
 8. If access remains blocked, record only a redacted document identifier, a sanitized state category such as `login-required`, `mfa-required`, or `access-denied`, and the exact user action needed.
 
-Canonical browser workflow: `../../peaks-solo/references/browser-workflow.md`.
+Canonical browser workflow: `../../peaks-code/references/browser-workflow.md`.
 
 ## Implementation-oriented analysis
 

package/skills/{peaks-qa → bee/peaks-qa}/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: peaks-qa
-description: QA and verification skill for Peaks. Use when a workflow needs unit-test coverage evidence, regression matrices, baseline reports, validation reports, acceptance checks, or refactor verification gates.
+description: |
+  QA and verification role for Peaks-Loop (LLM-only internal role; not user-invocable.
+  Triggered by peaks-code via `peaks sub-agent dispatch --role qa`.)
+  Use when a workflow needs unit-test coverage evidence, regression matrices,
+  baseline reports, validation reports, acceptance checks, or refactor verification gates.
+visibility: internal
+---
 ---
 
 ## Single-scope-axis naming convention
@@ -48,9 +54,9 @@ These two contracts are non-negotiable. The previous prose-only phrasing let the
 
 The canonical scope dir for this request is provided as `envelope.data.scopeDir` (absolute path). Write all session-id-scoped files under that path. **NEVER** construct paths like `.peaks/_runtime/<scope>/...` from frontmatter (where `<scope>` is a date-stamped session id, NOT a peaks-loop change-id — the change-id axis was removed in slice `2026-06-29-change-id-root-removal`). The path has already been resolved by the CLI.
 
-## Sub-agent dispatch (when launched by peaks-solo swarm)
+## Sub-agent dispatch (when launched by peaks-code swarm)
 
-When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-solo`, the following sections of THIS skill are **suspended** for the sub-agent run: Session id, Skill presence, Workspace initialization, Mode selection, Statusline install. The sub-agent must NOT call `peaks request init` (Solo already initialised the slot), and must write `.peaks/_runtime/<sessionId>/qa/test-cases/<rid>.md` with test cases that link to PRD acceptance items. Return only a compact JSON envelope.
+When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-code`, the following sections of THIS skill are **suspended** for the sub-agent run: Session id, Skill presence, Workspace initialization, Mode selection, Statusline install. The sub-agent must NOT call `peaks request init` (Code already initialised the slot), and must write `.peaks/_runtime/<sessionId>/qa/test-cases/<rid>.md` with test cases that link to PRD acceptance items. Return only a compact JSON envelope.
 
 > **v2.15.0+ 校准:** 每个 slice 完成,user 必介入做**业务审阅**(4-5 项业务/产品清单:业务流程 / 需求覆盖 / 边界 case / UI 装配 / 能合入下版吗),**不是技术审阅**。业务审过 → 进 final;业务不通过 → 返工。详见 `.peaks/memory/peaks-loop-slice-review-and-qa-perspective.md`。
 
@@ -202,7 +208,7 @@ Do not own product scope or implementation. Do not modify runtime configuration.
 
 ## Sub-agent context governance (G7 + G7.7 + G8 + G9 — slice #010)
 
-QA sub-agents (qa / qa-business / qa-perf / qa-security) follow the same G7 metadata-only + G8.6 share protocol as RD. Detailed: `skills/peaks-solo/references/context-governance.md`.
+QA sub-agents (qa / qa-business / qa-perf / qa-security) follow the same G7 metadata-only + G8.6 share protocol as RD. Detailed: `skills/peaks-code/references/context-governance.md`.
 
 → see `references/qa-context-governance.md` for the full G7 / G8.6 / G9 protocol + QA sub-agent prompt template.
 

package/skills/{peaks-qa → bee/peaks-qa}/references/artifact-per-request.md

@@ -9,12 +9,12 @@ The three files for any QA invocation land under the active session's `qa/` work
 | # | File | Path | Reader | Content |
 |---|------|------|--------|---------|
 | 1 | Test cases | `.peaks/_runtime/<session-id>/qa/test-cases/<request-id>.md` | RD (before impl), QA | Generated test scenarios with status |
-| 2 | Test report | `.peaks/_runtime/<session-id>/qa/test-reports/<request-id>.md` | QA, SC, Solo | Summary, coverage%, security, perf, risks |
-| 3 | Request artifact | `.peaks/_runtime/<session-id>/qa/requests/<request-id>.md` | Solo, RD↔QA loop | Verdict, boundary check, links to #1 and #2 |
+| 2 | Test report | `.peaks/_runtime/<session-id>/qa/test-reports/<request-id>.md` | QA, SC, Code | Summary, coverage%, security, perf, risks |
+| 3 | Request artifact | `.peaks/_runtime/<session-id>/qa/requests/<request-id>.md` | Code, RD↔QA loop | Verdict, boundary check, links to #1 and #2 |
 
 ## Required content
 
-The request artifact is the **verdict carrier** — it must include: QA verdict (`pass` / `return-to-rd` / `blocked`), the red-line audit outcome, links to the test-cases and test-report, the boundary check (acceptance items covered, gaps), and any cross-skill handoff notes for Solo. The test cases file enumerates every scenario with status; the test report summarises execution and links the security / performance / regression companion files.
+The request artifact is the **verdict carrier** — it must include: QA verdict (`pass` / `return-to-rd` / `blocked`), the red-line audit outcome, links to the test-cases and test-report, the boundary check (acceptance items covered, gaps), and any cross-skill handoff notes for Code. The test cases file enumerates every scenario with status; the test report summarises execution and links the security / performance / regression companion files.
 
 ## Rules
 

package/skills/{peaks-qa → bee/peaks-qa}/references/browser-validation-contracts.md

@@ -39,9 +39,9 @@ AskUserQuestion({
     { label: "I am logged in / I'll log in now",
       description: "Pause QA. The visible browser is already open; the user completes login in-place, then types 'logged in' or equivalent. QA then resumes browser_navigate + browser_snapshot from the post-login page." },
     { label: "Skip browser validation for this slice",
-      description: "Mark the affected acceptance items as unverified in the test report. Do NOT issue a pass verdict. The slice stays in qa-running with the browser gate marked blocked, reason=login-required. peaks-solo's repair loop will surface this on the next cycle." },
+      description: "Mark the affected acceptance items as unverified in the test report. Do NOT issue a pass verdict. The slice stays in qa-running with the browser gate marked blocked, reason=login-required. peaks-code's repair loop will surface this on the next cycle." },
     { label: "Cancel the workflow",
-      description: "Stop QA immediately. Emit a blocked TXT handoff so peaks-solo can surface the auth wall to the user. Do not mark any acceptance items as accepted." }
+      description: "Stop QA immediately. Emit a blocked TXT handoff so peaks-code can surface the auth wall to the user. Do not mark any acceptance items as accepted." }
   ]
 })
 ```

package/skills/{peaks-qa → bee/peaks-qa}/references/external-capability-guidance.md

@@ -5,5 +5,5 @@
 - Playwright MCP is the required path for controlled headed browser and E2E validation (it launches a headed browser on demand). The LLM runtime exposes the Playwright tools under its own server-and-tool namespace (the Playwright MCP); QA invokes them by name from the LLM's tool list. (peaks-loop no longer auto-installs MCPs as of slice #016; the user runs `claude mcp add playwright -- npx @playwright/mcp@latest` themselves when the tool list is empty.)
 - Chrome DevTools MCP is an optional secondary surface for CDP inspection (console, network, performance) of an already-running Chrome started with `--remote-debugging-port=9222`; it does NOT launch a browser on its own. The LLM invokes Chrome DevTools MCP tools directly when present in the tool list.
 - Agent Browser can support browser walkthroughs, but never submit forms, purchase, delete, or mutate authenticated state without explicit confirmation.
-- Canonical browser workflow (URL allow-list, login handoff, sanitization rules, tool mapping): `peaks-solo/references/browser-workflow.md`.
+- Canonical browser workflow (URL allow-list, login handoff, sanitization rules, tool mapping): `peaks-code/references/browser-workflow.md`.
 - If Playwright MCP is not installed and the user does not authorize installation, mark frontend browser validation blocked; screenshots, logs, manual steps, or other tools must not substitute for the mandatory headed browser gate.

package/skills/{peaks-qa → bee/peaks-qa}/references/qa-fanout-contract.md

@@ -142,9 +142,9 @@ envelope and into the slice's `reducerReport`.
 
 ## Cross-reference
 
-- `skills/peaks-solo/references/sub-agent-dispatch.md` — orchestrator
+- `skills/peaks-code/references/sub-agent-dispatch.md` — orchestrator
   contract for all Dispatchers
-- `skills/peaks-solo/SKILL.md` "Peaks-Loop Swarm parallel phase" — sibling
+- `skills/peaks-code/SKILL.md` "Peaks-Loop Swarm parallel phase" — sibling
   fan-out pattern
 - `.peaks/memory/sub-agent-resource-lifecycle-red-line.md` — G5 red line
 - `.peaks/memory/sub-agent-heartbeat-progress-red-line.md` — G6 red line
@@ -155,4 +155,4 @@ envelope and into the slice's `reducerReport`.
 
 > Body of `## 业务测试细分 (optional)`. If the PRD or project warrants it, subdivide `qa-business` further into roles like `qa-business-api` / `qa-business-frontend` / `qa-business-regression`; each gets its own `peaks sub-agent dispatch` call. Names are convention not contract — the dispatcher accepts any non-empty string. **Subdivision must stay ≤ 2 levels deep** (RL-4): `qa-business-api` is fine, `qa-business-api-user` is not. Two levels of depth is the empirical sweet spot — past that, the reducer cannot audit the boundaries between sub-agents, and prompts start overlapping.
 
-For the full contract (heartbeat instructions for each sub-agent, batch-id discipline, 30s cadence, 100-truncation, 5min stale) see `skills/peaks-qa/references/qa-fanout-contract.md` and `skills/peaks-solo/references/sub-agent-dispatch.md` §G6.
+For the full contract (heartbeat instructions for each sub-agent, batch-id discipline, 30s cadence, 100-truncation, 5min stale) see `skills/peaks-qa/references/qa-fanout-contract.md` and `skills/peaks-code/references/sub-agent-dispatch.md` §G6.

package/skills/{peaks-qa → bee/peaks-qa}/references/qa-sub-agent-dispatch.md

@@ -1,16 +1,16 @@
 # Sub-agent dispatch (QA)
 
-> Body of `## Sub-agent dispatch`. When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-solo`, the following sections of THIS skill are **suspended** for the sub-agent run:
+> Body of `## Sub-agent dispatch`. When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-code`, the following sections of THIS skill are **suspended** for the sub-agent run:
 
 - **Session id** — use the parent's sid (read `.peaks/_runtime/session.json` or pass `--session-id <parent-sid>` to any session-creating CLI). Do NOT spawn your own session. The new `peaks session info --active` reads the canonical binding for you.
-- **Skill presence (MANDATORY first action)** — do NOT call `peaks skill presence:set peaks-qa`. The sub-agent must not overwrite `.peaks/.active-skill.json`; the main Solo loop owns that file. If you need to mark your own state, write a marker file at `.peaks/_runtime/<sessionId>/system/sub-agent-qa.json` and only that.
-- **Workspace initialization** — Solo has already run `peaks workspace init` before fan-out. Do not re-run it.
-- **Mode selection** — Solo has already chosen the mode.
-- **Statusline install** — already done by Solo at session startup.
+- **Skill presence (MANDATORY first action)** — do NOT call `peaks skill presence:set peaks-qa`. The sub-agent must not overwrite `.peaks/.active-skill.json`; the main Code loop owns that file. If you need to mark your own state, write a marker file at `.peaks/_runtime/<sessionId>/system/sub-agent-qa.json` and only that.
+- **Workspace initialization** — Code has already run `peaks workspace init` before fan-out. Do not re-run it.
+- **Mode selection** — Code has already chosen the mode.
+- **Statusline install** — already done by Code at session startup.
 
 What the sub-agent **MUST** still do:
 
-0. **Do NOT call `peaks request init`** — Solo has already initialised the request artefact slot in the main loop before fan-out. The sub-agent reads it via `peaks request show <rid> --role qa --project <repo> --json` if it needs to.
+0. **Do NOT call `peaks request init`** — Code has already initialised the request artefact slot in the main loop before fan-out. The sub-agent reads it via `peaks request show <rid> --role qa --project <repo> --json` if it needs to.
 2. `peaks request show <rid> --role prd --project <repo> --json` (and `--role rd`, `--role ui` if UI is in the swarm plan).
 3. Standards preflight (dry-run only).
 4. Write `.peaks/_runtime/<sessionId>/qa/test-cases/<rid>.md` with test cases that link to PRD acceptance items.
@@ -30,7 +30,7 @@ What the sub-agent **MUST** still do:
 **Hard prohibitions** (sub-agent context):
 
 - Do NOT call `Skill(skill="...")`.
-- Do NOT call `peaks skill presence:set` — Solo owns the active-skill file.
+- Do NOT call `peaks skill presence:set` — Code owns the active-skill file.
 - Do NOT run the actual test suite, do NOT execute security/perf tools, do NOT open a browser — those are the **QA validation** phase, not the Swarm planning phase.
 - Do NOT commit, push, install hooks, or apply settings.json mutations.
 - Do NOT ask the user interactive questions. If you need clarification, return `{"status":"blocked","blockedReason":"<text>"}`.

package/skills/{peaks-rd → bee/peaks-rd}/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: peaks-rd
-description: Research and development skill for Peaks. Use for engineering analysis, refactor planning, project scanning, code standards, unit-test coverage gates, implementation contracts, task graphs, and RD handoffs. Always use this for Peaks-Loop refactor workflows.
+description: |
+  Research and development role for Peaks-Loop (LLM-only internal role; not user-invocable.
+  Triggered by peaks-code via `peaks sub-agent dispatch --role rd`.)
+  Use for engineering analysis, refactor planning, project scanning, code standards,
+  unit-test coverage gates, implementation contracts, task graphs, and RD handoffs.
+  Always use this for Peaks-Loop refactor workflows.
+visibility: internal
+---
 ---
 
 ## Single-scope-axis naming convention
@@ -17,7 +24,7 @@ RD workflow automatically runs `peaks context build --audience peaks-rd` before
 
 > **Read once per RD invocation; RD is built around these 4 guidelines.**
 
-Every RD action (planning, implementation, sub-agent dispatch, fan-out) MUST align with the 4 Karpathy guidelines. The full text lives at `andrej-karpathy-skills:karpathy-guidelines` (reference material only — do not execute upstream / run installer / persist sensitive examples). RD sub-agents receive the full text via `references/rd-sub-agent-dispatch.md` (see "Karpathy-guidelines context"). The 4 guidelines are:
+Every RD action MUST align with the 4 Karpathy guidelines (full text at `andrej-karpathy-skills:karpathy-guidelines` — reference only, do not execute upstream). RD sub-agents receive the full text via `references/rd-sub-agent-dispatch.md`. The 4 guidelines are:
 
 1. **Think Before Coding** — surface assumptions, name tradeoffs, ask when unclear. State red-line scope in `## Red-line scope` before any code change.
 2. **Simplicity First** — minimum code that solves the problem. No speculative features, no abstractions for single-use code, no error handling for impossible scenarios. If 200 lines could be 50, rewrite it. The 800-line file cap and `peaks scan file-size` gate enforce this mechanically.
@@ -40,9 +47,9 @@ For frontend / UI-affecting slices, RD's self-test uses the Playwright MCP heade
 
 → see `references/browser-self-test-contracts.md` and `references/browser-action-wrapper.md` (slice 3 thin wrapper).
 
-## Sub-agent dispatch (when launched by peaks-solo swarm)
+## Sub-agent dispatch (when launched by peaks-code swarm)
 
-When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-solo`, the following sections of THIS skill are **suspended** for the sub-agent run: Session id (use parent's), Skill presence, Workspace initialization, Mode selection, Statusline install.
+When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-code`, the following sections of THIS skill are **suspended** for the sub-agent run: Session id (use parent's), Skill presence, Workspace initialization, Mode selection, Statusline install.
 
 What the sub-agent MUST still do: read PRD via `peaks request show`, run standards preflight (dry-run only), write planning artefact (`rd/tech-doc.md` for feature/refactor; `rd/bug-analysis.md` for bugfix; skip for config/docs/chore), return compact JSON envelope.
 
@@ -50,7 +57,7 @@ What the sub-agent MUST still do: read PRD via `peaks request show`, run standar
 
 ## Skill presence (MANDATORY first action — main-loop context only)
 
-When this skill is running in the main Claude session (not as a sub-agent — i.e. user invoked `peaks-rd` directly, or `peaks-solo` is executing the role inline in assisted/strict mode), before any analysis or tool call, immediately run `peaks skill presence:set peaks-rd --project <repo> --mode <mode> --gate startup`. Install statusline on first run. Read durable project memory via `peaks project memories --project <repo> --json`.
+When this skill is running in the main Claude session (not as a sub-agent — i.e. user invoked `peaks-rd` directly, or `peaks-code` is executing the role inline in assisted/strict mode), before any analysis or tool call, immediately run `peaks skill presence:set peaks-rd --project <repo> --mode <mode> --gate startup`. Install statusline on first run. Read durable project memory via `peaks project memories --project <repo> --json`.
 
 → see `references/skill-presence-and-title.md` for the full contract.
 
@@ -224,7 +231,7 @@ Do not bypass the parallel review fan-out when the slice has a code-review / qa-
 
 ## Sub-agent context governance (G7 + G7.7 + G8 + G9 — slice #010)
 
-RD sub-agent prompt template MUST include the G7 path convention + G8.6 share protocol. Detailed protocol: `skills/peaks-solo/references/context-governance.md` + `skills/peaks-solo/references/headroom-integration.md`.
+RD sub-agent prompt template MUST include the G7 path convention + G8.6 share protocol. Detailed protocol: `skills/peaks-code/references/context-governance.md` + `skills/peaks-code/references/headroom-integration.md`.
 
 → see `references/rd-context-governance.md` for the full G7 / G8.6 / G9 protocol + RD sub-agent prompt template.
 

package/skills/{peaks-rd → bee/peaks-rd}/references/browser-self-test-contracts.md

@@ -21,7 +21,7 @@ AskUserQuestion({
     { label: "Skip browser self-test, hand off to QA",
       description: "Mark the slice's browser self-test as deferred. Do NOT mark the slice as RD-done; transition to qa-handoff with browser-gate=blocked reason=login-required, and let QA's gate machinery surface the wall to the user again." },
     { label: "Cancel the workflow",
-      description: "Stop RD. Emit a blocked TXT handoff so peaks-solo can surface the auth wall to the user. Do not modify code paths that the browser gate would have covered." }
+      description: "Stop RD. Emit a blocked TXT handoff so peaks-code can surface the auth wall to the user. Do not modify code paths that the browser gate would have covered." }
   ]
 })
 ```

package/skills/{peaks-rd → bee/peaks-rd}/references/mock-data-placement.md

@@ -19,7 +19,7 @@ When the project-scan in `.peaks/_runtime/<sessionId>/rd/project-scan.md` identi
 
 2. **Never inline mock data in component files**: Mock data, fixture objects, and stub responses belong in dedicated mock files. Components should receive data through their normal channels (props, API calls via services). Writing `const mockData = [...]` inside a `.tsx` file is prohibited.
 
-3. **Mock files must export TypeScript interfaces**: Every mock response type must be exported so RD implementation and QA test-cases can import the same contract. See peaks-solo's "Frontend-only development mode" for the full mock-to-real migration pattern.
+3. **Mock files must export TypeScript interfaces**: Every mock response type must be exported so RD implementation and QA test-cases can import the same contract. See peaks-code's "Frontend-only development mode" for the full mock-to-real migration pattern.
 
 4. **Every mock file must be marked**: Add `// MOCK: Replace with real API call when swagger.json is available` at the top of every mock file.
 

package/skills/{peaks-rd → bee/peaks-rd}/references/parallel-review-fanout.md

@@ -1,6 +1,6 @@
 # Parallel review fan-out (RD)
 
-> Body of `## Parallel review fan-out`. **When RD reaches the end of implementation, the three review activities (code review, QA test-cases draft, AND karpathy review) run in parallel via `peaks sub-agent dispatch <role>` (then executing the returned toolCall), not sequentially.** This is the same fan-out pattern peaks-solo uses for the post-PRD swarm. RD itself, when it is the main loop, behaves as a sub-agent orchestrator: it issues 3 `peaks sub-agent dispatch` calls in a single message and waits for all to return before aggregating findings and transitioning to `qa-handoff`.
+> Body of `## Parallel review fan-out`. **When RD reaches the end of implementation, the three review activities (code review, QA test-cases draft, AND karpathy review) run in parallel via `peaks sub-agent dispatch <role>` (then executing the returned toolCall), not sequentially.** This is the same fan-out pattern peaks-code uses for the post-PRD swarm. RD itself, when it is the main loop, behaves as a sub-agent orchestrator: it issues 3 `peaks sub-agent dispatch` calls in a single message and waits for all to return before aggregating findings and transitioning to `qa-handoff`.
 
 **v2.12.0 collapse (Group A — Tier 1+2+3):** the previous 4-way fan-out (slice 004) plus the appended `karpathy-reviewer` (slice 5/6) totalled **5 sub-agents**. The `security-reviewer` and `perf-baseline-reviewer` slots moved out of the RD fan-out into two new standalone audit skills:
 

package/skills/{peaks-rd → bee/peaks-rd}/references/rd-fanout-contracts.md

@@ -73,7 +73,7 @@ end of implementation, RD fires 3 sub-agents in parallel via
   conversation context. They MUST NOT mutate parent settings
   (`peaks skill presence:set`, hooks install, `.claude/settings.json`).
 - Sub-agents MUST NOT call `peaks workflow verify-pipeline` — that is
-  Solo's responsibility.
+  Code's responsibility.
 - Sub-agents MUST NOT modify the request artifact body — they only
   write their respective review artifact.
 - Sub-agents MUST NOT install or persist external material (no

package/skills/{peaks-rd → bee/peaks-rd}/references/rd-runbook.md

@@ -28,7 +28,7 @@ peaks understand show   --project <repo> --json                # when UA artifac
 peaks codegraph context --project <repo> "<task>"
 peaks codegraph affected --project <repo> <changed-files...> --json
 
-# 4.1 read project-scan from Solo's pre-RD scan — BLOCKING if missing
+# 4.1 read project-scan from Code's pre-RD scan — BLOCKING if missing
 # **STOP if .peaks/_runtime/<sessionId>/rd/project-scan.md does not exist.**
 # **Do not write any code, do not plan any implementation, do not pass go.**
 # **Create the project-scan first, then proceed.**
@@ -164,7 +164,7 @@ peaks codegraph affected --project <repo> <changed-files...> --json
 #     Without project rules, security review and code review triggers won't fire.
 
 # 7. AFTER implementation, BEFORE QA handoff — RUN THESE GATES:
-#    Peaks-Loop Gate B2: unit tests exist and pass for the changed surface → npx vitest run --changed (or project equivalent; the changed-only mode is the peaks slice check default as of run 017; use --run-tests for the full suite, or invoke /peaks-solo-test to run the full suite standalone)
+#    Peaks-Loop Gate B2: unit tests exist and pass for the changed surface → npx vitest run --changed (or project equivalent; the changed-only mode is the peaks slice check default as of run 017; use --run-tests for the full suite, or invoke /peaks-code-test to run the full suite standalone)
 #    Peaks-Loop Gate B3: code review evidence → .peaks/_runtime/<sessionId>/rd/code-review.md
 #    Peaks-Loop Gate B4: security review evidence → .peaks/_runtime/<sessionId>/rd/security-review.md
 #    Peaks-Loop Gate B5 (NEW): RD artifact body has no unfilled placeholders.

package/skills/{peaks-rd → bee/peaks-rd}/references/rd-sub-agent-dispatch.md

@@ -1,6 +1,6 @@
 # Sub-agent dispatch (RD)
 
-> Body of `## Sub-agent dispatch`. When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-solo`, the following sections of THIS skill are **suspended** for the sub-agent run:
+> Body of `## Sub-agent dispatch`. When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` (then the LLM executes the returned toolCall) from `peaks-code`, the following sections of THIS skill are **suspended** for the sub-agent run:
 
 ## Default `--from-dag` is mandatory (slice 2026-06-24-efficiency-4p-bundle / G2 / P0.3)
 
@@ -32,26 +32,26 @@
 > `tests/unit/dispatch/dispatch-fanout-mandatory.test.ts` (≥ 8 cases
 > covering 1-leaf, 2-leaf, 3+-leaf, config/docs/chore type-bypass, and
 > the preferences-with-serial-default fan-out escape hatch). See also
-> `skills/peaks-solo/references/fanout-mandatory.md` for the
+> `skills/peaks-code/references/fanout-mandatory.md` for the
 > orchestrator-side rationale; the two files share the same wording by
 > design — if either changes, update the other.
 
 - **Session id** — use the parent's sid (read `.peaks/_runtime/session.json` or pass `--session-id <parent-sid>` to any session-creating CLI). Do NOT spawn your own session. The new `peaks session info --active` reads the canonical binding for you.
-- **Skill presence (MANDATORY first action)** — do NOT call `peaks skill presence:set peaks-rd`. The sub-agent must not overwrite `.peaks/.active-skill.json`; the main Solo loop owns that file. If you need to mark your own state, write a marker file at `.peaks/_runtime/<sessionId>/system/sub-agent-rd.json` and only that.
-- **Workspace initialization** — Solo has already run `peaks workspace init` before fan-out. Do not re-run it.
-- **Mode selection** — Solo has already chosen the mode. Read it from the prompt arguments (or from `.peaks/.active-skill.json` if you can, but do not write it).
-- **Statusline install** — already done by Solo at session startup; do not re-run.
+- **Skill presence (MANDATORY first action)** — do NOT call `peaks skill presence:set peaks-rd`. The sub-agent must not overwrite `.peaks/.active-skill.json`; the main Code loop owns that file. If you need to mark your own state, write a marker file at `.peaks/_runtime/<sessionId>/system/sub-agent-rd.json` and only that.
+- **Workspace initialization** — Code has already run `peaks workspace init` before fan-out. Do not re-run it.
+- **Mode selection** — Code has already chosen the mode. Read it from the prompt arguments (or from `.peaks/.active-skill.json` if you can, but do not write it).
+- **Statusline install** — already done by Code at session startup; do not re-run.
 
 What the sub-agent **MUST** still do, from this skill's contract:
 
-0. **Do NOT call `peaks request init`** — Solo has already initialised the request artefact slot in the main loop before fan-out (the runbook has the exact `peaks request init --role rd --id <rid> --project <repo> --apply --type <type> --json` call). The sub-agent reads the slot via `peaks request show <rid> --role rd --project <repo> --json` if it needs to. Note: `peaks request init` is **dry-run by default**. Pass `--apply` to actually create the artifact.
+0. **Do NOT call `peaks request init`** — Code has already initialised the request artefact slot in the main loop before fan-out (the runbook has the exact `peaks request init --role rd --id <rid> --project <repo> --apply --type <type> --json` call). The sub-agent reads the slot via `peaks request show <rid> --role rd --project <repo> --json` if it needs to. Note: `peaks request init` is **dry-run by default**. Pass `--apply` to actually create the artifact.
 2. `peaks request show <rid> --role prd --project <repo> --json` (and `--role ui` if UI is in the swarm plan).
-3. Standards preflight (dry-run only; Solo owns the apply step).
-4. Project-scan read; create `rd/project-scan.md` only if Solo flagged it missing in the dispatch prompt.
+3. Standards preflight (dry-run only; Code owns the apply step).
+4. Project-scan read; create `rd/project-scan.md` only if Code flagged it missing in the dispatch prompt.
 5. Write the planning artefact: `rd/requests/<rid>.md` (feature/refactor, per the `artifact-per-request.md` contract) or `rd/bug-analysis.md` (bugfix). If `--type` is `config|docs|chore`, **no planning artefact is required** — return immediately with `{"role":"rd-planning","status":"skipped","reason":"type=<type>"}`.
 
    > **v2.11.0 change (Group A):** `rd/tech-doc.md` is removed. The per-slice planning record is the per-request artefact at `rd/requests/<rid>.md`; the slice's source-of-truth architecture is the immutable peaks-prd handoff at `prd/handoff.md` (verify handoff hash = `<dispatched value>` before reading).
-6. Return only a compact JSON envelope — Solo will run the convergence gate (`ls` checks):
+6. Return only a compact JSON envelope — Code will run the convergence gate (`ls` checks):
 
 ```json
 {
@@ -67,12 +67,12 @@ What the sub-agent **MUST** still do, from this skill's contract:
 **Hard prohibitions** (sub-agent context, in addition to general red lines):
 
 - Do NOT call `Skill(skill="...")` from inside the sub-agent — that defeats the fan-out.
-- Do NOT call `peaks skill presence:set` — Solo owns the active-skill file.
+- Do NOT call `peaks skill presence:set` — Code owns the active-skill file.
 - Do NOT commit, push, install hooks, or apply settings.json mutations.
-- Do NOT ask the user interactive questions. If you need clarification, return `{"status":"blocked","blockedReason":"<text>"}` and let Solo handle the user message.
+- Do NOT ask the user interactive questions. If you need clarification, return `{"status":"blocked","blockedReason":"<text>"}` and let Code handle the user message.
 - Do NOT modify code (the Swarm phase is planning only; code edits happen in the RD implementation phase, which is a separate sub-agent or inline run after Gate B).
 
-After returning, Solo re-checks Gate B (`ls .peaks/_runtime/<sessionId>/rd/requests/<rid>.md` etc.) and proceeds to RD implementation, which is a different sub-agent or inline run.
+After returning, Code re-checks Gate B (`ls .peaks/_runtime/<sessionId>/rd/requests/<rid>.md` etc.) and proceeds to RD implementation, which is a different sub-agent or inline run.
 
 ## Test Tool Detection (mandatory)
 

package/skills/{peaks-rd → bee/peaks-rd}/references/rd-transition-gates.md

@@ -61,7 +61,7 @@ npx vitest run --changed --reporter=verbose 2>&1 | tail -20
 # Any failing test or zero tests for new code → BLOCKED. Write tests, then re-run.
 #
 # To run the FULL suite (slower; not the default for `peaks slice check`),
-# drop `--changed` or use `npx vitest run --reporter=verbose`. The peaks-solo-test
+# drop `--changed` or use `npx vitest run --reporter=verbose`. The peaks-code-test
 # skill is the user-facing wrapper for the full suite; the slice check's
 # `--run-tests` flag is the CLI opt-in.
 ```
@@ -104,7 +104,7 @@ peaks scan request-type-sanity --project <repo> --type <type> --json
 peaks request repair-status <rid> --project <repo> --session-id <session-id> --json
 # Expected: atCap=false. exit 0.
 # atCap=true → BLOCKED. Three repair cycles already attempted; emit a blocked TXT
-# handoff via Solo rather than entering a fourth cycle.
+# handoff via Code rather than entering a fourth cycle.
 ```
 
 **Peaks-Loop Gate B8 — Diff stays inside the declared red-line scope:**

package/skills/{peaks-rd → bee/peaks-rd}/references/skill-presence-and-title.md

@@ -1,6 +1,6 @@
 # Skill presence (RD)
 
-> Body of `## Skill presence (MANDATORY first action — main-loop context only)`. When this skill is running in the main Claude session (not as a sub-agent — i.e. user invoked `peaks-rd` directly, or `peaks-solo` is executing the role inline in assisted/strict mode), before any analysis or tool call, immediately run:
+> Body of `## Skill presence (MANDATORY first action — main-loop context only)`. When this skill is running in the main Claude session (not as a sub-agent — i.e. user invoked `peaks-rd` directly, or `peaks-code` is executing the role inline in assisted/strict mode), before any analysis or tool call, immediately run:
 
 ```bash
 peaks skill presence:set peaks-rd --project <repo> --mode <mode> --gate startup

package/skills/{peaks-reviewer → bee/peaks-reviewer}/SKILL.md

@@ -71,6 +71,6 @@ Missing section: reviewer is skipped (transition still passes; envelope records
 - DO NOT silently prompt users for API keys. Missing env vars surface as `providerUnavailable` and the `fallbackOnError` policy decides skip vs throw.
 - DO NOT change the schema for the 5 existing envelope parsers (v2.13.3 territory). The ReviewerEnvelope schema is additive.
 
-## Sub-agent dispatch (when launched by peaks-solo swarm)
+## Sub-agent dispatch (when launched by peaks-code swarm)
 
-When this skill runs as a sub-agent dispatched by peaks-solo, the sub-agent receives the parent session id and change-id via envelope. It MUST write its output to `.peaks/_runtime/<sessionId>/rd/third-party-review.json` + `.md` and return a compact JSON envelope.
+When this skill runs as a sub-agent dispatched by peaks-code, the sub-agent receives the parent session id and change-id via envelope. It MUST write its output to `.peaks/_runtime/<sessionId>/rd/third-party-review.json` + `.md` and return a compact JSON envelope.

package/skills/{peaks-sc → bee/peaks-sc}/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: peaks-sc
-description: Source control, sync, and change-control skill for Peaks. Use when a workflow needs change impact, artifact retention, commit boundaries, GitHub artifact repository pointers, sync state, or rollback evidence.
+description: |
+  Source control, sync, and change-control role for Peaks-Loop (LLM-only internal role;
+  not user-invocable. Triggered by peaks-code via `peaks sub-agent dispatch --role sc`.)
+  Use when a workflow needs change impact, artifact retention, commit boundaries,
+  GitHub artifact repository pointers, sync state, or rollback evidence.
+visibility: internal
+---
 ---
 
 # Peaks-Loop SC
@@ -55,7 +61,7 @@ Every SC invocation must write a change-control record at `.peaks/_runtime/<sess
 - validation result (`peaks sc validate` output);
 - boundary record (`peaks sc boundary` output).
 
-Solo reads this record before declaring the workflow complete.
+Code reads this record before declaring the workflow complete.
 
 ## Refactor role