peaks-cli 1.3.6 → 1.3.8

package/skills/peaks-solo/SKILL.md

@@ -141,11 +141,10 @@ The instant Peaks-Cli Solo is invoked, **before** the mode-selection question, b
 ```bash
 # Session ID is auto-generated when omitted; the command returns it in the JSON output.
 # Do NOT pass --session-id manually — the CLI is the single source of truth for the
-# project session binding. If you forge a session id with `openssl rand` and pass it
-# via --session-id, peaks workspace init will write it to .peaks/.session.json but
-# the binding only sticks if no prior session is open. To avoid the "two sessions
-# in .peaks/" confusion that bites Solo, always omit --session-id here and let the
-# CLI auto-generate.
+# project session binding. To look up the active session id from a skill / sub-agent,
+# use `peaks session info --active --json` (read-only, no side effects). To avoid
+# the "two sessions in .peaks/" confusion that bites Solo, always omit --session-id
+# here and let the CLI auto-generate.
 peaks workspace init --project <repo> --json
 peaks skill presence:set peaks-solo --project <repo> --gate startup
 ```
@@ -170,8 +169,9 @@ After Step 0 has anchored the workspace and presence, before Step 1 mode selecti
 **Detection logic** (all read-only, no side effects; uses only existing CLIs):
 
 ```bash
-# 1. Confirm the current session id
-sid=$(cat .peaks/.session.json | python3 -c "import sys,json; print(json.load(sys.stdin)['sessionId'])")
+# 1. Confirm the current session id via the read-only CLI primitive
+#    (the on-disk binding file is internal — never `cat` it directly)
+sid=$(peaks session info --active --project "$(git rev-parse --show-toplevel)" --json | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['sessionId'])")
 
 # 2. Enumerate the session's artifact tree (one `find` call, no new CLI)
 find ".peaks/$sid/" -type f 2>/dev/null | sort
@@ -287,7 +287,7 @@ Filter with `--kind <decision|convention|module|rule|reference|project|lesson>`
 Extract a short (8-20 Chinese characters, or 4-10 English words) descriptive title from the user's first request. The title should capture the core task — e.g. "修复登录页OAuth回调异常", "添加暗色模式开关", "搭建项目基础架构". Then run:
 
 ```bash
-peaks session title $(cat .peaks/.session.json | python3 -c "import sys,json; print(json.load(sys.stdin)['sessionId'])") "<title>"
+peaks session title $(peaks session info --active --project "$(git rev-parse --show-toplevel)" --json | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['sessionId'])") "<title>"
 ```
 
 If the session directory already has a title (check via `peaks session list --json`), skip this step — the title is already set.
@@ -332,7 +332,7 @@ For frontend workflows, RD and QA must use Playwright MCP for real browser E2E.
 
 The workspace is created in Step 0 (Startup sequence) as a mandatory first action — before any analysis, role handoff, or artifact write, and regardless of how lightweight the request is. Session IDs are now **auto-generated** with the format `YYYY-MM-DD-session-<6位hex>` (e.g. `2026-05-26-session-a3f8b1`). The user does not provide a session ID — the system creates and persists it in `.peaks/_runtime/session.json` (the canonical home as of slice `2026-06-05-peaks-runtime-layer`; the legacy `.peaks/.session.json` is read-only back-compat for one minor release).
 
-When `peaks workspace init` is run without `--session-id`, it automatically generates a new session ID using today's date and a random hex suffix. If a valid session binding exists at `.peaks/_runtime/session.json` (or the legacy `.peaks/.session.json` for pre-migration trees), the existing session is reused.
+When `peaks workspace init` is run without `--session-id`, it automatically generates a new session ID using today's date and a random hex suffix. If a valid session binding exists at `.peaks/_runtime/session.json` (the canonical home, slice 2026-06-05-peaks-runtime-layer; the legacy `.peaks/.session.json` is read-only back-compat for one minor release), the existing session is reused. To read the active session id from a skill or sub-agent, use the `peaks session info --active --json` primitive — never `cat` the on-disk file directly (the path is internal).
 
 **Existing old-session cleanup**: If `.peaks/` contains numeric-only or generic session directories from prior runs (e.g. `2026-05-25-auth-system`), create the new correctly-named session, migrate any reusable artifacts into it, and note the migration in the TXT handoff. Delete empty old-session directories.
 
@@ -346,9 +346,13 @@ The workspace initialization creates this structure under `.peaks/`:
 # Canonical home for all per-project ephemeral state (active-skill
 # marker, session binding, sop-state). All writes go here; reads also
 # tolerate the legacy paths (`.peaks/.active-skill.json`,
-# `.peaks/.session.json`, `.peaks/sop-state/`) for one minor release
-# so a fresh upgrade does not break in-flight workflows. Older trees
-# are auto-migrated by `peaks workspace reconcile --apply`.
+# `.peaks/.session.json` — read-only back-compat for one minor release,
+# `.peaks/sop-state/`) for one minor release so a fresh upgrade does
+# not break in-flight workflows. Older trees are auto-migrated by
+# `peaks workspace reconcile --apply`. Skills and sub-agents MUST
+# NOT `cat` any of these files directly — use `peaks session info
+# --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)
 ├── session.json        # project → session binding (the only single-session source of truth)
