The field my own change made required left seven fixtures behind, and nothing measured it

[gunbai-bot]

gunbc#9542 added capacity_class to ExecutionRequirements as a required field. Seven training witness fixtures construct that literal and were not updated, so main has not compiled its witness corpus since 18:18Z. This adds the field and its import to all seven — two lines per file.

How it reached main — the mechanism, not the incident

#9542 merged while main was broken by a duplicate-definition pair, so every run died at Build the witness fold before the floor executed. It was approved and landed without ever being measured. Approvals never established that it worked; nothing did.

The defect surfaced the first time a floor ran to completion on a repaired main (33209193747), which is also the first run tonight whose red carried any information about a diff.

Why the value is CustomerExecutableCapacity

Decided on the model, not on what compiles. product/fabric/work.dag defines control-plane capacity as the cells "running our own scheduler, reconciliation, admission and receipt work", and states directly:

WHAT THIS FIELD IS NOT: it is not the executor's class. It is what THIS WORK REQUIRES.

A training run is not our scheduler, reconciliation, admission or receipt work — it is the customer workload the fabric exists to execute.

The counter-observation, and why it does not apply

Every other constructor in the tree passes ControlPlaneCapacity, and a peer declined to fill these in on exactly that ground — suggestive, not evidence. That caution was right. It loses because those five are control-plane because their subjects are: fabric_selection, fabric_terminal_contract and fabric_witness_run all model our own machinery. So the pattern is evidence for reading the field semantically, not for copying its value.

Recorded because a later reader will find seven fixtures disagreeing with every other constructor in the tree, and without this it looks like a mistake.

The field is inert here

Measured per file rather than in aggregate: all seven reference capacity_class zero times. They assert readback, checkpoint, resolution and reconciliation — never admission. So this changes no assertion in any of them, which is what makes it mechanical rather than a modeling decision with teeth.

Evidence

compile dag/test/claim/training_readback_witness_test.dag
  before: missing required field 'capacity_class' in literal of type 'ExecutionRequirements'
  after:  0 blocking error(s), 0 remaining capacity_class errors

What this does NOT do

It removes 7 of the 18 located failures in run 33209193747. The floor stays red on four families I do not own and have not touched:

file	error
dag/extdeps/bmc/pid_control_program.dag (×4)	Measure<…> vs Product(ZoneDemandValue)
dag/gunbc/source_integration_landing_spine.dag	map unresolved on Optional, plus its frontier row count
dag/gunbc/live_deploy/repository_convergence_placement.dag	no parameter primary_path
dag/test/claim/fabric/fabric_terminal_contract_witness_test.dag	ExecutionGrant<String> declared vs ExecutionGrant<NonEmptyStr>

So #9598 still cannot go green, and neither can anything else. That last row is in the fabric tree and I checked it specifically: it is not in my diff, and I have not established whether #9542 caused it — so it needs whoever owns ExecutionGrant's parameterisation rather than a guess from me.

— sent from silent-bear-842

[gunbai-bot]

Measured on run 33211835142. The fix took, exactly and completely — and the number I put in this PR body was wrong, so I am correcting it in the same comment.

The located set, before and after, at identity grain

	error occurrences	distinct files
before (#9598 run 33209193747)	26	11
after (this PR, run 33211835142)	12	4

Cleared — exactly the seven this PR touches, and nothing else:

training_attempt_graph_witness_test.dag
training_checkpoint_witness_test.dag
training_execution_control_witness_test.dag
training_observation_cut_witness_test.dag
training_readback_witness_test.dag
training_reconciliation_witness_test.dag
training_resolution_witness_test.dag

New errors introduced: none. The set difference in the other direction is empty, so this diff cleared seven files and added nothing.

Correcting my own count

This PR body says "removes 7 of the 18 located failures." 18 was wrong. The true before-figure is 26 occurrences across 11 files — I had summed the families carelessly, counting each file once where the log reports every error twice (the floor compiles in two passes). The honest statement is:

26 → 12 occurrences, 11 → 4 files. This PR clears 14 occurrences across 7 files.

The error understated the total and therefore understated this fix's share (7 of 11 files, not 7 of 18 anything). I am correcting it because a wrong denominator in a PR body is the kind of figure a later reader quotes.

Why a red here is the evidence, not a consolation

A green check is impossible on this branch while four families I do not own remain on main, so a green would establish nothing — it would falsify my model of the floor, which compiles the corpus rather than the diff. The discriminating outcome is precisely this: red, with the located set dropped to 12 and my seven identities absent from it. That names what cleared instead of asserting a boolean, which is strictly more informative than a passing gate would have been.

What remains, and it is not mine

dag/extdeps/bmc/pid_control_program.dag                        x4
dag/gunbc/source_integration_landing_spine.dag                 x2 kinds
dag/gunbc/live_deploy/repository_convergence_placement.dag     x2
dag/test/claim/fabric/fabric_terminal_contract_witness_test.dag x2

These need rulings from owners who are not available — a Measure parameterisation, an ExecutionGrant type argument. I am deliberately not carrying them into this PR. gunbc#9634 combined two defects because they were byte-identical duplicates requiring no ruling; these require judgment, so combining them would not repeat #9634, it would repeat what #9634 avoided — swapping four loud breaks for four quiet wrong ones.

This PR is therefore merge-ready on evidence rather than on a check that cannot go green: discriminating RED is the pre-fix compile of the same entry, positive control is the post-fix compile at 0 blocking, and the corpus measurement above shows exactly the intended identities clearing with nothing introduced.

— sent from silent-bear-842

[gunbai-bot]

Reconciling the counts, and widening my own remaining-work figure — my previous comment measured one phase and read as if it covered main's whole debt.

Both figures were right about different sets

figure	what it counts
my 26	strict-preparation occurrences (13 unique, each reported twice — the floor compiles in two passes)
the 18 I called wrong	13 unique strict-prep + 5 declarations, across both phases

Neither is the other's denominator, which is why they never reconciled by inspection. 18 was not wrong — I retract that part of my correction. It was unique-failures-across-both-phases.

The reconciled measurement, both phases

	strict-prep occurrences	strict-prep unique	declarations
before (#9598 run 33209193747)	26	13	5
after (this PR, run 33211835142)	12	6	5

Verified in this PR's own log, which states it outright:

required-ci: FAILED PHASE declarations (5 finding(s))

Where my last comment narrowed

I reported "12 occurrences across 4 files" remaining. That is strict-preparation only. It omits the declarations phase entirely, and those five failures are still on main, still blocking, and this PR does not touch them:

annotation_carrier_witness_test.dag 52:3, 58:12, 63:12, 84:24
  cites `test.fixture.frontier`, declared by no module          x4  CITED-MODULE-ABSENT
FIXTURE_CARRIER_CITATION_EXEMPTIONS stale row                    x1  CITATION-DEBT-ROW-STALE

They run in an earlier phase than strict-preparation, which is exactly why a strict-prep-shaped read misses them — the phase that fails first is not the phase people read.

So the honest remaining statement is five families, not four: the four I named plus this citation family — 12 strict-prep occurrences plus 5 declarations findings.

What is unchanged

This PR still clears exactly the seven files it touches, with an empty set difference in the other direction — nothing introduced. The reconciliation corrects what remains, which was never this fix's denominator.

And the caveat stands verbatim, because it is the distinction most easily skipped: this establishes that the seven capacity_class compile refusals are gone. It does not establish that the seven witnesses pass. Strict preparation still refuses, so no witness executed and no floor verdict exists on this branch. A cleared compile error is not a passing test.

— sent from silent-bear-842