Reproduced by running.

RULES.md 3.1 clause 14 says an integer must be safe (at most 2^53-1), that a larger value in an event field makes the event malformed, and that this holds for every integer field including index and block_number; clause 7 says the escrow rules read events the same way, and section 2 says a malformed event can never make an escrow look funded, claimed or refunded. census.ts (isInt, Number.isSafeInteger) and recount.py (as_int, MAX_SAFE) both classify such an event as malformed_dropped. escrow.ts structureProblem uses Number.isInteger for index (line 99) and block_number (line 101), so the same finalized hasStation.EscrowOpened or EscrowReleased with index 9007199254740993 is treated as well formed, grouped, and used as evidence.

The TypeScript census and the escrow module therefore disagree about the same event, and the escrow state comes from an event the spec says is never evidence. Because JSON.parse rounds 2^53+1 to 2^53, two distinct indexes also collapse into one event identity in escrow.ts (reported event_index 9007199254740992). Can cause a wrong escrow state as the spec defines it; no network, sign or spend path.

Fix: use Number.isSafeInteger in structureProblem for index and block_number (and in isInt at line 108), matching census.ts.

Reproduced by running.

RULES.md section 2 says that when any event page is structurally invalid (census clause 12) every escrow in the result is unverified with a note naming the page, and clause 14 says a page field holding an integer above 2^53-1 refuses the census. census.ts checkPage uses Number.isSafeInteger and refuses such a page; escrow.ts pageProblem (lines 112-125) uses this isInt helper built on Number.isInteger, so a page with to_block 9007199254740993 (or from_block, page or next_page of that size) passes as valid.

The escrow module then reads its events and reaches claimed, funded or refunded from a page the spec and the sibling module say is invalid. The two modules read the same page file differently in a snapshot: the census refuses and the escrows show a state. Can cause an escrow state where the rules demand unverified; no network, sign or spend path.

Fix: make isInt use Number.isSafeInteger so pageProblem matches census.ts checkPage.

Reproduced by running. RULES.md 3.1 clause 12 says an event page file that cannot be parsed as standard JSON (RFC 8259) refuses the census and is never turned into a count, and section 2 says such a page leaves every escrow unverified.

RFC 8259 section 8.1 requires JSON text to be UTF-8. readFileSync(path, 'utf8') replaces every invalid byte with U+FFFD instead of failing, so a page containing an invalid byte (for example 0xFF inside an account string) parses, and the garbled file is counted as a complete census and used as escrow evidence. tools/recount.py opens the file with encoding utf-8 and refuses it (exit 2).

This is a direct TypeScript against Python disagreement on a page file, of the kind the built-in cross-check (scripts/compare-recount.mjs) would flag as disagree-on-refusal if such a fixture existed; none does. The same lossy read applies to every fixture file (faucet-health.json, rpc-head.json and the rest). Can cause a wrong escrow state and a count presented as complete from a file the rules say to refuse; no network, sign or spend path.

Fix: decode with new TextDecoder('utf-8', { fatal: true }) and report a decode failure as 'not valid JSON' in loadErrors and pageErrors, which already makes the census refuse and every escrow unverified.

Reproduced by running.

RULES.md 1.1 says that when there is a previous snapshot on the same genesis, RPC health ok also needs no rollback, no changed finalized hash and no finalized height stuck longer than the stale limit, and rpc.stale must be true when the height is stuck. status.ts classifyRpc implements this through opts.previous, and snapshot.ts buildSnapshot forwards o.previous, but cli.ts builds the snapshot without ever reading the last line of the --log file (the previous snapshot is right there: appendSnapshot reads it for seq and prev_hash).

So in the only production path, these three checks never run: a second snapshot whose finalized height is 1000 blocks lower than the first, with a different hash, shows rpc.health ok, stale false and an empty conflicts list. The PR description lists 'rollback, changed finalized hash' among tested claims; they are tested only at the unit level on classifyRpc with a hand-built previous.

This is a wrong health and stale value (not a wrong reset flag), and the lower finalized height is then used to bound escrow evidence. No network, sign or spend path.

Fix: in the snapshot command, when --log is given, read the last snapshot with readSnapshots and pass { genesis: status.genesis.rpc, finalized_height, finalized_hash, observed_at: rpc.observed_at } as previous to buildSnapshot when its genesis is the pinned one (and add a cli-check for it).

