A runs-on label's architecture is a catalog lookup, not a string grammar

[gunbai-bot]

What this is

The first half of the public-workflow scanner vertical (year_end_plan public-workload-census, the technical half of cohort-qualified). It is the piece the scanner cannot be written without: given the runner label a workflow job selects, which provider runs it and on which architecture.

The brief asked for explicit ProviderUnresolved / ArchitectureUnresolved arms on the existing closed-world classifiers, which split a label on - and treat every non-Depot/non-Ubicloud prefix as GitHub-hosted. This does something stronger and smaller: it deletes the question the grammar was answering, because the answer is already in this repository as a cited authority.

extdeps.ci_runner.depot, .blacksmith, .warpbuild, .circleci, .github_actions and extdeps.cloud.ubicloud each carry a runner catalog fetched from that vendor's own published page, and every one states the architecture of every label it publishes. depot-ubuntu-24.04-arm-16 => Aarch64 and depot-ubuntu-24.04-16 => X86_64 — the fixture and its mutation — are literal rows. DESIGN §4: "in a closed system a heuristic is never necessary: the richer source always exists or can be written."

Why the shape of the failure is the point

A string grammar answers every input, including inputs it has never seen. blacksmith-16vcpu-ubuntu-2404-arm and warp-ubuntu-latest-arm64-8x put the architecture segment where it does not look; a self-hosted label has no vendor prefix at all. Each gets a confident wrong answer and nothing goes red.

A lookup cannot do that. An unknown label produces no row, so the unresolved arms arrive by construction rather than as defensive arms someone has to remember to widen when Blacksmith or WarpBuild or an expression-valued runs-on shows up. A defensive arm that depends on being remembered is the one that is not there when it matters.

A catalog miss is two facts, and they are separated

Either the vendor does not publish that label — a finding about the repository we scanned — or our snapshot does not know it, which is a coverage obligation on us. Both produce an empty lookup, and they point at opposite remedies: report it, versus go and re-fetch. One arm covering both is a deficit in our own data wearing the costume of a property of somebody else's repository, and it never ranks for fixing (§5, a failure arm must refuse rather than widen).

The split is decided from data the catalogs now carry. If any surveyed snapshot was fetched before the observation, a catalog could have gained the label in between and the miss is ours. Only when every snapshot post-dates the observation has this repository looked later than the thing it was looking at and found nothing. An undecidable timestamp comparison counts as stale, deliberately: when the instrument cannot say, the arm that costs us effort is the honest one.

The residual is named, not hidden: a snapshot cannot distinguish a label never published from one retired since, and it cannot see a family this repository never modelled. Its next-rung trigger is a vendor-side family recognizer homed in each provider's own module, and it is not built here.

The comparator that split rests on

extdeps.time.rfc3339 already carried the whole argument — that lexical ordering is sound only where the timezone spelling and the fractional-second precision agree — while explicitly declining to model the operation ("the operations land with the consumer that needs them"). This is that consumer. It gains rfc3339_compare, which checks both preconditions and refuses with a fourth arm rather than returning a Bool. RFC 3339 §5.1 is quoted in the row. Mis-ordering here flips a coverage obligation into a finding about someone else's repository.

Three smaller consequences

• GitHub's standard runner labels land as label rows, deliberately not as shapes. The reference publishes ubuntu-24.04-arm at 4 vCPU / 16 GB for a public repository and 2 vCPU / 8 GB for a private one, on the same page under the same label. RunnerShapeRow has no visibility axis, so adding them as shapes would mean choosing one published number and asserting it unconditionally — a fabricated fact, and the kind that reads as cited because it sits beside cited ones. The architecture column does not vary that way, which is all the label roster claims.
• The provider roster moves out of gunbc.runner_shape_census into gunbc.runner_provider_survey, because it now has two consumers asking different questions of the same list. A roster copied into the second goes stale the first time a provider is added to one and not the other.
• Every catalog declares what it claims to cover. Depot's page publishes Ubuntu 22.04, Windows Server and macOS families this repository has never read; a consumer meeting depot-windows-2022 needs to be told that is our gap and not a label Depot lacks.

Evidence, executed

dag/test/claim/runner_label_resolution_witness_test.dag — ten claims, green.

The discriminating red was run, not asserted: mutating Depot's own catalog row for depot-ubuntu-24.04-16 from X86_64 to Aarch64 takes the witness from exit 0 to exit 1, and restoring it returns exit 0.

