An approval carries the world it was granted against, and the recheck narrows the window

.github/workflows/ci.yml

@@ -120,12 +120,12 @@ jobs:
           set -eu
           echo "authority: $AUTHORITY ($AUTHORITY_NA not applicable)"
           echo "templates: $TEMPLATES ($TEMPLATES_NA not applicable)"
-          test "$AUTHORITY" = "verified 11/11"
+          test "$AUTHORITY" = "verified 13/13"
           # G13 is N/A on SQLite, the action's default store: SQLite has no clock of its own
-          # to diverge from (SPEC-v0.7 §8.9).
+          # to diverge from (SPEC-v0.7 §8.9). G16 is graded on both documents (§8.9).
           test "$AUTHORITY_NA" = "1"
-          test "$TEMPLATES" = "verified 6/6"
-          test "$TEMPLATES_NA" = "6"
+          test "$TEMPLATES" = "verified 7/7"
+          test "$TEMPLATES_NA" = "7"
           test -s verify-badge.json
           test -s verify-report.json
           test -s verify-report.xml

CHANGELOG.md

@@ -50,6 +50,73 @@ any change to one appears here.
   `InvalidArgument`. Verify gains G14, with a note beneath the table: a token is unique only as far
   as the operator's effect keys are, and a kernel that sees one store cannot check that two stores
   sharing a provider account never produce one effect-key string for two different effects.
