@sema-agent/server 7.9.0 → 7.11.0

package/dist/plugins/tidb-pool.js

@@ -1,5 +1,7 @@
 import mysql from "mysql2/promise";
 import { TIDB_APPROVAL_ASK_STATEMENTS } from "./approval-ask-store-sql.js";
+import { TIDB_ADOPTION_LOG_STATEMENTS } from "./adoption-log-sql.js";
+import { TIDB_PERMISSION_RULE_STATEMENTS } from "./permission-rule-store-sql.js";
 /**
  * Shared TiDB (MySQL wire-compatible) connection pool for the durable Session center (L1).
  * Owned by `main.ts`; closed on shutdown.
@@ -233,8 +235,8 @@ export const SCHEMA_STATEMENTS = [
      checkpoint   JSON         NOT NULL,
      outcome      JSON         NULL,
      deadline     BIGINT       NULL,
-     created_at   BIGINT       NOT NULL,
-     decided_at   BIGINT       NULL,
+     created_at_ms BIGINT      NOT NULL,
+     decided_at_ms BIGINT      NULL,
      -- rev (design/80 D-1): monotonic optimistic-concurrency counter bumped on every resolve/reopen, so a
      -- resolve(expect) requires the rev the resume observed to still be live → fail-closed on a concurrent
      -- resolve-reopen cycle (core → checkpoint.reopened_concurrently).
@@ -244,10 +246,10 @@ export const SCHEMA_STATEMENTS = [
      -- tool_unavailable (a fresh decision is allowed). Drives core's reopen-revote validation.
      -- NULL = NEVER REOPENED (the first resume is unconstrained).
      reopen_reason VARCHAR(32)  NULL,
-     -- terminal_at: crash-safe ABSOLUTE lifetime backstop (design/80 §3 inv#3), distinct from the per-approval
+     -- terminal_at_ms: crash-safe ABSOLUTE lifetime backstop (design/80 §3 inv#3), distinct from the per-approval
      -- deadline, stamped at put(). NULL on PRE-MIGRATION rows — those keep their DEADLINE-BASED expiry (the old
      -- path); the backstop only covers rows suspended after the column existed.
-     terminal_at  BIGINT       NULL,
+     terminal_at_ms BIGINT     NULL,
      -- gate_kind (design/80 D-D, SLA-timer): the CheckpointGate.kind, stamped at put(), so the SLA sweep splits by
      -- kind WITHOUT parsing the JSON blob per row — human/irreversible_ask past deadline are resolve-DENIED (the
      -- model continues with a denial), resource_limit/needs_review are abandonment-TTL → expire().
@@ -430,7 +432,7 @@ export const SCHEMA_STATEMENTS = [
      source_run_id VARCHAR(191) NOT NULL,
      scope         VARCHAR(190) NOT NULL,
      new_run_id    VARCHAR(191) NOT NULL,
-     claimed_at    BIGINT       NOT NULL,
+     claimed_at_ms BIGINT       NOT NULL,
      PRIMARY KEY (source_run_id, scope)
    ) COLLATE utf8mb4_bin`,
     // P1 (fleet failover, 2026-07-05): durable cross-replica WorkflowRunStore twin — one row per run, the full
@@ -443,7 +445,7 @@ export const SCHEMA_STATEMENTS = [
      run           MEDIUMTEXT   NOT NULL,
      rev           INT          NOT NULL DEFAULT 0,
      created_at_ms BIGINT       NOT NULL,
-     ended_at      BIGINT       NULL,
+     ended_at_ms   BIGINT       NULL,
      PRIMARY KEY (id),
      KEY idx_wfrun_scope_created (scope, created_at_ms),
      KEY idx_wfrun_scope_status (scope, status)
@@ -494,8 +496,8 @@ export const SCHEMA_STATEMENTS = [
      acked          TINYINT(1)   NOT NULL DEFAULT 0,
      source_task_id VARCHAR(191) NULL,
      principal      VARCHAR(190) NULL,
-     created_at     BIGINT       NOT NULL,
-     acked_at       BIGINT       NULL,
+     created_at_ms  BIGINT       NOT NULL,
+     acked_at_ms    BIGINT       NULL,
      PRIMARY KEY (run_id),
      KEY idx_wfnotify_acked (acked)
    ) COLLATE utf8mb4_bin`,
@@ -648,6 +650,51 @@ export const SCHEMA_STATEMENTS = [
     // 跟着中央 `ensureSchema` 在 **named-lock 的那条 conn** 上建 —— 把 pool 级 ensure 函数塞进执行循环
     // 会绕开 DDL 串行化。挂进来同时也是「这张表算生产 schema」的声明(基线导出按定义只收录被执行的语句)。
     ...TIDB_APPROVAL_ASK_STATEMENTS,
+    // design/177 shared-memory store(#192 单数纪律)—— org 盘的三张表。消费面 = shared-memory-store-sql.ts。
+    // 🔴 与 `agent_memory_engine_*`(design/138 本地记忆链)**零关系**:不 join、不共享 scope 登记、不互写
+    // (设计 182 §13)。两族同库不同面,合表/建视图会让 harvest 的私人笔记漏进团队库。
+    `CREATE TABLE IF NOT EXISTS shared_memory_scope (
+     -- 一个 org scope 一行。行缺席 = 该 org 从未开通 ⇒ 语义等价于 connected 且零 store(不是故障)。
+     scope_key     VARCHAR(190) NOT NULL,
+     -- 闭集词:connecting|unavailable|connected。读出时走 planeStateOf 的穷举 switch,未知词整拒快照。
+     state         VARCHAR(16)  NOT NULL,
+     -- host 自述原因,仅 unavailable 有意义;core 折成一行喂模型面。
+     message       VARCHAR(512) NULL,
+     updated_at_ms BIGINT       NOT NULL,
+     PRIMARY KEY (scope_key)
+   ) COLLATE utf8mb4_bin`,
+    `CREATE TABLE IF NOT EXISTS shared_memory_store (
+     -- 模型面把手,**全局唯一**:同 id 在两个 org 各一份会在跨 org 成员的快照里撞名,而 core 对撞名 id
+     -- 的处置是整行丢弃 —— 那是一次静默的库消失,所以用 PK 在库层堵死。
+     store_id      VARCHAR(64)  NOT NULL,
+     scope_key     VARCHAR(190) NOT NULL,
+     description   VARCHAR(512) NOT NULL,
+     -- 治理面结论,原样转达;core 对它零动作(模型面根本没有写通道)。
+     writable      TINYINT(1)   NOT NULL DEFAULT 0,
+     updated_at_ms BIGINT       NOT NULL,
+     PRIMARY KEY (store_id),
+     KEY idx_shared_memory_store_scope (scope_key, store_id)
+   ) COLLATE utf8mb4_bin`,
+    `CREATE TABLE IF NOT EXISTS shared_memory_entry (
+     store_id       VARCHAR(64)  NOT NULL,
+     -- 绝对路径。PK 即 keyset 分页索引:WHERE store_id = ? AND path > ? ORDER BY path。
+     path           VARCHAR(512) NOT NULL,
+     content        LONGTEXT     NOT NULL,
+     -- ISO 8601 原文逐字回放(core 只渲染匹配的 YYYY-MM-DD 前缀)。数值毫秒列是下面那根,两者不同义。
+     updated_at_iso VARCHAR(64)  NULL,
+     size_bytes     INT          NOT NULL,
+     updated_at_ms  BIGINT       NOT NULL,
+     PRIMARY KEY (store_id, path)
+   ) COLLATE utf8mb4_bin`,
+    // design/183 form b(纯身份重绑)的 **SQL 收编日志**。真源 = adoption-log-sql.ts 的
+    // `TIDB_ADOPTION_LOG_STATEMENTS`(与 PG twin 并排);展开进来的理由与 approval-ask 同款:
+    // 跟着中央 ensureSchema 在 named-lock 的那条 conn 上建,不绕开 DDL 串行化。
+    // 🔴 它**必须**与被迁的行同库(183 I2):phase 真源住别处 ⇒ 发起 host 被摧毁时与半迁移状态分家。
+    ...TIDB_ADOPTION_LOG_STATEMENTS,
+    // #154 车二(core 5.18.0 design/179 + 5.22.0 design/182)持久化权限规则店的三张表。真源 =
+    // permission-rule-store-sql.ts 的 `TIDB_PERMISSION_RULE_STATEMENTS`(与 PG twin 并排);展开进这个
+    // 数组的理由与上面那族逐字相同(named-lock 的那条 conn + 「这张表算生产 schema」的声明)。
+    ...TIDB_PERMISSION_RULE_STATEMENTS,
 ];
 /** Named MySQL/TiDB advisory lock that serializes the whole `ensureSchema` DDL run (see below). */
 export const ENSURE_SCHEMA_LOCK = "sema_ensure_schema";

