buyer: settle delivered work automatically, and free reservations a seller abandoned

[orveth]

The seller is paid in seconds, automatically, and a job that never delivers stops holding the buyer's money hostage.

Today an awarded job sits until a human runs collect, and a reservation left by a seller that simply stopped is only freed by restarting the daemon. This wires the other half of the trade loop: the buyer watches for delivered results and settles them itself, and it keeps reconciling while it serves.

The sentence that makes auto-spend reviewable

The watcher commits no new money; it converts a reservation the award created.

It pays only inside an envelope the buyer already reserved, for a job the buyer already awarded. That is why this is not a new spend authority — and it is the claim the rest of this description is here to substantiate.

The decision I most want reviewed: the verify predicate is INHERITED, not rebuilt

The slice was chartered to add an artifact predicate before any pay — commit-id + job-hash binding for every job, exact content where the job spec pins output. I did not build one, deliberately. Every part of it is already enforced in-tree, upstream of every spend:

• the job-hash is recomputed from the buyer's own signed offer and the seller's result must echo it exactly, else refuse (job_lifecycle.rs, accept path) — a check, not an echo of the seller's number;
• the amount comes from the offer (buyer-signed authority), never the seller-authored result amount;
• the commit-oid is required on the result and bound at accept, and the machine tip-match against bind.commit_oid runs inside authorize_pay, before any spend;
• the seller co-signature is required before any durable bind and verified pre-pay;
• the creq is verified field by field, fail-closed; the realized mint is frozen at accept; single-settlement is held under a per-job lock;
• "exact content where the spec pins output" is ContentPolicy, already applied in authorize_pay, with a floor() default when the spec pins nothing.

A second predicate here would be a second money-authority surface that can drift from the sealed one. So instead of new checks, this PR proves the watcher-triggered entry reaches the existing ones (see the money tooth below). Please review this as a decision, not as an omission — if you disagree, the right argument is "the inherited gate is insufficient because X", and I'd want to hear it.

One path to the spend gate

The collect RPC's whole body — money lock → budget gate → pay-then-flip — is lifted into a single settle_job. The RPC renders JSON over it; the watcher calls the same function. The daemon now has exactly one route to the spend gate, so "can the watcher reach around a money gate?" is answered by construction rather than by audit. Error mapping is preserved exactly.

The subscription is the wake, the fetch is the truth

An arriving result event is never evidence. It only says "look again", and optionally narrows which job to look at. What may be paid is read from durable state — an award whose reservation is still reserved — and decided entirely by the sealed pay path. A forged, replayed, or malformed result costs at most a wasted fetch.

The work set is derived (awards ⋈ reservations WHERE state='reserved'), not tracked as a new state, so no second lifecycle can disagree with the ledger the budget already trusts.

The award record itself is written at the one reserve-then-award seam both the manual and background award paths publish through — recording at the two call sites would let one drift. A store failure there does not fail the award: the event is already public and the reservation already held, so reporting failure would be untrue and would release genuinely committed funds. It names the consequence instead.

The boot re-check is the watch loop's first action. It sweeps before it ever waits, because a delivery that landed while the daemon was down has no event to replay — that sweep is the collect-saga boot pass the charter asked for.

Two defects I found in my own loop, fixed and toothed

1. Backstop starvation. My first version re-armed a sleep inside the select!, so the backstop reset on every arriving event — including the ones the watcher ignores, which reset it without sweeping. Steady traffic would have starved it indefinitely, killing it in exactly the case it exists for: a result event that was missed. Now a fixed-cadence interval.
2. A closed subscription stopped the watcher. Settling never depended on that subscription (the collect path opens its own client), so returning stranded every future delivery. Now it degrades loudly to periodic sweeps.

Both are the "liveness mechanism silently dead while everything looks fine" class, and correctness teeth are structurally blind to them — so watch_loop takes its sweep action as a parameter and both are tested with an injected counter: no relay, no clock control.

Freeing an abandoned reservation

The reconcile now runs on a slow timer as well as at boot. No new logic decides what may be released — the existing classification already rules it, including the part that matters most, that an ambiguous payment is never auto-released. It is already time-based rather than dependent on the seller announcing failure: a claim stops being live at the offer deadline whether or not feedback is ever published.

Gather runs without the money lock (per-job relay I/O would block trades for seconds); only the apply takes it. That ordering makes it impossible to release a reservation in the window after a payment melted but before its reserved → spent flip.

