Repository navigation
NAMESPACE CUT RESTART (XL-N): re-activate the Namespace/Type-Occurrence cutover off CURRENT MAIN only -- #8282's archive is EVIDENCE and never a base; recensus the 8,345 / 48% advisory share AT THE ACTIVATION REVISION rather than inheriting it; no dormant-52% rescope; first evidence-producing act re - #10462
Closed
briansrls wants to merge 28 commits into
Closed
briansrls wants to merge 28 commits into
briansrls wants to merge 28 commits into
Conversation
… of above the module that had to re-spell it
XL-0B's first constraint, discharged. gunbc.type_reference_decl_file_occurrence_census's
kernel-minted-provenance row states it: the KernelMinted arm must be DERIVED from
resolved_node_is_kernel_identity_for_name rather than re-spelled, "because a fifth prefix
test would add an authority while claiming to remove four."
THE FORK WAS POSITIONAL. v1.compiler.infer_env DECLARED that predicate and never called it.
The module that mints the span it tests -- v1.std.core, whose kernel_span synthesizes
"<kernel:NAME>" -- cannot import infer_env without closing a cycle, so
declaration_provenance_of re-derived the same comparison in place. One fact, two spellings,
for no reason but where the declaration sat. The predicate now lives in v1.std.core beside
kernel_span, and declaration_provenance_of reads it.
AND THE SPELLING IT REPLACED WAS THE WEAKER ONE, which the census had not counted. The
infer_env body inlined concat("<kernel:", name, ">"), reproducing kernel_span's output by
hand -- so it was a second authority for the span FORMAT as well as for the identity
question. The relocated body asks kernel_span. Editing that format used to leave the
recognizer answering the old shape with no refusal anywhere; that divergence now has no
constructor.
EVIDENCE, BOTH DIRECTIONS, BY EXECUTION.
ct_kernel_identity_single_authority_test runs in the required rust-unit-tests job under
`cargo test --release -p v1-compiler --lib`. Green as authored. Red under exactly the
mutation it exists to catch -- exact equality replaced by a "<kernel:" prefix test -- failing
on the discriminating row (a node carrying a kernel span for a DIFFERENT name), with a
positive control that stops that row being satisfied by a predicate that had simply stopped
answering true. Enrolled per DESIGN 4b(4): the climb keeps its discriminating red.
That suite is RED ON MAIN independently of this change -- 16 failed / 728 passed on an
unmodified tree at e5a51d6, measured by running the identical command on a clean
checkout before attributing anything here. The failures are host/index-sensitive
(schedule_retention, regen_round_cost, required_floor) and are not touched by this diff.
SCOPE, STATED SO THE LARGER HALF IS NOT READ AS DONE. This discharges the FIRST of the two
constraints the census names. The second is untouched and is bigger: CorpusDeclared still
carries decl_file as a position, so the DeclarationCarrier half std.repair_input_origin
explicitly defers to XL-0B/C is still owed. Both ledger rows are updated to say so and to
cite the predicate at its new home rather than at the stale (and, in state_space_conflation,
never-existent "v1.compiler.env") one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…arse it
The XL-0B receipt I appended to gunbc.type_reference_decl_file_occurrence_census quoted the
spelling it was retiring -- concat("<kernel:", name, ">") -- with RAW double quotes inside a
.dag String literal, which terminates the string and makes the source unparseable. The module
index then refuses the whole corpus, so heal-generated-artifacts could not index the tree and
never reached the regeneration the design-ledger carve-out delegates to it.
The file already uses the escaped form for exactly this; the added row now matches it.
AND THE DIAGNOSTIC'S LOCATION IS A BYTE OFFSET WEARING A LINE NUMBER'S CLOTHES. It reads
`dag/gunbc/type_reference_decl_file_occurrence_census.dag:15713-15714`, and that file is 526
lines in every tree -- main, this head, and the merge result. 15713 is the BYTE offset of the
opening quote of the broken literal. So the span is correct and its RENDERING sends every reader
to a line that does not exist. Filed separately rather than fixed here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…rpolates in a .dag string
The emitter row I added spelled its Rust assertion message with an inline format capture,
`{name}`. Inside a .dag String literal that brace form is INTERPOLATION, so the compiler resolved
a variable `name` that does not exist in ct_kernel_identity_single_authority_test and refused the
v2 self-compile. The bare `{}` placeholder already used elsewhere in this file does not
interpolate, so the message takes an explicit argument instead.
THIS ERROR WAS HIDDEN BEHIND THE PARSE REFUSAL and is the reason the whole-corpus pass matters:
while the module index refused to build, nothing downstream ran, so a second defect in a different
file sat invisible behind the first. Two sequential whole-tree runs were needed to see both, and
neither is visible to a cargo build of the seed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
… offset as a line Filed at the manager's request after gunbc#10350's module-index refusal cited dag/gunbc/type_reference_decl_file_occurrence_census.dag:15713-15714 in a file that is 526 lines in every tree. The span was CORRECT: 15713 is a byte offset, and the path was right. Only the rendering was wrong, and 'path:N-M' declares no unit, so the reader cannot tell which they hold. WHY IT EARNS A ROW RATHER THAN A FIX AT THE SITE. The reader who hit it did the correct diligence -- checked the cited file in main, the PR head and the merge result, confirmed it is not a generated artifact, declined to guess -- and was defeated anyway, authoring two candidate mechanisms (wrong path attribution, corpus-global line index) that were both false and neither eliminable from the log. A diagnostic that defeats correct diligence is the subject, not the quoting bug that surfaced it. It is the fabricated-plausible-output shape applied to a diagnostic's own span, and it is worse than an unlocated refusal rather than better: an unlocated refusal makes the reader search and they know it, while a confidently mislocated one makes them doubt the path and the tool. CEILING is rung 4 and the class is decidable, so the row names the capability rather than an artifact: a span type whose constructors distinguish byte offsets from line-column positions, with renderers deriving format from the constructor. That is a change to the span carrier and every renderer, so it is filed at the grain it must be repaired at rather than patched where it appeared. Carrier only -- docs/design-failure-modes.md is authored by heal per gunbc.generated_artifact's HealRegeneratesAfterProvisionalMerge carve-out. Appended at the END of the roster, per its own source-order rule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
… diagnostics in one night gunbc#10352 found the floor rendering cost=500ms EXACT from an integer-truncated nanosecond measurement -- comparison correct, refusal correct, rendering defective, and it recruited auditors into filing against the comparator. Same shape as this row's byte-offset-as-line, reached from an unrelated subject by a reader who was not looking for it. Two independent instances is what makes the operative rule worth stating: WHEN A LOCATED DIAGNOSTIC POINTS SOMEWHERE IMPOSSIBLE, DISTRUST THE UNITS BEFORE THE LOCATION. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
# Conflicts: # dag/gunbc/recurring_failure_mode/roster.dag
# Conflicts: # docs/design-failure-modes.md
…der the chain forces The regen drift was mine and it was TWO levels, not two files. LEVEL 1 -- v1_compiler_compiler_tests_rust.rs. I added ct_kernel_identity_single_authority_test to src/v1/compiler_tests_rust.dag and never wrote that module's own generated twin. It now carries the new emitter function and its entry in ct_coercion_tests's concat chain. LEVEL 2 -- compiler_tests.rs. Its only difference from the emitter's output was the POSITION of the test: I hand-inserted it before shaped_type_node, the emitter appends it at the end of ct_coercion_tests. Verified as a pure move rather than a content change -- the two files have an IDENTICAL MULTISET OF LINES and equal byte length, differing only in order. THE ORDER OF THE TWO PASSES IS FORCED AND THE NAIVE FIX IS SILENTLY DESTRUCTIVE. compiler_tests.rs is emitted by the seed's COMPILED-IN emitter, so a first-pass candidate is produced by the emitter as it was BEFORE this change -- it cannot emit a test it does not know about. That candidate was 134 lines short, exactly the size of the test, and copying it would have DELETED the enrolled RED while satisfying the drift check: a green PR whose discriminating probe no longer exists. So: pass 1 installs the emitter's own mirror, the seed is REBUILT so the emitter knows the test, and pass 2 produces a compiler_tests.rs that contains it -- 4521 lines, matching, with the test present. Checked rather than assumed: both files are byte-identical to their pass-2 candidates after cargo fmt, so formatting cannot re-introduce drift; the test and its discriminating assertion are present in the committed bytes. Regenerated on top of ce937d0, merged first because #10282 reshapes the marshal and a candidate computed on the older base could have been bytes that fight it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
Ledger APPEND COLLISION, resolved as a union rather than a choice. Main appended two failure-mode rows (denominator_moved_between_measurement_and_comparison, absent_reads_identically_to_never_looked) while this branch appended one (located_refusal_renders_its_span_in_the_wrong_units). Nothing here is a competing edit to a shared row -- three independent appends to one growing ledger -- so taking either side would have DELETED rows that were never in conflict. roster.dag conflicted with markers and both regions are pure appends: the import block and the roster list. Ordered main's two first because they landed first, then this branch's, since the roster is in APPEND order and not alphabetical -- reordering it would have rewritten the whole projection for no reason. docs/design-failure-modes.md conflicted with NO MARKERS, which is the generated-artifact merge driver refusing rather than answering: it leaves the ours side in the worktree and marks the path unmerged. Confirmed by reading the index stages rather than the worktree -- ours carried this branch's one row and none of main's two, theirs carried main's two and not this branch's. So the worktree copy was the pre-merge ours side, and committing it would have silently dropped main's two rows with no conflict ever shown. Rebuilt from the THEIRS side and re-applied this branch's delta: one index bullet and one body row, both placed to match the roster's append order. Verified rather than assumed: no conflict markers survive, each of the three rows appears exactly once, and the index-bullet count equals the roster-entry count at 99 -- the same bijection the projection is supposed to hold. Merge commit rather than the rebase the notice suggested: the repo squash-merges, so branch history is flattened anyway, and a rebase would force-push a head that CI auto-heal has already built on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…emit side reading a resource as a type
TWO SEPARATE THINGS LAND TOGETHER BECAUSE CI IS THE BINDING CONSTRAINT, not because they are one
change: the wave-admission rows this PR's own relocation requires, and the emit-side repair the
type-occurrence census refusal pointed at.
-- THE ADMISSION ROWS --
required-ci refused with `namespace-wave-admission (2 unadjudicated delta(s), 0 stale admission(s),
16 consumed admission(s))`. The two deltas are this PR's whole content:
TargetChanged binding v1.compiler.infer::ancestry_binding_is_kernel_identity
TargetChanged binding v1.compiler.emit_rust::import_name_resolves_to_host_realized_kernel_scalar
both for `resolved_node_is_kernel_identity_for_name`, base {v1.compiler.infer_env} -> head
{v1.std.core}. A relocation MUST produce TargetChanged bindings; the wall refusing until someone
says so out loud is the wall working. They are UNADJUDICATED, not unadjudicatable.
Adjudicated at full identity grain -- module, in_declaration, spelling, target -- one row per delta,
so the count goes 2 -> 0 by naming both subjects and not by widening. A third delta of the same
shape still refuses, which is what makes this distinguishable from erasing the subject.
The rows are born with their own death declared: when this merges, base and head both carry the
relocation, no run can produce these deltas, and both go STALE -- which reds every unrelated PR.
The trigger beside them says explicitly not to trust itself: join each row against MAIN'S tree on
its own tuple, and assert rows-checked equals rows-in-label, because a path guessed from a module
path reads empty and empty reads identically to "the binding is absent" -- the mechanism that
nearly carried 128 rows wrongly on the twenty-sixth entry.
-- THE EMIT-SIDE REPAIR --
The activation-revision recensus refused: CensusUnavailable { cause: DeclarationDomainDisagrees },
two occurrences, `dag/std/resources.dag::Network` and `::AuthContext`. The cause was already
authored in the tree. v1.compiler.parse's classifier gained a resource arm, dropping divergence from
202 items across 100 modules to these two, and its note ends: "Repairing the emit-side shape
predicates is a change to a different authority and is deliberately not smuggled in here." This is
that repair.
Those two resources declare NO capabilities, so they carry no children, no body, no params and no
connective -- they ARE bare leaves by shape, so the emit side read them as type items while the
parser read them as resources. Not instrument-only: all three emitters test is_type_decl_item BEFORE
is_resource_def_item, so both were EMITTED AS TYPE DECLARATIONS and the resource arm was unreachable
for them.
The exclusion DERIVES rather than re-spelling: is_type_alias_item and is_type_decl_item ask
v1.compiler.parse parsed_item_carries_resource_entries, the same single authority the parser asks,
so "what a resource item is" has one definition and these are two consumers of it. Spelling the
shape again here is what produced the divergence.
NOT PLACED IN is_bare_leaf_item, which would have been one site instead of two: that predicate is a
statement about SHAPE, a capability-less resource genuinely IS a bare leaf, and it has consumers
outside these arms whose meaning depends on its params-count claim -- narrowing it would have
silently changed alias hopping instead of resource classification.
AND NOT REPAIRED BY REORDERING THE CHAIN, which would also have greened the census. is_resource_def_item
still COUNTS properties -- the shape parse already had to fix -- so it would claim any sole_constructor
type, masked today only because the type arms run first. Reordering would have ARMED that over 202
items while turning the instrument green. That dormant defect is filed as the failure-mode row
dispatch_correctness_resting_on_arm_order: mitigatable today, ceiling structurally impossible, and
its next-rung trigger names the CAPABILITY -- a positive item kind carried on the emit side, so
dispatch derives as an exhaustive match and cannot be order-sensitive.
-- EVIDENCE --
The enrolled test asserts the composite the census actually joins on -- is_type_def_item OR
is_type_alias_item OR is_type_decl_item -- and not one arm. An earlier draft asserted
is_type_decl_item for a property-free bare leaf and went RED: with no inferred type such an item
reads as a type ALIAS. It is still a type item; the arm was the wrong subject, and a control that
had passed by luck would have shipped a test measuring something other than the refusal.
Four rows: the positive control, the resource discriminator (removing the exclusion turns it true),
an over-correction guard asserting a sole_constructor-only item is STILL a type item so the
exclusion can never be re-spelled as a property count, and a reader-agreement equality that fails
from either side.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
FIVE CONFLICTS, TWO KINDS, RESOLVED DIFFERENTLY BECAUSE THEY ARE DIFFERENT KINDS. namespace_wave_admission.rs is HAND-AUTHORED and its conflict was substantive: main REPLACED the admissions array, deleting the consumed rung-drop rows and adding 19 gunbc#10344 asset-identity rows. Main's array is current truth and this branch's copy was stale, so taking either side whole would have been wrong in opposite directions -- ours resurrects 16 rows main deliberately deleted, theirs drops the two rows this PR needs to be admitted at all. Resolved by taking MAIN's array and re-applying only this branch's delta: the KERNEL_IDENTITY_RELOCATION_LABEL const and its two TransitionAdmission rows. Verified by count rather than by reading: 19 gunbc#10344 rows preserved, 3 references to the new label, zero conflict markers. The other four -- docs/design-failure-modes.md, compiler_tests.rs, v1_compiler_compiler_tests_rust.rs, v1_compiler_emit_rust.rs -- are GENERATED. Their bytes are not authored on either side, so neither side's bytes are evidence of anything. Main's side is taken as a placeholder and the true content comes from regeneration against the .dag authorities, which this branch still holds intact. RAN THE CHECK I OWED FROM THE LAST MERGE, and it is the reason this one is trustworthy. Last time I resolved a generated projection by hand, re-applied the row I had ADDED, and silently dropped a row this branch had EDITED -- invisible to every membership and bijection check, because both sets still matched. So: diff the pre-merge head against the merge result restricted to the paths this branch touches, which is the superset that catches edits and not just additions. Seven files differ, and every one is accounted for -- four generated, one the union above, and two .dag authorities (05_emit_rust.dag, compiler_tests_rust.dag) that differ only because MAIN changed them. Confirmed positively rather than by absence: both test functions present and both wired into the emitter's concat chain, and this branch's citation edit intact. Merge commit rather than rebase: the repo squash-merges, so branch history is flattened anyway, and a rebase would force-push a head CI auto-heal has already built on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…piles before regeneration Taking main's side of the four generated artifacts during the merge was wrong in a way the merge itself could not show. v1_compiler_emit_rust.rs on main still calls crate::v1_compiler_infer_env::resolved_node_is_kernel_identity_for_name -- the symbol THIS BRANCH MOVED to v1.std.core -- so the merged tree did not compile, and a tree that does not compile cannot be regenerated. The plan 'take theirs, regen will supply the truth' has a precondition I did not state: regen must be able to BUILD, and the file breaking the build was the one waiting to be regenerated. Restored all four from this branch's pre-merge head, which is a compiling tree. These bytes are still not authored on either side and are not the answer -- they are a build-able starting point so the regeneration can produce the real ones from the merged .dag authorities, which carry both this branch's relocation and main's changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…this branch's three-substitution delta NEITHER SIDE OF v1_compiler_emit_rust.rs COMPILES AGAINST THE MERGED TREE, which is why two regen attempts died at 127 with no regeneration running at all. Main's copy calls crate::v1_compiler_infer_env::resolved_node_is_kernel_identity_for_name -- the symbol this branch moved -- and fails E0432. This branch's copy predates main's call-arity change and fails E0061. The file that must be regenerated is the file preventing the build that produces the regenerator. Broken by applying THIS BRANCH'S DELTA to MAIN'S BYTES, counted rather than eyeballed: three substitutions, each asserted to occur exactly once before replacement -- drop the spelling from the v1.compiler.infer_env re-export list, add it to the v1.std.core import list in the slot this branch uses, repoint the single call site. Post-conditions asserted: zero stale references remain, exactly one repointed reference exists. The re-wrap that follows is cargo fmt's, not mine: the pre-commit hook refused the hand edit until the import list was re-wrapped, which is the hook catching exactly the class of damage hand-editing a generated file does. The other three generated artifacts are taken from main verbatim, because none references the moved symbol and none needs a delta to build. Confirmed rather than assumed for compiler_tests.rs, which is the one that could have. THESE BYTES ARE A BOOTSTRAP, NOT THE ANSWER. The regeneration that follows overwrites all four from the merged .dag authorities. If the regenerated bytes differ from these, the regenerated ones are right. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…generate One conflict, and it is the append-collision class again: main landed append_only_carrier_whose_serialization_shares_a_merge_region -- which is a row ABOUT this exact failure -- while this branch carries located_refusal_renders_its_span_in_the_wrong_units and dispatch_correctness_resting_on_arm_order. Three independent appends to one growing list, so the union is the only resolution that loses nothing; either side taken whole deletes rows that were never in conflict. Ordered main's row first because the roster is in APPEND order and main's has LANDED while this branch's two have not. Verified by identity and by cardinality together: 101 row files, 101 roster entries, 101 imports, and each of the three rows present exactly twice -- once as an import, once as an entry. docs/design-failure-modes.md auto-merged without a conflict this time, and that is precisely when a generated projection is most dangerous: a clean auto-merge of generated bytes is not evidence that those bytes are what the generator emits. It is left to the regeneration rather than trusted, which is the rule this branch learned by breaking it -- a hand-resolution that dropped an edited row while every membership check still passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
Merged cleanly with no driver refusal, so the corrected route in #10383 did not fire here. Its verification step was run anyway, because the check is cheap and the failure it catches is invisible: set difference of the projection's row identities, main MINUS the merge result, is EMPTY -- no row went dark. Counts are not used as the check; a count says a number moved, only the difference names WHICH rows died. The projection is behind its authority by this branch's two rows, which is the authority-ahead-of-artifact state regeneration repairs and the generated-artifact gate can see. The state that nothing downstream can see -- a deletion -- is absent, and that is what was verified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…roduced the generator exactly The four generated artifacts now carry what --required-regen emits from the merged .dag authorities, produced by the forced two-pass order: install the emitter's own mirror, REBUILD so the emitter knows the new test, then regenerate the file it emits. A single pass emits compiler_tests.rs from the PRE-EDIT emitter, which cannot know a test that was just added. THE BOOTSTRAP WAS EXACT, AND THAT IS A RESULT RATHER THAN AN ASSUMPTION. v1_compiler_emit_rust.rs is ABSENT from this commit: the regenerated bytes are identical to the hand-applied bootstrap, so the three counted substitutions reproduced the generator's output precisely. Had they differed, the generator's bytes would have won and this commit would say so. VERIFIED BY EXECUTION, NOT BY COMPILE: cargo test --release -p v1-compiler --lib on the regenerated tree runs a_resource_item_is_not_read_as_a_type_item and it PASSES. The over-correction guard -- a sole_constructor-only item must still read as a type item -- is present in the emitted bytes, so the exclusion cannot be silently re-spelled as a property count without this going red. Both files are byte-identical after cargo fmt, so formatting cannot re-introduce drift. docs/design-failure-modes.md is deliberately NOT updated here. --required-regen does not emit it -- a run where all four .rs mirrors installed cleanly produced no projection candidate at all -- because that artifact is heal's under the design-ledger carve-out. The tree therefore lands authority-ahead-of-artifact on that one file BY DESIGN: the roster carries 101 rows and the projection 99. That is the state heal repairs and the generated-artifact gate can see. The state nothing downstream can see -- a row deleted -- was checked for by set difference against main and is absent. THE 16 SUITE FAILURES ARE MAIN'S, ESTABLISHED BY AN IDENTITY JOIN AND NOT BY A COUNT. Two trees on one runner, preconditions asserted before the comparison was trusted: the patch present in one (4 references) and absent in the other (0), and the two tree shas required to differ. Failing test NAMES compared as sets: mine MINUS main is EMPTY, main MINUS mine is EMPTY. An earlier attempt at this join was VACUOUS -- both arms silently measured the same tree, which guarantees identical sets by construction and looked exactly like the answer. Two sets of sixteen can be disjoint, so the count match established nothing on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…thority-ahead-of-artifact gap The remote tip 7f46e2c is a CI auto-heal commit that landed while this work was held locally, and it carries exactly the artifact --required-regen does not emit: docs/design-failure-modes.md regenerated to 101 rows, INCLUDING both of this branch's two. So the gap the previous commit declared -- roster 101, projection 99, repaired by heal under the design-ledger carve-out -- is closed here rather than after the next CI cycle. The carve-out worked as declared; this merge just collects the result. Verified after the merge rather than assumed: projection 101 rows and roster 101 entries, both new rows present in the projection exactly once, and the #10383 set-difference check -- rows on main MINUS rows here -- EMPTY, so nothing went dark. Source work confirmed present by count on all three carriers: the emit-side exclusion, the enrolled test in the emitted bytes, and the admission label. Merged rather than force-pushed over: heal's commit is real work on a shared branch, and a force push would have discarded a regeneration this branch needed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…ion the admissions array TWO CONFLICTS, TWO DIFFERENT RESOLUTIONS, AND THE GENERATED ONE FOLLOWS #10383's CORRECTED ROUTE. docs/design-failure-modes.md conflicted with ZERO markers, which is the generated-artifact driver REFUSING rather than answering: it leaves the OURS bytes in the worktree and marks the path unmerged. Staging what is sitting there is the move #10383 measured as destructive -- four of five heads that did it silently dropped rows. So the BASE side is taken verbatim via `git checkout origin/main --`, and the result is verified BY SET DIFFERENCE rather than by count: rows on the base MINUS rows here is EMPTY, so no row went dark. A marker count would have established nothing here, because zero markers is exactly what this driver GUARANTEES on a refusal. That leaves the tree authority-ahead-of-artifact by this branch's two rows -- roster 101, projection 99 -- which is heal's to close under the design-ledger carve-out and which the generated-artifact gate can see. It is the deliberate cost of the safe resolution: the deletion is what nothing downstream can detect, and the deletion is what was avoided. Heal has already closed this same gap once on this branch, at 7f46e2c. namespace_wave_admission.rs is HAND-AUTHORED and conflicted substantively: main deleted the nineteen gunbc#10344 asset-identity rows as CONSUMED and recorded a TWENTY-FOURTH DISSOLUTION entry for them, while this branch still carried them. Main's array is current truth; taking this branch's side would have resurrected nineteen rows main deliberately retired. Resolved by taking MAIN's array and re-applying only this branch's delta -- the KERNEL_IDENTITY_RELOCATION_LABEL const and its two TransitionAdmission rows. Verified by assertion rather than by eye, and the assertions caught two off-by-one slices before anything was written: exactly two rows carrying this branch's label, zero gunbc#10344 rows surviving, main's dissolution entry preserved, the extracted block ending on a closing brace, and zero conflict markers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
…e module emit-core hosts can reach the authority it asks Main parses again at 159421d (#10428 re-attached the annotation #10390 orphaned), so this is the one integrate-main push, carrying the build repair with it. THE BUILD FAILURE THIS FIXES, AT ITS ROOT RATHER THAN AT ITS SYMPTOM. v1_compiler_emit_core_support is compiled TWICE from one file: once inside v1-compiler, where crate::v1_compiler_parse resolves, and once inside v1-stage0-emit-core via #[path], where the crate root offered eight modules and parse was not one of them. Its reachable set is the INTERSECTION of two crate roots, so consuming the parser's single authority for "is this item a resource" compiled in one and E0432/E0433'd in the other. The emit-core crate's own generated doc says it exists to host that module "without copying semantics". The missing name was defeating that: the alternatives were to FORK the predicate into a module that cannot see the minting vocabulary it is defined against, or to SCATTER the exclusion across the call sites. So the boundary was the defect, not the predicate, and the fix is to make the root set true rather than to work around it. WHY NOT THE OTHER ARMS, since a reviewer meeting a partition edit inside a namespace-cut PR should not have to reconstruct this. MOVE the predicate down beside Node. Rejected: it is defined NEGATIVELY over parse's minting vocabulary -- true if any property's name is not "sole_constructor" -- so it is a statement ABOUT that vocabulary, and v1.compiler.parse's own note scopes it "complete against the parser's minting vocabulary AS OF THIS COMMIT". A definition whose truth is maintained by a module it cannot see is a fork with a delay on it. APPLY THE EXCLUSION IN THE CALLERS. Rejected on its own measurement. The hypothesis was four call sites; the enumeration is 24 call expressions in 12 functions across v1.compiler.emit_rust (19/9), emit_go, emit_python, trait_derive_emit, plus the census reader. Twelve hand-applied exclusions is twelve places the next property-minting modifier reintroduces the defect with nothing watching -- verbatim the failure parse's note predicts. WHAT LANDS. v1_compiler_parse joins the v1-infer unit and std_import joins std-core, chosen for LAYER: parse is a pipeline stage and sits beside v1_compiler_coercion and the infer modules. parse is a SOURCE in that unit -- nothing there is reachable from it -- so the unit graph gains no edge back, and validate_partition_r4 adjudicates that mechanically via SccSplit/UnitGraphCycle rather than by this paragraph. Every generated artifact in the chain was regenerated through its authority: the roster by the generated-artifact gate, the stage0 mirrors by --required-regen, the crate manifests and lib roots by --emit-partition-crates. No hand-edited generated bytes. THE TRANSITIVE CLOSURE IS THE CHECK, NOT THE IMMEDIATE DEPENDENCIES. An earlier report of this change said parse depends on eight modules and std_import on two. That is the immediate set and it passes cleanly on a closure that fails two levels down. The transitive closure of both seeds is 29 modules; 27 are already partitioned and the 2 remaining are the seeds themselves, so nothing else is dragged in -- corroborated independently by the emitter, which drifted three lib roots and NO Cargo manifest, meaning no new inter-crate dependency was required. THE ADMISSION ENTRY WAS RE-APPLIED ACROSS THIS MERGE, NOT CARRIED. The conflicting hunk was a misaligned array head -- this cohort's label line against the SCM cohort's, with the body below the marker belonging to the other subject -- so resolving the markers in place would have spliced one cohort's rows onto another's body. Main's file was taken whole and the delta re-derived at ROW IDENTITY grain against the merge base: 2 added here, 0 removed, against main's 29 additions and 254 removals. Merged array is 32 rows, no row of either side dark. The entry is renumbered TWENTY-THIRD and its citation of the now-dissolved twenty-sixth entry repointed, because #10355 deleted the entry it named. Verified by execution on the merged tree, not by inspection: cargo build green with the repair present and reached, cargo clippy --all-targets -D warnings clean, and compiler_tests::a_resource_item_is_not_read_as_a_type_item passing with its positive control, resource discriminator, sole_constructor over-correction guard and two-reader agreement assertion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
… the infer mirror from the merged authority Second integrate-main cycle on this branch. #10350 was CONFLICTING, which is not merely a merge chore: GitHub cannot compose refs/pull/N/merge for a conflicting PR, so no pull_request event is built and ZERO runs are created -- measured, total_count=0 for head 5250ea6. The stale composed tree GitHub kept serving (still carrying #10390's orphaned annotation, long after #10425 repaired it on main) is a SYMPTOM of the same missing ref, not a second defect. Both end here. dag/gunbc/recurring_failure_mode/roster.dag -- UNION, and union is correct here for a reason worth stating, because the same resolution authored a real defect on main tonight. This roster is an append-only SET whose entries are independent rows, so keeping both sides preserves two unrelated appends. The duplicate annotation preambles now sitting in main came from union-resolving a PROSE BLOCK, where "keep both sides" mints a second authority for one statement. Same resolution, opposite correctness, and what decides it is whether the file is a set or a narrative. Verified at row identity rather than by count: HEAD 102 rows, main 105, merged 107 = exactly the union, zero dark from either side, zero invented, and every roster entry has a matching import. src/v1/stage0/src/v1_compiler_infer.rs -- NOT hand-resolved. It is a generated mirror and #10402 landed on it while this branch moved resolved_node_is_kernel_identity_for_name out of the infer_env import block. The authority src/v1/04_infer.dag auto-merged clean, so the mirror was taken base-side and RE-DERIVED from the merged authority by --required-regen (planned=156 executed=156 adjudicated=156, drift reported on exactly lib.rs and this file). The check that a hand merge cannot pass: the derived mirror DIFFERS FROM BOTH PARENTS -- 87 changed lines against this branch, 59 against main. Had either side's delta been dropped it would have come out identical to one of them. dag/test/claim/emit_copy_qualification_witness_test.dag needed no resolution and got none: this branch has no changes to it, and the merged worktree copy is byte-identical to main's 565-line repaired file. Verified on the merged tree: cargo clippy --all-targets -- -D warnings clean, and compiler_tests::a_resource_item_is_not_read_as_a_type_item green against a test binary built AFTER the mirror was re-derived (checked by mtime, since an unchanged cargo metadata hash does not mean an unchanged binary). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
The namespace-wave-admission phase refused with `0 unadjudicated delta(s), 0 stale admission(s), 30 CONSUMED ADMISSION(S) DUE FOR DELETION ON THIS ROSTER-TOUCH`. The zero/zero half is the good reading -- this branch's own namespace work is clean. What refuses is the obligation the roster imposes on whoever touches it next: #10355 is in this branch's base, so its rows are satisfied at the base, and a consumed row comes due on the roster's own next touch. This change touches it. ADJUDICATED BY THE DECLARING-MODULE JOIN, NOT BY THE TRIGGER SENTENCE, because the entry being retired says in terms that a trigger sentence is not evidence the trigger fired. Each row was joined against MAIN's tree by its own (module, in_declaration, spelling, target) tuple: 30 of 30 name a spelling DECLARED in gunbc.scm.proposal, none open. Rows checked equals rows in label equals the count the wall reported -- 30 = 30 = 30 -- so the subject was not silently narrowed by a parser that could not see some of it. ONE OF THIS FILE'S TWO RECORDED JOIN FAILURE MODES ACTUALLY FIRED. RequireBinding and RequireBindingAbsent are COPRODUCT VARIANTS rather than data/fn/type declarations, so a declaration index reading only line-start declarations would have answered "not found" for both -- indistinguishable from "not declared", which is precisely the defect the TWENTY-NINTH DISSOLUTION records catching on its second pass. The join resolves variants and fields as well as declarations, and it was CALIBRATED rather than trusted: MergeCommit, ObjectStore and a fabricated name all answer NOT DECLARED against the same module, so a uniform "found" was not available to it. The two gunbc#10350 kernel-identity rows REMAIN. They are not consumed: this PR has not merged, so the base does not carry the relocation and the deltas are still producible. Their own deletion is owed to the first roster-touch after this lands, by the same join. SCM_PROPOSAL_VOCABULARY_LABEL is deleted with its rows, and the cohort's entry is retitled as the THIRTIETH DISSOLUTION recording the adjudication, including what the hand join does NOT establish: it is a necessary condition only, since admission_consumed_at_base resolves the full subject through the re-export chain and requires an exact singleton, which no hand join reproduces. The wall's own run at the exact head is the proof. The remaining required-witnesses-floor red is NOT addressed here and is not this branch's: STALE-QUARANTINE on test.claim.declared_type_expected_type_path_witness, inherited from #10402 landing a wall without retiring the expected-red row it greened. It is owed a standalone repair; carrying it here would put main's recovery inside a feature PR that is separately blocked on review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vz8ESEVFC7Cox1xAaXudg
… quarantine # Conflicts: # src/v1/stage0/src/v1_compiler_infer.rs
briansrls
marked this pull request as ready for review
September 4, 2026 19:59
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
|
Closing: this is an auto-opened PR over already-merged work, and merging it would revert the repository. Its head Measured rather than assumed — this head is 8 commits behind main and a three-dot diff against current main is 59 files, 2580 insertions, 528 deletions. It lacks:
So the "change" this PR proposes is the deletion of every one of those. It reads as a live PR carrying its lane's original brief in the title, which is exactly what makes the shape dangerous: the title describes work that was completed and landed, not work being proposed. It is currently No action is needed from anyone. Closing, and deleting the branch so it cannot re-arm. — sent from bright-ram-778 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9e41b5c2d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| why_the_positional_form_was_reached_for: "a kernel-minted type has NO declaration in the corpus -- v1.std.core kernel_span synthesizes the pseudo-file `<kernel:Name>` -- so there is genuinely no symbol for a citation to name. The path-shaped channel was already there, so the state was encoded as a value inside it.", | ||
| authority: NoSymbolAuthorityExists { | ||
| what_would_have_to_exist: "a provenance coproduct carrying the three states this String conflates -- a corpus declaration (a DeclarationRef), a kernel mint (a name with no declaration), and identity unavailable -- so that kernel-minted is a CONSTRUCTOR rather than a spelling recognised by substring. TWO CONSTRAINTS ON BUILDING IT, both established rather than assumed. FIRST, the KernelMinted arm must be DERIVED from v1.compiler.infer_env resolved_node_is_kernel_identity_for_name, which already owns kernel identity by EXACT EQUALITY and whose own note records that a substring or prefix test is a second, weaker authority for it; a fifth prefix test would add an authority while claiming to remove four. SECOND, std.repair_input_origin was read for this purpose and does NOT already model this axis: it partitions the same String by PRODUCER (six emitter surfaces, CandidateSpelling bare vs qualified), and its own header states that the source branch is deliberately named Candidate rather than DeclarationCarrier because carrying a DeclarationRef is deferred to XL-0B/C. So the provenance coproduct is the DeclarationCarrier half that module explicitly defers, and belongs beside it as that deferral discharged -- not coined as a rival.", | ||
| what_would_have_to_exist: "a provenance coproduct carrying the three states this String conflates -- a corpus declaration (a DeclarationRef), a kernel mint (a name with no declaration), and identity unavailable -- so that kernel-minted is a CONSTRUCTOR rather than a spelling recognised by substring. TWO CONSTRAINTS ON BUILDING IT, both established rather than assumed. FIRST, the KernelMinted arm must be DERIVED from resolved_node_is_kernel_identity_for_name, which already owns kernel identity by EXACT EQUALITY and whose own note records that a substring or prefix test is a second, weaker authority for it; a fifth prefix test would add an authority while claiming to remove four. THIS FIRST CONSTRAINT IS DISCHARGED (XL-0B, 2026-09-04): the predicate was relocated from v1.compiler.infer_env -- which declared it, never called it, and sat ABOVE the module whose kernel_span mints the span it tests -- into v1.std.core beside that minter, and v1.std.core declaration_provenance_of now reads it rather than re-deriving the comparison. Cite it at v1.std.core; the infer_env spelling is gone. The relocation also removed a second authority the census had not counted: the infer_env body inlined concat(\"<kernel:\", name, \">\") rather than calling kernel_span, so it was a rival spelling of the span FORMAT as well as of the identity question. Enrolled evidence, green as authored and red under exactly the prefix-test mutation, is v1.compiler.compiler_tests_rust ct_kernel_identity_single_authority_test, which executes in the required rust-unit-tests job under cargo test --release -p v1-compiler --lib. WHAT REMAINS UNDISCHARGED IS THE SECOND CONSTRAINT AND IT IS THE LARGER HALF: CorpusDeclared still carries decl_file as a position, so the DeclarationCarrier half std.repair_input_origin defers is still owed. SECOND, std.repair_input_origin was read for this purpose and does NOT already model this axis: it partitions the same String by PRODUCER (six emitter surfaces, CandidateSpelling bare vs qualified), and its own header states that the source branch is deliberately named Candidate rather than DeclarationCarrier because carrying a DeclarationRef is deferred to XL-0B/C. So the provenance coproduct is the DeclarationCarrier half that module explicitly defers, and belongs beside it as that deferral discharged -- not coined as a rival.", |
There was a problem hiding this comment.
When the kernel-identity predicate regresses, this test will not run on pull requests: the checked .github/workflows/witnesses.yml invokes cargo clippy --all-targets but contains no cargo test, and README.md:178 explicitly records that cargo test --release -p v1-compiler --lib is not run by CI because the rust-unit-tests job was deleted. Calling the test “enrolled evidence” in a required job therefore overstates the protection and can leave this census treating the behavior as guarded while a regression still merges; either enroll it in a required lane or record it as local-only coverage.
Useful? React with 👍 / 👎.
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.
Auto-opened by session-dashboard for session
quick-ant-643.Pushing to
session/quick-ant-643advances 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