runJob requests the gateway estimate (which carries the full system+user prompt) before it reads the ledger. The 'daily cap reached' check (line 216) and the requester 'remaining budget' check (line 220) only run inside the lock after the estimate returned.

When spentToday >= cap.daily, or jobSpent >= jobBudget, the outcome is decidable from local state alone, yet the prompt is posted to /models/estimate and only then is the run refused with 'refused locally, nothing sent' and exit 3. The sibling spend-guard tool was fixed for exactly this class in commit 5c5b881 (audit 355a3703 I11: 'the prompt does not leave the machine for a request that was always going to be refused'); imd-flop still has it for the two ledger-derived limits.

No FLOP is spent (the estimate is free) but the refusal message is inaccurate and the prompt is disclosed to the gateway for a call that can never be sent.

Fix: before provider.estimate, read spentToday/jobSpent once and refuse (same reason strings, same exit 3, same refused_local row with quote_raw/quote_padded null) when left <= 0; keep the in-lock re-check unchanged for the race.

reclaimIfDead reads the owner (line 109), then renames whatever is at path (line 111). If, between those two steps, another waiter already reclaimed the dead lock and created its own live lock file at path, the rename moves the live holder's file aside.

The code anticipates this and links it back (line 113), but between the rename and the link-back path does not exist, so any process calling takeLock in that window succeeds with openSync('wx') while the first holder is still inside its lockedCheck. The link-back then fails with EEXIST, that waiter exits 10 'contested', and the live holder's file is left as a leaked .stale. file.

Result: two cap checks can pass against the same spent_before and both append sent, so the daily cap can be exceeded by one padded quote.

Preconditions: a lock file older than 30 s whose recorded pid is dead on this host (a crash), plus three near-simultaneous runs; two scheduler preemptions at narrow points are needed, so it is rare but the code's own comment acknowledges the first half.

Fix: do not reclaim by rename; instead open the existing file, fstat it, and only unlink it if its inode still matches what was read and the owner is provably dead, or drop automatic reclaim and print the lock path for a human to remove (the current message names no file).

Re-audit of e99a2cf1 I14: the lock taken at line 228 now maps LedgerLockError to exit 10 and nothing is sent (verified: TS-I14 passes, exit 10 with 'refused locally, nothing sent'). One pre-call path still does not: when the estimate fails or returns no usable cost, refuse() calls appendLedger, which takes the lock itself; a LedgerLockError there is not a CliError, so main exits 1 with 'ledger lock timeout', no 'refused locally' prefix, and no refused_local row.

README line 48 documents this as a known gap, so it is reported for completeness of the exit-code contract (README line 46 states the unconditional rule two lines earlier). Nothing is sent and no FLOP is at risk.

Fix: in refuse(), catch LedgerLockError around appendLedger and rethrow as CliError(refused locally, nothing sent: ${e.message}, EXIT.REFUSED_LOCK), or let the original refusal code win since the row is only informational.

loadConfig (imd-flop/src/config.ts:18-21) spreads config.json over DEFAULT_CONFIG without checking that payer is "holder" or "requester". runJob only requires --job-budget when payer === "requester" (run.ts:159), and the cap check at run.ts:214-221 treats every non-"holder" value as the requester branch. There o.jobBudget is undefined, so left = NaN and q.padded > NaN is false: the run is never refused. Every ledger row then carries payer "sponsor", which spentToday (ledger.ts:74, payer === "holder") and jobSpent (ledger.ts:78, payer === "requester") both skip, so no attempt ever counts against any cap, and status/cap show report today's spend as 0 while calls keep going out. The sibling field caps[seat] was made to fail closed for exactly this class of input (prior audit TS-L10, run.ts:154-157); payer was not. Who can trigger it: anything that writes config.json other than config set payer (the agent operating the CLI, a hand edit, or a future writer). The holder's caps are the only brake on that agent, and this bypass leaves no trace in cap show.

Expected: a payer outside holder|requester refuses every run with exit 3 (REFUSED_CAP) and nothing sent, as a malformed cap does. Actual: every run exits 0 and is sent.

Fix: validate payer in loadConfig (or at run.ts:152 next to the cap check) and refuse with EXIT.REFUSED_CAP when it is not exactly "holder" or "requester"; make the run.ts:218 branch explicit (else if (cfg.payer === "requester")) with a final fail-closed refuse.

