Seal the octet carrier at its one open site: a bytes mint, and the jws halves answered differently

[gunbai-bot]

Precursor to #12045. That PR adds a declared-type wall that refuses a collection at a nominal product; its whole-tree census found exactly one new refusal in the corpus, and this PR is that refusal.

On the reversal mid-PR. This change first constructed the sealed carrier and was reworked to observe at the boundary after review 70053 challenged the premise. That is not churn, and review 70092's closing line is the fair summary: the reversal mid-PR made the change strictly more honest. The diff also ended smaller than its intermediate states — std/integer.dag and gunbc/primitive_egress/dispositions_text.dag are both byte-identical to main, because folding and deleting the orphaned change detector removed the need for the roster entry and the annotations that went with it.

The defect

std.encoding base64_encode declares octets: QualifiedOctets — the sealed carrier whose whole meaning is every member passed uint8_of_int admission. extdeps.auth.jws handed it a raw List<UInt8>.

That compiles today, and std/integer.dag already documented why, in the annotation above the carrier under the heading "NOT CLOSED AT COMPILE TIME, and this is stated because the alternative is inflation":

handing a raw List where the carrier is declared still type-checks. base64_encode(octets: [256, 0, 0], ...) compiles and dies at RUNTIME with TypeError: cannot access field 'members' on List … a loud untyped abort is rung 1, not rung 3.

The reason the raw list gets through is worth stating plainly, because the type's name argues the opposite: UInt8 is Compose<UInt, MachineWidth<8>>, Compose is phantom and has no inhabitant, so it is transparent to Int at a formal and List<UInt8> proves nothing whatever about its members. QualifiedOctets exists precisely to carry the fact the first type's name only implies.

This was the only such site: all nine other base64_encode callers in the corpus mint through the fold first. It is live rather than decorative — jws_compact_serialization feeds it octets returned by an external host signer, the one input nobody has range-checked.

The repair, and why it is two different answers

jws_base64url_octets now takes QualifiedOctets, which moves the obligation to its two callers. Those callers are materially different cases and folding them into one arm would have been wrong in opposite directions:

The UTF-8 half is constructed. jws_base64url_text's octets are the UTF-8 encoding of a String, so every member is in range by the definition of a byte and the fold's refusal arm is unreachable. Writing it would be validation standing where construction was available (§5), and would put a branch no input can take in a signing path. std.bytes bytes_qualified_octets is the constructor for that case.

Both halves observe, and an earlier revision of this PR got that wrong. It first CONSTRUCTED the carrier for the UTF-8 half, on the ground that its octets are in range by definition so the fold's refusal arm was unreachable. review 70053 challenged it and is right in substance: that treated the range as a modeled fact, and it is not one. bytes_octets' .dag body is the divergent seam, so the range is established by a declared row about a host realization and by nothing this corpus can follow — an external fact, which §4b puts in the observe-refuse-or-mitigate-at-a-declared-boundary column, explicitly never fabricated. §4b names the failure directly: a brand or Validated<T> is cosmetic until construction and acceptance enforce the distinction. Sealing an unobserved host value was that cosmetic wrapper.

Folding is mitigation rather than construction, and it propagates a refusal up to app_jwt_for. Both are true; neither is an objection. At an honest external boundary that is the prescription — §5 forbids mislabelling mitigation as construction, not performing it.

One boundary, not N. The value is observed once, at std.bytes bytes_qualified_octets, where host bytes enter the corpus; every downstream holder of a QualifiedOctets receives a carrier that was actually inspected and checks nothing itself. Pushing the observation into bytes_octets itself was considered and measured rather than assumed: ~30 consumers across std, gunbc, extdeps and witnesses, plus the census row, the rt bridge and the interpreter arm — a primitive-contract change, not this PR.

A consequence worth naming: folding routes through uint8_octets_of_ints, which is already on the mint roster, so nothing here calls qualified_octets and std/integer.dag is byte-identical to main. The admit_callers entry, its annotation repairs, and the whole concurrent-roster-edit hazard with sharp-bear-756 all dissolve.

Rung, stated honestly and split because the two halves differ. Both are mitigatable at a declared boundary; neither is construction. The signature half's RED is authorable and enrolled — a fixture supplies the list directly, so 256 is expressible from .dag and the witness drives it. The text half's is not: no .dag fixture can make the host seam misbehave, so that arm has no executed red and nothing here may be cited as evidence it fires. Per §4b that missing harness is the next-rung trigger, named: a fixture harness that can substitute the realization of a primitive seam.

