Repository navigation
Unenrol the six samsung_dram_module rows that now pass — and keep the three that threw - #8980
Merged
Merged
Conversation
… nine in the chunk The floor reports these six as STALE-QUARANTINE: enrolled as expected-red and PASSED, so the roster row is a debt that was repaid and never recorded. row_axes_match_the_labelled_module_organization capacity_is_thirty_two_gibibytes generation_is_ddr4 manufacturer_grounds_on_the_single_vendor_authority organization_derives_eighteen_dies_per_rank required_die_density_derives_four_gigabit THE OTHER THREE IN THE SAME CHUNK STAY ENROLLED, and that is the whole subtlety of this change: four_rank_by_four_is_realizable_on_ddr4 same_capacity_at_one_rank_by_eight_is_not_realizable generation_mismatch_fails_closed They did not pass. They THREW — `no such function: ddr4_generation_catalog` / `ddr5_generation_catalog` — so they never reached a verdict at all. Unenrolling a throwing row does not clean anything up: it converts a row the floor holds into a row the floor fails, which is redder, not cleaner. They become stale rows when the import-closure defect that makes them throw is repaired, and that is when they should be removed. Run them directly under claim_batch and all nine pass, which is why this looked for a while like the floor's six was wrong. It is not: the three pass with the full corpus loaded and throw under the floor's import-stripped corpus, which is the documented mechanism cli_run.rs already names — "typecheck resolved a name through the census while the interpreter never loaded its body". The direct run and the floor disagree for a reason that is written down. ENROLMENT ONLY — no witness is touched. A probe that greens when its wall lands becomes a permanent regression control; it does not retire. All six keep executing, they simply stop being predicted to fail. Roster 212 -> 206. WHY THESE WERE INVISIBLE UNTIL NOW: every non-verdict outcome counted as `known-red held`, so a repaid row and a rotted row were the same number. The de-collapse in gunbc#8959 is what separated them; this is the first population that separation surfaced.
This was referenced Aug 23, 2026
This was referenced Aug 23, 2026
Merged
briansrls
pushed a commit
that referenced
this pull request
Aug 23, 2026
… annotation grain (#8995) The sweep behind `v1_src_dag_parse` and `--required-ci`'s phase 1 walked `src/v1` alone -- 56 files -- while the 3831 authored `.dag` files under `dag/` and `src/v2` had no parse-grain check cheaper than the required floor. It also called `tokenize` + `parse`, which does not decide source-annotation grain at all: `tokenize` routes `//` blocks into the annotation channel as unbound captures and `admit_source_annotations` decides attachment later, so a §4c defect returned `error: None`. MEASURED both ways: planting an in-body `//` in `dag/std/algebra.dag` and in `src/v2/std/node.dag` left the old walk reporting both trees parse-clean. The floor refused the same files during STRICT PREPARATION, where no witness executes, so one misplaced comment reported as the whole corpus saying nothing. Three lanes hit that in one night. The walk now takes its roots as a parameter, over one shared roster (`v1_compiler.cli_run` `DAG_PARSE_SWEEP_ROOTS` = src/v1, dag, src/v2) so the standalone bin and the required phase cannot disagree about their subject, and each file goes through `parse_census_fill_sources` -- the frontend's own per-source form, which tokenizes, parses in an occurrence scope and admits annotations, returning parse diagnostics and annotation refusals as one population. Called with a single source, so files stay independent and nothing resolves across them. THIS IS NOT A WIDENING OF THE FLOOR'S SOURCE ROOTS, which `gunbc.ci_layer_roots` `v1_dead_witness_tree_triage_receipt_remainder` rules out: that blocker is NAME RESOLUTION (src/v1 and src/v2 collide on twelve last segments, so a shared pool re-binds bare cross-module references). This walk resolves nothing. The empty-walk refusal is now PER ROOT: a root that goes missing must not be absorbed by another root's files. EVIDENCE, by execution, on the built binary: - green: 3882 file(s) parse-clean, 1.9s -> 9.7s wall - red, in-body `//` planted in `dag/std/algebra.dag` and `src/v2/std/node.dag`: both refused with "sits inside a declaration body"; restored -> green - red, trailing `//` appended to `src/v1/annotation_bind.dag`: refused with "names no subject"; restored -> green - red, malformed `fn broken( {`: refused, exit 1 Both §4c wordings are covered, so a grep tuned to one no longer misses the other. AND IT FOUND A LIVE ONE ON MAIN, which is the receipt that this was not a theoretical gap: `dag/test/claim/build_cache_endpoint_observe_test.dag` carries a four-line `//` block inside a `match` arm, landed in #8980. Hoisted above the `test fn` it describes; that hoist is in this diff, because the sweep is red until it lands and there is no reason to leave a floor-killing defect standing while opening the PR that detects it. The bin keeps its name: `v1_src_dag_parse` is now narrower than its subject, and that is declared in the bin rather than quietly lived with -- the name is a member of `gunbc.ci_release_bins` `witness_declared_release_bins`, from which `.github/workflows/fleet-converge.yml` is GENERATED, so renaming is a regeneration and bundling one into a coverage fix is how a generated artifact drifts from its authority. Rename trigger recorded on the bin. Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The floor reports six
samsung_dram_modulerows as STALE-QUARANTINE — enrolled as expected-red and passing, so each roster row is a debt that was repaid and never recorded.Roster 212 → 206. Enrolment only — no witness is touched. All six keep executing; they simply stop being predicted to fail. A probe that greens when its wall lands becomes a permanent regression control, it does not retire.
Six, not the nine in the chunk — this is the whole subtlety
The same chunk holds three more rows that are not removed:
They did not pass. They threw —
no such function: ddr4_generation_catalog/ddr5_generation_catalog— so they never reached a verdict at all. Unenrolling a throwing row cleans nothing up: it converts a row the floor holds into a row the floor fails. Redder, not cleaner. They become stale rows when the import-closure defect that makes them throw is repaired, and that is when they should go.Why this looked wrong for a while
Run all nine directly under
claim_batchagainst clean main and you get 9/9 PASS, which reads as "the floor's six is wrong". It is not. The three pass with the full corpus loaded and throw under the floor's import-stripped corpus — the mechanismcli_run.rsalready documents:The direct run and the floor disagree for a reason that is written down, so the disagreement is evidence about the closure, not about the roster.
Why these were invisible until now
Every non-verdict outcome counted as
known-red held, so a repaid row and a rotted row were the same number. The de-collapse in #8959 is what separated them; this is the first population that separation surfaced.Expected CI state
Main currently fails on causes unrelated to this diff: nine witness failures whose identities all sit in the three files
96cb3628566(the 64 GiB DIMM model) modified, and — since #8909 merged — aTerminalLedgerUnrenderablerefusal that #8959 repairs. This PR clears the stale-quarantine cause only. Judge it on the STALE-QUARANTINE count going to zero.