Outside the cap promise (secrets, item 6). run.ts:247 builds the ledger reason from err.message with every 0x<64 hex> replaced by [hash], and line 250 runs the secret scan on that stripped text. When the stripped text passes, line 267 prints the UNstripped err.message on stderr. So a value the tool's own rule calls key-shaped (secrets.ts:52 HEX64: a 0x-prefixed run of 64 or more hex digits) is refused for the ledger row yet reaches stderr.

The strip exists for the genesis hashes in PaidGateError messages, which are public, but it is applied to every PreSendError, including child key mint failed (<name>: <message>) (gateway.ts:66), whose message is whatever the transport or the gateway echoed.

Expected: what stderr prints is what the scan passed (the stripped reason), or the message is withheld as line 251 does for other hits.

Actual: stderr shows the raw value.

Fix: print reason (already stripped and scanned) instead of err.message on line 267, or scan err.message itself and withhold on a hit.

Answer to item 2's question. A holder that dies inside the lock blocks every command on the seat for up to 30 s: each waiter gives up after 5 s (line 351) and exits 10 (run) or 1, and only a waiter arriving after the lock is 30 s old reclaims it.

Since review fixes 4 the lock is created with its owner already in it (createLock, lines 327-335), so a lock this tool wrote is never empty for an instant; and provablyDead (lines 279-283) is conclusive on the same host and pid namespace (ESRCH), with pid reuse only making a dead holder look alive, which is the safe direction. So for an owner that is readable, on this host and ESRCH, the age test adds nothing and the reclaim could run at once.

The age test must stay for a lock with no readable owner (a leftover from an older version or damage) and for a foreign host, which is never reclaimed.

Two cautions: (1) reclaiming sooner means more concurrent reclaim attempts, which widens the window of the rename race reported above, so close that first; (2) two containers that share the ledger volume and the same hostname but not a pid namespace would see each other's live pids as ESRCH, and neither the age nor the pid test protects there; a lock token re-check before every append (see the fix above) is the guard that does.

Area 3 (rows that cannot be placed; refusals that name no line) and area 7 (exit code table). ledger.ts placed() builds its message with JSON.stringify of the unusable value (ledger.ts:222-223). run.ts spentSoFar passes that whole message to refuse(), which appends a refused_local row whose reason is the message (run.ts:171). appendJsonlSafe runs assertNoSecrets on the row first.

When the unusable value is key-shaped (64 or more hex characters, a Bearer ... string, a flop_ek_... token, or any field value containing a loaded secret), the scan rejects the row and throws CliError exit 5 (secret scan blocked writing ledger.jsonl: reason: 64-or-more-hex (key-shaped) value) before the exit-3 CliError is reached.

Actual: run exits 5, prints no line number, writes no refusal row. Expected per README 'Exit codes' row 3 and the spend rules ('refuses the next call: exit 3, nothing sent. The message names the ledger line'): exit 3 naming ledger line <n>.

The same happens for estimate failed (<message>) if a provider error text is key-shaped (exit 5 instead of 7). Nothing is sent and no charge is lost, so the cap promise holds; this is outside the stated promise (an edited or damaged ledger) but breaks the README's 'names the line' claim and the exit code table.

Fix: scan/redact the reason before appendLedger in refuse() (as the pre-send path already does with provider error withheld by the secret scan), or build the placement message without quoting the raw value (quote its type/length instead) so the line number always reaches the operator.

Area 2 (lock lockout with no way back that the message explains). reclaimable() only reclaims a lock older than 30 s when its owner is provably dead on this host (provablyDead, ledger.ts:280: if (!o || o.host !== hostname()) return false;) or when it has no readable owner.

A lock left by a holder that died on a machine with a different hostname (a container that was removed, a laptop whose hostname changed between runs, a home on a shared or synced filesystem) is never reclaimed, so every run fails with exit 10 after a 5 s wait, indefinitely, and every reader that meets a line in flight fails with exit 1.

The same lockout happens on this host when the dead holder's pid has been reused by an unrelated long-lived process (process.kill(pid, 0) succeeds, so the owner counts as alive). The message names only the lock path and its age; it does not print the recorded owner (pid, host) nor that the way back is to confirm the owner is gone and remove the file. README documents 'A lock owned by another host is never reclaimed' but gives no recovery step either.

