@sema-agent/server 7.13.0 → 7.15.0

package/dist/capabilities/memory-notice.d.ts

@@ -0,0 +1,87 @@
+/**
+ * #217(板 [3499]②/[3521]④ 两次点名的 server 接线半场)—— 零记忆面部署形的**持久记忆披露**。
+ *
+ * 病(core [3479] 实测,#148 立案):一台没有任何持久记忆面的部署,用户说「请记住 X」,模型回一句
+ * 「已经记住了」——落盘处并不存在。用户带着「这条事实已入库」的信念离开,下一次会话才发现是空的。
+ *
+ * core 5.26.0 的分工:引擎**能自证**只读的两态(engine 侧 `writeScope:null` / runner 侧 `handsReadOnly`)
+ * 由引擎自动挂 `MEMORY_READONLY_NOTICE`;而「整台部署根本没有记忆面」这一形 core 只导出文本
+ * (`NO_PERSISTENT_MEMORY_NOTICE`)、**不注入** —— 逐字原文:「A deployment that composes its own prompt
+ * should include this block exactly when no memory face is mounted」。组装归宿主,与 `MEMORY_SAFETY`
+ * 同姿势。本模块就是那半场。
+ *
+ * ⚠️ 两条边界,越界即双重注入/假话:
+ *  · **engine 在场就不是我们的座位**。哪怕 `memoryWrite:false`(writeScope null)——那恰恰是引擎自己
+ *    挂只读披露的状态,server 再叠一句口径不同的「你没有持久记忆」= 同一件事两种说法同框。
+ *  · **推断到「有落盘路」就闭嘴**。判别式与 core 的 `rosterCanPersist` 同口径(已知落盘路 = 挂载且未
+ *    排除的文件写工具 / 可写 shell)。⚠️ 名单确实要读(codex 复审 [medium] 之后加的 `excludeTools` 一位:
+ *    roster 把落盘路**整批**卸掉时,手带在场也等于没有写通道),但负控仍然成立:必须**全部**已知落盘路
+ *    都不在才算断链 —— `excludeTools:["Write"]` 不算(Bash/Edit 还在),请求面摘一个工具名改不动结论。
+ */
+import { type PromptProvider, type TaskSpec } from "@sema-agent/core";
+import type { ScenarioHands } from "./hands-lane.js";
+/**
+ * 「已知落盘路」的工具名闭集 —— 与 core 的 `rosterCanPersist` 同口径:**文件写工具**(Write/Edit/
+ * NotebookEdit)或**可写 shell**(Bash)。刻意**不是** `HAND_TOOL_EFFECTS` 里 effect=write 的全集:
+ * core 逐字裁过「a generic write-effect tool does NOT count — a mail sender's side effect is not a
+ * memory store」,`TaskStop` 就是那种(有写副作用、不是落盘路)。
+ *
+ * 名字会漂,所以配一道防漂移钉(test/no-persistent-memory-notice.test.ts):每个名字必须在 core 的
+ * `HAND_TOOL_EFFECTS` 里且 effect 为 `write` —— core 改名/改档位当场红,而不是让这里静默失配成
+ * 「没有一个写工具被排除」(fail-open 方向)。
+ */
+export declare const KNOWN_PERSISTENCE_TOOL_NAMES: readonly ["Write", "Edit", "NotebookEdit", "Bash"];
+/** 披露段在 `prompt.assembled` 清单里的段 id(`core/` 命名空间是 core 保留的,部署段一律自家前缀)。 */
+export declare const NO_PERSISTENT_MEMORY_SECTION_ID = "sema/memory.no-persistent";
+/** 判别式的全部输入 —— 每一位都是**部署/装配期事实**,没有一位来自请求体的自我表态。 */
+export interface MemoryFaceFacts {
+    /** 本次任务最终的 `TaskSpec.memory`。`undefined` = 这一腿根本没有引擎记忆面(引擎未接、多租户 dark、
+     *  remote lane 平面分裂 fail-closed……三条路殊途同归:core 不会 prepare 记忆,也就不会挂任何披露)。 */
+    memory: TaskSpec["memory"];
+    /** 部署声明 `MEMORY_PERSISTENCE_CAPABLE`(三态)。`true` = operator 自证有推断看不见的持久通道
+     *  (自定义 writer / MCP 记忆服务)⇒ 披露会变成假话,撤回;`false` = 强制披露;缺席 ⇒ 走推断。 */
+    declaredCapable: boolean | undefined;
+    /** 本请求命中场景的手带表态(#196 判别位)。`none` = 该场景跑在不挂 `executionEnvFactory` 的 Runner 上,
+     *  core 的手带 band(Bash/Edit/Write/…)整批不 mount。 */
+    hands: ScenarioHands;
+    /** 折完 governance+settings 后的最终 `handsReadOnly`(plan 模式 / autonomy 收窄)。手带只剩读腿。 */
+    handsReadOnly: boolean;
+    /** 折完之后的最终 `TaskSpec.excludeTools`(roster 真卸载,不是延迟披露)。**全部**已知落盘路都被排掉
+     *  ⇒ 手带在场也等于没有写通道 —— core 的 `rosterCanPersist` 也是按排除后的 roster 算的,这里跟上。 */
+    excludeTools: readonly string[] | undefined;
+    /** 本部署的执行环境在 core 眼里算不算 **remote**(`isRemoteExecutionEnv`)。判别位 = `REMOTE_EXEC` 有没有
+     *  设 —— 注意 `host` 也算:core 的判别是**鸭子类型**(`workspaceHandle`/`execStream`/`suspendVM`/…),
+     *  而我方的 `remote-env-host.ts` 这几件全实现,亲验坐实。
+     *  为什么这一位必须进判别式(codex 复审 round2 [high],已核真):core 的 `rosterCanPersist` 在
+     *  `handsEnabled && isRemoteExecutionEnv` 时把 Write/Edit/NotebookEdit/Bash **全部不算**落盘路(沙箱盘
+     *  每任务即焚,够不着 host 记忆根)。而 server 在任何 remote 车道上默认让记忆引擎 dark —— 两件事合起来
+     *  正是**最常见的云部署形**:引擎不在、手带在,却一份持久面都没有。漏了这一位,那台机器就继续给
+     *  「已经记住了」的幻觉式回执 —— 恰恰是 #148 立案要消灭的形态。 */
+    remoteExecutionEnv: boolean;
+}
+/**
+ * 该不该把 `NO_PERSISTENT_MEMORY_NOTICE` 组进本次任务的 system prompt。
+ *
+ * 优先序(每一条都有独立理由,不是同一条判据的三种写法):
+ *  ① engine 在场 ⇒ **否**(引擎的座位,见文件头注);
+ *  ② 部署显式声明 ⇒ 声明说了算(`true` 撤回 / `false` 强制)—— operator 的部署事实压过我们的推断,
+ *     与 core 对 `memoryPersistenceCapable` 的处置同向;
+ *  ③ 否则推断:有已知落盘路(手带在场且不是只读)⇒ 否;没有 ⇒ 是。
+ */
+export declare function shouldDiscloseNoPersistentMemory(facts: MemoryFaceFacts): boolean;
+/**
+ * 把披露段组进一个 prompt provider,**按 provider 自己的钩子形分腿**(换形会改段身份与 append 座位):
+ *  · typed(`stableBlocks`)⇒ {@link mountNotice}(普通形追加 behavior 声明;已组装 identity 形接在其文本后)。
+ *  · string(`stableSystem`)⇒ 接在 role 层文本之后(落进 `core/role.base` 段)。
+ *  · 两个钩子都没有(= core 会用 `defaultPromptProvider`)⇒ **只发一条 typed 声明**,role 层留给 core 自己铸。
+ *
+ * ⚠️ 最后一腿为什么不是「自铸 role 层」(2026-08-12 复扫 medium,已实测):自铸形
+ * `stableSystem: (ctx) => ${ctx.userSystemPrompt ?? DEFAULT_SYSTEM_PROMPT}\n\n${段落}` 把**调用方的**
+ * systemPrompt 逐字变成了 provider 的输出。调用方传一份已组装 prompt(集成方/center 的常见形)时,装配器的
+ * 迁移卫就在 provider 输出上探到三锚 ⇒ pass-through 臂 ⇒ 保留集无 `core/role.append` ⇒ 已被 append 门放行的
+ * `appendSystemPrompt`/`settings.outputStyle` 静默蒸发(门在包装**之前**按未包装的 provider 判,两边分家)。
+ * 走 typed 声明腿就没有这条耦合:role 层仍由 core 按 `userSystemPrompt ?? DEFAULT_SYSTEM_PROMPT` 自己铸,
+ * 我方只贡献一条 behavior 段,`providerDropsAppend` 的判决包装前后逐格相同。
+ */
+export declare function withNoPersistentMemoryNotice(provider: PromptProvider | undefined): PromptProvider;
+//# sourceMappingURL=memory-notice.d.ts.map

