Repository navigation
Fix record-like if condition brace parsing - #9025
Merged
Merged
Conversation
# Conflicts: # src/v2/workflow/floor_expected_red.dag
…de them that it did not The floor reported seventeen v2.test.claim.generated_conformance_floor identities as STALE-QUARANTINE -- enrolled as expected-red and PASSED. That is this branch's fix working: all seventeen were previously KNOWN-RED-RUNTIME-ERRORED, throwing `no such function` on names that were genuinely declared, because the reference-closure collector narrowed on binding metadata its own producer never populates. Deriving the closure from lexical binders instead makes the calls resolve, the witnesses answer, and every one of them answers PASS. The two arms are not symmetric and that is why this reds the build. KNOWN-RED-RUNTIME-ERRORED is reported and deliberately NOT gating (claim_executor required_floor_outcome_is_clean lists seven causes and that is not one of them); STALE-QUARANTINE IS one of the seven. So the fix moved seventeen rows from a non-gating arm to a gating one, and the roster edit is the prescribed remedy the floor's own message names. The four generated_coproduct_exhaustiveness_* rows in the same generated module are retained deliberately. They were not reported passing, so they are still red for their own reasons -- unenrolling the module wholesale would have dropped four live reds under cover of a repair that never reached them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ather than by widening the seal
main does not compile. `extdeps.exec.command` `ArgvCommand` became `sole_constructor
{ program, arguments }` in #8919, and its carrier states the invariant: "Every
ArgvCommand construction site in the corpus was converted in the same change, because
a partial seal is a dual-authority interval rather than a weaker seal."
One site was not. `gunbc.runner_slot_provision` `observe_runner_slot_members_wet` still
built `ArgvCommand { argv: ["ls", "-1", actions_runner_base_dir] }`, producing four
distinct diagnostics and refusing the floor at strict-preparation — so no witness ran
and no `required-floor` counter line was emitted at all.
Not a missed conversion by that PR. #8992 ADDED this site after #8919 was authored and
before it merged; neither touched the other's lines, so git merged both without a
conflict and the corpus broke on semantics. A clean merge is not coherence.
WHAT WAS DELIBERATELY NOT DONE: `runner_slot_provision` is not added to `argv_command`'s
`admit_callers`. That list is forty named builders, each for ONE operation of ONE tool,
homed in that tool's own extdeps module; admitting a product module would defeat the
wall rather than satisfy it.
A MODELED ALTERNATIVE WAS LOOKED FOR FIRST and does not exist at this layer. `ls -1 |
parse` is a shell-ism, so the right first question was whether the substrate already
answers "what entries are under this path" without shelling out. `dag/extdeps/filesystem`
carries posix `EntryKind` but no listing operation, and the `list_dir` in
`src/v2/extdeps/file_system.dag` is the v2 realization surface, not reachable from a v1-era
`wet` observation running over `LocalExec`. So the builder is authored rather than the
listing being re-modeled, and the call site keeps enumerating BY DIRECTORY — which its own
carrier requires, since probing the desired names could only ever return a subset of what
was already intended and would make an out-of-band slot invisible.
`-1` is baked into the builder with its reason, following `rm_force_command`'s precedent:
ls(1) columnates to a terminal and emits one-per-line to a pipe, so a caller that does not
pass `-1` depends on where its output happens to go. It does not recurse and does not
include dotfiles; a caller needing either needs its own name, not a flags parameter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…protects it
Fixing the ArgvCommand seal unmasked nothing -- this was already visible. With
preparation passing, the fold runs and refuses:
REQUIRED-FLOOR REFUSAL cause=ExpectedRedIdentityDidNotExecute count=3
test.claim.compile_accepted_unevaluable_program_control.primitive_call_with_{extra,missing,wrong}_...
gunbc#9022 landed both the module and the enrolment. Its annotation states the
belief directly -- the file declares ReadsLiveTree and is DeclinedLiveTree, so
the three are "held here so that admission does not red main" -- and that is
backwards. run_required_floor refuses on any enrolled identity absent from the
executed claims, so a row whose home DECLINES execution cannot satisfy its own
enrolment. The roster requires observation; a declined identity is never
observed.
Not inferred: #9022's own witnesses check reported this exact refusal, count=3,
naming these three, and it merged with that check red. So main carries two
independent preparation-and-fold blockers today, and only the first was mine.
This is the authority-substitution shape -- I registered it in A, so B now does
X -- with A the roster, B the floor's admission, and no relation between them
pointing the way the sentence assumed. The relation that exists points the other
way.
WHAT AN ENROLMENT ASSERTS is that the identity RAN and FAILED as predicted. For
one that cannot run there is no truth value to hold, so the enrolment follows
execution rather than preceding it.
NOTHING IS HIDDEN. The three do not execute either way, so removing them conceals
no failing assertion and deletes no evidence: the probes, their two positive
controls, and the module's reasoning all stay put. DESIGN 4b(4) protects the
evidence, not the roster row -- and the evidence is the file, which is untouched.
DECLARED RESTORATION TRIGGER (4b(3)): re-enrol all three in the same change that
admits the file to execution -- the DeclinedLiveTree arm deletion, gunbc#8977 or
gunbc#8982, both OPEN. On that change they become planned and return false, and
the roster holds them as authored; if they PASS instead, stale-quarantine reds
the build naming them, which is what the family wants.
Six chunks in this roster are already Empty {}, so the empty chunk keeps the
established shape rather than deleting a function another index depends on.
…e floor The ArgvCommand repair in this branch unmasked a second main-red defect that had never been observed, because every run since it landed died at strict preparation before the fold could reach it. gunbc#9022 enrolled three compile_accepted_unevaluable_program_control identities in the expected-red roster while their file declares ReadsLiveTree, so the DeclinedLiveTree arm declines them (declined_live=899) and they are never planned. The floor requires every ENROLLED identity to be observed among the EXECUTED claims, so the run refuses with cause=ExpectedRedIdentityDidNotExecute count=3. Chunk 21's own annotation states the opposite belief -- "until it lands they are held here so that admission does not red main" -- and execution refutes it twice: on #9022's own run 32644795043, which was merged red, and again on run 32649496046 here, where it was the sole floor refusal once the seal stopped masking it. The precondition that enrolment was authored against has not landed: gunbc#8977 and gunbc#8982, which delete the decline arm, are both still open. The rows are correct and stay in chunk 21. Only their LIVENESS is wrong, so they join the file's existing exclusion in floor_expected_red_is_live -- the mechanism already used for the mock-totality family -- which keeps the rows for provenance while removing them from the live roster. Verified by execution, not by reading the predicate: each of the three returns excluded (exit 1) through --claim-run, and an arbitrary unrelated identity returns live (exit 0), so the predicate discriminates rather than excluding everything. The exclusion is a coupling, not a note: whoever lands #8977 or #8982 must delete these three exclusions in the same change, or the rows will execute while excluded, count as ordinary failures, and red the build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Third blocker on main, and the first one visible only after the other two cleared: with preparation passing and the roster refusal gone, the fold reaches this row and it returns false. FAIL test.claim.runner_host_deploy.srv4_enables_its_declared_runner_instances The cause is one conjunct, and it is not the width axis this row is otherwise about: && string_contains(s: enable, pattern: "'sudo' 'systemctl' 'enable' '--now'") That was correct against the hand-built argv the row was written for. #8919 routed runner_enable_command_argv through extdeps.systemd.systemctl systemctl_enable_now_command, which mints through the sealed argv_command with sudo_binary_path (/usr/bin/sudo) as the program and inserts sudo's non-interactive flag -- so the rendered prefix is no longer the four words the pattern names, and #8919 updated two lines of this file without reaching this one. WHAT I CHECKED BEFORE CHANGING ANYTHING, because a witness edited to match the code it guards is worse than a red one. Quoting was the obvious suspect and it is NOT the cause: shell_quote single-quotes unconditionally (emit_test's shell_quote(arg: "plain") == "'plain'" pins it), so the unit-name conjuncts still match. Admission was the other suspect and it is not the cause either: the fixture receipts bind correctly on every arm admit_runner_activation checks -- instance host, managed_unit against intended_unit, all six verified flags, pool host, and slice_unit against intended_compile_pool -- so the command is READY and `enable` is a real render rather than the refusal arm's "". THE REPAIR CITES RATHER THAN RE-SPELLS. The old pattern was a third authoring of facts extdeps.sudo.elevation and extdeps.systemd.systemctl already own, which is why it rotted without anyone touching it (DESIGN section 3). The conjunct is now two, deriving the program spellings from those authorities and split because they assert different things: that activation ELEVATES NON-INTERACTIVELY, and that it reaches systemctl's ENABLE --NOW. WHY THIS IS NOT measure() == measure(). `enable` and `--now` stay literal, and they are the discriminating half: they are systemctl's own operands, spelled inline by the builder rather than read from any row, so a command that carried the units without the verb still fails here. What the derived halves buy is that a future re-homing of the sudo or systemctl spelling moves the assertion with the authority instead of leaving a fourth copy to rot. Not verified locally: the same stale-binary limit recorded on the previous commit applies. CI is the authority.
…ix/argv-command-ls-seal
… its refusal arm from erasing the cause
srv4_enables_its_declared_runner_instances was red on main, and not on the
roster/units join it exists to check. Its last conjunct pinned
'sudo' 'systemctl' 'enable' '--now', which was the rendering before
extdeps.sudo.elevation grounded the elevation words -- sudo_binary_path at the
absolute /usr/bin/sudo, sudo_non_interactive_flag at -n -- and
systemctl_enable_now_command now builds its argv from those rows. Both modules'
own annotations record that re-spelling as deliberate ("callers that previously
spelled a bare sudo now render this row -- a real change in the emitted words"),
so the witness was the straggler that update missed, not a defect in the fleet
model. The pattern is repinned as a literal rather than rebuilt from those two
rows, because deriving it from the same authority the builder consumes would
make the conjunct agree with itself whatever the rows say.
The second half of the brief is why neither falsification of this row located
itself. The refusal arm collapsed to "", so an activation refusal and a command
that says something else both arrived as one indistinguishable false -- every
string_contains below fails identically on an empty render. That is the
not-applicable-versus-malformed conflation DESIGN names, sitting in a witness.
Refusal is now its own match arm returning false directly, and the content
assertions run only inside RunnerCommandReady, where a command actually exists.
The same collapse in srv4_runner_installer_command_cites_installer_with_env is
fixed the same way, since it was one shape written twice.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014oG2tMMAxgZeAQxDjvNsFm
…oncat Preparation refused on the previous head with a single diagnostic -- runner_host_deploy_witness_test.dag:4:33: name 'join' not found in module 'std.types' -- so the import I added to carry the derived invocation patterns named a symbol that module does not export. The witness already builds every other composed pattern with concat and needs no import for it; the two new ones now do the same. This is my own defect from the previous commit, not new fallout: the repair it carries is unchanged, only its spelling of string concatenation. The stale-binary limit recorded there is exactly why it reached CI to be caught -- a local compile under a binary that predates the seal cannot answer questions about this tree.
…ion ruling is right RULING ACCEPTED (swift-badger-524). #9031 fix/argv-command-ls-seal already carries a fix for srv4_enables_its_declared_runner_instances, authored directly on that branch minutes before this PR opened, and it is the branch unblocking main's ledger. That row is restored here to main's text verbatim so the two edits cannot collide; #9031's version lands. I WAS WRONG ABOUT THE DERIVATION AND THE REASON MATTERS. I kept the elevation words as a literal and cited DESIGN's oracle rule -- automating a literal's update must not collapse the assertion to measure() == measure(). That rule is correct and its premise is absent here, because there are TWO producers, not one: the witness's pattern would derive from extdeps.sudo.elevation and extdeps.systemd.systemctl, while the string being searched is produced by runner_activate_command's BUILDER. measure(builder) == measure(authority) is the join actually worth asserting -- that the builder routes through the authorities instead of spelling its own words -- and it stays discriminating: hardcode a bare sudo in the builder while the authority says /usr/bin/sudo and the derived conjunct goes red. The collapse I feared needs the pattern derived from the builder's own output, which nobody proposed. Worse, my literal had the failure mode I was avoiding, pointing the other way: a pinned 'sudo' 'systemctl' 'enable' '--now' is a THIRD authoring of facts two extdeps modules already own, and it rotted the moment activation routed through systemctl_enable_now_command -- which is why the row was red at all. Repinning it buys one green run and re-arms the trap. #9031 derives what an authority owns and leaves 'enable' and '--now' literal, because those are systemctl's own operands that the builder spells inline and no row owns. That is the general line and it is better than what I wrote. WHAT REMAINS IS THE HALF NOTHING ELSE CARRIES. The installer witness rendered RunnerCommandRefused as "" and then pattern-matched the empty string, so a REFUSAL and a WRONG RENDER produced the same false with opposite repairs -- the not-applicable-versus-malformed conflation. The assertions now run inside the Ready arm and the refusal arm returns false on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014oG2tMMAxgZeAQxDjvNsFm
This reverts commit 0279359.
…name resolution The floor line that opened this (qualified_spelling_takes_the_shared_layer, wall_ms=57337, +1.22GB, bare arm free) reads as "qualified-name resolution is expensive". It is not. Qualified resolution is a map_get. Measured, four orderings plus a discriminating control: a qualified PATTERN HEAD costs nothing, and the premium lands on whichever claim first compiles a qualified TYPE ANNOTATION -- once per process, then 5ms forever after. The mechanism is severity classification, not resolution. A qualified annotation's authored name misses env.source_visible_names (which carries the bare imported names), so the masked type-ref arm emits an advisory UnlistedImportUse. Classifying that one diagnostic calls compile_clean_unlisted_import_use_blocks_from_policy, which resolves and typechecks a whole separate entry closure over default_source_roots() -- the whole tree -- to evaluate one nullary Bool. A bare annotation emits no such diagnostic and skips it; a qualified pattern head never enters that arm. This is gunbc.ci_spec's already-documented cost B from 2026-07-25, whose dissolve-on (scope the policy resolve to the policy module's own import closure) was never discharged. That note measured 57.8s for a green compile paying this tail against the floor's 57337ms. Shape, answering the brief: constant per process, independent of the subject compiled, and corpus-denominated. Same probe, roots varied: 216ms warm against 44886ms when from_policy's whole-tree root set diverges from the caller's and pays a cold load -- 44.9s locally against 57.3s on the floor. Diagnosis only; no repair, and the 1.22GB is reported as consistent-with rather than measured, since the witness is quarantined and the floor line was not re-run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ng rather than widening Discharges the cost-B half of gunbc.ci_spec gunbc_ci_floor_batch_clamp_note's dissolve-on, which has named this exact repair since 2026-07-25 and was never landed. No second row is filed beside it: the obligation is discharged in place, because landing the fix while leaving its obligation open would be two authorities for one fact. compile_clean_unlisted_import_use_blocks_from_policy resolved and typechecked an entry closure over default_source_roots() -- the whole tree -- to evaluate one nullary Bool. That is not merely oversized (the policy module has three imports); it is a function answering a question about the caller's world by consulting a different one, which is why it presents as cost but is correctness-shaped, and why "n is small here" was never available. It now assembles the policy entry's own import closure and resolves that explicit source set. Every arm that cannot produce the exact closure REFUSES with a located message naming the module and the path. There is deliberately no whole-tree fallback: that arm would restore today's cost, zero the deficit's frequency by construction, and make the widening unrankable ever after (DESIGN section 5). It is a new closure builder rather than a reuse of resolve_virtual_source_with_imports because that BFS silently SKIPS an unresolvable import -- a silent skip here would answer the policy question from a graph missing the module the answer depends on. MEASURED, same probe and orderings, all probes PASS so the narrowed closure still returns the policy Bool: roots dag only C first qualified 44886ms -> 109ms roots dag + src/v2 C first qualified 216ms -> 151ms The qualified/bare asymmetry is gone rather than reduced: on the cold root set the qualified arm is now CHEAPER than the bare one. RESIDUE, reported rather than absorbed: the bare arm's 12967ms on the dag-only root set did not move (12881ms). The bare arm pays it too, so it was never part of the qualified asymmetry and this repair does not touch it. NOT UPGRADED: the floor's 1.22GB is still unattributed by execution. If the memory line survives this repair that is a second defect to find, not one to absorb here. v1 freeze admission: PURPOSE test (operator ruling 2026-08-20) -- a defect repair on a path the required floor executes every run, not growth on a v1 surface for v1's own sake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
# Conflicts: # src/v2/workflow/floor_expected_red.dag
This was referenced Aug 23, 2026
Merged
briansrls
pushed a commit
that referenced
this pull request
Aug 25, 2026
…9177) `docs/probes/qualified_name_resolution_cost_2026-08-23.md` is cited by src/v1/stage0/src/cli_run.rs and dag/gunbc/ci_spec.dag. It is absent from main and has never been present. It was authored in #9044, whose squash produced an EMPTY COMMIT because the code had already landed via #9025 five minutes earlier; the document was the only part of that PR not carried by the earlier one, so it was dropped in silence. This is the DESIGN section 3 stale-citation class in its worst form, and the reason it is worth its own change rather than a passing fix: a rotted line offset at least pointed somewhere once. This path never resolved for any reader, at any commit. No authoring-time care would have caught it, and the cited-symbol census could not either -- that lens checks SYMBOLS and this is a PATH. The cli_run.rs citer is load-bearing prose. It backs the 216ms/44886ms figures that justify the fail-closed scoped-closure design over a whole-tree resolve, so a reader following it to check the measurement found nothing. REPAIRED BY REMOVING THE DEPENDENCY, NOT BY RESTORING THE DOCUMENT. Both sites keep the figures they already carried inline, state plainly that the method document never landed, and point at refs/pull/9044/head, which exists and is stable. That leaves nothing in-tree that can rot. The document is deliberately NOT restored. docs/probes was BANKRUPTED on 2026-08-24 by d3bebd0, which deleted every transcription and left the directory at two files; re-landing a probe document there would re-open a corpus this repository closed the day before, and would strand 200 lines nothing cites. Verified disjoint from the live doc_graph_roots cleanup: this path is not in that population, and the two citers here are code, not documents. Comment- and note-only. No semantics, no generated-artifact drift (gate run, only these two files modified). The cli_run.rs half is a v1-seed edit and is admitted under the seed's maintenance arm as a defect repair -- it changes prose that was false, not behaviour. Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com>
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.
Summary
.dagauthorityif Present { 1 } else { 2 }Verification
cargo run -q -p v1-compiler --bin parse_witness -- --suite floorcargo fmt --all --checkclaim_executor --required-regen --source-root dag --source-root src/v2(first_generation_equal=true)