/** * [ref] 件⑤(core PM 三仓扫查 [ref] server 条 ③,并入 [ref])—— 「本 run 是否**显式**声明了 bypassPermissions」的 * per-session 登记簿,供 `boot/runner-deps.ts` 的 `onError(phase:"config")` 汇点给 core 的 `shell-gate-off` * 忠告定级。 * * ## 为什么需要它 * core 在「shell 门 doctrine=off ∧ 挂了真可写 Bash」时经 `onError(phase:"config", classification:"shell-gate-off")` * 发一条忠告(`prepare-hands-readface.js`),但它分不清 off 是**调用方显式选的**(server 把 `permissionMode: * "bypassPermissions"` 翻成 `shellGate:"off"`,[ref] 表)还是**没表态落到 core 默认**(无壳直连部署,真值得 * 一条 warn)。这正是真实用户提案里「bypass 下照打 shell gate doctrine is off 告警」的根:正常态被当异常打。 * 汇点只拿到 `ctx.sessionId`,而生效模式是 server 在 resolve-spec 阶段④ 单点算出的(`effectivePermissionMode`), * 所以由 resolve-spec 在算出 effMode 的那一行登记、汇点按 sessionId 回查。 * * ## 键 * `auth.sessionId`:authorizer 在服务路径上**恒**铸 session id(`security.ts` `uuidv7()`,core 的无 sessionId * 分支在服务路径不可达),且 spec.sessionId = 同一值 ⇒ core 回调的 `ctx.sessionId` 与登记键同源。 * 缺 authorizer 的裸装配(测试桩)拿不到键 ⇒ 不登记 ⇒ 汇点按「未声明」处理 = 仍 warn(退化方向=多一条告警, * 不是少一条)。 * * ## 已知界(codex r2 [medium],登记不修:属主在 core 回调契约) * 键是 session 而非**执行**:同 session 并发第二次提交在 resolveSpec 后才被 409 拒,其登记已覆盖前一次——若被拒的 * 那次是 bypass 而在跑的那次不是,且忠告恰在这一窗内发出,则一条本该 warn 的 `shell-gate-off` 被降成 info(仍整行 * 落日志、字段齐全,执法零变)。窗 = 在跑 run 的 resolveSpec 到其 prepare 期忠告之间(毫秒级,且要同 session 并发 * 提交 + 模式相反)。执行唯一的归因需要 core 回调 `ctx` 带 taskId / shellGate 出处(已作 core 侧诉求登记), * 到货后本簿退役。 * * ## 界 * 有界 Map(插入序淘汰,默认 10k 条,与 caps 缓存同量级):session id 是开集,长命 worker 不能无界累积。 * 淘汰掉的旧会话再来忠告时同样回落「未声明」⇒ warn(同一退化方向)。每次 resolve 覆写(同 session 后一轮改 * 模式时以最近一轮为准;续跑四条 rebuild 腿都经 resolveSpec ⇒ 同律登记)。 */ export interface SessionShellGateRegistry { /** resolve-spec 阶段④:登记本 session 这一轮是否显式声明 bypassPermissions(= server 翻成 shellGate:"off")。 */ note(sessionId: string | undefined, explicitOff: boolean): void; /** runner-deps 汇点:本 session 最近一轮是否显式声明了 off。未登记/已淘汰 ⇒ false(退化=照 warn)。 */ explicitlyOff(sessionId: string): boolean; } export declare function createSessionShellGateRegistry(cap?: number): SessionShellGateRegistry; //# sourceMappingURL=session-shell-gate-registry.d.ts.map