Reproduced by running. RULES.md section 1 says reset_detected is false only when both the faucet and the RPC report the pinned genesis, and section 1.1 says that for the faucet health body 'the HTTP status wins' and only HTTP 200 counts.

The faucet /chain reading is not held to any of that: networkStatus reads chain.body.genesisHash even when chain.http is null with an error set (no response), when chain.http is 500, and when fetched_at is eight days old or null, and resetDetected then returns false.

The HttpResult type says body is null when there was no response, so in M0 this needs an inconsistent fixture; in M1 a transport that keeps a cached or partially read body on a failed request would clear the reset flag from a read that did not happen. Severity is low because the input violates the HttpResult contract and the RPC must still agree; it is a reset value derived from a non-report rather than a wrong flag on well-formed input.

Fix: treat the /chain genesis as unknown unless chain.http === 200 and chain.error is null (and optionally apply the same freshness rule as the health reading), and note a rejected reading in conflicts.

Reproduced by running. escrow.ts treats more than one distinct finalized hasStation.EscrowOpened for one escrow id as conflicting evidence ('more than one distinct finalized open for this escrow', line 387) and leaves the escrow unverified, but that branch is only reached when there is no finalized release or refund.

When a release (line 372) or refund (line 379) is present, the code drops the opens from the evidence when opened.length is not 1 and reports claimed or refunded without any note that the chain shows two distinct opens for one id, which on a well-behaved chain is impossible and on a reorged or inconsistent page set is a sign the pages cannot be trusted.

The same evidence set is therefore judged conflicting or clean depending on whether a terminal event happens to be present, and the inconsistency disappears from the notes. RULES.md section 2 asks for 'unverified with a note' on conflicting evidence and says more conflicting evidence never gives a more confident answer.

Severity low: claimed still rests on a finalized release that exists in the input, so a consumer acting on it is acting on real evidence; the defect is lost information and an inconsistent conflict rule.

Fix: compute the 'more than one distinct finalized open' conflict before the terminal branches (alongside the release/refund multiplicity conflicts at lines 368-369), or at minimum add a note when opened.length > 1 on the claimed and refunded paths.

Reproduced by running.

RULES.md 3.1 clause 7 defines a malformed event and says 'the escrow rules read events the same way'; a block_number that is 'present but neither null nor an integer' is malformed, and a negative integer is an integer. census.ts readEvent and recount.py parse_event accept -5 and the event is then skipped by the block range filter (clause 4). escrow.ts structureProblem rejects it as 'block_number is not a whole number or null', so the same event is reported as 'malformed event ignored' by the escrow module and as 'outside the request or their page's range were skipped' by the census.

Both outcomes are conservative (never evidence; a finalized release naming the escrow leaves it unverified either way), so this is an inconsistency in notes and counts only.

Fix: drop the n < 0 test and let the page range check classify it as out of range, so the notes agree with the census.

RULES.md 1.1 requires, when there is a previous snapshot on the same genesis, that RPC health be degraded on a rollback, a changed finalized hash, or a finalized height stuck longer than the stale limit, and that rpc.stale be true when stuck. status.ts implements this behind StatusOptions.previous and snapshot.ts forwards o.previous, but cli.ts builds SnapshotOptions without previous even when --log names a log that already holds snapshots (store.appendSnapshot reads that log for seq and prev_hash only).

No test or script exercises the wired path: the only uses of previous are three unit tests of networkStatus.

Result: a wrong health value (ok instead of degraded), a wrong stale value (false instead of true on a stuck height) and a dropped conflict in the page, feeds and MCP. Found by reading, reproduced by running.

Fix: in the snapshot command, read the last line of --log (readSnapshots) and, when its status.genesis.rpc is non-null, pass {genesis, finalized_height, finalized_hash, observed_at} as previous to buildSnapshot; add a cli-checks case.

RULES.md 3.1 clause 14 says an integer must be safe (at most 2^53-1): a page field holding a larger value refuses the census and an event field holding one makes the event malformed, and this holds for every integer field (index, block_number, page, next_page, from_block, to_block).

RULES.md section 2 says a structurally invalid page (census clause 12) leaves every escrow unverified, and a malformed event (wrong types) can never make an escrow look funded, claimed or refunded. escrow.ts implements isInt() (line 107-109, used by pageProblem) and structureProblem() (line 99 for index, line 101 for block_number) with Number.isInteger, not Number.isSafeInteger, while census.ts and recount.py use the safe check.

