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

package/dist/src/services/runtime/runtime-service.d.ts

@@ -0,0 +1,59 @@
+/**
+ * Runtime service — slice S2-a of RD-2.
+ *
+ * Orchestrator that wires the runtime detector + vendor adapter
+ * registry into a small surface that the CLI commands call. The
+ * service owns the canonical list of built-in adapters (claude-code /
+ * codex / copilot) and decides which adapter handles a given
+ * `--via <id>` request.
+ *
+ * Design notes (Karpathy #2 Simplicity First):
+ *
+ *  - The service is a thin orchestrator — it does NOT contain any
+ *    vendor verb strings (claude / codex / copilot). All vendor verbs
+ *    live in `src/services/runtime/vendors/<vendor>.ts`. Verified by
+ *    AC-1.
+ *  - When `compactVia(id)` is called with an unknown id, the service
+ *    returns a "no-op" result with exitCode=0 and a warning instead of
+ *    throwing — vendor-neutrality means peaks-loop MUST keep working
+ *    even when the requested vendor adapter isn't registered.
+ *  - The service is the SOLE owner of the built-in adapter list. Tests
+ *    and CLI commands should never instantiate adapters directly;
+ *    they should call `listBuiltInAdapters()` or `getAdapter(id)`.
+ */
+import type { VendorAdapter, VendorCompactResult } from './vendor-adapter.js';
+export interface RuntimeServiceOptions {
+    /** Override the built-in adapter list (used by tests + the
+     *  adapter-registry's `register()` flow). */
+    readonly builtIns?: VendorAdapter[];
+    /** Override the home dir used by adapter detect() helpers. */
+    readonly home?: string;
+}
+/** Pure orchestrator. The runtime service holds built-in adapters as
+ *  the baseline registry; the AdapterRegistry layer (`src/services/
+ *  adapter/adapter-registry.ts`) extends this baseline at runtime via
+ *  user-registered adapters persisted to `.peaks/runtime/adapters.json`.
+ *  The two layers are intentionally separate:
+ *    - runtime-service: built-in vendor adapters for the runtime-detect
+ *      compact flow (S2-a).
+ *    - adapter-registry: persisted user-registered adapters (S2-a).
+ *  runtime-service itself does NOT consult the adapter registry —
+ *  callers (`peaks runtime compact --via <id>`) layer them: first look
+ *  up the id in the persisted registry, fall back to the built-in list.
+ */
+export declare class RuntimeService {
+    private readonly builtIns;
+    constructor(opts?: RuntimeServiceOptions);
+    /** Return all built-in adapters. Order: claude-code, codex, copilot. */
+    listBuiltInAdapters(): VendorAdapter[];
+    /** Resolve a built-in adapter by id. Returns undefined when not
+     *  found — caller should fall back to adapter registry or unknown. */
+    getBuiltInAdapter(id: string): VendorAdapter | undefined;
+    /** Compact via a built-in adapter. When the id is unknown, returns
+     *  a no-op result with a warning rather than throwing — vendor
+     *  neutrality demands peaks-loop stay alive even when a vendor is
+     *  not wired up. */
+    compactVia(id: string, force: boolean | undefined): Promise<VendorCompactResult & {
+        warning?: string;
+    }>;
+}

package/dist/src/services/runtime/runtime-service.js