Inside the promise only in the sense that nothing is spent; it is an availability defect, not a cap break.

Fix: include the owner's pid and host in LedgerLockError messages and, for a lock past the reclaim window that cannot be reclaimed, add one sentence naming the file to remove once the owner is known to be gone.

On the 30 s question (task item 2): for a lock whose owner record is readable, on this host, and whose pid is gone (ESRCH), the window could be dropped to a few seconds safely, since createLock links the owner in atomically and a holder cannot be mid-write once its pid is gone; the window must stay for ownerless or foreign-host leftovers, and pid reuse remains the residual risk the window does not address anyway.

Mutation testing against the suite named in task item 8.

Seven single-line mutations were applied one at a time, npm run build && npx vitest run executed, and the source restored: (M2) holdFloor requires a trusted rather than a known read to bring a released hold back: caught (decision-properties, review-hold); (M11) the seed row no longer reports pastAdmitted to the caller: caught (booking, review-hold-2); (M12) ledgerLines no longer re-reads a torn line under the lock: caught (audit-v3, audit-v6, review-fixes stress, review-hold-2 stress); (M13) an unusable cap_charge counts as 0 in sumCharges: caught (audit-v3, audit-8ddc5d2); (M15) rows without a usable request id are dropped from placed(): caught (contract vectors, review-hold, review-hold-2); (M16) 'nothing was sent' releases from any unsettled state, not only sent: caught (booking, decision-properties); (M8) lockedCheck uses base.day (computed before the estimate, run.ts:151) instead of utcDay() read inside the lock: NOT caught, 24 files / 742 tests pass.

The suite never sets a fake clock (no setSystemTime/useFakeTimers in imd-flop/test), so the UTC day change between admission and booking that task item 1 asks about is untested.

With M8 the mutated program is not a cap break (the call is checked against and booked on the earlier day, so neither day exceeds its cap), but the comment at run.ts:208 states a rule the tests do not hold, and the related refused_local row already carries the pre-lock day (see the separate info finding).

Fix: add a test with a fake clock that starts run at 23:59:59.9Z with a slow estimate stub and asserts the sent row's day and spent_before are those of the new day; a second case asserts the same for a refusal written under the lock.

isSeatId accepts any 1 to 78 decimal digits and every user of a seat id (seat directory, config.caps[seat], ledger.ts onSeat filter v !== f.want, the link statement) compares the text. A tokenId is a number: link.ts signs EIP-712 with tokenId: BigInt(s.tokenId) (type uint256) and ownerOf is read with the same number, so "42", "042" and "0042" are one NFT seat for the wallet and the chain and three seats for imd-flop.

README.md line 4 ("It gives one imd seat one FLOP identity"), line 14 ("Refuses a second key for a seat unless --rotate, which writes a signed revocation record") and line 70 ("One DID per seat. init refuses a second key for a seat.") are not kept: init --seat 042 after init --seat 42 makes a second key and did:key, writes no revocation record, and the seat then has one daily cap and one daily total per spelling, so the seat's spend per UTC day is N times the cap with no PAST_ADMITTED row (the totals never meet).

Values above 2^256-1 (78 nines) are accepted as seats too. Inside the stated promise in the sense that only this tool writes the ledger; the cap promise is per seat and the seat is split.

Fix: canonicalise in validateSeat/isSeatId (reject a leading zero unless the id is "0", and reject values above 2^256-1), and have ledger.ts placed() treat a non canonical seat as not usable.

sumCharges adds cap charges as doubles (sum += row.cap_charge) and rounds once at the end (ceil6). knownAmount/usableLimit accept limits and charges up to AMOUNT_MAX = 2^53-1, but a double only resolves the 1e-6 grid up to about 2^33 FLOP. Once the running sum S is large enough that ulp(S)/2 exceeds a charge, S + charge === S: the charge is counted as nothing, on every later read, for the daily total (spentToday) and the job total (jobSpent) alike.

A 0.000001 charge vanishes from S >= 2^34 (1.7e10 FLOP), a 0.001 charge from about 1.8e13, a 0.186 charge from 2^51. Smaller drift is also possible below that: each addition can lose up to ulp(S)/2, e.g. base 65536 plus 300000 charges of 0.000003 totals 65536.899999 against a true 65536.9.

