## 7.42.1 — 2026-10-05 **Hard-breaking changes:** none. **Closed sets:** none added. **Package exports:** +1 / −0 — `steerPriorityOf`. **Behavior narrowing:** none (one reading replaces two; a replay that spelled the default is no longer refused). ### A steer's priority has one reading on the 7.42 line too: absent means `next` (#1361; fix; +1 export) (@server @cli @client-core) - **Before (v7.42.0).** 7.42.0 was cut before the 7.41.2 patch and did not carry it: the live acceptance check (`sameAcceptedSteerInput`) compared the normalized priority (`priority ?? "next"`) while the parked replay check (`samePendingSteerPayload`) compared the row's raw member — a row parked without a priority against a retry that spelled `"next"` read as a different instruction: `409 steering.duplicate_input_id`, after which a client re-issuing under a fresh id queued the same instruction twice (server S-1121). `latest` therefore lacked a fix `patch-7.41` had. - **Now.** The same change as 7.41.2: `steerPriorityOf(x)` (src/core/task-notification.ts, the priority word's home; exported) is the one reading — `x.priority ?? "next"` — used by both comparators and by the admission default; `omitted→next`, `next→omitted` and `omitted→omitted` are the idempotent replay (queue unchanged), `next→later` / `next→now` still refuse. Parked rows are written as before (the field stays optional); old rows read through the same default. - **Who is hurt.** Nobody: a refusal that was never correct goes away; a real priority change still refuses. - **Consumers.** Anyone pinned to `7.42.0`: move to `7.42.1` (a `~7.42.0` range picks it up). server — the 7.42 / 7.43 pickup carries the fix either way; client-core / cli — pin `≥7.42.1` when swapping the embedded engine. - Pins: `test/backlog1361-steer-priority-one-reading.test.ts` (A–F from the reproduction; base 7.42.0 red on omitted↔next and on the live check); `test/export-surface.snapshot.json` (+1 name). ## 7.42.0 — 2026-10-05 **Hard-breaking changes:** one — #1327 (both halves). **#1327 — What breaks:** a caller policy no longer takes an allow rule — `createPermissionRulePolicy` refuses one (`config.invalid_permission_rules`, issue `unsupported.allow`), `PermissionRule.behavior` is `"deny" | "ask"`, the policy's name projection (`nameSets`) has no `allow` group, and the three issue codes that existed only to refuse an allow in one shape or another (`unsupported.bash_prefix`, `unsupported.file_glob`, `invalid.allow_param_rule`) are retired; the allow layer's disclosure `persistedRuleShadowed` (a string, stored rows only) is gone from `PermissionResult`'s ask arm, `AskRequest` and the park closure's sixth seat, and `RiskDescriptor.shadowedRule` from the park row — replaced by `allowRuleShadowed: { member, entries, omitted? }[]` on all four; `SKILL_ENTRY_INERT_REASONS` / `SkillEntryInertReason` are renamed `ALLOW_ENTRY_INERT_REASONS` / `AllowEntryInertReason`; the notice `skills.allowed_tool_not_granted` is renamed `permission.allowed_tool_not_granted` (audience `operator` → `user`, each `detail.entries[]` gains `source`). **#1327 — Why:** "this does not need asking" had several readings — a stored allow row cleared an ordinary question, a skill's row cleared it without disclosing a refusal, a hook's own `allow` only answered the unstated question, and the account of a stored row that could not clear was appended to the message the auto classifier reads; a caller policy's allow rule was a further reading (a statement the fold read at the unstated station only; a content-, path- or param-form allow refused at construction under three different codes); now every allow source is one member of one layer, read under one predicate, with one disclosure that only the card renders, and an allow rule has that one home — a request's entries in `TaskSpec.allowedTools`, the deployment's in `RunnerDeps.allowedTools` — while a policy says deny / ask. **#1327 — What to do:** read `allowRuleShadowed` (one record per member: `hook` / `deployment` / `persisted` / `skill` / `request`) where you read `persistedRuleShadowed` / `riskDescriptor.shadowedRule`; re-import the inert-reason set under its new name; route the notice by its new code (and expect it at the user's session); move the allow entries you handed `createPermissionRulePolicy` to `TaskSpec.allowedTools` (content forms too; write-path and domain forms read as nothing and are announced) or, for the deployment's standing grants, to `RunnerDeps.allowedTools`, and keep deny / ask rules in the policy. **Behavior narrowing (#1311 car A1):** three — `combinePolicies` returns a rule's deny over a deny from an approval seat that was never asked; an inline `TaskSpec.images` entry the model API would not accept is refused before the first model call (`config.image_invalid`); the changed-file notice also honors the caller policy's, the rule store's, the org lane's and an inherited parent policy's deny. **Closed sets:** none on the package root; four engine-internal module vocabularies (`READ_OUTCOMES`, `SYNTHETIC_READ_LAYERS`, `SYNTHETIC_READ_UNANSWERABLE_CAUSES`, `ADMITTED_IMAGE_MIME_TYPES`) and one thrown code (`config.image_invalid`). **Package exports:** none. **#1363:** `PermissionRuleIssue.code` +1 (`invalid.behavior`). **Closed sets:** `DecisionReason` +2 (`deployment_rule`, `request_rule`); `EngineNoticeCode` −1 +1 (`skills.allowed_tool_not_granted` → `permission.allowed_tool_not_granted`); new `ALLOW_RULE_MEMBERS` (5 words); `PermissionRuleIssue.code` −3 +2 (retired `unsupported.bash_prefix`, `unsupported.file_glob`, `invalid.allow_param_rule`; added `invalid.entry_type`, `unsupported.allow`); `PermissionRule.behavior` −1 (`allow`); trace kind +1 (`permission.allowed_tools_allowed`). **Package exports:** +11 / −2 — added `ALLOW_RULE_MEMBERS`, `ALLOW_ENTRY_INERT_REASONS`, `compileAllowEntry`, `compileAllowList` (#1356), types `AllowRuleMember`, `AllowRuleShadow`, `AllowEntryInertReason`, `CompiledAllowEntry`, `AllowEntryGateSeats`, `AllowEntryLane`, `AllowEntryHit`; removed `SKILL_ENTRY_INERT_REASONS`, `SkillEntryInertReason` (renamed). ### "This does not need asking" has one home: the allow layer (#1327; behavior + hard-breaking surface) (@server @cli @client-core @test) - **Before (v7.41.x).** Five readings of one fact. A person's stored allow row cleared an `ordinary` / `unstated` question (and, matched on a question it could not clear, appended its account to the ask's `message` — the text the auto classifier reads). A skill's `allowed-tools` row cleared the same questions but disclosed nothing when it could not. A PreToolUse hook's explicit `allow` only stopped the `unstated` question from being minted (a Write / Bash question in `default` still reached the person). There was no request-level or deployment-level allow list. In `auto` a skill's whole `Bash` and its interpreter-headed prefixes (sema's own interpreter table) stood down to the classifier, while a stored `Bash(npm run:*)` cleared without asking it. A caller policy's allow rule (`createPermissionRulePolicy([{ rule, behavior: "allow" }])`) was the fifth: a bare or covering name returned an allow that stated the tool — read at the unstated station only, so it never cleared a Write's or a shell command's question — while a content-, path- or param-form allow was refused at construction under three different codes (`unsupported.bash_prefix`, `unsupported.file_glob`, `invalid.allow_param_rule`). - **Now.** One layer, five members, one loop, one predicate, behind every tighten and ahead of the classifier — in this order: **a hook's explicit `allow`** (silent when a policy rewrote the arguments after the hook saw them), **the deployment's `RunnerDeps.allowedTools`**, **a person's stored allow rows**, **an active skill's `allowed-tools`**, **the request's `TaskSpec.allowedTools`**. A member that matches clears the ask only when an allow rule may clear it (the classes `unstated` and `ordinary`; never a deny, an ask rule, an org rule, governance, a hook's ask, a marked call, the plan mode's question, a mandated question). A member that matches and cannot clear is **disclosed**: `allowRuleShadowed` on the surviving ask (engine-stamped — a policy's own value is overwritten), rendered into the approval card's `message` at the card (`… (this run's allowedTools (Write) matches this call but does not clear the ask — )`), carried on the park row's `riskDescriptor.allowRuleShadowed` — and never on the decision the classifier reads. - **`TaskSpec.allowedTools`** — the reference implementation's `allowedTools`: the grammar a skill's list reads (tool names, `mcp__` / `__*` / globs, `Bash(...)` command rules, `Read(//dir/**)`; `*` voids the list, `mcp__*` / write paths / domains grant nothing and are announced). Lives for the run (steers included); a delegated child holds the entries until it ends; a resumed leg holds them only when its spec supplies them again (not checkpointed). A value that is not a list of strings refuses the run before it starts (`config.invalid_permission_rules`, `issues[].code: "invalid.entry_type"`). A call it clears: `decisionReason: "request_rule"`, trace `permission.allowed_tools_allowed` `{ source: "request", entries }`. - **`RunnerDeps.allowedTools`** — the same grammar for the deployment's standing yeses (`decisionReason: "deployment_rule"`, trace `source: "deployment"`), screened once at construction (a bad value refuses construction), its inert entries announced once there (no session id). - **A caller policy says deny / ask only.** `createPermissionRulePolicy` refuses an allow rule of any spelling at construction: `config.invalid_permission_rules`, one `unsupported.allow` issue per rule, its sentence naming the two homes (`TaskSpec.allowedTools`, `RunnerDeps.allowedTools`); under `onInvalidRule: "skip"` it is reported through `onIssue` and dropped, and the rules after it still compile. `PermissionRule.behavior` is `"deny" | "ask"`; the policy's `check()` has no allow tier and its `nameSets` no `allow` group. A call no rule reaches still gets `defaultAction` (`"allow"` is no objection — it states nothing and clears nothing). Deny / ask rules and their order are unchanged. - **A hook's `allow` clears the question** the default mode raises for a Write or a shell command, and in `auto` the classifier's question (the reference's default); under `dontAsk` the call therefore runs instead of being refused by the mode (the mode refuses only an ask that survives the allow layer, as the reference's dontAsk does); it never clears the plan mode's question (stricter than the reference — divergence `hook-explicit-allow-does-not-clear-plan-question`), and it is not stripped in `auto`. - **`auto` strips one entry shape, whichever list holds it** (the reference's table: the whole shell tool; a shell rule whose content is empty or `*`; `X`, `X:*`, `X *`, `X*`, `X -…*` for `python* node deno tsx ruby perl php lua npx bunx npm/yarn/pnpm/bun run bash sh ssh zsh fish eval exec env xargs sudo`, python's `-m dotted.module` excepted). A stored `Bash(npm run:*)` now hands its calls to the classifier in `auto`; a skill's `Bash(sed:*)` (sed is not in the reference's table) now grants in `auto`. Stored rows are stripped before the coverage is chosen, so `Bash(npm run build)` behind `Bash(npm run:*)` still admits `npm run build`. A whole-tool entry naming the shell under an alias, and a compound prefix by its final segment, are stripped too (sema-only shapes). - **One predicate, read whole.** A member clears only when both readings agree: the mandate reading (bits, doors, an ask rule) and the class table's own `ruleMayClear` column over every class the ask carries. So an ask a policy declares as a guard (`guard`), an unreadable rule (`ruleUnreadable`) or the classifier's fallback (`denialLimitFallback`) WITHOUT the real-approval bit is no longer cleared by any member — a stored row or a skill's row cleared it in 7.41.x. - **K-5:** a rule-shaped clear (a list entry, a stored row) and the read-only reader end the auto classifier's denial streak (the reference resets there); a hook's allow does not. - **An entry is read exactly as written**, in every list (a skill's two lists too): one with surrounding whitespace (`"Write "`), or whose tool-name part is empty or carries whitespace or an unbalanced parenthesis (`"Bash("`, `"Bash)"`, `""`), names no tool — it grants (or refuses) nothing and is announced with `reason: "grammar"`. 7.41.x read `"Write "` as `Write` (the rule parser trimmed it) and compiled `"Bash("` as a tool name nothing carries, silently. The reference reads a rule string without trimming it (2.1.280). The directory loader already trims the separators of a frontmatter list, so a skill file is unaffected; a host-built list with padded entries is. - **The approved-edit round** no longer takes a hook's `allow` as a statement: bytes a hook rewrote after the person approved go to that round's question (a narrowing; rare). - **Who is hurt.** A host that hands `createPermissionRulePolicy` an allow rule — the serving layer that encodes `settings.permissions.allow` as policy allow rules, a test helper that grants a server that way: construction now throws (under `"skip"` the rule is dropped and reported); a probe that pinned `unsupported.bash_prefix` / `unsupported.file_glob` / `invalid.allow_param_rule`, a rule policy's `nameSets[].allow`, or the `decisionReason: "rule"` a rule policy's allow stamped; a host that reads `persistedRuleShadowed` / `riskDescriptor.shadowedRule`, imports `SKILL_ENTRY_INERT_REASONS`, or routes `skills.allowed_tool_not_granted` (renamed — see the header); a deployment whose PreToolUse hook answers `allow` to calls it did not mean to approve (a Write / shell question in `default` and the classifier's question in `auto` are now cleared — it never was a no-op for MCP tools); a deployment that relied on a stored `Bash(npm run:*)` / `Bash(npx:*)` row clearing without the classifier in `auto`; a probe that pinned the stored row's account inside the ask's `message`; a policy that put its own `persistedRuleShadowed` on an ask (overwritten); a policy that declared a guard / an unreadable rule / a fallback without `requiresRealApproval` and relied on a stored or skill row to clear it; a host that builds an allow or deny list (`TaskSpec.allowedTools`, `RunnerDeps.allowedTools`, `SkillSpec.allowedTools` / `disallowedTools`) with padded entries — they read as nothing now (a padded deny entry no longer refuses; announced); a 7.41.x park row read by this release keeps its old `shadowedRule` key unread; A host that reads `persistedRuleShadowed` / `riskDescriptor.shadowedRule`, imports `SKILL_ENTRY_INERT_REASONS`, or routes `skills.allowed_tool_not_granted` (renamed — see the header); a probe or test that wrote a hook's `allow` on the model's own bytes as a mere statement and expected a policy's plain ask to still reach the person afterwards (an edit round, a park) — that ask is now cleared in the first round and the hook-judged bytes run (give the hook no `action` on those bytes, or mark the ask `authoredBy: "deployment"`) - **Compensation.** The grant a policy's allow carried moves as it was spelled: `allowedTools: ["mcp____*"]` on the request (it also clears the default mode's ordinary questions, which a policy's allow never did); a deployment's standing grant goes in `RunnerDeps.allowedTools`. A question that must reach a person whatever a hook or a list says: `authoredBy: "deployment"` or `requiresRealApproval` on the ask (both refuse every allow member). A hook that only observes: answer no `action`. The card's account: read `allowRuleShadowed` or the card's `message`. `auto`: name the narrow command (`Bash(npm run build)`) instead of the launcher prefix. - **Consumers.** server — send `settings.permissions.allow` whole into `TaskSpec.allowedTools` (content forms included — the 422 on a content-form allow and its premise go; deny / ask keep compiling into `createPermissionRulePolicy`) and the `APPROVAL_GRANT` knob into `RunnerDeps.allowedTools`; render `allowRuleShadowed`; route the renamed notice; never import sema's own settings file into the stored-rule store (it would be a second home); read an entry the engine's way at the submission door with `compileAllowEntry(entry, "allow" | "deny")` / `compileAllowList(entries, behavior)` (#1356: a reading, or an `ALLOW_ENTRY_INERT_REASONS` word) — refuse a deny-side entry that reads as nothing (400), keep the notice for an allow-side one (a deny list's `*` reads as nothing by itself and the rest of the list still refuses, the #1303 deny-side rule). cli — may hand the whole allow list over (the engine covers built-in names and content forms; write-path forms still read as nothing until KL-1303-b closes). client-core — `DecisionReason` +2, `PermissionRule.behavior` −1 (`allow`), `PermissionRuleIssue.code` −3 +2, the notice code rename, `ALLOW_ENTRY_INERT_REASONS` / `ALLOW_RULE_MEMBERS` mirrors from the package root. test — G4 family (see the 7.42.0 criteria). - **Not folded into this layer (ticketed).** The name-list policies' own allow lists — `createAllowDenyPolicy({ allow })`, `createApprovalPolicy`'s `autoAllow`, `createCoarseCommandNamePolicy`'s allow list — still state the calls they name (a hit on a server's tool clears the `unstated` question), and the write gate's session exemption (`isExempt`) still answers for a previously approved path: two more homes until #1359 and #1360 move them. A rule policy is the one factory that no longer states. - **Known limits.** KL-1327-a (an entry names a tool through its aliases — the reference's list does not expand aliases) · b (no host flag to put every hook-allowed call through the approver anyway) · c (no switch that strips every shell entry in `auto`) · d (a tool's own `"maybe"` tier that the probe proved reversible keeps its `unstated` question through a hook's allow). - Pins: `test/backlog1327b-policy-allow-retired.test.ts` (⑧–⑧e: an allow rule refused with one code naming both homes, the grant on its new home, deny / ask unchanged, no `allow` group in the projection, the three retired codes gone; real Runner + compile-time cells), `test/backlog1327-allow-one-home.test.ts` (real Runner, ①–⑳ + D1/D2 + H1/H2), `test/backlog1327-allow-entry-unit.test.ts` (the strip table, the screen, the parity table, the renderer); re-pinned: the stored-row disclosure suites (144 / 213 / 239 / 353 / 502 / 619 / 804 / 817 / 850 / 997 / design252 / 276 / 375 / permission-rule-gate / -wiring / risk-descriptor*), 1303 K2a (the interpreter arm is `node`; `sed` grants in auto), rb442 N7; the tests that handed a policy an allow rule now state it on `allowedTools` (permission-rules, 1065, 1111, 1303d, mcp-capability-and-rule-coverage, the MCP fixture's `grantMcpServers`) or as the deny / ask they meant (hardening-permission-core, 625 / 654 / 657). ### The read layer under the attachment seat: one read, structured notes, deferred effects (#1311 car A1; refactor, Read bytes unchanged) - **Before (v7.41.x).** The Read tool's whole read lived in one `execute` closure that wrote read state and advanced the reminder-disclosure throttle while it read, and spoke its notes (empty file, offset past the end, already in context, unchanged, the range header, the partial marker, the disclosure trailer) as finished strings — the already-in-context reminder spliced the canonical path into a marked ``. Nothing else could read a file "the way Read does" without also committing Read's side effects and inheriting its wording. - **Now.** `readForModel` (src/tools/fs/fs-read.ts) answers a value — the external data blocks in order, the engine's notes as structured members, the read-state observation, the disclosure effects, an outcome word (`attached` / `partial` / `unchanged` / `not_attached`) — and changes nothing; `commit` applies the read state and the effects when a carrier delivers; the Read tool is read → commit → its own renderer, and its result is byte for byte what it was (the Read, notebook, image, PDF, dedup and disclosure pins are unchanged). The disclosure pipeline itself is plan / commit / render (`discloseReminderShaped` keeps its one-call form for MCP and web). The image lane's byte checks are one function (`admitImageBytes`), the walk's per-entry read-deny judge is one function (`createEntryDenyJudge`), and a directory can be listed one level for the model (`enumerateDirectory`: files, directories and unfollowed links, denied entries withheld and counted exactly, 1000 entries then "… and N more entries", an abort-cut listing marked incomplete). - **Who is hurt.** Nobody: no package export moves and no tool result changes. Internal: `pdfResultToToolReturn` retires (the reader's refusal carries the error envelope). - Pins: `test/backlog1311a-read-layer.test.ts` ①②③⑤ and M6; every existing Read / Glob / Grep / image pin. ### An inline `TaskSpec.images` entry passes the same admission as an image the Read tool serves (#1311 car A1; behavior narrowing) (@server @client-core) - **Before (v7.41.x).** An inline image (`{ data, mimeType }`) went to the provider as given — no check that `mimeType` is one the API accepts, that `data` decodes to that type, or that it fits the 5 MB base64 limit; a mis-declared or over-size image failed the whole first request at the provider. - **Now.** At the step where a refused image URL already fails (after the UserPromptSubmit hook, before the first model call and before the objective's `human_input` is published) the inline arm decodes `data` and runs the Read image lane's admission without downsampling: the type is one of `image/png`, `image/jpeg`, `image/gif`, `image/webp`; the decoded bytes are within 5 MiB and carry that type's signature; the base64 is within 5 242 880 chars. A failure ends the run `failed` with `TaskResult.terminal.code` `config.image_invalid` and a message starting `TaskSpec.images: `; nothing is sent. A valid image is sent unchanged (re-encoded from the bytes that were checked, which for canonical base64 is the same string). - **Who is hurt.** A caller that sent `image/jpg`, an upper-case type, a type the API does not take, base64 with stray characters that happened to decode, or an image whose base64 is over 5 MB — each used to fail at the provider (or, on a lenient provider, reach the model) and now fails at the door. - **Compensation.** Send the API's own type word and the file's exact bytes; shrink an image over 5 MB before sending. The URL arm is unchanged (it already identifies the type by signature). - **Not checked, stated.** Like the Read image lane, the door checks the type's SIGNATURE, not that the image decodes: a file cut short after its first bytes still passes and can still fail at the provider (KL-1311a-c). - **Consumers.** server — a request whose inline image fails now gets the typed failure instead of a provider error; client-core — `config.image_invalid` joins the codes it maps. - Pins: `test/backlog1311a-read-layer.test.ts` ⑥. ### One synthetic-Read deny judge; the changed-file notice reads it (#1311 car A1; behavior narrowing of an advisory notice) (@server @test) - **Before (v7.41.x).** The changed-file notice asked two layers whether the model could re-read a file (the run's skill deny rows and the session / ancestor / frozen narrowing fold) and ignored the deployment's caller policy, the person's rule store, the org lane and a live inherited parent policy — a file the deployment denied to `Read` still got "modified externally, re-read before editing". - **Now.** `createSyntheticReadJudge` is the run's one answer to "would a `Read` of this file be refused outright?" over every layer that can refuse it, in three states — `deny`, `no_objection`, `unanswerable` with a cause word (`threw`, `timed_out`, `approval_seat`, `call_unreadable`, `org_unavailable`) — and the consumer picks where `unanswerable` goes. The rule store and org lane are read through the live gate's own readers (a store that cannot be read takes no part, as in the gate; an org lane that cannot be read is `unanswerable`). A deployment policy is asked with an already-aborted signal and no approver: a deny an approval seat attested reads as `approval_seat`, never as the policy's refusal. The changed-file notice reads `deny` as "do not report" and everything else as "report" (unchanged direction); prepare hands the same judge out (`syntheticReadVerdict`) for the attachment frame. Every probe carries the call id `-visibility-probe` (`changed-files-visibility-probe` here). - **The abort contract, now kept by every engine policy factory.** `createPreToolUseConstraintPolicy` (the inherited PreToolUse screening) handed an already-aborted signal no longer invokes the hook: it answers a deny carrying the engine settlement `task_aborted`, as `createApprovalPolicy` already did. INTEGRATION-CORE §4.6j states the contract for deployment policies. - **Who is hurt.** A deployment that relied on the notice for a path its own policy denies to `Read` (the notice was not actionable — the model could not re-read it); a deployment policy that logs every `check` sees probe calls with the synthetic id; a deployment wrapper that answers an aborted signal with its own deny makes the notice silent for that file. - **Compensation.** None needed for the notice; a policy that wants to tell probes apart reads the `-visibility-probe` id. - **The wait is bounded once.** One judgment waits at most one dependency timeout (15 s) in all — each layer gets what is left, a layer reached after it is not asked (`timed_out`); the changed-file notice judges its candidates together under one shared deadline, so a hung deployment policy costs a turn boundary one 15 s bound, not one per file per layer. - **Known limits.** KL-1311a-a (a deployment closure that reaches an approver before reading its signal can still be asked by a probe) · KL-1311a-b (a wrapper's own deny on an aborted signal reads as a refusal). - Pins: `test/backlog1311a-read-layer.test.ts` ④ and ④b (one row per engine policy factory: no seat reached under an aborted signal). ### `combinePolicies`: a deny from a seat that was never asked yields to a rule's deny (#1311 car A1; behavior, narrow) (@server @client-core) - **Before (v7.41.x).** The fold returned the FIRST deny it met. Under an interrupted run (or a visibility probe), an approval policy composed ahead of a rule deny answered its own deny (`approval aborted for "" (run or turn interrupted)`, settlement `task_aborted`) and the fold stopped there: the rule behind it was never asked, so the answer to "does any layer refuse this?" depended on the composition order. - **Now.** A deny attested `task_aborted` is held and the scan goes on; a later deny that does not carry that attestation is returned instead (the rewrite carry and the attestation transfer are unchanged); when no later layer refuses on its own, the held deny is returned — the same object, message and record as before. One rule, in the fold only; it keys on the attestation, so an interrupted live call and a probe take the same path. - **Who is hurt.** A consumer of the gate's record for a call cut by an interruption whose composed policy ALSO denies the call by rule: `tool_end.gate` now reads `{ disposition: { kind: "denied", deniedBy: "policy" } }` with the rule's message, where it read `deniedBy: "ask_resolution"` with the `task_aborted` settlement. Layers after the held deny are now consulted during that interruption (with the aborted signal — an engine factory reaches no seat; a deployment closure is called). - **Compensation.** None needed: the call is refused either way; read `deniedBy` / `settlement` per call as before. - Pins: `test/backlog1311a-read-layer.test.ts` ④ (composition order, both orders deny) and ④d (live gate during cancellation: the rule's deny; positive control — no rule deny, the seat's deny unchanged). ### A permission rule's `behavior` is a closed set at the compiler (#1363; behavior narrowing: a misspelled verb is refused instead of compiling to a dead rule) (@server @client-core) - **Before (v7.41.x).** `createPermissionRulePolicy([{ rule: "Write", behavior: "permit" }])` — or `"ALLOW"`, `" allow"`, an undefined `behavior`, a boxed `String("allow")` — compiled with no issue and matched nothing: a misspelled `deny` dropped that deny silently (fail-open). Only the literal `"allow"` was refused (`unsupported.allow`, car B of #1327). - **Now.** The compiler judges `behavior` against the closed set `deny | ask` first: the literal `"allow"` keeps `unsupported.allow` (the allow layer's sentence); every other value raises `config.invalid_permission_rules` with the new issue code **`invalid.behavior`** (the sentence names the two words and the value it got). Under `onInvalidRule: "skip"` the rule is dropped and reported; the rules after it still compile. - **Who is hurt.** A JS caller whose rule list carried a misspelled or missing verb: construction now throws where it used to build an inert rule. **Closed set:** `PermissionRuleIssue.code` +1 (`invalid.behavior`) — with car B's −3 +1 the release's net on that set is −3 +2. - **Compensation.** Spell the verb `deny` or `ask`; an allow entry goes to `TaskSpec.allowedTools` / `RunnerDeps.allowedTools`. - Pins: `test/backlog1363-rule-behavior-closed.test.ts` (five bad shapes × throw / skip; the literal `allow` and valid `deny` / `ask` as controls; the sentence names both words). ## 7.41.2 — 2026-10-05 **Hard-breaking changes:** none. **Closed sets:** none added. **Package exports:** +1 / −0 — `steerPriorityOf`. **Behavior narrowing:** none (one reading replaces two; a replay that spelled the default is no longer refused). ### A steer's priority has one reading: absent means `next` (#1361; fix; +1 export) (@server @client-core) - **Before (v7.41.1).** The live acceptance check (`sameAcceptedSteerInput`) compared the admission's normalized priority (`priority ?? "next"`), while the parked replay check (`samePendingSteerPayload`) compared the row's raw member — a row parked without a priority (every row a ≤7.115.0 server parked, or a client that omits the field) against a retry that spelled `"next"` read as a different instruction: `409 steering.duplicate_input_id`, after which a client re-issuing under a fresh id queued the same instruction twice (server S-1121, reproduced on 7.41.1 with `appendPendingSteer`). - **Now.** `steerPriorityOf(x)` (src/core/task-notification.ts, the priority word's home; exported) is the one reading — `x.priority ?? "next"` — used by both comparators and by the admission default; `omitted→next`, `next→omitted` and `omitted→omitted` are the idempotent replay (queue unchanged), `next→later` / `next→now` still refuse. Parked rows are written as before (the field stays optional); old rows read through the same default. - **Who is hurt.** Nobody: a refusal that was never correct goes away; a real priority change still refuses. - **Consumers.** server — S-1121: pin `7.41.2`, flip the probe cell, delete the MIGRATION / contract sentence about this boundary; client-core — none (one export added). - Pins: `test/backlog1361-steer-priority-one-reading.test.ts` (A–F from the reproduction; base 7.41.1 red on omitted↔next and on the live check); `test/export-surface.snapshot.json` (+1 name). ## 7.41.1 — 2026-10-05 **Hard-breaking changes:** none. **Closed sets:** none added (two existing sets become reachable from the package root). **Package exports:** +5 / −0 — `SKILL_GRANT_ORIGINS`, `SKILL_ENTRY_INERT_REASONS`, types `SkillGrantOrigin`, `SkillEntryInertReason` (all defined in 7.41.0, re-exported now), and `mintNamespacePrefix` (#1355, defined since the namespace minting landed, re-exported now). ### The two skill-grant vocabularies are on the package root (#1347; surface only; +4 exports) (@client-core @server) - **Before (v7.41.0).** `SKILL_GRANT_ORIGINS` (`model` / `user` / `inherited`) and `SKILL_ENTRY_INERT_REASONS` (`wildcard_all` / `namespace_wildcard` / `path_pattern` / `domain` / `content_unsupported` / `grammar`) and their two types were declared in `dist/core/skill-grant.d.ts` and not re-exported from `index.d.ts`; the 7.41.0 ship post called them consumable closed sets because the wire manifest scans every `dist/` file, not the package root. - **Now.** Both constants and both types are re-exported from the package root beside `RULE_TOOL_NAME_VERDICTS`; the consumer smoke probe asserts their presence. - **Who is hurt.** Nobody: additive. - **Consumers.** client-core — generate the two mirrors from the package root (CC-338). server — none. - Pins: `test/export-surface.snapshot.json` (+4 names); `scripts/consumer-smoke-probe.mjs` (two new object entries, run by `gate:blackbox`). ### The peer-segment minter is on the package root (#1355 part one; surface only; +1 export) (@server) - **Before (v7.41.0).** A covering-form rule such as `mcp__github.com` (two segments, accepted since #1156) or `mcp__github.com__*` was compiled and stored as written, while the engine mints the peer segment normalized (character set, length clamp with a digest suffix, separator fold: `mcp__github_com__`). The rule's segment and the minted segment are compared byte for byte, so such a rule never matches — a deny that reads protective and is inert. Nothing on the package root let a rule writer ask "is this segment one the engine mints?". - **Now.** `mintNamespacePrefix(ns, peer)` (src/core/protocol-naming.ts) is re-exported from the package root beside `PROTOCOL_TABLE` / `MCP_NAMESPACE` / `A2A_NAMESPACE`: a rule writer mints the prefix for the rule's peer and compares it with the rule's own spelling. Part two (7.42.0): `judgeRuleToolName` gains the verdict `unmintable_segment` with the minted spelling as `currentName`, and both rule compilers refuse through that one judge. - **Who is hurt.** Nobody: additive. - **Consumers.** server — S-1113: judge `permissions.deny` / `APPROVAL_DENY` covering-form rules at the door until the 7.42.0 verdict lands. - Pins: `test/export-surface.snapshot.json` (+1 name); `scripts/consumer-smoke-probe.mjs` (one new function entry, run by `gate:blackbox`). ## 7.41.0 — 2026-10-04 **Hard-breaking changes:** one — #1303. **#1303 — Before:** a skill that declared `allowed-tools` (or a host's `SkillSpec.manifest.allowTools`) narrowed the whole task once activated: every unlisted tool was refused (`allowPaths` fenced writes to directories), the listed ones still asked where they always asked, and activating it asked nobody. **#1303 — Who is hurt:** a deployment that relied on a skill's list to fence the model — an unlisted tool is now judged as usual (asked under an asking mode, run under `bypassPermissions` or a deployment allow) and a listed one runs without asking for the rest of the run; a host that hand-built `SkillSpec.manifest` (now refused by name: `config.spec_retired_key`) or wrote `allowPaths` (the write fence is gone), imported the deleted `SkillManifest` type or `skillScopeWriteToolNames`, passed the retired `deployedTools` option to `createSkillsFromDirectory` (refused: `config.deps_retired_key`) or matched on one of its three removed warning codes, or built an auto-promote record with `manifest` / `gate3Scoped` / `lineageId` or passed a manifest to `deriveTripwire`; an embedder with no approver under an asking mode (activating a skill that declares a list is now a card nobody answers — refused); a deployment policy that returns an unmarked `ask` (class `ordinary`) for a listed tool (the list clears it, as a stored allow rule would); a delegation tool that read `ctx.activeSkillScope()` (renamed `ctx.activeSkillGrants()`). **#1303 — Compensation:** fence tools with deny rules (a deployment deny list, a person's deny row) or a delegated agent definition's `allowTools`; fence write paths with session `allowDirs` / the write face (`createSessionRulePolicy`, the fs-write gate); mark a policy's question `mandated` / `requiresRealApproval` (or write an ask rule) when it must reach a person; with no approver, name `Skill` in an allow list or run `bypassPermissions`; move `manifest.allowTools` to `SkillSpec.allowedTools`; drop `deployedTools` (the loader copies every entry and the run's grant table reads it); give `deriveTripwire` the artifact's `{ allowedTools }` and drop `manifest` / `gate3Scoped` / `lineageId` from the promoted record. Everything else in this version adds, tightens or re-words: #1118 adds optional members and text lines; #1294 changes which hook seats fire for a call approved on a parked checkpoint (a PreToolUse seat now sees that call again on the resumed leg); #1307 / #1308 re-word request-time refusals of the file stores (no on-disk location in the sentence; the location rides the store's disclosure seat); #1309 turns a session's enumeration over its own damaged row from a short list into a refusal; #1310 and #1314 change model-facing text only; #1156 refuses a retired or prefix-less `__` tool name at the session-rules write (it used to fail every later run instead); #1328 refuses a resumed `Skill` call whose final arguments select another skill than the card named. **Closed sets:** `DecisionReason` +1 `skill`; `ASK_CLASSES` / `AskClass` +1 `requires_user_interaction` (`MODE_ARBITRATION` +1 row; `RELEASABLE_ASK_CLASSES` and `PERSISTED_RULE_MANDATES` unchanged); `ENGINE_NOTICE_CODES` +1 `skills.allowed_tool_not_granted` (audience `operator`, minter `engine`); trace kinds +1 `permission.skill_allowed`; config refusal codes +1 `config.user_invoked_skill_unknown`; `CheckpointErrorReason` +1 `skill_grants_damaged` and `CheckpointError.detail.field` +1 `boundGrantDigest` (both on the existing `checkpoint.invalid_outcome`); `SessionPolicyError.code` +1 `legacy_tool_name` (with `detail: { field, name, verdict, currentName? }`); new closed set `RULE_TOOL_NAME_VERDICTS` (`current` / `retired` / `unprefixed_namespace`). **Package exports:** +22 / −2 (the entry's count 2558 → 2578). Added — #1118: `readAgentState`, `agentStateSourceOfRecord`, `agentStateSummary`, types `AgentState`, `AgentApproval`, `AgentApprovalState`, `AgentStateRow`, `AgentStateSource`, `TranscriptStep`; #1303: types `SkillGrantRecord`, `SkillGrantHit`, `SkillGrantLane`, `SkillGateSeats`, `PermissionSeatInputs`, `PermissionSeatReading`; #1308: type `FileUsageWindowStoreOptions`; #1156: `judgeRuleToolName`, `RULE_TOOL_NAME_VERDICTS`, `assertSessionRuleNamesCurrent`, types `RuleToolNameVerdict`, `SessionPolicyStoreOptions`, `SessionRuleNameRefusal`. Removed — #1303: `SkillManifest`, `skillScopeWriteToolNames`. Members — new and optional: `TaskSpec.userInvokedSkills`, `SkillSpec.allowedTools` / `disallowedTools`, `CheckpointState.skillGrants`, the `tool_approval` pending action's `boundGrantDigest`, `ToolGateInput.requiresUserInteraction`, `UnifiedTaskOutput.agentState`, `AgentPollDetailsInput.agentState`, `ListAgentsRow.agentState`, `serveDurableAgentRowLane(row, agentState?)`, `checkpointSeat` on `AgentTranscriptToolOptions` / `ListAgentsToolOptions` / `TaskToolOptions` / `TaskPollOptions`, `TaskRegistry.agentStateSource` (new method), `FileUsageWindowStore`'s constructor options and `createFileTaskListStore`'s `onCorruptRead`, `mountedToolNames` on both session-rules stores (`FileStorageBackendOptions.sessionPolicy` forwards it), `loosenReasons`' third parameter; `AgentTranscriptToolOptions.registry` widens to `Pick & Partial>` (a full `TaskRegistry` still fits). Removed (the hard-breaking change above): `SkillSpec.manifest` (a host still passing it is refused by name), `SkillsDirectoryOptions.deployedTools` (refused by name), three `SkillsDirectoryWarningCode` words (`allowed_tool_pattern_unsupported`, `allowed_tool_not_mounted`, `disallowed_tools_unenforced`), `PromotedRecord.manifest` / `gate3Scoped` / `lineageId`; `deriveTripwire`'s second parameter is `Pick` (was `SkillManifest`). ### A skill's `allowed-tools` is a rule source for the run, not a fence (#1303; behavior (hard-breaking: the narrowing retires); closed sets +6 words) (@server @cli @client-core @test) - **Before (v7.40.1).** A skill's list narrowed the task: activating a skill with `allowed-tools` pushed a frame that refused every unlisted tool for the rest of the task (nested skills intersected; `allowPaths` fenced writes; an unreadable inherited frame refused everything), the listed tools still asked wherever they asked (an MCP tool on the list still raised its `unstated` card), and activation itself asked nobody. A slash-invoked skill had no seat at all. - **Now (the reference implementation's shape, 2.1.280).** The list is an allow-rule source and `disallowed-tools` a deny-rule source for the run the skill is activated in: - **The Skill card.** Activating a skill that declares either list asks once — `toolName: "Skill"`, class `unstated`, message `Execute skill: ` plus, where approving releases anything in the current mode, `Approving also lets these tools be used without asking for the rest of this run: ` (sanitized, ten entries at most; the auto classifier reads it). Read on the call's final arguments. A skill with no list, or empty lists, asks nothing. `Skill` now runs alone in its batch, so a call after it in the same message sees the rows. - **Listed tools run without asking — only where an allow rule could.** The rows are the allow layer's member beside a person's stored allow rows, under the same predicate: they clear `unstated` and `ordinary` asks only. Deny / ask rules, organization rules, the plan mode's question, `shellGate: "always"`, a server's destructive marks, write protection, the read boundary, a hook's ask and every mandated question still stand. Entry grammar = the persisted rule grammar: tool names, `mcp__` / `mcp____*` / glob, `Bash(...)` command rules (a compound only when every other segment is read-only by itself, as for a stored allow rule), `Read(//dir/**)`; the whole `Bash` and an interpreter prefix grant outside `auto` and stand down in `auto`. `*`, `mcp__*`, write paths and domains grant nothing and are announced (`skills.allowed_tool_not_granted`). - **Unlisted tools are judged as usual** — asked, never refused for being unlisted. - **`disallowed-tools`** (a `*` on it reads as nothing; the rest of the list still refuses) refuses for the rest of the run, read where a person's deny rows are read (the gate, an approved edit, a resumed call, the changed-files notice) — `decisionReason: "skill"`, `deniedBy: "policy"`. - **Lifetime** = the runTask (a steer, live or parked, folds into the run — measured on the reference: a mid-turn message does not end the grant); the next runTask starts clean. A delegated child captures the rows at spawn and keeps them until it ends; a capture the child cannot read refuses the spawn. - **`TaskSpec.userInvokedSkills`** — the slash route: the named skills' rows take effect at the start of the run, no `Skill` call, no card; an unknown name refuses the run (`config.user_invoked_skill_unknown`). Under `dontAsk` this is the only route that grants (the model route's card is refused). - **Attribution.** A cleared call carries `decisionReason: "skill"` and emits `permission.skill_allowed` `{ toolName, toolCallId, skill, entries }`. - **Who is hurt.** A deployment that fenced the model with a skill's list (unlisted tools now ask or run per the mode; listed ones run without asking for the run); a host that set `SkillSpec.manifest` / `allowPaths` (not read); an embedder with no approver under an asking mode (a skill that declares a list cannot be activated by the model — the card is refused with the remedy sentence); a deployment policy whose unmarked `ask` sits on a listed tool (cleared, like a stored allow rule clears it); a delegation tool reading `ctx.activeSkillScope()`; a probe that pinned "unlisted ⇒ denied by policy (safety)" or "Skill never asks". - **Compensation.** Deny rules or a delegated agent definition's `allowTools` to fence tools; session `allowDirs` / the write face to fence paths; `mandated` / `requiresRealApproval` or an ask rule for a question that must reach a person; an allow-list entry naming `Skill`, or `bypassPermissions`, for an embedder with no approver; `SkillSpec.allowedTools` in place of `manifest.allowTools`; `ctx.activeSkillGrants()` in place of `ctx.activeSkillScope()`. - **The directory loader copies; it judges nothing.** `createSkillsFromDirectory` reads `allowed-tools` / `disallowed-tools` into `SkillSpec.allowedTools` / `disallowedTools` entry by entry as the author wrote them — in every spelling the format uses (space, comma, flow sequence, quoted, multi-line, block scalar) — with no intersection against a roster, no projection onto a tool name, no refusal, no de-duplication and no warning; an entry naming a tool nothing mounts is carried (a grant that never fires), a repeat is carried, and an absent or empty list is an absent member. What an entry means is read in one place, the run's grant table, which announces at the start of the run what it cannot read (`skills.allowed_tool_not_granted`). Removed with the old mapping: the `SkillsDirectoryOptions.deployedTools` option (a host still passing it is refused, `config.deps_retired_key`) and the warning codes `allowed_tool_pattern_unsupported`, `allowed_tool_not_mounted`, `disallowed_tools_unenforced`. A deny list with no allow list is carried like any other (the "unenforced" notice it used to raise is gone: a deny row is enforced on its own). - **A host still passing `SkillSpec.manifest` is refused, not ignored.** Any element of `TaskSpec.skills` carrying the member ends the run with `config.spec_retired_key` (`TaskSpec.skills[].manifest is retired …`, naming `allowedTools` / `disallowedTools`), before the first model call; the resume ladder refuses it before the claim (`checkpoint.config_refused`, `detail.code` the same). `SkillManifest` and `SkillSpec.manifest` are gone from the types; the `allowPaths` write fence had no reader left and goes with them. - **The auto-promote fold has no scope gate.** `PromotedRecord` is `{ gate2Verdict }` (`manifest` and `gate3Scoped` removed: the per-skill runtime narrowing they described no longer exists, so there is no scope to arm or leave unpropagated; `lineageId`, which only keyed that scope, goes with them); `decideAutoPromote` is the three-gate present-and-passing fold with the same four guards; `deriveTripwire(text, declared, profileTokens?)` takes `declared: Pick` and reads each entry as a rule for the tool it names (symbol-drift baseline). The module is still inert (no production caller). - **Package surface.** Deleted: `SkillManifest`, `skillScopeWriteToolNames` (its one reader, the dead internal `PATH_WRITE_TOOLS`, is deleted with it; the roster member `pathTarget.skillScopeEligible` stays declared, with no reader). Added (types only): `SkillGrantRecord`, `SkillGrantHit`, `SkillGrantLane`, `SkillGateSeats`, `PermissionSeatReading`, `PermissionSeatInputs`. - **Not in this release, stated.** A write-path or domain entry (`Edit(src/**)`, `WebFetch(domain:…)`) grants nothing (the narrow allow reading for those forms is a later ticket); the model route's rows across a cross-process park follow the checkpoint section that carries them; a slash command typed mid-run grants nothing. Known limits: KL-1303-a (mid-run slash) · b (write-path / domain entries) · c (a note, not a gap: `*` voids an allow list and is inert on a deny list, whose other entries still refuse) · d (a card can list an entry that stands down in `auto`) · e (a malformed `_meta` result-size declaration is ignored silently) · f (the observer digest carries the observed child's tool output) · g (a 7.40.x worker that resumes a row parked by this release does not read the grant section). - **Park and resume (car C).** *Before:* a resumed leg started with an empty grant table — what the model's activation or a child's capture granted asked again, what `disallowed-tools` refused ran again, and a parked `Skill` call activated whatever the resume's skills defined. *Now:* - **The run's grown rows are frozen with the row.** A park writes `state.skillGrants` — the rows the model's activations and a delegated child's capture wrote, `{ skill, behavior, entry, origin }` with `origin` `"model"` or `"inherited"`, refusals included — and the resumed leg seeds them back (a re-supplied capture is not held twice). The slash route's rows are not frozen: the re-supplied spec writes them again (drop `userInvokedSkills` from the resume and that grant is gone). Absent section = zero rows; a present one that does not read as grant rows is refused before the claim — `checkpoint.invalid_outcome`, `detail.reason: "skill_grants_damaged"`, the row pending and unchanged — never read as empty. - **A parked Skill card binds the skill and the lists it was asked under.** The row of a parked `Skill` call carries `boundGrantDigest` — the card's two disclosures: the skill's name as the skill table spells it (resolved the one way the `Skill` tool resolves `skill`: exact, case-sensitive, no alias) and its two lists in canonical spelling (`Read()` / `Read(*)` read as `Read`, order and duplicates ignored); the body is not part of it — beside `boundInputHash`; only that row carries it. An approving resume recomputes it over the resume's skills as the resumed leg will serve them (read once at the resume entrance — each definition and its lists copied, so an edit to the host's own objects during the resume reaches neither the check nor the activation; first of a name; a skill the load gate rejects, or a resume that loads none, counts as absent) and the decided arguments; any difference — another skill named (a person's edit), lists wider, narrower or gone — or a `Skill` row without one is refused before the claim: `checkpoint.invalid_outcome`, `detail.field: "boundGrantDigest"`, a sentence that names the skills (no path), says which side differs ("given on the card for A, and this decision selects B" / "A no longer declares the lists this approval was asked under") and says to decide the row as deny and re-activate the skill. A deny decides as before. - **The table never holds the same row twice**, keyed on the row: activating a skill whose definition changed across the park writes the new definition's rows (its new refusals included). - **The binding is judged again on the bytes that run (#1328).** The resumed leg re-screens an approved call through PreToolUse (#1294) and a re-screen may rewrite it, while the claim judged only the decided bytes: a hook that answered the parked `Skill(a)` call with `updatedInput: { skill: "b" }` activated `b` and wrote `b`'s list as approved — the card the person approved showed `a`'s. The same judgement now runs once more at the resumed execution boundary on the bytes that will run (the person's rewrite, else the re-screen's, else the row's), after every station that can change them and right before the activation: a skill there that does not digest as `boundGrantDigest` — another skill than the card's (whatever its lists), one this resume does not load, or the card's skill with other lists — is not executed (the tool result is the refusal, `isError: true`; `tool_end.gate.disposition` `{ kind: "denied", deniedBy: "policy" }` beside the person's yes; the row is already consumed, so no `CheckpointError`) and writes no grant row; the sentence names both skills (no path) and says to have the model activate it again (a new card). A rewrite to the approved skill with other bytes (`args`) runs. *Who is hurt:* a deployment whose PreToolUse hook rewrites an approved parked `Skill` call to another skill — that call no longer runs, even when the other skill's lists are the same. *Compensation:* let the model activate the other skill itself; its card shows its lists. Pins: `test/backlog1328-parked-skill-rescreen-swap.test.ts` (real Runner, real stdio MCP server, both stores): ① the swap ⇒ not executed, no row, the swapped skill's tool still asks; ② no rewrite; ③ a name the resume does not load; ④ the approved skill with other bytes, ④b another skill with the same lists (refused: no row, its body never in the context), ④c same name and lists, another body (runs); ⑤ the person's edit (refused at the claim, the sentence says another skill was selected), ⑤b the card's skill widened (the sentence says its lists changed); ⑥ a card that disclosed no lists, ⑥b a row with no digest; ⑦ the model activates the other skill itself (its card); ⑧ the host edits the skills it passed between the claim and the execution; ⑨ a later station edits the handed bytes in place. Base `e262b667f`: ①③⑥⑦⑧ red on both stores, ②④⑤⑥b green (⑤'s sentence pin red there: it said "b no longer declares"); ④b red under a name-less digest; ⑨ added after, red with the check removed; seven mutations, each red on its own fixtures. - *Who is hurt:* an operator who edits a skill's lists while its card is parked (the approve is refused); a `Skill` call parked by 7.40.x through a hook / rule / policy ask (its row has no digest — an approve is refused, a deny decides); a host or SDK that routes `detail.field` / `detail.reason` exhaustively or keys on the `tool_approval` arm's key set (one new word each, one new key); a 7.40.x worker resuming a 7.41.0 row (it does not read the section — the run's skill refusals are lost there; no version stamp gates it). *Compensation:* decide the parked row as deny and let the model activate the skill again (a new card shows the current lists); drain parked rows before rolling back to 7.40.x; map `skill_grants_damaged` as terminal-for-the-row (the `write_face_damaged` row) and `boundGrantDigest` as its own recovery (deny + re-activate — re-approving the same row cannot pass). - Pins: `test/backlog1303c-park-resume-grants.test.ts` (real Runner, real stdio MCP server, the in-memory and the file checkpoint stores): ① the model route's grant and ② its refusal across a park; ③ a child's capture, with and without re-supply; ④ the slash route not frozen; ⑤ eight damaged shapes refused pre-claim + the empty-list control; ⑥ no rows ⇒ no section, no digest; ⑦ widened ⇒ refused; ⑦b no digest ⇒ approve refused, deny decides; ⑦c no skills loaded ⇒ refused; ⑦d / ⑦f the host edits its own skill objects inside the preflight window ⇒ neither the check nor the activation sees it; ⑦e a skill the load gate rejects ⇒ refused; ⑧ unchanged ⇒ activates; ⑨ narrowed ⇒ refused; ⑩ canonical spelling; ⑪ only the Skill row carries the digest; ⑫ both members across a fresh file store and Runner; ⑬ ⑭ the row-keyed table; ⑮ frozen rows outlive the skill's removal from the resume (the chosen reading of a park: the run keeps what it was granted and refused). Base `f65da1617`: 22 of 31 red (the nine greens are the controls ③b ④a ④b ⑤-empty ⑥ ⑧ ⑩ ⑬ ⑭); seventeen mutations, each red on its own fixtures. - **Consumers.** server — skill key whitelist: drop `manifest`, accept `allowedTools` / `disallowedTools`; pass `userInvokedSkills`; map `decisionReason: "skill"` / `permission.skill_allowed`; render the `Skill` card; DEPLOY-PREREQS: a request carrying `manifest` is refused (the engine refuses it too, `config.spec_retired_key`; `spec-fields.ts`'s `Record` goes red on the type change); park and resume — the resume refusal routing gains a reason word (`skill_grants_damaged`, terminal for the row) and a field word (`boundGrantDigest`, deny + re-activate), the park row's key set gains `boundGrantDigest` (engine-internal, not echoed on a decide), and DEPLOY-PREREQS: drain parked rows before rolling back to 7.40.x (KL-1303-g). cli — mint `userInvokedSkills` when the person types `/name`; render the `Skill` card (the message carries what approving releases). client-core — carry both lists in the skills projection (an MCP server's skills carry none), the request key, the vocabulary mirror (+`skill`, +the notice code). test — the (a)–(f) cells, `mcp__*` / `*`, S1–S13. - Pins: `test/backlog1303-skill-grant-lanes.test.ts` (real Runner, real stdio MCP server): ① a listed tool runs with no card after the Skill card (+ the three covering spellings); ② an unlisted tool is asked, not refused (direct list and the directory loader's list); ③ the card iff a list is declared; ④ the card on the final arguments (policy and hook rewrites); ⑤ `Skill` + a listed tool in one message; ⑥ a new runTask starts clean; ⑦ deny / ask rules first; ⑧ shell floor / server marks / plan mode not cleared; ⑨ `*` / `mcp__*` grant nothing and are announced; ⑩ `Bash(git:*)` vs a compound (a writing second segment asks, a read-only one runs — per command the same answer as a stored allow rule); ⑪ the slash route and its unknown-name refusal; ⑫ a child captures and keeps the rows; ⑬ deny rows at the gate, the edit round and the resumed boundary, gone next run; ⑭ dontAsk's two routes; ⑮a / ⑮b a parked / live steer leaves the grant in place, ⑮c an unlisted tool still asks after it; ⑯ an unreadable capture refuses the spawn; K1 card sentence (sanitized, capped, read by the classifier); K2a whole `Bash` / interpreter prefix by mode; K2b write-path / domain entries; K6 attribution; S11 a list naming `Skill`. Base `stage-7410`: 40 of the first 42 red (③'s two list-less rows are the controls); ⑮c added red on base. `test/backlog1303-skill-grant-unit.test.ts`: the entry grammar, the matcher both ways, the table, the capture reader, the card question. `test/backlog1303b-loader-and-surface.test.ts` (loader and surface): ① the loader copies both lists entry by entry in every spelling, with no warning; ② a name nothing mounts is carried, `deployedTools` is refused by name; ③ `SkillSpec.manifest` refused at the run, at the door and at the resume ladder; ④ no `allowPaths` / `gate3Scoped` / `SkillManifest` token anywhere in `src/`, the promoted record is one member; ⑤ the six types exported, the two names deleted (entry file, runtime, frozen snapshot); ⑥ the seven known-limit rows; S the loader's output compiles to the same rows and unread entries as the same lists written by hand; D a `*` on a deny list reads as nothing and the rest of the list still refuses (three unit cells, and the loader → Runner lane ⑬a′ in `backlog1303-skill-grant-lanes.test.ts`); ③ also the delegation lane (a `manifest` on an agent definition's `skills` refuses the child). Base `stage-7410`: 30 of the first 37 cells red (the type-level cells red under `tsc`), the directory-loader cell in `backlog1303-skill-grant-lanes.test.ts` ① red against a base-shaped loader. ### What a background agent is doing right now: one reading, three faces (#1118; behavior (additive: more facts on read faces); +9 exports) (@cli @client-core @server @test) - **Before (v7.40.0).** AgentTranscript returned a background agent's last N steps with no state and no time; ListAgents gave an agent row a status word and nothing else; TaskOutput a status word, and for a parked agent neither the approval card's id nor its deadline nor whether it had expired. A parent model asked "how far along is it?" had only the step list and answered from it: a child parked on an approval whose card had already expired was reported as "still on step 3, about halfway". - **Now.** One projection, `readAgentState` (`src/core/agent-state.ts`), reads the agent's registry row (the live handle, or the durable record when no live handle answers) and, for a parked row only, the approval checkpoint the row names. Every face carries it as `agentState` — `{ status, readAt, row, lastActivityAt?, approval?: { state, checkpointId?, deadline? } }` — and renders it with the same clauses: - AgentTranscript: first line `State: · last activity ago[ · approval (deadline in | deadline passed ago)]`, on every answer that resolved the row (the steps answer and the `not_retained` / read-failure / transcript-gone refusals alike). Each step line starts with `[ ago] `, or `[started ago, no result yet] ` for a call with no result; `details.steps[i]` gains `at` (epoch ms) and `inFlight`. - TaskOutput (background agents): a `state: …` line right after `status:`, on the live, durable-terminal, durable-parked and durable-still-running answers. - ListAgents: the activity clause and (parked) the approval clause as columns on agent rows with a live registry row. The status word is the registry row's own (`SemaTaskStatus` verbatim — `parked` = suspended on a durable approval). The approval state is the checkpoint row's (`pending` / `resolved` / `expired`) or `missing` / `unreadable`. Missing facts are said, not dropped: a durable row still marked running reads `last activity unknown (recorded as running by another engine process)`. The resume token never appears; the card is named by its non-secret `checkpointId`. - **Reference.** CC 2.1.280 has no model-facing mid-run state face: `TaskOutput` / `AgentOutputTool` are in its removed-tool set (`cli280.js` @14509156), the background launch result tells the model "if the user asks for progress, say the agent is still running" and "give status, not a guess" (@19756276, @16176281), and completion arrives as a `` with `completed|failed|killed|blocked` (@12580969); "Waiting for permission…" is a UI render (@31233163). UNANCHORED — no reference cell; the faces follow the reference's principle (state the facts the engine holds, invite no guess). - **Not visible, stated.** An approval answered in-process (a synchronous `onAsk`) while the agent runs is not recorded by the engine — such an agent reads `running`, and on AgentTranscript the waiting call shows as `started ago, no result yet`. A pending card past its deadline stays `pending` (the store's word); the deadline clause says it passed. A grandchild's row stays unreadable to its grandparent (existing access law). Roster rows with no local row carry no state (`unknown`, as before). - **Who is hurt.** A probe or renderer that pins AgentTranscript's FIRST line (`Agent a… — last N tool step(s)` is now the second line), its step lines byte-for-byte (they gain a time prefix), TaskOutput's second body line for a background agent (now `state: …`), or ListAgents' agent-row column count. A consumer that judges a `details` shape by key presence sees `agentState` on these answers. - **Compensation.** Read the step body after the `] ` prefix; read the header from `details.agentState` rather than the text. A host that mounts these tools itself passes `checkpointSeat` (the store it parks children into) to get the approval card; without it a parked agent reads `approval unreadable`. - **Consumers.** cli (L-776) — render `details.agentState` on the agent pane (status word, `lastActivityAt` relative to `readAt`, the card id / state / deadline for a parked agent); `details.steps[i].at` / `inFlight` for the transcript view. client-core — mirror the `AgentState` shape (open `status`; `approval.state` five words). server — a durable-row serving layer can render the same state with `readAgentState(agentStateSourceOfRecord(row), seat, now)` after its access check and pass it to `serveDurableAgentRowLane(row, agentState)`. test — the running / parked-pending / parked-expired / in-process-ask cells. - Pins: `test/backlog1118-child-state-one-source.test.ts` (real Runner + Agent tool background child): ① running (all three faces, epoch on details, age in text); ② parked on a pending card (card id + deadline, no token anywhere); ③ the card expired while the row reads parked; ③b a pending card past its deadline; ④ finished (positive control: today's terminal reading unchanged); ⑤ step times and the unfinished call; ⑥ the three faces equal at one instant (running and parked); ⑦ an in-process ask (running, no approval, the unfinished call); ⑧ a grandchild row stays unreadable; ⑨ presence (no seat ⇒ `unreadable`; a durable row run elsewhere ⇒ no `lastActivityAt`, said in text; no `approval` off parked); ⑩ step lines byte-identical apart from the prefix; ⑬ ListAgents reads each row's clock beside its facts (a slow card read on one row does not stamp a later row with an older instant). Baseline v7.40.0 (`stage-7400`): 10 of the first 11 red (⑧ green — the access law already held). Mutations M1–M16 per fixture in the car log. ### A background agent that keeps working is no longer stall-collected when no observer is mounted (#1118 finding; behavior (fix); +0 exports) (@server @test) - **Before (v7.40.0 and earlier releases carrying the design/164 stall sweep).** A background agent's registry row records its last activity on each tool start / end of the child (the stall signal `TaskRegistry.reapStaleSessionBackgroundAgents(staleMs)` reads). On the plain and fork background lanes that beat was fed only when the spawn carried an observer (`onBackgroundChildEvent`); the revive lane fed it always. With no observer mounted the row's last activity stayed at its spawn time for the whole run, so a session-scoped child that was busy running tools was collected — settled `killed`, attribution `system`, its run aborted — as soon as `staleMs` had passed since it was spawned. Measured on `stage-7400` (the 7.40.0 candidate), real Runner + Agent tool, no observer, `backgroundScope: "session"`, a child running twelve 20 ms tool steps back to back, `staleMs` 120, sweep after four steps had committed: the sweep returned 1 and the row ended `killed`. - **Now.** Both lanes feed the row's activity beat whether or not an observer is mounted (with no observer the fleet tick goes nowhere; the row's time still moves). Same cell: the sweep returns 0 and the child completes. A child stuck inside one call (one beat at the call's start, then nothing) is still collected once `staleMs` passes — positive control, same on both trees. - **Who is hurt (before).** A deployment that calls `reapStaleSessionBackgroundAgents` and spawns session-scoped background agents without an `onBackgroundChildEvent` observer: its busy children were killed as stalled at `staleMs` after spawn, with the interrupted-run wording. A deployment with an observer mounted was not affected (its rows already moved). - **Compensation.** None needed; a deployment that sized `staleMs` large to work around premature collection can size it to the real quiet stretch now. - **Also visible.** The same beat is the `lastActivityAt` the three read faces show; without the fix a busy child on such a deployment read `last activity