@sema-agent/sdk 16.3.0 → 17.1.0

package/openapi.yaml

@@ -869,7 +869,9 @@ paths:
             evicts an already-accepted instruction to make room. Opposite handling from not_running: the
             text is still valid — let the run resume (which drains the queue) or reduce concurrent steers,
             then resend.
-            errorCode "steering.duplicate_input_id" (server >=7.3.0 / core 5.14.0) — the Idempotency-Key you
+            errorCode "steering.duplicate_input_id" (server >=7.3.0 / core 5.14.0; server >= 7.118.0 adds `detail.differs`, a
+            non-empty subset of SteerReplayFacet — contains `text` ⇒ fresh key; otherwise the same instruction, replay with the
+            original values and do NOT change the key) — the Idempotency-Key you
             sent is already parked with DIFFERENT steering content (same key + same content is an idempotent
             no-op and 202s). The engine refuses rather than silently picking a side. Reissue with a fresh
             key — this is a new instruction, not a retry.
@@ -1029,7 +1031,7 @@ paths:
             Use POST /v1/runs/{taskId}/cancel for a run-level stop.
             errorCode "steering.not_running" (reused verbatim) — terminal / not accepting, or the stream
             settled in the race window ("run just finished on this replica — no in-flight turn to interrupt").
-            errorCode "steering.duplicate_input_id" — this Idempotency-Key was already accepted with DIFFERENT
+            errorCode "steering.duplicate_input_id" (server >= 7.118.0: read `detail.differs` first, see SteerReplayFacet) — this Idempotency-Key was already accepted with DIFFERENT
             content or at a DIFFERENT tier (core's replay identity includes the normalized tier: the same key
             that once went through the steer door (default tier) then hits this door (now) is refused —
             "idempotent success without the cut" would be a dispositive lie). Reissue with a fresh key.
@@ -2533,6 +2535,16 @@ paths:
         '409': { $ref: '#/components/responses/Conflict' }
         '422': { $ref: '#/components/responses/UnprocessableEntity' }
         '501': { $ref: '#/components/responses/NotImplemented' }
+        '503':
+          description: >-
+            server >= 7.118.0 — `state.mcp_reconnect_unsettled`: the time this endpoint waits for the re-dial to settle ran out (the same
+            constant as the `/mcp` panel, 10 s). Read it as "this endpoint did not wait for a result", NOT "failed": the re-dial is NOT
+            cancelled and still settles (success writes the roster onto this run, failure removes it). The body is `error` + `errorCode`
+            only (no `outcome`) and carries NO `Retry-After`; this is a close-then-dial transaction — confirm the server state before
+            re-sending, and do not use a re-send as a probe. SDK → ServiceStateError (never auto-retried: a non-submit POST).
+          content:
+            application/json:
+              schema: { $ref: '#/components/schemas/ErrorResponse' }
 
   /v1/sessions/{sessionId}/background:
     parameters:
@@ -3322,8 +3334,11 @@ paths:
             `approval_binding_mismatch` (`errorCode`, `field`: boundCallId|boundInputHash|answer — the third
             member since core 5.7.0/RB-459: the content-ask `answer` payload was refused) — your binding does
             NOT match the current pending action (TOCTOU/swap). The SDK splits these by `errorCode` into
-            ConflictError vs ApprovalBindingMismatchError. binding_mismatch = SAFETY signal: refetch + re-present
-            to the human, NEVER auto-retry. (S-57, server >= 7.54.0: the `field:"boundCallId"` shape is
+            ConflictError vs ApprovalBindingMismatchError (the engine's own code for the same refusal, `checkpoint.invalid_outcome`,
+            maps to that class too). binding_mismatch = SAFETY signal: refetch + re-present
+            to the human, NEVER auto-retry. A `decidedBy: "policy"` allow on a person-required card is the OTHER `invalid_outcome`
+            shape — the non-binding seat `hostDecision` — and answers `resume_outcome_invalid` (`field: "hostDecision"`, card pending;
+            see ApprovalDecidedBy). (S-57, server >= 7.54.0: the `field:"boundCallId"` shape is
             intercepted in steady state by the `approval_stale` second trigger source below — the server
             compares the echoed boundCallId against the current pending pre-CAS and answers 409
             `approval_stale` + `currentPending`; this code's boundCallId arm covers only the remaining race
@@ -3351,7 +3366,8 @@ paths:
             decide either resumes the parked host or starts that new run (both land on the byte-identical
             acceptance shape) — a host session already busy with another run instead answers the ordinary 409
             `conflict.session_active_run`.
-            EIGHTH group (server >= 7.75.0 / S-252, same PARKED WORKFLOW-CHILD lane): `decide.workflow_parks_unreadable`
+            EIGHTH group (server >= 7.75.0 / S-252, same PARKED WORKFLOW-CHILD lane; the 7.75.0–7.117.x reading — server >= 7.118.0
+            narrows the triggers, see the note after this group): `decide.workflow_parks_unreadable`
             — the workflow run's record carries no readable `parks[]` list (the ENGINE's own park-ownership
             ledger, and the single source this lane joins the caller's checkpoint against). A record written by
             an engine older than 7.17.0 does not carry the key at all, or one entry is damaged and the whole list
@@ -3375,6 +3391,15 @@ paths:
             there is no mapper branch, class, or type-union member to delete or keep for it — unlike
             `decide.workflow_host_not_parked` above, an OPEN decide.* code this SDK never gave a name to degrades
             through the base `DecideError` exactly as it always did, on any server version.
+            🔴 server >= 7.118.0 (core 7.44.0 #1319): routing and redemption read ONE source — the holder seat `parkedBy` the engine writes on
+            a `parks[]` entry (the record naming the card at the highest generation, exactly one ⇒ it takes the decision). The EIGHTH group
+            widens and now has two causes under one code (the body carries no cause word; the sentence differs): an entry written by an older
+            engine (cards still parked at the upgrade) ⇒ resume `runId` and decide again; a record that cannot be read (a malformed entry,
+            or `parks` present but not a list) ⇒ resuming does NOT clear it — an operator must repair that record; the body may add
+            `readableHolderRunId` (a clue). A record with NO `parks` key holds nothing: a card only it names answers 409
+            `conflict.resume_context_unavailable` (no `runId`). NINTH group: `decide.workflow_park_forked` (409, body `runIds`) — the same
+            run was resumed more than once and the copies all hold this card; nothing delivered, the card stays PENDING; resume one of
+            `runIds` and decide again (SDK → `DecideWorkflowParkForkedError`).
             SIXTH group (A-075.10, TIME-BASED retry-later pair): `resume.usage_window_exhausted` (#449 G1,
             core 5.60.1 — the deployment governance window on this run's ledger key is full; NOTHING was
             consumed or unpinned, the SAME token with the SAME decision redeems once the window slides) and
@@ -4232,32 +4257,14 @@ paths:
                     substitution), the command bytes were unreadable, or this ask belongs to one of the seven
                     families that never get offers — so do NOT diagnose the deployment's rule lane from one
                     frame or from that one refusal.
-                settledBy:
-                  type: string
-                  enum: [policy]
+                decidedBy:
+                  allOf: [{ $ref: '#/components/schemas/ApprovalDecidedBy' }]
                   description: >-
-                    server #1016 (>= 7.93.3, core 7.26.2), ADDITIVE — the SETTLEMENT SOURCE of this answer.
-                    `"policy"` is a MACHINE REFUSAL, NEVER THE USER'S WORDS: the deployment's own policy answered
-                    this card, not a person. ABSENT = today's shape (read as a person's answer).
-
-                    Same word, same source and the same three-question rationale as the durable leg's key
-                    (`POST /v1/approvals/{sessionId}/decide`, ApprovalDecision.settledBy) — see that schema for
-                    the full account. `decision:"deny"` ONLY: an allow-family decision carrying this key is a
-                    contradiction, refused BEFORE THE DECISION (400 `request.body_shape`, the same sentence as
-                    the durable leg) rather than after — the engine's refusal cannot travel back up this HTTP
-                    leg, and by then this door's own side effects (the session allow-all grant, a persisted
-                    rule, a DECIDED row that replays as a plain approval) have already landed. Because the
-                    refusal precedes the decision, the ask is NOT settled: the card is still open and the same
-                    `approvalId` can be answered again. The PARKED late-acceptance arm reads the same key.
-
-                    SHAPE, not word: a non-string is a 400. A word core does NOT know travels UNTOUCHED — this
-                    door still answers 200 (its 200 only ever meant "your answer was delivered") and the ENGINE
-                    refuses it fail-closed, settling as `approver_contract`, NEVER as `policy_refused`: a
-                    misspelled word must not be rendered as "the deployment's policy refused".
-
-                    No capability bit: an older server ignores unknown keys and answers 200, so the refusal is
-                    still read as a person's there. Judge by server version, or read back whether
-                    `tool_end.gate.settlement.kind` ever shows `policy_refused`.
+                    server >= 7.118.0 — WHO made this decision (one key read the same way by all three decision doors; see
+                    ApprovalDecidedBy). ABSENT = `person`. This door's own answers: a `policy` allow on a person-required card
+                    and a word outside the closed set are both 400 `request.body_shape`, refused BEFORE the decision (the card is
+                    still open; answer it again with the same `approvalId`). 🔴 An older server (no `approvalDecidedBy`
+                    capability bit) DROPS this key silently and answers 200 — probe the bit first.
                 note:
                   type: string
                   maxLength: 2048