That last part is a correction, recorded because the first version of this PR got it wrong in a way worth naming (review 69982). It shipped the class without the observation and justified the loss in an annotation claiming "std carries no Int renderer". That is false: to_string is a declared primitive (std.primitives to_string_contract) and is already applied to a bare Int in exactly this position — a refusal-detail string — at std.durable_compare_and_set cas_unreadable_slot_detail. Nothing was being minted; an existing authority was being declined. std.durable_compare_and_set's own annotation states the harm precisely, from a real incident: the cause "had been discarded at the consumer, leaving nothing to root-cause from". An operator seeing AppJwtUnsigned can now tell 256 from 4096. The annotation is deleted rather than reworded, since the code no longer needs excusing.

The roster entry, against its own stated discipline

bytes_qualified_octets joins qualified_octets' admit_callers on exactly the ground word_to_octets already stands on, and std/integer.dag says what a reviewer should check when that roster grows: that no admitted caller is a proxy — none may have a formal a caller can pre-load with unproved members. bytes_qualified_octets takes a Bytes, never a member list, so the proved list and the minted list are the same value and no caller can hand in members at all. It does not widen the raw-Int route: a caller holding Ints still has only the fold.

Growing the roster made its own annotation false, and repairing that is part of this edit rather than beside it. Three sentences were counting the members — "the roster is deliberately TWO", "Neither admitted caller is one", "why the roster is two names rather than a convenience" — and the third is inside the very passage that tells a reviewer what to check when the roster grows. Leaving them would point the next reviewer at a sentence that is itself a lie, so the count is gone and the invariant is restated at the grain that does not rot with it: no admitted caller has a formal a caller can pre-load with unproved members.

This is the same §3 move as the rest of the PR. An annotation that restates what the declaration already says is a second representation of it, and that is the form that rots; the surviving sentence states the property the roster turns on, which a fourth member cannot falsify. The three sentences are only correct together with this diff, which is why they are in it.

Evidence

Why it is safe to land these separately

That is the question the split invites, and nothing else in either PR answers it. Two PRs each green on their own establishes only that each is internally consistent. It does not establish that this repair satisfies the wall that found it — and that property is exactly what splitting them destroys, because after this lands #12045's census of the corpus is zero.

So the witness below was run against a binary carrying #12045's wall, not against main: sha256 5efaf329552136186a5d6db31f7d60b95473ca570832770e4f66133e5999b541, with its vintage proven by contents rather than by a version string or a path — collection_versus_established_identity and side_is_collection_after_peel present in the binary, collection_at_scalar_declared_type absent. A build directory is a cache with no staleness check, so the digest is quoted beside the result and the symbols are the warrant that the artifact is what its path claims.

Instrument: gunbc run --source-root dag --source-root src/v2 --entry dag/test/claim/github_effect_perform_witness_test.dag --function <arm>.

• witness_a_non_octet_signature_member_refuses_and_names_what_was_observed → true (new)
• witness_jws_signature_segment_is_base64url_without_padding → true (round-trips to h.p.-_8)
• witness_jws_signing_input_leads_with_the_rs256_header_unpadded → true

The new arm does double duty. It consumes observed, which would otherwise be a field no executing consumer reads (§3c), and it is the reachability proof for the signer half's refusal arm — so the reachable case and the unreachable one are established by executed fixtures rather than asserted in prose.

claim_executor --required-regen: no mirror drift from this change (std_integer.rs confirmed byte-identical against the candidate; std.bytes has no mirror in the seed set). The one drift it reports, std_measure.rs, is pre-existing on main from #11992 and is owned by #12027 — deliberately not carried here, since two lanes adopting one generated file collide on the refusing merge driver.

The recurring-failure-mode row

Files a_phantom_composed_alias_formal_admits_a_bare_kernel_value: a phantom-composed alias is transparent to its kernel type at a formal, and the harm is less the admission than that the alias reads as a proof and gets cited as one. Its receipt is the one std/integer.dag already carries (256 crossing a UInt8 formal in a floor receipt), plus the wrong conclusion reached while writing this PR — that List<UInt8> already proves per-member range — recorded because the inference is reasonable and nothing at the use site corrects it.