@@ -404,208 +408,13 @@ Do not default to git-backed storage or automatic commits for intermediate artif
 
 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.
 
-### 0. Project archetype detection (MANDATORY — run FIRST, deterministic CLI)
-
-Run the CLI; do NOT infer the archetype from prompts. Record the JSON output as `## Archetype` and `## Project mode` in `project-scan.md`. Later gates (frontend-only mode, visual system extraction, standards generation) read these fields.
-
-```bash
-peaks scan archetype --project <repo> --json
-```
-
-The command emits a stable JSON envelope with these fields you copy verbatim into `project-scan.md`:
-
-- `archetype`: `greenfield | legacy-frontend | legacy-fullstack | frontend-monorepo | unknown`
-- `confidence`: `high | medium | low`
-- `frontendOnly`: `true | false`
-- `frontendOnlyReason`: short string explaining the decision
-- `signals[]`: each signal's name, matched flag, and detail (paste under `## Archetype → Signals matched`)
-- `detected`: raw filesystem facts (package.json presence, backend frameworks, swagger paths, monorepo configs, src file count, lockfile age)
-
-If `archetype` is `unknown`, STOP and surface to the user as an open question in the TXT handoff — do NOT guess. If `confidence` is `low`, note the uncertainty in `project-scan.md` and confirm the choice with the user before proceeding.
-
-The CLI is the sole source of truth for archetype and frontend-only-mode decisions. Manual heuristics in older versions of this skill are superseded by the CLI output.
-
-### 1. Build tool: inspect config files for the framework
-
-| Config file | Framework |
-|---|---|
-| `.umirc.ts`, `config/config.ts` | Umi (Ant Design Pro) |
-| `next.config.*` | Next.js |
-| `vite.config.*` | Vite |
-| `rsbuild.config.*` | Rsbuild |
-| `rspack.config.*` | Rspack |
-| `farm.config.*` | Farm |
-| `craco.config.*` | CRA + craco |
-| `webpack.config.*` | Webpack |
-| `gulpfile.*` | Gulp (legacy) |
-| `angular.json` | Angular |
-| Custom `build/` or `scripts/build.*` only | Bespoke pipeline — record as `custom` and capture entry script path |
-
-If multiple build configs coexist (e.g. `webpack.config.js` + `vite.config.ts`), record ALL of them and mark `build.mixed: true`. Mixed builds are a constraint, not an error — do not silently pick one.
-
-### 2. Component library: check `package.json` dependencies
-
-| Package | Library |
-|---|---|
-| `antd` (capture major version: v3/v4/v5) | Ant Design |
-| `@ant-design/pro-components`, `@ant-design/pro-*` | Ant Design Pro suite |
-| `@mui/material` | Material UI |
-| `tailwindcss` + `radix-ui` | shadcn/ui |
-| `element-plus` / `element-ui` | Element UI/Plus |
-| `@arco-design/web-react` | Arco Design |
-| `tdesign-react` / `tdesign-vue-next` | TDesign |
-| `@douyinfe/semi-ui` | Semi Design |
-| `@nextui-org/react` | NextUI |
-| `@chakra-ui/react` | Chakra UI |
-| `vant` | Vant (mobile) |
-| Workspace package (`workspace:*`) or private-registry scope matching internal design system | In-house design system — record package name and entry path |
-
-**CRITICAL**: Never add a second component library to a project that already has one. Do not introduce shadcn/ui to an antd project or vice versa. For antd, ALSO record the major version — v3 / v4 / v5 have incompatible APIs and tokens; mixing component code across majors is a blocker.
-
-### 3. CSS framework: check for conflicts
-
-- **antd + TailwindCSS**: High conflict risk (preflight reset overrides base styles). Resolution:
-  - Both already in `package.json` → coexist; use Tailwind for layout, antd for components.
-  - Tailwind breaks antd styles → add `corePlugins: { preflight: false }` or `important: '#root'`.
-  - Only antd, user wants Tailwind → **Block**; propose antd `ConfigProvider` tokens or CSS Modules.
-- **Less/Sass**: Standard for Umi+antd projects; compatible with CSS Modules.
-- **CSS-in-JS (@emotion, styled-components)**: Check if component library already uses one internally; don't add competing solutions.
-
-### 4. State management, routing, data fetching: detect from `package.json`
-
-State: `zustand`, `jotai`, `redux`/`@reduxjs/toolkit`, `valtio`, `mobx`, `hox`
-Routing: `react-router-dom`, `@umijs/max`, Next.js file-based, `vue-router`
-Data fetching: `@tanstack/react-query`, `swr`, `ahooks` (`useRequest`), `umi-request`
-
-### 5. Legacy signals (legacy-frontend / legacy-fullstack only)
-
-Grep `src/` for outdated patterns and list them as constraints in `project-scan.md` under `## Legacy constraints`. RD must preserve these patterns for new code in the same file/module unless PRD explicitly authorizes modernization.
-
-| Signal | Detection |
-|---|---|
-| Class components | `extends React.Component` / `extends Component` in `.tsx`/`.jsx` |
-| `moment` instead of dayjs/date-fns | `package.json` dep |
-| Enzyme test suite | `package.json` dep `enzyme*` |
-| redux-saga / redux-thunk | `package.json` dep |
-| HOC-heavy patterns | `withRouter`, `connect()`, `compose(` frequency in `src/` |
-| Legacy lifecycle | `componentWillMount`/`componentWillReceiveProps` occurrences |
-| jQuery / Backbone / Vue 2 | `package.json` dep |
-| Inline styles dominant | `style={{` occurrences ≥ 50 |
-
-### 6. Project-scan artifact template
-
-```markdown
-# Project Scan: <project-name>
-**Date:** YYYY-MM-DD
-**Session:** <session-id>
-
-## Archetype
-- Type: <greenfield | legacy-frontend | legacy-fullstack | frontend-monorepo | unknown>
-- Signals matched: <bullet list of signals that drove the decision>
-
-## Project mode
-- Frontend-only: <true | false>
-- Reason: <archetype-derived | user-stated | backend-detected>
-
-## Build tool
-- Framework: <name> <version>
-- Config file: <path>
-- Mixed builds: <true | false; list all configs if true>
-
-## Component library
-- Library: <name> <version (major matters for antd)>
-- Design-system packages: <list>
-- In-house design system: <package name | none>
-
-## CSS solution
-- Primary: <Less/Sass/CSS-in-JS/TailwindCSS/CSS Modules>
-- Conflicts detected: <none | description and recommendation>
-
-## State management, routing, data fetching
-- State: <name>
-- Routing: <name>
-- Data fetching: <name>
-
-## Library versions
-- Source: output of `peaks scan libraries --project <repo> --json` (see Gate A; cross-check diff imports against `schemas/library-breaking-changes.data.json` in `peaks-rd` preflight)
-- Total: <count from scan.libraries.totalCount>
-- Notable: <bullet list of libraries with major >= a known breaking change in `schemas/library-breaking-changes.data.json`; e.g. "- antd@^5.18.0 (major=5) — see breaking-change rule for antd v4→v5 if any code uses Drawer.width">
-
-## Legacy constraints
-- <bullet list of legacy signals from section 5; empty for greenfield>
-```
+**Full checklist lives in [`references/project-scan-checklist.md`](references/project-scan-checklist.md)**: project archetype detection (Peaks-Cli Gate from `peaks scan archetype`), build-tool / component-library / CSS-framework / state-routing-data tables, legacy signals, and the project-scan artifact template. Read that file before doing the scan.
 
 ## Peaks-Cli Frontend-only development mode
 
 When the project has no live backend (no swagger.json, no API server), Solo must activate frontend-only mode.
 