So the same page set is refused by both census implementations but accepted by the escrow module, which then reports claimed/refunded with evidence from it. For an event index of 2^60 the census counts the event as malformed_dropped while the escrow module uses it as the event identity and evidence (event_index rendered as the rounded 1152921504606847000).

This is a confident state from input the spec classifies as invalid, and the escrow and census modules disagree on what is evidence. Found by reading, reproduced by running.

Fix: use Number.isSafeInteger in isInt() and in structureProblem's index and block_number checks, and add escrow tests mirroring fixtures/census-unsafe-integer.

networkStatus reads chain.body.genesisHash and feeds it straight to resetDetected() (line 271). It never looks at chain.http, chain.error or chain.fetched_at. RULES.md 1: 'Unknown is never good news' and reset_detected is false 'only when both the faucet and the RPC report the pinned genesis'.

RULES.md 1.1: 'A reading time later than the snapshot time is a conflict, noted in conflicts, whatever that reading's health.' The /chain reading is the only reading whose time is never parsed, so a genesisHash carried in the body of an HTTP 500, a reading taken weeks before the snapshot, or a reading dated after the snapshot still produces reset_detected=false with an empty conflicts list.

The faucet /health and gateway readings are subject to freshness and future-time checks (applyFreshness) but the one reading that drives the reset flag is not. A consumer that gates spending on reset_detected===false can be cleared by a stale or error-status faucet response while the RPC side alone says nothing about the faucet. Found by reading, reproduced by running.

Fix: treat a /chain result as a genesis report only when http===200 and fetched_at parses, is not later than now and is within the stale limit; otherwise set genesis.faucet to null (reset_detected becomes null) and push a conflict for a future reading time, as applyFreshness does for the other two readings.

setup() copies every entry under the repository root except the SKIP names and .build-* prefixes. Nothing limits the copy to tracked files or to the directories the tests read (observatory/, interfaces/, imd-flop/).

An unreadable file at the repository root (here a 0-permission .mcp.json left by the environment) makes cpSync throw before any control runs; the exception is not caught, so mutants.json is empty, the step exits 1 and mutants-canary reports every outcome as 'missing'. The check is therefore red on a tree that is otherwise clean, and the README promise 'rerun this command on the same revision in a fresh clone and compare outputs/' is the only way to get a result.

Running the same commit from a fresh local clone gave 159/159 killed with both controls passing, so this is a robustness defect of the runner, not a false pass. Reproduced by running.

Fix: copy only git ls-files-tracked paths, or only observatory/ plus the sibling directories the tests reference, and wrap setup() so a copy failure is reported as a structured 'setup-error' outcome instead of a crash.

FixtureSource.fromDir tests existsSync(pagesDir) and then calls readdirSync on it. When event-pages exists but is a file, readdirSync throws ENOTDIR; the error propagates out of fromDir, the CLI prints the raw OS message and exits 2. tools/recount.py load_pages tests os.path.isdir and, when false, treats the scenario as having no pages, printing a partial census (covered [], whole request a gap) with exit 0.

RULES.md says the recount is written from the rules alone and both must agree, including on refusals; compare-recount.mjs would classify this scenario as disagree-on-refusal. Neither behaviour is a wrong escrow state or a complete census, but the TypeScript side fails with a loader exception rather than a clause-15 style refusal naming the entry, and the escrow path would likewise crash instead of returning unverified with a note. Reproduced by running.

Fix: in fromDir, when event-pages exists and is not a directory, record it in loadErrors and pageErrors ('event-pages: not a directory') so census refuses and escrows are unverified; mirror that in recount.py (raise Unreadable when event-pages exists and is not a directory).

Reproduced by running. RULES.md 3.1 clause 14 (binding for 'every integer field in these rules' and explicitly for the escrow rules via clause 7: 'The escrow rules read events the same way') says an integer must be safe (|v| <= 2^53-1); a larger value is not an integer, so an event field holding one makes the event malformed and a page field holding one refuses.

Section 2 says a malformed event 'can never make an escrow look funded, claimed or refunded'. src/census.ts:106 uses Number.isSafeInteger, but src/escrow.ts uses Number.isInteger in structureProblem (line 99 for index, line 101 for block_number) and in isInt (line 108, used by pageProblem for from_block/to_block/page/next_page).

