@sema-agent/server 7.43.0 → 7.44.0

package/dist/task-settings.js

@@ -1,71 +1,13 @@
-/**
- * TaskRequest.settings wire — project a client's per-request `SemaSettings` stamp onto the per-task `TaskSpec`,
- * TIGHTEN-ONLY (deny-wins), at the SAME seam as runtime-governance (after the approval baseline + operator
- * governance). Backs the remote-mode settings path: sema runs over HTTP→engine with no local Runner, so the
- * resolved settings can't be applied by a local `tightenTaskSpec` — they ride on `TaskRequest.settings` and the
- * SERVICE projects them into the engine here.
- *
- * Design: `TaskRequest.settings` is a
- * PER-REQUEST ephemeral stamp = the v2-design TASK layer (a single-run override, NOT durable). It folds into THIS
- * spec via {@link tightenTaskSpec} and that is all — it is NEVER written to the durable `SessionPolicyStore` (the
- * operator/principal axis, design/99 §E6, a different trust axis + lifecycle). Re-applying on a resume leg is
- * idempotent (the same tighten), so no special resume handling is needed (mirrors runtime-governance).
- *
- * 🔒 SECURITY INVARIANTS (SDK settings.ts §3.3):
- *  - permissions are TIGHTEN-ONLY — folded via `tightenTaskSpec` (deny-wins `combinePolicies`); it THROWS on any
- *    override that would LOOSEN a stricter base safety field. The client can only ADD denies/asks/handsReadOnly on
- *    top of the deployment + operator baseline, never widen it.
- *  - permissionMode(轴B #2 注释保鲜,1.254——[816]/[820] 后的真实现):`defaultMode` 收**五**模式
- *    (default | acceptEdits | plan | bypassPermissions | auto),bypass/auto 被 HONOR 为 gate-shape 选择
- *    ——但深层不变量未变:bypass=「不加 ask 门」,恒不越部署基线(tightenTaskSpec deny-wins,基线 deny/
- *    ask 照压);精化语义见 :2xx 行内注释。旧头注的「NEVER honored/三模式白名单」是 pre-[816] 拍照。
- *
- * 🔴 SYNC WITH sema-cli(壳仓)的 `src/sema/settings/seam.ts`: the permissions→toolPolicy + §6.4 permissionMode derive MIRRORS
- * the shell's LOCAL-Runner resolver — both compose the SAME core primitives (`createAllowDenyPolicy` /
- * `combinePolicies` / `tightenTaskSpec`), so the deny-wins ENFORCEMENT is core-single-source. Only the COMPOSITION
- * is duplicated for the remote path; a proposed follow-up extracts it to `@sema-agent/sdk` for true
- * single-source. Because the core backstops (deny-wins + tighten-throws-on-loosen + this bypass-reject) hold either
- * way, a composition drift would be a local/remote CONSISTENCY gap, never a privilege escalation.
- *
- * v1 scope: `permissions` + `permissions.defaultMode` + `model` + `outputStyle` + `env` (shipped 1.26.0). DEFERRED
- * (need a seam, flagged to the team + advertised in capabilities so a caller never silently loses a setting):
- *  - (`env` is NO LONGER deferred — systematic-audit doc fix: core kept no untrusted `TaskSpec.env` seam (types §7
- *    Q4), so the SERVICE applies it on the TRUSTED host lane: `settings.env` → `cleanEnvMap` → `shellEnv` on the
- *    executionEnvFactory, single-user-gated. See `deriveSettings` below + main.ts.)
- *  - (`hooks` NO LONGER deferred either — 轴B #2 注释保鲜:applied 形已接线(本文件 hooks 分片 +
- *    main.ts 单用户闸),仅 malformed 才报 deferred;旧「需要 remote hook-runner」是接线前拍照。)
- */
 import { combinePolicies, createAllowDenyPolicy, createFsWriteGatePolicy, tightenTaskSpec, resolveReasoningProfile, rankOf, isThinkingLevel, CYBER_RISK, URL_SAFETY, HARNESS_SECTION_ANCHOR, RUN_WORKFLOW_TOOL_NAME, } from "@sema-agent/core";
 import { findCcRuleFormNames, findUnmatchableToolNames, formatUnmatchableToolNames } from "./config.js";
 import { parseHooksConfig } from "./hooks/hook-runner.js";
-/**
- * R4: coerce a raw top-level `body.permissionMode` (the LIGHT per-turn wire — the shell sends the
- * CC permission mode RAW, axis-agnostic; the service interprets) to a service-honored mode, or undefined.
- * 🔴 TIGHTEN-ONLY vs the DEPLOYMENT baseline still holds for every value: the mode only selects the CLIENT-derived
- * gate ({@link deriveSettingsPolicy}); it can never subtract from the deployment/operator policy (applyTaskSettings
- * folds via tightenTaskSpec, deny-wins). Post-[816] the honored set is the five-word table above (NOT "CC verbatim" —
- * see the {@link SettingsPermissionMode} header for the three-set contrast; the earlier "five CC modes" wording here
- * was A-065 P2-1's finding: no CC set has five members). `acceptEdits`,
- * `bypassPermissions` and `auto` are HONORED as gate-shape choices (they no longer coerce to `default`, which
- * would FORCE the manual ask gate onto a caller that explicitly asked for less asking — with the gate live, the old
- * coercion would have been a behavior change for them, incl. a headless-deny regression for bypass callers). An
- * UNKNOWN string still coerces to `default` (fail-safe: the most-asking mode).
- * #157-②: fresh submits can no longer REACH the unknown-word arm — the HTTP gate 400s a non-five-mode value
- * (server.ts, sibling of promptProfile) and the wire type is a closed enum. This lenient fold stays for the one
- * population the gate deliberately does not cover: RESUME replay of a persisted pre-gate body (outputStyle/model
- * two-layer posture — bricking a resume over a value that was legal at submit time is worse than the quiet fold).
- */
 export function coercePermissionMode(raw) {
     if (raw === "plan" || raw === "acceptEdits" || raw === "default" || raw === "bypassPermissions" || raw === "auto")
         return raw;
     if (typeof raw === "string" && raw.length > 0)
-        return "default"; // unknown → default (most-asking of OUR five; A-065 P3-1: for CC's `dontAsk` (=auto-deny) this fold IS a widening by CC semantics — reachable only via resume replay, fresh submits 400 at the HTTP gate)
-    return undefined; // absent → no opinion (don't touch the spec)
+        return "default";
+    return undefined;
 }
