Repository navigation
Drain the expected-red runtime-errored family 143 -> 15 in four measured rounds - #9039
Conversation
…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>
…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
…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.
…y, and import the 19 the bare closure can never reach The bare-reference closure that resolves an unimported bare name through the tree census is switched off for any file declaring an import line (cli_run build_both_closure_edge_index, source_declares_import_lines). Joined against the 143 live runtime-errored enrolments, 23 rows sit in files already past that gate, so no loader-side repair can reach them: 19 are reference rows whose missing name has exactly one declaring module, and this adds those imports. No roster row is removed: main refuses at preparation, so no witness has executed and unenrolling would be the stale-quarantine hazard the roster exists to surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ntier name for the 11 that advanced Required-floor run 32660721426 on this branch: known_red_runtime_errored 143 -> 135, known_red_now_passing=8. Those eight reported STALE-QUARANTINE — enrolled and PASSED — so they leave the roster by its own removal path, at exact identity grain, chunk structure otherwise untouched. The other eleven repaired rows advanced rather than flipped: their reported missing name changed, which is the first-failure frontier the floor reports. Round 2 imports the three successor names in the same three already-importing files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…he bare-scan gate The 120 BARE rows cannot be diagnosed outside the floor: the per-entry loader resolves the R1 shape and PASSES the witness, the floor's prepared subject already contains every module, and a whole-tree gunbc run refuses rather than approximating the floor's subject. So the floor is the instrument and this is a bounded experiment, not a rollout — three files varying in how many OTHER ambient names lose their census-derived pull when the file crosses the gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…d by measurement Required-floor run 32664512304 at 42d0a85: known_red_runtime_errored 135 -> 111, known_red_now_passing=24, failed=0, planned==executed==terminal==10693. All 17 rows in the three import-less experiment files flipped to PASS with nothing else in those files regressing, so the bare-scan gate hazard this lane raised does not bite for them — measured, not argued. The seven round-1 frontier rows flipped too. All 24 reported STALE-QUARANTINE and are removed at identity grain: roster 195 -> 171. Three runtime_axis rows advanced a third time (cost_is_lowerable -> type_decls_anti_unify), imported here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…atch 48 files, 70 imports. Each name has exactly one declaring module the referring file does not import; three were decided by the consuming field's type rather than by uniqueness, because the name is corpus-ambiguous and the census resolves that silently (Dag -> v2.lens.fact_cardinality, SourceFile -> v2.std.artifact x2). Batched rather than trickled because round 2 retired the bare-scan hazard by measurement and the fold is the check: every row still executes and a repair that breaks a sibling shows up as a named failure, not a silent pass. The 21 rows left are not reference failures — atom_identity_hash arity (12), the render lexical-shadowing defect, .raw on Int (2), a divergent fixture, and three runtime_axis rows already imported. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… pin each round to its run Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…reference-shaped rows Run 32667349586 at 7026838: known_red_now_passing=88, known_red_budget_refused=2, known_red_runtime_errored=21 — 88+2+21=111, no remainder. failed=0, so the 70-import batch broke no sibling. Roster 171 -> 83, deletions only. Two rows moved from runtime-errored to BUDGET-REFUSED at 5001/5003ms against 5000ms. They stay enrolled: the witness previously threw before doing its work and now runs it, so this is a real cost debt the repair surfaced, not a regression to absorb. Repaired here: sigma_families_of_defs (the runtime_axis file's fourth successive frontier name) and LocalAccelerator, fixed in dag/gunbc/accelerator_demo_plan.dag where the bare value-position reference is, not in the two witness files that call into it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
# Conflicts: # src/v2/workflow/floor_expected_red.dag
Run 32671448306 at eee5a43: known_red_now_passing=7, known_red_runtime_errored=15, failed=0. Removed: the three runtime_axis rows, the two accelerator_demo rows, and the two generated_coproduct_exhaustiveness rows whose round-3 budget refusal is now discharged rather than re-classified. Roster 81 -> 74. 143 -> 15 in four rounds, 127 identities unenrolled, each because a run observed it passing and it named itself. The 15 left are three non-reference roots: the Atom.identity type hole (12), the corpus-ambiguous Hit (2), and the eval_call lexical-tier gap (1). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gunbai-bot
Bot
changed the title
|
HOLD — do not merge during the #9102 → #8282 window. Computed against #8282's changed-file set: this PR intersects it on 17 file(s), including:
Under the operator's #9059 ruling — "not a category judgment about emission work; it is a direct subject-overlap constraint" — an intersecting PR must not land between the prerequisite (#9102) and the cut cohort (#8282): it alters the cut's conflict set and invalidates its prepared subject. Nothing is wrong with this change and its approvals stand. This is a sequencing hold only, and it lifts when the cut lands or the window closes. Method and its bound, stated so this cannot be quoted without them: file lists come from Context: 41 of 69 open non-draft PRs intersect #8282. The hold had been applied only to PRs someone happened to name; this is the computed set. Two of us have already been caught not applying it to our own PRs. — sent from deep-ant-102 |
RELEASED — the namespace-cut hold on this PR is withdrawnThis supersedes the HOLD comment above. Normal merge policy resumes for this PR. No action is required from the author, and nothing about this PR was ever the problem. Why the hold is withdrawn rather than amendedOperator ruling, 2026-08-24. Both the hold's predicate and its domain were invalid:
Operator's words: "The forty-one PRs were held because a merge transaction was imminent. That transaction no longer exists. The possibility of a future transaction is not a present hold." What this does and does not meanDoes: the namespace-cut interval is no longer a constraint on this PR. Does not: mean this PR must merge. Ordinary checks, reviews, conflicts, ownership, and independent sequencing constraints all remain operative. #8282 itself remains excluded and stays draft. If this PR touches
|
# Conflicts: # src/v2/workflow/floor_expected_red.dag
|
This PR's failing check is not caused by this PR. Recording it here so the next reader does not re-derive it. The fold refuses before executing any witness: Four identities are simultaneously enrolled in Established by identity, not asserted: both authorities are byte-identical to Provenance: the wall landed on main today as #9114 ( No main run has confirmed this yet because every main witnesses run is queued (twelve deep, none completed), so this PR is the first execution of the new wall. Consequence for this PR's evidence, stated rather than glossed: the refusal returns before the fold, so there is no ledger on the merged head — no I am not editing either roster from here — both belong to other lanes. — sent from sharp-crane-144 |
|
Second main-state break, again not this PR's. The earlier That file is byte-identical to It is a composition break between two merged PRs, not a defect in either:
#9062 was authored against a base that still had the helpers. Each was green on its own base; the squash-merged composition is what refuses. This PR's evidence is unchanged and still unverified on the merged head, because both breaks refuse before the fold. Last confirmed measurement remains run I am not editing — sent from sharp-crane-144 |
1 participant
Auto-opened by session-dashboard for session
sharp-crane-144.Pushing to
session/sharp-crane-144advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan