peaks-cli 1.0.16 → 1.0.17

package/dist/src/shared/version.d.ts

@@ -1 +1 @@
-export declare const CLI_VERSION = "1.0.16";
+export declare const CLI_VERSION = "1.0.17";

package/dist/src/shared/version.js

@@ -1 +1 @@
-export const CLI_VERSION = "1.0.16";
+export const CLI_VERSION = "1.0.17";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peaks-cli",
-  "version": "1.0.16",
+  "version": "1.0.17",
   "description": "Peaks CLI and short skill family for Claude Code automation.",
   "author": "SquabbyZ",
   "license": "MIT",

package/skills/peaks-solo/SKILL.md

@@ -9,12 +9,34 @@ Peaks Solo is the orchestration facade for the Peaks short skill family.
 
 Use this skill to identify the user scenario, recommend an execution mode, coordinate role skills, and produce the final handoff report. Do not collapse role responsibilities into this skill.
 
-## Skill presence (MANDATORY first action)
+## Startup sequence (MANDATORY — execute in order)
 
-Before any analysis, response, or tool call, immediately run:
+### Step 1: Mode selection (MUST run before presence:set)
+
+When the user invokes Peaks Solo without explicitly naming an execution profile, use `AskUserQuestion` BEFORE any other action. Present the recommended full-auto path as the first/default option with a practical description for each:
+
+1. **Full auto (Recommended)** — Peaks handles planning, role coordination, validation, and compact handoff end-to-end while preserving required confirmation gates for risky or shared-state actions.
+2. **Assisted** — Peaks proposes plans, artifacts, and checks, then pauses for user decisions at major workflow boundaries.
+3. **Swarm** — Peaks maximizes safe parallel role/worker execution for larger RD or QA workloads while keeping reducer validation and artifact boundaries explicit.
+4. **Strict** — Peaks uses the most conservative gates: explicit confirmations, strict slice specs, coverage evidence, QA acceptance, and commit boundaries before continuing.
+
+Map the user's selection to the `--mode` flag value:
+
+| User selects | `--mode` value |
+|---|---|
+| Full auto | `solo` |
+| Assisted | `assisted` |
+| Swarm | `swarm` |
+| Strict | `strict` |
+
+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.
+
+### Step 2: Set skill presence
+
+Only after the mode is known (user selected or explicitly named), run:
 
 ```bash
-peaks skill presence:set peaks-solo --mode <mode> --gate startup
+peaks skill presence:set peaks-solo --mode <mode-value> --gate startup
 ```
 
 Then display the compact status header: `Peaks Skill: peaks-solo | Gate: startup | Next: <one short action>`. Display this header on EVERY turn while the skill is active.
@@ -45,9 +67,9 @@ Use the Peaks CLI for runtime side effects.
 
 ## GStack integration
 
-Map gstack `Think→Plan→Build→Review→Test→Ship→Reflect` stages to Peaks role artifacts (PRD/RD/UI/QA/SC/TXT) and `/autoplan`/`/retro` patterns. Preserve Peaks confirmation gates and artifact boundaries; do not delegate orchestration to gstack commands.
+Map gstack stages to Peaks role artifacts; preserve Peaks confirmation gates. Do not delegate orchestration to gstack commands.
 
-For frontend workflows, Solo must ensure RD and QA use Playwright MCP for real browser E2E. Install via `peaks mcp plan/apply --capability playwright-mcp.browser-validation --yes`. Chrome DevTools MCP is a secondary CDP surface only — it does NOT launch a browser. If login/CAPTCHA/SSO/MFA appears, wait for user to complete login and explicitly confirm. Sanitize browser artifacts before retention (no login URLs, cookies, tokens, PII). Canonical workflow: `references/browser-workflow.md`.
+For frontend workflows, RD and QA must use Playwright MCP for real browser E2E (`peaks mcp plan/apply --capability playwright-mcp.browser-validation --yes`). Chrome DevTools MCP is a secondary CDP surface only. Sanitize browser artifacts before retention (no login URLs, cookies, tokens, PII). See `references/browser-workflow.md`.
 
 ## Local intermediate artifact workspace (MANDATORY)
 
