Pre-release: the human test pass

[A13xB0]

A human pass over everything, before the first release. Each scenario has steps and an expected result; tick what holds, and leave a comment on this issue for anything that does not, with the scenario number.

Docs for reference while testing: https://meshbench.github.io/docs/

---

1. Install and first launch

1. Download the latest release artefact for Linux, chmod +x, run it.
2. Expect: the workbench opens with no other installation, warms the default fixture, and the status bar carries the best-case honesty line.
3. With MESHBENCH_CARTO_KEY set in the environment (yours is set in fish): expect the CARTO dark basemap by default, no "API KEY REQUIRED" watermark anywhere while panning and zooming.
4. Unset the key and relaunch: expect OpenStreetMap tiles by default and nothing broken.

• passes as described

2. Your first simulation (the docs path)

Follow https://meshbench.github.io/docs/first-simulation.html literally, as if new.

1. File, Open a saved network, fixture-fife-strict.
2. Simulation, Start firmware on every node; watch the count reach 58.
3. Press play; double-click a repeater, and on its Console tab type advert.
4. Expect: the flood spreads on the map, the Events panel fills with causes, nothing in the doc's wording disagrees with what the screen shows.

• passes as described

3. Debugging a missed packet

1. In the run from scenario 2, open the Debug view.
2. Pick a failed reception in the Inspector; read its cause.
3. Use the map's link tool on that pair; expect the terrain cut-through with both directions' margins, and the cause to be consistent with what the cut-through shows.

• passes as described

4. Waveform mode

1. Configuration, RF Simulation: switch to waveform. Expect the status bar to name the mode and the run to continue without cutting a frame.
2. Let two nearby repeaters relay the same flood; in Debug, expect collision or capture verdicts that calculated mode would not produce.
3. Switch back to calculated; expect the mode stamped correctly again.

• passes as described

5. SDR observer

