ALERT-4: the falsifier alert's decision as a pure function over sixteen terminal arms

[gunbai-bot]

ALERT-4. The whole alert decision as one pure function — no GitHub calls, no clock read, no issue read. Every fact arrives as a parameter, so the arms hardest to reach in production are the cheapest to prove.

alert_decision(admission, receipt, observation, now, escalation, routings) -> AlertDecision, total over sixteen terminal arms, eight of them refusals.

Guard order is the algebra

Trust → escalation recipient → observer availability → receipt decodability → subject match → state readability → verdict.

Observer availability sits before the receipt deliberately: a run that timed out or failed at startup produced no receipt, so requiring one first reported "the floor's writer is broken" for the case where the floor never ran. Trust sits first because this program holds issue-write capability and an unadmitted run's receipt must never be decoded.

The facts each arm carries

• Every writing arm carries its complete next state. First red sets both clocks; heartbeat preserves first_red; silent refresh moves neither; changed class preserves first_red (restarting it would erase how long the observer has been broken, precisely when the incident worsened).
• FirstRedStanding — an adopted issue does not fabricate first_red = now. Declared once, in gunbc.falsifier_alert_state, and null on the wire rather than a sentinel instant.
• Escalation is structural. AlertNotification.escalation_handle: NonEmptyStr; the undeclared case is RefuseEscalationRecipientUndeclared, reached before any notifying arm can be built.
• Observer incidents are complete instructions — OpenObserverIncident / RefreshObserverIncident carry issue, next state and silent_for, with their own signature so a timeout after a startup failure is a changed class.
• Trusted controller failures notify. NotifyAlertControllerUnavailable replaces silent refusals for a trusted run with a bad receipt, corrupt marker, or non-joining routings — previously the workflow completed successfully while the alert had done nothing. It never renders receipt content and never overwrites the marker. Untrusted events stay silent, so the wall cannot be used to page an operator on demand.

Identity

IncidentSignature is a sorted set of ComponentIncidentIdentity { index, outcome_tag, failure_mode_tag }. The label is out of the identity — it was the delimiter hazard — and the stored marker is read back structurally, with its index through the same strict_natural_of_lexeme the receipt decoder uses.

Routing

Routings exact-join the failing set by index; missing, surplus and duplicate each refuse with the indices named.

Conclusions

TimedOut/StartupFailure → observer incident. Skipped/Neutral/ActionRequired → RunPreventedByConfiguration, countable and distinct from green. Cancelled → CancellationUnexplained, deliberately unresolved: the workflow_run envelope does not say who cancelled a run or why.

Evidence

52 witnesses, PASS-counted. Discriminating REDs per arm, each with a control that stayed green under the same mutation — receipts in falsifier_alert_decision_red_receipts_note.

Not in scope

The trust wall is not wired (ALERT-6, whose acceptance must prove both enforcement points). The AlertDecision -> AlertEffectPlan projection comes before shadow mode. Item 1's remaining half — typing marker members via the shared closed tag readers — waits on #7928.

Stacked on #7928; rebases onto it when that merges.

[gunbai-bot]

Fixed in b457d608c86. review 49641 is correct and the cause was mine: introducing AlertIncidentState I renamed the parameter type with a global substitution, and it hit alert_decision itself along with the three inner folds it was meant for. alert_decision now takes FalsifierAlertStateDecoding again — it is the function that performs the peel, so taking the peeled type was backwards as well as wrong.

The part worth more than the fix. The claim in the review that this "will not typecheck" is the reasonable expectation, and it is not what happened — that is the finding. The broken signature typechecked clean and all 18 witnesses passed, both before and after the correction, with an identical roster=18 pass=18. Callers were passing StateAbsent (a FalsifierAlertStateDecoding) into a parameter declared AlertIncidentState, and the body was passing that same parameter to alert_incident_state_of(decoding: FalsifierAlertStateDecoding) — mismatched in both directions at once, and nothing refused.

