peaks-loop 3.0.0 → 3.0.1

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

@@ -5,7 +5,7 @@
  * Per the "one-key completion" + "minimal-user-operation" tenets
  * (2026-06-11), the typical upgrade path is:
  *
- *   $ npm i -g peaks-cli@2.0   # postinstall does everything
+ *   $ npm i -g peaks-loop@2.0   # postinstall does everything
  *
  * OR (postinstall skipped / manual fallback):
  *
@@ -104,7 +104,7 @@ function collectFilesRecursive(root, predicate) {
  */
 function expandMemoryArtifacts(projectRoot) {
     const out = [];
-    // skills/**/SKILL.md (peaks-cli repo convention)
+    // skills/**/SKILL.md (peaks-loop repo convention)
     const skillFiles = collectFilesRecursive(join(projectRoot, 'skills'), (name) => name === 'SKILL.md');
     for (const abs of skillFiles) {
         out.push(relative(projectRoot, abs));
@@ -202,7 +202,7 @@ function writeUpgradeRecord(projectRoot, result) {
         const date = new Date().toISOString().slice(0, 10);
         const file = join(memoryDir, `upgrade-2.0-${date}.md`);
         const lines = [];
-        lines.push(`# Upgrade to peaks-cli 2.0 — ${date}`);
+        lines.push(`# Upgrade to peaks-loop 2.0 — ${date}`);
         lines.push('');
         lines.push(`> Auto-generated by \`peaks upgrade --to 2.0${result.applied ? ' --auto' : ''}\`.`);
         lines.push(`> Per the "one-key completion" + "minimal-user-operation" tenets.`);
@@ -248,14 +248,14 @@ function writeUpgradeRecord(projectRoot, result) {
 export function runUpgrade(input) {
     // Resolve the peaks binary. Default: the peaks.js script
     // co-located with this compiled module (the user just installed
-    // peaks-cli globally, but the global `peaks` shim is a .sh
+    // peaks-loop globally, but the global `peaks` shim is a .sh
     // script that cmd.exe can't run on Windows). Falling back
     // to just "peaks" lets the umbrella work when invoked from
     // a Unix-style environment that can run the shim directly.
     const here = dirname(fileURLToPath(import.meta.url));
     // Walk up from the compiled location to find bin/peaks.js.
     // The compiled service lives at dist/src/services/upgrade/upgrade-service.js;
-    // bin/peaks.js is at the peaks-cli root.
+    // bin/peaks.js is at the peaks-loop root.
     const peaksBin = input.peaksBin ??
         resolve(here, '..', '..', '..', '..', 'bin', 'peaks.js');
     const fallbackPeaks = 'peaks';

package/dist/src/services/verdict/envelopes.d.ts

@@ -1,5 +1,5 @@
 /**
- * peaks-cli v2.13.3 — Envelope unification (AC-1: real markdown parse).
+ * peaks-loop v2.13.3 — Envelope unification (AC-1: real markdown parse).
  *
  * The 5 input envelopes feeding `aggregateVerdict()` have always been
  * heterogeneous (peaks-security-audit / peaks-perf-audit / karpathy /

package/dist/src/services/verdict/envelopes.js

@@ -1,5 +1,5 @@
 /**
- * peaks-cli v2.13.3 — Envelope unification (AC-1: real markdown parse).
+ * peaks-loop v2.13.3 — Envelope unification (AC-1: real markdown parse).
  *
  * The 5 input envelopes feeding `aggregateVerdict()` have always been
  * heterogeneous (peaks-security-audit / peaks-perf-audit / karpathy /

package/dist/src/services/workflow/workflow-loader.js

@@ -22,7 +22,7 @@ import { existsSync, readFileSync } from 'node:fs';
 import { join } from 'node:path';
 import { homedir } from 'node:os';
 import { parseWorkflowYaml, lintWorkflowSpec } from './workflow-spec.js';
-/** Built-in default workflows shipped with peaks-cli (git-tracked). */
+/** Built-in default workflows shipped with peaks-loop (git-tracked). */
 const BUNDLED_WORKFLOWS = new Set(['default-fullauto-md', 'loop-with-quality-md']);
 /** Try the project → global → bundled fallback chain and parse + lint. */
 export function resolveWorkflow(projectRoot, id) {

package/dist/src/services/workspace/migrate-1-4-1-service.d.ts

@@ -1,7 +1,7 @@
 /**
  * `peaks workspace migrate-1-4-1` — R004.
  *
- * Cleanup command for projects upgraded from peaks-cli 1.4.1 → 1.4.2.
+ * Cleanup command for projects upgraded from peaks-loop 1.4.1 → 1.4.2.
  *
  * Slice 006 (1.4.0) moved the canonical per-session root to
  * `.peaks/_runtime/<sid>/`. Per-request artifacts (PRD, RD, QA, SC requests)

package/dist/src/services/workspace/migrate-1-4-1-service.js

@@ -1,7 +1,7 @@
 /**
  * `peaks workspace migrate-1-4-1` — R004.
  *
- * Cleanup command for projects upgraded from peaks-cli 1.4.1 → 1.4.2.
+ * Cleanup command for projects upgraded from peaks-loop 1.4.1 → 1.4.2.
  *
  * Slice 006 (1.4.0) moved the canonical per-session root to
  * `.peaks/_runtime/<sid>/`. Per-request artifacts (PRD, RD, QA, SC requests)

package/dist/src/services/workspace/migrate-types.d.ts

@@ -2,7 +2,7 @@
  * Type envelope for the `peaks workspace migrate` CLI command.
  *
  * The migrate command is the downstream-project counterpart to the
- * one-time Phase 5 migration script that ran on the peaks-cli self-host
+ * one-time Phase 5 migration script that ran on the peaks-loop self-host
  * for slice 2026-06-05-change-id-as-unit-of-work. Where
  * `peaks workspace reconcile` only handles the top-level runtime state
  * files (`.peaks/.session.json`, `.peaks/.active-skill.json`,

package/dist/src/services/workspace/migrate-types.js

@@ -2,7 +2,7 @@
  * Type envelope for the `peaks workspace migrate` CLI command.
  *
  * The migrate command is the downstream-project counterpart to the
- * one-time Phase 5 migration script that ran on the peaks-cli self-host
+ * one-time Phase 5 migration script that ran on the peaks-loop self-host
  * for slice 2026-06-05-change-id-as-unit-of-work. Where
  * `peaks workspace reconcile` only handles the top-level runtime state
  * files (`.peaks/.session.json`, `.peaks/.active-skill.json`,

package/dist/src/services/workspace/workspace-claude-settings-materializer.d.ts

@@ -17,7 +17,7 @@
  *
  * The function is idempotent: re-running on an already-materialized
  * project is a no-op (the file is rewritten only when its content
- * diverges from the current peaks-cli release's template, which
+ * diverges from the current peaks-loop release's template, which
  * keeps the consumer up to date as the template evolves).
  *
  * Even when the caller passes `noClaudeHooks: true`, the function
@@ -30,7 +30,7 @@
  *
  * Slice 2026-06-13-selfheal-claude-settings-template: the offline copy
  * is now ALSO drift-checked (via `templateContentMatches`) so stale
- * on-disk copies from earlier peaks-cli releases (which lacked the
+ * on-disk copies from earlier peaks-loop releases (which lacked the
  * `node -e "..."` wrapper) get refreshed automatically on the next
  * init. The action taken on the offline copy is surfaced in
  * `claudeSettings.offlineTemplate.action`.

package/dist/src/services/workspace/workspace-claude-settings-materializer.js

@@ -19,8 +19,8 @@ import { buildClaudeSettingsLocalJson, CLAUDE_SETTINGS_LOCAL_FILENAME, templateC
  * in a commit. Marked with a managed-by header so we can detect (and
  * not double-append) on subsequent inits.
  */
-const PEAKS_GITIGNORE_HEADER = '# >>> peaks-cli managed snippet (slice 2.0.1-bug3) — do not edit by hand';
-const PEAKS_GITIGNORE_FOOTER = '# <<< peaks-cli managed snippet';
+const PEAKS_GITIGNORE_HEADER = '# >>> peaks-loop managed snippet (slice 2.0.1-bug3) — do not edit by hand';
+const PEAKS_GITIGNORE_FOOTER = '# <<< peaks-loop managed snippet';
 const PEAKS_GITIGNORE_SNIPPET = [
     PEAKS_GITIGNORE_HEADER,
     '# Consumer-project .claude/settings.local.json: written by `peaks workspace init`',
@@ -28,10 +28,10 @@ const PEAKS_GITIGNORE_SNIPPET = [
     '.claude/settings.local.json',
     '# Offline template copy (.peaks/.claude-settings-template.json): written by',
     '# `peaks workspace init` as a manual-recovery anchor. The source-of-truth is',
-    '# peaks-cli\'s own `buildClaudeSettingsLocalJson()` — NOT this committed copy.',
+    '# peaks-loop\'s own `buildClaudeSettingsLocalJson()` — NOT this committed copy.',
     '# Gitignored so the init flow\'s drift-driven refresh does not show up as',
     '# "modified" in `git status` on every release bump. Recovery path: re-run',
-    '# `peaks workspace init` to regenerate; or copy from peaks-cli source.',
+    '# `peaks workspace init` to regenerate; or copy from peaks-loop source.',
     '.peaks/.claude-settings-template.json',
     PEAKS_GITIGNORE_FOOTER,
     ''
@@ -44,7 +44,7 @@ const PEAKS_GITIGNORE_SNIPPET = [
  *
  * The function is idempotent: re-running on an already-materialized
  * project is a no-op (the file is rewritten only when its content
- * diverges from the current peaks-cli release's template, which
+ * diverges from the current peaks-loop release's template, which
  * keeps the consumer up to date as the template evolves).
  *
  * Even when the caller passes `noClaudeHooks: true`, the function
@@ -57,7 +57,7 @@ const PEAKS_GITIGNORE_SNIPPET = [
  *
  * Slice 2026-06-13-selfheal-claude-settings-template: the offline copy
  * is now ALSO drift-checked (via `templateContentMatches`) so stale
- * on-disk copies from earlier peaks-cli releases (which lacked the
+ * on-disk copies from earlier peaks-loop releases (which lacked the
  * `node -e "..."` wrapper) get refreshed automatically on the next
  * init. The action taken on the offline copy is surfaced in
  * `claudeSettings.offlineTemplate.action`.
@@ -117,15 +117,15 @@ export async function materializeClaudeSettingsLocal(projectRoot, noClaudeHooks)
  * source-of-truth on disk for the manual recovery flow. The file is
  * GITIGNORED (added to `.peaks/.gitignore` by
  * `upsertPeaksGitignoreSnippet`) — the source-of-truth lives in
- * peaks-cli's own `buildClaudeSettingsLocalJson()`, NOT in any
+ * peaks-loop's own `buildClaudeSettingsLocalJson()`, NOT in any
  * committed copy. Gitignoring it ensures the init flow's drift-driven
  * refresh does not show up as "modified" in `git status` on every
- * peaks-cli release bump.
+ * peaks-loop release bump.
  *
  * Recovery path for users who need to re-create their
  * `.claude/settings.local.json`: re-run `peaks workspace init`
  * (the file is regenerated); or copy the template straight from
- * peaks-cli source (`src/services/workspace/claude-settings-template.ts`).
+ * peaks-loop source (`src/services/workspace/claude-settings-template.ts`).
  *
  * Slice 2026-06-13-selfheal-claude-settings-template: drift-check via
  * `templateContentMatches` BEFORE writing. If the on-disk copy's

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

@@ -47,7 +47,7 @@ export type WorkspaceInitReport = {
      * `.claude/settings.local.json` materialization did this call.
      *   - written:        the file was freshly written
      *   - refreshed:      the file already existed and was rewritten to
-     *                     match the current peaks-cli release's template
+     *                     match the current peaks-loop release's template
      *   - already-current: the file already matched the template; no
      *                     rewrite needed
      *   - skipped:        the caller passed noClaudeHooks=true

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

@@ -120,7 +120,7 @@ export class LegacyChangeIdSiblingError extends Error {
     legacyPath;
     code = 'LEGACY_CHANGE_ID_SIBLING';
     constructor(sessionId, legacyPath) {
-        super(`peaks-cli 2.8.3+ forbids the legacy sibling dir ${legacyPath}. ` +
+        super(`peaks-loop 2.8.3+ forbids the legacy sibling dir ${legacyPath}. ` +
             `Under the two-axis convention, change-id "${sessionId}" must live in the SESSION axis ` +
             `(.peaks/_runtime/<sessionId>/), not as a top-level sibling of .peaks/_runtime/. ` +
             `Migration: (1) inspect ${legacyPath} for user-authored content; ` +

package/dist/src/shared/path-safety.d.ts

@@ -1,5 +1,5 @@
 /**
- * Path-safety helpers for peaks-cli artifact paths.
+ * Path-safety helpers for peaks-loop artifact paths.
  *
  * Extracted after the v2.19.0 change-id root removal. The change-id
  * axis was eliminated entirely; the remaining helper utilities are

package/dist/src/shared/path-safety.js

@@ -1,5 +1,5 @@
 /**
- * Path-safety helpers for peaks-cli artifact paths.
+ * Path-safety helpers for peaks-loop artifact paths.
  *
  * Extracted after the v2.19.0 change-id root removal. The change-id
  * axis was eliminated entirely; the remaining helper utilities are

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

@@ -1 +1 @@
-export declare const CLI_VERSION = "3.0.0";
+export declare const CLI_VERSION = "3.0.1";

package/dist/src/shared/version.js

@@ -1 +1 @@
-export const CLI_VERSION = "3.0.0";
+export const CLI_VERSION = "3.0.1";

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

@@ -4,31 +4,31 @@ description: Peaks 专用输出风格：仅在 peaks skills 工作流中用东
 keep-coding-instructions: true
 ---
 
-This output style is self-gated. Apply the sections below only when the current task explicitly invokes or continues a Peaks-Cli skill workflow, including `/peaks-*`, `skills/peaks-*`, Peaks-Cli PRD/RD/QA/UI/SC/TXT/Solo work, or edits to this repository's `skills/` directory. For unrelated tasks, preserve the default Claude Code behavior and keep responses concise.
+This output style is self-gated. Apply the sections below only when the current task explicitly invokes or continues a Peaks-Loop skill workflow, including `/peaks-*`, `skills/peaks-*`, Peaks-Loop PRD/RD/QA/UI/SC/TXT/Solo work, or edits to this repository's `skills/` directory. For unrelated tasks, preserve the default Claude Code behavior and keep responses concise.
 
-## Peaks-Cli response contract
+## Peaks-Loop response contract
 
-When active, make the skill transition visually obvious with a light Northeastern Chinese humor tone. Keep technical facts, risks, commands, and evidence precise; use humor only in short labels or one-liners, never to obscure blockers or failures. Start the first response for a Peaks-Cli skill task with this banner:
+When active, make the skill transition visually obvious with a light Northeastern Chinese humor tone. Keep technical facts, risks, commands, and evidence precise; use humor only in short labels or one-liners, never to obscure blockers or failures. Start the first response for a Peaks-Loop skill task with this banner:
 
 ```markdown
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Peaks-Cli Skill Active: <skill-name> — 整活开工，但不整虚的
-Peaks-Cli Role Chain: <PRD → RD → QA → SC, or single role>
-Peaks-Cli Mode: <Solo | Assisted | Swarm | Strict | Economy>
-Peaks-Cli Current Gate: <confirmation | dry-run | coverage | QA | commit boundary | handoff>
+Peaks-Loop Skill Active: <skill-name> — 整活开工，但不整虚的
+Peaks-Loop Role Chain: <PRD → RD → QA → SC, or single role>
+Peaks-Loop Mode: <Solo | Assisted | Swarm | Strict | Economy>
+Peaks-Loop Current Gate: <confirmation | dry-run | coverage | QA | commit boundary | handoff>
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
 Use visible layout elements, not just a different tone: heavy separators, bracketed badges, a three-step workflow strip, and compact evidence tables. Then include a short process preview before doing work:
 
 ```markdown
-Peaks-Cli [流程] ① <current role action>  →  ② <next gate or validation>  →  ③ <handoff / artifact / follow-up>
+Peaks-Loop [流程] ① <current role action>  →  ② <next gate or validation>  →  ③ <handoff / artifact / follow-up>
 ```
 
 For swarm or economy mode, add a compact worker table when useful:
 
 ```markdown
-| Peaks-Cli Worker | Scope | Model/Cost lane | Output | Stop condition |
+| Peaks-Loop Worker | Scope | Model/Cost lane | Output | Stop condition |
 | --- | --- | --- | --- | --- |
 | RD-1 | <subsystem> | <high/economy/configured provider> | <artifact> | <done signal> |
 ```
@@ -36,7 +36,7 @@ For swarm or economy mode, add a compact worker table when useful:
 For final evidence, prefer this visual block:
 
 ```markdown
-┌─ Peaks-Cli Evidence ─────────────────────
+┌─ Peaks-Loop Evidence ─────────────────────
 │ Commands: <only commands that matter>
 │ Artifacts: <paths or none>
 │ Changed: <files or none>
@@ -45,28 +45,28 @@ For final evidence, prefer this visual block:
 └──────────────────────────────────────────
 ```
 
-For continuing turns in the same Peaks-Cli workflow, use a compact status header instead of the full banner:
+For continuing turns in the same Peaks-Loop workflow, use a compact status header instead of the full banner:
 
 ```markdown
-Peaks-Cli Skill: <skill-name> | Peaks-Cli Gate: <current gate> | Next: <one short action>
+Peaks-Loop Skill: <skill-name> | Peaks-Loop Gate: <current gate> | Next: <one short action>
 ```
 
-Structure active Peaks-Cli responses around:
+Structure active Peaks-Loop responses around:
 
-1. **Peaks-Cli Role** — name the active Peaks-Cli role or role chain, for example PRD → RD → QA → SC.
-2. **Peaks-Cli Mode** — state whether the workflow is Solo, Assisted, Swarm, Strict, or Economy.
-3. **Peaks-Cli Current Gate** — show the current required gate: product confirmation, RD dry-run, coverage, QA acceptance, commit boundary, or handoff.
+1. **Peaks-Loop Role** — name the active Peaks-Loop role or role chain, for example PRD → RD → QA → SC.
+2. **Peaks-Loop Mode** — state whether the workflow is Solo, Assisted, Swarm, Strict, or Economy.
+3. **Peaks-Loop Current Gate** — show the current required gate: product confirmation, RD dry-run, coverage, QA acceptance, commit boundary, or handoff.
 4. **Action** — describe the immediate next action in one short sentence before tool use.
-5. **Peaks-Cli Evidence** — end with only the evidence that matters: commands, artifacts, changed files, blockers, and next action.
+5. **Peaks-Loop Evidence** — end with only the evidence that matters: commands, artifacts, changed files, blockers, and next action.
 
 Do not produce long narrative logs. Prefer compact capsules, tables, and checklists when they reduce ambiguity. For unrelated non-Peaks tasks, do not show the banner.
 
-## Peaks-Cli + GStack alignment
+## Peaks-Loop + GStack alignment
 
-Use gstack as a workflow reference for `Think → Plan → Build → Review → Test → Ship → Reflect`, but keep Peaks-Cli as the authority:
+Use gstack as a workflow reference for `Think → Plan → Build → Review → Test → Ship → Reflect`, but keep Peaks-Loop as the authority:
 
-- Think maps to Peaks-Cli PRD and TXT context.
-- Plan maps to Peaks-Cli RD/UI planning, risk matrices, and slice contracts.
+- Think maps to Peaks-Loop PRD and TXT context.
+- Plan maps to Peaks-Loop RD/UI planning, risk matrices, and slice contracts.
 - Build maps to RD implementation under strict specs.
 - Review maps to code review, design review, and security review.
 - Test maps to QA regression and acceptance evidence.
@@ -75,7 +75,7 @@ Use gstack as a workflow reference for `Think → Plan → Build → Review →
 
 Do not imply that gstack commands are available unless the project has explicitly installed or exposed them.
 
-## Peaks-Cli Swarm development mode
+## Peaks-Loop Swarm development mode
 
 Use Swarm mode for broad, parallelizable work with separable responsibilities. When recommending or running swarm work:
 
@@ -87,7 +87,7 @@ Use Swarm mode for broad, parallelizable work with separable responsibilities. W
 
 Prefer parallel agents only for independent work. Do not duplicate searches or reviews already assigned to a worker.
 
-## Peaks-Cli Economy mode
+## Peaks-Loop Economy mode
 
 Use Economy mode when the user asks for low-cost execution or when the task is broad but low-risk. In Economy mode:
 
@@ -99,28 +99,28 @@ Use Economy mode when the user asks for low-cost execution or when the task is b
 
 When explaining Economy mode, separate **available now** from **recommended if configured**.
 
-## Peaks-Cli RD code-output rule
+## Peaks-Loop RD code-output rule
 
-When the active role is Peaks-Cli RD and code is produced or modified, require repeated dry-runs:
+When the active role is Peaks-Loop RD and code is produced or modified, require repeated dry-runs:
 
-1. run applicable Peaks-Cli standards dry-runs before planning or implementation;
+1. run applicable Peaks-Loop standards dry-runs before planning or implementation;
 2. rerun relevant dry-runs after each meaningful slice or standards-affecting decision;
 3. rerun before handoff, review, or commit-boundary work;
 4. include dry-run command, result, and remaining action in the RD handoff capsule.
 
 If a dry-run cannot be executed, state the blocker and keep it as the next action rather than silently skipping it.
 
-## Peaks-Cli Output examples
+## Peaks-Loop Output examples
 
-### Active Peaks-Cli skill
+### Active Peaks-Loop skill
 
 ```markdown
-Peaks-Cli Role: RD → QA
-Peaks-Cli Mode: Swarm
-Peaks-Cli Current Gate: RD dry-run before implementation
+Peaks-Loop Role: RD → QA
+Peaks-Loop Mode: Swarm
+Peaks-Loop Current Gate: RD dry-run before implementation
 Action: I will run standards dry-runs, then split workers by subsystem.
 
-Peaks-Cli Evidence:
+Peaks-Loop Evidence:
 - Commands: ...
 - Artifacts: ...
 - Blocker: none
@@ -129,4 +129,4 @@ Peaks-Cli Evidence:
 
 ### Non-Peaks task
 
-Use normal concise Claude Code responses without the Peaks-Cli role/mode/gate wrapper.
+Use normal concise Claude Code responses without the Peaks-Loop role/mode/gate wrapper.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peaks-loop",
-  "version": "3.0.0",
+  "version": "3.0.1",
   "description": "Loop Engineering CLI — workflow primitive / loop guards / evaluators / slice orchestration",
   "author": "SquabbyZ",
   "license": "MIT",
@@ -11,11 +11,11 @@
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/SquabbyZ/peaks-cli.git"
+    "url": "https://github.com/SquabbyZ/peaks-loop.git"
   },
-  "homepage": "https://github.com/SquabbyZ/peaks-cli",
+  "homepage": "https://github.com/SquabbyZ/peaks-loop",
   "bugs": {
-    "url": "https://github.com/SquabbyZ/peaks-cli/issues"
+    "url": "https://github.com/SquabbyZ/peaks-loop/issues"
   },
   "bin": {
     "peaks": "./bin/peaks.js"
@@ -91,6 +91,7 @@
     "@jridgewell/trace-mapping": "^0.3.31",
     "@stryker-mutator/core": "^8.7.1",
     "@stryker-mutator/typescript-checker": "^8.7.1",
+    "@stryker-mutator/vitest-runner": "^8.7.1",
     "@types/node": "^22.10.2",
     "@vitest/coverage-v8": "^2.1.8",
     "tsx": "^4.19.2",

package/schemas/decomposition-v1.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://peaks-cli.dev/schemas/decomposition-v1.json",
+  "$id": "https://peaks-loop.dev/schemas/decomposition-v1.json",
   "title": "Peaks Decomposition Result v1",
   "description": "v1 (legacy) slice decomposition output. Discriminated by the absence of a `schemaVersion` field. v1 files remain readable via `SchemaRouter.readResult`; new code should write v2 instead.",
   "type": "object",

package/schemas/decomposition-v2.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://peaks-cli.dev/schemas/decomposition-v2.json",
+  "$id": "https://peaks-loop.dev/schemas/decomposition-v2.json",
   "title": "Peaks Decomposition Result v2 (multi-pass)",
   "description": "v2 multi-pass slice decomposition output. Emitted by `peaks-slice-decompose` and the new `MultiPassOrchestrator`. Discriminated by `schemaVersion: 'v2'`. v1 files (no schemaVersion) remain readable via SchemaRouter.",
   "type": "object",

package/schemas/replay-fixture.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://peaks-cli.dev/schemas/replay-fixture.schema.json",
+  "$id": "https://peaks-loop.dev/schemas/replay-fixture.schema.json",
   "title": "Replay Fixture Metadata",
   "description": "Meta envelope for v2.14.0 G1 fixture-replay anti-fake-green test fixtures. Records the CLI command that produced the fixture, its source origin, sanitization report, and SHA-256 checksum. Every fixture under tests/fixtures/replay/ MUST have a co-located fixture.meta.json that validates against this schema.",
   "type": "object",

package/schemas/reviewer-envelope.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "peaks-cli/schemas/reviewer-envelope.schema.json",
+  "$id": "peaks-loop/schemas/reviewer-envelope.schema.json",
   "title": "ReviewerEnvelope",
   "description": "Schema-validated JSON envelope emitted by peaks-reviewer (third-party reviewer). All LLM JSON output MUST validate against this shape; free-form LLM JSON is rejected. v2.14.0 G4 AC-4.2.",
   "type": "object",

package/scripts/install-skills.mjs

@@ -392,10 +392,10 @@ const IDE_DETECTION_DIRS = [
 ];
 
 /**
- * Per-IDE skill install paths. Per peaks-cli tenet
+ * Per-IDE skill install paths. Per peaks-loop tenet
  * "minimal-user-operation" (2026-06-11), the user should
  * never have to run a per-platform install command — the
- * `npm i -g peaks-cli` postinstall iterates ALL of these
+ * `npm i -g peaks-loop` postinstall iterates ALL of these
  * and symlinks the peaks-* skill family to every platform
  * the user might be on.
  *
@@ -730,8 +730,8 @@ export function installBundledOutputStyles(options = {}) {
  *
  * Mirrors `installBundledOutputStyles` but writes to
  * `~/.claude/agents/` (Claude Code's sub-agent loader directory). Each
- * agent file ships under `agents/*.md` in the peaks-cli tarball and is
- * copied on `npm i -g peaks-cli@latest` with content-hash drift detection
+ * agent file ships under `agents/*.md` in the peaks-loop tarball and is
+ * copied on `npm i -g peaks-loop@latest` with content-hash drift detection
  * via a `.peaks-managed` marker (SHA-256 of the source content).
  *
  * Drift policy (mirrors output-styles):
@@ -867,7 +867,7 @@ export function installBundledAgents(options = {}) {
  * platforms can add an `agentsDir` field to their `IDE_SKILL_INSTALL_PROFILES`
  * entry to opt in.
  *
- * Per peaks-cli tenet "minimal-user-operation" (2026-06-11): the user
+ * Per peaks-loop tenet "minimal-user-operation" (2026-06-11): the user
  * should never have to run a per-platform install command. Symlink /
  * copy failures are soft (logged to stderr, never throw) so one platform's
  * failure doesn't block the others.
@@ -918,7 +918,7 @@ export function installBundledAgentsForAllPlatforms(options = {}) {
 
 /**
  * Per-platform fan-out — iterate ALL 8 IdeIds and call
- * `installBundledSkills` for each. Per peaks-cli tenet
+ * `installBundledSkills` for each. Per peaks-loop tenet
  * "minimal-user-operation" (2026-06-11): the user should
  * never have to run a per-platform install command. The
  * 1.x postinstall only handled the auto-detected single
@@ -1065,7 +1065,7 @@ export function detect1xProjectState(cwd = process.cwd()) {
 
 /**
  * Postinstall auto-upgrade — when the user just ran
- * `npm i -g peaks-cli@2.0` and `cwd` is a 1.x peaks-cli
+ * `npm i -g peaks-loop@2.0` and `cwd` is a 1.x peaks-loop
  * project, this shells out to the installed `peaks`
  * binary to run the umbrella `peaks upgrade --to 2.0 --auto`.
  *
@@ -1140,8 +1140,8 @@ if (process.argv[1] !== undefined && import.meta.url === pathToFileURL(resolve(p
     }
     const outputStylesResult = installBundledOutputStyles();
     // Slice 7/7 — bundled agents (Claude Code sub-agent prompts) ship
-    // under `agents/*.md` in the peaks-cli tarball and are auto-installed
-    // to `~/.claude/agents/` on `npm i -g peaks-cli@latest`. Drift
+    // under `agents/*.md` in the peaks-loop tarball and are auto-installed
+    // to `~/.claude/agents/` on `npm i -g peaks-loop@latest`. Drift
     // detection is content-hash + `.peaks-managed` marker (mirrors the
     // output-styles contract).
     const agentsPerPlatform = installBundledAgentsForAllPlatforms();
@@ -1174,7 +1174,7 @@ if (process.argv[1] !== undefined && import.meta.url === pathToFileURL(resolve(p
 
     // 2.0 postinstall: auto-detect 1.x project state in cwd
     // and dispatch the upgrade umbrella. This makes the
-    // user's `npm i -g peaks-cli@2.0` truly one-key.
+    // user's `npm i -g peaks-loop@2.0` truly one-key.
     if (process.env.PEAKS_SKIP_AUTO_UPGRADE !== '1') {
       // Fire-and-forget; the upgrade is async by design so
       // the npm install output isn't blocked. We print a
@@ -1183,7 +1183,7 @@ if (process.argv[1] !== undefined && import.meta.url === pathToFileURL(resolve(p
       autoUpgrade1xProjectIfPresent().then((result) => {
         if (result.ran) {
           process.stdout.write(
-            `\n✓ Detected 1.x peaks-cli project at ${result.projectRoot}\n` +
+            `\n✓ Detected 1.x peaks-loop project at ${result.projectRoot}\n` +
               `  → auto-upgraded to 2.0 (${result.signals?.length ?? 0} signals resolved)\n` +
               `  Run \`peaks audit red-lines --project .\` to verify.\n`
           );

package/skills/peaks-audit/SKILL.md

@@ -7,9 +7,9 @@ description: Gate autonomous LLM work on a 6-dimension audit + user-accepted goa
 
 > **Read once at the top of this file; the rest of the skill is written against it.**
 
-The `.peaks/` workspace is partitioned by a **single scope axis** (session-id, at `.peaks/_runtime/<sessionId>/...`) with a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` placeholders (NEVER bare `<sid>`). The peaks-cli change-id axis was removed in slice `2026-06-29-change-id-root-removal`; reviewable artifacts now live under `.peaks/_runtime/<sessionId>/<role>/...` only. OpenSpec's independent `openspec/changes/<change-id>/` vocabulary (L4) is preserved untouched. CLI mapping: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. Regression test `tests/unit/skills/skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) every `.peaks/_runtime/<X>/` has an axis label, (c) this callout is present.
+The `.peaks/` workspace is partitioned by a **single scope axis** (session-id, at `.peaks/_runtime/<sessionId>/...`) with a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` placeholders (NEVER bare `<sid>`). The peaks-loop change-id axis was removed in slice `2026-06-29-change-id-root-removal`; reviewable artifacts now live under `.peaks/_runtime/<sessionId>/<role>/...` only. OpenSpec's independent `openspec/changes/<change-id>/` vocabulary (L4) is preserved untouched. CLI mapping: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. Regression test `tests/unit/skills/skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) every `.peaks/_runtime/<X>/` has an axis label, (c) this callout is present.
 
-# Peaks-Cli Audit
+# Peaks-Loop Audit
 
 `peaks-audit` is the **first** step in any peaks-* workflow. It turns a human-expressed need into a 6-dimension audit plus a proposed goal, and refuses to let autonomous LLM work proceed on a partial audit. It is invoked IMMEDIATELY after the need is expressed, and BEFORE any PRD, RD, or QA work begins.
 

package/skills/peaks-doctor/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: peaks-doctor
-description: Orchestrate peaks-cli's L3 doctor (peaks audit + peaks doctor + peaks openspec from-doctor) for project health. Use when the user asks for a project health check, doctor report, audit, or wants to convert doctor findings into OpenSpec change records. Coordinates the L2 audit framework + the L3.2 doctor + the L3.3 from-doctor proposal generator. Triggers on `/peaks-doctor`, "peaks doctor", "项目健康", "doctor report", "health check", "check the project", "audit my repo".
+description: Orchestrate peaks-loop's L3 doctor (peaks audit + peaks doctor + peaks openspec from-doctor) for project health. Use when the user asks for a project health check, doctor report, audit, or wants to convert doctor findings into OpenSpec change records. Coordinates the L2 audit framework + the L3.2 doctor + the L3.3 from-doctor proposal generator. Triggers on `/peaks-doctor`, "peaks doctor", "项目健康", "doctor report", "health check", "check the project", "audit my repo".
 internal: true
 ---
 ---
 
-# Peaks-Cli Doctor
+# Peaks-Loop Doctor
 
-Peaks-Cli Doctor is the orchestration facade for the L3 doctor workflow. It runs the L2 audit framework (`peaks audit red-lines`) + the L3.2 doctor checks (`peaks doctor`) + the L3.3 from-doctor proposal generator (`peaks openspec from-doctor`). Use it when the user wants a project health check, a red-line audit, or to convert doctor findings into OpenSpec change records.
+Peaks-Loop Doctor is the orchestration facade for the L3 doctor workflow. It runs the L2 audit framework (`peaks audit red-lines`) + the L3.2 doctor checks (`peaks doctor`) + the L3.3 from-doctor proposal generator (`peaks openspec from-doctor`). Use it when the user wants a project health check, a red-line audit, or to convert doctor findings into OpenSpec change records.
 
 ## Skill-first architecture note (read once, internalise)
 
@@ -15,7 +15,7 @@ This skill is the **primary surface**. The `peaks <cmd>` CLI is **auxiliary**
 
 ## Code-Change Red Line (BLOCKING — read before ANY tool call)
 
-**Peaks-Cli Doctor is a doctor orchestrator, NOT an implementer. You MUST NOT write, edit, or modify any application source code directly.**
+**Peaks-Loop Doctor is a doctor orchestrator, NOT an implementer. You MUST NOT write, edit, or modify any application source code directly.**
 
 The doctor workflow is read-only by design. It produces:
 - `peaks audit red-lines` report (121 red lines in the current repo, 6 cli-backed)

package/skills/peaks-final-review/SKILL.md

@@ -7,9 +7,9 @@ description: Final-review skill for Peaks. Use when a workflow needs to assemble
 
 > **Read once at the top of this file; the rest of the skill is written against it.**
 
-The `.peaks/` workspace is partitioned by a **single scope axis** (session-id, at `.peaks/_runtime/<sessionId>/...`) with a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` placeholders (NEVER bare `<sid>`). The peaks-cli change-id axis was removed in slice `2026-06-29-change-id-root-removal`; reviewable artifacts now live under `.peaks/_runtime/<sessionId>/<role>/...` only. OpenSpec's independent `openspec/changes/<change-id>/` vocabulary (L4) is preserved untouched. CLI mapping: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. Regression test `tests/unit/skills/skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) every `.peaks/_runtime/<X>/` has an axis label, (c) this callout is present.
+The `.peaks/` workspace is partitioned by a **single scope axis** (session-id, at `.peaks/_runtime/<sessionId>/...`) with a nested **sub-agent axis** under `.peaks/_sub_agents/<sessionId>/...`. Use `<sessionId>` placeholders (NEVER bare `<sid>`). The peaks-loop change-id axis was removed in slice `2026-06-29-change-id-root-removal`; reviewable artifacts now live under `.peaks/_runtime/<sessionId>/<role>/...` only. OpenSpec's independent `openspec/changes/<change-id>/` vocabulary (L4) is preserved untouched. CLI mapping: session-id → `peaks session *`; sub-agent → `peaks sub-agent *`. Regression test `tests/unit/skills/skills-skill-md-naming.test.ts` enforces (a) zero bare `<sid>`, (b) every `.peaks/_runtime/<X>/` has an axis label, (c) this callout is present.
 
-# Peaks-Cli Final Review
+# Peaks-Loop Final Review
 
 Prepare 4-dim business review evidence for human acceptance. The LLM does the work; the human judges the outcome.
 

package/skills/peaks-ide/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: peaks-ide
-description: Orchestrate peaks-cli's IDE-aware behavior (hooks + statusline + handle) for a user's specific IDE. Detects the current state (which IDE the user is on, what peaks has already installed), plans the install / switch / status / uninstall actions, and invokes the existing peaks CLI primitives. Triggers on `/peaks-ide`, "set up peaks for my IDE", "switch peaks to Trae", "what did peaks install", "uninstall peaks hooks". Sits between the user and `peaks hooks install` / `peaks statusline install` / `peaks hook handle` — those are the CLI primitives; this skill is the user-facing surface.
+description: Orchestrate peaks-loop's IDE-aware behavior (hooks + statusline + handle) for a user's specific IDE. Detects the current state (which IDE the user is on, what peaks has already installed), plans the install / switch / status / uninstall actions, and invokes the existing peaks CLI primitives. Triggers on `/peaks-ide`, "set up peaks for my IDE", "switch peaks to Trae", "what did peaks install", "uninstall peaks hooks". Sits between the user and `peaks hooks install` / `peaks statusline install` / `peaks hook handle` — those are the CLI primitives; this skill is the user-facing surface.
 internal: true
 ---
 ---
 
-# Peaks-Cli IDE Setup (peaks-ide)
+# Peaks-Loop IDE Setup (peaks-ide)
 
-`peaks-ide` is the **user-facing surface** for everything peaks-cli does that's IDE-aware. It does NOT introduce new CLI commands. It orchestrates the existing CLI primitives — `peaks hooks install`, `peaks statusline install`, `peaks hook handle` — based on the user's intent and the IDE the user is on.
+`peaks-ide` is the **user-facing surface** for everything peaks-loop does that's IDE-aware. It does NOT introduce new CLI commands. It orchestrates the existing CLI primitives — `peaks hooks install`, `peaks statusline install`, `peaks hook handle` — based on the user's intent and the IDE the user is on.
 
 **Why this exists (dev-preference red line):** "skill is primary, CLI is auxiliary." The behavior that only an LLM in a skill prompt would use ("detect which IDE the user is on", "plan the migration steps", "ask the user before destructive actions") lives in this SKILL.md, not in a new `peaks <cmd>`. The CLI commands stay as atomic primitives the skill composes.