peaks-loop 4.1.1 → 4.1.3

package/dist/services/job/job-progress-store.d.ts

@@ -24,7 +24,6 @@
 import { z } from 'zod';
 export declare const JOB_PROGRESS_SCHEMA_VERSION: 1;
 /**
- * D3 (rid 2026-10-03-job-ledger-truthfulness) — what the mirror says when the
  * ledger has no pending slice.
  *
  * `currentSlice` is required by the schema below (it is a `string`, and readers
@@ -80,7 +79,6 @@ export interface NextSliceFacts {
     readonly currentSlice: string;
 }
 /**
- * criterion (c) (rid 2026-10-03-job-ledger-repair1) — the one sentence the reader
  * acts on, built from the mirror instead of guessed at.
  *
  * WHY THIS EXISTS. The parent slice made `currentSlice` honest (§2.38: it used to

package/dist/services/job/job-progress-store.js

@@ -29,7 +29,6 @@ import { guardRuntimeSegment, runtimeRoot } from '../../shared/runtime-root.js';
  * The single place a job-progress directory is built, and therefore the single
  * place the two ids that reach it are guarded.
  *
- * Slice 2026-09-15 (runtime-path-unrepresentable): this join used to be written
  * at three sites, none of them guarded, and the shipped text rule could not see
  * them — they sit in the service layer, outside the command layer it scans.
  * Both ids are caller-supplied (`peaks job checkpoint` takes them from flags).
@@ -41,7 +40,6 @@ function jobProgressDir(projectRoot, sessionId, jobId) {
 }
 export const JOB_PROGRESS_SCHEMA_VERSION = 1;
 /**
- * D3 (rid 2026-10-03-job-ledger-truthfulness) — what the mirror says when the
  * ledger has no pending slice.
  *
  * `currentSlice` is required by the schema below (it is a `string`, and readers
@@ -114,7 +112,6 @@ function addSliceAdvice(jobId) {
     return `peaks job add-slice --job-id ${jobId ?? '<job-id>'} --slice-label ${ADD_SLICE_LABEL_SLOT}`;
 }
 /**
- * criterion (c) (rid 2026-10-03-job-ledger-repair1) — the one sentence the reader
  * acts on, built from the mirror instead of guessed at.
  *
  * WHY THIS EXISTS. The parent slice made `currentSlice` honest (§2.38: it used to

package/dist/services/job/job-types.js

@@ -99,7 +99,6 @@ export const JobCheckpointInputSchema = z
 })
     .superRefine((v, ctx) => {
     if (v.state === 'done') {
-        // D2 (rid 2026-10-03-job-ledger-truthfulness). Two rules, in this order,
         // both on the same claim about the same field.
         //
         // 1. THE SHAPE RULE. It stays exactly where the defect was measured

package/dist/services/job-snapshot/snapshot.js

@@ -29,7 +29,6 @@ export function collectResourceSnapshot(jobDir) {
 // Non-enumerable internal attachment for test-time access via
 // `collectResourceSnapshot.dirSizeMb`. NOT a public export — keeps
 // the prod module surface clean per PRD while still allowing
-// targeted AC-1/AC-2/AC-3 unit tests to drive `dirSizeMb` directly.
 Object.defineProperty(collectResourceSnapshot, 'dirSizeMb', {
     value: dirSizeMb,
     enumerable: false,

package/dist/services/karpathy-cost/karpathy-cost-check-service.js

@@ -1,6 +1,5 @@
 // src/services/karpathy-cost/karpathy-cost-check-service.ts
 //
-// Slice 2026-07-30-karpathy-cost-self-review (slice 2/4). The
 // karpathy-reviewer's JSON envelope is extended with `evaluationCost`
 // + `costRatio` (see agents/karpathy-reviewer.md §4). This service
 // is the orchestrator-side consumer of those fields.

package/dist/services/legacy/legacy-detector.js

@@ -25,7 +25,6 @@ const PATTERNS = [
 ];
 /**
  * NOT the file-size cap, and NOT a second copy of it — decided 2026-09-30, rid
- * `2026-09-30-cap-unify-01` repair cycle (F6), and recorded in
  * `.peaks/docs/lint-gate.md` §4b row 7 so the next reader does not re-litigate it.
  *
  * This is a legacy SMELL heuristic: a number above which a file is big enough to

package/dist/services/lint/npx-resolver.js

@@ -17,6 +17,13 @@ import process from 'node:process';
 function locateNpmCliScript(scriptFile) {
     const candidates = process.platform === 'win32'
         ? [
+            // Standard Windows layout — the installer, the zip, and
+            // nvm-for-windows all put `node_modules/npm` beside `node.exe`, so the
+            // install is ONE level up from `process.execPath`, not two. This is the
+            // `npm` belonging to the very `node` that will run the script, so it is
+            // tried first; the three entries after it are the backstop for an `npm`
+            // installed elsewhere.
+            join(process.execPath, '..', 'node_modules', 'npm', 'bin', scriptFile),
             join(process.execPath, '..', '..', 'node_modules', 'npm', 'bin', scriptFile),
             `C:/nvm4w/nodejs/node_modules/npm/bin/${scriptFile}`,
             `C:/Program Files/nodejs/node_modules/npm/bin/${scriptFile}`

package/dist/services/log/log-commands-service.d.ts

@@ -1,7 +1,6 @@
 /**
  * Service layer for `peaks log tail` and `peaks log ls` subcommands.
  *
- * Slice 2026-06-16-cli-logging (G4). Pure helpers that the
  * commander layer in `src/cli/commands/log-commands.ts` wraps.
  * Separated from `logger.ts` so the surface is small + testable
  * without spinning up a Commander program.
@@ -30,7 +29,6 @@ export type TailLogOptions = {
     /** Override the date (PRD AC2: PEAKS_LOG_DATE_OVERRIDE). */
     dateOverride?: string;
     /**
-     * Slice 2026-06-23-audit-4th #B2: filter by batchId. When set,
      * only entries whose `batchId` field matches are returned (and
      * the trailing-window accounting respects the post-filter total
      * so a busy day does not push old matching entries out of view).

package/dist/services/log/log-commands-service.js

@@ -1,7 +1,6 @@
 /**
  * Service layer for `peaks log tail` and `peaks log ls` subcommands.
  *
- * Slice 2026-06-16-cli-logging (G4). Pure helpers that the
  * commander layer in `src/cli/commands/log-commands.ts` wraps.
  * Separated from `logger.ts` so the surface is small + testable
  * without spinning up a Commander program.
@@ -64,7 +63,6 @@ export function tailLog(opts = {}) {
     if (total === 0) {
         return { file: null, entries: [], total: 0 };
     }
-    // Slice 2026-06-23-audit-4th #B2: batchId filter — apply AFTER the
     // read but BEFORE the trailing window, so a single batch's
     // interleaved log lines surface as a coherent sequence instead of
     // being pushed out by sibling-batch lines.

package/dist/services/log/logger.d.ts

@@ -1,7 +1,6 @@
 /**
  * JSONL file logger for peaks-loop.
  *
- * Slice 2026-06-16-cli-logging (G1, G2, G5, G6, G7).
  *
  * Default-on file logging: every peaks-loop invocation writes a
  * structured log entry to `<homedir>/.peaks/logs/peaks-loop-YYYY-MM-DD.log`

package/dist/services/log/logger.js

@@ -1,7 +1,6 @@
 /**
  * JSONL file logger for peaks-loop.
  *
- * Slice 2026-06-16-cli-logging (G1, G2, G5, G6, G7).
  *
  * Default-on file logging: every peaks-loop invocation writes a
  * structured log entry to `<homedir>/.peaks/logs/peaks-loop-YYYY-MM-DD.log`

package/dist/services/log/redact.d.ts

@@ -1,7 +1,6 @@
 /**
  * Secret redaction for peaks-loop JSONL log lines.
  *
- * Slice 2026-06-16-cli-logging (G6). The logger must NEVER write
  * a raw secret to disk. We redact at two levels:
  *  1. Field level — when a structured payload contains a key whose
  *     name matches a secret pattern (`api_key`, `password`, `token`,

package/dist/services/log/redact.js

@@ -1,7 +1,6 @@
 /**
  * Secret redaction for peaks-loop JSONL log lines.
  *
- * Slice 2026-06-16-cli-logging (G6). The logger must NEVER write
  * a raw secret to disk. We redact at two levels:
  *  1. Field level — when a structured payload contains a key whose
  *     name matches a secret pattern (`api_key`, `password`, `token`,

package/dist/services/log/retention.d.ts

@@ -1,7 +1,6 @@
 /**
  * 7-day log rotation for peaks-loop.
  *
- * Slice 2026-06-16-cli-logging (G2). Cheapest possible rotation:
  * daily files are named by UTC date, so a "new day" automatically
  * means a new file. The retention sweep runs at the start of every
  * peaks-loop invocation and removes any `peaks-loop-*.log` whose

package/dist/services/log/retention.js

@@ -1,7 +1,6 @@
 /**
  * 7-day log rotation for peaks-loop.
  *
- * Slice 2026-06-16-cli-logging (G2). Cheapest possible rotation:
  * daily files are named by UTC date, so a "new day" automatically
  * means a new file. The retention sweep runs at the start of every
  * peaks-loop invocation and removes any `peaks-loop-*.log` whose

package/dist/services/loop/loop-bee-relation-service.d.ts

@@ -1,4 +1,4 @@
-import type Database from 'better-sqlite3';
+import { type SqliteDatabase } from '../sqlite/sqlite-driver.js';
 import { ZodError } from 'zod';
 import { type LoopBeeRelation, type LoopBeeRelationInput, type LoopBeeRelationRole } from './loop-bee-relation-types.js';
 /**
@@ -46,7 +46,7 @@ export declare class LoopBeeRelationIntegrityError extends Error {
  *      — enforced at DB level (UNIQUE).
  *      — surfaced as DUP_RELATION for friendlier errors.
  *
- * The constructor takes an open better-sqlite3 database (the existing
+ * The constructor takes an open SQLite database (the existing
  * `peaks state` boundary) so callers do not have to thread a path
  * through this layer; this matches the LoopReleaseService pattern.
  *
@@ -55,7 +55,7 @@ export declare class LoopBeeRelationIntegrityError extends Error {
  */
 export declare class LoopBeeRelationService {
     private readonly db;
-    constructor(db: Database.Database);
+    constructor(db: SqliteDatabase);
     /**
      * Persist a new LoopBeeRelation row.
      *

package/dist/services/loop/loop-bee-relation-service.js

@@ -1,3 +1,4 @@
+import { constraintKind } from '../sqlite/sqlite-driver.js';
 import { ZodError } from 'zod';
 import { LoopBeeRelationSchema } from './loop-bee-relation-types.js';
 import { ensureLoopBeeRelationTable, insertLoopBeeRelation, listLoopBeeRelationsByLoop, listLoopBeeRelationsByBee, updateLoopBeeRelationRole, removeLoopBeeRelation, getLoopBeeRelation } from './loop-bee-relation-store.js';
@@ -39,7 +40,7 @@ export class LoopBeeRelationIntegrityError extends Error {
  *      — enforced at DB level (UNIQUE).
  *      — surfaced as DUP_RELATION for friendlier errors.
  *
- * The constructor takes an open better-sqlite3 database (the existing
+ * The constructor takes an open SQLite database (the existing
  * `peaks state` boundary) so callers do not have to thread a path
  * through this layer; this matches the LoopReleaseService pattern.
  *
@@ -111,15 +112,16 @@ export class LoopBeeRelationService {
             return insertLoopBeeRelation(this.db, parsed);
         }
         catch (err) {
-            const code = typeof err === 'object' && err !== null && 'code' in err ? err.code : undefined;
+            // The driver's error CODE is not portable across SQLite bindings, so the question
+            // "which constraint failed" is asked of the seam, which reads node:sqlite's `errcode`
+            // (2067 / 787) and better-sqlite3's `code` alike.
+            const kind = constraintKind(err);
             // Partial unique index on (loop_release_id) WHERE role='main'.
-            // better-sqlite3 surfaces this as SQLITE_CONSTRAINT_UNIQUE with
-            // a message naming only `loop_bee_relation.loop_release_id`
-            // (the column the partial index covers), NOT the index name.
-            // It is distinguished from the (loop_release_id, bee_release_id)
-            // composite UNIQUE violation by the absence of bee_release_id
-            // in the message.
-            if (code === 'SQLITE_CONSTRAINT_UNIQUE') {
+            // It surfaces as a UNIQUE violation whose message names only
+            // `loop_bee_relation.loop_release_id` (the column the partial index covers), NOT the
+            // index name. It is distinguished from the (loop_release_id, bee_release_id)
+            // composite UNIQUE violation by the absence of bee_release_id in the message.
+            if (kind === 'unique') {
                 const msg = err instanceof Error ? err.message : String(err);
                 if (msg.includes('loop_bee_relation.bee_release_id')) {
                     // Composite UNIQUE(loop_release_id, bee_release_id).
@@ -138,8 +140,8 @@ export class LoopBeeRelationService {
                     }
                 ]);
             }
-            // FK violations from better-sqlite3 (foreign_keys = ON).
-            if (code === 'SQLITE_CONSTRAINT_FOREIGNKEY') {
+            // FK violations (foreign_keys = ON, which `openStateDb` turns on).
+            if (kind === 'foreign-key') {
                 // Distinguish by re-checking which row is missing; the friendly
                 // pre-check above should have caught these, but defense in depth.
                 const loopStill = this.db
@@ -183,8 +185,7 @@ export class LoopBeeRelationService {
             return updateLoopBeeRelationRole(this.db, id, newRole);
         }
         catch (err) {
-            const code = typeof err === 'object' && err !== null && 'code' in err ? err.code : undefined;
-            if (code === 'SQLITE_CONSTRAINT_UNIQUE') {
+            if (constraintKind(err) === 'unique') {
                 const existing = getLoopBeeRelation(this.db, id);
                 const loopId = existing?.loop_release_id ?? '<unknown>';
                 throw new LoopBeeRelationIntegrityError('TWO_MAIN_BEES', `loop '${loopId}' already has a main bee`, [{ path: 'role', message: 'at most one main bee per loop' }]);

package/dist/services/loop/loop-bee-relation-store.d.ts

@@ -1,4 +1,4 @@
-import type Database from 'better-sqlite3';
+import type { SqliteDatabase } from '../sqlite/sqlite-driver.js';
 import type { LoopBeeRelation, LoopBeeRelationRole } from './loop-bee-relation-types.js';
 /**
  * Low-level SQLite access for the `loop_bee_relation` table. The
@@ -10,13 +10,12 @@ import type { LoopBeeRelation, LoopBeeRelationRole } from './loop-bee-relation-t
  *
  * Defense in depth:
  *   - FK constraints enforce loop_release and bee_release referential
- *     integrity (better-sqlite3 + foreign_keys = ON).
+ *     integrity (foreign_keys = ON, applied by `openStateDb`).
  *   - Partial unique index `WHERE role = 'main'` enforces "at most one
  *     main bee per loop" at the storage layer (the service layer adds
  *     a friendlier error path on top).
  *   - UNIQUE (loop_release_id, bee_release_id) prevents accidental
  *     duplicate relations between the same loop and same bee release.
- *   - The migration does NOT touch any 4.x `bee_release` column (AC-3).
  *   - Lifecycle_status check on loop_release is NOT a DB-level constraint
  *     (the retirement rule is enforced in the service layer — see
  *     `LoopBeeRelationService.create`) so the DB stays decoupled from
@@ -27,7 +26,7 @@ import type { LoopBeeRelation, LoopBeeRelationRole } from './loop-bee-relation-t
  * database. Used by tests that build their own DB without the
  * openStateDb pipeline. Idempotent.
  */
-export declare function ensureLoopBeeRelationTable(db: Database.Database): void;
+export declare function ensureLoopBeeRelationTable(db: SqliteDatabase): void;
 /**
  * Insert a LoopBeeRelation row. The row's `schema_version` is taken from
  * the input (must equal `peaks.loop-bee-relation/1`); `id` and
@@ -40,14 +39,14 @@ export declare function ensureLoopBeeRelationTable(db: Database.Database): void;
  *
  * Returns the persisted row (with `id` filled in).
  */
-export declare function insertLoopBeeRelation(db: Database.Database, row: Omit<LoopBeeRelation, 'id' | 'created_at'>): LoopBeeRelation;
+export declare function insertLoopBeeRelation(db: SqliteDatabase, row: Omit<LoopBeeRelation, 'id' | 'created_at'>): LoopBeeRelation;
 /** Read a single LoopBeeRelation row by id; returns undefined if absent. */
-export declare function getLoopBeeRelation(db: Database.Database, id: number): LoopBeeRelation | undefined;
+export declare function getLoopBeeRelation(db: SqliteDatabase, id: number): LoopBeeRelation | undefined;
 /** List LoopBeeRelation rows for a given loop_release_id (optionally filtered by role). */
-export declare function listLoopBeeRelationsByLoop(db: Database.Database, loop_release_id: string, role?: LoopBeeRelationRole): LoopBeeRelation[];
+export declare function listLoopBeeRelationsByLoop(db: SqliteDatabase, loop_release_id: string, role?: LoopBeeRelationRole): LoopBeeRelation[];
 /** List LoopBeeRelation rows for a given bee_release_id (optionally filtered by role). */
-export declare function listLoopBeeRelationsByBee(db: Database.Database, bee_release_id: number, role?: LoopBeeRelationRole): LoopBeeRelation[];
+export declare function listLoopBeeRelationsByBee(db: SqliteDatabase, bee_release_id: number, role?: LoopBeeRelationRole): LoopBeeRelation[];
 /** Update the role of an existing relation. Returns the new row, or undefined if absent. */
-export declare function updateLoopBeeRelationRole(db: Database.Database, id: number, newRole: LoopBeeRelationRole): LoopBeeRelation | undefined;
+export declare function updateLoopBeeRelationRole(db: SqliteDatabase, id: number, newRole: LoopBeeRelationRole): LoopBeeRelation | undefined;
 /** Remove a LoopBeeRelation row by id. Returns true if a row was deleted. */
-export declare function removeLoopBeeRelation(db: Database.Database, id: number): boolean;
+export declare function removeLoopBeeRelation(db: SqliteDatabase, id: number): boolean;

package/dist/services/loop/loop-bee-relation-store.js

@@ -8,13 +8,12 @@
  *
  * Defense in depth:
  *   - FK constraints enforce loop_release and bee_release referential
- *     integrity (better-sqlite3 + foreign_keys = ON).
+ *     integrity (foreign_keys = ON, applied by `openStateDb`).
  *   - Partial unique index `WHERE role = 'main'` enforces "at most one
  *     main bee per loop" at the storage layer (the service layer adds
  *     a friendlier error path on top).
  *   - UNIQUE (loop_release_id, bee_release_id) prevents accidental
  *     duplicate relations between the same loop and same bee release.
