@sema-agent/sdk 16.1.0 → 16.3.0

package/openapi.yaml

@@ -416,7 +416,8 @@ paths:
         🔴 PREPARE-TIME REFUSALS ARE TRIAGED ON WORK DONE (server >= 7.104.0 / S-271, one rule for the whole table): a
         prepare-time refusal code that HAS a status in the server's per-code triage table (`resume_at.*` — `resume_at.not_found` is 404, the rest 422 —, governance codes,
         `rewind.store_unconfigured` / `rewind.capture_disabled` / `rewind.child_scope_unsupported` / `rewind_snapshot.unresolvable`, the
-        registered `config.*` codes incl. the three roster-bound ones, `corrupt_session`; codes outside the table, e.g. `rewind.invalid_spec`, stay
+        registered `config.*` codes incl. the three roster-bound ones and — server >= 7.116.0 — `config.invalid_checkpoint_store` (400) and
+        `config.user_invoked_skill_unknown` (400: top-level `userInvokedSkills` named a skill this run does not carry) and — server >= 7.117.0 — `config.image_invalid` (400: an inline image failed the engine's byte admission; `error` starts with `TaskSpec.images: `), `corrupt_session`; codes outside the table, e.g. `rewind.invalid_spec`, stay
         200 with a failed body) answers its 4xx / 5xx ERROR BODY only when the whole submission did ZERO WORK (cumulative
         `stats.turns === 0` AND `stats.tokens === 0` — the common case: nothing billed, not idempotency-cached). When a
         `verify` / `cascade` run's earlier tier already ran turns and only the last tier is refused, the SAME code arrives
@@ -885,6 +886,13 @@ paths:
             ⚠️ Against a server 7.19.0–7.22.0 the OLD caveat applies verbatim: only the parked legs dedupe —
             a lost 200 retried with the same key injects TWICE with byte-identical receipts; treat a lost 200
             there as "outcome unknown", never "safe to retry".
+            🔴 server >= 7.117.0 — TWO MORE 409 answers on a TERMINAL run (the `parked_for_wake` leg), refused BEFORE the wake card is minted
+            (no card is minted; the row is untouched; on 7.116.x this was a 202 `parked_for_wake` followed by a refusal at `/wake`, i.e. a card that could
+            never be redeemed): when the stored submit body of this session is one this version no longer replays — errorCode
+            `checkpoint.unsupported_version` (`retriable: true` = the card is still pending / cancellable, NOT "a retry will succeed"; the stored body carries
+            `settings.permissions.allow` under an earlier reading — list or statement era) or errorCode `resume_blocked_by_policy` (`blockedBy: "request.field_invalid"`;
+            the stored skill `disallowedTools` carries an entry the engine now reads as nothing). Both answers are word-for-word the ones `POST /v1/sessions/{sessionId}/wake`
+            gives for the same body. Way out: cancel the task and resubmit as a new one (with the entry fixed). The SDK does not retry them (409 is not in the retry set).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -960,7 +968,8 @@ paths:
         un-started ones settle as interrupted pairs, in-flight tools are NOT collateral. TWO shapes,
         discriminated by `text` presence.
         WITH text = cut + steer: the in-flight turn is cut and the text goes to the FRONT of the queue — the
-        `"now"` tier is the VERB's semantics, not a body field (the steer op's `priority` stays advisory) —
+        `"now"` tier is the VERB's semantics, not a body field (the steer op's own `priority` is a separate
+        input: it takes effect only on a server whose `Capabilities.fleet.steerPriority` reads `"engine"`) —
         and the run CONTINUES. 202 `{taskId, status, delivery:"queued-immediate", messageId, note}`;
         `messageId` ≡ the engine inputId, and a real cut is proven ONLY by a `task.turn_interrupted` event on
         the run stream whose `detail.inputId` matches it (core: no false interrupt claims — every real cut
@@ -2419,9 +2428,10 @@ paths:
             written. DETERMINISTIC: a retry cannot change it (the SDK does not auto-retry this code; it arrives as a bare `APIError`
             with `errorCode: "corrupt"`); the repair is the operator's — fix the file or delete it (deleting = an explicit "no
             rules"). For a damaged rules row `error` names the session, the damage grade and both exits, with NO on-disk path.
-            ⚠️ The same code also comes from the write path's high-water-mark sidecar (`.hwm.json`) being unreadable, and that one
-            sentence STILL names the sidecar's on-disk path (server 7.114.0 discloses it as a known gap: core #1307 / #1309, core
-            7.41.0). Also `internal.error` (unclassified).
+            ⚠️ The same code also comes from the write path's high-water-mark sidecar (`.hwm.json`) being unreadable: the sentence names the
+            object, the damage and both exits (fix the mark file, or delete it — deleting gives up the number it was holding). server >= 7.116.0
+            does NOT name the on-disk path any more (the location goes to the operator log `file_store_corrupt_read` only); server <= 7.115.x
+            still did. Also `internal.error` (unclassified).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -3039,14 +3049,13 @@ paths:
         2c session-sync PUSH Phase A — a SMALL metadata body (`entryIds, snapshots, policy, anchors, resolution?`); the
         entries stream in Phase B. The cloud classifies (§7), pre-checks blob presence (a missing referenced hash →
         422 `missing_blob` — PUT it first), guards the import lease + any active run (409), then mints a stagingId.
-        ⚠️ S-15 EPOCH DEBT (registered 2026-08-30, codex adversarial review; migration is a SEPARATE batch):
-        server ≥7.52's Phase A actually consumes `{entryIds, fileHistory?, policy, anchors, resolution?,
-        logDigest?}` (routes/session-sync.ts) — the `snapshots` key below is SILENTLY IGNORED there (an
-        unknown body key), so on ≥7.52 a push lands entries/policy/anchors and the session itself but NO
-        file snapshots/history; the snapshot-epoch shape below is what ≤7.51 servers consume. The full
-        migration (SessionManifest/SessionBundle/push-pull orchestration + `fileHistory: FileHistoryExport |
-        null` + epoch negotiation) is tracked as its own debt — this op's schema deliberately stays the
-        ≤7.51 truth until that batch lands rather than half-changing.
+        ⚠️ S-15 EPOCH: server ≥7.52's Phase A consumes `{entryIds, fileHistory?, policy, anchors, resolution?,
+        logDigest?}` (routes/session-sync.ts) — the `snapshots` key is SILENTLY IGNORED there (an unknown body key); the
+        file history rides `fileHistory` (a `FileHistoryExport` envelope, `null` / absent = none) and every blob it references must have been
+        `PUT …/sync/blobs/{hash}` first. ≤7.51 servers consume `snapshots` and do not know `fileHistory`. SDK 16.2.0 carries
+        `fileHistory` in `pushSessionBundle` / `importSessionBundle` (and fills `snapshots: []` on the pull side when the manifest omits it); a hand-rolled
+        push must send `fileHistory` itself, and only to a peer whose `capabilities.sessionSyncFileHistory` is not false (server >= 7.116.0 — else the
+        commit 422s `missing_blob`).
         `identical` → `{ relation:"identical", basis, payloadVerified }` with NO stagingId (skip Phase B);
         `basis` is `"entry-ids+digest"` when the caller supplied a comparable digest and it matched, else
         `"entry-ids"` (id-set equality only) — see the `ImportStaged` schema, which has carried these two
@@ -3063,6 +3072,11 @@ paths:
               properties:
                 entryIds: { type: array, items: { type: string } }
                 snapshots: { type: array, items: { $ref: '#/components/schemas/SyncSnapshot' } }
+                fileHistory:
+                  oneOf:
+                    - { $ref: '#/components/schemas/FileHistoryExport' }
+                    - { type: 'null' }
+                  description: 'server >= 7.52: the file-history envelope (replaces `snapshots`); `null` / absent = none. Every blob it references must already be PUT.'
                 policy: { type: array, items: { $ref: '#/components/schemas/SessionRulesRecord' } }
                 anchors: { type: array, items: { $ref: '#/components/schemas/SyncAnchor' } }
                 resolution: { type: string, enum: [overwrite-dst], description: Override a fork/stale loss-of-history conflict. }
@@ -4639,10 +4653,11 @@ paths:
         `LEADER_ENABLED` (default OFF) + `REMOTE_EXEC=e2b`. Mode is a SERVER deploy flag, not a client choice:
         `LEADER_FANOUT_ENABLED=true` (default) lets the router fan out to N isolated workers (= the value-HOLD
         correctness bet); `=false` pins a single worker. Either way it runs the E2B+git pipeline. Door B's brain
-        is the strong single agent via `/v1/tasks`+`/v1/runs`+`scenario`. When disabled (`LEADER_ENABLED` off)
-        the route is simply NOT REGISTERED → the generic **404** `not_found.route`, not 501.
-        (Corrected 2026-07-31: "When disabled → 501" was never true — no code path emits 501 here; a consumer
-        branching on 501 to detect "leader unavailable" never fires.)
+        is the strong single agent via `/v1/tasks`+`/v1/runs`+`scenario`. When there is no leader face on the deployment
+        (`LEADER_ENABLED` off) the answer depends on the server: server >= 7.116.0 mounts the route unconditionally and answers
+        **501 `capability.leader_endpoint_required`** (new code; under multi-tenant the identity gate's 401 still comes first);
+        <= 7.115.x did not register the route at all → the generic **404** `not_found.route`. Detect "leader unavailable" by
+        `errorCode` (or the `capabilities.leader` bit, which reads the same fact as the gate), not by the status alone.
 
 
         🔴 IDEMPOTENCY (server >= 7.24.0): this POST now consumes the `Idempotency-Key` header — the header is
@@ -4783,7 +4798,8 @@ paths:
           description: >-
             (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate (not the bare
             isOperator, whose empty-OPERATOR_PRINCIPALS "true-for-all" would make this index-mutating door
-            world-writable).
+            world-writable). With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501
+            `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -4837,7 +4853,7 @@ paths:
         '400': { $ref: '#/components/responses/BadRequest' }
         '401': { $ref: '#/components/responses/Unauthorized' }
         '403':
-          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate (§P2.4a).
+          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate (§P2.4a). With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -4891,7 +4907,7 @@ paths:
       responses:
         '200': { description: '{ bake }.', content: { application/json: { schema: { type: object, required: [bake], additionalProperties: false, properties: { bake: { $ref: '#/components/schemas/BakeRecordView' } } } } } }
         '403':