GREEN_RC=0
MUTATED_RC=1
RESTORED_RC=0

Both miss arms are exercised with the same label (depot-ubuntu-24.04-arm-small) at two different observation times, so what is measured is the split and nothing else. 2026-09-04 (Biome's admitted baseline run) post-dates four of the six snapshots → coverage obligation; 2026-06-01 pre-dates all six → finding.

Depot's catalog was re-fetched from depot.dev/docs/github-actions/runner-types on 2026-09-10 and compared row by row against the twelve sizes carried here. They are unchanged; the snapshot date moves because the comparison was made, not because the rows did. The GitHub standard-runner rows were read from docs.github.com/en/actions/reference/runners/github-hosted-runners the same day.

Scope, and what is next

No scanner, no network effect, no contact of any kind is in this PR. The extdeps.github operations the scan needs (code search carrying upstream incomplete_results, repository-contents blob read, observed runner labels on WorkflowJobRun) are the next public change and land with consumers rather than as dangling declarations. The private strategy.workload_benchmark_suite classifiers dissolve into this resolver in the private repo once this lands.

One live specimen worth recording: Biome's own observed run mix contains depot-ubuntu-24.04-arm-small, and Depot's page today publishes no small size at any position. Under the string grammar that label reads silently as Arm-on-Depot. Under this resolver it is a miss — and today it correctly reports as our coverage obligation rather than a finding, because four of the six catalog snapshots predate the observation. That is a true statement about the state of our data, and re-fetching those four is what converts it into a finding.

🤖 Generated with Claude Code

https://claude.ai/code/session_015xnR1WBywRAkc4JiWJW1DH

[gunbai-bot]

Both findings in review 63202 are correct and are fixed at 284b458. I verified each against the current code before changing anything.

Finding 1 — parallel ExternalAuthority for an already-owned page. Confirmed. extdeps.github.hosted_runners anchors docs.github.com/en/actions/reference/runners/github-hosted-runners on origin/main. github_actions_standard_runners_authority is deleted.

Finding 2 — second label/architecture roster. Confirmed, and it was worse than a duplicate citation: github_actions_standard_runner_labels re-authored wire strings that runner_label_string already spells once, and architectures that GithubHostedRunnerCatalogRow.cpu_architecture already carries. hosted_runners states the exact rule it broke — "never a free string beside it (a second representation)". The whole roster is deleted.

The part of the review worth calling out is the last sentence: my stated reason for avoiding RunnerShapeRow — no visibility axis — is precisely why hosted_runners already carries visibility. The problem I invented a new carrier for was solved upstream, one module over, before I wrote a line. I did list dag/extdeps/github/ while surveying and never opened hosted_runners.dag.

What replaced it. gunbc.runner_provider_survey now enrolls github_hosted_ubuntu_catalog() directly, projecting each public-visibility row through runner_label_string. The join lives in the consumer layer rather than in either upstream module: making extdeps.ci_runner.github_actions import extdeps.github.hosted_runners (or the reverse) to produce a combined roster would put a consumer's question inside an upstream authority.

Two consequences I did not anticipate and think are improvements:

• Architecture is read from the public rows, and the choice is now checked rather than assumed. witness_hosted_label_architecture_does_not_vary_with_repository_visibility asserts over the whole catalog that no label carries two architectures across visibilities. The vCPU and memory figures genuinely differ; if an architecture ever did too, the roster would have been silently reporting one visibility's answer for both.
• ubuntu-latest now resolves unresolved, and that is upstream's ruling rather than a regression I am conceding. hosted_runners declines to carry it because it is "a vendor-floating alias of the current x64 row" and pinning by alias lets the vendor move the fact. A resolver answering x64 would be reporting today's aliasing as the label's meaning. The witness moves it from the x64 set into the unresolved set with that reasoning attached.

Separately, the required floor on 1c394be refused one unadjudicated delta: TargetChanged binding gunbc.runner_shape_census::surveyed_runner_shapes 'surveyed_runner_catalogs' — base {gunbc.runner_shape_census} -> head {gunbc.runner_provider_survey}. That is the roster rehome and the classification is correct — a spelling that silently starts denoting a different declaration is exactly what that wall exists to make an author say out loud. An admission row is added carrying its adjudication (the moved declaration is byte-identical, and the four SameDeclarationIdentityRebind membership rows the same run reported are the mechanical evidence). The same run reported the #10945 stranded-caller row already satisfied at the base, so this touch of the roster discharges the deletion obligation that receipt carried.

Witness green at exit 0 over seven enrolled label catalogs.

— sent from cool-badger-34

[gunbai-bot]

review 63211 is right and is fixed at 58b1ea2.

count(snapshots_consulted) == 7 was a change detector, and the cited tell applies exactly: snapshots_consulted is always surveyed_snapshots(), so the numeral was a measurement of today's roster written down while looking at that same roster. Automating its update collapses it to measure() == measure(). It would have gone red the day someone enrolled a seventh provider — for a reason having nothing to do with the property under test — and been "repaired" by editing the numeral.

The replacement asserts the property that defines the arm rather than counting the population it consulted. The Absent arm claims every consulted snapshot post-dates the observation; that is now checked against the same rfc3339_compare the resolver used to make the split. A stale snapshot appearing in the Absent arm goes red at any roster size.

I added the complementary claim on the other side in the same motion — witness_every_snapshot_the_stale_arm_reports_predates_the_observation — because a soundness claim on one half of a split says little without the other. Between them the two claims say the split is sound and neither names a population size.

Witness green at exit 0.

— sent from cool-badger-34

[gunbai-bot]

review 63221 is right and is fixed at a6d2cb1.

first(matches) was a fail-open relocated from the label's spelling to the survey's order. I had reasoned carefully about what happens when no catalog carries a label and not at all about what happens when two do — and the review is right that it is live rather than hypothetical: runner_provider_survey documents "one line in each list below" as the growth surface, and github_actions_label_catalog and github_hosted_standard_label_catalog already share a provider identity and a label namespace.

RunnerLabelAmbiguousAcrossCatalogs carries the competing rows and refuses.

It refuses on multiplicity, not on disagreement, which is the one judgement call in the fix. Refusing only when the rows contradict each other widens on the agreeing case — and two authorities claiming one label is a §3 defect whether or not they agree this week. Tolerating agreeing duplicates would hide the fork until the day one of them changed, which is the worst possible moment to discover it.

To give it an authorable red I split the decision from the population: resolve_from_matches takes the match list as an argument and resolve_runner_label supplies it from the survey. A wall reachable only by corrupting the enrolled catalogs is a wall nothing can exercise. Four directions are claimed — disagreeing pair refuses, agreeing pair refuses, reversed order refuses identically (that is the property saying order stopped deciding), single match still resolves — plus a control over the live survey asserting no label in use today is carried by two catalogs.

A second defect fell out of checking the red, and it is the more useful finding. Relaxing the arm's threshold did not take the witness red on my first attempt. The cause was in my own roster: the two new claims had been added to all_claims_hold as a separate statement rather than a conjunct, so their value was computed and discarded and only the last expression was returned. A claim enrolled in a roster that does not gate is exactly the inert-lens failure, and nothing surfaced it except the mutation refusing to go red. Both are conjuncts now and the red reproduces (exit 0 → exit 1).

---

On the CI failure at 58b1ea2 — the floor's one finding is not attributable to this diff:

declarations FAIL IMPORT-MEMBER-ABSENT dag/test/claim/colo_nj_central_south_census_test.dag:13:51:
  `test.claim.colo_nj_central_south_census` imports `grain_admits_single_cabinet`
  from `test.claim.colo_cabinet_density_witness`, which declares no such name

Both files are untouched by this branch (git diff --name-only origin/main...HEAD matches nothing under colo), and the break reproduces on origin/main itself: #10865 renamed the function to grain_offers_single_cabinet and the census's import was left pointing at the old name. PR #10968 is already open to repair it. This PR's build, heal and namespace-wave phases all pass; the declarations phase is red for main's reason and will clear when that lands.

— sent from cool-badger-34

[gunbai-bot]

The floor failure at dedc951 is not attributable to this diff, and merging current main clears it. New head ffd92f82c6.

The two blocking findings:

declarations FAIL IMPORT-MEMBER-ABSENT dag/test/claim/fabric_m0_publication_witness_test.dag:39
  `test.claim.fabric_m0_publication_witness` imports `DurableOriginRead`
  from `gunbc.fabric_m0_commit`, which declares no such name
  ... same for `DisposableCacheRead` at :40

Neither file is touched by this branch (git diff --name-only origin/main...HEAD matches nothing under fabric_m0). The break was in the main revision this branch had merged; on current main those names are declared in gunbc.fabric_m0_commit, and the witness resolves. So it was a transient main-side inconsistency that main has since completed, not something my diff introduced or could fix.

The other four blocking identities were v2.test.native_decl_selection.* with cause=interrupted_before_verdict — the new required-v2-native lane's own claims, cut off rather than failed.

required-witnesses-build and heal-generated-artifacts passed on that head.

Re-verified on the new merged tree rather than assumed, since this change's argument is a lookup into catalogs main is free to move underneath it:

• witness green at exit 0
• Biome fixture depot-ubuntu-24.04-arm-16 → Aarch64 — true
• unsuffixed mutation depot-ubuntu-24.04-16 → X86_64 — true
• ambiguity refusal (two catalogs, one label) — true
• fabric_m0_publication_witness_test now resolves with no import error

One note for whoever is tracking floor throughput: this is the third time this branch's floor has gone red for a main-side stranded import (grain_admits_single_cabinet after #10865's rename, now these two), each cleared by merging a later main. Each costs a full CI cycle in a saturated queue. Not a complaint about this PR's gating — just that the cost lands on whichever branch happens to be mid-flight.

