peaks-loop 3.1.2 → 4.0.0-beta.10

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

@@ -0,0 +1,118 @@
+import { z } from "zod";
+/**
+ * LoopBeeRelation — spec §4.6.
+ *
+ * The loop↔bee coupling row. M2 scope:
+ *   - four roles: main / supporting / candidate / retired.
+ *   - exactly one main per loop (enforced by partial unique index + service).
+ *   - FK to loop_release (TEXT id) and bee_release (INTEGER id).
+ *   - cannot link to a retired loop (enforced in service).
+ *
+ * Out of scope (deferred to later slices):
+ *   - share/desktop fields on the relation itself (none in spec §4.6).
+ *   - evolution evidence references (M4).
+ *
+ * Field semantics — see the spec for full prose. Highlights:
+ *
+ *   - `id` is the autoincrement row id; storage key.
+ *   - `loop_release_id` is the FK to loop_release.id (TEXT).
+ *   - `bee_release_id` is the FK to bee_release.id (INTEGER). Note that
+ *     `bee_release.id` is an autoincrement INTEGER (not bee_name) — this
+ *     matches the existing 4.x schema convention used by bee_manifest,
+ *     bee_segment_ref, bee_file, bee_change.
+ *   - `role` is the four-value union. A loop can have at most one `main`
+ *     row; multiple supporting / candidate / retired rows are allowed.
+ *   - `reason` is an NL string the LLM authors at crystallization time
+ *     (e.g. "primary bee — implements the loop's success_criteria").
+ *   - `created_at` is server-stamped from the system clock; the input
+ *     schema does not let clients supply it (would be a backdate hole).
+ */
+export declare const LoopBeeRelationRoleSchema: z.ZodEnum<["main", "supporting", "candidate", "retired"]>;
+export type LoopBeeRelationRole = z.infer<typeof LoopBeeRelationRoleSchema>;
+export declare const LOOP_BEE_RELATION_ROLES: readonly LoopBeeRelationRole[];
+/**
+ * Zod schema for the create payload (LoopBeeRelationInput).
+ *
+ * `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`).
+ *
+ * `bee_release_id` is a positive integer; matching the
+ * `bee_release.id` autoincrement INTEGER PK.
+ */
+export declare const LoopBeeRelationInputSchema: z.ZodObject<{
+    loop_release_id: z.ZodString;
+    bee_release_id: z.ZodNumber;
+    role: z.ZodEnum<["main", "supporting", "candidate", "retired"]>;
+    reason: z.ZodString;
+}, "strip", z.ZodTypeAny, {
+    role: "main" | "candidate" | "retired" | "supporting";
+    reason: string;
+    bee_release_id: number;
+    loop_release_id: string;
+}, {
+    role: "main" | "candidate" | "retired" | "supporting";
+    reason: string;
+    bee_release_id: number;
+    loop_release_id: string;
+}>;
+export type LoopBeeRelationInput = z.input<typeof LoopBeeRelationInputSchema>;
+/**
+ * Full Zod schema for a LoopBeeRelation row as persisted. Differs from
+ * the input schema only in that `schema_version` is exposed (and
+ * defaulted to the fixed literal). The literal constraint still rejects
+ * any client-supplied value other than `"peaks.loop-bee-relation/1"`;
+ * the default means omitting the key is fine and the output always
+ * carries the constant.
+ *
+ * We expose this as the canonical "row schema" used by service.create /
+ * read paths.
+ */
+export declare const LoopBeeRelationSchema: z.ZodObject<{
+    loop_release_id: z.ZodString;
+    bee_release_id: z.ZodNumber;
+    role: z.ZodEnum<["main", "supporting", "candidate", "retired"]>;
+    reason: z.ZodString;
+} & {
+    id: z.ZodNumber;
+    schema_version: z.ZodDefault<z.ZodLiteral<"peaks.loop-bee-relation/1">>;
+    created_at: z.ZodString;
+}, "strip", z.ZodTypeAny, {
+    schema_version: "peaks.loop-bee-relation/1";
+    role: "main" | "candidate" | "retired" | "supporting";
+    reason: string;
+    id: number;
+    created_at: string;
+    bee_release_id: number;
+    loop_release_id: string;
+}, {
+    role: "main" | "candidate" | "retired" | "supporting";
+    reason: string;
+    id: number;
+    created_at: string;
+    bee_release_id: number;
+    loop_release_id: string;
+    schema_version?: "peaks.loop-bee-relation/1" | undefined;
+}>;
+export type LoopBeeRelation = z.infer<typeof LoopBeeRelationSchema>;
+/**
+ * Convenience: strict-parse an unknown payload into a LoopBeeRelation
+ * row. Throws ZodError on failure. This is the public validation
+ * boundary.
+ */
+export declare function parseLoopBeeRelation(input: unknown): LoopBeeRelation;
+/**
+ * Convenience: safe-parse that returns a Result-like shape so callers
+ * can render findings without try/catch noise.
+ */
+export declare function safeParseLoopBeeRelation(input: unknown): {
+    ok: true;
+    row: LoopBeeRelation;
+} | {
+    ok: false;
+    findings: Array<{
+        path: string;
+        message: string;
+    }>;
+};

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

