blockyard 0.0.9 → 0.1.0

package/systemd/blockyard.service

@@ -68,11 +68,13 @@ Environment=BLOCKYARD_NODE_URL=http://127.0.0.1:8331
 Environment=BLOCKYARD_DATADIR=/home/bitcoin/.bitcoin
 Environment=BLOCKYARD_LOGFILE=/home/bitcoin/.bitcoin/debug.log
 Environment=BLOCKYARD_LOG_LEVEL=info
-# ACCESS: accounts are OFF by default, so anyone who can reach the bound addresses
-# reads this monitor (role "viewer": charts, feeds, read-only RPC console). User
-# administration, the audit trail and node writes stay closed to them. Uncomment to
-# require sign-in (accounts, roles, sessions, CSRF, per-user audit):
-#Environment=BLOCKYARD_AUTH=1
+# ACCESS: hardened out of the box (2026-09-15) -- bound to 127.0.0.1 and sign-in ON;
+# the first start prints the admin password once (or set BLOCKYARD_ADMIN_PASSWORD).
+# To serve a LAN address put it in config/local.json (`server.hosts`) or uncomment
+# the first line; to open the monitor to readers with no account, the second --
+# then anyone who can reach the bound addresses reads it as role "viewer".
+#Environment=BLOCKYARD_BIND=0.0.0.0
+#Environment=BLOCKYARD_AUTH=0
 #
 # Node writes stay off, and while accounts are off they stay off even if actions are
 # enabled -- a write with no identity behind it is not attributable. Enabling needs

package/docs/PRIVATE-LEADERBOARD.md