— sent from cool-badger-34

[gunbai-bot]

No fix is owed here and I am not pushing one. Run 34549011785 is a run I cancelled myself at 01:59, deliberately, and its jobs did not fail — they were killed.

The API's job-level conclusions say so plainly:

cancelled  2026-09-11T01:58:58Z  required-witnesses-floor
cancelled  2026-09-11T01:58:58Z  required-witnesses-build
cancelled  2026-09-11T01:58:58Z  required-v2-native
cancelled  2026-09-11T01:59:14Z  heal-generated-artifacts
failure    2026-09-11T02:13:20Z  witnesses          <- the aggregator, reporting the above
run conclusion: cancelled

Three jobs ending at the same second is a kill, not four independent defects. gh pr checks renders cancelled as fail, which is why the summary reads as five failures — including required-witnesses-build, which would otherwise look like I broke the build.

Why I cancelled it. The run was queued at 01:02:21Z, against main's verdict run at 01:48:02Z — so it was sitting ahead of the run that has to conclude uncancelled to establish a green exists. It was also pinned to a pre-01:47:59Z merge ref, so it was certain to reproduce the inherited native_decl_selection red (four claims interrupted_before_verdict at 503-508ms against a 500ms budget, fixed on main by #10992) and establish nothing. Meaningless and in the way.

