igneum/docs/plans/miner-ui-5-first-share-runbook.md

Runbook: "first share within 10 minutes of download in 9 of 10 fresh Windows installs"

7 October 2026, miner-ui-5. The measurement behind the /evidence line in mission item 6 (docs/analysis/mission/mission.md 2.6, reinvent.md 3.1). Written for the shipper (ae892a8b0f78fe31c) to run at the Devnet 2 gate of each cut; the app lane does not run it. Nothing here touches PC 1 or a live manifest.

What is measured

Ten fresh Windows 11 installs, each timed from the download's first byte to the first accepted share or block, with three timed steps between: the installer (download start to the app's first screen), the node (first screen to node.synced true), the card (synced to the first ACCEPTED block line, or the first share once pool-0 exists). The claim passes when 9 of 10 reach the first accepted block or share inside 600 s of the download's start.

Where the numbers come from

Step	Start mark	End mark	Read from
Download	the first byte of Igneum-Miner-Setup-<v>.exe (the fetch's own timestamp)	the file complete	the job script's clock
Install and first screen	the file complete	api/state answers with phase = welcome (the engine is up)	the app's URL file, then api/state
Setup	welcome	setup_done true (Continue, Make me an address, I have saved my key, Start mining: the playbook clicks or the job posts api/setup)	api/state
Node	setup_done	node.synced true and node.state synced	api/state
Card	synced	ladder.first_block_at set (the first ACCEPTED block line) or, with pool-0, the first share_result line	api/state.ladder
Total	download start	ladder.first_block_at (or the share)	both clocks, the box's and the VM's, read as UTC

api/state.ladder.first_synced_at and first_mining_at carry the node and card marks from the engine's own clock; the runbook takes those over the script's reads when both exist.

The ten installs

• Ten fresh Windows 11 VMs (or ten fresh user profiles on the two PCs is NOT acceptable: a fresh profile shares the machine's node data and its driver state). The fleet's Windows wave boxes are the candidates; PC 1 and PC 2 are not (PC 1 is the project lead's desk, PC 2 holds a standing node).
• Each VM: the GPU driver installed, no Igneum folder under %LOCALAPPDATA%, the clock right (the clock card blocks mining otherwise and the run is void, not a fail).
• The download is the public installer URL of the cut under test, through the dl host, never a scratch copy.
• The run is node tools/build-job.mjs run --target <vm> --script relay/playbooks/first-share.ps1 with the playbook recording the six marks as RESULT lines; the collect job brings app/ladder.json back.

The playbook's RESULT lines

RESULT step=download start=<utc ms> end=<utc ms> bytes=<n>
RESULT step=install end=<utc ms>
RESULT step=setup end=<utc ms>
RESULT step=node end=<utc ms> synced_at=<ladder.first_synced_at>
RESULT step=card end=<utc ms> mining_at=<ladder.first_mining_at> first_block_at=<ladder.first_block_at> hash=<ladder.first_block_hash>
RESULT total_s=<end - download start> pass=<true|false>

A run without a first_block_at inside 1,800 s ends with pass=false and the step it stalled in. A Poisson miss is a fail too: an 8 GB card at 100 GH/s has a 46 percent chance inside the first hour (reinvent 1.4), so the claim is about the install and the node, and the card step is measured against the Poisson expectation from api/ladder.network.hashrate_hps and the card's rate (mining.hash_total); a run whose card step passed the expected gap by less than one gap is reported as "within expectation" beside the pass word.

What is published

/evidence gets one table: ten rows (card model, driver, the four step times, the total, pass), the median of each step, the pass count, the cut's version and the installer's sha256. The site lane owns the page; the shipper hands it the table as a JSON file (site/evidence/first-share-<version>.json) with the same keys as the RESULT lines.

Known holes

• Pool-0 is not built into the app yet (reinvent 3.5), so today the end mark is the first accepted block, not a share; the claim's words say "first share or block" until the pool field ships.
• SmartScreen (reinvent 3.1) adds two clicks the playbook must make; the time they take counts in the install step.
• A VM without a GPU passthrough measures the node steps only and is reported as such, not as a pass.