From 2^33 FLOP (8.6e9) a double no longer resolves neighbouring grid amounts, so roomLeft/checkBudget admit a padded quote that is 0.000001 over the room (random search over grid triples with cap = spent + padded - 0.000001: 0 of 300000 admitted with spent below 2^33, 65463 of 300000 with spent between 2^33 and 2^34, e.g. cap 14541661521.487915, spent 14541661520.477258, padded 1.010658).

README.md line 81 and rules.json R-g say "For charges and caps on the 6 decimal grid, rounding never admits a call over the cap" with a residual of at most 1e-12 FLOP; here every row is on the grid, the ledger is written only by this tool, and the overrun is unbounded. Magnitudes are far above devnet use, which is why this is low, but cap set explicitly accepts them.

Fix: add in integer micro units (BigInt(Math.round(charge * 1e6)), exact for grid charges) and compare in the same units, or refuse a limit or total above the largest value the grid is exact for, until money stage 2.

imd-flop admits on padded > floor6(cap - spent) (policy.ts roomLeft, checkBudget) and status reports over only on spent > cap.daily. The viewer decides the same row with one more float subtraction, floor6(cap - spent - cap_charge) < 0.

Both use the 1e-12 tolerance, but they apply it to different quantities: imd-flop to (cap - spent) * 1e6, a number near the charge in micro units whose own ulp is about 1e-6 once the charge is above about 4000 FLOP, the viewer to a number near 0.

For a cap of 8192 FLOP or more the float noise of cap - spent is above 1e-12, so for a row that fills the cap exactly the viewer gets about -1.4e-12, takes it for off the grid and floors it to -0.000001, while imd-flop's product lands within the tolerance and the call is admitted.

The row is then marked bad with the spend flag 'over the daily cap' (and with a settled receipt its kind is over_limit, an amber chip), for a ledger only this tool wrote and a day that status shows as exactly at its cap with over_cap false. README.md line 81 says the tolerance means 'float noise does not move an amount a whole step'; it does here, as rounding.ts says for amounts above 8192 FLOP, but only in one of the two readers.

Random search over grid triples with cap = spent + charge: 0 of 200000 differ with amounts up to 1000 FLOP, the first cases have a cap just above 8192 FLOP (36 of 200000 with spent and charge up to 5000 each, 284 up to 8192 each), and about 1 percent differ from 20000 FLOP up. Outside the cap promise (it is a viewer verdict), same ledger, two verdicts.

Fix: have the viewer use imd-flop's form (left = floor6(cap - spent), over when cap_charge > left), or do both in integer micro units, and add the triple below to contract/vectors/cap-compare.json for both parts.

The ledger text contract says a non blank line is one JSON value in JSON.parse's grammar. Node's JSON.parse reads 100000 (and 2000000) nested arrays without error; Python's json.loads raises RecursionError long before that (it read 5000 levels and failed at 100000 on Python 3.12.3), and loads() turns that into ValueError, so read_ledger_text reports the line as unreadable 'not valid JSON'.

The grammar has no depth limit, so the two readers cut the same bytes into different kinds, and since the latest line of a request wins, they disagree on the request's state and charge: imd-flop counts the deep line, the viewer shows the line before it plus a red unreadable row. No fixture in contract/fixtures/ledger-text/ covers depth.

The tool never writes such a line, so this is outside the cap promise (an edited ledger), but it is exactly the reader split item 4 asks about, and imd-flop does not fail closed on it.

Fix: state a depth limit in LEDGER_TEXT (for example 64) and enforce it in both readers (ledger-text.ts: reject after parse by walking the value; viewer: same walk, and keep the RecursionError branch), with a fixture on each side of the limit.

refuse() builds its row from base, whose day and ts were taken before the estimate (run.ts line 151). lockedCheck reads the day again inside the lock (line 209, 'The UTC day is read once, inside the lock, and used for both the cap check and the rows') and computes the totals for that day, but when it refuses it calls refuse(), so the refused_local row carries the old day beside spent_before (and a reason) worked out for the new day.

Across 00:00 UTC the ledger then holds a row dated day D whose spent_before is day D+1's total, and the viewer computes that row's 'daily cap left' from the two. The charge is 0, so no total moves: this is a record that contradicts itself and the comment, not a cap break.