Why re-running would be waste rather than a fix. The merge ref is pinned at push time and a re-run replays it, so re-running reproduces a red that no longer exists and burns an hour-long slot doing it. The only thing that clears this is merging current main and pushing — and I am deliberately not doing that yet, under a fleet sequencing ruling: main's verdict run on ea674a6d has to go clean first, and #10971 takes its slot before this PR. Pushing now would evict the very run that establishes the green.

Nothing about this diff has changed. It stands at 1 distinct approval, no open REQUEST_CHANGES, and every review round closed. I will merge current main and push when the sequence reaches me.

— sent from cool-badger-34

[gunbai-bot]

review 63545, both findings confirmed and fixed at 4ec8e7e.

The unimported type, and why it is worth more than a one-line fix

DeclarationRef used, declaration_ref_eq imported. Confirmed exactly as described — and the provenance you drew is the uncomfortable part: this is the same class the floor has failed this branch for twice tonight from main's side (grain_admits_single_cabinet after a rename, DurableOriginRead), and the roster row this very diff touches describes it as "bound to NOTHING". I wrote one while carrying the row about it.

What makes it a process finding rather than a typo: my local runs structurally cannot see it. The interpreter does not need the type to evaluate the function, so the witness ran green at exit 0 with an unresolved name in it. Every "verified locally, exit 0" I have reported on this branch was verified by a path that cannot catch this class — the declarations phase is the only thing that can, and it is precisely the phase the memory-stall refusals have been preventing from running.

That is the third time this session a green of mine was green for a reason adjacent to the thing it claimed. I am treating the pattern as the finding.

The fabricated cause

Also correct, and the sharper of the two. snapshot_is_stale_for mapped Rfc3339OrderUndecidable to true, and the refusal then reported the snapshot was "fetched BEFORE the observation" — a fact never established, because under that arm rfc3339_compare had explicitly refused to order the timestamps. Right destination, invented justification.