package/dist/capabilities/memory-notice.js

@@ -0,0 +1,110 @@
+/**
+ * #217(板 [3499]②/[3521]④ 两次点名的 server 接线半场)—— 零记忆面部署形的**持久记忆披露**。
+ *
+ * 病(core [3479] 实测,#148 立案):一台没有任何持久记忆面的部署,用户说「请记住 X」,模型回一句
+ * 「已经记住了」——落盘处并不存在。用户带着「这条事实已入库」的信念离开,下一次会话才发现是空的。
+ *
+ * core 5.26.0 的分工:引擎**能自证**只读的两态(engine 侧 `writeScope:null` / runner 侧 `handsReadOnly`)
+ * 由引擎自动挂 `MEMORY_READONLY_NOTICE`;而「整台部署根本没有记忆面」这一形 core 只导出文本
+ * (`NO_PERSISTENT_MEMORY_NOTICE`)、**不注入** —— 逐字原文:「A deployment that composes its own prompt
+ * should include this block exactly when no memory face is mounted」。组装归宿主,与 `MEMORY_SAFETY`
+ * 同姿势。本模块就是那半场。
+ *
+ * ⚠️ 两条边界,越界即双重注入/假话:
+ *  · **engine 在场就不是我们的座位**。哪怕 `memoryWrite:false`(writeScope null)——那恰恰是引擎自己
+ *    挂只读披露的状态,server 再叠一句口径不同的「你没有持久记忆」= 同一件事两种说法同框。
+ *  · **推断到「有落盘路」就闭嘴**。判别式与 core 的 `rosterCanPersist` 同口径(已知落盘路 = 挂载且未
+ *    排除的文件写工具 / 可写 shell)。⚠️ 名单确实要读(codex 复审 [medium] 之后加的 `excludeTools` 一位:
+ *    roster 把落盘路**整批**卸掉时,手带在场也等于没有写通道),但负控仍然成立:必须**全部**已知落盘路
+ *    都不在才算断链 —— `excludeTools:["Write"]` 不算(Bash/Edit 还在),请求面摘一个工具名改不动结论。
+ */
+import { NO_PERSISTENT_MEMORY_NOTICE } from "@sema-agent/core";
+import { hasConstitutionAnchors } from "../task-settings.js";
+/**
+ * 「已知落盘路」的工具名闭集 —— 与 core 的 `rosterCanPersist` 同口径:**文件写工具**(Write/Edit/
+ * NotebookEdit)或**可写 shell**(Bash)。刻意**不是** `HAND_TOOL_EFFECTS` 里 effect=write 的全集:
+ * core 逐字裁过「a generic write-effect tool does NOT count — a mail sender's side effect is not a
+ * memory store」,`TaskStop` 就是那种(有写副作用、不是落盘路)。
+ *
+ * 名字会漂,所以配一道防漂移钉(test/no-persistent-memory-notice.test.ts):每个名字必须在 core 的
+ * `HAND_TOOL_EFFECTS` 里且 effect 为 `write` —— core 改名/改档位当场红,而不是让这里静默失配成
+ * 「没有一个写工具被排除」(fail-open 方向)。
+ */
+export const KNOWN_PERSISTENCE_TOOL_NAMES = ["Write", "Edit", "NotebookEdit", "Bash"];
+/** 披露段在 `prompt.assembled` 清单里的段 id(`core/` 命名空间是 core 保留的,部署段一律自家前缀)。 */
+export const NO_PERSISTENT_MEMORY_SECTION_ID = "sema/memory.no-persistent";
+/** 排除后还剩不剩已知落盘路。空/缺席的排除名单 ⇒ 一定还剩(最常见的路径,提前短路)。 */
+function anyPersistenceToolSurvives(excludeTools) {
+    if (excludeTools === undefined || excludeTools.length === 0)
+        return true;
+    const excluded = new Set(excludeTools);
+    return KNOWN_PERSISTENCE_TOOL_NAMES.some((name) => !excluded.has(name));
+}
+/**
+ * 该不该把 `NO_PERSISTENT_MEMORY_NOTICE` 组进本次任务的 system prompt。
+ *
+ * 优先序(每一条都有独立理由,不是同一条判据的三种写法):
+ *  ① engine 在场 ⇒ **否**(引擎的座位,见文件头注);
+ *  ② 部署显式声明 ⇒ 声明说了算(`true` 撤回 / `false` 强制)—— operator 的部署事实压过我们的推断,
+ *     与 core 对 `memoryPersistenceCapable` 的处置同向;
+ *  ③ 否则推断:有已知落盘路(手带在场且不是只读)⇒ 否;没有 ⇒ 是。
+ */
+export function shouldDiscloseNoPersistentMemory(facts) {
+    if (facts.memory !== undefined)
+        return false;
+    if (facts.declaredCapable !== undefined)
+        return !facts.declaredCapable;
+    if (facts.hands === "none" || facts.handsReadOnly)
+        return true;
+    // remote 执行环境:手带写的是沙箱盘(每任务即焚),够不着任何 host 侧持久面 —— core 的
+    // `rosterCanPersist` 在这一形下把四只写工具**全部**不算,这里逐字同口径。
+    if (facts.remoteExecutionEnv)
+        return true;
+    // 手带在场,但 roster 可能把落盘路整批卸掉了(`excludeTools` 是真卸载)。⚠️ 负控仍成立:排掉**一个**
+    // `Write` 不算无写通道(Bash/Edit 还在)—— 必须**全部**已知落盘路都不在,才算这条链断了。
+    return !anyPersistenceToolSurvives(facts.excludeTools);
+}
+/** 披露段作为独立 `behavior` 声明的形。**不能**用 `identity`:那个 slot 会替换 role base。 */
+const NOTICE_BLOCK = { id: NO_PERSISTENT_MEMORY_SECTION_ID, slot: "behavior", text: NO_PERSISTENT_MEMORY_NOTICE };
+/**
+ * 把披露段挂进一组 typed 声明。两条腿,分界线是 core 装配器会走哪条臂:
+ *  · 普通形 ⇒ 追加一条 `behavior` 声明(装配器正常 compose,段落各就各位);
+ *  · 声明里有**已组装 identity**(三锚齐全)⇒ 装配器走 pass-through 臂:`roleBase = 该 identity 的文本`,
+ *    其余声明**一条不挂**(core 只发一条「N 条声明未挂载」的告警)。此时追加 behavior 段等于什么都没做 ——
+ *    披露判为真、模型侧一个字都收不到,正是 #148 要消灭的那种沉默。所以这一形改成把披露段接在**该 identity
+ *    文本之后**(pass-through 臂原样把它当 `core/role.base` 发出去),文字真的进 prompt。
+ *    ⚠️ `contentHash` 一并摘掉:文本被追加过就不再是 center 那份发布物的摘要,留着 = 一条对不上的对账锚
+ *    (core 会为不匹配的摘要再发一条告警)。原文一个字节不改,只在后面接。
+ */
+function mountNotice(decls) {
+    const assembledIdentity = decls.find((d) => d.slot === "identity" && hasConstitutionAnchors(d.text));
+    if (!assembledIdentity)
+        return [...decls, NOTICE_BLOCK];
+    return decls.map((d) => (d === assembledIdentity ? { id: d.id, slot: d.slot, text: `${d.text}\n\n${NO_PERSISTENT_MEMORY_NOTICE}` } : d));
+}
+/**
+ * 把披露段组进一个 prompt provider,**按 provider 自己的钩子形分腿**(换形会改段身份与 append 座位):
+ *  · typed(`stableBlocks`)⇒ {@link mountNotice}(普通形追加 behavior 声明;已组装 identity 形接在其文本后)。
+ *  · string(`stableSystem`)⇒ 接在 role 层文本之后(落进 `core/role.base` 段)。
+ *  · 两个钩子都没有(= core 会用 `defaultPromptProvider`)⇒ **只发一条 typed 声明**,role 层留给 core 自己铸。
+ *
+ * ⚠️ 最后一腿为什么不是「自铸 role 层」(2026-08-12 复扫 medium,已实测):自铸形
+ * `stableSystem: (ctx) => ${ctx.userSystemPrompt ?? DEFAULT_SYSTEM_PROMPT}\n\n${段落}` 把**调用方的**
+ * systemPrompt 逐字变成了 provider 的输出。调用方传一份已组装 prompt(集成方/center 的常见形)时,装配器的
+ * 迁移卫就在 provider 输出上探到三锚 ⇒ pass-through 臂 ⇒ 保留集无 `core/role.append` ⇒ 已被 append 门放行的
+ * `appendSystemPrompt`/`settings.outputStyle` 静默蒸发(门在包装**之前**按未包装的 provider 判,两边分家)。
+ * 走 typed 声明腿就没有这条耦合:role 层仍由 core 按 `userSystemPrompt ?? DEFAULT_SYSTEM_PROMPT` 自己铸,
+ * 我方只贡献一条 behavior 段,`providerDropsAppend` 的判决包装前后逐格相同。
+ */
+export function withNoPersistentMemoryNotice(provider) {
+    if (provider?.stableBlocks) {
+        const blocks = provider.stableBlocks.bind(provider);
+        return { ...provider, stableBlocks: (ctx) => mountNotice(blocks(ctx)) };
+    }
+    if (provider?.stableSystem) {
+        const stable = provider.stableSystem.bind(provider);
+        return { ...provider, stableSystem: (ctx) => `${stable(ctx)}\n\n${NO_PERSISTENT_MEMORY_NOTICE}` };
+    }
+    return { stableBlocks: () => [NOTICE_BLOCK] };
+}
+//# sourceMappingURL=memory-notice.js.map