Number.isInteger(9007199254740992) is true, so an EscrowOpened/EscrowReleased/EscrowRefunded with index or block_number 2^53+1 (parsed as 2^53) is accepted as finalized evidence and sets the state, and its evidence record carries a silently rounded event_index/block_number (9007199254740992). The same page is refused by the census (page field) or counted as malformed_dropped (event field).

Trust gap: the escrow module trusts an identity (genesis, block_hash, index) the spec says has no identity; two distinct indexes 2^53 and 2^53+1 collapse into one key. This can cause a wrong escrow state (funded shown where the rules require unverified).

Fix: use Number.isSafeInteger in structureProblem and isInt (escrow.ts lines 99, 101, 108), matching census.ts.

Reproduced by running.

RULES.md 1.1 says RPC health is ok only when every check runs and passes, including 'when there is a previous snapshot on the same genesis: no rollback, no changed finalized hash, and no finalized height stuck for longer than the stale limit', and 1.1 lists a backwards height as a conflict. src/status.ts:178 implements this only when opts.previous is given, and src/snapshot.ts:34 forwards o.previous, but the only producer of real snapshots, the snapshot command in src/cli.ts (lines 149 to 158), builds the snapshot without reading the last line of the --log file it then appends to (appendSnapshot at line 157 reads that line for seq and prev_hash, so the data is available).

The result: in a hash-chained log whose previous entry on the same genesis has finalized_height 3341575, a new snapshot whose RPC head reports finalized 3341500 is published with rpc.health "ok", rpc.stale false and conflicts []. A changed finalized hash at the same height, or a finalized height stuck for hours, is likewise never degraded.

This is a wrong health value (ok when a check the rules require did not run) and the only unit tests of the check (test/status.test.ts:98-120) pass previous by hand, so no check-step covers the wiring.

Fix: in the snapshot command, when --log is given, read the last snapshot (readSnapshots) and pass previous = {genesis: last.status.genesis.rpc, finalized_height, finalized_hash, observed_at} when those are non-null, into buildSnapshot; or else make rpc health unknown and note that the continuity check could not run.

Reproduced by running.

RULES.md 1.1: 'A reading time later than the snapshot time is a conflict, noted in conflicts, whatever that reading's health.' networkStatus applies this (applyFreshness, classifyRpc) to faucet /health, the gateway and the RPC head, but the faucet /chain result, the one reading whose body supplies genesis.faucet and therefore half of reset_detected (RULES 1: false only when both faucet and RPC report the pinned genesis), is read at line 244 with its fetched_at never looked at: no future-time conflict, no staleness, no 'no parsable time'.

The shipped fixtures/status-healthy/faucet-chain.json has fetched_at 2026-11-09T23:47:52Z while meta.now (the snapshot time) is 2026-11-09T23:47:41Z, 11 seconds in the future, yet the healthy status, feeds, page and MCP all publish conflicts [] and reset_detected false; the consistency step passes on it because every output agrees on the same unchecked value.

Trust gap and asymmetry: the same 11 second skew on faucet-health.json or rpc-head.json is reported as a conflict and lowers health, while on the reading that governs the reset flag it is silent. A faucet /chain reading from days before a reset (same genesis as the pin) would also set reset_detected false with no note while the RPC read is fresh.

Because RULES 1 makes reset_detected depend on the faucet's genesis report, callers treat false as 'safe to spend'; a stale or inconsistent report should at least be a conflict.

Fix: run the time checks on chain.fetched_at too: a time later than now goes to conflicts; a missing or unparsable time or one older than the stale limit should either make genesis.faucet null (so reset_detected becomes null, 'not enough evidence') or add a conflict, and the status-healthy fixture's fetched_at should not be later than its now.

Reproduced by running. For faucet /health the rules and classifyFaucet make the HTTP status win over the body ('A body that says ok with any other HTTP status is degraded'; 'only HTTP 200 counts').

For faucet /chain, the reading that supplies genesis.faucet, the body is read whatever the http field says: http 500 with error 'server error', or http null (no response) with error 'timeout', both with a body carrying the pinned genesisHash, give genesis.faucet = pinned and reset_detected false with conflicts []. A proxy or error page returning a cached or default body on a failing faucet is therefore counted as the faucet 'reporting the pinned genesis'.