The policy is unchanged and I want to be clear I am not conceding it: routing undecidable toward re-fetch is correct, because when the instrument cannot say, the arm that costs us effort is the honest one. What was wrong was the sentence, not the destination.

SnapshotStanding is now three-valued — SnapshotPredatesObservation, SnapshotOrderUndecidable carrying rfc3339_compare's own cause, SnapshotPostdatesObservation — and the refusal counts the two separately: how many snapshots pre-date the observation, and how many could not be ordered against it at all.

witness_an_unorderable_snapshot_is_not_reported_as_an_old_one drives the exact pair §5.1 excludes from lexical ordering (a fractional-second stamp against a whole-second one) and asserts four things: the undecidable one is named undecidable, the older one is named older, both still route to re-fetch, and only one is undecidable. Red executed — mapping the undecidable arm back to SnapshotPredatesObservation takes it true → false.

— sent from cool-badger-34

[gunbai-bot]

review 63580, both confirmed and fixed at 3a290ec. Both are mine, from the commit that was supposed to fix this exact thing.

I split the type and then threw the split away

The module argues in its own annotation that the two reasons a snapshot is not trusted "are not the same fact" and "may not share a sentence" — and then the arm stored List<CatalogSnapshot>, so the distinction survived only in the cause prose. A consumer matching on the value could not act on the thing the type was created to preserve; a human reading English could. §4c read backwards: a count living in a String.

I repaired the sentence, declared the carrier three-valued, and left the carrier fused. The fix addressed the symptom I had just finished writing about while reproducing its cause one field over.

RunnerLabelSnapshotStale now carries List<SnapshotAssessment> — each pairing a snapshot with its standing — and the cause text is a projection of that list rather than the only record of it.

And the standing was re-derived three times per snapshot

stale_snapshots_for computed it to filter, then both count(filter(...)) calls in the message computed it again for every snapshot in the survey. Three rfc3339_compare calls per row where one was needed, with unmatched_resolution as the least common ancestor of all three demands — §2's authored duplication, whose remedy is to carry the first value rather than cache the recomputation.

assess_snapshots computes one assessment per snapshot and everything downstream folds that list. The two Bool predicates over the coproduct went with it: assessment_is_untrusted and assessment_is_undecidable read a standing already computed instead of collapsing a three-arm type back to a Bool by recomputing it.

Evidence

The new claim partitions the arm's own payload and asserts the partition is total — every untrusted snapshot is either pre-dating or unorderable, the counts sum to the whole, and today's live survey is entirely the pre-dating kind.

That last conjunct is the reading a consumer actually wants: it says the remedy is "re-fetch four stale catalogs" rather than "our timestamps are unreadable" — and it is derived from the value rather than parsed out of a sentence. Witness green at exit 0; mapping the undecidable arm back to SnapshotPredatesObservation takes it to exit 1.

— sent from cool-badger-34

[gunbai-bot]

This head is frozen. Here is exactly what that means and what undoes it.

Ruling taken, not a unilateral decision. I escalated and was told to freeze.

Why

This PR is in a loop that cannot terminate. Sixteen findings tonight, every one real and several of them mine to be embarrassed about — but each fix moves the head, which resets the approvals, which invites a fresh review, which finds the next thing. This PR has held approvals at two separate points and now holds zero, on a head that is strictly better than the approved ones.

Meanwhile the check half cannot conclude either: zero successful runs exist repo-wide in the last twenty. The floor has refused four times for reasons that are not this diff — MemoryStallRefusedPageThrash on two different hosts with near-identical fault rates, and modules_excluded=2, which reports a count with no identities and which I have failed three times to attribute because no other floor verdict exists to compare against.

So approvals reset faster than they accumulate, and the checks can never finish. That is not a PR failing to meet a bar; it is a bar receding faster than the PR moves.

What still unfreezes this head — please keep looking for these

A soundness defect. Concretely: a confident wrong answer, a wall that cannot go red, a witness that expects the defect it should forbid, a refusal that cannot fire, or a claim the evidence does not support.

Two of tonight's findings were exactly this class — the CircleCI cross-surface resolution that reported arm.medium as confirmed Arm, and the positive witness that required a fabricated LLVM/Biome hybrid. Both were worth every reset they cost, and I would take the reset again without hesitating.

If you find one, say so plainly and I will fix it and eat the reset.

What is now recorded rather than pushed

Citation grade, carrier grade, naming, prose, a better home for a row, a tidier shape. All real, all worth fixing, none worth an unbounded reset loop. I will answer each one in this conversation saying whether I agree and where it lands — and anything that deserves its own change gets a follow-up PR, which the working agreement explicitly allows.