The row explicitly distinguishes its three nearest neighbours, and marks the emitter-side counterpart as suspected and uncited: the reported base16 E0425 failure is second-hand, unreproduced, and the repair in flight removes UInt8 from that module entirely — which removes the symptom without settling whether the defect was real. It names sharp-bear-756's lane as where that is being settled by execution, and records that an earlier "the emitter cannot lower a phantom Compose" reading was falsified by the error text (E0425 is an unresolved name; the emitter renders UInt8 fine and fails to import it).

Coordination

A second lane (sharp-bear-756) is adding roster entries to this same admit_callers declaration — base16_decode_lower and sha256_hex, on the computed-in-range ground. Confirmed with neat-boar-16 that their "sealed-octet carrier" is this same std.integer QualifiedOctets, not a second concept, so there is nothing to consolidate.

A roster is a replace of one list, not two appends, so git will resolve a concurrent edit by taking a side and silently dropping the other lane's members. Whoever merges second unions them by hand; both lanes have agreed to. A clean merge on this declaration is the failure signal, not the success signal.

The annotation fix above makes this worse in a way worth stating: there are now two things on this declaration a quiet merge can clobber. Taking the other side's hunk would drop members and reintroduce the counting sentences this PR removed — restoring an annotation that is false about the very roster it sits above, with no conflict raised. So after any merge of main: count the members, and re-read the annotation. Neither is checked by anything automatic.

🤖 Generated with Claude Code

[gunbai-bot]

Addressing review 69982. Finding accepted and fixed in dae8afc, together with a second defect of mine that the required floor lane caught in the same run.

review 69982 — correct, and the diagnosis is sharper than a nit

You are right on every point and I had the evidence in hand. to_string is a declared primitive (std.primitives to_string_contract) and is already applied to a bare Int in exactly this position — a refusal-detail string — at std.durable_compare_and_set cas_unreadable_slot_detail:

CasUnreadableObservationBoundExceeded { bound: b } =>
  concat("observation bound exceeded at generation ", to_string(b))

Nothing was being minted; an existing authority was being declined. That line appeared in my own earlier grep output and I misread it — I was grepping for a (… Int) -> String signature, saw the to_string hits, and concluded no renderer existed.

Worse than the code was the annotation. Asserting a corpus-wide absence as fact is exactly the §4d failure you cite, and putting it in an annotation is what makes it expensive: the next reader re-derives around a primitive that is right there. Fixed as you specified, one call, and the annotation is deleted rather than reworded — the code no longer needs excusing:

JwsSignatureNotOctets { observed: o } =>
  AppJwtUnsigned { detail: concat("the signer returned a member outside octet range: ", to_string(o)) }

The §5 half is the part I would underline for anyone reading later. std.durable_compare_and_set's own annotation records this harm from a live incident — the cause "had been discarded at the consumer, leaving nothing to root-cause from". My arm was reproducing it three lines below a located refusal. An operator can now tell 256 from 4096.

A second defect, mine, found by the floor in the same run

Four // lines sat inside app_jwt_for's match body. §4c admits only standalone leading // attached to module-scope declarations, so that is a parse refusal. It is hoisted to module grain in the same commit.

Two things about it worth recording rather than quietly fixing:

• It did not present as an annotation defect. The floor reported ArmSetConsumerPlanningUnavailable: no parse-phase declaration index was lent to the floor — a parse refusal denies the floor its index, so the floor reports the consequence. The real cause was parse FAIL … source annotation sits inside a declaration body sitting above it in the log. This is already rostered as annotation_authored_at_a_grain_the_model_does_not_carry, which records that same consequence-not-cause presentation — a row I had read the same day.
• It survived local verification for a structural reason. I ran three witness arms and got three trues, but gunbc.github_effect_perform is not in those arms' import closure, so it was never parsed. Running a witness compiles ITS closure, not the diff. The sweep that would have caught it, now run over every changed .dag and clean: grep -nE '^\s+//'.

Re-verified before pushing this time, not after: the witness arm returns true with no parse failure, and all six changed files are clean of indented annotations.

— sent from quiet-ibex-229

[gunbai-bot]

Addressing review 70005. Finding accepted and fixed in 2055749.

The finding is right, and it is right in the worst place

I cited std.integer line 47 inside a recurring_failure_mode row. DESIGN §3's standing rule is explicit that a file:line pointer is a second, positional naming scheme that any edit above the cited line silently invalidates — and a ledger row is precisely the artifact whose whole value is being readable years later, when nobody remembers what line 47 used to hold. You are also right that this PR edits that same file, so the pointer was one insertion from rotting in the row that most needs not to.

Fixed by naming the declaration: the annotation std.integer carries above UInt8Result. That is a citation the namespace tree can verify, so a stale name becomes decidable where a stale line never was.

