peaks-loop 4.0.0-beta.5 → 4.0.0-beta.7

package/dist/src/services/workflow/workflow-router-service.js

@@ -1,4 +1,4 @@
-import { getConfiguredExecutionModelId, STRONGEST_MODEL_ID } from '../config/model-routing.js';
+import { getConfiguredExecutionModelId, getStrongestModelId } from '../config/model-routing.js';
 import { getLocalArtifactPath } from '../artifacts/workspace-service.js';
 import { createRdSwarmPlan } from '../rd/rd-service.js';
 import { createTechPlan, getTechStatus } from '../tech/tech-service.js';
@@ -37,12 +37,12 @@ function assertCodeModeAllowed(mode, codeMode) {
         throw new Error('codeMode requires code workflow mode');
     }
 }
-function step(input, executionModelId) {
+function step(input, executionModelId, strongestModelId) {
     const modelRole = EXECUTION_STAGES.includes(input.stage) ? 'execution' : 'strongest';
     return {
         ...input,
         modelRole,
-        modelId: modelRole === 'execution' ? executionModelId : STRONGEST_MODEL_ID,
+        modelId: modelRole === 'execution' ? executionModelId : strongestModelId,
         dryRunOnly: true,
         invokesAgents: false,
         writesArtifacts: false
@@ -78,40 +78,40 @@ function annotateSteps(steps, codeMode) {
         };
     });
 }
