From 43eaab7ac72eae731437f7a9f8c672d7a8ea4384 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Wed, 7 Oct 2026 22:22:19 +0000 Subject: [PATCH] adv-accept report: ledger 23:22 BST, gap-deep4 holding cores on box 2 Co-Authored-By: Claude Fable 5.1 --- docs/analysis/cryptanalysis/report-acceptance-rule.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/analysis/cryptanalysis/report-acceptance-rule.md b/docs/analysis/cryptanalysis/report-acceptance-rule.md index 79300b490..566c1e29e 100644 --- a/docs/analysis/cryptanalysis/report-acceptance-rule.md +++ b/docs/analysis/cryptanalysis/report-acceptance-rule.md @@ -767,7 +767,12 @@ sweep-s00f, so s00f was ended (rows kept, frontier recorded; s00g re-queued) and Record: row 90's first half on box 2 (attempts-10k-a, 8,000 of 10,000 at 23:20) runs box 2's binary from before the pre-emption-safe change (that rebuild went to build-1 only), so it prints progress without the running totals and writes its rows at its end; it is minutes from done and is left to finish; box 2 is -rebuilt now for any later run. +rebuilt now for any later run (done 23:21 BST). + +23:22 BST, box 2: the freed cores went to my re-queued sweep-s08 rather than gap-deep4 (the pool's order +among adv waiters is not strictly by arrival), so every shard of mine on box 2 was ended or withdrawn +(s08 at 346 rows, frontier 800349) until gap-deep4 held its 8 cores, then the five shards re-queued from +their frontiers (s08 from 800349, s06c from 609791, s04b from 400603, s02e from 221880, s00g from 40822). ## Where the pass stands (for the 00:00 BST reading; numbers refreshed as rows land)