otto-intel-mcp 0.1.2 → 0.1.3

package/dist/execution-delegation-admin.d.ts

@@ -1,9 +1,11 @@
 /**
- * execution-delegation-admin.ts — the three delegation ADMIN tools on the hosted MCP (PR-1b, seat ruling D10 = (a)).
+ * execution-delegation-admin.ts — the four delegation ADMIN tools on the hosted MCP (PR-1b, seat ruling D10 = (a)).
  *
  *   otto_delegation_fence   — the ONLY writer of the Model-B project policy: ensure-by-digest + read-back.
  *   otto_delegation_status  — one user's grant/fence read-back, bound to the user a CDP access token resolves to.
  *   otto_delegation_revoke  — developer-side revoke with read-back, fail-closed under the rig lock.
+ *   otto_delegation_cap     — reserves the expiry a delegation is minted with, records the chosen per-swap
+ *                             cap against it, and confirms after the mint that CDP kept that exact instant.
  *
  * Every tool: the request header FIRST (constant-time, before parsing or any CDP read — the same seam as
  * `otto_submit_under_delegation`), then the strict schema, then the reads. Nothing here logs a token, the
@@ -44,7 +46,7 @@
  * support_reason }` from an operator holding the server secret; the reason is written to the structured log
  * through the boot redactor (URLs and configured secret values never land in the log), the token never is.
  */
-import { type DelegationFenceResult, type DelegationFenceStatusResult, type DelegationRevokeResult, type DelegationStatusResult } from './execution-delegation-admin-definition.js';
+import { type DelegationCapResult, type DelegationFenceResult, type DelegationFenceStatusResult, type DelegationRevokeResult, type DelegationStatusResult } from './execution-delegation-admin-definition.js';
 import { type DelegationCaller } from './execution-delegation.js';
 import type { ExecutionToolRuntime } from './execution-tools.js';
 /** Read-back after a write: the engine propagates asynchronously (the proof kit waited 3 s flat). */