-          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate.
+          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -4909,7 +4925,7 @@ paths:
       responses:
         '202': { description: '{ bakeId, cancelRequested, note }.', content: { application/json: { schema: { $ref: '#/components/schemas/BakeCancelAck' } } } }
         '403':
-          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate.
+          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -4971,7 +4987,7 @@ paths:
       responses:
         '200': { description: 'SSE stream.', content: { text/event-stream: { schema: { type: string } } } }
         '403':
-          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate (this summary previously did not mention the restriction at all).
+          description: (declared 2026-07-31) errorCode "auth.operator_only" — EXPLICIT operator gate (this summary previously did not mention the restriction at all). With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -5183,7 +5199,7 @@ paths:
               schema: { $ref: '#/components/schemas/EntryProvenanceAccount' }
         '400': { description: 'errorCode "request.id_invalid" — the entry id could not be decoded.' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'errorCode "auth.operator_only" — provenance and erasure are operator-only deployment actions.' }
+        '403': { description: 'errorCode "auth.operator_only" — provenance and erasure are operator-only deployment actions. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '500':
           description: >
             errorCode "internal.memory_control_plane_corrupt" — core's FAIL-CLOSED refusal: the control plane
@@ -5253,7 +5269,7 @@ paths:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'errorCode "auth.operator_only" — provenance and erasure are operator-only deployment actions.' }
+        '403': { description: 'errorCode "auth.operator_only" — provenance and erasure are operator-only deployment actions. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '409':
           description: >
             Three core-minted codes, passed through verbatim; branch on `errorCode` (the status cannot tell them
@@ -5332,7 +5348,7 @@ paths:
               schema: { $ref: '#/components/schemas/MemoryOriginExternalResult' }
         '400': { description: 'errorCode "request.query_invalid" — `scopes` is absent or normalizes to an empty list. The refusal text also names where scope keys come from and repeats that an empty answer is not a clean store.' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions.' }
+        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '500':
           description: 'errorCode "internal.memory_control_plane_corrupt" (meaning (1) only on this read face) or "internal.error" (unclassified, text not echoed).'
           content:
@@ -5382,7 +5398,7 @@ paths:
             application/json:
               schema: { $ref: '#/components/schemas/MemoryOriginClearancesResult' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions.' }
+        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '500':
           description: 'errorCode "internal.memory_control_plane_corrupt" (the ledger cannot be read soundly) or "internal.error".'
           content:
@@ -5446,7 +5462,7 @@ paths:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions.' }
+        '403': { description: 'errorCode "auth.operator_only" — origin marking and clearance are operator-only deployment actions. With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '409':
           description: >
             Six core-minted codes, passed through verbatim; BRANCH ON `errorCode` — the six operator actions all
@@ -5569,7 +5585,7 @@ paths:
             application/json:
               schema: { $ref: '#/components/schemas/WiringDiagnostics' }
         '401': { $ref: '#/components/responses/Unauthorized' }
-        '403': { description: 'Multi-tenant worker: wiring diagnostics are operator-only (`auth.operator_only`).' }
+        '403': { description: 'Multi-tenant worker: wiring diagnostics are operator-only (`auth.operator_only`). With an EMPTY `OPERATOR_PRINCIPALS` the answer is instead 501 `capability.operator_principals_required` (server >= 7.116.0; any identity, ahead of authorization — branch on `errorCode`, not the status).' }
         '404': { description: 'This worker serves no wiring diagnostics (older server, or a process not assembled by the composition root).' }
 
   /v1/sendfile-links:
@@ -5899,7 +5915,9 @@ paths:
           description: >
             OPERATOR-ONLY cross-tenant read. Absent (or equal to the caller's own principal) = read your own
             rules. Anything else requires explicit OPERATOR_PRINCIPALS membership ⇒ otherwise 403
-            `auth.operator_only`. Rule text contains command shapes, so third-party reads are an information
+            `auth.operator_only` (server >= 7.116.0: with an EMPTY list the answer is 501
+            `capability.operator_principals_required` instead — any identity, ahead of authorization; your own rules never
+            go through the operator gate). Rule text contains command shapes, so third-party reads are an information
             disclosure and are deliberately not opened to non-operators.
         - name: scope
           in: query
@@ -6644,7 +6662,14 @@ components:
         application/json:
           schema: { $ref: '#/components/schemas/QuotaError' }
     NotImplemented:
-      description: 501 — capability not available (e.g. no TiDB run store; leader gated off; `wake` unsupported).
+      description: >
+        501 — "this deployment cannot answer this" (e.g. no TiDB run store; `wake` unsupported). server >= 7.116.0: HTTP has exactly ONE status for
+        "unavailable on this deployment" — 501 — and the CAUSE is the code: `capability.*` = change the deployment shape / wire the facility
+        (incl. the new `capability.leader_endpoint_required` for `/v1/leader*` and `capability.shared_memory_required` for `/v1/shared-memory/*`),
+        `feature.*` = turn a knob on (incl. the new `feature.memory_consolidation_disabled` and `feature.config_catalog_disabled`), and
+        `capability.operator_principals_required` = configure `OPERATOR_PRINCIPALS` (every operator-only endpoint answers it, for any identity,
+        when the list is empty; a non-empty list the caller is not on is still 403 `auth.operator_only`). Branch on `errorCode`, not the status
+        (these families answered 404 / 403 on <= 7.115.x). The one registered exception is `a2aServe`'s two routes (404, anti-fingerprint).
       content:
         application/json:
           schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -6824,7 +6849,18 @@ components:
               name: { type: string }
               description: { type: string }
               content: { type: string }
-              manifest: { type: object, additionalProperties: true }
+              manifest:
+                type: object
+                additionalProperties: true
+                deprecated: true
+                description: >
+                  RETIRED — server >= 7.116.0 rejects the WHOLE skill when this key is present on a delegated agent's skill (unknown key:
+                  `agent.skills must be …`; a top-level skill answers 400 `request.field_invalid` "skill.manifest was retired in core 7.41.0 — …").
+                  core 7.41.0 retired the skill manifest (hard break, no alias). Rewrite `manifest.allowTools` to the skill's
+                  `allowedTools` (an allow-rule source, not a fence); `manifest.allowPaths` has no replacement (use the session rules'
+                  `allowDirs`). Older servers (<= 7.115.x) still accept it; the key stays declared here until the next major.
+              allowedTools: { type: array, items: { type: string }, description: 'server >= 7.116.0 — the skill''s allow-rule source (see `SkillSpec.allowedTools`); <= 7.115.x rejects the key (unknown key).' }
+              disallowedTools: { type: array, items: { type: string }, description: 'server >= 7.116.0 — the skill''s deny-rule source (see `SkillSpec.disallowedTools`); <= 7.115.x rejects the key (unknown key).' }
               files:
                 type: array
                 items:
@@ -6933,6 +6969,18 @@ components:
             LISTING RENDERER, not to this gate: turn it down with `settings.skillListingBudgetFraction` /
             `settings.skillListingMaxDescChars`.
           items: { $ref: '#/components/schemas/SkillSpec' }
+        userInvokedSkills:
+          type: array
+          items: { type: string, minLength: 1 }
+          description: >
+            server >= 7.116.0 (core 7.41.0 #1303). Skills the HUMAN called by name (the shell parses the typed `/name`; by `SkillSpec.name`).
+            Their `allowedTools` / `disallowedTools` take effect from the start of the run and NO `Skill` card is raised (the human naming
+            it is the statement); it governs this one run only (a steer does not end it; the next submit does not carry it). Every name must be
+            a skill the run carries (scenario factory ∪ this request's `skills`), else the engine refuses to start: 400
+            `config.user_invoked_skill_unknown` (sync leg `POST /v1/tasks`; the async / live-stream legs answer 2xx and the same code lands on the
+            terminal run row; `disableSkills: true` makes any name this code). A bad value shape (bare string / empty-string member / non-string /
+            object / null) is a 400 `request.field_invalid`. Does not deliver the skill body. PROBE `capabilities.userInvokedSkills` (constant true);
+            absent = an older server that answers 400 `request.body_shape` listing the key in `unknownKeys` — do not send it.
         reasoningEffort:
           type: string
           enum: [off, minimal, low, medium, high, xhigh, max]
@@ -7146,6 +7194,13 @@ components:
           description: 'core 5.11.0: extra READ-ONLY absolute host paths — read fence only (classify read-boundary auto-allow + read_file/grep containment); writes to the same dirs are still refused. Same shape/400 rules as additionalDirectories; servers <6.6.0 silently ignore (harmless additive).'
         images:
           type: array
+          description: >
+            Image input: `{ data, mimeType }` (inline base64) or `{ url }`. 🔴 INLINE-ARM ADMISSION (server >= 7.117.0 / core 7.42.0): `mimeType` must be one of `image/png` /
+            `image/jpeg` / `image/gif` / `image/webp` (the API's type word, not a file extension), the decoded bytes must carry the DECLARED type's file signature, and the decoded size must
+            not exceed 5 MiB — otherwise the engine refuses BEFORE the first model call (after the UserPromptSubmit hook; not one model token spent) with 400 `config.image_invalid`, whose
+            `error` starts with `TaskSpec.images: `. Before 7.117.0 such an image was sent as-is to the model provider and the whole first request failed there (no code to branch on).
+            A base64 string longer than 5 242 880 characters (the model API's 5 MB image cap; the server reads the engine's exported constant) is NOT this code: the submit gate refuses it first
+            with 413 `request.payload_too_large` (zero model calls, no submit hook, no run row). The `{ url }` arm is unchanged. The model must accept image input (`ModelInfo.vision`; absent = unknown, send anyway).
           items:
             oneOf:
               - type: object
@@ -7289,9 +7344,20 @@ components:
             the delivery lane, so raising it only helps a model whose declared window is below 200 000 tokens.
             The engine's own twin code `config.skill_listing_budget_invalid` (400) is NOT reachable through this
             submit leg today — it belongs to callers that build a `TaskSpec` directly.
-            🔴 `permissions.allow` IS A STATEMENT, NOT A WHITELIST (server >= 7.115.0 / S-654; probe
-            `capabilities.settings.permissions.allowGrant === true` — an absent key is an older server that reads the bucket as a
-            list, so put nothing in it there). The bucket is compiled by the SAME rule compiler as `deny` / `ask`: a hit is a
+            🔴 `permissions.allow` — THE READING DEPENDS ON THE SERVER GENERATION (probe `capabilities.settings.permissions`; an absent bit = the older generation).
+            server >= 7.117.0 (`allowLayer === true`, core 7.42.0): the WHOLE list goes to the engine's allow layer and a listed call is NOT ASKED — the engine's ordinary and
+            "nobody stated it" questions are cleared, built-in write gates and shell checks included (like the reference implementation's `permissions.allow`); content forms
+            (`Bash(git:*)`, `Read(//dir/**)`) are accepted; entries the engine reads as nothing (`*`, write-path forms such as `Edit(src/**)`, domain forms, names with whitespace) are NOT
+            refused — the run opens with an `engine_notice` `permission.allowed_tool_not_granted`. Any layer's deny / ask rule, operator `APPROVAL_REQUIRE` / `APPROVAL_NEVER_AUTO` /
+            `MANUAL_MODE_SHELL_GATE=always`, write protection, governance, a hook's ask and plan-mode asks still ask (a matching `request` member then shows as `allowRuleShadowed` on the
+            card). The submit gate judges only the shape (array of strings, at most 1000 entries => 400) and the NAMES (the same judge and the same sentence as `deny` / `ask`: a retired name,
+            an unprefixed short name, or a protocol name whose server segment cannot be minted / is missing / is a wildcard (`mcp__*`) is a whole-request 422) — never the content.
+            🔴 THE 422 SENTENCE (server >= 7.117.0): `error` starts with `request settings cannot be applied as written: ` (<= 7.116.x: a different sentence that said tighten-only — all three
+            buckets share this exit, and the old head misled a caller writing a tightening rule and lied about the allow bucket). Do NOT dispatch on the sentence: it carries no code of its own, so
+            `errorCode` is the status-derived coarse code `request.unprocessable`.
+            The skill lists (`skills[].allowedTools`) read exactly like this bucket from 7.117.0 on.
+            Server 7.115.0–7.116.x (`allowGrant` without `allowLayer`): `permissions.allow` IS A STATEMENT, NOT A WHITELIST — an absent `allowGrant` is a server <= 7.114.x that reads the bucket
+            as a list, so put nothing in it there. The bucket is compiled by the SAME rule compiler as `deny` / `ask`: a hit is a
             reasoned allow = "somebody stated it" (it answers an MCP / A2A server-tool call nobody stated; without it an
             ask-class mode raises a card, and with no approval surface the call is refused); a miss states nothing and the call is
             judged as usual — a tool off the list is NOT refused any more (<= 7.114.x refused it). It does NOT skip the question
@@ -7300,8 +7366,11 @@ components:
             for that). For "only these tools" use the real knobs: the session rule `toolAllow`
             (`PUT /v1/sessions/{sessionId}/policy`), per-request `excludeTools` / `excludeAllTools`, or the deployment's scenario
             tool surface. Entry forms: a tool-name rule (exact name, `mcp__<server>__*`, `a2a__<peer>__*`; `Bash(*)` is accepted
-            and compiled as a whole-tool rule); a retired name, a short name with no protocol prefix, a missing / two-segment
-            MCP name (`mcp__figma` -> write `mcp__figma__*`), a backslash, more than 512 characters, or a CONTENT form
+            and compiled as a whole-tool rule; server >= 7.116.0 also accepts the two-segment covering form `mcp__<server>` / `a2a__<peer>`,
+            read as the whole server — same meaning as `mcp__<server>__*`); a retired name, a short name with no protocol prefix, a missing-segment
+            name (`mcp__` / `mcp__<server>__`), a protocol name whose server segment the engine cannot have minted (e.g. `mcp__github.com__*` —
+            write `mcp__github_com__*`; server >= 7.116.0 refuses it with a 422 instead of accepting a rule that can never match), a backslash,
+            more than 512 characters, or a CONTENT form
             (`Bash(npm:*)`, `Read(./x)`, `WebFetch(domain:...)`) is a whole-request 422 (permanent content-form allows live in the
             persistent rule store: `/v1/rules/cc-import`, or answer yes on a card). The same applies to a PreToolUse hook: an
             EXPLICIT `permissionDecision: "allow"` states it (and binds only the arguments the hook saw); a hook that only adds
@@ -8218,6 +8287,16 @@ components:
             is unchanged at 7.64.0 — only its source moved (projected from `result.terminal`, or read straight
             off a legacy flat blob). ⚠️ K-24 / S-173 (server >= 7.104.0): on a `needs_review` PARK row it is core's canonical
             `review.pending` (absent before) — never read "errorCode present" as "failed"; read `status` first.
+            🔴 server >= 7.116.0 (S-1099) adds three values for the run store's own terminal verdicts, which used to live only in the `error`
+            sentence: `run.stalled` (heartbeat-lost reap — and the read-time fold that precedes the reap; sentence `run stalled (instance lost?)`),
+            `run.orphaned` (local-lane restart / session-occupancy takeover reclaim; sentence `run orphaned by engine restart`) and
+            `approval.expired` (the expiry reap of a durably parked approval; the column already carried it, the read face did not project it;
+            sentence `approval expired before decision`). None of the three means the request was wrong — resending the same request is
+            pointless, only a new submission makes a new run. READ `status` FIRST (`failed`), then branch on the code. Open set (a string; always keep a
+            default arm). ABSENCE: rows written by <= 7.115.x carry only the sentence; a one-time startup migration backfills the code
+            (log `one_time_migrations_applied` `holderDeathCodeRowsBackfilled`) and a new replica reads such a row as the code during the upgrade window,
+            but the migration has a window (30 days after the release, then the write-back and the read half are deleted) — so
+            "no `errorCode`" never proves "not a holder death": rows migrated late or after the window stay sentence-only.
         error: { type: string }
         jobId:
           type: string
@@ -9029,7 +9108,8 @@ components:
             server >=7.12.0 — the `GET /v1/outcomes` mechanical-signal read aggregate (design/73 §7.2) is
             available. Predicate mirrors the route's refusal arms exactly: a QUERYABLE ledger is wired (a
             file-only sink writes JSONL and has no query face ⇒ 501), AND on a multi-tenant deployment the
-            operator list is non-empty (single-user has no such gate — the only user IS the operator).
+            operator list is non-empty (single-user has no such gate — the only user IS the operator); with an empty
+            list the multi-tenant route answers 501 `capability.operator_principals_required` (server >= 7.116.0; 403 before).
             Added because this face previously had a 501 but NO capability bit, leaving consumers to
             trial-by-501 — the exact pattern this capability surface exists to remove.
         images:
@@ -9053,7 +9133,17 @@ components:
             principal→org membership fold present), so true ⟺ the face actually works — a deployment with
             the store but no membership authority deliberately reports false (and does not mount the routes).
         workflows: { type: boolean, description: "ENGINE-CAN: this worker's engine can orchestrate S8 self-orchestration workflows (server: `workflowsCapable ?? Boolean(workflowRunStore)`). The MOUNTING of the durable /v1/workflows read routes is the separate `workflowsList` bit below; the two coincide in today's wiring but are declared as orthogonal axes." }
-        workflowsList: { type: boolean, description: "`GET /v1/workflows` list face (separate from the per-run reads)." }
+        workflowsList: { type: boolean, description: "`GET /v1/workflows` list / detail / stream faces (the workflow run store is wired; separate from the per-run reads). server >= 7.116.0: the journal face `GET /v1/workflows/{id}/journal` is advertised by the new bit `workflowsJournal`, not by this one (value unchanged)." }
+        workflowsJournal:
+          type: boolean
+          description: >
+            server >= 7.116.0 (predicate class "facility": the workflow run store AND the journal store). Advertises
+            `GET /v1/workflows/{id}/journal`. On a deployment with the run store but no journal store (`DB_BACKEND=memory`,
+            multi-tenant bare boot, SQL coordinates not fully configured) with self-orchestration on, `workflowsList` is true
+            and this is false; the journal face then answers 501 `capability.workflow_store_required` (any id, ahead of the
+            per-row owner check; `capability.self_orchestration_required` when the run store is absent). A journal entry point reads THIS bit, not
+            `workflowsList`. ABSENT = an older server (<= 7.115.x): fall back to `workflowsList` (the old behaviour — the
+            bit could be true while the journal face always answers 501).
         workflowModels:
           type: array
           items: { type: string }
@@ -9096,8 +9186,8 @@ components:
             (DESIGN-278 §5 S2 — deployment config self-description) is mounted on this DEPLOYMENT. TWO-term
             conjunction, written against the route's own refusal arms: ① the `CONFIG_CATALOG_ENABLED` knob is
             on (default on; a compliance deployment that turns it off makes the path a 404 — the valve-family
-            precedent) AND ② the operator principal list is NON-EMPTY (with an empty list the route 403s every
-            identity). 🔴 DEPLOYMENT-LEVEL AVAILABILITY, NOT THE CALLER'S AUTHORIZATION: the caller's own
+            precedent; server >= 7.116.0 answers 501 `feature.config_catalog_disabled` there, 404 before) AND ② the operator principal list is NON-EMPTY (with an empty list the route refuses every
+            identity — 501 `capability.operator_principals_required` on server >= 7.116.0, 403 before). 🔴 DEPLOYMENT-LEVEL AVAILABILITY, NOT THE CALLER'S AUTHORIZATION: the caller's own
             identity is NOT in the predicate — the route additionally requires the CURRENT principal to be an
             explicit operator (`routes/config-catalog.ts` `explicitOperatorOk`, else 403 `auth.operator_only`),
             so a non-operator reads `true` and still gets 403. Show/invoke the catalog only for an identity you
@@ -9117,8 +9207,15 @@ components:
             `false`/absent otherwise (same predicate as the route's 501). `resume: "snapshot"` is a semantic
             advertisement: the bus is latest-state (not an event log) and every connection opens with a full
             snapshot frame, so reconnect = re-snapshot (deliberately no last-event-id cursor); transient
-            bg_notification frames re-deliver via the durable completion inbox. `steerPriority: "advisory"` =
-            steer body.priority is accepted + enum-validated but a no-op until the core queue seam (E15).
+            bg_notification frames re-deliver via the durable completion inbox. `steerPriority` (a string, open
+            set) says whether the steer body's `priority` takes effect on THIS server: `steerPriority: "advisory"`
+            (server <=7.115.x) = accepted + enum-validated + echoed but a no-op (nothing is handed to the engine);
+            `steerPriority: "engine"` (server >=7.116.0) = `priority` (`now` / `next` / `later`) is handed to the
+            engine as the injection tier, and the engine owns what each tier means — `now` cuts the in-flight turn
+            IMMEDIATELY (the running tool receives an abort, an approval card pending on this replica is revoked; one `engine_notice`
+            `task.turn_interrupted` frame is the evidence), `later` is delivered after the turn the run would have stopped on, no `priority` =
+            `next`. Read this bit before offering a `priority` choice; an absent
+            or unknown value means "do not assume it takes effect", never `"engine"`.
           oneOf:
             - type: boolean
               enum: [false]
@@ -9342,22 +9439,28 @@ components:
         settings:
           type: object
           description: >
-            🔴 server >= 7.115.0 (S-654), ALWAYS present: `{ permissions: { allowGrant: true } }` — the VERSION bit for "which reading does this
-            server give `settings.permissions.allow` on a task submit". `permissions.allowGrant === true` = the `allow` bucket is compiled into
-            ALLOW RULES: a hit gives "somebody stated it" (so an MCP / A2A server-tool call nobody stated no longer raises a card) — it is NOT
-            "skip the question" and NOT a whitelist (a tool off the list is no longer refused; the engine's own write gate / shell checks still ask
-            on built-in tools, deny / ask still win; a bad-shape or content-form name is a whole-request 422).
-            🔴 ABSENT KEY = an older server (<= 7.114.x), which read `allow` as a WHITELIST (everything off the list refused) — do not put anything
-            in the allow bucket there. NOT the same bit as `taskSettings.permissions` (unchanged, still a boolean: "this server accepts the
-            `settings.permissions` face"). A version bit: constant `true`, never varies with the deployment; the deployment-level "who stated what"
-            (operator env `APPROVAL_GRANT`) is on the operator diagnostics face (`serverGates.approvalGrant`), not here.
+            🔴 server >= 7.115.0, ALWAYS present: `{ permissions: { allowGrant: true } }`; server >= 7.117.0 adds `allowLayer: true` to `permissions` — the VERSION bits for
+            "which reading does this server give `settings.permissions.allow` on a task submit" (both constant `true`, never vary with the deployment: the single-user
+            and `REQUIRE_PRINCIPAL=true` forms carry the same value). Read three levels: `settings` -> `permissions` -> <bit>; an absent / non-boolean bit = a server without it.
+            `permissions.allowGrant === true` (>= 7.115.0) = the `allow` bucket is read as allow RULES, not as a list (a tool off the list is no longer refused).
+            `permissions.allowLayer === true` (>= 7.117.0, core 7.42.0) = the server hands the WHOLE `allow` list to the engine's allow layer: a listed call is NOT ASKED (the engine's
+            ordinary and "nobody stated it" questions are cleared — built-in write gates / shell checks included, like the reference implementation's `permissions.allow`); content forms
+            (`Bash(git:*)`, `Read(//dir/**)`) are accepted; entries the engine reads as nothing (`*`, write-path / domain forms, names with whitespace) are NOT refused — the run opens with an
+            `engine_notice` `permission.allowed_tool_not_granted`; any layer's deny / ask rule, operator `APPROVAL_REQUIRE` / `APPROVAL_NEVER_AUTO` / shell floor / write protection /
+            governance, a hook's ask and plan-mode asks still ask (a matching member then shows as `allowRuleShadowed` on the card). The submit gate judges only the shape and the NAMES (retired
+            name / unprefixed short name / unmintable protocol server segment => 422, at most 1000 entries => 400) — never the content.
+            🔴 ABSENT `allowLayer` with `allowGrant` present = a 7.115.0–7.116.x server: allow is a STATEMENT (it does not clear the engine's own write gate / shell checks; a content form
+            is a whole-request 422). ABSENT KEY altogether (no `settings`) = an older server (<= 7.114.x), which read `allow` as a WHITELIST (everything off the list refused) — do not put
+            anything in the allow bucket there. NOT the same bit as `taskSettings.permissions` (unchanged, still a boolean: "this server accepts the `settings.permissions` face"). The
+            deployment-level "who stated what" (operator env `APPROVAL_GRANT`) is on the operator diagnostics face (`serverGates.approvalGrant`), not here.
           additionalProperties: true
           properties:
             permissions:
               type: object
               additionalProperties: true
               properties:
-                allowGrant: { type: boolean, description: 'Constant `true` on server >= 7.115.0: `settings.permissions.allow` is read as allow RULES (a statement), not as a list. The whole `settings` key being absent = an older server.' }
+                allowGrant: { type: boolean, description: 'Constant `true` on server >= 7.115.0: `settings.permissions.allow` is read as allow RULES, not as a list. The whole `settings` key being absent = an older server.' }
+                allowLayer: { type: boolean, description: 'Constant `true` on server >= 7.117.0 (core 7.42.0): the whole `settings.permissions.allow` list goes to the engine allow layer (listed calls are not asked; content forms accepted; entries read as nothing get an `engine_notice` `permission.allowed_tool_not_granted`). Absent = a server without it (7.115.0–7.116.x: allow is a statement; older: a list).' }
         memoryWrite:
           type: boolean
           description: >
@@ -9373,9 +9476,25 @@ components:
             S-15 换店; ≤7.51 the last conjunct was the file-snapshot store). Gate the whole sync surface off
             this. ⚠️ The two BLOB faces (PUT …/sync/blobs/{hash}, GET …/sync/history/blobs/{hash})
             additionally need the store's blob faces (`syncBlobFaces` — the SQL/cloud backends; the local
-            file backend has none): without them the PUT answers 501 `capability.snapshot_store_required`
-            and the history PULL answers the no-oracle 404 `not_found.blob`, while the REST of the sync
-            surface keeps working.
+            file backend has none): without them BOTH answer 501 `capability.snapshot_store_required`
+            (server >= 7.116.0; the history PULL answered a no-oracle 404 `not_found.blob` there on <= 7.115.x),
+            while the REST of the sync surface keeps working. Since server >= 7.116.0 the two blob faces are
+            advertised by their own bit `sessionSyncFileHistory`; this bit speaks for the conversation half
+            (its predicate additionally requires a session-policy store that can purge, `deleteBySession` —
+            a deployment whose embedder-supplied store lacks it answers the whole family 501
+            `capability.policy_purge_required` and this bit is false).
+        sessionSyncFileHistory:
+          type: boolean
+          description: >
+            server >= 7.116.0 (predicate class "facility": `sessionSync` AND the file-history store has blob transfer faces
+            — SQL backends only; `DB_BACKEND=local` is always false). Advertises exactly the two file-history blob faces
+            `PUT /v1/sessions/{sessionId}/sync/blobs/{hash}` and `GET /v1/sessions/{sessionId}/sync/history/blobs/{hash}`.
+            READ IT ON BOTH ENDS of a sync: if either is false, sync the conversation only — do not push `fileHistory`, do
+            not PUT blobs (a `fileHistory` pushed to a peer without the blob faces 422s `missing_blob` after commit). When
+            false the two routes answer 501 `capability.snapshot_store_required` (any session id, ahead of the owner check).
+            A blob that the session history graph does not reference / whose bytes are gone stays a 404 `not_found.blob`.
+            ABSENT = an older server (<= 7.115.x): the bit cannot be read there (a `DB_BACKEND=local` deployment with
+            `sessionSync: true` answered PUT blob 501 on every call), so try as before.
 
         # ─── S-139(sdk 8.3.0):对 server 7.60.0 的整体重对账补齐的 19 位 ───────────────────────
         # 行号 = server 7.60.0 树的 `src/http/routes/capabilities.ts`。语义与谓词的全文在
@@ -9468,7 +9587,8 @@ components:
           description: >
             Governance carry-out bundle pair `POST /v1/memory/{export,import}` (operator lane) —
             capabilities.ts:261, two conjuncts: both engine seams wired AND `operatorPrincipals` NON-EMPTY
-            (an empty roster makes those routes 403 for every identity). True does not promise the backend
+            (an empty roster makes those routes refuse every identity — 501 `capability.operator_principals_required` on
+            server >= 7.116.0, 403 before). True does not promise the backend
             has the bundle composite face (core then refuses loudly with `memory.export_incomplete`).
         memoryCompliance:
           type: boolean
@@ -9570,10 +9690,13 @@ components:
         a2aServe:
           type: boolean
           description: >
-            Server-as-peer knob (capabilities.ts:564 = `config.a2aServe !== undefined`): true ⟺
-            `GET /.well-known/agent-card.json` and `POST /v1/a2a` exist; false ⟺ both 404. Scope is ROUTE
-            EXISTENCE, not "every method runs" — `message/send` / `tasks/get` additionally need a durable run
-            store (without it they answer a named JSON-RPC `-32004`).
+            Server-as-peer: true ⟺ `GET /.well-known/agent-card.json` and `POST /v1/a2a` exist; false ⟺ both 404
+            (`not_found.route`, anti-fingerprint — the one registered exception to "unavailable = 501"). server >= 7.116.0
+            predicate (class "facility + config"): the `A2A_SERVE_ENABLED` knob AND a durable run store; <= 7.115.x looked at the knob
+            only (`config.a2aServe !== undefined`). 🔴 value change: with the knob on but NO durable run store
+            (`DB_BACKEND=memory`, multi-tenant bare boot) this bit is now false and the card and the RPC both answer 404 (7.115.x:
+            true, card 200, every `message/send` / `tasks/get` a JSON-RPC `-32004`); the startup log carries a warn
+            `a2a_serve_not_served`. The old "the server deliberately does not fold the run store into this bit" note is retired.
         agentRoster:
           type: boolean
           description: >
@@ -9768,6 +9891,23 @@ components:
             answers the request key with a 400 `request.body_shape` naming it under `unknownKeys` — do not send the key
             there and tell the user the factory skills stay installed. True only says "this server knows the key", not
             whether the deployment has any factory skills.
+        userInvokedSkills:
+          type: boolean
+          enum: [true]
+          description: >
+            server >= 7.116.0 (constant true; no predicate, no tenant gate) — the ADVANCE READING for the request key
+            `TaskRequest.userInvokedSkills` (skills the human named; effective from the start of the run, no `Skill` card);
+            the bit and the key are the SAME word. ABSENT = an older server (<= 7.115.x), which answers the key with a 400
+            `request.body_shape` naming it under `unknownKeys` — do not send it there.
+        skillToolLists:
+          type: boolean
+          enum: [true]
+          description: >
+            server >= 7.116.0 (constant true) — the skill tool lists `allowedTools` / `disallowedTools` TAKE EFFECT (allow-rule /
+            deny-rule source; see `SkillSpec.allowedTools`). ABSENT = an older server (<= 7.115.x): on a top-level skill the two
+            lists are accepted but the engine does not read them — they are silently inert and there is NO 400 to probe, so do not
+            expect them to stop a tool (fence with deny rules instead); on a delegated agent's skill they are an unknown key that
+            rejects the whole skill.
     WriteProtectionCapability:
       type: object
       additionalProperties: false
@@ -9902,11 +10042,50 @@ components:
         engine refuses the skill outright at load time, so the HTTP face answers first where the caller can read it).
         The bound is 1 048 576 **UTF-16 code units** (`MAX_SKILL_CONTENT_CHARS`); see the STRING-LENGTH UNIT
         convention in `info.description` for why this `maxLength` states that number verbatim.