1. Open the Glasgow SDR Observer node window, SDR pane, serve rtl_tcp.
2. Connect SDR++ with the documented settings (https://meshbench.github.io/docs/sdr-observer.html).
3. Expect chirp bursts at channel width while playing, the bare noise floor while paused, and the stream surviving a drag of the observer across the map.

• passes as described

6. Importing a real network

Follow https://meshbench.github.io/docs/importing.html with the ScotMesh CoreScope URL, GUI tab only.

1. Add areas, fetch, commit, read traffic, apply regions - the numbered buttons in order.
2. Expect the counts reported at each step, regions applied to a sensible number of nodes, and a flood that actually relays afterwards.
3. Deliberately skip "apply regions" on a fresh import and confirm the mesh transmits but does not relay - then check the page's "If nothing relays" checklist catches it.

• passes as described

7. Firmware development loop

1. meshbench dev -from <your MeshCore checkout>; expect the build to land in the firmware library named after the branch and assigned to repeaters.
2. Bench view: define a two-arm sweep, your build against the release, three seeds, a control arm.
3. Expect: per-arm results with delivered, redundant, rx_spread, at_risk_2db; the control arms identical; the run log readable while it goes.

• passes as described

8. A companion app against the mesh

1. App view, Companion bench: give me a mesh and an endpoint (TCP).
2. Connect meshcore-cli or your own client; expect real protocol bytes, infos answered.
3. Press "drop every client connection"; expect the client to see a dead socket, and reconnecting to work after serving again.

• passes as described

9. One emulated board

1. Assign the Generic_E22_sx1262 published image to a single node (one board at a time; they are heavy).
2. Expect it to boot, advert on the air unprompted, and appear in the events as a transmitter; console reachable and answering get name.

• passes as described

10. Scripting and the clients

1. Run cookbook example 3 (small mesh with traffic) in Python: expect it to build the mesh, run, and print event counts.
2. On the docs site, flip a ways block to Python; expect every page to remember the choice.
3. meshbench test -fixture fixtures/fixture-fife-strict.json -junit out.xml: expect assertions checked, JUnit written, exit code 0.

• passes as described

11. Determinism spot-check

1. Run the same fixture and seed twice (native firmware), same duration.
2. Expect identical event totals both times.

• passes as described

12. Docs site and READMEs, as a reader

1. Read the Learn path start to finish (Overview through Reading a result); note anything unclear or wrong as a comment here.
2. Try search ("/"), the on-page rail, a phone-width window, and both light and dark themes; expect the white logo on its dark rail everywhere.
3. Look at both repository READMEs on GitHub in dark and light themes; expect the card on the main repo, the theme-aware white logo on the docs repo, badges alive, no broken links.

• passes as described

---

---

Part two: every window, one picture each

The twelve scenarios above are the journeys. This part is the inventory: every panel, window, tab, section and menu the application has, so the pass can say it covered all of them rather than the ones somebody thought of.

Run the sweep, which drives the binary once per step and writes one picture per step:

go build -o meshbench ./cmd/meshbench
tools/shots/shots.py            # every step, into ./shots
tools/shots/shots.py panels     # or one bucket at a time
tools/shots/shots.py --list     # what it would run

internal/ui/workbench/shotsteps_test.go checks the manifest against the application's own panel table, so a panel added without a step is a red build rather than a picture nobody took. Tick a bucket when every picture in it holds; comment with the step name for any that does not.

Views (6)

Each view is its own arrangement. The switcher should mark the current one.

picture	what it is	expected
view-plan.png	The Plan view	the view's own panels are docked and drawn, and the view switcher marks Plan as current
view-run.png	The Run view	the view's own panels are docked and drawn, and the view switcher marks Run as current
view-debug.png	The Debug view	the view's own panels are docked and drawn, and the view switcher marks Debug as current
view-validate.png	The Validate view	the view's own panels are docked and drawn, and the view switcher marks Validate as current
view-bench.png	The Bench view	the view's own panels are docked and drawn, and the view switcher marks Bench as current
view-app.png	The App view	the view's own panels are docked and drawn, and the view switcher marks App as current

• every picture in this bucket holds

Panels (72)

Each panel twice: filling the window, and popped out into a window of its own. A panel that draws docked and not in its own window is a fault this window set has had.

picture	what it is	expected
panel-boards.png	The Boards panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-boundary.png	The Boundary panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-budget.png	The Budget panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-companion-bench.png	The Companion bench panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-compare.png	The Compare panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-configuration.png	The Configuration panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-console.png	The Console panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-energy.png	The Energy panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-events.png	The Events panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-experiment-log.png	The Experiment log panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-firmware.png	The Firmware panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-fleet.png	The Fleet panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-import.png	The Import panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-inspector.png	The Inspector panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-licences.png	The Licences panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-link.png	The Link panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-live-feed.png	The Live feed panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-logs.png	The Logs panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-map.png	The Map panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-matrix.png	The Matrix panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-nodes.png	The Nodes panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-nodes-running.png	The Nodes running panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-packet.png	The Packet panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-packet-timeline.png	The Packet timeline panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-planning.png	The Planning panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-provisioning.png	The Provisioning panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-resources.png	The Resources panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-results.png	The Results panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-runs.png	The Runs panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-schedule.png	The Schedule panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-scoreboard.png	The Scoreboard panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-setup.png	The Setup panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-sweep.png	The Sweep panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-timelines.png	The Timelines panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-validate.png	The Validate panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
panel-waterfall.png	The Waterfall panel, filling the window	the panel draws its own content, with no empty region and no placeholder text
popout-boards.png	The Boards panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-boundary.png	The Boundary panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-budget.png	The Budget panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-companion-bench.png	The Companion bench panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-compare.png	The Compare panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-configuration.png	The Configuration panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-console.png	The Console panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-energy.png	The Energy panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-events.png	The Events panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-experiment-log.png	The Experiment log panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-firmware.png	The Firmware panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-fleet.png	The Fleet panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-import.png	The Import panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-inspector.png	The Inspector panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-licences.png	The Licences panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-link.png	The Link panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-live-feed.png	The Live feed panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-logs.png	The Logs panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-map.png	The Map panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-matrix.png	The Matrix panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-nodes.png	The Nodes panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-nodes-running.png	The Nodes running panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-packet.png	The Packet panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-packet-timeline.png	The Packet timeline panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-planning.png	The Planning panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-provisioning.png	The Provisioning panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-resources.png	The Resources panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-results.png	The Results panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-runs.png	The Runs panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-schedule.png	The Schedule panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-scoreboard.png	The Scoreboard panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-setup.png	The Setup panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-sweep.png	The Sweep panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-timelines.png	The Timelines panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-validate.png	The Validate panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel
popout-waterfall.png	The Waterfall panel popped out	a window of its own with a title bar, draggable, and the same content as the docked panel

• every picture in this bucket holds

The node window (10)

One capture per tab.

picture	what it is	expected
node-console.png	A node's own window on its Console tab	the window opens on Console with that tab's content drawn
node-companion.png	A node's own window on its Companion tab	the window opens on Companion with that tab's content drawn
node-sdr.png	A node's own window on its SDR tab	the window opens on SDR with that tab's content drawn
node-settings.png	A node's own window on its Settings tab	the window opens on Settings with that tab's content drawn
node-radio.png	A node's own window on its Radio tab	the window opens on Radio with that tab's content drawn
node-stats.png	A node's own window on its Stats tab	the window opens on Stats with that tab's content drawn
node-activity.png	A node's own window on its Activity tab	the window opens on Activity with that tab's content drawn
node-connect.png	A node's own window on its Connect tab	the window opens on Connect with that tab's content drawn
node-hardware.png	A node's own window on its Hardware tab	the window opens on Hardware with that tab's content drawn
node-output.png	A node's own window on its Output tab	the window opens on Output with that tab's content drawn

• every picture in this bucket holds

The board view (3)

Both tables, and the console with its frames decoded.

picture	what it is	expected
board-radio.png	The board view's Radio table	the board's panel on the left, the Radio table with a verdict on every row, and the console along the bottom
board-wiring.png	The board view's Wiring table	the board's panel on the left, the Wiring table with a verdict on every row, and the console along the bottom
board-decoded.png	The console with its frames decoded — then tick decode in the console strip	the decode tick is on and framed traffic reads as prose, with the plain boot log still beside it

• every picture in this bucket holds

Configuration (6)

One capture per section.

picture	what it is	expected
config-general.png	Configuration: the general section	the section opens with its own settings and each carries the caption that says why it matters
config-rf.png	Configuration: the rf section	the section opens with its own settings and each carries the caption that says why it matters
config-terrain.png	Configuration: the terrain section	the section opens with its own settings and each carries the caption that says why it matters
config-traffic.png	Configuration: the traffic section	the section opens with its own settings and each carries the caption that says why it matters
config-provisioning.png	Configuration: the provisioning section	the section opens with its own settings and each carries the caption that says why it matters
config-resources.png	Configuration: the resources section	the section opens with its own settings and each carries the caption that says why it matters

• every picture in this bucket holds

Licences (5)

One capture per section.

picture	what it is	expected
licences-forks.png	Licences: forks	every row names a component, its licence and its origin
licences-bundled.png	Licences: bundled	every row names a component, its licence and its origin
licences-golibs.png	Licences: golibs	every row names a component, its licence and its origin
licences-runtime.png	Licences: runtime	every row names a component, its licence and its origin
licences-data.png	Licences: data	every row names a component, its licence and its origin

• every picture in this bucket holds

Menus (7)

Every dropdown. One entry lives in one menu.

picture	what it is	expected
menu-file.png	The File menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-view.png	The View menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-simulation.png	The Simulation menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-mesh.png	The Mesh menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-analysis.png	The Analysis menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-window.png	The Window menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only
menu-help.png	The Help menu, open	the menu drops with its sections, icons and shortcuts, and one entry appears in one menu only

• every picture in this bucket holds

---

Part three: the documentation, as a reader

The manual is part of the change, so a release is not tested until the pages have been walked against the build. A page describing a view the application no longer has is worse than no page, because somebody will follow it.

Published at https://meshbench.github.io/docs/. Walk them with:

tools/shots/shots.py docs

It opens each page in turn and prints what the page is held to. Capture anything that disagrees with the application and comment with the step name. shotsteps_test.go reads the site's own navigation table, so a page published without a step here is a red build.

Follow the guides literally, in order, as if new. That is the only way a missing step shows up: somebody who knows the application fills the gap without noticing it is there.

page	what it is	held to
index	Learn - Overview	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
concepts	Learn - What is real	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
getting-started	Learn - Getting started	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
first-simulation	Learn - Your first simulation	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
results	Learn - Reading a result	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
fixtures	Use - Shipped networks	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
importing	Use - Importing a network	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
debugging	Use - Debugging packet delivery	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
firmware-library	Use - Firmware library	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
firmware-development	Use - Firmware development	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
board-view	Use - The board view	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
testing-repeaters	Use - Testing a repeater	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
app-development	Use - App development	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
testing	Use - Testing your own code	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
experiments	Use - Running an experiment	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
studies	Use - Studies	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
sdr-observer	Use - Listening with SDR++	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
architecture	Understand - Architecture	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
native-vs-emulated	Understand - Native and emulated	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
rf-simulation	Understand - RF simulation	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
rf-chain	Understand - The RF chain	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
waveform	Understand - Waveform mode	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
timing	Understand - Time and determinism	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
golden-vectors	Understand - Golden vectors	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
emulation	Understand - Emulation	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
firmware-integration	Understand - Running real firmware	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
what-it-does-not-do	Understand - Accuracy and limits	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
scripting	Automate - Scripting a session	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
cookbook	Automate - Scripting cookbook	every step can be followed literally, in order, and the application does what the page says at each one - no step names a control that is not there, and no screenshot shows a view that has changed
agent-skills	Automate - Agent skills	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
reference-cli	Automate - CLI	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
reference-control	Automate - Control socket	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
reference-python	Automate - Python client	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
reference-go	Automate - Go client	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
reference-js	Automate - Node client	every entry matches the build: it is generated, so the check is that nothing here is missing or stale, not that the prose reads well
settings	Reference - Settings	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
resources	Reference - What gets downloaded	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
tools	Reference - External tools	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
quality-gates	Reference - What the build enforces	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application
repositories	Reference - Repositories and licences	what it claims is true of the build in front of you, and every screenshot on it is recognisable in the application

• every page holds

---

Anything that fails: comment with the scenario number, what you did, what you expected, and what happened. Screenshots welcome.

[A13xB0]

Claude's pass, part 1 (scenarios 1-4), with notes

Driven through the control socket against a windowed build, screenshotting each step. Scenarios 1-4 done here; 5-12 need things this machine or this pass cannot supply (noted at the end). Notes only - not opening issues yet, per the plan to file them after both our passes.

1. Install and first launch - PASSES

Default fixture warms (378 nodes, seed 9001), and the status bar carries the honesty line verbatim: results are a best case: no multipath, bare earth, ideal demodulator. CARTO dark basemap is default with (c) OpenStreetMap contributors, (c) CARTO attribution and no API-key watermark while panning. I did not test the key-unset relaunch (step 4).

2. First simulation - PASSES, two notes

Opened fixture-fife-strict, firmware started, played, advert at Abernethy Repeater answered -> OK - Advert sent, flood spread, Events filled (17.9k events, Sent 1834 / Received 477).

• N1 (docs, not code): the count reaches 56, not 58. The scenario says "watch the count reach 58". firmware.state returns {nodes: 56, running: 56, total: 58} - the SDR observer and the emitter never boot firmware. The app is honest about this ("56 on MeshCore", "56 nodes running firmware"); it is this checklist and the docs page that say 58. Anyone following it literally waits for a number that never arrives.
• N2 (UX): opening a network does not fit the map to it. After File > Open, the viewport stays where it was, so fife-strict appears as a tiny cluster in the corner of a mostly-empty map and the flood is invisible. You have to know to press fit. This is the exact moment a newcomer decides nothing happened. Worth fitting on open, or at least on first play.

3. Debugging a missed packet - PASSES on substance, two UI faults

The causes are genuinely good. Misses carry real physics:

• its own transmitter was keyed; LoRa is half duplex
• its demodulator was already locked to <node>; a LoRa receiver decodes one packet at a time
• decoded its header, then 133 symbol(s) were destroyed by a collision
• would have decoded at 15.0 dB, lost to a stronger interferer

The cut-through is excellent: terrain in green, first Fresnel zone as the band, both directions' margins side by side, plus CLEAR. The tightest point is 3.5 km along, with 11 m of clearance - 95% of the first Fresnel radius. Terrain is not what limits this path; if it does not work, the answer is in the link budget rather than the profile. That verdict is consistent with the miss causes above (congestion, not terrain), which is what the scenario asks for.

• N3 (bug, code): floor is a catch-all and mislabels congestion as weak signal. EventClass (internal/sim/engine/events.go:137) prefix-matches the detail string and returns ClassFloor as its default. So receiver-lock misses and collision misses are both counted as floor - "simply too quiet". The comment directly above the constants states the intent it breaks: "a miss that was simply too quiet ... three different problems with three different fixes". Measured on one fife run: of 357 misses, 37 were classed floor and not one of them was a floor miss - they were receiver lock and collisions. This matters because the cards and filter chips count by class: a user reads "floor" and buys antennas when the actual fix is fewer or rescheduled transmissions. Wrong conclusion, in the direction the project cares most about.
• N4 (bug, UI): the Link panel is unusable docked. Docked in the right sidebar it renders no cut-through at all, and the pair label overflows into a one-character-wide column down the right edge, wrapping per character ("s / c / o / - / A / v / o / n ..."). Pop it out to its own window and it renders perfectly. So the panel has no minimum width and no horizontal handling.

4. Waveform mode - PASSES, and better than asked

Switching to waveform stamps waveform RF in the status bar and the run continues uninterrupted. The nice detail: the honesty line itself changes, from ... bare earth, ideal demodulator to ... bare earth, real coding chain - it drops the caveat that no longer applies. Switching back restores calculated RF and the original wording. I did not get two repeaters to relay the same flood to compare collision/capture verdicts against calculated mode (step 2).

Smaller notes

• N5: the packet timeline has no legend - red / orange / green marks encode something a newcomer cannot read.
• N6: node names truncate with no tooltip in both the Nodes table and the Inspector's From/To (Abernethy Rep..., sco-tay-moncr...), and several similar names collide once cut.
• N7 (scripting): nodes.select_many takes a bare list. Handed {"names": [...]} it matches neither case in its type switch, silently deselects everything, and returns {"selected": null} as success. A silent no-op that looks like it worked.
• N8 (scripting): rf.mode is setter-only - calling it with no argument errors instead of returning the current mode, so a script cannot ask what mode it is in.
• Positive: refusals are unusually good. workspace.set with a bad view answers no view ""; there is: Plan, Run, Debug, Validate, Bench, App.

Not covered

5 (SDR++), 8 (meshcore-cli), 12 (docs site as a reader) need external apps. 9 (emulated board) is blocked here: radioserver not found - it ships from our QEMU fork and is not installed on this machine. 7, 10, 11 not reached yet; 11 is at least partly covered by TestRadioStackIsDeterministic, which passes.

[A13xB0]

Claude's pass, part 2 (scenarios 10 and 11)

11. Determinism spot-check - PASSES

Two runs of fixture-fife-permissive at the shipped seed produced 162 unique deliveries both times, and the two logs are byte-identical once the wall-clock timing line is removed. TestRadioStackIsDeterministic agrees at the frame level.

10. Scripting and the clients - step 3 FAILS

meshbench test -fixture fixtures/fixture-fife-strict.json -junit out.xml does check assertions and does write valid JUnit, but it exits 1, not 0, because the shipped fixture fails its own assertion:

fixture-fife-strict: 58 nodes, 56 running firmware, SF8 at 62 kHz, seed 9001
provisioned 56 nodes with 594 lines
    20.0 s  AngusOutlaw1: public hello from Angus
    ... six public messages from three companions ...
FAIL  at least 10 unique deliveries
        0 unique deliveries, wanted at least 10
meshbench: 1 of 1 assertions failed

Not a flake, and not the harness: the same command on fixture-fife-permissive passes with 162 unique deliveries and exits 0. So the machinery works and it is fife-strict specifically that delivers nothing.

• N9 (bug): fixture-fife-strict fails its own assertion. Zero of six public messages are delivered where the fixture asks for ten. The two fixtures differ in what they schedule as well as how strict they are: permissive floods adverts from many repeaters first, strict sends only three companions' public hello with no advert beforehand, so there may be no learned route for anything to travel. Whether the right fix is the assertion, the schedule, or the region rules needs someone who knows what the fixture was written to demonstrate. Either way a fixture that ships in the repository and fails its own check is not something to release.
• N10 (process, and the reason N9 survived): nothing in CI runs meshbench test. grep over .github/workflows finds no invocation. The assertions in the shipped fixtures are therefore never enforced, which is exactly how one drifts to zero deliveries unnoticed. This is the same shape as the always-red scheduled job in [Pre-release] Three live-firmware tests fail against real nodes, one possibly behavioural #373: an assertion nobody runs and an assertion that always fails are worth the same.

I did not do step 1 (Python cookbook example 3) or step 2 (docs-site language toggle).

Running total

scenario	verdict
1 install and first launch	passes (step 4, key-unset relaunch, not done)
2 first simulation	passes, notes N1 N2
3 debugging a missed packet	passes on substance, faults N3 N4
4 waveform mode	passes (step 2, collision verdicts, not done)
10 scripting and clients	step 3 fails, N9 N10
11 determinism	passes

5, 8, 12 need external applications. 9 is blocked here (radioserver not found, it ships from our QEMU fork). 6 and 7 not reached.

Ten notes so far, N1 to N10. Two are code bugs I would want fixed before release (N3 floor misclassification, N9 the failing shipped fixture), one is a visible UI fault (N4 the Link panel docked), and N10 is the process gap that lets N9 hide.

[A13xB0]

Claude's pass, part 3: a genuinely fresh install

Re-ran scenario 1 properly, from an empty cache. XDG_CACHE_HOME and XDG_CONFIG_HOME pointed at an empty directory, so this is what a first-time user gets, not what my warmed machine gets. Screenshots are of the workbench window alone rather than the desktop.

N11 (the big one): first launch downloads 513 MB of terrain, unprompted

Opening the application and touching nothing pulls 513 MB across 6,233 terrain files. Measured twice from two independent empty caches, and it came to 513 MB on the nose both times, so it is the default network's fixed cost rather than a coincidence.

after a first launch, nothing clicked	size
terrain/	513 MB, 6,233 files
tiles/	296 KB
matrix/	824 KB
firmware/	nothing

There is no consent step, no size shown beforehand, and no way to decline. It happens because a plain launch warms scotland-ireland-strict, a 378-node national network with 71,253 links, and every link wants ground under it. On a metered connection, a phone hotspot, or a slow line, half a gigabyte arrives before the user has decided they want the application.

The docs understate this. getting-started.html says the cache "grows with the firmware builds and map tiles you use" and budgets "200 MB for the bundle" - terrain is not mentioned, and it is by far the largest thing. A docs fix is warranted whatever is decided about the behaviour.

N12: the progress line names the wrong activity, which is why it reads as stuck

The first thing on screen is:

measuring every link - 0% (0 of 71253)

It is not lying and it does finish, in a couple of minutes on a fast line. But the time is not going into measuring: it is going into a 513 MB download that the line never mentions. So the percentage sits at or near zero while the actual work is invisible and unnamed, which is exactly the shape of a stall. On a slow link this would sit at "0% (0 of 71253)" for a very long time with nothing saying that anything is being fetched.

This exact lesson has already been learned once in the tree, which is what makes it worth fixing rather than arguing about. From firmwarelib.go:

Bytes rather than one step: the job used to sit at 0 of 1 until the file landed, which on a slow link is what a stall looks like.

The firmware download was fixed for precisely this. The terrain warm was not.

N13: a running download is not surfaced at all

With a firmware download in flight and ui.state reporting jobs: 2, the status bar showed only 4873 links, weighted by the weaker direction's margin. The download had nowhere to appear.

N14: no progress is reachable programmatically

session.status returns the finished summary and never the running job. ui.state returns a bare jobs: 2 with no name, no total and no progress. A script driving the workbench cannot tell what it is waiting for or how far along it is, which is the same gap the scripting notes already warn about for waits.

Related, and still live: ui.state still reported jobs: 2 after the firmware download had completed and the file was on disk, which is the documented "finished jobs are only marked, not removed" trap.

N15: resource.list answers with a count where the rows were the question

resource.list -> {"rows": 5}

The five rows are not reachable through the verb. This is the fifth instance of a shape already fixed in four other verbs, and it bit me directly: I could not find out what the resources were without reading the source.

N16: there is no way to obtain the emulator toolchain from the GUI

The Resources page has five providers, and I checked them in the source: SoftDevice, terrain tiles, basemap, building footprints, map tiles. None of them is Renode, QEMU or radioserver. So a user cannot fetch the emulator toolchain from the application at all, and ~/.cache/meshbench/tools/ does not exist on this machine, including in the real non-test install. That is why the four emulated live tests fail here.

To be fair to the docs, tools.html is genuinely good on this: the four search locations and their order, the tool table with environment variables, why the versions are pinned (the SX1262 device, the SEVONPEND fix), and what each bundle ships. The gap is not knowledge, it is that a source checkout has no path to those tools at all - not automatic, not offered, not in the GUI - while the docs describe the cache directory as "where the installer puts anything it downloads after the fact". For someone running a development build, no installer ever does.

Credit where it is due: when you do try to start an emulated node without them, the error is excellent. It names all the search locations, says what to do, and warns that a distribution build will not work because ours carries the SX1262 device.

What a user currently has to do, start to finish

1. Download the tarball release, not the AppImage or the .deb: those two carry radioserver but not the emulators, at 110 MB against a 26 MB AppImage.
2. Or, from a source checkout, build radioserver from meshcore-native with ./build.sh radioserver out, obtain a QEMU carrying our SX1262 device and configured --enable-gcrypt, and a Renode carrying the SEVONPEND fix.
3. Put them beside the binary or in ~/.cache/meshbench/tools/. Not on PATH: a desktop application inherits nothing useful from a shell.
4. Then download a board image from the firmware library and set a node's role to it.

Steps 2 and 3 have no support in the application whatsoever.

Running total

Scenarios 1 to 4, 10 and 11 covered across the three parts. Sixteen notes, N1 to N16. The ones I would not release without deciding on are N3 (misclassified miss causes), N9 (a shipped fixture failing its own assertion), N11 (half a gigabyte with no consent) and N16 (emulated boards unobtainable outside a tarball release).

I have not brought an emulated board up, because the toolchain to do it does not exist on this machine and cannot be fetched from the application - which is itself the finding.

[A13xB0]

Claude's pass, part 4 (scenarios 5, 6, 7, 8, 9, 10 steps 1 and 2, and 12)

Driven through the control socket against a windowed build of origin/main at 8a6c509, which stamps itself dev+8eb4156. One mesh at a time. Every code reference below I re-checked against main afterwards and it still holds. Notes continue from N16.

The headline: scenario 9 now passes - an emulated Generic_E22_sx1262 boots, adverts on the air unprompted and answers its console, three runs of three. Scenario 7 fails outright: meshbench dev truncates its own build to zero bytes whenever a workbench is running, so the firmware development loop does not work at all in the only situation it is used in. And there is a way to wedge the whole application permanently that I hit twice by accident (N29).

---

9. One emulated board - PASSES, 3 runs of 3

N16 is answered: ~/.cache/meshbench/tools/ now holds radioserver, qemu-system-xtensa and renode, and the new Setup page finds all three and says where. setup.check reports "ready": 6, "missing": 1 with only the Nordic SoftDevice outstanding, which is honest and exactly the page N16 asked for.

Three nodes on a blank network, Emu set to Generic_E22_sx1262 and pinned to the published simple_repeater v1.17.0 board image, the other two native. QEMU comes up with our own machine and radio wiring:

qemu-system-xtensa -machine esp32,radio-path=.../nodefs/Emu/radio.sock,radio-spi=2,
  radio-nss=18,radio-busy=32,radio-dio1=33,radio-fem=13 ...
radioserver: listening on .../nodefs/Emu/radio.sock
radioserver: joined the engine at 127.0.0.1:38039
radioserver: emulator connected

It boots, provisions, and adverts unprompted:

{"at_ms": 35750, "class": "sent", "detail": "114 bytes, 586 ms on air",
 "from": "Emu", "kind": "tx", "message_id": 3129343913604550904}
{"at_ms": 36336, "class": "received", "detail": "first time this node heard the message",
 "from": "Emu", "to": "Ears1", "snr_db": 15}
{"at_ms": 36336, "class": "received", "detail": "first time this node heard the message",
 "from": "Emu", "to": "Ears2", "snr_db": 6.96}

nodes.stats puts it beyond doubt: {"name": "Emu", "backend": "emulated", "sent": 1, "last_sent_to": "Ears2", "irq_reads": 25860}, and both native nodes heard: 1 from Emu. The console answers:

> get name
  -> > Emu
> get repeat
  -> > on
> advert
  -> OK - Advert sent

Three full runs from scratch, three adverts, three consoles answering. Given how flaky this has been I ran it three times before writing that down.

• N17 (UX): a node's console shows nothing of its own boot. console.read on a node that has been running for minutes returns {"lines": 0}, because consoleFor attaches the buffer on first use and only collects from that moment. Everything interesting has already happened and is only in ~/.cache/meshbench/nodefs/Emu/console.log, which no part of the application shows: the ROM banner, E (1723) SPIFFS: mount failed, -10025, the repeater ID, and the whole provisioning conversation. Somebody debugging a board that will not start opens the console and finds it empty.
• N18 (determinism): an emulated node is not deterministic in time. Same seed, same scenario, three runs: the advert went out at 35.75 s, 41.20 s and 34.79 s. The message id was identical all three times, so the content is stable and only the timing moves - the emulator free-runs against the wall rather than against the engine's clock. Worth saying out loud somewhere, because "same seed, same result" is stated as a feature and this is a real exception to it.

---

7. Firmware development loop - FAILS

N19 (bug, and the one I would fix first): meshbench dev destroys the build it just made, whenever a workbench is running.

Same command, same checkout, twice, differing only in whether a workbench was listening on the control socket:

$ MESHBENCH_CONTROL_SOCKET=/tmp/no-such-socket meshbench dev -from ~/msim/MeshCore -name local-p4a
local-p4a  .../firmware/native/local-p4a/meshcore-simple_repeater-linux-amd64  0.6 MB
  workbench not running, so it is cached but not loaded
-rwxr-xr-x 583768  meshcore-simple_repeater-linux-amd64

$ MESHBENCH_CONTROL_SOCKET=/tmp/mb318.sock meshbench dev -from ~/msim/MeshCore -name local-p4b
local-p4b  .../firmware/native/local-p4b/meshcore-simple_repeater-linux-amd64  0.6 MB
  in the workbench's firmware library
-rwxr-xr-x      0  meshcore-simple_repeater-linux-amd64

firmware.Build already writes the binary into the cache at native/<label>/<NativeBinaryName(role)>, and that is the path it reports. cmd_dev then hands that same path to firmware.import, which calls firmware.Import, which computes dst as exactly the same path and calls copyFile(src, dst, true). copyFile opens the source for reading and then opens the destination O_WRONLY|O_CREATE|O_TRUNC - the same file - so io.Copy reads from a file it has already truncated. Zero bytes. It reports success, prints "0.6 MB" (measured before the import), and says "in the workbench's firmware library".

Everything downstream then fails in a way that does not name the cause:

node.start -> engine: firmware on 1 of 3 nodes; 2 failed, first: Ears1:
  firmware: no native builds published for MeshCore local-study-07-ack-redundancy
  Build one with meshcore-native's build.sh, or set MESHBENCH_NATIVE to your own

The fix looks like a same-file guard in copyFile, or not re-importing a path that is already inside the cache. I have not opened a PR because the branch and title want an MSIM-<n> and I do not have one.

Step 1 otherwise does what it says: the build is named after the branch (study/07-ack-redundancy becomes local-study-07-ack-redundancy), lands in the library, and is assigned to every repeater.

Step 2 and 3. Three arms - mine (the local build), release (repeater-v1.17.0) and control (also repeater-v1.17.0) - three seeds, two senders, on fife-permissive. The run log is genuinely readable while it goes; experiment.state returns a rolling log and session.status carries {"job": {"id": "experiment", "done": 6, "total": 9, "what": "running arms"}}, which is the progress N14 said was unreachable. That part is better than it was.

The results are not usable:

arm	runs	tx	rx	delivered	redundant	collisions	rx_spread	at_risk_2db
mine	3	0	0	0	0	0	0	absent
release	3	138.7	70	58.7	11.3	323.3	0.043	0
control	3	120.7	68	57	11	266.3	0	0

• N20 (UX): a failed arm reads as a catastrophic result. All three mine cells errored with the N19 failure, and the per-arm table renders that as delivered: 0 beside release: 58.7 with nothing on the row to say the arm never ran. The truth is only in the per-run err field and a top-level warning. The at_risk_2db key is correctly absent rather than zero, which is exactly the distinction the code comments argue for - the same care has not reached delivered.

• N21 (bug): the control arm is not identical to the arm it duplicates, and the seed is not what separates the runs. control and release are the same configuration and the same three seeds. They disagree on every column. Worse, look at the per-run rows:

  release 9001  tx 176  rx 74  delivered 62  collisions 493  airtime 164293
  release 9002  tx 120  rx 68  delivered 57  collisions 234  airtime 118929
  release 9003  tx 120  rx 68  delivered 57  collisions 243  airtime 118929
  control 9001  tx 120  rx 68  delivered 57  collisions 243  airtime 118929
  control 9002  tx 121  rx 68  delivered 57  collisions 278  airtime 119732
  control 9003  tx 121  rx 68  delivered 57  collisions 278  airtime 119732
  

  control at seed 9002 and at seed 9003 are byte-identical. So are release 9002 and 9003 in everything but collisions. And control at 9001 is identical to release at 9003 - a different arm, a different seed, the same row. What varies is the position in the run order, not the seed. rx_spread for control is therefore 0, which presents three runs that are really one measurement as perfect agreement. experiment.go's own header names this as the third of the three things that decide whether the numbers mean anything: "the seed must vary across runs of one arm, or the spread being reported is one draw repeated."

• N22 (bug): firmware.set with a role updates the view for every node. The engine-side loop honours the role filter; the world-side loop is

  for i := range w.Nodes {
      if node == "" || w.Nodes[i].Name == node {
          w.Nodes[i].Firmware = version
      }
  }

  so after meshbench dev the status bar says 46 nodes pinned to local-study-07-ack-redundancy (correct) while nodes.list shows all 58 carrying it, including nine companions, the room server, the emitter and the SDR observer - two of which never boot firmware at all.

---

6. Importing a real network - PASSES, with two faults

ScotMesh CoreScope, Fife as the area, the panel's numbered steps in order. Counts are reported at every step and they are good:

1. add area   boundary.set "Fife" -> 2 matches; boundary.accept -> {"accepted": "Fife", "areas": 1}
2. fetch      {"nodes": 59, "records": 488, "skipped_no_position": 44, "uncertain": 0}
3. commit     {"nodes": 59, "strategy": "replace-all"}   ->  750 links
4. read traffic   "read 39574 packets, 398 nodes seen"
5. apply regions  {"applied": 44}

And a flood then does relay. With regions applied before firmware starts, advert at Abernethy Repeater produced one message carried by 22 distinct transmitters to 25 receivers; later floods on the same network reached 31 and 17 transmitters. That is the thing the scenario asks for and it works.

• N23 (bug): infer.apply says 44 and the view shows 4. Reproduced on three separate imports. The verb's engine-side loop matches a node by public key or by name and applies to 44; the loop that updates the snapshot matches by name only (find(w.Nodes[i].Name, "")), and the comment beside it admits the compromise - "This keeps the live view roughly in step". The run is right and everything a person or a script can see is wrong: nodes.list reports regions on 4 of 59, and nodes.regions answers {"nodes": 59, "regions": null}. The importing page tells the reader to "confirm the count" at this exact step; the two counts available disagree by an order of magnitude, and the smaller one looks precisely like the failure the same page warns about.

Deliberately skipping "apply regions". Fresh import, no inference, everything else the same. The result is more subtle than the page says:

• a repeater's advert still floods, 22 distinct transmitters, exactly as with regions applied - adverts are unscoped;

• a companion's public message was transmitted once and received by nobody (1 transmitter, 0 receivers), against 1 transmitter, 6 receivers for the same command on the same network with regions applied.

• N24 (docs): "every node transmits and none relays" is only true of scoped traffic. From importing.md: "Without this step every node transmits and none relays." The first thing anyone does after an import is press advert, and that floods twenty-two hops deep with no regions at all. So the page's own headline symptom does not appear, and the operator concludes the import is fine.

• N25 (docs): the "If nothing relays" checklist's item 2 does not do what it says. It reads "A quiet node with no regions. The total was healthy, one repeater was not. Ask it: get repeat on its console." On a repeater holding no regions whatsoever, get repeat answers -> > on, because it reports whether repeating is enabled and says nothing about regions. region list, the obvious next guess, answers -> Err - ??. So the checklist item that exists to find a node with no regions cannot find one. Items 1, 3 and 4 are sound.

• N26 (docs): the socket lane tells you to call a verb that refuses. importing.md:219 lists {"id":9,"method":"infer.result"} between infer.run and infer.apply. The live answer is infer.result is the workbench's own callback, not a verb to call, a good refusal to a call the documentation asked for. It is registered with HandleInternal and gated in socket.go, so it can never be reached from outside. reference-control.md:68 repeats the same dead step in its flow line, infer.run {hours:168} -> infer.result -> infer.apply. The ::python and ::go lanes of the same block correctly leave it out, so it is only the socket lane in both places.

---

8. A companion app against the mesh - PASSES

meshcore-cli is not installed on this machine, so I wrote a raw socket client instead. bench.serve gave {"node": "Phone", "addr": "10.100.72.98:46251"} - a LAN address rather than loopback, which the code explains and which is right for pointing a phone at it.

Sending APP_START framed as '<', little-endian length, payload, the reply is real protocol:

frame '>' len=66 code=5   (RESP_CODE_SELF_INFO)
050116164716516b1e93ccf945737e365342a680545bcbaa7d26d3443271f4d3951e54e2
00000000000000000000000040d6011a40d6011a08053437313635313642
adv_type=1  tx_dbm=22  max_tx=22
pubkey 4716516b1e93ccf945737e365342a680545bcbaa7d26d3443271f4d3951e54e2

That is what infos prints. Then bench.drop answered {"dropped": 1} and the client saw the socket die immediately: recv returned b'', and a write followed by a read also returned b''. Serving again and reconnecting worked first time and returned the same SELF_INFO.

• N27 (UX): serving again moves the endpoint. The port is allocated with port zero, so the first serve was :46251 and the second :37461. Correct on its own terms - the comment explains that a fixed port collides with the last run that has not finished dying - but it means "press stop, press serve" hands the operator a new address every time, and any client that was pointed at the old one has to be reconfigured rather than reconnected.

---

5. SDR observer - PASSES on substance; SDR++ itself not driven

SDR++ is installed here (/usr/bin/sdrpp), but it is a GUI application and this machine belongs to somebody who is using it, so I did not open it. Instead I connected a raw rtl_tcp client to the served observer, which tests everything except SDR++'s own settings.

sdr.serve answered {"node": "SDRObs", "addr": "127.0.0.1:41477", "rate_hz": 250000} and the stream begins with a genuine dongle-info header, 52544c30 00000005 0000001d - magic RTL0, tuner 5, 29 gain steps - then IQ at 494 kB/s, which is 247 k complex samples a second against a declared 250 kHz.

The playing-versus-paused difference is unmistakable once there is traffic. Six adverts fired during a 30 second sample, then a 15 second sample while paused:

	rms	peak	samples above magnitude 20
playing	14.27	89.90	744,807 of 7,487,387 (9.95%)
paused	3.56	13.51	0 of 3,737,688 (0.00%)

Bursts well above the floor while playing, the bare floor while paused, in both calculated and waveform mode (waveform measured separately: 15.56 / 97.68 / 6.26% against 4.03 / 19.14 / 0%). And the stream survived being dragged: four nodes.move calls across the map while a client was attached, with no break and no change in rate.

One thing worth knowing for anyone repeating this: a short sample with no traffic in it looks identical played and paused. My first attempt sampled 8 seconds after a single advert and measured rms 3.59 against 3.56, which I very nearly wrote up as a defect. It was an empty window.

• N28 (scripting): nodes.move takes name where every other node verb takes node. nodes.move with {"node": ...} is refused with nodes.move needs a name: which node to move, which is a clear refusal, but it is the only verb of its family spelled that way.

---

10 step 1. Cookbook example 3 in Python - PASSES

03_small_mesh_with_traffic.py, with MESHBENCH_BINARY pointed at the build under test, built the mesh, ran ten minutes of simulated time and printed:

MeshBench: calculated reception, default excess loss - a best case; no multipath,
no body loss, no oscillator error
162 events, 63 receptions in the tail

Exit code 0, and the run log ends t= 600.610s run finished. Ten minutes and four seconds of wall clock for six hundred seconds of simulated time, so essentially realtime on this machine, on a four-node mesh.

---

10 step 2. The docs site's language toggle - PASSES

Verified by driving headless Chrome against the generated site over http:// with a persistent profile, not by reading the JavaScript. Clicked python once on importing.html: all six ways blocks on the page moved from gui to python and localStorage["meshbench-docs-way"] became "python". Then navigated to fixtures.html, debugging.html and testing-repeaters.html with no further clicks, and every one came up on python, tabs and panes together. The choice is stored on click and re-applied on load, so it is remembered as the scenario asks.

---

12. Docs site and READMEs, as a reader - PASSES WITH FAULTS

The Learn path reads well and most of what it asserts checks out against the tree. The interactive parts are in good shape and I could not fault them.

What is fine, said once each. Search on / focuses the box without inserting the slash, "waveform" returns nine hits with correct deep links, arrow keys select, Escape closes and blurs, and / typed inside the box inserts normally. The on-page rail renders when a page has three or more h2s, is present at 1440 px and correctly hidden below the 1120 px breakpoint, with scrollspy. At phone width (390 px, DPR 2) the nav goes static, thirty-eight links collapse behind a toggle with aria-expanded handled properly, search stays usable, results fit the viewport, and none of eight pages checked overflowed horizontally; wide code scrolls inside its own container. In both themes the rail is rgb(20,19,31) and the logo renders byte-identically, so the white logo on its dark rail is right everywhere. There are no broken internal links or dead anchors in the generated HTML, and infer.result is the only verb the docs name that does not exist. reference-cli.md's tables match cmd/meshbench/; fixtures.md's counts are exact for all three fixtures (58/46/9, 161/142/16, 378/336/39).

And N11 is partly answered: getting-started.md now says "roughly 500 MB of terrain that arrives on first launch" and "Budget about 1 GB for a first session", with a bandwidth warning and the -fixture "" escape. That is the docs half of N11 fixed.

• N32 (bug): "File, Open a saved network" cannot open a shipped fixture on a fresh install. first-simulation.md:10 and fixtures.md:20 both open with "File, then Open a saved network" and then name a shipped fixture. That menu item runs project.list, which reads only os.UserConfigDir()/meshbench/projects; nothing seeds the shipped fixtures into it and no menu item lists fixture.Embedded(). Measured live: project.list returned {"dir": "/home/alex/.config/meshbench/projects", "projects": ["fixture-scotland-ireland-permissive", "fixture-scotland-ireland-strict"]} on a machine that has been used for months, and fixture-fife-strict, the one the page tells you to pick, is not among them. On a fresh install that picker is empty. This is the first instruction of scenario 2, and it only worked for me because I opened fixtures by path over the socket.
• N33 (docs): testing.md's worked example is stale and names a node that does not exist. Line 154 shows node Kirkcaldy Companion, 58 nodes running real MeshCore firmware. There is no Kirkcaldy Companion in fixture-fife-strict; cmd_serve.go picks the first companion_radio in file order, which is AngusOutlaw1. The count is the N1 error again: firmware.state returns 56 running of 58. app-development.md:13 has the identical block correct, so this is a copy that did not get updated.
• N34 (docs): "reach the node total" is the exact wording that produced the 56-of-58 bug. It appears in first-simulation.md:17, fixtures.md:28 and testing-repeaters.md:94. The running count reaches 56 and the node total is 58, which is what enginefirmware.go's own comment is about. Three pages tell the reader to wait for a number that does not arrive.
• N35 (docs): concepts.md:96 lists five node kinds and there are six. It omits advanced-repeater, which is a real Kind and is present in every shipped fixture. fixtures.md:14 lists all six, so the two pages disagree.
• N36 (docs): the glibc floor is wrong, and the example distribution is below it. docs/install.md:37 in the main repo, which getting-started.md links to twice as the authority, says "Needs glibc 2.34 or newer (Ubuntu 22.04, Debian 12, RHEL 9, Fedora 35 ...)". The pipeline builds against 2.35, and getting-started.md itself says 2.35. Fedora 35 ships 2.34 and would not run it.
• N37 (docs): getting-started.md disagrees with its own next paragraph about what a release contains. Line 11 says "Releases ship builds for Linux (AppImage), macOS (dmg) and Windows (zip)"; step 1, four lines later, downloads meshbench-linux-x86_64.tar.gz and untars it. The .deb the pipeline publishes is never mentioned, and the dmg is Apple Silicon only while the page says just "macOS (dmg)". Given N16, which build a reader picks decides whether they can run an emulated board at all, so this one has consequences.
• N38 (bug): the main README has a broken image. README.md:49 references docs/workbench-plan.png; the file is at docs/images/workbench-plan.png. Broken for every reader.
• N39 (bug): two of the five README badges are dead. The CI badge .../actions/workflows/ci.yml/badge.svg returns 404 and renders broken, and the release badge returns 200 with the SVG title release: no releases or repo not found despite four real releases, v0.0.4 being the latest. Both because shields.io and camo fetch anonymously and the repository is private. The three static badge/ shields are fine. Worth deciding before the release whether to drop them or accept that they will come alive at the same moment the repository does.
• N40 (UX): the docs site is public and almost every link it makes into the repository 404s. https://meshbench.github.io/docs/ serves fine, but the clone URL, the releases page, docs/install.md linked from getting-started.md, and both meshbench-dev-skills and meshbench-scripting-skills are private and give a reader outside the org a 404. Only MeshBench/meshbench-reports resolves. That is a consequence of the repository still being private rather than a mistake, but it is what a reader meets today, and it is the same set of links a first release announcement would send people down.

The docs repo README's <picture> block is genuinely theme-aware and correct: the light fallback is a staged image that is fully visible on white, and the white PNG is only ever served to dark. The main README's header card exists and is tracked; its raw URL 404s anonymously and 200s with a token, which is private-repo behaviour rather than a missing asset. I could not check how either README actually renders on github.com in the two themes, because the repository is private and I did not open a browser session against it, so the badge and image behaviour there is inferred from status codes plus camo's known anonymous fetching.

---

Two faults that are not any one scenario's

• N29 (bug, and the worst thing here): replacing the network while firmware is running wedges the whole application, permanently. Twice out of two attempts, calling project.new (File, New network) while 59 nodes were running firmware and the run was playing, then starting firmware on the new network, left the workbench answering nothing at all - not the control socket, not the window, no further line in the session log. I left the first one 25 minutes and the second about 10, and neither moved. SIGQUIT says exactly where:

  goroutine 10 [select, 16 minutes]:
  internal/firmware.(*Bridge).WaitAdvance(...)      firmware/lockstep.go:48
  internal/sim/engine.(*Engine).runFirmware(...)    engine/firmwarerun.go:50
  internal/sim/engine.(*Engine).Step(...)           engine/engine.go:383
  internal/app/session.Register.func3.1(...)        session/verbs.go:175
  internal/app/state.(*Store).Run(...)              state/store.go:199
  

  The store's own goroutine is inside a tick, waiting for a firmware bridge to acknowledge an advance. WaitAdvance ends on an ack, on the node's done channel, or on the context - and the tick calls s.eng.Step(context.Background()), so there is no context to end and no timeout. One node that neither acks nor closes parks the goroutine that answers every verb and draws every frame. There is no way back except killing it.

  The counter-test: pausing and calling node.stop on every node before project.new made the identical import-and-start sequence complete in 37 seconds. That was a three-node mesh rather than fifty-nine, so treat it as suggestive about the trigger rather than proof of it. What the stack does prove is the exposure: a single bridge that neither acks nor closes can park the goroutine that answers every verb, with no timeout to end it.

• N30 (bug): a workbench launched with a fixture name that resolves to nothing can never run anything. -fixture "" prints loading: fixture: nothing named and carries on. w.Tick is only ever installed by installBody, which nothing on that path calls, so pressing play sets playing: true and advances sim.state's now_ms forever while the engine is never stepped: events stays 0, nothing transmits, and typed console commands queue up unanswered. sim.step is silent about it too - it returns now_ms and does nothing when w.Tick is nil. project.new installs the tick and fixes it, so a person who does File, New network never meets this; a script that launches with a mistyped -fixture gets a workbench that looks completely healthy and is inert. Measured: sim.state reported now_ms: 390910 while the engine's own clock was at 1800 ms.

Smaller

• N31 (scripting): nodes.list's sent and heard are always zero. Nothing in the tree ever writes state.Node.Sent or .Heard. With nodes.stats reporting Emu sent 1 and the Scoreboard panel drawing Emu 1, nodes.list still returned sent 0 heard 0 for every node. The panels read NodeStat and are fine; it is the two fields the socket publishes that are dead. Same family as N7 and N15.
• boundary.set "Fife" returns two entries that are both {"kind": "administrative", "name": "Fife"}. Nothing distinguishes them, so a person choosing from that list is guessing.
• Positive, and worth recording: the new Setup page is a direct answer to N16. It names every tool, where it was found, what it cost on disk, and for the one thing missing, what to press. session.status now carries a job object with done, total and what, which closes most of N14.

Running total

scenario	verdict
5 SDR observer	passes on substance; SDR++ itself not driven
6 importing a real network	passes, faults N23 N24 N25 N26
7 firmware development loop	fails, N19 N20 N21 N22
8 companion app	passes, note N27
9 one emulated board	passes, 3 runs of 3, notes N17 N18
10 step 1 cookbook in Python	passes
10 step 2 docs language toggle	passes
12 docs site and READMEs	passes with faults, N32 to N40

Every scenario has now been through a pass. Forty notes, N1 to N40.

The ones I would not release without a decision on, adding to N3, N9, N11 and N16 from the earlier parts:

• N19 - meshbench dev truncates its own build to zero bytes whenever a workbench is running, which makes scenario 7 impossible as written and is a one-line same-file guard away from working.
• N29 - the whole application can be wedged permanently from a menu item, with no timeout anywhere in the path to end it.
• N32 - "File, Open a saved network" cannot open a shipped fixture on a fresh install, and that is the first instruction of the first documented walkthrough.
• N21 - the Bench's control arm does not reproduce the arm it duplicates, two of three seeds give bit-identical rows, and rx_spread therefore reports perfect agreement between runs that are really one measurement.

The first three are things a new user meets in their first hour. The fourth is worse in a quieter way: it is the one tool here whose whole job is to say whether a difference is real.

[A13xB0]

Claude's pass, part 5: on Windows

Windows 10 Home 22H2 (19045.6466), Intel UHD 620. First pass on this platform, so it is aimed at what only Windows can answer, plus the notes from parts 1-4 that a second machine can settle.

Driven over the control socket against main + #497 + #502 + #503 + #504 merged, which is what a release would be if the open Windows work lands. Scenario 1 cannot be done without #503 at all - a bare meshbench.exe is what the Start menu runs, and it exited 2 with nothing on screen, which is #499.

scenario	verdict
1 install and first launch	passes with #503; fails outright without it
2 first simulation	passes
4 waveform mode	passes
9 one emulated board	fails - the toolchain is found, the image cannot be fetched (#516)
10 step 3 meshbench test -junit	passes - N9 is fixed
11 determinism	passes
3, 5, 6, 7, 8, 12, 10 steps 1-2	not reached

---

1. Install and first launch - passes, and most of part 3's notes are answered

From a genuinely empty cache (LOCALAPPDATA and APPDATA pointed at fresh directories), launched by a GUI-subsystem parent with no console, which is what the Start menu gives it.

N11 is fixed. Part 3 measured 513 MB across 6,233 terrain files on a first launch with nothing clicked. Now, after sixty seconds of touching nothing:

cache: 0.2 MB in 20 files

Terrain is not fetched until it is allowed. sim.state says so properly:

no terrain: nothing under this study is cached and nobody has been asked whether it may be downloaded, so this is bare earth, which the propagation model treats as free space: the most optimistic answer it has... terrain.allow settles it either way

and the held warm reports itself as a finished-and-failed job, exactly as the scripting notes describe: {"id":"links","finished":true,"failed":true,"what":"held: no permission to download terrain, no link measured"}.

N12 is fixed. Allowing terrain, the download is now its own job, priced in bytes:

t+ 3s  tiles: fetching terrain, 0 MB of about 499 MB    1/6233
t+15s  tiles: fetching terrain, 33 MB of about 499 MB   368/6233
t+27s  tiles: fetching terrain, 59 MB of about 499 MB   768/6233

N13 is fixed - session.status's job field carries that tiles job, so the running download is what surfaces rather than the links job behind it. N14 is largely answered by job.list, which returns rows with done, total, what, finished and failed. N15 is fixed - resource.list returns the five rows, not a count.

One residual: for the first 15-20 seconds the library is genuinely empty while the published catalogue is fetched, and nothing says a fetch is in flight. I read it too early twice and concluded board images did not exist on Windows before waiting properly. They do - 72 of them.

2. First simulation - passes

fife-strict, 56 of 58 nodes on firmware, advert at Abernethy Repeater answered -> OK - Advert sent, and the flood reached 35 distinct transmitters and 222 receptions, events 791 to 7,772. N1's 56-of-58 wording is still what the checklist says.

4. Waveform mode - passes

rf.mode to waveform is picked up mid-run without stopping: events went 1 to 2,401 across the switch, and the status line names the mode both ways.

• waveform: waveform RF: reception is decided by the full receive chain - demodulation, FEC and CRC
• back to calculated: calculated RF: reception is decided by link budgets and demodulator floors - the fast model

N8 is fixed. rf.mode with no argument now answers {"mode": "calculated"} instead of erroring, so a script can ask what mode it is in.

3 (partly). N3 is fixed, and it is worth showing

EventClass no longer prefix-matches the detail prose - it reads ev.Class, with ClassUnclassified where it used to fall through to floor. Measured over 3,000 events of one waveform run, the classes separate properly and floor holds only real floor misses:

collision      decoded its header, then 165 symbol(s) were destroyed by a collision
floor          waveform: no preamble lock at -11.1 dB measured SNR
               waveform: header unreadable at -10.5 dB measured SNR
half-duplex    its own transmitter was keyed; LoRa is half duplex
interference   would have decoded at -3.7 dB, lost to a stronger interferer
receiver-busy  its demodulator was already locked to sco-tay-moncreiffe; a LoRa receiver decodes one packet at a time

Part 1 found 37 of 357 misses classed floor and not one of them a floor miss. That is gone.

10 step 3 - passes. N9 is fixed

$ meshbench test -fixture fixtures/fixture-fife-strict.json -junit out.xml
fixture-fife-strict: 58 nodes, 56 running firmware, SF8 at 62 kHz, seed 9001
provisioned 56 nodes with 526 lines and 67 frames
ok    at least 10 unique deliveries
        317 unique deliveries, wanted at least 10
PASS: 1 assertions, 17s     exit 0

N10 is still live. grep over .github/workflows still finds no invocation of meshbench test, so the shipped fixtures' assertions are enforced by nothing. N9 was fixed by something else noticing; the gap that let it hide is unchanged.

11. Determinism - passes

Two runs of fixture-fife-strict at the shipped seed: 317 unique deliveries both times, and the two outputs are byte-identical once the timing line is removed.

9. One emulated board - fails, and not for the reason part 3 predicted

N16 is answered on Windows. The Setup page finds the whole toolchain out of the MSI bundle and names where each one is:

Emulator toolchain
  ready   radioserver          C:\Program Files\MeshBench\radioserver.exe
  ready   qemu-system-xtensa   C:\Program Files\MeshBench\qemu\bin\qemu-system-xtensa.exe
  ready   renode               C:\Program Files\MeshBench\renode_1.16.1-portable\renode.exe
  ready   s140 SoftDevice      C:\Users\amy\AppData\Local\meshbench\softdevice\s140-6.1.1

setup.check reports ready: 8, missing: 1, the one being board images. And that is where it stops: every published board image 404s on download (#516). The catalogue derives its version from the asset filename and discards the release's tag, so it offers v1.17.1 and the fetch asks for releases/tags/v1.17.1, which does not exist - MeshCore tags are repeater-v1.17.1. boardcheck/probe.go already composes the tag correctly; the download path never got it.

So the toolchain problem part 3 found is solved, and a different one now stands in the same place. On a machine with no image already cached, an emulated board cannot be started at all.

Three other things came off this scenario:

• Every row in the firmware library points at a 65-byte checksum file, not the build #515 - every row in firmware.library points at the .sha256 sidecar rather than the build, so all six builds are described as 65 bytes and the real executables appear nowhere. Running firmware is unaffected, which is why it has gone unnoticed.
• firmware.set accepts parameters it does not read, and pins a board node to a native build #517 - firmware.set accepts board and does not read it, pinning a board node to a native build; the failure then reads no native builds published for MeshCore v1.17.1, which sends you off to build MeshCore from source for a problem that is nothing of the kind. It accepts arbitrary unknown keys too, which is the rule Four verbs do not read the parameter their own description documents, and six fields are empty after a fixture opens #476 closed.
• wb.sim.start() waits for a node that has already failed to start, with no timeout and no error. It sat for over seven minutes on a three-node network where the failure was known within eight seconds. Calling firmware.start and polling firmware.state shows it immediately; sim.start never notices.

Windows-only faults, filed separately

• The Windows MSI installs, then the application starts and disappears #499 / cmd: a bare invocation opens the workbench (#499) #503 - the Start menu shortcut passes no arguments and main treated that as a usage error, so the application started and vanished. Root-caused against the installed v0.0.5 whose SHA256 the issue names.
• cmd: keep redirected output on Windows, and let a crash say where it happened #502 - firmware, cmd, package: the Windows pass — every windows-tagged issue #497's console adoption throws away redirected output, and a panic still reached nobody. Both fixed and measured.
• Tests do not isolate their cache on Windows, so they read and write the real one #505 - t.Setenv("XDG_CACHE_HOME", ...) does not isolate on Windows, so fifteen test files read and write the real cache. This machine's runs directory now holds 100 run-0NN.json records planted by the test suite, and TestRunPanelsDrawBeforeTheDiskAnswers fails because it reads 200 where it wrote 4.
• go build ./... does not compile on Windows: tools/goldencap has no build constraint #506 - go build ./... does not compile on Windows: tools/goldencap uses termios constants with no build constraint.
• windows-check.yml tests a command that no longer exists, and hides it #507 - windows-check.yml tests meshbench.exe check, a command that no longer exists, and hides the failure behind || echo and continue-on-error.
• The MSI has no dialogs, so it cannot say it finished or let anyone choose where it goes #508 - the MSI has no dialogs at all, so it cannot say it finished or offer a location; wixl builds none, and getting either means moving off it.

Not reached

3 (the Debug view and the link tool as a person uses them), 5 (SDR++), 6 (a live CoreScope import), 7 (meshbench dev - no MeshCore checkout here), 8 (meshcore-cli), 12 (the docs site as a reader), and 10 steps 1-2.

[A13xB0]

The pass now covers the whole application rather than twelve hand-picked journeys, and every step produces a picture.

Part one is unchanged: the twelve scenarios are the paths somebody actually walks, and a sweep of every window does not replace them.

Part two is the inventory, driven from a manifest:

bucket	steps
Views	6
Panels	72 — every panel docked, and again popped out
The node window	10 — one per tab
The board view	3
Configuration	6
Licences	5
Menus	7
total	109

Run it with:

go build -o meshbench ./cmd/meshbench
tools/shots/shots.py

The list cannot go stale. internal/ui/workbench/shotsteps_test.go reads tools/shots/steps.json against panelMenus — the same table the panel registrations use — and fails when a panel has no capture step, in either direction. Verified by deleting a step: "Waterfall" has no docked capture step, so nothing takes its picture.

Two things this turned up while being built:

• The board view had no flag at all. It opens from a button on a node's Hardware tab and nothing else, so no capture could reach the one window this release just shipped and documented. -board-view and -board-tab now exist.
• -play alone photographs a broken panel. It advances the clock and leaves every counter at zero, which looks exactly like a panel that does not work. The traffic steps carry -inject too: measured 24 events / 8 sent / 16 received, against 0 of 0 for the same panel a moment earlier.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6

[A13xB0]

Claude's pass, part 6: the v0.0.7 release on Windows

First pass against a published release artefact rather than a build tree. Downloaded meshbench-windows-x86_64-bundled.msi from the v0.0.7 release, SHA256 checked against the release's own SHA256SUMS (871b123c…6cfb, matches), installed with msiexec /qn, exit 0. Windows 10 Home 22H2 (19045). Driven over the control socket, with screenshots.

> meshbench.exe -version
meshbench v0.0.7, go1.25.13, bundled

Issues opened this pass: #607, #608, #609, #610, #611, #612, #613.

---

Scenario verdicts

scenario	verdict
1 install and first launch	passes; steps 3-4 not testable on a release build, see below
2 first simulation	passes, one wording note
3 debugging a missed packet	partial — causes verified, cut-through not reached
4 waveform mode	passes
10 step 3 meshbench test -junit	passes
11 determinism	passes
12 docs and READMEs	partial — #612
5, 6, 7, 8, 9, 10 steps 1-2	not reached
part two (109 pictures)	not run — needs the source tree, and #613 breaks its framing

---

1. Install and first launch — passes

Bare meshbench.exe — which is what the Start menu shortcut runs — opens the workbench. #499 is fixed; part 5 could not do scenario 1 at all without #503, and this needs neither.

The honesty line is present and picks up the terrain state: results are a best case: terrain only 49% cached, no multipath, bare earth, ideal demodulator. The update check works and says this is the newest release: 0.0.7.

Steps 3 and 4 cannot be run against a release build as written. They ask for MESHBENCH_CARTO_KEY set and then unset, expecting CARTO and then a fall back to OpenStreetMap. But package.yml stamps the key into release binaries at link time (-X …basemap.defaultCartoKey), so unsetting the environment variable does not leave the build keyless — it leaves it on the stamped key. The steps describe a build made from source, not the thing being released. Worth rewording, or splitting into "from source" and "from a release".

The API-KEY-REQUIRED scare, and what it actually was — #607

The first screenshot of the pass looked alarming:

It is not what it looks like. v0.0.7's key works and the ldflags are correct. Those are tiles cached on 2 September by a locally built binary — which has no key, because the secret only exists in CI — and the tile cache has no notion of whether a tile arrived keyed, so it re-serves them forever. Same build, same view, with the cache moved aside:

The dates settle it. Same tile, same day, four hours apart: carto-dark/9/251/158 at 12:03 clean, carto-light/9/251/158 at 15:57 watermarked.

Worth fixing because it is unfalsifiable from the inside — the app is doing everything right, the key is valid, and the map is still defaced — and because anyone who runs go build before installing a release hits it. Filed as #607.

2. First simulation — passes

fixture-fife-strict opened, firmware started on 56 nodes, played, advert typed at Abernethy Repeater:

 123.530  > advert
 123.530    -> OK - Advert sent

The flood spread and the Events panel filled with real physics — 3,280 events in the first 20 s, causes like decoded its header, then 165 symbol(s) were destroyed by a collision it could not capture over; beyond what CR 4/8 can repair.

Correction to N1 from part 1. That note said the checklist and the docs page say 58. The docs are right: first-simulation.html says "choose fixture-fife-strict to see it moving in seconds (58 nodes)", and the fixture does have 58 nodes. It is only this checklist's scenario 2 that says "watch the count reach 58" about the firmware count, which stops at 56 — the SDR observer and the emitter never boot firmware. One line to fix, here rather than in the docs.

3 and the Debug view

Not completed — I read causes from the event stream rather than driving the Inspector and the link tool. The Debug view itself draws and works:

4. Waveform mode — passes

Switched mid-run; the run continued without cutting a frame (events kept climbing, clock kept advancing) and the status bar stamps the mode. Switching back to calculated stamps correctly again, and session.status explains itself properly: calculated RF: reception is decided by link budgets and demodulator floors - the fast model.

10 step 3 and 11 — both pass

N9 is fixed and stays fixed. meshbench test -fixture fixture-fife-strict.json -junit out.xml gives 317 unique deliveries, wanted at least 10, PASS: 1 assertions, 16s, exit code 0, and the JUnit parses as valid XML.

Determinism: two runs at seed 9001 gave 317 unique deliveries both times, output identical but for the wall-clock line.

---

Two things about node names

#608 — supplementary-plane emoji draw as missing-glyph boxes. Ten of the 58 names in fixture-fife-strict carry emoji, and every one outside the BMP is a box, everywhere a name appears:

The split is clean — Bishop Hill ☀️🔋 shows both behaviours in one string, ☀ (U+2600) fine and 🔋 (U+1F50B) a box — so it is font coverage, not mangled data. The build ships LICENCES/bundled-noto-color-emoji.txt, so the face is bundled and licensed but is not in the chain for these codepoints. This one will bake itself into all 109 pictures of part two.

#609 — three names are already broken on disk. Drumcarrow Craig NWR ��, Kellie Law NWR 🌤️� and Kilcreggan Rpt ☀️��, ten occurrences across four shipped fixtures. The signature is a UTF-8 sequence cut mid-character: Lucklaw Hill in the same file is U+26F0 U+FE0F U+1F324, missing the trailing U+FE0F — the same cut one codepoint earlier, landing on a clean boundary so it left no marker. Live CoreScope returns 50 nodes today with zero U+FFFD, and carries multi_byte_status fields per node, so something upstream already watches for this.

The control socket, on Windows — #610, #611, #612

Three findings, and together they are the weakest part of the Windows story.

#612 — the reference page cannot be followed here. It says the application listens on $XDG_RUNTIME_DIR/meshbench.sock and stops there. On Windows the address is TCP on an auto port, written to %LOCALAPPDATA%\meshbench\control.json, and every connection must send {"token":"…"} as its first line. Neither is documented; I found both by probing. The same page also says "There are 256 verbs. 256 of them say what they are for … the rest are marked as not described yet" — the page carries exactly 255, and if all are described there is no "rest".

#610 — two workbenches cannot both start with the default. The second refuses, blaming tcp:127.0.0.1:0 — a port nobody requested, and the sentinel for "pick any free one". Explicit ports work fine; three coexisted happily.

#611 — and when a second one does start, it orphans the first. control.json holds one entry, so the newcomer overwrites it. Verified with a GUI workbench playing at 264 s and a fresh headless one: both alive and answering, and a client discovering the documented way reaches the idle one. Silent, and the bad kind of silent — a script does not error, it drives the wrong session against a real engine.

#613 — -look ignores its zoom

-look 56.33,-3.32,8 and -look 56.33,-3.32,14 render the same near-whole-world view; z16 shows Greenland. The centre is honoured, only the third field is dropped.

This matters for part two of this issue: shots.py frames its captures with -look, so every map-bearing picture in the 109 would come out at world scale — and shotsteps_test.go would not catch it, because a picture was taken.

---

What this pass did not cover

Scenarios 5 (SDR observer), 6 (importing), 7 (firmware dev loop), 8 (companion bench), 9 (emulated board), and 10 steps 1-2. Part two's 109 pictures were not run — they need the source tree, and #613 would frame them wrong. Part three was walked only for the pages the findings touch.

Screenshots and crops for everything above are on the evidence/issue-318-v0.0.7-windows branch under docs/evidence/318-v0.0.7-windows/; delete the branch whenever it has served its purpose.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG

[A13xB0]

Claude's pass, part 7: v0.0.8 on Windows, from a clean machine

Re-run of part 6 against v0.0.8, and this time from a genuinely empty machine rather than a warmed one — which turned out to matter, because it surfaced something the warmed pass could not have seen.

Method. Downloaded meshbench-windows-x86_64-bundled.msi from the v0.0.8 release, SHA256 checked against the release's own SHA256SUMS (71052c6a…a0ce, matches). Then, before installing:

• uninstalled the v0.0.8 MSI I had put on for the upgrade test — Program Files\MeshBench removed cleanly, its Start menu entry with it
• removed %LOCALAPPDATA%\meshbench (516 MB) and %APPDATA%\meshbench
• reinstalled from the MSI, msiexec /qn, exit 0
• launched bare meshbench.exe, which is what the Start menu shortcut runs, and touched nothing

> meshbench.exe -version
meshbench v0.0.8, go1.25.13, bundled

Six of the seven from part 6 are fixed and verified. One is half fixed. One new P1: #622.

---

The seven from part 6

issue	verdict on v0.0.8
#607 basemap cache serves keyless tiles	half fixed — new poisoning prevented, existing caches still served
#608 emoji draw as boxes	fixed — the bundle now carries the font
#609 U+FFFD in fixtures	fixed — zero, in both spellings
#610 two workbenches, port 0	fixed
#611 control.json orphaning	fixed
#612 control socket reference	fixed for Windows and the handshake; count still says 256 for 255 verbs
#613 -look ignores zoom	fixed

Details are on each issue; the short version:

#608 was the most satisfying to confirm. The fix commit left open whether the MSI carried the font at all — it did not, and now it does (fonts\NotoColorEmoji.ttf, 10.18 MB). v0.0.7 left, v0.0.8 right:

#613 also unblocks part two of this issue — shots.py frames captures with -look, so the 109-picture sweep can now be taken at the zoom each step intends.

#607 is the one to keep open. Keyless tiles now cache apart, which stops future poisoning. But tiles written before the fix went into the ordinary carto-light/ path, and a keyed v0.0.8 still reads it. Restoring my September 2 cache and launching v0.0.8 gives a defaced map again, with zero tiles fetched in that run — so it is reading pre-fix poison, not fetching keyless. The population this issue is about is exactly the population that already has a poisoned cache. A cache-path version bump would make the commit's "whatever is already poisoned stops being looked at" true.

---

#622 — first launch fetches 42% of the terrain and then reports partial for ever

This is what the clean machine bought. On first launch the app fetches terrain, says "about 499 MB", finishes, and stops:

The download completes cleanly — 6,233 files, 500.45 MB, no truncated or zero-byte tiles. But the study is then stuck reporting itself as partial:

partial terrain: 127 of 256 sampled tiles under this study are cached and the rest is bare earth, so some of this answer is free space and nothing in it says which part

terrain.prefetch — which nothing in the interface leads you to — says the study actually wants 14,725 tiles, with 8,492 still missing, another ~680 MB. Running it to completion gets to state: "terrain", 256/256, to_fetch: 0, and 948.94 MB on disk.

So first launch delivers 42% of the tiles and 53% of the bytes, presents that as the whole job, and leaves no route to the rest.

The sharpest consequence is that results move underneath you. meshbench test -fixture fixture-fife-strict.json -seed 9001 gave 350 unique deliveries while the cache was still filling and 322 — twice, identically — once it had settled. Same fixture, same seed, same build. That is correct for terrain-dependent propagation, and determinism itself is fine; but a number copied out of a first session does not reproduce later, and the only hint is a ground note you have to go looking for.

---

Scenario verdicts

scenario	verdict
1 install and first launch	passes, with #622 against it
2 first simulation	passes
4 waveform mode	passes
10 step 3 meshbench test -junit	passes — 350/322 deliveries, exit 0, valid JUnit
11 determinism	passes — 322 both runs, output identical but for the timing line
3 debugging a missed packet	partial — causes verified, cut-through not reached
12 docs and READMEs	partial — #612's remaining count
5, 6, 7, 8, 9, 10 steps 1-2	not reached
part two (109 pictures)	not run — needs the source tree, but #613 no longer blocks it

Scenario 1's first launch is a good experience now. It opens on Setup, which says what is ready, what is blocking, what is waiting on you and what is absent, with a cost against each row and a verb behind each button:

Uninstall is clean — Program Files\MeshBench and the Start menu entry both go. The only Start menu leftover on this machine is MeshBench WiX Trial.lnk, pointing at a MeshBenchWiXTrial directory that does not exist; that is from an earlier local packaging experiment rather than from any released MSI, so it is noted rather than filed.

---

A note on N11, which is no longer what part 5 recorded

Part 3 filed N11 (first launch downloads 513 MB of terrain unprompted) and part 5 recorded it fixed: terrain held until terrain.allow said otherwise. v0.0.8 does not behave that way — a fresh install starts fetching terrain immediately, with ground.chosen: false, and nothing asks.

I went looking before filing it, and this is deliberate and documented. terrain.allow says so plainly:

Downloads are on unless somebody turned them off; there is no third state and nothing waits to be asked.

and getting-started.html now discloses the cost up front, which is exactly what part 3 asked for and did not get:

Budget about 1 GB for a first session … the ground under its links is roughly 500 MB of terrain that arrives on first launch.
Bandwidth on the first run. That terrain is fetched before you have done anything else, so a metered connection is worth knowing about in advance.

So the design changed rather than regressed, and the docs followed it honestly. Flagging it only because this issue's own history says otherwise, and someone reading part 5 would expect a consent step that is not there. N12 and N13 are properly fixed: the progress line is priced in bytes and names the right activity, and session.status.job carries the running download.

The one thing the new docs get wrong is the 500 MB figure, which describes the partial fetch rather than the study — that is part of #622.

---

What this pass did not cover

Scenarios 5 (SDR observer), 6 (importing), 7 (firmware dev loop), 8 (companion bench), 9 (emulated board), and 10 steps 1-2. Part two's 109 pictures still need the source tree.

Evidence for this pass is on the evidence/issue-318-v0.0.7-windows branch under docs/evidence/318-v0.0.8-windows/, beside part 6's under 318-v0.0.7-windows/; delete the branch whenever it has served its purpose.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG

[A13xB0]

Pass on v0.0.8, on a machine that started with nothing

Run against the released meshbench-linux-x86_64-compact.tar.gz, not a source build, with XDG_CACHE_HOME and XDG_CONFIG_HOME pointed at empty directories so the whole thing was met the way a new user meets it. 109 of the 109 inventory pictures taken; every one looked at.

The headline: it works from new

From an empty profile, with nothing pre-fetched:

fixture-fife-strict: 58 nodes, 56 running firmware, SF8 at 62 kHz, seed 9001
provisioned 56 nodes with 526 lines and 67 frames
ok    at least 10 unique deliveries
        317 unique deliveries, wanted at least 10
JUnit written to /tmp/mbfresh/out.xml
PASS: 1 assertions, 11s

It fetched its own firmware, brought all 56 nodes up, delivered 317 packets, checked the assertion, wrote valid JUnit and exited 0. Scenario 11 holds too: 317 on three consecutive runs, identical.

Scenario results

#	scenario	result
1	Install and first launch	partly - it launches and warms, but see #616; step 4 is untestable as written (below)
10.3	meshbench test -junit	passes - assertions checked, valid JUnit, exit 0
11	Determinism	passes - 317 unique deliveries, three runs, identical
Views (6)	all six draw, switcher marks the current one	passes with a caveat - see #618
Panels (72)	every panel drawn docked and popped out	passes - all 72 taken, docked and popped-out sets match exactly. Layout faults in #619, #620
Node window (10)	one picture per tab	fails - see #624
Configuration (6)	one per section	fails - see #625
Licences (5)	one per section	fails - see #625
Menus (7)	one per menu	passes - all seven distinct and correctly structured

Scenarios 2-9 and 12 not attempted this pass.

Issues opened

Behaviour

• A first launch spends about 499 MB of terrain before anybody has pressed anything #616 - a first launch spends about 499 MB of terrain before anybody has pressed anything. The three-state consent prefs.go still documents has been collapsed to "on unless turned off", and the Resources panel's own footer ("Nothing here is fetched without being asked") is contradicted by its own "Filled itself 64.0 MB" card.
• The firmware refusal counts the truncated list, so it says "5 of 58" when it means 56 #617 - the firmware refusal counts the truncated display list: it says "no firmware for 5 of 58 nodes ... and 52 more" where the answer is 56. This is the first sentence a new user gets back when they press play.
• The first-run banner calls the machine unset-up while the page it opens says nothing is broken #618 - the startup banner calls the machine unset-up while the page it just opened says nothing is broken. Also why Setup, not the Map, is in front of all six view captures.
• Three shipped fixtures carry the same study area twice, byte for byte #623 - three shipped fixtures carry the same study area twice, byte for byte. The dedupe guard already exists in boundary.accept; these files predate it.

Layout

• Docked right-rail panels break at their own default width: chips sliced, a column header wrapped one letter per line #619 - docked right-rail panels break at their own default width: the Interference chip sliced in half, four filter chips unreachable, the Console's detail header wrapped one letter per line. Popping out is not a workaround - the Resources window draws Open Configuration as a vertical strip of letters.
• Event tables render flush to the bottom, so a short run leaves a void between the header and its own rows #620 - Events and Inspector render rows flush to the bottom, leaving up to 85% of the panel blank between the header and its own data.

The pass's own instruments

• The node-window capture steps are off by one from Tab, so five photograph the wrong tab and Output is never taken #624 - the node-window steps are off by one against Tab, because Antenna was added to the enum and not to the flag's help text or the manifest. Five of ten photograph the wrong tab; Output has never been photographed. Four more use a repeater for tabs only a companion, an observer or a board node grows.
• -config-section and -licence-section never open their panel, so eleven capture steps produce eleven identical pictures #625 - -config-section and -licence-section never open their panel, and five of the six configuration section names do not exist. All eleven captures in those two buckets are byte-identical pictures of the Setup page.

Small

• "1 assertions": three counted headings have no singular #621 - "1 assertions", in the Schedule panel and as the last line of a passing meshbench test.
• The Help menu has no route to the manual #626 - the Help menu has no route to the manual.

Corrections to this checklist

Scenario 1 step 4 cannot be tested as written. Unsetting MESHBENCH_CARTO_KEY does not leave a release build keyless: cartokey.go falls back to defaultCartoKey, stamped by the release pipeline. Verified - a cold cache with the variable unset still fetched into tiles/carto-dark (not carto-dark-keyless) and rendered CARTO Dark with no watermark. Step 3 passes as written. Step 4 needs rewording to say what a build with no stamped key should do, and testing on a source build.

The default fixture is the national one. A plain launch opens scotland-ireland-strict at 378 nodes, which is what makes #616 cost half a gigabyte rather than 63 MB. Worth saying in step 1 so the tester knows which mesh they are looking at.

One thing not checked

board-decoded is the single step needing a hand on the mouse (tick decode in the console strip), and the emulated-board scenario (9) needs a board booted one at a time. Neither was attempted.

Also noticed, not filed

• Node labels collide on the map at the fixture's default zoom ("The Mysterons" over "CaptBlack-Mysteron1", "Mothy" over "Jazzy").
• The map's layer panel cannot be collapsed and covers real nodes in a smaller window.
• The Experiment log and the session log both carry UI chatter - showing Setup, Logs is in its own window - Window, then dock every window back - alongside what happened to the simulation.
• Configuration > Overview reports a Vulkan device and measure links on the GPU on, with Last warm on the GPU: not yet after 679 links were measured. Might be a fallback that was not announced, might be ordering; not established either way.

[A13xB0]

Part 7 addendum: reconciling the Windows and Linux passes on v0.0.8, and a correction

The Linux pass (#616-#621, #623-#626) and my Windows pass (#622) ran against v0.0.8 within minutes of each other. Nothing was filed twice, but several findings touch, and one of mine was wrong.

The correction

In part 7 I wrote that terrain downloading unprompted on a fresh install was "deliberate rather than a regression, and the docs followed it honestly", and I explicitly declined to file it. That was wrong, and #616 is right.

My evidence was documentation: terrain.allow says "Downloads are on unless somebody turned them off; there is no third state and nothing waits to be asked", and getting-started.html now discloses the cost and warns about metered connections. I read the docs, found them self-consistent, and stopped. The Linux pass read the source, where the three-state design is still written down along with the reason for it:

TerrainDownloads is whether terrain may be fetched without asking. A pointer for the same reason as GPU: "not yet asked" is a third state, and it is the one a fresh install is in. A national network's ground is several hundred megabytes, which is not a thing to spend on somebody's tethered phone because they opened the application.
— internal/app/session/prefs.go:33

with access.go:61 collapsing it. So the documentation describes the collapsed behaviour rather than justifying it, and part 5 of this issue recorded the gate working. Documentation agreeing with the build is not evidence that either matches the intent — I treated it as though it were. N11 is a regression; #616 is the issue for it.

Where the two passes meet

Linux	mine	relationship
#616 first launch spends 499 MB unasked	#622 that fetch delivers 42% of the tiles	two halves of one behaviour — whether it should happen, and what it does when it does
#617 firmware refusal says "5 of 58"	part 6's note on scenario 2's "reach 58"	same number, different faults — theirs is a bug in firmwaregate.go, mine is the checklist's own wording. Both want fixing, or a fix gets tested against a checklist expecting 58
#623 duplicate study areas in fixtures	#609 U+FFFD in fixtures	same class — bad shipped data that survived several regenerations because nothing checked. #609's fix added a guard; a duplicate-area check belongs beside it
#624, #625 capture steps wrong	#613 -look ignored its zoom	same sweep — all three break part two's pictures. With #613 fixed and these two open, the 109 still cannot be trusted

The rest are independent: #618 (first-run banner), #619 (right-rail panels), #620 (event tables), #621 (1 assertions), #626 (Help menu) are all things the Windows pass either did not reach or walked past.

Cross-platform confirmations

I re-ran four of the Linux findings against the Windows MSI. All four reproduce, so none of them are platform-specific:

• A first launch spends about 499 MB of terrain before anybody has pressed anything #616 — fetching terrain, 58 MB of about 499 MB with ground.chosen: false, 59.5 MB on disk 25 s after a first launch on a wiped machine.
• The firmware refusal counts the truncated list, so it says "5 of 58" when it means 56 #617 — byte for byte: no firmware for 5 of 58 nodes … and 52 more, against firmware.state saying 56.
• "1 assertions": three counted headings have no singular #621 — PASS: 1 assertions twice in my own output, which I had read straight past.
• Three shipped fixtures carry the same study area twice, byte for byte #623 — identical hashes to theirs, 537327c423c188fa for both copies of Fife in fixture-fife-strict.

And #618 I had already captured both halves of without noticing: my first-launch screenshot shows Blocking 1 with the matching "something in this session cannot run" heading, and my later one shows Blocking 0 · Waiting on you 1 with "nothing is broken" — while session.status still returned "this machine is not set up yet". Both screenshots are on the evidence branch and are now linked from that issue.

Net position on v0.0.8

Twelve issues open against this pass across both platforms. Of the seven from part 6: five fixed and verified, #607 half fixed (existing poisoned caches still served), #612 fixed except the 256-versus-255 count.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG

[A13xB0]

Part 7 addendum 2: scenario 9 on Windows — emulated boards do not boot at all

I marked scenario 9 "not reached" in parts 6 and 7. Asked to actually run it, and it fails: #632, P0.

No emulated board boots on the v0.0.8 Windows bundled MSI. Not a flake — 2 of 2 probes and the ordinary user path, identically:

board.probe Generic_E22_sx1262
  build  passed
  boot   failed   bc-under-test: firmware started but never connected within 40s
  fem/flood/power/radio/rx/tx  untested

node.set_board + node.set_firmware + node.start
  ERROR: Abernethy Repeater: firmware started but never connected within 40s

The cause is three steps upstream of that timeout. nodefs/<node>/emulator.log:

qemu-system-xtensa.exe: sx1262: cannot load the chip model at
C:\Program Files\MeshBench\libvirtualsx1262.dll: The specified module could not be found.

The DLL is present and setup.check reports it ready. That message from LoadLibrary means a dependency is missing, and its import table names it: libstdc++-6.dll, the MinGW C++ runtime, which is nowhere on the machine and is not in the bundle. Upstream's virtual-sx1262 v1.3.0 Windows asset ships the DLL without it, so the fix belongs there — statically linking libstdc++ is the clean version. Full trace on #632.

Renode loads the same library through LoadLibraryW, so this is every emulated board on Windows, ESP32 and nRF52 alike, not just the QEMU path. Both emulators themselves are fine and run standalone (QEMU 9.2.2 meshbench fork, Renode 1.16.1).

What this means for this issue. Scenario 9 is the one part of the checklist that the Windows passes have never actually completed, and it has failed for a different reason each time — #516 (image would not download, since fixed), then #514's fetcher on compact builds, now this. It is worth treating as unverified on Windows until a board is watched booting there, rather than as a scenario that keeps nearly working.

It also blocks scenario 5 (SDR observer) and the emulated half of scenario 7 from being meaningfully tested here.

A check worth adding. package.yml runs file on the DLL, which passes on one that cannot load, and setup.check marks the row ready on the strength of the path existing. Something that tries to load it would have caught this before the release — the same shape as the bundle-carries-the-font check that #608 added one release ago, which is exactly the class of bug it was invented for.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG