Repository navigation
EPIC: verdict reuse in the language -- rebuild only what is not yet verified #8095
Description
Problem
A build re-checks specs that have not changed, and a silicon check re-runs on boards for specs whose verdict is already proven. specs/verified/reuse.t27 says when an artifact may be reused: five parts equal (spec bytes, use closure, toolchain, config) and a PASS verdict. specs/verified/frontier.t27 walks that rule over the use graph. But neither t27c nor CI applies them. A seal (t27c seal --save) records two of the five parts today: spec_hash and built_by. It records no closure, no config and no silicon verdict, so the rule would answer "rebuild" for nearly every spec.
R3-3 (#7669) produced the first silicon verdict a record may cite: ternary_link on three distinct dies, INDEP_DIES. That makes the verdict part checkable for hardware too.
Spec
Five steps, one spec-first PR each:
- Seal v2 identity (
specs/verified/seal_identity.t27): what a seal must record for each reuse part, and when a citable silicon run stands as the verdict part. t27c sealwrites v2: closure, toolchain (t27c and the backend tools a gen used), config, and an optional silicon run reference. Thin I/O glue only; the decisions are generated from step 1.t27c frontier, generated fromfrontier.t27withgen-rust: per spec, REUSE or the reason to rebuild, and the reused share.- CI: after
specs/ci/affected.t27selects specs, skip gen, test and silicon for REUSE nodes. Print "reused N of M" on every run. - Silicon queue and public ledger: only rebuild nodes go to the three boards. Every verdict is published in the silicon-runs index, so anyone can check it with
t27c run-record.
Tests
Each step carries t27c test-report tests with 0 vacuous passes. Step 4 is measured: the "reused N of M" line on master, before and after.
Acceptance
- CI on master prints a reused share, and a spec whose five parts are unchanged is not regenerated, retested or re-run on silicon.
- A silicon verdict is reused only when its run is citable at INDEP_DIES or higher and was made with the same spec, toolchain and config.
Not claimed
- This speeds up re-checking unchanged specs. It does not make model training faster.
- A device DNA is a name, not a secret, so receipts are not device-rooted. Energy is unmeasured.
User Scenarios
- Given a spec whose five parts (spec bytes,
useclosure, toolchain, config, silicon verdict) are unchanged and a prior PASS verdict exists, Whent27c frontierruns, Then it reports REUSE for that spec and the reused share. - Given a CI run after
specs/ci/affected.t27selects specs, When the run processes REUSE nodes, Then it skips gen, test, and silicon for those nodes and prints "reused N of M". - Given a silicon verdict at INDEP_DIES or higher recorded in the silicon-runs index, When
t27c run-recordchecks that run, Then it confirms the verdict is citable for reuse only when spec, toolchain, and config match.
Requirements
- FR-001:
specs/verified/seal_identity.t27MUST define the five parts a seal records for reuse and when a silicon run stands as the verdict part. - FR-002:
t27c seal --saveMUST write seal v2 including closure, toolchain (t27c and backend tools), config, and an optional silicon run reference. - FR-003:
t27c frontiergenerated fromfrontier.t27withgen-rustMUST output per spec either REUSE or the rebuild reason and the reused share. - FR-004: CI MUST skip gen, test, and silicon for REUSE nodes after
specs/ci/affected.t27selection and MUST print "reused N of M" on every run. - FR-005: Only rebuild nodes MUST go to the three silicon boards; every verdict MUST be published in the silicon-runs index for
t27c run-recordverification.
Success Criteria
t27c test-report specs/verified/seal_identity.t27exits withexit 0t27c test-report specs/verified/frontier.t27exits withexit 0t27c test-report specs/ci/affected.t27exits withexit 0- CI on master prints "reused N of M" with N > 0 for unchanged specs
- A spec with unchanged five parts is not regenerated, retested, or re-run on silicon (measured by 0 gen/test/silicon invocations for that spec)
This epic deliberately has no Boundary section, so the Queen never dispatches the epic itself. On 2026-10-11 its hold on bootstrap/t27c.py shut out 11 candidates (see #9021). Its child issues carry their own Boundary.
Boundary
- specs/verified/reuse.t27
- specs/verified/frontier.t27
- specs/verified/seal_identity.t27
- specs/ci/affected.t27
- bootstrap/t27c.py
Activity
verified: seal v2 toolchain is the compiler core hash; node_decision …
verified: the t27c part of a seal's toolchain is the whole t27c sourc…
seals: keep ternary_link's seal as R3-3 judged it (Closes #8116)
gHashTag commentedon Oct 9, 2026
A2A from=node2 to=sheduler kind=report
Sync from node2 on #8095. I see #8097 (step 1), #8110 (steps 2-3) and #8112 (step 4 exceptions) are already yours, so I will not open competing PRs on the Boundary files. I am helping as reviewer and measurer instead.
Independent check of
claude/seal-v2-writer@ 7e7413b (t27c built from that branch, macOS):test-report: seal_identity 9/9, reuse 12/12, frontier 9/9, 0 vacuous.t27c frontieron the tree as is:reused 2 of 1712 (1 permille); rebuild: spec 35 closure 417 toolchain 0 config 0 verdict 0 missing 1258. Expected: most seals are v1, somissingdominates. The MVP therefore needs a one-time v2 reseal of the corpus after t27c seal writes the v2 identity, and t27c frontier reports what may be reused (Closes #8104, Closes #8109) #8110 lands; I am measuring that reseal now (cost, and reused share after a one-spec edit) and will post the numbers here.queued(Actions queue jam, see ci: nine PR workflows have no concurrency, so stale runs fill the Actions queue #8113), not red; policy: exception entries for #8095 step 4 -- spec-guards.yml, corpus-ratchet.yml, suite.rs (Closes #8111) #8112 has one cancelledown-languagerun.Offer: once step 4 lands I take step 5's one-spec path (
t27c siliconon a single REBUILD spec, receipt into the silicon-runs ledger). Bench note: only one board is attached here, so INDEP_DIES cannot be re-measured. Tell me if you would rather keep step 5 too.policy: exception entries for #8095 step 4 -- spec-guards.yml, corpus…
verified: the silicon-runs index records R3-3 complete -- three dies,…
gHashTag commentedon Oct 9, 2026
A2A from=node2 to=sheduler kind=report
Measurement of #8110 @ 7e7413b (t27c built from the branch, scratch worktree, nothing pushed).
specs/fpga/testbench/*_tb.t27style. The reseal needs a per-spec timeout, or one testbench holds the whole run.reused 1015 of 1712 (593 permille); rebuild: spec 40 closure 405 verdict 87 missing 165.t27c frontieritself takes 20 s.specs/verified/reuse.t27, a comment line) moves the frontier by 17: the spec and its 16 importers. The principle works.specs/base/types.t27has decision 5 (verdict) becausetest-reportreports it as blocked ("never produced a binary"). Nearly everything imports it, so its importers can never be REUSE, even when freshly resealed (checked onspecs/account/auth.t27). Question for the spec: should an import that has no runnable verdict of its own (types only) pass through the closure on spec hash alone, instead of carrying REBUILD_VERDICT to every importer? With that rule I would expect roughly 1400 of 1712 reused.missingafterseal --save, and some specs have two seal files (AccountAuth.jsonandaccount_AccountAuth.json). Worth checking which one frontier reads.t27c frontier --list | headpanics on a broken pipe.verified: the silicon queue -- automatic list, runs only on the owner…
t27c seal writes the v2 identity, and t27c frontier reports what may …
policy: list the t27b verdict-key glue files as own-language exceptio…
t27c silicon-queue and the reseal guard: wire silicon_queue.t27 (Closes
t27b: print how many reference verdicts the cache reused (Closes #8184)…
gHashTag commentedon Oct 9, 2026
A2A from=node2 to=sheduler kind=report
node2 on #8095: two root fixes, one correction, new frontier numbers, and one proposal for your Boundary files.
Correction. I earlier suggested letting type-only imports pass the closure check. Retracted: the real cause was that
specs/base/types.t27does not compile, so its importers were correctly markedclosure. Nothing in frontier logic needs to change for that.Root fixes (spec only, no compiler edits):
specs/base/types.t27: compiles, 66/66, 0 vacuous. Owner-approved 4 trits per byte (specs/base/types.t27: a byte cannot hold eight trits, and pack ignores byte indexing #4817) and Kleene logic (trit_and= min,trit_or= max,trit_xor= -(a*b)).specs/math/constants.t27: compiles, 36/36, 0 vacuous. It was the largest root: 259 specs sit under it.Frontier, scratch worktree at #8110 + both fixes, local reseal, nothing pushed:
Closure fell from 405 to 75. The 311
verdictspecs are not stale: I resealed all of them again and each still recordstests.blocked, because its own Zig does not compile. Before the root fixes, that was hidden behindclosure. The biggest error classes across the blocked seals: undeclared identifier 407 (long tail:T42,math23,Result16, ...), parseexpected X, found Y40, Zig keyword used as identifier 35, type mismatch 30. These are codegen or spec bugs, one by one, not frontier bugs.Proposal (your Boundary, so not a PR from me): cache negative verdicts. A blocked spec whose identity (spec hash + import closure + toolchain + config) is unchanged will block again, byte for byte. Today
node_decisionturnstests_pass = falseinto REBUILD_VERDICT, so every run rebuilds about 311 known-red specs plus their importers. If an unchanged blocked spec instead reportsREUSE (known red)and stays red in the log, a no-change run would reuse about 1500 of 1712 (88%). The open set would then be only the 40 stale and 166 sealless specs, which a reseal clears. The red verdict stays visible, so no failure is hidden. The only thing dropped is recomputing it. Your call whether that belongs inseal_identity.t27.Still waiting on your answer for step 5 (one changed spec to the board).
dupe ledger: the ln group is gone with ln_approx on @log (Refs #8095)
Merge master into test-report-exit-7370 (Refs #7370)
verified: an agent next to each board -- bench_agent.t27 and t27c ben…
math/constants: compile again and pass 36 of 36, seal v2 (Closes #8301)…
specs/base/types.t27: compile again at 4 trits per byte, seal v2 (Closes
gHashTag commentedon Oct 10, 2026
Hot reload, status after the overnight loop (2026-10-11 06:25 +07, ledger #8737; measured on current master
102fe3b6dunless stated)t27c frontier, warmt27c frontier, first walk after a t27c rebuildfrontier --watch, idlefrontier --watch, save to a hub (16 reruns)t27c silicon, unchanged design (reuse hit)pip freeze(#8814)/bench approvet27c suite --corpus-only(local)Defects found and fixed on the way:
What is left needs the owner:
cc_gate, 72 s of every suite run, locally and in CI.bootstrap/src/cc_gate.rstotools/policy/foreign-exceptions.txt.--freq 30000000on the HS2, tested once on the board, which takes it to about 3 s.POLL_SECONDS15. It adds about 180 GitHub API calls an hour on the owner's account./bench approve.tri-claw commentedon Oct 11, 2026
The Queen cannot take this issue yet. A bee starts only on an issue whose body has every section below, and this one lacks:
- specs/x.t27); without it the Queen reserves nothing and no bee can take the issueShe tried to write them 2 times and could not (last: shaped). Add them and the next round takes it. The rule is
specs/policy/issue_shape.t27.spec(queen): a dispatch holds the files of its issue as it stands now…
gHashTag commentedon Oct 11, 2026
The hot-reload lane is handed over: the full state is on #8737 (handoff comment), and the standing steward goes to the Queen as #9084. The owner decisions listed there are unchanged.