Cross-mint smoke: a script that runs, and states what it cannot prove

[orveth]

What

The cross-mint smoke script, rewritten against the CLI the binary actually has, and staged.

Why

The script shipped in #196 had never been run. Against the real binary, every invocation in it returns rc=1:

script invoked	reality
mobee budget status --json	no budget command
mobee config set …	no config command
mobee job post/settle/show	no job command — the trade path is daemon RPC / MCP (post_job, award, collect, get_job)
mobee --home X …	--home is a post-subcommand flag, on wallet only; everything else reads MOBEE_HOME
mobee wallet balances --json	it is balance, and there is no --json
mobee buyer restart	only buyer / buyer serve / buyer status
MOBEE=./target/release/mobee	CARGO_TARGET_DIR is redirected; nothing is at ./target
config set default_mint	no such field — the buyer's mint is derived as the first accepted_mints entry

A script in that state does not fail at step 0. It fails partway — and on the real-money path, partway means after the melt, with sats gone from the source and nothing issued at the target. That is the worst failure geometry the slice has.

Staging

The external unknowns are measured before our own code is involved:

• --self-test — parsers against fixtures. The status=needs_payment branch appears only on a non-test mint, so fixtures are the only coverage available before real sats. Runs on every mode, including both real ones.
• --dry-run — testnut. Proves gates, home discipline, env config, funding, balance parsing, bolt11 issue, and that a melt which cannot route returns non-zero — the property every || die guarding a real melt depends on.
• --stage-a — the hop by hand in three wallet commands (wallet mint at target → wallet melt at source → wallet mint-complete at target). No daemon, no relay, no seller, no hop code. Answers the one question no hermetic test can: does Lightning route source → target, and what does it cost? Ends in a fee-fit verdict against the exposure cap.
• --stage-b — refuses, naming exactly what it still needs, rather than pretending.

Stage A before Stage B is the point: A's unknowns are external (two mints, LN routing, fees), B's are ours. Run together, a failure tells you neither. Run in order, an A-failure means the mint pair and a B-failure means our code.

Safety is structural, not procedural

• The fence cannot be left open. Config comes entirely from the environment, and env overrides are never persisted — measured: a home booted with MOBEE_ALLOW_REAL_MINTS=true still reads allow_real_mints = false in its config.toml, and re-reading without the env reverts. The real-mint flip is process-scoped and evaporates on exit. The previous design restored the fence in an EXIT trap with || true on both restores — a restore that can fail silently.
• The ~/.mobee fallback is unreachable. Bootstrap does write into MOBEE_HOME, and an unset MOBEE_HOME resolves to ~/.mobee, which on this box holds a real key and wallet. Every invocation is funnelled through one wrapper that refuses any directory this run did not itself create and mark, refuses an empty home, and refuses anything resolving into ~/.mobee. Both refusals are asserted in the dry run.
• The exposure cap is a runtime gate. MOBEE_TOTAL_BUDGET_SATS bounds the spend in the budget gate, which charges the hop's full cost (delivery + fee reserve + input fee) — independent of anything the script asserts afterwards.
• Authorization names the spend. The real stages require a token matching <amount>:<source>:<target>. The expected value is never echoed on refusal.

Evidence

Built and run on the merged tree. dev@2ab64b7 is #196 squashed with nothing else on top, and its tree hash is identical to the branch it was built from (d3f58c4f…), so the binary under test is the merged-tree binary.

cargo build -p mobee --release   rc=0
--self-test                      rc=0   (11/11 parser checks)
--dry-run                        rc=0   (DRY RUN PASSED)

Refusal paths, each verified:

--stage-a, no auth                 rc=1
--stage-a, wrong token             rc=1   expected token NOT echoed
--stage-a, identical mints         rc=1   "that is a direct payment, not a hop"
--stage-b                          rc=1   refuses, names what it needs

What this still does not prove