@@ -1,230 +0,0 @@
-# Blockchain leaderboards for the Diversions — scoping report
-
-**Private local document.** Gitignored via `docs/PRIVATE-*.md`. Not a decision, not a commitment —
-a scoping of what this would actually take, written 2026-09-13.
-
-> Note on the privacy guard: `test/privacy.test.js` scans `git ls-files`, so an ignored file is
-> outside it. That is how a real LAN address reached a commit earlier today. Nothing sensitive
-> should go in here on the assumption a test will catch it.
-
----
-
-## The short answers
-
-| question | answer |
-|---|---|
-| Do we need a Bitcoin address? | **Only if you want on-chain writes or signed identity.** A working leaderboard needs neither. |
-| How do people submit scores? | **A replay, not a score.** The server re-plays the game and computes the score itself. |
-| Can we do it for free? | **Yes, entirely** — if "use the blockchain" means *seed from a block hash and anchor by timestamp*. **No** if it means *one transaction per score*. |
-| What is the hard part? | **Not the blockchain.** It is proving a score was earned rather than typed into a POST body. |
-
----
-
-## 1. The insight this whole design rests on
-
-The three games were built with a pure-rules / screen split, and the rules are **deterministic by
-construction**. This was done for testability, but it is exactly what a trustworthy leaderboard
-needs.
-
-Verified headless under Node on 2026-09-13:
-
-```
-tetris.js   newGame(seed) with a seeded rng(seed); newGame(12345) twice → identical queue
-arkanoid.js hash01(key) everywhere, NO Math.random — capsules, minion lanes, drift phases
-breakout.js launch angle is an argument, not a roll
-all three   "no DOM, no canvas, no clock"; they import and run fine in plain Node
-```
-
-Entry points for a replay: `step(g, dtMs)` (breakout, arkanoid), `tick(g)` / `move` / `rotate` /
-`hardDrop` (tetris). `tetrust.js` already drives the rules from a **fixed-step accumulator**
-(`while (G.acc >= ms)`), so a game is already a discrete sequence of steps, not a wall-clock
-animation.
-
-**Therefore the server can replay a submitted game and recompute the score.** That is real
-anti-cheat, and it does not involve Bitcoin at all.
-
-## 2. What "use the blockchain" can usefully mean here
-
-Four options, ranked by what they actually buy:
-
-### (a) Block hash as the game seed — free, and the best fit
-
-The tip hash at game start becomes the seed. This gives three properties for nothing:
-
-- **Unpredictable** — nobody can pre-compute a favourable piece order, because nobody knows block
-  N+1's hash. (Miners have a marginal grinding advantage; irrelevant at this stake.)
-- **A lower time bound** — a game seeded from block N provably was not played before block N. That
-  is a real timestamp, from our own node, at zero cost.
-- **A fair shared round** — everyone playing "the block 966,781 round" gets the same piece order, so
-  scores are comparable in a way they never are with per-player seeds. This is the genuinely novel
-  bit: a *per-block tournament*.
-
-We already have the data: `/api/blocks` returns hashes, and the monitor is watching a node anyway.
-
-### (b) OpenTimestamps anchoring — free, proves *when*
-
-Hash the leaderboard state periodically and submit the digest to public OTS calendar servers, which
-aggregate thousands of digests into one transaction. Produces a Bitcoin-anchored proof that the
-leaderboard said X at time T, and costs nothing because the calendar operator pays the fee.
-
-Cost: one outbound HTTPS call to a third party, which conflicts with this project's "outbound
-connections are limited and on demand" stance — it would need to be opt-in and documented in
-`docs/SECURITY.md` alongside the exchange APIs.
-
-### (c) OP_RETURN per score — cheap, not free, and probably wrong
-
-Real numbers from the node right now: fee estimates ≈ **5.65e-06 BTC/kvB ≈ 0.57 sat/vB**, relay
-floor 1 sat/vB. A minimal OP_RETURN transaction is ~200 vB → **~200 sats ≈ 15¢** at $77k.
-
-But: needs a funded wallet, key custody, a UTXO set to manage, change handling, fee bumping when the
-mempool moves, and it puts arcade scores in every archival node on Earth, for ever. It also requires
-passing the node-writes gate, which currently needs four independent yeses and is off by default.
-
-**Recommendation: no.** Use (a) for fairness and (b) for timestamping.
-
-### (d) Signed scores for pseudonymous identity — free via RPC, but legacy addresses only
-
-A player signs their submission with a Bitcoin key; the address is their leaderboard identity. No
-funds, no on-chain footprint.
-
-**Partly wrong as first written, corrected 2026-09-13 after the operator asked "why do we need
-crypto primitives — can't we just use the bitcoind rpc?".** They were right.
-
-*Verifying* a user's signature needs no crypto code at all: **`verifymessage` is already permitted
-by our own allowlist** and the node does the pubkey recovery. Confirmed it genuinely evaluates
-rather than stubbing — a malformed signature errors `-3 Malformed base64 encoding`, and a bech32
-address errors `Address does not refer to key`.
-
-What survives is an **asymmetry**: the node can verify, but it cannot sign *for us*. The Umbrel has
-no wallet loaded (`listwallets` → `[]`), `signmessage` is in our own deny list as a wallet mutator,
-and asking a user's node to hold the monitor's identity is the wrong layer anyway. So:
-
-- **users proving they control an address** → pure RPC, no crypto, no dependency;
-- **the monitor holding its own identity and signing attestations** → local keys, which is a
-  custody decision rather than a coding one.
-
-Node 22 does have enough for the second if wanted: secp256k1 DER sign/verify, `ripemd160`, and
-therefore hash160 — a P2WPKH address derives zero-dependency (verified: produced a valid bech32
-address with a ~40-line encoder). It is *recovery* from a compact signature that Node lacks, and
-only the monitor-side signing path would need it.
-
-**THE REAL CONSTRAINT IS ADDRESS TYPE, NOT CRYPTO.** Measured against the node on 2026-09-13:
-
-| address | `verifymessage` |
-|---|---|
-| P2PKH `1...` | **works** — returned `false` for a wrong signature, i.e. it evaluated |
-| P2SH `3...` | error: `Address does not refer to key` |
-| P2WPKH `bc1q...` | error: `Address does not refer to key` |
-| P2TR `bc1p...` | error: `Address does not refer to key` |
-
-Core's `verifymessage` implements the old "Bitcoin Signed Message" scheme, which is defined only
-for P2PKH. **Most modern wallets — including the one on an Umbrel — hand out `bc1q` or `bc1p`
-addresses, and those users cannot sign this way at all.** That is the main obstacle to the
-user-identity design, and no amount of our own code fixes it, because the limitation is in the
-signing standard rather than in us.
-
-Options, in order of how much they cost:
-
-1. **Accept legacy-only**, and say so in the UI: "paste a `1...` address". Many wallets can still
-   produce one; Sparrow, Electrum and Core itself can sign with a legacy key. Free, honest, and
-   excludes some users.
-2. **BIP-322** — the modern generalised signing scheme covering segwit and taproot, and what `bc1`
-   wallets actually implement. **Checked, and the answer is no:** Core 31.1.0 (`/Satoshi:31.1.0/`)
-   exposes `verifymessage`, `signmessage`, `signmessagewithprivkey`, `signrawtransactionwithkey`,
-   `signrawtransactionwithwallet` and `enumeratesigners` — and **no BIP-322 method of any name**.
-   So the node cannot verify a segwit or taproot signature for us. Supporting `bc1` identities means
-   implementing BIP-322 verification ourselves, which needs precisely the secp256k1 primitives the
-   RPC route was chosen to avoid. That is a substantial piece of work and a dependency-rule
-   conversation, not an afternoon.
-3. **Do not use Bitcoin signing for identity at all** — a chosen display name plus the replay proof.
-   The replay is what makes a score trustworthy; the address only says *who*. If the leaderboard is
-   local or shared-by-export, a name is sufficient and costs nothing.
-
-## 3. Recommended design
-
-**Decision taken 2026-09-13: identity means _users prove who they are_** — the monitor holds no
-key, signs nothing, and custodies nothing. Everything below assumes that.
-
-**Per-block tournaments, verified by replay, identified by address, anchored by timestamp.**
-
-1. A round opens when a block lands. Its hash seeds every game in that round.
-2. The player plays locally, exactly as now.
-3. On game over, the client submits a **replay**: `{ game, seedBlock, seedHash, steps[], claimedScore }`
-   where `steps[]` is the discrete input sequence the fixed-step loop already produces.
-4. The server imports the same pure rules module, replays the steps, and computes the score itself.
-   The claimed score is ignored except as a cross-check — a mismatch is a rejected submission.
-5. Accepted entries join the round's board. When the round closes (next block), the board is hashed
-   and optionally OTS-anchored.
-
-**Identity, if a player wants one** (optional — an anonymous entry is still replay-verified):
-
-- The server issues a challenge string tied to the round (`blockyard:<round>:<nonce>`).
-- The player signs it in their own wallet and pastes address + signature.
-- We call `verifymessage` — already permitted by the allowlist, no crypto code, no key on our box.
-- `validateaddress` first, so a `bc1` address is refused with *"legacy `1...` addresses only, see
-  BIP-322 note"* rather than a confusing `Address does not refer to key`.
-
-Two allowlist additions are needed, one line each: `validateaddress` and `deriveaddresses`. Both
-are read-only and currently denied only because nothing had asked for them.
-
-**Testing this path needs no wallet.** `signmessagewithprivkey` takes a WIF and a message and
-returns a signature, so a test can generate a genuine legacy-address signature as a fixture and
-assert that our verification accepts it and rejects a tampered message — without depending on a
-wallet existing on whatever node the suite runs against. That matters: the Umbrel has none
-(`listwallets` → `[]`), and the fake node in `scripts/fake-node.js` would otherwise have to grow a
-signing implementation.
-
-Why this is worth doing: the leaderboard is **verifiable by anyone**. Given the replay, any third
-party can recompute the score using the same public rules file. That is a much stronger claim than
-most leaderboards can make, and it comes from the determinism that already exists.
-
-## 4. What it actually costs to build
-
-| piece | size | notes |
-|---|---|---|
-| Record inputs in the three screen modules | **M** | The fixed-step loop already exists; capture `(stepIndex, action)` pairs. Arkanoid is the fiddliest — mouse position per step needs quantising or it is unreplayable. |
-| Headless replay harness | **S** | The rules already import under Node. Mostly a loop and a score readout. |
-| Replay determinism tests | **M** | The real work: proving client and server agree on every float. **See §5.** |
-| Submission API + storage | **S** | One POST, one GET, a JSON file per round. |
-| Round lifecycle from block events | **S** | The monitor already emits new-tip events. |
-| Leaderboard UI | **M** | A page, a per-round board, a "verify this replay yourself" button. |
-| OTS anchoring | **S** | Optional, opt-in, one HTTPS call. |
-| **Total** | **~2-4 days** | Assuming local/self-hosted scope. |
-
-## 5. The risks, honestly
-
-- **Floating-point determinism is the sharp edge.** `breakout.js` and `arkanoid.js` advance ball
-  physics with floats. Same JS engine, same order of operations, same result — but client and server
-  are *different Node/browser builds*, and any divergence makes an honest player's replay fail
-  verification. **This must be proven before building anything else**: record N real games in a
-  browser, replay them server-side, and assert bit-identical scores. If it does not hold, the fix is
-  integer or fixed-point physics, which is a rules rewrite. Tetris is much safer here — it is
-  integer grid logic.
-- **Replay size.** A ten-minute Arkanoid game at 60 steps/second is ~36,000 steps. Compressible
-  (most steps are "no input"), but it is not a 20-byte score.
-- **A leaderboard is inherently shared, and this app is not.** Blockyard is a single-user LAN
-  monitor that ships open-access with a `viewer` ceiling. A *global* leaderboard means **you run a
-  hosted service** — with moderation, abuse handling, data retention, and an endpoint strangers
-  POST to. That is a different product with different obligations, not a feature of this one.
-  Three honest scopes:
-  - **Local only** — verified replays, your own high scores, no server. Nearly free to build.
-  - **Shared export** — a signed/anchored replay file you can hand to someone else to verify.
-  - **Hosted leaderboard** — the real product, and the one with ongoing cost and duty of care.
-- **Replay does not stop a bot.** It proves the score was *achievable under the rules*, not that a
-  human earned it. A perfect Tetris bot submits perfectly valid replays. Per-block rounds limit the
-  damage (everyone gets one shot at that seed) but do not eliminate it.
-- **Scope creep into custody.** The moment there is a funded address, this stops being a monitor and
-  becomes something holding other people's money-adjacent state. Option (c) is where that starts,
-  which is the strongest argument against it.
-
-## 6. Recommendation
-
-1. **Spike the determinism question first** (half a day). Everything else is wasted if browser and
-   server disagree on ball physics.
-2. Build **local-only** verified replays with block-hash seeds. Free, no address, no third party, no
-   hosted service, and it delivers the interesting half: provably fair rounds and self-verifying
-   scores.
-3. Add **OTS anchoring** only if "provably at this time" matters to you. Opt-in, documented as an
-   outbound connection.
-4. **Do not** put scores on-chain per-game, and **do not** introduce a funded wallet.
-5. Treat a hosted global leaderboard as a separate product decision, not a Diversions feature.