Every pass is reported, including the pass that changed nothing — a path that prints only when it acts is indistinguishable in a log from one that has stopped running. Released jobs are named, and the examined count is in the line because it is also the per-pass relay-fetch count, so #180's amplification is visible while it grows.

The #176 chain, in full

#176 was escalated to money-path mandatory on the strength of a relay-operator confirmation, requiring the buyer to hand-roll an auth-and-resend on the payment write. I corrected the premise at the source and then reversed the change. The chain, so the gate reviews a decision rather than noticing an absence:

1. Mandated. The relay operator confirmed from relay source that 1059 writes are auth-gated unconditionally and a lost race is a deterministic silent drop with no SDK resend.
2. Premise corrected. That confirmation was authoritative about the relay, but the claim it was read as supporting was about the client. Relay::send_event (nostr-relay-pool-0.44.1) already does auth-and-resend on the auth-required: prefix — the issue cited wait_for_ok in isolation, one level below where the resend lives. Every precondition holds (prefix match, auto-auth default on, signer present, bounded auth + ok waits), and no silent-loss path exists: payment_sent returns Err on an empty accepted-set. Hand-rolling ours would have been a third publish of the same event on a money path.
3. Reversed. With the silent-drop claim dead, the payment write is simply correct money code running today — the same status as the receipt write, which we had already declined to touch. Under the rule that we do not touch working money paths mid-slice for latency, the reroute was dropped.

What survives is the real residual: automatic_authentication(true) stated explicitly as a drift guard against an upstream default flip, plus a contract tooth. Demonstrated on the wire — same write, auto-auth on lands, off is refused with the literal auth-required: string. Honest limitation: the SDK default is already true, so deleting that line changes nothing today; it guards the dependency boundary, not local deletion.

Named residue — not silent

The charter said drive_auto_award would become event-driven. It did not. The only production consumer of the event-driven wait is the get_job RPC's wait_for; drive_auto_award still polls on its interval. That is a claim-wait (3402) — a different consumer from the delivery watch — and folding it in would widen a money slice for latency, so it is filed as a follow-up rather than done here.

Also filed from this work: the boot-path per-job fetch pattern (#180), which the reconcile cadence is currently holding down rather than fixing.

Evidence

Baseline on the frozen base tip, then per piece: applied with count reconciliation, red-on-revert with the named failure, restored clean.

• baseline 589 passed / 0 failed / 3 ignored, RC=0
• final 596 / 0 / 3, RC=0 — +7 tests, reconciling exactly (several assertions were folded into existing tests rather than spawning parallel ones)
• red-on-revert: 8 mutations, all production-side, each restored before the next so a tooth can only go red for its own mutation. Every one behaved as predicted:
  • delete the award record at the seam → seam tooth red
  • widen the work set to include spent → derivation tooth red
  • make the watcher sweep nothing → money tooth red on its non-vacuity anchor
  • swap the interval back to a per-iteration sleep → starvation tooth red, observing exactly the predicted broken value (1 sweep)
  • return on a closed subscription → degrade tooth red
  • silence the empty reconcile pass → reporting tooth red
  • drop the released job ids → reporting tooth red
  • Burst tick behaviour → green, as predicted: recorded because it states honestly what the no-overlap tooth does not cover — overlap is structurally impossible in a single-task loop that awaits its pass, so no compiling mutation can produce it
• the revert harness treats a mutation that fails to compile as inconclusive, never as a bite — a non-compiling revert proves nothing.

The money tooth deserves its own note: every assertion in it is a "nothing happened" assertion (zero spend, no journal, no files, reservation intact), so all of them would pass if the watcher had never woken at all. The anchor is that accept writes the pay-bind before the pre-pay co-signature gate refuses — so the bind file existing is positive proof the watcher really drove that job. Counterparty events are published from a separate client, because one nostr-sdk client cannot observe its own events and that trap bites fixtures exactly as it bites production.

No live spend has been run. The dogfood trade is held pending explicit sign-off.

[orveth]

Gate: CODE-GATE PASS on 26c523b (both bounce items closed with production-line red-on-reverts re-run at the gate; #176 SDK reading verified against nostr-relay-pool source; 4 money/liveness reverts re-proven; all gate combos 0-failed). Merged to dev for integration testing per the rolling model — stays open for main review. Dogfood latency receipt joins when the seller seat wakes.