A successful melt, mint-complete after real payment, and cross-mint LN routing. Those are structurally impossible against a test mint — measured, not assumed: on testnut a melt of a freshly issued invoice returns wallet error: Payment failed (rc=2). They are exactly what Stage A exists to measure, and it is gudnuf-gated.

Follow-up in this PR: funding, and shape-checking what gets melted

Stage A created a fresh empty home and then asserted a source balance — so the first real run would have died at buyer holds 0 sats. The funding step was missing entirely.

Paying the invoice happens out of band and by a human, so funding is two invocations sharing one throwaway wallet: --fund prints the bolt11, --fund-complete <quote_id> issues once it is paid. That makes a home reusable across invocations, so make_home became ensure_home — it reuses one carrying our marker, and still refuses any directory this tooling did not create.

The authorization token now names the total funded exposure rather than each step's amount: one human decision about how many real sats are at risk, which is the shape the spend was approved in.

A mint that auto-funds prints minted_sats=… where a real mint prints a bolt11. Both are non-empty, so an emptiness check would feed that line straight into wallet melt. is_bolt11 checks the shape instead, and the self-test pins both directions.

Re-verified after the change rather than carrying the earlier green forward:

--self-test                        rc=0   11/11
--dry-run                          rc=0   DRY RUN PASSED
--fund / --fund-complete /
--stage-a / --stage-b              rc=1   each, without matching auth
                                          and creating no home before the gate

Two operational notes for whoever runs it: RUN_DIR must be set to a persistent path — it defaults to /tmp, and real ecash lives in that home, so a /tmp clean burns it. And the mint pair pre-flighted read-only: both HTTP 200, NUT-4 and NUT-5 present, "disabled":false, no advertised min/max.

Stage A ran for real, and found a bug in this script

Executed by the orchestrator under gudnuf's authorization, funded from turtle-ln. It routed: melt at btcforplebs → mint at cubabitcoin, 5 sats delivered, fee 2. Final balances 8 source + 5 target = 13/15. Fee-fit: 21 + ~2 ≈ 23 against a 50 cap, so Stage B is viable on this pair.

The strand path fired for real — twice — and recovered both times with zero sats lost. The recovery text was load-bearing and it held.

The bug: quote ids truncated at the underscore

parse_quote_id matched [A-Za-z0-9-]. No underscore. So lcLc0JwHHCIG_UIwQ8cvPB-LXgiVfSxE6ZO6Tq1b became lcLc0JwHHCIG.

The character class is the whole cure. It now matches to whitespace. Quote ids are opaque — testnut issues UUIDs, the real mints issue base64url — and enumerating the characters of an identifier you don't define is the mistake.

Two things made it sail two hops past the parse:

1. A truncated id is a prefix of a real one. It stays id-shaped, so nothing looked wrong at the parse site.
2. The far-end error described a different subsystem's symptom: quote <id> has no stored amount; pass --amount to complete it. Reading complete_mint_by_id, that branch is reachable only when the quote lookup returns None — it means the id was not found, and the code then guesses you need --amount, having no way to know the id is truncated. Confirmed live: leg-1 recovery succeeded with the full id and no --amount.

--amount is now passed at both call sites as a cross-check, not a fix — when the quote is found, mint-complete refuses a completion whose amount differs from the stored one, so it pins that we're completing the quote we raised.

Why the self-test didn't catch it

The fixture was a UUID, copied from testnut — the mint the dry run can reach. So a fixture standing in for a format I had explicitly documented as unreachable inherited the format of the reachable world, and proved the parser against a character set that could not fail.

A fixture for a format you cannot observe must be drawn from that format, not from the one in front of you. Otherwise it is a check that cannot fail, which is the same as a check that did not run.

Both shapes are pinned now, the base64url one verbatim from the live run, and the old class is confirmed red against it (12-char prefix of a 40-char id).

--self-test    rc=0   13/13
--dry-run      rc=0   DRY RUN PASSED
refusal gates  rc=1   each

🤖 Generated with Claude Code