[Amperstrand]

STACKED ON #780 — merge #780 first

Base is fix/752-swap-empty-outputs so the diff shows only this change; retarget to main after #780 merges. This PR consumes the machinery #780's pin (gonuts v0.13.1) delivered.

What

#703's map named this the program's top work item: the resume half of #497 was built but unwired — gonuts v0.13.1 records a pending-swap intent (exact request bytes, secrets, blinding factors) atomically with the counter reservation BEFORE the irreversible POST, and ResumePendingSwaps replays intents (replay succeeds when the mint honours NUT-19 replay within its cache window — the "deterministic signing" reading was corrected by the #497 research; see the scoping section below), but zero call sites existed. The value was durable; the recovery was not automatic.

One wiring call, off the boot critical path: TollWallet.New runs the recovery pass after LoadWallet in a background goroutine. Design properties:

• Never blocks boot — an intent whose mint is down at boot costs its replay timeout (30 s each); the daemon binds its API first.
• No loss on deferral — the per-intent policy leaves failed replays recorded (never deleted on a bad guess); a mint that returns later recovers its value on the next wallet load.
• Idempotent — SaveProofs is keyed by secret; replaying an already-saved proof is a no-op.
• Log-observable — recovered sats / failed-pass counts logged per load.

The crash-window test (end-to-end, -race)

A stub signing mint (mirrors the fork's harness) fails the first swap answer — client-side indistinguishable from a drop after the mint processed the request, exactly the #497 window. Receive errors; the next wallet load replays the intent and restores the balance — the "lost" value becomes spendable without a second spend:

--- PASS: TestWalletLoadRecoversCrashedSwapIntent (5.24s)
    [balance recovered via >=2 mint swap calls: intent replayed, proofs stored]
--- PASS: TestWalletLoadKeepsIntentWhenMintStaysDown (17.25s)
    wallet load with mint down: 16.3s (LoadWallet baseline; recovery deferred to background)

The mint-down test's timing bound is a discriminator, not a stopwatch: LoadWallet's own dead-mint baseline is ~16 s (its AddMint retry ladder — pre-existing, measured with the wiring stashed); a synchronous recovery would add ≥30 s/intent. The assertion sits between them.

Verification

• src/tollwallet: full module suite green under -race (2 new tests).
• make go-battery: green through every module except the two pre-existing merchant timing failures documented since test(contract): FROM-ARG scope fence for cloud-lab Dockerfiles #728.
• deps-sync 137/137, changelog checks clean.

Fund-safety note

Pure recovery wiring — no money-path semantics change: no new derivation, no new irreversible calls (the replay re-POSTs the SAME request bytes the original POST sent; a mint that already processed it returns the same signatures within its NUT-19 cache window — beyond it the mint refuses with 11001 already-spent and the intent stays journaled, per the scoping section below), no re-spend risk (inputs were consumed by the original POST or weren't). This is the CDK saga's replay-first resume, consuming the record side #780 shipped.

Updates the #703 map: Class B resume half closed; no-fund-loss on the conformance lane becomes measurable for this crash point.

---

Supersedes #771 (carrier adjudication, #665 addendum)

This PR is the single carrier for the #497 resume wiring; #771 should close as superseded when this lands (recommendation posted there: #771 (comment)). Why this one carries:

• Wiring site: TollWallet.New is the single funnel — full boot (newFullMerchant→NewWalletPort→New), degraded boot (DefaultWalletFactory→New) and the degraded→full upgrade all construct through it, so every wallet load heals and boot never blocks (test-pinned). fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's synchronous merchant-boot call pays 30 s/intent on the path to serving.
• Pin state: zero pin hunks (stacked on fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780); fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's four pseudo-version hunks are obsolete since fork v0.14.0 exists.
• Tests: in-repo -race end-to-end recovery tests vs stubbed seam tests.

Adopted from #771: the NUT-19-scoped changelog wording (its reword commit was never on its branch — the text lived only in a PR comment) and its crash-injection lane run as the model for the merge condition below. Dropped deliberately: #771's WalletPort.ResumePendingSwaps port surface — dead surface under this wiring (only the gonuts backend needs the call; cdk self-resumes on open, the sidecar daemon owns its intents).

Recovery claim, scoped (NUT-19)

The original body text said "mints sign deterministically — verified against cdk-mintd 0.17.6". That finding was corrected by the deeper #497 research (comment 2): the identical-signature replay comes from NUT-19 cached responses; cdk-mintd's default backend is in-memory with a ~60 s TTL, and beyond the window a mint that already processed the swap refuses with 11001 already-spent — replay is then refused forever, and a mint without NUT-19 never replays. In those cases the intent stays journaled (visible, not lost) pending a NUT-09 /restore fallback — fork-level follow-up. The mechanism is still a strict improvement over rc1 (value destroyed and unjournaled); the fragment, the call-site comment, and the body's claims now all carry this scoping.

Merge condition

One green tests/cloud-lab/run-crash-injection.sh run against this head (the #771 lane run validated the shared fork mechanism; this wiring differs — recovery runs concurrently with serving), plus one concurrent-traffic scenario (a Receive while a stale intent replays). Safe by construction: the replay re-POSTs journaled bytes while new swaps reserve fresh counter ranges and SaveProofs is secret-keyed.

[Amperstrand]

@felixfelix-bot — requesting cross-identity approval for this PR (#703 work item 1, the #497 resume half). STACKED on #780 (base is its branch; retarget after it merges).

What: One wiring call — TollWallet.New runs gonuts v0.13.1's ResumePendingSwaps after LoadWallet, in the background (never on the boot critical path; failed replays stay recorded for the next load; idempotent by secret-keyed saves). The record side landed with #780's pin; this makes the recovery automatic.

Why: #703's map — the resume half of #497 was built-but-unwired (zero call sites, same dead-code shape as the NUT-13 guards): value was durable but never recovered.

Evidence: end-to-end crash-window test under -race (stub mint fails the first swap answer — client-side indistinguishable from a drop after processing; next wallet load replays the intent and restores the balance, ≥2 mint swap calls, no second spend); mint-down test pins load-completes + intent-kept with a discriminator bound (16s pre-existing LoadWallet baseline vs ≥30s synchronous replay — baseline verified with the wiring stashed). Full tollwallet module -race green; battery green except the two pre-existing timing failures documented since #728.

[Amperstrand]

[release support 2026-10-09] gonuts-tollgate v0.14.0 is tagged (≡ v0.13.2 tree; carries ResumePendingSwaps/d7591d2); module verified resolving at the tag, so this PR can pin the real version rather than a pseudo-version.

• Carrier question for the maintainer before either merges: fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 (merchant boot resume + the original fork pin, lane-A-reviewed end-to-end incl. the fork's resume path) and this PR (wallet-load wiring of the same ResumePendingSwaps) are the same family. Pick the single carrier — or state the deliberate split — so the four go.mod repins land exactly once and the crash-injection lane runs against one branch.

[Amperstrand]

CHANGES-REQUESTED — the mechanism is fund-safe and the wiring site is the right one (I verified every wallet-construction path funnels through it), but this PR repeats, in three places, the exact unqualified recovery claim #771 was just called on — and per the #665 addendum's carrier question this PR should become the sole carrier of the resume feature, which makes fixing that claim before merge non-negotiable.

Fund-safety audit (same lens as the #771 review). The brick-class questions come back clean, and most of the substance is inherited rather than new: the replay mechanics live in the fork, and your base is #780's pin (gonuts v0.13.1), which contains d7591d2 — the commit lane A audited end-to-end (containment was verified via git merge-base --is-ancestor d7591d2 v0.13.1 during #780's review). This diff adds no derivation, no new irreversible calls, no re-spend path: the goroutine re-POSTs journaled request bytes via ResumePendingSwaps, and per-intent failures retain the intent. Crash-at-each-step: crash before POST → intent journaled, replayed later; crash between mint acceptance and SaveProofs → your TestWalletLoadRecoversCrashedSwapIntent (crash simulated by failing the first swap answer, balance restored on next load with ≥2 swap calls — I re-ran both new tests under -race in a clean worktree, both PASS, mint-down load at 16.35 s, right on the documented LoadWallet baseline); crash mid-replay → fork-side SaveProofs is secret-keyed so the replay is idempotent; mint down → TestWalletLoadKeepsIntentWhenMintStaysDown pins retention plus the non-blocking bound. The 30 s discriminator is sound because the dead-mint ladder is fixed-retry/fixed-delay — wall-clock stable, not load-sensitive.

The wiring site is the strong half of this PR. I audited call sites: TollWallet.New is the single funnel — full boot (newFullMerchant → NewWalletPort → New), degraded boot (DefaultWalletFactory at src/merchant/merchant_degraded.go:249 → New), and the degraded→full upgrade (newFullMerchant again) all pass through it, so every load heals, boot never blocks (test-pinned, unlike #771's synchronous merchant-boot call which costs 30 s/intent on the path to serving), and the degraded-boot self-heal property lane A verified for #771 holds here too, via the upgrade's second New. Under the cdk_wallet build the wiring is inert by construction (CDK resumes on open) and the sidecar path never constructs a TollWallet — the wiring lands exactly on the one backend that needs it, which also means #771's WalletPort.ResumePendingSwaps port surface is dead weight under this design.

1. (blocker — the recovery claim is unqualified, three times). The changelog fragment headline "A crashed swap's value is recovered automatically on the next wallet load" (changelog.d/793-resume-pending-swaps.added.md#L1-L8), the code comment "mints sign deterministically, so a re-POST returns the same signatures (verified against cdk-mintd 0.17.6)" (tollwallet.go#L96), and the body's fund-safety note all repeat the claim the fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 review rejected: per the deeper Priority: P0 — research-first: the swap crash window can silently destroy received value; the correct fix shape (pre-persisted swap intents) must be designed, not improvised. #497 research (comment 2), the identical-signature replay comes from NUT-19 cached responses, cdk-mintd's default backend is in-memory with a ~60 s TTL, and beyond the window the mint answers 11001 "Proofs already spent" — replay is then refused forever, and a mint without NUT-19 never replays. A router power-loss minutes after the crash is not recovered by this mechanism; the value is journaled-not-lost, pending a NUT-09 /restore fallback that is fork-level follow-up work. The scoped wording already exists — fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's author wrote it when applying that review (#771 comment, head c0f638b) — note that commit is not on fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's branch (its head b3ce6d54 still carries the unscoped fragment), so lift the text from the comment. Also consider fixed rather than added: Priority: P0 — research-first: the swap crash window can silently destroy received value; the correct fix shape (pre-persisted swap intents) must be designed, not improvised. #497 is a value-destruction bug this closes, and fixed is the stronger release-notes claim once scoped.

2. (criterion 12 — take the carrier role explicitly; adjudication per the v0.6.0 pre-tag readiness — test plan, approved-idle PRs, and owed decisions #665 addendum). fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 and feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793 wire the same fork capability at different sites. Deep-compare: mechanism — feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793's background-every-load supersedes fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's synchronous merchant-boot call (covers every construction path, never delays serving, retry on any future load); pin state — feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793 rides fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780's pin cleanly while fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 still carries four pseudo-version pin hunks that are obsolete now that fork v0.14.0 exists; test coverage — feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793's in-repo -race end-to-end tests exercise the actual recovery, fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's seam/merchant tests only stub it (its real evidence is the external crash-injection lane); changelog — both currently unqualified (see 1). One carrier: this PR. State the supersession in the body (the test(merchant): late-receive outcome selection raced the owed-grant ERROR line — the #681 "regression" was a racy assertion #718→fix(merchant): de-flake the suite trio — late-outcome picker, first-reachable re-arm, owed-grant retry clock (#731, #732, #733) #774 precedent), so fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 can be closed as superseded rather than silently dropped — I've posted the supersession recommendation on fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 separately. What feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793 should absorb from fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771: the scoped fragment wording (item 1) and one crash-injection lane run against this head — fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's lane PASS validates the fork mechanism both share, but your wiring difference (recovery concurrent with serving, not before it) is exactly what a lane re-run should exercise; make it a merge condition as it was for fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771.

3. (goroutine lifecycle). The fire-and-forget go func() (tollwallet.go#L106) has no cancellation or shutdown coordination: a daemon Shutdown racing an in-flight replay pass gets a logged error and retained intents — benign under the journaling semantics, but the reasoning lives only in this review. A sync.WaitGroup consulted by Shutdown, or at minimum a comment stating the race is safe because replay is idempotent and intents survive, would keep the next reader from "fixing" it into something that blocks boot. Related operator-log note (the async analogue of fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's balance-snapshot finding): the boot "Wallet Balance" line will never include recovered value; your per-pass recovery log line is the reconciliation point — one sentence in the fragment saying so would pre-empt confusion.

4. (concurrent-traffic interleaving untested). With recovery in the background, the daemon can serve new payments while a stale intent replays. Safe by construction — the replay re-POSTs persisted bytes while new swaps reserve fresh counter ranges and SaveProofs is secret-keyed — but no test exercises Receive-during-resume. Fold one such scenario into the crash-injection lane run from item 2 rather than adding a unit test for it.

5. (minor) The mint-down test leaks wb without Shutdown (deliberate — the point is the intent outlives the process) — fine on Linux; a one-line comment saying the un-link is intentional would help. Base freshness: stacked on fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 by design; retarget to main after fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 lands and note that if fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 repins to v0.13.2/v0.14.0 (per its review) this branch inherits it mechanically.

Freeze compatibility: stop-ship-shaped — this is the P0 feature's landing vehicle and the design is right — but land order is #780 → this PR with the scoped claim in fragment and comment, and one green crash-injection lane run against this head (plus the concurrent-traffic scenario) as the merge condition.

[Amperstrand]

Review items applied — head b9b47c90 (commit on top of the original; base still fix/752-swap-empty-outputs for the clean stacked diff).

• Scoped claim (item 1): fragment rewritten as 793-resume-pending-swaps.fixed.md — headline scoped to the NUT-19 cache window, the boundary stated (cdk-mintd in-memory ~60 s TTL → 11001 already-spent beyond it; intent stays journaled, visible-not-lost, pending NUT-09 /restore fork follow-up), plus the operator reconciliation note (boot balance line excludes recovered value). The tollwallet.go comment carries the same scoping and the Priority: P0 — research-first: the swap crash window can silently destroy received value; the correct fix shape (pre-persisted swap intents) must be designed, not improvised. #497-comment-2 correction of the cdk-mintd-0.17.6 finding.
• Carrier role (item 2): supersession section added to the PR body; recommendation comment stands on fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771. What was adopted vs dropped is enumerated there.
• Goroutine lifecycle (item 3): comment-only — fire-and-forget documented as deliberate with the safety argument (idempotent re-POST, retained intents); a WaitGroup consulted by Shutdown would make Shutdown pay the 30 s replay timeout, which is the wrong direction, so the comment route was taken.
• Test comment (item 5): the deliberate non-shutdown of wb is now stated.

Verified after the edit: gofmt/go vet clean, both new tests re-pass under -race (27 s), changelog fragments suite 18/0, duplicates check 4/0.

Item 4 (concurrent-traffic scenario + lane run on this head) cannot run from this host — no usable docker daemon here (the crash-injection lane needs it) and this is not the ai-legion rig. The merge condition is stated in the PR body; the lane owner needs to run tests/cloud-lab/run-crash-injection.sh against b9b47c90.

[Amperstrand]

Scoped-claim check (author-side, review item 1): the branch already carries the full scoping — remaining gap was body-only, now fixed there too. Head unchanged: b9b47c9.

Verified on the current head (b9b47c9, the 18:38 docs(resume): scope the recovery claim commit):

• Fragment changelog.d/793-resume-pending-swaps.fixed.md: headline carries the boundary verbatim ("when the mint honours NUT-19 replay within its cache window") plus the beyond-TTL consequence sentence (11001 already-spent, intent stays journaled — visible, not lost — pending the NUT-09 /restore fork follow-up), re-categorized added→fixed, and the operator-log reconciliation note.
• Call-site comment (tollwallet.go, the recovery goroutine): same scoping, including the Priority: P0 — research-first: the swap crash window can silently destroy received value; the correct fix shape (pre-persisted swap intents) must be designed, not improvised. #497-comment-2 correction provenance and the fire-and-forget race-safety rationale. There is no separate ResumePendingSwaps doc comment on this branch by design — the port surface was dropped (body: "dead surface under this wiring"), so this comment is the contract's carrier.

Delta applied now (PR body only — no tree change): the two remaining unqualified instances are scoped in place — the "What" section's "mints sign deterministically" parenthetical and the fund-safety note's "returns the same signatures" now both carry the window boundary with a pointer to the scoping section, and that section's closing sentence reads "fragment, the call-site comment, and the body's claims now all carry this scoping."

For the parallel docker lane: behavior-tested SHA is b9b47c9 — still the head; the race the lane coordination feared doesn't materialize because nothing in the tree moved. Fragments 18/18 + duplicates green on this head.

[Amperstrand]

Rebase onto the repinned base @ head 1c51f8c (base #780 now at a5d738e, gonuts v0.14.0):

• Inherits the v0.14.0 pin (the Priority: P2 — NUT-13 residue-collision guard is dead code in gonuts v0.13.0 (Conduition disclosure): CheckCollidingKeysets never invoked; wallet-level fix belongs in gonuts-tollgate, tracked here #705 NUT-13 guard wiring) mechanically, per the review's note.
• The guard immediately caught this PR's own fixture — the stub mint advertised an invented keyset ID, exactly the forged-keyset shape Priority: P2 — NUT-13 residue-collision guard is dead code in gonuts v0.13.0 (Conduition disclosure): CheckCollidingKeysets never invoked; wallet-level fix belongs in gonuts-tollgate, tracked here #705 refuses. Fixture now derives its ID via crypto.DeriveKeysetId (the refusal line is quoted in the fixture comment as the guard working). Sibling fixtures across the module had the same disease; fixed on the base branch (fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 @ a5d738e, six files, full module -race green at the new pin).
• Review items from the CHANGES-REQUESTED were applied at b9b47c9 by the fleet lane (scoped NUT-19-window claim, fixed category, goroutine-lifecycle comment, deliberate-non-shutdown comment) — verified present in the rebase and re-tested.
• Full tollwallet module -race green on the final head (60.9s).

Remaining merge condition per the review: the crash-injection lane run against this head (1c51f8c) + the concurrent-traffic scenario — running next on the ai-legion docker host; results will be posted here.

[Amperstrand]

Rel-verify: cloud-lab crash-injection lane on #793 head 1c51f8ca — PASS per scenario: (b), (c), (d), (e); (a) SPLIT: byte-identical replay + recovery PASS, owed-grant convergence FAIL (3/3 runs) (lane rc1-793, ai-legion, docker 29.x; transcript: /root/src/rel-793-transcript.md on the lane host).

Head note: the branch moved mid-lane with a change that is not docs-only — the rebase repinned gonuts-tollgate v0.13.1 → v0.14.0 (NUT-13 keyset guard, bolt counter hardening, the missed fifth go.mod). The full battery therefore ran twice: against b9b47c90 (v0.13.1) and against the new head 1c51f8ca (v0.14.0). The wiring diff (tollwallet.go/merchant.go) is byte-identical across both heads and wallet/pending_swaps.go is identical across both fork versions; every scenario reproduced identically. Merge condition (one green stock run-crash-injection.sh + one concurrent-traffic scenario): satisfied on both heads.

• (a) crash pre-POST (intent journaled, never sent) — replay/recovery PASS, owed-grant convergence FAIL. Request-swallow killer (the mint never saw the swap), SIGKILL on marker, restart → replay re-POSTed byte-identically (sha256 199fa757…, len 3654, same hash pre-kill and post-restart), first exposure at the mint, wallet: pending swap 56cffafc… recovered 50 sats, TollWallet.New: pending-swap recovery: 50 sats recovered from crashed swap(s), health payment 200/kind-1022. But the crash intent resolved abandoned ("NUT-07: all proofs unspent after the call had ended"), owed-grants.json empty, no Owed grant applied, no AUTH for the crashed customer — reproduced 3/3 across both heads. Mechanism: with the swap never sent, the proofs are unspent at the mint until the replay lands; at boot the merchant's NUT-07 reconcile and TollWallet.New's background replay POST run unsequenced, the checkstate won every time, and terminal-abandonment fired before the replay consumed the proofs. Customer outcome: payment POST died with the container, token now spent-by-the-replay (same-token retry refused), no session, no grant, while the operator banked the 50 sats. On main this same crash abandons correctly (proofs stay unspent, customer retry works) — the background resume is what makes "unspent ⇒ abandon" unsound in this window; fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771's synchronous design sequenced replay-before-reconcile and converged owed → granted. Not a 10002/fund-safety SEV (mint clean, no re-derivation) — a customer-entitlement regression specific to the pre-POST crash shape. Fix direction: sequence the receive-intent reconcile after the resume pass for intents whose proofs the wallet holds pending swaps for (or treat "unspent + pending-swap intent exists" as still-pending).
• (b) crash post-POST pre-save (the crash-window lane: no value recovery after restart (SIGKILL between mint-signed and wallet-save) — #502/#700 acceptance FAILS on main #719 window) — PASS, stock lane verbatim (exit 0 both heads): killer swallows the mint's signed answer, SIGKILL, restart → replay within ~1 s, pending swap ffca1381…/02c92f80… recovered 50 sats, owed grant applied (allotment 3,000,000 ms = 50 sat × 60 s exactly, attempts 0), health payment 200, no 10002/duplicate-output anywhere (mint logs clean in every run). Byte-identity of the replay for this shape is hash-pinned by the (d) run (same crash shape, instrumented proxy). Boot-log evidence of the design property: "Money path listening: the API is bound and serving; mint-dependent init is still in flight" precedes the recovery line.
• (c) end-to-end purchase after resume — PASS in every run: 200 with kind-1022 session event, tags ['p','device-identifier','allotment','metric','start-time'], Amount after swap: 30, valve AUTH + fake-ndsctl AUTH <mac> for post-recovery buyers in all runs.
• (d) NEW — Receive-during-resume — PASS with the overlap proven. Lane-local hold-proxy (disclosed below) forwards the resume replay to the mint but delays delivery of its response 14 s; the moment the replay is in flight, a fresh purchase is submitted. Killer log (ms timestamps): replay HELD code=200 at 18:00:08.057 (mint answered from its NUT-19 cache), concurrent purchase's swap passed the proxy at 18:00:10.094 — fresh derivation, different sha256/len — while the replay was still held; purchase verdict 200/kind-1022/allotment + gate AUTH at 18:00:10; owed grant for the crashed customer at 18:00:13; HOLD-RELEASED 18:00:22 → pending swap 3c91e9cf… recovered 50 sats. Wallet does not serialize Receive behind the recovery pass; no counter/derivation interleaving (replay = journaled bytes, purchase = fresh range), no lost journal update, mint clean. Reproduced identically on 1c51f8ca (replay 5685e785…, concurrent 26e294f1…).
• (e) stale intent beyond the NUT-19 TTL, repeated loads — PASS. Tollgate stayed down 95 s (> cdk-mintd's 60 s in-memory cache TTL, verified in cdk-axum source DEFAULT_TTL_SECS = 60); the replay was refused exactly as the scoped claim states: HTTP 400: {"code":11001,"detail":"Token Already Spent"}. The replay attempt was byte-identical on every load (sha256 fba15969… ×4), the intent stayed journaled (OpID bytes present in /etc/tollgate/wallet.db after each of 4 loads) and visible (one named-OpID refusal line per load), no busy-loop (exactly 4 attempts across 4 loads, driver-asserted; CPU 0.03–0.05 % at rest), no recovery line ever (operator killer-mint balance stays 30 — the stuck 50 sats are journaled, not wallet-held), and the service stayed healthy (health payment 200/kind-1022). Customer side converged anyway: crash ref → owed (proofs spent), owed grant applied, AUTH recorded — the customer does not wait on the operator's NUT-09 /restore fallback.

Scratch-tree disclosures (lane-local, none part of the PR): (1) the #728 ARG GO_VERSION hoist in Dockerfile.client (#728 unmerged; image unbuildable without it on docker 29.x); (2) build.network: host in the per-run override builds (this host's build bridge has no DNS — same workaround as rel-771 and the prior #719 triage); (3) lane-only tools: the rel-771 killer variants + variant driver carried over, plus three new rc1-793 files — killerproxy-hold.py (stock crash-window behavior; post-release it holds the first watched response N seconds, everything else passes), run-crash-injection-d.sh, run-crash-injection-e.sh (drivers derived from the var driver; kill/restart sequence unchanged); (4) five isolated compose projects/subnets (172.31.82–.86), no host ports, all torn down (down -v + project images rmi'd). Gonuts pin verified resolving on-host at both v0.13.1 and v0.14.0. Second-pass caveat: the battery's post-run docker logs snapshots of upstream containers truncated to entrypoint banners — all upstream-log assertions for 1c51f8ca come from the drivers' live-grep run logs plus exec-captured journals (first-pass full logs unaffected).

Not covered by this run: the standard cloud-lab pytest suite (rel-771 already ran it against the shared mechanism; its pre-existing failure set is documented there), mint/melt crash windows (fork-level, out of scope), QEMU/router-surface behavior, and the gated lanes.

Open item for review: the (a)-shape reconcile-vs-replay ordering above — it is adjacent to this PR's merge condition rather than inside it (the stock lane and the concurrent-traffic scenario both pass), but it is a real customer-entitlement regression introduced by moving recovery to a background goroutine, and it reproduces deterministically on both heads. Cheap deterministic repro: rel-771's scenario-(a) invocation against this branch.

[Amperstrand]

Rebase-proofing applied — head ddf4fa62: the resume stub's keyset ID is now derived from its keys (crypto.DeriveKeysetId) instead of invented. Harmless under the current v0.13.1 base, required for the v0.14.0 base #780 now carries — its keyset-ID verification (tollgate #705, fork #37) would refuse the stub on rebase (same class as the ten fixtures fixed on #780). Both tests re-run green under -race. Sequencing unchanged: #780 → retarget this PR to main → crash-injection lane run on the final head.

[Amperstrand]

Correction to the comment above (raced with a parallel push): the rebase-proofing landed independently — head 1c51f8ca carries the branch rebased onto the repinned base (038558c1+a5d738ea) WITH the resume stub's derived-ID fix already applied (same crypto.DeriveKeysetId approach; my redundant local duplicate was dropped, nothing pushed from my side for this item). Both resume tests verified green under -race on 1c51f8ca this session. Remaining merge condition unchanged: one crash-injection lane run against the final head + the concurrent-traffic scenario.

[Amperstrand]

CLEAN — this is the right shape for the resume half of #497: the wiring is one background pass off the boot critical path, the recovery claim is scoped honestly to the NUT-19 window, the pin is the real v0.14.0 tag, and both new tests pass under -race in my own worktree (3.5s recovery test; the mint-down discriminator measured 16.1s — the LoadWallet baseline, proving recovery never touches the boot path). Merge condition: close #771 as superseded in the same motion (below).

I audited this with the same lens as my turn-1 review of #771, and every finding from that review is addressed here: the NUT-19/60s-TTL scoping (with the #497 comment-2 correction cited by name in tollwallet.go — including the honest note that the quick-restart harness always replayed inside the TTL), the journaled-visible-not-lost framing with the NUT-09 fallback tracked as the fork-level follow-up, the boot-balance reconciliation note, and the pin. I also re-verified the anti-brick properties at the pinned tag specifically (my earlier fork audit was at the pre-tag d7591d2): at v0.14.0, resumeOneSwap re-POSTs intent.RequestBytes verbatim and the file contains zero derivation calls — the #257/#266/#480 class cannot trigger, and the counter reservation is still the atomic pre-POST transaction the machinery promises. The fire-and-forget goroutine is safe by construction: bolt ops are thread-safe, per-intent failures retain the intent, a Shutdown racing the pass costs at most a retry next load, and SaveProofs' secret-keying makes replays idempotent.

1. (merge condition — cross-PR coordination) fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 and this PR wire the same recovery, differently. fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771: WalletPort.ResumePendingSwaps port ceremony + newFullMerchant boot wiring + the d7591d2 pseudo-pin. feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793: a direct call in TollWallet.New, background, off the critical path, real tag. This PR is strictly the better shape — simpler, boot-safe by design rather than by non-fatal handling, and honestly documented. When this lands, fix(merchant): boot resume replays journaled swap intents — close the #719 crash window (#497) #771 should be closed as superseded (its changelog.d/771-* fragment dies with it; its seam tests covered the port layer this PR deliberately skips). Two resume wirings must not both merge — they would double-fire on every boot.

2. (one-word body nit, non-blocking) The body says it "consumes the machinery fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780's pin (gonuts v0.13.1) delivered" while src/tollwallet/go.mod pins v0.14.0 — correct (the tag exists and contains the NUT-13 guard the test credits), but a reader reconciling the pin will pause. One clause — "…delivered (this branch bumps the pin to the v0.14.0 tag for the NUT-13 keyset-ID verification)" — saves them the pause.

3. (verified, for the record) The test fixture is the strongest part: a stub mint doing real blind signing with a derived keyset ID — and the comment that the fork's NUT-13 guard fired on the fixture's first draft is the guard verified working from the tollgate side (a two-way check between the repos). The swapCalls >= 2 assertion proves the recovery replayed the intent rather than recovering by accident; the wallet-A-shutdown step models the real db-lock release process death performs. The mint-down test's timing bound (30s vs the ~16s baseline vs a synchronous ≥46s) is a genuine discriminator for the off-critical-path claim — I measured 16.1s.

Residuals, all tracked and correctly out of scope: mint/melt intents (fork #33), the NUT-09 restore fallback beyond the cache window, the sidecar path (daemon-owned). The changelog fragment follows the convention, links the PR, and its boundary paragraph is the honest-scoping model I'd hold up for every fund-safety entry from now on.

Lane status note: the crash-injection acceptance (run-crash-injection.sh / the variant driver) is running on ai-legion against this stack as I write (the cl-crash-793* project legs) — I deliberately did not launch a competing run against a timing-sensitive kill harness mid-flight. My verdict above rests on the diff, the fork audit at the pinned tag, and my own -race run of both tests; the lane's posted verdict should close the loop on the end-to-end leg.

Freeze compatibility: exactly stop-ship — this is the fund-safety P0 of the batch, the design is the CDK-shaped one, and the residual risk (the >60s window) is now documented and journaled rather than silent, which is the honest ceiling for this release.

[Amperstrand]

Addendum to the rel-verify comment above — the (a)-finding's race is now proven both ways by intervention (same head 1c51f8ca, run cl-crash-793f; transcript §Appendix B).

The (a)-shape failure was inferred to be an ordering race between the merchant's boot NUT-07 reconcile (checkstate) and TollWallet.New's background replay. To prove it, the lane re-ran the identical scenario-(a) crash with one lane-local intervention (killerproxy-raceflip.py, disclosed: crash window byte-identical to the reqswallow killer; post-release it holds the tollgate's first POST /v1/checkstate 6 s while the replay's /v1/swap passes immediately):

19:33:45.492  /v1/swap PASSED-THROUGH            ← replay reaches the mint FIRST
19:33:45.494  /v1/checkstate CHECKSTATE-HELD 6s  ← reconcile's query stuck at proxy
19:33:51.510  /v1/checkstate FORWARDED → proofs now SPENT
19:33:57      Owed grant applied (allotment 3,000,000 ms) + ndsctl AUTH
journal:      crash ref → state=owed, "NUT-07: proofs spent; owed entitlement recorded"

ordering at boot	runs	crash-intent resolution	customer outcome
checkstate first (natural boot)	3/3	abandoned (unspent)	dead token, no session, no grant
replay first (intervention)	1/1	owed (spent)	owed grant applied + gate AUTH

Identical crash shape, driver, and head — ordering is the only variable, and it flips the outcome. That also validates the fix direction empirically: sequencing the receive-intent reconcile after the resume pass for intents whose proofs the wallet holds pending swaps for converges the customer with no other changes (the intervention run's customer got exactly the (b)-shape treatment: owed → granted → AUTH).

[Amperstrand]

Lane head-record: a696660a (third head) — production-identical to the tested 1c51f8ca, verdicts carry. Diff vs the tested SHA touches only src/merchant/merchant_degraded_recovery_test.go (stub derives its keyset ID) and a changelog fragment — zero production-code changes, so the rel-verify battery and the race-intervention addendum above apply verbatim. No re-run performed. Tested-SHA ledger: b9b47c90 (full battery, gonuts v0.13.1) → 1c51f8ca (full battery + intervention, gonuts v0.14.0) → a696660a (production-identical carry). The (a)-shape reconcile-vs-replay finding remains open at this head — the Appendix-A regression command (expect owed + Owed grant applied) is the acceptance check for whatever fix lands.

[Amperstrand]

Verdict addendum — CLEAN → CHANGES-REQUESTED (one change, empirically validated by the rel-verify lane's Appendix B intervention): sequence the boot receive-intent reconcile after the resume pass for intents whose proofs the wallet holds pending swaps for. My original verdict below stands for everything it examined — the wallet-level wiring, the anti-brick properties at the pinned tag, the tests — but it reviewed the PR as a wallet change. The crash lane proved it as a system change, and at the system level the current head ships a customer-harming race in the natural boot ordering.

The lane's both-ways intervention is the cleanest possible proof: identical crash shape, head and driver, with only the boot ordering flipped — checkstate-first (natural, 3/3) resolves the crash intent abandoned on an unspent answer (the replay hasn't re-POSTed yet), so the customer keeps a dead token, no session, no grant, while the operator's replay recovers the value moments later; replay-first (intervention, 1/1) gets the mint's answer spent, the intent resolves owed, and the customer receives the grant and gate AUTH. This is precisely the AGENTS.md warning class — "wallet-internal atomicity does NOT make the Receive→…→gate chain atomic; when the gate fails after a successful Receive, decide refund vs late-grant explicitly" (#258, #403) — resurfacing as a boot-time ordering race between the two halves of the #502 business-transaction record: the customer half (#700's NUT-07 reconcile) and the operator half (this PR's replay) each converge correctly in isolation and destructively interleave together.

Requested change (the lane's validated direction, restated as the review ask):

1. Deterministic sequencing, not a timing hope. The receive-intent reconcile must observe post-replay proof state for any intent the wallet journaled a pending swap for. Concretely: make the resume pass observable (a done-signal or a ResumePendingSwaps completion the boot path can await for affected intents only — awaiting the whole pass would re-couple boot to mint availability, which this PR rightly removed), or have the reconcile re-check an intent it is about to abandon if pending swaps for its proofs still exist. The intervention run demonstrates the fix needs no customer-half changes beyond ordering: the (b)-shape treatment (owed → granted → AUTH) is what every (a)-shape crash should converge to.
2. The >60s NUT-19 window stays correct under sequencing — verify it stays so. When the replay fails beyond the cache TTL, the proofs are genuinely unspent and abandoned is the right resolution (the customer's token still spends elsewhere; no value reached the operator). The sequencing change must not turn that case into a false owed. A test pinning the failed-replay → unspent → abandoned path alongside the succeeded-replay → spent → owed path would close the matrix.

Everything else in my original review is unchanged — including the merge condition that #771 closes as superseded. The new merge conditions are: the sequencing change above, the concurrent-traffic scenario the lane already names, and one lane run against the final head. This remains the right shape and the right stack (#780 → #793); it just needs its two halves to boot in the right order.

[Amperstrand]

Lane head-record: 4a7a0d98 (fourth head) — production still identical to the tested 1c51f8ca; verdicts carry. Net diff vs a696660a is e446897 (the #728/#724 client-Dockerfile ARG hoist, third landing) — src/ production delta vs the tested SHA is zero lines, so no re-run. Disclosure change for the record: the lane's Dockerfile.client ARG-hoist scratch-patch is now redundant (branch carries it); the lane's remaining local patches are build.network: host (build-bridge DNS workaround, host-specific) and the killer/driver observability tools. Tested-SHA ledger: b9b47c90 (battery, v0.13.1) → 1c51f8ca (battery + race intervention, v0.14.0) → a696660a → 4a7a0d98 (carries). The (a)-shape reconcile-vs-replay finding remains open at this head.

[Amperstrand]

Rebased onto main@f66cd67 (3 conflicts resolved: token-recovery go.mod/go.sum gonuts repin → v0.14.0 kept; Dockerfile.client GO_VERSION hoist → main's already-landed version kept, the PR's third-landing commit was a duplicate of what main now carries). Plus two fixture updates the v0.14.0 #705 guard requires: cherry-picked #908's NUT-02 fixture derivation (its check_state_correlation family) and derived the togglable-mint keyset id in register_mint_test (the PR's own new test used a literal id).

Verification at the new head: src/merchant full suite ok — 303.9s; src/tollwallet ok — 49.6s (was failing pre-fix); builds: merchant/tollwallet/token-recovery all OK. Ready for approving review (tracker #965).

[felixfelix-bot]

Review: CHANGES REQUESTED — the stated base is closed, and the branch carries a stale pin + a stale description

Reviewed cold at head mod-pr793 (bfe3557, 2026-10-17). The code direction is right and I want
it to land — but as it stands the PR cannot be verified or merged, and the problems are mechanical,
not conceptual.

1. The stated precondition is unsatisfiable: base #780 is CLOSED, not merged

The body opens with "STACKED ON #780 — merge #780 first. Base is fix/752-swap-empty-outputs … This
PR consumes the machinery #780's pin (gonuts v0.13.1) delivered."

But:

#780  state = CLOSED, mergedAt = null   (closed 2026-10-11)
main  packaging/build-inputs.json .gonuts.version = v0.13.0

So #780 never merged, and its pin (v0.13.1) is not on main. The base branch
fix/752-swap-empty-outputs still exists upstream and the PR is base: fix/752-swap-empty-outputs,
mergeable: CONFLICTING. Anyone reading the description and following it would wait for a merge that
is not coming.

2. The branch actually carries a different, newer pin than it says — and the pin fence fails

The last commit (bfe3557) says "the #705 guard (gonuts v0.14.0) refuses literal ids", and the
carriers agree with that commit, not with the description:

carriers: 3 × v0.14.0     2 × v0.14.0 // indirect
manifest (.gonuts.version): v0.13.0        <-- disagrees with every carrier

tests/contract/check-gonuts-pin.py on this branch — exit 1, 8 findings:

🔴 src/cli/go.mod: pins … v0.14.0, manifest says v0.13.0 — run scripts/bump-gonuts.sh v0.13.0
🔴 src/cli/go.sum: does not record … v0.13.0 — the bump never reached this module's sum file
🔴 src/go.mod / src/go.sum, src/merchant/*, src/tollwallet/*  — same

This is the #791 drift class exactly: manifest and carriers disagree, and the go.sum files do
not record the manifest's version. The fence message even names the remedy. Note the direction —
the manifest is the stale side here (v0.13.0) while the carriers moved to v0.14.0, so the fix is
almost certainly scripts/bump-gonuts.sh <the intended version> rather than downgrading the carriers.
Whichever version is chosen, manifest + all 5 carriers + all 5 go.sums must move together, which is
what that script exists to do.

3. Stale description, and one factual correction it needs

The body's own scoping section already contains the correction — "replay succeeds when the mint
honours NUT-19 replay within its cache window — the 'deterministic signing' reading was corrected by
the #497 research" — but the surrounding text still describes #493 (via #780) as delivering
"recovery in seconds, no mint dependency", and #886 (which I reviewed just now) states plainly that
this PR alone shows no recovery at all for its scenario without the NUT-09 fallback. Those three
statements do not agree, and a reader cannot tell which is current.

What is genuinely good here — and why I want this to land

• feat(cloud-lab): scenario (e') + cdk-mintd 0.18.1 variant + gonuts repin to the NUT-09 restore fallback — #866 (draft until gonuts #40) #886's stated dependency checks out. feat(cloud-lab): scenario (e') + cdk-mintd 0.18.1 variant + gonuts repin to the NUT-09 restore fallback — #866 (draft until gonuts #40) #886 declares it is "Draft until BOTH merge: 1. feat(tollwallet): recover crashed swaps on wallet load — wire ResumePendingSwaps (#497 resume half, #703 item 1) #793 —
  the boot-resume wiring that drives the fallback … Without it, scenario (e′) shows no recovery at
  all — this is the expected red, not a bug". So this wiring is a real precondition for feat(cloud-lab): scenario (e') + cdk-mintd 0.18.1 variant + gonuts repin to the NUT-09 restore fallback — #866 (draft until gonuts #40) #886, and
  both PRs are held on each other by a correctly-stated chain rather than by guesswork.
• The design is the right shape for the invariant. TollWallet.New kicks recovery off the boot
  critical path, and the intent (request bytes, secrets, blinding factors) is persisted
  atomically with the counter reservation, before the irreversible POST — which is precisely the
  AGENTS.md rule ("Reserve/persist the counter range before the network call that exposes it",
  fix: bump gonuts-tollgate v0.7.1 → v0.7.4 for swap-counter race #266) and the reason a crash cannot re-expose derivation outputs. Recovery replaying recorded intents
  rather than re-deriving is the correct instrument for the brick class (Cashu payment fails: 'outputs have already been signed before' on v0.5.0 #257/fix: bump gonuts-tollgate v0.7.1 → v0.7.4 for swap-counter race #266/tollwallet: service restart permanently breaks swaps — 'Duplicate outputs' against any mint with prior swap history #480).
• It is honest about the previously-unwired gap: "the resume half of Priority: P0 — research-first: the swap crash window can silently destroy received value; the correct fix shape (pre-persisted swap intents) must be designed, not improvised. #497 was built but unwired …
  zero call sites existed. The value was durable; the recovery was not automatic." Recognising that
  the fix is a wiring call, not new machinery, is the useful framing.

What is needed before this can be approved

1. Resolve the base: retarget to main (or the current canonical branch) and state which pin is
   intended; the description's "merge fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 first" must go, since fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780 is closed.
2. Run scripts/bump-gonuts.sh so manifest, all 5 carriers and all 5 go.sums agree, then confirm
   check-gonuts-pin.py exits 0.
3. Rebase off the stale base — 3 behind / 10 ahead of main, currently CONFLICTING.
4. Update the description so the recovery capability it claims matches what it (and feat(cloud-lab): scenario (e') + cdk-mintd 0.18.1 variant + gonuts repin to the NUT-09 restore fallback — #866 (draft until gonuts #40) #886) actually
   deliver.
5. Re-run the suites after the rebase (I am not reporting test results for a conflicted,
   pin-drifted branch — any green I produced now would not be evidence for the merged state).

Verification I did and did not do

• Did: inspect the pin across all carriers, run the pin fence (failed as above), check fix(wallet-bump): gonuts-tollgate v0.13.1 — amount==fee swaps refused locally, never POSTed with empty outputs (#752) #780's state
  and main's pin, check the base branch's existence and the branch's divergence, read the intent/
  persistence design and the #886 dependency statement.
• Did not: run the Go suites or the cloud-lab scenario (e′) — Docker is unavailable on this host,
  and the branch is CONFLICTING with a drifted pin, so test results would not be meaningful until it
  is rebased. tollgate-A04E is not the right instrument for a wallet-recovery lane either.
• Not merged, not pushed — as with every PR in this sweep.

Labels: not applied — this account has pull: true / triage: false here and no permission to
create or attach labels. Intended label for whoever can: high (top-item boot-recovery wiring for the
pending-swap intent class), blocked on retarget + pin consistency + rebase.

FULL_REVIEW: ~/reports/reviews/tollgate-module-basic-go-pr793-kimi.md