@@ -0,0 +1,114 @@
+import { z } from "zod";
+/**
+ * LoopBeeRelation — spec §4.6.
+ *
+ * The loop↔bee coupling row. M2 scope:
+ *   - four roles: main / supporting / candidate / retired.
+ *   - exactly one main per loop (enforced by partial unique index + service).
+ *   - FK to loop_release (TEXT id) and bee_release (INTEGER id).
+ *   - cannot link to a retired loop (enforced in service).
+ *
+ * Out of scope (deferred to later slices):
+ *   - share/desktop fields on the relation itself (none in spec §4.6).
+ *   - evolution evidence references (M4).
+ *
+ * Field semantics — see the spec for full prose. Highlights:
+ *
+ *   - `id` is the autoincrement row id; storage key.
+ *   - `loop_release_id` is the FK to loop_release.id (TEXT).
+ *   - `bee_release_id` is the FK to bee_release.id (INTEGER). Note that
+ *     `bee_release.id` is an autoincrement INTEGER (not bee_name) — this
+ *     matches the existing 4.x schema convention used by bee_manifest,
+ *     bee_segment_ref, bee_file, bee_change.
+ *   - `role` is the four-value union. A loop can have at most one `main`
+ *     row; multiple supporting / candidate / retired rows are allowed.
+ *   - `reason` is an NL string the LLM authors at crystallization time
+ *     (e.g. "primary bee — implements the loop's success_criteria").
+ *   - `created_at` is server-stamped from the system clock; the input
+ *     schema does not let clients supply it (would be a backdate hole).
+ */
+export const LoopBeeRelationRoleSchema = z.enum([
+    "main",
+    "supporting",
+    "candidate",
+    "retired",
+]);
+export const LOOP_BEE_RELATION_ROLES = [
+    "main",
+    "supporting",
+    "candidate",
+    "retired",
+];
+/**
+ * Zod schema for the create payload (LoopBeeRelationInput).
+ *
+ * `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`).
+ *
+ * `bee_release_id` is a positive integer; matching the
+ * `bee_release.id` autoincrement INTEGER PK.
+ */
+export const LoopBeeRelationInputSchema = z.object({
+    loop_release_id: z
+        .string()
+        .min(1)
+        .max(64)
+        .regex(/^[a-z][a-z0-9]*(-[a-z0-9]+)*$/, {
+        message: "loop_release_id must be kebab-case starting with a lowercase letter",
+    }),
+    bee_release_id: z
+        .number()
+        .int()
+        .positive()
+        .max(2 ** 31 - 1, "bee_release_id out of 32-bit range"),
+    role: LoopBeeRelationRoleSchema,
+    reason: z
+        .string()
+        .trim()
+        .min(1, "reason is required (LLM-authored NL explanation)")
+        .max(2000),
+});
+/**
+ * Full Zod schema for a LoopBeeRelation row as persisted. Differs from
+ * the input schema only in that `schema_version` is exposed (and
+ * defaulted to the fixed literal). The literal constraint still rejects
+ * any client-supplied value other than `"peaks.loop-bee-relation/1"`;
+ * the default means omitting the key is fine and the output always
+ * carries the constant.
+ *
+ * We expose this as the canonical "row schema" used by service.create /
+ * read paths.
+ */
+export const LoopBeeRelationSchema = LoopBeeRelationInputSchema.extend({
+    id: z.number().int().positive(),
+    schema_version: z
+        .literal("peaks.loop-bee-relation/1")
+        .default("peaks.loop-bee-relation/1"),
+    created_at: z.string().datetime(),
+});
+/**
+ * Convenience: strict-parse an unknown payload into a LoopBeeRelation
+ * row. Throws ZodError on failure. This is the public validation
+ * boundary.
+ */
+export function parseLoopBeeRelation(input) {
+    return LoopBeeRelationSchema.parse(input);
+}
+/**
+ * Convenience: safe-parse that returns a Result-like shape so callers
+ * can render findings without try/catch noise.
+ */
+export function safeParseLoopBeeRelation(input) {
+    const r = LoopBeeRelationSchema.safeParse(input);
+    if (r.success)
+        return { ok: true, row: r.data };
+    return {
+        ok: false,
+        findings: r.error.issues.map((i) => ({
+            path: i.path.join("."),
+            message: i.message,
+        })),
+    };
+}

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