@@ -70,14 +92,22 @@ peaks workspace init --project <repo> --session-id <YYYY-MM-DD-<slug>> --json
 The workspace initialization creates this structure under `.peaks/<session-id>/`:
 
 ```
-prd/requests/   # PRD artifacts (goals, non-goals, acceptance, frontend delta)
-ui/requests/    # UI artifacts (design drafts, visual direction, taste reports)
-rd/requests/    # RD artifacts (tech docs, scan reports, slice specs, coverage, CR findings)
-qa/requests/    # QA artifacts (test cases, test reports, regression matrices, browser evidence)
+prd/source/     # PRD source documents (Feishu exports, pasted content)
+prd/requests/   # PRD request artifacts (goals, non-goals, acceptance, frontend delta)
+ui/requests/    # UI request artifacts (visual direction, taste reports)
+rd/requests/    # RD request artifacts (slice specs, coverage, CR findings)
+qa/test-cases/  # QA test cases
+qa/test-reports/ # QA test reports (regression matrices, browser evidence)
+qa/requests/    # QA request artifacts
 sc/             # SC artifacts (change-control, impact, retention, boundary)
 txt/            # TXT artifacts (handoff capsules, lessons, memory extraction)
 ```
 
+Role skills create these key files at the directory levels shown above:
+- `rd/project-scan.md` (Solo step 0.6), `rd/tech-doc.md` (RD planning step 3b)
+- `ui/design-draft.md` (UI step 3a)
+- Request-scoped files under each role's `requests/` subdirectory
+
 ### Root pollution prohibition (CRITICAL)
 
 **NEVER write Peaks intermediate artifacts to the project root directory.** Specifically prohibited at root level:
@@ -99,72 +129,49 @@ Do not default to git-backed storage or automatic commits for intermediate artif
 
 ## Pre-RD project scan checklist (MANDATORY)
 
-Before handing off to `peaks-rd` for implementation, Peaks Solo MUST scan the target project and record these findings in `.peaks/<session-id>/rd/project-scan.md`. This prevents component-library misidentification, CSS framework conflicts, and build-tool mismatches.
+Before handing off to `peaks-rd`, scan the project and record findings to `.peaks/<session-id>/rd/project-scan.md`. RD and UI roles read this before starting work.
 
-### 1. Build tool and framework detection
-
-Identify the project's build tool and meta-framework by inspecting config files:
+### 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 |
-| `webpack.config.*` | Webpack (CRA, custom) |
+| `webpack.config.*` | Webpack |
 | `angular.json` | Angular |
 
-Record the detected framework and its version from `package.json`.
-
-### 2. Component library detection
-
-Identify the UI component library in use by checking `package.json` dependencies:
+### 2. Component library: check `package.json` dependencies
 
 | Package | Library |
 |---|---|
 | `antd` | Ant Design |
-| `@mui/material`, `@emotion/*` | Material UI (MUI) |
-| `@shadcn/ui`, `tailwindcss` + `radix-ui` | shadcn/ui |
-| `element-plus`, `element-ui` | Element UI/Plus |
+| `@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 |
 | `@nextui-org/react` | NextUI |
 | `@chakra-ui/react` | Chakra UI |
-| `tdesign-react`, `tdesign-vue-next` | TDesign |
 
-**CRITICAL**: Never assume the component library. If the project uses `antd` and `@ant-design/pro-components`, do not introduce shadcn/ui components or vice versa. Adding a second component library to a project that already has one will cause style conflicts and bloated bundles.
+**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.
 
-Record the detected library, version, and any design-system packages (e.g. `@ant-design/pro-components`, `@ant-design/icons`).
+### 3. CSS framework: check for conflicts
 
-### 3. CSS framework detection and conflict prevention
+- **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.
 
-Check `package.json` for CSS solutions and detect conflicts:
+### 4. State management, routing, data fetching: detect from `package.json`
 
-- **TailwindCSS** (`tailwindcss` in devDependencies) + **antd**: High conflict risk. Tailwind's preflight reset overrides antd's base styles. If TailwindCSS is not already in `package.json`, do NOT add it to a project that uses a component library with its own CSS-in-JS or Less/Sass solution.
-- **CSS Modules** (`.module.css`, `.module.less`): Compatible with most component libraries.
-- **styled-components / @emotion**: Check if the component library already uses these internally (MUI uses Emotion, antd v5 uses CSS-in-JS with `@ant-design/cssinjs`). Do not add a competing CSS-in-JS solution.
-- **Less/Sass**: Umi + antd projects typically use Less. Adding TailwindCSS on top of Less requires `postcss.config.js` and may cause selector specificity wars.
+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`
 