@@ -61,6 +63,50 @@ export declare function ensureDelegationFence(runtime: ExecutionToolRuntime, raw
 export declare function readDelegationFenceStatus(runtime: ExecutionToolRuntime): Promise<DelegationFenceStatusResult>;
 /** `otto_delegation_status` — one user's read-back, bound to the token's user. */
 export declare function readDelegationStatus(runtime: ExecutionToolRuntime, rawInput: unknown, caller: DelegationCaller): Promise<DelegationStatusResult>;
+/**
+ * `otto_delegation_cap` — RESERVE the expiry a delegation will be minted with, record the chosen per-swap
+ * cap against it, and CONFIRM the mint (Founder word `delegate cap choice`, 2026-09-02; round 3, after the
+ * codex gate NO-GO'd rounds 1 and 2 and the seat ruled the collision out rather than documenting it).
+ *
+ * ══════════════════════════════════════════════════════════════════════════════════════════════════
+ * 🔴 WHY THE ORDER IS RESERVE → MINT → CONFIRM, AND NOT MINT → RECORD
+ * ══════════════════════════════════════════════════════════════════════════════════════════════════
+ * The gate's second finding is the whole reason: an expiry is the ONLY thing a send can learn about a live
+ * grant, so keying the RECORD by anything else — r1's expiry-as-key, r2's mint key — fixes the record and
+ * not the send. Its probe minted a $10 replacement carrying the SAME expiry as a standing $5,000 row and
+ * watched a plan run at $5,000. Live confirmation of exactly that, on the dev project (2026-09-02T22:17Z):
+ * CDP refuses a second mint over a live grant (409 `already_exists`), but after a user-side revoke a
+ * re-mint at the SAME instant succeeds and reads back at that identical instant. Two grants for one user
+ * CAN share an expiry.
+ *
+ * So round 3 stops trying to tell them apart and makes them impossible:
+ *
+ *   RESERVE — the SERVER picks the instant. It walks back from the second the person's chosen duration
+ *     lands on and takes the first whole second no durable row for this user occupies, then writes the cap
+ *     against it BEFORE any grant exists. The caller cannot choose the enforcement key, which is the
+ *     property that makes it unique. The ladder only ever steps EARLIER (seat ruling): a permission must
+ *     never outlive the duration the person chose, and the page shows the instant it actually got.
+ *
+ *   MINT — the caller passes `mint_expires_at` to `createDelegation` verbatim. It is the reserved second
+ *     plus one millisecond, because CDP refuses a bare `.000Z` (401 `unauthorized` "Wallet authentication
+ *     error" — isolated on one session: `.000Z` refused, `.137Z` accepted, `.000Z` refused again) and
+ *     truncates the filler away, storing exactly the reserved second.
+ *
+ *   CONFIRM — the server re-reads the grant from CDP and refuses unless the instant CDP reports IS the
+ *     reserved one. That is the assertion the whole construction rests on: if CDP ever normalises,
+ *     truncates differently, or another actor's grant is what reads back, this is where it surfaces
+ *     instead of silently binding a permission to a row it was never matched to.
+ *
+ * 🔴 A CONFIRM MISMATCH REVOKES THE FRESH GRANT, AND MARKS THE USER FAIL-CLOSED ON THIS SERVER. That is a
+ * heavy consequence and it is the intended one: the live permission is not the one this cap was chosen
+ * for, and the alternative — leaving it standing — is a permission whose bound nobody can name. If CDP's
+ * echo behaviour ever changed globally, every mint would land here and every delegated send would stop,
+ * which is the correct direction for a control that bounds a person's money.
+ *
+ * 🔴 NEITHER PHASE TAKES A USER ID OR AN EXPIRY FROM THE CALLER. The identity comes from
+ * `validateAccessToken`; the reserved instant comes from the store; the live instant comes from CDP.
+ */
+export declare function reserveDelegationCap(runtime: ExecutionToolRuntime, rawInput: unknown, caller: DelegationCaller): Promise<DelegationCapResult>;
 /** What the support path writes to the structured log: the user id and the REDACTED reason — never a token. */
 export interface SupportActionSink {
     write(entry: {

package/dist/execution-delegation-admin.js

@@ -1,9 +1,11 @@
 /**
- * execution-delegation-admin.ts — the three delegation ADMIN tools on the hosted MCP (PR-1b, seat ruling D10 = (a)).
+ * execution-delegation-admin.ts — the four delegation ADMIN tools on the hosted MCP (PR-1b, seat ruling D10 = (a)).
  *
  *   otto_delegation_fence   — the ONLY writer of the Model-B project policy: ensure-by-digest + read-back.
  *   otto_delegation_status  — one user's grant/fence read-back, bound to the user a CDP access token resolves to.
  *   otto_delegation_revoke  — developer-side revoke with read-back, fail-closed under the rig lock.
+ *   otto_delegation_cap     — reserves the expiry a delegation is minted with, records the chosen per-swap
+ *                             cap against it, and confirms after the mint that CDP kept that exact instant.
  *
  * Every tool: the request header FIRST (constant-time, before parsing or any CDP read — the same seam as
  * `otto_submit_under_delegation`), then the strict schema, then the reads. Nothing here logs a token, the
@@ -47,9 +49,10 @@
 import { getAddress } from 'viem';
 import { revocationRequested } from './adapter/cdp-signer.js';
 import { redactBootMessage } from './boot-redaction.js';
-import { DELEGATION_FENCE_INPUT_SCHEMA, DELEGATION_REVOKE_INPUT_SCHEMA, DELEGATION_STATUS_INPUT_SCHEMA, } from './execution-delegation-admin-definition.js';
+import { DELEGATION_CAP_INPUT_SCHEMA, DELEGATION_FENCE_INPUT_SCHEMA, DELEGATION_REVOKE_INPUT_SCHEMA, DELEGATION_STATUS_INPUT_SCHEMA, } from './execution-delegation-admin-definition.js';
 import { assertDelegationCaller, } from './execution-delegation.js';
-import { MODEL_B_PER_SWAP_CAP_USD, MODEL_B_POLICY_LINEAGE_PREFIX, MODEL_B_POLICY_NAME_V1, MODEL_B_POLICY_VERSION, modelBLineageVersion, modelBProjectPolicyBody, policyRulesDigest, readBackModelBFence, } from './execution-delegation-policy.js';
+import { boundedDelegationExpiry, MODEL_B_PER_SWAP_CAP_MIN_USD, MODEL_B_PER_SWAP_CAP_USD, MODEL_B_POLICY_LINEAGE_PREFIX, MODEL_B_POLICY_NAME, MODEL_B_POLICY_VERSION, fenceIsCurrent, modelBLineageVersion, modelBProjectPolicyBody, policyRulesDigest, readBackModelBFence, } from './execution-delegation-policy.js';
+import { DelegationCapExpiryUnavailableError, DELEGATION_MINT_PAUSED_MESSAGE, MODEL_B_CAP_RULESET_VERSION, } from './execution-delegation-cap-store.js';
 import { refuse } from './execution-errors.js';
 const DEFAULT_FENCE_WAIT = { pollMs: 500, maxPolls: 20 };
 function servicesOf(runtime) {
@@ -110,7 +113,9 @@ export async function ensureDelegationFence(runtime, rawInput, caller, wait = {}
         if (project.length > 1)
             return refuseAmbiguous(project);
         const before = readBackModelBFence(snapshot);
-        if (before.present)
+        // A v1 fence reads back as PRESENT (swaps and deposits keep working under it) but is not current: it
+        // is upgraded in place below — the one write the Founder's `fence v2` word triggers, by running this tool.
+        if (before.present && fenceIsCurrent(before))
             return fenceResult('unchanged', before.id, before.rulesDigest);
         let action;
         let targetId;
@@ -129,8 +134,12 @@ export async function ensureDelegationFence(runtime, rawInput, caller, wait = {}
                 if (againProject.length > 1)
                     return refuseAmbiguous(againProject);
                 const read = readBackModelBFence(again);
-                if (read.present)
+                // Only a CURRENT fence is "unchanged" (codex gate r1 MEDIUM): a v1 fence that appeared during the
+                // ensure is present but not current, and this path never updates — it says so and asks for a re-run.
+                if (read.present && fenceIsCurrent(read))
                     return fenceResult('unchanged', read.id, read.rulesDigest);
+                if (read.present)
+                    return refuse('DELEGATION_FENCE_ABSENT', `a v${read.version} fence of our lineage appeared during the ensure (id ${read.id}); this path never updates — run the fence tool again to upgrade it in place`);
                 const appeared = againProject[0];
                 if (!appeared)
                     return refuse('DELEGATION_FENCE_ABSENT', 'the create was refused as a duplicate but no project policy reads back; run the fence tool again');
@@ -175,7 +184,7 @@ export async function ensureDelegationFence(runtime, rawInput, caller, wait = {}
             if (afterProject.length > 1)
                 return refuseAmbiguous(afterProject);
             const after = readBackModelBFence(listed);
-            if (after.present && after.id === targetId)
+            if (after.present && fenceIsCurrent(after) && after.id === targetId)
                 return fenceResult(action, after.id, after.rulesDigest);
             last = after.present
                 ? `a v-current policy reads back under id ${after.id}, not the written id ${targetId}`
@@ -183,7 +192,7 @@ export async function ensureDelegationFence(runtime, rawInput, caller, wait = {}
             if (poll + 1 < maxPolls)
                 await new Promise((resolve) => setTimeout(resolve, pollMs));
         }
-        return refuse('DELEGATION_FENCE_ABSENT', `the fence was ${action} (id ${targetId}) but does not read back as "${MODEL_B_POLICY_NAME_V1}" with the v1 rules digest under that id after ${maxPolls} polls (${last}); nothing is submittable until it does`);
+        return refuse('DELEGATION_FENCE_ABSENT', `the fence was ${action} (id ${targetId}) but does not read back as "${MODEL_B_POLICY_NAME}" with the v${MODEL_B_POLICY_VERSION} rules digest under that id after ${maxPolls} polls (${last}); nothing is submittable until it does`);
     });
 }
 function fenceResult(action, id, rulesDigest) {
@@ -191,7 +200,7 @@ function fenceResult(action, id, rulesDigest) {
         status: 'present',
         action,
         policy_id: id,
-        policy_name: MODEL_B_POLICY_NAME_V1,
+        policy_name: MODEL_B_POLICY_NAME,
         rules_digest: rulesDigest,
         per_swap_cap_usd: MODEL_B_PER_SWAP_CAP_USD,
     });
@@ -205,11 +214,20 @@ export async function readDelegationFenceStatus(runtime) {
     const fence = readBackModelBFence(await services.rig.listProjectPolicies());
     return Object.freeze({
         present: fence.present,
-        policy_name: MODEL_B_POLICY_NAME_V1,
+        // The name that READS BACK (v1 until the fence tool upgrades it), so the page can tell which fence stands.
+        policy_name: fence.present ? fence.name : MODEL_B_POLICY_NAME,
         per_swap_cap_usd: MODEL_B_PER_SWAP_CAP_USD,
+        per_swap_cap_min_usd: MODEL_B_PER_SWAP_CAP_MIN_USD,
         // The public authority binding: published present or absent, so the agent CLI mints to THIS project
         // (and can still bind status/revoke to it after the fence is removed). Registration requires it set.
         ...(services.publicProjectId ? { project_id: services.publicProjectId } : {}),
+        ruleset_version: MODEL_B_CAP_RULESET_VERSION,
+        /**
+         * 🔴 THE PAUSE IS PUBLISHED, so the page and the CLI can SAY it before a person signs in rather than
+         * discovering it at the reserve. False means no new permission can be created on this worker; it says
+         * nothing about permissions that already stand — those keep working, and revoke always does.
+         */
+        mint_enabled: services.mintEnabled,
         ...(fence.present ? { rules_digest: fence.rulesDigest } : { reason: fence.reason }),
     });
 }
@@ -232,24 +250,261 @@ export async function readDelegationStatus(runtime, rawInput, caller) {
     const input = parseWith(DELEGATION_STATUS_INPUT_SCHEMA, rawInput);
     const user = await userFromAccessToken(services, input.accessToken);
     const fence = readBackModelBFence(await services.rig.listProjectPolicies());
-    const requestedHere = revocationRequested(services.rig.rig, user.userId);
     const grant = await services.rig.rig.readDelegation(user.userId);
     const expiresAtMs = grant ? Date.parse(grant.expiresAt) : Number.NaN;
+    // Per GRANT, not per user: a revoke aimed at a permission the person no longer holds says nothing
+    // about the one they hold now.
+    const requestedHere = grant !== undefined && revocationRequested(services.rig.rig, user.userId, grant.expiresAt);
     const active = grant !== undefined &&
         !requestedHere &&
         Number.isFinite(expiresAtMs) &&
         expiresAtMs > runtime.nowMs();
+    /**
+     * 🔴 THE CAP COMES FROM THE CONFIRMED-ACTIVE RECORD, AND ONLY WHEN IT NAMES THE GRANT THAT READS BACK
+     * — exactly the check the delegated send makes, so this surface and the send can never disagree about
+     * what is in force. A reservation that was never confirmed shows NO cap, because it authorises
+     * nothing. It is OMITTED, never defaulted: absence here means the send will refuse, and a page that
+     * showed the ceiling instead would tell the reader their permission allows $5,000 when it allows
+     * nothing at all.
+     */
+    let recordedCapUsd;
+    if (grant && services.capStore.available) {
+        try {
+            const confirmed = await services.capStore.readActive(user.userId, runtime.nowMs());
+            if (confirmed &&
+                Date.parse(confirmed.expiresAt) === expiresAtMs &&
+                confirmed.requiredVersion <= MODEL_B_CAP_RULESET_VERSION) {
+                recordedCapUsd = confirmed.perSwapCapUsd;
+            }
+        }
+        catch {
+            // A read that FAILED is not "nothing is confirmed" — the send will refuse either way, and this
+            // surface says so by omitting the field rather than inventing a number in either direction.
+            recordedCapUsd = undefined;
+        }
+    }
     return Object.freeze({
         user_id: user.userId,
         addresses: [...user.addresses],
         fence: Object.freeze({
             present: fence.present,
-            policy_name: MODEL_B_POLICY_NAME_V1,
+            policy_name: fence.present ? fence.name : MODEL_B_POLICY_NAME,
             per_swap_cap_usd: MODEL_B_PER_SWAP_CAP_USD,
             ...(fence.present ? { rules_digest: fence.rulesDigest } : {}),
         }),
-        delegation: Object.freeze({ active, ...(grant ? { expires_at: grant.expiresAt } : {}) }),
+        delegation: Object.freeze({
+            active,
+            ...(grant ? { expires_at: grant.expiresAt } : {}),
+            ...(recordedCapUsd !== undefined ? { per_swap_cap_usd: recordedCapUsd } : {}),
+        }),
         revocation_requested_here: requestedHere,
+        // What this worker implements — the page and the CLI refuse to reserve or mint against an older one.
+        ruleset_version: MODEL_B_CAP_RULESET_VERSION,
+        // Whether a NEW permission can be created here at all (the staged-deploy gate). Never gates this read,
+        // and never gates revoke.
+        mint_enabled: services.mintEnabled,
+    });
+}
+/**
+ * `otto_delegation_cap` — RESERVE the expiry a delegation will be minted with, record the chosen per-swap
+ * cap against it, and CONFIRM the mint (Founder word `delegate cap choice`, 2026-09-02; round 3, after the
+ * codex gate NO-GO'd rounds 1 and 2 and the seat ruled the collision out rather than documenting it).
+ *
+ * ══════════════════════════════════════════════════════════════════════════════════════════════════
+ * 🔴 WHY THE ORDER IS RESERVE → MINT → CONFIRM, AND NOT MINT → RECORD
+ * ══════════════════════════════════════════════════════════════════════════════════════════════════
+ * The gate's second finding is the whole reason: an expiry is the ONLY thing a send can learn about a live
+ * grant, so keying the RECORD by anything else — r1's expiry-as-key, r2's mint key — fixes the record and
+ * not the send. Its probe minted a $10 replacement carrying the SAME expiry as a standing $5,000 row and
+ * watched a plan run at $5,000. Live confirmation of exactly that, on the dev project (2026-09-02T22:17Z):
+ * CDP refuses a second mint over a live grant (409 `already_exists`), but after a user-side revoke a
+ * re-mint at the SAME instant succeeds and reads back at that identical instant. Two grants for one user
+ * CAN share an expiry.
+ *
+ * So round 3 stops trying to tell them apart and makes them impossible:
+ *
+ *   RESERVE — the SERVER picks the instant. It walks back from the second the person's chosen duration
+ *     lands on and takes the first whole second no durable row for this user occupies, then writes the cap
+ *     against it BEFORE any grant exists. The caller cannot choose the enforcement key, which is the
+ *     property that makes it unique. The ladder only ever steps EARLIER (seat ruling): a permission must
+ *     never outlive the duration the person chose, and the page shows the instant it actually got.
+ *
+ *   MINT — the caller passes `mint_expires_at` to `createDelegation` verbatim. It is the reserved second
+ *     plus one millisecond, because CDP refuses a bare `.000Z` (401 `unauthorized` "Wallet authentication
+ *     error" — isolated on one session: `.000Z` refused, `.137Z` accepted, `.000Z` refused again) and
+ *     truncates the filler away, storing exactly the reserved second.
+ *
+ *   CONFIRM — the server re-reads the grant from CDP and refuses unless the instant CDP reports IS the
+ *     reserved one. That is the assertion the whole construction rests on: if CDP ever normalises,
+ *     truncates differently, or another actor's grant is what reads back, this is where it surfaces
+ *     instead of silently binding a permission to a row it was never matched to.
+ *
+ * 🔴 A CONFIRM MISMATCH REVOKES THE FRESH GRANT, AND MARKS THE USER FAIL-CLOSED ON THIS SERVER. That is a
+ * heavy consequence and it is the intended one: the live permission is not the one this cap was chosen
+ * for, and the alternative — leaving it standing — is a permission whose bound nobody can name. If CDP's
+ * echo behaviour ever changed globally, every mint would land here and every delegated send would stop,
+ * which is the correct direction for a control that bounds a person's money.
+ *
+ * 🔴 NEITHER PHASE TAKES A USER ID OR AN EXPIRY FROM THE CALLER. The identity comes from
+ * `validateAccessToken`; the reserved instant comes from the store; the live instant comes from CDP.
+ */
+export async function reserveDelegationCap(runtime, rawInput, caller) {
+    const services = servicesOf(runtime);
+    assertDelegationCaller(services, caller);
+    const input = parseWith(DELEGATION_CAP_INPUT_SCHEMA, rawInput);
+    if (!services.capStore.available) {
+        return refuse('DELEGATION_CAP_STORE_UNAVAILABLE', `the per-swap cap cannot be recorded on this server, so nothing would enforce it (${services.capStore.unavailableReason ?? 'store unavailable'})`);
+    }
+    /**
+     * 🔴 THE STAGED-DEPLOY GATE, ON RESERVE ONLY (gate finding, CRITICAL 2 — the first rolling deployment).
+     *
+     * With `DELEGATION_MINT_ENABLED` false — the default in code — no NEW permission can be created on
+     * this worker, so there is no cap-bearing grant a still-serving cap-unaware binary could execute at
+     * the shared ceiling. That is the fence the ruleset handshake cannot be for the FIRST rollout, because
+     * the binary that would have to honour it predates it.
+     *
+     * 🔴 AND CONFIRM IS DELIBERATELY NOT GATED. Confirm binds a permission that ALREADY EXISTS at Coinbase
+     * to the reservation it was minted for. Refusing it would leave a live grant with no record — which is
+     * fail-closed for sending, but strictly worse for the person: an unbindable permission they have to
+     * find and revoke. The flag is flipped false→true by the runbook, so the only mid-flow flip is
+     * on→off, and letting an in-flight mint finish binding is the safe half of that.
+     *
+     * Sends under permissions that already stand are untouched, and REVOKE is never gated: pausing the
+     * creation of authority must never pause its withdrawal.
+     */
+    if (input.phase === 'reserve' && !services.mintEnabled) {
+        return refuse('DELEGATION_MINT_PAUSED', DELEGATION_MINT_PAUSED_MESSAGE);
+    }
+    const user = await userFromAccessToken(services, input.accessToken);
+    return input.phase === 'reserve'
+        ? reservePhase(services, runtime, user.userId, input)
+        : confirmPhase(services, runtime, user.userId, input);
+}
+/** The RESERVE phase: claim a free instant, record the cap against it, hand back what to mint with. */
+async function reservePhase(services, runtime, userId, input) {
+    const nowMs = runtime.nowMs();
+    /**
+     * The LATEST instant this permission may carry — the person's own duration, on a whole second. The
+     * ladder never returns anything after it, so an offset can only ever shorten a grant.
+     */
+    let latest;
+    try {
+        latest = boundedDelegationExpiry(input.requestedDays, nowMs);
+    }
+    catch (error) {
+        return refuse('DELEGATION_INPUT_INVALID', error instanceof Error ? error.message : 'the requested expiry is not usable');
+    }
+    let reservation;
+    try {
+        reservation = await services.capStore.reserve(userId, input.mintKey, latest.expiresAt, input.perSwapCapUsd, nowMs);
+    }
+    catch (error) {
+        if (error instanceof DelegationCapExpiryUnavailableError) {
+            return refuse('DELEGATION_CAP_EXPIRY_UNAVAILABLE', 'no free expiry instant is available for this delegation right now; nothing is reserved — try again in a moment');
+        }
+        // The claim (or the record beside it) failed. Nothing is cached either — the store writes disk
+        // first — so the honest answer is that nothing was reserved, never a success the caller mints against.
+        return refuse('DELEGATION_CAP_STORE_UNAVAILABLE', 'the per-swap cap could not be written durably; nothing is reserved and no permission should be minted');
+    }
+    return capResult('reserve', reservation.record, reservation.outcome === 'reserved');
+}
+/**
+ * The CONFIRM phase: the instant CDP holds must BE the instant that was reserved, and the reservation
+ * must still be confirmable. Promotes it to confirmed-active in one durable write; on a mismatch it
+ * revokes the fresh grant.
+ */
+async function confirmPhase(services, runtime, userId, input) {
+    const nowMs = runtime.nowMs();
+    const grant = await services.rig.rig.readDelegation(userId);
+    const grantMs = grant ? Date.parse(grant.expiresAt) : Number.NaN;
+    if (!grant ||
+        !Number.isFinite(grantMs) ||
+        grantMs <= nowMs ||
+        revocationRequested(services.rig.rig, userId, grant.expiresAt)) {
+        return refuse('DELEGATION_NOT_ACTIVE', 'no active delegation reads back for this end user, so there is nothing to confirm');
+    }
+    let outcome;
+    try {
+        outcome = await services.capStore.confirm(userId, input.mintKey, grant.expiresAt, nowMs);
+    }
+    catch {
+        return refuse('DELEGATION_CAP_STORE_UNAVAILABLE', 'the reservation for this mint could not be read or promoted, so nothing is confirmed');
+    }
+    switch (outcome.outcome) {
+        case 'confirmed':
+        case 'already_confirmed':
+            return capResult('confirm', outcome.record, outcome.outcome === 'confirmed');
+        case 'unreserved':
+            return refuse('DELEGATION_CAP_UNRECORDED', 'no per-swap cap was reserved for this mint on this server, so what the person agreed to is unknown; mint the permission again');
+        case 'not_reservable':
+            return refuse('DELEGATION_CAP_UNRECORDED', `the reservation for this mint is ${outcome.state} and can no longer be confirmed; mint the permission again`);
+        case 'superseded':
+            /**
+             * 🔴 NEVER REVIVED. This reservation WAS confirmed and a later one replaced it; promoting it again
+             * would bring a replaced permission back, and on a wider cap that is the widening this whole unit
+             * exists to prevent.
+             */
+            return refuse('DELEGATION_CAP_SUPERSEDED', 'this permission was replaced by a later one and is not brought back; mint the permission again');
+        case 'cancelled':
+            /**
+             * 🔴 THE PERSON PRESSED STOP WHILE THIS PERMISSION WAS BEING CREATED (gate finding, r4: "Add a
+             * durable revoke generation so Stop cancels already-reserved/in-flight mints"). The fresh grant
+             * is taken away rather than left standing — a Stop that leaves a permission behind is not a Stop.
+             */
+            return revokeOnCancel(services, userId, nowMs);
+        case 'expiry_mismatch':
+            return revokeOnMismatch(services, userId, nowMs);
+    }
+}
+/**
+ * A Stop landed between this mint's reservation and its confirmation. The grant exists at Coinbase and
+ * the person has said they do not want it, so it is revoked here and nothing is ever confirmed for it.
+ */
+async function revokeOnCancel(services, userId, nowMs) {
+    let revoked = false;
+    try {
+        await services.rig.rig.revoke(userId);
+        revoked = true;
+    }
+    catch {
+        // Issued and not confirmed. The refusal is the same either way — nothing is confirmed here.
+    }
+    void nowMs;
+    return refuse('DELEGATION_CAP_CANCELLED', `this permission was stopped while it was being created; ${revoked ? 'it has been revoked' : 'a revoke was issued and could not be confirmed'} and nothing is confirmed for it — allow a new one if you still want it`);
+}
+/**
+ * 🔴 A MISMATCH TAKES THE FRESH GRANT AWAY. The live permission is not the one this cap was reserved
+ * for — CDP stored something else, or another actor's grant is what reads back — so it is revoked rather
+ * than left standing with a bound nobody can name. The revoke is per grant: it marks only the permission
+ * that actually read back, never the person.
+ */
+async function revokeOnMismatch(services, userId, nowMs) {
+    let revoked = false;
+    try {
+        await services.rig.rig.revoke(userId);
+        revoked = true;
+    }
+    catch {
+        // Issued and not confirmed. The refusal is the same either way — this server acts under nothing.
+    }
+    await services.capStore
+        .readActive(userId, nowMs)
+        .then((active) => (active ? services.capStore.revoke(userId, active.expiresAt, nowMs) : false))
+        .catch(() => false);
+    return refuse('DELEGATION_CAP_GRANT_CHANGED', `the delegation that reads back is not the one this per-swap cap was reserved for; ${revoked ? 'it has been revoked' : 'a revoke was issued and could not be confirmed'} and nothing is submitted under it — mint the permission again`);
+}
+/** One shape for both phases, so the two answers cannot drift apart. */
+function capResult(phase, record, wroteIt) {
+    return Object.freeze({
+        phase,
+        user_id: record.userId,
+        expires_at: record.expiresAt,
+        // The value to mint with exists only on the reserve — by confirm the mint has already happened.
+        ...(phase === 'reserve' ? { mint_expires_at: record.requestedExpiresAt } : {}),
+        per_swap_cap_usd: record.perSwapCapUsd,
+        state: record.state,
+        ruleset_version: record.requiredVersion,
+        recorded: wroteIt,
     });
 }
 const STDOUT_SUPPORT_SINK = {
@@ -277,6 +532,53 @@ export async function revokeDelegation(runtime, rawInput, caller, supportSink =
             ts: new Date(runtime.nowMs()).toISOString(),
         });
     }