@@ -0,0 +1,46 @@
+import type Database from "better-sqlite3";
+import { type LoopRelease, type LoopReleaseInput, type LoopReleaseLifecycleStatus } from "./loop-release-types.js";
+/**
+ * Thin service wrapper around the loop_release store. M1 keeps the
+ * surface tiny on purpose: create / read / list / search. Promotion,
+ * retirement, evaluation, and the `loop_bee_relation` joins are
+ * 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
+ * `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`.
+ *
+ * All write paths re-validate the input via the Zod schema, mirroring
+ * the boundary-check discipline used elsewhere (e.g.
+ * `lintManifestStrict` in `src/services/sediment/manifest-lint.ts`).
+ */
+export declare class LoopReleaseService {
+    private readonly db;
+    constructor(db: Database.Database);
+    /**
+     * Persist a new LoopRelease row. Re-validates the input via the
+     * Zod schema; throws ZodError on failure.
+     */
+    create(input: LoopReleaseInput): LoopRelease;
+    /** Read a LoopRelease row by id; returns undefined if absent. */
+    read(id: string): LoopRelease | undefined;
+    /**
+     * List LoopRelease rows. Filter by `status` when supplied; without
+     * it, returns ALL rows (across `candidate` / `stable` / `retired`).
+     * Sort is newest-first by `archived_at`.
+     */
+    list(opts?: {
+        status?: LoopReleaseLifecycleStatus;
+    }): LoopRelease[];
+    /**
+     * Search LoopRelease rows whose `scenario` contains the query
+     * string (case-insensitive substring match via LIKE). Filter by
+     * `status` to scope the search.
+     */
+    search(opts: {
+        query: string;
+        status?: LoopReleaseLifecycleStatus;
+    }): LoopRelease[];
+}

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

@@ -0,0 +1,66 @@
+import { LoopReleaseSchema, } from "./loop-release-types.js";
+import { ensureLoopReleaseTable, insertLoopRelease, getLoopRelease, listLoopReleasesByStatus, searchLoopReleasesByScenario, } from "./loop-release-store.js";
+/**
+ * Thin service wrapper around the loop_release store. M1 keeps the
+ * surface tiny on purpose: create / read / list / search. Promotion,
+ * retirement, evaluation, and the `loop_bee_relation` joins are
+ * 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
+ * `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`.
+ *
+ * All write paths re-validate the input via the Zod schema, mirroring
+ * the boundary-check discipline used elsewhere (e.g.
+ * `lintManifestStrict` in `src/services/sediment/manifest-lint.ts`).
+ */
+export class LoopReleaseService {
+    db;
+    constructor(db) {
+        this.db = db;
+        // Idempotent — safe to call on every constructor invocation; the
+        // openStateDb pipeline already applied the SQL migration, but a
+        // caller-built DB (e.g. tests) needs this.
+        ensureLoopReleaseTable(this.db);
+    }
+    /**
+     * Persist a new LoopRelease row. Re-validates the input via the
+     * Zod schema; throws ZodError on failure.
+     */
+    create(input) {
+        const row = LoopReleaseSchema.parse(input);
+        insertLoopRelease(this.db, row);
+        return row;
+    }
+    /** Read a LoopRelease row by id; returns undefined if absent. */
+    read(id) {
+        return getLoopRelease(this.db, id);
+    }
+    /**
+     * List LoopRelease rows. Filter by `status` when supplied; without
+     * it, returns ALL rows (across `candidate` / `stable` / `retired`).
+     * Sort is newest-first by `archived_at`.
+     */
+    list(opts = {}) {
+        if (opts.status)
+            return listLoopReleasesByStatus(this.db, opts.status);
+        const all = ["candidate", "stable", "retired"];
+        const out = [];
+        for (const s of all)
+            out.push(...listLoopReleasesByStatus(this.db, s));
+        return out;
+    }
+    /**
+     * Search LoopRelease rows whose `scenario` contains the query
+     * string (case-insensitive substring match via LIKE). Filter by
+     * `status` to scope the search.
+     */
+    search(opts) {
+        const hits = searchLoopReleasesByScenario(this.db, opts.query);
+        if (!opts.status)
+            return hits;
+        return hits.filter((r) => r.lifecycle_status === opts.status);
+    }
+}

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