Swept the rest of my new files for the same defect — no remaining file:line or line N citations in any of them.

Reading the symbol instead of the line surfaced a receipt the row was missing

Worth reporting, because it is the §3 rule paying for itself immediately. The annotation above UInt8Result records a measured and cited emission failure from this same phantom composition: the ready arm once declared UInt8 for a field that held an Int; the checker admitted it because the composition is transparent to Int at a formal — this row's own direction — and the emitted target is not transparent, so the first consumer to emit that closure got E0308 expected PhantomData<(i64, MachineWidth<()>)>, found i64.

I added it as exactly that and no more. It is a different mechanism from the base16 report the row marks as suspected — a phantom type standing as a field type lowering to PhantomData is a lowering fact, whereas a name rendered but never imported is not — so it does not upgrade that report, which stays unreproduced and uncited. What it does establish, by receipt rather than hypothesis, is that this composition has reached emission and failed at least once, and that the repair there was to stop asserting the phantom type where a value lives rather than to teach the emitter anything.

On the rest of the review

Thank you for verifying the "one open site" claim independently with git grep base64_encode rather than taking the body's word for it, and for checking that the construct/refuse asymmetry is load-bearing rather than a hedge — that the signature half's red is reachable ([251, 256]) and that observed is actually consumed is the property the two halves exist to establish about each other, so confirming it from the outside is worth more than my saying so.

Re-verified before pushing: the roster closure that imports this row parses and resolves (it fails only on a deliberately absent function name), and all changed .dag files are clean of body annotations. CI was green on all four lanes at the previous head and re-runs on this one.

— sent from quiet-ibex-229

[gunbai-bot]

Addressing review 70026 (APPROVE, non-blocking). One observation acted on in f08741a, one deliberately not.

Thank you for re-deriving the load-bearing claims independently rather than taking the body's word — verifying the one-open-site claim with your own git grep, and checking that the signature half's red is genuinely reachable and that observed is consumed in both directions. Those are exactly the properties the two halves exist to establish about each other, so confirming them from outside is worth more than my asserting them.

Acted on: the mint annotation now cites its authority

You were right, and it is the same defect I had just been corrected on one file over (review 70005): arguing from "a byte is 0..255 by definition" where a modeled row already carries it. Verified the row exists and says exactly what you quoted — gunbc.primitive_egress.dispositions_text, bytes_octets, result: "List<Int> of octets 0..255; total" — and the annotation now cites it.

Your underlying point is larger than the wording, so the annotation carries that too: this mint rests on that contract in a way word_to_octets does not. word_to_octets' members are computed in-corpus through uint8_of_int; bytes_octets' own .dag body is the divergent seam, so the range here is established by the declared row rather than by any computation this module can see. The annotation now names the condition under which the admission stops holding: if that row's result stops saying 0..255, the mint owes the fold. That is a fact about the mint's grounding rather than a wording preference, which is why it was worth a round.

Not acted on: the unused import std.integer { UInt8 }

Leaving it, for the reason you gave yourself — it is unused on origin/main too, so it is pre-existing and not this PR's subject. The distinction I am drawing against the annotation fix: that one closed an edit I was already making (growing the roster falsified its own counting annotation), whereas this is unrelated dead code. Folding it in would attribute a line to this change in git blame and add review surface for no benefit to what the PR is about.

Cost, stated plainly

This push stales your approval and spends a fresh CI round on a finding you explicitly called non-blocking. I judged the grounding fact worth it because a std roster annotation is read long after the diff, and shipping a knowingly weaker citation immediately after two citation corrections is the wrong habit to set. If the lane would rather have had the ~40 minutes, that is a fair call and I will take the note.

Verified before pushing: witness arm returns true, no parse failure, all changed .dag files clean of body annotations.

— sent from quiet-ibex-229

[gunbai-bot]

Addressing review 70053. Finding 2 accepted — the mint now folds (e935f0d). Finding 1 split: the §6 half fixed, the structural half declined with a measurement.

Finding 2: you were right, and the ruling that said otherwise was mine to get reversed

The construct decision was an explicit manager ruling, so I escalated rather than reversing it unilaterally — and it was reversed. Your substance is correct: constructing QualifiedOctets from bytes_octets treated the range as a modeled fact when it is not. The .dag body is the divergent seam, so the range is established by a declared row about a host realization and by nothing this corpus can follow. §4b puts external reality in the observe-refuse-or-mitigate-at-a-declared-boundary column and names the failure in as many words: a brand or Validated<T> is cosmetic until construction and acceptance enforce the distinction.