-function createSoloSteps(executionModelId) {
+function createSoloSteps(executionModelId, strongestModelId) {
     return [
-        step({ id: 'code-product-direction', stage: 'product-direction', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Product direction needs strong judgment before execution work is delegated.', dependsOn: [] }, executionModelId),
-        step({ id: 'code-design-direction', stage: 'design-direction', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Design direction uses the recommended default before cheaper implementation work.', dependsOn: ['code-product-direction'] }, executionModelId),
-        step({ id: 'code-tech-direction', stage: 'tech-direction', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Technical boundaries and approval gates use the recommended default with high-confidence planning.', dependsOn: ['code-design-direction'] }, executionModelId),
-        step({ id: 'code-tech-review', stage: 'tech-review', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Tech artifacts and gate decisions require strong review and a recommended default path.', dependsOn: ['code-tech-direction'] }, executionModelId),
-        step({ id: 'code-rd-planning', stage: 'rd-planning', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'RD task decomposition and acceptance criteria use the recommended default before execution delegation.', dependsOn: ['code-tech-review'] }, executionModelId),
-        step({ id: 'code-coding-execution', stage: 'coding-execution', owner: 'peaks-rd', modelTier: executionModelId === STRONGEST_MODEL_ID ? 'top-tier' : 'mid-tier', reason: `Coding and routine refactoring must use the configured execution worker model ${executionModelId}.`, dependsOn: ['code-rd-planning'] }, executionModelId),
-        step({ id: 'code-unit-test-execution', stage: 'unit-test-execution', owner: 'peaks-rd', modelTier: executionModelId === STRONGEST_MODEL_ID ? 'top-tier' : 'mid-tier', reason: `Unit test authoring and focused test runs must use the configured execution worker model ${executionModelId}.`, dependsOn: ['code-coding-execution'] }, executionModelId),
-        step({ id: 'code-quality-review', stage: 'quality-review', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Reducer and final quality gates need strong synthesis and risk review.', dependsOn: ['code-unit-test-execution'] }, executionModelId)
+        step({ id: 'code-product-direction', stage: 'product-direction', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Product direction needs strong judgment before execution work is delegated.', dependsOn: [] }, executionModelId, strongestModelId),
+        step({ id: 'code-design-direction', stage: 'design-direction', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Design direction uses the recommended default before cheaper implementation work.', dependsOn: ['code-product-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'code-tech-direction', stage: 'tech-direction', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Technical boundaries and approval gates use the recommended default with high-confidence planning.', dependsOn: ['code-design-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'code-tech-review', stage: 'tech-review', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Tech artifacts and gate decisions require strong review and a recommended default path.', dependsOn: ['code-tech-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'code-rd-planning', stage: 'rd-planning', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'RD task decomposition and acceptance criteria use the recommended default before execution delegation.', dependsOn: ['code-tech-review'] }, executionModelId, strongestModelId),
+        step({ id: 'code-coding-execution', stage: 'coding-execution', owner: 'peaks-rd', modelTier: executionModelId === strongestModelId ? 'top-tier' : 'mid-tier', reason: `Coding and routine refactoring must use the configured execution worker model ${executionModelId}.`, dependsOn: ['code-rd-planning'] }, executionModelId, strongestModelId),
+        step({ id: 'code-unit-test-execution', stage: 'unit-test-execution', owner: 'peaks-rd', modelTier: executionModelId === strongestModelId ? 'top-tier' : 'mid-tier', reason: `Unit test authoring and focused test runs must use the configured execution worker model ${executionModelId}.`, dependsOn: ['code-coding-execution'] }, executionModelId, strongestModelId),
+        step({ id: 'code-quality-review', stage: 'quality-review', owner: 'peaks-code', modelTier: 'top-tier', reason: 'Reducer and final quality gates need strong synthesis and risk review.', dependsOn: ['code-unit-test-execution'] }, executionModelId, strongestModelId)
     ];
 }
-function createSoloStepsForMode(codeMode, executionModelId) {
-    return annotateSteps(createSoloSteps(executionModelId), codeMode);
+function createSoloStepsForMode(codeMode, executionModelId, strongestModelId) {
+    return annotateSteps(createSoloSteps(executionModelId, strongestModelId), codeMode);
 }
-function createTeamSteps(executionModelId) {
+function createTeamSteps(executionModelId, strongestModelId) {
     return [
-        step({ id: 'team-product-direction', stage: 'product-direction', owner: 'human', modelTier: 'top-tier', reason: 'Team product direction should stay on the governed planning path.', dependsOn: [] }, executionModelId),
-        step({ id: 'team-design-direction', stage: 'design-direction', owner: 'human', modelTier: 'top-tier', reason: 'Team design direction should preserve reviewability and accountability.', dependsOn: ['team-product-direction'] }, executionModelId),
-        step({ id: 'team-tech-direction', stage: 'tech-direction', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Team technical plans should remain strongly governed before RD execution.', dependsOn: ['team-design-direction'] }, executionModelId),
-        step({ id: 'team-tech-review', stage: 'tech-review', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Team tech approval requires strong review before execution.', dependsOn: ['team-tech-direction'] }, executionModelId),
-        step({ id: 'team-rd-planning', stage: 'rd-planning', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'Team RD task decomposition remains on the governed strongest-model path.', dependsOn: ['team-tech-review'] }, executionModelId),
-        step({ id: 'team-coding-execution', stage: 'coding-execution', owner: 'peaks-rd', modelTier: executionModelId === STRONGEST_MODEL_ID ? 'top-tier' : 'mid-tier', reason: `Bounded coding tasks must use the configured execution worker model ${executionModelId}.`, dependsOn: ['team-rd-planning'] }, executionModelId),
-        step({ id: 'team-unit-test-execution', stage: 'unit-test-execution', owner: 'peaks-rd', modelTier: executionModelId === STRONGEST_MODEL_ID ? 'top-tier' : 'mid-tier', reason: `Unit-test tasks must use the configured execution worker model ${executionModelId}.`, dependsOn: ['team-coding-execution'] }, executionModelId),
-        step({ id: 'team-quality-review', stage: 'quality-review', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'Team RD outputs still need reducer and quality review gates.', dependsOn: ['team-unit-test-execution'] }, executionModelId)
+        step({ id: 'team-product-direction', stage: 'product-direction', owner: 'human', modelTier: 'top-tier', reason: 'Team product direction should stay on the governed planning path.', dependsOn: [] }, executionModelId, strongestModelId),
+        step({ id: 'team-design-direction', stage: 'design-direction', owner: 'human', modelTier: 'top-tier', reason: 'Team design direction should preserve reviewability and accountability.', dependsOn: ['team-product-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'team-tech-direction', stage: 'tech-direction', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Team technical plans should remain strongly governed before RD execution.', dependsOn: ['team-design-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'team-tech-review', stage: 'tech-review', owner: 'peaks-tech', modelTier: 'top-tier', reason: 'Team tech approval requires strong review before execution.', dependsOn: ['team-tech-direction'] }, executionModelId, strongestModelId),
+        step({ id: 'team-rd-planning', stage: 'rd-planning', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'Team RD task decomposition remains on the governed strongest-model path.', dependsOn: ['team-tech-review'] }, executionModelId, strongestModelId),
+        step({ id: 'team-coding-execution', stage: 'coding-execution', owner: 'peaks-rd', modelTier: executionModelId === strongestModelId ? 'top-tier' : 'mid-tier', reason: `Bounded coding tasks must use the configured execution worker model ${executionModelId}.`, dependsOn: ['team-rd-planning'] }, executionModelId, strongestModelId),
+        step({ id: 'team-unit-test-execution', stage: 'unit-test-execution', owner: 'peaks-rd', modelTier: executionModelId === strongestModelId ? 'top-tier' : 'mid-tier', reason: `Unit-test tasks must use the configured execution worker model ${executionModelId}.`, dependsOn: ['team-coding-execution'] }, executionModelId, strongestModelId),
+        step({ id: 'team-quality-review', stage: 'quality-review', owner: 'peaks-rd', modelTier: 'top-tier', reason: 'Team RD outputs still need reducer and quality review gates.', dependsOn: ['team-unit-test-execution'] }, executionModelId, strongestModelId)
     ];
 }
 function uniqueStrings(values) {
     return [...new Set(values)];
 }
-function createModelRouting(steps, executionModelId) {
+function createModelRouting(steps, executionModelId, strongestModelId) {
     return {
         strongestModel: {
-            modelId: STRONGEST_MODEL_ID,
+            modelId: strongestModelId,
             uses: steps.filter((step) => step.modelRole === 'strongest').map((step) => step.stage)
         },
         executionModel: {
@@ -135,10 +135,10 @@ function getTechPlanBlockedReasons(techPlan) {
 function getTechPlanNextActions(techPlan) {
     return [...techPlan.nextActions];
 }
-function createModeStatus(economyMode, swarmMode, executionModelId, executionModelSource) {
+function createModeStatus(economyMode, swarmMode, executionModelId, executionModelSource, strongestModelId) {
     const economySummary = economyMode
         ? `Economy mode enabled: code worker and test worker strictly use ${executionModelId} from config providers.`
-        : `Economy mode disabled: code worker and test worker use ${STRONGEST_MODEL_ID}, matching planner/reviewer.`;
+        : `Economy mode disabled: code worker and test worker use ${strongestModelId}, matching planner/reviewer.`;
     const swarmSummary = swarmMode
         ? 'Swarm mode enabled: peaks-rd coding, unit-test, and peaks-qa quality work must be represented as swarm worker tasks.'
         : 'Swarm mode disabled: swarm worker graph generation is bypassed.';
@@ -183,8 +183,14 @@ export function createWorkflowRouterPlan(request) {
     // object (`config: { providers: {} }`) still surfaces the "must be
     // configured" error from `getConfiguredExecutionModelId`.
     const effectiveProviders = request.config?.providers ?? { minimax: { model: 'minimax-2.7' } };
-    const executionModelId = economyMode !== false ? getConfiguredExecutionModelId(effectiveProviders) : STRONGEST_MODEL_ID;
-    const modeStatus = createModeStatus(economyMode, swarmMode, executionModelId, economyMode ? 'config.providers' : 'planner-reviewer-strongest-model');
+    // Slice 2026-07-09 add-zcode-adapter (A.3): the strongest
+    // planner/reviewer model is now resolved via `getStrongestModelId`,
+    // which reads `config.model` (if present) or falls back to the
+    // env-var-overridable default. This decouples the strongest-model
+    // pick from any specific vendor constant.
+    const strongestModelId = getStrongestModelId(request.config);
+    const executionModelId = economyMode !== false ? getConfiguredExecutionModelId(effectiveProviders) : strongestModelId;
+    const modeStatus = createModeStatus(economyMode, swarmMode, executionModelId, economyMode ? 'config.providers' : 'planner-reviewer-strongest-model', strongestModelId);
     const codeMode = getCodeMode(request.mode, request.codeMode);
     const decisionProfile = getDecisionProfileSummary(request.mode, codeMode);
     const artifactWorkspacePath = request.artifactWorkspacePath ?? (request.workspace ? getLocalArtifactPath(request.workspace) : undefined);
@@ -195,7 +201,7 @@ export function createWorkflowRouterPlan(request) {
     const techStatus = getTechStatus({ sessionId: request.sessionId, ...sharedWorkspaceOptions });
     const techPlan = createTechPlan({ sessionId: request.sessionId, goal, swarm: swarmMode, dryRun: true, ...sharedWorkspaceOptions });
     const rdPlan = createRdSwarmPlan({ skill: 'rd', sessionId: request.sessionId, goal, maxWorkers, swarmMode, executionModelId, dryRun: true, ...sharedWorkspaceOptions });
-    const steps = codeMode ? createSoloStepsForMode(codeMode, executionModelId) : createTeamSteps(executionModelId);
+    const steps = codeMode ? createSoloStepsForMode(codeMode, executionModelId, strongestModelId) : createTeamSteps(executionModelId, strongestModelId);
     const blockedReasons = uniqueStrings([
         ...techStatus.blockedReasons,
         ...getTechPlanBlockedReasons(techPlan),
@@ -213,7 +219,7 @@ export function createWorkflowRouterPlan(request) {
         decisionProfile,
         dryRun: true,
         routePolicy: request.mode === 'code' ? 'code-broad-multi-model' : 'team-rd-limited-multi-model',
-        modelRouting: createModelRouting(steps, executionModelId),
+        modelRouting: createModelRouting(steps, executionModelId, strongestModelId),
         modelAssignments: createModelAssignments(steps),
         modeStatus,
         techStatus,

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

@@ -1 +1 @@
-export declare const CLI_VERSION = "4.0.0-beta.5";
+export declare const CLI_VERSION = "4.0.0-beta.7";

package/dist/src/shared/version.js

@@ -1 +1 @@
-export const CLI_VERSION = "4.0.0-beta.5";
+export const CLI_VERSION = "4.0.0-beta.7";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peaks-loop",
-  "version": "4.0.0-beta.5",
+  "version": "4.0.0-beta.7",
   "description": "Loop Engineering CLI — workflow primitive / loop guards / evaluators / slice orchestration",
   "author": "SquabbyZ",
   "license": "MIT",

package/scripts/install-skills.mjs

@@ -172,21 +172,15 @@ function readPackageVersion(packageRoot = resolvePackageRoot()) {
 }
 
 function createConfigDefaults(packageRoot) {
-  return {
+return {
     version: readPackageVersion(packageRoot),
     currentWorkspace: null,
   workspaces: [],
   language: 'en',
-  model: 'sonnet',
   economyMode: true,
   swarmMode: true,
   tokens: {},
-  providers: {
-    minimax: {
-      model: 'minimax-2.7'
-    }
-  },
-    proxy: {}
+  proxy: {}
   };
 }
 
@@ -381,7 +375,7 @@ function resolveProjectRoot(options) {
  * overrides `PEAKS_CLAUDE_SKILLS_DIR` / `PEAKS_CLAUDE_OUTPUT_STYLES_DIR`
  * continue to work, and the legacy default is preserved.
  */
-const IDE_DETECTION_DIRS = [
+export const IDE_DETECTION_DIRS = [
   { id: 'claude-code', dir: '.claude' },
   { id: 'trae', dir: '.trae' },
   { id: 'trae-cn', dir: '.trae-cn' },
@@ -389,6 +383,7 @@ const IDE_DETECTION_DIRS = [
   { id: 'cursor', dir: '.cursor' },
   { id: 'qoder', dir: '.qoder' },
   { id: 'tongyi-lingma', dir: '.tongyi-lingma' },
+  { id: 'zcode', dir: '.zcode' },
 ];
 
 /**
@@ -404,7 +399,7 @@ const IDE_DETECTION_DIRS = [
  * directory was never populated. 2.0 fixes this by giving
  * all 8 platforms canonical install paths.
  */
-const IDE_SKILL_INSTALL_PROFILES = {
+export const IDE_SKILL_INSTALL_PROFILES = {
   'claude-code': {
     skillsDir: join(homedir(), '.claude', 'skills'),
     outputStylesDir: join(homedir(), '.claude', 'output-styles'),
@@ -469,6 +464,14 @@ const IDE_SKILL_INSTALL_PROFILES = {
     envVar: 'PEAKS_OPENCLAW_SKILLS_DIR',
     outputStylesEnvVar: 'PEAKS_OPENCLAW_OUTPUT_STYLES_DIR',
   },
+  'zcode': {
+    skillsDir: join(homedir(), '.zcode', 'skills'),
+    outputStylesDir: join(homedir(), '.zcode', 'output-styles'),
+    agentsDir: join(homedir(), '.zcode', 'agents'),
+    envVar: 'PEAKS_ZCODE_SKILLS_DIR',
+    outputStylesEnvVar: 'PEAKS_ZCODE_OUTPUT_STYLES_DIR',
+    agentsEnvVar: 'PEAKS_ZCODE_AGENTS_DIR',
+  },
 };
 
 function detectInstalledIdeId(projectRoot) {

package/skills/peaks-code/SKILL.md

@@ -18,7 +18,7 @@ The boundary is closed under this slice:
 
 ## Single-scope-axis naming convention (2.7.1)
 
-The `.peaks/` workspace has a **single scope axis** (session-id) plus a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` (NEVER bare `<sid>`). Reviewable artifacts live at `.peaks/_runtime/<sessionId>/<role>/...` (gitignored); the change-id is an optional filename slug and does NOT route filesystem writes. CLI: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. OpenSpec's `openspec/changes/<change-id>/` vocabulary (L4) is preserved. Test `skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) axis labels, (c) this callout.
+The `.peaks/` workspace has a **single scope axis** (session-id) plus a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` (NEVER bare `<sid>`). Reviewable artifacts live at `.peaks/_runtime/<sessionId>/<role>/...` (gitignored); the change-id is an optional filename slug and does NOT route filesystem writes. CLI: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. Test `skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) axis labels, (c) this callout.
 
 ## Karpathy guidance (Slice 1/6 — karpathy prompt-injection-lift)
 
@@ -58,12 +58,6 @@ When a NEW conversation opens on a session whose `lastActivity` is from today AN
 
 Proactive context-overflow defense. CLI: `peaks session checkpoint [--reason <r>] [...flags]`. Fire `--reason periodic` every 20 tool calls (G1 hard-coded), `--reason artifact-written` per PRD/RD/QA/TXT write. See `references/periodic-checkpoint.md` (otherwise `tests/unit/code/checkpoint-periodic-frequency.test.ts` fails).
 
-### Peaks-Loop Step 0.5: OpenSpec first-run opt-in (conditional)
-
-Run when `openspec/` is absent and `.peaks/.peaks-openspec-opt-in.json` is missing. Asks once and persists the decision.
-
-→ see `references/openspec-workflow.md` for the full opt-in flow + lifecycle.
-
 ### Peaks-Loop Step 0.6: Audit + Goal (NEW)
 
 Invoke peaks-audit after need expressed; store approved goal at `.peaks/_runtime/<sessionId>/audit-goal/<rid>.json`. **All autonomous work requires approved goal.** → `references/audit-goal-gate.md`.
@@ -104,9 +98,13 @@ After Step 0.7 returns "fresh", run `peaks upgrade --detect-1x --project <root>
 
 ### Peaks-Loop Step 0.8 — Job 启动 (BLOCKING on LLM judgement — v3.1.1 patch + v3.1.2 mechanical gates)
 
-The CLI is a **recorder + gate** for job-shape (the LLM judges). LLM calls `peaks code detect-job --is-job <bool> --rationale <text> --suggested-job-id <jid> --suggested-strategy <single|rotating> --confidence <high|medium|low>`, which writes `.peaks/_runtime/<sessionId>/job-shape.json`. Downstream steps call `read-job-shape` and refuse if missing.
+> **CLI reality check (D-001 sediment, 2026-07-09):** The CLI surface has changed since this section was last verified. The actual command is **`peaks job init --job-id <jid> --slice-list <list> --main-loop-strategy <single|rotating> [--parallelism-hint <serial|llm-decides>] [--exit-policy <strict|best-effort>] [--project <repo>]`**. The legacy `peaks code detect-job --is-job/--suggested-job-id/--confidence` form described below is **no longer present** in 4.0.0-beta.6. If you find `--is-job` rejected, fall back to `peaks job init`.
 
-**Hard rule (v3.1.1 red-line #10):** LLM MUST NOT skip `peaks code detect-job`. If `read-job-shape` throws `JOB_SHAPE_NOT_DECIDED`, record a decision before proceeding.
+The CLI is a **recorder + gate** for job-shape (the LLM judges). LLM calls `peaks job init --job-id <jid> --slice-list <list> --main-loop-strategy <single|rotating>` (with `--caller-id <id>` and `--project <repo>` in non-Claude-Code environments), which writes `.peaks/_runtime/<sessionId>/job/<jid>/state.json` and emits a `[job-event] {kind: job-started, jobId, total, strategy}` line. Downstream steps call `peaks job status --job-id <jid>` to read state.
+
+**Hard rule (v3.1.1 red-line #10):** LLM MUST NOT skip the job-init call. If `peaks job status` reports `done: 0` and the slice work has begun, the LLM forgot to initialize — re-call `peaks job init` immediately.
+
+> **D-003 sediment (2026-07-09):** The historical `JOB_SHAPE_NOT_DECIDED` exception thrown by `read-job-shape` is no longer wired in 4.0.0-beta.6. The current CLI uses `peaks job status` which reports a passive `done: 0` instead of throwing. Both behaviors enforce the same intent (no work may begin before init) but the failure mode is a soft warning rather than a hard exception. LLM should treat `done: 0` after Step 0.8 as a recoverable miss, not an unrecoverable error.
 
 **v3.1.2 mechanical gates** (recorder-only was bypassed twice):
 
@@ -149,7 +147,9 @@ Run `peaks project memories --project <repo> --json` to read decisions / convent
 
 ### Peaks-Loop Step 2.5: Set session title
 
-Extract a short title from the user's first request (8-20 Chinese chars or 4-10 English words). Run `peaks session title` with the active sid. Skip if a title is already set. → `references/skill-presence-and-title.md` (same file as Step 2).
+Extract a short title from the user's first request (8-20 Chinese chars or 4-10 English words). Run `peaks session title <sid> "<title>" --json`. Skip if a title is already set. → `references/skill-presence-and-title.md` (same file as Step 2).
+
+> **CLI reality check (D-002 sediment, 2026-07-09):** The session id is a **positional argument**, not a `--session-id` flag. Correct invocation is `peaks session title 2026-07-08-session-17918f "add-zcode-adapter — peaks-loop 第 9 IDE 接入" --json`. Passing `--session-id` will be rejected with `error: unknown option '--session-id'`.
 
 ## Sub-agent session sharing (MANDATORY — one conversation = one sid)
 
@@ -159,6 +159,19 @@ When peaks-code dispatches a sub-agent (peaks-rd, peaks-qa, peaks-ui, peaks-txt,
 
 Peaks-Loop Code may: identify scenarios, recommend profiles, coordinate role skills through artifacts, coordinate project memory extraction, request user confirmation at risk/commit boundaries. Peaks-Loop Code must NOT silently install hooks / create agents / enable MCP / modify Claude settings / create GitHub repos / bypass role-skill artifacts. → `references/boundaries.md`.
 
+## CLI Drift Index (sediment 2026-07-09)
+
+> **Reading guide:** This document was last verified against CLI surface in **peaks-loop 4.0.0-beta.6**. The CLI has drifted in 4 places since this SKILL.md was last fully aligned. Each drift below is annotated **inline at the relevant step** with a `> CLI reality check` blockquote. When you hit a `error: unknown option ...` error, **read the inline reality check first** before guessing.
+
+| Drift ID | Step | Symptom | Fix | Inline location |
+|---|---|---|---|---|
+| **D-001** | 0.8 | `peaks code detect-job --is-job ...` rejected with `error: unknown option '--is-job'` | Use `peaks job init --job-id <jid> --slice-list <list> --main-loop-strategy <single\|rotating>` | §Step 0.8 first paragraph |
+| **D-002** | 2.5 | `peaks session title --session-id <sid> ...` rejected with `error: unknown option '--session-id'` | sid is positional: `peaks session title <sid> "<title>" --json` | §Step 2.5 |
+| **D-003** | 0.8 | `JOB_SHAPE_NOT_DECIDED` exception expected but never thrown | Current behavior is `peaks job status` reports `done: 0` passively — treat as recoverable miss, not hard error | §Step 0.8 third paragraph |
+| **D-010** | 11c | `peaks memory extract` returns `extractedCount: 0` despite `<!-- peaks-memory:start -->` existing | Block requires YAML frontmatter (`title:` + `kind:` + `---`) + closing `<!-- peaks-memory:end -->`. Bare `peaks-memory:start` is parsed silently but produces no writes | §Step 11c + 11d |
+
+> **Sediment lesson (master record):** `.peaks/memory/peaks-code-runbook-4-0-0-beta-6-skill-md-cli-d-001-d-002-d-003-d-010.md`
+
 ## Peaks-Loop GStack integration
 
 Map gstack stages to Peaks-Loop role artifacts; preserve confirmation gates. → `references/gstack-integration.md` + `references/browser-workflow.md`.
@@ -239,11 +252,13 @@ After final validation, refresh project-local standards via `peaks standards ini
 
 **11c — Canonical extract** (the only CLI that writes `.peaks/memory/`): `peaks memory extract --project <repo> --artifact .peaks/_runtime/<sessionId>/txt/handoff.md --apply --json`. `--apply` is REQUIRED (without it the command only previews — no files land).
 
+> **CLI reality check (D-010 sediment, 2026-07-09):** The `<!-- peaks-memory:start -->` block must be followed immediately by a **YAML frontmatter** (`title: ...`, `kind: lesson | decision | convention`) and a `---` separator. Each block must close with `<!-- peaks-memory:end -->`. A bare `peaks-memory:start` without the YAML fields is parsed but produces no `plannedWrites` — the CLI silently returns `extractedCount: 0`. Full format reference: see any successful extract output (e.g. `.peaks/_runtime/2026-07-08-session-17918f/txt/handoff-003-add-zcode-adapter.md`).
+
 **11d — Gate C (zero-write outcome):** If `extractedCount === 0` after 11c, fire AskUserQuestion:
 
 > "本次 code 未沉淀任何 `.peaks/memory` 文件。可选: (a) 回去在 handoff.md 嵌入至少 1 个 `peaks-memory:start` block 后重试; (b) 显式接受 no-sediment 并记录为 lesson; (c) 取消完成。"
 
-Default option = (a). Code MUST NOT silently accept (b) without user pick. Full bash + flow at `references/runbook.md` §Step 11.
+> **D-010 fix root cause check:** When firing 11d, first inspect whether the block has the YAML frontmatter (`title:` + `kind:` + `---`). If the `<!-- peaks-memory:start -->` exists but no `title:` line follows, fix the block format and re-run 11c — don't ask the user yet. Default option = (a). Code MUST NOT silently accept (b) without user pick. Full bash + flow at `references/runbook.md` §Step 11.
 
 **Why this step exists:** audit 2026-07-03 confirmed 2 consecutive sessions produced zero `.peaks/memory/` files despite completing RD + QA + handoff artifacts; `assisted` mode silently skipped runbook Step 10 (no STOP condition). **Why `peaks memory extract` (not `peaks project memories:extract`):** the artifact-scoped extract is canonical; the batch-scoped sibling is for non-handoff flows. Always use `peaks memory extract --apply`.
 
@@ -288,7 +303,6 @@ Index of every `references/` file. Read on demand.
 | `references/local-artifact-workspace.md` | Workspace tree + root-prohibition. |
 | `references/micro-cycle.md` | RD micro-cycle + repair loop. |
 | `references/mode-selection.md` | Step 1 mode + `--mode`. |
-| `references/openspec-workflow.md` | Step 0.5 OpenSpec. |
 | `references/playwright-mcp-multi-terminal.md` | Multi-terminal Playwright MCP. |
 | `references/project-memory-loading.md` | Step 2.3 memories. |
 | `references/project-scan-checklist.md` | Pre-RD scan + template. |

package/skills/peaks-code/references/external-references.md

@@ -10,8 +10,6 @@ Do not run upstream installer flows, mutate agent settings, or commit `.codegrap
 
 **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 via `peaks capabilities` before naming, references only (no execute/install/persist), Peaks-Loop CLI for all side effects. Do not execute upstream installers, do not install upstream resources, do not persist sensitive examples — Peaks-Loop gates remain authoritative. External skills inform, they do not approve.
 
-**OpenSpec lifecycle**: `render → validate → show → to-rd → validate → archive`. Code'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; Code 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.
 
-Detailed rules: `references/external-skill-invocation.md`, `references/openspec-mcp-workflow.md`, `references/workflow.md`, `references/existing-system-extraction.md`. For an informational mapping of peaks artefact paths to the A2A (Agent2Agent) protocol's Task / Artifact / Part / Message / AgentCard vocabulary (no A2A implementation, just a shared naming layer), see `references/a2a-artifact-mapping.md`.
+Detailed rules: `references/external-skill-invocation.md`, `references/workflow.md`, `references/existing-system-extraction.md`. For an informational mapping of peaks artefact paths to the A2A (Agent2Agent) protocol's Task / Artifact / Part / Message / AgentCard vocabulary (no A2A implementation, just a shared naming layer), see `references/a2a-artifact-mapping.md`.

package/skills/peaks-code/references/external-skill-invocation.md

@@ -40,7 +40,7 @@ The skill body must not silently:
 - commit or sync intermediate artifacts;
 - create remote repositories.
 
-All of these must route through the Peaks CLI under the appropriate command (`peaks artifacts …`, `peaks memory …`, `peaks openspec …`, `peaks standards …`, `peaks codegraph …`, `peaks capabilities …`), with dry-run preview where supported and `--yes` / `--apply` where a real write is required. The `peaks mcp …` command tree was retired in slice #016; MCP install / dispatch is the LLM runtime's job, not the CLI's.
+All of these must route through the Peaks CLI under the appropriate command (`peaks artifacts …`, `peaks memory …`, `peaks standards …`, `peaks codegraph …`, `peaks capabilities …`), with dry-run preview where supported and `--yes` / `--apply` where a real write is required. The `peaks mcp …` command tree was retired in slice #016; MCP install / dispatch is the LLM runtime's job, not the CLI's. Note: peaks-code's 11-step workflow does NOT route through any external artifact lifecycle (OpenSpec or otherwise) — all reads/writes are confined to the LLM-authored artifact workspace under `.peaks/_runtime/<sessionId>/<role>/`. External CLI surfaces remain available for users who call them directly, but Code never calls them on the user's behalf as of the 2026-07-08 RR decoupling slice.
 
 ## Allowed in-process references
 

package/skills/peaks-code/references/runbook.md

@@ -149,9 +149,7 @@ 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. Peaks-Loop 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
+# 9. Peaks-Loop Workspace reconcile (slate cleanup)
 peaks workspace reconcile --project <repo> --apply --older-than 7
 
 # 10. Peaks-Loop TXT handoff — invoke peaks-txt which embeds memory markers (BLOCKING)

package/skills/peaks-code/references/step-0-55-1x-detection.md

@@ -73,10 +73,11 @@ The decision is persisted via `peaks preferences set --project <root> --key auto
 
 ## How this integrates with the rest of the workflow
 
-- Step 0.5 (OpenSpec opt-in) — runs first if `openspec/` is missing.
 - Step 0 (anchor) — runs always.
 - Step 0.7 (resume detection) — runs after Step 0.
 - **Step 0.55 (1.x detection) — runs after Step 0.7, only when the project is not on a 2.0 layout.**
 - Step 1 (mode selection) — runs after Step 0.55.
 
 The 1.x detection is intentionally placed AFTER Step 0.7 because the user might already have a 1.x-converted in-flight slice; the resume flow takes precedence over the upgrade prompt.
+
+> **Historical note (prior to 2026-07-08 RR slice):** an OpenSpec first-run opt-in step (Step 0.5) used to sit between Step 0 and Step 0.7. peaks-code is now decoupled from OpenSpec and does not surface that step; this reference still preserves the historical ordering for context.

package/skills/peaks-code/references/workflow-gates-and-types.md

@@ -44,7 +44,7 @@ When Peaks-Loop Code coordinates development in a code repository, keep this ord
 6. **Peaks-Loop 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. **Peaks-Loop 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. **Peaks-Loop SC phase** — change-control evidence: impact, retention, validate, boundary;
-9. **Peaks-Loop OpenSpec archive** — exit gate: validate → archive only after QA verdict=pass (when `openspec/` exists);
+9. **Peaks-Loop Workspace reconcile** — slate cleanup;
 10. **Peaks-Loop TXT handoff capsule** — mode, validated decisions, artifact paths, standards deltas, open questions, next action;
 11. **Peaks-Loop Final snapshot** — `peaks project dashboard` + `peaks skill doctor` to confirm the workflow closed cleanly.
 

package/skills/peaks-slice-decompose/SKILL.md

@@ -108,4 +108,64 @@ This skill does NOT modify source code. It documents the v2 envelope produced by
 |---|---|
 | `references/v2-schema.md` | Field-by-field table for `DecompositionResultV2`, `PassResult`, `SliceV2`, `CrossPassEdge.arbitratedBy`, `LlmArbitration`. |
 | `references/granularity-decision.md` | Decision tree for the 4 `--granularity` modes; `shouldSubdivide()` thresholds + tie-break semantics. |
-| `references/cross-pass-edge-interpretation.md` | The 4 edge kinds and how `peaks-rd` should use them for dispatch ordering; `LlmArbitration` trace reader. |
+| `references/cross-pass-edge-interpretation.md` | The 4 edge kinds and how `peaks-rd` should use them for dispatch ordering; `LlmArbitration` trace reader. |
+
+---
+
+## SC template hard rules (sediment 2026-07-09)
+
+These rules are added in response to **D-009a + D-009c** discovered while running RID 003-add-zcode-adapter. They prevent the same class of mistake from re-occurring in future SC drafts.
+
+### Rule 1 — Pre-flight: detect ESM vs CJS before writing export syntax (D-009c)
+
+Before specifying `--caller-id` / export guard syntax in any SC task, run:
+
+```bash
+head -3 package.json | grep '"type"'
+```
+
+- `"type": "module"` → ESM. Use `export const FOO = ...` for any constant that tests need to import. **Do NOT** write `if (typeof module !== 'undefined' && module.exports) { module.exports = { FOO }; }` — that pattern is CJS-only.
+- No `"type"` field (or `"type": "commonjs"`) → CJS. Use the `module.exports` guard.
+
+Why: RID-003 SC §3.5 originally specified the CJS guard for `scripts/install-skills.mjs`. The script is actually ESM (`"type": "module"`). The RD agent had to backtrack and the SC lost 5 minutes of spec clarity.
+
+### Rule 2 — Whitelist fixture sync is NOT collateral (D-009a)
+
+When a slice adds a new entry to a **whitelist fixture** (e.g. `tests/unit/ide/ide-registry.test.ts` asserting `expect(adapters).toHaveLength(7)` after adding the 8th adapter), that fixture sync is a **primary task**, not a "by the way" footnote.
+
+Mandatory structure for any slice that adds to a known set:
+
+```markdown
+### Tasks
+
+| Task | File | Change |
+|---|---|---|
+| T-1 | `src/services/ide/ide-types.ts` | Add `'zcode'` to IdeId |
+| T-2 | `src/services/ide/ide-registry.ts` | Register ZCODE_ADAPTER |
+| T-3 | `tests/unit/ide/ide-registry.test.ts` | Update whitelist: 7 → 8 adapters, add 'zcode' |
+| T-4 | `tests/unit/install-skills-script.test.ts` | Update whitelist: 5 → 6 platforms, add 'zcode' |
+```
+
+If you find a whitelist fixture during execution but didn't pre-list it as a task, treat it as a **NEW TASK** and run the SC ↔ QA repair loop, not as "necessary collateral". Pre-listing prevents surprises at Gate 1.
+
+### Rule 3 — Adapter interface optional fields (D-009b reciprocal)
+
+When extending `IdeAdapter` (or any plugin-interface in `src/services/**/ide/`), prefer **optional fields** over required fields so existing implementations don't need stub updates:
+
+```ts
+// ✅ Optional — back-compat safe
+interface IdeAdapter {
+  readonly detectCurrentModel?: () => Promise<string | undefined>;
+}
+
+// ❌ Required — every existing adapter must add a stub
+interface IdeAdapter {
+  readonly detectCurrentModel: () => Promise<string | undefined>;
+}
+```
+
+If a field MUST be required, document in the SC why each existing implementation must be updated inline, and pre-list those updates as primary tasks (Rule 2 pattern).
+
+---
+
+**Sediment source:** `.peaks/_runtime/2026-07-08-session-17918f/qa/003-add-zcode-adapter/{slice-A-completion,slice-B-completion}.md` D-009a/b/c sections. Master lesson: `.peaks/memory/peaks-code-runbook-4-0-0-beta-6-skill-md-cli-d-001-d-002-d-003-d-010.md`.

package/skills/peaks-code/references/openspec-workflow.md

@@ -1,81 +0,0 @@
-# OpenSpec Lifecycle for Peaks Code
-
-Peaks Code orchestrates RD, QA, and SC. When the target repository uses OpenSpec, Code must drive the full lifecycle through the Peaks CLI so each role works against the same stable surface.
-
-> **Slice #016 (2026-06-09)**: this document used to live at `openspec-mcp-workflow.md` and contained a section on the `peaks mcp *` lifecycle. The MCP subsystem was retired in slice #016; that section is gone. The OpenSpec lifecycle described below is unchanged.
-
-## OpenSpec change lifecycle
-
-```text
-peaks openspec render   →  RD authors a change pack (dry-run, then --apply)
-peaks openspec validate →  Code gates RD output before slicing starts
-peaks openspec show     →  any role reads parsed proposal/tasks state
-peaks openspec to-rd    →  RD projects the pack into refactor slice input
-                          SC projects it into commit boundary candidates
-peaks openspec validate →  QA gates the final state before sign-off
-peaks openspec archive  →  Code moves the change under changes/archive/<id>/
-```
-
-Rules Code applies:
-
-- `render --apply` is the only Peaks-managed way to write a change pack. Other roles must not hand-edit `openspec/changes/**`.
-- `validate` is run twice per change in a refactor flow: once before slicing (RD entry gate) and once before archive (QA exit gate). Both must end with `data.valid === true`.
-- `archive --apply` is the lifecycle terminator; Code only invokes it after QA acceptance and SC commit.
-
-## Refactor workflow wiring
-
-For `peaks-code refactor` runs against a repository with `openspec/`:
-
-1. RD entry gate — `peaks openspec validate <id>` must pass and `peaks openspec to-rd <id>` must return `acceptance.length > 0`.
-2. Each slice must reference one OpenSpec tasks section as its commit boundary (per `references/openspec-commit-boundaries.md` in peaks-sc).
-3. QA exit gate — re-run `peaks openspec validate <id>` after implementation; record the result in the QA validation report.
-4. Archive — `peaks openspec archive <id> --apply` only after QA passes the exit gate and SC closes the final commit.
-
-If the consuming LLM needs an MCP server for docs lookup or research (e.g. Context7), it checks its own tool list for `mcp__<server>__*` and tells the user the install command if absent. peaks-loop is no longer in the install path; the LLM is the executor, the IDE is the dispatcher.
-
-## Boundary
-
-Code must not write `openspec/changes/**` or `~/.claude/settings.json` directly. Every mutation goes through the CLI commands above. The CLI returns stable envelopes; Code captures them as artifact links rather than re-explaining their content in the handoff.
-
----
-
-# Step 0.5 — OpenSpec first-run opt-in (conditional)
-
-> Body of `### Peaks-Loop Step 0.5`. After the workspace is anchored, before project scan, Code checks whether
-the project already has an `openspec/` directory. The lifecycle
-(`render → validate → show → to-rd → validate → archive`) only applies
-when `openspec/` exists; without it, RD/QA/SC silently skip the
-openspec-aware paths and you lose change-proposal tracking, commit
-boundaries from `tasks.md`, and the historical archive.
-
-To make that opt-in visible instead of silent, Code runs:
-
-```bash
-# 1. Detect whether the project already has openspec/.
-ls <repo>/openspec/changes 2>&1
-# 2. If absent, ask the user once — only on the first Code run in this
-#    project. The decision is sticky: write it to .peaks/.peaks-openspec-opt-in.json
-#    so subsequent Code invocations do not re-ask.
-test -f <repo>/.peaks/.peaks-openspec-opt-in.json || \
-  echo "{\"enabled\": <bool>}" > <repo>/.peaks/.peaks-openspec-opt-in.json
-```
-
-**AskUserQuestion** (only when `openspec/` is absent and the opt-in
-file is missing):
-
-| Option | What it does |
-|---|---|
-| Enable OpenSpec for this project (Recommended) | Run `peaks openspec init --project <repo> --apply`. After that, every Code run uses the change-proposal lifecycle for the same project. |
-| Skip for now | Do nothing. Code proceeds without openspec; the question is re-asked on the next first-run detection. |
-| Never ask again for this project | Write `{enabled: false, sticky: true}`. Code stops asking. The user can re-enable later by removing `.peaks/.peaks-openspec-opt-in.json` and re-running. |
-
-The first option is the recommended default because it gives Code the
-full change-proposal lifecycle (proposal / tasks / design / specs
-deltas, archive on ship, commit boundaries from `tasks.md`). It costs
-only a single scaffolded directory and pays back the first time the
-project needs a real review trail.
-
-If the user picks "Enable", the only required follow-up is to make
-sure `openspec/changes/` is added to git (it is part of the project
-repo, not a tool-managed artefact). Code does not run `git add` for
-the user; that is the user's commit boundary.