@@ -0,0 +1,55 @@
+import type Database from "better-sqlite3";
+import type { LoopRelease, LoopReleaseLifecycleStatus } from "./loop-release-types.js";
+/**
+ * Low-level SQLite access for the `loop_release` table. The
+ * migration is registered with the existing `openStateDb()` pipeline
+ * via `src/services/skillhub/migrations/002-loop-release.sql` and
+ * `004-loop-bee-extension.sql` (it applies every `*.sql` file in
+ * lexicographic order). The function `ensureLoopReleaseTable` below
+ * is a belt-and-suspenders re-applier for callers that pass a
+ * database they built themselves (e.g. tests).
+ *
+ * Defense in depth:
+ *   - All JSON columns are stored as TEXT and parsed at the boundary.
+ *     No big JSON BLOB at the SQLite layer — the row stays small and
+ *     queryable.
+ *   - The migration is idempotent (CREATE TABLE IF NOT EXISTS, CREATE
+ *     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
+ * database. Used by tests that build their own DB without the openStateDb
+ * pipeline. Idempotent.
+ *
+ * M3: the CREATE here now includes the four share / desktop extension
+ * columns from migration 004 (`shareable`, `share_excluded_paths`,
+ * `desktop_visible`, `export_bundle_format`). For an existing M2-era
+ * database, the migration runner will already have applied 004 and
+ * 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;
+/**
+ * Insert a LoopRelease row. The row's `schema_version` is taken from
+ * the input (must equal `peaks.loop/1`); `archived_at` is stamped
+ * from the server clock here, so callers cannot backdate a row.
+ *
+ * Idempotent in the table sense (UNIQUE on `id`) — re-inserting the
+ * 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;
+/** Read a single LoopRelease row by id; returns undefined if absent. */
+export declare function getLoopRelease(db: Database.Database, id: string): LoopRelease | undefined;
+/** List LoopRelease rows filtered by lifecycle_status. */
+export declare function listLoopReleasesByStatus(db: Database.Database, 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[];

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

@@ -0,0 +1,134 @@
+/**
+ * Low-level SQLite access for the `loop_release` table. The
+ * migration is registered with the existing `openStateDb()` pipeline
+ * via `src/services/skillhub/migrations/002-loop-release.sql` and
+ * `004-loop-bee-extension.sql` (it applies every `*.sql` file in
+ * lexicographic order). The function `ensureLoopReleaseTable` below
+ * is a belt-and-suspenders re-applier for callers that pass a
+ * database they built themselves (e.g. tests).
+ *
+ * Defense in depth:
+ *   - All JSON columns are stored as TEXT and parsed at the boundary.
+ *     No big JSON BLOB at the SQLite layer — the row stays small and
+ *     queryable.
+ *   - The migration is idempotent (CREATE TABLE IF NOT EXISTS, CREATE
+ *     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
+ * database. Used by tests that build their own DB without the openStateDb
+ * pipeline. Idempotent.
+ *
+ * M3: the CREATE here now includes the four share / desktop extension
+ * columns from migration 004 (`shareable`, `share_excluded_paths`,
+ * `desktop_visible`, `export_bundle_format`). For an existing M2-era
+ * database, the migration runner will already have applied 004 and
+ * the columns will exist; for a freshly-built DB via this helper the
+ * columns are baked in. Either way the schema converges.
+ */
+export function ensureLoopReleaseTable(db) {
+    db.exec(`
+    CREATE TABLE IF NOT EXISTS loop_release (
+      id                       TEXT PRIMARY KEY,
+      name                     TEXT NOT NULL,
+      scenario                 TEXT NOT NULL,
+      trigger_policy           TEXT NOT NULL,
+      success_criteria_json    TEXT NOT NULL,
+      interaction_policy       TEXT NOT NULL,
+      feedback_policy          TEXT NOT NULL,
+      evolution_policy         TEXT NOT NULL,
+      evaluator_policy_json    TEXT NOT NULL,
+      linked_bees_json         TEXT NOT NULL DEFAULT '[]',
+      run_history_json         TEXT NOT NULL DEFAULT '[]',
+      crystallization_evidence_json TEXT NOT NULL DEFAULT '[]',
+      lifecycle_status         TEXT NOT NULL CHECK (lifecycle_status IN ('candidate','stable','retired')),
+      version                  TEXT NOT NULL,
+      schema_version           TEXT NOT NULL CHECK (schema_version = 'peaks.loop/1'),
+      archived_at              TEXT NOT NULL,
+      shareable                INTEGER NOT NULL DEFAULT 1 CHECK (shareable IN (0, 1)),
+      share_excluded_paths     TEXT NOT NULL DEFAULT '[]',
+      desktop_visible          INTEGER NOT NULL DEFAULT 1 CHECK (desktop_visible IN (0, 1)),
+      export_bundle_format     TEXT NOT NULL DEFAULT 'peaks.bundle/1' CHECK (export_bundle_format = 'peaks.bundle/1')
+    );
+    CREATE INDEX IF NOT EXISTS idx_loop_release_lifecycle_status ON loop_release(lifecycle_status);
+    CREATE INDEX IF NOT EXISTS idx_loop_release_scenario ON loop_release(scenario);
+  `);
+}
+function rowToLoopRelease(row) {
+    return {
+        id: row.id,
+        name: row.name,
+        scenario: row.scenario,
+        trigger_policy: row.trigger_policy,
+        success_criteria: JSON.parse(row.success_criteria_json),
+        interaction_policy: row.interaction_policy,
+        feedback_policy: row.feedback_policy,
+        evolution_policy: row.evolution_policy,
+        evaluator_policy: JSON.parse(row.evaluator_policy_json),
+        linked_bees: JSON.parse(row.linked_bees_json),
+        run_history: JSON.parse(row.run_history_json),
+        crystallization_evidence: JSON.parse(row.crystallization_evidence_json),
+        lifecycle_status: row.lifecycle_status,
+        version: row.version,
+        schema_version: row.schema_version,
+        // M3: coerce the SQLite 0/1 INTEGER convention to JS boolean, and
+        // parse the JSON-encoded path list at the boundary.
+        shareable: row.shareable === 1,
+        share_excluded_paths: JSON.parse(row.share_excluded_paths),
+        desktop_visible: row.desktop_visible === 1,
+        export_bundle_format: row.export_bundle_format,
+    };
+}
+/**
+ * Insert a LoopRelease row. The row's `schema_version` is taken from
+ * the input (must equal `peaks.loop/1`); `archived_at` is stamped
+ * from the server clock here, so callers cannot backdate a row.
+ *
+ * Idempotent in the table sense (UNIQUE on `id`) — re-inserting the
+ * same id throws a UNIQUE-constraint error; callers wanting upsert
+ * semantics should use a separate path (M5 / crystallization event).
+ */
+export function insertLoopRelease(db, row) {
+    const stmt = db.prepare(`INSERT INTO loop_release (
+       id, name, scenario, trigger_policy,
+       success_criteria_json, interaction_policy, feedback_policy, evolution_policy,
+       evaluator_policy_json, linked_bees_json, run_history_json, crystallization_evidence_json,
+       lifecycle_status, version, schema_version, archived_at,
+       shareable, share_excluded_paths, desktop_visible, export_bundle_format
+     ) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)`);
+    stmt.run(row.id, row.name, row.scenario, row.trigger_policy, JSON.stringify(row.success_criteria), row.interaction_policy, row.feedback_policy, row.evolution_policy, JSON.stringify(row.evaluator_policy), JSON.stringify(row.linked_bees), JSON.stringify(row.run_history), JSON.stringify(row.crystallization_evidence), row.lifecycle_status, row.version, row.schema_version, new Date().toISOString(), 
+    // M3: serialize the booleans to the SQLite 0/1 convention.
+    row.shareable ? 1 : 0, JSON.stringify(row.share_excluded_paths), row.desktop_visible ? 1 : 0, row.export_bundle_format);
+}
+/** Read a single LoopRelease row by id; returns undefined if absent. */
+export function getLoopRelease(db, id) {
+    const row = db
+        .prepare("SELECT * FROM loop_release WHERE id = ?")
+        .get(id);
+    if (!row)
+        return undefined;
+    return rowToLoopRelease(row);
+}
+/** List LoopRelease rows filtered by lifecycle_status. */
+export function listLoopReleasesByStatus(db, status) {
+    const rows = db
+        .prepare("SELECT * FROM loop_release WHERE lifecycle_status = ? ORDER BY archived_at DESC, id ASC")
+        .all(status);
+    return rows.map(rowToLoopRelease);
+}
+/**
+ * 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 function searchLoopReleasesByScenario(db, query) {
+    const like = `%${query}%`;
+    const rows = db
+        .prepare("SELECT * FROM loop_release WHERE scenario LIKE ? COLLATE NOCASE ORDER BY archived_at DESC, id ASC")
+        .all(like);
+    return rows.map(rowToLoopRelease);
+}