@@ -4349,7 +4356,7 @@ paths:
             application/json:
               schema: { $ref: '#/components/schemas/AskDecisionAck' }
         '400':
-          description: 'Malformed body — `request.invalid_json` (unparseable) or `request.body_shape` (schema reject, e.g. an `actor` carrying anything but `label`, or — on a server < 7.104.0 — a `settledBy` key). Server >= 7.104.0 (S-843) adds the `settledBy` refusals shared with the durable `/decide` leg: `request.field_conflict` (with a non-deny decision), `settled_by_not_in_proof` (direct-door worker), `request.field_invalid` (non-string, or outside the 1..16-character column) — see AskDecisionBody.settledBy.'
+          description: 'Malformed body — `request.invalid_json` (unparseable) or `request.body_shape` (schema reject, e.g. an `actor` carrying anything but `label`, or — on a server < 7.104.0 — a `settledBy` key). Server >= 7.118.0 reads `decidedBy` (see AskDecisionBody.decidedBy): `request.field_conflict` (a `policy` allow on a person-required card), `decided_by_not_in_proof` (direct-door worker), `request.field_invalid` (outside the closed set); the retired `settledBy` key is a `request.body_shape`.'
           content:
             application/json:
               schema: { $ref: '#/components/schemas/ErrorResponse' }
@@ -6591,6 +6598,13 @@ components:
         declared exceeds the roster bound (name 128, contract id / revision 64, `modelGate` 64); the caller cannot route
         around it and a verbatim retry never changes it (DETERMINISTIC — the SDK does not auto-retry these codes; they land
         on ServiceStateError via the 503 tail, with no wait hint); only the deployment fixing its declaration helps.
+        Server >= 7.119.0 adds `state.scenario_assignment_unknown` to this slot — the center's scenario assignment for the principal names a
+        scenario this deployment does not have; refused before any side effect or billing, zero run, body `detail: { scenario, source }`, NO
+        `Retry-After` (resending before the assignment is re-pointed — or the scenario added back to the deployment — is pointless; then retry
+        verbatim, the serving replica reads the new assignment after its own cache window, one minute by default). The caller did nothing wrong:
+        an explicit unknown `scenario` in the body is still 400 `scenario_unknown`. DETERMINISTIC for the SDK's retry arm (see
+        `ErrorResponse.errorCode`); lands on ServiceStateError. On a resume leg the same refusal folds into 409 `resume_blocked_by_policy`
+        (`blockedBy: state.scenario_assignment_unknown`).
         Which of them carry a wait hint is stated ONCE, under `headers.Retry-After` below (kept in one place so
         the two statements cannot drift apart).
       headers:
@@ -6849,16 +6863,6 @@ components:
               name: { type: string }
               description: { type: string }
               content: { type: string }
-              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:
@@ -7121,7 +7125,7 @@ components:
             key on every submit of that session). ⚠️ A server < 7.104.0 answers 400 `request.body_shape` (unknown key).
         permissionMode:
           type: string
-          enum: [default, plan, acceptEdits, bypassPermissions, auto]
+          enum: [default, plan, acceptEdits, bypassPermissions, auto, dontAsk]
           description: >
             🔴 K-32 — server >= 7.106.0 (S-877 / core 7.34.0 design/1111 "one permission mode"), READ THIS FIRST; the long text
             below describes <= 7.105.0. The effective mode passes through VERBATIM to the engine (`TaskSpec.permissionMode`); the
@@ -7134,13 +7138,16 @@ components:
             `config.permission_mode_unavailable`. `bypassPermissions` RELEASES the ten releasable ask classes (server >= 7.115.0: the tenth is `unstated`, a server-tool call nobody stated)
             and DISCLOSES each (`tool_end.gate.disposition.released` + one `engine_notice` `permission.ask_released_by_mode` per (mode, class) per run);
             immune classes (deployment-authored, ask / org rules, hooks, ancestors, questions …) still ask; a write whose protection
