One file-transport realization authority: delete the two-spelling subject by gunbai-bot[bot] · Pull Request #10142 · gunb-ai/gunbc

gunbai-bot · 2026-09-02T23:23:32Z

The subject this deletes

Filesystem.WriteCreateNew had two Rust realizations: a hand-written
write_file_create_new in the seed interpreter, and a string of Rust source in
v1.compiler.emit_rust inlined into every compiled program.

Review 5089156132 on #10069 measured what that costs. Finding 3 repaired the interpreter
to stage-then-publish while the emitted spelling still opened the target directly, so a
failed emitted write left a partial repository the model reported as never created.
Repairing the reachable authority left the other lying — §4b rung honesty, where a class's
rung is the minimum across its paths.

#10069 brought the two back into agreement by hand, and its own annotation admitted that
nothing but review held them there. This is the construction that replaces the review. The
designated SCM reviewer commissioned it as the gate before any new write consumer,
because landing add/commit against a duplicated realization makes the old spelling the
attractor the replacement-migration doctrine warns about.

The seam is a complete named function, not a block

My first proposal kept the emitted bare block and taught the seed to build a function from
it. The reviewer refused it, correctly: that translator must know what the block assumes in
scope and how its result channel maps onto io::Result, which makes it a third
hand-maintained authority on the seam — worse than the fork it replaces, because a fork
fails loudly the moment the sides disagree while a translator keeps producing something
plausible from inputs it has misunderstood.