package/dist/plugins/workflow-journal-store-sql.d.ts

@@ -41,7 +41,7 @@ import { type SqlDriver } from "./sql-driver.js";
 /** Dual-dialect durable WorkflowJournalStore. See the file header for the dialect-delta ledger. */
 /** RB-242 租约旋钮。TTL 只是**崩溃兜底**(engine 终态 finally 显式释放;[1981]/[1984] 两层分工:
  *  engine 崩了没释放 ⇒ 陈旧 claim 可被接管)。
- *  🔴 缺省 1h,与 core file 参考实现同值([1984] :284)——**租约无心跳**(claimed_at 在授予时刻定格,
+ *  🔴 缺省 1h,与 core file 参考实现同值([1984] :284)——**租约无心跳**(claimed_at_ms 在授予时刻定格,
  *  运行期间不刷新),所以 TTL 必须盖过最长合法 run 时长:取小了(我初版 15min)会在一次 >TTL 的活跑
  *  中把 claim 判陈旧、放另一副本进来接管——恰是本缝要防的双跑。要更短的接管等待,先给 engine 半场
  *  加心跳刷新,再谈调小。 */
@@ -89,8 +89,8 @@ export declare class SqlWorkflowJournalStore implements WorkflowJournalStore {
      *  语义(bake-store `idem_key UNIQUE` 先例):PK (source_run_id, scope) 上的原子赢或观察。四步,每步
      *  单语句原子,并发交叉在任一步都收敛到「恰一个持有者」:
      *   ① 抢空位:INSERT..DO NOTHING / ON DUP KEY 无操作 —— affected=1 即赢;
-     *   ② 同持有者幂等重入(engine 重试同一 resume):按 (键, new_run_id) 守卫的 claimed_at 刷新;
-     *   ③ TTL 崩溃兜底接管:claimed_at < now-ttl 守卫下的原子改持有者(engine 终态会显式释放,
+     *   ② 同持有者幂等重入(engine 重试同一 resume):按 (键, new_run_id) 守卫的 claimed_at_ms 刷新;
+     *   ③ TTL 崩溃兜底接管:claimed_at_ms < now-ttl 守卫下的原子改持有者(engine 终态会显式释放,
      *     走到这步=上一持有 engine 崩了没释放;两层分工见 SqlWorkflowJournalStoreOptions 注);
      *   ④ 都没赢 ⇒ 读在位者返 {granted:false, holder}(holder 进 engine 的拒绝文案供归因)。 */
     resumeClaim(input: {

package/dist/plugins/workflow-journal-store-sql.js

@@ -76,8 +76,8 @@ export class SqlWorkflowJournalStore {
      *  语义(bake-store `idem_key UNIQUE` 先例):PK (source_run_id, scope) 上的原子赢或观察。四步,每步
      *  单语句原子,并发交叉在任一步都收敛到「恰一个持有者」:
      *   ① 抢空位:INSERT..DO NOTHING / ON DUP KEY 无操作 —— affected=1 即赢;
-     *   ② 同持有者幂等重入(engine 重试同一 resume):按 (键, new_run_id) 守卫的 claimed_at 刷新;
-     *   ③ TTL 崩溃兜底接管:claimed_at < now-ttl 守卫下的原子改持有者(engine 终态会显式释放,
+     *   ② 同持有者幂等重入(engine 重试同一 resume):按 (键, new_run_id) 守卫的 claimed_at_ms 刷新;
+     *   ③ TTL 崩溃兜底接管:claimed_at_ms < now-ttl 守卫下的原子改持有者(engine 终态会显式释放,
      *     走到这步=上一持有 engine 崩了没释放;两层分工见 SqlWorkflowJournalStoreOptions 注);
      *   ④ 都没赢 ⇒ 读在位者返 {granted:false, holder}(holder 进 engine 的拒绝文案供归因)。 */
     async resumeClaim(input) {
@@ -85,20 +85,20 @@ export class SqlWorkflowJournalStore {
         const ins = await this.db.query(this.q(
         // INSERT IGNORE(非 ON DUP KEY 无操作形):TiDB 对「无变化的 DUP KEY UPDATE」affected 报 1
         // (MySQL 报 0)——真双库跑出来的方言差;IGNORE 形两家都在冲突时报 0。
-        "INSERT IGNORE INTO workflow_resume_claim (source_run_id, scope, new_run_id, claimed_at) VALUES (?, ?, ?, ?)", "INSERT INTO workflow_resume_claim (source_run_id, scope, new_run_id, claimed_at) VALUES ($1, $2, $3, $4) ON CONFLICT (source_run_id, scope) DO NOTHING"), [input.sourceRunId, input.scope, input.newRunId, now]);
+        "INSERT IGNORE INTO workflow_resume_claim (source_run_id, scope, new_run_id, claimed_at_ms) VALUES (?, ?, ?, ?)", "INSERT INTO workflow_resume_claim (source_run_id, scope, new_run_id, claimed_at_ms) VALUES ($1, $2, $3, $4) ON CONFLICT (source_run_id, scope) DO NOTHING"), [input.sourceRunId, input.scope, input.newRunId, now]);
         if (ins.affected === 1)
             return { granted: true };
-        const refresh = await this.db.query(this.q("UPDATE workflow_resume_claim SET claimed_at = ? WHERE source_run_id = ? AND scope = ? AND new_run_id = ?", "UPDATE workflow_resume_claim SET claimed_at = $1 WHERE source_run_id = $2 AND scope = $3 AND new_run_id = $4"), [now, input.sourceRunId, input.scope, input.newRunId]);
+        const refresh = await this.db.query(this.q("UPDATE workflow_resume_claim SET claimed_at_ms = ? WHERE source_run_id = ? AND scope = ? AND new_run_id = ?", "UPDATE workflow_resume_claim SET claimed_at_ms = $1 WHERE source_run_id = $2 AND scope = $3 AND new_run_id = $4"), [now, input.sourceRunId, input.scope, input.newRunId]);
         if (refresh.affected >= 1)
             return { granted: true };
-        const takeover = await this.db.query(this.q("UPDATE workflow_resume_claim SET new_run_id = ?, claimed_at = ? WHERE source_run_id = ? AND scope = ? AND claimed_at < ?", "UPDATE workflow_resume_claim SET new_run_id = $1, claimed_at = $2 WHERE source_run_id = $3 AND scope = $4 AND claimed_at < $5"), [input.newRunId, now, input.sourceRunId, input.scope, now - this.resumeClaimTtlMs]);
+        const takeover = await this.db.query(this.q("UPDATE workflow_resume_claim SET new_run_id = ?, claimed_at_ms = ? WHERE source_run_id = ? AND scope = ? AND claimed_at_ms < ?", "UPDATE workflow_resume_claim SET new_run_id = $1, claimed_at_ms = $2 WHERE source_run_id = $3 AND scope = $4 AND claimed_at_ms < $5"), [input.newRunId, now, input.sourceRunId, input.scope, now - this.resumeClaimTtlMs]);
         if (takeover.affected >= 1)
             return { granted: true };
         const holder = await this.db.query(this.q("SELECT new_run_id FROM workflow_resume_claim WHERE source_run_id = ? AND scope = ?", "SELECT new_run_id FROM workflow_resume_claim WHERE source_run_id = $1 AND scope = $2"), [input.sourceRunId, input.scope]);
         // 行在①-③间被释放的窄窗:holder 读空 ⇒ 如实返 denied 无 holder(engine 下一次重试会在①赢)。
         const row = holder.rows[0];
         const holderId = row?.new_run_id === undefined ? undefined : String(row.new_run_id);
-        // ②的 UPDATE 在 MySQL 缺省协议下只数**被改变**的行——同毫秒重入(claimed_at 未变)会 affected=0
+        // ②的 UPDATE 在 MySQL 缺省协议下只数**被改变**的行——同毫秒重入(claimed_at_ms 未变)会 affected=0
         // 掉到这里;持有者==自己仍是 granted(幂等重入语义不依赖 affected 的方言细节)。
         if (holderId === input.newRunId)
             return { granted: true };

package/dist/plugins/workflow-run-store-sql.d.ts

@@ -12,7 +12,7 @@
  *
  * ## WorkflowRunStore twin
  * One row per run: the full `WorkflowRun` as a JSON blob + EXTRACTED columns for everything SQL needs to
- * index/filter (scope, status, created_at_ms, ended_at) + an authoritative `rev` column (the OCC key — the
+ * index/filter (scope, status, created_at_ms, ended_at_ms) + an authoritative `rev` column (the OCC key — the
  * blob's own `rev` is OVERLAID from the column on every read, so writes never have to know the bumped value
  * up front). `update` is a single-statement CAS (`WHERE id AND scope [AND rev]`, `SET rev = rev + 1`);
  * `listByScope` projects через core's SHARED `summarizeWorkflowRun` (anti-drift — identical to InMemory/File).

package/dist/plugins/workflow-run-store-sql.js

@@ -46,7 +46,7 @@ export class SqlWorkflowRunStore {
     async put(id, run) {
         const stored = { ...run, id, rev: run.rev ?? 0 }; // key authoritative + observed-rev base (InMemory parity)
         try {
-            await this.db.query(this.q("INSERT INTO workflow_run (id, scope, status, run, rev, created_at_ms, ended_at) VALUES (?,?,?,?,?,?,?)", "INSERT INTO workflow_run (id, scope, status, run, rev, created_at_ms, ended_at) VALUES ($1,$2,$3,$4,$5,$6,$7)"), [id, run.scope, run.status, JSON.stringify(stored), stored.rev, run.createdAt, run.endedAt ?? null]);
+            await this.db.query(this.q("INSERT INTO workflow_run (id, scope, status, run, rev, created_at_ms, ended_at_ms) VALUES (?,?,?,?,?,?,?)", "INSERT INTO workflow_run (id, scope, status, run, rev, created_at_ms, ended_at_ms) VALUES ($1,$2,$3,$4,$5,$6,$7)"), [id, run.scope, run.status, JSON.stringify(stored), stored.rev, run.createdAt, run.endedAt ?? null]);
         }
         catch (e) {
             // create-once error every backend throws (contract) — dup-key classification is dialect-specific:
@@ -83,7 +83,7 @@ export class SqlWorkflowRunStore {
                 return false; // even the skeleton is oversize — keep the prior revision
             blob = slim;
         }
-        const res = await this.db.query(this.q(`UPDATE workflow_run SET run = ?, rev = rev + 1, status = ?, ended_at = ? WHERE id = ? AND scope = ?${expect !== undefined ? " AND rev = ?" : ""}`, `UPDATE workflow_run SET run = $1, rev = rev + 1, status = $2, ended_at = $3 WHERE id = $4 AND scope = $5${expect !== undefined ? " AND rev = $6" : ""}`), expect !== undefined
+        const res = await this.db.query(this.q(`UPDATE workflow_run SET run = ?, rev = rev + 1, status = ?, ended_at_ms = ? WHERE id = ? AND scope = ?${expect !== undefined ? " AND rev = ?" : ""}`, `UPDATE workflow_run SET run = $1, rev = rev + 1, status = $2, ended_at_ms = $3 WHERE id = $4 AND scope = $5${expect !== undefined ? " AND rev = $6" : ""}`), expect !== undefined
             ? [blob, run.status, run.endedAt ?? null, id, scope, expect.rev]
             : [blob, run.status, run.endedAt ?? null, id, scope]);
         return res.affected === 1; // rev always bumps → affected is a faithful CAS verdict
@@ -156,12 +156,12 @@ export class SqlWorkflowRunStore {
             return 0; // retention is always explicit
         // Cheap columns only; terminal-set + keep-N semantics computed in JS to match InMemory EXACTLY
         // (isTerminalWorkflowStatus is core's — no status list duplicated into SQL).
-        const { rows } = await this.db.query(this.q("SELECT id, status, created_at_ms, ended_at FROM workflow_run WHERE scope = ? ORDER BY created_at_ms DESC, id DESC", "SELECT id, status, created_at_ms, ended_at FROM workflow_run WHERE scope = $1 ORDER BY created_at_ms DESC, id DESC"), [scope]);
+        const { rows } = await this.db.query(this.q("SELECT id, status, created_at_ms, ended_at_ms FROM workflow_run WHERE scope = ? ORDER BY created_at_ms DESC, id DESC", "SELECT id, status, created_at_ms, ended_at_ms FROM workflow_run WHERE scope = $1 ORDER BY created_at_ms DESC, id DESC"), [scope]);
         const terminal = rows.filter((r) => isTerminalWorkflowStatus(String(r.status)));
         const doomed = [];
         for (let i = 0; i < terminal.length; i++) {
             const r = terminal[i];
-            const anchor = r.ended_at != null ? Number(r.ended_at) : Number(r.created_at_ms);
+            const anchor = r.ended_at_ms != null ? Number(r.ended_at_ms) : Number(r.created_at_ms);
             const tooOld = opts.maxAgeMs !== undefined && anchor < now - opts.maxAgeMs;
             const overKeep = opts.keep !== undefined && i >= opts.keep;
             if (tooOld || overKeep)
@@ -311,31 +311,31 @@ export class SqlWorkflowNotifyJournalStore {
     async record(input) {
         // Idempotent-on-runId (a second record for the same run — incl. an acked one — is a no-op): TiDB
         // `INSERT IGNORE` vs PG `ON CONFLICT (run_id) DO NOTHING`.
-        await this.db.query(this.q("INSERT IGNORE INTO workflow_notify_journal (run_id, scope, acked, source_task_id, principal, created_at) VALUES (?,?,0,?,?,?)", "INSERT INTO workflow_notify_journal (run_id, scope, acked, source_task_id, principal, created_at) VALUES ($1,$2,0,$3,$4,$5) ON CONFLICT (run_id) DO NOTHING"), [input.runId, input.scope, input.sourceTaskId ?? null, input.principal ?? null, input.createdAt]);
+        await this.db.query(this.q("INSERT IGNORE INTO workflow_notify_journal (run_id, scope, acked, source_task_id, principal, created_at_ms) VALUES (?,?,0,?,?,?)", "INSERT INTO workflow_notify_journal (run_id, scope, acked, source_task_id, principal, created_at_ms) VALUES ($1,$2,0,$3,$4,$5) ON CONFLICT (run_id) DO NOTHING"), [input.runId, input.scope, input.sourceTaskId ?? null, input.principal ?? null, input.createdAt]);
     }
     async ack(runId, ackedAt) {
-        await this.db.query(this.q("UPDATE workflow_notify_journal SET acked = 1, acked_at = ? WHERE run_id = ? AND acked = 0", "UPDATE workflow_notify_journal SET acked = 1, acked_at = $1 WHERE run_id = $2 AND acked = 0"), [ackedAt, runId]);
+        await this.db.query(this.q("UPDATE workflow_notify_journal SET acked = 1, acked_at_ms = ? WHERE run_id = ? AND acked = 0", "UPDATE workflow_notify_journal SET acked = 1, acked_at_ms = $1 WHERE run_id = $2 AND acked = 0"), [ackedAt, runId]);
     }
     async listPending() {
-        const { rows } = await this.db.query("SELECT run_id, scope, source_task_id, principal, created_at FROM workflow_notify_journal WHERE acked = 0");
+        const { rows } = await this.db.query("SELECT run_id, scope, source_task_id, principal, created_at_ms FROM workflow_notify_journal WHERE acked = 0");
         return rows.map((r) => ({
             runId: String(r.run_id),
             scope: String(r.scope),
             acked: false,
             ...(r.source_task_id != null ? { sourceTaskId: String(r.source_task_id) } : {}),
             ...(r.principal != null ? { principal: String(r.principal) } : {}),
-            createdAt: Number(r.created_at),
+            createdAt: Number(r.created_at_ms),
         }));
     }
     /** Retention (same sweep as reapAllScopes): ACKED rows are pure history — without this the twin re-opens
      *  the unbounded-growth hole the same release closed for workflow_run. Pending rows are NEVER reaped (they
      *  are the recovery backlog; the orphan-grace sweep is what retires a stuck pending run). */
     async reapAcked(before) {
-        const res = await this.db.query(this.q("DELETE FROM workflow_notify_journal WHERE acked = 1 AND acked_at < ?", "DELETE FROM workflow_notify_journal WHERE acked = 1 AND acked_at < $1"), [before]);
+        const res = await this.db.query(this.q("DELETE FROM workflow_notify_journal WHERE acked = 1 AND acked_at_ms < ?", "DELETE FROM workflow_notify_journal WHERE acked = 1 AND acked_at_ms < $1"), [before]);
         return res.affected;
     }
     async get(runId) {
-        const { rows } = await this.db.query(this.q("SELECT run_id, scope, acked, source_task_id, principal, created_at, acked_at FROM workflow_notify_journal WHERE run_id = ?", "SELECT run_id, scope, acked, source_task_id, principal, created_at, acked_at FROM workflow_notify_journal WHERE run_id = $1"), [runId]);
+        const { rows } = await this.db.query(this.q("SELECT run_id, scope, acked, source_task_id, principal, created_at_ms, acked_at_ms FROM workflow_notify_journal WHERE run_id = ?", "SELECT run_id, scope, acked, source_task_id, principal, created_at_ms, acked_at_ms FROM workflow_notify_journal WHERE run_id = $1"), [runId]);
         const r = rows[0];
         if (!r)
             return null;
@@ -345,8 +345,8 @@ export class SqlWorkflowNotifyJournalStore {
             acked: Number(r.acked) === 1,
             ...(r.source_task_id != null ? { sourceTaskId: String(r.source_task_id) } : {}),
             ...(r.principal != null ? { principal: String(r.principal) } : {}),
-            createdAt: Number(r.created_at),
-            ...(r.acked_at != null ? { ackedAt: Number(r.acked_at) } : {}),
+            createdAt: Number(r.created_at_ms),
+            ...(r.acked_at_ms != null ? { ackedAt: Number(r.acked_at_ms) } : {}),
         };
     }
 }

package/dist/rules-consent.d.ts

@@ -0,0 +1,126 @@
+import { type ImportPreview, type ImportResult, type ImportedSettingsLayer, type RuleScope } from "@sema-agent/core";
+import type { PermissionRuleStoreProvider, RuleApprovalRecordStore } from "@sema-agent/core";
+import { type RuleImportTicket, type RuleTicketRedeemResult } from "./plugins/permission-rule-store-sql.js";
+/**
+ * 本车道**真正**依赖的三面(**结构**接口,不是 SQL 类)。
+ *
+ * 🔴 为什么不直接吃 `PermissionRuleStores`(SQL 束):同意车道是**纯协议逻辑**,它对「行躺在 MySQL 还是
+ * PG 还是别处」一无所知也不该知道。吃结构接口有两个真收益:①单元测试能用 core 自己的
+ * `InMemoryPermissionRuleStore` / `InMemoryRuleApprovalRecordStore` 驱动**同一段**代码(而不是为了测协议
+ * 去拉一个数据库);②将来若真出了 File 形规则店,本文件一个字不用改。SQL 束结构上满足本接口。
+ */
+export interface RuleConsentStores {
+    provider: PermissionRuleStoreProvider;
+    /** core 的记录店面 + 一个**可选**的加项:`discardPendingRecord`(超帽拒绝时收掉 `prepareCcImport`
+     *  已经落盘的那一条 pending 记录)。没有这个加项的后端只是留一条孤儿行,不影响任何判决
+     *  (语义与「已确认的记录永不被收」的硬条款见 SQL 侧同名方法)。 */
+    approvals: RuleApprovalRecordStore & {
+        discardPendingRecord?(recordId: string): Promise<boolean>;
+    };
+    tickets: {
+        mint(input: {
+            ticketId: string;
+            principal: string;
+            approvalId: string;
+            candidates: ReadonlyArray<{
+                rule: string;
+                scope: RuleScope;
+            }>;
+            ttlMs: number;
+        }): Promise<RuleImportTicket>;
+        /** 一次**认领**(不是「已完成」)。语义与「认领之后怎么办」见 {@link RuleConsentStores.tickets.release}。 */
+        consume(ticketId: string, principal: string): Promise<RuleTicketRedeemResult>;
+        /** 把认领**放回去**(认领之后遇到不确定/瞬时失败时)。`mustRemainValidMs` = 放回之后这张票至少还要
+         *  能用多久 —— 撑不过就**不算放回成功**(理由逐字见 store 侧 `release` 的头注)。 */
+        release(ticketId: string, principal: string, mustRemainValidMs?: number): Promise<boolean>;
+    };
+}
+/** 导入票的存活窗。人从「看到预览」到「按下确认」是一次交互,不是一段会话——十分钟宽到不会误伤,
+ *  窄到一张泄漏的票不会常驻。运维旋钮暂不开(没有部署形要求它可调;要开时走 config.ts 的既有姿势)。 */
+export declare const RULE_IMPORT_TICKET_TTL_MS: number;
+/** 可重试那一支通告给客户端的等待秒数(`state.rule_import_retry` 的 `retryAfterSec` / `Retry-After`)。
+ *  短 —— 它对应的是一次瞬时 store 抖动,不是排队。**单一真源在本文件**:放回认领时要用它判「这张票
+ *  还能不能撑过这段窗」,HTTP 层要用它填响应,两处用同一个数才谈得上「承诺兑得出来」。 */
+export declare const RULE_IMPORT_RETRY_AFTER_SEC = 2;
+/**
+ * **全部层合计**的候选上限(codex 交叉复审 round7 [high] 二,验真后修)。
+ *
+ * 单层 16 KiB 只管住了**请求体**,管不住**下游工作量**:紧凑的合法规则(`Bash(ls)` 十个字符)能让三层
+ * 塞进上千条候选,而 core 的 `redeemRuleBatch` 是**逐候选**跑一遍「读店 + CAS 写」的串行循环 —— 一个
+ * 已鉴权的请求就能把连接池占满、把响应撑到兆字节。全局限流器默认是关的,拦不住它(一次准入就够了)。
+ *
+ * 帽数的是 **core 已经解析好的候选**(不是我们自己再数一遍 JSON):零重复解析,而且数的正好是那条串行
+ * 循环的**真实**长度。位置在**铸票之前** —— 超限就没有票,那条昂贵的循环一次都跑不起来(代价只剩一条
+ * 已铸的 pending 记录,与任何一次没去兑付的 prepare 留下的残余同形)。
+ * 200 的取值:一份人手写的 CC settings 极少超过几十条;200 给了一个数量级的余量,又把最坏工作量钉在
+ * 「几百次 SQL」而不是「几万次」。
+ */
+export declare const MAX_IMPORT_CANDIDATES = 200;
+/** 一次导入 prepare 的产物(HTTP 200 体的素材),或**超帽**的拒绝(见 {@link MAX_IMPORT_CANDIDATES})。 */
+export type RuleImportPrepared = {
+    ok: true;
+    preview: ImportPreview;
+    ticket: string;
+    expiresAtMs: number;
+} | {
+    ok: false;
+    reason: "too-many-candidates";
+    candidates: number;
+};
+/** 导入 redeem 的结果。`refused` 的四个成因**在 wire 面折成同一个 404**(见顶注 ①)——这里保留分类
+ *  只为服务端日志/诊断。 */
+export type RuleImportRedeemed = {
+    ok: true;
+    result: ImportResult;
+}
+/** `retryable` = 这次失败**没有裁定任何事**(store 抛错 / CAS 冲突),认领已放回,属主原样重试即可。
+ *  它与裁定性拒绝(载荷被篡改、记录不存在)分家是承重的:把两者塌成一格,一次数据库抖动就会被
+ *  客户端读成「这张票永远不能用了」。⚠️ **wire 面仍然折成同一个 404**(零存在性 oracle 不因此松动);
+ *  这一位只进服务端日志与本层的重试判据。 */
+ | {
+    ok: false;
+    reason: "ticket-unusable" | "record-unusable" | "payload-mismatch";
+    detail: string;
+    retryable?: true;
+};
+/** 卡道兑付的结果。 */
+export type CardRulePersisted = {
+    ok: true;
+    rule: string;
+    rev: number;
+    alreadyRedeemed: boolean;
+} | {
+    ok: false;
+    reason: "no-candidates" | "unknown-candidate" | "confirm-refused" | "redeem-refused";
+    detail: string;
+};
+/** 一层用户交上来的 settings(HTTP 载荷已 zod 校验过的形)。 */
+export interface RuleImportLayerInput {
+    layer: ImportedSettingsLayer;
+    path: string;
+    root: string;
+    content: string;
+}
+export interface RuleConsentLane {
+    /** 卡道兑付口:一次 ask 决议携规则确认 ⇒ prepare→confirm→redeem 一气呵成。 */
+    persistCardRule(input: {
+        principal: string;
+        toolName: string;
+        /** 被裁决的命令**原字节**(与 ask 上的那份同源;规则文本由引擎从它铸,调用方不供文本)。 */
+        command: string;
+        /** 客户端选中的候选**文本**——用来在引擎铸出的候选表里定位下标。文本对不上 ⇒ 拒(不猜)。 */
+        ruleText: string;
+        toolCallId?: string;
+        boundInputHash?: string;
+        scope?: RuleScope;
+    }): Promise<CardRulePersisted>;
+    /** 导入道:读层 → 预览 + pending 记录 + 票。 */
+    prepareImport(principal: string, layers: readonly RuleImportLayerInput[]): Promise<RuleImportPrepared>;
+    /** 导入道:原子消费票 → confirm → redeemRuleBatch。 */
+    redeemImport(principal: string, ticket: string): Promise<RuleImportRedeemed>;
+}
+export declare function createRuleConsentLane(stores: RuleConsentStores, opts?: {
+    ticketTtlMs?: number;
+    newTicketId?: () => string;
+}): RuleConsentLane;
+//# sourceMappingURL=rules-consent.d.ts.map

package/dist/rules-consent.js

@@ -0,0 +1,198 @@
+/**
+ * #154 车二 —— **同意车道的 server 半场**(core 5.18.0 design/179 `permission-rule-consent.ts` 的宿主侧)。
+ *
+ * core 把一条规则进店的路钉成三步:`durable approval record (pending)` → `authenticated confirmation
+ * transfer (approved)` → `principal-bound redemption (redeemed)`,而且**只有第三步**够得着写面。core 明写
+ * 「The confirmation transfer is an in-process call. **A deployment must reach it only from its
+ * authenticated approval channel**」—— 那句话是把一段责任**交给宿主**,不是一段已经完成的检查。本文件就是
+ * 那段责任的落点:
+ *
+ *  · 卡道(兑付口):一次 ask 决议携「不再询问」时,由**这里**去 prepare→confirm→redeem。人是谁 =
+ *    回决端点已验明的 principal(不是请求体里的任何字段);规则文本 = **引擎**从被裁决的命令铸的候选
+ *    (`prepareCardApproval` 不收调用方候选,core 在那条入口上已经把「写自己的规则」这件事变成不可拼写),
+ *    客户端只能说「我选第几个」。
+ *
+ *  · 导入道(CC settings):`prepare` 读用户交上来的 settings 层、铸 pending 记录 + **server 自铸的票**;
+ *    `redeem` 原子消费票、confirm、`redeemRuleBatch`。
+ *
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ * 🔴 票的信任边界四条,**全部是 server 附加的**(不是 core 的语义)
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ * 亲读 core 的 `mintRuleTicket`(dist,5.22.0):`return \`rt.${candidateIndex}.${recordId}\`` —— 它**没有**
+ * TTL、没有签名、没有消费位、没有载荷绑定。core 的票在**进程内**是够的(它的相邻语义是「重放同一次兑付是
+ * 幂等的」),但一条跨网络、由客户端保管、可被复制的票需要另外四样:
+ *   ① **principal 绑定** —— redeem 的已验明 principal 必须 = prepare 铸票的那一位。跨 principal redeem 与
+ *      unknown ticket **同形 404**:两者返回不同的码就是一台存在性 oracle(拿别人的票撞库能探到「它存在」)。
+ *   ② **过期** —— `RULE_IMPORT_TICKET_TTL_MS`;过期 redeem 拒。
+ *   ③ **一次性原子消费** —— 同票二次 redeem 拒,并发双 redeem **恰一成功**。判据由 SQL 的单条条件
+ *      `UPDATE … WHERE consumed_at_ms IS NULL` 回答,**禁 read-then-write**(见 store 那侧的 🔴 注)。
+ *   ④ **载荷绑定** —— redeem 应用的规则集 = prepare 时刻的快照。core 已经结构上保证了「规则文本来自记录」,
+ *      本层再加一道:票上钉着 prepare 时刻候选集的摘要,redeem 时与记录上的候选集重算比对,不符即拒 ——
+ *      于是「篡改记录再拿旧票兑付」这条路上多一道等式,而不是只靠「记录只有我们能写」这一条信念。
+ *
+ * 命名(CLAUDE.md 工厂律):`build*` = 纯数据;`create*` = 活对象。本文件的 {@link createRuleConsentLane}
+ * 返回一个带方法的束 ⇒ `create*`。
+ */
+import { randomUUID } from "node:crypto";
+import { recordFailOpen } from "./observability/fail-open.js";
+import { confirmRuleApproval, prepareCardApproval, prepareCcImport, redeemRuleBatch, redeemRuleTicket, } from "@sema-agent/core";
+import { buildRulePayloadHash } from "./plugins/permission-rule-store-sql.js";
+/** 导入票的存活窗。人从「看到预览」到「按下确认」是一次交互,不是一段会话——十分钟宽到不会误伤,
+ *  窄到一张泄漏的票不会常驻。运维旋钮暂不开(没有部署形要求它可调;要开时走 config.ts 的既有姿势)。 */
+export const RULE_IMPORT_TICKET_TTL_MS = 10 * 60_000;
+/** 可重试那一支通告给客户端的等待秒数(`state.rule_import_retry` 的 `retryAfterSec` / `Retry-After`)。
+ *  短 —— 它对应的是一次瞬时 store 抖动,不是排队。**单一真源在本文件**:放回认领时要用它判「这张票
+ *  还能不能撑过这段窗」,HTTP 层要用它填响应,两处用同一个数才谈得上「承诺兑得出来」。 */
+export const RULE_IMPORT_RETRY_AFTER_SEC = 2;
+/**
+ * **全部层合计**的候选上限(codex 交叉复审 round7 [high] 二,验真后修)。
+ *
+ * 单层 16 KiB 只管住了**请求体**,管不住**下游工作量**:紧凑的合法规则(`Bash(ls)` 十个字符)能让三层
+ * 塞进上千条候选,而 core 的 `redeemRuleBatch` 是**逐候选**跑一遍「读店 + CAS 写」的串行循环 —— 一个
+ * 已鉴权的请求就能把连接池占满、把响应撑到兆字节。全局限流器默认是关的,拦不住它(一次准入就够了)。
+ *
+ * 帽数的是 **core 已经解析好的候选**(不是我们自己再数一遍 JSON):零重复解析,而且数的正好是那条串行
+ * 循环的**真实**长度。位置在**铸票之前** —— 超限就没有票,那条昂贵的循环一次都跑不起来(代价只剩一条
+ * 已铸的 pending 记录,与任何一次没去兑付的 prepare 留下的残余同形)。
+ * 200 的取值:一份人手写的 CC settings 极少超过几十条;200 给了一个数量级的余量,又把最坏工作量钉在
+ * 「几百次 SQL」而不是「几万次」。
+ */
+export const MAX_IMPORT_CANDIDATES = 200;
+export function createRuleConsentLane(stores, opts) {
+    const deps = { provider: stores.provider, approvals: stores.approvals };
+    const ticketTtlMs = opts?.ticketTtlMs ?? RULE_IMPORT_TICKET_TTL_MS;
+    const newTicketId = opts?.newTicketId ?? (() => randomUUID());
+    return {
+        async persistCardRule(input) {
+            // 🔴 候选**由引擎铸**(core `prepareCardApproval` 不收调用方候选;那条入口上「写自己的规则」
+            // 结构上不可拼写)。本层只把「人选了哪一个」翻译成下标。
+            const prepared = await prepareCardApproval({
+                principal: input.principal,
+                toolName: input.toolName,
+                command: input.command,
+                ...(input.toolCallId !== undefined ? { toolCallId: input.toolCallId } : {}),
+                ...(input.boundInputHash !== undefined ? { boundInputHash: input.boundInputHash } : {}),
+                ...(input.scope !== undefined ? { scope: input.scope } : {}),
+                deps,
+            });
+            if (prepared === undefined) {
+                return { ok: false, reason: "no-candidates", detail: "the rule lane cannot speak for this command (compound / redirection / unsupported tool)" };
+            }
+            const index = prepared.candidates.findIndex((c) => c.rule === input.ruleText);
+            const ticket = index < 0 ? undefined : prepared.tickets[index];
+            if (index < 0 || ticket === undefined) {
+                return { ok: false, reason: "unknown-candidate", detail: "the chosen rule text is not one the engine minted for this command" };
+            }
+            const confirmed = await confirmRuleApproval({ approvalId: prepared.approvalId, principal: input.principal, selectedCandidate: index, deps });
+            if (!confirmed.ok)
+                return { ok: false, reason: "confirm-refused", detail: confirmed.reason };
+            const redeemed = await redeemRuleTicket({ ticket, principal: input.principal, deps });
+            if (redeemed.status !== "redeemed")
+                return { ok: false, reason: "redeem-refused", detail: redeemed.reason };
+            return { ok: true, rule: redeemed.rule, rev: redeemed.rev, alreadyRedeemed: redeemed.alreadyRedeemed };
+        },
+        async prepareImport(principal, layers) {
+            // core 的 `CcImportLayer.readFile` 是一条**注入的**读口 —— 云端部署没有用户的文件系统,内容由
+            // 调用方交上来(这是本仓的部署形,不是绕过:读的仍然只是 allow 桶,拒/问桶是收紧方向、另有通道)。
+            const ccLayers = layers.map((l) => ({
+                layer: l.layer,
+                path: l.path,
+                root: l.root,
+                readFile: async () => l.content,
+            }));
+            const { preview, approvalId } = await prepareCcImport({ layers: ccLayers, principal, deps });
+            // 帽在**铸票之前**(见 {@link MAX_IMPORT_CANDIDATES}):没有票 ⇒ 那条逐候选的串行 SQL 循环跑不起来。
+            if (preview.candidates.length > MAX_IMPORT_CANDIDATES) {
+                // core 在**返回预览之前**就把 pending 记录落了盘 ⇒ 这次不做的导入会留一条永远没人要的行。
+                // 收掉它(codex round8 [medium]:被拒的 prepare 不该在共享库里长东西)。best-effort:收不掉
+                // 也只是留一条 pending 孤儿,不影响任何判决 —— 但**绝不**因此把 413 变成 500。
+                try {
+                    await stores.approvals.discardPendingRecord?.(approvalId);
+                }
+                catch (err) {
+                    recordFailOpen("server.rules.rejected-prepare-row-left", err instanceof Error ? err.message : String(err));
+                }
+                return { ok: false, reason: "too-many-candidates", candidates: preview.candidates.length };
+            }
+            const minted = await stores.tickets.mint({ ticketId: newTicketId(), principal, approvalId, candidates: preview.candidates, ttlMs: ticketTtlMs });
+            return { ok: true, preview, ticket: minted.ticketId, expiresAtMs: minted.expiresAtMs };
+        },
+        async redeemImport(principal, ticket) {
+            // ①②③ 一次原子**认领**同时回答(principal 绑定 / 未过期 / 未认领);四类拒绝在 wire 面同形。
+            const consumed = await stores.tickets.consume(ticket, principal);
+            if (!consumed.ok)
+                return { ok: false, reason: "ticket-unusable", detail: consumed.reason };
+            // 🔴 codex round1 [high] 一(验真后修):认领**之后**的每一步都可能失败,而旧形把认领当终局 ⇒
+            // 一次 store 抖动就永久烧掉这张票,客户端拿到与「票不存在」同形的 404,重试无门。
+            // 处置:裁定性拒绝(载荷被篡改 / 记录不存在)**留着**认领(重试不改判);不确定/瞬时失败**放回**
+            // 认领并标 `retryable`。放回不打开双兑付的门(认领仍是单持有者),兑付腿本身按 core 的设计幂等。
+            // 🔴 codex 交叉复审 round3 [high] 一(验真后修):返回值是**「认领确实放回去了吗」**,不是 void。
+            // 旧形无条件回 `retryable: true`,而释放本身也可能失败(同一场 store 故障往往两跳一起挂)——
+            // 那就变成对客户端**撒谎**:它拿着一张其实已经烧掉的票去重试,只会收到 404,人的确认永久丢失。
+            // 判据必须是「释放**确认**成功」;没确认就不许承诺重试(如实按不可重试报,四类同形 404)。
+            const releaseClaim = async () => {
+                try {
+                    return await stores.tickets.release(ticket, principal, RULE_IMPORT_RETRY_AFTER_SEC * 1000);
+                }
+                catch (err) {
+                    // 放不回去 = 回到「认领即烧票」的旧形(属主这一轮不能重试,票随 TTL 消失)。**不**把一次
+                    // 已经失败的请求再变成一次抛错;但也**不**静默 —— 登记的 F 类兜底,理由逐字见 tag 词表。
+                    recordFailOpen("server.rules.ticket-claim-release-failed", err instanceof Error ? err.message : String(err));
+                    return false;
+                }
+            };
+            /** 「不确定」那一支的统一收口:**释放确认成功**才承诺可重试。 */
+            const indeterminate = async (detail) => {
+                // 放回之后这张票至少要能撑过我们通告的等待窗 —— 撑不过就不承诺重试(见 store 侧 `release` 头注)。
+                const released = await releaseClaim();
+                return { ok: false, reason: "record-unusable", detail, ...(released ? { retryable: true } : {}) };
+            };
+            try {
+                // ④ 载荷绑定:记录上的候选集必须与铸票时刻的快照同摘要。
+                const record = await stores.approvals.get(consumed.approvalId);
+                if (record === undefined)
+                    return { ok: false, reason: "record-unusable", detail: "the approval record behind this ticket is gone" };
+                if (buildRulePayloadHash(record.candidates) !== consumed.payloadHash) {
+                    return { ok: false, reason: "payload-mismatch", detail: "the approval record's candidates changed after the ticket was minted" };
+                }
+                // 🔴 确认是**一次性状态跃迁**,不是每次兑付都要过的门:重试一张**放回过认领**的票时,记录
+                // 早已不是 `pending` 了(core 的崩溃序:`redeemRuleTicket` 在调用写面**之前**就把记录推到
+                // `redeemed`,所以哪怕一个候选都没落地,状态也已经变了)。对已确认的记录再调一次
+                // `confirmRuleApproval` 会拿到 `not_pending` —— 把它当拒绝就等于「放回了认领却永远兑不动」,
+                // round1/round3/round5 那一串修复到此全部白做。判据用记录**自己的状态**,不是猜错误串。
+                if (record.state === "pending") {
+                    const confirmed = await confirmRuleApproval({ approvalId: consumed.approvalId, principal, deps });
+                    if (!confirmed.ok) {
+                        // `conflict` = CAS 输给了一个并发写者(瞬时);其余是裁定(记录不存在/状态不对)。
+                        if (confirmed.reason === "conflict")
+                            return await indeterminate(confirmed.reason);
+                        return { ok: false, reason: "record-unusable", detail: confirmed.reason };
+                    }
+                }
+                const result = await redeemRuleBatch({ approvalId: consumed.approvalId, principal, deps });
+                if ("status" in result) {
+                    // core 的 refused 里既有裁定也有瞬时(OCC 用尽 / 店读不出来)——分不清就按**可重试**放回:
+                    // 兑付是幂等的,多放一次认领最坏是多跑一遍同样的重放;烧掉一张真票是不可逆的。
+                    return await indeterminate(result.reason);
+                }
+                // 🔴 codex 交叉复审 round5 [high] 二(验真后修):core 的 `redeemRuleBatch` 把**逐候选**的失败
+                // 记在 `skippedAtRedeem` 里,顶层照样返回一个 ImportResult —— 只判顶层 `status` 会把「一半没落地」
+                // 当成功回 200,而认领已经烧掉,那一半再也补不回来。
+                // 为什么这条车道可以把「非空 skippedAtRedeem」一律当**不确定**:候选在 `prepareCcImport` 那一步
+                // 就已经全过了同一个验证器(过不了的进 `preview.skipped`,压根不进记录),所以兑付期的逐候选拒绝
+                // 实际只剩「店读不出/写不进 / OCC 用尽 / 隔离栅栏」这类**瞬时或异常**成因。重放是幂等的
+                // (记录里存着每个候选已铸的 dot),所以放回认领让人重试,代价上界只是再跑一遍同样的重放。
+                // 残留(如实登记):真出现一条**永久**被拒的候选时,客户端会一直拿到 503 直到票到期(10 分钟)——
+                // 有界、且不破坏任何已落地的规则;要更好得让 core 把逐候选拒绝分成瞬时/裁定两类,已列后续件。
+                if (result.skippedAtRedeem.length > 0) {
+                    return await indeterminate(`partial import: ${result.skippedAtRedeem.length} candidate(s) did not land (${result.skippedAtRedeem.map((x) => x.reason).join("; ")})`);
+                }
+                return { ok: true, result };
+            }
+            catch (err) {
+                return await indeterminate(err instanceof Error ? err.message : String(err));
+            }
+        },
+    };
+}
+//# sourceMappingURL=rules-consent.js.map

package/dist/run-local.js

@@ -53,7 +53,7 @@ import { applyEffective, resolveMcpServers, mcpForScenario } from "./config-cent
 import { hostExecutionEnvFactory } from "./plugins/remote-env-host.js";
 import { makeLoadProjectMemory, makeProbeInstructionSources } from "./project-memory.js";
 import { loadSkills } from "./capabilities/skills.js";
-import { GiteaClient } from "./capabilities/repo-tools.js";
+import { createRepoClient } from "./capabilities/repo-tools.js";
 import { webSearchConfigFromEnv, createWebSearchBackend } from "./plugins/web-search.js";
 import { buildScenarios, selectScenario, centerScenarios } from "./capabilities/scenarios.js";
 import { pickHandsRunner, withoutExecutionEnv } from "./capabilities/hands-lane.js";
@@ -539,7 +539,7 @@ export async function runLocal(argv, deps = {}) {
     const handslessSubRunner = new Runner(withoutExecutionEnv(subRunnerDeps));
     // Capability layer (loadSkills + buildScenarios + selectScenario) — assembled exactly like main.ts.
     const skills = loadSkills(config.skillsDir);
-    const repoClient = config.gitApiBaseUrl ? new GiteaClient(config.gitApiBaseUrl, config.gitApiToken) : undefined;
+    const repoClient = config.gitApiBaseUrl ? createRepoClient(config.gitApiKind, config.gitApiBaseUrl, config.gitApiToken) : undefined;
     // systematic-audit: wire the env-configured WebSearch backend (WEB_SEARCH_PROVIDER) exactly like main.ts, so the
     // default scenario's WebSearch tool is assembled on the CLI path too (it was silently never built before).
     const webSearchCfg = webSearchConfigFromEnv();