When provider.complete() rejects with PreSendError (FlopProvider.complete wraps every assertPaidNetwork failure and every mintChildKey failure this way, providers.ts:139-146), the catch block builds reason = nothing sent: ${err.message...} (run.ts:249) and appends the refused_local row with cap_charge 0 (run.ts:250). appendLedger runs assertNoSecrets on that row. Only 0x + 64 hex is stripped from the message; any other 64-or-more hex run, a Bearer ... or flop_ek_... shaped substring, or a loaded secret is not. Those strings come from the RPC/faucet the recheck talks to: gateway.ts:227 eth_chainId error: ${j.error.message}, gateway.ts:181 rpc error: ${msg.error.message}, gateway.ts:259 Ethereum chain id ${chainId} ... (a chain id of 0xff..ff (64 f) prints as a 78-digit decimal, which HEX64 at secrets.ts:52 matches because digits are hex characters). When the scan hits, appendLedger throws CliError(REFUSED_RULE) from inside the catch: the refused_local line is never written, the pre-call sent row (cap_charge = padded quote) stays the latest line for that request_id, and the CLI exits 5 'secret scan blocked writing ledger.jsonl' instead of 1 'nothing sent'. spentToday then counts the phantom reservation for the rest of the UTC day, so the next run is refused with 'daily cap reached' although no child key was minted and nothing was sent. receipt <id> --refresh cannot clear it: the gateway has no receipt for an unminted request, so capCharge stays prev.cap_charge (cli.ts:442). status lists it as a pending paid attempt. This is the invariant the README states for this path ('the latest ledger line is refused_local with cap charge 0') and that TS-L11 tests only with a clean message. Trigger: the ETH_RPC_URL endpoint or the FLOP devnet RPC/faucet answering the pre-call check correctly and the in-provider recheck with such an error (a hostile operator, or an inconsistent load-balanced RPC whose error text carries a hash without 0x).

Fix: build the ledger reason from a fixed vocabulary (for example nothing sent: pre-send refusal) or pass the message through redactFlagged/scan before the append, and if the append still throws, still throw the EXIT.ERROR 'nothing sent' CliError after writing a minimal refused_local row; never let a scan failure keep the sent reservation live.

scanForSecrets visits only values: for an object it recurses into each value and passes the key as the field name, but the key string itself is never matched against the registry, HEX64, FLOP_TOKEN, BEARER or PEM. A completion whose usage object (stored verbatim in the response record, run.ts:261) carries a 64-hex string or a flop_ek_... token as a property name with a harmless value therefore passes writeJsonSafe and lands in responses/.json (mode 0644), and redactFlagged cannot null it either. The README's rule 1 says 'any 64-hex value' and 'flop_ek_... tokens' are rejected before anything touches disk; the gateway (which knows the child token it minted) is exactly the party whose output this scan exists to filter. Impact is limited to gateway-supplied content reaching a world-readable file; the registry check for our own loaded secrets has the same gap.

Fix: in visit(), also run the string checks on each key k (treat it as a string value with field name k), and in redactFlagged delete or rename a flagged key.

The cap check lives entirely inside lockedCheck, which runs only after provider.estimate() returned. Whether today's holder spend already equals the daily cap, or a ledger cap_charge is unusable, is known before any estimate (spend-guard fixed the same ordering as IMD audit 355a3703 I11, commit 5c5b881; imd-flop did not). Consequences: a run that will be refused anyway sends a prompt to the gateway's /models/estimate (a free call, but the prompt leaves the machine), and when that estimate fails the user sees exit 7 ESTIMATE_FAILED and a refused_local row with reason 'estimate failed', not the cap refusal. The per-call check genuinely needs the quote and is correctly inside the lock; only the 'daily cap reached'/'unusable ledger charge' refusals are locally decidable. Not a spend risk.

Fix: before the estimate, compute spentBefore under the lock (or unlocked, as an early exit only) and refuse with REFUSED_CAP when left <= 0 or the ledger charge is unusable; keep the authoritative check inside the lock.

takeLock creates ledger.jsonl.lock with openSync(path, 'wx') (ledger.ts:122) and only then writes the owner record {pid, host, token} (ledger.ts:123). A SIGKILL, OOM kill, power loss or a thrown error between those two calls (or a write that is lost before fsync) leaves an existing lock file with no readable owner. readOwner then returns null, provablyDead(null) is false by design ('unreadable or malformed: never provably stale', ledger.ts:92), so reclaimIfDead never fires no matter how old the file is, and every subsequent withLedgerLock waits 5 s and throws LedgerLockError. Every run on that home exits 10 'refused locally, nothing sent' forever, receipt --refresh silently reports 'receipt and ledger disagree', and nothing in the CLI tells the user that the lock file is empty or how to recover. The same permanent state arises when the recorded host no longer equals hostname() (hostname change, home directory moved to another machine). Fail-closed, so no spend is at risk; the cost is an unrecoverable-by-CLI outage of the paid path.