-### Mode determination (deterministic — CLI is the source of truth)
-
-The CLI decision is authoritative. Read `frontendOnly` and `frontendOnlyReason` directly from the `peaks scan archetype --json` output and copy both into `project-scan.md` under `## Project mode`. Do NOT re-derive the decision from user phrasing.
-
-User-stated intent is **only** consulted when it conflicts with the CLI result. The two conflict cases:
-
-- **CLI says `frontendOnly=false` but the user says "前端项目 / 没有后端 / 先 mock 数据"**: STOP and `AskUserQuestion` to confirm whether to override the scan (the repo probably contains a backend folder the user wants to ignore). Record the override decision and reason in `project-scan.md`.
-- **CLI says `frontendOnly=true` but the user says "需要做后端 / 加 API"**: STOP and `AskUserQuestion` to confirm whether the request actually targets the missing backend (the user may be confused about repo scope, or there is a separate backend repo Solo should switch to).
-
-When there is no conflict, do not ask — the CLI value wins and the workflow proceeds.
-
-### Mock data strategy selection
-
-Solo records the chosen mock strategy in `.peaks/_runtime/<sessionId>/rd/tech-doc.md` under a `## Mock Data Strategy` section. The choice depends on the project scan results:
-
-| Project data-fetching pattern | Recommended mock approach | Rationale |
-|---|---|---|
-| Umi + `umi-request` / `@umijs/plugins` request | Umi mock directory (`mock/*.ts`) | Built-in, zero-config, auto-reload on file change |
-| `@tanstack/react-query` + custom fetcher | Service-layer mock with `Promise.resolve()` stubs in the service file | Keeps query hooks unchanged; swap fetcher target later |
-| `ahooks` `useRequest` + service functions | Service-layer mock: replace HTTP call with `Promise.resolve(mockData)` | Matches existing service-function pattern |
-| MSW (Mock Service Worker) already configured | Add new handlers to existing MSW setup | Consistent with project convention |
-| No existing pattern (greenfield) | Service-layer mock with a `mock/` directory and typed fixture files | Clean separation, easy to delete later |
-| Existing `src/services/*` but no fetcher abstraction | Inline mock inside the service file; preserve the function signature | Keeps existing call-sites unchanged |
-| Mixed data-fetching styles (e.g. react-query + raw fetch in legacy files) | Match the style of the most recently added code in the same module | Avoid introducing a third style |
-| Cannot decide from scan alone | STOP and `AskUserQuestion` | Asking once beats picking differently on every run |
-
-**Mock data rules:**
-
-1. Every mock response must match the shape of the expected real API response. Define a TypeScript interface for the response type first, then create mock data that satisfies it.
-2. Mock data should be realistic (not `"test"`, `"foo"`, `123`) — use plausible Chinese/English content that resembles production data.
-3. Each mock must export its TypeScript interface so RD implementation and QA test-cases can import the same types.
-4. Mark every mock file with a header comment: `// MOCK: Replace with real API call when swagger.json is available`.
-5. Before producing any mock file, register the plan in `.peaks/_runtime/<sessionId>/rd/mock-plan.md` with: chosen strategy (from the table above), planned file paths, and a one-line rationale per file. This file is the source of truth for mock locations across runs — RD must read it before writing code, QA must read it before writing test cases.
-
-### API contract placeholder pattern
-
-When no swagger.json exists, RD defines API contracts as TypeScript interfaces with a mock-then-real service layer:
-
-```
-src/services/types/<feature>-api.types.ts   ← API request/response interfaces
-src/services/<feature>-service.ts          ← Service functions (mock → real)
-mock/<feature>-mock.ts                     ← Mock data satisfying interfaces
-```
-
-Each service function returns a typed mock response marked with `// MOCK: Replace with real API call when swagger.json is available`.
-
-### Mock-to-real migration path
-
-When swagger.json becomes available later, the migration follows this sequence:
-
-1. Generate typed API client from swagger.json (e.g. via `openapi-typescript` or manual mapping).
-2. Replace mock imports with generated API calls, one service file at a time.
-3. Remove corresponding mock files.
-4. Run QA regression to verify the real API responses match the mock interface contracts.
-
-Solo records the migration readiness in the TXT handoff capsule under a `## API Migration` section listing: mock file paths, the corresponding swagger endpoints (when known), and the migration status for each.
-
-### Feishu document access fallback
-
-When the PRD source is a Feishu/Lark document that requires authentication:
-
-1. **Primary path**: Playwright MCP headed browser → user completes login → Solo reads document content via `browser_snapshot`.
-2. **Fallback A (user cannot login)**: Ask user to copy-paste the document content or export as Markdown/PDF. Solo creates the PRD artifact from the pasted content.
-3. **Fallback B (user provides export)**: User drops a `.md` or `.pdf` export into `.peaks/_runtime/<sessionId>/prd/source/`. Solo reads and processes it.
-4. **Fallback C (none of the above)**: Mark PRD as `blocked` with reason `doc-inaccessible`, list the exact next steps for the user, and pause the workflow.
-
-Never silently fall back to unauthenticated `fetch` or `WebFetch` for authenticated documents.
+**Full frontend-only contract lives in [`references/frontend-only-mode.md`](references/frontend-only-mode.md)**: mode determination (CLI is authoritative), mock-data strategy table by project data-fetching pattern, mock data rules, API contract placeholder pattern (`src/services/types/` + `src/services/` + `mock/`), mock-to-real migration path, and the Feishu document access fallback chain. Read that file before producing any mock files.
 
 ## Peaks-Cli Request type classification + Workflow order + Transition verification gates
 