+- **Precondition fingerprints** (`docs/SPEC-v0.7.md` §6, §7). `@protect(..., preconditions=provider)`
+  and `Control.execute(..., preconditions=provider)`, where the provider takes the `Action` and
+  returns a mapping of the state an approval depends on. A precondition fingerprint **narrows**
+  the window between a human's approval and the action's execution; it does not close it.
+  Under `APPROVE` the provider is called when the approval is requested, and the result is kept only
+  as a `sha256:` fingerprint on the request (`ApprovalRequest.precondition_fingerprint`, stored in the
+  new `approvals.precondition_fingerprint` column). On the presenting pass it is called again,
+  strictly before the store call that consumes the approval, and the action is refused with
+  `ApprovalMismatch` and a reason of its own: `precondition_changed` where the two fingerprints
+  differ, `precondition_missing` where only one side has one (a store that lost the column, or the
+  gateway and the ACS hook, which name no provider), and `precondition_unavailable` where the
+  provider raises or returns something that is not a canonicalizable mapping. Every refusal reserves
+  nothing and leaves the approval granted. On the request pass a provider that fails refuses the
+  action with `ActionDenied(reason="precondition_unavailable")` before any human is asked, and a
+  fingerprint that is computed and then **not recorded** (a store without the column, a third-party
+  `ApprovalProvider` building its own request) refuses with
+  `ActionDenied(reason="precondition_missing")` and **withdraws the request it left behind** where
+  this call can reach it: denied while it is pending, spent where a grant landed inside the window,
+  and `not_withdrawn:<status>` in the evidence where neither write was possible (the provider raised
+  after recording, or the store refused). §6.4 states that bound and its residual. **A withdrawal is
+  a `deny_approval`**, so `find_denied_request` returns it and the gateway's "no is an answer"
+  pre-check refuses every call for that action hash until the request expires, as though a human had
+  said no: fail-closed, bounded by the TTL, and traceable through the approver
+  `ctrlrun:precondition-not-recorded`. `ALLOW`, `DENY` and `Control.resume` never call the provider;
+  observe mode compares, records and runs.
+  The comparison is a network call, so it runs outside the atomic reservation write, and a change
+  that lands after the comparison and before the reservation is not refused: T261b opens that
+  window and asserts exactly that. Raw provider output reaches no receipt, event, log line or
+  table, and a provider's exception is recorded by its type name only. No `skip_preconditions`,
+  and no timeout parameter: a provider that hangs holds the call and reserves nothing.
+- **Migration `0005_precondition_fingerprint`** adds `approvals.precondition_fingerprint`, `NULL` on
+  every existing row, on SQLite and Postgres. A database built by 0.6.1's own code migrates keeping
+  every row, and 0.6.1 refuses the migrated database at open naming `0005`. **Stop every 0.6 process
+  before any 0.7 process opens the store**: a store checks migrations only at open, so a 0.6.1
+  process already running would consume a fingerprinted approval with no comparison, *and* would
+  rehash every `v4` receipt under `v3`'s keys and report a correct chain as altered. The trigger is
+  the first receipt a 0.7 process writes, not the first caller that passes `preconditions=`, and
+  nothing in the new process can see the old one.
+- **G16 in `ctrlrun verify`**, "a moved fingerprint is refused" before the reservation, under
+  `ctrlrun.guarantees/v3`. Verify supplies its own provider, because a provider is named in code
+  that verify does not read, and the report says so beneath the table; `not applicable` only where
+  no action requires approval. The store conformance suite gains a `precondition-fingerprint` case
+  and a broken-store fixture that fails it by name.
+
+### Changed
+
+- **`ctrlrun.receipt/v4`**, with `precondition_at_request` and `precondition_at_recheck`, and the
+  first receipt-schema bump that does not report older receipts as altered. A receipt read from a
+  store is now hashed as the document it was read from (`docs/SPEC-v0.7.md` §6.11, amending
+  `SPEC-v0.6.md` §6.4's last bullet), so every `v3` receipt a released 0.6 wrote still rehashes to its
+  stored hash and a chain spanning `v3` and `v4` verifies end to end. A key added to a stored
+  receipt, a relabelled `schema`, a removed one or an unknown one is `content_altered` at its `seq`,
+  and no longer something a reader could miss. **Visible**: `to_dict()`, `ctrlrun receipts --json`
+  and `ctrlrun inspect` render each receipt under its own schema, so a pre-v0.6 receipt shows its
+  own `v1` or `v2` label and keys where 0.6.1 showed `v3`. Upgrade every reader before any writer:
+  a `v4` JSONL line handed to 0.6.1 rehashes wrongly.
+- **`ctrlrun verify` prints each distinct note once**, where it printed only the first note in the
+  report, which would have dropped G16's beneath G3's. CI's `verify` job expects `verified 12/12`
+  and `verified 7/7`.
+- **A receipt chain reader no longer stops at a row it cannot hash.** A stored document holding a
+  value with no canonical form (a float, a lone surrogate) made `verify_chain` raise, so one
+  tampered row ended the walk: `ctrlrun receipts --verify-chain` exited with no report and a forged
+  field at another `seq` went unnamed. Such a row is `content_altered` at its `seq`, named by the
+  refusal's type and never its message.
+- **`APPROVAL_CONSUMED` carries what the presenting pass compared**, where a precondition was
+  compared, so a suspended action's resumed leg, whose receipt is the only one it gets, records the
+  comparison its first leg made.
 
 ### Fixed
 

docs/SPEC-v0.3.md

@@ -1037,21 +1037,27 @@ checks against the parent's subject but does not authenticate — `--as` is an a
 as one (§5.7, §13). An unqualified MUST above a table containing its own exceptions would teach an
 implementer that delegation is authenticated.
 
-| Entry point | Builds an `Action` | Resolves identity | Evaluates authority |
-|---|---|---|---|
-| `@protect` → `Control.execute` | yes | yes (§3.2) | yes |
-| `Control.execute` called directly | no — the caller built it | no; the in-process trust boundary (§3.1) | yes |
-| `Control.evaluate` | no | no | yes — returns the combined §4.6 decision |
-| `Control.resume` | rehydrated from the store | no — the principal is the held action's | evaluated and recorded, not re-decided (§5.6.1) |
-| `Control.delegate` / `Control.revoke` | no — creates authority | checks `by` is unexpired (§5.3 rule 0) | the six checks of §5.3 |
-| The gateway's `tools/call` | yes | yes (§8.2) | yes, before the approval gate (§8.3) |
-| `ctrlrun.acs`'s request hook | yes | yes (§8.4) | yes, before the approval gate (§8.3) |
-| `ctrlrun.verify.run` | no - it drives the rows above | no - it synthesizes principals for a scratch store | no - it asserts that the rows above do |
-| An adapter's protected tool -> `@protect` -> `Control.execute` | yes - `@protect` does, from the bound call | yes (§3.2), from the `Control`'s provider | yes, before the approval gate |
-| `ctrlrun.adapter.needs_approval` -> `Control.evaluate` | yes - **core** builds it; the adapter supplies neither a principal nor an `Action` | yes (§3.2), by `Control.resolve_principal` | yes - the combined §4.6 decision, and it writes nothing |
-| `ctrlrun.adapter.InterruptApprovalProvider.wait` -> `grant_approval` / `deny_approval` | no - it records an answer about an action that already exists | no - the principal was resolved when the request was created | **no**, and `SPEC-v0.5.md` §4.1 argues why: a grant authorizes nothing on its own, and `Control.execute` decides the action again in full before consuming it |
-| `ctrlrun mcp-operator`'s read tools | no | **no** - they are consulted for nothing, and `SPEC-mcp-operator.md` §4.1 argues why: a provider that ran on every read would make an expired credential turn `receipts` into a refusal | no - they report what the rows above already decided |
-| `ctrlrun mcp-operator`'s write tools -> `grant_approval` / `deny_approval` / `resolve_effect` | no - each answers about an action or an effect that already exists | yes, from the configured `IdentityProvider` and from nothing else; a decline, a raise, an expiry and a principal with no `user` are four distinguishable refusals (`SPEC-mcp-operator.md` §3.3) | **no**, for `SPEC-v0.5.md` §4.1's reason, restated in `SPEC-mcp-operator.md` §4.3: a grant authorizes nothing on its own |
+| Entry point | Builds an `Action` | Resolves identity | Evaluates authority | Rechecks preconditions (`SPEC-v0.7.md` §7) |
+|---|---|---|---|---|
+| `@protect` → `Control.execute` | yes | yes (§3.2) | yes | yes, under `APPROVE`, where the decorator names `preconditions=`, before each store call that consumes the approval; refuses a fingerprinted approval where it names none |
+| `Control.execute` called directly | no — the caller built it | no; the in-process trust boundary (§3.1) | yes | yes, as above, where the call passes `preconditions=` |
+| `Control.evaluate` | no | no | yes — returns the combined §4.6 decision | **no**: it writes nothing and consumes nothing |
+| `Control.resume` | rehydrated from the store | no — the principal is the held action's | evaluated and recorded, not re-decided (§5.6.1) | **no**: `SPEC-v0.6.md` §7.2.3, refusing would strand a reservation the remote may be acting on |
+| `Control.delegate` / `Control.revoke` | no — creates authority | checks `by` is unexpired (§5.3 rule 0) | the six checks of §5.3 | **no**: they consume no approval |
+| The gateway's `tools/call` | yes | yes (§8.2) | yes, before the approval gate (§8.3) | **no provider**, and it refuses a presented approval that carries a fingerprint (`precondition_missing`) |
+| `ctrlrun.acs`'s request hook | yes | yes (§8.4) | yes, before the approval gate (§8.3) | **no provider**, and refuses a fingerprinted approval, as the gateway |
+| `ctrlrun.verify.run` | no - it drives the rows above | no - it synthesizes principals for a scratch store | no - it asserts that the rows above do | informational: it drives the first two rows with its own provider for G16 |
+| An adapter's protected tool -> `@protect` -> `Control.execute` | yes - `@protect` does, from the bound call | yes (§3.2), from the `Control`'s provider | yes, before the approval gate | yes, as the `@protect` row |
+| `ctrlrun.adapter.needs_approval` -> `Control.evaluate` | yes - **core** builds it; the adapter supplies neither a principal nor an `Action` | yes (§3.2), by `Control.resolve_principal` | yes - the combined §4.6 decision, and it writes nothing | **no**, for `Control.evaluate`'s reason |
+| `ctrlrun.adapter.InterruptApprovalProvider.wait` -> `grant_approval` / `deny_approval` | no - it records an answer about an action that already exists | no - the principal was resolved when the request was created | **no**, and `SPEC-v0.5.md` §4.1 argues why: a grant authorizes nothing on its own, and `Control.execute` decides the action again in full before consuming it | **no**: it records an answer, and `Control.execute` rechecks before consuming |
+| `ctrlrun mcp-operator`'s read tools | no | **no** - they are consulted for nothing, and `SPEC-mcp-operator.md` §4.1 argues why: a provider that ran on every read would make an expired credential turn `receipts` into a refusal | no - they report what the rows above already decided | **no**: they read |
+| `ctrlrun mcp-operator`'s write tools -> `grant_approval` / `deny_approval` / `resolve_effect` | no - each answers about an action or an effect that already exists | yes, from the configured `IdentityProvider` and from nothing else; a decline, a raise, an expiry and a principal with no `user` are four distinguishable refusals (`SPEC-mcp-operator.md` §3.3) | **no**, for `SPEC-v0.5.md` §4.1's reason, restated in `SPEC-mcp-operator.md` §4.3: a grant authorizes nothing on its own | **no**: a grant authorizes nothing on its own; the recheck is at consumption |
+
+The fifth column is added by `SPEC-v0.7.md` §7, which argues every cell, the "no"s as
+deliberately as the "yes"es. v0.7 adds no entry point; it adds a check to one, the precondition
+recheck on `Control.execute`'s presenting pass, which **narrows** the window between a human's
+decision and the effect and does not close it (`SPEC-v0.7.md` §6.7). Recorded here in the same
+commit as the code, as §7 requires.
 
 The `ctrlrun.verify.run` row is **informational**, added by `SPEC-v0.4.md` §3.9 and §9.4. The
 three adapter rows are added by `SPEC-v0.5.md` §4.1, which states each cell with its argument;