Low because in M0 the HttpResult comes from a fixture and a live transport (M1) may never produce body with http null; still a trust gap in the status module itself, and the asymmetry with /health is not documented in RULES.

Fix: take genesis.faucet from chain.body only when chain.http === 200 (otherwise null, so reset_detected is null, 'not enough evidence'), and add a conflict or detail when a non-200 /chain carried a genesis.

Reproduced by running. When a snapshot supplies finalizedHeight (src/snapshot.ts:45 does so whenever the RPC genesis equals the pin, whatever rpc.health is), any copy with block_number above it is skipped with the note 'N event above the finalized height ignored' and the state is computed from the rest.

An EscrowOpened above the height leaves the escrow unverified (safe), but an EscrowReleased or EscrowRefunded above the height, marked finalized on the page, leaves a positive 'funded' with the opened event as evidence. The same happens when the RPC head is an hour stale (fixtures/status-stale-rpc: rpc.health degraded, finalized 3341575) because the height is still applied.

RULES section 2 lets 'funded' stand with no finalized terminal event, so this is allowed by the letter of the spec, but it is a trust asymmetry: the page and the RPC disagree about finality of a terminal event ('More conflicting evidence never gives a more confident answer'), and the consumer of escrows.json sees funded, not unverified, for an escrow that the retained raw page says was released.

The out-of-range rule (lines 313 to 322) already treats a suspect finalized release as a conflict; the above-height case is the same shape and should be handled the same way.

Fix: when a finalized terminal copy for this escrow is above the finalized height (or the height comes from a head whose health is not ok), push a conflict such as 'a finalized release above the RPC finalized height names this escrow' so the state is unverified, matching the out-of-range handling.

Reproduced by running. RULES section 4: 'Tests fail if any attempt is left in the log', and the canary step proves this for attempts made inside a test body. The check is a single afterAll hook that reads attemptLog() once.

Anything recorded after that hook, for example a blocked fetch called from a setTimeout, setImmediate or an unawaited promise that resolves after the last test, is recorded in memory and then discarded with the worker: the file passes, exit 0, and OBS_ATTEMPTS_FILE stays empty, so check.sh never sees it.

The same holds for a leftover attempt from a test in a file whose afterAll ordering runs the harness hook before another file-level hook (vitest runs after hooks in stack order, so a hook declared in the test file itself is caught, as verified). In M0 no src module schedules network calls, so the exposure is to future tests and transports (M1) that use timers or background retries; a retry loop that fires after the suite would leave no trace.

Fix: make recordAttempt append synchronously to OBS_ATTEMPTS_FILE when set (so check.sh can fail the test step on a non-empty attempts.jsonl regardless of timing), and/or add a process 'beforeExit' or vitest teardown check that rethrows if attemptLog() is non-empty.

pageProblem() (escrow.ts:112-125) validates page integer fields with isInt() at line 107-109, which uses Number.isInteger. RULES.md 3.1 clause 14 says an integer 'must also be safe: from -(2^53 - 1) to 2^53 - 1.

A larger value is not an integer, so a page field holding one refuses the census', and section 2 (lines 86-88) says a page that is structurally invalid per census clause 12 makes every escrow unverified with a note. census.ts isInt() (line 105-107) correctly uses Number.isSafeInteger, so the two modules disagree on the same file: the census refuses (exit 2) while the escrow command returns definite states claimed, refunded and funded from the page the rules call invalid.

Can cause a wrong escrow state as defined by the spec: a definite state from a page that must leave every escrow unverified. Found by reading, reproduced by running.

Fix: use Number.isSafeInteger in escrow.ts isInt() (and structureProblem) so pageProblem matches census checkPage.

structureProblem() checks index (line 99) and block_number (line 101) with Number.isInteger, not Number.isSafeInteger. RULES.md 3.1 clause 14 says a value larger than 2^53-1 'is not an integer, so ... an event field holding one makes the event malformed. This holds for every integer field in these rules (index, block_number, ...)' and clause 7 says 'The escrow rules read events the same way'.

Section 2 says a malformed event 'can never make an escrow look funded, claimed or refunded'. The census (census.ts readEvent/isInt) counts the same event in malformed_dropped, so the escrow and census disagree about the same event. Can cause a wrong escrow state as defined by the spec (funded from an event the rules define as malformed).