@@ -0,0 +1,51 @@
+import { ClaudeCodeAdapter } from './vendors/claude-code.js';
+import { CodexAdapter } from './vendors/codex.js';
+import { CopilotAdapter } from './vendors/copilot.js';
+const DEFAULT_BUILT_INS = [
+    new ClaudeCodeAdapter(),
+    new CodexAdapter(),
+    new CopilotAdapter()
+];
+/** Pure orchestrator. The runtime service holds built-in adapters as
+ *  the baseline registry; the AdapterRegistry layer (`src/services/
+ *  adapter/adapter-registry.ts`) extends this baseline at runtime via
+ *  user-registered adapters persisted to `.peaks/runtime/adapters.json`.
+ *  The two layers are intentionally separate:
+ *    - runtime-service: built-in vendor adapters for the runtime-detect
+ *      compact flow (S2-a).
+ *    - adapter-registry: persisted user-registered adapters (S2-a).
+ *  runtime-service itself does NOT consult the adapter registry —
+ *  callers (`peaks runtime compact --via <id>`) layer them: first look
+ *  up the id in the persisted registry, fall back to the built-in list.
+ */
+export class RuntimeService {
+    builtIns;
+    constructor(opts = {}) {
+        this.builtIns = opts.builtIns ?? [...DEFAULT_BUILT_INS];
+    }
+    /** Return all built-in adapters. Order: claude-code, codex, copilot. */
+    listBuiltInAdapters() {
+        return [...this.builtIns];
+    }
+    /** Resolve a built-in adapter by id. Returns undefined when not
+     *  found — caller should fall back to adapter registry or unknown. */
+    getBuiltInAdapter(id) {
+        return this.builtIns.find((a) => a.id === id);
+    }
+    /** Compact via a built-in adapter. When the id is unknown, returns
+     *  a no-op result with a warning rather than throwing — vendor
+     *  neutrality demands peaks-loop stay alive even when a vendor is
+     *  not wired up. */
+    async compactVia(id, force) {
+        const adapter = this.getBuiltInAdapter(id);
+        if (adapter === undefined) {
+            return {
+                exitCode: 0,
+                stdout: '',
+                stderr: '',
+                warning: `no built-in adapter registered for id="${id}" — falling back to no-op; use \`peaks adapter register --id ${id} --binary <cmd>\` to wire one`
+            };
+        }
+        return adapter.compact({ force: force === true });
+    }
+}

package/dist/src/services/runtime/vendor-adapter.d.ts

@@ -0,0 +1,59 @@
+/**
+ * Vendor adapter contract — slice S2-a of RD-2 (2026-07-08 session).
+ *
+ * Each `VendorAdapter` is a thin wrapper around ONE AI runtime (Claude
+ * Code / Codex / Copilot / custom) that knows how to:
+ *
+ *   1. Detect whether the current environment is that vendor
+ *      (env vars, sentinel binaries, environment shape).
+ *   2. Issue a compact command through that vendor without forcing
+ *      peaks-loop's core code to know vendor-specific verbs.
+ *
+ * The interface is intentionally MINIMAL (Karpathy #2 Simplicity First):
+ * two methods (`detect`, `compact`) plus an `id` + `displayName`.
+ * New verbs (status, refactor, etc.) are NOT in scope — they would
+ * bloat the surface and force every vendor to implement every verb
+ * whether the vendor supports it or not. When a future verb is needed
+ * it can either be added to the interface (with all vendors forced to
+ * implement) or — preferred — handled through a separate
+ * verb-specific adapter family.
+ *
+ * Vendor-specific verb strings (`claude --compact`, `codex --compact`,
+ * `copilot compact`) MUST live ONLY in adapter implementations under
+ * `src/services/runtime/vendors/<vendor>.ts`. The runtime service that
+ * orchestrates these adapters (runtime-service.ts) and the CLI commands
+ * (`peaks runtime compact --via <id>`) MUST NOT contain vendor verbs
+ * — verified by AC-1: `rg -n "claude --compact|codex --compact|copilot
+ * compact" src/services/code/` must return 0 matches.
+ *
+ * See `.peaks/_runtime/2026-07-08-session-17918f/prd/002-adapter-runtime-and-polyrepo.md`
+ * for the source PRD.
+ */
+export interface VendorCompactArgs {
+    /** When `true`, the vendor is asked to compact unconditionally even
+     *  if its auto-detector says it would not normally do so. */
+    readonly force?: boolean;
+}
+export interface VendorCompactResult {
+    readonly exitCode: number;
+    readonly stdout: string;
+    readonly stderr: string;
+}
+export interface VendorAdapter {
+    /** Stable identifier used by `peaks runtime compact --via <id>` and
+     *  by the adapter registry. Convention: lowercase, dash-separated,
+     *  e.g. `claude-code`, `codex`, `copilot`. */
+    readonly id: string;
+    /** Human-readable name shown in `peaks runtime list` output. */
+    readonly displayName: string;
+    /** Whether the CURRENT environment is this vendor. Detectors MUST
+     *  be pure functions of env + filesystem; they MUST NOT spawn
+     *  processes or call vendor CLIs (a detect that itself runs the
+     *  vendor would defeat the purpose of asking whether the vendor is
+     *  present). */
+    detect(): Promise<boolean>;
+    /** Issue a compact command for this vendor. The adapter chooses
+     *  which binary + args + env to invoke; callers MUST NOT pass
+     *  vendor verbs through this method. */
+    compact(args?: VendorCompactArgs): Promise<VendorCompactResult>;
+}

