Octet-as-char meaning fork: declared std.encoding ASCII route, rfc_5280 Time fails closed, honest non-UTF-8 fixture + RFM

[gunbai-bot]

XL-2 follow-up (manager lively-crane-656): the four OCTET-AS-CHAR sites of RFM bare_from_code_point_binds_the_total_seed_builtin. Stacked on #13378 (still open, branch session/bright-fox-380-fcp); retarget/merge after it lands.

These sites spelled a BYTE as a character. That is a second meaning for from_code_point (DESIGN §3, meaning fork), so none migrate to from_code_point. The derivation was approved by the manager before any code was written.

Derivation

• Authority DFS. std.bytes and std.machine_word UInt8 own octets, and std.encoding owns encodings. No ASCII or Latin-1 route existed.
• Upstream.
  • Git pathnames are uninterpreted, NUL-free octet strings (gitformat-index: the entry path name is NUL-terminated; core.quotePath assumes no encoding).
  • X.509 UTCTime/GeneralizedTime are VisibleString subsets, so ASCII only (X.680 §46–47, RFC 5280 §4.1.2.5).
  • No upstream specifies Latin-1, so no Latin-1 route is declared.
• New named conversion plan (DESIGN §4): std.encoding ascii_decode_octets(List<Int>) -> AsciiDecodeOutcome.
  • Arms: AsciiDecoded{text} | AsciiNonAscii{at, octet}.
  • Partial. Exact and lossless on 0x00..0x7F, because ISO 646 IRV maps each octet to the Unicode Basic Latin scalar with the same number.
  • Realized through std.coercion unicode_scalar_fold.
  • NUL is in the domain: it is an ASCII control. A caller that uses NUL as a delimiter refuses it under its own policy.

Migrated identities

Several of these modules are outside the required gate.

identity	disposition
extdeps.git.object_store::git_ascii_field_text	Consumes ascii_decode_octets. NUL stays refused by git field policy (it is the delimiter), so behaviour is unchanged.
extdeps.standards.rfc_5280::ascii_of	Removed. New read_time_text consumes ascii_decode_octets. A non-ASCII Time octet refuses with the new arm X509Refusal::X509TimeNotAscii{at, octet}.
test.claim.git_upstream_model_witness::witness_git_ls_tree_z_preserves_non_utf8_path_octets	Confirmed: it already supplies a real 0xFF octet through std.bytes octets_bytes([255, …]), so the non-UTF-8 property is held at the decode interface. Its only bare call was the TAB constant, now std.unicode.scalar char_text(c: 9) (a Char constant, not an octet decode).
test.manual.git_upstream_model_execution::git_r0_typed_execution_read_back	raw_name was concat(from_code_point(255), ".dag"), written through the String path carrier. On disk that is C3 BF .dag, valid UTF-8, so it never exercised a non-UTF-8 path. Renamed honestly to non_ascii_name (char_text(c: 255)).

Behaviour change: rfc_5280

ascii_of was total: it spelled any octet as Latin-1 text, which is an implicit lossy crossing. A Time carrying a non-ASCII octet now refuses (X509TimeNotAscii) instead of being admitted as fabricated text. This fails closed, as DESIGN §5 requires. A VisibleString cannot carry 0x80..0xFF, so a conforming certificate is unaffected.

Gap recorded (DESIGN §4d)

New RFM gunbc.recurring_failure_mode.non_utf8_path_fixture_spelled_through_a_string_path_carrier. No executing path proves a real non-UTF-8 filesystem→git→read-back round trip, because extdeps.filesystem's path carrier is String.

• Next-rung trigger: a filesystem octet-path carrier.
• Sufficient for: the manual fixture creating, adding and reading back a name containing octet 0xFF.

The parent RFM's OCTET-AS-CHAR population is updated to 0 identities, 4 dispositioned. No new bare from_code_point caller is added. The CHAR-kind identities in the same modules (git_store_object_canonical_hash_input NUL, ls_tree_z_record) belong to the CHAR population and are untouched here.

Controls (claims run remotely on the exact head with --claim-run)

• test.claim.ascii_decode_octets_witness_test (new):
  • positive control: [0, 9, 65, 127] decodes exactly, NUL included.
  • RED: [46, 255, 128] refuses at position 1 with octet 255.
• test.claim.x509_rfc5280_witness_test::a_non_ascii_time_octet_refuses_and_an_ascii_time_reads:
  • supplied UTCTime DER, one octet 0xB2 → RED refusal X509TimeNotAscii{at:1, octet:178}.
  • ASCII twin reads "22Z".
  • The real path is the_sample_leaf_reads_as_openssl_reads_it (validity goes through read_time).
• All PASS:
  • x509_rfc5280_witness_test (15/15)
  • git_upstream_model_witness_test (all, including the non-UTF-8 witness and every git_ascii_field_text consumer)
  • heal_candidate_witness_test (12/12; gunbc.heal_candidate consumes git_ascii_field_text)
• test.manual.git_upstream_model_execution: FAIL on the runner identically on the base branch (std.unicode.scalar: partial from_code_point (typed refusal) + char_text; migrate v2 callers #13378 head, same dispatch), so the failure predates this change. The log shows the fixture writing ÿ.dag, which confirms the UTF-8 finding.
  • Typed cause (pre-existing, outside the gate; probed on the runner because the test collapses it to false): git_r0_typed_execution_read_back → GitR0LiveFixtureExecutionRefused { diagnostic: "git-ls-tree-z-decode-refused" }, raised where extdeps.git.object_store git_decode_ls_tree_z decodes the git -c core.quotePath=false ls-tree -z --format=…%x00… stdout. The inner cause, which the test discards as cause: _, is GitLsTreeZFramingRefused { GitNulQuartetIncompleteRecord { field_count: 0 } }. The result is identical on the std.unicode.scalar: partial from_code_point (typed refusal) + char_text; migrate v2 callers #13378 base. Not rostered under dag/gunbc/recurring_failure_mode; the manager will route it.

No floor_cross_claim_pure_producers_warm rows; no fill-debt rows needed.

🤖 Generated with Claude Code