@sema-agent/server 7.43.0 → 7.44.0

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

@@ -9,83 +9,38 @@ export class SqlWorkflowJournalStore {
         this.db = db;
         this.resumeClaimTtlMs = opts?.resumeClaimTtlMs ?? DEFAULT_RESUME_CLAIM_TTL_MS;
     }
-    /** Pick the dialect's SQL text. Both statements stay written out at the call site ON PURPOSE. */
     q(tidb, pg) {
         return this.db.dialect === "tidb" ? tidb : pg;
     }
-    /** Record one agent's result. Idempotent per (run_id, ordinal): the PK upsert OVERWRITES (last-write-wins), so a
-     *  resumed run re-appending its replayed prefix verbatim leaves no duplicate. callKeyOrdinal is the SOLE ordinal
-     *  source (core's parser — a malformed key collapses to 0, matching InMemory). Throws on a REAL failure
-     *  (LOAD-BEARING), EXCEPT an oversize result is skip-journaled (see below) rather than throwing the workflow dead. */
     async append(runId, scope, entry) {
-        // codex R10 定谳:result 列=TEXT(PG)/MEDIUMTEXT(TiDB),存的是 stringify 输出——NUL/lone surrogate
-        // 在输出里恒为 \uXXXX 六字符**转义形**(纯 ASCII),TEXT 列可精确存取;22P05 只咬 ::jsonb cast。
-        // 故 journal 无需任何 NUL 守卫:直存=逐位回放(R8 skip/R9 invalidate 均为过度修,已撤——那会把
-        // 可精确回放的完成结果作废成不必要的活跑重执行,外部副作用可能重复)。
         const serialized = JSON.stringify(entry.result);
-        // TiDB rejects a row over the ~6 MiB txn-entry-size-limit ("entry too large"); a large agent TaskResult would
-        // make this LOAD-BEARING append THROW + kill the workflow — and the PG twin (no such limit) would NOT, a
-        // dialect divergence. DEGRADE identically on both: skip-journal an oversize result (no-op, never insert/throw)
-        // → its ordinal isn't cached, so a resume re-runs that one agent live (resume is an optimization).
         if (oversizeJournalResult(serialized))
             return;
         await this.db.query(this.q("INSERT INTO workflow_journal (run_id, ordinal, scope, call_key, result, created_at_ms) VALUES (?,?,?,?,?,?) " +
-            // scope NOT in the UPDATE: a re-append keeps the FIRST writer's scope (fail-closed — a re-append must never
-            // reassign tenancy). The owner is the sole writer + runId is unique per scope, so this never fires
-            // cross-scope in practice; the secure choice over matching InMemory's last-write-wins on scope.
             "ON DUPLICATE KEY UPDATE call_key = VALUES(call_key), result = VALUES(result)", "INSERT INTO workflow_journal (run_id, ordinal, scope, call_key, result, created_at_ms) VALUES ($1,$2,$3,$4,$5,$6) " +
             "ON CONFLICT (run_id, ordinal) DO UPDATE SET call_key = EXCLUDED.call_key, result = EXCLUDED.result"), [runId, callKeyOrdinal(entry.callKey), scope, entry.callKey, serialized, Date.now()]);
     }
-    /** Entries for `runId` IF its recorded scope === `scope`, ASCENDING by ordinal; otherwise EMPTY. CORE-9 audit
-     *  BLOCKER: scope in the WHERE (twin of WorkflowRunStore) — the LLM controls `resumeFromRunId`, so a cross-scope
-     *  runId resolves to an empty journal (resume safely diverges to live, never discloses another tenant's results).
-     *  Each row's `result` is the persisted JSON.stringify(TaskResult) → JSON.parse back. Throws on failure (LOAD-BEARING). */
     async load(runId, scope) {
         const { rows } = await this.db.query(this.q("SELECT call_key, result FROM workflow_journal WHERE run_id = ? AND scope = ? ORDER BY ordinal ASC", "SELECT call_key, result FROM workflow_journal WHERE run_id = $1 AND scope = $2 ORDER BY ordinal ASC"), [runId, scope]);
         return rows.map((r) => ({ callKey: String(r.call_key), result: JSON.parse(String(r.result)) }));
     }
-    /** [1412] locator 云形(core 1.353 WorkflowJournalStore.locator additive):SQL 店的 journal 坐标=
-     *  [1402] HTTP 读面路由(file 店返 jsonl 路径=CC 本地形;此处返云形,core 铸 diagnostics 教句时单源引用)。 */
     locator(runId, _scope) {
         return `/v1/workflows/${runId}/journal`;
     }
-    /** codex R1-H2:分页投影读——LIMIT/OFFSET 界行数,字节门界单行字节(超限行不取 result 全文,只回字节数;
-     *  读面标 truncated)。ORDER BY ordinal 与 load 同轴。
-     *  🔴 param ORDER differs by dialect (see file header): TiDB's `?`s bind in text order (maxResultBytes first,
-     *  inside the CASE); PG's `$n` are positional, so its array keeps runId/scope first. Never unify — a swap
-     *  silently mis-binds the OTHER dialect's placeholders. */
     async loadPage(runId, scope, opts) {
         const params = this.db.dialect === "tidb"
             ? [opts.maxResultBytes, runId, scope, opts.limit, opts.offset]
             : [runId, scope, opts.maxResultBytes, opts.limit, opts.offset];
-        const { rows } = await this.db.query(this.q("SELECT call_key, CASE WHEN LENGTH(result) > ? THEN NULL ELSE result END AS result_json, LENGTH(result) AS result_bytes FROM workflow_journal WHERE run_id = ? AND scope = ? ORDER BY ordinal ASC LIMIT ? OFFSET ?", 
-        // codex R3: PG's LENGTH(text) is CHARACTER count (TiDB's LENGTH is byte count) — a multi-byte UTF-8 row
-        // would slip past the byte-budget door on plain LENGTH; OCTET_LENGTH keeps this the byte count PG-side
-        // too (real dual-DB-suite-confirmed anti-drift).
-        "SELECT call_key, CASE WHEN OCTET_LENGTH(result) > $3 THEN NULL ELSE result END AS result_json, OCTET_LENGTH(result) AS result_bytes FROM workflow_journal WHERE run_id = $1 AND scope = $2 ORDER BY ordinal ASC LIMIT $4 OFFSET $5"), params);
+        const { rows } = await this.db.query(this.q("SELECT call_key, CASE WHEN LENGTH(result) > ? THEN NULL ELSE result END AS result_json, LENGTH(result) AS result_bytes FROM workflow_journal WHERE run_id = ? AND scope = ? ORDER BY ordinal ASC LIMIT ? OFFSET ?", "SELECT call_key, CASE WHEN OCTET_LENGTH(result) > $3 THEN NULL ELSE result END AS result_json, OCTET_LENGTH(result) AS result_bytes FROM workflow_journal WHERE run_id = $1 AND scope = $2 ORDER BY ordinal ASC LIMIT $4 OFFSET $5"), params);
         return rows.map((r) => ({ callKey: String(r.call_key), resultJson: r.result_json === null ? null : String(r.result_json), resultBytes: Number(r.result_bytes) }));
     }
