igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

release-0.3.20 plan: main accepts the wipe canary's clock

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 12:36:56 +00:00
parent 0ba41a50ab
commit 125e58711f
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/release-0.3.20.md
View file

@ -419,3 +419,5 @@ Speculative builds on the candidate from the ship worktree, box only, sequential
**The 3080 hour's number (the fleet, 12:33Z):** on thr-3080b (RTX 3080 10 GB, driver 570.211.01, the sm_86 server, p1-3080's own failed segment 163366..163373), at the DEFAULT SP1_GPU_ELEMENT_THRESHOLD the chain proof completes, rc 0, 66 s wall for the eight-block segment, device_used 8,642 MiB of 9,883 with nothing else on the card. p1-3080 fails because its miner holds about 1,547 MiB and 8,642 plus 1,547 passes 9,885 (its "free_mib=25" on every one of 29 failures). Per tier: a 10 GB card is a mine-only card OR a prove-only card, never both; the sentence "proving needs a 12 GB card; mining continues" is right for the default mine-and-prove install and stays; a 10 GB owner who wants to prove instead can, at the cost of the miner (box-prover's MINER=pause on the fleet; an app choice to route for 0.3.21). Lower thresholds reading now for whether the compressed step fits beside the miner's 1.5 GB; the number goes in the bench log with this sentence. The 610-driver host approved (one rent, the sm_86 server). Build-server lane: c4459193 as vendor/igneum-node-0320d, the sequence from 13:33 BST (hands, seed, the Windows cross of c4459193, then 6a3432a3's as the known-failed shape); the PC 2 kept-datadir job on those two exes.
**The wipe canary's clock (13:4x BST):** c18-1 is held by the 0.3.20 cases until about 14:00 BST, so a wipe canary on it would read synced about 15:40 BST, past the checkpoint. The shipper's call: the fleet rents a second one-shot pod of c18-1's class now and starts the wipe canary on c4459193's binary the moment its build lands (synced about 15:15 BST by the 98-minute class), with the kept read on the pool-1 0.3.17 copy and the restart step on that pod; c18-1 keeps the cases and the pool window. The wipe is the decisive read by rule (release-rules.md 3), so the pin never cuts without it and b7cc37e7's lineage does not stand in; a slip past 15:30 BST holds the pin to the wipe line and main hears the clock.
**Main (13:4x BST):** the clock change accepted as set: the wipe canary on the second rented pod is the decisive read, the pin follows its synced line, and a slip past 15:30 BST is reported as a clock, not cut on the other lines.