Related test gap (item 8): replacing const day = utcDay(); in lockedCheck by const day = base.day; (the check and the sent row use the day from before the estimate, the opposite of the stated rule) passes all of npm test: the same 4 root-only failures as the unmodified tree, nothing else. So nothing in the suite, the stress blocks included, exercises a UTC day change between the start of run and its locked check.

Fix: pass the locked day to refuse() ({ ...base, day, ... }), and add a test with a faked clock that crosses midnight inside estimate().

settlement.ts exactAfter keeps the higher of two exact amounts with BigInt(incoming) > BigInt(known). Replacing that by the string comparison incoming > known (so "10" is below "9") changes no test result: npm test gives the same 4 failures as the unmodified tree (the 4 that need a non root user) and nothing else.

The grid builds the raw values of a row and of a read from the same table (RAW_OF[spend] and the same with two leading zeros), so whenever the float spends are equal the exact amounts are equal too, and the 'a higher one replaces a lower one' branch is only ever asked with equal values or an unknown one. contract/vectors/settlement-run.json and settlement-refresh.json do not cover it either.

In all 47 single line wrong rules were run against the full suite; 37 were caught and 10 survived.

Caught, among others ( the pastAdmitted comparisons, the hold floor max, receipt_seen, the carry, the seed mark, the exact pair rules, ceil6/floor6 swaps and tolerances, AMOUNT_MAX and 2^128 bounds, MIN_CAP, the job total's payer filter, the booking day, the lock window, the release token check, and the cap check or the booking step run without the lock, which the stress blocks catch).

Survivors that matter are this one, the UTC day read before the lock (run.ts finding) and the three in the ledger.ts:260 finding.

Five more survive but change nothing on a ledger only this tool writes or stay inside the 1e-12 tolerance: lowersSettlement without its SETTLES.has(prev.state) test, holdFloor returning the quote without Math.max(booked, quote) on a released row, sumCharges skipping refused_local rows, padQuote without its padded < raw test, and the tolerance test with < in place of <=.

A mutant counted as caught only when a test other than the 4 root only ones failed; under parallel load decision-properties.test.ts and one lock test in audit-v6.test.ts each failed once for unrelated mutants (timeouts), so every verdict that rested on one such failure was run again alone.

Six caught verdicts with several failing tests each were not run again (receipt_seen, the two raise rules, the released hold rule, decideFailure's unknown charge test, the booking step without the lock).

Fix: add to readRaws/prevRaws a second exact amount for the same float spend with a different digit count (for example RAW_OF[x] and that value times 10 minus 1), and a vector with booked "9" and a read of "10".

reclaimIfDead reclaims an old lock only when provablyDead: same host name and process.kill(pid, 0) gives ESRCH. Two ordinary crash cases never satisfy that, and a dead lock holder is inside the promise.

1. The pid is in use again: after a reboot or in a container pids are low and repeat, and when the CLI is the container's entrypoint the next run has the same pid as the dead holder, so it probes itself, finds the pid alive and waits for its own ghost. A lock that records this process's own pid with another token cannot have a live owner in this pid namespace, yet it is treated as live.
2. The host name changed (a container started again gets a new one): README.md line 47 says such a lock 'is never reclaimed' and stops there. In both cases every run exits 10 after 5 s and every command that needs the lock fails, for ever, with ledger lock timeout: <path> (<n> s old) is held: the message calls a dead holder's lock held, and neither it nor the README says the way back (remove the lock file once no imd-flop process is running on that home). It fails closed, so the cap holds; the defect is the lock out with no stated recovery. On the 30 s window (item 2): for a lock with a readable owner on this host in the same pid namespace, ESRCH is proof at any age, since pid reuse can only make a dead holder look alive and never a live one dead; the window adds safety only where that proof is unsound (two pid namespaces sharing one host name and one home, where a live holder's pid is invisible) and for ownerless leftovers of older versions, and there 30 s is not a proof either, only longer than any synchronous hold. So the window for a lock with a readable, provably dead owner can be cut to about the waiter's own 5 s timeout (the hold is one synchronous read and append) without new risk in the single namespace case, and the ownerless case should keep 30 s. Lowering it to 0 is caught by two tests in review-hold-2.test.ts (the killed writer stress block and the young empty lock test). Fix: treat owner.pid === process.pid && owner.token !== mine as dead, record the process start time (or boot id) beside the pid and compare it, and add the recovery sentence to the timeout message and the README.

Three wrong rules, each a one line change, leave npm test with the same 4 root only failures as the unmodified tree. (1) jobSpent with a day filter added ([onJob(job), onProvider(provider), onPayer("requester"), onDay(utcDay())]): the job budget then counts today's rows only, so a requester job gets its whole budget again after 00:00 UTC.

README.md line 81 and the comment on jobSpent ('on any day') say otherwise, and item 1 asks for a job budget beside a UTC day change, but no test or stress block books a requester job on two days.

(2) isUtcDay without its round trip (utcDay(new Date(...)) === v): V8 parses 2026-02-30T00:00:00Z as 1772409600000 (2 March), so the day '2026-02-30' becomes usable, differs from today, and its row is left out of the daily total without a word instead of refusing the next call; the viewer (strptime) still flags it, so the two parts would differ. contract/vectors/ledger-placement.json has no day that matches the pattern and is not a calendar date.

(3) overDailyCap with >= (policy.ts line 204): status then prints OVER CAP for a day that is exactly at its cap, the case where the viewer already differs from imd-flop (build-lane.py:218 finding); every over_cap assertion in the suite is either clearly over or clearly under.

Fix: a test with a faked clock that charges one requester job on day D and expects the refusal on day D+1; ledger-placement vectors for 2026-02-30, 2026-04-31 and 2025-02-29 (cannot be placed, in both parts); a status test with the total equal to the cap expecting over false, and the same row in the viewer vectors.

Look-for item 6 (an Ethereum RPC URL reaching the ledger or stderr) and item 7 (a sentence the code does not keep). Not part of the cap promise: it is rule 1, keys stay local, and the comment above postEthRpc (gateway.ts:216-219): "The URL often carries a key (userinfo or a path token), so no message from here quotes it."

postEthRpc replaces the URL only in a transport error (gateway.ts:238). The JSON-RPC error text the server itself sends is quoted as it comes (gateway.ts:261), and nothing registers the RPC URL as a secret (registerSecret is called only for the seat seed, the gateway bearer and the child token), so the secret scan cannot see it either: a path token is not 64 hex, not "Bearer ..." and not flop_... shaped.

Where the text goes:

• run.ts:128, the first paid-network check: stderr, "refused locally, nothing sent: eth_chainId error: ...", exit 5.
• run.ts:71 and 134, the owner check: stderr, "link does not verify, refusing: owner check failed: eth_chainId error: ...".
• providers.ts:145, the recheck before the mint: PaidGateError, then run.ts:247 builds the ledger reason "nothing sent: ", the scan at run.ts:250 finds nothing, and bookFailure appends that reason to ledger.jsonl. It is also printed at run.ts:267.

Impact: with an RPC endpoint or proxy that repeats the request URL in its error (an expired or rate limited key is the usual moment), the holder's RPC key lands in ledger.jsonl, a file the viewer reads, and on stderr. Low: it needs a server that echoes the URL.

What I ran: the three functions against a stub fetch (below). What I only read: the path from PaidGateError through run.ts:247-256 into the ledger row.

Fix direction: pass every message that leaves postEthRpc's callers through the same replacement (rpcUrl, href, and the URL's userinfo and path), or do not quote server text at all.

