@sema-agent/client-core 0.77.1 → 0.77.2

package/dist/gateVocabulary.js

@@ -1,11 +1,3 @@
-/**
- * **谁拒的** —— 判决是这次 deny 的那一**层**(sdk `DeniedBy` / core `DENIED_BY_VALUES`,
- * 7.6.0 起八词、**7.9.0 起九词**)。顺序逐字同源。
- * 🔴 真闭集(见模块顶注):表外词到不了消费端,所以这张表**没有**逃生口。
-
- * 🔴 形制:`Object.freeze` 的数组,**不是**只在类型面只读的 `readonly T[]` —— 后者一行 `.splice()`
- *    就能改,而公面消费者拿到的正是这个实例(本仓已定谳的病形,同 `RESUME_RETRY_LATER_CODES`)。
- */
 export const GATE_DENIED_BY_WORDS = Object.freeze([
     'policy',
     'hook',
@@ -17,66 +9,26 @@ export const GATE_DENIED_BY_WORDS = Object.freeze([
     'write_protection',
     'ask_resolution',
 ]);
-/**
- * 逐词一句人话。**九句刻意逐字互异**:对用户/运维是九条不同的下一步(改部署策略 / 改 hook /
- * 找组织管理员 / 撤自己的常驻规则 / 调 auto 模式 / 退出 plan 模式 / 找合规 / 改写保护表 /
- * 看那次审批的结算)。
- */
 const DENIED_BY_SENTENCES = Object.freeze({
-    /** 部署 ToolPolicy 拒(直接拒,或复查一次已批准的编辑),或审批-编辑链撞了轮次上限。 */
     policy: "denied by this deployment's permission policy",
-    /** PreToolUse hook 拒 / 抛 / 从未作答 —— 「没作决定的 hook」的 fail-closed 拦阻也按 hook 层归因。 */
     hook: 'denied by a PreToolUse hook',
-    /** 组织策略规则拒。 */
     org: 'denied by an organization rule',
-    /** **这个人自己**名下的一条常驻 deny 规则拒(他 settings 的 deny 表导进来的那类行)。
-     *  它是 `org` 的**个人店同胞**:同属「可以否掉一次人已经给过的批准」的复查层。 */
     persisted_rule: 'denied by a persisted rule',
-    /** auto 模式分类器**直接**拒(它的 ASK 侧角色是 `origin: "denial_limit_fallback"`,不是这一格)。 */
     classifier: 'denied by the auto-mode classifier',
-    /** plan 模式对写工具的只读拦阻。 */
     plan_mode: 'denied because plan mode only allows reads',
-    /** 合规的调用期锁。 */
     compliance: 'denied by a compliance lock',
-    /** 一次被批准的编辑被限制链改写到了**没有任何审批覆盖**的写保护路径上。 */
     write_protection: 'denied because the write landed on a write-protected path',
-    /** 这次 ask 的**结算本身**就是拒(有人说了不 / 窗到期 / 没人可问……)—— 细节在 `settlement`。 */
     ask_resolution: 'denied when the approval was resolved',
 });
-/**
- * 一个 `deniedBy` 词 → 一句人话。**唯一铸点**(三端共用;端零自拼)。
- *
- * 🔴 表外词的那一句说的是「**这条门记录本不该长这样**」,不是「有个新词」——理由见模块顶注
- *    (出集的记录在 server 侧整条不上帧,所以真读到一个表外词意味着记录有缺陷)。原样带上那个
- *    词:运维要拿它去问上游。
- * 🔴 非串 / 空串同样走兜底 —— 一个读不出的层名不是「没有层」(deny 臂在类型上就必须点名一层)。
- * 🔴 **查表用 `Object.hasOwn`,不用 `in` / 裸下标**(异源对抗复审 [medium]):`Object.freeze` 冻的是
- *    **自有属性**,原型链原样还在 ⇒ 一个来自 wire 的 `constructor` / `toString` / `__proto__` 会命中
- *    `Object.prototype` 上的成员,措辞口于是返回一个**函数**而不是一句话:呈现调用当场坏掉,而且
- *    它绕过了上下两条精心分家的兜底。这是本仓已定谳的病形(wire 键控的表一律用 Map 或自有属性判据)。
- */
 export function gateDeniedByDetail(deniedBy) {
     if (typeof deniedBy === 'string' && Object.hasOwn(DENIED_BY_SENTENCES, deniedBy)) {
         return DENIED_BY_SENTENCES[deniedBy];
     }
     const word = typeof deniedBy === 'string' && deniedBy.length > 0 ? deniedBy : '(none)';
-    return `denied, but the layer name ${word} is not one this gate record should be able to carry — engines withhold records that carry an unknown layer, so this one is damaged`;
+    return `denied by a layer this build does not know (${word}) — this build does not know this layer name: a newer engine may have added it, or the record may be damaged; this client cannot tell which`;
 }
-/**
- * 一只 ask 的**出身** —— 谁问的(sdk `AskOrigin` / core `ASK_ORIGINS`;7.5.x 及以前八词、
- * 7.6.0 十词、**7.9.0 起十一词**)。顺序逐字同源。
- * 🔴 真开集(见模块顶注):server 只判非空串,新词会带着合法的帧到达。
-
- * 🔴 形制:`Object.freeze` 的数组,**不是**只在类型面只读的 `readonly T[]` —— 后者一行 `.splice()`
- *    就能改,而公面消费者拿到的正是这个实例(本仓已定谳的病形,同 `RESUME_RETRY_LATER_CODES`)。
- */
 export const ASK_ORIGIN_WORDS = Object.freeze([
     'content_question',
-    // 🔴 0.67.0 / core 7.14.0 **BREAKING 换词,无 alias**:`unresolvable` → `ancestor_marked`
-    //    (`dist/core/ask-origin.js:1` `ASK_ORIGINS` 真字节;`ask-origin.d.ts:36-38` 是它的定义句)。
-    //    换的是**词**不是位:同一条 ladder 臂、同一张资格表。旧词按 clean-cut **不留别名** ——
-    //    一条 pre-7.14 的耐久行带 `"unresolvable"` 时它是**非成员**,投影**省略**那一格(见
-    //    {@link askOriginDetail} 的表外词兜底句;`ASK_ORIGIN_SENTENCES` 里不再有它的一句)。
     'ancestor_marked',
     'org_unavailable',
     'org_rule',
@@ -88,30 +40,6 @@ export const ASK_ORIGIN_WORDS = Object.freeze([
     'safety_tighten',
     'policy',
 ]);
-/**
- * 逐词一句人话。**十一句刻意逐字互异** —— 尤其是这三对刻意分家的同胞:
- *   · `org_unavailable` / `rule_store_unavailable`:两个「治理源这次读不出来 ⇒ fail-closed 问人」,
- *     一个是**组织**店、一个是**这个人自己**的持久规则店,下一步找的人不同;
- *   · `shell_gate_tighten` / `safety_tighten`:两条 tighten 分成两个词,正是为了说出**哪一层**
- *     引擎逻辑提的问(粗粒度 shellGate 教条 vs 调用的显式事实:egress 标 / 不可逆标 / 写保护);
- *   · `org_rule` / `ask_rule`:组织的规则 vs 这个人自己的常驻 ask 行。
- *
- * ── 🔴 0.65.0 三句订正(B-080③;core `dist/core/ask-origin.d.ts` 真字节)───────────────────────
- * 三句修前各自漂开了上游的定义,而漂的方向都是「把引擎真正说的事换成一件别的事」:
- *   · **`ancestor_marked`**(0.67.0 前名 `unresolvable`)修前渲「门拿不定主意」—— core:36-38 逐字是「the call is MARKED by an
- *     ancestor (an inherited approver-unavailable float, or a durable mandate floated down because
- *     this task can park it): it must reach the park with no synchronous decision-maker in between」。
- *     那不是犹豫,是**祖先盖的标记**+一条硬路径约束;渲成「拿不定主意」会让人去找一个不存在的
- *     「让门自己拿主意」的配置。
- *   · **`shell_gate_tighten`** 修前渲「**每一条** shell 命令都问」—— 过度陈述。core:58-59 逐字是
- *     「raised the ask over a tier the COARSE `shellGate` doctrine installed」:问的是**这一档以上**的,
- *     不是全部。
- *   · **`rule_store_unavailable`** 修前渲固定的「规则店读不出来」—— 而这一个词 core 7.9.0 起盖的是
- *     **两种机制**(store 读失败 **或** tightening lexer 的 `unreadable`:展开里有读不懂的词 / 引号未
- *     闭合 / 语法错,core:44-51),core CHANGELOG 7.9.1 逐字交代处置:「a card that hard-codes store
- *     wording for the origin should read the message」。⇒ 本铸点改成**引擎的 `message` 优先**(见
- *     {@link askOriginDetail} 的 additive 第二参),表里留的那一句改成两种机制都成立的中性句。
- */
 const ASK_ORIGIN_SENTENCES = Object.freeze({
     content_question: 'the tool itself asked you a question',
     ancestor_marked: 'an ancestor marked this call (an inherited approver-unavailable float, or a durable mandate): it must reach the park with no synchronous decision-maker in between',
@@ -125,41 +53,11 @@ const ASK_ORIGIN_SENTENCES = Object.freeze({
     safety_tighten: 'the gate tightened on this call’s own facts (network egress, irreversibility, or a protected write)',
     policy: 'this deployment’s permission policy asks about this call',
 });
-/**
- * 哪些 `origin` 词的一句人话应当**让位给引擎自己的 `message`**(闭集;0.65.0 新铸)。
- *
- * 🔴 **不是「有 message 就用 message」**:绝大多数出身词的那一句是本包写的、对每一只同出身的 ask
- *    都成立的**定义句**,而引擎的 `message` 是**这一只**调用的拒因/疑因散文 —— 两者不同类,
- *    无差别地拿 message 顶掉定义句会把「谁问的」换成「引擎这一次写了什么」。
- * 🔴 本集只收**一个词盖了多种机制**的那一类:`rule_store_unavailable` 的两条腿(店读不出来 /
- *    这条命令对不上你的规则行)对人的下一步不同,而只有引擎的 message 分得出来。
- *    加员 = 上游又把一个词做成了多机制合并词,必须同批带坐标。
- */
 const ORIGIN_PREFERS_ENGINE_MESSAGE = new Set(['rule_store_unavailable']);
-/**
- * 一个 `origin` 词 → 一句人话。**唯一铸点**(三端共用;端零自拼)。
- *
- * @param origin  帧/行上的 `origin` 词(开集;非串/空串走兜底)
- * @param message 🆕 **0.65.0 additive 第二参**(B-080③):引擎在这只调用上给的散文
- *   (`PermissionResult.message` / 卡上的同名位)。**只在 {@link ORIGIN_PREFERS_ENGINE_MESSAGE}
- *   的词上优先**,其余词一字不读 —— 理由写在那张表的头注。缺席 / 非串 / 空白串 ⇒ 行为与本参
- *   出现之前**逐字节相同**(表里那一句中性定义句)。
- *
- * 🔴 表外词的那一句说的是「**这个词比这一端新**」,不是「坏记录」——理由见模块顶注(server 只判
- *    非空串,core 加词当天合法的帧就带着它到达)。原样带上那个词,并明说这次仍然是在问人:
- *    读不懂出身**不改变**这只 ask 要人回答这件事。
- * 🔴 非串 / 空串:同走兜底但词位渲 `(none)` —— 「没报出身」与「报了一个读不懂的出身」在这一句里
- *    不必分家(两者对用户的下一步相同:照常回答这只 ask),但都**不许**被折成十一词里的任何一个。
- * 🔴 `message` 是引擎/工具产文,**只渲不回喂模型**(与卡上其余散文位同一条纪律);本铸点
- *    **不截断不改写**它 —— 显示封顶归端(它才知道自己的行宽)。
- */
 export function askOriginDetail(origin, message) {
-    // 🔴 自有属性判据,理由与 `gateDeniedByDetail` 逐字相同(冻结不移除原型)。
     const known = typeof origin === 'string' && Object.hasOwn(ASK_ORIGIN_SENTENCES, origin)
         ? ASK_ORIGIN_SENTENCES[origin]
         : undefined;
-    // 🔴 让位只在**多机制合并词**上发生,且只在 message 真是一句非空散文时:引擎没给 / 给的是坏值
-    //    ⇒ 回落表里那一句中性定义句(绝不渲半句、绝不渲空)。
     if (typeof origin === 'string' && ORIGIN_PREFERS_ENGINE_MESSAGE.has(origin)) {
         const spoken = typeof message === 'string' ? message.trim() : '';
         if (spoken.length > 0)
@@ -170,75 +68,17 @@ export function askOriginDetail(origin, message) {
     const word = typeof origin === 'string' && origin.length > 0 ? origin : '(none)';
     return `this call asks; its origin ${word} is a word newer than this client, so answer it as usual`;
 }
-/**
- * **编译期对账钉**(不出公面):`DeniedBy` 那张表的成员必须真属于 sdk 的联合,**双向**
- * (它在 wire 上是真闭集,型面也闭)。
- */
 const _deniedByWordsPin = GATE_DENIED_BY_WORDS;
 void _deniedByWordsPin;
-/**
- * 🔴 **`AskOrigin` 那条型面钉 0.67.0 退役,理由要写清**(如实登记,不是偷偷删):
- * 它此前写作 `const _askOriginWordsPin: readonly AskOrigin[] = ASK_ORIGIN_WORDS`,而
- * `AskOrigin = SdkAskOrigin` 的型面带 `(string & {})` 逃生口 ⇒ **任何字符串都满足它**,这条钉
- * 在 core 7.14.0 把 `unresolvable` 换成 `ancestor_marked` 的当天**一声不响**(亲验:换词后
- * `npx tsc --noEmit` 0 红)。一条恒真的钉不是钉,是[gates-fail-in-their-own-ways] 的「无契约表」那一档。
- * ⇒ 判据整只移交给 `run-gate-vocabulary-test.mjs` 的 **B 段**:本表对 **core `ask-origin.js` 的
- * `ASK_ORIGINS` 真字节**双向等值(词表属主是 core,sdk 只是它的镜像且**今天滞后一代**)。
- * 那条对账拿的是运行期真字节,逃生口影响不到它。
- */
-// ══ 0.67.0 / core 7.14.0 #688 C3 —— 第三张表:`ruleStoreUnreadable` 两词 ═════════════════════
-//
-// 它不是 `AskOrigin` 的第十二个词,而是**一个 origin 词底下的机制位**:`rule_store_unavailable`
-// 这一个词盖了**两种机制**(core `ask-origin.d.ts:98-104` 顶注逐字点名),而对人的下一步**相反**。
-// 词表属主 = core `RULE_STORE_UNREADABLE_KINDS`(`ask-origin.d.ts:116`),本包逐词逐序镜像,
-// `run-gate-vocabulary-test.mjs` 的 C 段对**实装 core 的真字节**双向等值。
-/**
- * **规则店读不出来是哪一头**(core `RULE_STORE_UNREADABLE_KINDS`;逐词逐序镜像,7.14.0 起两词)。
- *   · `store` —— 接上的那个店**读不出来**(读失败 / 超时 / 适配器抛了);
- *   · `call`  —— 店读到了,但**这一次调用**读不出来(收紧 lexer 的 `unreadable`:展开里有读不懂的词 /
- *     引号未闭合 / 语法错 —— 引擎自己那句话在 ask 的 `message` 上)。
- *
- * 🔴 **真闭集**(与 `AskOrigin` 的开集刻意不同):core 在**唯一 stamp 点**把政策自报的值剥掉之后
- *    才盖章(7.14.0 合同逐字「A policy's self-declared value is removed at the stamp」)⇒ 表外值
- *    结构上到不了消费端。
- * 🔴 形制:`Object.freeze` 的数组,理由同上面两张表。
- */
-// 🔴 0.68.0 / L-245:形制从 `readonly string[]` 改成**字面元组**(理由同 `CLASSIFIER_DENY_CAUSES`:
-//    型面交得出成员字面量,端才能派生型而不是再抄一遍两个词)。
 export const RULE_STORE_UNREADABLE_KINDS = Object.freeze(['store', 'call']);
 const RULE_STORE_UNREADABLE_SET = new Set(RULE_STORE_UNREADABLE_KINDS);
-/** 这个值是不是 {@link RULE_STORE_UNREADABLE_KINDS} 的成员(core `isRuleStoreUnreadable` 的镜像)。
- *  🔴 **唯一判据口**:窄读器与端都调它,谁都不许再抄一份字面量(B-025 的根因就是手抄)。
- *  🔴 0.68.0 / L-245:改成**型守卫** —— 端用它一判就拿到闭集成员型,下一步喂措辞铸点时不必 cast。 */
 export function isRuleStoreUnreadableKind(v) {
     return typeof v === 'string' && RULE_STORE_UNREADABLE_SET.has(v);
 }
-/** 逐词一句人话。**两句刻意逐字互异** —— 两条不同的下一步(去修部署的规则店 / 去改自己那条规则)。
- *  🔴 0.68.0 / L-245:表型改 `Record<RuleStoreUnreadableKind, string>` —— core 加第三个机制词那天
- *  **这张表少一个键 ⇒ 编译期当场红**,逼人同批补那一句话(修前是 `Record<string,…>`,加词一声不响)。 */
 const RULE_STORE_UNREADABLE_SENTENCES = Object.freeze({
     store: 'your standing deny/ask rules could not be read at all (the rule store did not answer), so this call asks',
     call: 'this command could not be read against your standing deny/ask rules (the engine’s own sentence is on this ask), so it asks',
 });
-/**
- * 一个 `ruleStoreUnreadable` 词 → 一句人话。**唯一铸点**(三端共用;端零自拼)。
- *
- * 🔴 **与 {@link askOriginDetail} 并列不互替**:那一句答「谁问的」(出身),本句答「读不出来的是
- *    **哪一头**」。`rule_store_unavailable` 那只 ask 上两句都该在,渲一句丢一句就等于把人指去
- *    错的地方 —— 而这正是 core 把这一位单独铸出来的理由。
- * 🔴 **查表用 `Object.hasOwn`**(冻结不移除原型;理由与本文件另两个铸点逐字相同)。
- *
- * ── 🔴 0.68.0 / L-245:入参从 `unknown` 收窄成**闭集成员型** ─────────────────────────────────
- * 修前这里同样留着一句「is **a word newer than this client**」的兜底,而它**结构上走不到**:
- * 唯一到达本铸点的路是卡口的窄读器(`toolApprovalWire` 的 `readRuleStoreUnreadable`),那一层已经
- * 按闭集把表外值判成了缺席;而这一面在上游是**真闭集**(core 在唯一 stamp 点把政策自报值剥掉之后
- * 才盖章)⇒ 一个「比这一端新」的值根本到不了。
- * ⚠️ 与**隔壁那一句**({@link askOriginDetail})的处置刻意相反,而两边都是对的:`AskOrigin` 在 wire
- *    上是**开集**(server 只判非空串,core 加词当天合法的帧就带着它到达)⇒ 那一句兜底**真的会被
- *    走到**,必须留。一套面一条规矩:闭集则收窄 + 编译期围栏,开集则保留兜底。
- * 🔴 渲染路径不许抛,所以 never 分支照样交一句话;只是它现在说的是「这个词不在本端的闭集里」
- *    (一句真话),而不再冒充「上游比我新」。
- */
 export function ruleStoreUnreadableDetail(kind) {
     const known = Object.hasOwn(RULE_STORE_UNREADABLE_SENTENCES, kind)
         ? RULE_STORE_UNREADABLE_SENTENCES[kind]

package/dist/goalStopHook.d.ts

@@ -1,142 +1,15 @@
-/**
- * REF-CC-156(midband-04,split,2026-08-02):拆自 `hooksWireCaps.ts`——那个文件里约 220 行(占其
- * 387 行的 57%)是 `/goal` 命令专属的 Stop-hook 版本判档 + prompt 组装 + 模块级单实例状态,与
- * `hooksWireCaps.ts` 其余部分(通用 settings-file hooks 投影 + 治理门)是两个不同的关注点,原文件
- * 只在 `hooksForWire()` 尾部合流一次。纯搬迁,行为不变:所有导出名字原样保留(`hooksWireCaps.ts`
- * 显式 re-export,外部 import 路径零改动),模块级状态(`wireSessionStopHookPrompt`/
- * `wireSessionStopHookCcSemantics`)随代码一起搬到本文件,`docs/refactor/p1-scan/singleton-manifest.json`
- * 的两条登记同批把 `file` 改成本文件坐标。
- *
- * ── 以下为原文件的领域说明(逐字保留)────────────────────────────────────────────────────────
- *
- * SESSION-SCOPED Stop hook overlay(`/goal`,任务 #75 · C-7,2026-07-26)
- * CC 220 的 `/goal <condition>` 会往 `sessionHooksRegistry` 注册一条会话级 Stop×prompt 钩子
- * (`t.sessionHooksRegistry.add(sessionId,"Stop","",{type:"prompt",prompt})`),那才是「干到条件满足
- * 再停」的机制半边。CC 是单进程,注册进壳内 registry 就够。
- *
- * 🔴 **sema 是双进程壳,壳侧那条钩子在 live 模式 fire 不到**(实证,不是推测):壳的 Stop 钩子只有
- * `src/query/stopHooks.ts handleStopHooks` 一个执行点,调用方是 `src/query.ts` —— 壳自己的 query
- * 循环;live 模式 turn 循环在引擎里跑,壳的 query.ts 不参与。upstreamBridge 只 fire SubagentStop 且
- * observe-only。所以引擎腿必须走 `settings.hooks` 投影,这个 overlay 就是那条腿。
- *
- * 🟢 **本 overlay 默认开**(2026-07-26 翻默认;逃生口 `SEMA_GOAL_STOP_HOOK_WIRE=0/false/no/off`)。
- *
- * 修前默认关,理由是两条**前提**——两条都已被 server 侧行为取证**证伪**([1721],6 条行为
- * 用例已进 server 仓;cli 仓另有 scripts/run-goal-stop-hook-live-test.mjs 的真引擎+真模型复验):
- *   ① 旧论断「SDK 类型 DEFERRED ⇒ 服务端会 400」**是把类型面当成了运行时校验面**,对 server
- *      不成立:`parseHooksConfig({Stop:[{hooks:[{type:"prompt",prompt}]}]})` 无 error、真解析;
- *      prompt 形在 server 的条目白名单里与 command/http/agent **并列**
- *      (@sema-agent/server hooks/hook-runner `entry.type !== "command" && … !== "prompt" && …`
- *      那道 type_not_supported 闸口把 prompt 放行,1.277.1 dist 对应 hook-runner.js:390)。
- *      卡着的只是 **SDK / registry-core 的类型**(见下方 cast),与 server 运行时接受与否两件事。
- *   ② 旧论断「引擎侧 Stop×prompt 是否真 fire 未取证」已取证:**真 fire**(Stop 触发时 prompt
- *      载体调用一次,`$ARGUMENTS` 已替换为 payload JSON)、**能拦停**(模型输出
- *      `{"decision":"block","reason":…}` → `{block: reason}`,core `runner/runtask.js:1663`
- *      `(spec.hooks ?? deps.hooks)?.stop` 起 stop gate,整条链通)、非决策 JSON 不拦(与 command
- *      形 exit-0 非 JSON 同语义)、`stop_hook_active:true` 如实进 payload(模型可自己收手;core
- *      另有 STOP_HOOK_BLOCK_CAP=8 连续拦停硬上限兜底,不会无限拦停)。
- *   ③ 最坏情况**不是** 400,而是**钩子不生效**:部署没组装 prompt 载体(`ctx.hookLlm` 缺席)⇒
- *      server 记账 `hook_entries_skipped{reason:"llm_carrier_unavailable"}` 并跳过,**非阻断**。
- * ⇒ 默认开。等件(不阻断本腿):registry-core hooks 契约建模 prompt 形([1717]① 在飞)、SDK
- *   `SettingsHookCommand` 放开 prompt 形 —— 到位后把下方 cast 换成直类型即可。
- *
- * 纪律:
- *  - 只放 goal 这一条(单值,不是通用会话钩子通道)——通用会话/插件钩子仍按 `hooksWireCaps.ts`
- *    模块头所述不投影;
- *  - 走 `hooksForWire()` 的**同一套治理门**(trust / disableAllHooks / allowManagedHooksOnly):
- *    overlay 在门之后才合并,策略禁钩子时一并禁掉;
- *  - `/goal clear` 传 null 收回。
- */
 import { type EnvLike } from './hostEnv.js';
 import type { WireHooksConfig } from './finalVerifyWire.js';
-/** The env ESCAPE HATCH for the engine leg (see the block comment above). */
 export declare const GOAL_STOP_HOOK_WIRE_ENV = "SEMA_GOAL_STOP_HOOK_WIRE";
 export declare const CC_STOP_SEMANTICS_MIN_SERVER = "1.279.3";
-/**
- * 引擎自报版本是否达到 CC Stop 语义线({@link CC_STOP_SEMANTICS_MIN_SERVER})。
- *
- * 🔴 三条纪律:
- *   · **数值比较**,不是字典序(`1.9.0` < `1.279.0`,字符串比较会判反);
- *   · **预发版不算达标**(`1.279.0-rc.1` 里那套可能还在改)——正则只认三段纯数字,带 `-` 的直接落
- *     null ⇒ false;
- *   · 读不出/探不到 ⇒ **false**(降级方向恒安全:老形在新引擎上仍能拦,新形在老引擎上一次都拦不住)。
- */
 export declare function ccStopSemanticsFromVersion(version: string | undefined | null): boolean;
-/**
- * 本会话连着的引擎是否具备 CC Stop 语义?判据 = live 车道的 `/v1/capabilities` 自报 `version`
- * (engineCapsCache 的 boot-kick 缓存,与 `/health.version` 同源)。
- *
- * 🔴 「未判即降级」:caps 探测是构造期 fire-and-forget,`/goal` 真被敲下时通常早已落袋;万一没落袋
- * 就按老引擎走(meta 也同步退档)——**宁可少承诺,不可多承诺**。
- */
 export declare function engineCcStopSemantics(env?: EnvLike): boolean;
-/**
- * Is the `/goal` Stop-hook engine leg armed? **Default ON** since 2026-07-26 — both of the premises
- * that kept it opt-in were disproved by server-side behavior evidence ([1721]) and re-verified against
- * a real engine + real model (cli scripts/run-goal-stop-hook-live-test.mjs). Set
- * `SEMA_GOAL_STOP_HOOK_WIRE` to an {@link envFlagOff} spelling(REF-CC-141 dup-02 单源)to disarm
- * (an operator escape hatch, not a default).
- */
 export declare function isGoalStopHookWireArmed(env?: EnvLike): boolean;
-/**
- * Register (or clear, with `null`) the session-scoped `/goal` Stop prompt hook that rides
- * `settings.hooks.Stop` to the engine. Single-valued: a new goal replaces the previous one,
- * exactly like CC 220's `Xdr` (remove-then-add). Projection is gated by
- * {@link isGoalStopHookWireArmed} — storing is always safe, sending is not (yet).
- */
 export declare function setWireSessionStopHook(prompt: string | null, opts?: {
-    /**
-     * 这条目标登记时,引擎是否已判定为 CC 语义档({@link engineCcStopSemantics})?
-     *
-     * 🔴 **为什么要在 set 那一刻锁存,而不是在 `hooksForWire()` 里现读**:`/goal` 的 meta
-     * (对模型讲「会不会拦到条件成立为止」)是在 set 那一刻发出去的,而投影发生在随后每个 turn。
-     * 两处各读一次的话,caps 探测中途落袋就会造出「meta 承诺拦到底、投出去的却还是老门」的错配 ——
-     * 判据必须锚在**真正决定结果的那个量**上,而它只有一个:**这条目标登记时的档位**。
-     * 缺省 false ⇒ 不传就是老引擎档:翻档只能靠证据打开,不能靠默认值。
-     */
     ccSemantics?: boolean;
 }): void;
-/** The currently registered `/goal` Stop prompt, or null (registered ≠ projected — see the gate). */
 export declare function getWireSessionStopHook(): string | null;
-/** 当前这条目标登记时锁存的档位(真 = 投裸条件,假 = 投壳自造的门)。 */
 export declare function getWireSessionStopHookCcSemantics(): boolean;
-/**
- * 把 `/goal` 的**原始条件**包成一条对引擎 prompt 载体**可执行**的 Stop 门 prompt。
- *
- * 🔴 适用面(2026-07-26 提货批后):**只用于未达标线的引擎档**(见 {@link CC_STOP_SEMANTICS_MIN_SERVER})。
- * 达标档起引擎自己按 CC
- * 220 逐字组装(系统提示 + 会话转录 + `wrapCondition`),那一档投的是**裸条件** —— 见
- * {@link ccStopSemanticsFromVersion} 与 `hooksForWire()` 的分道(见 {@link goalStopHookMatcher})。
- * 本函数保留,是 tolerate-absent 的实体:老引擎上退回它,仍能拦一次;删掉它等于在老引擎上静默失效。
- *
- * 🔴 为什么必须包(2026-07-26 live 围栏实测,不是设计偏好):CC 单进程的 prompt 钩子执行器
- * (`src/utils/hooks/execPromptHook.ts`)会给条件**套一层系统提示**(「You are evaluating a hook…
- * 回 `{ok:true}` / `{ok:false,reason}`」)**并把整段会话前置**,所以裸条件在 CC 那边能被真评估。
- * 引擎侧的载体两样都没有:
- *   · 无系统提示、无会话历史;
- *   · Stop payload 的 `transcript_path` 是**空串**(server basePayload),评估者对本会话是**瞎的**;
- *   · 判据 schema 也不同 —— core 只认 stdout JSON 的 `decision:"block"`。
- * 实测(钉版 server 1.277.1 + core 1.416 + 真模型):裸条件 `the project contains a file named
- * DONE.txt` 送过去,载体照样被调用,模型回的是**散文**(「I don't have direct access to your file
- * system…」)⇒ `parseHookStdout` 拿不到 decision ⇒ **一次都不拦**。即:不包 = 每次停机白烧一次
- * 模型调用、零效果。
- *
- * 所以这里把条件包成引擎契约里**能落地**的形状。诚实标注它**够不到 CC 的完整语义**:
- *   · 能做到:每个 turn 的**第一次**停机尝试被拦下,目标原文重新注入给模型,逼它自查后再收尾
- *     (`stop_hook_active` 为真时门自己收手 ⇒ 不会无限拦停);真正「条件是否成立」的判断交给
- *     **有会话、有工具的主模型**,而不是让瞎的评估者假装判断;
- *   · 做不到:CC 那种「拦到条件真成立为止」(需要引擎把 transcript 交给载体)、以及「条件满足后
- *     自动清除目标」。这两条是**等件**,meta 文案因此不照抄 CC `Pwo`(见 cmd-goal.tsx)。
- *
- * 台账仍存**原始条件**({@link getWireSessionStopHook}),所以 `/goal clear` 读回的是用户写的那句。
- */
 export declare function buildGoalStopHookPrompt(condition: string): string;
-/**
- * `hooksWireCaps.ts` 的 `hooksForWire()` 尾部合流点(REF-CC-156 拆分的接口):治理门跑完之后,
- * 调用方传入 `managedOnly`(allowManagedHooksOnly 是否命中),本函数原样返回要 concat 进
- * `merged['Stop']` 的那一条 matcher,或 `null`(未登记 / 被 managedOnly 挡 / overlay 未 armed)。
- * 非导出到包外(不进 `index.ts` 的公开面)——只是本文件与 `hooksWireCaps.ts` 之间的私有接口。
- */
 export declare function goalStopHookMatcher(managedOnly: boolean): NonNullable<WireHooksConfig[string]>[number] | null;
-/** 测试钩:清 `/goal` 锁存(壳里靠进程边界隔离;包内同进程多组断言必须能清)。 */
 export declare function __resetGoalStopHookForTests(): void;

package/dist/goalStopHook.js

@@ -1,119 +1,14 @@
-/**
- * REF-CC-156(midband-04,split,2026-08-02):拆自 `hooksWireCaps.ts`——那个文件里约 220 行(占其
- * 387 行的 57%)是 `/goal` 命令专属的 Stop-hook 版本判档 + prompt 组装 + 模块级单实例状态,与
- * `hooksWireCaps.ts` 其余部分(通用 settings-file hooks 投影 + 治理门)是两个不同的关注点,原文件
- * 只在 `hooksForWire()` 尾部合流一次。纯搬迁,行为不变:所有导出名字原样保留(`hooksWireCaps.ts`
- * 显式 re-export,外部 import 路径零改动),模块级状态(`wireSessionStopHookPrompt`/
- * `wireSessionStopHookCcSemantics`)随代码一起搬到本文件,`docs/refactor/p1-scan/singleton-manifest.json`
- * 的两条登记同批把 `file` 改成本文件坐标。
- *
- * ── 以下为原文件的领域说明(逐字保留)────────────────────────────────────────────────────────
- *
- * SESSION-SCOPED Stop hook overlay(`/goal`,任务 #75 · C-7,2026-07-26)
- * CC 220 的 `/goal <condition>` 会往 `sessionHooksRegistry` 注册一条会话级 Stop×prompt 钩子
- * (`t.sessionHooksRegistry.add(sessionId,"Stop","",{type:"prompt",prompt})`),那才是「干到条件满足
- * 再停」的机制半边。CC 是单进程,注册进壳内 registry 就够。
- *
- * 🔴 **sema 是双进程壳,壳侧那条钩子在 live 模式 fire 不到**(实证,不是推测):壳的 Stop 钩子只有
- * `src/query/stopHooks.ts handleStopHooks` 一个执行点,调用方是 `src/query.ts` —— 壳自己的 query
- * 循环;live 模式 turn 循环在引擎里跑,壳的 query.ts 不参与。upstreamBridge 只 fire SubagentStop 且
- * observe-only。所以引擎腿必须走 `settings.hooks` 投影,这个 overlay 就是那条腿。
- *
- * 🟢 **本 overlay 默认开**(2026-07-26 翻默认;逃生口 `SEMA_GOAL_STOP_HOOK_WIRE=0/false/no/off`)。
- *
- * 修前默认关,理由是两条**前提**——两条都已被 server 侧行为取证**证伪**([1721],6 条行为
- * 用例已进 server 仓;cli 仓另有 scripts/run-goal-stop-hook-live-test.mjs 的真引擎+真模型复验):
- *   ① 旧论断「SDK 类型 DEFERRED ⇒ 服务端会 400」**是把类型面当成了运行时校验面**,对 server
- *      不成立:`parseHooksConfig({Stop:[{hooks:[{type:"prompt",prompt}]}]})` 无 error、真解析;
- *      prompt 形在 server 的条目白名单里与 command/http/agent **并列**
- *      (@sema-agent/server hooks/hook-runner `entry.type !== "command" && … !== "prompt" && …`
- *      那道 type_not_supported 闸口把 prompt 放行,1.277.1 dist 对应 hook-runner.js:390)。
- *      卡着的只是 **SDK / registry-core 的类型**(见下方 cast),与 server 运行时接受与否两件事。
- *   ② 旧论断「引擎侧 Stop×prompt 是否真 fire 未取证」已取证:**真 fire**(Stop 触发时 prompt
- *      载体调用一次,`$ARGUMENTS` 已替换为 payload JSON)、**能拦停**(模型输出
- *      `{"decision":"block","reason":…}` → `{block: reason}`,core `runner/runtask.js:1663`
- *      `(spec.hooks ?? deps.hooks)?.stop` 起 stop gate,整条链通)、非决策 JSON 不拦(与 command
- *      形 exit-0 非 JSON 同语义)、`stop_hook_active:true` 如实进 payload(模型可自己收手;core
- *      另有 STOP_HOOK_BLOCK_CAP=8 连续拦停硬上限兜底,不会无限拦停)。
- *   ③ 最坏情况**不是** 400,而是**钩子不生效**:部署没组装 prompt 载体(`ctx.hookLlm` 缺席)⇒
- *      server 记账 `hook_entries_skipped{reason:"llm_carrier_unavailable"}` 并跳过,**非阻断**。
- * ⇒ 默认开。等件(不阻断本腿):registry-core hooks 契约建模 prompt 形([1717]① 在飞)、SDK
- *   `SettingsHookCommand` 放开 prompt 形 —— 到位后把下方 cast 换成直类型即可。
- *
- * 纪律:
- *  - 只放 goal 这一条(单值,不是通用会话钩子通道)——通用会话/插件钩子仍按 `hooksWireCaps.ts`
- *    模块头所述不投影;
- *  - 走 `hooksForWire()` 的**同一套治理门**(trust / disableAllHooks / allowManagedHooksOnly):
- *    overlay 在门之后才合并,策略禁钩子时一并禁掉;
- *  - `/goal clear` 传 null 收回。
- */
 import { hostEnv } from './hostEnv.js';
 import { envFlagOff } from './envFlag.js';
 import { engineCapString } from './engineCapsCache.js';
 let wireSessionStopHookPrompt = null;
-/**
- * CC 语义档的**锁存位**(见 {@link setWireSessionStopHook})。投影形按它分道:
- * 真 ⇒ 裸条件(引擎自己包 CC 形);假 ⇒ 壳自造的门 prompt(老引擎唯一能落地的形)。
- */
 let wireSessionStopHookCcSemantics = false;
-/** The env ESCAPE HATCH for the engine leg (see the block comment above). */
 export const GOAL_STOP_HOOK_WIRE_ENV = 'SEMA_GOAL_STOP_HOOK_WIRE';
-// ── 引擎档位:CC 220 Stop×prompt 完整语义(达标线 = CC_STOP_SEMANTICS_MIN_SERVER,见下)────────
-//
-// server 1.279.0 把 CC 220 的 prompt-hook 半场搬进了引擎(dist/hooks/cc-stop-prompt.js +
-// branch-transcript.js,源码直读):
-//   ① Stop×prompt 触发时先取 `sctx.getBranch()`(core 1.419+ 就在 stop gate ctx 里传了它)渲染成
-//      会话转录;**证据面为空则整条 prompt 条目被过滤掉、评估者根本不被调用**
-//      (`hook_entries_skipped{reason:"stop_prompt_no_evidence:<why>"}`)——这正是老引擎那条
-//      「白烧一次模型调用、零效果」的反面;
-//   ② 调用时带 CC 220 **逐字**的系统提示(`ccPromptSystemFor("Stop")` = CC 的 full 档)+ CC 逐字的
-//      条件包装(`wrapCondition`);
-//   ③ 判词 `{ok,reason,impossible}` 在**引擎翻译层**映射:ok ⇒ 放行、impossible ⇒ 记 warn 后**放行**
-//      (真 fail-open,既不 block 也不产 additionalContext)、其余 ⇒ block(reason 喂回模型)。
-//
-// ⇒ 到这一档,壳侧唯一正确的动作是把 CC `Xdr` 的**原形(裸条件)**投出去 —— 引擎会自己包。继续投
-//   壳自造的门 prompt 只会被再包一层、并与 CC 系统提示要求的判词 schema 打架。
-// 🔴 但老引擎**没有这套**(1.278.0 的 hooks/ 目录里既无 cc-stop-prompt 也无 branch-transcript,
-//   hook-llm 连 `system` 形参都没有):裸条件送过去评估者对本会话是瞎的,回散文 ⇒ 一次都不拦。
-//   所以判档失败/探不到时**必须**退回老形,绝不「因为代码里写了 enforced 就真拦」。
-//
-// 🔴 **为什么达标线钉 1.279.3 而不是 CC 面首次出现的 1.279.0** —— 两道闸,缺一道都不许翻档:
-//
-//   ① **core 下限**(1.279.1 才补上):CC Stop 语义在 1.279.0 就在了,但 1.279.1 才把
-//      `@sema-agent/core` 的下限提到 `^1.422.0`。core <1.422 上,一条只带 `additionalContext` 的
-//      Stop 反馈**不结束 + 不计数 + 清零计数** ⇒ block 与 additionalContext 交替时计数呈锯齿
-//      (`[0,1,0,1,0]`)、`STOP_HOOK_BLOCK_CAP` 永远到不了 ⇒ 无界循环;1.422 起它计入上限且不再清零。
-//      (注:goal 这条路本身产不出 additionalContext —— CC 判词的 ok/impossible 两支在引擎翻译层都
-//       直接 `continue`;但那条通道对 command 形钩子是开着的,而**上限修好的是最坏值,不是这条通道的
-//       性质**:它仍然会让那一轮不结束。所以措辞面一步都不许放松,见 cmd-goal 的 meta 四档。)
-//
-//   ② **判词额度**(1.279.3 才补上):1.279.1/1.279.2 的引擎侧 hook 载体把 `max_tokens` 钳死在
-//      `Math.min(…, 1024)`(dist/hooks/hook-llm.js)。而 CC 的评估者系统提示要求「quote evidence
-//      from the transcript」,推理档模型的 thinking 还与输出**共用**这份额度 ⇒ 判词被截断(JSON 不
-//      闭合)或干脆零 text 块 ⇒ `parseCcVerdict` 拿不到 ⇒ 引擎**丢弃整条判词并 fail-open 放行**。
-//      🔴 这条缺口的形状与 ① 不同,但危害更隐蔽:它让 enforced 档对模型讲的那两句承诺在**守卫失效
-//      的那些轮里变成空话,而且没有任何人知道**(引擎侧只留一行 `hook_llm_unparsed_verdict` /
-//      `hook_llm_failed{returned no content}` 记账,壳侧、用户侧、模型侧全都看不到)。
-//      1.279.3 起 `maxOutputTokens` 由调用方声明,CC 评估者路声明 `CC_EVALUATOR_MAX_OUTPUT_TOKENS`
-//      = 4096,并对「无内容」重试一次(**不**重试「有内容但读不懂」)。
-//
-// ⇒ 达标线钉的是「**承诺能兑现**的那个组合」,不是「能力面在场」的那一版。差一档就翻,等于把用户
-//   放到一个「守卫会静默失效」的搭配上,还对着模型把话说满。
 export const CC_STOP_SEMANTICS_MIN_SERVER = '1.279.3';
-/** `x.y.z` → 数值三元组;非法形 ⇒ null(预发标记按「未达标」处理,见下)。 */
 function parseSemverCore(v) {
     const m = /^(\d+)\.(\d+)\.(\d+)$/.exec(v.trim());
     return m ? [Number(m[1]), Number(m[2]), Number(m[3])] : null;
 }
-/**
- * 引擎自报版本是否达到 CC Stop 语义线({@link CC_STOP_SEMANTICS_MIN_SERVER})。
- *
- * 🔴 三条纪律:
- *   · **数值比较**,不是字典序(`1.9.0` < `1.279.0`,字符串比较会判反);
- *   · **预发版不算达标**(`1.279.0-rc.1` 里那套可能还在改)——正则只认三段纯数字,带 `-` 的直接落
- *     null ⇒ false;
- *   · 读不出/探不到 ⇒ **false**(降级方向恒安全:老形在新引擎上仍能拦,新形在老引擎上一次都拦不住)。
- */
 export function ccStopSemanticsFromVersion(version) {
     if (typeof version !== 'string' || version.length === 0)
         return false;
@@ -131,77 +26,25 @@ export function ccStopSemanticsFromVersion(version) {
         return gotPatch > minPatch;
     return true;
 }
-/**
- * 本会话连着的引擎是否具备 CC Stop 语义?判据 = live 车道的 `/v1/capabilities` 自报 `version`
- * (engineCapsCache 的 boot-kick 缓存,与 `/health.version` 同源)。
- *
- * 🔴 「未判即降级」:caps 探测是构造期 fire-and-forget,`/goal` 真被敲下时通常早已落袋;万一没落袋
- * 就按老引擎走(meta 也同步退档)——**宁可少承诺,不可多承诺**。
- */
 export function engineCcStopSemantics(env = hostEnv()) {
     const base = env.SEMA_LIVE_BASEURL;
     if (!base)
         return false;
     return ccStopSemanticsFromVersion(engineCapString(base, 'version'));
 }
-/**
- * Is the `/goal` Stop-hook engine leg armed? **Default ON** since 2026-07-26 — both of the premises
- * that kept it opt-in were disproved by server-side behavior evidence ([1721]) and re-verified against
- * a real engine + real model (cli scripts/run-goal-stop-hook-live-test.mjs). Set
- * `SEMA_GOAL_STOP_HOOK_WIRE` to an {@link envFlagOff} spelling(REF-CC-141 dup-02 单源)to disarm
- * (an operator escape hatch, not a default).
- */
 export function isGoalStopHookWireArmed(env = hostEnv()) {
     return !envFlagOff(env[GOAL_STOP_HOOK_WIRE_ENV]);
 }
-/**
- * Register (or clear, with `null`) the session-scoped `/goal` Stop prompt hook that rides
- * `settings.hooks.Stop` to the engine. Single-valued: a new goal replaces the previous one,
- * exactly like CC 220's `Xdr` (remove-then-add). Projection is gated by
- * {@link isGoalStopHookWireArmed} — storing is always safe, sending is not (yet).
- */
 export function setWireSessionStopHook(prompt, opts) {
     wireSessionStopHookPrompt = prompt && prompt.length > 0 ? prompt : null;
     wireSessionStopHookCcSemantics = wireSessionStopHookPrompt === null ? false : opts?.ccSemantics === true;
 }
-/** The currently registered `/goal` Stop prompt, or null (registered ≠ projected — see the gate). */
 export function getWireSessionStopHook() {
     return wireSessionStopHookPrompt;
 }
-/** 当前这条目标登记时锁存的档位(真 = 投裸条件,假 = 投壳自造的门)。 */
 export function getWireSessionStopHookCcSemantics() {
     return wireSessionStopHookCcSemantics;
 }
-/**
- * 把 `/goal` 的**原始条件**包成一条对引擎 prompt 载体**可执行**的 Stop 门 prompt。
- *
- * 🔴 适用面(2026-07-26 提货批后):**只用于未达标线的引擎档**(见 {@link CC_STOP_SEMANTICS_MIN_SERVER})。
- * 达标档起引擎自己按 CC
- * 220 逐字组装(系统提示 + 会话转录 + `wrapCondition`),那一档投的是**裸条件** —— 见
- * {@link ccStopSemanticsFromVersion} 与 `hooksForWire()` 的分道(见 {@link goalStopHookMatcher})。
- * 本函数保留,是 tolerate-absent 的实体:老引擎上退回它,仍能拦一次;删掉它等于在老引擎上静默失效。
- *
- * 🔴 为什么必须包(2026-07-26 live 围栏实测,不是设计偏好):CC 单进程的 prompt 钩子执行器
- * (`src/utils/hooks/execPromptHook.ts`)会给条件**套一层系统提示**(「You are evaluating a hook…
- * 回 `{ok:true}` / `{ok:false,reason}`」)**并把整段会话前置**,所以裸条件在 CC 那边能被真评估。
- * 引擎侧的载体两样都没有:
- *   · 无系统提示、无会话历史;
- *   · Stop payload 的 `transcript_path` 是**空串**(server basePayload),评估者对本会话是**瞎的**;
- *   · 判据 schema 也不同 —— core 只认 stdout JSON 的 `decision:"block"`。
- * 实测(钉版 server 1.277.1 + core 1.416 + 真模型):裸条件 `the project contains a file named
- * DONE.txt` 送过去,载体照样被调用,模型回的是**散文**(「I don't have direct access to your file
- * system…」)⇒ `parseHookStdout` 拿不到 decision ⇒ **一次都不拦**。即:不包 = 每次停机白烧一次
- * 模型调用、零效果。
- *
- * 所以这里把条件包成引擎契约里**能落地**的形状。诚实标注它**够不到 CC 的完整语义**:
- *   · 能做到:每个 turn 的**第一次**停机尝试被拦下,目标原文重新注入给模型,逼它自查后再收尾
- *     (`stop_hook_active` 为真时门自己收手 ⇒ 不会无限拦停);真正「条件是否成立」的判断交给
- *     **有会话、有工具的主模型**,而不是让瞎的评估者假装判断;
- *   · 做不到:CC 那种「拦到条件真成立为止」(需要引擎把 transcript 交给载体)、以及「条件满足后
- *     自动清除目标」。这两条是**等件**,meta 文案因此不照抄 CC `Pwo`(见 cmd-goal.tsx)。
- *
- * 台账仍存**原始条件**({@link getWireSessionStopHook}),所以 `/goal clear` 读回的是用户写的那句。
- */
 export function buildGoalStopHookPrompt(condition) {
     const reason = `[session goal] Before you stop: verify that this goal actually holds — ${condition}. ` +
         `If it does hold, say so plainly and finish. If it does not, keep working toward it and do not ` +
@@ -216,31 +59,11 @@ export function buildGoalStopHookPrompt(condition) {
         'Otherwise reply with exactly:\n' +
         JSON.stringify({ decision: 'block', reason }));
 }
-/**
- * `hooksWireCaps.ts` 的 `hooksForWire()` 尾部合流点(REF-CC-156 拆分的接口):治理门跑完之后,
- * 调用方传入 `managedOnly`(allowManagedHooksOnly 是否命中),本函数原样返回要 concat 进
- * `merged['Stop']` 的那一条 matcher,或 `null`(未登记 / 被 managedOnly 挡 / overlay 未 armed)。
- * 非导出到包外(不进 `index.ts` 的公开面)——只是本文件与 `hooksWireCaps.ts` 之间的私有接口。
- */
 export function goalStopHookMatcher(managedOnly) {
     if (wireSessionStopHookPrompt === null || managedOnly || !isGoalStopHookWireArmed())
         return null;
-    // 🔴 这个双 cast 是**类型面的最小且诚实的局部处置**,不是「绕过校验」:
-    //   · server **运行时接受** prompt 形(hook-runner 条目白名单与 command/http/agent 并列,
-    //     [1721] 6 条行为用例 + cli 仓 live 围栏双证);
-    //   · 卡着的是 **SDK 类型**:`SettingsHookCommand.type` 仍是字面量 `"command"`
-    //     (@sema-agent/sdk dist/settings.d.ts,prompt 形 v1 标 DEFERRED);
-    //   · **registry-core 建模 prompt 形在 [1717]① 等件中**,SDK 随后放开。
-    // 到位后这里换成直类型、去掉 cast(唯一改动点,调用面不动)。
     return {
         matcher: '',
-        // 🔴 投影形**按引擎档位分道**(锁存于 set 那一刻,见 setWireSessionStopHook):
-        //   · CC 语义档(server ≥ CC_STOP_SEMANTICS_MIN_SERVER)⇒ **裸条件** —— 与 CC `Xdr` 注册的
-        //     `{type:"prompt",prompt:condition}` 逐字同形;引擎自己套 CC 系统提示 + 会话转录 +
-        //     `wrapCondition`,再包一层只会打架;
-        //   · 老引擎档 ⇒ 包装后的可执行门 prompt(裸条件在老引擎上一次都拦不住 —— 见
-        //     buildGoalStopHookPrompt 的实测说明)。
-        // 台账两档都存**原始条件**,供 `/goal clear` 读回。
         hooks: [
             {
                 type: 'prompt',
@@ -251,7 +74,6 @@ export function goalStopHookMatcher(managedOnly) {
         ],
     };
 }
-/** 测试钩:清 `/goal` 锁存(壳里靠进程边界隔离;包内同进程多组断言必须能清)。 */
 export function __resetGoalStopHookForTests() {
     wireSessionStopHookPrompt = null;
     wireSessionStopHookCcSemantics = false;