-Record the CSS solution(s), any detected conflicts, and a recommendation. If a conflict is detected (e.g. TailwindCSS added to an antd project), apply the resolution decision tree before blocking:
-
-**CSS conflict resolution (when both TailwindCSS and a component library coexist):**
-
-| Scenario | Resolution | Priority |
-|---|---|---|
-| TailwindCSS + antd already in `package.json` (project lives with both) | Do not remove either. Record as "coexisting — project already handles specificity." RD uses Tailwind for layout/spacing utilities and antd for component styling. Add `@layer` directives if Tailwind preflight breaks antd. | Non-blocking |
-| TailwindCSS present but antd styles visibly broken | Add `corePlugins: { preflight: false }` to `tailwind.config.js` or scope Tailwind with `important: '#root'`. Record the fix in project-scan. | Fix before RD |
-| Project has only antd, user wants TailwindCSS | **Block.** Propose alternatives: CSS Modules + antd's `ConfigProvider` token system, or antd's built-in utility patterns. Only proceed with TailwindCSS if user explicitly confirms after seeing the conflict warning. | Blocking |
-
-If none of the above apply and the conflict cannot be resolved automatically, flag as a blocking pre-RD issue with the specific conflict description and proposed resolution options for user decision.
-
-### 4. State management, routing, and data fetching
-
-Detect and record:
-- State management: `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. Project-scan artifact
-
-Write the scan result to `.peaks/<session-id>/rd/project-scan.md` with these sections:
+### 5. Project-scan artifact template
 
 ```markdown
 # Project Scan: <project-name>