+        🔴 server >= 7.116.0 (core 7.41.0): a skill carries two TOOL LISTS, `allowedTools` / `disallowedTools` — the
+        run-scoped ALLOW-RULE and DENY-RULE source of the skill once it is activated. NOT a fence (<= 7.115.x the engine read
+        the skill's tool list as "only these"): unlisted tools are judged as usual, listed ones are not asked about for the rest
+        of the run. On server 7.116.x that made it WIDER than `settings.permissions.allow` (then a statement that did not
+        release the engine's own write gate / shell ordinary asks on built-in tools); server >= 7.117.0 reads the two request-level
+        allow sources the SAME way (see `capabilities.settings.permissions.allowLayer`). Probe `capabilities.skillToolLists`
+        (absent = an old server that accepts the keys on a top-level skill and silently ignores them). The skill's `manifest`
+        key is RETIRED: any value on a top-level skill is a 400 `request.field_invalid` ("skill.manifest was retired in core
+        7.41.0 — …"; rewrite `manifest.allowTools` to `allowedTools`; `allowPaths` has no replacement), and on a delegated
+        agent's skill (`agents[].skills[]`) it is an unknown key that rejects the whole skill.
       required: [name, description, content]
       properties:
         name: { type: string, minLength: 1 }
         description: { type: string }
         content: { type: string, minLength: 1, maxLength: 1048576 }
+        allowedTools:
+          type: array
+          items: { type: string }
+          description: >
+            server >= 7.116.0. The skill's run-scoped ALLOW-RULE source (permission-rule spellings: a tool name,
+            `mcp__<server>` / `mcp__<server>__*`; `*`, write paths and domain forms grant nothing). Once the skill is activated
+            (named in top-level `userInvokedSkills` — no `Skill` card — or activated by the model and the card approved) the
+            listed tools are not asked about for the rest of the run: it clears the engine's ordinary and "nobody stated it" asks;
+            deny / ask rules, `APPROVAL_REQUIRE`, `APPROVAL_NEVER_AUTO`, the shell floor, write protection and plan-mode asks are not cleared.
+            NOT a fence: unlisted tools are judged as usual. Versus `settings.permissions.allow`: on server 7.116.x this list was WIDER (that bucket
+            was then only a statement); server >= 7.117.0 reads the two the SAME way, entry for entry (entries the engine reads as nothing get an
+            `engine_notice` `permission.allowed_tool_not_granted`). A non-string-array is a 400 `request.field_invalid`; a protocol name whose server
+            segment cannot be minted / is missing / is a wildcard (`mcp__*`) is a 400 too, and from 7.117.0 so is a retired name / unprefixed short
+            name (the name layer is judged by the same judge as the allow bucket) and a list of more than 1000 entries (top-level `skills[]` and
+            `agents[].skills[]` judge identically). Probe `capabilities.skillToolLists`.
+        disallowedTools:
+          type: array
+          items: { type: string }
+          description: >
+            server >= 7.116.0. The skill's run-scoped DENY-RULE source (same grammar / gates / probe as `allowedTools`): once the skill
+            is activated these tools are refused for the run (no execution, no card; `tool_end.gate.disposition` is
+            `{ kind: "denied", deniedBy: "policy" }`); write-path forms and command rules compile into deny rows too.
+            🔴 server >= 7.117.0: an entry the engine reads as nothing (`*`, a domain form `WebFetch(domain:…)`, a protocol name with a wildcard, a name with
+            whitespace or malformed) is refused AT SUBMIT — 400 `request.field_invalid`, `error` = `skill.disallowedTools entry "<entry>" reads as nothing (<reason>): <how to write it>`
+            (delegated level: prefix `agents[<i>]: skills[<j>]: `), top-level `skills[]` and `agents[].skills[]` alike — because an entry that looks like a refusal but refuses nothing is
+            worse than none (<= 7.116.x accepted it with only an operator-audience notice that was not sent to the session stream; that code is now `permission.allowed_tool_not_granted`,
+            user audience, on the session stream). 🔴 The resume legs judge the stored body the same way: a parked task whose stored skill `disallowedTools` carries such an entry answers
+            409 `resume_blocked_by_policy` (`blockedBy: "request.field_invalid"`, same sentence) BEFORE the claim — row and card untouched; a terminal run's `POST /v1/runs/{taskId}/steer`
+            answers it before minting the wake card. Why: engine 7.41 trimmed whitespace (`"Bash "` was a working deny), engine 7.42 reads verbatim (reads as nothing). The allow side does not refuse.
 
     McpServerSpec:
       type: object
@@ -10648,16 +10827,17 @@ components:
         baseUrl/apiKey/headers (the service strips them).
       # 🔴 封闭 + required 补铸造点(census 批2 第三段,2026-07-30):铸造点 `routes/capabilities.ts`
       # 是逐键字面量投影(白名单,不是透传——「open set」旧注不成立,新键要先过这道 spec)。core Model 类型
-      # 里 id/provider/reasoning 都是必填、`vision` 由 `input` 恒算 ⇒ 五键无条件;contextWindow/maxOutputTokens
-      # 0/缺省即省略,supportedEffortLevels 仅 reasoning 模型。
-      required: [name, id, provider, reasoning, vision]
+      # 里 id/provider/reasoning 都是必填 ⇒ 四键无条件;contextWindow/maxOutputTokens 0/缺省即省略,
+      # supportedEffortLevels 仅 reasoning 模型。🔴 server 7.117.0 起 `vision` 是三态(收 / 不收 / 没声明 `input`),
+      # 没声明 ⇒ 键缺席 ⇒ 不再是必有键(此前由 `input` 恒算成布尔,对没声明的条目报 false)。
+      required: [name, id, provider, reasoning]
       additionalProperties: false
       properties:
         name: { type: string, description: 'the @mention handle (user-pickable model name).' }
         id: { type: string, description: 'underlying model id (display, e.g. deepseek-v4-pro).' }
         provider: { type: string }
         reasoning: { type: boolean, description: 'a reasoning-tier model (picker can badge it).' }
-        vision: { type: boolean, description: 'accepts image input.' }
+        vision: { type: boolean, description: 'Whether this catalog row accepts image input — THREE states (server >= 7.117.0; before it a row that declared no `input` reported `false`): `true` = the row declares `input` and it contains "image"; `false` = declares `input` without it; ABSENT = the row declared no `input` (a hand-written catalog entry; the env lane and the config-center lane always declare it). ABSENT means UNKNOWN, not false: treat it as "send the image anyway and tell the user", do not read it as `false` and block the image locally — the server hands the image to the model for that same row at run time. Only an explicit `false` justifies "this model does not take images".' }
         contextWindow: { type: integer, description: 'E4 (SHIPPED) — context-window token DENOMINATOR for the %-used gauge; omitted when unknown.' }
         maxOutputTokens: { type: integer, description: 'E4 (SHIPPED) — single-call max output tokens; omitted when unknown.' }
         supportedEffortLevels:
@@ -11841,6 +12021,11 @@ components:
         expiresAtMs: { type: number, description: 'Absolute window deadline — the SAME number minted once for the tool_approval frame (never recomputed).' }
         sessionId: { type: string }
         requiresRealApproval: { type: boolean, enum: [true] }
+        rememberRefused:
+          type: boolean
+          enum: [true]
+          description: >-
+            server >= 7.116.0, ADDITIVE, present ONLY when true (never `false`): the "remember for this session" answer (live `allow_session` / durable `/decide` `remember:"session"`) will NOT be remembered on this card — the decision is accepted and applies once, the receipt's `rememberApplied` is `false` (existing key, not a new one), later cards of the same kind still ask. A shell reads this to decide whether to render the "allow for the session" choice instead of inferring it from `requiresRealApproval` / `mandated` / `governanceForced`. One bit for four reasons: the operator-governance gate / a human must approve each time / a mandated card / the answer would also grant more than this one call (new in 7.116.0: approving an engine `Skill` card activates the skill and frees its listed tools for the run, which the card cannot show, so it is not remembered). ABSENT = remember works on this card, OR an older server (<= 7.115.x never carries the key). Same bit on the live frame, the `approval_request` card (= `card_json`, incl. the reconnect replay), the `livePending` row, and the `/v1/approvals` `pending[]` row (+ their `/stream` frames); NOT on inbox rows.
         governanceForced: { type: boolean, enum: [true] }
         mandated: { type: boolean, enum: [true], description: 'server >= 7.101.0 (T4①): the mandated bit, same layer and shape as the two flags above (present only when true); the SAME value as `frame.mandated` (read once when the entry is minted).' }
         mandate:
@@ -12003,6 +12188,9 @@ components:
             Present ⇔ the request carried `remember:"session"` and the worker has an exemption store. `true` = the
             per-session per-tool exemption landed; `false` = the grant failed (logged) or the gate carried no
             rememberable toolName — the decision itself still stands.
+            🔴 server >= 7.116.0: ALWAYS `false` on a card that carries `rememberRefused: true` (an engine `Skill` card etc. — the
+            answer would also grant more than this one call): the decision is accepted and applies once, the exemption store gets
+            zero writes (existing key, not a new one). Ordinary cards keep `true` = landed.
 
     ApprovalExemption:
       type: object
@@ -12112,6 +12300,16 @@ components:
             toolName: { type: string }
             summary: { type: string }
             touchedPaths: {}
+            allowRuleShadowed:
+              type: array
+              items: { $ref: '#/components/schemas/AllowRuleShadow' }
+              description: >
+                server >= 7.117.0 (core 7.42.0): the DURABLE dual of `ToolApprovalFrame.allowRuleShadowed` — the allow-layer members that matched this call
+                and could not clear its ask (same shape and semantics; entries are secret-redacted again at the server's read boundary). Passed through whole
+                on `GET /v1/approvals` and `/v1/approvals/stream`. Absent != "you have no rule". 🔴 The old key `shadowedRule` (a string, server <= 7.116.x)
+                is RETIRED: the SQL backend rewrote its parked rows once at the 7.117.0 boot to `[{ member: "persisted", entries: [<old value>] }]`, but the
+                file backend's pre-upgrade parked rows and run results already on disk (`checkpointGate.riskDescriptor`) keep the old key verbatim
+                (text still redacted, no structured disclosure) — a consumer reading those must still tolerate the old string.
         # server 7.16.0 [3684]② — durable 队列行归因两键(与活卡 tool_approval 帧的同名键语义同族、判据不同源;
         # 两条腿对同一只 ask 的在场性可以不一致,两侧都只认在场、都禁把缺席读成否定)。
         ruleSuggestions:
@@ -12146,6 +12344,11 @@ components:
             🔴 DISPLAY / TRIAGE ONLY, and ABSENT MEANS THERE REALLY IS NO SUPPLY (rule lane unarmed, the
             command yields no rule, no rule could silence this ask, or an old row) — never "the projection
             dropped it", which is precisely the bug this key exists to close. Never `null`, never `[]`.
+        rememberRefused:
+          type: boolean
+          enum: [true]
+          description: >-
+            server >= 7.116.0, ADDITIVE, present ONLY when true (never `false`): the "remember for this session" answer (live `allow_session` / durable `/decide` `remember:"session"`) will NOT be remembered on this card — the decision is accepted and applies once, the receipt's `rememberApplied` is `false` (existing key, not a new one), later cards of the same kind still ask. A shell reads this to decide whether to render the "allow for the session" choice instead of inferring it from `requiresRealApproval` / `mandated` / `governanceForced`. One bit for four reasons: the operator-governance gate / a human must approve each time / a mandated card / the answer would also grant more than this one call (new in 7.116.0: approving an engine `Skill` card activates the skill and frees its listed tools for the run, which the card cannot show, so it is not remembered). ABSENT = remember works on this card, OR an older server (<= 7.115.x never carries the key). Same bit on the live frame, the `approval_request` card (= `card_json`, incl. the reconnect replay), the `livePending` row, and the `/v1/approvals` `pending[]` row (+ their `/stream` frames); NOT on inbox rows.
         governanceForced:
           type: boolean
           enum: [true]
@@ -13098,31 +13301,97 @@ components:
       type: object
       description: >
         2c session-sync `GET …/sync/manifest` payload (wrapped server-side as `{ manifest }`). The THIN cross-backend
-        snapshot: entry IDS (oldest-first, NOT payloads) + per-snapshot relPath→blobHash + policy + anchors + leaf.
-      # 封闭(census 批2 第三段,2026-07-30):铸造点 `session-sync.ts`(exportSessionManifest 尾部
-      # 字面量)恰是这 7 键,全部无条件(leafId 缺席位=null 不省略)。
+        snapshot: entry IDS (oldest-first, NOT payloads) + the file-history envelope + policy + anchors + leaf.
+        🔴 server >= 7.52 (S-15, design/381; re-read byte for byte against 7.116.0): the key `snapshots` (per-snapshot
+        relPath→blobHash, the retired E19 whole-tree snapshot epoch) is NO LONGER SENT — the server's `exportSessionManifest` mints
+        `{ sessionId, entryIds, entryCount, leafId, fileHistory, policy, anchors }` and `fileHistory` (core's versioned
+        `FileHistoryExport` envelope; `null` = no history / the source store cannot export) replaces it. <= 7.51 servers still send
+        `snapshots` and no `fileHistory`. The blob BYTES never ride the manifest: content-addressed, via the history blob faces
+        (`GET …/sync/history/blobs/{hash}` / `PUT …/sync/blobs/{hash}`; probe `capabilities.sessionSyncFileHistory` on BOTH ends).
+        The SDK's `manifest()` fills `snapshots: []` when the wire omits it.
+      # 封闭(census 批2 第三段,2026-07-30;16.2.0 按 7.116.0 发布字节重核):铸造点 `session-sync.ts`(exportSessionManifest 尾部
+      # 字面量)恰是 `{ sessionId, entryIds, entryCount, leafId, fileHistory, policy, anchors }` 7 键(≥7.52),无 `snapshots`;
+      # ≤7.51 老 server 发 `snapshots`、无 `fileHistory` ⇒ 两键都不进 required(支持底线 3.0.0)。
       additionalProperties: false
-      required: [sessionId, entryIds, entryCount, leafId, snapshots, policy, anchors]
+      required: [sessionId, entryIds, entryCount, leafId, policy, anchors]
       properties:
         sessionId: { type: string }
         entryIds: { type: array, items: { type: string }, description: Oldest-first, verbatim cross-backend. }
         entryCount: { type: integer, description: '= entryIds.length (the `/sync/entries` trailer count).' }
         leafId: { type: [string, 'null'] }
-        snapshots: { type: array, items: { $ref: '#/components/schemas/SyncSnapshot' } }
+        snapshots: { type: array, items: { $ref: '#/components/schemas/SyncSnapshot' }, description: 'server <= 7.51 ONLY (the retired E19 snapshot epoch); server >= 7.52 does not send it — see `fileHistory`.' }
+        fileHistory:
+          oneOf:
+            - { $ref: '#/components/schemas/FileHistoryExport' }
+            - { type: 'null' }
+          description: 'server >= 7.52: the per-edited-file rewind history envelope; `null` = no history / the source store cannot export; key ABSENT = a <= 7.51 server (that generation sends `snapshots`).'
         policy: { type: array, items: { $ref: '#/components/schemas/SessionRulesRecord' } }
         anchors: { type: array, items: { $ref: '#/components/schemas/SyncAnchor' } }
 
+    FileHistoryExport:
+      type: object
+      description: >
+        Mirror of core's `FileHistoryExport` (`formatVersion: "file-history/1"`) — the session-sync envelope for the per-edited-file rewind history graph
+        (server >= 7.52; replaces the retired E19 `SyncSnapshot`). Blob bytes are NOT inside: they are content-addressed and travel through the history blob faces.
+        The SDK reads only `tracked[].versions[].blobHash` (which blobs to move) and passes everything else through verbatim — the server's import door judges
+        `formatVersion` (refuse-not-coerce) and the closed `keyKind` / `keyFamily` sets, so they are plain strings here.
+      required: [formatVersion, tracked, boundaries]
+      properties:
+        formatVersion: { type: string, description: 'today only `file-history/1`; the server refuses any other value.' }
+        tracked:
+          type: array
+          items:
+            type: object
+            required: [relOrAbsPath, keyKind, keyFamily, baseAvailable, versions]
+            properties:
+              relOrAbsPath: { type: string }
+              keyKind: { type: string }
+              keyFamily: { type: string }
+              baseAvailable: { type: boolean }
+              versions:
+                type: array
+                items:
+                  type: object
+                  required: [version, blobHash, backupTime]
+                  properties:
+                    version: { type: integer }
+                    blobHash: { type: [string, 'null'], description: '`null` = the "did not exist" marker (no blob to move).' }
+                    mode: { type: integer }
+                    parentIdent: { type: string }
+                    backupTime: { type: string }
+        boundaries:
+          type: array
+          items:
+            type: object
+            required: [entryId, files]
+            properties:
+              entryId: { type: string }
+              files:
+                type: array
+                items:
+                  type: object
+                  required: [relOrAbsPath, version]
+                  properties:
+                    relOrAbsPath: { type: string }
+                    version: { type: integer }
+
     SessionBundle:
       type: object
       description: >
         The portable state of ONE session, ready to replay into another backend. Blobs are NOT inlined (each
         snapshot carries only its `manifest`; the bytes stream through the content-addressed blob routes). The SDK
-        assembles this from a manifest + the streamed entries for a PUSH.
+        assembles this from a manifest + the streamed entries for a PUSH. server >= 7.52: the file history rides `fileHistory`
+        (the `FileHistoryExport` envelope) instead of `snapshots`.
       required: [sessionId, entries, snapshots, policy, anchors]
       properties:
         sessionId: { type: string }
         entries: { type: array, items: { $ref: '#/components/schemas/SyncEntry' } }
         snapshots: { type: array, items: { $ref: '#/components/schemas/SyncSnapshot' } }
+        fileHistory:
+          oneOf:
+            - { $ref: '#/components/schemas/FileHistoryExport' }
+            - { type: 'null' }
+          description: 'server >= 7.52 file-history envelope (same as `SessionManifest.fileHistory`); key absent = the source is a <= 7.51 server.'
         policy: { type: array, items: { $ref: '#/components/schemas/SessionRulesRecord' } }
         anchors: { type: array, items: { $ref: '#/components/schemas/SyncAnchor' } }
 
@@ -13409,6 +13678,8 @@ components:
             `not_found.resource` / `request.unprocessable` / `capability.unavailable` …). ALWAYS PRESENT on server >= 7.104.0
             (S-607); before that it was absent when the original refusal carried no code. SDK:
             `ResumeBlockedByPolicyError.blockedBy` (`undefined` when the key is absent or not a string — never defaulted).
+            server >= 7.117.0 adds a third fold source: a stored skill `disallowedTools` entry the engine now reads as nothing (the submit leg's 400 `request.field_invalid` sentence)
+            ⇒ `blockedBy: "request.field_invalid"`, refused before the claim; the terminal-run steer leg answers it before minting the wake card.
 
     ResumeLegConflictError:
       description: >
@@ -13985,10 +14256,17 @@ components:
         unattended leg run under `UNATTENDED_PERMISSION_MODE=dontAsk`).
     AskClass:
       type: string
-      enum: [content_question, hook, ancestor, unverifiable_delete, transcript_write, org_rule, governance_unavailable, rule_unreadable, ask_rule, denial_limit_fallback, operator_forced, shell_floor, write_protection_unresolved, probe, write_protection, tool_marks_mcp, tool_marks_a2a, policy_rra, artifact_shared_read, mode, unstated, ordinary]
-      description: >
-        core `ASK_CLASSES` (twenty-two words as of core 7.40.0 — 7.34.0 minted twenty; `shell_floor` joined in 7.39.0 #1260 and rides
-        server >= 7.113.0; `unstated` joined in 7.40.0 and rides server >= 7.115.0) — which CLASS an ask falls in (the columns of the mode × class arbitration table).
+      enum: [content_question, hook, ancestor, unverifiable_delete, transcript_write, org_rule, governance_unavailable, rule_unreadable, ask_rule, denial_limit_fallback, requires_user_interaction, operator_forced, shell_floor, write_protection_unresolved, probe, write_protection, tool_marks_mcp, tool_marks_a2a, policy_rra, artifact_shared_read, mode, unstated, ordinary]
+      description: >
+        core `ASK_CLASSES` (twenty-two words as of core 7.40.0, twenty-three as of core 7.41.0 — 7.34.0 minted twenty; `shell_floor` joined in 7.39.0 #1260 and rides
+        server >= 7.113.0; `unstated` joined in 7.40.0 and rides server >= 7.115.0; `requires_user_interaction` joined in 7.41.0 and rides
+        server >= 7.116.0) — which CLASS an ask falls in (the columns of the mode × class arbitration table).
+        `requires_user_interaction` = the MCP server declared, in the tool's advertisement, `_meta["anthropic/requiresUserInteraction"] === true`
+        (only the boolean `true`): EVERY call of that tool asks the human, in EVERY mode including `bypassPermissions` (it is not one of the ten
+        RELEASABLE classes), and only the human's answer clears it — `settings.permissions.allow`, operator `APPROVAL_GRANT`, a skill's tool list +
+        `userInvokedSkills` and a hook's explicit allow all fail to; with no approval seat the call is refused (the server sees nothing). The frame
+        also carries `requiresRealApproval: true` / `mandated: true` (`origin: "safety_tighten"`). A client that renders cards by exhaustive `askClass`
+        adds this one word.
         `unstated` = NOBODY STATED IT: in an ask-class mode (`default` / `acceptEdits` / `auto` / `plan`) a call to an MCP server tool or A2A skill
         (a seat that states no permission of its own) reached the end of the fold with no layer — rule / hook / approver / classifier / mode
         release — having said "this time is fine"; the engine raises a card with `askClass: "unstated"` (sentence `The agent requested permission to use <tool>,
@@ -15589,6 +15867,11 @@ components:
         args:
           description: '"tool_approval" only: the call''s args, secret-redacted. UNTRUSTED for display. Absent (with argsOmitted) when over the byte cap or unserializable.'
         argsOmitted: { type: boolean, enum: [true] }
+        rememberRefused:
+          type: boolean
+          enum: [true]
+          description: >-
+            server >= 7.116.0, ADDITIVE, present ONLY when true (never `false`): the "remember for this session" answer (live `allow_session` / durable `/decide` `remember:"session"`) will NOT be remembered on this card — the decision is accepted and applies once, the receipt's `rememberApplied` is `false` (existing key, not a new one), later cards of the same kind still ask. A shell reads this to decide whether to render the "allow for the session" choice instead of inferring it from `requiresRealApproval` / `mandated` / `governanceForced`. One bit for four reasons: the operator-governance gate / a human must approve each time / a mandated card / the answer would also grant more than this one call (new in 7.116.0: approving an engine `Skill` card activates the skill and frees its listed tools for the run, which the card cannot show, so it is not remembered). ABSENT = remember works on this card, OR an older server (<= 7.115.x never carries the key). Same bit on the live frame, the `approval_request` card (= `card_json`, incl. the reconnect replay), the `livePending` row, and the `/v1/approvals` `pending[]` row (+ their `/stream` frames); NOT on inbox rows.
         governanceForced:
           type: boolean
           enum: [true]
@@ -15674,29 +15957,45 @@ components:
             requiresRealApproval / shadowed / hook-produced / inherited-unresolved / ancestor-resolved /
             anonymous asks. Absence reads as "THIS CARD has no such option", never as "this deployment has no
             rule lane" (that is `capabilities.permissionRules`) and never as "your rule broke" (that is
-            `persistedRuleShadowed`).
+            `allowRuleShadowed`; `persistedRuleShadowed` on a server <= 7.116.x).
 
             ⚠️ REDEMPTION SCOPE is the live respond leg keyed by this frame's `approvalId` only; a replayed
             offer on another replica is not a promise that it is still redeemable.
         persistedRuleShadowed:
           type: string
+          deprecated: true
           description: >
-            server >= 7.13.0 (core 5.25.0 #144), ADDITIVE, "tool_approval" only: this ask MATCHED one of the
+            🔴 RETIRED by server 7.117.0 (core 7.42.0) — replaced by `allowRuleShadowed`, no alias. A server >= 7.117.0 never mints this key
+            (its strict card schema even refuses a stored card carrying it); only a server <= 7.116.x still does, and the SDK keeps the declaration
+            for those servers (the supported floor is far below 7.117.0). Slated for deletion in the next major.
+
+            For those older servers (server >= 7.13.0 / core 5.25.0 #144, ADDITIVE, "tool_approval" only): this ask MATCHED one of the
             caller's persisted allow rules and that rule COULD NOT silence it. The value is the shadowed rule's
             VERBATIM text (secret-redacted + length-bounded). UNTRUSTED for display, same treatment as `message`.
-
-            It documents a BEHAVIOUR NARROWING ("Allow rules silence the CLASSIFIER's questions, never a MANDATED
-            one"): under MANUAL_MODE_SHELL_GATE=always, for tools carrying an egress/irreversible mark, and under
-            the governance gates, asks a rule used to silence now REAPPEAR. Render an explanatory line ("your rule
-            is still there — this call must be confirmed each time"); without it the only conclusion a user can
-            draw is "my rule broke", while the rule sits fine in the store.
-
-            🔴 ABSENT != "you have no rule": present only when a rule matched AND could not clear the ask. Most
-            asks have no match at all, and matched-and-cleared ones never become asks (they were silenced — no
-            card exists). 🔴 Deliberately SEPARATE from `governanceForced` and not derivable from it: that key
-            answers "who imposed the gate", this one answers "what happened to YOUR rule"; governance is only one
-            of three un-silenceable sources (doctrine `always` and a tool's own mark carry no governance badge).
-            The durable dual is `gate.riskDescriptor.shadowedRule` on the parked row.
+            🔴 ABSENT != "you have no rule": present only when a rule matched AND could not clear the ask. 🔴 Deliberately SEPARATE
+            from `governanceForced` and not derivable from it: that key answers "who imposed the gate", this one answers "what
+            happened to YOUR rule". The durable dual on those servers is `gate.riskDescriptor.shadowedRule` on the parked row.
+        allowRuleShadowed:
+          type: array
+          items: { $ref: '#/components/schemas/AllowRuleShadow' }
+          description: >
+            server >= 7.117.0 (core 7.42.0), ADDITIVE, "tool_approval" only — BREAKING RENAME, replacing the retired string `persistedRuleShadowed`
+            (no alias): the allow-layer members that MATCHED this call and could NOT clear this ask, one `{ member, entries, omitted? }` record per
+            matching member (see AllowRuleShadow). `member` is one of `hook` / `deployment` / `persisted` / `skill` / `request`; `entries` are the
+            entries that member matched, as their source spells them (UNTRUSTED for display like `message`, secret-redacted, <= 512 chars each,
+            <= 32 listed; a `hook` record's `entries` is always the empty list); `omitted` counts the entries not listed.
+
+            The explaining sentence ("... matches this call but does not clear the ask — <reason>") is IN `message` (the engine writes it where it builds
+            the card); this key is the structured twin of the same fact. Render a line from it ("your rule matched, but this call must be confirmed each
+            time"): without it the only conclusion a user can draw is "my rule broke".
+
+            🔴 ABSENT != "you have no rule": present only when a member matched AND could not clear the ask; a match that cleared never becomes an ask.
+            🔴 `member: "hook"` does not say whose hook (a deployment PreToolUse hook and, on the single-user lane, the request's own `settings.hooks`
+            share one member). 🔴 Deliberately SEPARATE from `governanceForced` (that one: "who imposed the gate"; this one: "what happened to YOUR
+            rule"). What the allow layer can NOT clear: any layer's deny / ask rule, operator `APPROVAL_REQUIRE` / `APPROVAL_NEVER_AUTO` /
+            `MANUAL_MODE_SHELL_GATE=always`, write protection, sensitive-path writes, governance, a hook's ask, plan-mode asks. The durable dual is
+            `gate.riskDescriptor.allowRuleShadowed` on the parked row (PendingCheckpoint.riskDescriptor). Rolling-upgrade caveat: a card stored by a
+            <= 7.116.x replica (`card_json` carrying `persistedRuleShadowed`) cannot be read by a >= 7.117.0 replica — the replay skips it.
         probeCause:
           type: object
           description: >
@@ -16053,6 +16352,11 @@ components:
         argsOmitted: { type: boolean, enum: [true], description: 'Present (true) only when args exceeded the byte cap. Never false.' }
         toolCallId: { type: string, description: 'The engine''s tool-call id (the `call_…` on the assistant message''s tool_use block) — same domain as ToolApprovalFrame.toolCallId.' }
         risk: { $ref: '#/components/schemas/ApprovalRiskAxes' }
+        rememberRefused:
+          type: boolean
+          enum: [true]
+          description: >-
+            server >= 7.116.0, ADDITIVE, present ONLY when true (never `false`): the "remember for this session" answer (live `allow_session` / durable `/decide` `remember:"session"`) will NOT be remembered on this card — the decision is accepted and applies once, the receipt's `rememberApplied` is `false` (existing key, not a new one), later cards of the same kind still ask. A shell reads this to decide whether to render the "allow for the session" choice instead of inferring it from `requiresRealApproval` / `mandated` / `governanceForced`. One bit for four reasons: the operator-governance gate / a human must approve each time / a mandated card / the answer would also grant more than this one call (new in 7.116.0: approving an engine `Skill` card activates the skill and frees its listed tools for the run, which the card cannot show, so it is not remembered). ABSENT = remember works on this card, OR an older server (<= 7.115.x never carries the key). Same bit on the live frame, the `approval_request` card (= `card_json`, incl. the reconnect replay), the `livePending` row, and the `/v1/approvals` `pending[]` row (+ their `/stream` frames); NOT on inbox rows.
         governanceForced:
           type: boolean
           enum: [true]
@@ -16084,12 +16388,21 @@ components:
             promise and the per-leg index rules are stated verbatim on ToolApprovalFrame.ruleOffers.
         persistedRuleShadowed:
           type: string
+          deprecated: true
+          description: >
+            🔴 RETIRED by server 7.117.0 (core 7.42.0) — replaced by `allowRuleShadowed`, no alias (a server >= 7.117.0 never mints it; the strict card
+            schema refuses a stored card carrying it). Only a server <= 7.116.x still does; slated for deletion in the next major. For those servers
+            (ADDITIVE, server >= 7.13.0 / core 5.25.0 #144): the VERBATIM text of the persisted rule this ask matched but which could not silence it
+            (secret-redacted + length-bounded). UNTRUSTED for display. Semantics, the ABSENT != "you have no rule" clause and the deliberate separation
+            from `governanceForced` are stated verbatim on ToolApprovalFrame.persistedRuleShadowed.
+        allowRuleShadowed:
+          type: array
+          items: { $ref: '#/components/schemas/AllowRuleShadow' }
           description: >
-            ADDITIVE (server >= 7.13.0 / core 5.25.0 #144): the VERBATIM text of the persisted rule this ask
-            matched but which could not silence it (secret-redacted + length-bounded). UNTRUSTED for display.
-            Semantics, the ABSENT != "you have no rule" clause and the deliberate separation from
-            `governanceForced` are stated verbatim on ToolApprovalFrame.persistedRuleShadowed — the live frame,
-            the stored `card_json` and the replayed frame carry the SAME material.
+            ADDITIVE (server >= 7.117.0 / core 7.42.0, BREAKING RENAME of the retired `persistedRuleShadowed`): the allow-layer members that matched this
+            call and could not clear this ask. Semantics, the five members, the always-empty `hook` entries, the explaining sentence living in `message`,
+            the ABSENT != "you have no rule" clause and the separation from `governanceForced` are stated verbatim on ToolApprovalFrame.allowRuleShadowed
+            — the live frame, the stored `card_json`, the replayed frame and the `approval_request` card carry the SAME material.
         fromSubagent: { type: boolean, enum: [true], description: 'Present ⇔ the ask comes from a DELEGATED child — the explicit discriminator (a worker cannot forge it).' }
         sourceTaskId: { type: string, description: 'The child''s core session id — row-join value + fallback discriminator.' }
         sourceAgentName: { type: string, description: 'The child agent''s display name, redacted. UNTRUSTED.' }
@@ -16214,6 +16527,37 @@ components:
         `.strict()`). The eleven known words are exported at runtime as the SDK's `ASK_ORIGINS` (core 7.32.1
         `ASK_ORIGINS`, verbatim and in order) — known words, NOT an enforcement table.
 
+    AllowRuleMember:
+      type: string
+      enum: [hook, deployment, persisted, skill, request]
+      description: >
+        The closed five-word vocabulary of `AllowRuleShadow.member` (server >= 7.117.0 / core 7.42.0 `ALLOW_RULE_MEMBERS`, verbatim and in the order the engine reads the members). The SDK exports
+        it at runtime as `ALLOW_RULE_MEMBERS`. Owner = core; read it as an open string with a default arm (core may add a member and the server follows).
+
+    AllowRuleShadow:
+      type: object
+      additionalProperties: false
+      required: [member, entries]
+      description: >
+        One allow-layer DISCLOSURE record (`ToolApprovalFrame.allowRuleShadowed` / `ApprovalCard.allowRuleShadowed` / the durable
+        `PendingCheckpoint.riskDescriptor.allowRuleShadowed`; server >= 7.117.0 / core 7.42.0 `AllowRuleShadow`): one member of the allow layer that
+        MATCHED the call and could NOT clear its ask. At most one record per member, at most five per ask. The vocabulary owner is core; the server
+        drops the whole key on a member outside the five words, so a >= 7.117.0 server only ever sends these five — still read `member` as an open
+        string with a default arm (core may add members and the server follows).
+      properties:
+        member:
+          $ref: '#/components/schemas/AllowRuleMember'
+          description: >
+            Which allow-layer member matched, in the order the engine reads them: `hook` = a PreToolUse hook's explicit `allow` (a deployment hook or,
+            on the single-user lane, the request's own `settings.hooks` — the key cannot say which) · `deployment` = the operator's `APPROVAL_GRANT` ·
+            `persisted` = a person's stored allow rules · `skill` = an activated skill's `allowedTools` · `request` = the request's `settings.permissions.allow`.
+        entries:
+          type: array
+          maxItems: 32
+          items: { type: string, maxLength: 512 }
+          description: 'The entries that member matched, as their source spells them (UNTRUSTED for display, secret-redacted, <= 512 chars each, <= 32 listed). Always the empty list for `hook` — its word is about the call, not about an entry.'
+        omitted: { type: integer, minimum: 1, description: 'How many matched entries were not listed (beyond the cap). Absent = none omitted.' }
+
     RuleOffersAbsence:
       type: string
       enum: [mandated, shadowed, lane_cannot_speak]
@@ -16222,7 +16566,7 @@ components:
         `ApprovalCard.ruleOffersAbsence`; server >= 7.55.0 / core #490 fix ②, S-15). The engine names which
         door is shut: `mandated` = this ask must be confirmed every time (🔴 this arm must NOT point the user
         at writing a rule — a rule would not silence it, and saying so sends them into a loop); `shadowed` = a
-        rule matched but could not clear it (the machine-readable twin of `persistedRuleShadowed`);
+        an allow-layer member matched but could not clear it (the machine-readable twin of `allowRuleShadowed`; `persistedRuleShadowed` on a server <= 7.116.x);
         `lane_cannot_speak` = the engine could mint no coverable form for this command.
 
         Engine-side MUTUALLY EXCLUSIVE with `ruleOffers`. 🔴 ABSENCE IS NOT AN ASSERTION — it covers both
@@ -16707,16 +17051,27 @@ components:
             sessionId: { type: string, description: 'gone.ask_parked ONLY — gate reconciliation coordinate 1; drive the existing durable-gate flow with it.' }
             gateBoundCallId: { type: string, description: 'gone.ask_parked ONLY — gate reconciliation coordinate 2.' }
             gateBoundInputHash: { type: string, description: 'gone.ask_parked ONLY — gate reconciliation coordinate 3.' }
-            state: { type: string, enum: [DENIED, VOID], description: 'gone.ask ONLY — the terminal state.' }
+            state: { type: string, enum: [DENIED, VOID], description: 'gone.ask ONLY — the terminal state. server >= 7.116.0 also mints `VOID` for "the process that held the ask is gone" (local lane restart; see `deniedReason`).' }
             deniedReason:
               type: string
               description: >
                 gone.ask ONLY — attribution, GROUPED BY `state`. `DENIED` carries the single-member deny
                 vocabulary `routing_failure_fail_closed`; `VOID` carries the separate (and growing) void
-                vocabulary, e.g. `adhoc_leg_no_durable_domain`. The two vocabularies never mix.
+                vocabulary, seven words today: `run_cancelled`, `batch_aborted`, `batch_bound_elsewhere`,
+                `adhoc_leg_no_durable_domain`, `orphan_ttl_exceeded` and — new in server 7.116.0 (local lane) —
+                `crashed_before_park` (the process that held the ask crashed / was killed) and `shutdown_before_park`
+                (an orderly shutdown could not settle the card inside its grace window; a fault shape, hard to build black-box).
+                The last two are the SAME word as `GET /v1/approvals` `crashConverged[].cause`; the other six were already on the wire
+                (7.3.0 / 7.55.0 / 7.108.0) and are only registered in the server's self-minted word table by 7.116.0.
+                ABSENT = the row carries no attribution. The two vocabularies never mix; the VOID one is open (read an unknown word as "the ask ended without
+                a human decision, reason unknown").
       description: >
         410 body. THE TWO LEGS ARE DISJOINT: `gone.ask_parked` carries exactly the three gate coordinates,
-        `gone.ask` carries exactly `{state, deniedReason?}`. Routing off field presence across the legs is how a
+        `gone.ask` carries exactly `{state, deniedReason?}` (no `consumerState`).
+        🔴 server >= 7.116.0 (local lane, `DB_BACKEND=local`): after a crash / kill and a restart on the same data root, answering the PREVIOUS
+        life's still-open card is now `410 gone.ask` with `state: "VOID"` and `deniedReason` `crashed_before_park` / `shutdown_before_park` —
+        <= 7.115.x answered `200` + `consumerState: "absent"` (the run had long been reclaimed; nothing executed). An ask that was already decided
+        (decided, then the process died mid-execution) is unchanged: `409 conflict.ask_decided`. SQL backends are unchanged in 7.116.0. Routing off field presence across the legs is how a
         consumer ends up driving the wrong durable gate.
         🔴 The checkpoint token is NEVER here: the resume credential is not externally disclosed. Use
         `sessionId`.
@@ -18495,9 +18850,15 @@ components:
       description: >-
         [2400] TR-4 — per-message queue priority on POST /v1/runs/{taskId}/steer. ACCEPTED + ENUM-VALIDATED
         FAIL-LOUD (`routes/runs.ts`; anything else is 400 `request.field_invalid`) and echoed back on the
-        receipt, but ADVISORY today: core's steer is a single-slot last-writer-wins with no per-message priority
-        or addressable drop, so a faithful priority queue (and DELETE /v1/runs/{taskId}/queue/{messageId}) waits
-        on a core seam.
+        receipt. WHETHER IT TAKES EFFECT is the server's call — read `Capabilities.fleet.steerPriority` first:
+        `"engine"` (server >=7.116.0) = the tier is handed to the engine on every delivery leg (`now` cuts the in-flight turn
+        IMMEDIATELY — the running tool receives an abort, an approval card pending on this replica is revoked, one `engine_notice`
+        `task.turn_interrupted` frame is the evidence; `next` ≡ no `priority`; `later` is delivered after the turn the run would have stopped on; parked
+        legs store the tier and deliver on the resume's / wake's first turn; replaying the same `Idempotency-Key` + text with a different effective
+        tier is 409 `steering.duplicate_input_id`); `"advisory"` (server <=7.115.x) = accepted and echoed but NOT applied —
+        core's steer was a single-slot last-writer-wins with no per-message priority or addressable drop, so a
+        faithful priority queue (and DELETE /v1/runs/{taskId}/queue/{messageId}) waited on a core seam. An absent
+        or unknown capability value means "do not assume it is applied".
 
     SteerReceipt:
       type: object
@@ -18774,6 +19135,8 @@ components:
             server 1.239 ([1392]②): on allow_session, an honest echo of whether the grant was REALLY
             recorded (true = landed in the bridge store; false = no sessionId, could not record — do not
             render "session-wide allowed"). Omitted on non-allow_session decisions and on older servers.
+            🔴 server >= 7.116.0: ALWAYS `false` on a card that carries `rememberRefused: true` (an engine `Skill` card etc.) — the decision
+            applies once and nothing is remembered (existing key, not a new one).
         updatedInputForwarded:
           type: boolean
           description: >