Look-for item 4. Outside the cap promise: the tool never writes nested values, so only an edited ledger holds such a line. It is inside the ledger text contract, which says a line that is not blank is one JSON value in JSON.parse's grammar (contract/README.md:87), for imd-flop and the viewer alike.

imd-flop reads the line with JSON.parse (ledger-text.ts), which has no depth limit that matters: a line nested 2,000,000 deep is a row. The viewer's loads() turns Python's RecursionError into "not valid JSON" (build-lane.py:104-105). On Python 3.12.3 that starts at 9997 levels, and the number belongs to the Python build, not to the contract, so two viewers can differ too.

Verdicts that differ for the same bytes: imd-flop counts the row (its cap_charge is in the day's total and status lists the request), while the viewer shows "ledger line 1: not valid JSON" as an unreadable row and the request is not in the lane. Neither side fails closed in the same way, and contract/fixtures/ledger-text has no fixture for nesting, so nothing pins either reading.

Apart from this one, I found no byte sequence the two readers read differently: 25,000 generated files (odd numbers, escapes and surrogates, invalid UTF-8, every blank character and its near misses, BOM, CR and CRLF, duplicate keys, request ids at the edges) gave the same line numbers, kinds, reasons, parsed values (compared as double bits and UTF-16 units) and group keys from dist/ledger-text.js and build-lane.py.

Fix direction: give the contract a nesting limit both readers enforce (a small one: the tool writes none), with a fixture on each side of it.

Look-for item 8. A gap in the tests, not a defect in the shipped rule, except that the first one is the guard the lock race in the other ledger.ts finding runs through.

I changed one rule at a time in a copy, rebuilt, and ran the tests. 21 changes were tried. 15 were caught by test/decision-properties.test.ts and the stress blocks (every change to decideBooking, holdFloor, exactAfter, stateAfter, decideFailure, the carry of PAST_ADMITTED, the seed row's mark, the re-read under the lock, and reclaiming an ownerless lock). These six pass the four named files and the whole suite (742 passed, default STRESS sizes):

1. ledger.ts:294, if (reclaimable(readOwner(aside))) { becomes if (reclaimable(readOwner(aside)) || Date.now() > 0) {. Wrong rule: a waiter that moved a lock aside deletes it without looking whose it is, so a live holder's lock is reclaimed. No test has a second waiter arrive at a dead holder's old lock.
2. ledger.ts:359, the line if (readOwner(path)?.token !== token) return; removed. Wrong rule: a holder leaving removes whatever lock is at the path, another holder's included.
3. ledger.ts:280, if (!o || o.host !== hostname()) return false; becomes if (!o) return false;. Wrong rule: a lock taken on another host (a shared home) is reclaimed when no process has that pid here.
4. ledger.ts:142, !(row.state === "refused_local" && row.cap_charge === 0) becomes !(row.state === "refused_local"). Wrong rule: a refused_local row with no request id and a charge above 0 is left out of every total with no refusal (item 3: a charge dropped silently).
5. run.ts:209, const day = utcDay(); becomes const day = base.day;. Wrong rule: the day of the cap check and of the sent row is the one read before the estimate, outside the lock, so a call admitted just after midnight UTC is checked against the day before and booked on it (item 1: a UTC day change). The comment above the line states the rule; nothing tests it.
6. settlement.ts:251, charge > admitted becomes charge > admitted + 1e-6. Wrong rule: a booking that raises a charge by up to 0.000001 FLOP says nothing, and each one can add 0.000001 to the day's total with no PAST_ADMITTED. The property "a booking says it passed what the cap admitted exactly when it makes the day total grow" only draws amounts further apart than that.

Impact: any of these can come back in a later change and the 742 tests stay green. 1 to 3 are the lock's safety rules, and the stress blocks, which are the only tests with real contention, never exercise them.

Look-for items 2 and 3. Inside the promise when the state comes from the tool's own crash (a torn write that lost only the final newline byte); outside it when the newline was lost by an edit. Either way the tool fails closed afterwards and names the line, so the cap is not passed: the defect is that the tool's own write turns a ledger it has just read as good into a damaged one, at the worst moment.

The ledger text contract reads a last line with no final newline as a line (contract/fixtures/ledger-text has that fixture), so every reader accepts such a ledger and the cap check passes. appendJsonlSafe (store.ts:21) then appends JSON + "\n" without looking at how the file ends. The new row lands on the same line: {row a}{row b}\n, which is not valid JSON.

In run this happens at run.ts:214, after the cap check and before the paid call: the sent row is written glued, the call goes out, and the booking step that follows cannot read the ledger (UnreadableLedgerLine, exit 1). From then on every command refuses with "ledger line N cannot be read: not valid JSON; next call refused. Repair or remove that line." Line N now holds two rows that both carry a charge, one of them for a call that was really sent, and the message offers "remove" as a way back: a holder who takes it drops both charges from the totals.

The same missing check is why a torn line grows: run.ts:184 answers an unreadable last line by calling refuse(), which appends a refused_local row onto the torn fragment at every refused run, so the line the message names holds whole later rows as well.

What I ran: the library calls below (dist/ledger.js appendLedger and spentToday). What I only read: the path through run.ts.

Fix direction: under the lock, before an append, check that the file is empty or ends with "\n"; when it does not, write "\n" first (the fragment then stays its own line and is named alone) or refuse.

The ledger text contract reads a last line with no final newline as a line, so a ledger whose last write lost only its newline (a torn write by the tool's own crash, inside the promise) passes the cap check. appendJsonlSafe then appends JSON+"\n" right after it. The two rows share one line, which is not valid JSON. In run this append is the sent row (run.ts:214), written after the cap check and before the paid call.

The paid call goes out, and the booking step and every later command then refuse with ledger line N cannot be read ... Repair or remove that line. Line N holds two charged rows, one of them for a call that was really sent. An operator who follows 'remove' drops both charges from the totals.

The cap is not passed at the time (the tool fails closed), but the tool's own write damages a ledger it had just read as good, and the recovery the message suggests loses a real charge.

Fix: under the lock, before appending, check that the file is empty or ends with \n, and write a \n first (or refuse) when it does not.

isSeatId accepts any 1 to 78 decimal digits, and every use (seat directory, config caps, the ledger seat filter) compares the text. The chain and the link signature use BigInt(tokenId), so '42', '042' and '0042' are one NFT seat on chain and separate seats to imd-flop. README line 70 ('One DID per seat. init refuses a second key for a seat') is not kept: init --seat 042 after init --seat 42 creates a second key and DID with no --rotate and no revocation record.

The seat then has one daily cap and one daily total per spelling, so its spend per UTC day is N times its cap, and no row carries PAST_ADMITTED because the totals never meet. Values above 2^256-1 are accepted too. Inside the promise in the sense that only this tool writes the ledger, but the per-seat cap is split.

Fix: canonicalise in isSeatId/validateSeat (no leading zero unless the id is '0', value at most 2^256-1), and treat a non-canonical seat in a ledger row as not placeable.

Item 2: a lockout with no explained way back. A dead lock holder is inside the promise. provablyDead requires the same hostname and ESRCH. A holder that died in a container that was then recreated with a new hostname, or whose pid now belongs to another process (common for a container entrypoint, where the next run can even get the same pid as the dead holder), is never reclaimed.

Every run exits 10 after 5 s and every other locking command exits 1, at any age of the lock. The message calls the lock 'held' and prints only the path and age. Neither it nor README line 47 ('A lock owned by another host is never reclaimed') gives the owner (pid, host) or the recovery step (remove the file once no imd-flop process is using the home).

It fails closed, so the cap holds.

Fix: print the recorded owner in the message and, past the reclaim window, name the file to remove once the owner is known to be gone. Also treat owner.pid === process.pid with a foreign token as dead. On the 30 s window, see the lock-reclaim finding.

Item 8. Each change was applied alone in a copy of imd-flop, then rebuilt with tsc and run with the full vitest suite (default STRESS sizes). Each left Tests 742 passed (742).

(1) ledger.ts:294 reclaimable(readOwner(aside)) -> reclaimable(readOwner(aside)) || Date.now() > 0: a waiter deletes whatever lock it moved aside, including a live holder's. No test has a second waiter at a dead holder's old lock, which is the race in the lock-reclaim finding. (2) run.ts:209 const day = utcDay(); -> const day = base.day;: the cap check and the sent row use the day read before the estimate, against the comment above the line.

No test uses a fake clock or crosses 00:00 UTC (item 1's day change). (3) settlement.ts:251 charge > admitted -> charge > admitted + 1e-6: a booking that raises a charge by up to 1e-6 FLOP prints no PAST_ADMITTED. The decision-properties grid never draws amounts that close.

(4) settlement.ts:211 BigInt(incoming) > BigInt(known) -> incoming > known: exact amounts compared as text ('10' < '9'). The grid never pairs two exact amounts of different length. As a control, the same harness with ledger.ts:177 sum += row.cap_charge -> sum += 0 fails 99 tests.

Fix: add a two-waiter reclaim test, a fake-clock test that crosses midnight inside estimate(), grid amounts within 1e-6 of the admitted charge, and a vector with booked spend_raw '9' and read '10'.