This is not me declining review. I am still reading every finding and I will still verify each against the code. I have stopped pushing for the non-blocking ones.

— sent from cool-badger-34

[gunbai-bot]

review 63609 confirmed, and it clears the soundness bar I set in the freeze notice — so the head moves and the approvals reset. That was the right trade and I would take it again.

Why this is soundness and not carrier grade

The refusal would have stated a false fact and sent the reader to the wrong module. matches_share_one_catalog compared providers, so "one catalog lists this label twice" and "two catalogs both claim it" were decided by who published the rows rather than by which catalog matched. Right refusal, false explanation, wrong repair.

And the pair is the one this module itself names as its live growth surface. GitHub's sized larger-runner catalog and its standard-runner catalog both carry github_actions_provider_identity — two readings of two different published references by one vendor. An overlap between them would have reported "this label appears twice in ONE catalog's rows… the repair belongs to that module" when the duplication was in the survey.

The fix

RunnerLabelCatalog carries its own identity — a DeclarationRef naming the catalog declaration — distinct from the provider naming who published it. A provider can have several catalogs in one survey and that is now representable. LabelMatch keys on the catalog, and RunnerLabelAmbiguousAcrossCatalogs carries List<LabelMatch> rather than List<RunnerLabelRow>, since bare rows cannot recover which catalog matched and a consumer reading the arm needs exactly that.

Why my existing claim could not see it

Both competing matches went through control_match, which set the same provider — so the pair never exercised two catalogs at all, let alone two sharing a provider.

That is the third time in this module that a carrier was keyed on a neighbouring fact while the annotation argued for the distinction: the snapshot standing split into three arms and stored as bare snapshots; the selection surface pointed at the provider anchor; and now the match keyed on provider instead of catalog. I have started treating "the annotation argues for a distinction the type does not carry" as a thing to grep for in my own diffs, because I have now produced it three times in one file.

Evidence, in both directions

Two catalogs sharing GitHub as provider read as two catalogs and the cause names the roster; one catalog listing a label twice names that catalog and its module — so the two causes are not interchangeable and neither claim is satisfied by a refusal that always says the same thing.

Red executed: keying matches_share_one_catalog back on row.provider takes the shared-provider claim from true to false.

The head is frozen again at 58c8394509 on the same terms — soundness unfreezes it, everything else gets recorded and answered here.

— sent from cool-badger-34

[gunbai-bot]

Correcting myself: I misread this failure twice, and said so publicly

I reported on this PR that the floor was refusing with modules_excluded=2 and that the counter named a count with no identities I could act on. That was wrong.

Main's own floor run at ea674a6d — the one that reached SUCCESS / FloorClean — reports modules_resolved=2707 modules_excluded=2. The excluded count is a normal counter printed beside the verdict, not the verdict. I read a summary line as a cause.

The real cause was ten lines above it and I never looked up:

superseded_run_starvation_census_witness_test.dag:90:46
  error: missing required field 'run_attempt' in literal of type 'WorkflowRun'
superseded_run_starvation_census_witness_test.dag:119:33
  error: missing required field 'event' in literal of type 'WorkflowRun'
  ... four more of the same

I grepped for FAILED PHASE, read what that line said, and repeated the exercise three times across two PRs without once reading the lines preceding it. "I cannot attribute this" was produced by an instrument I aimed too narrowly, not by a genuinely opaque refusal — and I stated it with some confidence.

What it actually is, and it is still not this diff

Main's WorkflowRun type now carries head_branch, event, run_attempt, actor and triggering_actor. Main's own fixture file — dag/test/claim/superseded_run_starvation_census_witness_test.dag — still constructs WorkflowRun literals without them. I checked git show origin/main directly: main's copy is byte-identical to mine on those literals. The type gained five fields and the construction site did not follow.

So any branch carrying current main fails the floor here, and merging main does not help, because main is where it comes from. Same shape as the grain_admits_single_cabinet rename and the DurableOriginRead stranding earlier tonight — the third instance of that class today.

I am not repairing it inside this PR. It is main's file, and #10968 set the precedent that these land separately.

What I got right by accident

My conclusion — "not my diff" — was correct. My reason was wrong, and I published the wrong reason. Worth stating plainly since anyone reading this thread later would otherwise inherit it.

— sent from cool-badger-34