-    /** GC — purge ALL journal entries for a run (the run reaper calls this once the run is terminal + retained). Scoped
-     *  by run_id alone; idempotent (affected-row count). Mirrors the resume-anchor store's deleteBySession. */
     async deleteByRun(runId) {
         const res = await this.db.query(this.q("DELETE FROM workflow_journal WHERE run_id = ?", "DELETE FROM workflow_journal WHERE run_id = $1"), [runId]);
         return res.affected;
     }
-    /** RB-242 / WF2([1981] core 拍板 a 形,签名逐字)—— cross-replica resume admission lease。
-     *
-     *  语义(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_ms 刷新;
-     *   ③ TTL 崩溃兜底接管:claimed_at_ms < now-ttl 守卫下的原子改持有者(engine 终态会显式释放,
-     *     走到这步=上一持有 engine 崩了没释放;两层分工见 SqlWorkflowJournalStoreOptions 注);
-     *   ④ 都没赢 ⇒ 读在位者返 {granted:false, holder}(holder 进 engine 的拒绝文案供归因)。 */
     async resumeClaim(input) {
         const now = Date.now();
-        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_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]);
+        const ins = await this.db.query(this.q("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_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]);
@@ -95,36 +50,25 @@ export class SqlWorkflowJournalStore {
         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_ms 未变)会 affected=0
-        // 掉到这里;持有者==自己仍是 granted(幂等重入语义不依赖 affected 的方言细节)。
         if (holderId === input.newRunId)
             return { granted: true };
         return { granted: false, holder: holderId };
     }
-    /** 只有 holder 能释放(new_run_id 守卫)—— engine 在 newRunId 终态/放弃时调;非 holder 调用=no-op。 */
     async releaseResumeClaim(input) {
         await this.db.query(this.q("DELETE FROM workflow_resume_claim WHERE source_run_id = ? AND scope = ? AND new_run_id = ?", "DELETE FROM workflow_resume_claim WHERE source_run_id = $1 AND scope = $2 AND new_run_id = $3"), [input.sourceRunId, input.scope, input.newRunId]);
     }
-    /** GC — time-based sweep: purge journal entries older than `maxAgeMs` (created_at_ms < now - maxAgeMs). The
-     *  per-run deleteByRun has no production caller (a run-store reap gives no per-run hook), so this bounded sweep
-     *  — wired into the service reaper — is what keeps the heaviest table (TaskResult-bearing) from growing without
-     *  bound. A resume of a journal older than the retention window simply re-runs live (resume is an optimization).
-     *  Idempotent; returns the rows purged. */
     async reapExpired(now, maxAgeMs) {
         const res = await this.db.query(this.q("DELETE FROM workflow_journal WHERE created_at_ms < ?", "DELETE FROM workflow_journal WHERE created_at_ms < $1"), [now - maxAgeMs]);
         return res.affected;
     }
 }
-/** MySQL-protocol (TiDB) binding — historical class name + ctor shape preserved. */
 export class TiDBWorkflowJournalStore extends SqlWorkflowJournalStore {
     constructor(pool, opts) {
         super(mysqlDriver(pool), opts);
     }
 }