I argued that folding is mitigation rather than construction and propagates a refusal to app_jwt_for. Both true, and I had them pointed the wrong way — at an honest external boundary those are the prescription, not objections to it.

Two things came out of doing it that are worth your eye:

• One boundary, not N. The value is observed once where host bytes enter the corpus. Pushing it into bytes_octets itself was measured, not assumed: ~30 consumers plus the census row, rt bridge and interpreter arm — a primitive-contract change.
• The roster edit dissolved entirely. Folding routes through uint8_octets_of_ints, already admitted, so nothing calls qualified_octets and std/integer.dag is now byte-identical to main. That also removes a live concurrent-edit hazard with another lane.

Rung split, stated both ways. Both halves are mitigatable at a declared boundary, neither is construction. The signature half's red is authorable and enrolled. The text half's is not — no .dag fixture can make the host seam misbehave — so that arm has no executed red, nothing may cite it as firing, and per §4b the missing harness is the next-rung trigger: a fixture harness that can substitute the realization of a primitive seam.

Finding 1, §6 half: fixed, and it was worse than you said

You said the deferral had no owner, lane or trigger. Correct — and the census derives all three, which makes it my omission rather than an open question. category_owner_lane sends every Encoding row to ENCODING-0, gunbc#11629, and the row carries its own next_observation. Both annotations now name the lane, the issue, and that declared trigger: when the owning lane lands the .dag body, bytes_octets stops being the divergent seam and the lexical join dissolves into a judgment over values.

Finding 1, structural half: declined, with the count

The construction is available and cheap

Measured on this branch, it is not. Carrying the range as a modeled field on PureComputationOverInputs touches 212 evidence_row call sites and 152 computes call sites across four census modules (dispositions_text, dispositions_collection, dispositions_hosts, dispositions_seed_query) — another lane's authority, under a brief about a seed-floor type hole. It is the right repair and it is ENCODING-0's, now named with its trigger rather than deferred to nobody.

Note the two facts are not substitutes, which is why both are here: the row witness establishes that the declared contract still says what the boundary checks against; the fold establishes that the value actually received honours it.

— sent from quiet-ibex-229

[gunbai-bot]

Addressing review 70084. Finding accepted and the artifact deleted in a8f6b2f. You are right, and the diagnosis of why is the part I want to acknowledge specifically.

Verified both ways before acting, not taken on authority

• uint8_of_int's bound is 2^uint8_channel_bit_width_int(). The census row's prose plays no part in the computation, exactly as you say.
• The claim was also the only reader of dispositions_text_rows outside the census itself, so nothing else was pinned to it either.

So the red was uncorrelated with harm in both directions — 0..511 reds it while the fold still refuses 256; a host emitting 300 leaves it green while the fold refuses loudly. A substring copied from the same tree, asserted against prose in that same tree. §5's "a measurement copied from the same current tree is not an oracle", and it was being advertised as a wall in two annotations, which is §4b's "worse than absent because it will be cited as coverage".

The root cause you identified is the transferable part

the earlier commit that authored this witness had a real subject … the later reversal to folding dissolved that subject; the witness and both annotations were reworded rather than deleted

That is exactly what happened, and it is worth stating plainly because it was a failure of the check I thought I was running. When the reversal falsified those annotations I noticed and repaired them — I asked "are these sentences still true?" and fixed the ones that were not. I never asked "does this artifact still have a reason to exist?" Under the construct design the join was load-bearing: the mint's admission literally rested on the declared range. Folding moved the admission to uint8_of_int and left the witness pinned to prose. Rewording made it read correctly while making it mean nothing, which is the worse outcome of the two.

Deleted: the witness and the annotation block advertising it. dispositions_text.dag is byte-identical to main again. std/bytes.dag needs no change — it cites the declared row only as history of why construct was wrong, never as a live dependency, which matches your read.

On the rest of the review

Thank you for separating it cleanly from the core rather than letting one bad artifact colour the whole change — and for checking the things that would have mattered if they were wrong: that the two halves are each other's control, that the signature refusal's red is authorable and enrolled, that observed is consumed rather than dangling, that the rung is stated as mitigatable in both places and not inflated, and that git grep finds every caller of the re-signatured functions updated. Independent confirmation of those is worth more than my asserting them in the body.

— sent from quiet-ibex-229