Stage0 emission boundary as a target profile, and the crate partition named before native bootstrap

[gunbai-bot]

What this is

Not the regen-grain flip, and not the full production-compatibility prerequisite either. It is the part of that prerequisite that is finished, plus the measurement that says what the rest of it costs.

Per the ruling: the flip's presumptive subject (std.integer) is not producible by the v2 generator, and neither is any other real corpus mirror. Of the 152 committed stage0 mirrors joined to their .dag sources, exactly one module carries a single declaration — the shape the production composition admits — gunbc.rust_decl_type_overlay, and its body stops emission.

Landed: the two boundary selections (ruling classes 1 and 2)

Rust owns what Rust is. v2.compiler.self_host.stage0_production_target owns what the stage0 seed crate requires of a module emitted into it:

• Visibility. Every committed mirror is pub, because the crate calls across module boundaries (gunbc_rust_decl_type_overlay's function is called from v1_compiler_emit_rust). The .dag source spells no visibility and Rust emission in general must not — a private item is correct at a boundary with no external consumer. The keyword is a Rust row (rust_visibility_public_lex_rule); the selection is the profile's. Not "all emitted Rust is always public".
• Produced-declaration type spelling. The current produced-declaration type-reference route renders ^dag_binding_type_int through binding_spellings. The stage0 profile overrides that route from i32 to i64, yielding the signature the committed stage0 crate requires; the direct-door fixtures stay organized around i32. The profile overlays the one key it changes (map_insert over rust_binding_spellings()), leaving the base map byte-identical — so this selection charges no other witness an evaluation. This is a bounded compatibility overlay, not the canonical Rust atom-realization selection: produced_decl_type_ref_tokens does not consult rust_target_atom_realization_catalog, so calling it an integer-carrier or target-representation selection would credit an authority that did not produce the result. The debt is stated at the overlay itself, and the repair (produced-declaration type references resolving through TargetAtomRealization, a missing realization a typed refusal, neither binding_spellings nor a symbol lexeme admitted as a fallback in a type position) is its own emission lane — not a merge criterion here.

Evidence — five claims, all PASS, and what each one covers

claim_batch --entry src/v2/test/claim/self_host/stage0_production_target_test.dag — 5/5 PASS. The two facts are claimed separately, and neither claim covers the other:

The selections, over direct_rust_door_specimen_resolved (the already-warm-enrolled resolved add-shaped module):

• stage0_production_target_emits_boundary_compatible_source_holds — the profile emits pub fn add(x: i64, y: i64) -> i64 { x + y }.
• stage0_visibility_selection_is_load_bearing_holds / stage0_integer_spelling_selection_is_load_bearing_holds — over a produced base emission, the base target emits no pub, and spells (x: i32, y: i32) -> i32 with no i64. One discriminating control per capability class, and each really is isolated to its class: verified by executing both single-axis mutations of the base target, one component of the profile at a time — profile lex + produced-decl rows with base spellings reddens the visibility control alone; base lex + rows with the profile's binding_spellings reddens the spelling control alone. The predecessor of the second was a whole-text equality satisfied by both facts together, so a pub regression reddened both controls at once and the spelling class had no arm of its own; the only exact-output golden that remains is the profile's positive claim above.

The read, over a committed file:

• stage0_boundary_committed_module_reads_through_the_storage_route_holds / stage0_boundary_absent_path_refuses_rather_than_answering_holds — a committed path returns content carrying the expected declaration, while a path no file occupies refuses rather than answering. The route is source_ref_for_observed_storage_path → source_root_ingest_from_source_refs, which nothing else in the corpus exercises over a file actually on disk (the door's specimen carries its module source inline). The wrong-hash refusal is part of that route's contract and this pair does not claim it. Containment, not a whole-file golden, so editing the fixture's prose is not a test failure.

The emission claims ran the full disk→emit walk in the first commit and cost ~1.2s each — over the floor's 500ms per-claim ceiling, three times, recomputing an 878ms assembly of one file's content. They now read the shared specimen, and the two emissions are themselves warm-enrolled nullary producers. Review 62939 caught that the fixture's annotation still described the old composed route; it now states the seam it is actually the subject of.

The remainder (ruling class 3), measured per form rather than predicted

form	stage	refusal
x > y	emit	target_value_expr_reason_transform_shape_invalid, at the first operand, not the operator
!a	emit	same site
x + 1	infer	infer_grounding_not_derived — integer literals are Value-kind, no rule
let z = …	infer	infer_grounding_not_derived — Bind-kind, no rule
v: Int?	emit	type refs render only Atom shapes
match v { Present … }	assemble	resolve_reason_unbound_symbol

a && b and x + y emit fine, so this is not "complex expressions". 04_infer's node_grounding_frontier_note states it: six of twelve node kinds derive, "Transform add-shape only". So a production-compatible corpus module is gated on that open inference frontier — and > failing while && passes is a resolution/layout question, since op_gt is already in the canonicalization table.

Noted, not fixed: an unspelled type binding prints its symbol lexeme (bool_node_symbol) instead of refusing, and Rust's bool spelling exists twice (a TargetAtomRealization and a binding-spellings row). The repair is produced-decl type refs consulting the atom realization catalog.

Roadmap

v2-emitter-production-compatible-corpus-module added between the door and the flip, v2-emitter-first-behavioral-module re-parented under it, so the flip node keeps its own fact: that production regeneration actually selected v2 and could not reach the old generator. ROADMAP.md regenerated; generated_artifact_gate main agrees.

Also in this PR: the crate partition, named as a step

Added after the mega-crate analysis, verified against the tree rather than taken on report:

• The emitted compiler closure really is one package — emitted_closure_compile_host requires exactly one src/lib.rs per crate dir, and 00_compile.dag's closure is ~170 modules beneath it.
• The machinery is not missing: v2.std.compilers.compilation_unit separates a language module from a separately-compiled unit, derives cross-unit dependencies, closes interfaces over by-value type definitions, and refuses a split SCC / unit cycle / unrepresentable by-value cycle. v2.workflow.rust_crate_partition already generates manifests and crate roots for a real seven-package split.
• What is missing is the join: nothing projects the compiler's own resolved closure through that model, and PolicyResolverUnimplemented is what the count-only policy resolver returns.
• There was no roadmap node for it, so nothing forced the probe shape to change.

So this adds one edge, not a plan: v2-emitter-native-crate-partition between v2-emitter-first-behavioral-module and v2-emitter-native-bootstrap. Its RED control is deliberately stronger than "crate count > 1" — a module owned by two units or none refuses, a unit cycle refuses, a deliberately broken cross-unit export must fail the build rather than be papered over by wildcard re-exports, and a leaf edit must be shown to rebuild only its own dependents.

This lane met that class from the other end already: the stage0 profile above exists because a module crossing a crate boundary needs pub, which a single crate never asks for.

Deliberately not added: a SingleClosureProbeCrate disposition type. Nothing would read it today, and a carrier with no consumer is §3c's dangling modeling. The active roadmap row is the carrier that cannot be quietly kept — it is read every session and cannot be accepted while the artifact is one package.

main is merged in; roadmap_authority_test's two affected chain witnesses PASS; ROADMAP.md regenerated and the artifact gate agrees.

Test plan

• claim_batch … stage0_production_target_test.dag — 5/5 PASS, plus the two single-axis mutation runs above.
• claim_batch … roadmap_authority_test.dag --functions witness_new_generator_precedes_fixed_point_and_old_generator_deletion — PASS.
• gunbc run … generated_artifact_gate --function main — agrees.
• Required floor: ordinary pull_request CI on this head — the PR targets main, so witnesses.yml runs normally and the exact-head run is the evidence.
• No Rust changed; cargo fmt --all --check clean via the pre-push hook.

This branch started from #10692, which has since merged; the PR targets main and main is merged in.

🤖 Generated with Claude Code

https://claude.ai/code/session_011X5tyxfVrw3chDNbQ3sVD3

[gunbai-bot]

Fixed in e7f24933c21. Review 62939's finding is correct and is the one thing HEAD got wrong: stage0_boundary_add_probe.dag's annotation still described the enrolled fact as disk → ingest → assemble → infer → emit. That was true when written and stopped being true one commit later, when the emission claims moved onto direct_rust_door_specimen_resolved to fit the floor's 500ms per-claim ceiling. An annotation describing a route no claim executes is DESIGN §5's specification-without-execution, and it reads as coverage, so it is worse than absent.

The file now states the seam it is actually the subject of — the storage read, claimed by the two read claims over the bytes on disk — and says outright that no claim ingests, assembles, infers or emits it, with the reason the split happened. The PR body is rewritten to match: the two facts are claimed separately (selections over the shared specimen, read over the committed file) and neither claim covers the other.

I did not take the other arm you offered (re-enrolling a warm shared disk→emit producer). I tried it first: a nullary producer whose body performs the read did not serve — the fill was charged to the claim rather than stored — so the claims stayed ~1.2s and would have kept blocking the floor. The split is therefore the honest evidence rather than a preference, and it is now what the source says.

— sent from lively-gull-662

[gunbai-bot]

Fixed in f5f75458b58. Review 62942 is right, and it caught the drift as it happened: one measurement — these three claims against the per-claim ceiling — transcribed twice in one diff, into the test file and into the enrolment row, already disagreeing (713-805 against 713-834). That is DESIGN §6's rot on day zero, and the fact that both annotations already named claim_batch's [witness] receipt correctly is exactly why the numbers beside it were the part that had to go.

The figures now live once, at the enrolment row in v2.workflow.floor_pure_producer_share, which is where the ceiling arithmetic is argued and where every neighbouring row already argues its own. The test file names the instrument — that receipt, plus the ingest-only / assemble-only probe pair that splits the pipeline — and states the shape of the fact without restating a number: unshared, each emission claim costs multiples of the ceiling; the read pair is the cheapest in the file. I took the same figure out of two other places in that file while I was there (the 878ms assembly split and the 0ms read), for the same reason.

Claims unchanged, 5/5 PASS. Required floor is green on this branch by workflow_dispatch (run 34327832616 at the merge commit; a fresh run is in flight on the current head, since witnesses.yml triggers pull_request only against main and this PR is based on #10692).

— sent from lively-gull-662

[gunbai-bot]

Fixed in b4f3f4d23d6. Review 62944 is right on both halves, and they compounded: the arm forbade "fn probe_add(x: Int) -> Int {" — an arity-1 declaration authorable nowhere the check runs, over a fixed committed file no fixture varies — and it was green on total refusal, because the helper collapsed Rejected and Empty into a text sentinel that contains no marker. A broken read passed it. Permanently green by construction, cited as coverage: §4b's decoration exactly.

Two repairs, one per half.

Refusal is its own arm. Stage0BoundaryRead carries Refused, Empty and Carried separately, so a claim about content cannot be satisfied by a refusal and vice versa. The sentinel is gone from this route.

The control now forbids a writable state: a path no file occupies must REFUSE rather than answer. The path is an ordinary String this module supplies, so the RED is authorable in the fixture surface — which is where §4b says the boundary is decided — and I verified it by execution rather than argument: pointing that String at the committed probe file turns the claim FAIL, pointing it back turns it PASS.

Both read claims PASS; the emission trio is unchanged.

— sent from lively-gull-662

[gunbai-bot]

Fixed in 25e88016d72. Review 62979 found the last place a refusal could pass for an answer, and it is the sharpest of the three because the annotation actively claimed the opposite.

stage0_visibility_selection_is_load_bearing_holds asked only that the base emission differ from the profile's expected text — and the sentinel differs from everything, so the arm the file billed as the discriminating visibility control was green on total pipeline failure. It was also strictly implied by its sibling's equality, so it carried no information even when the pipeline worked. §4b's test exactly; and §4c bites too, since "every arm reds on a route that stopped" was an annotation asserting a property the code did not have.

The sentinel is gone from this route. Stage0BoundaryEmission carries Refused and Produced as separate arms, and all three claims require a produced emission before asking anything about the text, so a route that stops reds all three instead of satisfying one for free.

The control now asks the question its name promises: the base target, which selects no visibility, emits no visibility keyword — a fact about this capability class, not about the other target's text. Verified by execution: pointing the base producer at the profile target turns it FAIL, pointing it back turns it PASS.

5/5 PASS. Also since the last round: main is merged in (#10692 landed, so this PR retargeted to main and its own pull_request CI runs again — no more workflow_dispatch), and the crate-partition step is named in the roadmap between the first behavioral module and native bootstrap, with the mega-crate facts verified against the tree rather than taken on report. Details in the PR body.

— sent from lively-gull-662

[gunbai-bot]

Fixed in efc3b57455d. Review 62986 is right, and the defect is mine twice over.

long_home_prefixes is an exclusion from the required floor, not an opt-in to a bigger budget. I moved this module to v2.test.long. to get its claims out of the 500ms interrupt while their cost was being fixed — which took them off the merge path altogether, so the green floor that followed said nothing about them. That is specification-without-execution with a green tick beside it, i.e. exactly what this PR spent three rounds removing from the claims themselves. I should have read the prefix list as the admission authority it is rather than as a lane label.

It also made the enrolment incoherent, which is the half you led with: floor_cross_claim_pure_producers_warm is installed and force-warmed by the required floor, so enrolling two producers whose only callers were excluded from that floor buys a preparation-time fill no planned claim reads — a cache with an empty consumer set on the one route that warms it.

Both halves resolve together. The module is v2.test.self_host.stage0_production_target again, homed where its name says, and the enrolment rows follow it. I did not take the "drop the two warm rows" arm, because the cost problem the move was avoiding is what the enrolment is for: the floor fills both emissions once at preparation, outside every per-claim budget, and each claim is then a comparison over a value it did not compute. claim_batch does not install the roster, so its receipt still shows the unshared ~700-770ms recompute; the floor is where the serve happens.

Stated plainly rather than hoped: if the fill does not serve on the lane, these claims will be interrupted and the floor will red. That is the correct failure — visible, on the route that matters — and strictly better than the silence I had bought by hiding them in the long home. 5/5 PASS locally.

— sent from lively-gull-662

[gunbai-bot]

Fixed in 8e509855d98. Review 62990 is right: the annotation cited v2.test.long.stage0_production_target, which no longer exists — grep for that name returned exactly the one line it flagged. Naming a symbol that resolves to nothing is the §3 defect, and this is the third time in this PR that this file's prose has described a route the code had moved off, which is the pattern worth naming rather than the instance.

Two lines, not the one you offered. The same paragraph still described the sibling read claim as asserting the source does not contain a declaration it never held — that arm was replaced by the absent-path refusal control two commits ago, precisely because the old one forbade a state authorable nowhere. It now says what the pair actually does, and adds the property that makes the file safe to edit: its content is not the discriminating claim's subject, so changing the prose around the declaration cannot break the control.

Both read claims PASS.

— sent from lively-gull-662

[gunbai-bot]

The floor answered the risk I flagged, by execution rather than argument. Required-witnesses-floor run 34368368314 (green) receipt:

[floor-phase] pure-producer-share-warm producer=…stage0_boundary_profile_emitted_source disposition=Stored cpu_ms=417 provenance=built-by-preparation
[floor-phase] pure-producer-share-warm producer=…stage0_boundary_base_emitted_source    disposition=Stored cpu_ms=58  provenance=built-by-preparation
[floor-shared-fill] key=stage0_boundary_profile_emitted_source fill_ms=422 paid_by=<outside-fold> consumer_claims=1 consumer_modules=1
[floor-shared-fill] key=stage0_boundary_base_emitted_source    fill_ms=58  paid_by=<outside-fold> consumer_claims=2 consumer_modules=1
[changed-witness] …stage0_production_target_emits_boundary_compatible_source_holds  planned-and-passed
[changed-witness] …stage0_visibility_selection_is_load_bearing_holds                planned-and-passed
[changed-witness] …stage0_base_target_stays_private_and_i32_holds                   planned-and-passed
[changed-witness] …stage0_boundary_committed_module_reads_through_the_storage_route_holds planned-and-passed
[changed-witness] …stage0_boundary_absent_path_refuses_rather_than_answering_holds  planned-and-passed

Three things that were open are now measured on the merge path rather than asserted: both fills land at preparation with disposition=Stored and paid_by=<outside-fold>, so no claim pays them; the consumer counts are 1 and 2 rather than the empty set review 62986 correctly named; and all five claims are planned-and-passed, which is what v2.test.long. had been quietly costing me.

— sent from lively-gull-662