package/dist/src/services/runtime/vendor-adapter.js

@@ -0,0 +1 @@
+export {};

package/dist/src/services/runtime/vendors/claude-code.d.ts

@@ -0,0 +1,7 @@
+import type { VendorAdapter, VendorCompactArgs, VendorCompactResult } from '../vendor-adapter.js';
+export declare class ClaudeCodeAdapter implements VendorAdapter {
+    readonly id = "claude-code";
+    readonly displayName = "Claude Code";
+    detect(): Promise<boolean>;
+    compact(args?: VendorCompactArgs): Promise<VendorCompactResult>;
+}

package/dist/src/services/runtime/vendors/claude-code.js

@@ -0,0 +1,39 @@
+/**
+ * Claude Code vendor adapter — slice S2-a.
+ *
+ * Stubs the compact verb to `claude --compact` (the canonical vendor
+ * verb for Claude Code). The actual binary is invoked via spawn so
+ * the adapter does NOT block peaks-loop. When the `claude` binary is
+ * not on PATH the adapter returns exitCode=127 + stderr explaining
+ * the missing binary, which the runtime service surfaces as a warning
+ * + no-op rather than a fatal error (vendor-neutrality: peaks-loop
+ * should still work even when the host vendor CLI is absent).
+ */
+import { spawn } from 'node:child_process';
+export class ClaudeCodeAdapter {
+    id = 'claude-code';
+    displayName = 'Claude Code';
+    async detect() {
+        return process.env.CLAUDE_CODE === '1'
+            || process.env.CLAUDE_CODE === 'true'
+            || (process.env.CLAUDE_CODE_ENTRYPOINT?.length ?? 0) > 0;
+    }
+    async compact(args = {}) {
+        const argv = ['--compact'];
+        if (args.force === true)
+            argv.push('--force');
+        return new Promise((resolveRun) => {
+            const proc = spawn('claude', argv, { stdio: ['ignore', 'pipe', 'pipe'] });
+            let stdout = '';
+            let stderr = '';
+            proc.stdout.on('data', (chunk) => { stdout += chunk.toString('utf8'); });
+            proc.stderr.on('data', (chunk) => { stderr += chunk.toString('utf8'); });
+            proc.on('error', (err) => {
+                resolveRun({ exitCode: 127, stdout, stderr: stderr + (stderr.length > 0 ? '\n' : '') + err.message });
+            });
+            proc.on('close', (code) => {
+                resolveRun({ exitCode: code ?? 0, stdout, stderr });
+            });
+        });
+    }
+}

package/dist/src/services/runtime/vendors/codex.d.ts

@@ -0,0 +1,7 @@
+import type { VendorAdapter, VendorCompactArgs, VendorCompactResult } from '../vendor-adapter.js';
+export declare class CodexAdapter implements VendorAdapter {
+    readonly id = "codex";
+    readonly displayName = "Codex";
+    detect(): Promise<boolean>;
+    compact(args?: VendorCompactArgs): Promise<VendorCompactResult>;
+}

package/dist/src/services/runtime/vendors/codex.js