-            cannot be judged is refused (`deniedBy: mode`). Request vocabulary: FIVE words — `dontAsk` on a fresh submit is 400
-            `request.field_invalid` (S-902). The three sentences below — "omitting both carriers means no mode-derived gate", "`auto`
+            cannot be judged is refused (`deniedBy: mode`). Request vocabulary: SIX words (server >= 7.119.0) — `dontAsk`, the engine's
+            "auto-refuse" mode, is accepted and passes through verbatim: the ENGINE refuses the calls that would ask (no card, no parked row,
+            `tool_end.gate.disposition = { kind: denied, deniedBy: mode, mode: dontAsk, … }`), the run ends normally, and it is never looser
+            than `default`. One exception: a PreToolUse hook's OWN ask, when no other class in that ask's set backs it, is still handed to a person
+            (the engine's `arbitrateByMode`: the `hook` class on a row without `hookAskFloor`). Send it only when `capabilities.permissionModes` carries it: that bit absent = server <= 7.118.x, whose request
+            vocabulary is FIVE words — `dontAsk` on a fresh submit is 400 `request.field_invalid` there. The three sentences below — "omitting both carriers means no mode-derived gate", "`auto`
             is armed by the principal's entitlement independent of the mode word", "`bypassPermissions` adds no mode-derived gate" —
             hold for <= 7.105.0 only.
-            CC-parity permission-mode INTENT — the five values THIS wire's closed submit-gate accepts (post-[816]/
-            [820]/[822]; not a claim these are CC's/sema-cli's complete mode vocabulary, which is wider, e.g.
-            `dontAsk`). The frontend (TUI shell / web portal) carries the RAW mode; the SERVICE interprets it TIGHTEN-ONLY vs the deployment baseline:
+            CC-parity permission-mode INTENT — the values THIS wire's closed submit-gate accepts (the first five on server <= 7.118.x,
+            plus `dontAsk` from 7.119.0 = the engine's whole mode vocabulary, `capabilities.permissionModes`). The frontend (TUI shell / web portal) carries the RAW mode; the SERVICE interprets it TIGHTEN-ONLY vs the deployment baseline:
             `plan` ⇒ mount present_plan (core enablePlanMode) + read-only hands (CC EnterPlanMode research);
             `default` adds the manual ask gate on non-exempt writes (scratchpad dirs / remembered session
             exemptions still auto-allow — not literally every Write/Edit); the server emits the SAME gate-policy
@@ -7151,7 +7158,7 @@ components:
             as plain `default`; `acceptEdits` adds the SAME gate narrowed to auto-allow inside the working
             directory — but only when the service has a trusted working directory to scope it to; on a sandbox
             execution lane with none wired, `acceptEdits` degrades to asking on every non-exempt write, same
-            as `default`; `bypassPermissions` adds no mode-derived gate at all. None of the five can ever subtract
+            as `default`; `bypassPermissions` adds no mode-derived gate at all. None of them can ever subtract
             from the deployment/operator policy (deny-wins). Omitting this field is NOT itself "no mode-derived
             gate" — this field wins over a `settings.permissions.defaultMode` bundle when both are sent, but when
             THIS field is omitted the bundled mode (if any) still supplies one; only when neither carrier supplies
@@ -7422,6 +7429,14 @@ components:
           items: { $ref: '#/components/schemas/TaskAgentDefinition' }
           description: Per-task sub-agent definitions (roster additions scoped to this task only).
         interactiveTools: { type: boolean, description: Mount interactive (prompting) tools. }
+        approvalReach:
+          allOf: [{ $ref: '#/components/schemas/ApprovalReach' }]
+          description: >-
+            server >= 7.118.0 (core 7.43.0 #1354) — declares that NOBODY on this run can answer approvals. Passed verbatim to the
+            engine. The live approver callback is no longer this run's approver (`wiring_manifest` `ask.form: "declared_none"`); on a
+            deployment with a parking facility the first gated call PARKS the run (`paused`) — for "refuse and keep going" use
+            `permissionMode: "dontAsk"`. It never approves or releases anything. A value outside the closed set ⇒ 400
+            `request.field_invalid`. Probe `capabilities.approvalReach` first.
         oneShot:
           type: boolean
           description: >
@@ -8109,18 +8124,21 @@ components:
           enum: [mysql, pg, local, memory]
           description: >
             The ASSEMBLED backend (same word table; nothing assembled = `memory`). `declared != backend` is legal:
-            `DB_BACKEND=pg` + `SESSION_BACKEND=memory` (deliberately non-durable, no `degradedReason`) / an `auto` degrade
-            (`db_unreachable`) / a default-derived local store that could not be built (`declared: local`, `backend: memory`,
-            `local_unwritable`).
+            `DB_BACKEND=pg` + `SESSION_BACKEND=memory` (deliberately non-durable, no `degradedReason`) / a default-derived local
+            store that could not be built (`declared: local`, `backend: memory`, `local_unwritable`). Server >= 7.119.0: a configured
+            SQL store that cannot open is retried inside the wait window and then the boot is REFUSED — it never degrades to memory
+            (server <= 7.118.x degraded it silently under `SESSION_BACKEND=auto`, with the RETIRED word `degradedReason: db_unreachable`).
         durable: { type: boolean, description: '`backend !== "memory"`.' }
         degradedReason:
           type: string
           enum: [db_unreachable, local_unwritable]
           description: >
-            PRESENT-IFF the degrade arm ran; closed two words by backend family (server `STORE_DEGRADED_REASONS`):
-            `db_unreachable` = the SQL family could not open under `SESSION_BACKEND=auto` (connect or DDL, not told apart);
+            PRESENT-IFF the degrade arm ran; the server's own closed set (`STORE_DEGRADED_REASONS`) is ONE word since server >= 7.119.0:
             `local_unwritable` = the default-derived local file store could not be built (mkdir / lock / permission / read-only
-            mount / disk full). Absent = not degraded.
+            mount / disk full). ⚰️ RETIRED word `db_unreachable`: the SQL family could not open under `SESSION_BACKEND=auto` (connect or DDL, not told
+            apart) — a server <= 7.118.x (inside the support floor) still sends it; a server >= 7.119.0 NEVER does (a configured SQL store that
+            cannot open is retried, then the boot is refused — the SQL family has no degraded state). Kept in this enum so a valid response from an
+            older server still validates; it is deleted once the support floor rises past 7.118.x. Absent = not degraded.
         sql:
           allOf: [{ $ref: '#/components/schemas/SqlEngineCapability' }]
           description: >
