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

release-0.3.20 plan: the fallback pin 6b94c823 on the mirror

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 11:47:57 +00:00
parent 2095b32368
commit e0dca71eb5
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

@ -367,3 +367,5 @@ A second commit follows behind the gates: igneum_getFinalityKey, igneum_getProof
**Staging recipe (scratch r0319-app, 13:4x UK):** `digest-box.sh <igneumd on the box> <file|''> <port>` starts the binary on the box alone (no peers, own appdir) and prints "Consensus params digest: <hex>", killed by pid (the lost r0312/digest.sh replaced; the Mac builds and runs nothing). `stage-floor-file.sh <live daa> <igneumd on the box> <port>` writes ov16-floor-<floor>.json from the live sixteen-field object (floor = ceil((daa + 604,800) / 3,600) * 3,600, window untouched), prints the one-line diff and both digests. Dry run on the 0.3.17 binary at DAA 275,300: live eada4bda, moved floor 882,000 reads 844ebde1 (the moved digest is read again on the pinned binary at the publish). Not published.
**8097d600 alone is not a pin (the node lane's honesty line, 13:5x UK):** the whole finality test module on build-2 shows one red unit test on 8097d600, `the_template_answers_and_synced_reads_behind_while_the_catch_up_holds_the_state` (500ddd66's PC 1 rule test, line 37 asserting `behind` TRUE while the state is held, the expectation the isSynced ruling inverted); the code is right, the test is stale; on 8097d600 the lane had run the four new finality tests, consensus-core, kaspa-pow and the exec RPC suite, not the whole module. Shipper's word: the fallback pin is a one-line test-only commit directly on 8097d600 (behind false with the state held, the snapshot still answers), pushed as release-0.3.20-node, the second commit rebased on it without the test change; the whole module run on the fallback; the gate lines on the 8097d600 build carry to the fallback (byte-identical code, stated in the tip) but the pinned binary is rebuilt from the fallback commit for the commit-string read-back. No known-red pins.
**The fallback pin is on the mirror (14:0x UK): release-0.3.20-node = 6b94c823**, the test-only commit directly on 8097d600 (no code line touched; binaries byte-identical to 8097d600's; the two gate lines on the 8097d600 build carry to it, stated in the tip). The whole finality module runs on 6b94c823 from a clean worktree on build-2. The second commit (key methods, claims, settled floor, watchdog) lands as 6b94c823's child when its suites are green; both binaries rebuild on build-1 then (the fallback's for the read-back, the second commit's for the fleet's 12 GB line). The vendor worktree has the mirror branch fetched; the checkout happens at the pin.