@@ -0,0 +1,43 @@
+/**
+ * Codex vendor adapter — slice S2-a.
+ *
+ * Stub adapter (PRD out-of-scope: full implementation lands in a
+ * future slice). The detect() heuristic is intentionally permissive:
+ * if CODEX_HOME or ~/.codex is present we report detected=true so
+ * `peaks runtime detect` exercises the codex branch. compact() uses
+ * the canonical `codex --compact` invocation; missing-binary is
+ * reported as exitCode=127, not a thrown error (the runtime service
+ * surfaces that as a warning + no-op so a missing vendor CLI does
+ * not break peaks-loop).
+ */
+import { spawn } from 'node:child_process';
+import { existsSync } from 'node:fs';
+import { join } from 'node:path';
+export class CodexAdapter {
+    id = 'codex';
+    displayName = 'Codex';
+    async detect() {
+        if (process.env.CODEX_HOME !== undefined && process.env.CODEX_HOME.length > 0)
+            return true;
+        const home = process.env.HOME ?? process.env.USERPROFILE ?? '';
+        return home.length > 0 && existsSync(join(home, '.codex'));
+    }
+    async compact(args = {}) {
+        const argv = ['--compact'];
+        if (args.force === true)
+            argv.push('--force');
+        return new Promise((resolveRun) => {
+            const proc = spawn('codex', argv, { stdio: ['ignore', 'pipe', 'pipe'] });
+            let stdout = '';
+            let stderr = '';
+            proc.stdout.on('data', (chunk) => { stdout += chunk.toString('utf8'); });
+            proc.stderr.on('data', (chunk) => { stderr += chunk.toString('utf8'); });
+            proc.on('error', (err) => {
+                resolveRun({ exitCode: 127, stdout, stderr: stderr + (stderr.length > 0 ? '\n' : '') + err.message });
+            });
+            proc.on('close', (code) => {
+                resolveRun({ exitCode: code ?? 0, stdout, stderr });
+            });
+        });
+    }
+}

package/dist/src/services/runtime/vendors/copilot.d.ts

@@ -0,0 +1,7 @@
+import type { VendorAdapter, VendorCompactArgs, VendorCompactResult } from '../vendor-adapter.js';
+export declare class CopilotAdapter implements VendorAdapter {
+    readonly id = "copilot";
+    readonly displayName = "GitHub Copilot";
+    detect(): Promise<boolean>;
+    compact(args?: VendorCompactArgs): Promise<VendorCompactResult>;
+}

package/dist/src/services/runtime/vendors/copilot.js

@@ -0,0 +1,40 @@
+/**
+ * Copilot vendor adapter — slice S2-a.
+ *
+ * Stub adapter (PRD out-of-scope: full implementation lands in a
+ * future slice). Copilot's compact verb is `copilot compact`
+ * (subcommand form, not `--compact` flag — different from Claude
+ * Code + Codex). The adapter encapsulates that verb here so the
+ * runtime service + CLI never see it.
+ */
+import { spawn } from 'node:child_process';
+import { existsSync } from 'node:fs';
+import { join } from 'node:path';
+export class CopilotAdapter {
+    id = 'copilot';
+    displayName = 'GitHub Copilot';
+    async detect() {
+        if (process.env.GITHUB_COPILOT === '1' || process.env.GITHUB_COPILOT === 'true')
+            return true;
+        const home = process.env.HOME ?? process.env.USERPROFILE ?? '';
+        return home.length > 0 && existsSync(join(home, '.copilot'));
+    }
+    async compact(args = {}) {
+        const argv = ['compact'];
+        if (args.force === true)
+            argv.push('--force');
+        return new Promise((resolveRun) => {
+            const proc = spawn('copilot', argv, { stdio: ['ignore', 'pipe', 'pipe'] });
+            let stdout = '';
+            let stderr = '';
+            proc.stdout.on('data', (chunk) => { stdout += chunk.toString('utf8'); });
+            proc.stderr.on('data', (chunk) => { stderr += chunk.toString('utf8'); });
+            proc.on('error', (err) => {
+                resolveRun({ exitCode: 127, stdout, stderr: stderr + (stderr.length > 0 ? '\n' : '') + err.message });
+            });
+            proc.on('close', (code) => {
+                resolveRun({ exitCode: code ?? 0, stdout, stderr });
+            });
+        });
+    }
+}

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.6";

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.6";

package/package.json

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

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`.
@@ -288,7 +282,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-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.