- *   - The migration does NOT touch any 4.x `bee_release` column (AC-3).
  *   - Lifecycle_status check on loop_release is NOT a DB-level constraint
  *     (the retirement rule is enforced in the service layer — see
  *     `LoopBeeRelationService.create`) so the DB stays decoupled from

package/dist/services/loop/loop-bee-relation-types.d.ts

@@ -41,7 +41,7 @@ export declare const LOOP_BEE_RELATION_ROLES: readonly LoopBeeRelationRole[];
  * `loop_release_id` must match the same kebab-case pattern as
  * `LoopRelease.id` — this is a defensive duplicate of the FK target's
  * shape, but the authoritative check is the FK constraint at insert
- * time (better-sqlite3 with `foreign_keys = ON`).
+ * time (with `foreign_keys = ON`, which `openStateDb` applies).
  *
  * `bee_release_id` is a positive integer; matching the
  * `bee_release.id` autoincrement INTEGER PK.

package/dist/services/loop/loop-bee-relation-types.js

@@ -40,7 +40,7 @@ export const LOOP_BEE_RELATION_ROLES = [
  * `loop_release_id` must match the same kebab-case pattern as
  * `LoopRelease.id` — this is a defensive duplicate of the FK target's
  * shape, but the authoritative check is the FK constraint at insert
- * time (better-sqlite3 with `foreign_keys = ON`).
+ * time (with `foreign_keys = ON`, which `openStateDb` applies).
  *
  * `bee_release_id` is a positive integer; matching the
  * `bee_release.id` autoincrement INTEGER PK.

package/dist/services/loop/loop-release-service.d.ts

@@ -1,4 +1,4 @@
-import type Database from 'better-sqlite3';
+import type { SqliteDatabase } from '../sqlite/sqlite-driver.js';
 import { type LoopRelease, type LoopReleaseInput, type LoopReleaseLifecycleStatus } from './loop-release-types.js';
 /**
  * Thin service wrapper around the loop_release store. M1 keeps the
@@ -7,7 +7,7 @@ import { type LoopRelease, type LoopReleaseInput, type LoopReleaseLifecycleStatu
  * deliberately deferred to M2 / M4 / M5 — shipping them here would
  * lock in an interface that the ratchet has not yet ratified.
  *
- * The constructor takes an open better-sqlite3 database (the existing
+ * The constructor takes an open SQLite database (the existing
  * `peaks state` boundary) so callers do not have to thread a path
  * through this layer; this matches the `retainRelease` pattern in
  * `src/services/skillhub/release-retain.ts`.
@@ -18,7 +18,7 @@ import { type LoopRelease, type LoopReleaseInput, type LoopReleaseLifecycleStatu
  */
 export declare class LoopReleaseService {
     private readonly db;
-    constructor(db: Database.Database);
+    constructor(db: SqliteDatabase);
     /**
      * Persist a new LoopRelease row. Re-validates the input via the
      * Zod schema; throws ZodError on failure.

package/dist/services/loop/loop-release-service.js

@@ -7,7 +7,7 @@ import { ensureLoopReleaseTable, insertLoopRelease, getLoopRelease, listLoopRele
  * deliberately deferred to M2 / M4 / M5 — shipping them here would
  * lock in an interface that the ratchet has not yet ratified.
  *
- * The constructor takes an open better-sqlite3 database (the existing
+ * The constructor takes an open SQLite database (the existing
  * `peaks state` boundary) so callers do not have to thread a path
  * through this layer; this matches the `retainRelease` pattern in
  * `src/services/skillhub/release-retain.ts`.

package/dist/services/loop/loop-release-store.d.ts

@@ -1,4 +1,4 @@
-import type Database from 'better-sqlite3';
+import type { SqliteDatabase } from '../sqlite/sqlite-driver.js';
 import type { LoopRelease, LoopReleaseLifecycleStatus } from './loop-release-types.js';
 /**
  * Low-level SQLite access for the `loop_release` table. The
@@ -17,7 +17,6 @@ import type { LoopRelease, LoopReleaseLifecycleStatus } from './loop-release-typ
  *     INDEX IF NOT EXISTS) so re-running it is safe.
  *   - The M3 migration (`004-loop-bee-extension.sql`) is non-breaking:
  *     it only adds new columns with DEFAULTs and does NOT touch any
- *     pre-existing column on `bee_release` (AC-3).
  */
 /**
  * Re-apply the loop_release table migration against an already-open
@@ -31,7 +30,7 @@ import type { LoopRelease, LoopReleaseLifecycleStatus } from './loop-release-typ
  * the columns will exist; for a freshly-built DB via this helper the
  * columns are baked in. Either way the schema converges.
  */
-export declare function ensureLoopReleaseTable(db: Database.Database): void;
+export declare function ensureLoopReleaseTable(db: SqliteDatabase): void;
 /**
  * Insert a LoopRelease row. The row's `schema_version` is taken from
  * the input (must equal `peaks.loop/1`); `archived_at` is stamped
@@ -41,15 +40,15 @@ export declare function ensureLoopReleaseTable(db: Database.Database): void;
  * same id throws a UNIQUE-constraint error; callers wanting upsert
  * semantics should use a separate path (M5 / crystallization event).
  */
-export declare function insertLoopRelease(db: Database.Database, row: LoopRelease): void;
+export declare function insertLoopRelease(db: SqliteDatabase, row: LoopRelease): void;
 /** Read a single LoopRelease row by id; returns undefined if absent. */
-export declare function getLoopRelease(db: Database.Database, id: string): LoopRelease | undefined;
+export declare function getLoopRelease(db: SqliteDatabase, id: string): LoopRelease | undefined;
 /** List LoopRelease rows filtered by lifecycle_status. */
-export declare function listLoopReleasesByStatus(db: Database.Database, status: LoopReleaseLifecycleStatus): LoopRelease[];
+export declare function listLoopReleasesByStatus(db: SqliteDatabase, status: LoopReleaseLifecycleStatus): LoopRelease[];
 /**
  * Search LoopRelease rows whose `scenario` contains the query string.
  * M1 uses a case-insensitive LIKE; FTS5 promotion is deferred. The
  * query is treated as a literal substring (no regex, no SQL
  * injection surface) — it is escaped via parameter binding.
  */
-export declare function searchLoopReleasesByScenario(db: Database.Database, query: string): LoopRelease[];
+export declare function searchLoopReleasesByScenario(db: SqliteDatabase, query: string): LoopRelease[];

package/dist/services/loop/loop-release-store.js

@@ -15,7 +15,6 @@
  *     INDEX IF NOT EXISTS) so re-running it is safe.
  *   - The M3 migration (`004-loop-bee-extension.sql`) is non-breaking:
  *     it only adds new columns with DEFAULTs and does NOT touch any
- *     pre-existing column on `bee_release` (AC-3).
  */
 /**
  * Re-apply the loop_release table migration against an already-open

package/dist/services/loop/monotonic-guard.d.ts

@@ -22,7 +22,6 @@ export declare function toScoreRow(evaluator: string, gateAction: 'pass' | 'warn
 export declare const DEFAULT_MONOTONIC_THRESHOLD = 0.05;
 /** Compare `previous` against `current` and report monotonicity.
  *
- *  Rules (reflected in `tests/unit/loop/monotonic-guard.test.ts`):
  *    - missing previous cycle → skip (`MONOTONIC_NO_PREVIOUS`)
  *    - evaluators not present in both cycles → skip that evaluator
  *    - score unchanged / up → ok

package/dist/services/loop/monotonic-guard.js

@@ -50,7 +50,6 @@ export function toScoreRow(evaluator, gateAction, degraded, observedAtIso = new
 export const DEFAULT_MONOTONIC_THRESHOLD = 0.05;
 /** Compare `previous` against `current` and report monotonicity.
  *
- *  Rules (reflected in `tests/unit/loop/monotonic-guard.test.ts`):
  *    - missing previous cycle → skip (`MONOTONIC_NO_PREVIOUS`)
  *    - evaluators not present in both cycles → skip that evaluator
  *    - score unchanged / up → ok

package/dist/services/mcp/cli-executor.d.ts

@@ -0,0 +1,36 @@
+/** Ceiling on one CLI execution. Generous for a read, far short of "forever". */
+export declare const DEFAULT_EXECUTION_TIMEOUT_MS = 15000;
+/** How to start this tree's own CLI. */
+export interface CliLaunch {
+    readonly command: string;
+    readonly argsPrefix: readonly string[];
+}
+/**
+ * Resolve the platform-neutral launch shape. Uses the shared daemon-supervisor
+ * resolvers rather than a second copy of them: the entry path and the
+ * TypeScript-loader flags have to agree with every other self-spawn in this
+ * tree, and the file that owns them says so in as many words.
+ */
+export declare function resolveCliLaunch(): CliLaunch;
+export interface CliExecution {
+    /** The concrete argv that was handed to the CLI, without the launch prefix. */
+    readonly argv: readonly string[];
+    /** Exit status, or `null` when the process died on a signal or was killed. */
+    readonly exitCode: number | null;
+    readonly stdout: string;
+    readonly stderr: string;
+    /** True when the deadline fired and the child was killed. */
+    readonly timedOut: boolean;
+    /** Set ONLY when the process could not be started at all. Never set on timeout. */
+    readonly launchError?: string;
+}
+export interface ExecuteOptions {
+    readonly launch?: CliLaunch;
+    readonly timeoutMs?: number;
+    readonly cwd?: string;
+}
+/**
+ * Run one argv. Always resolves: a failure is a described outcome, never a
+ * rejection, because the caller has to report it to the harness either way.
+ */
+export declare function executeCliArgv(argv: readonly string[], options?: ExecuteOptions): Promise<CliExecution>;

package/dist/services/mcp/cli-executor.js

@@ -0,0 +1,97 @@
+// src/services/mcp/cli-executor.ts
+//
+// The one place the MCP server touches the outside world: it runs a concrete
+// argv against the peaks CLI and hands back what happened.
+//
+// THREE RULES, EACH MEASURED INTO THE SHAPE BELOW.
+//
+// 1. NO SHELL, NO PLATFORM BRANCH (spec §8.2). The launch is
+//    `node <this tree's CLI entry>` — `process.execPath` plus the argument list
+//    that makes this Node interpret that entry. Naming the CLI as a command
+//    (`peaks`) is measurably wrong on a platform whose CLI is a batch shim:
+//    Node refuses to spawn `.cmd`/`.bat` without a shell, and with a shell the
+//    argv array stops being an argv array. `process.execPath` needs neither, so
+//    one shape serves every platform and no `if (platform)` exists.
+//
+// 2. THE TIMEOUT IS MANDATORY, NOT OPTIONAL. `peaks job status --watch` never
+//    returns. It is outside the read-only surface, but it proves the class: a
+//    server that waits forever on a hung child gives its caller no recovery
+//    path. A timeout therefore returns a NAMED failure, never an empty success
+//    (spec §7.2 + §9 rule 3).
+//
+// 3. THE CHILD GETS NO STDIN. Our stdin is the JSON-RPC transport; a child that
+//    inherited it would read our protocol stream and answer the harness itself.
+import { spawn } from 'node:child_process';
+import { readonlySpawnOptions } from '../readonly-surface/argv-guard.js';
+import { cliEntryPath, interpreterArgs } from '../web/daemon-supervisor.js';
+/** Ceiling on one CLI execution. Generous for a read, far short of "forever". */
+export const DEFAULT_EXECUTION_TIMEOUT_MS = 15_000;
+/**
+ * Resolve the platform-neutral launch shape. Uses the shared daemon-supervisor
+ * resolvers rather than a second copy of them: the entry path and the
+ * TypeScript-loader flags have to agree with every other self-spawn in this
+ * tree, and the file that owns them says so in as many words.
+ */
+export function resolveCliLaunch() {
+    return { command: process.execPath, argsPrefix: interpreterArgs(cliEntryPath()) };
+}
+/** The spawn + drain half: one child, one settlement, whatever happens to it. */
+function runChild(launch, argv, cwd, timeoutMs) {
+    return new Promise((resolve) => {
+        let stdout = '';
+        let stderr = '';
+        let timedOut = false;
+        let settled = false;
+        let launchError;
+        const child = spawn(launch.command, [...launch.argsPrefix, ...argv], {
+            ...readonlySpawnOptions(),
+            cwd,
+            // stdin must stay ours; stdout/stderr are read as data.
+            stdio: ['ignore', 'pipe', 'pipe'],
+            // Windows contract: a spawned child must not allocate a console window.
+            windowsHide: true
+        });
+        const deadline = setTimeout(() => {
+            timedOut = true;
+            child.kill();
+        }, timeoutMs);
+        const settle = (exitCode) => {
+            if (settled)
+                return;
+            settled = true;
+            clearTimeout(deadline);
+            const outcome = { argv, exitCode, stdout, stderr, timedOut };
+            resolve(launchError === undefined ? outcome : { ...outcome, launchError });
+        };
+        child.stdout.setEncoding('utf8');
+        child.stdout.on('data', (chunk) => {
+            stdout += chunk;
+        });
+        child.stderr.setEncoding('utf8');
+        child.stderr.on('data', (chunk) => {
+            stderr += chunk;
+        });
+        child.on('error', (error) => {
+            launchError = error.message;
+        });
+        // `close` (not `exit`) so both pipes are drained before we read them.
+        child.on('close', (code) => {
+            settle(code);
+        });
+    });
+}
+/**
+ * Run one argv. Always resolves: a failure is a described outcome, never a
+ * rejection, because the caller has to report it to the harness either way.
+ */
+export async function executeCliArgv(argv, options = {}) {
+    let launch;
+    try {
+        launch = options.launch ?? resolveCliLaunch();
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : String(error);
+        return { argv, exitCode: null, stdout: '', stderr: '', timedOut: false, launchError: message };
+    }
+    return runChild(launch, argv, options.cwd ?? process.cwd(), options.timeoutMs ?? DEFAULT_EXECUTION_TIMEOUT_MS);
+}