@@ -8926,40 +8944,14 @@ components:
             not inside the HMAC payload, so accepting it unsigned would be tamperable); 501 without an exemption
             store. On the parked-background-agent leg the grant lands on the child's ROOT/HOST session (the whole
             session tree shares it). The 200 body echoes `rememberApplied` when a store is wired.
-        settledBy:
-          type: string
-          enum: [policy]
+        decidedBy:
+          allOf: [{ $ref: '#/components/schemas/ApprovalDecidedBy' }]
           description: >-
-            server #1016 (>= 7.93.3, core 7.26.2), ADDITIVE — WHO made this decision. `"policy"` is a MACHINE
-            REFUSAL, NEVER THE USER''S WORDS: the deployment''s own policy answered this card (a headless lane —
-            CI, a background batch, a shell refusing by a standing deployment posture). ABSENT = today''s shape
-            (`person`), so an unrevised caller is byte-for-byte unchanged.
-
-            WHY IT EXISTS: without the word, a policy refusal is byte-identical to "a person pressed No", and the
-            model reads "the user doesn''t want to proceed; STOP and wait for the user to tell you how to proceed"
-            — a sentence about a person, in a run where none is coming. With it the engine mints a POLICY sentence
-            instead, this request''s `reason` travels as the POLICY''s words (not as the user''s guidance), and the
-            settlement is recorded as `policy_refused` (`who.party: "none"`).
-
-            CONSTRAINTS: `decision:"deny"` only — only a person approves an action that EXECUTES, so
-            `{decision:"approve", settledBy:"policy"}` is a contradiction, refused by the SERVER before the
-            decision (400 `request.field_conflict`, the SAME SENTENCE as the live door) with the engine''s own
-            pre-CAS refusal (`checkpoint.invalid_outcome`) behind it as depth; the server does NOT silently drop
-            the key. It is therefore MUTUALLY EXCLUSIVE with `remember` (which is approve-only) — one body
-            cannot carry both. The vocabulary''s owner is still core: the server accepts the KEY and relays the
-            VALUE verbatim, so a word core does not know is refused by the engine, never by a server-side
-            second judge of the vocabulary.
-            REFUSED on a direct-door worker (400 `settled_by_not_in_proof` — not inside the HMAC payload, same
-            rule as `remember` / `updatedInput` / `checkpointToken`); a non-direct-door deployment is unchanged.
-
-            SHAPE, not word: a non-string is 400 `request.field_invalid` (same family as `reason must be a
-            string`). A word core does NOT know travels UNTOUCHED and is refused BY THE ENGINE pre-CAS:
-            409 + `errorCode: "resume_outcome_invalid"` + `field: "hostDecision"` + `retriable: true`, and the
-            card STAYS PENDING (re-decide the same coordinates with a corrected body). NOTE this family no
-            longer answers `approval_binding_mismatch`: from server 7.93.3 the `policy_ask` gate splits
-            `invalid_outcome` by `field`, and the non-binding seats (`hostDecision`, `approver`) answer
-            `resume_outcome_invalid` — "you approved the wrong action" is a sentence about a different fault.
-            The binding seats and the field-absent shape are byte-for-byte unchanged.
+            server >= 7.118.0 — WHO made this decision (one key read the same way by all three decision doors; see
+            ApprovalDecidedBy). ABSENT = `person`. This door's own answers: a `policy` allow on a person-required card is
+            refused by the ENGINE before the CAS (409 `resume_outcome_invalid` + `field: "hostDecision"`, the card stays
+            pending); outside the closed set ⇒ 400 `request.field_invalid`; any value on a direct-door worker ⇒ 400
+            `decided_by_not_in_proof`. An older server (no `approvalDecidedBy` bit) refuses the key (400 `request.body_shape`).
 
     ApprovalRow:
       type: object
@@ -9364,6 +9356,29 @@ components:
             `noteRecorded` (a live-card-only deployment has no row to write, and a flapping store cannot write
             one; both answer `false` while the decision itself still stands). This bit only says "this build
             knows the key" — same family as `permissionRulesRevoke`, deliberately gated on no facility.
+        approvalDecidedBy:
+          type: boolean
+          description: >-
+            server >= 7.118.0, hardcoded true (a version bit): the three approval decision doors read `decidedBy` (ApprovalDecidedBy).
+            Send it only when this is present; absent = an older server (the durable doors and `plan_review` 400 it, the live
+            `respond` drops it silently and answers 200).
+        approvalReach:
+          type: boolean
+          description: >-
+            server >= 7.118.0, hardcoded true (same word as the request key): TaskRequest.approvalReach is understood. Absent = an
+            older server — do not send the key.
+        permissionModes:
+          type: array
+          items: { type: string }
+          description: >-
+            server >= 7.119.0 — the permission-mode words this worker's REQUEST face accepts: the engine's `PERMISSION_MODES` whole set, engine order
+            (today six: `default`, `acceptEdits`, `plan`, `auto`, `bypassPermissions`, `dontAsk`). The top-level `TaskRequest.permissionMode`,
+            `settings.permissions.defaultMode` and `GET /v1/capabilities?permissionMode=` read ONE closed set: every word in the bit is accepted by
+            all three, a word outside it is 400 `request.field_invalid` whose sentence lists the same words. Send `dontAsk` only when this bit
+            carries it; ABSENT = server <= 7.118.x (five words, `dontAsk` is a 400). OPEN set: the bit forwards the engine's vocabulary
+            verbatim, so a future engine word shows up here before this document knows it — decide by the bit, do not filter it through the
+            `PermissionMode` schema. It says "this server accepts the word", not "the word takes effect on this submit" (`auto` still needs a
+            classifier seat and an entitlement — see `permissionModeAuto`).
         respondFreeFormRules:
           type: boolean
           description: >
@@ -9628,8 +9643,9 @@ components:
             the same false, and a shell must do different things for those. `reason` is present ONLY when
             `armed` is false; read its vocabulary as an OPEN set (server already grew it from four words to
             six). `model` is omitted when the classifier route cannot be resolved (the server logs the
-            engine's refusal rather than 500-ing the read face). `?permissionMode=<five words>` folds the
-            caller's INTENT into the verdict; anything outside the five words is a 400
+            engine's refusal rather than 500-ing the read face). `?permissionMode=<mode word>` folds the
+            caller's INTENT into the verdict (server >= 7.119.0 takes the six words of `capabilities.permissionModes` — `dontAsk` answers
+            `armed: false` / `reason: mode_not_auto`; server <= 7.118.x takes five); anything outside the server's words is a 400
             `request.field_invalid`.
           # 🔴 required 只有**三位**:武装两键(armed / reason)是 server >= 7.57.0 (S-80)
           # 才有的,而本包的支持地板是 3.0.0 => every 7.x <= 7.56.0 server is inside the promised face and