package/skills/peaks-solo/references/frontend-only-mode.md

@@ -0,0 +1,73 @@
+# Peaks-Cli 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.
+
+When the project has no live backend (no swagger.json, no API server), Solo must activate frontend-only mode.
+
+### Mode determination (deterministic — CLI is the source of truth)
+
+The CLI decision is authoritative. Read `frontendOnly` and `frontendOnlyReason` directly from the `peaks scan archetype --json` output and copy both into `project-scan.md` under `## Project mode`. Do NOT re-derive the decision from user phrasing.
+
+User-stated intent is **only** consulted when it conflicts with the CLI result. The two conflict cases:
+
+- **CLI says `frontendOnly=false` but the user says "前端项目 / 没有后端 / 先 mock 数据"**: STOP and `AskUserQuestion` to confirm whether to override the scan (the repo probably contains a backend folder the user wants to ignore). Record the override decision and reason in `project-scan.md`.
+- **CLI says `frontendOnly=true` but the user says "需要做后端 / 加 API"**: STOP and `AskUserQuestion` to confirm whether the request actually targets the missing backend (the user may be confused about repo scope, or there is a separate backend repo Solo should switch to).
+
+When there is no conflict, do not ask — the CLI value wins and the workflow proceeds.
+
+### Mock data strategy selection
+
+Solo records the chosen mock strategy in `.peaks/_runtime/<sessionId>/rd/tech-doc.md` under a `## Mock Data Strategy` section. The choice depends on the project scan results:
+
+| Project data-fetching pattern | Recommended mock approach | Rationale |
+|---|---|---|
+| Umi + `umi-request` / `@umijs/plugins` request | Umi mock directory (`mock/*.ts`) | Built-in, zero-config, auto-reload on file change |
+| `@tanstack/react-query` + custom fetcher | Service-layer mock with `Promise.resolve()` stubs in the service file | Keeps query hooks unchanged; swap fetcher target later |
+| `ahooks` `useRequest` + service functions | Service-layer mock: replace HTTP call with `Promise.resolve(mockData)` | Matches existing service-function pattern |
+| MSW (Mock Service Worker) already configured | Add new handlers to existing MSW setup | Consistent with project convention |
+| No existing pattern (greenfield) | Service-layer mock with a `mock/` directory and typed fixture files | Clean separation, easy to delete later |
+| Existing `src/services/*` but no fetcher abstraction | Inline mock inside the service file; preserve the function signature | Keeps existing call-sites unchanged |
+| Mixed data-fetching styles (e.g. react-query + raw fetch in legacy files) | Match the style of the most recently added code in the same module | Avoid introducing a third style |
+| Cannot decide from scan alone | STOP and `AskUserQuestion` | Asking once beats picking differently on every run |
+
+**Mock data rules:**
+
+1. Every mock response must match the shape of the expected real API response. Define a TypeScript interface for the response type first, then create mock data that satisfies it.
+2. Mock data should be realistic (not `"test"`, `"foo"`, `123`) — use plausible Chinese/English content that resembles production data.
+3. Each mock must export its TypeScript interface so RD implementation and QA test-cases can import the same types.
+4. Mark every mock file with a header comment: `// MOCK: Replace with real API call when swagger.json is available`.
+5. Before producing any mock file, register the plan in `.peaks/_runtime/<sessionId>/rd/mock-plan.md` with: chosen strategy (from the table above), planned file paths, and a one-line rationale per file. This file is the source of truth for mock locations across runs — RD must read it before writing code, QA must read it before writing test cases.
+
+### API contract placeholder pattern
+
+When no swagger.json exists, RD defines API contracts as TypeScript interfaces with a mock-then-real service layer:
+
+```
+src/services/types/<feature>-api.types.ts   ← API request/response interfaces
+src/services/<feature>-service.ts          ← Service functions (mock → real)
+mock/<feature>-mock.ts                     ← Mock data satisfying interfaces
+```
+
+Each service function returns a typed mock response marked with `// MOCK: Replace with real API call when swagger.json is available`.
+
+### Mock-to-real migration path
+
+When swagger.json becomes available later, the migration follows this sequence:
+
+1. Generate typed API client from swagger.json (e.g. via `openapi-typescript` or manual mapping).
+2. Replace mock imports with generated API calls, one service file at a time.
+3. Remove corresponding mock files.
+4. Run QA regression to verify the real API responses match the mock interface contracts.
+
+Solo records the migration readiness in the TXT handoff capsule under a `## API Migration` section listing: mock file paths, the corresponding swagger endpoints (when known), and the migration status for each.
+
+### Feishu document access fallback
+
+When the PRD source is a Feishu/Lark document that requires authentication:
+
+1. **Primary path**: Playwright MCP headed browser → user completes login → Solo reads document content via `browser_snapshot`.
+2. **Fallback A (user cannot login)**: Ask user to copy-paste the document content or export as Markdown/PDF. Solo creates the PRD artifact from the pasted content.
+3. **Fallback B (user provides export)**: User drops a `.md` or `.pdf` export into `.peaks/_runtime/<sessionId>/prd/source/`. Solo reads and processes it.
+4. **Fallback C (none of the above)**: Mark PRD as `blocked` with reason `doc-inaccessible`, list the exact next steps for the user, and pause the workflow.
+
+Never silently fall back to unauthenticated `fetch` or `WebFetch` for authenticated documents.

