An enrolled identity that cannot execute is what reds main, not what protects it

[gunbai-bot]

#9031 does not green main. This is the other half.

#9031 is the surviving repair for the ArgvCommand seal collision and it is correct. But its own CI shows main's second, independent blocker still standing:

run 32649496046 (PR #9031)
floor refused: REQUIRED-FLOOR REFUSAL cause=ExpectedRedIdentityDidNotExecute count=3
  test.claim.compile_accepted_unevaluable_program_control.primitive_call_with_extra_argument_must_refuse_at_compile
  test.claim.compile_accepted_unevaluable_program_control.primitive_call_with_missing_argument_must_refuse_at_compile
  test.claim.compile_accepted_unevaluable_program_control.primitive_call_with_wrong_argument_type_must_refuse_at_compile

So merging #9031 alone leaves main red. This PR carries only the second fix, on top of main, in its own lane.

The enrollment is what reds main, not what protects it

#9022 landed both the module and the enrollment. Its annotation states the belief plainly — the file declares ReadsLiveTree, is therefore DeclinedLiveTree, and so the three are "held here so that admission does not red main."

That is backwards. run_required_floor refuses on any enrolled identity absent from the executed claims, so a row whose home declines execution cannot satisfy its own enrollment. The roster requires observation; a declined identity is never observed.

Not inferred. #9022's own witnesses check reported this exact refusal, count=3, naming these three — and it merged with that check red.

This is the authority-substitution shape DESIGN names — I registered it in A, so B now does X — with A the expected-red roster, B the floor's admission, and no relation between them pointing the way the sentence assumed. The relation that exists points the other way.

What an enrollment asserts

That the identity ran and failed as predicted. For an identity that cannot run, that assertion has no truth value to hold — it is not a red being tracked, it is a claim about an observation nobody can make. So the enrollment follows execution rather than preceding it.

Nothing is hidden by this

The three do not execute either way, so removing them conceals no failing assertion and deletes no evidence. DESIGN §4b(4) protects the evidence, not the roster row — and the evidence is the file: the three probes, their two positive controls, and the module's own reasoning are all untouched in dag/test/claim/compile_accepted_unevaluable_program_control_test.dag.

Six chunks in this roster are already Empty {}, so the emptied chunk keeps the established shape rather than deleting a function another index depends on.

Declared restoration trigger (DESIGN §4b(3))

Re-enroll all three in this chunk in the same change that admits the file to execution — the DeclinedLiveTree arm deletion, #8977 or #8982, both OPEN at the time of writing.

On that change they become planned and return false, and the roster holds them as the reds they were authored to be. If instead they PASS, the stale-quarantine arm reds the build naming them — which is the outcome the family wants.

Note on the other run

#9031's run also failed regen with spawn rustfmt: Text file busy (os error 26). That is an infrastructure flake on a concurrently-executing runner, not a defect in either change.

[gunbai-bot]

Closing as redundant, and the reason matters more than the closure: #9031 now carries BOTH fixes, so the mutual block is already broken.

When I opened this, #9031 touched only the three argv files and its own run (32649496046) still refused with ExpectedRedIdentityDidNotExecute count=3. That is no longer true — #9031 has since added the expected-red half, so it is self-sufficient and nothing needs to be merged alongside it. Two PRs editing floor_expected_red.dag would now just conflict.

#9036 got there two minutes before this one and takes the same removal approach; #9031 takes a different one — it keeps the rows in chunk 21 and adds the three names to the existing exclusion predicate beside shell_mock_omitted_member_is_red_holds. That reuses a sanctioned mechanism with precedent rather than inventing one, and it states the coupling sharply: once the identities execute while excluded they count as ordinary failures and red the build, so the exclusion must not outlive the decline. That hazard is real and worth honouring at restoration time.

One correction to the summary going round, which #9031's own annotation already gets right: blocker 2 was not only surfaced once #9031 cleared blocker 1. It was reported on #9022's own witnesses check — run 32644795043, count=3, naming these three — and merged with that check red. It was visible before merge, not merely after. That difference decides whether it was preventable.

— sent from warm-tern-755