Repository navigation
shell -> dag Phase 1 cgroup vertical (#7978) on a branch caught up to main - #8035
Merged
Merged
Conversation
…nt witness axes Cadence, eval budget and expected verdict were carried on one axis (WitnessConsumerCadence), so a witness that is both expensive and known-red was inexpressible. The eval ceiling was armed only for a batch whose entries intersected the long-lane batch roster, so such a root earned its budget by ALSO joining that batch: two schedule occurrences, the second on a batch that expects green, which paged the operator once per heartbeat window for a witness that is red BY DESIGN (#7737). Expectation itself was batch-wide and matched on entry PATHS, so file placement and batch homogeneity decided polarity. std.witness_admission gains WitnessExecutionBudget and WitnessExpectedVerdict as independent axes; ExplicitWitnessAdmission carries all three per row, and explicit_witness_admission_is_known_red now reads the EXPECTATION rather than the cadence. The scheduler ceiling reads witness_long_eval_budget_entries — the union of the long-lane batch roster and rows declaring their own long budget — so batch membership no longer confers time. The direct_rust duplicate long-lane row deletes; its paired schedule-multiplicity admission deletes with it, its dissolve_on having fired. claim_executor matches every executed witness against its own row: still-red is agreement, unexpected green is a typed StaleKnownRedRefusal naming the rows to un-quarantine. The refusal is derived from roster membership joined against per-witness outcomes and carried as data, so it reaches the component receipt as its own StaleKnownRed mode (-> Refused) instead of falling through the substring classifier's WitnessRed arm, where an un-quarantine and a regression would share one alert signature with opposite remedies. The batch-wide predicate survives only for a corpus resolve refuse, which has no per-witness outcomes, and only in its narrow all-entries form.
…nted failure Function-grain expectation replaced hermetic_known_red_entry_paths outright, so it is deleted rather than left beside its successor (-D dead_code caught it as the CI build error). The wet twin survives because it still scopes a WALL budget, a different fact from polarity. The still-red arm now passes only when every failure in the summary is matched by an agreement, instead of reading an empty unexpected-failure list as 'nothing failed'. Outcomes and failures are pushed in lockstep today so the counts agree; if one ever arrives without a per-witness identity the arm refuses rather than narrowing an unmatchable failure into a pass.
…nd not Done Both directions asserted. It must not collapse into WitnessRed (an un-quarantine and a regression would share one alert class signature with opposite remedies), and it must not read as success (an expected-red row that silently went green would accumulate on a roster nobody revisits — the fail-open this mode closes). Also fixes the two fixture helpers in the admission witness that still called known_red_probe without the now-required budget.
One declared-long row raises the ceiling for every row in the batch carrying it, so the known-red probe batch now runs at the long ceiling. That is the pre-existing lane granularity rather than a new grain, and it narrows to per-row on the cost-envelope trigger already declared beside it — stated here rather than left for a reader to discover.
… an identity set TWO DEFECTS FOUND IN REVIEW, both mine. (1) The classifier computed green = (outcome == Pass) and routed EVERY other outcome into the expected-red agreement arm. That blessed a budget kill, an interpreter fault, a non-Bool return and an unobserved row as though the business assertion had executed and returned false — the empty-observation conflation, in the one place that decides whether a red is real. It also contradicted a recorded ruling outright: BudgetExceeded is an interruption plus a measured lower bound on cost, never a semantic verdict on a witness, so a known-red witness that timed out reported its quarantine intact while its behaviour was unobserved. ExpectedRedDisposition now gives each outcome its own row. Only Fail is agreement. Pass is the stale quarantine. TimedOut is a budget failure and RuntimeError/NotBool an infrastructure-or-referent failure — both red the batch instead of being blessed. A rostered expected-red witness with no observation is EvidenceAbsent: counted and named on every path, never agreement and never a failure, because absent evidence is not a verdict. Refusal-before-evaluation shares the infrastructure arm today because run_claim formats the typed InterpError to a String before ClaimOutcome is built; that is declared on the variant with its trigger, not recovered by sniffing prose. (2) The ceiling roster concatenated its two inputs, so a witness reaching it through both would be listed twice. It is now an identity set joined on schedule_witness_entry_eq. The dedup control is worth naming, because the first one was a tautology: it read the live union, and the live inputs are disjoint, so deleting the membership check left it green — measured, not assumed. The fold is now exposed as witness_long_eval_budget_union_in and the control drives it with a planted overlap, which reds the moment the join stops using identity.
…ond ledger entry The collapse dissolves on the SAME trigger gunbc.witness_row_cost witness_cost_timed_out_seed_deferral_note already carries, because it is the same fact: the typed InterpError does not survive the marshalling of ClaimOutcome across the interpreter boundary. Realizing witness execution from .dag puts the typed error in hand at the point of judgement and splits the arm. One fact, one home — a new ledger entry for one cause is the parallel-ledger failure. Also promotes this PR's own tautology finding to a named tell in the body: a control that reads a live population can be vacuous whenever that population does not exhibit the property, and will stay green untouched. Found by mutation, not by reading.
…n terminal arms Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…t only the PR Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ent state Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…riven witnesses Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…production caller may use them Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- component index is a Nat read by a strict numeric decoder, not text - outcome and failure_mode carry the existing typed authorities, unmodelled wire refuses - unsuccessful rows identity-join the complete population in both directions - component_count requires a number; the event numeric decoder names its two consumers Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ns policy - issue observation un-fused from the state marker (duplicate/never-closed) - notifications carry a handle; undeclared escalation refuses - incident identity is a sorted typed set, label-free, read back structurally - every writing arm carries its complete next state - routings exact-join the failing set by index - non-success conclusions no longer read as a green corpus Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ut, strict natural decode Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tanding, complete writing instructions - FirstRedStanding on the marker; an adopted issue no longer fabricates first_red = now - observer-unavailable decided before a receipt is required (a timed-out run has none) - OpenObserverIncident / RefreshObserverIncident carry issue, next state and throttle - NotifyAlertControllerUnavailable reports trusted internal failures instead of silence - review 49873: marker index readback goes through strict_natural_of_lexeme Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…singleton count The floor red on 7992dae is ci_floor_plan_witnesses returning false, and it is correct: the witness pinned the known-red probe lane to EXACTLY ONE runnable whose explicit_entries length equals the whole corpus roster. That is the shape the recut deliberately replaced, so the witness had to move with it. What replaces it is strictly stronger than the count it drops. Each runnable must match EXACTLY one derived budget roster by IDENTITY (schedule_witness_entry_roster_contains over every entry), not by length — so a same-sized wrong population refuses, and the two rosters cannot be swapped between runnables, which is the budget inversion the split could otherwise hide. The runnable count must equal the number of NONEMPTY rosters, so an empty side schedules no batch rather than an empty one. Every runnable independently keeps the lane's SelectionApplied / hermetic / no-host-compiler profile, which the single-runnable form only ever asserted once. And a coverage clause requires the two rosters to sum to the corpus roster, so the split cannot silently drop a row. Pinning only the total would permit the swap; pinning only the count would permit either side carrying the wrong rows. Both are asserted. NOT VERIFIED LOCALLY, and disclosed rather than implied: this container cannot build the interpreter (five SIGKILLs today compiling the v1-compiler lib, two of them at load 9-13, with memory.events max 0 / oom_kill 1 at a 2.68 GiB peak against a 31.27 GiB cap — the kill arrives from an ancestor cgroup, not this one), and CI's own release-bins binary will not run here (requires GLIBC_2.39, unavailable). CI is the only oracle currently reachable for this change.
… exact Two defects found in review, both real, both closed here. BLOCKER 1 — a DECLARATION was flipping the result green. The Err arm returned ok:true whenever every explicit entry merely DECLARED a typed pre-verdict refusal. No ClaimOutcome exists on that path and run_claim has already formatted the typed InterpError into a String, so the observed phase and cause cannot be matched against the declared ones — a row declaring PreVerdictResolve/UnboundImportedVariantConstructor was admitted when some entirely different pre-verdict fault occurred. Disclosing that did not make it sound: an unobserved fact must not be verdict-bearing. The arm is now NON-GREEN and the declaration only classifies WHY, via its own mode ExpectedRedPreVerdictUnverified, which floor_component_receipt maps to Refused alongside its two siblings. It is distinct from both by design: StaleKnownRed says an executed row passed (delete the admission), ExpectedRedEvidenceAbsent says a rostered row never ran (make it run), and this one says the row stopped as declared while nothing proves it stopped for the declared reason (carry the typed cause across the boundary). Dissolve-on: EXPECTED-RED-CAUSE-1. BLOCKER 2 — the identity join was not exact, and this one is worse than it looks because it falsified the PR's own thesis. known_red_probe_batch_ matches_roster asserted length equality plus ONE-WAY containment and the note called that an identity join. It is not: actual [A, A] against expected [A, B] satisfies both — lengths agree at 2, every actual entry is present — while B is dropped and A duplicated. A same-sized wrong population passed, which is exactly what the note claimed would refuse. Replaced with known_red_roster_set_eq: duplicate-free on BOTH sides plus containment in BOTH directions, which for identity-set rosters is set equality. covers_lane had the identical shape one line down (a bare count that two swapped rows or one duplicate per side both satisfy) and is fixed with the same move rather than left standing beside the repair. Why the earlier swap probe missed it, recorded in the note so the calibration survives: swapping the two rosters changes the ASSIGNMENT, and one-way containment does catch that, because a fast entry is genuinely absent from the long roster. Multiplicity is an orthogonal axis the swap never perturbs. Evidence that a clause is non-vacuous is not evidence that it is exact, and one discriminating RED establishes only the failure mode it actually drives. Witnesses: witness_known_red_roster_set_eq_is_exact_not_a_length_agreement drives [A,A] vs [A,B] in both directions plus the order-independence and subset cases; declared_pre_verdict_refusal_is_non_green_and_carries_its_own_ mode pins the mode string and its distinctness from both siblings; fcr_pre_verdict_unverified_is_a_refusal_distinct_from_both_siblings pins the receipt projection. Rust side 9/9 green by execution; the .dag side is unverified locally for the reasons the previous commit records.
Found in review, and it is the same defect class as the identity join it sits beside: a stated discrimination wider than the one the test drives. declared_pre_verdict_refusal_is_non_green_and_carries_its_own_mode claimed "if someone restores the green arm, the first assertion here fails". It did not. All three assertions compared string constants to each other and to a literal; none observed ClaimResult.ok. run_discovery_batch_node has two call sites and neither is a test, so nothing executed the arm — flipping ok:false back to ok:true left the whole test green. The arm was non-green and the mode-distinctness half was genuine, but the regression control the comment promised did not exist. Repaired by construction rather than by weakening the sentence: the arm's ClaimResult is extracted to pre_verdict_unverified_claim_result, its single construction site, and the test now calls it and asserts ok == false. Restore the green arm and the test fails. It also pins that the typed mode and the located cause reach detail, that the entry count is carried, and that no per-witness population is fabricated on a path that observed no witness. Also worth stating because it is a real new refusal the previous commit did not advertise: covers_lane moved from a length sum to set_eq(concat(fast, long), corpus_roster), and duplicate-freedom over the CONCAT additionally forbids an entry appearing in BOTH budget rosters. The old form could not see that — 2 + 1 == 3 holds with one row double-counted and one missing. A row in both rosters would now refuse rather than pass. 9/9 executor unit witnesses green by execution.
# Conflicts: # src/v1/stage0/src/bin/claim_executor.rs
cursor review 50216 requested changes and the finding is real. Verified
against the code before acting: known_red_probe_corpus_{fast,long}_budget_
roster were derived from the whole corpus roster, so the three
ExpectTypedPreVerdictRefusal rows sat in the same discovery batch as
ExpectAssertionFalse rows.
Those two kinds cannot share a batch. A pre-verdict row stops the batch at
RESOLVE, so NO per-witness outcome exists for anyone in it, and the Err arm
admits that stop only when EVERY entry declared a pre-verdict refusal. One
pre-verdict row in a mixed batch therefore reds its siblings — witnesses that
were holding quarantine correctly and that the stop says nothing about. That
is the batch-wide coupling this whole PR exists to remove, reintroduced one
axis over by the budget split itself. Splitting on budget alone was not
enough, and the roster that would have caught it
(known_red_pre_verdict_refusal_roster) was imported by the plan and never
used to schedule anything.
The lane now derives up to FOUR batches, one per (expectation kind, declared
budget) pair, each homogeneous in both facts that govern it: the ceiling it
needs and the fact that decides its verdict. Nothing is authored — a new
admission routes itself, and an empty side schedules no batch rather than an
empty one.
Worth stating plainly: isolating the pre-verdict batches does NOT make them
pass. They are non-green by construction until EXPECTED-RED-CAUSE-1 lands,
because a declaration classifies a stop and does not verify it. The point is
that their refusal stays THEIR refusal — located and countable — instead of
being spread over rows it has nothing to say about.
Witnesses moved with it. The partition claim is now four-way with per-row
exactly-one-side membership (not a pairwise XOR, which cannot express four
sides); a new no_batch_mixes_a_pre_verdict_row_with_an_assertion_false_row
asserts the kinds are disjoint in both directions AND that the pre-verdict
side is nonempty, so it cannot pass by the population being empty; budget
homogeneity now covers all four rosters; and the plan witness pins batches
to rosters IN ORDER, each by set equality, plus a union clause so the split
can neither drop a row nor double-count one. The pairwise check is a fold
with an index rather than recursion, to avoid a Loop with no descent
evidence.
Unverified locally: the cold full-lib rebuild still cannot complete here.
4fba338 did not parse. A leading '+' at the start of a continuation line is a parse error ("expected expression, found Plus"); the six sites were the new four-way partition arithmetic in exact_witness_admission_witness_test.dag. Operators moved to the end of the preceding line. No logic changes. Proved on minimal three-line fixtures rather than inferred from the file: let a = 1 \n + 2 \n + 3 -> parse error let a = true \n && false \n && true -> parses let a = 1 + 2 + 3 -> parses So '+' cannot BEGIN a continuation line, '&&' can, and '+' mid-line is fine. Corpus census: leading-'&&' occurs 9,570 times tree-wide, leading-'+' occurred exactly 6 times and all 6 were these. This commit wrote the first uses of a form the grammar does not admit, which is why no prior file caught it. Two things worth knowing beyond the respelling, neither fixed here. The panic is FATAL TO THE WHOLE SOURCE ROOT rather than to the offending entry: while that file was in the tree, any dag-rooted claim_batch run died on it, including runs parsing unrelated fixtures in other directories. So it would not have presented as a localized witness failure. And the asymmetry itself - '&&' admitting leading-operator continuation while '+' does not - is a language-layer gap with no evident reason, whose diagnostic names the token without saying that the POSITION is what is wrong. Both are filed to the operator rather than chased here. I had already hit this exact class earlier in this branch on '==', '!=' and '<' and did not generalize it to arithmetic. The general rule is: in .dag, a binary operator may not start a line.
…WitnessRed
cursor review 50221 requested changes and the finding is real. Verified
against the code: pre_verdict_unverified_claim_result set
expectation_refusal: None and put ExpectedRedPreVerdictUnverified only in
`function` and `detail`. batch_failure_mode_and_detail reads
expectation_refusal off the VALUE and otherwise falls through to
falsifier_failure_mode, whose fallback arm is "WitnessRed". So those batches
reached the floor receipt as WitnessRed -> Failed, while the .dag vocabulary
this same PR added said ModeExpectedRedPreVerdictUnverified -> Refused.
The arm was half-wired: non-green result and receipt vocabulary present, the
classification path missing. And the shape of the miss is the one this PR
exists to remove — one fact in two representations, the second recovered by
substring-matching prose. StaleKnownRed already avoids it by travelling as an
ExpectationRefusal; pre-verdict now does the same.
ExpectationRefusal gains PreVerdictUnverified { declared_entries, cause },
the constructor sets it, and detail() is the single place the message is
built rather than a second format! beside the carrier. The enum's doc now
states why it is the ONLY structural route to a typed mode, so the next arm
does not repeat this.
The test was extended to assert the receipt, not the constant: it calls
batch_failure_mode_and_detail and requires the mode to equal the
pre-verdict mode and NOT to be WitnessRed. The previous version asserted
mode-string distinctness and would have passed against this defect
untouched — the same too-narrow-assertion class as the earlier
identity-join and regression-control findings, three for three in this PR.
Unverified locally: two more equivalent SIGKILLs on the cold full-lib
rebuild, so I stopped per the two-kill rule. Two things a compile would have
caught were checked by reading instead: ClaimResult has no Clone derive (so
the record is built from a second constructor call, not r.clone()), and the
matches! borrows &r.expectation_refusal rather than moving it.
…eipt module ONE file conflicted, dag/gunbc/floor_component_receipt.dag, and the cause was not drift: #7928 landed forty minutes ago and SPLIT this module, moving FloorComponentFailureMode and its readers into gunbc.floor_component_receipt_document. Main's side of both hunks is empty because the declarations moved, not because they were deleted, so taking either side wholesale would have been wrong — theirs drops the three new arms, ours re-declares a type that now lives elsewhere and forks it. Resolved by taking both intents: the declarations follow main to their new home, carrying ModeStaleKnownRed, ModeExpectedRedEvidenceAbsent and ModeExpectedRedPreVerdictUnverified with them, and the three arm notes move with the arms they document rather than being orphaned in the module that no longer defines them. Main's split added a reader this branch had not seen, and it needed the arms too. There are now FOUR places a mode must appear — the type, floor_component_failure_mode_of (the SEED reader), floor_component_failure_mode_tag, and floor_component_failure_mode_of_wire_tag (the WIRE reader, which must be total over exactly what the tag table can emit). Extending three and missing the wire reader would have reproduced main's own documented incident: a strict decoder refusing a receipt the floor itself produces. All four are extended. floor_component_outcome_of_mode maps all three to Refused, and because outcome_matches_implied_mode DERIVES the valid pairs from that function rather than restating them, the pair check extends for free — which is the property that note exists to preserve. SEMANTIC MERGE READ, since a clean textual merge of a safety arm is not proof of a correct one: src/v1/stage0/src/bin/claim_executor.rs auto-merged and never entered conflict resolution, so nobody chose a side on the pre-verdict arm. Confirmed by reading it after the merge — ok: false, runtime_unit_count_unavailable(msg), and expectation_refusal: Some(refusal) all survive, and the Err arm still calls the extracted constructor. The fail-open is not restored.
…alert4 # Conflicts: # dag/gunbc/falsifier_alert_state.dag # dag/test/claim/falsifier_alert_migration_witness_test.dag
Parser and bash runtime scan must agree on all four fixture outcomes; mutation sketches on both sides prove drift reds without shipping defects. Co-authored-by: Cursor <cursoragent@cursor.com>
…k refused Run 31219557841's regen job refused on the pre-plan witness naming walk: red_receipt_other_class is a plain fn in a *_test.dag unreachable from every test fn, which is silent de-enrollment. Deleted rather than promoted. It has zero call sites, and the changed-signature claim it looks like it should carry is already covered on the correct side -- the receipt stays red_receipt (the current run) while the STORED STATE's signature varies via signature_of_fixture(component: other_failing_component). Varying the receipt would exercise the wrong half of the comparison. So this is a dead scaffold, not a missing witness. Worth naming because a local run cannot find this class: claim_batch executes the roster handed to it, built by grepping `test fn`, so a plain fn no test reaches is outside that denominator by construction. The suite reported 52/52 before and after -- true both times, and silent on exactly the thing that failed to enroll. Decision suite 52/52 after the deletion, PASS-counted against roster. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Resolve supersede-vs-duplicate conflicts in proc_self_cgroup semantic and witness modules (vertical supersedes parser-only main), keep main's ci_floor_peak_emit dissolution note, and regenerate ci.yml/falsifier.yml from expected_ci_yml/expected_falsifier_yml so the typed cgroup membership loop matches ci_floor_peak_emit emission. Co-authored-by: Cursor <cursoragent@cursor.com>
regen refused on b73bead with a located non-exhaustive match: floor_component_receipt_document.dag:443:7 — missing variant(s) ModeStaleKnownRed, ModeExpectedRedEvidenceAbsent, ModeExpectedRedPreVerdictUnverified My merge commit enumerated FOUR places a mode must appear and extended all four. There were FIVE. The fifth is component_outcome_agrees_with_failure_mode, inside floor_component_receipt_document.dag — the module the #7928 split CREATED. That is not a different mistake from the one the merge was guarding against; it is the same one, one module further along: I enumerated the consumer roster visible from the module I started in, and the split had moved consumers as well as declarations. Fixed by enumerating rather than counting. A scan for every match over the coproduct corpus-wide finds four (two of which are the outer/inner halves of this one nested match), and re-running it after the fix reports zero remaining non-exhaustive sites. Verified further by parity: all eight modes now appear at exactly six structural sites each, in lockstep — type, seed reader, tag table, wire reader, outcome_of_mode, pair agreement. ModeUnrecorded's five is correct and not an omission: it is deliberately absent from the seed reader, which never observes "no mode was recorded", and failure_mode_wire_reader_note already records why. The three new arms delegate to outcome_matches_implied_mode exactly as the other non-Unrecorded arms do, so the pair check stays derived from floor_component_outcome_of_mode rather than restating which pairs are valid. No wildcard: a catch-all here would have suppressed precisely the refusal that located this, and five of six arms being identical is what makes that tempting. Worth stating because it is the good outcome, not the bad one: the arms are real and that match was genuinely non-exhaustive without them, so the typechecker refused and named both the variants and the line. A count-based check would have said nothing.
…red path alert_decision_observer_unavailable's IncidentCurrent arm returned RefreshObserverIncident unconditionally -- it never compared the heartbeat window, and never compared the stored signature either. On the four-hourly falsifier cadence a permanently timed-out observer therefore paged every four hours, which is the notification spam this module exists to end. Two notes a few lines apart asserted the guard existed. The code was wrong and the prose was right, which is the worse orientation: an auditor reading the policy would have found it documented, coherent and untrue. The witness was holding it in place. a_repeated_observer_outage_refreshes_the_ same_incident asked the repeat case at last=5000 now=6000 -- a one-second gap inside a twenty-hour window -- and asserted RefreshObserverIncident, pinning the spam as the contract. That is why 52/52 was green over it, and why the correct fix would have read as a regression. New RefreshObserverIncidentWithoutNotification arm; the observer path now mirrors the red path. The two notifying cases share one arm because they produce the same effect -- the red path splits its two only because their MESSAGES differ, a distinction in what gets said rather than whether to say it. The suppressed arm carries last_notification_at UNCHANGED. Advancing it to now looks right (the run did just observe the incident) but restarts the window every cadence, so the elapsed comparison can never fire and the heartbeat goes silent permanently -- converting a spam defect into a strictly worse silence defect that nothing observes. The field records when we last SPOKE, never when we last LOOKED. Adding the arm broke alert_decision_notifies and alert_decision_notification as non-exhaustive, so the closed coproduct made it structurally impossible to add a suppressing arm while leaving a predicate claiming it notifies. Roster 52 -> 55, 55/55 PASS-counted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Remove merge-appended trailing blank lines from generated workflows (heal artifact), update DESIGN shell→intent citations to the landed cgroup vertical symbols, and escape literal braces in ci_floor_peak emit goldens so dag interpolation does not corrupt expected bytes. Co-authored-by: Cursor <cursoragent@cursor.com>
…teps. Heal could not push author-commit-required workflow paths; CI projected scaffold dissolve-on lines for ci_floor_peak pre/post pipelines that were missing from the committed ci.yml and falsifier.yml. Co-authored-by: Cursor <cursoragent@cursor.com>
One conflict, and it is an import list rather than a semantic one — main added verify_floor_discovery_terminal_for_coordinator, FloorDiscoveryConsumerRole and FLOOR_DISCOVERY_CONSUMER_ENV to the same use block this branch had already touched. A union, not a choice: taking either side wholesale drops the other's symbols and fails to compile. The pre-verdict arm auto-merged again and was read after merging rather than assumed: ok: false, runtime_unit_count_unavailable(msg), and expectation_refusal: Some(refusal) all survive. That check is not ceremony — main's side of that hunk is still the old ok: true result, so a bad resolution there silently restores the fail-open with nothing to announce it. Verified by execution rather than by reading, since an import error is exactly what a read misses: cargo check --bin claim_executor finishes clean, no errors and no unused-import warnings (the build runs -D warnings, so an over-inclusive union would have failed rather than passed quietly). Both sides' symbols are present and used.
gunbai-bot
Bot
changed the title
gunbai-bot
Bot
changed the title
The cross-realization tag equality fold in extdeps.linux.proc_self_cgroup uses structural off-variant wildcard arms; enroll it in non_fold_residue so non_fold_residue_no_unrostered_or_stale passes on the floor. Co-authored-by: Cursor <cursoragent@cursor.com>
gunbai-bot
Bot
changed the title
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.
Carries the last unmerged
keen-ibex-349child thread — #7978, the shell→intent Phase 1 cgroup vertical — on a branch caught up to currentmain.#7906 and #7935 have both landed while this was being assembled, so their content is now present via
mainrather than via this branch. What #8035 contributes overorigin/mainis exactly #7978's 15 paths and nothing else.This branch is content-identical to
main + #7978: building that combination independently and diffing it against this head yields 0 differing paths. Whichever of the two lands, the tree is the same.What was verified about the fold
Generated artifacts are only adjudicated by the
generated-artifactmerge driver when hunks textually collide; otherwise they are plain text-merged with nothing checking them. So combines are enumerated at combined-diff grain (files differing from all parents), never fromrev-list, which reports every legitimately-taken side.dag/gunbc/ci_layer_roots.dag, authoreda1ea1454787mainNo generated artifact was ever combined on this branch.
The one combined file was checked as an identity join rather than as "it merged without conflict":
1517 + 14 + 10 = 1541lines and102 + 3 = 105declarations, zero duplicated names — an exact additive union of two disjoint edits. The detector is armed; planting one duplicate declaration moves it 0 → 1.Projection: confirmed by execution
heal_generated_artifactspassed on head1f387fbffae, whose content this still carries:main_wetwrites the whole registry, so a clean pass is a full-registry drift check.regenalso passed on that head, closing the seed fixed-point.Bounds
ci) is the one axis not yet green on this branch; every prior run was superseded by a push before reaching it.[wet-witness-row-outcome-receipt]channel, not the check conclusion.