package/dist/config-types.d.ts

@@ -13,6 +13,22 @@ import type { QuestionThrottle } from "./question.js";
 import type { InfraCostRates } from "./observability/cost-taxonomy.js";
 import type { Autonomy, CommandRule } from "./runtime-governance.js";
 import type { GitApiKind } from "./git-api-kind.js";
+/** #228:记忆向量面的 embedder 坐标(env `MEMORY_EMBEDDER_*` 解析结果;单一属主 = 本类型,
+ *  `plugins/memory-embedder.ts` 的工厂直接消费它,不复制形状)。语义与三问见
+ *  {@link ServiceConfigFlat.memoryEmbedder}。纯数据 —— 端点原文照存(拼 `/embeddings` 是 transport
+ *  的活,与 `memorySync.url` 的尾斜杠口径一致)。 */
+export interface MemoryEmbedderConfig {
+    /** OpenAI 兼容服务的基址或完整 `/embeddings` 端点(两种写法都收,拼接在工厂里归一)。 */
+    endpoint: string;
+    /** 模型名,原样进请求体 `{ model, input }`。 */
+    model: string;
+    /** 声明维度(正整数)。响应向量长度与它不等 = 抛,绝不截断/补零。 */
+    dimensions: number;
+    /** 单次 embed 的活性上限(ms)。`MEMORY_EMBEDDER_TIMEOUT_MS`,默认 30s。 */
+    timeoutMs: number;
+    /** 可选 Bearer(自托管 TEI/vllm/ollama 通常不需要;公有云端点需要)。 */
+    apiKey?: string;
+}
 /** A sema-registry MCP server resolved to a core spec (env-NAME refs already → real values) plus the
  *  scenarios it applies to (empty = all). `resolveSpec` filters by scenario and passes `spec` to core. */
 export interface ScopedMcpServer {
@@ -23,7 +39,8 @@ export interface ScopedMcpServer {
  *  off (the control plane never mounts). The runner-facing facts (the runner principal, the build-host CACHE_BASE,
  *  the default base ref) live here so image-api injects only VETTED, server-fixed values into the build.sh argv —
  *  operator free-text never reaches the runner. */
-/** #151 车3(design/172 流内审批协议)的配置面。总开关默认 **false**;四个从属旋钮只在开关为真时生效
+/** #151 车3(design/172 流内审批协议)的配置面。总开关默认 **true**(clay 裁 2026-08-08,#164 翻真验证后;
+ *  树上已生效,发布线落在 7.4.0 之后的下一个发布);四个从属旋钮只在开关为真时生效
  *  (语义与「谁需要 / 谁被伤 / 什么补偿」三问见 `ServiceConfigFlat.streamApproval` 的注)。 */
 export interface StreamApprovalConfig {
     /** 协议总开关。`STREAM_APPROVAL_ENABLED`,默认 **true**(clay 裁 2026-08-08,#164 翻真验证后;7.5.0 起)。显式 false ⇒ 全链逐字 7.3.0 前行为(唯一干净还原键)。
@@ -233,6 +250,37 @@ export interface ServiceConfigFlat {
     /** The single-user deployment's one memory scope name (env MEMORY_SCOPE; default "local" under
      *  single-user). Feeds `spec.memory.scope` — the new engine consumes the same normalized scopes. */
     memoryScope?: string;
+    /** #217(core 5.26.0 `TaskSpec.memoryPersistenceCapable`)—— 本部署对「这台机器上的任务**能不能**把
+     *  用户说的『记住 X』落到持久处」的**自我声明**,env `MEMORY_PERSISTENCE_CAPABLE`,三态:
+     *   · 缺席(默认)⇒ 键不上 TaskSpec,core 按自己的 roster 推断(已知落盘路 = 挂载且未排除的文件写工具
+     *     或可写 shell;remote 执行环境的手带写的是沙箱盘,不算够得着 host 记忆根);
+     *   · `true` ⇒ 部署自证有推断**看不见**的持久通道(自定义 writer / MCP 记忆服务 / remote lane 与记忆根
+     *     共享挂载)。它撤回引擎的只读披露,并在 remote lane 上**恢复** `# Memory` 写指令(core 5.26.0 r13/r14
+     *     收窄的官方恢复路径);
+     *   · `false` ⇒ 强制披露只读/无持久面,并关掉文件工具往记忆根的写通道(披露不会被存储事实打脸)。
+     *
+     *  🔴 **`false` 自 core 5.27.0 起还多一层**([3612] F2,#231 提货):declared-false 的会话是**受限会话**
+     *  —— materialize/search/harvest 一律按**已提交账**(ledger + shadow)供给,磁盘上无事务背书的分歧
+     *  既不收编也不供给,而是留盘 + 响亮点名(`restricted_divergence`,`HarvestRejectionCode` 新成员),
+     *  等下一次**非受限**会话走正常门收编。这补上了 5.26.0 自己登记的那条残余(读侧入站同步收编磁盘分歧
+     *  **与会话意图无关**)——在那之前,这里写的「披露不会被存储事实打脸」只是半真话:披露说「本机存不下」,
+     *  引擎却仍可能把别处落进记忆根的字节收进这次会话的账。
+     *  ⚠️ **这一层的射程 = file 记忆引擎**(`MEMORY_ENGINE_BACKEND` 未设的默认单机形):受限视图是
+     *  `FileMemoryEngineBackend.restrictedAdoptionView` 的实装,而 `engine.materialize` 取它走的是
+     *  `?? this.backend` 的**可选** seam。我方 pg/tidb 两只记忆后端没有实装、也不需要——它们的读侧走库,
+     *  盘上目录只是每任务的投影工作区,没有「读磁盘即收编」这条通道。`false` 在 DB 后端上仍照常买到
+     *  披露 / 写门 / 零收编 harvest 三件(引擎级,与后端无关)。
+     *
+     *  与请求键 `memoryWrite`(MF-30)**两轴正交**,不是同一件事的两种写法:`memoryWrite` 是**本次运行**的
+     *  客户端表态(per-run 暂停写,writeScope:null),`memoryPersistenceCapable` 是**部署**声明(operator 面,
+     *  与请求无关)。两轴任一取「否」方向即只读方向 —— 客户端能收紧本次运行,永远不能靠表态把部署声明的
+     *  `false` 撑开(operator 旋钮不挂客户端表态派生腿)。
+     *  ⚠️ **别把两轴的「只读」当成同一件事**([3612] F2 修后口径,逐字对齐 core):**受限**是**会话级的
+     *  verdict 单键**(= 这里的 declared-false),而 `writeScope:null` 的只读**平面**(`memoryWrite:false` 的
+     *  per-run 暂停 / org 层默认只读 / 双根非写面)**保持 adopt-on-read 原样** —— 受限是会话的**声明**,
+     *  永远不是平面的**结构**。所以:一次 `memoryWrite:false` 的运行照常收编磁盘上的新内容(用户手改、
+     *  git pull 落下的文件都还认),它只是不 harvest;而 declared-false 的部署连收编都不做。 */
+    memoryPersistenceCapable?: boolean;
     /** 142-S2.5-W1: TOC 同步 client 腿 —— file memory 形态把本地记忆盘与中心(DB 权威,
      *  POST /v1/memory/sync/:scope)做一轮一 RTT 双向同步。env 三键:`MEMORY_SYNC_URL`(设了=开;缺省
      *  undefined=纯本地现状零变化)/`MEMORY_SYNC_TOKEN`(Bearer)/`MEMORY_SYNC_SCOPE`(可选,缺省=
@@ -246,6 +294,25 @@ export interface ServiceConfigFlat {
         maxPushEntries?: number;
         maxPullEntries?: number;
     };
+    /** #228(黑板 [3590]/[3606] 两裁):记忆检索的**向量面**接线 —— OpenAI 兼容 `/embeddings` 端点。
+     *  env 四键(+ 可选 key):`MEMORY_EMBEDDER_ENDPOINT` / `MEMORY_EMBEDDER_MODEL` / `MEMORY_EMBEDDER_DIM`
+     *  (+ `MEMORY_EMBEDDER_TIMEOUT_MS` / `MEMORY_EMBEDDER_API_KEY`)。三问:
+     *
+     *  ① **谁需要**:pg 记忆后端的部署。core 的记忆引擎三档(`vectorMode = lexical|portable|native`)不是
+     *     档位旋钮,而是「后端上限 × embedder 在场」的**推断结果**([3590] 裁①:不开档位 env —— 显式选档
+     *     只会造出「选了 native 却没 embedder」这类矛盾态)。本仓在 #228 之前从未注入过 embedder,所以
+     *     pg 部署的检索**恒 lexical**(词面 jaccard),向量列空转。配上这几键 = 该部署真正拿到语义检索。
+     *  ② **半配为何拒启**:三键里少任何一件,「向量面」都无从组装。静默忽略的后果不是功能缺席,而是
+     *     **operator 以为开了**——检索照常返回结果(词面档),质量差异只在最终答案里,任何日志都不报。
+     *     所以照 `MEMORY_SYNC_*` / `REQUIRED_ENVS_BY_LANE` 的同款姿势整拒并点名缺哪几键。
+     *  ③ **维度守卫为何是拒启不是 warn**:向量列写错维度是**静默毒库**形([3606] 裁③)——错长度的向量
+     *     既不会让 DB 报错(本仓 pg 记忆表的 embedding 是 `jsonb`,无维度约束),也不会让检索报错(维度
+     *     不匹配的行只是悄悄退回词面档),只会让「向量面开着」这句话变成谎。所以坏 DIM(非正整数)在
+     *     boot 期拒;运行期真维度不符(模型换了 / 端点指错)由 embedder 自己抛,绝不截断补零。
+     *
+     *  ⚠️ 后端门:只有 `MEMORY_ENGINE_BACKEND=pg` 收这几键 —— tidb 记忆后端 v1 无向量档(传 embedder
+     *  它自己就 fail-loud 拒),file 引擎压根没有 embedder 接缝。配错后端 = 拒启点名。 */
+    memoryEmbedder?: MemoryEmbedderConfig;
     /** design/170 件A(clay 三裁 [2687]):org 记忆准入模式。`enforce`(默认)=判决即结果;`audit`=判决
      *  照算但纯观察零行为变化(不整拒、不窄化 writeScope,只记 would-deny/would-narrow)——运维诊断位,
      *  非发布步骤(audit-first 灰度步按裁2 免除)。env `MEMORY_ORG_ADMISSION_MODE`(enumEnv 二值)。 */
@@ -908,16 +975,26 @@ export interface ServiceConfigFlat {
      *  旋钮本身缺省对现行为零影响(D1)。`STREAM_ASK_WINDOW_MARGIN_MS`,默认 10000(10s）。ttl 概念沿用既有
      *  `approvalTimeoutSec` 族,本旋钮不新增第二个 TTL 概念。 */
     streamAskWindowMarginMs: number;
-    /** #151 车3(design/172 流内审批协议)总开关 + 四个从属旋钮。**协议整体默认 OFF**——开关关闭时全链
-     *  逐字现行为:不发 `approval_request` 帧、不落 `approval_ask` 行、窗 = 既有 `DEFAULT_APPROVAL_TTL_MS`
-     *  (5min)、`askStore` 不注入协调器。理由(三问):
-     *   - 谁需要 60s 窗:开了协议的部署——approver 就盯着流、秒级应答,窗短 ⇒ 少占一条活腿、更快落到可恢复
-     *     的 park 面。这是协议的设计意图,不是随手取的数。
+    /** #151 车3(design/172 流内审批协议)总开关 + 四个从属旋钮。
+     *
+     *  **现行默认(clay 裁 2026-08-08 走 (a),#164 翻真验证后)**:`STREAM_APPROVAL_ENABLED` 默认 **true**
+     *  = 协议整体默认 **ON**;`STREAM_ASK_WINDOW_MS` 默认 **300000**(5min,与 sync 腿既有活卡窗、与
+     *  `DEFAULT_APPROVAL_TTL_MS` 对齐——「开协议」不再顺带把窗砍短)。⚠️ 版本坐标:翻转**已在树上生效**,
+     *  发布线上落在 7.4.0 之后的下一个发布,所以一台自报 7.4.0 的**已发布** worker 仍是 OFF,别只按
+     *  `/health` 的版本号推默认。显式 `STREAM_APPROVAL_ENABLED=false` 是**唯一干净还原键** ⇒ 全链逐字回到
+     *  翻转前行为:不发 `approval_request` 帧、不落 `approval_ask` 行、不起收敛器腿、窗 = 既有
+     *  `DEFAULT_APPROVAL_TTL_MS`(5min)、`askStore` 不注入协调器。
+     *
+     *  **旋钮为什么存在(2026-08-08 翻转前的成文前提,已被上面的裁定取代,留作沿革)**:那一版默认 false +
+     *  60s 窗,三问记的是那个世界——
+     *   - 谁需要 60s 窗:opt-in 开了协议的部署——approver 就盯着流、秒级应答,窗短 ⇒ 少占一条活腿、更快落到
+     *     可恢复的 park 面。
      *   - 谁被伤:①未 opt-in 的存量部署(把 5min 砍成 60s = 人离开工位 90 秒回来卡已经没了);②**park 设施
      *     不在场**的部署——窗到期后 `"unavailable"` 没有降级目的地,core fail-closed deny,60s 会把
      *     「人 90 秒后批准 = 放行」变成「拒绝」,是真行为回归。
-     *   - 补偿:把 60s 绑在**新旋钮 + 新开关**上,一个字不动 `DEFAULT_APPROVAL_TTL_MS`;两边都不伤,也不给
-     *     既有腿新增第二个 TTL 概念。
+     *   - 补偿:把 60s 绑在**新旋钮 + 新开关**上,一个字不动 `DEFAULT_APPROVAL_TTL_MS`。
+     *  ⇒ 翻真时「窗变短」这一项被从翻转里摘出(窗默认抬回 300000),被伤面①②因此消失;60s 只在运维显式设
+     *  `STREAM_ASK_WINDOW_MS=60000` 时才回来。
      *
      *  `STREAM_APPROVAL_ENABLED` / `STREAM_ASK_WINDOW_MS` / `STREAM_APPROVAL_REPLAY_MAX` /
      *  `STREAM_APPROVAL_ADMIT_MAX_PER_TASK` / `STREAM_APPROVAL_ADMIT_MAX_PER_OWNER` /
@@ -1046,7 +1123,7 @@ export type ServiceModelPlaneConfig = Pick<ServiceConfigFlat, "gatewayBaseUrl" |
  *  就是本组的门状态,故进组;`parseApprovalDomain` 的返回类型相应是 `Omit<…, "directDoorActive">`。 */
 export type ServiceApprovalConfig = Pick<ServiceConfigFlat, "approvalRequire" | "approvalDeny" | "approvalTimeoutSec" | "approvalAutoBudget" | "approvalNeverAuto" | "approvalHmacKeys" | "durableApproval" | "directApprovalDoor" | "directDoorActive" | "resourceSuspend" | "resourceSuspendTtlSec" | "askQuestionEnabled" | "questionThrottle" | "toolApprovalEnabled" | "permissionRulesEnabled" | "permissionRulesEnabledExplicit" | "streamAskWindowMarginMs" | "streamApproval" | "mcpElicitation" | "sensitiveWritePatterns" | "manualModeShellGate">;
 /** 组:memory(记忆面 + TOC 同步腿)。 */
-export type ServiceMemoryConfig = Pick<ServiceConfigFlat, "memoryEngineEnabled" | "memoryEngineDir" | "memoryEngineRemoteLaneAllowed" | "memoryEngineBackend" | "memoryScope" | "memorySync" | "memoryOrgAdmissionMode" | "memoryOrgDirectoryJson" | "memoryOrgGrantTtlMs" | "memoryOrgUnavailableBackoffMs" | "projectMemoryEnabled" | "syncImportLeaseStaleSec">;
+export type ServiceMemoryConfig = Pick<ServiceConfigFlat, "memoryEngineEnabled" | "memoryEngineDir" | "memoryEngineRemoteLaneAllowed" | "memoryEngineBackend" | "memoryScope" | "memoryPersistenceCapable" | "memorySync" | "memoryEmbedder" | "memoryOrgAdmissionMode" | "memoryOrgDirectoryJson" | "memoryOrgGrantTtlMs" | "memoryOrgUnavailableBackoffMs" | "projectMemoryEnabled" | "syncImportLeaseStaleSec">;
 /** 组:auth(鉴权 / 身份 / 治理棒)。`commandPolicy` 只有 sema-registry 腿(无 env 标量形),故 env 解析
  *  函数不产出它,但它与 `autonomy` 是同一根治理棒的两半,归本组。 */
 export type ServiceAuthConfig = Pick<ServiceConfigFlat, "authToken" | "authTokens" | "allowUnauthedWrites" | "corsOrigins" | "principalHeader" | "requirePrincipal" | "autonomy" | "commandPolicy" | "operatorPrincipals" | "principalJwtPubkeys" | "principalJwtIss" | "principalJwtAud" | "principalJwtMaxTtlSec" | "bindHost" | "bindHostSource">;

package/dist/config.d.ts

@@ -4,7 +4,7 @@ import type { ServiceConfig, ServiceConfigFlat, ServiceConfigGroups } from "./co
 /** design/158 A1: the config TYPE face lives in the leaf module config-types.ts; re-exported here so
  *  every existing `from "./config.js"` importer compiles unchanged (pure-type consumers should prefer
  *  importing config-types.js directly — a type-only leaf, no loader baggage). */
-export type { ServiceConfig, ScopedMcpServer, ImageBakeConfig, ServiceConfigFlat, ServiceConfigGroups, ServiceStoreConfig, ServiceModelPlaneConfig, ServiceApprovalConfig, ServiceMemoryConfig, ServiceAuthConfig, ServiceOrchestrationConfig, ServiceLimitsHttpConfig, ServiceObservabilityConfig, ServiceIntegrationsConfig, } from "./config-types.js";
+export type { ServiceConfig, ScopedMcpServer, ImageBakeConfig, ServiceConfigFlat, ServiceConfigGroups, ServiceStoreConfig, ServiceModelPlaneConfig, ServiceApprovalConfig, ServiceMemoryConfig, ServiceAuthConfig, ServiceOrchestrationConfig, ServiceLimitsHttpConfig, ServiceObservabilityConfig, ServiceIntegrationsConfig, MemoryEmbedderConfig, } from "./config-types.js";
 /** Parse the AUTONOMY env into a validated autonomy mode. Unset/empty → undefined (unmanaged → no extra
  *  tightening). An UNKNOWN value FAILS at startup rather than silently becoming a no-op (a typo'd `AUTONOMY=readonly`
  *  must not silently leave a deployment ungoverned — fail-loud, same discipline as numEnv). Exported so the HOT

package/dist/config.js

@@ -1257,6 +1257,32 @@ function parseMemoryEngineWord(word) {
         `(engine ON, the default) or ${MEMORY_ENGINE_OFF_WORDS.join(" | ")} (engine OFF). ` +
         `An unrecognized value used to read as "on", so a misspelled kill-switch silently kept memory injection running.`);
 }
+/**
+ * #217:`MEMORY_PERSISTENCE_CAPABLE` 的**三态**读取(core 5.26.0 `TaskSpec.memoryPersistenceCapable`)。
+ *
+ * 与 {@link parseMemoryEngineWord} 共用同一份双族词表(operator 面写法一致,别让同一台机器上的两个记忆
+ * 旋钮各认一套词),但**多一个态**:缺席/空串 ⇒ `undefined` ⇒ TaskSpec 上整键缺席 ⇒ core 走自己的推断
+ * (三态语义的 absent 腿,零迁移)。空串等同未设,与 MEMORY_ENGINE 同理由(compose 的 `${X:-}` 模板天天产它)。
+ *
+ * 不认得的词 **拒启**而不是回落:这个键是「本部署能不能替用户记住事情」的真值来源,静默倒向任何一侧都
+ * 是猜——倒向 `true` 会让一台其实存不下的部署继续给幻觉式回执(#148 原病),倒向 `false` 会让一台真有
+ * 自定义持久通道的部署对用户说假话。
+ */
+function parseMemoryPersistenceCapable(raw) {
+    if (raw === undefined)
+        return undefined;
+    const w = raw.trim().toLowerCase();
+    if (w === "")
+        return undefined;
+    if (MEMORY_ENGINE_ON_WORDS.includes(w))
+        return true;
+    if (MEMORY_ENGINE_OFF_WORDS.includes(w))
+        return false;
+    throw new Error(`env MEMORY_PERSISTENCE_CAPABLE="${raw}" is not a known on/off word — use one of: ${MEMORY_ENGINE_ON_WORDS.join(" | ")} ` +
+        `(this deployment CAN persist "remember X" — declares a channel the roster inference cannot see, and restores the ` +
+        `\`# Memory\` write instruction on a remote execution lane) or ${MEMORY_ENGINE_OFF_WORDS.join(" | ")} (it CANNOT — ` +
+        `forces the read-only disclosure). Leave it UNSET to let the engine infer from the mounted roster.`);
+}
 /** #210:SANDBOX_PKG_SOURCE 的闭集校验(词表 = README/MIGRATION 成文的四词)。`none` 由调用点的三元
  *  链先摘走(字段整个缺席),留在这里的只可能是前三词或一个手滑值。 */
 const SANDBOX_PKG_SOURCES = ["global", "cn", "custom", "none"];
@@ -1278,6 +1304,85 @@ function syncEntryCap(name, field) {
         throw new Error(`env ${name}="${raw}" must be an integer >= 1 (it is an entries-per-batch cap; an ignored cap means NO cap)`);
     return { [field]: n };
 }
+/**
+ * #228(黑板 [3590]/[3606] 两裁):`MEMORY_EMBEDDER_*` 族 —— 记忆检索向量面的**唯一**开关。
+ *
+ * 三态(与 `MEMORY_SYNC_*` 半配拒启同族):
+ *  · 三键全缺席 ⇒ `undefined`,不注入 embedder,现状零变化(检索恒 lexical 词面档);
+ *  · 半配(1~2 键)⇒ **拒启并点名缺哪几键**(REQUIRED_ENVS_BY_LANE 的报文形)。静默忽略的后果不是
+ *    功能缺席,而是 operator 以为向量面开着——检索照常出结果,差异只在答案质量里,零日志;
+ *  · 坏值(URL 不合法 / 非 http(s) / DIM 非正整数 / TIMEOUT 非法或越界)⇒ 拒启带指路(#210 A 档)。
+ *
+ * 另两条门(都是「配了但永远不生效」的死旋钮形,一律拒启而非 warn):
+ *  · `MEMORY_ENGINE_BACKEND` 必须是 `pg` —— tidb 记忆后端 v1 无向量档(传 embedder 它自己 fail-loud
+ *    拒),file 引擎没有 embedder 接缝;
+ *  · 记忆引擎本身必须开着(`MEMORY_ENGINE != off`)。
+ *
+ * 维度守卫的**位置**(诚实记档):本仓建 pg 记忆表时不传 `memoryVector`(见 boot/stores.ts 的
+ * `ensurePgMemoryEngineSchema(q)`),即 embedding 列是 `jsonb`、schema 侧**没有可对表的维度常量**;
+ * 所以 boot 期能做的只有「DIM 是正整数」,真正的维度守卫在写入路径两处:① 本仓 embedder 拿到长度
+ * 不符的响应直接抛(绝不截断/补零);② `PgMemoryEngineBackend.embeddingParam` 对长度不符的向量返回
+ * null(该行退回词面档,不写坏向量)。
+ */
+function parseMemoryEmbedder(ctx) {
+    // 空串 = 未设(compose `${X:-}` 模板天天产它,本仓一律同判)
+    const endpoint = process.env.MEMORY_EMBEDDER_ENDPOINT || undefined;
+    const model = process.env.MEMORY_EMBEDDER_MODEL || undefined;
+    const dimRaw = process.env.MEMORY_EMBEDDER_DIM || undefined;
+    const apiKey = process.env.MEMORY_EMBEDDER_API_KEY || undefined;
+    const timeoutRaw = process.env.MEMORY_EMBEDDER_TIMEOUT_MS || undefined;
+    const trio = [
+        ["MEMORY_EMBEDDER_ENDPOINT", endpoint],
+        ["MEMORY_EMBEDDER_MODEL", model],
+        ["MEMORY_EMBEDDER_DIM", dimRaw],
+    ];
+    const missing = trio.filter(([, v]) => v === undefined).map(([name]) => name);
+    if (missing.length === 3) {
+        // 三键全缺席 = 文档化的默认姿态(不注入)。但**从属**两键单独在场 = 同款半配陷阱:operator 调了
+        // 超时/配了 key,却一个向量都不会算(MEMORY_SYNC_TOKEN/SCOPE 无 URL 对称拒启的同款先例)。
+        if (timeoutRaw !== undefined || apiKey !== undefined) {
+            throw new Error(`MEMORY_EMBEDDER_TIMEOUT_MS/MEMORY_EMBEDDER_API_KEY are set but the embedder itself is not configured — refusing to start half-configured (set MEMORY_EMBEDDER_ENDPOINT, MEMORY_EMBEDDER_MODEL and MEMORY_EMBEDDER_DIM to enable the memory vector plane, or unset the other MEMORY_EMBEDDER_* keys)`);
+        }
+        return undefined;
+    }
+    // 三键缺任一(TS 也靠这一支收窄,不需要非空断言)
+    if (endpoint === undefined || model === undefined || dimRaw === undefined) {
+        throw new Error(`MEMORY_EMBEDDER_* is half-configured — missing ${missing.join(", ")}. The memory vector plane needs all three of MEMORY_EMBEDDER_ENDPOINT, MEMORY_EMBEDDER_MODEL, MEMORY_EMBEDDER_DIM; refusing to start rather than silently running lexical-only retrieval while the deployment believes vectors are on (#228).`);
+    }
+    if (!URL.canParse(endpoint)) {
+        throw new Error(`MEMORY_EMBEDDER_ENDPOINT="${endpoint}" is not a valid URL (expected e.g. https://embeddings.example.com/v1 — the OpenAI-compatible base, or the full .../embeddings endpoint)`);
+    }
+    const parsedEndpoint = new URL(endpoint);
+    const proto = parsedEndpoint.protocol;
+    if (proto !== "http:" && proto !== "https:") {
+        throw new Error(`MEMORY_EMBEDDER_ENDPOINT="${endpoint}" must be http(s) (got "${proto}") — the embedder leg is an HTTP POST to an OpenAI-compatible /embeddings face`);
+    }
+    // URL 里的 userinfo 一律拒(codex 二轮 F1):`https://user:pass@host/v1` 形把凭据种进一个会被
+    // 传输层错误、日志、PatchReport 冲突文案反复复制的字符串里 —— 脱敏只能事后擦,拒收才是源头。
+    // 需要 auth 就走 MEMORY_EMBEDDER_API_KEY(Bearer 头,不进 URL)。
+    if (parsedEndpoint.username !== "" || parsedEndpoint.password !== "") {
+        throw new Error("MEMORY_EMBEDDER_ENDPOINT must not carry credentials in the URL (user:password@host) — URL userinfo leaks into transport errors, logs and memory conflict reports. Use MEMORY_EMBEDDER_API_KEY (sent as a Bearer header) instead.");
+    }
+    const dimensions = Number(dimRaw);
+    if (!Number.isSafeInteger(dimensions) || dimensions < 1) {
+        throw new Error(`MEMORY_EMBEDDER_DIM="${dimRaw}" must be a positive integer (the embedding dimension, e.g. 1024). A wrong dimension writes wrong-length vectors into the memory embedding column, which neither the DB nor retrieval reports — the vector plane just silently degrades to the lexical floor (#228).`);
+    }
+    if (ctx.memoryEngineBackend !== "pg") {
+        throw new Error(`MEMORY_EMBEDDER_* is set but MEMORY_ENGINE_BACKEND=${ctx.memoryEngineBackend} — the vector plane exists only on the pg memory backend (the tidb backend is lexical-only in v1 and refuses an embedder; the file engine has no embedder seam). Set MEMORY_ENGINE_BACKEND=pg, or unset MEMORY_EMBEDDER_*.`);
+    }
+    if (!ctx.memoryEngineEnabled) {
+        throw new Error("MEMORY_EMBEDDER_* is set but MEMORY_ENGINE=off — the memory engine is not wired at all, so the embedder would never be called; unset one of the two (#228)");
+    }
+    return {
+        endpoint,
+        model,
+        dimensions,
+        // 活性保护:挂死的 embedder 会把整条记忆写入路径吊住(undici 默认 headers 超时 300s 太钝)。
+        // 下界 1s(比这更短的向量调用只会全轮超时);上界 5min(再长就不是超时保护了)。
+        timeoutMs: numEnvBounded("MEMORY_EMBEDDER_TIMEOUT_MS", "30000", 1000, 300_000),
+        ...(apiKey !== undefined ? { apiKey } : {}),
+    };
+}
 /** 域:memory(记忆面 + TOC 同步腿)—— 记忆引擎开关/方言/根目录、scope 缺省、同步 client 三键、项目记忆。 */
 function parseMemoryDomain(ctx) {
     const { requirePrincipal } = ctx; // 跨域入参①:多租户下记忆面 DARK(scope 缺省不铸)
@@ -1376,7 +1481,12 @@ function parseMemoryDomain(ctx) {
         // memoryScopeFor returns undefined there). An explicit MEMORY_SCOPE always wins.
         memoryEngineBackend,
         memoryScope, // hoisted above (the 142-S2.5-W1 sync-scope default consumes it)
+        // #217:三态 ⇒ 只有真表态才上键(缺席腿必须是**整键缺席**,不是 present-as-undefined —— 后者会被
+        // resolve-spec 原样搬上 TaskSpec,把 core 的「absent = 各自推断」读成一个显式表态)。
+        ...((v) => (v !== undefined ? { memoryPersistenceCapable: v } : {}))(parseMemoryPersistenceCapable(process.env.MEMORY_PERSISTENCE_CAPABLE)),
         ...(memorySync ? { memorySync } : {}),
+        // #228:向量面接线(三态解析 + 后端/引擎两门,全在 parseMemoryEmbedder 里 fail-loud)
+        ...((v) => (v !== undefined ? { memoryEmbedder: v } : {}))(parseMemoryEmbedder({ memoryEngineBackend, memoryEngineEnabled })),
         memoryOrgAdmissionMode,
         ...(memoryOrgDirectoryJson !== undefined ? { memoryOrgDirectoryJson } : {}),
         memoryOrgGrantTtlMs,
@@ -1856,7 +1966,7 @@ const APPROVAL_GROUP_KEYS = [
 ];
 const MEMORY_GROUP_KEYS = [
     "memoryEngineEnabled", "memoryEngineDir", "memoryEngineRemoteLaneAllowed", "memoryEngineBackend", "memoryScope",
-    "memorySync", "memoryOrgAdmissionMode", "memoryOrgDirectoryJson", "memoryOrgGrantTtlMs", "memoryOrgUnavailableBackoffMs",
+    "memoryPersistenceCapable", "memorySync", "memoryEmbedder", "memoryOrgAdmissionMode", "memoryOrgDirectoryJson", "memoryOrgGrantTtlMs", "memoryOrgUnavailableBackoffMs",
     "projectMemoryEnabled", "syncImportLeaseStaleSec",
 ];
 const AUTH_GROUP_KEYS = [

package/dist/governance-ask-marks.js

@@ -40,7 +40,8 @@
  *
  * 🔴 codex 交叉复审 round3 [medium](验真):`toolCallId` **不是**全局唯一的 —— 它多数情况下是**提供方**
  * 逐字给的 id(core 的 brain 层不另铸),本仓自己的代码就是这么假设的:core 把 tool-result 引用命名成
- * `tr_<sessionId>_<toolCallId>`(见 `plugins/tool-result-store-sql.ts` 的 `deleteBySession` 顶注),
+ * `tr_<sessionId>~<toolCallId>~<contentSeg>`(core 5.26.0 #119 起的四段单射形;见 `plugins/tool-result-store-sql.ts`
+ * 的 `deleteBySession` 顶注),
  * `deriveAskId` 也把 `sourceTaskId`/`runId`/`legKey` 一并入哈希。一张不分格的表会**跨任务/跨租户串味**:
  * 低熵 id(本地/自建模型服务常见的 `call_1` 之类)下,A 任务的治理标会被 B 任务的普通 ask 读走(假出处),
  * 或被 B 的一次治理放行反手清掉(丢真出处)。

package/dist/http/routes/capabilities.js

@@ -159,8 +159,11 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
             // served this task — the RESOLVED `Model.id`, not the requested `TaskSpec.model` ref … Lets a UI echo
             // 'served by X'". A grep for the identifier `effectiveModel` returns zero hits in core and that was mistaken
             // for "core doesn't have it" (search by SEMANTICS, not by identifier name). It already reaches the wire:
-            // `POST /v1/tasks` returns the TaskResult verbatim (~L1852), the SDK declares `TaskResult.model`, and this
-            // server already consumes it internally for cache-family accounting (~L1843). Pinned by
+            // `POST /v1/tasks` returns the TaskResult verbatim (`routes/tasks.ts` `sendSubmitResult` — the sync submit
+            // leg's one response mouth; design/158 A9 moved the whole sync-submit surface OUT of `http/server.ts`, so the
+            // old `~L1852` anchor into that file is dead), the SDK declares `TaskResult.model`, and this server already
+            // consumes the resolved id internally for cache-family accounting (`budget.ts` `cacheFamilyOfMirror` + its
+            // caller in `routes/side-query.ts`, NOT `http/server.ts`). Pinned by
             // `test/effective-model-echo-wire.test.ts` (real HTTP: resolved id echoed, absent key stays absent) so a
             // future projection/whitelist on this leg can't silently drop it — the `toolEndEventData`-label bug class.
             // Nothing is advertised as a capability BIT here because an additive result field needs no gate
@@ -296,6 +299,18 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
                 backend: deps.backend,
                 parkFacility: deps.checkpointStore !== undefined,
             }).active,
+            // #229(设计稿 233 稿B v2 §3):回决**理由**位在本二进制里存在的探测位 —— live
+            // `POST /v1/tool-approvals/:id/respond` 收 `note` + 回执带 `noteRecorded`,durable 回决口的三个回体
+            // 投 `decisionNote`。
+            // 🔴 **恒 true,且必须与 `noteRecorded` 同车**:老 server 对未知请求键**静默忽略 + 照回 200**
+            // (live 腿的 parser 是非 strict 的手写形),所以没有这一位时,「理由记上了」与「这台压根不认识
+            // 这个键」在 wire 上不可判别 —— 壳只能拿一个 200 猜。位在场 ⇒ 按 `noteRecorded` 逐次读结果;
+            // 位缺席 ⇒ 老 server,别渲这一格。
+            // 🔴 谓词**刻意不挂任何设施**(不是 `Boolean(deps.backend)` 之类):本位声明的是「这个二进制认识
+            // 这个键」这件版本事实,**不是**「你的理由一定会被记下」——后者是 per-call 的,由 `noteRecorded`
+            // 逐次如实回答(店缺席/店抖动时它就是 `false`)。把部署条件混进版本位,会让「says yes ⟺ 面真能用」
+            // 这句话在两个不同的问题上各说一半(与 `permissionRulesRevoke` 的存在性信号同族,见其注)。
+            approvalDecisionNote: true,
             // [1469] POST /v1/side-query(core 1.361 Runner.sideQuery 包装):一次性 brain 路由问答,无 session
             // 副作用。恒可用(runner 自带)——探测位供壳判「引擎腿在」而非 trial-by-404。
             sideQuery: true,
@@ -354,9 +369,12 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
             //    `workflowsCapability(deps)` (hardened script runner ∧ governance), boot-computed in main.ts. Falls back
             //    to the `Boolean(workflowRunStore)` proxy when the boot flag isn't wired (older callers / tests).
             //  • `workflowsList` = can durably LIST workflow runs = `Boolean(workflowRunStore)` (GET /v1/workflows* 501s
-            //    without it — list AND detail/stream, see the store gate ~L731).
+            //    without it — list AND detail/stream, see the store gate in `routes/workflows.ts`, the
+            //    `if (!deps.workflowRunStore)` → 501 `capability.self_orchestration_required` arm).
             // ⚠️ In the CURRENT service wiring these two COINCIDE: `workflowRunStore` is built IFF self-orchestration is on
-            // (InMemoryWorkflowRunStore when WORKFLOW_RUN_STORE=memory, else File — main.ts ~L527), the SAME gate that
+            // (InMemoryWorkflowRunStore when WORKFLOW_RUN_STORE=memory, else File — built in
+            // `boot/workflow-orchestration.ts`, which design/158 A10 split out of main.ts; main.ts itself no longer
+            // mentions InMemoryWorkflowRunStore at all, so the old `main.ts ~L527` anchor is dead), the SAME gate that
             // wires the safe script runner `workflowsCapability` checks → `Boolean(workflowRunStore)` ≡ `workflowsCapability`
             // always today. So this split is core's FORWARD-LOOKING orthogonal-axes CONTRACT, NOT a fix for a live
             // divergence (the earlier "memory backend → no store → divergence" framing was WRONG — InMemory IS a store;