So my evidence did not catch this and could not have. Every witness in the suite exercises behavior, and the behavior was right the whole time; what was wrong was a declared type that no consumer checked. This is a below-floor gap in the sense DESIGN §4b names — "values inhabit declared types" is the ordinary compiler floor, and a diff that lands a declaration the substrate does not enforce is not compensated by the higher-order properties above it. I am not fixing that here; it is well outside this PR. But recording it plainly matters more than the one-line correction, because the natural reading of "18/18 green" is that the module typechecks in the sense a reader assumes, and on this seam it does not.

Review found it by reading. That is the internal/external division DESIGN names — my witnesses find missing behavior, a reader finds missing checks — and it landed on exactly the class where execution evidence is blind.

— sent from calm-fox-748

[gunbai-bot]

Acted on the non-blocking remark in review 49651, because the charitable reading in it does not hold. Landed in 32ae6ed6f30.

The review read the overlap between alert_decision and falsifier_alert_notification_decision as "intentional lane staging ahead of effect-plan wiring, not semantic dilution." I checked rather than accepting it: falsifier_alert_notification_decision had zero production consumers — only its own witnesses — and alert_decision_red recomputes exactly its rule, the same window comparison against last_notification_at, the same signature comparison, the same silent_for. That is not staging, it is a §3 fork: one rule, two implementations, agreeing only by diligence. The narrower one was also the more tempting thing for an effect plan to call later, at which point the alert would have had two answers to the same question with nothing forcing them to match.

Deleted, with the §4b(4) distinction observed: the redundant production machinery goes, the evidence does not. Its six payload-driven witnesses carried coverage the ALERT-4 suite genuinely lacked — they reach the arms through falsifier_alert_state_from_payload, the seam that turns issue-body bytes into the coproduct, where my claims had been constructing CurrentState by hand. So they moved onto alert_decision instead of being deleted alongside the function. Both suites PASS-counted: decision 24/24, migration 46/46.

One of the six failed on the move, and the failure was worth keeping. Written as "an empty payload opens a first red", it red: an empty string is not valid JSON, so it decodes to StateMalformed and the alert refuses. The fixture was wrong, not the code — StateAbsent means the issue body carried no marker at all, which the decoder never produces, because by the time bytes reach it a marker was found. Absence is decided one seam earlier.

I kept it as a claim rather than a corrected mistake because the tempting repair is on the wrong side. Mapping an empty payload to StateAbsent would turn "I read a marker and could not understand it" into "there was no marker" — the empty-observation narrow, with a data-loss consequence: an unreadable incident record would silently start a new incident and overwrite the old one. It now asserts the refusal, under the name an_empty_payload_refuses_rather_than_reading_as_an_absent_marker.

review 49654 raised nothing actionable; no change owed there.

— sent from calm-fox-748

[gunbai-bot]

review 49672 raised nothing blocking, but its reasoning about the Bool helpers rests on a fact that was true and unwritten, so I wrote it down — 2bc74cbbe7e.

The review is right that alert_decision_notifies, notification_escalates, routing_lacks_owner and notification_has_unowned_routing are the shape that normally trips predicate dissolution, and right that they are safe here. I verified the premise rather than taking it: all four are consumed only by witnesses, with no production dispatch site anywhere in the tree.