@@ -189,8 +196,6 @@ Write the scan result to `.peaks/<session-id>/rd/project-scan.md` with these sec
 - Data fetching: <name>
 ```
 
-RD and UI roles read this scan before starting work. Solo must not hand off to RD without this artifact.
-
 ## Frontend-only development mode
 
 When the project is a pure frontend repository without a live backend (no swagger.json, no API server), Solo must activate frontend-only mode. This is triggered when the user says "先 mock 数据", "没有后端", "前端仓", or similar.
@@ -216,31 +221,15 @@ Solo records the chosen mock strategy in `.peaks/<session-id>/rd/tech-doc.md` un
 
 ### API contract placeholder pattern
 
-When no swagger.json exists, RD defines API contracts as TypeScript interfaces in a dedicated location:
+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
-    <feature>-service.ts        ← Service functions (mock now, real later)
-  mock/
-    <feature>-mock.ts           ← Mock data satisfying the interfaces
+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 follows this migration-ready pattern:
-
-```typescript
-// src/services/knowledge-service.ts
-import type { KnowledgeListResponse, KnowledgeCreateRequest } from './types/knowledge-api.types';
-// MOCK: Replace mock import with real HTTP call when swagger.json is available
-import { mockKnowledgeList } from '@/mock/knowledge-mock';
-
-export async function fetchKnowledgeList(params: KnowledgeListParams): Promise<KnowledgeListResponse> {
-  // TODO: Replace with real API call — POST /api/v1/knowledge/list
-  return mockKnowledgeList;
-}
-```
+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
 
@@ -266,22 +255,25 @@ Never silently fall back to unauthenticated `fetch` or `WebFetch` for authentica
 
 When Peaks Solo coordinates development in a code repository, keep this order explicit:
 
-0. workspace initialization (`.peaks/<session-id>/` created, directory structure verified);
-1. project scan (component library, CSS framework, build tool detected and recorded);
-2. standards preflight;
-3. PRD scope and spec artifacts — confirmed by user;
-4. **Swarm parallel phase** — after PRD confirmed, launch UI, RD(planning), QA(test-cases) simultaneously:
-   4a. UI design draft and visual direction (MANDATORY when request is frontend/user-visible);
-   4b. RD tech-doc (architecture planning, component tree, data flow, API contracts);
-   4c. QA test-case generation (unit, integration, UI-regression test cases);
-5. OpenSpec change artifacts for non-trivial work when `openspec/` already exists or the user approves adding it;
-6. RD implementation slices (consumes UI design-draft + RD tech-doc + QA test-cases);
-7. unit tests for new/changed behavior, with focused new-code coverage accepted for legacy low-coverage repos;
-8. code review and security review with CRITICAL/HIGH issues fixed before progression; marked-blocked CRITICAL/HIGH issues only allow a blocked handoff, not QA or completion;
-9. RD post-check dry-run;
-10. QA validation (auto-proceed from RD), executing test cases + API checks + Playwright MCP headed browser E2E for frontend;
-11. QA security and performance checks plus test report;
-12. TXT final handoff capsule, including reusable skill-usage lessons when the workflow revealed new habits or preferences.
+0. **Snapshot** — `peaks doctor` + `peaks project dashboard` to capture baseline state before anything else;
+0.5. **Workspace initialization** — `.peaks/<session-id>/` created, directory structure verified;
+0.6. **Project scan** — component library, CSS framework, build tool, state management, routing, data fetching detected and recorded to `.peaks/<session-id>/rd/project-scan.md`;
+1. **Standards preflight** — `peaks standards init/update --dry-run`, must reference concrete project-scan findings (never emit generic templates);
+2. **PRD phase** — capture request as canonical artifact, extract scope and acceptance criteria:
+   - Full-auto/Swarm: auto-transition to `confirmed-by-user` once the artifact is complete;
+   - Assisted/Strict: pause with `AskUserQuestion` for explicit user confirmation before proceeding;
+3. **Swarm parallel phase** — after PRD confirmed, launch UI, RD(planning), QA(test-cases) simultaneously:
+   3a. UI design draft and visual direction (MANDATORY when request is frontend/user-visible);
+   3b. RD tech-doc (architecture planning, component tree, data flow, API contracts);
+   3c. QA test-case generation (unit, integration, UI-regression test cases);
+4. **RD implementation** — consumes UI design-draft + RD tech-doc + QA test-cases + project-scan; includes unit tests for new/changed behavior (TDD);
+5. **Code review + security review** — CRITICAL/HIGH issues fixed before progression; marked-blocked issues only allow a blocked handoff;
+6. **QA validation** (auto-proceed from RD in full-auto) — execute test cases + API checks + Playwright MCP headed browser E2E for frontend + security/perf checks + test report;
+7. **RD↔QA repair loop** — if QA verdict is `return-to-rd`, loop back to step 4 (RD implementation) and re-run through QA; max 3 repair cycles, then emit blocked TXT regardless;
+8. **SC phase** — change-control evidence: impact, retention, validate, boundary;
+9. **OpenSpec archive** — exit gate: validate → archive only after QA verdict=pass (when `openspec/` exists);
+10. **TXT handoff capsule** — mode, validated decisions, artifact paths, standards deltas, open questions, next action;
+11. **Final snapshot** — `peaks project dashboard` + `peaks skill doctor` to confirm the workflow closed cleanly.
 
 ### Transition verification gates (MANDATORY — run the command, see the output)
 
@@ -301,7 +293,7 @@ ls .peaks/<id>/prd/requests/<rid>.md \
    .peaks/<id>/rd/tech-doc.md \
    .peaks/<id>/qa/test-cases/<rid>.md
 # Every line must be a file path.
-# Frontend: ui/design-draft.md missing → BLOCKED
+# Frontend: ui/design-draft.md missing → apply swarm degradation rule 1 (do not block RD, note "ui-design-missing" in TXT)
 # Pure backend: ui/design-draft.md absent → state skip reason, proceed
 ```
 