-/** PostgreSQL binding — historical class name + ctor shape preserved. */
 export class PgWorkflowJournalStore extends SqlWorkflowJournalStore {
     constructor(pool, opts) {
         super(pgDriver(pool), opts);

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

@@ -2,19 +2,8 @@ import { summarizeWorkflowRun, isTerminalWorkflowStatus, WorkflowRunStoreError }
 import { foldKeyFamily, MAX_PENDING_PER_SESSION, PURGE_FENCE_MS, SERVED_FENCE_MS, } from "../orchestration/workflow-completion-inbox.js";
 import { mysqlDriver, pgDriver } from "./sql-driver.js";
 import { isDupKeyError } from "./sql-errors.js";
-/** Row cap guard: a run blob beyond this is NOT stored on update (the prior revision stays) — TiDB's
- *  ~6 MiB txn-entry limit would otherwise throw the (best-effort) progress write into the workflow loop.
- *  `put` (create, small) still throws on a real failure. Mirrors the journal's oversize skip-degrade. */
 export const MAX_RUN_BLOB_BYTES = 4 * 1024 * 1024;
 const onWarnType = (msg, meta) => void [msg, meta];
-/** Review fix (1.108, lens④ HIGH): an oversize blob must NOT fail the update outright — core's persist chain
- *  treats `false` as a CAS loss and does NOT advance its tracked rev, so once a run outgrows the cap EVERY later
- *  write (including the TERMINAL one) keeps failing → the durable row is stuck `running` forever and the 24h
- *  orphan sweep finalizes a genuinely-completed run as `abandoned`. Instead degrade the PAYLOAD, not the write:
- *  step 1 truncate the two unbounded strings (result/error); step 2 drop the heavy arrays (phases/agents/groups)
- *  with an explicit marker. Returns null only when even the skeleton is oversize (physics — caller keeps the
- *  prior revision, matching the old behavior for that corner). Dialect-neutral (pure JS, no SQL) — shared
- *  verbatim by both twins. */
 export function slimOversizeRun(run, maxBytes) {
     const MARK = "…[truncated: run blob exceeded the store cap]";
     const cut = (s) => s.slice(0, 4000) + MARK;
@@ -30,9 +19,6 @@ export function slimOversizeRun(run, maxBytes) {
     blob = JSON.stringify(step2);
     return Buffer.byteLength(blob) <= maxBytes ? blob : null;
 }
-/** Dual-dialect durable `WorkflowRunStore`. See the file header for the dialect-delta ledger.
- *  `onWarn` (optional, same shape as the completion-inbox's {@link InboxWarn}) is the C5 trace channel for
- *  `update`'s oversize-slim degrade (see there) — omit it and construction/behavior is unchanged (additive). */
 export class SqlWorkflowRunStore {
     db;
     onWarn;
@@ -40,18 +26,15 @@ export class SqlWorkflowRunStore {
         this.db = db;
         this.onWarn = onWarn;
     }
-    /** Pick the dialect's SQL text. Both statements stay written out at the call site ON PURPOSE. */
     q(tidb, pg) {
         return this.db.dialect === "tidb" ? tidb : pg;
     }
     async put(id, run) {
-        const stored = { ...run, id, rev: run.rev ?? 0 }; // key authoritative + observed-rev base (InMemory parity)
+        const stored = { ...run, id, rev: run.rev ?? 0 };
         try {
             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) — the dialect classification has a single
-            // owner (`sql-errors.ts`, A-032 P1-①); the old local form read only mysql2's string `code`.
             if (isDupKeyError(this.db.dialect, e)) {
                 throw new WorkflowRunStoreError("workflow_run.already_exists", "workflow run id already exists");
             }
@@ -64,36 +47,24 @@ export class SqlWorkflowRunStore {
         if (!r)
             return null;
         const run = JSON.parse(String(r.run));
-        run.rev = Number(r.rev); // the COLUMN is the OCC authority — overlay it (the blob's rev may predate a CAS bump)
+        run.rev = Number(r.rev);
         return run;
     }
     async update(id, scope, run, expect) {
-        // id/scope immutable in the stored payload (InMemory parity: key + partition are authoritative). The blob's
-        // rev is NOT trusted (see get's overlay) — write it as-is; the column bump below is the real OCC state.
         let blob = JSON.stringify({ ...run, id, scope });
         if (Buffer.byteLength(blob) > MAX_RUN_BLOB_BYTES) {
-            // Oversize degrade (1.108 review fix): slim the payload so the write — critically the TERMINAL one —
-            // still lands (a `false` here would never be retried with a smaller payload; see slimOversizeRun).
-            // C5 (2026-07-31): the degrade drops real data (phases/agents/groups → []) — that must leave a trace
-            // reaching whoever can act on it, not just a same-shaped `true` return. `onWarn` is optional so a
-            // caller that hasn't wired a sink yet keeps building/running unchanged.
             this.onWarn?.("workflow_run_blob_oversize_slimmed", { id, scope, fullBytes: Buffer.byteLength(blob), capBytes: MAX_RUN_BLOB_BYTES });
             const slim = slimOversizeRun({ ...run, id, scope }, MAX_RUN_BLOB_BYTES);
             if (slim === null)
-                return false; // even the skeleton is oversize — keep the prior revision
+                return false;
             blob = slim;
         }
         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
+        return res.affected === 1;
     }
     async listByScope(scope, opts) {
-        // 🔴 genuinely-divergent CONSTRUCTION (not just SQL text): PG's `$n` placeholders are POSITIONAL and must
-        // track `params.length` as each optional clause is appended, while TiDB's `?` is positionless — a single
-        // `q()` pair can't express that, so the where/limit assembly forks per dialect. The FILTER logic itself
-        // (status → session → limit, session dropping unmatched/absent-key rows via JSON extraction, limit applied
-        // last) is identical; only the placeholder bookkeeping differs.
         const params = [scope];
         let where;
         let limit = "";
@@ -104,9 +75,6 @@ export class SqlWorkflowRunStore {
                 params.push(opts.status);
             }
             if (opts?.session !== undefined) {
-                // core 1.368([1516]②)session 下推臂:limit 前应用、严格等值、无字段行剔除(JSON path 缺席 →
-                // NULL → `= ?` 恒假 ✓)。JSON 提取而非投影列:对存量行零迁移直接生效;行量有 retention 界,
-                // 与本函数固有的全行 JSON.parse 同量级。
                 where += " AND JSON_UNQUOTE(JSON_EXTRACT(run, '$.originatingSessionId')) = ?";
                 params.push(opts.session);
             }
@@ -122,7 +90,6 @@ export class SqlWorkflowRunStore {
                 where += ` AND status = $${params.length}`;
             }
             if (opts?.session !== undefined) {
-                // core 1.368([1516]②)session 下推臂(TiDB twin 同案注释):JSON 提取、limit 前、缺席键 → NULL → 拒 ✓
                 params.push(opts.session);
                 where += ` AND run::json->>'originatingSessionId' = $${params.length}`;
             }
@@ -131,7 +98,6 @@ export class SqlWorkflowRunStore {
                 limit = ` LIMIT $${params.length}`;
             }
         }
-        // Sort in SQL (newest first), summarize via core's SHARED projection (anti-drift).
         const { rows } = await this.db.query(`SELECT run, rev FROM workflow_run WHERE ${where} ORDER BY created_at_ms DESC, id DESC${limit}`, params);
         return rows.map((r) => {
             const run = JSON.parse(String(r.run));
@@ -139,11 +105,6 @@ export class SqlWorkflowRunStore {
             return summarizeWorkflowRun(run);
         });
     }
-    /** Retention (the store never auto-purges; reap is explicit): the contract's `reap` is scope-keyed and the
-     *  contract deliberately has NO cross-scope enumeration — but the SQL twin CAN enumerate (DISTINCT on the
-     *  extracted scope column), which is exactly what a periodic deployment sweep needs. Walks every scope through
-     *  the contract-faithful `reap` (terminal-only; running rows are the orphan-grace sweep's business). Service
-     *  extension, not a contract member. Byte-identical text on both dialects (no params) — no q() needed. */
     async reapAllScopes(now, opts) {
         const { rows } = await this.db.query("SELECT DISTINCT scope FROM workflow_run");
         let total = 0;
@@ -153,9 +114,7 @@ export class SqlWorkflowRunStore {
     }
     async reap(scope, now, opts) {
         if (opts?.maxAgeMs === undefined && opts?.keep === undefined)
-            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).
+            return 0;
         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 = [];
@@ -169,16 +128,12 @@ export class SqlWorkflowRunStore {
         }
         if (doomed.length === 0)
             return 0;
-        // Bulk delete-by-id-set: TiDB expands a dynamic `IN (?,?,…)` (one placeholder per id, spread params);
-        // PG binds the whole set as one array via `= ANY($2::text[])`. Same result set, different statement shape.
         const res = await this.db.query(this.q(`DELETE FROM workflow_run WHERE scope = ? AND id IN (${doomed.map(() => "?").join(",")})`, "DELETE FROM workflow_run WHERE scope = $1 AND id = ANY($2::text[])"), this.db.dialect === "tidb" ? [scope, ...doomed] : [scope, doomed]);
         return res.affected;
     }
 }
-/** The SQL fence row kinds. `run_id = ''` on a purge fence (session-wide). */
 const KIND_SERVED = "served";
 const KIND_PURGE = "purge";
-/** Dual-dialect `WorkflowCompletionInbox`. See the file header for the dialect-delta ledger. */
 export class SqlWorkflowCompletionInbox {
     db;
     onWarn;
@@ -195,43 +150,26 @@ export class SqlWorkflowCompletionInbox {
     async enqueue(entry) {
         const now = Date.now();
         await this.sweepFences(now);
-        // Served fence FIRST (per-runId — cross-replica: a poll served on ANOTHER replica fences us here).
         const served = await this.db.query(this.q("SELECT 1 FROM workflow_inbox_fence WHERE session_id = ? AND kind = ? AND run_id IN (?, ?) AND until_ms >= ?", "SELECT 1 FROM workflow_inbox_fence WHERE session_id = $1 AND kind = $2 AND run_id IN ($3, $4) AND until_ms >= $5"), [entry.sessionId, KIND_SERVED, entry.runId, foldKeyFamily(entry.runId), now]);
         if (served.rows.length > 0) {
             this.onWarn?.("workflow_completion_enqueue_after_poll_served", { sessionId: entry.sessionId, runId: entry.runId });
             return;
         }
-        // Purge fence: owner-scoped exactly like the File impl (owner_known=0 → conservative fence-all;
-        // owner_known=1 → fences only the SAME owner; a different owner = a new legitimate claimant, passes).
         const purge = await this.db.query(this.q("SELECT owner, owner_known FROM workflow_inbox_fence WHERE session_id = ? AND kind = ? AND run_id = '' AND until_ms >= ?", "SELECT owner, owner_known FROM workflow_inbox_fence WHERE session_id = $1 AND kind = $2 AND run_id = '' AND until_ms >= $3"), [entry.sessionId, KIND_PURGE, now]);
         const pf = purge.rows[0];
         if (pf && (Number(pf.owner_known) === 0 || (pf.owner === null ? entry.owner === null : String(pf.owner) === entry.owner))) {
             this.onWarn?.("workflow_completion_enqueue_after_purge", { sessionId: entry.sessionId, runId: entry.runId });
             return;
         }
-        // Atomic move-to-tail (1.108 review fix — the prior DELETE-then-INSERT had a crash window that dropped the
-        // old entry; self-healing via the notify journal, but atomic is free here). Genuinely divergent statement:
-        // TiDB `REPLACE` = delete-conflicting-row + insert atomically, and omitting `seq` mints a fresh
-        // AUTO_INCREMENT = tail. PG has no REPLACE, so the twin is an upsert that explicitly re-mints `seq` off the
-        // BIGSERIAL's own sequence — same outcome (idempotent-on-runId + move-to-tail in ONE statement).
         await this.db.query(this.q("REPLACE INTO workflow_completion_inbox (session_id, run_id, owner, status, summary, enqueued_at_ms, kind, payload) VALUES (?,?,?,?,?,?,?,?)", "INSERT INTO workflow_completion_inbox (session_id, run_id, owner, status, summary, enqueued_at_ms, kind, payload) VALUES ($1,$2,$3,$4,$5,$6,$7,$8) " +
             "ON CONFLICT (session_id, run_id) DO UPDATE SET seq = nextval(pg_get_serial_sequence('workflow_completion_inbox','seq')), " +
             "owner = EXCLUDED.owner, status = EXCLUDED.status, summary = EXCLUDED.summary, enqueued_at_ms = EXCLUDED.enqueued_at_ms, kind = EXCLUDED.kind, payload = EXCLUDED.payload"), [entry.sessionId, entry.runId, entry.owner, entry.status, entry.summary, entry.enqueuedAt, entry.kind ?? null, entry.payload ?? null]);
-        // 1.108 review (lens① MAJOR ×2): the File impl's check-then-set is atomic on one event loop; here the
-        // fence check and the INSERT are two network statements, so a fence written IN BETWEEN (a poll served on
-        // another replica, or a racing purge) would leave fence + pending row coexisting → the next drain re-pushes
-        // an already-served/purged completion. Close the window by RE-CHECKING after the insert and self-revoking —
-        // ordering guarantees the loser is always visible to someone: markTerminalServed/purge write their fence
-        // BEFORE their delete, so either their delete kills our row, or our re-check sees their fence.
-        // (Residual, documented: a purge racing a NEW claimant's enqueue between fence-write and session-DELETE can
-        // still drop that one push — ms window + sessionId reclaim in it is contrived; the WorkflowStatus poll floor
-        // + notify-journal recovery cover it. File parity: purge drops the whole session queue there too.)
         const confirm = await this.db.query(this.q("SELECT kind, owner, owner_known FROM workflow_inbox_fence WHERE session_id = ? AND until_ms >= ? AND (run_id IN (?, ?) OR (kind = ? AND run_id = ''))", "SELECT kind, owner, owner_known FROM workflow_inbox_fence WHERE session_id = $1 AND until_ms >= $2 AND (run_id IN ($3, $4) OR (kind = $5 AND run_id = ''))"), [entry.sessionId, now, entry.runId, foldKeyFamily(entry.runId), KIND_PURGE]);
         for (const f of confirm.rows) {
             const isServed = String(f.kind) === KIND_SERVED;
             const purgeFencesUs = !isServed && (Number(f.owner_known) === 0 || (f.owner === null ? entry.owner === null : String(f.owner) === entry.owner));
             if (isServed || purgeFencesUs) {
-                await this.ack(entry.sessionId, entry.runId); // self-revoke: the fence won the race
+                await this.ack(entry.sessionId, entry.runId);
                 this.onWarn?.(isServed ? "workflow_completion_enqueue_after_poll_served" : "workflow_completion_enqueue_after_purge", {
                     sessionId: entry.sessionId,
                     runId: entry.runId,
@@ -239,21 +177,14 @@ export class SqlWorkflowCompletionInbox {
                 return;
             }
         }
-        // Cap: drop-oldest beyond MAX_PENDING_PER_SESSION (warn per drop, File parity). TiDB requires a LIMIT
-        // alongside OFFSET (MySQL-protocol syntax); PG's OFFSET stands alone.
         const over = await this.db.query(this.q("SELECT seq, run_id FROM workflow_completion_inbox WHERE session_id = ? ORDER BY seq DESC LIMIT 100000 OFFSET ?", "SELECT seq, run_id FROM workflow_completion_inbox WHERE session_id = $1 ORDER BY seq DESC OFFSET $2"), [entry.sessionId, MAX_PENDING_PER_SESSION]);
         if (over.rows.length > 0) {
-            // Bulk delete-by-seq-set: dynamic `IN (?,?,…)` on TiDB vs array-bound `= ANY($2::bigint[])` on PG.
             await this.db.query(this.q(`DELETE FROM workflow_completion_inbox WHERE session_id = ? AND seq IN (${over.rows.map(() => "?").join(",")})`, "DELETE FROM workflow_completion_inbox WHERE session_id = $1 AND seq = ANY($2::bigint[])"), this.db.dialect === "tidb" ? [entry.sessionId, ...over.rows.map((r) => r.seq)] : [entry.sessionId, over.rows.map((r) => r.seq)]);
             for (const r of over.rows)
                 this.onWarn?.("workflow_completion_inbox_overflow", { sessionId: entry.sessionId, droppedRunId: String(r.run_id) });
         }
     }
     async pending(sessionId) {
-        // 2026-07-11(同一缺陷的 SQL 半场):filter SERVED-fenced rows like the in-memory
-        // inbox does — markTerminalServed's fence-INSERT and ack-DELETE are two statements, and a drain on
-        // another replica between them re-emitted an already-served completion (the in-memory pending()
-        // filters by servedAt; this brings the SQL twin to the same semantics).
         const { rows } = await this.db.query(this.q("SELECT i.run_id, i.owner, i.status, i.summary, i.enqueued_at_ms, i.kind, i.payload FROM workflow_completion_inbox i " +
             "WHERE i.session_id = ? AND NOT EXISTS (SELECT 1 FROM workflow_inbox_fence f WHERE f.session_id = i.session_id AND f.kind = ? AND f.run_id IN (i.run_id, REGEXP_REPLACE(i.run_id, '#[0-9]+$', '')) AND f.until_ms >= ?) " +
             "ORDER BY i.seq ASC", "SELECT i.run_id, i.owner, i.status, i.summary, i.enqueued_at_ms, i.kind, i.payload FROM workflow_completion_inbox i " +
@@ -276,7 +207,6 @@ export class SqlWorkflowCompletionInbox {
     async purge(sessionId, purgedOwner) {
         const now = Date.now();
         await this.sweepFences(now);
-        // Fence FIRST (an enqueue racing the purge must lose), then clear. Upsert = a re-purge refreshes the window.
         await this.db.query(this.q("INSERT INTO workflow_inbox_fence (session_id, kind, run_id, owner, owner_known, until_ms) VALUES (?,?,?,?,?,?) " +
             "ON DUPLICATE KEY UPDATE owner = VALUES(owner), owner_known = VALUES(owner_known), until_ms = VALUES(until_ms)", "INSERT INTO workflow_inbox_fence (session_id, kind, run_id, owner, owner_known, until_ms) VALUES ($1,$2,'',$3,$4,$5) " +
             "ON CONFLICT (session_id, kind, run_id) DO UPDATE SET owner = EXCLUDED.owner, owner_known = EXCLUDED.owner_known, until_ms = EXCLUDED.until_ms"), this.db.dialect === "tidb"
@@ -291,15 +221,9 @@ export class SqlWorkflowCompletionInbox {
             "ON DUPLICATE KEY UPDATE until_ms = VALUES(until_ms)", "INSERT INTO workflow_inbox_fence (session_id, kind, run_id, owner, owner_known, until_ms) VALUES ($1,$2,$3,NULL,0,$4) " +
             "ON CONFLICT (session_id, kind, run_id) DO UPDATE SET until_ms = EXCLUDED.until_ms"), [sessionId, KIND_SERVED, runId, now + SERVED_FENCE_MS]);
         await this.ack(sessionId, runId);
-        // design/144 家族 ack(与 in-memory 语义对齐):fleet 帧无 seq 传家族前缀,park 行是 seq 键——
-        // 精确 DELETE 必 miss。剥行键尾部 #digits 与传入前缀比对(REGEXP_REPLACE/regexp_replace 语义=foldKeyFamily)。
         await this.db.query(this.q("DELETE FROM workflow_completion_inbox WHERE session_id = ? AND run_id <> ? AND REGEXP_REPLACE(run_id, '#[0-9]+$', '') = ?", "DELETE FROM workflow_completion_inbox WHERE session_id = $1 AND run_id <> $2 AND regexp_replace(run_id, '#[0-9]+$', '') = $3"), [sessionId, runId, runId]);
     }
 }
-/**
- * Dual-dialect `WorkflowNotifyJournalStore` — the crash-safe recovery backlog for at-least-once completion
- * notify. See the file header for the dialect-delta ledger.
- */
 export class SqlWorkflowNotifyJournalStore {
     db;
     constructor(db) {
@@ -309,8 +233,6 @@ export class SqlWorkflowNotifyJournalStore {
         return this.db.dialect === "tidb" ? tidb : pg;
     }
     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_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) {
@@ -327,9 +249,6 @@ export class SqlWorkflowNotifyJournalStore {
             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_ms < ?", "DELETE FROM workflow_notify_journal WHERE acked = 1 AND acked_at_ms < $1"), [before]);
         return res.affected;
@@ -350,8 +269,6 @@ export class SqlWorkflowNotifyJournalStore {
         };
     }
 }
-/** MySQL-protocol (TiDB) bindings — historical class names preserved; `onWarn` is an ADDITIVE optional 2nd
- *  ctor arg (existing 1-arg call sites are unaffected — see {@link SqlWorkflowRunStore}'s C5 trace channel). */
 export class TiDBWorkflowRunStore extends SqlWorkflowRunStore {
     constructor(pool, onWarn) {
         super(mysqlDriver(pool), onWarn);
@@ -367,8 +284,6 @@ export class TiDBWorkflowNotifyJournalStore extends SqlWorkflowNotifyJournalStor
         super(mysqlDriver(pool));
     }
 }
-/** PostgreSQL bindings — historical class names preserved; `onWarn` is an ADDITIVE optional 2nd ctor arg
- *  (existing 1-arg call sites are unaffected — see {@link SqlWorkflowRunStore}'s C5 trace channel). */
 export class PgWorkflowRunStore extends SqlWorkflowRunStore {
     constructor(pool, onWarn) {
         super(pgDriver(pool), onWarn);

package/dist/plugins/worktree-isolation.js

@@ -1,83 +1,17 @@
-/**
- * SVC-3 — git-WORKTREE ISOLATION wrapper for the deployment-level `executionEnvFactory` (design/97
- * CORE-6). A higher-order factory that mints a per-AGENT isolated git worktree when (and ONLY
- * when) core threads `ctx.isolation === "worktree"` through the TRUSTED `RunInternals` channel.
- *
- * WHY this lives in service, not core: core ships the env-AGNOSTIC primitive (`addWorktree` / `pruneWorktrees`
- * on the base `ExecutionEnv` seam, plus the `ExecutionEnvFactoryContext.isolation` hint). The env-SPECIFIC
- * bits — which concrete adapter roots an env at the worktree dir, which repo is the operator-trusted base,
- * where the reaper runs — are deployment wiring, so they belong here (铁律 core-service-boundary). We consume
- * the core export; we do NOT reimplement the git plumbing.
- *
- * SHAPE (per the task contract):
- *   const factory = withWorktreeIsolation(baseFactory, opts);
- *   - ctx.isolation === "worktree": `addWorktree(baseEnvForGit, { repoRoot, sessionId: ctx.sessionId,
- *     rootEnvAt, commit? })` → a worktree-rooted env WITH `destroy()` (the Runner calls it on task end →
- *     `git worktree remove --force`, which tears down ONLY that worktree, never the base repo).
- *   - otherwise: `baseFactory(ctx)` verbatim — the SHARED base env, NO `destroy` (the Runner must never tear
- *     the base down). Non-isolated tasks behave exactly as before this wrapper existed.
- *
- * 🔴 TRUST GATE (the whole point of SVC-3): the ONLY input that turns isolation ON is core's
- * `ctx.isolation` — populated from `ctx.agent({ isolation })` via the TRUSTED `RunInternals`, which core
- * guarantees is NEVER sourced from the untrusted `TaskSpec` (see core remote-env.ts §isolation). This wrapper
- * reads NOTHING else from `ctx` to decide isolation, and `repoRoot` comes ENTIRELY from the operator-supplied
- * closure (config), never from any task/`ctx` field — so an untrusted caller can neither flip isolation on a
- * repo it shouldn't touch nor inject a `repoRoot` path to escape the allowed roots. We additionally assert the
- * configured `repoRoot` is contained within an operator-trusted `allowedRoots` set at wrap time (defence in
- * depth: a mis-wired deployment fails loud rather than git-worktree-ing an arbitrary path).
- *
- * 🔴 ISOLATE-ONLY (clay): the runtime NEVER merges a worktree back. The orchestrator script reads each
- * worktree's result (via the worktree dir / the snapshot) and decides verify+merge in USERLAND. We only mint
- * and reap; merge policy is not ours.
- *
- * ⚠️ BOUNDARY CAVEATS (from core's CORE-6 doc — kept here so a future wirer doesn't reintroduce
- * a footgun):
- *  - durable-suspend is INCOMPATIBLE with a worktree env: core's prepare-task rejects a NON-remote factory env
- *    for a suspendable run (a host/NodeExecutionEnv-rooted worktree is not snapshotable). So an isolated agent
- *    MUST run to completion without parking — do NOT combine `isolation:"worktree"` with a suspend/HITL park
- *    on the host lane. (On an isolated lane like e2b/k8s the worktree would have to root a REMOTE env; that is
- *    a follow-on, see `rootEnvAt` below — host lane is v1.)
- *  - `git worktree` isolates the git WORKING COPY, not arbitrary shell access: bash inside the worktree can
- *    still reach the host filesystem/network. The worktree is a coordination boundary, NOT a security sandbox
- *    — pair it with a real sandbox lane (e2b/k8s/local-docker) when isolation from the host is required.
- *  - UNCOMMITTED changes in the base repo are ABSENT in the child worktree (core creates it `--detach` at
- *    `HEAD`/`commit`). An isolated agent sees the committed tree only — commit (or stash→apply, in userland)
- *    before fanning out if the base's dirty state must be visible.
- *  - a worktree orphaned by a process CRASH (the Runner never reached `destroy`) is reaped by
- *    {@link pruneWorktrees} — wired into the service reaper (best-effort, userland; core ships no post-kill
- *    Runner hook).
- */
 import path from "node:path";
 import { addWorktree, pruneWorktrees, } from "@sema-agent/core";
-/** Normalize a path for containment checks: resolve to absolute + drop a trailing separator. */
 function norm(p) {
     const r = path.resolve(p);
     return r.length > 1 && r.endsWith(path.sep) ? r.slice(0, -1) : r;
 }
-/** True when `child` is `root` itself or a descendant of it (segment-aware: `/a/b` is NOT under `/a/bc`). */
 function isWithin(root, child) {
     const r = norm(root);
     const c = norm(child);
     if (c === r)
         return true;
     const rel = path.relative(r, c);
-    // path.relative returns "" for equal, a non-"../"-leading relative for a descendant, and a "../"-leading
-    // (or absolute, on Windows drive change) path for an outside/sibling target.
     return rel.length > 0 && !rel.startsWith("..") && !path.isAbsolute(rel);
 }
-/**
- * SERIALIZE git worktree ADMIN ops per repo (MODULE-level, keyed by normalized repoRoot). `git worktree
- * add`/`remove`/`prune` all mutate the same repo's `.git/worktrees` registry; running any two CONCURRENTLY
- * against one repo races. Two callers share this registry:
- *   - the isolation wrapper's mint (`add`) and teardown (`remove`) legs;
- *   - the service reaper's `prune` leg (#62 svc3 race: prune used to bypass the wrapper's closure-local
- *     lock entirely — the adverse arm is prune observing a mid-mint "registered, dir not yet populated"
- *     window and DEREGISTERING the half-minted worktree, handing the task a dir git no longer tracks and
- *     making its eventual `git worktree remove` fail loud on a healthy run).
- * A promise-chain mutex per repoRoot: each op runs after the prior one SETTLES (success OR failure — never
- * deadlock). Git ops are ~ms and serial-safe; agents still run fully parallel. The map is bounded by the
- * number of distinct configured repoRoots (operator config, typically 1) — no eviction needed.
- */
 const gitAdminLocks = new Map();
 function serializeGitAdmin(repoRoot, fn) {
     const key = norm(repoRoot);
@@ -85,38 +19,21 @@ function serializeGitAdmin(repoRoot, fn) {
     gitAdminLocks.set(key, run.then(() => undefined, () => undefined));
     return run;
 }
-/**
- * Wrap a deployment's `executionEnvFactory` so an agent with `ctx.isolation === "worktree"` runs in its own
- * detached git worktree. See the file header for the full contract + trust gate + caveats.
- *
- * Throws at WRAP time (fail-loud, not faked) if `repoRoot` is not contained within `allowedRoots` — a
- * mis-wired deployment must not silently git-worktree an arbitrary path.
- */
 export function withWorktreeIsolation(baseFactory, opts) {
     const repoRoot = norm(opts.repoRoot);
     const allowedRoots = (opts.allowedRoots?.length ? opts.allowedRoots : [repoRoot]).map(norm);
-    // Trust gate (defence in depth): the configured repoRoot must live inside an operator-trusted root. This is
-    // a CONFIG invariant (repoRoot is never a task input), so a violation = mis-wire → fail loud at boot.
     if (!allowedRoots.some((root) => isWithin(root, repoRoot))) {
         throw new Error(`withWorktreeIsolation: repoRoot ${repoRoot} is not within any allowedRoots [${allowedRoots.join(", ")}] — refusing to git-worktree an untrusted path`);
     }
     const serialize = (fn) => serializeGitAdmin(repoRoot, fn);
     return async (ctx) => {
-        // TRUST GATE: the ONLY trigger is core's RunInternals-sourced ctx.isolation. We read nothing else from ctx
-        // (and never anything from a TaskSpec) to decide isolation — see file header.
         if (ctx.isolation !== "worktree") {
-            // Non-isolated: the SHARED base env, verbatim, NO destroy attached → the Runner never tears the base
-            // down (core's hasDestroy() returns false for a plain base env). Behaviour identical to no wrapper.
             return baseFactory(ctx);
         }
-        // S3([2113] core 裁定的 server 半场):keep-if-changed 需要在保留分支跑 inner teardown(LSP evict
-        // 链等)而不跑 `git worktree remove` —— core addWorktree 把两者焊成一个复合 destroy 拆不开,所以在
-        // rootEnvAt 铸造点捕获 inner env 的**原** destroy 引用(per-mint 变量;core 稍后才把复合 destroy
-        // 装回同一对象上)。
         let innerDestroy;
         const { env, worktreeDir } = await serialize(() => addWorktree(opts.baseEnvForGit, {
             repoRoot,
-            sessionId: ctx.sessionId, // core sanitizes this into the worktree dir name (human-readable orphan diag)
+            sessionId: ctx.sessionId,
             rootEnvAt: async (dir) => {
                 const inner = await opts.rootEnvAt(dir);
                 const d = inner.destroy;
@@ -126,8 +43,6 @@ export function withWorktreeIsolation(baseFactory, opts) {
             },
             ...(opts.commit ? { commit: opts.commit } : {}),
         }));
-        // keep-if-changed 判定基点:mint 后立刻解析 worktree 的 HEAD(=detach 基点)。判定轴与 core Agent
-        // 车道逐字同款(subagent.js finish):dirty 文件 >0 ∥ base..HEAD commits >0 ⇒ changed。
         let baseSha;
         {
             const r = await opts.baseEnvForGit.exec("git rev-parse HEAD", { cwd: worktreeDir });
@@ -135,7 +50,6 @@ export function withWorktreeIsolation(baseFactory, opts) {
                 baseSha = r.value.stdout.trim();
         }
         const isChanged = async () => {
-            // 判定失败 ⇒ 保守保留(Agent 车道 changed=true 缺省同款:删错=用户产出蒸发,留错=一个目录)。
             const status = await opts.baseEnvForGit.exec("git status --porcelain", { cwd: worktreeDir });
             if (!status.ok || status.value.exitCode !== 0)
                 return true;
@@ -154,37 +68,18 @@ export function withWorktreeIsolation(baseFactory, opts) {
             ...(ctx.taskId ? { taskId: ctx.taskId } : {}),
             worktreeDir,
         });
-        // Wrap core's `destroy()` (runs `git worktree remove`) through the SAME mutex so a concurrent teardown can't
-        // race the registry lock and orphan the worktree. The other env methods (exec/fs) keep their own binding —
-        // we only override `destroy`. Idempotent at the git level (remove of an already-gone worktree is a no-op).
-        //
-        // POST-MORTEM + RETRY (2026-07-26, the deterministic pin for the 30-round reaper-race intermittent):
-        // core's destroy is FAIL-OPEN on the remove — `git-worktree-env.js` neither checks the exec Result nor lets a
-        // rejection out (`.catch(() => undefined)`), so one transient failure (spawn EAGAIN/EMFILE under full-suite
-        // load) resolves destroy() normally while leaving dir+registration behind — and `git worktree prune` can NEVER
-        // reap a worktree whose dir still exists, so the orphan is permanent. Until core checks the result (reported),
-        // we verify the dir is actually gone after each destroy, retry ONCE on residue, and FAIL LOUD if it survives
-        // both — a thrown teardown is diagnosable; a silently-accumulating orphan tree is not.
         const coreDestroy = env.destroy.bind(env);
         const residue = async () => {
             const r = await opts.baseEnvForGit.exists(worktreeDir);
-            return r.ok ? r.value : false; // can't verify (base env unhealthy) → don't invent a residue; destroy stays best-effort
+            return r.ok ? r.value : false;
         };
-        // IDEMPOTENCY (core 1.423): the remove leg is now FAIL-LOUD ([1796]§二 → [1801] — the fail-open this wrapper's
-        // post-mortem was built against is fixed), so a REPEAT destroy would hit `git worktree remove` on an
-        // already-removed worktree and reject. A completed destroy + no residue ⇒ short-circuit (the goal state is
-        // already reached; double/concurrent destroy is a legal Runner shape). The first call always goes through
-        // coreDestroy (the inner env's own teardown must run).
         let destroyedOnce = false;
         let keptOnce = false;
         env.destroy = () => serialize(async () => {
             if (keptOnce)
-                return; // kept 是终态:二次 destroy 不得把保留的产出删掉
+                return;
             if (destroyedOnce && !(await residue()))
-                return; // idempotent repeat — done is done(原语义:残留时放行重试)
-            // S3 keep-if-changed:有改动(或判不出来)⇒ 保留目录+registration 给 userland verify+merge,
-            // 只跑 inner teardown(LSP evict/host 收尾;rootEnvAt 铸的是 persistent 形,不 rm 目录),
-            // 并披露坐标 —— 不披露的保留=只是换了个姿势的蒸发。残留检查在本分支让位:目录在=目的。
+                return;
             if (await isChanged()) {
                 keptOnce = true;
                 try {
@@ -205,31 +100,16 @@ export function withWorktreeIsolation(baseFactory, opts) {
             if (!(await residue()))
                 return;
             opts.logger?.warn?.("worktree_destroy_residue_retry", { worktreeDir, sessionId: ctx.sessionId });
-            await coreDestroy(); // second shot on a live registration/dir — safe; a missing one is short-circuited above
+            await coreDestroy();
             if (await residue()) {
                 throw new Error(`worktree destroy left residue at ${worktreeDir} (git worktree remove failed twice — see core git-worktree-env fail-open)`);
             }
         });
-        return env; // carries the serialized destroy() → core's Runner removes the worktree (ONLY this one) on task end.
+        return env;
     };
 }
-/**
- * Best-effort reaper hook: deregister worktrees orphaned by a process crash (the Runner never reached
- * `destroy`). Core's {@link pruneWorktrees} runs `git worktree prune` against the base repo — it cleans up
- * registrations whose worktree dirs are already gone. Wired into the service reaper (userland; core ships no
- * post-kill Runner hook). NEVER throws (a prune failure is logged, never fatal).
- *
- * NOTE: `git worktree prune` only deregisters worktrees whose DIRECTORY is missing. A crashed run that left
- * the dir intact is NOT reaped by prune alone — that is acceptable for v1 (the worktree lives under the known
- * `.sema-worktrees/` parent and is human-/script-reapable; a stricter age-based sweep is a follow-on).
- */
 export async function reapOrphanWorktrees(baseEnvForGit, repoRoot, logger) {
     try {
-        // #62:prune 动的是与 add/remove 同一张 `.git/worktrees` 注册表 ⇒ 必须过同一把 per-repoRoot 锁
-        // (曾绕锁直跑;恶劣臂见 serializeGitAdmin 注)。
-        // core 3.0.0(#94 提货):pruneWorktrees 从「失败 throw」改为回执 `{ok:true}|{ok:false,detail}`——
-        // 只靠下面的 catch 发警在 3.0.0 下= prune 失败**静默化**(CI svc3 钉抓出)。回执臂与 throw 臂
-        // (serializeGitAdmin/env 传输层仍可抛)两路都进同一条 warn,判据不变:失败必须留痕。
         const r = await serializeGitAdmin(repoRoot, () => pruneWorktrees(baseEnvForGit, norm(repoRoot)));
         if (r.ok === false)
             logger?.warn?.("worktree_prune_failed", { repoRoot: norm(repoRoot), error: r.detail });