Kind reflection (#11819) and a computing SHA-256 under the identity layer

[gunbai-bot]

Carries #11819 (merged from session/gentle-seal-490, unparked by operator direction 2026-09-21) plus the computing-mint seam under the identity layer. One PR by operator direction — and the identity layer does not move onto the digest in it; see Piece B for the measurement that decided that.

Read the scope change first: Piece A delivers ONE working wall, not the three #11819 reported. That is a reduction, and it was found because the positive control was fixed first — while the wall refused everything, all three reds looked equally real.

All evidence below is from a compiler built from this tree at e20e8c5004, with a must-fail control passing first (--definitely-not-a-real-flag → exit 2). Witnesses re-run after merging main.

Piece A — the kind wall

MachineWidth's type parameter is kind-annotated, and the wall now discriminates:

fixture	result
MachineWidth<NotAWidth> — bodyless, structurally identical to the kind's arms	exit 1, one blocking error, and it is the kind refusal
MachineWidth<PointerWidth> — the kind's own declared inhabitant	exit 0, zero blocking, compiled: 1 files emitted
dag/std/integer.dag — the 4 live sites, real corpus	exit 0, zero blocking, emits

The red is the strong form: only a check consulting the kind's declared arms refuses a bodyless type of the same shape. That closes the defect #11819 left open, which is what makes its reds mean anything.

Enrolled as test.claim.type_argument_kind_inhabitance_witness_test — 6/6 green. Two design points: the oracle counts blocking rows of the named class, never "did it compile" (a boolean stays red through any refusal); and the sources declare their own kind rather than importing std.machine_constraints, so the module avoids ReadsLiveTree and actually executes in CI.

Retracted: the type-parameter-in-value-position refusal does not fire

#11819 lists it as firing. On a built compiler it does not. The seed's binding_resolves_to_type_parameter is a literal false, so the guard is unreachable by construction; the corrected predicate v1.compiler.infer declares (name_is_enclosing_declared_type_parameter) occurs 14× in the .dag and 0× in the seed. A module whose whole content is a generic function returning its own type parameter compiles with exit 0 and emits — v1.compiler.infer's own note records that it renders into a crate failing rustc E0425, so the silence trades a located refusal for an unlocated one downstream.

That PR hand-patched the kind check into the seed, not this one, and the stage0 regen that would carry the rest has not run.

The witness pins the hole (== 0) rather than deleting the evidence, with an adequacy control on the same harness and run that does count a blocking row, and a trigger naming the capability. It goes red when the wall starts working — that red means flip the assertion, not relax it.

Piece B — the computing mint lands as a declared frontier; the object-ref family does NOT change

What lands: B1 (the computing cryptographic mint), the sole-constructor FabricAddressedObject, and the structural family retained with a row saying why. What was tried and withdrawn in this PR: B2, binding fabric_object_ref_of to that mint.

B1	std.content_hash content_hash_of_value_cryptographic — the module's first mint that hashes bytes (through extdeps.crypto.sha2, FIPS 180-4) instead of parsing a digest someone else computed; through its own sha256_hex_digest wall, so computed and parsed digests share one admission path. It has no production consumer and says so: a declared frontier (DESIGN §3c), its annotation naming the consumer that will bind (fabric_object_ref_of), the row, and the one claim that runs the real path — test.claim.content_hash_family_grounded_witness the_computing_mint_reaches_the_published_digest_of_a_fabric_preimage, oracle sha256:6fccc7fc… computed by coreutils and Python hashlib outside this corpus.
B2	Withdrawn on measurement (below). fabric_object_ref_of mints the structural family, total, exactly as on main; fabric_object_ref_of_wire admits only that family. FabricAddressedObject sole_constructor stays — the object and its ref are one carrier minted in one place, which closes subject_and_its_digest_as_independent_parameters regardless of family.
B3	Does not retype — capability boundary, below.
B4	Trigger names the capability, not the artifact.
B5	Not a §4b(3) drop: main never held cryptographic identity, so there is no previous rung to lower. Filed as a §4b meta-obligation 2 stall — gunbc.recurring_failure_mode fabric_object_identity_is_a_structural_locator (rung 1, ceiling 3, class can climb after one capability lands).

Why B2 was withdrawn: it cancelled the required floor, and the cause was pinned

Main's merge-queue floors run 210 wet identities and finish in ~38 min. This branch's floor cancelled at the 90-min cap because the spark pair_serving_*_real_execution claims — which append and re-read event chains through gunbc.fabric.fabric_storage_file_store — took 3–15 minutes each instead of ~1 s. Every put, every verified get and every closure step paid an interpreted SHA-256. The srv1 differential (same 9-claim file, systemd-run memory cgroup; time from first PASS to last):

binary	tree	9 claims
merge-base 4b3f2a2e	base	7 s
PR 9e1f47bb	base	7 s — the kind-reflection seed change is cleared
PR 9e1f47bb	PR	23 m 36 s
PR 9e1f47bb	PR, only the mint's family flipped back	8 s

Receipt with binary path, sha256 and build time: #11996 (comment). The brief's point 4, measured on a consumer: interpreted execution of this closure is not viable at floor rate, let alone line rate. A seed intrinsic, a shell-out per object, and a bigger floor cap are each refused in the row for the reasons DESIGN gives. Trigger, at capability grain: native emission of the extdeps.crypto.sha2 closure sufficient for every consumer of the file store to run at floor rate — measured as those spark claims completing inside main's floor envelope with the mint cryptographic. An emitted closure that is still slow does not fire it.

After the withdrawal, on srv1 with the same PR binary: fabric_storage 9/9, fabric_storage_wire 11/11, fabric_storage_file_store_wet 10/10, content_hash_family_grounded 30/30 (including the new inhabitance claim), pair_serving_authority_log_real_execution 9/9 in 7 s of claim time. The floor on this head is the discriminating control: it must complete inside main's envelope.

Why the pure kernel and not the shell arm, under either family — structural, not economic. crypto.Sha256Sum.File takes a path; fabric_object_preimage produces a NonEmptyStr in memory. The shell arm is a temp-file write plus a spawn, and that write manufactures the custody gap verification exists to close. Minting stays pure, so fabric_object_verified stays a pure check.

B3 — the retype cannot land, and two rows were about to retire on a satisfied trigger

UInt32 is Compose<UInt, MachineWidth<32>> over Phantom → a structural operand, and std.operator_realization operator_realization_for routes Add/Sub/Mul/Div/Mod on a structural operand to structural_arithmetic_refusal. v2.std.node Hash is the compiler's own node identity, computed for every node of every compile including the compiles by which v2 emits itself. Retyping it does not give a slower compiler — it gives one that cannot be emitted; and the B2 measurement above is what "slower" would mean per node even where it could run.

Both gunbc.scm.object_store and gunbc.scm.commit_closure carried dissolve-on "a computing cryptographic digest reachable from .dag" — which B1 satisfies literally, while ObjectId stays fnv1a64. Read literally they retire on this merge with the capability dead (DESIGN §4b(3)). commit_closure's is the worse one: the sentence it guards is that "Merkle" here must not import an adversarial commitment, which stays true — retiring it would delete the only thing saying so.

Both restated to the same capability, deliberately not two rows for one fact: native emission of the extdeps.crypto.sha2 closure — sufficient for v2 to emit and build itself with node identity minted from a cryptographic family.

Rung, at the minimum across paths

• .dag acceptance path — the kind wall discriminates; red and green separate.
• Emitted path for sha2 — refused by construction. Unchanged.
• Fabric object identity — rung 1, unchanged from main, now filed with its ceiling and trigger instead of unstated.

So the kind wall climbed. The digest class did not, and no row retires on it. Nothing in this PR was floor-proven at 189cab5 in any sense that matters: that head's floor ran zero wet claims.

Also

• Stale "no SHA-256 computation exists in .dag" corrected in docs/plans/fabric-storage.md (Known limits now says the family is structural, why, and the trigger) and gunbc.scm.object_store. dag-native-scm-design.md deliberately untouched — gunbc#11997 owns it.
• Classes filed: a_carrier_swap_moves_the_mint_and_strands_the_parser (read-path-only refusal; a put-only smoke test is green by construction), a_wall_declared_in_dag_is_inert_in_the_seed_that_compiles, and fabric_object_identity_is_a_structural_locator.
• A §4c defect of my own — an annotation inside a coproduct's arm list — caught by the compiler, not by review.

Attribution: of the failure-mode rows in this diff, only the three named above are this lane's. The other three came in with the #11819 merge and are gentle-seal-490's work.

🤖 Generated with Claude Code

[gunbai-bot]

Fixed in 1cbc682. review 69717 is correct, and the commit order it reconstructed is the whole explanation: 97cd138 rewrote that bullet, 3dde2d3 moved the mint afterwards, and nothing came back to the doc.

Taking it as the class rather than the line: this PR re-points gunbc.scm.object_store and gunbc.scm.commit_closure away from a dissolve-on that had become satisfied, and then asserted the opposite of its own shipped code in a plan doc one file over. Same defect, committed by the author correcting it, in the section titled "Known limits of the first realization" — which is exactly where a reader goes to learn whether the weak digest is still live.

What the bullet now says: object refs mint through std.content_hash content_hash_of_value_cryptographic over extdeps.crypto.sha2, with test.claim.fabric.fabric_storage_witness the_mint_computes_a_real_sha256_digest cited as the execution receipt. The heading changed too — "Weak digest" is no longer the limit. What remains is emission: UInt32 is Compose<UInt, MachineWidth<32>>, a structural operand, and std.operator_realization operator_realization_for routes arithmetic on a structural operand to structural_arithmetic_refusal, so the closure runs only interpreted.

A third clause was wrong that the review did not have to catch. The bullet credited the realization choice to "measured throughput against object size". I have withdrawn that reasoning: the throughput figure I had inferred came from an undecomposed wall-clock number, and when I measured properly the result contradicted it — a fabric witness performing ~25 real SHA-256 mints ran in 1m55s against 1m59s for a zero-hash witness over the same corpus, so interpreted SHA-256 over small preimages is lost in corpus-load noise. The decision was always structural: crypto.Sha256Sum.File takes a path, fabric_object_preimage produces bytes in memory, so a shell transport costs a temp-file write per object and manufactures the custody gap (hash one file, store another) that verification exists to close. The bullet now carries that argument, because it is the one that holds and the one a later reader would otherwise re-derive incorrectly from numbers I no longer stand behind.

A second bullet was added for something a storage-plan reader meets at the first call: the mint answers an Optional and the refusal is propagated rather than absorbed. Falling back to the structural digest would answer with a locator in precisely the case where identity could not be established.

The collision arm keeps its paragraph with its reason inverted rather than deleted — under the old family a collision was an accident; under SHA-256 it is an attack, so the wall matters more now, not less.

No code changed; the three witnesses remain 6/6, 10/10 and 11/11 by execution on the merged tree.

— sent from nimble-hawk-154

[gunbai-bot]

Fixed in 17a4cca. review 69733 is correct, and verifying it split the population in a way worth recording.

Sixteen seed declarations were added or modified by the #11819 carry; only one is growth. Fifteen resolve in the .dag authority — type_arg_kind_inhabitance, KindInhabitance, the kind_* helpers, parse_optional_type_param_kind, type_param_kind_property_name, the WidthResolution arms — so they are generated bytes carried ahead of a regen, which is ExistingSeedItemModified rather than addition. One does not: binding_resolves_to_type_parameter occurs zero times in every .dag under src/v1. That is the growth, and it is the only declaration gunbc.kind_reflection_seed_growth cites. The other fifteen are named in the row header rather than omitted, because a receipt that counts only what the roster can cite under-reports its own growth.

Why it is declared rather than implemented. It stands where v1.compiler.infer declares name_is_enclosing_declared_type_parameter, which reads InferScope.enclosing_declared_type_param_names — a field the seed InferScope does not carry. Honouring it by hand means adding a struct field and threading it through every construction site in generated Rust: hand-authoring compiler logic into the seed so a wall goes green, which is the direction DESIGN §7 and this repo's standing instruction both refuse.

Why it is not deleted, since that is the first repair anyone reaches for. Deleting the stub means deleting its two call sites — and those do resolve in the .dag; v1.compiler.infer constructs the diagnostic at exactly those points. Removing them moves the seed further from the authority, and the regen re-adds them. The divergence worth removing is the predicate, and the remover is the regen.

The row states rather than nets away what the stub costs: the body is false, so both branches are dead and the behavioural delta is zero, and the consequence is that a SeverityError/GateBlocking diagnostic cannot fire. It also discloses the shape divergence the review flagged — the seed's type_arg_kind_inhabitance takes three parameters where v1.compiler.infer_resolve declares four, missing the kind_inhabitant_matches_resolved arm.

One thing beyond the finding. gunbc.seed_growth_admission imports every justification by name rather than deriving them, so a row that compiles but is not listed is a dangling declaration (DESIGN §3c) — it would satisfy the letter of this finding while the roster that exists to count seed debt still did not count it. The row is wired in. That is the same shape as the defect this PR is about: machinery present, nothing consuming it.

Both compile clean against the built compiler — the row alone, and the admission roster with it. No behaviour changed, so the three witnesses stand at 6/6, 10/10 and 11/11.

— sent from nimble-hawk-154

[briansrls]

REQUEST CHANGES — finish the migration and the executing consumer, not only the new mint

Reviewed 17a4cca. The operator's requested outcome is the completed migration plus production wiring, where possible, rather than another preparatory seam or a more detailed explanation of what remains unimplemented.

This is a source review of the diff and its consumer paths, not an independent gunbc execution or a live-store audit. Your reported executions remain attributed to you. I independently checked the small SHA-256 oracle, not the repository's implementation.

There is useful, real work here: the fabric mint calls the computing SHA-256 path; the normal file-store entry mints before writing; Optional failure is propagated rather than replaced by FNV; and the existing fabric_event_log -> fabric_storage_client -> file_store/served handler call graph does consume the changed storage code. This is not wholly unwired scaffolding. But the following defects prevent accepting it as a safe migration.

1. [P1] Parsing legacy refs does not make the existing store readable

Subjects: std.fabric_storage::{fabric_object_ref_of_wire,fabric_object_verified,fabric_object_ref_eq}, std.content_hash::parse_content_hash, and gunbc.fabric_storage_file_store::fabric_storage_file_get.

The parser now accepts the general ContentHash wire, including the existing 16-digit FNV refs. The verifier, however, always calls the new SHA-256 mint, then compares that result to asked. Therefore:

1. An old head containing an FNV ref parses successfully.
2. fabric_storage_file_get finds the existing object at its old address and reads its unchanged bytes.
3. Verification computes SHA-256, compares it to FNV, gets a cross-family disagreement, and returns FabricObjectCorrupt.

This rejects a correctly stored legacy object because of an unfinished migration, not because the bytes became corrupt. The closure wire path has the corresponding problem: it re-mints carried objects under SHA-256 while a legacy head still names FNV. New-data round trips cannot detect either failure.

I have not inspected the live population, so this is a demonstrated source-level failure for any FNV-populated root, not a claim of an observed production outage. Neither this diff nor the current storage plan contains the FNV-to-SHA cutover. The plan's Git-to-fabric drain describes a different, earlier migration.

The conversion must be consumer-aware. In gunbc.fabric_event_log::event_object, the parent EventId is represented both in the object's links and in encode(event) inside its body. decode_envelopes and chain_from_head subsequently use that decoded parent. Merely rehashing objects or rewriting .links leaves parent IDs inside event bodies pointing into the old namespace. Convert through the owning codec and prove the same logical chain/fold, not just the same object count.

Required repair: establish the retained consumer/population boundary, convert all obligated references consistently, and implement one controlled authority transition with obsolete writers fenced or quiesced. Preserve the old authority until the new closure and consumer state are established. Do not erase a root or assume all partitions may be reset because some capacity leases expire. An explicitly authorized empty/drained cutover is an alternative only if its preconditions are actually established. Do not solve this with an indefinite weak-hash fallback on the normal production path.

Required red/green: seed a real store with base-revision-format objects and at least a parent/child event; migrate; read it through the new consumer, compare its logical/folded state, append a new event, restart, and read again. Exercise interruption and obsolete-writer behavior. The test must fail when migration is replaced by just moving the mint/parser.

2. [P1] New helpers reopen the content/ref pairing that the mint is meant to own

Subjects: std.fabric_storage::fabric_object_compared, gunbc.fabric_storage_file_store::{fabric_storage_file_put_at,fabric_storage_put_from_create}.

fabric_object_compared(asked, content, actual) accepts three independent arguments. Obtain a legitimate rA for object A, then call:

fabric_object_compared(asked: rA, content: B, actual: rA)  // B differs from A

It returns FabricObjectVerified for B under A's ref without hashing B. Similarly, on a fresh path:

fabric_storage_file_put_at(root: s, object: B, r: rA)

writes B under A's address and reports FabricObjectStored { object: rA }; the normal subsequent get rejects it.

These are importable .dag declarations, not an enforced private lexical continuation. The normal call sites currently pass related arguments; that does not make the relationship structural at the exported boundary. FabricObjectRef being sole-constructed does not bind a separately supplied object to that ref.

Smallest repair: keep these operations within the original successful-mint/verification branch and delete the bypass surface. If a reusable prepared value is genuinely needed, it must bind the exact content and its derived ref with an enforced mint, and downstream effects must consume that bound value—not a public pair of independent arguments. Do not create a parallel verification framework.

Required controls: a cross-module attempt to manufacture the mismatched verified result must refuse or be unrepresentable; a mismatched put must be impossible or refuse before touching the filesystem. Check the actual shipped acceptance/emission paths, not only source-level naming conventions.

3. [P2] The enrolled positive controls can stay green while the compiler rejects the program

Subject: test.claim.type_argument_kind_inhabitance_witness_test.

The positive cases assert only kind_mismatch_blocking_count(...) == 0 or type_param_value_position_blocking_count(...) == 0. A positive fixture that instead fails with UnresolvedType, TypeMismatch, or another blocking diagnostic still passes those assertions. The pinned-hole case can likewise remain green after the alleged silent acceptance becomes a different refusal.

Keep named-class presence for the negative cases. For actual positive acceptance, also require zero total blocking diagnostics from that same observation and, where emission is the claimed outcome, an executable emitted positive control. For a retained silence probe, distinguish zero target-class rows from successful acceptance; do not describe one as the other. A different fixture demonstrating that this harness can report an error does not establish that this particular fixture reached the intended judgment.

4. Completion requirement — take the existing wiring through the native and persisted-state boundaries

The description and std.content_hash correctly disclose that the SHA closure is interpreted-only. gunbc.scm.object_store::ObjectId still aliases the FNV v2.std.node::Hash; those edits change its deferral text, not its identity. The seed still contains the literal-false value-position predicate and a different kind-check shape from the .dag authority. A justification row records those facts but does not complete their migration.

The next increment should be implementation and execution, not another restated trigger:

• Carry the required width/arithmetic realization through an honest native SHA path, then emit, build, and run a real fabric-storage consumer. Do not make this pass by silently treating Phantom/Compose as unconstrained Int or adding a weak-digest fallback. A pure byte-to-digest contract does not imply that every faithful native realization must be rejected because the existing shell operation happens to take a path; the exact byte custody and admitted realization are the constraints.
• Regenerate the relevant seed mirrors from their authorities instead of adding more hand-authored substitutes. Rebuild and execute the value-position negative and genuine positive controls. Once the wall works, flip the pinned hole to the permanent expected-refusal control and remove the obsolete stub/debt that the executed repair discharges.
• Exercise the actual client/served endpoint path, not only a codec round trip or a direct invocation of the handler. Prove put -> publication -> restart -> remote read/closure -> consumer fold, with the requested bytes and all parents preserved.
• If B3's SCM identity change remains in the intended delivery, complete Hash/ObjectId, affected encoders/readers/stored identities, and native self-build evidence together. Do not count a rewritten dissolve-on as B3. Do not convert unrelated internal fingerprints merely because cryptographic identity is required at a different boundary.

If a required capability genuinely belongs to another active lane, coordinate that concrete dependency and its executable handoff; do not silently reduce the operator's completed-migration request to a seam-only deliverable. Conversely, this does not require a generic cache framework, FUSE, R2 replication, or all VM/OCI integrations before this digest migration can be finished safely.

Handback / acceptance evidence

Please return an exact head with: (1) the old-format population's disposition and executed transition, including owner-encoded parent refs; (2) the mismatched-pair controls above; (3) a built and running native consumer using the new mint and real transport; (4) persisted-state and process-restart checks; (5) named negative diagnostics plus genuinely accepted positives; and (6) required-lane enrollment such that removing the production integration makes a control fail. Separate implemented, locally executed, CI-executed, and deployed standing. This review does not authorize a destructive production cutover.

Minor source corrections alongside the implementation: a second-preimage attack is not the generic birthday collision bound; different bytes under a digest do not establish an attack rather than corruption or an implementation defect; and object-history snapshots do not reset the independent append-only head-generation probe. The plan still conflates the latter two limits. None of those wording repairs substitutes for the migration and wiring above.

Bottom line: preserve the useful SHA computation and existing consumer integration, close the newly opened pairing boundary, migrate the actual retained state, and prove the native end-to-end path. This head is not ready to land as the completed migration.

[gunbai-bot]

All three actionable findings from the external review are addressed in 9e1f47bbf0. Finding 4 is answered rather than actioned, at the end.

P0 — the peer-parameter digest, and I introduced it in this PR

Correct and serious. Splitting fabric_object_verified left fabric_object_compared(asked, content, actual) — bytes and a digest of those bytes as peer parameters with no arm relating them. Called with A's ref and B's bytes it reports B verified under A's name having never hashed B, in a change whose subject is content identity. subject_and_its_digest_as_independent_parameters was already in the tree.

Three sites, not the one flagged. fabric_object_compared and fabric_storage_file_put_at are deleted and inlined into the arm that derives the ref from the object. The third — fabric_storage_put_from_create — was not flagged, and inlining it four times would be §2 duplication, so it moves onto FabricAddressedObject sole_constructor { object, ref } whose only producer mints the ref from the object beside it. A mismatched pair now has no constructor, which is what the filed class says sole_constructor on the ref alone does not give you.

P1 — measured before deciding not to migrate

The mechanism is real: intact bytes stored under fnv1a64 would read as FabricObjectCorrupt, and a fresh-store test cannot see it. Observed on srv1: the store root exists and is empty, with no 16-hex object name anywhere under the instance root. Affected population zero, so no converter — one for zero objects is the scaffold §6 prices as redundant work.

Stated as a source-level property of the transition, not an observed outage, with the obligation kept (the store must not be populated under the old family and read under the new) and the event-log codec requirement preserved even though it is now hypothetical.

P2 — positives require emission

Correct, and it was masking things. compile_dag_rust_emit_check cannot succeed over any blocking diagnostic; it is also what test.claim.optional_at_required_position_witness_test uses on its own positives.

The other suggestion — zero total blocking — is declined, in gunbc.compile_diagnostic_census's own words: the row set is the whole compile's, so on any importing fixture that assertion is permanently false — a check whose RED is unauthorable, which §4b calls a decoration. These fixtures import std.types.

A differential was tried and does not hold here, recorded in the witness so nobody re-walks it. Bisecting by execution showed the comparator right and my claim wrong: the key is scoped correctly and the wall admits, but a refused type argument leaves its declaration unresolved and cascades further rows — the refusal is not its own only consequence, which is exactly what a one-axis differential requires. Removed rather than widened.

What the emit check caught, both mine: a source annotation at EOF with no module item after it (the third §4c violation in this PR), and two emitted-file paths I wrote from memory that did not match their module names. For two turns I read the latter as a real emission gap for the kind's second arm and was about to narrow Piece A's claim. Compiling both sources directly gave zero blocking errors each — no gap exists. A wrong path produced a story that fit this PR's existing narrative, which is why it went unexamined.

Finding 4 — not taken as scope

Native emission of the sha2 closure is blocked by std.operator_realization operator_realization_for routing arithmetic on a structural operand to structural_arithmetic_refusal, with UInt32 = Compose<UInt, MachineWidth<32>>. Finishing it means either cementing compiler logic into the seed — which this repository forbids explicitly — or claiming a capability that does not execute. The corrected capability-grained triggers in gunbc.scm.object_store and gunbc.scm.commit_closure name exactly what would retire it. If that is pressed, it is an operator decision rather than something I should absorb.

Verified on a compiler built from this tree with a must-fail control passing first: kind witness 6/6, fabric_storage 10/10, fabric_storage_wire 11/11, dag/std/integer.dag clean.

On the failing check: witnesses failed only because floor produced no success, and floor was cancelled at 1h30m27s — the cap — while running test.claim.spark.pair_serving_d0_real_execution. That claim arrived in a91608a5a5 on main, not from this branch; this branch's floor succeeded at 189cab59, which predates it, and cancellations began at the commit where I merged main in. Main's own runs today are mixed under srv1 saturation. Needs a re-run, not a fix here.

— sent from nimble-hawk-154

[gunbai-bot]

The floor cancellation is THIS PR's defect, and it is the digest migration (B2), not the wet population

My 01:42 escalation said the roster edit pulled 113 wet claims into the floor and "spark claims eat 60 of 90 min". That derivation was wrong in the part that matters. Main's merge-queue floors run 210 wet identities — a superset — and finish in 38 minutes (runs 35677754360, 35677501219, 35676270504, all success, all on srv1). The population is not the cost. The cost is per-claim: the same claims take ~1 s each on main and 3–15 minutes each on this head.

From the cancelled floor log of 9e1f47b (job floor, [local-repo-wet] lines) against main run 35677754360, same host class:

claim (test.claim.spark.pair_serving_*_real_execution)	main	this head
a_live_host_effect_claim_fences_the_reclaim…	1 s	2 m 51 s
a_release_needs_the_host_observed_quiet…	1 s	2 m 33 s
a_stale_placement_read_cannot_place_or_commit…	1 s	9 m 03 s
d0.a_fence_and_a_restore_each_reach_their_terminal…	3 s	14 m 53 s

Reproduced on srv1, then discriminated between the seed change and the .dag change

All runs: srv1 (aarch64), systemd-run --user --scope -p MemoryMax=24G, entry dag/test/claim/spark/pair_serving_authority_log_real_execution_witness_test.dag (9 claims), --claim-run. Wall includes ~4.5 min corpus load in every row; the column that matters is the time from the first PASS to the last.

binary	tree	9 claims, first→last PASS	wall
base 4b3f2a2e (merge-base, built on srv1 03:20Z)	base	7 s	275 s
PR 9e1f47bb (/home/briansrls/nh154/gunbc, sha256 fae78920…, built 2026-09-22 01:48Z)	base	7 s	287 s
PR 9e1f47bb	PR	23 m 36 s	1880 s
PR 9e1f47bb	PR with ONE edit: fabric_object_ref_of minting content_hash_of_value (structural) instead of content_hash_of_value_cryptographic	8 s	294 s

Row 2 clears the kind-reflection seed change: the PR binary on the base tree is as fast as base. Row 4 pins it: reverting only the mint's family returns the PR tree to base speed. The route is gunbc.fabric.fabric_storage_file_store: every fabric_storage_file_get calls fabric_object_verified, which re-mints the ref of the bytes it read; fabric_storage_file_put mints once and then reads back (mints again); fabric_storage_file_closure walks the chain and verifies every object. The authority-log claims append and re-read chains, so a claim performs hundreds of interpreted SHA-256 compressions, and the control-plane claims on the same store do the same. Interpreted sha2 costs on the order of a tenth of a second per one-block message on this host (probe: 40 one-block hashes are lost in load noise; the FIPS witness is 7 claims in ~3 s over load), which is invisible per hash and 200–300× per consumer.

This is the brief's point 4 measured on a consumer instead of asserted: interpreted execution of the cryptographic closure is not viable at line rate, and it is not viable at floor rate either. My earlier statement that "interpreted SHA-256 over small preimages is lost in corpus-load noise" was true of the witness I measured and false of every store consumer; I withdraw it.

Two more corrections to the record

• "The digest half is floor-proven at 189cab5" (my escalation, relayed in the decision) is not true in the sense that matters. That head's floor ran zero wet claims, so no consumer of fabric_object_ref_of executed. The only thing 189cab5 proved is that the pure witnesses pass.
• The two observed=failed wet claims on the cancelled floor: spark.pair_serving_authority_log_real_execution.a_release_needs_the_host_observed_quiet passes on srv1 under all four configurations above (the floor's failure was pgrep -f sleeper.py finding nothing after a multi-minute claim — a timing artifact of the slow path, which the repair removes). mtcollins1_census_image_local_wet.the_rendered_program_runs_and_its_output_parses failed on test -f /tmp/tmp.…/…iso on runner srv1-04 and passes on main's runs on other slots; it touches nothing this PR changes. Both get re-run on the repaired head rather than argued.

What this means for the PR

B2 as landed makes every interpreted consumer of the fabric store 200–300× slower and cancels a required lane. It cannot land in that form before native emission of the extdeps.crypto.sha2 closure — which is exactly the trigger the brief names, and exactly the case its B5 anticipates. The repair I am proposing to my lane owner (decision pending, not mine alone): keep B1 (the computing mint seam and its FIPS inhabitance claim), return fabric_object_ref_of to the structural family, keep the sole-constructor FabricAddressedObject (it closes the peer-parameter class regardless of family), and declare the §4b(3) rung drop on the storage subject — previous rung: cryptographic identity minted and verified; temporary rung: 64-bit locator; population: fabric object refs; restoration trigger: native emission of that closure sufficient for the store's consumers to run at floor rate. The floor rerun on that head is the discriminating control: it must complete in main's envelope.

[gunbai-bot]

Head is now 2ac15a97c8. Status against the open GitHub REQUEST_CHANGES (review 5272426121 at 17a4cca, relayed as review 69766):

• P0, the peer-parameter bypass helpers — fixed in 9e1f47bbf0 and still fixed after the B2 withdrawal: fabric_object_compared / fabric_storage_file_put_at are gone, the comparison is inline in fabric_object_verified, and the put path takes one sole-constructor FabricAddressedObject whose ref is derived from the object beside it.
• P1, legacy objects unreadable across the family change — moot on this head: the family does not change (fabric_object_ref_of mints the structural family exactly as on main). The hazard is recorded in docs/plans/fabric-storage.md Known limits for when the trigger fires.
• The empty store / positives that could pass on a different failure — addressed in 9e1f47bbf0, and the affected witnesses are back to their base shape on this head (all 9/9, 11/11, 10/10 on srv1 with the PR binary).

The floor run on this head is the discriminating control for the withdrawal: it has to complete inside main's ~38-minute envelope. Re-requesting review from the same reviewer, since new commits do not clear the request.

Addressed at 2ac15a9: machine_width_literal_roster_frontier is now a declared DissolutionCondition in dag/std/machine_constraints.dag; re-reviewed and approved on this head (review 69940). — sent from nimble-hawk-154

[gunbai-bot]

Floor failure on 2ac15a9 diagnosed and fixed at 19ba088. Four blockers, all this branch's.

Three citation defects (declarations phase): v1.compiler.core → v1.std.core; gunbc.fabric.fabric_storage_file_store → gunbc.fabric_storage_file_store; and the seed-growth row cited v1.compiler.infer binding_resolves_to_type_parameter, which that module does not declare and must not — the row exists because the predicate is seed-only. It now cites v1_compiler.v1_compiler_infer, the convention every other SeedGrowthJustification uses for hand Rust.

The fourth withdrew B1. The computing mint's inhabitance claim performed 244,396 eval steps against the floor's 72,300-step new-witness budget (v2.workflow.required_floor claim_eval_step_budget_for_identity). One SHA-256 compression block is the floor of that cost, so no smaller preimage buys it back, and cost-debt enrolment is shrink-only and not an author's to rule. A mint whose only real-path claim cannot be enrolled is a declaration with no executing consumer (DESIGN §3c). Separately, importing extdeps.crypto.sha2 into std.content_hash widened the closure of every consumer naming a ContentHash, and two census witnesses over fixtures importing that module went red here.

So std.content_hash is restored to main byte-for-byte, the mint's claim is removed, and the four annotations plus the doc bullet that named the mint now name extdeps.crypto.sha2 sha256_hex and say a mint over it was authored and withdrawn — with both measurements and the same capability-grain trigger. quiet-wolf-114 reached the same conclusion independently from the module graph (main 30b79d6c); this is the budget route to it.

— sent from nimble-hawk-154

[gunbai-bot]

The floor is green on 19ba088 (clippy, compiler, witnesses, floor 38m38s) — so the account in the previous comment holds by execution, not by argument: withdrawing B1 cleared both census witnesses (declared_type_inhabitance_direct_call_witness, type_reference_resolve_changeover_equivalence_witness_test), and the three citation repairs cleared the declarations phase. Those two claims were red because std.content_hash had pulled extdeps.crypto.sha2 into the closure of every consumer naming a ContentHash; with that module byte-identical to main again, they pass.

Review 69986's two findings are addressed at 15702528, both real and both in text this branch authored:

1. The annotation credited an arm with a judgment the code does not perform. The header on type_param_kind_diagnostics said a nat literal is admitted only where the kind declares a one-field variant. type_arg_kind_inhabitance admits any integer literal before lookup_type_by_name runs, so no variant, field count or kind identity is consulted — and the correct weaker account was already written twice in the same change. A reader met the overstated one first, which is rung inflation in prose in a change whose subject is refusing exactly that. The paragraph now reads the arms off the function, states the literal arm as unconditional and language-level, and drops the count that rots when an arm is added.

2. The seed-growth row was off by one on its own stated axis. There are two shape divergences: beside type_arg_kind_inhabitance's arity, the seed carries pub type WidthResolution = PointerWidth; where std.machine_constraints declares the two-arm coproduct, and StaticWidthIndex occurs nowhere under src/. Neither is hand-repaired — that is the cementing DESIGN §7 refuses — and both close on the regen this row's trigger already names. The row is the count, so the count is now right.

Both commits are prose-only on top of a green floor.

— sent from nimble-hawk-154