@@ -345,62 +337,19 @@ find . -maxdepth 1 -name "*.png" -o -name "*.jpg" -o -name "qa-*.js" -o -name "m
 ```
 
 
-## Swarm parallel phase (PRD确认后并行蜂群)
+## Swarm parallel phase
 
-PRD 确认后，UI 设计稿、RD 技术文档、QA 测试用例三者都是从 PRD 派生出来的独立产物，互不依赖。Peaks Solo 必须并行启动这三个角色，而不是串行执行。
+After PRD reaches `confirmed-by-user`, Solo launches peaks-ui, peaks-rd(planning), and peaks-qa(test-cases) simultaneously using parallel Agent calls. All three derive independently from the same PRD and write to separate artifact paths. Solo waits for all three, checks convergence (Gate B), then enters RD implementation.
 
-### 并行依赖分析
-
-```
-PRD (confirmed-by-user)
- │
- ├── peaks-ui  → design-draft.md   独立：只需要 PRD 知道要设计哪些页面/组件
- ├── peaks-rd  → tech-doc.md       独立：只需要 PRD 知道架构范围和数据流
- └── peaks-qa  → test-cases/*.md   独立：只需要 PRD 的验收标准来写测试用例
-                    │
-                    ↓ 三个都完成后汇合
-              peaks-rd (implementation)
-                    读取 design-draft.md + tech-doc.md + test-cases/*.md
-                    开始编码实现
-```
+### Degradation when swarm roles fail
 
-### 为什么可以并行
+1. **UI missing**: RD continues with PRD visual descriptions; note "ui-design-missing" in TXT.
+2. **RD planning missing**: RD continues; note "tech-doc-missing" in TXT.
+3. **QA test-cases missing**: RD continues; QA must backfill test cases before issuing verdict.
+4. **Two or more missing**: Fall back to sequential mode (PRD → RD → QA); note "swarm-degraded-to-sequential".
+5. **All three missing**: Pause workflow; report to user; request confirmation to continue.
 
-- **UI 不依赖 RD 技术文档**：设计稿描述"长什么样"，技术文档描述"怎么建"，两者从同一个 PRD 出发独立产出
-- **RD 技术文档不依赖 UI 设计稿**：架构决策（组件树、数据流、API 契约）可以从 PRD 的功能描述直接推导，不需要等到视觉设计完成。RD 实现阶段才需要读设计稿
-- **QA 测试用例不依赖实现代码**：TDD 原则——测试用例应该在代码之前写好。QA 根据 PRD 验收标准写用例，不依赖 RD 的输出
-
-### 并行执行规则
-
-1. PRD 状态到达 `confirmed-by-user` 后，Solo 同时启动 peaks-ui、peaks-rd(planning)、peaks-qa(test-cases)
-2. 如果在 full-auto 模式下，使用并行 Agent 调用来执行（一次发送多个 Agent tool call）
-3. 三个角色各自写入独立产物，互不冲突
-4. Solo 等待三个角色全部完成后，再进入 RD 实现阶段
-5. RD 实现阶段读取所有三个产物，综合实施
-
-### 产物汇合检查
-
-在进入 RD 实现阶段前，Solo 确认以下产物存在且非 draft：
-
-```
-.peaks/<session-id>/ui/design-draft.md          ← peaks-ui 产出
-.peaks/<session-id>/rd/tech-doc.md              ← peaks-rd 规划产出
-.peaks/<session-id>/qa/test-cases/<id>.md       ← peaks-qa 测试用例产出
-```
-
-缺任何一个都不能进入实现阶段。
-
-### 并行失败降级处理
-
-当 swarm 并行阶段任一角色失败或超时时，Solo 不得无限等待或静默跳过：
-
-1. **UI 失败（design-draft 缺失）**: RD 实现阶段使用 PRD 的视觉描述作为参考继续编码，UI 失败不阻塞 RD 进入实现，但阻塞最终 QA 的视觉回归检查。Solo 必须在 TXT 手记中标注 "ui-design-missing" 风险
-2. **RD(planning) 失败（tech-doc 缺失）**: 不阻塞 RD 实现阶段，RD 可以在实现过程中内联补充技术决策。tech-doc 缺失必须在 TXT 手记中标注
-3. **QA(test-cases) 失败（test-cases 缺失）**: 不阻塞 RD 实现，但 QA 必须在 RD 完成实现后补充测试用例才能进入验证阶段。阻塞 QA verdict 直到测试用例补齐
-4. **两个或以上角色失败**: 回退到串行降级模式——按 PRD→RD(含内联设计+规划)→QA(含测试用例+验证) 的顺序逐步执行，跳过 UI 阶段。TXT 手记标注 "swarm-degraded-to-sequential"
-5. **全部三个角色失败**: 暂停工作流，向用户报告失败原因（大概率是 PRD 信息不足或 CLI 环境问题），请求用户确认是否继续
-
-Solo 在发起并行调用后，等待所有角色返回结果。如果某个 Agent 返回错误或超时，按上述规则降级处理，不阻塞整个工作流。
+**UI phase mandatory for frontend**: When the request affects user-visible behavior (pages, components, forms, modals, tables, styling, interaction, or layout), Peaks Solo MUST invoke `peaks-ui` in the swarm parallel phase alongside RD planning and QA test-case generation. UI produces design drafts that RD implementation later consumes. Skipping UI for frontend work is a blocking violation. The only valid reason to skip UI is when the request is purely backend (API, database, CLI, config, or build tooling).
 
 ## Mandatory RD QA repair loop (AUTO-PROCEED)
 
@@ -408,8 +357,6 @@ After `peaks-rd` finishes any implementation, repair, or code-output slice, Peak
 
 **Full-auto auto-proceed rule**: In Solo (full-auto) profile, when RD transitions to `qa-handoff`, Solo immediately invokes `peaks-qa` with the same `<request-id>`. 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 the request has zero code changes (documentation-only, standards-only).
 
-**UI phase mandatory for frontend**: When the request affects user-visible behavior (pages, components, forms, modals, tables, styling, interaction, or layout), Peaks Solo MUST invoke `peaks-ui` in the swarm parallel phase alongside RD planning and QA test-case generation. UI produces design drafts that RD implementation later consumes. Skipping UI for frontend work is a blocking violation. The only valid reason to skip UI is when the request is purely backend (API, database, CLI, config, or build tooling).
-
 A QA report with any failing, blocked, missing, or unverified acceptance item is not a pass.
 
 When QA reports problems:
@@ -420,114 +367,75 @@ When QA reports problems:
 4. run `peaks-qa` again on the repaired output;
 5. repeat until QA reports all acceptance items passed, or emit a blocked TXT handoff.
 
-For full-auto or long-running workflows, prefer using Claude Code's `goal` command to encode this loop goal: "RD fixes until QA passes all acceptance items." Do not treat `goal` as a replacement for Peaks role artifacts; it is only the controller objective for the RD↔QA loop.
+**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.
+
+In full-auto mode, treat the RD↔QA repair loop as a built-in controller objective: loop through RD→QA until all acceptance items pass (max 3 cycles). Do not exit the loop on a non-passing QA verdict unless the TXT handoff marks the workflow as blocked.
 
 ## Default runbook
 
-The default end-to-end sequence Peaks Solo orchestrates when a user supplies a request (feature / bug / refactor / product-doc link) and selects the Solo (full-auto) profile. Each role's own Default runbook owns the per-role detail; Solo's job is to drive the cross-role state transitions in order and confirm the artifact chain is complete before declaring the workflow done.
+> **Maintenance**: The numbered workflow list above (steps 0-11) is the canonical phase sequence. This runbook is the executable CLI transcription. When updating this skill, keep both in lockstep — a change to one must be reflected in the other.
+
+The end-to-end CLI sequence for the Solo (full-auto) profile. Assisted/Strict profiles pause at `[CONFIRM]` markers below. Full-auto and Swarm auto-proceed through all gates. See Transition Gates for artifact verification at each stage.
 
 ```bash
-# 0. snapshot the project before anything else
+# 0. Snapshot + 0.5 Workspace + 0.6 Project scan
 peaks doctor --json
-peaks project dashboard --project <repo> --json     # one-call cross-role status
-peaks skill runbook peaks-solo --json               # confirm Solo's own runbook is intact + apply-gated
-peaks skill presence:set peaks-solo --mode solo     # show persistent skill presence every turn
-
-# 0.5 workspace initialization — MANDATORY before any artifact write
+peaks project dashboard --project <repo> --json
+peaks skill runbook peaks-solo --json
 peaks workspace init --project <repo> --session-id <YYYY-MM-DD-<slug>> --json
-
-# 0.6 project scan — MANDATORY before RD handoff
-# detect: build tool, component library, CSS framework, state management, routing, data fetching
-# write result to .peaks/<session-id>/rd/project-scan.md
-
-# 1. PRD phase — capture the request as the canonical artifact
-peaks request init --role prd --id <request-id> --project <repo> --apply --json
-# (Solo executes peaks-prd Default runbook here, including authenticated
-#  document handling via Playwright MCP per peaks-solo/references/browser-workflow.md)
-# write artifact to .peaks/<session-id>/prd/requests/<request-id>.md
-peaks request transition <request-id> --role prd --state confirmed-by-user --project <repo> --json
-peaks request transition <request-id> --role prd --state handed-off --project <repo> --json
-
-# 2. Swarm parallel phase — launch UI, RD(planning), QA(test-cases) simultaneously
-# After PRD confirmed, all three can work independently from the same PRD.
-# Use parallel Agent calls in full-auto mode.
-
-# 2a. peaks-ui (MANDATORY for frontend, skip only for pure backend)
-peaks request init --role ui --id <request-id> --project <repo> --apply --json
-peaks request transition <request-id> --role ui --state direction-locked --project <repo> --json
-peaks request transition <request-id> --role ui --state handed-off --project <repo> --json
-# output: .peaks/<session-id>/ui/design-draft.md
-
-# 2b. peaks-rd tech-doc (architecture planning — NOT implementation yet)
-peaks request init --role rd --id <request-id> --project <repo> --apply --json
-peaks request transition <request-id> --role rd --state spec-locked --project <repo> --json
-# output: .peaks/<session-id>/rd/tech-doc.md
-# scope: architecture decisions, component tree, data flow, API contracts, dependencies
-
-# 2c. peaks-qa test-case generation (before implementation — TDD)
-peaks request init --role qa --id <request-id> --project <repo> --apply --json
-# output: .peaks/<session-id>/qa/test-cases/<request-id>.md
-# scope: unit test cases, integration test cases, UI regression test cases
-
-# === Swarm convergence check ===
-# All three artifacts must be present and non-draft before RD implementation starts:
-#   .peaks/<session-id>/ui/design-draft.md
-#   .peaks/<session-id>/rd/tech-doc.md
-#   .peaks/<session-id>/qa/test-cases/<request-id>.md
-
-# 3. RD implementation phase — consumes all three swarm outputs
-# (Solo executes peaks-rd Default runbook here: standards preflight + project-scan consumption +
-#  openspec entry gate + implementation + openspec exit gate)
-# reads: design-draft.md + tech-doc.md + test-cases/<id>.md
-peaks request transition <request-id> --role rd --state implemented  --project <repo> --json
-peaks request transition <request-id> --role rd --state qa-handoff   --project <repo> --json
-
-# 4. QA validation phase — AUTO-PROCEED from RD implementation
-# (Solo executes peaks-qa Default runbook here: execute test cases + test report +
-#  Playwright MCP frontend validation when frontend is in scope + security/perf checks)
-# writes to .peaks/<session-id>/qa/test-reports/<request-id>.md
-peaks request transition <request-id> --role qa --state running         --project <repo> --json
-peaks request transition <request-id> --role qa --state verdict-issued  --project <repo> --json
-
-# 5. SC phase — record change-control evidence after QA passes
-# (Solo executes peaks-sc Default runbook here for the full sequence)
-peaks sc impact     --change-id <change-id> --module <module> --file <path>      --json
-peaks sc retention  --slice-id  <request-id> --prd <prd> --rd <rd> --qa <qa>     --json
-peaks sc validate   --slice-id  <request-id>                                     --json
-peaks sc boundary   --slice-id  <request-id> --artifact <artifact> --code <file> --json
-
-# 6. close the loop — final verification and optional OpenSpec archive
-peaks request list --project <repo> --json                          # every artifact reached its terminal state?
-peaks request show <request-id> --role qa --project <repo> --json   # QA verdict is pass?
-peaks openspec validate <change-id> --project <repo> --json         # exit gate (when openspec/ exists)
-peaks openspec archive  <change-id> --project <repo> --apply --json # only after QA verdict=pass
-
-# 7. TXT phase — compact handoff capsule
-# (Solo executes peaks-txt Default runbook here; durable extraction requires authorization)
+# → write .peaks/<session-id>/rd/project-scan.md (Gate A)
+
+# 1. Standards preflight
+peaks standards init --project <repo> --dry-run --json
+# or: peaks standards update --project <repo> --dry-run --json
+
+# 2. PRD (Assisted/Strict: [CONFIRM] before confirmed-by-user)
+peaks request init --role prd --id <rid> --project <repo> --apply --json
+peaks request transition <rid> --role prd --state confirmed-by-user --project <repo> --json
+peaks request transition <rid> --role prd --state handed-off --project <repo> --json
+
+# 3. Swarm parallel — launch UI + RD(planning) + QA(test-cases) simultaneously
+peaks request init --role ui --id <rid> --project <repo> --apply --json
+peaks request transition <rid> --role ui --state direction-locked --project <repo> --json
+peaks request transition <rid> --role ui --state handed-off --project <repo> --json
+peaks request init --role rd --id <rid> --project <repo> --apply --json
+peaks request transition <rid> --role rd --state spec-locked --project <repo> --json
+peaks request init --role qa --id <rid> --project <repo> --apply --json
+# → Gate B convergence check. Assisted/Strict: [CONFIRM]
+
+# 4. RD implementation (consumes design-draft + tech-doc + test-cases + project-scan)
+peaks request transition <rid> --role rd --state implemented --project <repo> --json
+peaks request transition <rid> --role rd --state qa-handoff --project <repo> --json
+
+# 5. Code review + security review (fix CRITICAL/HIGH before proceeding)
+
+# 6. QA validation (AUTO-PROCEED from RD in full-auto)
+peaks request transition <rid> --role qa --state running --project <repo> --json
+peaks request transition <rid> --role qa --state verdict-issued --project <repo> --json
+# → Gate D check. Assisted/Strict: [CONFIRM]
+
+# 7. RD↔QA repair loop — if verdict is return-to-rd, re-run 4 through 6 until QA passes or blocked TXT
+
+# 8. SC phase
+peaks sc impact --change-id <cid> --module <module> --file <path> --json
+peaks sc retention --slice-id <rid> --prd <prd> --rd <rd> --qa <qa> --json
+peaks sc validate --slice-id <rid> --json
+peaks sc boundary --slice-id <rid> --artifact <artifact> --code <file> --json
+
+# 9. OpenSpec archive (exit gate; only after QA pass, when openspec/ exists)
+peaks openspec validate <cid> --project <repo> --json
+peaks openspec archive <cid> --project <repo> --apply --json
+
+# 10. TXT handoff
 peaks memory extract --project <repo> --artifact <qa-artifact> --dry-run --json
 
-# 8. final snapshot to confirm the workflow really closed
+# 11. Final snapshot
 peaks project dashboard --project <repo> --json
-peaks skill doctor --json                            # all 7 required skills still healthy?
-peaks skill presence:clear                          # workflow complete, remove presence indicator
+peaks skill doctor --json
+peaks skill presence:clear
 ```
 
-Solo's RD↔QA repair loop (`## Mandatory RD QA repair loop` above) applies if QA's verdict is `return-to-rd`. In that case, Solo re-runs phase 3 + phase 4 against the same `<request-id>` instead of starting a new one; the previous artifacts get appended with new transition notes via `--reason` rather than rewritten.
-
-For Assisted, Swarm, or Strict profiles, Solo pauses at the transition boundaries to confirm the next phase rather than running the chain straight through. The CLI sequence is the same; only the confirmation gate cadence differs.
-
-## Mode selection
-
-When the user invokes Peaks Solo without explicitly selecting an execution profile, use `AskUserQuestion` before orchestration starts. Present the recommended full-auto path as the first/default option, and give every option a practical description so users can choose quickly.
-
-Offer these profiles unless the active command narrows the valid set:
-
-1. **Full auto (Recommended, Solo profile)** — Peaks handles planning, role coordination, validation, and compact handoff end-to-end while preserving required confirmation gates for risky or shared-state actions.
-2. **Assisted** — Peaks proposes plans, artifacts, and checks, then pauses for user decisions at major workflow boundaries.
-3. **Swarm** — Peaks maximizes safe parallel role/worker execution for larger RD or QA workloads while keeping reducer validation and artifact boundaries explicit.
-4. **Strict** — Peaks uses the most conservative gates: explicit confirmations, strict slice specs, coverage evidence, QA acceptance, and commit boundaries before continuing.
-
-If the user already names a profile, do not ask again unless the request crosses a risk boundary or the named profile conflicts with required Peaks gates.
+Repair loop details: see `## Mandatory RD QA repair loop` above for the full 5-step procedure and the 3-cycle cap. Append transition notes via `--reason` rather than rewriting artifacts during repair cycles.
 
 ## Project standards preflight
 
@@ -579,7 +487,7 @@ Use Peaks TXT for the compact handoff capsule: mode, validated decisions, artifa
 
 **External skills**: All external skill references (`mattpocock/skills`, `awesome-design-md`, `taste-skill`, `shadcn/ui`, `Chrome DevTools MCP`, `Figma Context MCP`, `Context7`, etc.) follow the three-stage pattern: capability discovery before naming, reference-only (no execute/install/persist), Peaks CLI for all side effects. External skills inform, they do not approve.
 
-**OpenSpec lifecycle**: `render → validate → show → to-rd → validate → archive`. Validation at RD entry (before slicing) and QA exit (before archive); both must be `data.valid === true`.
+**OpenSpec lifecycle**: `render → validate → show → to-rd → validate → archive`. Solo's default runbook handles the exit gate (validate → archive after QA pass). Entry-gate validation (to-rd before slicing) is available when `openspec/` exists pre-workflow; Solo delegates it to `peaks-rd` during implementation.
 
 **MCP lifecycle**: `list → plan → apply --yes → call → rollback`. `apply` backs up settings and refuses non-peaks entries unless `--claim` is passed.
 

package/skills/peaks-solo/results.tsv

@@ -1 +0,0 @@
-timestamp	commit	skill	old_score	new_score	status	dimension	note	eval_mode