package/docs/STATE-2026-09-09.md

@@ -1,200 +0,0 @@
-# State of the project — 2026-09-09 (handoff for an agent with a real browser)
-
-> **Superseded 2026-09-14, names only.** This is a dated record and its measurements stand as
-> written. The names in it are the ones in use that day and are no longer current: the project
-> is **BlockYard** (`/storage/blockyard`, systemd `blockyard.service`, env vars `BLOCKYARD_*`,
-> default web port 21000), and the node it watches is Bitcoin Core. `bmc-port-guard.sh` and
-> `/etc/ssl/bmc-local/ca.crt` are real artefacts on the operator's machine and keep their names.
-
-Written by the session that built the mining/visualisation layer. Everything below was
-run on this box; the things I could **not** do are listed explicitly at the end. Read
-`AGENTS.md` first for the rules (zero dependencies, RPC-only sources, never fabricate a
-figure, a chart never erases itself).
-
-## What is running
-
-| Thing | Where | Note |
-|---|---|---|
-| bmcmonitor | `https://<LAN address>:8088` | systemd `bmcmonitor.service`, TLS via a **local CA** (`/etc/ssl/bmc-local/ca.crt`), binds the **LAN address only** — loopback, docker bridges and the tailnet address all refuse, by design |
-| Node watched | `bmc-main`, RPC `127.0.0.1:8331` | the node's own esplora REST is on `127.0.0.1:3005` |
-| Log tailing | **OFF** (default since today) | the UI reads RPC only. `BMC_MON_LOG_SOURCE=1` re-enables it for parser work; do not add panels that need it |
-| Block-chain node under dev | `/storage/bitcoinmachinecode` | a *different* session works there; do not restart or reindex it casually |
-
-Import the CA or the browser will refuse the certificate. After any deploy, hard-reload:
-asset URLs are stamped `?v=<build>` and the stamp changes when files change, so a tab
-holding an old tab keeps running old code — that has already produced one false report
-today ("still renders nothing" while the fix was on disk and undeployed).
-
-## Verify, don't trust this document
-
-```bash
-cd /storage/bmcmonitor
-npm test                      # unit + render + contract tests
-bash scripts/smoke.sh         # 109 checks against a real server
-npm run counts                # do the documented counts match the suite?
-LAN=$(python3 -c "import json;print(json.load(open('config/local.json'))['server']['hosts'][0])")
-BMC_MON_BASE=https://$LAN:8088 BMC_MON_CA=/etc/ssl/bmc-local/ca.crt npm run render:live
-sudo systemctl restart bmcmonitor          # deploy after editing public/** or server/**
-sudo journalctl -u bmcmonitor -f           # server-side view; the UI records to it
-```
-
-`render:live` renders **every page** under the DOM stub against the running monitor and
-fails if an asserted card is empty. Today it caught, in order: an uncaught `ReferenceError`
-that killed the entire Overview (two cards "rendered nothing" because one line above them
-threw), a `fmt is not defined` crash on the Node page, and a card that no test had ever
-reached.
-
-## What was built today (mining + visualisation)
-
-- **Mining page** (`#mining`): block flow (construction → tip → history, the tip explicitly
-  labelled `current tip`, colour = age verdict), ghost cards for the next blocks marked
-  `not yet assembled`/`estimate`, ancestor-package table (CPFP shape from
-  `getblocktemplate…depends`, with `depends` being **indices into the array**, not txids),
-  and two treemaps.
-- **Treemaps** (`public/js/goggles.js`): one rectangle per transaction, area = vbytes,
-  colour = the feerate it pays, richest-first. The canvas is **the block**: a 14%-full block
-  looks 14% full and the rest is drawn blank and labelled. Cells are bounded (400) and the
-  remainder collapses into ONE aggregate cell so the block is always whole.
-- **Tip freshness** is judged against the chain's own measured block interval, not a fixed
-  clock: amber past ~1× the average gap, red past ~1.5×, floors at 4/8 min. Arrival is only
-  counted when the page **witnessed** the height change — a first paint must not claim a
-  fresh tip (that bug coloured a 14-minute-old block green).
-- **Overview** gained a compact copy of the block map (`ovGnTreemap`, `w4`, `.treemap.sm`).
-
-## Bugs I fixed, so you don't re-diagnose them
-
-- `rows` TDZ in `renderOverview` — two `rows` in one function; killed the whole Overview
-  render (the Fees card and the "mempool vs blocks" card were collateral).
-- `fmt is not defined` in `panels.js:drawSelf` — the Node page crashed.
-- Treemap `drawFrame` referenced `label` without destructuring → **every partly-filled
-  block threw at paint time and the canvas stayed blank**.
-- The treemap tween re-requested animation frames whenever the clock failed to advance
-  (hidden/throttled tab) → unbounded loop. Now a frame budget + stalled-clock check, and
-  the settled layout always draws.
-- **CSP**: the policy is `style-src 'self'` with no `style-src-attr` allowance (correct,
-  tightened earlier today). My new markup emitted `style="..."` and the browser blocked
-  **several hundred** applications, so the train and maps lost every colour. All of it now
-  travels as `data-pool` / `data-rate` / `data-w` / `data-delay` / `data-rail` and lands on
-  `el.style` through the CSSOM (`applyMiningStyles` in `mining.js`, `applyDataSizes` in
-  `app.js`). The palette index comes from our own array — a pool name from the node cannot
-  become CSS. `test/csp.test.js` now fails if any JS-built markup carries a style attribute.
-- **The Fees card** was found with `getElementById('ovFees').closest('.card')`, and the DOM
-  stub answers `closest()` with `null` — so **no test ever exercised that card**. It is now
-  `#ovFeesCard`, addressed by id, and asserted in `test/web-contract.test.js`.
-
-## Known, open, or unverified — this is what a browser is for
-
-1. **Nothing has been seen rendered.** No real-browser harness exists. Layout, colour
-   legibility, overlap, and "does the treemap read as a block" are unverified by me.
-2. **Treemaps at `w4`** (33%) on Mining, `w4` on Overview: is 168px/240px high enough for
-   the labels, and is the "block unfilled" band legible at that width?
-3. **Legend/label collisions** inside rectangles (rate + `k` vbytes text) at small cell
-   sizes, and the `selection ends` / `everything fits in one block` label near the right
-   edge.
-4. **Hover tooltips** (`.goggles-tip`) are positioned `left/bottom` — check they don't
-   cover the cursor's cell or overflow the card.
-5. **Motion**: the map tweens only when the Mining page is open and the template refetches
-   (on load + every 20 s). Confirm the tween is visible, and that `prefers-reduced-motion`
-   snaps without losing information.
-6. **`app.js` boot throws under the DOM stub** (`TypeError` at `boot()`, harness-only). Real
-   browsers don't hit it; it means a stub element is missing, and it will keep biting anyone
-   extending the harness.
-7. Ghost-card forward capacity numbers are **queue-depth estimates**, not node data.
-8. No TLS certificate automation (self-signed local CA), and `:8999` (mempool-backend API)
-   is loopback-only by a netfilter rule — separate from this app.
-
-## Guardrails that will bite if you ignore them
-
-- **Zero dependencies.** No `npm install`. Node builtins and hand-written canvas only.
-- **No host identity in committed files.** `test/privacy.test.js` derives the username,
-  hostname forms and interface addresses at run time and fails on them — it caught a
-  hardcoded LAN address in one of my scripts today. Use RFC 5737 documentation ranges in
-  docs and tests, and read addresses from config/env at run time.
-- **Test counts are generated** (`npm run counts:fix`). Never type them.
-- **Every claim in a comment must be a measurement** with a number and a date. "Seems" is
-  not a justification, and this project has twice been burned by a check that passed for
-  the wrong reason (a vacuous assertion, a stub that answered `null`).
-- A chart **never erases itself** to show a status; absence renders as `–` with a reason,
-  and stale data renders visibly stale.
-- Absent data is **never** filled with a guess: no per-tx `depends` in
-  `getrawmempool` on this node, so cluster analysis is only drawn from
-  `getblocktemplate`, and the panel says which of the two it is.
-
----
-
-## Measured in a real browser (2026-09-10, headless Chromium over CDP)
-
-`scripts/browser-check.mjs` drives Chromium over CDP with Node's built-in WebSocket: it
-loads the page, samples **canvas pixels with getImageData**, reads inline vs computed CSSOM
-values, measures element rects, collects console/exceptions, and can pass the screenshot to
-the local vision model. This is the first time any of this has been looked at rather than
-inferred. It found five defects that 349 passing tests did not.
-
-### Found and fixed
-1. **Shared animation handle.** `goggles.js` kept one module-level `raf` for both maps, so
-   each canvas's render cancelled the *other* one's pending frame — and the first frame was
-   drawn only inside that callback. The loser painted **nothing**: `__hasData: true`, 401
-   rects laid out, 68% of the canvas covered on paper, **zero painted pixels**. Now the
-   handle is per-canvas (`c.__raf`) and the settled layout is painted before any animation.
-2. **Tween grew cells from zero size.** With a snapshot arriving every second, the chart
-   spent most of its life mostly-cleared with 1px rectangles. Now position interpolates and
-   **size never does**; new cells fade in with alpha. A tween must be the difference between
-   two visible states, not the thing that makes pixels exist.
-3. **`style-src` was silently vetoing my own markup** (several hundred blocked
-   applications): all `style="..."` removed in favour of `data-pool` / `data-rate` /
-   `data-w` / `data-h` / `data-delay` / `data-rail` + CSSOM. Guarded by a test that fails if
-   any JS-built markup carries a style attribute.
-4. **`.closest('.card')`** made the Fees card invisible to every test (the DOM stub answers
-   `null`), so it could render nothing forever. Now addressed by `#ovFeesCard`.
-5. **`rows` TDZ** in `renderOverview` killed the whole Overview. Also: the earlier "fixed"
-   report was false because the fix was never **deployed** — deploy is part of a fix.
-
-### Still broken, with the measurements
-- **The Mining page block map still paints nothing** (`gnTreemap`: `rects: 401`,
-  `distinctColours: 0`, `paintedPixelsPct: 0`) while the mempool map on the same page paints
-  100% with the identical code path and the same rect count. I did not find the cause. Start
-  by comparing what differs at `drawFrame` time between the two — `geom.unused` is set for
-  the block map and absent for the mempool map, which changes `region`; instrument
-  `drawFrame` with a counter and a sample of the first rect's `fillStyle`.
-- **The style pass is only half applying.** In the browser: `.bdot` inline style is
-  `background: rgb(95, 176, 201)` with **no `--pool`**, and `.bfill span` has `background`
-  but **no width**, while `document.querySelectorAll('[data-w]')` counts 27 of which **2**
-  have an inline width (the sync hero's, applied by app.js). So `applyMiningStyles` is
-  running an older code path than the one on disk and served (`setProperty` and
-  `applySizes` are both present in the served bytes, and `Cache-Control: no-cache`). That
-  contradiction is unresolved — check whether the module the browser evaluates is the
-  module the server sent (compare `import.meta` resolution / a marker constant), before
-  touching the style code again.
-- **The flow row overflows its card** and is cut off: `.flow` scrollWidth 2236 inside
-  clientWidth 1369. I added `.flow { width: max-content }` + `.flowwrap { overflow-x: auto }`;
-  the browser still measured clipping after the change, so either the CSS did not apply as
-  written or the grid parent constrains it. Re-measure `.flowwrap` rather than `.flow`.
-
-> **Superseded 2026-09-14:** the first two readings above were the harness measuring the
-> previous build, not the page — `Page.navigate` to a URL differing only in its fragment does not
-> reload the document (`docs/RULES.md` rule 25). Re-run against the current build on 2026-09-10,
-> `gnTreemap` and `gnMempoolTreemap` both painted 100% of their pixels.
-
-### Notes on the harness itself
-- Chromium only survives inside one shell invocation, so launch + check must run together:
-  `rm -rf /tmp/cp; (setsid /usr/bin/chromium-browser --headless=new --no-sandbox
-  --user-data-dir=/tmp/cp --remote-debugging-port=9333 --ignore-certificate-errors
-  about:blank &) ; until curl -s 127.0.0.1:9333/json/version >/dev/null; do sleep 2; done;
-  BMC_MON_BASE=https://<lan>:8088 node scripts/browser-check.mjs mining`
-- Quote `--remote-allow-origins=*` or the shell globs it into filenames.
-- **`Page.navigate` to a URL differing only in `#fragment` does not reload the document.**
-  Reusing a warm browser therefore re-measures whatever was loaded before the last deploy:
-  `public/**` changes, the page does not, and every reading is of the previous build. The
-  harness now appends `?t=<ms>` for this reason. Rule 25: prove the browser is running the
-  bytes you served before believing anything it says about them.
-- Do not assert `document.body.firstChild` is an element. Leading whitespace before
-  `<header>` is a `#text` node in every ordinary document; a probe that checked this
-  "proved" the Overview rendered nothing when it had rendered fine throughout.
-- `Page.loadEventFired` is not reliably seen by the current waiter; the probe's
-  **load guard** (abort unless `#nav` and body children exist) is what stops a broken
-  invocation being reported as "the page is blank" — that happened once and the vision
-  model confidently confirmed a blank white page that was only my own bad URL.
-- Vision: this deployment answers with `content: null` and the text in `reasoning`; reading
-  only `content` silently yields an empty review.
-- `mempool-backend.service` has been `failed` since 2026-09-09 16:58 (start-limit hit after
-  12 restarts; its own stdout is not in the journal). Unrelated to the above, untouched.