Fix: make the owner record and the lock file one atomic step: write the JSON to a private temp file in the same directory, then linkSync(temp, lockPath) (fails with EEXIST exactly like 'wx') and unlink the temp; alternatively treat a 0-byte lock older than the 30 s threshold as reclaimable, and print the lock path with the exit-10 message so a human can inspect it.

reclaimIfDead() decides a lock is stale from one read of path (line 109) and then renames whatever is at path (line 111). Between those two steps another reclaimer can finish the same reclaim and create its own fresh lock at path. The second reclaimer then moves that live lock aside.

While it reads the moved file and tries to link it back (line 113), path does not exist, so any other waiter's openSync(path, "wx") succeeds and it enters withLedgerLock while the first reclaimer is still inside its body.

The link-back then fails with EEXIST and throws "ledger lock contested" (exit 10) for the second reclaimer, but by then two processes are running lockedCheck() + appendLedger() at once: both read the same spent_before, both pass the daily/job-budget check, and both append a sent row, so the cap can be exceeded by one padded quote. The first holder's lock file is left stranded at <lock>.stale.<pid>.<hex> and its releaseLock() is a no-op.

A three-process variant (the first reclaimer finishes while its lock is aside; the second reclaimer links the released owner's file back) leaves a dead-owner lock at path that blocks every run with exit 10 for up to 30 s.

Preconditions: a holder that crashed leaving a lock older than 30 s, and three or more runs started together (for example an automation retrying after the crash). The windows are microseconds, so this is an atomicity/liveness defect rather than an easy exploit, but the comment on lines 104-106 claims two waiters cannot both act on one stale file, and that no longer holds once the moved file is a live lock.

Fix: re-read path immediately before the rename and refuse to move it unless its owner is still the dead one (compare pid and token), or reclaim through a hard link of the inode that was read (open + fstat, then rename only if the inode matches); on EEXIST at link-back, unlink the stranded aside file only when its token is the mover's own.

takeLock() creates ledger.jsonl.lock with openSync("wx") and only then writes the owner JSON. If the process is killed, hits ENOSPC, or the machine loses power between the two calls (the write is never fsync'd), the lock exists with no owner record. readOwner() returns null for it, provablyDead(null) is false, and reclaimIfDead() refuses it forever regardless of age.

Every later run then waits 5 s and exits 10 "refused locally, nothing sent: ledger lock timeout", and receipt --refresh prints "receipt and ledger disagree" instead. The message names neither the lock file nor a recovery step, so the holder cannot tell transient contention from a permanent wedge. The v6 tests assert that an unattributable lock is never stolen, which is right for a foreign or hand-made file, but this file is one the CLI itself failed to finish writing.

Fix that keeps the fail-closed design: write the owner record to a sibling temp file (write + fsync) and publish it with linkSync(tmp, path) so the lock appears atomically with its owner (EEXIST still means held); or treat a zero-length lock older than the 30 s staleness age as reclaimable, since no live holder can own one; and put the lock path and the recovery step in the LedgerLockError message.

refuse() appends a refused_local row through appendLedger(), which takes the ledger lock itself. On the estimate-failure and no-usable-cost paths (lines 198 and 200) that append runs outside the lockedCheck lock, so a LedgerLockError thrown there is not the one caught at lines 229-231 and reaches cli.ts as a non-CliError: the run exits 1 with "imd-flop: ledger lock timeout".

The refused_local row is never written, and the message no longer says that the estimate failed or that nothing was sent, although this is before the paid call, which is the case exit 10 is documented to cover (README.md:46). README.md:48 records it as a known gap, so this is an accepted residual rather than a regression; it is listed so the re-audit of I14 is complete.

Fix: catch LedgerLockError inside refuse() and rethrow CliError(REFUSED_LOCK) carrying the original refusal reason, or take the quote inside the locked section.

The appendLedger() call in the refresh path (line 447) takes the ledger lock itself. Every failure of that call, including LedgerLockError when another process holds ledger.jsonl.lock, is swallowed by the bare catch and reported as "receipt and ledger disagree; reservation held, chain-final green blocked" with exit 0.

The receipt file has already been rewritten with the fresh settlement (line 422), the ledger row still carries the reservation, and the stderr line names a data disagreement that does not exist. The outcome is safe (the reservation is kept and a later --refresh re-applies the settlement because settledKnown !== prev.spend), but a script cannot distinguish "ledger updated" from "ledger not updated" by exit code, and the holder is told the wrong cause.

The same path is what the v3 test asserts for a read-only ledger, so this is a message/exit-code precision issue, not a spend defect.

Fix: catch LedgerLockError separately and report "ledger lock timeout; settlement not booked, run --refresh again" with a non-zero exit (REFUSED_LOCK), keeping the disagree wording for genuine identity or amount conflicts.

The README documents that a timed-out attempt has a ledger row but no receipt file and is checked later with imd-flop receipt <request_id> --refresh. In that state saved is null, so the merged receipt is {...c, request_id, ...} built only from classifyReceipt, which carries no seat, did, ss58 or network.

The file written at cli.ts:422 therefore lacks seat and did. matchReceipt (src/match.ts:30-31, 43-44) then reports fields seat, did, seat(link), did(link) and the attempt shows match=mismatch in receipt, receipt --refresh and status. Every later refresh spreads the same saved (still without seat/did), so the mismatch is permanent.

Meanwhile the ledger booking at cli.ts:435-447 keys off identityOk alone, so a settled amount IS booked against a receipt whose match says mismatch, which contradicts the documented rule that matches means the receipt agrees with its records and that a mismatch keeps the reservation.

Operators are trained by the README to treat mismatch as a revoked/rotated-DID or identity signal; a false alarm after every timeout either sends them chasing a non-issue or teaches them to ignore mismatches. The non-refresh path (receipt <id> with no file, cli.ts:458) does copy seat/did from the ledger row, so only the refresh path is wrong.

Fix: when saved is null, seed seat, did, ss58 and network from ledgerRow (and mock_scenario for mock) before writing, exactly as run.ts:297 does for a fresh receipt.

scanForSecrets visits only values; each key k is used solely as the field name for the SECRET_FIELD / PUBLIC_HEX_FIELDS lookups and is never itself tested against the registry, the bearer/FLOP_TOKEN/PEM regexes or HEX64. run.ts:261 stores the raw gateway usage object in the response record, and run.ts:267 relies on writeJsonSafe to block anything key-shaped.

A gateway (or a buggy proxy) that echoes the child token, the parent bearer or any 64-hex string as a property name in usage therefore passes the scan with zero findings, withheld is never set, and the key material lands in a 0644 file under responses/. redactFlagged could not clear it either, since setNull only nulls values.

Rule 1 ("a pre-write scan rejects anything shaped like a key") is thus bypassable through key names. stdout is not affected (run --json does not print usage).

Fix: in visit, run the string checks on each key as well (treat the key as a string value with field name k), and in redactFlagged delete or rename offending keys.

takeLock creates the lock file and writes the owner record in two steps. If the process dies (SIGKILL, power loss) or writeSync fails (ENOSPC, EIO) between them, the lock exists with no owner JSON.

On the ENOSPC path the error is not EEXIST, so line 126 rethrows without unlinking the just-created file. readOwner (line 88-94) returns null for an empty/malformed file and provablyDead(null) is false by design ("never provably stale"), so reclaimIfDead never fires no matter how old the file is.

Every subsequent run then loops for 5 s and exits 10 with 'refused locally, nothing sent: ledger lock timeout' (the pre-call exit code), receipt --refresh reports the misleading 'receipt and ledger disagree' message, and nothing in the CLI tells the operator which file to remove. By contrast a lock whose owner JSON names a dead pid on this host is reclaimed after 30 s.

Fix: write the owner record to a temp file and linkSync/renameSync it into place so the lock is never observable without an owner; on a write failure unlink the path before rethrowing; and have takeLock include the lock path in the LedgerLockError message.

readJsonl parses every non-blank line with no error handling. appendJsonlSafe uses appendFileSync with no fsync, so a crash or disk-full event mid-append can leave a partial last line.

After that, latestAttempts throws SyntaxError on every call: run fails inside lockedCheck (fail-closed, nothing sent, but exit 1 rather than the documented exit 3 for an unusable ledger), and status, cap show and receipt all exit 1 with the bare parser message, which does not name the ledger file or the line.

The README's exit-code table reserves 3 for 'a ledger cap_charge is unusable' and 1 for 'any unexpected error', so a script branching on 3 to alert on ledger problems never fires, and the operator has no diagnostic command left that works.

Fix: catch parse failures per line in readJsonl, raise a typed error naming the file and line number, map it to UnusableLedgerCharge/REFUSED_CAP in run, and let status report the corrupt line instead of dying.

sumCharges throws for any latest row whose cap_charge is missing, null, non-numeric, negative or non-finite. runJob maps that to REFUSED_CAP (exit 3) at run.ts:210, which is correct. But status (cli.ts:375) and cap show (cli.ts:263) call spentToday unguarded, so the same ledger state makes both diagnostic commands exit 1 with 'ledger cap_charge unusable; next call refused' and no row identifier.

The row that needs fixing (request_id, line) is never shown anywhere, and receipt <id> --refresh, the only command the README offers to repair a ledger row (TS-M2 path at cli.ts:437-440), requires the operator to already know the request_id.

Fix: make spentToday/jobSpent return a structured result (or let UnusableLedgerCharge carry the request_id), have status and cap show print the offending request_id(s) with today's known-good total instead of throwing, and keep run on exit 3.

After the refreshed receipt has already been written to receipts/.json (cli.ts:422), the ledger append at cli.ts:447 runs under its own withLedgerLock. If another process holds the lock (or the lock is stale and unreclaimable, see the empty-lock finding), appendLedger throws LedgerLockError, the bare catch prints the fixed string 'receipt and ledger disagree; reservation held, chain-final green blocked' and the command returns EXIT.OK.

The message is false (the receipt and ledger do not disagree; the ledger could not be written), the exit code tells a script the refresh succeeded, and the two stores are now inconsistent: the receipt file says state settled / settled 0.05 while the ledger's latest row is still state estimated, spend null, cap_charge 0.186. receipt <id> without --refresh then shows settled=0.05 next to ledger: state estimated, spend blank.

Only a later refresh that happens to get the lock repairs it.

Fix: catch LedgerLockError separately, report 'ledger lock timeout; settlement not booked, re-run --refresh', and exit non-zero (10 fits the documented meaning: lock not taken, nothing written).

The README accepts exit 1 for a post-call lock failure, and the pre-call/post-call split (10 vs 1) is implemented as documented. But the failure mode is harsher than the README describes. Because appendLedger here (and at run.ts:250 for the timeout/error branch) is not wrapped, the raw LedgerLockError escapes runJob, so cli.ts:475 prints only 'imd-flop: ledger lock timeout' and nothing is written to stdout even with --json.

The operator is not given the request_id, the response file path, or the receipt line, although the paid call completed and both files were written; the only way to find the attempt is status. On the timeout branch the same failure exits 1 instead of 6, the ledger's latest row stays sent (not timeout_unknown), and the 'Spend is UNKNOWN ... Check later with imd-flop receipt ' guidance is lost.

On the success branch a cost_reported above the padded quote (e.g. 0.25 vs 0.186) is never recorded, so the exposure raise that the ledger-reservation tests guarantee is silently dropped and spentToday under-counts until a later refresh settles the row.

Fix: catch LedgerLockError around both post-call appends, print the request_id, response path and 'ledger row not written: pending' to stderr (and the normal JSON to stdout), then exit with the branch's own code (6 on timeout) or 1 as documented.

num() is used for cap set <FLOP/day>, --per-call and --job-budget. Number() accepts hexadecimal (0x10 is 16), binary/octal prefixes, exponent notation (1e-7), and surrounding whitespace, so cap set 0x10 silently sets a 16 FLOP/day cap and --per-call 1e-7 sets a per-call cap below the 1e-6 quote granularity that ceil6 produces, after which every run is refused with exit 3 and a confusing 'padded quote 0.000186 FLOP is over the per-call cap 1e-7'. run --max-tokens goes through Number() too (cli.ts:327) but is then integer-range checked; quote --max-tokens (cli.ts:289) has no check, so quote --max-tokens abc exits 0 and prints estimated_output_tokens null / estimated_cost_flop null / padded null, and with --provider flop would send max_tokens: null to the gateway.

None of this spends FLOP (quote is free, caps only ever refuse), so this is a hardening note.

Fix: validate FLOP amounts with a decimal regex (^\d+(\.\d{1,6})?$) and reuse the run path's integer check for quote.

loadConfig (imd-flop/src/config.ts:20) spreads config.json over DEFAULT_CONFIG without checking that payer is exactly "holder" or "requester". runJob only demands --job-budget when payer === "requester" (run.ts:159), and the cap branch at run.ts:214-221 treats every non-"holder" value as the requester case. With payer "sponsor" and no --job-budget, o.jobBudget is undefined, so left = NaN at run.ts:219 and q.padded > NaN is false: no refusal ever fires.

Every ledger row then carries payer "sponsor", which spentToday (ledger.ts:74 filters payer === "holder") and jobSpent (ledger.ts:78 filters payer === "requester") both skip, so nothing counts against any cap and status/cap show print today's spend as 0 while calls keep going out. The sibling field caps[seat] fails closed for malformed input (run.ts:154-157, prior finding TS-L10); payer does not.

Precondition: a writer of config.json other than config set payer (hand edit, a future writer, or the agent operating the CLI).

Fix: validate payer in loadConfig or next to the cap check and refuse with EXIT.REFUSED_CAP when it is not exactly holder|requester; make the run.ts:218 branch else if (cfg.payer === "requester") with a final fail-closed refuse.

When provider.complete() rejects with PreSendError (FlopProvider.complete wraps every assertPaidNetwork failure this way, providers.ts:139-143, and mintChildKey failures too), the catch block builds reason = nothing sent: ${err.message} with only 0x+64-hex stripped (run.ts:249) and appends the refused_local row with cap_charge 0 (run.ts:250). appendLedger runs assertNoSecrets on the row.

Any other 64-or-more hex run (HEX64 at secrets.ts:52 matches bare hex and decimal digit runs), a Bearer ... or flop_ek_... shaped substring in the message is not stripped. Those strings come from the RPC/faucet the recheck talks to (gateway.ts: eth_chainId error: ${j.error.message}, rpc error: ..., Ethereum chain id ${chainId} ...; a chain id of 0xff..ff prints as a 78-digit decimal).

When the scan hits, appendLedger throws CliError(REFUSED_RULE) from inside the catch: the refused_local line is never written, the pre-call sent row (cap_charge = padded quote) stays the latest line for that request_id, and the CLI exits 5 'secret scan blocked writing ledger.jsonl' instead of 1 'nothing sent'. spentToday counts the phantom reservation for the rest of the UTC day, so the next run is refused with 'daily cap reached' although nothing was minted or sent. receipt <id> --refresh cannot clear it (no gateway receipt exists for an unminted request; cli.ts:442 keeps prev.cap_charge) and status lists it as pending.

This breaks the README invariant for this path ('the latest ledger line is refused_local with cap charge 0'), which TS-L11 tests only with a clean message.

Fix: build the ledger reason from a fixed vocabulary (e.g. nothing sent: pre-send refusal) or pass it through redactFlagged before the append, and if the append still throws, still write a minimal refused_local row and throw the EXIT.ERROR 'nothing sent' CliError; never let a scan failure keep the sent reservation live.

A timed-out attempt has a ledger row but no receipt file; the README says to check it later with receipt <id> --refresh. In that state saved is null, so the merged receipt at cli.ts:418 is built only from classifyReceipt, which carries no seat, did, ss58 or network.

The file written at cli.ts:422 therefore lacks seat and did. matchReceipt (src/match.ts:30-31, 43-44) then reports fields seat, did, seat(link), did(link), and the attempt shows match=mismatch in receipt, receipt --refresh and status. Every later refresh spreads the same saved (still without seat/did), so the mismatch is permanent.

Meanwhile the ledger booking at cli.ts:435-447 keys off identityOk alone, so the settled amount IS booked against a receipt whose match says mismatch, contradicting the documented rule that matches means the receipt agrees with its records. Operators are told to treat mismatch as a revoked/rotated-DID signal; a false alarm after every timeout either sends them chasing a non-issue or teaches them to ignore mismatches.

The non-refresh path (cli.ts:458) does copy seat/did from the ledger row, so only the refresh path is wrong.

Fix: when saved is null, seed seat, did, ss58 and network from ledgerRow (and mock_scenario for mock) before writing, as run.ts:297 does.

scanForSecrets visits only values. For an object it recurses into each value and passes the key as the field name, but the key string itself is never matched against the registry (loaded secrets), HEX64, FLOP_TOKEN, BEARER or PEM.

A completion whose usage object (stored verbatim in the response record, run.ts:261) carries a 64-hex string, a flop_ek_ token, a Bearer string or a loaded secret as a property name with a harmless value passes writeJsonSafe and lands in responses/.json (mode 0644); redactFlagged cannot clear it either because setNull only nulls values.

The README's rule 1 says 'any 64-hex value' and 'flop_ek_... tokens' are rejected before anything touches disk, and the gateway (which knows the child token it minted) is the party whose output this scan exists to filter. stdout is unaffected (run --json does not print usage).

Fix: in visit(), also run the string checks on each key k (treat it as a string value under field name k), and in redactFlagged delete or rename a flagged key. Merged from three specialist reports of the same defect.

takeLock creates ledger.jsonl.lock with openSync(path, 'wx') (ledger.ts:122) and only then writes the owner record {pid, host, token} (ledger.ts:123), with no fsync.

A SIGKILL, OOM kill, power loss, or a writeSync failure (ENOSPC/EIO, which is not EEXIST so line 126 rethrows without unlinking the just-created file) leaves an existing lock with no readable owner. readOwner returns null, provablyDead(null) is false by design ('unreadable or malformed: never provably stale', ledger.ts:92), so reclaimIfDead never fires regardless of age, and every subsequent withLedgerLock waits 5 s and throws LedgerLockError.

Every run on that home exits 10 'refused locally, nothing sent: ledger lock timeout' forever, receipt --refresh prints the misleading 'receipt and ledger disagree', and no message names the lock file or a recovery step. The same permanent state arises when the recorded host no longer equals hostname(). Fail-closed, so no spend is at risk; the cost is an outage of the paid path that the CLI cannot recover from.

Fix: make the owner record and the lock one atomic step (write the JSON to a private temp file in the same directory, then linkSync(temp, lockPath), which fails EEXIST exactly like 'wx'; unlink the temp), unlink the path before rethrowing a write failure, and/or treat a zero-byte lock older than the 30 s threshold as reclaimable; print the lock path in the exit-10 message. Merged from three specialist reports.

runJob requests provider.estimate() (which carries the full system+user prompt) before it reads the ledger. The 'daily cap reached' check (run.ts:216) and the requester 'remaining budget' check (run.ts:220) run only inside lockedCheck after the estimate returned.

When spentToday >= cap.daily, or jobSpent >= jobBudget, or a ledger cap_charge is unusable, the outcome is decidable from local state alone, yet the prompt is posted to /models/estimate (on --provider flop) and only then is the run refused with 'refused locally, nothing sent' and exit 3. When that estimate fails the user sees exit 7 ESTIMATE_FAILED and a refused_local row with reason 'estimate failed', not the cap refusal.

The sibling spend-guard tool was fixed for exactly this in commit 5c5b881 (audit 355a3703 I11: 'the prompt does not leave the machine for a request that was always going to be refused'); imd-flop was not. No FLOP is spent (the estimate is free); the prompt is disclosed to the gateway for a call that can never be sent and the exit code is wrong.

Fix: before provider.estimate, compute spentBefore and refuse with REFUSED_CAP (same reason strings, same refused_local row with quote_raw/quote_padded null) when left <= 0 or the ledger charge is unusable; keep the authoritative in-lock check for the per-call cap and the race. Merged from two specialist reports.

readJsonl parses every non-blank line with no error handling. appendJsonlSafe uses appendFileSync with no fsync, so a crash or disk-full event mid-append can leave a partial last line.

After that, latestAttempts throws SyntaxError on every call: run fails inside lockedCheck (fail-closed, nothing sent, but exit 1 rather than the documented exit 3 for an unusable ledger), and status, cap show and receipt all exit 1 with the bare parser message, which names neither the ledger file nor the line.

The README's exit-code table reserves 3 for 'a ledger cap_charge is unusable' and 1 for 'any unexpected error', so a script branching on 3 to alert on ledger problems never fires, and the operator has no diagnostic command left that works.

Fix: catch parse failures per line in readJsonl, raise a typed error naming the file and line number, map it to UnusableLedgerCharge/REFUSED_CAP in run, and let status and cap show report the corrupt line instead of dying.

After the refreshed receipt has already been written to receipts/.json (cli.ts:422), the ledger append at cli.ts:447 runs under its own withLedgerLock. If another process holds the lock (or the lock is stale and unreclaimable, see the zero-byte-lock finding), appendLedger throws LedgerLockError, the bare catch at cli.ts:448 prints the fixed string 'receipt and ledger disagree; reservation held, chain-final green blocked' and the command returns EXIT.OK.

The message is false (the ledger could not be written; nothing disagrees), the exit code tells a script the refresh succeeded, and the two stores are now inconsistent: the receipt file says state settled / settled 0.05 while the ledger's latest row is still state estimated, spend null, cap_charge 0.186. Only a later refresh that happens to get the lock repairs it.

The outcome is safe for spend (the reservation is kept), but the operator is told the wrong cause and a script cannot tell 'ledger updated' from 'not updated'.

Fix: catch LedgerLockError separately, report 'ledger lock timeout; settlement not booked, re-run --refresh', and exit non-zero (10 fits the documented meaning: lock not taken, nothing written); or write the receipt file only after the ledger append succeeds. Merged from two specialist reports.

The README accepts exit 1 for a post-call lock failure, and the pre-call/post-call split (10 vs 1) is implemented as documented (TS-I14 passes). But the failure mode is harsher than described. appendLedger at run.ts:322 (success) and run.ts:250 (timeout/error branch) is not wrapped, so the raw LedgerLockError escapes runJob and cli.ts:475 prints only 'imd-flop: ledger lock timeout'; nothing is written to stdout even with --json.

The operator gets neither the request_id, the response file path nor the receipt line, although the paid call completed and both files were written; the only way to find the attempt is status. On the timeout branch the same failure exits 1 instead of 6, the ledger's latest row stays sent (not timeout_unknown), and the 'Spend is UNKNOWN ... Check later with imd-flop receipt ' guidance is lost.

On the success branch a cost_reported above the padded quote (0.25 vs 0.186) is never recorded, so the exposure raise the ledger-reservation tests guarantee is silently dropped and spentToday under-counts until a later refresh.

Fix: catch LedgerLockError around both post-call appends, print the request_id, response path and 'ledger row not written: pending' to stderr (and the normal JSON to stdout), then exit with the branch's own code (6 on timeout) or 1 as documented.

reclaimIfDead decides a lock is stale from one read of path (ledger.ts:109) and then renames whatever is at path (ledger.ts:111) without re-checking. Between those two steps another waiter can finish the same reclaim and create its own live lock at path. The second reclaimer then moves that live lock aside.

The code anticipates this and links it back (ledger.ts:113), but between the rename and the link-back path does not exist, so any other waiter's openSync(path, 'wx') succeeds and it runs lockedCheck() while the first holder is still inside its body. The link-back then fails EEXIST and that reclaimer exits 10 'contested', and the live holder's file is left stranded as .stale.. (its releaseLock is a no-op).

Result: two cap checks read the same spent_before, both pass, both append sent, so the daily cap can be exceeded by one padded quote.

Preconditions: a holder that crashed leaving a lock older than 30 s with a dead pid on this host, plus three or more runs started together (e.g. automation retrying after a crash); the windows are microseconds, so this is an atomicity defect rather than an easy exploit. The comment at ledger.ts:104-106 claims two waiters cannot both act on one stale file; that no longer holds once the moved file is a live lock.

Fix: re-read path immediately before the rename and refuse to move it unless its owner is still the dead one (compare pid and token), or reclaim via open + fstat and only unlink if the inode still matches what was read; on EEXIST at link-back unlink the aside file only if its token is the mover's own. Merged from two specialist reports.

num() is used for cap set <FLOP/day>, --per-call and --job-budget.

Number() accepts hexadecimal (0x10 is 16), binary/octal prefixes, exponent notation (1e-7) and surrounding whitespace, so cap set 0x10 silently sets a 16 FLOP/day cap and --per-call 1e-7 sets a per-call cap below the 1e-6 quote granularity that ceil6 produces, after which every run is refused with exit 3 and the message 'padded quote 0.186 FLOP is over the per-call cap 1e-7'. run --max-tokens goes through Number() (cli.ts:327) but is then integer-range checked in runJob; quote --max-tokens (cli.ts:289) has no check, so quote --max-tokens abc exits 0 and prints estimated_output_tokens null / estimated_cost_flop null / padded null, and with --provider flop would send max_tokens: null to the gateway.

Nothing here spends FLOP (quote is free, caps only ever refuse): a hardening note.

Fix: validate FLOP amounts with a decimal regex (^\d+(.\d{1,6})?$) and reuse the run path's integer check for quote.

Re-audit of e99a2cf1 I14: the lock taken at run.ts:228 now maps LedgerLockError to exit 10 and nothing is sent (TS-I14 passes). One pre-call path still does not: when the estimate fails or returns no usable cost (run.ts:198, 200), refuse() appends a refused_local row through appendLedger (run.ts:189), which takes the lock itself.

A LedgerLockError there is not a CliError, so main exits 1 with 'imd-flop: ledger lock timeout', without the 'refused locally' prefix, without naming the estimate failure, and without the refused_local row. README.md:48 records this as a known gap, two lines after README.md:46 states the unconditional rule, so it is an accepted residual rather than a regression; listed so the re-audit of I14 is complete. Nothing is sent and no FLOP is at risk.

Fix: in refuse(), catch LedgerLockError around appendLedger and rethrow CliError('refused locally, nothing sent: ...', EXIT.REFUSED_LOCK), or let the original refusal code win since the row is informational. Merged from two specialist reports.

Re-audit of e99a2cf1 I12: fixed as far as a runtime check can go (TS-I12 passes; a promise-returning body throws TypeError and leaves no lock behind). syncResult (ledger.ts:146-152) only sees the promise after fn() has already run to its first await, so an async body's pre-await part executes under the lock, the TypeError is thrown to the caller, the lock is released, and the body's post-await part still runs unlocked (test/audit-v7d.test.ts itself asserts afterAwait === true).

The signature fn: () => T at ledger.ts:155 still accepts async functions at compile time, so a future caller gets the error only when the code path executes. Production callers (lockedCheck, appendLedger) are synchronous, so no current spend path is affected.

Fix: narrow the type so a promise-returning body fails tsc, e.g. fn: () => T extends PromiseLike<unknown> ? never : T, keeping the runtime check as a backstop.