@@ -12529,6 +12545,13 @@ components:
             the vocabulary's owner is still core and it has grown before, so read it the same way as everywhere
             else: branch known words, keep a `default` arm, and treat an unknown one as "unknown origin", never
             as "no origin". A row minted before the bit existed reads absent (unreported), not "no authority".
+        boundGrantDigest: { type: string, description: 'server >= 7.118.0 — a parked `Skill` card''s grant-binding digest; same value as the live frame''s ToolApprovalFrame.boundGrantDigest.' }
+        boundGrants:
+          allOf: [{ $ref: '#/components/schemas/BoundSkillGrants' }]
+          description: 'server >= 7.118.0 — the value `boundGrantDigest` hashes, published ONLY when it hashes to it (the engine judges; a pair that disagrees reads as absent). DEPLOYMENT TEXT: render with contextual escaping.'
+        classifierNoRuling:
+          allOf: [{ $ref: '#/components/schemas/AutoModeFallbackCause' }]
+          description: 'server >= 7.118.0 — only on a parked `classifier_no_ruling` card: why the auto-mode classifier did not rule.'
         objective: { type: ['string', 'null'], description: 'task objective, null if unavailable.' }
         input:
           description: >
@@ -12759,6 +12782,11 @@ components:
       description: >
         Session audit (`GET /v1/sessions/:id`) — true shape. `messages` = current model context
         (older history folded into a summary message); can be large.
+        Server >= 7.119.0 (wire VALUE change, shape unchanged): string leaves inside `messages` (assistant text / reasoning, tool arguments,
+        tool results, shell output, compaction summaries) pass the SAME redaction as the live and ledger frames — a credential-shaped span reads
+        `«redacted:…»`. Key set, count and segment order are verbatim; a history with no credential-shaped span is byte-identical; the archive itself is
+        untouched (the redaction is read-side only), and `?blobCap=` truncation runs AFTER redaction. A caller that rebuilds a model context from this
+        read gets the placeholder, not the original string.
       # 🔴 **暂不封闭**(census 轴一裁定,2026-07-30):本体是 core `StoredSession.buildContext()` 的投影
       # (server `audit.ts` auditFromStorage),再叠 server 自己的两条 additive 后处理(windowMessages /
       # truncateMessageBlobs)与路由层追加的 owner —— 键集由「core 投影 × 查询参数」共同决定,不是一个