So extdeps.filesystem.rust_realization holds one complete named definition, and both
consumers copy its exact bytes. Verified by an executed control that compares the two
committed projections — byte-identical, exactly once each — not by trusting a regeneration
receipt, which is a different property. No byte count is quoted here on purpose: a transcribed
length is a receipt that rots the moment the definition changes, and it already did (the figure
said 953 after the block had grown past 1,500). Byte EQUALITY is the stable claim; the test that
re-derives it is the instrument. (It was not identical at first: the row wrote the OpenOptions chain
on one line and one copy is committed through a path rustfmt normalizes. The row is now
authored in rustfmt's own shape, which is why that formatting is load-bearing.)

Three files carry the definition; only one is authored

Worth stating plainly, because grep makes this look like the PR failed its own goal. The
text appears in filesystem_rust_realization.dag, in gunbc_file_transport_generated.rs,
and in src/v1/stage0/src/v1_rt.rs. The first is the authority. The second is the
seed's enrolled generated artifact. The third is the committed projection of
v1.compiler.runtime_rust — dag/gunbc/generated_projection_paths.dag lists v1_rt.rs
among the files that are generated rather than hand-maintained.

So these are shared reads of one authority, not parallel authorities: no one edits the
second or third, and both are regenerated and drift-gated. That is the distinction the PR
turns on, and it is the reason the number of copies is not the measurement — what matters
is how many of them anyone can author, which is one.

It returns `io::Result<()>`, not the transport tuple

The reviewer's one adjustment, and the reasoning is not seed ergonomics: the
(success, content, error, byte_count) tuple is the File transport's result-channel
policy. Making it canonical would stringify std::io::Error inside the realization and
discard the host's structured failure before any consumer asked for that loss. Each
consumer projects the outcome into the channel it owns — ordinary consumer code, not a
second implementation.

Why the runtime module, and a correction

I told the reviewer emit_non_empty_wrappers answered the emission-site question. It
answers where a definition goes once; it does not make it reachable. The seed splits
into ~8 partition crates that re-export only what stage0_crates names explicitly —
NonEmptyVec is mirrored by name for exactly this reason — so crate:: resolved in the
monolithic crate and failed E0432 in every partitioned one. I found that by compiling, not
by reading.

v1_rt is the route that reaches all of them: emit_prelude already emits
use crate::v1_rt; into every module, and the runtime is already mirrored into the
foundation crate. It also sits beside rt_filesystem(), where the filesystem runtime lives.

The staging collision, closed in the one place that now exists

Review 58836 found {path}.gunbc-create-{pid} is unique per target but not per thread.
Two threads racing one target collided on the temporary, so the loser reported EEXIST
against an internal name it never asked to write — a refusal that does not locate itself at
the operator's subject; and if the winner then failed too, both could refuse with nothing
published. A process-wide atomic sequence gives each attempt its own staging name, so the
loser now falls through to hard_link and refuses on the real target.

Its control is deterministic because the obvious one is a decoration. Racing N threads
and asserting one winner passes under the defective naming too — same verdict, same
ErrorKind, no information. The discriminating control instead plants exactly the staging
file the old rule would derive and leaves the target absent: the old rule refuses a
legitimate create, the sequence lets it proceed.

Mutation-proven: reverting the row to PID-only naming turns
a_leftover_staging_file_does_not_refuse_a_legitimate_create red while the N-thread
race stays green — which is the measurement showing which of the two carries
information. The race is kept beside it as the positive control.

The staging name is allocated, not calculated

The first revision derived the candidate from (pid, sequence) in one shot. That makes it
unique among live calls in one process; it does not make an occupied candidate
unobservable. This function deliberately ignores removal failure after publication, so
stale staging files are an admitted physical state, and a later process may reuse the pid
and restart its sequence at zero. A one-shot candidate returning its own AlreadyExists
therefore reproduces the identical #10069 defect — target absent, legitimate create refused
because an internal filename was occupied — at a frequency low enough to be harder to
observe. That is the external reviewer's finding, and it is correct; I had missed it.

The loop now allocates: an occupied candidate is skipped and the next tried, any other
open error is the host's and returns unchanged, and exhaustion is checked and refuses with
the distinct StagingCandidateBudgetExhausted diagnostic under ErrorKind::Other — a distinct
diagnostic, not a typed Rust cause, since there is no payload to downcast to. The occupied arm does not
remove the file it found — that file belongs to another attempt, and deleting it would
convert a naming collision into data loss.

My own control could not have caught this: it plants the PID-only name #10069 used, which
under the current rule is not a candidate at all, so it passed without ever exercising an
occupied candidate. It proved the literal suffix changed, not that the class closed. The
new control an_occupied_staging_candidate_is_skipped_rather_than_refused plants the first
candidate the current rule derives, in a RE-EXECUTED test binary so the sequence is known to start
at zero, and requires the operation to skip it, acquire the next, publish the target, and
leave the planted file untouched. The old control stays beside it as #10069's historical
mutation.

Projection identity executes, it is no longer an annotation

The first revision proved byte identity by a one-time manual comparison and explained in an
annotation why rustfmt shape is load-bearing. An annotation cannot be the enforcement — no
Accepted program reads one (§4c) — and a future rustfmt release or generator edit could
reopen the difference without touching the authority, with nothing to say so.
both_projections_carry_the_one_authority_verbatim compares the canonical constant-plus-function
block — not the function alone — and asserts it appears in
emitted v1_rt exactly once, that the two extracted byte ranges are identical, and that
the seed artifact is already at rustfmt's fixed point — the last of which nothing else
would notice, since fmt as a merge gate is a declared §4b(3) rung drop.

This is not the forbidden equality witness: that pins two independently authored
implementations to each other. There is one implementation here, and this checks its two
projections carry it unchanged — necessary precisely because one path passes through an
external canonicalizer this repo does not own.

It earned its keep on its first run, going red on real drift: the gate had regenerated the
seed artifact with the allocation loop while v1_rt still carried the one-shot, because
wet-actuator artifacts and emitted mirrors regenerate through different commands. The
manual comparison it replaces would have passed when run and said nothing.

Enrollment

The seed's copy is enrolled by symbol: FileTransportRealizationGeneratedRsArtifact,
a variant of gunbc.generated_artifact's artifact type, carrying its location,
commit-requirement, equality and emit rows, a WetActuatorGeneratedRegistration in the
crate layout, and merge-driver enrollment in .gitattributes — so drift is refused by the
gates rather than noticed by a reviewer, which is the property #10069's residue note said
was missing.

Stating that as "151 rather than 150" would be the wrong citation: a roster count is an
observation of this tree at this moment, invalidated by any unrelated artifact landing
or leaving, while the registered identity is the stable fact and is the thing a reader can
grep. That is §3's cite-the-symbol rule applied to a roster rather than to a line.

Verified by execution

check	result
`required-ci --required-lane build`	`adjudicated=37 matches=37 drifted=0 absent=0`, `failed=0`
`required-regen`	`first_generation_equal=true`, every rostered artifact adjudicated
`required-regen-fixed-point`	`fixed_point_equal=true`
`cargo clippy --all-targets -- -D warnings`	clean
`cargo fmt --all --check`	clean
`cargo test -p v1-compiler --lib write_file_create_new`	10 passed, 0 failed
committed-copy comparison	byte-identical

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

…ject `Filesystem.WriteCreateNew` had TWO Rust realizations. The seed interpreter carried a hand-written `write_file_create_new`; v1.compiler.emit_rust carried a string of Rust source inlined into every compiled program. Review 5089156132 on gunbc#10069 measured the consequence: finding 3 repaired the interpreter to stage-then-publish while the emitted spelling still opened the target directly, so a failed emitted write left a partial repository the model reported as never created. Repairing the reachable authority left the other lying -- section 4b rung honesty, where a class's rung is the MINIMUM across paths. #10069 brought them back into agreement BY HAND and said so: nothing but review held them there. This is the construction that replaces the review, commissioned by the designated SCM reviewer as the gate before any new write consumer, because landing add/commit against a duplicated realization makes the old spelling an attractor. THE SEAM IS A COMPLETE NAMED FUNCTION, NOT A BLOCK. My first proposal kept the bare block and taught the seed to build a function from it; the reviewer refused it and was right. That translator would have to know what the block assumes in scope and how its result channel maps onto io::Result, making it a THIRD hand-maintained authority on the seam -- worse than the fork, because a fork fails loudly when the sides disagree while a translator keeps producing something plausible. So extdeps.filesystem.rust_realization holds one complete named definition and both consumers copy its exact bytes. VERIFIED BY COMPARING THE COMMITTED ARTIFACTS, not by trusting a regen receipt, which is a different property: 953 bytes on both sides, byte-identical. IT RETURNS io::Result<()>, NOT THE FILE RESULT TUPLE, per the reviewer's one adjustment. The tuple is the File transport's result-channel POLICY; making it canonical would stringify std::io::Error inside the realization and discard the host's structured failure before any consumer asked for that loss. Each consumer projects the outcome into its own channel -- ordinary consumer code, not a second implementation. THE DEFINITION LIVES IN THE RUNTIME MODULE, AND A CRATE-ROOT ONE WOULD NOT WORK. I told the reviewer emit_non_empty_wrappers answered the emission-site question. It answers where a definition goes once; it does NOT make it reachable. The seed splits into ~8 partition crates that re-export only what stage0_crates names explicitly -- NonEmptyVec is mirrored by name for exactly this reason -- so `crate::` resolved in the monolith and failed E0432 in every partitioned crate. v1_rt is the route that reaches all of them: emit_prelude already emits `use crate::v1_rt;` everywhere, and the runtime is already mirrored into the foundation crate. It also sits beside rt_filesystem(), where the filesystem runtime lives. THE STAGING NAME CARRIES A SEQUENCE, closing review 58836's finding in the one place that now exists. `{path}.gunbc-create-{pid}` was unique per TARGET but not per THREAD, so two threads racing one target collided on the TEMPORARY and the loser reported EEXIST against an internal name it never asked to write -- a refusal that did not locate itself at the operator's subject, and if the winner then failed too, both could refuse with nothing published. THE CONTROL FOR IT IS DETERMINISTIC BECAUSE THE OBVIOUS ONE IS A DECORATION. Racing N threads and asserting one winner PASSES under the defective naming: same verdict, same ErrorKind, no information. So the discriminating control plants exactly the staging file the old rule would derive and leaves the TARGET ABSENT -- the old rule refuses a legitimate create, the sequence lets it proceed. Mutation-proven: reverting the row to PID-only naming turns `a_leftover_staging_file_does_not_refuse_a_legitimate_create` RED while the N-thread race stays green, which is the measurement that shows which of the two carries information. Seed projection is an enrolled generated artifact (location, commit-requirement, equality and emit rows, a WetActuatorGeneratedRegistration, and merge-driver enrollment in .gitattributes), so drift is refused by the gates rather than noticed by a reviewer. Verified by execution: required-regen first_generation_equal=true, 151/151 adjudicated required-regen-fixed-point fixed_point_equal=true cargo clippy --all-targets -- -D warnings clean cargo fmt --all --check clean cargo test -p v1-compiler --lib write_file_create_new 5 passed, 0 failed Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

Two required changes from external review of the first revision, and the first of them is a defect I had missed rather than a refinement. ALLOCATION, NOT CALCULATION. A per-attempt sequence makes the staging name unique among LIVE calls in one process. It does NOT make an occupied candidate unobservable, and this function deliberately ignores removal failure after publication, so stale staging files are an ADMITTED physical state -- and a later process may reuse the pid and restart its sequence at zero. A one-shot candidate returning its own AlreadyExists therefore reproduces the identical #10069 defect -- target absent, legitimate create refused because an INTERNAL filename was occupied -- at a frequency low enough to be harder to observe. So the loop allocates: an occupied candidate is skipped and the next tried; any other open error is the host's and returns unchanged; exhaustion is CHECKED and refuses with a typed cause rather than wrapping onto a sequence already used. The occupied arm does not remove the file it found -- that file belongs to another attempt, and deleting it would convert a naming collision into data loss. MY OWN CONTROL COULD NOT HAVE CAUGHT THIS. The previous test plants the PID-only name #10069 used, which under the new rule is not a candidate at all, so it passes without ever exercising an occupied candidate -- it proved the literal suffix changed, not the class closed. The generalized control plants the FIRST candidate the CURRENT rule derives, in a forked child so the sequence is known to start at zero, and requires the operation to skip it, acquire the next, publish the target, and leave the planted file untouched. The old control is kept beside it as the historical mutation for #10069's naming. PROJECTION IDENTITY NOW EXECUTES. The first revision proved byte identity by a one-time manual comparison and explained in an annotation why rustfmt shape is load-bearing. An annotation cannot be the enforcement: a future rustfmt release or generator edit could reopen the difference without touching the authority, and nothing would say so. The witness asserts the definition appears in emitted v1_rt exactly once, that the two extracted byte ranges are identical, and that the seed artifact is already at rustfmt's fixed point -- the last of which nothing else would notice, since fmt as a merge gate is a declared rung drop. This is NOT the forbidden equality witness: that pins two independently authored implementations to each other. There is one implementation here, and this checks its two PROJECTIONS carry it unchanged -- necessary precisely because one path passes through an external canonicalizer this repo does not own. IT EARNED ITS KEEP IMMEDIATELY. On its first run it went red on real drift: the gate had regenerated the seed artifact with the allocation loop while v1_rt still carried the one-shot, because wet-actuator artifacts and emitted mirrors regenerate through DIFFERENT commands. The manual comparison it replaces would have passed when run and said nothing. Verified by execution: required-ci --required-lane build rostered=37 adjudicated=37 matches=37 drifted=0 required-regen first_generation_equal=true, 151/151 required-regen-fixed-point fixed_point_equal=true cargo clippy --all-targets -- -D warnings clean cargo fmt --all --check clean write_file_create_new tests 7 passed, 0 failed committed-copy comparison byte-identical, 1586 bytes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

… limit External review of a3437c3 found three defects and then corrected one of its own rulings. This carries all of it, plus the composition main's movement forced. THE WRAP GUARD IS WITHDRAWN, AND THE REASONING IS THE REVIEWER'S, NOT MINE. I argued the loop TOLERATES a revisited sequence value. That is true but shallow. The counter neither allocates nor certifies a staging identity -- it only chooses which pathname to PROBE, and the successful create_new IS the allocation event, so a revisited candidate is re-adjudicated by the filesystem rather than trusted. fetch_add and Relaxed stay; there is no sequence-exhaustion state to model, because process-lifetime counter wrap is not a failure of anything. The annotation now describes the atomic as a candidate-ORDER input. EXHAUSTION IS NOT AlreadyExists. It was, and that is #10069's defect re-expressed one level up: AlreadyExists is precisely how a caller of a create-only write concludes THE TARGET IS PRESENT, DO NOT OVERWRITE. Returning it when the target is ABSENT and the cause is an internal staging deficit is an internal condition wearing the domain refusal's identity. Now ErrorKind::Other; the one surviving AlreadyExists is the occupied-candidate arm, where it means what it says. It is a distinct DIAGNOSTIC, not a typed cause -- there is no payload to downcast to, and the earlier prose claiming otherwise overclaimed and is corrected. THE 1024 IS ONE NAMED AUTHORITY, NOT THREE SPELLINGS. It was a literal inside generated Rust. It is now rust_file_create_staging_candidate_attempt_limit, rendered into a pub const that travels with the function as ONE canonical block, read by the function and by the controls. A control that retyped the number would be a second authority for the same fact -- the failure this whole PR removes, in miniature -- and would keep passing after the row changed. There is no second numeric spelling anywhere. MY FORK CONTROL WAS VACUOUS, AND MY COMMENT ASSERTED THE FALSE GUARANTEE OUT LOUD. fork COPIES the counter; cargo runs these as threads of ONE process where siblings have already advanced it, so the planted -0 candidate was very likely never probed and the test passed without exercising an occupied candidate at all. Re-exec instead: a new process image gets the static's initializer. The controller discovers the helper's full name from the harness rather than hardcoding a module path that would rot, and requires "1 passed", so a renamed or filtered-out helper cannot leave it green. THE BUDGET ARM IS NOW REACHED RATHER THAN ASSERTED. Nothing executed it before, so the limit was a number no path ever met. The new control occupies exactly the CONFIGURED number of candidates, then requires refusal, kind Other, the cause and both counts named, NO target published, and every planted file byte-intact. It also protects the other control: if candidate naming ever changes so the planted names stop being probed, this one publishes instead of exhausting and goes red. PROMOTING THE LIMIT PUT A BLIND SPOT IN MY OWN PROJECTION TEST, which the reviewer caught. Extraction began at `pub fn`, so seed rendering 1024 against v1_rt rendering a stale 512 would compare identical function bytes, compile on both sides, stay green, and behave differently. "It would not compile without the constant" proves presence, never agreement. The compared range now begins at the generated pub const. MUTATION-PROVEN: setting v1_rt's constant to 512 with the function bytes untouched turns it RED; the previous version was green on that exact mutation. The projection control also caught its second real drift unaided: my first spelling of the refusal was not at rustfmt's fixed point (rustfmt collapses Error::other(\n format!(..)\n)), so the two copies diverged. Re-authored in rustfmt's shape and verified mechanically BEFORE regenerating. Nothing else gates this -- fmt as a merge gate is a declared rung drop. COMPOSITION. The B..T delta was NOT disjoint: main moved v1_interpreter.rs, lib.rs, stage0_crate_layout.dag and 05_emit_rust.dag, all files this PR authors, so the old head's artifacts were no longer the projection of the merged authorities -- which is exactly what failed CI there (drifted .github/workflows/witnesses.yml). Three generated projections came back UNMERGED from the driver with no conflict markers; regenerated rather than resolved by hand. Two pub mod lines were seeded only to break the generator's dependency on its own stale output, and the regenerator then MOVED one of them, proving the seeding conferred no authority. Verified by execution on this exact tree: required-ci --required-lane build rostered=37 adjudicated=37 matches=37 drifted=0 failed=0 required-regen first_generation_equal=true, 154/154, converged round 1 cargo clippy --all-targets -- -D warnings clean cargo fmt --all --check clean write_file_create_new battery 10 passed, 0 failed stale-constant mutation RED, as required Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

Main moved 24 commits / 103 files during the previous verification pass. Exactly one file overlapped this PR's authored set, and it conflicted: both sides had appended a different row to generated_artifact_registry -- mine FileTransportRealizationGeneratedRsArtifact, main's CouponCadQueryProgramArtifact. Unlike the previous composition's conflicts, this one is in an AUTHORED .dag file rather than a generated projection, so the merge driver correctly left it to a human decision instead of refusing. The decision is a union. Taking either side would have dropped the other's registration while leaving its committed generated file in the tree -- an artifact with no roster row is exactly the ungated-drift state this PR exists to close, so resolving by picking a side would have reintroduced the defect in the act of merging the fix for it. Both rows are present, and both survive in the GeneratedArtifact type declaration. Verified by execution on the recomposed tree: required-ci --required-lane build rostered=37 adjudicated=37 matches=37 drifted=0 phases_run=2 phases_failed=0 required-regen first_generation_equal=true, 154/154, converged round 1 cargo clippy --all-targets -- -D warnings 0 errors cargo fmt --all --check clean write_file_create_new battery 10 passed, 0 failed Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

briansrls

Exact-head review checkpoint on 7c80b88. The implementation changes reported for the named attempt budget, canonical constant+function projection range, re-exec controls, ErrorKind::Other budget diagnostic, registry union, and local 10-test/build/regen/fmt/clippy receipts are present directionally. Three source-authority sentences remain false and require a head change before this run can qualify a merge candidate: (1) the authority says nothing transforms the text on either projection path, although one path runs through rustfmt and the actual guarantee is that the canonical block is a proved rustfmt fixed point; (2) the generated-artifact comment still says the emitted copy is crate-root and needs no qualifier, although it is in v1_rt and sibling emitted modules call it through v1_rt::; (3) rust_file_create_new_canonical_block's comment says leaving the constant behind would not compile and that this keeps projections from drifting, but the proved 1024-vs-512 mutation compiles and is caught only by canonical-block equality. Correct those claims to name the actual mechanisms. Metadata-only corrections also remain in the PR body: it still says the occupied-candidate control uses a forked child, and the verification table still says 7 tests rather than 10; update those without treating them as CI-relevant. CI on this exact head is still queued. After a corrected exact head is terminal green, present the complete B..T adjudication before merge actuation; native APPROVE will bind that exact head and observed tip.

gunbai-bot · 2026-09-03T05:37:07Z

Thanks — the second note lands (the escaped one-liner is a real authoring cost, and the annotation says why the alternative is worse). The first one is factually wrong, and I want to correct it on the record rather than let it stand, because it understates the guarantee and would be citable later as "a reviewer assessed this at rung 2".

v1_rt.rs is not a third hand-carried copy. It is a generated projection.

Review 59156 says it "hand-carries the same bytes rather than being a generated artifact". It is in the emitted-population manifest — it is emitted from v1.compiler.runtime_rust, and rt_filesystem obtains its bytes by calling rust_file_create_new_canonical_block() from the one authority. It is regenerated by claim_executor --required-regen like any other projection; earlier in this PR it appeared in a literal FAIL generated surface drift: v1_rt.rs line and was recovered by regeneration, which is not something a hand-maintained file does.

The likely source of the error is a heuristic that gunbc.generated_projection_paths documents and explicitly rejects, in a comment that names this exact file:

THE FILE HEADER IS NOT THE POPULATION and was tested and rejected as one: 135 files carry // Generated by v1 compiler -- do not edit. at that ref, and the header disagrees with the model in BOTH directions — main.rs and std_lens_verdict.rs carry it and are hand-maintained, while compiler_tests.rs, emitted_population.rs and v1_rt.rs lack it and are in the emitted-population manifest.

So v1_rt.rs lacking the header is a known property of that file, not evidence about how it is maintained.

What follows for the rung claim. There are two projections of one authority, both derived, neither authored — so equality is maintained by construction, not by anyone remembering to copy. What both_projections_carry_the_one_authority_verbatim guards is the residual that construction genuinely does not cover: one projection's path passes through rustfmt, which this repo does not own, so a formatter change could separate two byte streams that the model says are one. That is why the test also asserts the seed artifact is already at rustfmt's fixed point.

That residual is not hypothetical. The control has gone red twice on real drift during this PR — once when a wet-actuator artifact and an emitted mirror regenerated through different commands, and once when my own spelling of the exhaustion arm was not at rustfmt's fixed point and the two copies diverged. Both would have been invisible otherwise, since fmt as a merge gate is a declared §4b(3) rung drop.

Both notes were non-blocking and I am not treating the correction as a request for re-review.

— sent from deep-carp-676

briansrls

Follow-up on exact head 7c80b88. Workflow 33718394528 is now terminal SUCCESS: required build, required floor, Rust unit/Clippy, fabric evidence, aggregate witnesses, and heal-generated-artifacts succeeded; emit-copy qualification skipped as expected. I accept the forward segment B=3547b3f902803eb3c0b4b6995e5bab7e807918bb..T=6c596058c787e6e41b5ccd6cf3293f18e0c255de as semantically disjoint from this transport cut. The nontrivial checks close as follows: #10180 changes a fail-closed scratch-source substitution around the existing plain Filesystem.Write witnesses, not WriteCreateNew or its staging/refusal realization; #10154 changes separate floor-cut/stall authorities and the Design* projections, while the fmt-drop referent and the FileTransportRealization artifact arm/path remain distinct; #10140's namespace collector/witness has no file-transport actuation route. This acceptance does NOT lift REQUEST_CHANGES 5098133640. The same head still contains the three false authority-mechanism claims named there, and the PR body still says forked child and 7 tests. Correct the source claims (new head), update the body, obtain terminal exact-head CI on that corrected head, then only later main movement beyond 6c59605 needs fresh forward-delta classification if the composed checkpoint remains 3547b3f.

External review 5098133640 filed REQUEST_CHANGES on 7c80b88 for three statements in this module that describe mechanisms the tree does not have. All three are correct findings. None of them touch the implementation -- which is the point: an annotation that describes a guarantee the code does not provide is worse than no annotation, because it is the thing a later reader cites instead of checking. 1. "Nothing transforms the text on either path" is FALSE. One projection route passes through rustfmt, a canonicalizer this repo does not own, and it has already moved these bytes twice during this change. The true statement -- now written -- is that no HAND-MAINTAINED SEMANTIC TRANSLATOR stands between the authority and either projection, and that the route containing rustfmt is CHECKED by an executed fixed-point assertion. The seam is not absent; it is guarded, and saying "absent" retires the reason the guard exists. 2. The generated-artifact annotation still said the emitted copy is crate-root and needs no qualifier. It is in v1_rt, and emitted modules reach it as `v1_rt::gunbc_file_write_create_new`. `pub` is required by BOTH projections, not just the seed's. The crate-root arrangement was tried first and does not work under the split-crate seed, which the module says thirty lines earlier -- so the file contradicted itself. 3. The canonical-block comment claimed that copying the function while leaving the constant behind WOULD NOT COMPILE, and that this is what keeps the projections from drifting. I falsified that sentence myself and did not notice: the 1024-vs-512 mutation I ran to prove the widened control discriminates compiles on BOTH sides, matches byte-for-byte across the entire function, and behaves differently. Compilation proves the PRESENCE of a constant with the expected name; it says nothing about AGREEMENT on its value. What proves agreement is extracting from the constant through the function and comparing bytes, which is why the control's range begins where it does. The comment now records that it was falsified by a mutation against this very module, so the next reader inherits the experiment rather than the claim. The PR body carried two stale facts against the same head and is corrected: the occupied-candidate control runs in a RE-EXECUTED test binary, not a forked child (the fork version was the vacuous one), and the battery is 10 tests, not 7. The compared subject is now named as the canonical constant-plus-function block rather than "the definition", so the blind-spot repair is explicit rather than implied. Annotation-only, and the tree proves it: after regeneration the ONLY changed file is this .dag. No generated byte moved, which is section 4c's erasure property holding -- semantic passes receive the annotation-erased projection, so prose cannot reach the emitted program. Verified by execution on this exact tree: required-regen first_generation_equal=true, 154/154 required-ci --required-lane build rostered=37 matches=37 drifted=0 phases_failed=0 cargo clippy --all-targets -- -D warnings 0 errors cargo fmt --all --check clean write_file_create_new battery 10 passed, 0 failed Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

All three source-authority corrections and the two PR-body ledger corrections are present on superseding head 479317a. The old review is dismissed as satisfied; merge authorization remains a separate forward-composition question.

briansrls

Native content ruling on exact head 479317a. Review 5098133640 is satisfied and dismissed. The authority now states the actual mechanisms: no hand-maintained semantic translator; rustfmt is a guarded projection seam; pub and v1_rt:: qualification are required on the emitted route; and compilation proves constant presence while canonical constant-plus-function byte equality proves agreement. The PR body now says re-exec, names the canonical block, and records 10 tests. Commit 479317a is annotation-only over 7c80b88, and workflow 33727071926 is terminal SUCCESS on the exact head across required build, required floor, Rust unit/Clippy, fabric evidence, heal-generated-artifacts, and aggregate witnesses; emit-copy qualification skipped as expected. CONTENT IS ACCEPTED; no content blocker remains. This is intentionally COMMENT, not APPROVE: main movement after the previously admitted 6c59605 checkpoint overlaps the generated-output closure and qualifying compiler/workflow machinery, including parser authority/mirror changes, lib.rs and emitted_population.rs regeneration, and later witnesses.yml changes. Therefore 479317a is not merge-authorized. Use the requested quiet/queued slot: pin T0, compose it once, regenerate to first-generation and referenced fixed-point equality, obtain terminal exact-head CI on the resulting H, keep main at T0, then present H/T0 and any conflict resolutions for native APPROVE before releasing the slot.

gunbc-ci-auto-heal and others added 4 commits September 2, 2026 23:22

briansrls previously requested changes Sep 3, 2026

View reviewed changes

briansrls reviewed Sep 3, 2026

View reviewed changes

briansrls merged commit 07d6abc into main Sep 3, 2026
7 checks passed

briansrls deleted the scm-file-transport-authority branch September 3, 2026 10:14

briansrls restored the scm-file-transport-authority branch September 3, 2026 10:18

gunbai-bot Bot mentioned this pull request Sep 3, 2026

SCM MVP-N #10213

Closed

6 tasks

gunbai-bot Bot mentioned this pull request Sep 27, 2026

Fix two claims broken on main (pick_ingested_probe normalized arm; stage0 layout overlap) #12406

Merged

Navigation Menu

Repository navigation

One file-transport realization authority: delete the two-spelling subject - #10142

One file-transport realization authority: delete the two-spelling subject#10142
briansrls merged 5 commits into
mainfrom
scm-file-transport-authority

gunbai-bot Bot commented Sep 2, 2026 •

edited

Loading

Uh oh!

briansrls left a comment

Uh oh!

gunbai-bot Bot commented Sep 3, 2026

Uh oh!

briansrls left a comment

Uh oh!

briansrls left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

gunbai-bot Bot commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The subject this deletes

The seam is a complete named function, not a block

Three files carry the definition; only one is authored

It returns io::Result<()>, not the transport tuple

Why the runtime module, and a correction

The staging collision, closed in the one place that now exists

The staging name is allocated, not calculated

Projection identity executes, it is no longer an annotation

Enrollment

Verified by execution

Uh oh!

briansrls left a comment

Choose a reason for hiding this comment

Uh oh!

gunbai-bot Bot commented Sep 3, 2026

Uh oh!

briansrls left a comment

Choose a reason for hiding this comment

Uh oh!

briansrls left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

gunbai-bot Bot commented Sep 2, 2026 •

edited

Loading

It returns `io::Result<()>`, not the transport tuple