@sema-agent/server 7.3.0 → 7.5.0

package/dist/config-types.d.ts

@@ -9,6 +9,7 @@ import type { SealedKeyPoison } from "./sealed-key.js";
 import type { McpServerSpec, Model, ModelRoles } from "@sema-agent/core";
 import type { ApprovalHmacKey, PrincipalJwtKey } from "./auth-keys.js";
 import type { ElicitationThrottle } from "./elicitation.js";
+import type { QuestionThrottle } from "./question.js";
 import type { InfraCostRates } from "./observability/cost-taxonomy.js";
 import type { Autonomy, CommandRule } from "./runtime-governance.js";
 /** A sema-registry MCP server resolved to a core spec (env-NAME refs already → real values) plus the
@@ -24,12 +25,12 @@ export interface ScopedMcpServer {
 /** #151 车3(design/172 流内审批协议)的配置面。总开关默认 **false**;四个从属旋钮只在开关为真时生效
  *  (语义与「谁需要 / 谁被伤 / 什么补偿」三问见 `ServiceConfigFlat.streamApproval` 的注)。 */
 export interface StreamApprovalConfig {
-    /** 协议总开关。`STREAM_APPROVAL_ENABLED`,默认 **false**。关 ⇒ 全链逐字现行为。
+    /** 协议总开关。`STREAM_APPROVAL_ENABLED`,默认 **true**(clay 裁 2026-08-08,#164 翻真验证后;7.5.0 起)。显式 false ⇒ 全链逐字 7.3.0 前行为(唯一干净还原键)。
      *  翻真要等回决端点(车4)与对账收敛器(车5)到位——在此之前是个不完整协议(有卡无正规回决口、
      *  有 PARKING 无收敛器、跨副本回决无唤醒路径)。 */
     enabled: boolean;
     /** 开关为真时作为 `ToolApprovalCoordinator` 的 `ttlMs`(design/172 §3.3 的「配置窗默认」)。
-     *  `STREAM_ASK_WINDOW_MS`,默认 **60000**。`0` = 运维显式关窗 ⇒ 恒 park(§3.3 窗=0 语义)。
+     *  `STREAM_ASK_WINDOW_MS`,默认 **300000**(同裁与 sync 腿既有 5min 活卡窗对齐)。`0` = 运维显式关窗 ⇒ 恒 park(§3.3 窗=0 语义)。
      *  开关为假 ⇒ 本值不参与,窗保持既有 `DEFAULT_APPROVAL_TTL_MS`(5min)。 */
     windowMs: number;
     /** 开流重放(§5)每次最多投几张未决卡——**读面**的帽,超出只投最新的并记一次 warn,开流不失败。
@@ -748,12 +749,28 @@ export interface ServiceConfigFlat {
      *  facts only ride when the deployment actually knows them (image binding/pkgSource/egress), absent = block
      *  unchanged. `SANDBOX_ENV_FACTS=false` opts out. */
     envFactsEnabled: boolean;
-    /** ③ sensitive-path write DENY set (core 1.295 `createSensitivePathPolicy`, composed into the fs-write gate
-     *  fold on host-semantics lanes — task-settings.ts). The PATTERN SET is core's call (RECOMMENDED_SENSITIVE_PATTERNS
-     *  — .env/.ssh/keys/.git hooks+config/cloud creds/histories, rationale documented core-side); the server only
-     *  passes it through. `SENSITIVE_WRITE_PATTERNS` (comma-separated): explicitly set = FULL REPLACEMENT of the
-     *  recommended set (not a merge); `off` or an empty value = disabled (empty array); unset = core's recommended
-     *  set. Deny composes deny-wins, so a session exemption / acceptEdits auto-allow never crosses it. */
+    /** ③ sensitive-path write DENY set (core 1.295 `createSensitivePathPolicy`). The PATTERN SET is core's call
+     *  (RECOMMENDED_SENSITIVE_PATTERNS — .env/.ssh/keys/.git hooks+config/cloud creds/histories, rationale
+     *  documented core-side); the server only passes it through. `SENSITIVE_WRITE_PATTERNS` (comma-separated):
+     *  explicitly set = FULL REPLACEMENT of the recommended set (not a merge); `off` or an empty value = disabled
+     *  (empty array); unset = core's recommended set.
+     *  🔴 **施加点 = governance 层,无条件(#177 / [2951] issue #29;搬家前「composed into the fs-write gate fold
+     *  on host-semantics lanes — task-settings.ts」的旧描述已作废)**:与 `AUTONOMY`/`MANUAL_MODE_SHELL_GATE`
+     *  同拍,resolve-spec 预铸成一条纯 DENY policy 递给 `applyRuntimeGovernance`,**不看客户端 settings/
+     *  permissionMode 的在场性、不看落在哪个模式臂、不看执行 lane**。旧家把它唯一的合成点挂在
+     *  `deriveSettingsPolicy` 的 fs-write gate 闭包里,而那个闭包只在 default/auto/acceptEdits 三臂被调用 ⇒
+     *  `bypassPermissions` / `permissionMode` 键缺席(headless `-p` 的默认姿势)/ body 连 settings 都没有
+     *  这三形整条 DENY 腿不建(邻仓 46 格真机矩阵实证)。裁决 env 仍按 lane 分形(host 真 fs / 沙箱
+     *  `DeferredSandboxPathEnv` 代理),与 fs-write ask 门同一份、单点构造。
+     *  折叠仍是 deny-wins(tightenTaskSpec ⇒ combinePolicies),所以会话豁免 / acceptEdits 自动 allow /
+     *  客户端 settings allow 一律越不过它;非守卫目标该 policy 返回 `action:"allow"`(core 的 ToolPolicy
+     *  没有「无意见」第三态;这个 allow 在 combinePolicies 的 deny/ask 优先折叠里不构成一票,故在折叠
+     *  语境下等价于弃权)⇒ 不给 bypass 加 ask 门。
+     *  ⚠️ 非法模式(不含任何路径段,如 `"/"`)在 boot 期 fail-loud(createResolveSpec 先编译一次)——
+     *  **对存量部署是行为变更**:搬家前这种坏值只在 default/auto/acceptEdits 三臂上每请求炸,只跑
+     *  headless 的部署带着坏值也能起服务;现在起不来(方向=运维当场看见,而不是每任务一条 500)。
+     *  ⚠️ 沙箱 lane 的相对形写目标有一格今天无人裁决(cwd 里的守卫段看不见)——边界与两条收口路
+     *  成文在 boot/resolve-spec.ts 的 `RelativeTargetLexicalEnv` 类注。 */
     sensitiveWritePatterns: string[];
     /** [1557]§四 opt-in (cli[1555]② finding, core[1556] suggested mechanism): the CC manual-family permission
      *  modes (default/auto/acceptEdits) gate every fs WRITE hand tool (Write/Edit/NotebookEdit) but never touched
@@ -831,6 +848,12 @@ export interface ServiceConfigFlat {
      *  stream (the durable-suspend leg is wired separately). A CC cap → posture-gated (single-user turnkey →
      *  ON; multi-tenant opt-in); `ASK_QUESTION_ENABLED=true/false` overrides. */
     askQuestionEnabled: boolean;
+    /** #166 裁2:AskUserQuestion 的**裁量窗**——每 run 腿的并发帽 / 总量帽 / 无人应答的释放窗。窗用尽或到期
+     *  不是拒绝、也不是替人作答:协调器报 `unavailable`,落点(durable park / 非 durable 合成续跑)归 core。
+     *  `QUESTION_MAX_CONCURRENT_PER_RUN`(默认 2)/ `QUESTION_MAX_TOTAL_PER_RUN`(20)/ `QUESTION_TTL_MS`
+     *  (300000),越界值启动期响亮拒(照 `MCP_ELICITATION_*` 同门,不静默夹取)。缺席 ⇒ 协调器出厂窗
+     *  {@link import("./question.js").DEFAULT_QUESTION_THROTTLE}(与本旋钮族默认逐字同值)。 */
+    questionThrottle?: QuestionThrottle;
     /** [816]/[820]② live tool-approval HITL — mount the ToolApprovalCoordinator on `RunnerDeps.onAsk` + the
      *  `POST /v1/tool-approvals/:id/respond` route so a policy `ask` (the fs-write gate, ask-lists, non-durable safety
      *  asks) routes to the live human as the CC three-choice card on the run's stream (core 1.290 sync-ask leg). A CC
@@ -975,7 +998,7 @@ export type ServiceStoreConfig = Pick<ServiceConfigFlat, "sessionBackend" | "ses
 export type ServiceModelPlaneConfig = Pick<ServiceConfigFlat, "gatewayBaseUrl" | "gatewayApiKey" | "gatewayFallbackUrls" | "gatewayMaxRetries" | "anthropic" | "resilience" | "model" | "models" | "modelApiKeyEnv" | "modelApiKeys" | "modelQuotaWeights" | "tiers" | "projects" | "roles" | "cascadeLadder" | "degrade">;
 /** 组:approval(审批 / HITL 门)。`directDoorActive` 无 env 解析腿(装配层三域合取的产物),但语义上
  *  就是本组的门状态,故进组;`parseApprovalDomain` 的返回类型相应是 `Omit<…, "directDoorActive">`。 */
-export type ServiceApprovalConfig = Pick<ServiceConfigFlat, "approvalRequire" | "approvalDeny" | "approvalTimeoutSec" | "approvalAutoBudget" | "approvalNeverAuto" | "approvalHmacKeys" | "durableApproval" | "directApprovalDoor" | "directDoorActive" | "resourceSuspend" | "resourceSuspendTtlSec" | "askQuestionEnabled" | "toolApprovalEnabled" | "streamAskWindowMarginMs" | "streamApproval" | "mcpElicitation" | "sensitiveWritePatterns" | "manualModeShellGate">;
+export type ServiceApprovalConfig = Pick<ServiceConfigFlat, "approvalRequire" | "approvalDeny" | "approvalTimeoutSec" | "approvalAutoBudget" | "approvalNeverAuto" | "approvalHmacKeys" | "durableApproval" | "directApprovalDoor" | "directDoorActive" | "resourceSuspend" | "resourceSuspendTtlSec" | "askQuestionEnabled" | "questionThrottle" | "toolApprovalEnabled" | "streamAskWindowMarginMs" | "streamApproval" | "mcpElicitation" | "sensitiveWritePatterns" | "manualModeShellGate">;
 /** 组:memory(记忆面 + TOC 同步腿)。 */
 export type ServiceMemoryConfig = Pick<ServiceConfigFlat, "memoryEngineEnabled" | "memoryEngineDir" | "memoryEngineRemoteLaneAllowed" | "memoryEngineBackend" | "memoryScope" | "memorySync" | "memoryOrgAdmissionMode" | "memoryOrgDirectoryJson" | "memoryOrgGrantTtlMs" | "memoryOrgUnavailableBackoffMs" | "projectMemoryEnabled" | "syncImportLeaseStaleSec">;
 /** 组:auth(鉴权 / 身份 / 治理棒)。`commandPolicy` 只有 sema-registry 腿(无 env 标量形),故 env 解析

package/dist/config.d.ts

@@ -137,7 +137,11 @@ export declare function applyAutoCompactWindow(m: Model, explicit?: number): voi
  *      (常驻进程不 crash);
  *   ③ per-request 腿(`settings.permissions.{ask,deny}`,task-settings.ts)—— 该请求 422。
  *
- * 三种拼法:
+ * 四种拼法:
+ *   - CC 形规则条目(`Bash(ps:*)`/`Edit(src/**)`,#186 [3047]§七 装机实测):CC 的权限规则 DSL 写法。这些
+ *     名单比的是**整串工具名**,带括号那串不是任何活工具的名字 ⇒ 永不匹配。指引=按命令名走
+ *     `runtime.commandPolicy`,整条 shell 进门走 `MANUAL_MODE_SHELL_GATE=always`。判别式见
+ *     {@link findCcRuleFormNames}(它同时是 `allow` 腿的**唯一**判据,见下方例外说明)。
  *   - 退役名(`bash`/`Task`/`KillShell`…):core `RETIRED_TOOL_NAMES` 静态表,指引=现役名。
  *   - pre-prefix 短名(`figma__x`):v4 自动加前缀的折叠面已删,实挂名恒带 `mcp__`,指引=补全前缀。
  *   - 不完整 MCP 名(`mcp__`、`mcp__figma`):前缀对但缺段——MCP 实挂名恒是 `mcp__<server>__<tool>` 三段形,
@@ -151,6 +155,7 @@ export interface UnmatchableToolName {
     name: string;
     guidance: string;
 }
+export declare function findCcRuleFormNames(names: readonly string[]): UnmatchableToolName[];
 export declare function findUnmatchableToolNames(names: readonly string[]): UnmatchableToolName[];
 /** {@link findUnmatchableToolNames} 的成句形——三条腿的文案同源(只有前缀/出口不同)。 */
 export declare function formatUnmatchableToolNames(source: string, bad: readonly UnmatchableToolName[]): string;

package/dist/config.js

@@ -5,6 +5,7 @@ import { CODE_AGENT_PROMPT, formatUserScope, isThinkingLevel, PROTOCOL_TABLE, pr
 import { ROSTER_PRIMARY_ROLES, ROSTER_CHEAP_ROLES } from "@sema-agent/registry-core";
 import { parseApprovalHmacKeys, parsePrincipalJwks } from "./auth-keys.js"; // design/158 A4: the parser leaf — NOT security.js (base config layer must not value-import the 55KiB auth module)
 import { DEFAULT_ELICITATION_THROTTLE } from "./elicitation.js";
+import { DEFAULT_QUESTION_THROTTLE } from "./question.js";
 function csv(name) {
     return (process.env[name] ?? "")
         .split(",")
@@ -878,9 +879,43 @@ function parseDegradeOn(words) {
     }
     return words;
 }
+/**
+ * #186 — the CC-rule-form arm, split out because it is the ONE arm that also judges an **allow** list.
+ *
+ * The general "unmatchable name" judgment deliberately spares `allow` (a mistyped live name leaves the allowlist
+ * effectively empty ⇒ everything is denied ⇒ fail-CLOSED and immediately visible). A CC-form entry is a different
+ * animal: `allow: ["Bash(ps:*)"]` is what a CC user writes to get FEWER prompts, and what they actually get is
+ * "only a tool literally named `Bash(ps:*)` may run" ⇒ Bash unavailable, with no warning anywhere. That is a
+ * spelling-FAMILY error, not a typo, so it is refused on every list — with the two knobs that really do the job.
+ *
+ * 本批**不实现** CC 形语义(参数级规则是扩面,另候裁);判据只认括号的在场,残形(`Bash(ps`)同样拒——
+ * 半个括号一样永不匹配活名。
+ */
+function ccRuleFormGuidance(name) {
+    if (!name.includes("(") && !name.includes(")"))
+        return undefined;
+    return (`CC-form rule specifier — this list matches the WHOLE tool name verbatim, so it can only ever match a tool literally named "${name}". ` +
+        `Drop the parentheses to gate the tool itself ("${name.split("(")[0] ?? name}"); ` +
+        `to decide per COMMAND use \`runtime.commandPolicy\` ({command, decision} — bare argv[0] names); ` +
+        `to put every shell call behind an approval use MANUAL_MODE_SHELL_GATE=always`);
+}
+export function findCcRuleFormNames(names) {
+    const out = [];
+    for (const name of names) {
+        const guidance = ccRuleFormGuidance(name);
+        if (guidance !== undefined)
+            out.push({ name, guidance });
+    }
+    return out;
+}
 export function findUnmatchableToolNames(names) {
     const out = [];
     for (const name of names) {
+        const ccGuidance = ccRuleFormGuidance(name);
+        if (ccGuidance !== undefined) {
+            out.push({ name, guidance: ccGuidance });
+            continue;
+        }
         const retired = RETIRED_TOOL_NAMES.get(name);
         if (retired !== undefined) {
             out.push({ name, guidance: retired });
@@ -902,26 +937,36 @@ export function findUnmatchableToolNames(names) {
 }
 /** {@link findUnmatchableToolNames} 的成句形——三条腿的文案同源(只有前缀/出口不同)。 */
 export function formatUnmatchableToolNames(source, bad) {
-    return (`${source} names tool(s) that can never match a live tool (core 5.0.0 RB-476 — the alias/auto-prefix folds are gone): ` +
+    return (`${source} names tool(s) that can never match a live tool (these lists are RAW whole-name comparisons — core 5.0.0 RB-476 removed the alias/auto-prefix folds): ` +
         bad.map((b) => `${b.name} → ${b.guidance}`).join("; "));
 }
 /**
  * #151 流内审批协议(design/172)的九键段(车3 刀 3a 五键 + 车5 收敛器四键)。
  *
- * **总开关默认 false** ⇒ 全链逐字现行为(不发 approval_request、不落 ask 行、不起收敛器腿、窗仍是
- * `DEFAULT_APPROVAL_TTL_MS`)。窗/帽四键沿用 `numEnv` fail-loud 形(坏形启动期炸,不静默折 NaN);
+ * **总开关默认 true**(clay 裁 2026-08-08 走 (a),#164 翻真验证后)。⚠️ 版本坐标:翻转**已在树上生效**,
+ * 发布线上它落在 7.4.0 之后的下一个发布(CHANGELOG `Unreleased` 段,预计 7.5.0)—— 所以一台自报 7.4.0
+ * 的**已发布** worker 仍是 OFF,而拿 main 构建的 worker 已是 ON。别只按 `/health` 的版本号推默认。显式
+ * `STREAM_APPROVAL_ENABLED=false` 是**唯一干净还原键** ⇒ 全链逐字回到翻转前行为(不发
+ * approval_request、不落 ask 行、不起收敛器腿、窗仍是 `DEFAULT_APPROVAL_TTL_MS`)。同一裁定把窗默认
+ * 从 60s 抬到 300000(= `DEFAULT_APPROVAL_TTL_MS` 的 5min),于是「开协议」不再顺带把窗砍短 ——
+ * 当年默认 false + 60s 窗那一版的「谁需要 / 谁被伤 / 什么补偿」成文记录在 `config-types.ts` 的
+ * `ServiceConfigFlat.streamApproval` 注里(读它时记得它记的是**翻转前**的前提)。
+ * 窗/帽四键沿用 `numEnv` fail-loud 形(坏形启动期炸,不静默折 NaN);
  * 车5 的四键一律 **`numEnvBounded`**(§9 C6:batch 整数 ≥1 有上帽,grace/TTL 非负有界)——它们直接
  * 决定 reaper 每 tick 的库压与「多久算遗孤」,一个手滑的 `0` 或 `1e12` 都是运维事故面。
  *
- * 🔴 跨旋钮不变量(§9 C6,`#157` 三分类 P 族姿势):`ADHOC_GRACE < ORPHAN_TTL`。破坏形**拒启** ——
- * 若 adhoc 宽限 ≥ 遗孤 TTL,判据 5 会先于判据 4 触发,一条 adhoc 腿拿到的归因就成了
+ * 🔴 跨旋钮不变量(§9 C6,`#157` 三分类 P 族姿势):**`WINDOW + ADHOC_GRACE < ORPHAN_TTL`**。破坏形
+ * **拒启** —— 判据 4 在 `expiresAtMs + ADHOC_GRACE` 触发而 `expiresAtMs ≈ createdAtMs + WINDOW`,判据 5
+ * 在 `createdAtMs + ORPHAN_TTL` 触发;不等式不成立时判据 5 会先于判据 4 到,一条 adhoc 腿拿到的归因就成了
  * `orphan_ttl_exceeded`(「遗孤兜底」)而不是 `adhoc_leg_no_durable_domain`(「结构上无对账域」),
- * 审计面从此读不出真实成因。默认值(60s vs 7d)自然满足;只有显式改坏才会撞上。
+ * 审计面从此读不出真实成因。⚠️ **窗那一项不能省**(本注上一版只写 `ADHOC_GRACE < ORPHAN_TTL`,与下方
+ * 真校验和它的 codex C7 论证矛盾):只比宽限会漏掉窗,例如 WINDOW 与 ORPHAN_TTL 等长时校验放行但遗孤
+ * 兜底必定先到。默认值(300s + 60s vs 7d)自然满足;只有显式改坏才会撞上。
  */
 function streamApprovalConfig() {
     const cfg = {
-        enabled: boolEnv("STREAM_APPROVAL_ENABLED", false),
-        windowMs: numEnv("STREAM_ASK_WINDOW_MS", "60000"),
+        enabled: boolEnv("STREAM_APPROVAL_ENABLED", true), // clay 裁 2026-08-08 走 (a):#164 翻真验证后默认 ON;false=唯一干净还原键
+        windowMs: numEnv("STREAM_ASK_WINDOW_MS", "300000"), // 同裁抬 5min:「窗变短」从翻真里摘出,与 sync 腿既有活卡窗对齐
         replayMax: numEnv("STREAM_APPROVAL_REPLAY_MAX", "50"),
         admitMaxPerTask: numEnv("STREAM_APPROVAL_ADMIT_MAX_PER_TASK", "32"),
         admitMaxPerOwner: numEnv("STREAM_APPROVAL_ADMIT_MAX_PER_OWNER", "256"),
@@ -998,13 +1043,21 @@ function parseApprovalDomain(ctx) {
             },
         },
         askQuestionEnabled: postureOn("ASK_QUESTION_ENABLED"), // §4④ AskUserQuestion live HITL; posture-gated (single-user → ON)
+        // #166 裁2:AskUserQuestion 裁量窗三旋钮,姿势照 MCP_ELICITATION_* 抄(bounded ⇒ 越界启动期拒,不静默
+        // 夹取)。默认值 = 协调器出厂窗逐字(纯旋钮化,零行为改动)。
+        questionThrottle: {
+            maxConcurrentPerRun: numEnvBounded("QUESTION_MAX_CONCURRENT_PER_RUN", String(DEFAULT_QUESTION_THROTTLE.maxConcurrentPerRun), 1, 64),
+            maxTotalPerRun: numEnvBounded("QUESTION_MAX_TOTAL_PER_RUN", String(DEFAULT_QUESTION_THROTTLE.maxTotalPerRun), 1, 10_000),
+            ttlMs: numEnvBounded("QUESTION_TTL_MS", String(DEFAULT_QUESTION_THROTTLE.ttlMs), 1_000, 3_600_000),
+        },
         toolApprovalEnabled: postureOn("TOOL_APPROVAL_ENABLED"), // [816]/[820]② live tool-approval HITL; posture-gated (single-user → ON), mirrors askQuestion
         // #151 车2(design/172 §3.3 D3):ToolApprovalCoordinator 窗长三元的安全余量。numEnv fail-loud 形,
         // 照邻居旋钮(approvalTimeoutSec 等)抄——坏形（非数字)在启动期炸,不静默折成 NaN。
         streamAskWindowMarginMs: numEnv("STREAM_ASK_WINDOW_MARGIN_MS", "10000"),
-        // #151 车3 刀 3a(design/172 流内审批协议):五键。**总开关默认 false** ⇒ 全链逐字现行为(不发
-        // approval_request、不落 ask 行、窗仍是 DEFAULT_APPROVAL_TTL_MS)。窗/帽四键与邻居旋钮同 numEnv
-        // fail-loud 形——坏形在启动期炸,不静默折 NaN。语义与三问分析见 config-types.ts 的 StreamApprovalConfig。
+        // #151 车3 刀 3a + 车5(design/172 流内审批协议):九键。默认极性 / 窗值 / 解析形 / 跨旋钮不变量
+        // **一处成文** = 本文件 `streamApprovalConfig()` 的头注,这里不复述 —— 复述的两份必然各自漂,这条注
+        // 的上一版正是这么漂的(默认翻 ON 之后它还写着「总开关默认 false」整整一版)。
+        // 三问记录(翻转前那一版)见 config-types.ts 的 StreamApprovalConfig。
         streamApproval: streamApprovalConfig(),
         // [875]a 成文:0(缺省)= durable HITL 无限期等人,时间型 reapSuspended 不跑;file/memory lane 的回收
         // 探针只在 DURABLE_APPROVAL=true 时注入(无 durable 的部署两只 suspended 回收器恒 NO-OP,parked 行的
@@ -1483,7 +1536,7 @@ const MODEL_PLANE_GROUP_KEYS = [
 const APPROVAL_GROUP_KEYS = [
     "approvalRequire", "approvalDeny", "approvalTimeoutSec", "approvalAutoBudget", "approvalNeverAuto",
     "approvalHmacKeys", "durableApproval", "directApprovalDoor", "directDoorActive", "resourceSuspend",
-    "resourceSuspendTtlSec", "askQuestionEnabled", "toolApprovalEnabled", "streamAskWindowMarginMs", "streamApproval", "mcpElicitation",
+    "resourceSuspendTtlSec", "askQuestionEnabled", "questionThrottle", "toolApprovalEnabled", "streamAskWindowMarginMs", "streamApproval", "mcpElicitation",
     "sensitiveWritePatterns", "manualModeShellGate",
 ];
 const MEMORY_GROUP_KEYS = [

package/dist/elicitation.js

@@ -27,6 +27,7 @@
 import { AsyncLocalStorage } from "node:async_hooks";
 import { uuidv7, delimitUntrusted } from "@sema-agent/core";
 import { redactSecrets, redactDeep } from "./trace/redact.js";
+import { recordFailOpen } from "./observability/fail-open.js";
 /** Size bounds on the UNTRUSTED server-controlled payload (the throttle bounds COUNT, these bound SIZE — an
  *  opted-in-but-hostile server otherwise amplifies a multi-MB prompt/schema into the durable log + SSE socket).
  *  The message is a human-facing prompt (a few KB is ample); a requestedSchema over the cap is dropped (the form
@@ -187,6 +188,8 @@ export class ElicitationCoordinator {
             rc.lastByServer.set(req.server, t);
         }
         catch {
+            // #157:投递失败 ⇒ decline。方向已是 fail-closed(问不到人就是拒),缺的只是留痕。
+            recordFailOpen("server.elicitation.open-frame-undelivered", `elicitation=${id} server=${req.server}`);
             settle({ action: "decline" }); // inflight rolled back in settle
         }
         const answer = await answerP;
@@ -195,7 +198,8 @@ export class ElicitationCoordinator {
         // ordering-uncritical: the shell already has the answer via respond; a late/lost dismiss is cosmetic.
         void Promise.resolve()
             .then(() => ctx.emit({ type: "elicitation_complete", elicitationId: id, mcpServerName: req.server, action: answer.action, serverNowMs: this.now() }))
-            .catch(() => undefined);
+            // #157:F 类兜底,与 question.ts 的孪生面同形同 tag 形(丢收尾渲染,不丢答案)。
+            .catch(() => recordFailOpen("server.elicitation.complete-breadcrumb-dropped", `elicitation=${id}`));
         return answer;
     };
     /** `POST /v1/elicitations/:id/respond` — resolve a parked elicitation with the shell's answer. Owner-gated with a

package/dist/env-facts.d.ts

@@ -78,7 +78,9 @@ export declare function ensureScratchpadDir(localDataRoot: string, sessionId: st
  *   - 绝对路径 + ≤{@link MAX_PATH}(core 渲染上限同源,超限=core 只能给模型假路径)+ canonical
  *     深度 ≥3(裸 /、/tmp、/home 一整块系统目录不能当豁免域;穿越形按 resolve 归一后判);
  *   - mkdir -p 确保存在(gate 的 canonicalize 与 core 根围栏都要真目录)。
- *  敏感路径的最后一道在 core gate 折叠里(sensitivePatterns deny 恒赢,exemptDirs 越不过)。 */
+ *  敏感路径的最后一道**不在**写门折叠里(#177 起搬家):守卫集 `SENSITIVE_WRITE_PATTERNS` 由
+ *  governance 拍(boot/resolve-spec.ts → applyRuntimeGovernance)无条件铸成 DENY 基线,经 tightenTaskSpec
+ *  与写门 deny-wins 折叠 —— 结论不变(deny 恒赢,本函数放出的 exemptDirs 越不过它),但施加点已换。 */
 export declare function acceptShellScratchpadDir(raw: unknown, opts: {
     requirePrincipal: boolean;
     hostSemanticsLane: boolean;

package/dist/env-facts.js

@@ -113,7 +113,9 @@ export async function ensureScratchpadDir(localDataRoot, sessionId) {
  *   - 绝对路径 + ≤{@link MAX_PATH}(core 渲染上限同源,超限=core 只能给模型假路径)+ canonical
  *     深度 ≥3(裸 /、/tmp、/home 一整块系统目录不能当豁免域;穿越形按 resolve 归一后判);
  *   - mkdir -p 确保存在(gate 的 canonicalize 与 core 根围栏都要真目录)。
- *  敏感路径的最后一道在 core gate 折叠里(sensitivePatterns deny 恒赢,exemptDirs 越不过)。 */
+ *  敏感路径的最后一道**不在**写门折叠里(#177 起搬家):守卫集 `SENSITIVE_WRITE_PATTERNS` 由
+ *  governance 拍(boot/resolve-spec.ts → applyRuntimeGovernance)无条件铸成 DENY 基线,经 tightenTaskSpec
+ *  与写门 deny-wins 折叠 —— 结论不变(deny 恒赢,本函数放出的 exemptDirs 越不过它),但施加点已换。 */
 export async function acceptShellScratchpadDir(raw, opts) {
     if (typeof raw !== "string" || raw.length === 0)
         return undefined; // additive 常态:键缺席/异形,零告警

package/dist/fleet/fleet-bus.d.ts

@@ -318,7 +318,12 @@ export declare class FleetEventBus {
         type: "snapshot";
     }>;
     /** Subscribe to deltas. Returns an unsubscribe thunk. The caller typically sends `snapshot()` first, then every
-     *  delta this delivers — the snapshot+delta sequence is the live fleet view. */
+     *  delta this delivers — the snapshot+delta sequence is the live fleet view.
+     *
+     *  每个回调各自隔离(#183 复审 R3 HIGH):扇出是同步的,修前一个抛错的订阅方会把异常传回**发布方**——
+     *  而发布方是 JournalingWorkflowRunStore.put/update 的投影点,core 持久化对 put 抛错 catch{} 且不推进
+     *  storeRev ⇒ durable 行冻在 running 而 notify 已 ack,无恢复路径。投影消费方永远不该能楔死 durable
+     *  写路;抛错记 {@link recordFailOpen}(F 类,登记闸),不上抛、不影响其余订阅方。 */
     subscribe(cb: (frame: FleetFrame) => void): () => void;
     /** Live counts (test/observability). */
     get size(): {

package/dist/fleet/fleet-bus.js

@@ -21,6 +21,7 @@
  * replica-local). A cross-replica fleet roll-up is a fleet-token-gated trace-API concern (separate), not this.
  */
 import { EventEmitter } from "node:events";
+import { recordFailOpen } from "../observability/fail-open.js";
 import { redactSecrets } from "../trace/redact.js";
 /** [2687-cli] 幽灵行案的单源判别:一条 `task_notification` 只有在 **agent 族 × 终态** 时才允许打
  *  `onChildTerminal`(fleet「subagent 树」只渲 agent 子代)。`background_bash`/`monitor`/`external`
@@ -121,10 +122,31 @@ export class FleetEventBus {
         return { type: "snapshot", tasks: [...this.tasks.values()], workflows: [...this.workflows.values()], ts: this.now() };
     }
     /** Subscribe to deltas. Returns an unsubscribe thunk. The caller typically sends `snapshot()` first, then every
-     *  delta this delivers — the snapshot+delta sequence is the live fleet view. */
+     *  delta this delivers — the snapshot+delta sequence is the live fleet view.
+     *
+     *  每个回调各自隔离(#183 复审 R3 HIGH):扇出是同步的,修前一个抛错的订阅方会把异常传回**发布方**——
+     *  而发布方是 JournalingWorkflowRunStore.put/update 的投影点,core 持久化对 put 抛错 catch{} 且不推进
+     *  storeRev ⇒ durable 行冻在 running 而 notify 已 ack,无恢复路径。投影消费方永远不该能楔死 durable
+     *  写路;抛错记 {@link recordFailOpen}(F 类,登记闸),不上抛、不影响其余订阅方。 */
     subscribe(cb) {
-        this.emitter.on("frame", cb);
-        return () => this.emitter.off("frame", cb);
+        const isolated = (frame) => {
+            try {
+                cb(frame);
+            }
+            catch (err) {
+                // detail 构造自身也包住:抛出值若带会抛错的 toString,String() 本身会抛并逃出隔离层(fresh 复审观察项)。
+                let detail = "subscriber threw a value whose String() also threw";
+                try {
+                    detail = String(err);
+                }
+                catch {
+                    /* keep the fallback detail */
+                }
+                recordFailOpen("server.fleet.subscriber-callback-threw", detail);
+            }
+        };
+        this.emitter.on("frame", isolated);
+        return () => this.emitter.off("frame", isolated);
     }
     /** Live counts (test/observability). */
     get size() {

package/dist/governance-ask-marks.d.ts

@@ -0,0 +1,31 @@
+/** 标记通道的活对象(CLAUDE.md 工厂命名律:有方法 ⇒ `create*`)。**一格 scope 的视图**。 */
+export interface GovernanceAskMarks {
+    /**
+     * 写下「这次工具调用的门**当前**是不是治理层给的」。
+     *
+     * 🔴 为什么是 set 而不是只加不减(codex 交叉复审 round2 [medium],验真):**同一个 `toolCallId` 会被
+     * 复查**。core 的 `recheckApprovedEdit`(`prepare-task.js`)在人编辑了 args 之后拿**同一个**
+     * `creq.toolCallId` 重跑策略链,并可能就此再产一只 ask。若只加不减,「原始 args 治理层要问 / 编辑后
+     * 治理层放行、由**别的**策略提出第二问」这条真实路径会让第二张卡挂着一个陈旧的治理标 —— 而
+     * `isMarked` 又是非消费式的,这个假出处会一直传下去。所以每次治理层裁决都**如实覆写**本格。
+     */
+    setMarked(toolCallId: string, marked: boolean): void;
+    /** 回查(**非消费式**)。空串/缺席一律 false —— 没有身份就没有证据。 */
+    isMarked(toolCallId: string | undefined): boolean;
+    /** 测试用:清掉本视图能看到的格。 */
+    clear(): void;
+    /** 测试/可观测:本视图内的标记数。 */
+    size(): number;
+}
+/** 一张独立的标记表(不进程共享)。生产路径用的是下面 `governanceAskMarksFor` 给出的**分格视图**;
+ *  本工厂给测试(与将来的多实例形)一个不依赖任何环境的干净表。 */
+export declare function createGovernanceAskMarks(opts?: {
+    max?: number;
+}): GovernanceAskMarks;
+/** 进入一条 run 腿的标记作用域(唯一调用点 = `ToolApprovalCoordinator.runWithContext`)。 */
+export declare function runWithGovernanceAskScope<T>(scope: string, fn: () => T): T;
+/** **写侧**入口:当前异步作用域那一格的视图;作用域外 = `undefined`(写 no-op,见顶注)。 */
+export declare function currentGovernanceAskMarks(): GovernanceAskMarks | undefined;
+/** **读侧**入口:按**显式** scope 取视图(读侧不读 ALS —— 理由见顶注 round5 那段)。 */
+export declare function governanceAskMarksFor(scope: string): GovernanceAskMarks;
+//# sourceMappingURL=governance-ask-marks.d.ts.map

package/dist/governance-ask-marks.js

@@ -0,0 +1,122 @@
+/**
+ * [2942]/[2943] `governanceForced` 的**判定缝** —— operator 治理层产的 ask 在 server 进程内的标记通道。
+ *
+ * 🔴 为什么需要一条 out-of-band 通道(侦察结论,亲验装树 core 5.16.x dist):
+ * `PermissionResult.decisionReason`(`"rule" | "mode" | "hook" | "safety" | "classifier"`)**到不了帧铸点**。
+ * core 在 `dist/core/runner/prepare-task.js` 的 ask 铸造点(`resolveAsk({...})`,三处继承臂 + 主臂)只把
+ * `toolName / toolCallId / args / preview / message / askSourceIdentity() / riskAxesOf() / requiresRealApproval`
+ * 装进 `AskRequest`;`decisionReason` 连同整个 `PermissionResult` 一起留在 core 内部。`AskRequest` 的类型面
+ * (`dist/core/tool-policy.d.ts:78`)也确认没有这个键。所以「映射 decisionReason ⇒ governanceForced」这条
+ * 缝在**当前 core 上不存在**——它不是没接线,是没有这个字段可读。
+ *
+ * 另一侧同样不可用:`riskAxes.irreversible` 在 shellGate 上场时对**每一次** shell 调用都为真(core
+ * `prepare-task.js:1620-1631` 无条件 `irreversibilityTier.set("Bash"/"Monitor", …)`),与「这只 ask 是谁
+ * 提的」无关;`requiresRealApproval` 的生产者是 core 自己的两条安全策略(unverifiable-delete /
+ * transcript-integrity),与治理层无关。两者都不是判据。
+ *
+ * ⇒ 采用的方案 = **server 标记自家产物**:治理层策略(`runtime-governance.ts` 的
+ * `applyRuntimeGovernance`)在合成时被包一层观察器,自己产 `ask` 时把该次调用的 `toolCallId` 记进本表;
+ * 帧铸点(`tool-approval.ts` 的 `askBroadcast`)按 `toolCallId` 回查。
+ * **禁把信号藏进 message 文本**——那是 in-band hack,消费端只能靠正则猜。
+ *
+ * ## 三条硬语义
+ *
+ * 1. **只做正向断言**。命中 = 有直接证据(治理策略本人产的 ask,或治理层把 shellGate 抬到 `"always"` 后
+ *    的 shell 调用——该档下每一次 shell 调用都被治理层门住,推断是紧的)。**未命中 ≠ 「不是治理」**,
+ *    只是「没有证据」⇒ wire 上键**缺席**,绝不编一个 `false`。宁可漏标,不可错标:一个错标会把运维支去
+ *    翻一份根本没门住这只 ask 的治理配置。
+ * 2. **peek,不 consume**。同一 `toolCallId` 可能被广播两次(重试 / failover / 闭包再入,见
+ *    `tool-approval.ts` 里 `pendingByAskId` 的顶注),消费式读会让第二帧莫名丢键。
+ * 3. **有界**。写入点是每一次工具调用,读取点只在 ask 上——未被读到的标记(调用被放行 / 被别的策略 deny)
+ *    必须能自己老化掉。按插入序淘汰最旧的(`Set` 的迭代序 = 插入序)。
+ *
+ * ## 作用域:按**审批 broker key** 分格,不是进程级一锅烩
+ *
+ * 🔴 codex 交叉复审 round3 [medium](验真):`toolCallId` **不是**全局唯一的 —— 它多数情况下是**提供方**
+ * 逐字给的 id(core 的 brain 层不另铸),本仓自己的代码就是这么假设的:core 把 tool-result 引用命名成
+ * `tr_<sessionId>_<toolCallId>`(见 `plugins/tool-result-store-sql.ts` 的 `deleteBySession` 顶注),
+ * `deriveAskId` 也把 `sourceTaskId`/`runId`/`legKey` 一并入哈希。一张不分格的表会**跨任务/跨租户串味**:
+ * 低熵 id(本地/自建模型服务常见的 `call_1` 之类)下,A 任务的治理标会被 B 任务的普通 ask 读走(假出处),
+ * 或被 B 的一次治理放行反手清掉(丢真出处)。
+ *
+ * 分格用的 **scope = 审批协调器的 broker key**(`["session", owner, sessionId]` / `["adhoc", owner, taskId]`)。
+ * 选它的理由是**两侧都够得到、且是同一个值**:
+ *  · 写侧(治理策略的观察器跑在 core 的 `policy.check` 里,入参只有 `ToolCallRequest`)⇒ 经
+ *    AsyncLocalStorage 拿 —— 作用域由 `runWithContext` 与审批 ctx **同拍**进出。
+ *  · 读侧(`askBroadcast`)⇒ 由 `origin`/`primary` **显式算出**同一把 key。
+ *
+ * 🔴 读侧**显式算**而不是也读 ALS(codex 交叉复审 round5 [medium],红先复现后改的形):委派/长命 bg 子代
+ * 的 ask 可能在**另一条腿**的上下文里发出(宿主腿退场、壳重连出新腿,子代的卡落到新腿的流上)。读侧若取
+ * 环境里的那张表,拿到的是**新腿**的空表,信号静默丢失 —— 那条路径已由
+ * `test/governance-forced-signal.test.ts` 的「长命 bg 子代形」用例钉住(改形前它是红的)。scope 由**出处**
+ * 决定、与卡投递到哪条连接无关,与本仓 `AskOriginIdentity` 顶注「投递面与出处面是两件事」同源。
+ *
+ * 残余(成文):同一 (owner, sessionId) 下的**并发多 run** 共用一格 —— 那正是 broker 自己的分组粒度
+ * (卡本来就跨该会话投递),同租户同会话内的 id 碰撞才会互串,比进程级一锅烩窄得多。要再窄需要一个
+ * 写侧也够得到的 run 级身份,core 的 `ToolCallRequest` 今天给不出。
+ */
+import { AsyncLocalStorage } from "node:async_hooks";
+/** 默认表容量(全进程合计,复合键计数)。一次 turn 的工具调用数远小于此;满表淘汰的是最旧的标记
+ *  (那些早已不可能再被读到)。 */
+const DEFAULT_MAX_MARKS = 1024;
+/** 复合键。JSON 元组编码(同 `streamKey`/`sessionAllowKey` 先例):任何一段里含分隔符都不可能与下一段
+ *  的边界产生歧义 —— 一个精心构造的 sessionId 因此无法伪造出另一格。 */
+const compositeKey = (scope, toolCallId) => JSON.stringify([scope, toolCallId]);
+/** 一张独立的标记表(不进程共享)。生产路径用的是下面 `governanceAskMarksFor` 给出的**分格视图**;
+ *  本工厂给测试(与将来的多实例形)一个不依赖任何环境的干净表。 */
+export function createGovernanceAskMarks(opts) {
+    return createScopedView(new Set(), "", Math.max(1, Math.floor(opts?.max ?? DEFAULT_MAX_MARKS)));
+}
+function createScopedView(marks, scope, max) {
+    return {
+        setMarked(toolCallId, marked) {
+            if (typeof toolCallId !== "string" || toolCallId === "")
+                return; // 无身份 ⇒ 无从回查,不占格
+            const key = compositeKey(scope, toolCallId);
+            // 重标记要**刷新新鲜度**:先删后加把它挪到插入序尾部,免得一只长命的 ask 被自己后来的调用挤掉。
+            marks.delete(key);
+            if (!marked)
+                return; // 覆写成「不是治理门」= 清格(setMarked 顶注:复查路径的陈旧标)
+            marks.add(key);
+            while (marks.size > max) {
+                const oldest = marks.values().next();
+                if (oldest.done)
+                    break;
+                marks.delete(oldest.value);
+            }
+        },
+        isMarked(toolCallId) {
+            return typeof toolCallId === "string" && toolCallId !== "" && marks.has(compositeKey(scope, toolCallId));
+        },
+        clear() {
+            for (const k of [...marks])
+                if (k.startsWith(`[${JSON.stringify(scope)},`))
+                    marks.delete(k);
+        },
+        size() {
+            let n = 0;
+            for (const k of marks)
+                if (k.startsWith(`[${JSON.stringify(scope)},`))
+                    n += 1;
+            return n;
+        },
+    };
+}
+/** 进程级底表(分格由复合键承担,见顶注「作用域」段)。 */
+const processMarks = new Set();
+/** 写侧的 scope 载体 —— 由 `ToolApprovalCoordinator.runWithContext` 与审批 ctx 同拍进出。 */
+const scopeAls = new AsyncLocalStorage();
+/** 进入一条 run 腿的标记作用域(唯一调用点 = `ToolApprovalCoordinator.runWithContext`)。 */
+export function runWithGovernanceAskScope(scope, fn) {
+    return scopeAls.run(scope, fn);
+}
+/** **写侧**入口:当前异步作用域那一格的视图;作用域外 = `undefined`(写 no-op,见顶注)。 */
+export function currentGovernanceAskMarks() {
+    const scope = scopeAls.getStore();
+    return scope === undefined ? undefined : createScopedView(processMarks, scope, DEFAULT_MAX_MARKS);
+}
+/** **读侧**入口:按**显式** scope 取视图(读侧不读 ALS —— 理由见顶注 round5 那段)。 */
+export function governanceAskMarksFor(scope) {
+    return createScopedView(processMarks, scope, DEFAULT_MAX_MARKS);
+}
+//# sourceMappingURL=governance-ask-marks.js.map

package/dist/hooks/hook-runner.d.ts

@@ -14,6 +14,21 @@ export declare const MAX_HOOK_MATCHER_GROUPS = 16;
 export declare const MAX_HOOK_HTTP_HEADERS = 32;
 /** hook 进程 stdout/stderr 各自的采集上限(字节)——防输出洪泛打爆内存/日志。 */
 export declare const MAX_HOOK_OUTPUT_BYTES: number;
+/**
+ * 一次事件里所有 hook 上下文片段**聚合后**喂给模型的总量上限(字符)。
+ *
+ * 为什么单条帽不够:一次事件最多 {@link MAX_HOOK_ENTRIES_PER_EVENT} 条(parseHooksConfig 的广度闸),
+ * 每条最多推两段(`decision:"block"` 的 reason + `hookSpecificOutput.additionalContext`),
+ * {@link composeHooks} 再把部署槽与 task 槽的**成品**拼一次 —— 单条 4096 相乘后一次注入可达 ~256KB,
+ * 而这些字符是**逐次工具调用**进模型可见文本的(core `hooks.js` 的 preToolContext / `prepare-task.js`
+ * 的 tool_result 追加 / `runtask.js` 的 Stop follow-up),不是日志。
+ *
+ * 帽值取 10_000 的依据:模型可见文本在本栈的既有预算量纲就是 10k —— core `truncateError`
+ * (`src/core/tool-errors.ts`)的 10k 中截,逐字锚 CC 序列化器 `A7e` 的 `1e4`;#181 战役里 core 还要给
+ * `beforeToolCall` block reason 补一道同值兜底闸。取同一量级 = 「一次 hook 注入 ≤ 一份错误文本预算」,
+ * 且 4096 的单条帽保证**前两条**钩子的话仍整段进得去(截断是配置广度的代价,不是常态)。
+ */
+export declare const MAX_HOOK_CONTEXT_TOTAL_CHARS = 10000;
 export interface ParseHooksConfigResult {
     config?: HooksConfig;
     /** 人可读的第一条校验错误(HTTP 层用它 400 fail-loud;resume 防御路径用它 warn)。 */
@@ -96,6 +111,19 @@ export type HookLlmCall = (opts: {
 /** 失败判别码(B8:判别一律走码,禁按 error 文案分支——v3.1 批2,统检第二波 high)。error 仍是给人看的
  *  自由文本;code 是给控制流的。缺席=未分类失败(不重试、不特判)。 */
 export type HookLlmFailureCode = "no_content" | "hard_timeout";
+/**
+ * hook 上下文片段 → 喂给模型的单串。**所有** `additionalContext` 聚合点的唯一属主(此前是同一个
+ * `contexts.join("\n")` 表达式抄在二十余处,总量帽无处可挂 —— 那正是漂移成因)。
+ *
+ * 三条语义,都是承重的:
+ *  1. **顺序保留、只截尾**:先来的钩子先说话;一旦装不下就停,后面的条目一律不再挤进来(哪怕更短)。
+ *     按长度重排会让"第 3 条钩子的话"随别人的长度忽隐忽现,排障时无从复现。
+ *  2. **截断可见**:尾巴挂一行标记说明省了几条、丢了多少字符。静默丢弃会让 hook 作者以为自己的
+ *     context 生效了,而模型那头根本没见过 —— 这类"以为配好了"的缺席比长文本本身更贵。
+ *  3. **标记不计预算**:与 core `truncateError` / CC `A7e` 同姿势(marker 不占那 10k),否则帽值的
+ *     含义会随标记文案长度漂。
+ */
+export declare function buildHookContext(parts: readonly string[]): string | undefined;
 /**
  * 阶段三a:`http` 条目——契约语义 = POST hook 输入 JSON 到 `url`;headers 里的 `$NAME` 仅当 NAME 列在
  * `allowedEnvVars` 才从 worker 进程 env 插值(配置本身绝不携带密钥值,契约同边界)。