@@ -12790,7 +12818,11 @@ components:
             them is not known" narrowed to this; it still does NOT say "never consumed"; see `engine_notice`
             `task.user_steer_undrained{cause:"crashed"}`). Converged rows only, one row per (taskId, messageId),
             newest 500. From server >=7.111.0 (S-966) the rows include SUBAGENT steers (recorded under the run on the
-            receipt; same row shape, `kind` is still only `steer`; `messageId` = the subagent steer receipt's).
+            receipt; same row shape; `messageId` = the subagent steer receipt's).
+            `kind` = the engine LANE the input was queued on at acceptance (server >= 7.118.0 / core 7.44.0 #1362, closed two words):
+            `steer` (priority `now` / `next` / absent) or `follow_up` (priority `later`, queued for the run's end); the crash notices
+            split the same way (`task.user_steer_undrained` / `task.user_followup_undrained`, the latter with
+            `detail: { followUp, cause: "crashed", taskId, sessionId }`). Read both words; branch on `cause`.
             ABSENT = this read has nothing to report (zero rows, or the ledger could not be read —
             the authoritative notice is the frame on the run stream); the `?message=` single-entry form never
             carries it.
@@ -12800,7 +12832,7 @@ components:
             additionalProperties: false
             properties:
               messageId: { type: string }
-              kind: { type: string, enum: [steer] }
+              kind: { type: string, enum: [steer, follow_up] }
               taskId: { type: string, description: The run the input was accepted for (its 200/202 receipt). }
               acceptedAt: { type: string, description: ISO timestamp. }
               cause: { type: string, enum: [crashed] }
@@ -13573,8 +13605,10 @@ components:
             7.104.0 / S-271 — a deployment-declared tool exceeds the roster bound), `config.tool_schema_bound` (503, server >=
             7.106.0 / core 7.35.0 #765 — a tool's `parameters` schema exceeds the roster row's key bound; "same family, same tier";
             <= 7.105.0 answered the synchronous leg 200 + a failed body), `corrupt` (500 — the session rule store
-            cannot read its own bytes) and `internal.memory_control_plane_corrupt` (500 — the memory control plane refuses
-            fail-closed). Every other 5xx code keeps the status-based retry.
+            cannot read its own bytes), `internal.memory_control_plane_corrupt` (500 — the memory control plane refuses
+            fail-closed) and `state.scenario_assignment_unknown` (503, server >= 7.119.0 — the center's scenario assignment for the
+            principal is dangling; only re-pointing the assignment, or adding the scenario back to the deployment, helps). Every other 5xx
+            code keeps the status-based retry.
             🔴 `request.host_posture_refused` (422) has TWO triggers (same code, same status — "you wrote it right, this
             deployment will not grant that host posture"): (1) the write-containment face (`permissionMode: bypassPermissions` ⇒
             `writeFace: open`; read `capabilities.taskWriteFaceOpen` first); (2) server >= 7.106.0 / S-895: `inheritEnv: "all"` on a
@@ -13600,6 +13634,20 @@ components:
             🔴 NOT interchangeable with `taskId`: the workflow-child park lane mints no taskId at all (this
             decision never landed on any run, so minting one would be a lie), and the other two decide lanes
             mint no runId. Branch by `errorCode`, never fall back from one handle to the other.
+        readableHolderRunId:
+          type: string
+          description: >-
+            server >= 7.118.0, on `decide.workflow_parks_unreadable` (409) ONLY and only on its "the record cannot be read" cause: the
+            readable record that holds the card at the highest generation (absent when there is none or a tie — never null). Where the
+            work can be carried on — a CLUE, not a way to unblock this decision (the damaged record `runId` names keeps it undeliverable
+            until it is repaired). SDK reads it as `DecideWorkflowParksUnreadableError.readableHolderRunId`.
+        runIds:
+          type: array
+          items: { type: string }
+          description: >-
+            server >= 7.118.0, on `decide.workflow_park_forked` (409) ONLY: the resumed copies of one workflow run that all hold this card at
+            the same generation (>= 2). Recovery = resume ONE of them, then decide again; retrying the decide never succeeds.
+            SDK reads it as `DecideWorkflowParkForkedError.runIds`.
         cause:
           type: string
           description: >-
@@ -13642,10 +13690,19 @@ components:
             row's configuration was refused — `taskConfig` (change the configuration, then decide the SAME card again) or
             `inheritedGate` (the row's recorded mode seed is bad — the run can only be cancelled). Also on 400 `request.field_invalid` for a
             `settings.hooks` tool-event matcher that selects an engine alias but not its canonical name (server >= 7.115.0 / S-1025):
-            `field` is always the literal `settings.hooks` (see `detail`). SDK: `err.extra.field`.
+            `field` is always the literal `settings.hooks` (see `detail`). Also on 400 `request.body_shape` (server >= 7.119.0), on the THREE
+            tool-approval decision doors (`POST /v1/tool-approvals/{id}/respond`, `POST /v1/tasks/{taskId}/asks/{askId}/decision`,
+            `POST /v1/approvals/{sessionId}/decide`) and ONLY there: the body carried the retired key `settledBy` (any value but `undefined` —
+            `null` and `""` count), the refusal landed before any decision, and `field` is the literal `settledBy`; the three doors now answer
+            the SAME sentence. Every such 400 carries it, even when another defect in the same body was hit first (the sentence then names that
+            defect). Branch on the code plus `field`, never on the sentence; a bad body WITHOUT that key carries no `field`. SDK: `err.extra.field`.
         detail:
           description: >
-            🔴 TWO SHAPES under one code — branch on `field` (or the `errorCode`), never guess from the type of `detail`. On 400
+            🔴 SHAPES differ by code — branch on `field` (or the `errorCode`), never guess from the type of `detail`. On 503
+            `state.scenario_assignment_unknown` (server >= 7.119.0): an OBJECT `{ scenario, source }` — `scenario` = the dangling scenario name,
+            `source` ∈ `ruling` (the center's assignment for this principal names a scenario this deployment does not have) / `deployment`
+            (the deployment default `DEFAULT_SCENARIO` is dangling — the server refuses to BOOT on that, so a request reaches it only on an
+            embedder that assembles `resolveSpec` itself). On 400
             `request.field_invalid` for a `settings.hooks` tool-event matcher (server >= 7.115.0 / S-1025; additive, the sentence and the code
             are unchanged): an OBJECT `{ event, alias, canonical }` — `event` = the tool event of the refused group (the first refused one when
             several are), `alias` / `canonical` = the engine catalog's alias and canonical name (closed strings, never the caller's raw bytes),
@@ -13660,6 +13717,12 @@ components:
                 event: { type: string }
                 alias: { type: string }
                 canonical: { type: string }
+            - type: object
+              required: [scenario, source]
+              additionalProperties: false
+              properties:
+                scenario: { type: string }
+                source: { type: string, enum: [ruling, deployment] }
             - type: string
         count:
           type: integer
@@ -14251,16 +14314,27 @@ components:
       enum: [default, acceptEdits, plan, auto, bypassPermissions, dontAsk]
       description: >
         core 7.34.0 `PERMISSION_MODES` (six words). CLOSED on the gate record (the server screens it with core `isPermissionMode`;
-        an out-of-set word withholds the whole `gate`). ⚠️ The REQUEST face (`TaskRequest.permissionMode`) takes FIVE on server
-        7.106.0 — `dontAsk` on a fresh submit is 400 `request.field_invalid` (S-902) — yet `dontAsk` can still appear here (e.g. an
-        unattended leg run under `UNATTENDED_PERMISSION_MODE=dontAsk`).
+        an out-of-set word withholds the whole `gate`). The REQUEST face (`TaskRequest.permissionMode`) takes the same six words from
+        server 7.119.0 (`capabilities.permissionModes`); on server <= 7.118.x it takes FIVE — `dontAsk` on a fresh submit is 400
+        `request.field_invalid` there — yet `dontAsk` can still appear here on those versions (e.g. an 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, 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]
+      enum: [content_question, hook, ancestor, dangerous_delete, unverifiable_delete, transcript_write, org_rule, governance_unavailable, rule_unreadable, ask_rule, denial_limit_fallback, classifier_no_ruling, 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
+        core `ASK_CLASSES` (twenty-two words as of core 7.40.0, twenty-three as of core 7.41.0, twenty-four as of core 7.43.0, twenty-five as of core 7.45.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).
+        server >= 7.116.0; `classifier_no_ruling` joined in 7.43.0 #1353 and rides server >= 7.118.0; `dangerous_delete` joined in 7.45.0 and rides
+        server >= 7.119.0) — which CLASS an ask falls in (the columns of the mode × class arbitration table).
+        `dangerous_delete` = a DELETE OF A PROTECTED PLACE: an `rm` / `rmdir` whose target is the filesystem root, a top-level directory, the home
+        directory, the task root / working directory / an added working directory or an ancestor of one (including `rm -rf *` at the task root and
+        `rm -rf ~/*`), or a shell handed a script that is only assembled at run time (`bash -c "$CMD"`, `eval "$(…)"`). ONLY A PERSON'S ANSWER clears
+        it: no mode (`bypassPermissions` included), no allow (request `settings.permissions.allow`, operator `APPROVAL_GRANT`, a stored allow row, a
+        skill's tool list, a hook's allow) and no `auto` classifier does; the frame carries `requiresRealApproval: true`, nobody answering means the
+        call does not run (the unattended leg refuses), and it is bypass-IMMUNE (not one of the ten releasable classes).
+        `classifier_no_ruling` = the auto-mode classifier did not rule (it could not run — `error` / `timeout` — or replied with no verdict —
+        `parse_error`), so a person decides: the denial-limit fallback's row (bypass-immune, no allow rule clears it, the classifier is not asked
+        again); the live frame and the inbox row also carry the cause as `classifierNoRuling`.
         `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 +
@@ -15963,18 +16037,12 @@ components:
             offer on another replica is not a promise that it is still redeemable.
         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 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`.
-            🔴 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.
+          description: >-
+            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 rule's VERBATIM text (secret-redacted + length-bounded; UNTRUSTED
+            for display, like `message`). Absent != "you have no rule"; deliberately separate from `governanceForced`.
+            RETIRED: server >= 7.117.0 (core 7.42.0, BREAKING rename, no alias) never mints this key on any face; its successor is
+            `allowRuleShadowed` (all five allow-layer members, not just the rule store). Kept for servers in [7.13.0, 7.117.0) only (sdk 16.3.0).
         allowRuleShadowed:
           type: array
           items: { $ref: '#/components/schemas/AllowRuleShadow' }
@@ -16192,6 +16260,24 @@ components:
             `ASK_CLASSES` order, non-empty, `classes[0] === askClass`); one ask can belong to several, so read the whole
             set, not just `askClass`. Present together with `askClass`; passed through verbatim in order (the server
             neither sorts nor dedupes).