package/skills/peaks-solo/references/micro-cycle.md

@@ -89,12 +89,14 @@ peaks slice check [--rid <rid>] [--project <path>] [--json]
 
 这个命令编排：
 1. `npx tsc --noEmit`（typecheck）
-2. `npx vitest run`（全 suite）
+2. `npx vitest run --changed`（默认；changed-only suite，只跑 git 改动相关的 test，~1-3s）。要全量请加 `--run-tests`；要彻底跳过请加 `--skip-tests`。
 3. 3-way fan-out（code-review + security-review + perf-baseline）
 4. `peaks workflow verify-pipeline --rid <rid> --project <path>`
 
 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`。
+
 ## Micro-cycle → 边界 check → QA 的串联
 
 ```
@@ -139,7 +141,7 @@ verdict=return-to-rd → RD 修 (new slice 内部走 micro-cycle)
 ## 为什么这套比当前 peaks-solo 的设计合理
 
 - **快**：micro-cycle ~100ms（vs 30s 全 suite），改 10 个 bug 从 5 分钟降到 30 秒
-- **稳**：边界 check 不省，4 项检查（tsc + vitest + 3-way + verify-pipeline）一次全跑
+- **稳**：边界 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 验证
 

package/skills/peaks-solo/references/project-scan-checklist.md