-/** L2 ultracode (design/111): the effective `thinking` level given the explicit `reasoningEffort` and the ultracode
- *  preset. ultracode FLOORS at the "ultra" tier — core's single source `resolveReasoningProfile("ultra").thinking`
- *  (= "max"), never a hardcoded literal — so an explicit higher tier still wins (none exists above max today;
- *  future-proof). Awareness rides for free: core composes ORCHESTRATION_AWARENESS from thinking∈{xhigh,max}, no field. */
 export function effectiveThinking(reasoningEffort, ultracode) {
     const explicit = isThinkingLevel(reasoningEffort) ? reasoningEffort : undefined;
     if (!ultracode)
@@ -73,56 +15,13 @@ export function effectiveThinking(reasoningEffort, ultracode) {
     const ultra = resolveReasoningProfile("ultra").thinking;
     return explicit && rankOf(explicit) > rankOf(ultra) ? explicit : ultra;
 }
-/** R4: fold a top-level `body.permissionMode` onto the parsed settings as `permissions.defaultMode` (the top-level
- *  field is the explicit per-turn intent → it WINS over a bundle defaultMode). Creates a minimal settings object when
- *  no `body.settings` bundle was sent. The result flows through {@link applyTaskSettings} (tighten-only). */
 export function withPermissionMode(settings, mode) {
     const base = settings ?? {};
     return { ...base, permissions: { ...base.permissions, defaultMode: mode } };
 }
-/**
- * design/201 §6-1 —— 本请求的**生效** permission mode,单点。优先序逐字同 {@link withPermissionMode}:
- * 顶层 `body.permissionMode`(本轮显式表态)赢过 bundle 的 `settings.permissions.defaultMode`;两处
- * 都没有 ⇒ `undefined` = **无表态**(调用点据此不写键,而不是替调用方选一个默认值)。
- *
- * 🔴 为什么必须是一只函数:同一个「生效模式」此前在 resolve-spec 里被算了两次(hooks 腿的
- * `permission_mode` 载荷、settings 折叠腿的 `withPermissionMode`),三审同点判定翻译表**不得**成为
- * 第三个算点 —— 三处各算各的,任何一次优先序修订都会让三面分家,而分家在这条轴上的形态是
- * 「壳发的 bundle bypass 在 A 面生效、在 B 面没生效」这种最难被外部发现的静默偏差。
- */
 export function effectivePermissionMode(body, settings) {
     return coercePermissionMode(body.permissionMode) ?? settings?.permissions?.defaultMode;
 }
-/**
- * design/201 §2 —— 显式 permission mode → `TaskSpec.shellGate` 档位的**翻译表(单一真源)**。
- *
- *  · `bypassPermissions` ⇒ `"off"` —— CC `--dangerously-skip-permissions` 的对位裁定
- *    (与 fs-write 面的 bypass 臂两面归一,见 {@link deriveSettingsPolicy})。
- *  · `auto` ⇒ `"classify"` —— **design/201 §8 开口按施工期新披露亲裁改译**(原裁定字面是 off,
- *    §8 保留「core auto 分类器覆盖面有新披露时可独立再裁,表驱动一行」——新披露见下段):
- *
- *    ⚠️ **`auto` 这一行有一条待裁的开口(design/201 §8 明列「core auto 分类器覆盖面有新披露时可独立再裁,
- *    表驱动一行」)。施工期对抗复审给出了那条新披露,已亲读安装包核实**:
- *      · core 只在**已经产生 `ask`** 之后才咨询分类器(`dist/core/hooks.js`:`if (input.autoMode &&
- *        decision.action === "ask" …)`);
- *      · 而 `shellGate:"off"` 下 core **不铸任何 shell 面的门**(`dist/core/runner/prepare-task.js` 的
- *        `shellGate === "off"` 臂反而发一条 `classification:"shell-gate-off"` 的 onError:「真可写 Bash 挂着
- *        却没有 shell 安全轴折叠」)。
- *    两条合起来:`auto` × off ⇒ Bash 既不产 ask、分类器也就永不被咨询 —— off 档下「筛选权交给分类器」
- *    不成立。故 auto 归 classify 组:分类器坐在 classify 产的 ask 之上,语义才真是「交给分类器」
- *    (良性只读命令由分类器自动放行,其余 ask;这正是 auto 模式的本义)。发车帖向 [3378] 裁定链披露此
- *    一行偏离;core auto 分类器若来日在 off 档下也有咨询点,可再裁回(表驱动一行)。
- *  · `default` / `acceptEdits` / `plan` ⇒ `"classify"` —— 这一档原先由壳无条件注入 `MANUAL_MODE_SHELL_GATE`
- *    供给(车道缺省走了 operator 通道),现在归位到表态轴。`plan` 本身 handsReadOnly(core 明写此档下
- *    shellGate 无效),给它 classify 纯为一致性。
- *
- * 🔴 **入参非可选**:缺席(无表态)不是这张表的一行 —— 它的语义是「不写这个键」,只能在调用点判。
- * 把它折进来会逼出一个 `undefined` 返回值,而那正是「写 off」与「不写」被混同的入口(core 的
- * 缺席默认是 off,但**写**一个 off 会成为 governance 的 base,与缺席不是同一件事)。
- *
- * 🔴 **闭集 exhaustive switch,无 default 臂**:五个模式词是封闭词表,新增一个模式而不更新本表
- * 是**编译错误**(#157 的安全轴纪律:词表的未知项不许有静默兜底臂)。
- */
 export function shellGateForMode(effMode) {
     switch (effMode) {
         case "bypassPermissions":
@@ -134,18 +33,11 @@ export function shellGateForMode(effMode) {
             return "classify";
     }
 }
-/** Cap on `outputStyle` length — it lands in the system prompt, so it shares the `MAX_SYSTEM_PROMPT_CHARS` (16384)
- *  posture (an uncapped prompt body is a per-turn token-cost hole; adversarial review). Exported so the HTTP layer
- *  (prepareSpec) can 400 fail-loud on submit with the SAME bound this defensive parse enforces on every path. */
 export const MAX_SETTINGS_OUTPUT_STYLE_CHARS = 16_384;
-/** Cap on the element count of each permission list (allow/deny/ask) — bounds a pathological rule blast. */
 export const MAX_SETTINGS_PERMISSION_RULES = 1_000;
-/** Caps on `settings.env` — bound a pathological env blast (count + per-value length; values land in the shell env). */
 export const MAX_SETTINGS_ENV_VARS = 256;
 export const MAX_SETTINGS_ENV_VALUE_CHARS = 32_768;
 export const MAX_SETTINGS_ENV_KEY_CHARS = 256;
-/** A `Record<string,string>` of non-empty string keys → string values (capped), or undefined. Untrusted input →
- *  defensive (drop non-string entries, over-long values, and bound the count). */
 function cleanEnvMap(v) {
     if (v === null || typeof v !== "object" || Array.isArray(v))
         return undefined;
@@ -154,7 +46,7 @@ function cleanEnvMap(v) {
     let seen = 0;
     for (const [k, val] of Object.entries(v)) {
         if (n >= MAX_SETTINGS_ENV_VARS || seen >= MAX_SETTINGS_ENV_VARS * 8)
-            break; // bound BOTH accepted + total iterated (adversarial-review LOW)
+            break;
         seen++;
         if (typeof k === "string" && k.length > 0 && k.length <= MAX_SETTINGS_ENV_KEY_CHARS && typeof val === "string" && val.length <= MAX_SETTINGS_ENV_VALUE_CHARS) {
             out[k] = val;
@@ -163,29 +55,17 @@ function cleanEnvMap(v) {
     }
     return n > 0 ? out : undefined;
 }
-/** A string[] of non-empty strings (capped at {@link MAX_SETTINGS_PERMISSION_RULES}), or undefined. Untrusted input
- *  → defensive (drop non-strings/empties; cap the count). */
 function cleanStringArray(v) {
     if (!Array.isArray(v))
         return undefined;
     const out = v.filter((x) => typeof x === "string" && x.length > 0).slice(0, MAX_SETTINGS_PERMISSION_RULES);
     return out.length > 0 ? out : undefined;
 }
-/**
- * Validate an untrusted `body.settings` (raw `unknown` off the wire) into the service-trusted {@link
- * ParsedTaskSettings}. NEVER trusts the wire type — every field is shape-checked; unknown keys are ignored
- * (forward-compatible, matching the SDK's open `[k: string]: unknown`). `defaultMode` accepts the FIVE modes
- * (post-[816]; unknown values coerce to `default` — see the header note). Returns the
- * present-but-deferred field names so the caller can warn/advertise rather than silently dropping `env`/`hooks`.
- */
 export function parseTaskSettings(raw) {
     if (raw === null || raw === undefined || typeof raw !== "object")
         return { deferred: [] };
     const s = raw;
     const deferred = [];
-    // `hooks` is NO LONGER deferred(hook-runner 阶段一):契约校验(registry-core HooksConfig +
-    // 服务侧上限)通过 → 进 applied 形状,由 apply 侧单用户闸决定翻不翻;malformed → 报 deferred(镜像 env 的
-    // present-but-malformed 姿势——本函数是 resume 等路径的防御层,submit 路径另有 fail-loud 400)。
     let hooksConfig;
     if (s.hooks !== undefined && s.hooks !== null) {
         const parsedHooks = parseHooksConfig(s.hooks);
@@ -196,11 +76,9 @@ export function parseTaskSettings(raw) {
     }
     const shellEnv = cleanEnvMap(s.env);
     if (s.env !== undefined && s.env !== null && shellEnv === undefined)
-        deferred.push("env"); // present but malformed/empty → report
+        deferred.push("env");
     const out = {};
     const perms = s.permissions;
-    // F1(#157 复审留裁裁修):出现但形错(数组/标量)——本层是 RESUME 重放也走的宽容层,不 throw,但必
-    // 留痕 deferred(镜像 env/hooks malformed 姿势;fresh submit 已被 http 门 400 拦,这里护的是存量行)。
     if (perms !== undefined && perms !== null && (typeof perms !== "object" || Array.isArray(perms))) {
         deferred.push("permissions");
     }
@@ -209,13 +87,6 @@ export function parseTaskSettings(raw) {
         const allow = cleanStringArray(p.allow);
         const deny = cleanStringArray(p.deny);
         const ask = cleanStringArray(p.ask);
-        // 🔒 whitelist the five honored modes (OUR set, not a CC set — see SettingsPermissionMode header / A-065 P2-1);
-        // any other value is dropped (absent = no opinion). This drop arm is the RESUME-replay lenient layer — fresh
-        // submits already 400 at the HTTP gate (server.ts #157-③, [2766] ruling), same two-layer posture as the
-        // top-level permissionMode leg. `bypassPermissions` is
-        // accepted post-[816] because it now means "do not ADD the mode-derived fs-write ask gate" — exactly every
-        // mode's pre-[816] behavior — and can never subtract from the deployment baseline (tightenTaskSpec deny-wins;
-        // the module-header §3.3 invariant is thereby REFINED, not weakened: bypass still cannot LOOSEN anything).
         const mode = p.defaultMode;
         const defaultMode = mode === "default" || mode === "acceptEdits" || mode === "plan" || mode === "bypassPermissions" || mode === "auto" ? mode : undefined;
         if (allow || deny || ask || defaultMode) {
@@ -224,15 +95,11 @@ export function parseTaskSettings(raw) {
     }
     if (typeof s.model === "string" && s.model.length > 0)
         out.model = s.model;
-    // outputStyle is appended to the system prompt → cap it (defense in depth; prepareSpec 400s an over-cap value on
-    // submit, this drops it on any path the HTTP gate didn't cover, e.g. a resume of a pre-cap stored body).
     if (typeof s.outputStyle === "string" && s.outputStyle.length > 0 && s.outputStyle.length <= MAX_SETTINGS_OUTPUT_STYLE_CHARS) {
         out.outputStyle = s.outputStyle;
     }
     if (shellEnv)
         out.shellEnv = shellEnv;
-    // L2 ultracode preset (design/111): a CC-parity boolean. Only `true` opts in; any other value is ignored (a settings
-    // bundle that ONLY sets ultracode still returns `settings` via the hasApplied OR below).
     if (s.ultracode === true)
         out.ultracode = true;
     if (hooksConfig)
@@ -240,33 +107,12 @@ export function parseTaskSettings(raw) {
     const hasApplied = out.permissions !== undefined || out.model !== undefined || out.outputStyle !== undefined || out.shellEnv !== undefined || out.ultracode !== undefined || out.hooks !== undefined;
     return { settings: hasApplied ? out : undefined, deferred };
 }
-/** Defensive acceptance of the `appendSystemPrompt` rider ([1478] R2 + codex F2): the HTTP 400 gate (prepareSpec,
- *  MAX_SYSTEM_PROMPT_CHARS) only covers FRESH submits — every resume family re-enters resolveSpec on a STORED body,
- *  and a pre-1.243 store preserved unknown request keys verbatim (the field was INERT then), so an over-cap legacy
- *  value must not become active prompt content after rollout (context exhaustion / spend hole). Over-cap ⇒ dropped +
- *  warned — the rider was inert pre-upgrade, so dropping preserves the stored task's prior behavior; a 4xx here would
- *  permanently brick that task's resume instead (same defensive posture as parseTaskSettings' outputStyle drop).
- *  Cap value = the submit gate's (16384; MAX_SETTINGS_OUTPUT_STYLE_CHARS — both land in the same spec field). */
-/** TRUE when `text` is an ALREADY-ASSEMBLED system prompt — core's migration guard detects the same three
- *  constitution anchors and takes the pass-through assembler arm, whose section subset (OPAQUE_KEPT, dist-read)
- *  has NO `core/role.append`: any append rider (top-level or settings.outputStyle) would be SILENTLY discarded
- *  there. Shared predicate for the submit 400 gate, the resolveSpec resume mirror, and the center-declaration
- *  probe — one definition so the three gates can't drift. */
 export function hasConstitutionAnchors(text) {
     return typeof text === "string" && text.includes(CYBER_RISK) && text.includes(URL_SAFETY) && text.includes(HARNESS_SECTION_ANCHOR);
 }
-/** codex R9 (provider-aware append-less detection): mirrors core's ACTUAL pass-through triggers instead of a raw
- *  body-text heuristic — the assembler's migration guard probes (a) `stableBlocks` identity declarations and
- *  (b) `stableSystem` OUTPUT for the three anchors; a plain `userSystemPrompt` under the DEFAULT provider (no
- *  scenario provider) never triggers it and `core/role.append` is retained, so an anchored systemPrompt there
- *  must NOT block/strip a rider (R9 false-positive: unbranded default / scan rejected valid combos). Probing
- *  calls the provider hooks with a minimal ctx — server providers (and centerPromptProvider) are pure functions
- *  of ctx, and the same hooks run again inside core's assembly; a hook throw = conservative false (core will
- *  fail the task loudly on its own). `replaceAll` owns the whole prompt(legacy free-form `system()` 腿已随 core 2.0.0 删除)
- *  (REPLACE_ALL_EXCLUDED strips role.append) → append-less true. */
 export function providerDropsAppend(provider, userSystemPrompt) {
     if (!provider)
-        return false; // core defaultPromptProvider — role.append always retained
+        return false;
     if (provider.replaceAll === true)
         return true;
     const ctx = { userSystemPrompt, tools: [], memoryEnabled: false, consolidationEnabled: false };
@@ -286,11 +132,11 @@ export function providerDropsAppend(provider, userSystemPrompt) {
             return false;
         }
     }
-    return false; // core 2.0.0 删除了 legacy free-form `system()` 腿(不存在的腿不需要探测)——结构化 provider 到此都保 append
+    return false;
 }
 export function acceptAppendSystemPrompt(v, warn, packDropsAppend) {
     if (v === undefined)
-        return undefined; // absent = the only QUIET arm (codex R8: defined-but-malformed must warn)
+        return undefined;
     if (typeof v !== "string" || v.length === 0) {
         warn?.(`appendSystemPrompt dropped: defined but malformed (${typeof v === "string" ? "empty string" : `non-string: ${typeof v}`}) — fresh submits 400 this shape; a stored resume body carrying it is normalized to absent`);
         return undefined;
@@ -299,29 +145,13 @@ export function acceptAppendSystemPrompt(v, warn, packDropsAppend) {
         warn?.(`appendSystemPrompt dropped: ${v.length} chars exceeds the ${MAX_SETTINGS_OUTPUT_STYLE_CHARS} cap (pre-cap stored body on a resume leg?)`);
         return undefined;
     }
-    // codex R2/R3/R9: `packDropsAppend` = the caller's PROVIDER-AWARE append-less verdict ({@link
-    // providerDropsAppend} over the effective provider / center snapshot — NOT a raw body-text heuristic, which
-    // false-positived on default-provider scenarios where core retains role.append). Fresh submits 400 the combo
-    // in resolveSpec; this is the resume-family mirror — the rider was INERT pre-1.243, so dropping WITH a warn
-    // preserves the stored task's prior behavior and leaves an audit trail. (core typed error at the assembly
-    // boundary = the structural endgame, requested on the board.)
     if (packDropsAppend === true) {
         warn?.("appendSystemPrompt dropped: the effective prompt pack cannot mount the append rider (assembled-identity/stableSystem pass-through, replaceAll, or legacy provider — no core/role.append section)");
         return undefined;
     }
     return v;
 }
-/** A name-keyed ASK-list ToolPolicy: a tool whose NAME is in `askNames` tightens to `ask` (HITL gate); every other
- *  tool is out of scope (`allow`). core's `createAllowDenyPolicy` has only allow/deny slots (no `ask`), so the
- *  CC-parity `permissions.ask` list — "prompt the human before THIS tool" — needs this thin policy. Composed
- *  deny-wins with the allow/deny base, so `ask` only ever tightens (a baseline `deny` still wins; `allow`→`ask`). */
 function createAskListPolicy(askNames) {
-    // RAW matching (core 5.0.0 RB-476 — the canonicalToolName fold is GONE): the rule name is compared to
-    // `req.toolName` verbatim, no alias folding in either direction. A rule written against a retired alias
-    // ("MultiEdit"/"Task") therefore matches NOTHING — which is why such a list is rejected up front
-    // ({@link rejectUnmatchableSettingsNames}) instead of being silently mounted as a no-op gate.
-    // (旧注写的 "Canonical-space matching, mirroring core's createAllowDenyPolicy (1.202)" 是折叠面还在时的
-    //  拍照,与下面这行 RAW 代码整段矛盾——同批改正,连同 :348 的 "canonical toolName key space"。)
     const askSet = new Set(askNames);
     return {
         check(req) {
@@ -329,59 +159,28 @@ function createAskListPolicy(askNames) {
                 ? { action: "ask", message: `tool "${req.toolName}" requires approval by your settings`, decisionReason: "rule" }
                 : { action: "allow" };
         },
-        // [931]③ core 1.300 名单池审计面:自定义 closure 无元数据曾是审计盲区(`ask:["*"]`/typo 名静默
-        // no-op)——附 nameSets 后 core prepare 对实挂宇宙交叉核,无匹配名 → onError config.toolpolicy.
-        // unmatched_names(enforcement 字节不变,纯观测)。core combinePolicies 全链透传。
         nameSets: [{ ask: askNames }],
     };
 }
-/** [1245]/[1247]③ — the mode-derived dynamic-workflow ask gate (CC "Run a dynamic workflow?" dialog, engine half).
- *  core mounts `run_workflow` with effect="write" and NO exemption in the gate stack, but the mode-derived leg here
- *  only ever gated fs writes — so manual/default mode ran workflows un-asked ([1245] clay dogfood). This leg keys
- *  the canonical name(`Workflow`;5.0.0:旧拼法 aliases 已随 core RB-476 退役,raw 直比)
- *  and attaches on default/auto/acceptEdits, independent of the fs-gate wiring (workflow gating is not
- *  fs-dependent — sandbox lanes get it too). acceptEdits asks ON PURPOSE: CC's acceptEdits auto-allows file edits
- *  only, a workflow confirmation is not an edit ([1248]② — cli to verify against the 212 live shell; flip there
- *  if the real shell differs). bypassPermissions/undefined-mode attach nothing (pre-existing behavior); plan is
- *  blocked upstream by handsReadOnly (effect="write"). Deployment disable stays `RuntimeCaps.allowWorkflows` —
- *  this leg is the per-request HITL gate, not the capability switch.
- *
- *  🔴 A-033.1(#256):这三处曾**手抄字面量** `"Workflow"`。core 改名该工具时,手抄的名字与 core 实挂的名字
- *  分家 ⇒ ask 腿的 `req.toolName !== "Workflow"` 恒真、deny 腿恒假,**整条门不触发**,而且不报错、不留痕
- *  —— 安全轴上的静默 fail-open。现在四处引用(本文件两条腿 + `nameSets` 审计面 + `http/server.ts` 的
- *  可满足性预检)全部派生自 core 导出的 {@link RUN_WORKFLOW_TOOL_NAME},core 一改名这四处同步跟着改。 */
 const WORKFLOW_ASK_NAMES = [RUN_WORKFLOW_TOOL_NAME];
 function createWorkflowAskPolicy(isExempt) {
     return {
         async check(req) {
             if (req.toolName !== RUN_WORKFLOW_TOOL_NAME)
                 return { action: "allow" };
-            // codex F2 (durable lane): the "don't ask again this session" grant (decide remember="session" →
-            // approvalExemptionStore) is probed at the POLICY layer here — the durable lane parks every policy `ask`
-            // and its own exempt probe only covers the deployment policy's asks, so without this probe a remembered
-            // Workflow approval would re-park on every later call. Same posture as the fs-write gate's isExempt
-            // (RAW toolName key space — 5.0.0 折叠面退役后各层比对的都是 `req.toolName` 逐字,一个 grant 服务所有层
-            //  靠的是「同一个 raw 名」而不是「同一个 canonical 空间」);a THROWN probe ⇒ not exempt (fail-closed).
             if (isExempt) {
                 try {
                     if (await isExempt(req.toolName))
                         return { action: "allow", decisionReason: "rule" };
                 }
                 catch {
-                    /* fail-closed: keep asking */
                 }
             }
             return { action: "ask", message: `dynamic workflow "${req.toolName}" requires approval in this permission mode`, decisionReason: "rule" };
         },
-        nameSets: [{ ask: WORKFLOW_ASK_NAMES }], // [931]③ audit face, same as createAskListPolicy
+        nameSets: [{ ask: WORKFLOW_ASK_NAMES }],
     };
 }
-/** codex F1 (plan-mode escape): `run_workflow` mounts off self-orchestration INDEPENDENT of the hands band
- *  (core prepare-task dist 亲读:handsReadOnly only strips/reads the hand tools; the runtime plan blocker
- *  `planModeRef` starts INACTIVE and only the model-driven EnterPlanMode tool arms it), so USER-driven plan
- *  (permissionMode=plan) would run workflows — whose child agents write by default — during "read-only"
- *  research. Plan therefore composes an explicit canonical-space DENY (not ask: plan is research, CC blocks
- *  write-effect tools outright), deny-wins under the fold so nothing can un-tighten it. */
 function createWorkflowPlanDenyPolicy() {
     return {
         check(req) {
@@ -392,52 +191,6 @@ function createWorkflowPlanDenyPolicy() {
         nameSets: [{ deny: WORKFLOW_ASK_NAMES }],
     };
 }
-/**
- * Build the per-request permission ToolPolicy from the parsed settings (mirrors shell `seam.ts` — see header).
- *  - base = name-keyed allow/deny (`createAllowDenyPolicy`): an `allow` list narrows to those tools; a `deny` list
- *    hard-blocks — composed deny-wins with an ASK-list ({@link createAskListPolicy}) so `permissions.ask` actually
- *    forces an approval gate (NOT silently dropped — review finding). `deny` > `ask` > `allow` on overlap.
- *  - `defaultMode` derive onto that base ([820]/[822] five-mode table; the fs-write gate needs `gate` wiring —
- *    without it every mode degrades to the base rules only, the pre-[816] behavior):
- *      `default`           → base + `createFsWriteGatePolicy({rootPath: cwd, exemptDirs:[scratchpad], ask})` — CC
- *                            manual: every fs write asks (the [816] P0 fix), scratchpad writes ride free.
- *      `acceptEdits`       → base + the same factory with `acceptDirs:[cwd]` — writes INSIDE the cwd subtree
- *                            auto-allow, OUTSIDE still ask (CC 207 dirname-variant card). NOT a loosen vs the
- *                            deployment: the factory only ever emits allow/ask and is folded deny-wins, so a
- *                            baseline deny/ask still wins; vs `default` it is simply a narrower CLIENT gate, and
- *                            both are client-side ADDITIONS the client may size itself.
- *      `plan`              → handsReadOnly + present_plan (unchanged; the write tools never reach an ask).
- *      `bypassPermissions` → base only, NO factory ([820] table: bypass = "不加门" not "开门" — deployment
- *                            approval/governance baselines still apply; this is exactly every mode's pre-[816]
- *                            derive, so bypass grants nothing that wasn't already granted).
- *      `auto`              → base + the `default` factory (ask 兜底) — core's auto-mode classifier (entitlement-
- *                            gated: RunnerDeps.autoMode ∧ runtimeCaps.autoMode, 1.276/1.277) screens asks UPSTREAM
- *                            of resolveAsk, allowing safe calls and leaving suspicious ones on the ask path ([822]②).
- *      absent (undefined)  → base only, NO factory: an expressed-no-mode request keeps its pre-[816] behavior
- *                            (attaching the ask gate on a mere allow/deny-list stamp would regress headless callers
- *                            that never asked for a mode; the shell always sends its mode explicitly).
- * Returns the composed ToolPolicy + whether `handsReadOnly` should tighten. Returns `undefined` policy when there
- * is no permission rule and no mode-derived gate (nothing to project).
- */
-/**
- * A3 — the per-request leg of the ONE "this name can never match a live tool" judgment (single source:
- * config.ts {@link findUnmatchableToolNames}; the other two legs are the `APPROVAL_*` env vars, which reject at
- * boot, and the center-published `runtime.approvalRequire`, which rejects that domain and keeps the prior value).
- *
- * WHY this leg exists: `ask`/`deny` are mounted as RAW name comparisons (`createAskListPolicy` /
- * core's `createAllowDenyPolicy`, the 5.0.0 fold removal), so a retired name ("Task"/"bash"/"KillShell") or a
- * pre-prefix/incomplete MCP name ("figma__x"/"mcp__figma") mounts a gate that matches NOTHING — the caller
- * believes it added an approval gate or a hard block and got neither. That is the FAIL-OPEN direction, and it was
- * silent on this leg. Throwing here surfaces as a 422 at the HTTP boundary (resolve-spec already wraps every
- * throw out of `applyTaskSettings`), i.e. the same fail-loud posture the other two legs have.
- *
- * `allow` is deliberately NOT judged by the GENERAL arm: it is a WHITELIST — a name that matches nothing leaves
- * the allowlist effectively empty, so every tool falls to "not in the allowlist" and is DENIED. That fails closed
- * and is immediately visible to the caller, which is a different (and acceptable) failure mode from a silent hole.
- * The ONE exception is the CC-rule-form arm ({@link findCcRuleFormNames}, #186): `allow: ["Bash(ps:*)"]` is the
- * shape a CC user writes to get FEWER prompts and it silently costs them Bash entirely — a spelling-family error,
- * not a typo, so it is refused on all three lists. See the config.ts docblock for the two knobs it points at.
- */
 function rejectUnmatchableSettingsNames(perms) {
     for (const [field, names] of [["permissions.ask", perms.ask], ["permissions.deny", perms.deny]]) {
         if (!names)
@@ -458,39 +211,22 @@ export function deriveSettingsPolicy(settings, gate, workflowGate) {
         return {};
     const { allow, deny, ask, defaultMode } = perms;
     rejectUnmatchableSettingsNames(perms);
-    // The base name-keyed gate: allow/deny via core's helper + an ask-list (FINDING-1: `ask` must enforce, not drop).
-    // Each is composed deny-wins (`deny` > `ask` > `allow`), so the fold can only ever tighten.
     const policies = [];
     if (allow || deny)
         policies.push(createAllowDenyPolicy({ ...(allow ? { allow } : {}), ...(deny ? { deny } : {}) }));
     if (ask)
         policies.push(createAskListPolicy(ask));
-    // The mode-derived fs-write ask gate (core 1.290 factory — real shape read in dist: {env, rootPath?, acceptDirs?,
-    // exemptDirs?, defaultWrite}, gates Write/Edit/NotebookEdit, exempt→accept→default layering, canonicalize inside
-    // the given env, only ever allow/ask). undefined without wiring (see FsWriteGateWiring). #156/#165: the sandbox
-    // lanes supply wiring too — same factory, a deferred real-env proxy and no cwd; the shape difference lives
-    // entirely in what `resolve-spec.ts` puts in the wiring, not in a second code path here.
-    // (③ sensitive-path DENY 已随 #177 搬 governance 层——见 FsWriteGateWiring 尾注。deny-wins 由
-    //  tightenTaskSpec 折叠保证:豁免/acceptDirs/settings allow 仍然越不过部署 DENY 基线。)
     const fsWriteGate = (acceptCwd) => {
         if (!gate)
             return undefined;
-        // #156/#165: `cwd` is optional (absent on the sandbox lanes). Omitting `rootPath` makes core leave a relative
-        // target relative → the sandbox proxy's lexical `absolutePath` refuses it → ask; omitting `acceptDirs` means
-        // acceptEdits mints no auto-allow domain at all. Both are the intended fail-safe, NOT a degraded host arm.
         const gatePolicy = createFsWriteGatePolicy({
             env: gate.env,
             ...(gate.cwd !== undefined ? { rootPath: gate.cwd } : {}),
             ...(acceptCwd && gate.cwd !== undefined ? { acceptDirs: [gate.cwd] } : {}),
             ...(gate.scratchpadDir ? { exemptDirs: [gate.scratchpadDir] } : {}),
-            ...(gate.isExempt ? { isExempt: gate.isExempt } : {}), // 1.294 session-exemption probe (see FsWriteGateWiring)
+            ...(gate.isExempt ? { isExempt: gate.isExempt } : {}),
             defaultWrite: "ask",
         });
-        // NotebookEdit coverage is core-native since 1.296.1(我方 [886]① 请修 core 已兑现,1.207 的临时参数桥
-        // 就此撤除):DEFAULT_GUARDED_TOOLS 含 NotebookEdit,且两 policy 共用 `writeTargetPath` 提取器——canonical
-        // NotebookEdit 时 notebook_path 恒先(诱饵 file_path 失效),其余工具 file_path 先(反向诱饵也封);均 dist
-        // 亲读。回归锚保留在 test/task-settings.test.ts(NotebookEdit deny + 双向诱饵),现在锁的是 core 行为经
-        // 我方折叠——core 若回退,锚变红。
         return gatePolicy;
     };
     const compose = (...extra) => {
@@ -500,10 +236,6 @@ export function deriveSettingsPolicy(settings, gate, workflowGate) {
     const basePolicy = compose();
     switch (defaultMode) {
         case "plan":
-            // plan = read-only hands + the plan workflow: a TIGHTEN (handsReadOnly false→true), honored remotely.
-            // ALSO mount core's `present_plan` (enablePlanMode) so the model explores read-only then
-            // proposes a plan (CC EnterPlanMode→ExitPlanMode parity). Both are tighten/additive — no loosening.
-            // codex F1: run_workflow mounts OUTSIDE the hands band — deny it explicitly (see createWorkflowPlanDenyPolicy).
             return { toolPolicy: compose(createWorkflowPlanDenyPolicy()), handsReadOnly: true, enablePlanMode: true };
         case "acceptEdits": {
             const p = compose(fsWriteGate(true), createWorkflowAskPolicy(workflowGate?.isExempt));
@@ -511,10 +243,6 @@ export function deriveSettingsPolicy(settings, gate, workflowGate) {
         }
         case "default":
         case "auto": {
-            // (historical note kept: the pre-[816] impl fell through to base-only here — with no gate to attach,
-            // acceptEdits-as-loosen could not be honored. The [820] factory inverts the frame: default now ADDS an ask
-            // gate and acceptEdits ADDS a narrower one, both tighten-safe under the deny-wins fold.)
-            // ([1557]§四 的 shellGate 便车已随 #153 搬 governance 层——见 FsWriteGateWiring 尾注。)
             const p = compose(fsWriteGate(false), createWorkflowAskPolicy(workflowGate?.isExempt));
             return p ? { toolPolicy: p } : {};
         }
@@ -523,20 +251,6 @@ export function deriveSettingsPolicy(settings, gate, workflowGate) {
             return basePolicy ? { toolPolicy: basePolicy } : {};
     }
 }
-/**
- * Apply a client's parsed per-request settings onto a base `TaskSpec`, TIGHTEN-ONLY, in a SINGLE {@link
- * tightenTaskSpec} pass (so the permission override composes deny-wins onto the baseline — TRAP #1 — and
- * `handsReadOnly`/`onAsk` can only narrow). `tightenTaskSpec` THROWS `TaskSpecTightenError` if any override would
- * LOOSEN a stricter base — surfaced by the caller as a 4xx (a client settings stamp that tries to widen is a
- * client error, never a silent weakening). `model`/`outputStyle` are applied directly (model is the caller's
- * choice WITHIN the catalog — the caller gates it before calling; outputStyle appends to the system prompt).
- *
- * Returns `base` untouched when the parsed settings project nothing onto the spec.
- */
-// ([1557]§四 的 SHELL_GATE_RANK 副本与 shellGateSafe 守卫已随 #153 搬 runtime-governance ——
-// settings 折叠不再触碰 TaskSpec.shellGate,base 上 governance 层施加的值原样透传。design/201 的
-// {@link shellGateForMode} 也不改这句话:那只纯函数产的是 governance 的 base,由 resolve-spec 阶段④
-// 写进 spec 字面量;本折叠拿到的 `base` 里可能因此已经带着一档 shellGate,而它照旧原样透传。)
 export function applyTaskSettings(base, settings, gate, workflowGate) {
     const { toolPolicy, handsReadOnly, enablePlanMode } = deriveSettingsPolicy(settings, gate, workflowGate);
     let next = base;
@@ -546,14 +260,10 @@ export function applyTaskSettings(base, settings, gate, workflowGate) {
             overrides.toolPolicy = toolPolicy;
         if (handsReadOnly !== undefined)
             overrides.handsReadOnly = handsReadOnly;
-        next = tightenTaskSpec(next, overrides); // deny-wins compose + THROWS on loosen (fail-loud)
+        next = tightenTaskSpec(next, overrides);
     }
-    // R4: enablePlanMode (mount present_plan) is ADDITIVE — it widens NOTHING (a read-only plan workflow), so it rides
-    // directly (not through tightenTaskSpec, which guards safety fields). Only ever set true (plan), never cleared.
     if (enablePlanMode)
         next = { ...next, enablePlanMode: true };
-    // outputStyle → appended system prompt (additive UX directive; never a safety field). The caller already set any
-    // business systemPrompt; core's appendSystemPrompt rides after the scenario base.
     if (settings.outputStyle) {
         const appended = next.appendSystemPrompt ? `${next.appendSystemPrompt}\n\n${settings.outputStyle}` : settings.outputStyle;
         next = { ...next, appendSystemPrompt: appended };

package/dist/task-workflow.js

@@ -1,82 +1,26 @@
-/**
- * Workflow super-set unlock — map the per-task `body.selfOrchestration` intent onto
- * `TaskSpec.selfOrchestration`, the gate that mounts core's LLM-authored `run_workflow` engine (the workflow.ts
- * agent/parallel/pipeline orchestrator). Same shape as the rank-1 roster gap: the engine (core run_workflow +
- * workflow.ts) is BUILT, but nothing mapped a body field to the per-task spec flag, so it was unreachable over HTTP
- * (capabilities advertised `workflows:true` but the LLM could never call run_workflow).
- *
- * Gating:
- *  - DEPLOYMENT: `selfOrchestrationEnabled` must be on (the workflowScriptRunner + stores are wired). Otherwise a set
- *    flag is a harmless no-op (core fail-closes run_workflow without the sandbox runner), so it's dropped for clarity.
- *  - MULTI-TENANT: honored ONLY when a per-principal entitlement RESOLVER is wired (`hasEntitlementResolver`). 🔴 core's
- *    `allowWorkflows` (RuntimeCaps) is TIGHTEN-ONLY — a resolver can only DENY; `undefined` = NO restriction, so the
- *    deployment capability governs. Therefore WITHOUT a resolver the engine would mount run_workflow UNGATED for every
- *    tenant. So we fail-closed here (defense-in-depth: a misconfigured multi-tenant deployment with no entitlement
- *    source must NOT leak the LLM-authored workflow engine). WITH a resolver, core enforces `allowWorkflows`
- *    per-principal (deny → fail-closed). Single-user (owns its own worker) honors directly. Three-gate: engine-can ∧
- *    center-may(allowWorkflows) ∧ shell-show.
- */
 export function selfOrchestrationFromBody(body, config, hasEntitlementResolver) {
     if (body.selfOrchestration !== true || !config.selfOrchestrationEnabled)
         return undefined;
     if (config.requirePrincipal !== true)
-        return true; // single-user: honor directly
-    return hasEntitlementResolver ? true : undefined; // multi-tenant: fail-closed unless an entitlement resolver gates it
+        return true;
+    return hasEntitlementResolver ? true : undefined;
 }
-/**
- * §4 (Fork) — map the per-task `body.enableFork` intent onto `TaskSpec.enableFork`. core 1.257 (design/136 BREAKING)
- * RETIRED the standalone `Fork` tool; a fork is now `Agent(subagent_type:"fork")`, and `enableFork` is one of the two
- * governance axes (`forkGovernanceDenial(spec.enableFork, runtimeCaps.allowFork)`) that gate it.
- *
- * 🔴 CONSUME-CRITICAL — the default FLIPPED to opt-OUT: core now treats `enableFork === undefined` as **available**
- * (only an EXPLICIT `enableFork:false` / `allowFork:false` denies — CC's default posture). So where the SERVICE intends
- * to DENY, it must return `false` EXPLICITLY — the old "return undefined = not granted" is now fail-OPEN.
- *  - DEPLOYMENT posture OFF (`!forkEnabled`, e.g. multi-tenant default): `false` (explicit deny — preserve opt-in posture).
- *  - PER-TASK OPT-OUT (`body.enableFork === false`): `false` (any tenancy).
- *  - SINGLE-USER TURNKEY: `true` — DEFAULT ON for the LLM (clay 2026-07-01). (core still only lets it fork where the
- *    session store is fork-capable and never inside a fork / read-only band — graceful degrade, no capability lie.)
- *  - MULTI-TENANT: `true` ONLY with a per-principal entitlement RESOLVER wired (core then enforces `allowFork`
- *    tighten-only per-principal); WITHOUT a resolver `false` (fail-closed — `allowFork` is tighten-only so an absent
- *    resolver = `undefined` = ungated, and now `enableFork:undefined` also auto-grants, so the service must hard-deny).
- */
 export function enableForkFromBody(body, config, hasEntitlementResolver) {
     if (!config.forkEnabled)
-        return false; // posture must enable the primitive (FORK_ENABLED; posture-OFF multi-tenant) — explicit deny (opt-OUT default)
+        return false;
     if (body.enableFork === false)
-        return false; // explicit per-task opt-OUT (any tenancy)
+        return false;
     if (config.requirePrincipal !== true)
-        return true; // single-user turnkey: DEFAULT ON for the LLM
-    return hasEntitlementResolver; // multi-tenant: honor iff a resolver gates it, else fail-closed (core enforces allowFork per-principal, tighten-only)
+        return true;
+    return hasEntitlementResolver;
 }
-/**
- * The workflow-script MODEL allowlist (`agent({model})` picks). core is
- * fail-closed: NO allowlist configured ⇒ `WorkflowModelNotAllowedError` on ANY model pick, which on a TOC
- * single-user deployment broke clay's own dual-model scripts (决策 v4-pro + 执行 v4-flash) out of the box —
- * the operator configured every catalog entry themselves, so there is nothing to protect them from.
- *  - Explicit `SELF_ORCHESTRATION_MODELS` always wins (any tenancy — the operator's deliberate narrowing).
- *  - SINGLE-USER: default to the deployment's OWN model catalog (`Object.keys(models)`).
- *  - MULTI-TENANT: keep core's fail-closed empty default (a model pick is a cost/capability grant the
- *    operator must make explicitly; a tenant script must not self-select the expensive rung).
- * Returns undefined when no allowlist should be set (core then fail-closes picks; the script's `agent()`
- * without a model still runs on the workflow's default role — only PICKING is gated).
- */
 export function workflowModelAllowlistFor(config) {
     if (config.selfOrchestrationModels.length > 0)
         return config.selfOrchestrationModels;
     return config.requirePrincipal !== true ? Object.keys(config.models) : undefined;
 }
-/** design/122 caps for a caller-supplied `retainSubagentSessions` object (core defaults 30min/16; the ledger
- *  is run-scoped and fully released at parent end, so these only bound the WITHIN-RUN memory pin). */
-export const RETAIN_SUBAGENT_TTL_MS_CAP = 24 * 60 * 60 * 1000; // 24h — far above any sane interactive run
+export const RETAIN_SUBAGENT_TTL_MS_CAP = 24 * 60 * 60 * 1000;
 export const RETAIN_SUBAGENT_MAX_CAP = 64;
-/**
- * design/122 (core 1.225): normalize an untrusted `body.retainSubagentSessions` onto the TaskSpec field.
- * `true`/`false` pass through (core's own defaults apply); an object keeps only NUMERIC ttlMs/max, each
- * clamped to a positive integer under the cap (retention pins settled child sessions in memory for the
- * parent run's lifetime — the knob must not become a caller-controlled resource hold). Anything malformed →
- * undefined = OFF (core default). Defensive, never throws: RESUME re-runs resolveSpec WITHOUT the HTTP-layer
- * validation, so this normalizer is the single guard on every path.
- */
 export function normalizeRetainSubagentSessions(raw) {
     if (raw === true || raw === false)
         return raw;
@@ -87,20 +31,9 @@ export function normalizeRetainSubagentSessions(raw) {
     const ttlMs = clamp(o.ttlMs, RETAIN_SUBAGENT_TTL_MS_CAP);
     const max = clamp(o.max, RETAIN_SUBAGENT_MAX_CAP);
     if (ttlMs === undefined && max === undefined)
-        return undefined; // an empty/garbage object grants nothing
+        return undefined;
     return { ...(ttlMs !== undefined ? { ttlMs } : {}), ...(max !== undefined ? { max } : {}) };
 }
-/**
- * Per-task wall clock by TENANCY POSTURE (clay 2026-07-04, make-real 教训①:600s 默认墙钟砍掉了健康推进的
- * 长任务/chaos 恢复 run):
- *  - SINGLE-USER turnkey(`requirePrincipal !== true`)= the user IS the superadmin → **NO wall clock**
- *    (undefined; core arms none — its separate wedge safety-net still catches a stuck tool call, so "no wall"
- *    never means "hangs forever"). CC has no whole-task decapitation either.
- *  - MULTI-TENANT: base 2400s (big tasks — council/debate/discuss — 3600s). (PAIR-REVIEW F-4 附带修:此行
- *    曾写 600s/1500s 与代码漂移——真值以下方 base 为准。)
- *  - Explicit `TASK_TIMEOUT_SEC` wins in ANY tenancy (the operator's deliberate wall) and keeps its documented
- *    raise-only floor (`Math.max` with the base, so a misconfigured low value cannot shrink a council budget).
- */
 export function taskWallClockSec(envTimeoutSec, requirePrincipal, big) {
     const base = big ? 3600 : 2400;
     if (envTimeoutSec > 0)