+        boundGrantDigest:
+          type: string
+          description: >-
+            server >= 7.118.0 (core 7.43.0 #1348 / #1357), "tool_approval" only — on a call of the engine's `Skill` tool: the hash of what
+            approving it ALSO grants (the skill name + its two lists, canonical spelling); absent on every other card. Same value as the
+            parked row's / the inbox row's twin (the live card and its parked twin reconcile by `(toolCallId, boundGrantDigest)`); passed
+            through verbatim. A live "allow for this session" is remembered under "this tool + this digest" and answers only an ask with the
+            same digest (same skill, same lists); a different skill or a changed list asks again. The durable `remember: "session"` never
+            remembers a skill card.
+        boundGrants:
+          allOf: [{ $ref: '#/components/schemas/BoundSkillGrants' }]
+          description: 'server >= 7.118.0, "tool_approval" only — the value `boundGrantDigest` hashes; present iff it is. DEPLOYMENT TEXT: render with contextual escaping.'
+        classifierNoRuling:
+          allOf: [{ $ref: '#/components/schemas/AutoModeFallbackCause' }]
+          description: >-
+            server >= 7.118.0 (core 7.43.0 #1353), "tool_approval" only, only on a `classifier_no_ruling` card — WHY the auto-mode classifier
+            did not rule (`error` / `timeout` = it could not run; `parse_error` = it replied with no verdict), so a person decides. The server
+            screens it with the engine's closed set (an out-of-set word is withheld). Display only.
         denialLimitFallback: { $ref: '#/components/schemas/DenialLimitFallback' }
         parked:
           type: boolean
@@ -16388,13 +16474,11 @@ 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.
+          description: >-
+            server >= 7.13.0 (core 5.25.0 #144), ADDITIVE — the persisted rule this ask matched but which could not silence it; frame and
+            card carry the SAME material (see ToolApprovalFrame.persistedRuleShadowed).
+            RETIRED: server >= 7.117.0 (core 7.42.0) never mints this key on any face (its strict card schema even refuses a stored card
+            carrying it); its successor is `allowRuleShadowed`. Kept for servers in [7.13.0, 7.117.0) only (sdk 16.3.0).
         allowRuleShadowed:
           type: array
           items: { $ref: '#/components/schemas/AllowRuleShadow' }
@@ -16633,21 +16717,25 @@ components:
     RuleOfferMatch:
       type: string
       description: >
-        The MATCH FORM of a persisted rule — the server's `PERSISTED_RULE_MATCHES`, verbatim (the vocabulary
+        The MATCH FORM of a persisted rule — the server's `PERSISTED_RULE_MATCHES`, verbatim and in order (the vocabulary
         is OWNED BY CORE; the server only transcribes it and pins set equality, so core adding a member turns
-        the server red at compile time).
+        the server red at compile time). ONE vocabulary for two faces: a card's rule offer (`RuleOffer.match`, the
+        server's card schema validates it with this very enum) and a persisted rule row (`GET /v1/rules`).
 
         `exact` = this one command only (`Bash(git status)`). `prefix` = the historical colon-star
         word-boundary prefix (`Bash(git status:*)`) and the ONLY spelling for a compound prefix form; it stays
         a permanent compatibility read. `wildcard` = the trailing space-star form (`Bash(npm run *)`), the
-        same predicate as `prefix` on a single command body, minted by core's suggestion face since
-        design/382 / #510. `subpath` = the `Read(//abs-dir/**)` directory form, which never holds a command.
-
-        🔴 FOUR MEMBERS, not "the three today's miner emits": this type describes what a consumer may RECEIVE,
-        and the server's wire validator accepts all four. A consumer type narrower than the mint point is a
-        lie — it lets a `switch` claim exhaustiveness the wire does not honour. (The retired `RuleSuggestion`
-        declared only two, which is exactly why a legal `wildcard` candidate used to be dropped as malformed.)
-      enum: [exact, prefix, wildcard, subpath]
+        same predicate as `prefix` on a single command body. `subpath` = the `Read(//abs-dir/**)` directory form,
+        which never holds a command. `path` (server >= 7.67.0) = the path-family pattern grammar for deny/ask/allow
+        rules (`//abs`, `~/`, root-relative, cwd-relative; `*` within a segment, `**` across segments). `name` /
+        `name_prefix` (server >= 7.118.0 / core 7.43.0 #1318) = the `Skill` name grammar: `Skill(<name>)` exact,
+        `Skill(<prefix>:*)` a name prefix with NO word boundary; a skill card's "don't ask again" offer carries
+        `match: "name"`. A replica rolled back to 7.117.x reads a `name` / `name_prefix` row as a damaged row.
+
+        🔴 SEVEN MEMBERS, closed: the server validates the member on both faces. A consumer type narrower than the
+        mint point is a lie — it lets a `switch` claim exhaustiveness the wire does not honour (SDK <= 16 declared
+        four here, so a `path` offer and every 7.118.0 skill-card offer were dropped as malformed).
+      enum: [exact, prefix, wildcard, subpath, path, name, name_prefix]
 
     RuleOfferUncoveredReason:
       type: string
@@ -17223,25 +17311,66 @@ components:
           additionalProperties: false
           properties:
             label: { type: string, maxLength: 256 }
-        settledBy:
-          type: string
-          enum: [policy]
+        decidedBy:
+          allOf: [{ $ref: '#/components/schemas/ApprovalDecidedBy' }]
           description: >-
-            server S-843 (>= 7.104.0), ADDITIVE — the SETTLEMENT SOURCE of this decision. Same word, same source, same
-            sentence as the durable decide leg's key (`POST /v1/approvals/{sessionId}/decide`, ApprovalDecision.settledBy —
-            see that schema for the full account; the server judges this door and `/decide` with one function, and the live
-            respond leg reads the same two refusal sentences under its own `request.body_shape` family):
-            `"policy"` = the deployment's own policy answered this card, not a person; ABSENT = today's shape.
-            `decision:"deny"` only (an approve carrying it ⇒ 400 `request.field_conflict`); REFUSED on a direct-door worker
-            (400 `settled_by_not_in_proof`); a non-string ⇒ 400 `request.field_invalid`. 🔴 An UNKNOWN word is the OPPOSITE of
-            `/decide` here: this door does not judge the word, so it answers 200 and the word is stored with the decision (the
-            card is settled as `deny`; its source cannot be corrected afterwards, and an idempotent replay replays it), and the
-            engine refuses the word fail-closed at settlement — NOT `/decide`'s 409 `resume_outcome_invalid` with the card left
-            pending for a corrected re-decide. THIS leg only: the value lands in a fixed-width
-            `settled_by` column — outside 1..16 characters ⇒ 400 `request.field_invalid` before the CAS; none of the three
-            response bodies echoes it. OLDER SERVERS (< 7.104.0): this body schema is strict, so the key is an unknown key ⇒
-            400 `request.body_shape` and nothing is decided — a loud refusal, not a silent drop. No capability bit; gate on
-            the server version.
+            server >= 7.118.0 — WHO made this decision (one key read the same way by all three decision doors; see
+            ApprovalDecidedBy). ABSENT = `person`. This door's own answers (both refused before the decision, the card does
+            not move): a `policy` allow on a person-required card ⇒ 400 `request.field_conflict`; outside the closed set ⇒
+            400 `request.field_invalid`; any value on a direct-door worker ⇒ 400 `decided_by_not_in_proof`. An older server
+            (no `approvalDecidedBy` bit) has a strict body here ⇒ 400 `request.body_shape`, nothing decided.
+
+    ApprovalDecidedBy:
+      type: string
+      enum: [person, policy]
+      description: >
+        server >= 7.118.0 (`APPROVAL_DECIDED_BY`, verbatim and in order) — WHO made an approval decision, one key on all three decision
+        doors (live `POST /v1/tool-approvals/{approvalId}/respond`, durable `POST /v1/tasks/{taskId}/asks/{askId}/decision`, durable
+        `POST /v1/approvals/{sessionId}/decide`). `person` = a person decided through the approval channel (ABSENT means this);
+        `policy` = this deployment's own policy decided (a rule / posture answering on someone's behalf, a headless lane) — BOTH
+        directions: the engine records `tool_end.gate.settlement.kind` = `policy_allowed` / `policy_refused` (`who.party: "policy"`).
+        The only verb constraint is the engine's own: a person-required card (`requiresRealApproval`) cannot be ALLOWED by a policy.
+        Send it only when `GET /v1/capabilities` carries `approvalDecidedBy: true`. Outside the closed set (including `sla_timeout` —
+        "the wait ran out with nobody answering" is said only by the server's own deadline sweep — and the old `human` / `timeout`
+        words) ⇒ 400 before the decision. It REPLACES the 7.93.3–7.117.x key `settledBy` (deny-only, the same fact), deleted
+        by server 7.118.0 with no alias: sending `settledBy` ⇒ 400 `request.body_shape` on all three doors.
+        `plan_review` does not take it (400 `request.body_shape`).
+
+    ApprovalReach:
+      type: string
+      enum: [none]
+      description: >
+        The closed set of the request key `approvalReach` (core 7.43.0 #1354 `APPROVAL_REACH`, verbatim): `none` — nobody on this run can be
+        asked to approve. There is no positive word ("a person is reachable" is the `interactionPosture: "interactive"` promise).
+
+    AutoModeFallbackCause:
+      type: string
+      enum: [error, timeout, parse_error]
+      description: >
+        core 7.43.0 `AUTO_MODE_FALLBACK_CAUSES`, verbatim and in order — why the auto-mode classifier did not rule: `error` / `timeout` (it could
+        not run), `parse_error` (it replied with no verdict). Carried as `classifierNoRuling` on a `classifier_no_ruling` card (server >= 7.118.0).
+
+    BoundSkillGrants:
+      type: object
+      description: >
+        core 7.43.0 `BoundSkillGrants` (three keys, verbatim) — what approving an engine `Skill` card ALSO grants: `skill` = the loaded skill's
+        name (`null` = the call names no loaded skill; it grants nothing), `allowedTools` = what activation lets be used without asking,
+        `disallowedTools` = what activation refuses for the rest of the run (canonical spelling: de-duplicated, sorted). DEPLOYMENT TEXT.
+      required: [skill, allowedTools, disallowedTools]
+      additionalProperties: false
+      properties:
+        skill: { type: ['string', 'null'] }
+        allowedTools: { type: array, items: { type: string } }
+        disallowedTools: { type: array, items: { type: string } }
+
+    SteerReplayFacet:
+      type: string
+      enum: [text, trusted, priority, actor]
+      description: >
+        core 7.44.0 #1374 `STEER_REPLAY_FACETS`, verbatim and in order — the facets on which a replayed steering input id differs from the
+        accepted one. Carried as `detail.differs` (a non-empty subset, the engine's order) on 409 `steering.duplicate_input_id` (server >= 7.118.0):
+        contains `text` ⇒ a different instruction, reissue with a fresh key; no `text` ⇒ the SAME instruction — do NOT change the key (it
+        would queue twice), replay with the original values.
 
     AskDecisionAck:
       type: object
@@ -18381,7 +18510,7 @@ components:
           type: object
           description: 'Approval seam: wired form, which seat it came from, and (effective half) what it adjudicates to.'
           properties:
-            form: { type: string, enum: [callback, allow, deny, absent] }
+            form: { type: string, enum: [callback, allow, deny, absent, declared_none], description: '`declared_none` (server >= 7.118.0 / core 7.43.0): the run declared nobody on it can be asked (`approvalReach: "none"`), so a callback beside the declaration is not this run''s approver.' }
             provenance: { type: string, enum: [spec, deps] }
             effective: { type: string, enum: [human_reachable, auto_allow, auto_deny, park_only, unresolved] }
         question:
@@ -19759,17 +19888,11 @@ components:
             engine's catalogue, not on this wire. READ IT; do not switch over a closed list. A name the grammar
             does not know is still a 400 on the input faces.
         match:
-          type: string
-          enum: [exact, prefix, wildcard, subpath, path]
-          description: >
-            The match form (core `PersistedRuleMatch`, five members). `exact` = this one command only ·
-            `prefix` = word-boundary prefix (the historical colon-star spelling, and the only spelling for a
-            compound prefix) · `wildcard` = the space-star form, the SAME predicate as `prefix` on a single
-            command body · `subpath` = the directory (read-containment) form, which never admits a command ·
-            `path` = NEW in server >= 7.67.0, the path-family pattern grammar for deny/ask/allow rules (`//abs`,
-            `~/`, root-relative, cwd-relative; `*` within a segment, `**` across segments).
-            SDK 8.7.0 and earlier declared only the first two — a consumer rendering this cell off a closed list
-            must add the other three.
+          allOf: [{ $ref: '#/components/schemas/RuleOfferMatch' }]
+          description: >
+            The match form — the same seven-member vocabulary as a card's rule offer (`RuleOfferMatch`, the server's
+            `PERSISTED_RULE_MATCHES`): `exact` / `prefix` / `wildcard` / `subpath` / `path`, and from server >= 7.118.0
+            `name` / `name_prefix` (a `Skill(<name>)` / `Skill(<prefix>:*)` rule).
         command: { type: string, description: 'What the matcher actually compares against, parsed out of `rule` at mint time and stored so no consumer re-parses. Trust this + `match`, not your own parse of `rule`.' }
         adds:
           type: array