That is the entire justification, and nothing held it. One future call site — an effect plan branching on alert_decision_notifies instead of matching AlertDecision — would silently make these exactly the collapse this lane already refused twice (review 49400, and the state module's own no-notifies-bool argument), because the arms do not notify the same thing and a Bool answering "does this notify" erases the instruction at the boundary where the caller chooses what to say.

The note states it as a convention and says so plainly, because nothing in the substrate distinguishes a witness caller from a production one today. It names the check that would catch a violation: if the effect plan ever imports this module, the import list is where to look. Not a wall, and not described as one.

— sent from calm-fox-748

[gunbai-bot]

review 49673 (REQUEST_CHANGES on 32ae6ed6f30) is recorded in the dashboard tally but its artifact has not reached me — no message body delivered, and /api/reviews/49673/artifacts/stdout.log is not reachable from this session. So rather than guess at what it says, I audited the consolidation commit myself for what a reviewer would most plausibly catch, and found real dead surface. Fixed in 72665e9b5c4.

Deleting the forked throttle left eleven import-only symbols in gunbc.falsifier_alert_decision — ReceiptDecoded, ReceiptNotJson, ReceiptMemberAbsent, ReceiptMemberMalformed, ReceiptSchemaUnknown, ReceiptComponentCountMismatch, ReceiptUnsuccessfulComponentIdentityNotUnique, ReceiptSubjectMatches, ReceiptSubjectRunIdMismatch, ReceiptSubjectWorkflowMismatch, ReceiptSubjectHeadShaMismatch — each appearing exactly once in the file, in its own import. The module carries the decoding and subject-match values through as opaque payloads on RefuseReceiptMalformed / RefuseReceiptMismatch and never names a variant, so only the two types are needed. Same class in gunbc.falsifier_alert_state: millisecond_count was imported but its last call site went with the deleted function.

Both suites re-run after the removal: decision 24/24, migration 46/46, PASS-counted against roster.

If review 49673 was pointing at something else, I would like to see it — the artifact link in the tally is the only reference I have and it does not resolve from here. Happy to act on it once the body lands.

Worth flagging that neither the dead imports nor the earlier signature defect (review 49641) produced any compiler complaint. That is the same gap I recorded on this PR: the substrate is not checking these declarations, so unused-import and parameter-type errors both pass silently and review is currently the only thing catching them.

— sent from calm-fox-748

[gunbai-bot]

Operator verdict addressed — all five corrections plus the conclusions ruling, in 2d7775955ae. 44 witnesses, PASS-counted 44/44.

P0-1 — issue observation un-fused from the state marker. AlertIssueObservation = NoOpenAlertIssue | OneOpenAlertIssue { issue, state } | MultipleOpenAlertIssues | AlertIssueLookupRefused is now the input; StateAbsent is a property of a body that exists. The two live defects are witnessed as the corrected behaviour: an existing marker-less issue is adopted on red rather than duplicated, and closed on green rather than reported as GreenWithNoOpenIncident. MultipleOpenAlertIssues refuses rather than picking one — two open alert issues means the alert already lost track of itself, and writing to an arbitrary half compounds it. AlertIssueLookupRefused refuses rather than reading as absence, which would open a duplicate on every red until the lookup recovered.

P0-2 — the mention is now structural, and you were right that it was not. AlertNotification carried an EscalationRecipient, and EscalationUndeclared inhabits that type — so a notification mentioning nobody was constructible and typechecked. The type forced an author to think about the recipient; it did not force the artifact to have one. It is now escalation_handle: NonEmptyStr, with RefuseEscalationRecipientUndeclared reached before any notifying arm can be built. Lane ownership stays absent-able and renderable, because "whose component broke" may honestly have no answer while "who is told the observer is broken" may not.

The old independence claim asserted that such a notification carried no mention — it passed, and it was measuring the wrong thing. It now asserts the refusal.

P0-3 — identity is a typed sorted set. ComponentIncidentIdentity { index, outcome_tag, failure_mode_tag } inside IncidentSignature, sorted by index, compared as a set both directions. The label is out of the identity entirely — it was the delimiter hazard (human-authored text containing : or |), and index already identifies the component uniquely now that #7928's decoder refuses a non-unique population. Rendering exists only for writing the marker, and the marker is read back structurally rather than string-compared, so a rendering change cannot silently become a behavioural change; an unparseable marker refuses rather than reading as "the incident changed".

P0-4 — every writing arm carries its complete next state, with the policy stated once. First red sets both clocks to now; heartbeat preserves first_red and moves last_notification_at; silent refresh moves neither; legacy migration preserves the recovered first_red. Changed class preserves first_red — that was the one needing a decision rather than an inheritance, and restarting it would erase how long the observer has been broken precisely when the incident got worse. One claim per arm.

P1-5 — routings exact-join the failing set by index, the same identity the signature is keyed on. Missing, surplus and duplicate each refuse with the offending indices named. Accept-and-join rather than deriving inside the decision, so the lane roster does not get a second copy inside the alert.

Conclusions policy. TimedOut and StartupFailure → NotifyObserverUnavailable; Skipped/Neutral/ActionRequired → RunPreventedByConfiguration, countable and distinct from a green; Cancelled → CancellationUnexplained. Cancellation is deliberately not resolved into supersession/operator/unexplained: the workflow_run envelope does not say who cancelled a run or why, so the arm records the distinction as unresolved with its dissolve-on named. Guessing "supersession" because it is common would fabricate; paging on every force-push would be noise.

Not in this PR, per your sequencing: the AlertDecision -> AlertEffectPlan projection before shadow mode, and ALERT-6's two-point trust-wall proof.

— sent from calm-fox-748

[gunbai-bot]

review 49807 is right — fixed in e2a0a585eff. Both blocks folded into one gunbc.floor_component_receipt_document import; the redundant FalsifierAlertState re-import is gone.

Cause was mine and worth naming since it is a pattern rather than a slip: I added the new symbols by appending fresh import blocks while satisfying unresolved-type errors one at a time, and the compiler accepted the duplicates, so nothing pushed back. That is the third time on this stack that a declaration-level rule turned out to be unenforced — after the alert_decision parameter type (review 49641) and the bare cross-module references on #7928 (review 49774). All three were caught by a reader; none by execution, because in every case the behaviour was correct and only the declaration was wrong. Witnesses do not see this class at all, which is exactly why the review pass matters here.

Suite re-run after the change: 44/44, PASS-counted against roster.

— sent from calm-fox-748

[gunbai-bot]

review 49830 found no defect, but its parenthetical — "11-arm (actually 15, counting all refuse arms)" — was a real catch about my prose, so I checked it. Fixed in 5981ea2cb72.

Counted against the live coproduct: sixteen arms, eight of them refusals. Two of my own notes were stale:

• falsifier_alert_decision_arm_separation_note still opened "FOUR DISTINCT REFUSE ARMS" and enumerated four investigations. The operator verdict added RefuseEscalationRecipientUndeclared, RefuseMultipleOpenIssues, RefuseIssueLookup and RefuseRoutingJoin; the arms grew and the sentence describing them did not. Now names all eight and what each one sends a human to look at.
• The witness note said "a decision procedure with eleven terminal arms ... and the four Refuse arms route to four different people."

Both corrected against the coproduct rather than from memory, and I kept the incident in the note rather than silently renumbering, because this is the same class three times on this stack — a name-level claim sitting false beside a mechanism that stayed correct. The previous two were caught by reviewers (the run_id_at decoder note on #7928, the LogicalOr invariant sentence earlier); this one was caught by a reviewer's aside while approving.

The specific hazard is worth stating: a count in prose decays every time the coproduct grows, silently, without anyone touching the sentence. It is DESIGN's positional-citation problem in a different coordinate — a claim about the shape of something the containment tree already knows exactly. The durable fix is not to write counts at all, and where the count IS the point (as it is here — "eight different investigations" is the argument for not collapsing them), it needs re-checking whenever the arms move.

Suite re-run: 44/44, PASS-counted.

— sent from calm-fox-748

[gunbai-bot]

Operator live-head items 1–4 plus review 49873, in 98726f9cfa4. 52 witnesses, PASS-counted 52/52.

3 — observer-unavailable now runs BEFORE the receipt is required. This was the sharpest of the four. A run that timed out or failed at startup produced no receipt — that is what those conclusions mean — so demanding a decoded, subject-matched receipt first sent every one of them to RefuseReceiptMalformed. The alert would have reported "the floor's writer is broken" for the common case where the floor never ran at all: a true statement about a missing artifact standing in for the true statement about a missing observer, with the wrong remedy and no notification. Order is now trust → recipient → observer availability → receipt → subject → state → verdict, which reads as escalating questions about what can be known.

2 — an adopted issue no longer claims to know when the incident started. FirstRedStanding = FirstRedObserved { at } | FirstRedUnknownBeforeTracking, and it lives on the marker itself (gunbc.falsifier_alert_state), so the unknown case survives a write instead of being flattened on the way out. On the wire it is JSON null, not a sentinel — 0 is a valid EpochMs meaning 1970, and every consumer would have had to know which impossible instant meant "unknown". Issue creation time is deliberately not substituted: when the issue was filed is not when the falsifier went red, and relabelling one as the other is the same fabrication one layer removed.

That change surfaced a smaller one worth naming. My first version detected the null by string-matching the number reader's diagnostic prose, which would have made a marker's meaning depend on the wording of an error message — reading state out of prose, which is exactly the practice this module deleted when it dropped the First red: regex, crept back in one layer down. StateNumberNull is now a typed arm; first_red reads it as the standing, last_notification_at still refuses.

4 — the observer arms are complete writing instructions, split into OpenObserverIncident / RefreshObserverIncident with issue, next state and silent_for, so the ordinary throttle governs them and a permanently broken observer does not comment every four hours. They carry their own signature (observer-unavailable:<tag>), so a timeout after a startup failure is a changed class and a timeout after a timeout is not.

4 — trusted internal failures now notify. NotifyAlertControllerUnavailable { cause, issue_disposition, notification } replaces the silent refusals for a trusted run whose receipt is missing/malformed/mismatched, whose marker is corrupt, or whose routings do not join. Previously the workflow completed successfully while the thing it exists to do had not happened — the original incident's exact shape, one layer up. It never renders receipt content and never overwrites the marker. Untrusted events stay silent, and the asymmetry is deliberate: making them notify would hand an attacker a way to page an operator on demand.

review 49873 / item 1 (partial) — the marker index readback now goes through strict_natural_of_lexeme, the same cardinal check the receipt decoder applies to the same semantic. The reviewer is right that a stored signature is hand-editable, so -1 and 6.5 are at least as reachable there as on the wire; both refuse, witnessed. The rest of item 1 — typing the marker members as ComponentOutcomeKind / FloorComponentFailureMode via the shared closed tag readers — waits for #7928 to land, as you sequenced.

Also still open by sequence: #7928 item A (gaining ModeStaleKnownRed and the expected-red-evidence-absent mode) needs #7906 merged first; it is still OPEN. I am not guessing at those mappings.

PR body updated separately — it still described the eleven-arm shape.

— sent from calm-fox-748

[gunbai-bot]

review 49908 found a real single-authority defect I introduced. Fixed in e4c65710c17.

I declared FirstRedStanding in both gunbc.falsifier_alert_state and gunbc.falsifier_alert_decision, identical shape, while the decision module already imported the state module and pointedly omitted those three names from its import list. Collapsed to the state module's declaration, which is where it belongs — the carrier field it types lives there.

Worth naming rather than fixing quietly: this is the §3 fork on the very carrier FalsifierAlertState.first_red is typed by, and it landed in the same commit whose note argues against exactly that. The reviewer is also right about the mechanism of harm — witnesses reading state.first_red through one declaration's constructors while the state module writes through the other would have stayed in agreement only by diligence, and a variant added to one side would have forked the meaning of the field silently.

Cause was the same one as the duplicate imports earlier on this stack: I added the type where I needed it while satisfying an unresolved-name error, and nothing pushed back. That is now four declaration-level defects on this stack caught by readers and none by execution — parameter type, bare cross-module references, duplicate imports, and now a duplicate type declaration. All four had correct behaviour and a wrong declaration, which is precisely the class witnesses cannot see.

Suite re-run: 52/52, PASS-counted.

PR body and title also updated — they still described the eleven-arm shape from before the operator verdict; it is sixteen arms, eight refusals.

— sent from calm-fox-748

[gunbai-bot]

review 49927 is correct. Fixed in 88d6726415a — IncidentLegacy.first_red is FirstRedStanding, matching the carrier it is threaded from and into.

The reviewer's reasoning about why it matters is the right one and worth restating: the whole point of FirstRedStanding was to make "unknown before tracking" representable, and re-narrowing to EpochMs on the one arm that carries a legacy incident re-opened exactly the state the carrier exists to hold. That arm is where an unknown first-red is most likely to arrive.

The prediction that "the module will not typecheck" is again the part worth reporting. It did. FirstRedStanding values flowed into a field declared EpochMs, and that same binding then flowed back out into three fields declared FirstRedStanding — a mismatch in both directions at once — and all 52 witnesses passed before and after the correction. Behaviour was right throughout because the value never changed shape at runtime; only the declaration was wrong.

That is the fifth declaration-level defect on this stack found by a reader and the fifth not caught by execution: parameter type (review 49641), bare cross-module references (review 49774), duplicate imports (review 49807), duplicate type declaration (review 49908), and now a field type. Every one had correct behaviour and a wrong declaration. I am not treating the passing suite as evidence about declarations any more, and I have said as much rather than quietly re-running it.

One note on process: the first re-run after this change reported 0/52, which was claim_batch truncating under load rather than a real failure — it printed only its startup line. Re-run after a pause: 52/52, PASS-counted against roster. Reporting it because a 0/52 that is actually a dead command is the same trap as an empty FAIL-grep reading as green, just pointing the other way.

— sent from calm-fox-748

[gunbai-bot]

review 49947 is right on all four findings, and they are one defect. Fixed in c86d46db48d.

The defect: two representations of one failure. When the operator verdict moved controller failures from silent refusals to NotifyAlertControllerUnavailable, I added the notify arms and left the refuse arms declared. So RefuseReceiptMismatch, RefuseReceiptMalformed, RefuseRoutingJoin, RefuseMultipleOpenIssues, RefuseIssueLookup and RefuseMalformedState sat on AlertDecision uninhabited, beside inhabited Controller* causes meaning exactly the same things. The reviewer names the consequence precisely: ALERT-5/6 would write exhaustive dispatch handlers for arms that never run.

All six are deleted. AlertControllerCause is the single authority, and ControllerIssueLookupRefused / ControllerMultipleOpenIssues — previously dead — are now the inhabited representation of those two cases. IncidentIndeterminate carries a cause rather than a whole AlertDecision, which also removes a needless recursion through the decision type.

One case moved as part of collapsing rather than being mechanically renamed: an unparseable stored signature was still returning the silent RefuseMalformedState. It is the same class as a corrupt marker — the alert cannot read its own state — so it now reports through ControllerMarkerMalformed with the issue named. Leaving it silent would have kept exactly the defect the operator verdict removed, in the one arm nobody was looking at.

The two stale notes are the same failure in prose, and both are corrected. falsifier_alert_decision_arm_separation_note still described four top-level refuse arms that no longer exist; it now states the two axes that actually govern — whose failure it is decides whether anyone is told (untrusted stays silent so the wall cannot be used to page an operator; ours notifies), and which failure it is decides who investigates, carried as the typed cause. decision_order_note still said a corrupt marker yields RefuseMalformedState on both green and red; the behaviour it describes is unchanged — the marker is still never written over, and a green run still does not close — but who hears about it changed, and the note now says so.

I kept the incidents in both notes rather than silently rewriting. This is now six declaration-or-prose defects on this stack caught by readers: five declaration-level and this pair of stale authority paragraphs. The pattern is consistent — behaviour correct, description wrong — and prose is the half no witness can ever check.

Suite re-run: 52/52, PASS-counted.

— sent from calm-fox-748

[gunbai-bot]

review 49971 is correct on both. Fixed in df8d4f21c20 — current_state_marker_round_trips and legacy_marker_is_its_own_state_not_malformed now match FirstRedObserved { at: t } instead of comparing a FirstRedStanding to a bare Int.

This one was a verification gap, not just an oversight, and that is the part worth reporting. When FirstRedStanding landed on this branch I re-ran the decision suite (52/52) and the migration suite — but I ran the migration suite on the base branch, where first_red is still EpochMs, so it passed 71/71 and told me nothing about the branch that changed the type. The suite that would have caught this was run, and run against the wrong tree.

It would have redded loudly rather than silently: the interpreter's cross-representation equality guard raises on exactly this comparison, which is how the same class surfaced elsewhere on this branch. So this is a case where the substrate does catch the defect at runtime — unlike the six declaration-level ones — and my process simply never put the two together in one place.

Migration suite on this branch after the fix: 65/65. Decision suite: 52/52. Both PASS-counted against roster.

One thing I checked rather than assumed while doing it: the migration roster is 65 here against 71 on the base, and I did not take that on faith. The six absent claims are exactly the payload-driven ones moved onto alert_decision during the review 49651 consolidation — a_decoded_legacy_marker_notifies_exactly_once_as_a_migration, a_decoded_changed_signature_always_notifies_even_inside_the_window, a_decoded_unchanged_signature_is_suppressed_inside_the_window, a_decoded_unchanged_signature_heartbeats_once_the_window_elapses, a_decoded_malformed_marker_refuses_instead_of_starting_a_new_incident, and an_empty_payload_refuses_rather_than_reading_as_an_absent_marker. Coverage moved, nothing dropped. A shrinking roster across a merge is worth confirming by name every time, because the merge driver on this repo can resolve one side away without a conflict.

— sent from calm-fox-748

[gunbai-bot]

Recording a merge conflict, not resolving it — the head stays where the two approvals are until the operator decides to spend the round.

State. #7928 merged as squash d145104eda2. git merge-base --is-ancestor 49a9dd7004cc origin/main says NO: the squash put #7928's content on main under a new lineage while this branch still carries the pre-squash commits. So the two files both PRs touch conflict textually even though the content is substantively the same work:

• dag/gunbc/falsifier_alert_state.dag
• dag/test/claim/falsifier_alert_migration_witness_test.dag

Measured read-only with git merge-tree --write-tree origin/main df8d4f21c20e — no worktree write, no head move.

This refutes the prediction the retarget was priced on. The plan held that retargeting after #7928 merged would need no rebase, the base change alone collapsing the diff. That is true for a fast-forward base and false for a squash-merged one. One round was the right call; "no conflict resolution in it" was not.

Why I am not pushing. Both approvals sit on df8d4f21c20e. A merge commit moves the head, discards both, and demands a fresh CI round. That trade may well be correct — this PR cannot merge or run CI conflicted, so the approvals are not redeemable as they stand — but whether to spend it tonight is not my call, and the branch freeze names exactly this case.

Resolution recipe when it is authorized (merge commit, not rebase, per repo merge policy):

git merge origin/main
# resolve the two files above, then re-verify by NAME not by count

The witness file needs care specifically. Its diff against main is 4 insertions, 79 deletions, and that shrink is expected — six witnesses were deliberately moved to falsifier_alert_decision_witness_test.dag — but a count cannot distinguish a deliberate move from the generated-artifact merge driver silently resolving one side away. Diff the test fn name lists and account for every missing name individually.