+    /**
+     * ══════════════════════════════════════════════════════════════════════════════════════════════
+     * 🔴 THE DURABLE RECORD IS REVOKED IN THE SAME OPERATION, AND FIRST (gate finding, round 4 CRITICAL 1)
+     * ══════════════════════════════════════════════════════════════════════════════════════════════
+     * "Revoke does not transition the durable record. The normal revoke calls only `rig.revoke()` and never
+     * `capStore.revoke()` … a new grant can inherit the revoked grant's old $5,000 cap without
+     * confirmation. This is exactly the prohibited widening direction." Its probe on the shipped fixtures:
+     * revoke → fresh process → same-expiry re-mint → `afterReportedRevoke=confirmed_active, sendStatus=sent,
+     * enforcedOldCap=5000`.
+     *
+     * The in-process revocation marker dies with the process; the RECORD does not. So the record moves
+     * first, and the CDP call happens only after it has:
+     *
+     *   · the grant is read FIRST, so the record and the marker name the SAME permission;
+     *   · a durable transition that THROWS means nothing is revoked at Coinbase either — the caller is told
+     *     to retry, rather than being left with a removed grant and a record that still says it stands;
+     *   · a transition that finds nothing to change (`false`) is NOT a failure: the record was already
+     *     revoked, or this person's live grant was minted out-of-model and was never recorded here. The
+     *     CDP revoke still goes out — a person must always be able to take a permission away;
+     *   · if the CDP revoke then fails, the record is ALREADY revoked. That is the safe direction (this
+     *     server will submit nothing under it) and a retry re-issues the CDP call.
+     *
+     * 🔴 THE EXPIRY IT CONSUMED STAYS CONSUMED. The reservation row survives as `revoked`, so no later
+     * permission minted through Otto's page or CLI can land on that instant — which is what closes the
+     * probe above: the re-minted grant gets a DIFFERENT second, matches no confirmed record, and is
+     * refused rather than inheriting anything.
+     */
+    if (services.capStore.available) {
+        try {
+            /**
+             * 🔴 ONE TRANSACTION, BOTH WRITES (gate r5 CRITICAL: "commits the generation bump and then performs
+             * the active-record revoke in a separate transaction … the process dies or stalls before
+             * `capStore.revoke()` … a fresh worker still reads the old record as `confirmed_active`").
+             *
+             * `stop` bumps the revoke generation — EVERY Stop, including one that finds no grant, the case the
+             * round-4 gate named, so a mint already in flight is cancelled at its confirm — AND moves whatever
+             * record is confirmed-active to `revoked`, inside one `BEGIN IMMEDIATE`. A crash between the two
+             * commits neither. It takes no expiry: a Stop means Otto acts under nothing for this person, which
+             * is also what the CDP-side revoke below does to whatever grant is live, so the two halves agree
+             * without a read in between that could see a different grant than either of them acts on.
+             */
+            await services.capStore.stop(userId, runtime.nowMs());
+        }
+        catch {
+            return refuse('DELEGATION_REVOKE_NOT_CONFIRMED', 'the permission could not be marked revoked durably, so nothing was revoked at Coinbase either — retry');
+        }
+    }
     try {
         // Serialized on the rig, the lock held through the read-back; the user is marked revocation-requested BEFORE
         // the raw revoke, so a plan queued behind this call is refused whatever the read-back says.