Repository navigation
The two retained native build subjects get a planted-defect control, and their entrypoints get executed - #11972
Merged
Merged
Conversation
… one now say what they compute
THE SUBJECT: `std.integer`'s `UInt8Ready.value`, `qualified_octets` and `uint8_int_value` --
the three declarations gunbc#11643 added over `UInt8 = Compose<UInt, MachineWidth<8>>`.
THE DEFECT, re-derived rather than patched at the symptom (DESIGN 6b). `std.machine_constraints`
declares `Compose<Algebra, MachineConstraint> = Phantom`, and a phantom HAS NO INHABITANT. Those
three declarations put an `Int` in one anyway: a field typed by an uninhabited carrier, a sealed
list of them, and `v + 0` to cross back out. The SEED TYPECHECKER admits this because the
composition is transparent to `Int` at a formal; the RUST EMITTER renders `Compose` faithfully as
`PhantomData`, which is not. Neither realization is unfaithful -- the row they read cannot be
satisfied, and each resolved it differently.
WHY IT WAS INVISIBLE: declarations over `UInt8` typecheck and their witnesses evaluate under the
interpreter, where transparency holds. Their EMITTED Rust is produced by nothing on the merge path.
THE IMPLEMENTATION BOUNDARY: the three sites, plus the sealed carrier they construct
(`QualifiedOctets.members`) and its accessor, plus the call sites that the deleted identity-add
forces (`std.encoding` x2, `std.machine_word` x2, one witness x2). `std.machine_constraints` and
`v1.compiler.emit_rust` are UNTOUCHED: an earlier attempt of mine declared `Compose<A,M> = A`, and
it was reversed because it would cement the defect
`gunbc.recurring_failure_mode.bounded_natural_arithmetic_evaluated_as_unbounded_int` files -- that
row's finding is that the interpreter is the permissive side and N must become VISIBLE, and making
the width permanently invisible is the opposite of its climb.
THE PRECEDENT IS ON MAIN: `std.encoding` `base64_octets` already took exactly this move --
`fn base64_octets(values: List<Int>) -> QualifiedOctetsResult` -- and its annotation gives the
reason in the same terms, that `List<UInt8>` "MADE IT DECORATIVE" because "UInt8 is a phantom
transparent to Int".
POSITIVE CONTROL, by execution on the repaired source:
gunbc test //gunbc/instruments:self-host
closure=a4402ad806e6541eba0bc2576c0004e4eec3a17b913427bb1a214485a6626385
binary=e574f9bf770926a190b6f665699cd7cedf4882836fc15c489709118c91781a85
exit_status=0 warning_count=0 (RUSTFLAGS="-D warnings", rustc 1.98.1)
gunbc test //gunbc/instruments:v2-native-cli
closure=61bfe87fed10dab67b8eb38bf85bae025dbc544ddcc7a88961ae4b4155ef2ad1
binary=7d3a25789a4ef4044a70b9b7b9ea8eb9560eb8649da8559886531048f0e67f00
exit_status=0 warning_count=0
Both closures previously refused with three errors in the emitted `std_integer.rs`
(gunbc#11915 observed the self-host half at main 87c6658). Zero now. The self-host closure
identity and binary sha reproduced BYTE-IDENTICALLY across two independent runs.
MUTATION CONTROL, red by execution: `establish_discriminating_red` injects one type error into the
entry's own emitted module and requires cargo to fail ALONE on it, naming the injected symbol.
self-host: Discriminated subject=EntryOwnModule module=v2_compiler_compile red=1616
v2-native-cli: Discriminated subject=EntryOwnModule module=v2_cli_compile_cli red=326
Bytes restored byte-exactly and the binary sha unchanged afterwards, so the green above is a
function of the emitted bytes rather than a replayed or fingerprint-aliased verdict.
NO ENFORCED RUNG DROPS. A phantom brand checks nothing, so there was no wall at these three sites
to remove. `uint8_of_int` still refuses anything outside [0, 2^8) and is still the only way to
reach `UInt8Ready`. The width is still not stated in a type that can carry it, so the structural
ceiling on the failure-mode row is unchanged and remains its trigger -- and that climb is a
NEWTYPE over the carrier with sole construction, NEVER a return to `Phantom`.
DISPOSITION OF WHAT IT REPLACES: `uint8_int_value` is DELETED, not deprecated -- it was `v + 0`
over a carrier with no inhabitant. Its four call sites become the value itself; one annotation in
`std.machine_word` cited it as a scalar-formal receipt and is corrected in place rather than left
pointing at a deleted symbol. `UInt8` the TYPE SURVIVES: `base64_decode` mints `List<UInt8>` and
`npm`/`mercurial` consume it, none of which is downstream of these three sites.
REGENERATED MIRROR: `src/v1/stage0/src/std_integer.rs`, via two `--regen-round-cost` rounds --
round A installed (convergence_stages=1), round B confirmed the fixed point
(convergence_stages=0, NoChangedMirrorsToRebuild, identical executable_digest).
`src/v1/stage0/src/gunbc_cli_dispatch_surface.rs` is ALSO rewritten by that regen and I did NOT
author it: a dissolution string in its `.dag` authority had drifted from its committed mirror
before this change. It is carried because the regenerator emits it and the tree must be
self-consistent, and it is named here so it does not read as part of this repair.
EXACT-HEAD HANDBACK: every figure above was measured on this branch's tree at this commit's
content, not on a preserved crate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…and their entrypoints get executed
THE SUBJECT: `//gunbc/instruments:self-host` (emits and builds `v2.compiler.compile`, the
`SourceRootEvalDriver` test driver) and `//gunbc/instruments:v2-native-cli` (emits and builds
`v2.cli.compile_cli`, the `NativeCliDriver` front door). Two gaps, both measured on the tree.
GAP 1 -- NEITHER SUBJECT HAD A PLANTED-DEFECT CONTROL. `prepare_emitted_compiler_for_entry` passed
the literal `"v2_native_lane_carries_no_mutation_probe"` to `run_cargo`, so both were admitted on a
green cargo run ALONE. A fingerprint alias, a replayed cached verdict, or an emitter that stopped
reaching rustc all report `Completed status=0` byte-identically to a real compile. The required
emit-compile phase already owns a real control, and its roster
(`gunbc.ci_layer_roots required_emit_compile_entries`) is eight small entries containing NEITHER
native subject.
REPAIR: call the SAME producer, `emitted_closure_compile_host::establish_discriminating_red` --
one type error into the entry's own emitted module, cargo must fail ALONE on a diagnostic naming
the injected symbol, bytes restored byte-exactly. Not a second copy of its shape (DESIGN 3). The
binary's sha is re-read afterwards and must be unchanged, so the artifact handed on is shown to be
the one the green baseline produced rather than assumed to be. The baseline's attribution symbol is
aligned to `MUTATION_PROBE_SYMBOL`, because the old literal became false the moment a mutation ran.
GAP 2 -- THE BUILT ARTIFACTS WERE NEVER EXECUTED BY THEIR OWN INSTRUMENTS. The CLI binary was
spawned by nothing at all; the eval driver only by the separate operator-invoked
`--required-v2-native` route, never by `self-host`. `v2.test.cli.v2_native_cli` exercises the CLI's
FOLDS over supplied argv and a supplied ingest -- the right subject for those rows, and not an
inhabitance claim that the program runs (DESIGN 3's pairing obligation, 5's
specification-without-execution).
REPAIR: `walk_eval_driver_door` and `walk_cli_door` spawn what was built.
POSITIVE CONTROL, green by execution (`gunbc test //gunbc/instruments:self-host`, exit 0):
self-host: driver accepted the clean root — mode=census universe=0
self-host: driver refused the poison specimen — reason="tokenize_lex_e1_unrecognized_char"
self-host v1->v2: closure=a4402ad806e6541eba0bc2576c0004e4eec3a17b913427bb1a214485a6626385
binary=e574f9bf770926a190b6f665699cd7cedf4882836fc15c489709118c91781a85
exit_status=0 warning_count=0 door_universe=0
Two census runs of one binary differing ONLY in their root, with different answers. The CLI's
no-entry arm is the same shape: it reaches `cli_no_entry`, a located cause only that module's own
fold produces, so the process demonstrably started, parsed argv, decided and set its own status.
MUTATION CONTROL, red by execution, on both subjects:
self-host: Discriminated subject=EntryOwnModule module=v2_compiler_compile red=1616
v2-native-cli: Discriminated subject=EntryOwnModule module=v2_cli_compile_cli red=326
AN EXPECTING-RED PROBE, ENROLLED RATHER THAN DELETED OR WEAKENED (DESIGN 4b(4)). The CLI's emit arm
FAILS and stays: the built door CANNOT emit a closure. Measured on the artifact -- over the fixture
root `infer_grounding_not_derived`, over the real corpus a located `parse_g0_tokens_remain` at
`dag/extdeps/access/posix_effective_principal_read_op.dag` on the `service ... { operation ... }`
form. These are limitations in the emitted front end, not defects of this instrument, and
`v2.cli.compile_cli` already records the same shape at gunbc#11507. The probe pins the cause BY
NAME, so a crash, a spawn failure or a different refusal fails the instrument; and an exit 0 fails
it too, with an explicit instruction to flip it into a regression control requiring the emitted text
to name the subject. That limitation is routed to the session that owns the front end.
A SECOND READER, DECLARED RATHER THAN LEFT TO BE FOUND. `walk_eval_driver_door` spells `census` as a
literal, which makes it a second reader of the eval driver's verb surface. RETIREMENT TRIGGER AT
CAPABILITY GRAIN: the entrypoint control derives its argv from that driver's own plan once the plan
is on main, sufficient that no verb spelling survives in this file -- deliberately not "when
gunbc#11952 lands", which could be satisfied while the literal still stood. That join is owned by
gunbc#11952, not by this change.
DISPOSITION OF WHAT IT REPLACES: the `"v2_native_lane_carries_no_mutation_probe"` literal is gone --
it was a true statement about a lane with no mutation probe and became false. `WELL_FORMED_CONTROL_ROOT`
is named for its property, not its first reader, because both walks consume it. One new fixture,
`fixtures/native_cli_door/door_probe.dag`, in its own directory because a CLI source root is walked
recursively and a shared directory would make the control's ingest depend on other authors.
EXACT-HEAD HANDBACK: every figure above was measured on this branch's content. This branch sits on
the Pkg1a repair (gunbc#11971); without it neither closure builds and none of these controls run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gunbai-bot
Bot
changed the title
…ow hold Ints (review 69590) review 69590 on #11972 found that this repair left `std.machine_word` declaring lists of an uninhabited carrier while carrying `Int`s -- the exact state the failure-mode row this PR adds describes as the defect. Verified against the code and fixed; the reviewer is right. THE CHAIN THE REVIEW NAMED, confirmed line by line. Retyping `UInt8Ready { value: Int }` makes `octet` an `Int` at `machine_word.dag:613`; it is pushed into `acc: List<UInt8>` (`:604`) and sealed as `RawOctetsReady { octets: List<UInt8> }` (`:94`); that list reaches `qualified_octets(members: List<Int>)` at `:681`, and `qualified_octet_members` -- now `List<Int>` -- is passed to `octets_big_endian_value(octets: List<UInt8>, ...)` (`:686`). Three live declarations naming a carrier with no inhabitant. Latent only because `std.machine_word` is in neither emitted closure; the next closure reaching it gets the same `E0308 expected PhantomData<...>, found i64` this PR exists to remove. FIXED: those three to `List<Int>`. The round-trip annotation asserted the `UInt8`-on-both-sides spelling as the thing that removed a disagreement, so it is corrected rather than left standing, and it now records WHY the element type is `Int`. Two further annotations named the element type of a live declaration and are updated. `UInt8` leaves the import: the TYPE is no longer spelled in the module (the variants and `uint8_of_int` still are). THE SAME CLASS WAS IN A SECOND MODULE, which the review did not reach and which the same reasoning condemns. `std.encoding` `base64_encode_optional` folds `qualified_octet_members` -- retyped by this PR -- into `base64_encode_step_optional(octet: UInt8)`, so `EncOne`/`EncTwo`, `base64_group_of_octets` and both encode steps were left in the same state. Retyped to `Int`. WHAT IS DELIBERATELY NOT RETYPED, and it is stated in `std.encoding` so the asymmetry is not read as an oversight: `base64_decode_values` mints its own `List<UInt8>?` from a `List<Int>` and is NOT fed by this PR's carrier. It, `base64_decode`, `utf8_admit_octet`, `utf8_decode_octets` and their consumers (`extdeps.npm`, `extdeps.mercurial` and its `octetNN: UInt8` fields) are a SEPARATE PRODUCER of the same class. Retyping a public network surface is a different decision with a different owner -- `std.machine_word`'s own note already warns that this lane touching it would be the second authority it exists to remove. EVIDENCE, by execution on the corrected corpus: gunbc test //gunbc/instruments:self-host -> exit 0 closure=a4402ad806e6541eba0bc2576c0004e4eec3a17b913427bb1a214485a6626385 binary=e574f9bf770926a190b6f665699cd7cedf4882836fc15c489709118c91781a85 exit_status=0 warning_count=0 (RUSTFLAGS="-D warnings") BOTH IDENTITIES ARE UNCHANGED by this fix, which corroborates the review's own reading rather than contradicting it: `std.machine_word` is not in this closure, so the defect was latent and correcting it cannot move these bytes. The binary was produced by a DIFFERENT seed than the earlier run (8ae311bab4ccc090... vs 6702ed2ff0e5d645...) and came out byte-identical, which is a stronger reproducibility result than the first two runs gave. NO RUNG MOVES. A phantom brand checks nothing, so no wall is removed by deleting these spellings. `uint8_of_int` is still the only way into the accumulator and still refuses outside [0, 2^8). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Fixed in Confirmed exactly as described. Fixed: those three retyped to The same class was in a second module, which the review did not reach. What I deliberately did not extend to, now stated in Evidence on the corrected corpus — Both identities are unchanged by the fix. That corroborates your reading rather than undercutting it: One correction to my own earlier record while I am here: I had told my manager these encoding sites "spell |
…efusal, and an unlocked fault-and-restore Both blockers were verified against the code before changing anything; both are real. (A) THE EMIT PROBE ADMITTED A SIGNAL AS ITS EXPECTED RED. The previous arm compared `status == Some(0)` for the flip, so a `None` -- no exit status, i.e. killed -- fell through to a `stderr.contains(...)` test, and a process killed AFTER printing a plausible diagnostic satisfied it. `unwrap_or_default()` then filed that run as `exit 0`. Two conflations in one arm: a signal read as a refusal, and a status the process never took written into the receipt. It is now a closed partition, `adjudicate_cli_emit_probe`, and the order is load-bearing. The TERMINATION is decided first and `None` is its own arm, so a signal cannot reach any test over the child's output however complete that output looks. Then a non-zero status, then EMPTY STDOUT (the CLI writes emitted text there and nothing else, so bytes on a refusal are a different termination), then the refusal itself. THE REFUSAL IS IDENTIFIED THROUGH THE CLI'S CONTRACT, NOT BY SUBSTRING. `v2.cli.compile_cli` renders `diagnostic chain: A -> ... -> Z | FATAL AT <locus>` and its `cli_fatal_diagnostic` folds the chain to its LAST element; that module's own annotation says why -- the head answers `parse_grammar_choice_overlap_residue` for every entry tried, a grammar-global ADVISORY that is never the fatal. So `cli_refusal_determining_reason` reads `Z` and compares THAT. A `contains()` over the line matched the pinned word sitting anywhere in the chain, which is exactly how an unrelated fatal could have satisfied this probe. CONTROLS, EXECUTING, and each one measured RED against the arm it exists for. Reverting `adjudicate_cli_emit_probe` to the previous logic (`unwrap_or_default` plus `contains`) fails EXACTLY two of the seven: the_expected_word_with_a_signal_fails FAILED <- the signal hole the_expected_word_beside_a_different_fatal_fails FAILED <- the substring hole (the other five stay green) So the pair discriminates the two defects specifically rather than reddening on any damage. On the restored implementation all seven pass. The stderr in the signal control is byte-identical to the passing case; only the termination differs. (B) THE FAULT-AND-RESTORE RAN WITHOUT THE PROBE-ROOT EXCLUSION. `gunbc.recurring_failure_mode` `a_shared_probe_root_lets_one_run_compile_anothers_source` names this caller in terms: the lock EXISTS in `emitted_closure_compile_host` `acquire_probe_root_lock`, `run_required_emit_compile` takes it, and the v2-native route "selects the same root through `lane_emit_compile_probe_root` and passes it to emission without acquiring anything". Its specimen (gunbc#10940) is a run that refused `E0063` against an innocent tree. ADDING THE MUTATION MADE THAT WINDOW WORSE, which is why the lock lands in the same change: the fault deliberately writes a BROKEN tree and then repairs it, so an unlocked peer's baseline can read our faulted bytes -- its `Discriminated` verdict then quotes OUR injected symbol -- or its restore can erase our red before we read it. The lock's own annotation records measuring that exact shape. The lock is taken BEFORE the emission, because the emission is what writes the shared root, and is held by `ProbeRootLockGuard` through build, fault, restore and the binary-identity re-read. A guard rather than a call pair because the function returns early on nine refusal paths, and a leaked lock turns a transient overlap into a permanent refusal for every later run on that host. CONTROL, AND ITS LIMIT STATED RATHER THAN GLOSSED. The operator's control was two overlapping PREPARATIONS with one paused mid-fault. That is NOT what this test does, and the module says so: a preparation is a whole-corpus emit plus two cargo builds, and pausing one at a chosen instant is not something this suite can stage honestly. What it establishes is the property that control rests on -- a second holder is REFUSED rather than admitted, with the cause naming a concurrent run -- plus release-on-drop, because a lock that refuses correctly and never releases is worse than the defect. The real path is `prepare_emitted_compiler_for_entry`; deleting its acquisition returns this route to the state that row files against it. #11971 is untouched: this commit is on the Pkg1 branch only. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…iew 69606) review 69606 on #11971 is correct on the facts and I am recording the correction rather than quietly rewriting the note. WHAT IT FOUND. This change deleted `uint8_int_value`, whose one job was crossing out of `UInt8`. `utf8_admit_octet` was one of its call sites, so that line became `word_of_int(width: Width8, value: b)` with `b` still spelled `UInt8` -- a value typed by an uninhabited carrier handed to an `Int` formal, which is the shape this PR's own occurrence text names as the defect. And the scope note I added to `std.encoding` listed `utf8_admit_octet` among declarations left untouched. THE DIFF TOUCHED IT. The note was false about that function, which is the prose-outruns-code failure this PR is otherwise correcting. WHAT I FIXED: the note. It now states that `utf8_admit_octet` WAS touched, why, and what remains unrepaired. WHY NOT THE ONE-LINE RETYPE THE REVIEW PROPOSES, stated as a measurement rather than a preference. `b: Int` plus `utf8_decode_octets(octets: List<Int>)` does NOT remove the emission defect; it MOVES it. `base64_decode` answers `List<UInt8>?` and feeds `utf8_decode_octets`, so today both sides of that call spell `UInt8` and the boundary typechecks under emission -- `PhantomData` meets `PhantomData` -- while the mismatch sits INSIDE `utf8_admit_octet` at `word_of_int`'s `Int` formal. Retyping the two utf8 declarations puts a `List<i64>` formal opposite a `List<PhantomData>` argument at the `base64_decode` call, which is a NEW mismatch at a boundary that currently has none. Removing the defect rather than relocating it requires retyping `base64_decode_values` and `base64_decode`, and therefore the `extdeps.npm` and `extdeps.mercurial` surfaces behind them. That is the separate producer whose retyping is explicitly not this change's decision, so I am reporting it rather than extending into it. WHAT IS NOT NEW, because "this diff created it" is only half true. The decode path did not emit cleanly before this change either: the deleted crossing rendered as `compile_error!` ("operator realization: host operator `+` on structural operand std.integer.UInt8"). So this change exchanged one unemittable form for another at a site it was obliged to touch. Neither form is reached by any closure the instruments emit, which is why both are latent. RESTORING THE CROSSING IS NOT AVAILABLE: `uint8_int_value` was an identity add over an uninhabited carrier and emitted as that same `compile_error!`, which is why the ruling deleted it. There is no other `UInt8 -> Int` construction in the corpus. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator ruling: land the repair as is, and record what it does not cover as a NAMED REMAINDER on `gunbc.recurring_failure_mode.bounded_natural_arithmetic_evaluated_as_unbounded_int` rather than opening a successor now. WHAT THE REMAINDER IS: `std.encoding`'s decode path is still spelled over the uninhabited carrier -- `base64_decode_values`, `base64_decode`, `utf8_decode_octets`, `utf8_admit_octet`, and the `extdeps.npm` and `extdeps.mercurial` surfaces behind them. WHY IT IS DEFERRED, recorded as the measurement rather than as a budget: retyping the two utf8 declarations RELOCATES the defect. Both sides of the `base64_decode` -> `utf8_decode_octets` call spell `UInt8` today, so that boundary typechecks under emission and the mismatch sits inside `utf8_admit_octet`; retyped, a `List<i64>` formal would face a `List<PhantomData>` argument at a call that currently has none. And it is not a regression: the path was unemittable before the repair too, via the `compile_error!` the deleted crossing rendered. TRIGGER, AT CAPABILITY GRAIN: a retained closure emits that decode path. The retype-versus-newtype decision is made then, on the evidence that closure produces. Deliberately not written as "retype base64_decode", which names one of the two answers and would be satisfied by a retype where the newtype climb belonged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…l that no code runs TWO REVIEWS, both correct, both about residue this session's own repairs created. BOTH FIXES LAND HERE, AND ONE OF THEM WAS MEANT FOR #11971. review 69619 is a finding against the Pkg1a repair (`std.encoding`, `std.machine_word`), but that branch entered the merge queue while this fix was being verified and protected-branch rules correctly refused the push. Dequeuing a landing PR to append a non-blocking cleanup is not a trade worth making, so the fix rides here instead -- this branch already carries Pkg1a's commits, so the corpus reaches the same end state either way. Stated plainly so nobody later reads #11971 as having contained it. review 69619 -- `octet_int_values` BECAME A NICKNAME. It had a real body, `qualified_octet_members(...) |> map(o => uint8_int_value(v: o))`, the crossing out of the uninhabited `UInt8` carrier. Deleting `uint8_int_value` collapsed that map to the identity, leaving a function whose body was exactly its delegate and whose signature was exactly the accessor's. DESIGN section 3 names a second name for one concept as the recurring violation. DELETED, its four call sites naming the accessor directly (`std.encoding` `base64_decode_step_flush` and three rows of `test.claim.machine_word_witness`), the `std.machine_word` import narrowed, and the annotation that argued about the parameter's element type replaced by one recording what stood there. VERIFIED RATHER THAN ASSUMED, because the deletion carried a hazard the review could not see: `test.claim.machine_word_witness` holds a MEASURED warning that an `import std.integer` would rebind bare `Int` there and break every claim in the file, and three repointed rows now name a `std.integer` function. Bare resolution had to be shown to reach it: claim_batch --entry dag/test/claim/machine_word_witness_test.dag --functions <all 64> requested: 64 PASS: 64 FAIL: 0 The first attempt was piped through `tail`, so the capture held 16 lines and showed 5 of 64 -- a truncated green is indistinguishable from a run that mostly did not execute. Re-run in full. review 69621 -- ANNOTATIONS DESCRIBED A POSITIVE CONTROL THAT DOES NOT EXIST. When the emit arm became an expecting-red probe the logic changed and the prose did not. `CLI_DOOR_EMITTED_WITNESS` appears in its own declaration and in the FLIP INSTRUCTION string and nowhere else; the admitting verdict `PinnedRefusalHeld` requires stdout to be EMPTY. Three paragraphs asserted a control no code runs -- the rung inflation DESIGN section 4b(1) forbids, and the same defect `e7d3bf9` corrected once already on this branch. Fixed in FOUR places: the three the review cited, plus `door_refusal_exit_status`'s doc which it did not reach and which still called the emit arm "the green" and spoke of "the one argument the positive control supplies". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s this row's own standard demands (review 69637) TWO CARRIERS THIS CHANGE LEFT BEHIND. Both verified against the code. (1) THE FAILURE-MODE ROW STATED A BYPASS THAT NO LONGER EXISTS. `a_shared_probe_root_lets_one_run_compile_anothers_source` asserted in the PRESENT TENSE that "THE v2-NATIVE ROUTE DOES NOT: v1_compiler.cli_run.native_lane_runner ... passes it to emission without acquiring anything". This change repairs exactly that caller, so the row's distinguishing fact was false at this head and DESIGN section 4b requires the row to be updated rather than left stating it. The bypass sentence is now PAST TENSE and KEPT rather than deleted -- the shape is the row's subject and the specimen is what makes it legible -- and an occurrence records the repair: the lock is taken BEFORE the emission (the emission is what writes the shared root), held through baseline, fault, restore and the identity re-read, by a Drop guard because that function returns early on nine refusal paths. IT ALSO RECORDS WHY THE REPAIR LANDED WHEN IT DID, which is this row's mechanism running forward rather than a tidy-up: the same change added the fault-and-restore, which deliberately writes a BROKEN tree and repairs it, WIDENING the exact window this row files. The lock's own annotation had already measured that shape. THE ROW IS NOT DISCHARGED, exactly as its own trigger says: selection and exclusion are still two operations, so the next caller can reach around the same guard. The repaired caller's rung moves from BELOW the ladder to 1; ceiling and trigger unchanged. Evidence recorded with its limit stated -- refusal-and-release is executing, two overlapping preparations with one paused mid-fault is not. (2) THE SEED-GROWTH ROW'S OWN STANDARD OBLIGED AN ENUMERATION, AND THIS IS THE PART I WOULD HAVE MISSED. The review flags ~560 lines of hand-written seed Rust with no receipt covering it, and marks it ADVISORY (ctrl policy, not a DESIGN rule). It is more than advisory, because `source_root_eval_driver_seed_growth`'s reason says of itself: "this row's reason is the standing enumeration of what is retained: a mode that is not in it is hand-authored Rust no row accounts for." The additions were not in it, so the row's own standard was violated. They are enumerated now -- the two door walks, the CLI spawn (whose stdout contract is the CLI driver's, so it cannot share `run_native_binary`), the emit probe's closed partition, the lock guard and the two test modules -- together with which of them is irreducibly host (the spawns, the lock) and which is expressible in `.dag` and retained only because its inputs arrive from a spawn on this side of the boundary (the adjudication, a pure fold over a status and two strings). That last one moves on the same capability this row's trigger already names. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…00-pkg1 # Conflicts: # dag/std/encoding.dag # dag/std/machine_word.dag
…usal exit, and retract a third inert receipt claim THREE FINDINGS, all verified against the merged code before changing anything. (1) THE DECODER DID NOT KNOW THE CHAIN HAD BECOME LOCATED, AND THE CONTROLS COULD NOT SEE IT. gunbc#11965/#11985 moved the refusal to `lens_verdict_diagnostics_located_chain_text`, so every link is `<reason> @ <locus>` (`lens_verdict_diagnostic_located_text`). This decoder compared the WHOLE last link against the bare constant, so a CORRECT CURRENT REFUSAL decoded as `DeterminingReasonDiffers` -- the probe would have refused the very thing it pins. Nothing caught it because the control fixture still fed the OLD unlocated rendering: a designed fixture that stayed green while the world it was written against moved, which is the failure DESIGN section 3 names when it says the pairing claim must assert the ROUTE and not only the answer. The reason is now split off the locus and THE LOCATION IS KEPT -- printed in the held line and in the mismatch refusal, because where the fatal sits is what a reader needs the day the pinned limitation changes. `v2.cli.compile_cli` is untouched. (2) THREE HOLES IN THE ACCEPTANCE, each admitting something that is not a refusal. - ANY NON-ZERO EXIT was accepted. `v2_cli_exit` sends every `CliRunRefused` through `std.process` `exit_failure`, whose code is `extdeps.process.posix_exit` `exit_code_general_error` = 1. So a refusal takes EXACTLY 1, and `Some(101)` -- a Rust panic -- beside plausible stderr was passing as the pinned red. New `UnexpectedExitCode` arm; `CLI_DOOR_REFUSAL_EXIT` names the authority. - `split(" | FATAL AT").next()` RETURNS THE WHOLE INPUT when the delimiter is absent, so a truncated render decoded as if complete. The full rendering is now required: a `REFUSED: ` prefix, a `diagnostic chain: ` section, a present ` | FATAL AT ` delimiter (`split_once`), and a located last link. - THE NO-ENTRY ARM took any non-zero too, and now takes the same exit-1 rule. (3) A RECEIPT FIELD DESCRIBED AN OBSERVATION NO PATH CAN PRODUCE. `door_emitted_bytes`'s doc said a nonzero value would be "visible in the receipt on the day the door starts emitting". It cannot be: `adjudicate_cli_emit_probe` returns `StdoutNotEmpty` before `PinnedRefusalHeld` whenever stdout is non-empty, `walk_cli_door` binds the field only in the admitting arm, and an emitting door answers `ProbeGreened` -- an `Err`, so no receipt is built. The field is ZERO BY CONSTRUCTION and now says so. THIS IS THE THIRD TIME THIS FILE CARRIED THAT SHAPE (69621, the `CLI_DOOR_EMITTED_WITNESS` paragraph, and this), and the pattern is consistent: the logic changed and a sentence describing the old behaviour stayed. I swept the file's added annotations for others of this form; the two remaining hits are this retraction quoting the false claim, and the flip INSTRUCTION, which correctly describes what a future regression control must do rather than what runs today. CONTROLS, 10 EXECUTING AND REWRITTEN AGAINST THE CURRENT RENDERING: the_current_located_refusal_at_exit_one_passes (accepted: chain + exit 1 + empty stdout) the_same_output_with_a_signal_fails (byte-identical stderr; termination differs) the_same_output_with_an_unexpected_code_fails (101 + plausible text) a_different_determining_reason_fails (chain still mentions the pinned word) a_truncated_render_without_the_fatal_delimiter_fails an_unlocated_last_link_fails (the pre-merge format is not the contract) output_without_the_refused_prefix_fails an_emitting_door_triggers_the_flip a_refusal_carrying_stdout_fails a_second_holder_is_refused_and_the_first_release_readmits test result: ok. 10 passed; 0 failed Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ad been hiding it
THE FIRST REAL RUN WITH THE LOCATED DECODER REFUSED, AND IT WAS RIGHT TO.
V2-NATIVE REFUSAL cause=NativeCliDoorRefusedForAnUnpinnedReason — the built CLI's DETERMINING
diagnostic is `translate_rejected_grounding_not_derived` at <synthetic node occurrence>, not
`infer_grounding_not_derived`.
THE CHAIN IS THIRTY-FOUR ADVISORIES AND ONE FATAL. `infer_grounding_not_derived` is what the chain
is FULL of; the last link -- the one `diagnostics_fatal` folds to -- is
`translate_rejected_grounding_not_derived`. This probe had pinned the advisory.
WHY NOTHING CAUGHT IT UNTIL NOW, and the two causes compounded:
- The original `contains()` decoder matched the advisory ANYWHERE in the line, so the probe passed
while pinning a symbol that is not the fatal. The substring defect was not merely a fail-open in
the abstract -- it was actively CONCEALING a wrong pin.
- The measurement that chose the constant printed only the chain's HEAD (`head -3`, `cut -c1-200`),
so the tail was never seen. That is exactly the error `v2.cli.compile_cli`'s own annotation
warns about: "THE WHOLE ORDERED CHAIN, BECAUSE THE HEAD IS NOT THE CAUSE ... the head answers
`parse_grammar_choice_overlap_residue` for every entry tried".
Fixing the decoder to read the LAST link is what surfaced it, on the first execution.
THE CORPUS ALREADY HELD THE ANSWER, and it is cited rather than re-derived from my one run:
`v2.test.claim.translate_underived_refusal` `translate_refused_canonical_grounding` asserts BOTH
halves -- `diagnostics_fatal_reason(d) == ^translate_rejected_grounding_not_derived` AND
`!= ^infer_grounding_not_derived` -- with an annotation saying in terms that "THE FATAL IS THE
GATE'S OWN REASON AND NEVER THE ADVISORY'S" and that infer's frontier rows "sit before it spelled
infer_grounding_not_derived". A landed claim agreed with the binary against this probe.
REPINNED to `translate_rejected_grounding_not_derived`, and THE FIXTURES REBUILT FROM THE BINARY'S
OWN STDERR rather than from what I expected it to say: advisories in front, the translate fatal
last. The advisory in front is what makes the accepting fixture discriminating -- a decoder matching
anywhere in the chain would accept it while pinning the wrong symbol, which is the defect this
commit removes. The neighbouring controls keep an advisory in their chains for the same reason.
10 controls pass. What this does NOT change: the door still cannot emit, so the arm still expects
red; only the reason it pins is now the one the door actually determines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…no-entry arm
THREE BLOCKERS, each admitting something that is not this door's rendering.
(1) THE RECORD WAS SAMPLED, NOT PARSED, and it let three different things through.
- `split_once(" | FATAL AT")` HANDS BACK THE TAIL AND I DISCARDED IT. So
`REFUSED: ...chain... @ locus | FATAL AT` with NOTHING after it parsed as a complete record,
carrying a fatal location nobody wrote. The tail is now required non-empty.
- NO AGREEMENT CHECK, so `| FATAL AT other.dag bytes 1..2` beside a last link located elsewhere
was admitted. `diagnostics_fatal` picks the LAST link and
`lens_verdict_diagnostic_locus_text` renders THAT diagnostic's locus, so the two halves cannot
legitimately disagree: a record that contradicts itself is not one this probe can claim to have
read the fatal from. The locus and the `FATAL AT` location must be equal.
- `contains("REFUSED: ")` IS PRESENCE, NOT FRAMING. A stray `REFUSED:` -- in relayed child output,
in a quoted sentence -- followed by an unframed chain satisfied it. The refusal is ONE LINE that
STARTS with the prefix; the line is now located and stripped, and each marker of the record is
required in order rather than sought anywhere in the stream.
(2) THE NO-ENTRY ARM VALIDATES ITS OWN FRAME, and deliberately NOT through the chain decoder.
`cli_no_entry` is a PARSE refusal: `v2_cli_run` is never reached, so there is no chain and no
`FATAL AT`, and routing it through the emit decoder would demand markers its contract does not have.
It previously tested `contains(detail)` plus exit 1, which accepted that sentence occurring anywhere
-- including inside a longer refusal that failed for a different reason. Now the prefix must frame
the line and the detail must be what that line carries. EMPTY STDOUT is required too, and it follows
from the contract rather than from caution: the refusal is decided during the parse, before anything
could be emitted.
(3) THE DIFFERENT-FATAL CONTROL WAS TESTING NOTHING ABOUT THE CURRENT PIN. It placed the OLD
advisory in the non-final link, so it could not distinguish "reads the last link" from "matches the
pinned word anywhere" -- the very defect the previous commit fixed. It now puts
`translate_rejected_grounding_not_derived` ITSELF in a non-final link and requires the record to
refuse, which is the property the arm exists to establish.
CONTROLS: 14 pass, four of them new and refusing --
a_record_truncated_after_the_fatal_marker_fails (` | FATAL AT` with nothing after)
a_contradicting_fatal_location_fails (suffix disagrees with the last link)
a_stray_refused_prefix_with_an_unframed_chain_fails (presence is not framing)
the_no_entry_refusal_frame_is_required (framed / unframed / wrong cause / absent)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…verse size (review 69673)
`walk_eval_driver_door` spawns the driver in CENSUS mode and read `clean.terminal.universe` into the
instrument receipt. A census marker is `{"_terminal":"complete","mode":"census","file_refusals":N}`
and carries no such key, so THIS FILE'S OWN DECODER fills `universe: 0` unconditionally. The field
was a fabricated measurement: DESIGN section 5's "no fabricated plausible output", and section
4b(1)'s rung inflation applied to a receipt.
THE ANNOTATION ON `main` NAMED THIS CONSUMER BEFORE IT EXISTED, which is what makes this worth more
than a deletion: "THE CENSUS ARM'S ZEROS ARE NOT A MEASUREMENT AND NOTHING READS THEM ... They are
struct fill for fields the mode does not have. If a future consumer wants a count from a census
marker, the honest change is a per-mode marker type, not a zero that has quietly become
load-bearing." My field was that consumer, and its doc called the fill "the size of the universe its
accepting control derived".
REMOVED RATHER THAN RE-DESCRIBED. The honest alternative the annotation offers -- a per-mode marker
type -- is a change to the decoder's contract that this instrument does not need: the accepting
arm's real evidence is the assertion the control already makes, that the mode is `census` and there
are ZERO per-file refusals over a well-formed root. A receipt field restating a required constant
adds nothing a reader can act on. The log line now prints only what the marker actually carries
(`mode`, `file_refusals`).
AND I AUDITED THE REST RATHER THAN WAITING FOR A FIFTH REVIEW, because four instances of one shape
in one file is a pattern in my work and not four coincidences (`CLI_DOOR_EMITTED_WITNESS`, the
positive-control paragraphs, `door_emitted_bytes`, and this). The remaining receipt fields all carry
genuinely decoded values -- `door_refusal_reason` is the poison arm's own `fatal_reason` -- but TWO
of them are now REQUIRED to equal `CLI_DOOR_REFUSAL_EXIT`, so a written receipt always shows 1 in
both. Their doc previously implied they were informative; it now says they are confirmations rather
than variables, recorded so the receipt states what the door was OBSERVED to do rather than
asserting it silently.
14 controls pass unchanged; the deletion touches no adjudication.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…n-blocking) `run_cli_door`'s doc justified a lossy stderr decode by calling it "diagnostic relay rather than a subject". THAT IS FALSE ABOUT WHICH STREAM CARRIES THE CLAIM: both door arms read their ENTIRE verdict out of stderr -- `cli_refusal_determining_reason` decodes the located chain, the determining reason and its locus from it, and `cli_no_entry_refusal_framed` reads its frame from it. stdout is required to be EMPTY on every admitting path, so stderr is the only stream either arm adjudicates. THE SAFETY CONSEQUENCE WAS SMALL AND THE STATED REASON WAS STILL WRONG, which is why it is worth a commit rather than a shrug: `from_utf8_lossy` substitutes U+FFFD, which cannot fabricate the pinned ASCII, so a mangled stream would have REFUSED rather than passed. What was wrong is the sentence explaining why a weaker decode was acceptable -- in a change whose whole business is retracting annotations that describe what the code does not do. CORRECTED BY MAKING THE DECODE MATCH THE CLAIM, not by rewriting the sentence, because the sibling already states the rule for exactly this case: `run_native_binary` -- "a receipt surface cannot transform its own subject; invalid UTF-8 on this stream is a refusal." Invalid UTF-8 on stderr is now `NativeCliDoorStderrNotUtf8`, the same shape as the stdout arm beside it. Review 69687 offered either this or a lossy decode with an honest reason. The checked decode is the one the corpus's own rule points at, and it costs nothing: neither arm can be fed repaired bytes. 14 controls pass unchanged; the adjudicators are untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
review 69687's non-blocking point is correct and is fixed in The finding: Why it was worth a commit rather than a shrug, which is also the reviewer's framing: the safety consequence really is small — U+FFFD cannot fabricate the pinned ASCII, so a mangled stream refuses rather than passes. What was wrong was the stated reason for accepting a weaker decode, in a change whose whole business is retracting annotations that describe what the code does not do. Leaving it would have been the same defect this PR corrected four times. Fixed by making the decode match the claim, not by rewriting the sentence. The sibling already states the rule for exactly this case — 14 controls pass unchanged; the adjudicators are untouched. Both instruments were re-run serially at the prior head and are green, which is what establishes the strict record parser matches the binary rather than my reading of the contract: Note the census line: it now prints only what a census marker actually carries, after review 69673 caught |
`ProbeRootLockGuard` was bound inside `prepare_emitted_compiler_for_entry`, so it dropped AT THAT FUNCTION'S RETURN -- and both entrypoint walks spawn `binary_path` after it returns. WHY THAT IS THE ROW'S OWN INVALID STATE, one step later than the repair covered. The probe build uses a shared `CARGO_TARGET_DIR` (`<workspace>/target`) and the executable's name is derived from the ENTRY (`probe_package_name`), so two runs of one entry write the SAME path. A peer taking the freed lock could rebuild and replace the executable between the drop and our spawn; the walks would then report about an artifact whose identity was verified BEFORE it was swapped. That is "a build whose SOURCE came from one revision and whose DEPENDENCIES came from another", with a verdict computed against somebody else's tree. TAKEN THE REAL FIX, NOT THE DOCUMENTED-HOLE ONE. review 69715 offered either extending the guard or recording on the row that post-preparation spawns sit outside the transaction. The WALKS ARE THE POINT OF THIS CHANGE -- a receipt asserting "the entrypoint executed" about a possibly-swapped binary is precisely the unattributable verdict the row exists to prevent, so declaring the hole would have left this instrument's headline claim resting on it. The guard now travels in `EmittedPreparation` and is released when the CALLER drops the preparation. The transaction spans emission, cargo baseline, injected fault, restore, binary-identity re-read AND every spawn of the artifact. Underscore-prefixed because nothing reads it: its lifetime is its behaviour. BOTH PLACES THAT STATED THE OLD SPAN ARE CORRECTED, not just the code. The guard's own doc said the transaction ended at the identity re-read, and the failure-mode row paragraph I added said "THAT CALLER IS REPAIRED AS OF 2026-09-21" over that same short span -- an overstatement under DESIGN section 4b(1), which the row of all places should not carry. Both now state the corrected span and record that the first cut stopped short. The log line reads `held for emit+build+fault+restore+spawn`. 14 controls pass; the adjudicators are untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ew 69715 follow-up)
`cli_no_entry_refusal_framed` tested `starts_with(CLI_DOOR_REFUSAL_DETAIL)`. The rendering it is
adjudicating is `v2.cli.compile_cli` `cli_parse_finish`'s
`concat("emit needs the module to resolve as its subject -- ", cli_usage)` -- the detail, a ` -- `
boundary, and the module's DECLARED usage line. A prefix test admitted two records that are not
that one:
- the detail TRUNCATED, with nothing following it;
- the detail followed by ANY continuation, so `<detail>; instead the fatal is cli_unknown_option`
passed while describing a different refusal.
The trimmed body must now EQUAL the complete record. The boundary and the usage line are named as
constants citing `compile_cli` rather than spelled inline, so the harness and the module cannot
drift apart silently.
CONTROLS, beside the genuine rendering and both measured RED against the previous logic:
truncated-after-detail `REFUSED: <detail>` and nothing more
misleading continuation `REFUSED: <detail>; instead the fatal is cli_unknown_option`
Reverting the function to `starts_with` fails `the_no_entry_refusal_frame_is_required` at the
truncation assertion, so the pair discriminates the defect rather than reddening on any damage. The
three existing cases (unframed, wrong cause, absent) are kept; 14 controls pass on the fix.
THIS IS THE SAME DEFECT CLASS AS THE EMIT ARM'S, ONE FUNCTION OVER, and worth naming as such: every
finding against this file has been a PRESENCE TEST STANDING IN FOR A RECORD CHECK -- `contains` for
the chain, `split(..).next()` for a delimiter that may be absent, and now `starts_with` for this
detail. The emit side received that scrutiny two rounds earlier and I did not carry it across to its
sibling at the time.
Nothing else touched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Side-chat review approved merging this head under the operator's delegation. I read the floor log: verdict=FloorClean, unexpected_failures=0. |
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
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.
THE SUBJECT:
//gunbc/instruments:self-host(emits and buildsv2.compiler.compile, theSourceRootEvalDrivertest driver) and//gunbc/instruments:v2-native-cli(emits and buildsv2.cli.compile_cli, theNativeCliDriverfront door). Two gaps, both measured on the tree.GAP 1 -- NEITHER SUBJECT HAD A PLANTED-DEFECT CONTROL.
prepare_emitted_compiler_for_entrypassedthe literal
"v2_native_lane_carries_no_mutation_probe"torun_cargo, so both were admitted on agreen cargo run ALONE. A fingerprint alias, a replayed cached verdict, or an emitter that stopped
reaching rustc all report
Completed status=0byte-identically to a real compile. The requiredemit-compile phase already owns a real control, and its roster
(
gunbc.ci_layer_roots required_emit_compile_entries) is eight small entries containing NEITHERnative subject.
REPAIR: call the SAME producer,
emitted_closure_compile_host::establish_discriminating_red--one type error into the entry's own emitted module, cargo must fail ALONE on a diagnostic naming
the injected symbol, bytes restored byte-exactly. Not a second copy of its shape (DESIGN 3). The
binary's sha is re-read afterwards and must be unchanged, so the artifact handed on is shown to be
the one the green baseline produced rather than assumed to be. The baseline's attribution symbol is
aligned to
MUTATION_PROBE_SYMBOL, because the old literal became false the moment a mutation ran.GAP 2 -- THE BUILT ARTIFACTS WERE NEVER EXECUTED BY THEIR OWN INSTRUMENTS. The CLI binary was
spawned by nothing at all; the eval driver only by the separate operator-invoked
--required-v2-nativeroute, never byself-host.v2.test.cli.v2_native_cliexercises the CLI'sFOLDS over supplied argv and a supplied ingest -- the right subject for those rows, and not an
inhabitance claim that the program runs (DESIGN 3's pairing obligation, 5's
specification-without-execution).
REPAIR:
walk_eval_driver_doorandwalk_cli_doorspawn what was built.POSITIVE CONTROL, green by execution (
gunbc test //gunbc/instruments:self-host, exit 0):self-host: driver accepted the clean root — mode=census universe=0
self-host: driver refused the poison specimen — reason="tokenize_lex_e1_unrecognized_char"
self-host v1->v2: closure=a4402ad806e6541eba0bc2576c0004e4eec3a17b913427bb1a214485a6626385
binary=e574f9bf770926a190b6f665699cd7cedf4882836fc15c489709118c91781a85
exit_status=0 warning_count=0 door_universe=0
Two census runs of one binary differing ONLY in their root, with different answers. The CLI's
no-entry arm is the same shape: it reaches
cli_no_entry, a located cause only that module's ownfold produces, so the process demonstrably started, parsed argv, decided and set its own status.
MUTATION CONTROL, red by execution, on both subjects:
self-host: Discriminated subject=EntryOwnModule module=v2_compiler_compile red=1616
v2-native-cli: Discriminated subject=EntryOwnModule module=v2_cli_compile_cli red=326
AN EXPECTING-RED PROBE, ENROLLED RATHER THAN DELETED OR WEAKENED (DESIGN 4b(4)). The CLI's emit arm
FAILS and stays: the built door CANNOT emit a closure. Measured on the artifact -- over the fixture
root
infer_grounding_not_derived, over the real corpus a locatedparse_g0_tokens_remainatdag/extdeps/access/posix_effective_principal_read_op.dagon theservice ... { operation ... }form. These are limitations in the emitted front end, not defects of this instrument, and
v2.cli.compile_clialready records the same shape at gunbc#11507. The probe pins the cause BYNAME, so a crash, a spawn failure or a different refusal fails the instrument; and an exit 0 fails
it too, with an explicit instruction to flip it into a regression control requiring the emitted text
to name the subject. That limitation is routed to the session that owns the front end.
A SECOND READER, DECLARED RATHER THAN LEFT TO BE FOUND.
walk_eval_driver_doorspellscensusas aliteral, which makes it a second reader of the eval driver's verb surface. RETIREMENT TRIGGER AT
CAPABILITY GRAIN: the entrypoint control derives its argv from that driver's own plan once the plan
is on main, sufficient that no verb spelling survives in this file -- deliberately not "when
gunbc#11952 lands", which could be satisfied while the literal still stood. That join is owned by
gunbc#11952, not by this change.
DISPOSITION OF WHAT IT REPLACES: the
"v2_native_lane_carries_no_mutation_probe"literal is gone --it was a true statement about a lane with no mutation probe and became false.
WELL_FORMED_CONTROL_ROOTis named for its property, not its first reader, because both walks consume it. One new fixture,
fixtures/native_cli_door/door_probe.dag, in its own directory because a CLI source root is walkedrecursively and a shared directory would make the control's ingest depend on other authors.
EXACT-HEAD HANDBACK: every figure above was measured on this branch's content. This branch sits on
the Pkg1a repair (gunbc#11971); without it neither closure builds and none of these controls run.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Relationship to #11971 (Pkg1a). This branch is built on top of that repair, so until #11971 lands this PR's diff against
mainalso shows its commit. Without it neither closure builds and none of the controls below execute. Land #11971 first; this diff then reduces to the instrument-seam change alone.🤖 Generated with Claude Code