@@ -0,0 +1,136 @@
+# Peaks-Cli 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.
+
+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.
+
+### 0. Project archetype detection (MANDATORY — run FIRST, deterministic CLI)
+
+Run the CLI; do NOT infer the archetype from prompts. Record the JSON output as `## Archetype` and `## Project mode` in `project-scan.md`. Later gates (frontend-only mode, visual system extraction, standards generation) read these fields.
+
+```bash
+peaks scan archetype --project <repo> --json
+```
+
+The command emits a stable JSON envelope with these fields you copy verbatim into `project-scan.md`:
+
+- `archetype`: `greenfield | legacy-frontend | legacy-fullstack | frontend-monorepo | unknown`
+- `confidence`: `high | medium | low`
+- `frontendOnly`: `true | false`
+- `frontendOnlyReason`: short string explaining the decision
+- `signals[]`: each signal's name, matched flag, and detail (paste under `## Archetype → Signals matched`)
+- `detected`: raw filesystem facts (package.json presence, backend frameworks, swagger paths, monorepo configs, src file count, lockfile age)
+
+If `archetype` is `unknown`, STOP and surface to the user as an open question in the TXT handoff — do NOT guess. If `confidence` is `low`, note the uncertainty in `project-scan.md` and confirm the choice with the user before proceeding.
+
+The CLI is the sole source of truth for archetype and frontend-only-mode decisions. Manual heuristics in older versions of this skill are superseded by the CLI output.
+
+### 1. Build tool: inspect config files for the framework
+
+| Config file | Framework |
+|---|---|
+| `.umirc.ts`, `config/config.ts` | Umi (Ant Design Pro) |
+| `next.config.*` | Next.js |
+| `vite.config.*` | Vite |
+| `rsbuild.config.*` | Rsbuild |
+| `rspack.config.*` | Rspack |
+| `farm.config.*` | Farm |
+| `craco.config.*` | CRA + craco |
+| `webpack.config.*` | Webpack |
+| `gulpfile.*` | Gulp (legacy) |
+| `angular.json` | Angular |
+| Custom `build/` or `scripts/build.*` only | Bespoke pipeline — record as `custom` and capture entry script path |
+
+If multiple build configs coexist (e.g. `webpack.config.js` + `vite.config.ts`), record ALL of them and mark `build.mixed: true`. Mixed builds are a constraint, not an error — do not silently pick one.
+
+### 2. Component library: check `package.json` dependencies
+
+| Package | Library |
+|---|---|
+| `antd` (capture major version: v3/v4/v5) | Ant Design |
+| `@ant-design/pro-components`, `@ant-design/pro-*` | Ant Design Pro suite |
+| `@mui/material` | Material UI |
+| `tailwindcss` + `radix-ui` | shadcn/ui |
+| `element-plus` / `element-ui` | Element UI/Plus |
+| `@arco-design/web-react` | Arco Design |
+| `tdesign-react` / `tdesign-vue-next` | TDesign |
+| `@douyinfe/semi-ui` | Semi Design |
+| `@nextui-org/react` | NextUI |
+| `@chakra-ui/react` | Chakra UI |
+| `vant` | Vant (mobile) |
+| Workspace package (`workspace:*`) or private-registry scope matching internal design system | In-house design system — record package name and entry path |
+
+**CRITICAL**: Never add a second component library to a project that already has one. Do not introduce shadcn/ui to an antd project or vice versa. For antd, ALSO record the major version — v3 / v4 / v5 have incompatible APIs and tokens; mixing component code across majors is a blocker.
+
+### 3. CSS framework: check for conflicts
+
+- **antd + TailwindCSS**: High conflict risk (preflight reset overrides base styles). Resolution:
+  - Both already in `package.json` → coexist; use Tailwind for layout, antd for components.
+  - Tailwind breaks antd styles → add `corePlugins: { preflight: false }` or `important: '#root'`.
+  - Only antd, user wants Tailwind → **Block**; propose antd `ConfigProvider` tokens or CSS Modules.
+- **Less/Sass**: Standard for Umi+antd projects; compatible with CSS Modules.
+- **CSS-in-JS (@emotion, styled-components)**: Check if component library already uses one internally; don't add competing solutions.
+
+### 4. State management, routing, data fetching: detect from `package.json`
+
+State: `zustand`, `jotai`, `redux`/`@reduxjs/toolkit`, `valtio`, `mobx`, `hox`
+Routing: `react-router-dom`, `@umijs/max`, Next.js file-based, `vue-router`
+Data fetching: `@tanstack/react-query`, `swr`, `ahooks` (`useRequest`), `umi-request`
+
+### 5. Legacy signals (legacy-frontend / legacy-fullstack only)
+
+Grep `src/` for outdated patterns and list them as constraints in `project-scan.md` under `## Legacy constraints`. RD must preserve these patterns for new code in the same file/module unless PRD explicitly authorizes modernization.
+
+| Signal | Detection |
+|---|---|
+| Class components | `extends React.Component` / `extends Component` in `.tsx`/`.jsx` |
+| `moment` instead of dayjs/date-fns | `package.json` dep |
+| Enzyme test suite | `package.json` dep `enzyme*` |
+| redux-saga / redux-thunk | `package.json` dep |
+| HOC-heavy patterns | `withRouter`, `connect()`, `compose(` frequency in `src/` |
+| Legacy lifecycle | `componentWillMount`/`componentWillReceiveProps` occurrences |
+| jQuery / Backbone / Vue 2 | `package.json` dep |
+| Inline styles dominant | `style={{` occurrences ≥ 50 |
+
+### 6. Project-scan artifact template
+
+```markdown
+# Project Scan: <project-name>
+**Date:** YYYY-MM-DD
+**Session:** <session-id>
+
+## Archetype
+- Type: <greenfield | legacy-frontend | legacy-fullstack | frontend-monorepo | unknown>
+- Signals matched: <bullet list of signals that drove the decision>
+
+## Project mode
+- Frontend-only: <true | false>
+- Reason: <archetype-derived | user-stated | backend-detected>
+
+## Build tool
+- Framework: <name> <version>
+- Config file: <path>
+- Mixed builds: <true | false; list all configs if true>
+
+## Component library
+- Library: <name> <version (major matters for antd)>
+- Design-system packages: <list>
+- In-house design system: <package name | none>
+
+## CSS solution
+- Primary: <Less/Sass/CSS-in-JS/TailwindCSS/CSS Modules>
+- Conflicts detected: <none | description and recommendation>
+
+## State management, routing, data fetching
+- State: <name>
+- Routing: <name>
+- Data fetching: <name>
+
+## Library versions
+- Source: output of `peaks scan libraries --project <repo> --json` (see Gate A; cross-check diff imports against `schemas/library-breaking-changes.data.json` in `peaks-rd` preflight)
+- Total: <count from scan.libraries.totalCount>
+- Notable: <bullet list of libraries with major >= a known breaking change in `schemas/library-breaking-changes.data.json`; e.g. "- antd@^5.18.0 (major=5) — see breaking-change rule for antd v4→v5 if any code uses Drawer.width">
+
+## Legacy constraints
+- <bullet list of legacy signals from section 5; empty for greenfield>
+```