Note too that JSON indices above 2^53 collapse in JavaScript (9007199254740992 and 9007199254740993 parse to the same number), so two distinct chain events would share one (genesis, block_hash, index) key in escrow.ts. Found by reading, reproduced by running.

Fix: use Number.isSafeInteger at lines 99 and 101.

FixtureSource.fromDir reads page files with readFileSync(path, 'utf8'), which silently replaces invalid byte sequences with U+FFFD, and then JSON.parse succeeds.

RULES.md clause 12 says a page file that 'cannot be read or parsed as standard JSON (RFC 8259 ...)' refuses the census and leaves every escrow unverified; RFC 8259 section 8.1 requires JSON text to be UTF-8 encoded. tools/recount.py opens the file with encoding='utf-8' (strict), gets a UnicodeDecodeError (a ValueError) and exits 2 with 'cannot read ... invalid start byte'.

So a corrupted or non-UTF-8 page yields a census marked complete, with a corrupted by_account key, and definite escrow states in TypeScript, where the rules and the independent recount both refuse. The built-in cross-check does not cover this because no fixtures/census-* scenario holds such a file.

Impact: a count shown as complete from an unreadable page; TypeScript and Python disagree. Found by reading, reproduced by running.

Fix: decode with new TextDecoder('utf-8', { fatal: true }) (or check the buffer with Buffer.isUtf8) before JSON.parse and treat a decode failure like a parse failure (push to loadErrors and pageErrors).

RULES.md 1.1 (lines 43-44) says RPC health ok requires, 'when there is a previous snapshot on the same genesis: no rollback, no changed finalized hash, and no finalized height stuck for longer than the stale limit'. classifyRpc() implements these checks only when StatusOptions.previous is supplied (status.ts:178-194) and buildSnapshot forwards o.previous (snapshot.ts:34).

The snapshot command, even with --log where the previous snapshot is on disk (appendSnapshot reads it at store.ts:54), never sets previous (cli.ts:149-152), so the check silently cannot run and health is still 'ok'. Section 1.1 says a check that could not run never yields ok ('ok needs every check below to run and pass'). This yields a wrong health value and a missing conflict: a chain that rolled back by 75 finalized blocks between two logged snapshots is shown healthy.

The unit tests (test/status.test.ts:98-113) exercise classifyRpc with previous directly, so nothing covers the CLI wiring. Found by reading, reproduced by running.

Fix: in the snapshot command, read the last line of --log (readSnapshots) and pass previous: { genesis: last.status.genesis.rpc, finalized_height: last.status.finalized_height, finalized_hash: last.status.finalized_hash, observed_at: last.status.rpc.observed_at ?? last.observed_at } when those are non-null; or mark rpc health unknown/degraded with a note when a log exists but no previous was applied.

Run on this machine (Node v24.21.0, Python 3.12.3): every step exit 0, 485/485 tests passed, recount 13 agree + 7 both-refused of 20 fixtures, mutants 159 killed, no attempts.jsonl. The digest over outputs/ was d7554801e2bf2c3d99ab65bd26d78d77afc646ca6be6df57e7c68817cf1ef7e4, not the expected decd38476868f2cd55209326f74de27f33214b404a2deaf69b66cadb85d3c372.

The run pin stores process.version, which is part of snapshot.json, snapshots.jsonl, pin.json and the get_snapshot_meta MCP transcript in each of the five scenario outputs, so the digest changes with any Node patch release and the README expectation cannot be checked except on v22.23.4. Not a correctness defect; reported so the difference is explained rather than taken as a regression.

The requested Node 22 run was not possible on this machine, so the digest claim remains unverified here.

Fix: document the digest as Node-version-specific, or publish a second digest computed with pin.node excluded (for example over the four feed files only).

parseSpec() uses intAsBigInt so integers never round, but YAML floats still arrive as IEEE doubles and toRational() rebuilds the fraction from String(v), the shortest round-trip form of the double, not from the literal in the file. drift.ts lines 11-14 promise 'match or mismatch only from exact integer arithmetic (BigInt)' and 'unknown ... when scaling leaves a fraction'.

