[Flotapponnier]

Four defects on bench 308, each one measured against the live feeds.

A coin whose makers left kept its row

A Prometheus gauge that is never Set keeps its last value for as long as the process lives. probeBasicSwap published only the coins it found on the book, so a coin that disappears from the feed never gets a new value and keeps republishing the market it used to have.

Measured 2026-10-27: privacy_book_maker_count{coin="FIRO"} has been flat at 1 for 24 h (changes(...[24h]) = 0) while the BasicSwap feed carries zero Firo offers, expired or otherwise. The abstract already promised the opposite:

Expired offers are excluded. The feeds keep them in the list, and counting them would let a coin whose last maker left months ago keep a row that looks like a market.

The expiry filter does its job on offers; nothing did it on the gauge. Every coin in the cohort is now published every tick, zero included. zero_is_a_value: true ships with it, otherwise the honest 0 deletes the row instead of showing it, and a coin whose market left is the most informative row this board has.

One guard kept: an empty offer list is a feed failure, not an empty market, and still publishes nothing.

The Pairs column over-counted

The feed carries an offer as an ordered (coin_from, coin_to) pair, and the key was from + "/" + to, so a market listed in both directions counted twice. Measured on the live book:

coin	published	real markets
XMR	8	5
DASH	3	2
WOW	5	4

The key is now undirected and the column is named Markets, which is what it counts.

Both companion panels rendered empty

load.ts builds a panel query as `${panel.label_key}="${p.slug}"` with no normalisation. The gauges were labelled XMR, PART_BLIND; the rows are xmr, part-blind. Nothing matched, values came back {} for both panels, and no error was raised anywhere, while the subtitle promised "the offers and pairs behind the count". The harness now labels by row slug and the provider queries move with it.

sample_size was not a sample count

It was sum(privacy_book_live_offers{...}), so PIVX showed "3 samples" because PIVX has three offers. It is now max(count_over_time(privacy_book_maker_count{...}[24h])), the number of scrapes behind the row.

Two additions that follow

• Coins on offer column, from the privacy_book_size_offered gauge the harness already collected and the board never showed. The second finding claims one maker can offer thousands of coins; now there is a column where a reader can check it.
• Dedupe by peerId on the Monero maker directory. 9 entries, 9 distinct peers today, so this changes no number; the headline column must not be able to count one participant twice.

Tests

basicswap_test.go covers the undirected key, reciprocal offers, an expired offer, the zero-fold for every cohort coin, and which side the size comes from. Each gate was proved to pull: with the old behaviour reinstated, the direction and reciprocal tests fail and the expired-offer test dies on the nil entry that is the frozen-gauge path.

Gates: go build ./... && go vet ./... && go test ./... ok, pnpm validate 257 specs valid, tsc --noEmit clean, bun test src/ 731 pass 0 fail.

Deploy order

The harness must ship before the worker rebuild: the spec now selects coin="xmr" and that series does not exist until the new binary runs. In between, the bench fails quorum and keeps its previous render, which is the intended behaviour of that guard.