A literal with more than about 17 significant digits is silently rounded first: 1.0000000000000000001 FLOP (decimals 18, which is 10^18 + 0.1 base units, not a whole number) becomes 1 and the item reports match against a runtime of exactly 1000000000000000000; the item's spec field shows 1. The same rounding could turn a true mismatch into a match when the discrepancy sits beyond the 17th digit of a FLOP amount with 18 decimals (for example 1200000.000000000000001 FLOP).

Impact: a wrong drift status; no escrow, health or reset effect. Found by reading, reproduced by running.

Fix: parse float scalars from their source text (the yaml library exposes the scalar source via a custom tag/resolver or by walking the CST), or treat any float whose String() form differs from its source text as unknown.

Reproduced by running. Merges the economics, permissions and math specialists' event-field findings. RULES.md 3.1 clause 14 says an integer must be safe (|v| <= 2^53-1) for every integer field, including index and block_number, and that an event field holding a larger value makes the event malformed.

Clause 7 says the escrow rules read events the same way. Section 2 says a malformed event can never make an escrow look funded, claimed or refunded. structureProblem() checks index (line 99) and block_number (line 101) with Number.isInteger, not Number.isSafeInteger. census.ts and recount.py both use the safe check. So one finalized event is malformed_dropped in the census and the recount, but the escrow module uses it as evidence.

JSON.parse also rounds 9007199254740993 to 9007199254740992, so two distinct indexes collapse into one (genesis, block_hash, index) identity, and the evidence shows the rounded value.

Impact: a wrong escrow state as the spec defines it (funded or claimed where the rules require unverified), and the escrow and census outputs disagree about the same event in one snapshot. No network, sign or spend path.

Fix: use Number.isSafeInteger at lines 99 and 101, and add an escrow fixture that mirrors fixtures/census-unsafe-integer.

Reproduced by running. Merges the economics and math findings. RULES.md 3.1 clause 12 says an event page file that cannot be read or parsed as standard JSON (RFC 8259) refuses the census and is never turned into a count.

Section 2 says such a page leaves every escrow unverified. RFC 8259 section 8.1 requires JSON text to be UTF-8. readFileSync(path, 'utf8') replaces invalid bytes with U+FFFD instead of failing. The garbled page then parses, is counted as a complete census and is used as escrow evidence. tools/recount.py opens the file as strict utf-8 and exits 2.

This is a direct TypeScript against Python disagreement that scripts/compare-recount.mjs would flag, but no fixtures/census-* scenario holds such a file. The same lossy read applies to every fixture file (meta.json, faucet-chain.json, rpc-head.json and the rest).

Impact: a census shown as complete, and a claimed escrow, from a file the rules say to refuse. No network, sign or spend path.

Fix: decode with new TextDecoder('utf-8', { fatal: true }) (or check Buffer.isUtf8) and record a failure as 'not valid JSON' in loadErrors and pageErrors.

Reproduced by running. Merges the economics, flow, permissions and math findings. RULES.md 1.1 says RPC ok needs every check to run and pass, including, when a previous snapshot on the same genesis exists, no rollback, no changed finalized hash and no finalized height stuck past the stale limit.

In those cases rpc.stale must be true. classifyRpc (status.ts:178-195) implements this only through opts.previous, and buildSnapshot forwards o.previous. cli.ts builds SnapshotOptions without previous, even when --log names a log whose last entry appendSnapshot then reads for seq and prev_hash. The only tests of the check (test/status.test.ts) pass previous by hand, so the wiring is untested, although PR #5 lists rollback and changed hash as tested.

Impact: a wrong health and stale value (ok and false) and a missing conflict on the page, the feeds and MCP. The lower, rolled-back finalized height is then used to bound escrow evidence. It cannot change reset_detected.

No network, sign or spend path.

Fix: when --log is given, read its last snapshot (readSnapshots). When that snapshot's status.genesis.rpc is non-null, pass {genesis, finalized_height, finalized_hash, observed_at: rpc.observed_at} as previous. Add a cli-checks case.

Reproduced by running. Merges the economics (low), flow (medium) and permissions (medium and low) /chain findings. RULES.md 1.1: 'A reading time later than the snapshot time is a conflict, noted in conflicts, whatever that reading's health.' networkStatus applies that check to faucet /health, the gateway and the RPC head, but never reads chain.fetched_at, chain.http or chain.error.

The shipped fixtures/status-healthy/faucet-chain.json has fetched_at 2026-11-09T23:47:52Z, 11 s after meta.now 2026-11-09T23:47:41Z. The status, and outputs/healthy/status.json from npm run check, still show conflicts [] and reset_detected false. The consistency step passes because every output agrees on the same unchecked value.

The same 11 s skew on faucet-health.json produces the conflict and a degraded faucet. A body carried on HTTP 500, on http null with an error (no response), or on a 39-day-old reading also counts as the faucet reporting the pinned genesis.

Impact: reset_detected false and an empty conflicts list from a /chain reading the rules treat as a conflict, or that is not a current report. A real reset still needs the RPC to report the pinned genesis too, which limits this to medium.

Fix: take genesis.faucet from chain.body only when chain.http === 200 and chain.error is null; otherwise use null, so reset_detected is null. Run the applyFreshness time checks on chain.fetched_at, so a future time is a conflict and an old or unparsable time leaves the faucet genesis unknown or noted. Correct the status-healthy fixture.

Reproduced by running. Merges the economics and flow findings. Clause 15 says every entry under event-pages must be a page file, and that anything else refuses the census and leaves escrows unverified.

When event-pages itself is a regular file, FixtureSource.fromDir (source.ts:125-127: existsSync, then readdirSync) throws ENOTDIR. The CLI exits 2 with the raw OS message for both census and escrow, rather than a refusal or an unverified result with a note. recount.py checks only os.path.isdir, treats the scenario as having no pages and prints status partial with exit 0. compare-recount.mjs would call this disagree-on-refusal, but no fixture exercises it.

It does not show a partial count as complete, but the independent witness is more lenient than the rules.

Fix: in recount.py raise Unreadable when os.path.lexists(pages_dir) and not os.path.isdir(pages_dir). In source.ts record 'event-pages: not a directory' in loadErrors and pageErrors.

Reproduced by running (permissions specialist). A finalized EscrowReleased above the finalized height is counted only as 'N event above the finalized height ignored', and the open alone gives funded. The same happens with fixtures/status-stale-rpc (rpc.health degraded, head an hour old), because snapshot.ts:45 applies the height whatever the RPC health.

RULES section 2 allows funded without a terminal event, so this matches the letter of the spec: funded is true as of the bounded height. However, the page and the RPC disagree about the finality of a terminal event that names this escrow, and a consumer reading escrows.json sees funded for an escrow the retained page says was released. The out-of-range rule (lines 313-321) treats the same shape as a conflict.

Fix: treat a finalized terminal copy above the height as conflicting evidence (unverified with a note), or at least name the ignored release or refund in the note.

Reproduced by running; found in this review, not reported by the specialists. RULES section 5 requires the page, the feeds and MCP to agree on every health value, reset_detected, conflicts and every escrow state. scripts/consistency.mjs finds cells with regexes over the raw HTML (line 114 for data-k cells, line 159 for rows) and never strips comments or looks at hidden, style or class visibility.

A page.ts change that wraps a row in a comment, or adds hidden or style="display:none" to a , removes the value from what a reader sees, while the checker still counts the cell as rendered and agreeing. The consistency canary has no tamper of this kind. Its existing tampers (dropping a row, a duplicate cell, text differing from data-v, an unmarked cell, a swapped label) are all caught, as verified.

This is evidence honesty: the step can report a pass for a page that hides the reset flag. The shipped page is fine (it has no comments).

Fix: strip comments before matching (or parse with a real HTML parser), fail on hidden, style or inline display on rows and cells, and add these tampers to consistency-canary.mjs.

Reproduced by running; found in this review. RULES section 4: 'A source scan fails any src module, other than guard.ts, that ... calls fetch, WebSocket ...'. The patterns are /\bfetch\s*(/ and /new\s+WebSocket\b/, so a call that does not put '(' straight after the word fetch, or does not put 'WebSocket' straight after 'new', passes the scan.

Examples are fetch.call(globalThis, u), const f = globalThis.fetch; f(u), and new globalThis.WebSocket(u). The current src has no network path: grep finds no fetch, WebSocket, child_process or node:net/http use outside guard.ts. The runtime block in test/setup.ts would also catch such a call, but only on a path a test executes.

This is a gap in the static guarantee that M1 transports will rely on, not a live network path.

Fix: match the bare identifiers (/\bfetch\b/ and /\bWebSocket\b/) in src, since src has no legitimate use, and add these forms to the scan's own sample list.