@sanning/proof 0.19.0 → 0.20.0

package/src/message-parts.ts

@@ -1,275 +1,115 @@
 /**
- * A file part's BYTES, and what a receiver holding them commits to.
- *
- * `envelope-spec.md` section 4.1 (v1.13, amendment A18, proof#145, ratified by
- * Phil 2026-09-22). The Python half is `src/sanning_proof/message_parts.py` and
- * the two are held together by `cross-kernel/run_parts.sh`.
- *
- * THE DEFECT THIS CLOSES. Section 4.1 said "Binary and file parts are committed
- * by their own content hash inside that canonical object" and stopped, which
- * decided half of "an altered part fails". Measured against both SDKs
- * (anchor#219, attack 1, in both languages): a transport that keeps a part's
- * DESCRIPTOR and swaps its BYTES produces `accepted`. No exception, no finding,
- * and nothing in either record: the descriptor's hash and the bytes' hash sit
- * side by side and no rule ever compared them, so both sides commit to the same
- * message object and the pair reads `verified`. Swapping the bytes AND the
- * descriptor was caught all along. This is the sixth instance of one class in
- * this section, "a deviation produces nothing and a reader is obliged to call
- * it clean", and the repair is the same shape as A13's and A14's: remove the
- * silent branch rather than narrow it.
- *
- * THE RULE, which is the smallest additive one that closes it:
- *
- *   * a file part is `kind: "file"` plus `content_hash` (64 hex characters,
- *     either case, the SHA-256 of the part's exact bytes) and `content_length`
- *     (a safe integer), and the bytes are NOT in the message;
- *   * a receiver handed a part's bytes MUST hash them, and where the digest is
- *     not the descriptor's, or the byte count is not the descriptor's, it
- *     commits to the message AS IT ACTUALLY HELD IT: that part's
- *     `content_hash` and `content_length` replaced by the held bytes' own,
- *     nothing else touched. Its `handoff.received` then commits to a different
- *     message object from the sender's, so the formed pair FAILS on
- *     `message_hash`, a failure section 4.1 already names, and the receiving
- *     side writes `outcome: "rejected"`. That is the ONE reading that moves,
- *     and it moves only for a receiver that holds the bytes;
- *   * every other deviation is named and none is silent. Three of them are
- *     REFUSALS of one supply, so a receiver's own decoding defect never becomes
- *     permanent evidence against an honest sender;
- *   * an inline part is ACCEPTED, and it is committed by the MESSAGE ITSELF
- *     (proof#157, ratified by Phil 2026-09-22). `message_hash` is SHA-256 over
- *     the canonical bytes of the message object, so a part carrying its content
- *     inside the message is already committed: alter that content and the
- *     message object changes, the hash changes, and the pair fails. None of the
- *     swapped-bytes attack applies, because that attack works only where a
- *     descriptor's hash and bytes travelling BESIDE the message are two
- *     separate things with nothing comparing them. Inline is not the risky
- *     shape, it is the safest one. Where an inline part ALSO carries a
- *     `content_hash` or a `content_length`, the receiver checks BOTH against
- *     the inline content and names a disagreement: one commitment governs, and
- *     a second one present and disagreeing is itself a finding.
- *
- * WHY THE HELD MESSAGE RATHER THAN A FINDING ON THE RECEIVING SIDE. A finding
- * only the receiving side's own reader sees is the shape of every laundering
- * path this section has closed: the party being audited publishes the pack, so
- * a deviation that lives outside the committed record is a deviation that party
- * chooses whether anyone reads. `message_hash` is the one value both sides
- * publish and a reader already grades.
- *
- * WHAT DOES NOT MOVE. A receiver that never holds a part's bytes checks
- * nothing, substitutes nothing and reads exactly as it did before this
- * amendment: every file part is `PART_UNCHECKED`, and section 4.1 forbids
- * treating an unchecked part as a checked one. No envelope field moves, no
- * `spec_version` moves, no verdict word and no record-layer finding is coined.
- *
- * A REFUSAL IS SCOPED TO ITS PART, AND THE RECORD IS STILL WRITTEN (proof#156
- * gate). The first cut of this module refused GLOBALLY: one refusal anywhere
- * set `heldMessage` to null and dropped every substitution. That made the
- * attack A18 exists to close launderable (a genuine swap on part 0 plus any
- * refusal-triggering supply on part 1 wrote nothing at all), let a SENDER deny
- * the receiver a record with an upper-case `content_hash` or a `"bytes": null`
- * on an otherwise conformant descriptor, and contradicted section 4.1's own
- * paragraph saying an uncheckable part is NAMED in the receiver's reading. So
- * a problem with one part names that part, leaves the rest of the reading
- * intact, and `heldMessage` is never null. A message-level problem is reserved
- * for a message-level condition, and even then it produces a named result:
- * `PARTS_NOT_AN_ARRAY`, and the entry-scoped `BYTES_FOR_UNKNOWN_PART`.
- *
- * WHAT THE CALLER STILL OWES, AND THE ONE FUNCTION THAT STATES IT.
- * `substituted` decides whether a hand-off is `rejected`; it does NOT decide
- * whether one is clean. A part that was refused reads `PART_UNCHECKED`,
- * section 4.1 forbids a reader treating an unchecked part as a checked one,
- * and a surface reporting a hand-off states how many parts were checked. A
- * caller that wrote `accepted` on "nothing was substituted" alone would be
- * calling a part it never established clean, which is the class this whole
- * section keeps repairing.
- *
- * The sharp version, measured (proof#156 second gate, F5): deliver a tampered
- * copy of a part ALONE and it is `part_mismatched`, substituted, and the pair
- * fails on `message_hash`. Deliver the tampered copy AND the true one and it
- * is `conflicting_part_bytes`, `part_unchecked`, nothing substituted, a
- * `heldMessage` byte-identical to the sender's, and the pair VERIFIES. Adding
- * data suppresses detection, and the refusal that names it lives only in
- * `refusals`, which is a finding only the receiving side's own reader sees:
- * the exact shape the paragraph above refuses to create.
- * `PART_ENCODING_MISMATCH` has the same property.
- *
- * Until that round the obligation was PROSE IN THIS COMMENT with no mechanism,
- * which is a rule a caller has to read to obey. `uncheckedHeldParts` is the
- * mechanism's additive half: it names the parts the receiver HELD bytes for
- * and did not check, so a caller writes `accepted` only where `substituted` is
- * empty AND that list is empty, instead of re-deriving it from the refusals.
- * It cannot make the mistake IMPOSSIBLE, because this module reads and does
- * not write the record. What the record layer does with the list was
- * proof#162, and Phil ratified it on 2026-09-22: `outcome: "accepted"` keeps
- * meaning what it means today, and the count of held-but-unchecked parts
- * rides in an ADDITIVE `context` key, REQUIRED when it is not zero. Its force
- * is against SDKs through conformance vectors rather than against records
- * through readers, since only the receiver knows what bytes it held, so THIS
- * LIST IS WHAT EVERY SDK BUILT ON THE RULE WILL COUNT. A part missing from it
- * is a part no record will ever mention (anchor#191 is the first caller).
- *
- * WHAT THIS MODULE DOES NOT DO. It does not canonicalize and it does not hash
- * the message. It returns the message a receiver commits to, and the caller
- * hashes that with the rule section 4.1 already states, so this module has no
- * failure mode of its own for a message too deep or not serializable and there
- * is no branch here where one kernel throws and the other returns.
+ * File parts of a hand-off message, and the message a receiver holding their
+ * bytes commits to (envelope-spec.md §4.1). Conformance:
+ * `test-vectors/handoff/parts/`.
+ *
+ * A file part is `kind: "file"` plus `content_hash` (SHA-256 of the exact
+ * bytes, 64 hex in either case) and `content_length` (a safe integer), with
+ * the bytes outside the message. A receiver handed a part's bytes must hash
+ * them. Where the digest or the length differs from the descriptor, the
+ * receiver commits to the message as it actually held it: that part's
+ * `content_hash` and `content_length` replaced by the held bytes' own. Its
+ * `message_hash` then differs from the sender's and the pair fails, so a
+ * transport that keeps the descriptor and swaps the bytes is caught in the
+ * committed record, not in a finding only the receiver's reader sees.
+ *
+ * An inline part (content inside the message) is committed by `message_hash`
+ * itself. If it also carries a `content_hash` or `content_length`, both are
+ * checked against the inline content and a disagreement is named.
+ *
+ * A refusal is scoped to its part and never stops the record being written:
+ * `heldMessage` is never null, so neither a sender nor a bad supply can deny
+ * the receiver a record or launder a swap on another part.
+ *
+ * `substituted` decides `rejected`; it does not make a hand-off clean. A caller
+ * writes `accepted` only when `substituted` and `uncheckedHeldParts` are both
+ * empty. Supplying a tampered copy alongside the true one reads
+ * `conflicting_part_bytes` with nothing substituted, so held-but-unchecked parts
+ * must be counted in the record.
+ *
+ * This module does not canonicalize or hash the message; the caller hashes
+ * `heldMessage` as §4.1 states.
  */
 import { sha256Hex } from "./crypto.js";
 
-/**
- * The result of a part whose supplied bytes hash to its `content_hash` AND
- * count to its `content_length`.
- */
+/** The supplied bytes match both `content_hash` and `content_length`. */
 export const PART_MATCHED = "part_matched";
 
 /**
- * The result of a part whose supplied bytes miss either of those, with no
- * respelling of them that explains the digest. The held-message substitution
- * applies to this part, and it replaces BOTH values with the held bytes' own.
+ * The supplied bytes miss either value, and no respelling explains the digest.
+ * The held message replaces both values with the held bytes' own.
  */
 export const PART_MISMATCHED = "part_mismatched";
 
-/**
- * A file part whose bytes were not supplied, or whose supply was REFUSED. It is
- * not checked and it is not clean: section 4.1 forbids a reader treating it as
- * checked.
- */
+/** Bytes not supplied, or the supply was refused. Not checked, and not clean. */
 export const PART_UNCHECKED = "part_unchecked";
 
 /**
- * A `kind: "file"` part carrying its content inside the message, and ACCEPTED
- * (proof#157, ratified by Phil 2026-09-22). It is committed by the MESSAGE
- * ITSELF: `message_hash` is SHA-256 over the canonical bytes of the message
- * object, so altering that content changes the message, changes the hash, and
- * fails the pair. Nothing is hashed against it here and nothing is substituted,
- * because there is nothing travelling beside the message for the message to
- * disagree with. That is why the swapped-bytes attack cannot reach this shape.
+ * A file part with its content inside the message, committed by
+ * `message_hash` itself. Nothing is hashed or substituted.
  */
 export const PART_INLINE_BYTES = "part_inline_bytes";
 
 /**
- * An inline part whose `content_hash`, `content_length` or both DISAGREE with
- * its inline content: no single reading of that content satisfies every claim
- * the part writes beside it. The message's own commitment still governs and
- * nothing is substituted; this names the SECOND claim that disagrees with it,
- * which is a finding in its own right (proof#157).
- *
- * ONE name for both claims, exactly as `PART_MISMATCHED` is one name for both
- * on a descriptor part. It was `part_inline_hash_mismatch` for one round of
- * this unmerged PR, when only the hash was compared; a name that says "hash"
- * about a result that also covers a length asserts more than its body does, so
- * the name was re-cut with the rule (proof#156 second gate, F4).
- *
- * The check is deliberately permissive ACROSS readings: the raw UTF-8 of the
- * value, its base64 decoding and its hex decoding are all tried, so this fires
- * only where no reading agrees at all. It is not permissive BETWEEN claims: one
- * reading has to satisfy all of them, because a hash that agrees under the
- * base64 decoding beside a length that agrees under the raw text describes no
- * blob that exists.
+ * An inline part whose `content_hash` or `content_length` disagrees with its
+ * inline content. The raw UTF-8, base64 and hex readings are all tried, but one
+ * reading must satisfy every claim present. Nothing is substituted.
  */
 export const PART_INLINE_MISMATCHED = "part_inline_mismatched";
 
 /**
  * `kind: "file"` without a conformant `content_hash` and `content_length`. A
- * sender's defect rather than a receiver's, so it is named rather than refused:
- * the receiver did nothing wrong by holding it.
+ * sender's defect, so it is named rather than refused.
  */
 export const PART_MALFORMED_DESCRIPTOR = "part_malformed_descriptor";
 
-/**
- * Any other part. It is committed as ordinary JSON content and this rule checks
- * nothing about it.
- */
+/** Any other part: ordinary JSON content, not checked by this rule. */
 export const PART_NOT_A_FILE = "part_not_a_file";
 
 /**
- * REFUSAL of ONE supplied entry. Bytes were supplied for no part of the
- * message, or for a part this rule cannot check. The caller and the message
- * disagree about what was sent, and hashing bytes against a part that is not
- * there establishes nothing. Where the entry names a part that EXISTS but is
- * not checkable, the refusal carries that part's index and the part keeps the
- * result it classified to; where it names no part at all, the refusal carries
- * the entry position and no part. Neither stops the record being written.
+ * Refusal of one supplied entry: it names no part, or a part this rule cannot
+ * check. Carries that part's index when the part exists, else only the entry
+ * position.
  */
 export const BYTES_FOR_UNKNOWN_PART = "bytes_for_unknown_part";
 
-/**
- * REFUSAL. Two DIFFERENT byte strings were supplied for one part. A receiver
- * holding two answers has not established which one it held.
- */
+/** Refusal: two different byte strings were supplied for one part. */
 export const CONFLICTING_PART_BYTES = "conflicting_part_bytes";
 
 /**
- * REFUSAL of ONE supplied entry. The supplied bytes miss the descriptor, but a
- * base64 or hex RESPELLING of them in EITHER direction hashes to it: either the
- * bytes DECODE to the part (the receiver's stack never decoded what it was
- * handed) or they ENCODE to it (the receiver's stack decoded bytes the sender
- * committed in their encoded spelling, which is what a single-line DER
- * attachment, a PEM body and a JWT all are). That is a coding defect in the
- * receiver, not a tamper by the sender: a proto3 JSON transcoder re-encodes
- * base64 URL-safe and unpadded while behaving honestly, and under the silence
- * this amendment removes it produced a permanent tamper record against a sender
- * who did nothing. Recording evidence out of a receiver's own bug is the one
- * outcome worse than recording nothing, so BOTH directions are guarded
- * (proof#156 gate): guarding only the decoding direction left the other half of
- * one honest stack's behavior reading as a tamper.
+ * Refusal of one supplied entry: the bytes miss the descriptor, but a base64
+ * or hex respelling in either direction hashes to it. That is a receiver's
+ * coding defect (an undecoded supply, or a decoded PEM, DER or JWT the sender
+ * committed as text), not a sender's tamper, so it must not produce a tamper
+ * record.
  */
 export const PART_ENCODING_MISMATCH = "part_encoding_mismatch";
 
 /**
- * A MESSAGE-LEVEL result. The message carries a `parts` key whose value is
- * present and is not an array, which is how proto3 JSON encodes a map and so is
- * reachable from the same transport family the motivating example comes from.
- * Section 4.1 asks for one result per part; a message shaped like this has
- * part-shaped content and no parts, and before proof#156's gate it produced
- * zero readings and an accepted record. It is named rather than refused: the
- * receiver did nothing wrong by holding it, and nothing in it is checked. A
- * `parts` written as `null` is an ABSENT `parts` and is not this, on A14's
- * ruling that an absent value and one written as `null` name one thing.
+ * Message-level: `parts` is present, not null and not an array (proto3 JSON
+ * encodes a map this way). Named, not refused. A `parts` of `null` is absent.
  */
 export const PARTS_NOT_AN_ARRAY = "parts_not_an_array";
 
-/**
- * NOTE, not a refusal. One part supplied more than once with IDENTICAL bytes is
- * one supply stated twice, and the part is checked normally. Different bytes for
- * one part are `CONFLICTING_PART_BYTES`.
- */
+/** Note, not a refusal: one part supplied more than once with identical bytes. */
 export const PART_SUPPLIED_TWICE = "part_supplied_twice";
 
-/**
- * The order refusals are reported in, fixed so two kernels report one list
- * rather than two orderings of it.
- */
+/** The fixed order refusals are reported in. */
 export const REFUSAL_ORDER = [
   BYTES_FOR_UNKNOWN_PART,
   CONFLICTING_PART_BYTES,
   PART_ENCODING_MISMATCH,
 ] as const;
 
-/**
- * The order message-level results are reported in, for the same reason as
- * `REFUSAL_ORDER`.
- */
+/** The fixed order message-level results are reported in. */
 export const MESSAGE_RESULT_ORDER = [PARTS_NOT_AN_ARRAY] as const;
 
 /**
- * The results that put a HELD part into `uncheckedHeldParts`, written out so a
- * third kernel reads the rule rather than inferring it from one kernel's
- * filter (proof#156 third gate, C1).
- *
- * The line is whether the MESSAGE ITSELF commits the part's content. It does
- * not for these two: `PART_UNCHECKED` is a supply the rule refused to grade,
- * and `PART_MALFORMED_DESCRIPTOR` is a part whose content lives BESIDE the
- * message under a claim no receiver can use, so in both the receiver holds
- * bytes that nothing in the committed record covers.
- *
- * The other three results a supply can be refused against are excluded, and
- * excluded for a reason rather than by omission. `PART_INLINE_BYTES`,
- * `PART_INLINE_MISMATCHED` and `PART_NOT_A_FILE` all carry their content
- * INSIDE the message, which `message_hash` already commits on both sides:
- * bytes supplied beside one of those grade nothing and hide nothing, because
- * a reader of either pack reads the content itself. Counting them would make
- * the caller's obligation fire on parts no attack can reach.
+ * Results that put a held part into `uncheckedHeldParts`: those whose content
+ * the message itself does not commit. Inline parts and non-file parts with no
+ * URL are excluded because `message_hash` already commits their content; a URL
+ * part (`isUrlPart`) counts, because the message commits the URL and not the
+ * file behind it.
  */
 const HELD_UNCHECKED_RESULTS: readonly string[] = [
   PART_UNCHECKED,
@@ -277,33 +117,10 @@ const HELD_UNCHECKED_RESULTS: readonly string[] = [
 ];
 
 /**
- * The keys that make a part carry its content INLINE, in the order they are
- * read. Settled at `bytes` alone (envelope-spec §4.1, A31, proof#163): that
- * is A2A's spelling, the one the wedge actually emits, and it is the only
- * inline spelling either reference kernel has read from a real producer.
- * `content` and `data` were added on inference rather than on an observed
- * wire shape, and sanning-io/anchor's `filePart()` and `file_part()` SDK
- * helpers, the only producer this plane ships, confirm the inference was
- * wrong: both emit a descriptor part, `kind: "file"` plus `content_hash` and
- * `content_length`, and neither ever writes a `content` or `data` wire key
- * for inline bytes. None is A2A 1.0.0's either: its `Part` has no `kind` and
- * carries a file as `raw` or `url`, so a literal A2A part reads
- * `part_not_a_file` (envelope-spec §4.1, A19). The one key present with a
- * value that is not `null` is the inline content.
- *
- * A key present with `null` is an ABSENT inline value, on A14's ruling that an
- * absent value and one written as `null` name one thing. That matters: a
- * proto3 JSON encoder can write an unset field as `"bytes": null`, and reading
- * that as inline made a conformant DESCRIPTOR part uncheckable
- * (proof#156 gate). Such a part falls through to the descriptor rule, which is
- * what it is.
+ * The key that makes a part carry its content inline (envelope-spec §4.1).
+ * `bytes` is A2A's spelling. A key present with `null` is absent, so a proto3
+ * `"bytes": null` on a descriptor part still reads as a descriptor.
  */
-// Before A31 this list also carried `content` and `data`, and a conformant
-// DESCRIPTOR part that happened to carry either key meaning something else (a
-// filename, a caption) was silently reclassified as inline and never checked
-// against supplied bytes: the swapped-bytes check A18 exists to run
-// (proof#145) never ran on it. proof#163 is resolved by narrowing to `bytes`
-// alone, closing that gap.
 export const INLINE_BYTES_KEYS = ["bytes"] as const;
 
 const HEX64 = /^[0-9a-fA-F]{64}$/;
@@ -312,9 +129,8 @@ const LOWER_HEX = "0123456789abcdef";
 const UPPER_HEX = "0123456789ABCDEF";
 
 /**
- * The largest integer a double carries exactly, the same bound section 4.1 puts
- * on `event.sequence`: a `content_length` outside it is a value the two kernels
- * would read as two numbers.
+ * The largest exactly representable integer, the bound §4.1 puts on
+ * `event.sequence`. A larger `content_length` is malformed.
  */
 export const MAX_SAFE_INTEGER = Number.MAX_SAFE_INTEGER;
 
@@ -322,12 +138,8 @@ const BASE64_STANDARD = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012
 const BASE64_URLSAFE = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
 
 /**
- * One byte string a receiver holds, and the part it holds it for.
- *
- * `part` is an INDEX into the message's `parts` array. It is an index rather
- * than a content hash on purpose: keying the supply by the value the check is
- * about to grade would mean a receiver could only supply bytes it had already
- * agreed with, which is the whole defect stated backwards.
+ * A byte string the receiver holds, keyed by the index of its part. Keyed by
+ * index, not by hash, so a receiver can supply bytes that disagree.
  */
 export interface SuppliedPart {
   part: unknown;
@@ -341,13 +153,9 @@ export interface PartReading {
 }
 
 /**
- * A caller error. Nothing is written, nothing is signed, no record made.
- *
- * `part` is the part index where the refusal is about a part of the message,
- * and `entry` is the POSITION of the offending supplied entry in the sequence
- * the caller passed. The position is recorded rather than the value the caller
- * named, so a caller that names a part with a float or a string cannot make two
- * kernels serialize one reading two ways.
+ * A caller error. `part` is the part index where there is one; `entry` is the
+ * position of the supplied entry, recorded rather than the caller's value so
+ * every implementation serializes it the same way.
  */
 export interface Refusal {
   name: string;
@@ -356,29 +164,18 @@ export interface Refusal {
 }
 
 /**
- * Something worth reporting that refuses nothing and checks nothing out. Same
- * shape as a `Refusal` and carried in its own list, so no caller can read a
- * note as a refusal by looking only at a name.
+ * Reported, but refuses nothing. Kept in its own list so a note is never read
+ * as a refusal by name alone.
  */
 export type Note = Refusal;
 
 /**
- * The message a receiver commits to, and everything it found on the way.
+ * What a receiver commits to, and what it found.
  *
- * `heldMessage` is ALWAYS the message the receiver commits to and is never
- * null: a refusal is scoped to the supply it is about and never denies the
- * receiver a record (proof#156 gate). The caller commits `event.message_hash`
- * as SHA-256 over its JCS (RFC 8785) canonical bytes, which is the rule section
- * 4.1 already states and the reason this module does not hash anything itself.
- *
- * `messageResults` carries the message-level named results, in
- * `MESSAGE_RESULT_ORDER`. It is empty for every message whose shape the rule
- * reads.
- *
- * `substituted` carries the indexes of the parts whose descriptor the receiver
- * replaced with the held bytes' own hash and length. It is empty for an honest
- * hand-off, and where it is not empty the receiving side writes
- * `outcome: "rejected"`.
+ * `heldMessage` is never null; the caller commits `event.message_hash` as
+ * SHA-256 over its JCS bytes. `messageResults` is in `MESSAGE_RESULT_ORDER`.
+ * `substituted` lists the parts replaced by held bytes; non-empty means the
+ * receiver writes `outcome: "rejected"`.
  */
 export interface HeldMessage {
   parts: PartReading[];
@@ -398,20 +195,15 @@ function hasOwn(value: Record<string, unknown>, key: string): boolean {
 }
 
 /**
- * 64 hex characters, in EITHER case. Phil ratified proof#135 as "pin the hex
- * charset only": a case-only difference names the same value, and refusing
- * upper case here would contradict a ratified decision and punish a producer
- * who did nothing wrong. Every comparison against a digest lowercases both
- * sides, which is what the other kernels already do.
+ * 64 hex characters in either case: the hex rule pins the charset, not the
+ * case. Every digest comparison lowercases both sides.
  */
 function isHex64(value: unknown): boolean {
   return typeof value === "string" && HEX64.test(value);
 }
 
 /**
- * A byte count: an integer at least zero and inside the safe range. `true` is
- * not a number. Zero is a legal length: the empty part is a real part, and a
- * rule that read zero as "no length" would leave it unchecked in silence.
+ * A non-negative safe integer. Zero is legal: the empty part is a real part.
  */
 function isSafeLength(value: unknown): boolean {
   return typeof value === "number" && Number.isSafeInteger(value) && value >= 0;
@@ -421,17 +213,10 @@ function isSafeIndex(value: unknown): boolean {
   return typeof value === "number" && Number.isSafeInteger(value) && value >= 0;
 }
 
-/**
- * Distinguishes "no inline content" from an inline content of `null`, which
- * A14's ruling says is the same thing but which a plain `null` could not be
- * told apart from a legitimate value.
- */
 const ABSENT = Symbol("absent");
 
 /**
- * The part's inline content, or `ABSENT` where it carries none: the FIRST of
- * `INLINE_BYTES_KEYS` present with a value that is not `null`, so a part
- * spelling it twice reads one way in both kernels.
+ * The first of `INLINE_BYTES_KEYS` present with a non-null value, or `ABSENT`.
  */
 function inlineValue(part: Record<string, unknown>): unknown | typeof ABSENT {
   for (const key of INLINE_BYTES_KEYS) {
@@ -443,13 +228,8 @@ function inlineValue(part: Record<string, unknown>): unknown | typeof ABSENT {
 }
 
 /**
- * Every byte string a reader can form from an inline value: the raw UTF-8 of
- * the string, its base64 decoding and its hex decoding. Deliberately
- * permissive: this exists only to decide whether a `content_hash` sitting
- * BESIDE inline content agrees with it, and the message's own commitment
- * governs either way, so the finding fires only where no reading agrees at all.
- * A value that is not a string carries no readings, so a `content_hash` beside
- * one has nothing to agree with.
+ * The raw UTF-8, base64 and hex readings of an inline string value. A
+ * non-string has no readings.
  */
 function inlineReadings(value: unknown): Uint8Array[] {
   if (typeof value !== "string") return [];
@@ -464,19 +244,13 @@ function inlineReadings(value: unknown): Uint8Array[] {
 }
 
 /**
- * The SHAPE a part reads with before any supplied bytes are considered, or
- * `null` where the part is one this rule checks against them.
- *
- * Shape only, and synchronous on purpose: the inline hash agreement needs
- * SHA-256, which is async here and not in Python, so refining
- * `PART_INLINE_BYTES` to `PART_INLINE_MISMATCHED` happens in the reading
- * loop instead. Keeping it out of here is what lets `isFilePart` mean the same
- * thing, and have the same signature, in both kernels.
+ * The result a part reads before supplied bytes are considered, or `null` for
+ * a checkable descriptor part. Synchronous so `isFilePart` stays synchronous;
+ * the inline hash check, which needs async SHA-256, runs in the reading loop.
  */
 function classify(part: unknown): string | null {
   if (!isPlainObject(part)) return PART_NOT_A_FILE;
   if (part.kind !== "file") return PART_NOT_A_FILE;
-  // ACCEPTED, and committed by the message itself (proof#157).
   if (inlineValue(part) !== ABSENT) return PART_INLINE_BYTES;
   if (!isHex64(part.content_hash)) return PART_MALFORMED_DESCRIPTOR;
   if (!isSafeLength(part.content_length)) return PART_MALFORMED_DESCRIPTOR;
@@ -484,28 +258,10 @@ function classify(part: unknown): string | null {
 }
 
 /**
- * Whether the claims written BESIDE an inline part's content agree with it.
- *
- * Two claims can sit beside inline content, `content_hash` and
- * `content_length`, and BOTH are read (proof#156 second gate, F4). The length
- * was skipped for one round of this unmerged PR, on the argument that a reader
- * holding the message can see a contradiction between the content and the
- * claim from the message alone. That argument is true and it is also true of
- * `content_hash`, which is compared: accepting it deletes the neighboring
- * check. So the rule is the one section 4.1 already applies to a descriptor
- * part, where a hash that misses and a count that misses reach one result: two
- * claims about one blob, and reading one of them lets the other be false in
- * silence.
- *
- * A claim that is ABSENT, or is not the shape the table names, is not a claim:
- * it is not compared and it cannot disagree. A part writing neither agrees by
- * default, because the message's own commitment governs and this only ever
- * names a SECOND claim that contradicts it.
- *
- * ONE reading has to satisfy EVERY claim present, rather than each claim
- * finding its own. Grading them separately would let a `content_hash` that
- * agrees under the base64 decoding sit beside a `content_length` that agrees
- * under the raw text, a pair no blob in the world satisfies, and call it clean.
+ * Whether the `content_hash` and `content_length` beside an inline part agree
+ * with its content. An absent or malformed claim is not compared. One reading
+ * must satisfy every claim present: a hash agreeing under base64 beside a
+ * length agreeing under raw text describes no real blob.
  */
 async function inlineClaimsAgree(part: Record<string, unknown>): Promise<boolean> {
   const wanted = isHex64(part.content_hash)
@@ -524,23 +280,16 @@ async function inlineClaimsAgree(part: Record<string, unknown>): Promise<boolean
 }
 
 /**
- * Whether this part is one this rule CHECKS against bytes travelling BESIDE the
- * message: a conformant descriptor part. Exactly the three conditions section
- * 4.1 states, in the order that keeps inline content out. An INLINE part is
- * accepted and committed by the message itself (proof#157), so there is nothing
- * here for supplied bytes to be checked against and this answers `false`.
+ * Whether bytes beside the message are checked against this part: true only
+ * for a conformant descriptor part, never for an inline one.
  */
 export function isFilePart(part: unknown): boolean {
   return classify(part) === null;
 }
 
 /**
- * The parts of a message, or none at all.
- *
- * A message that carries no `parts` array carries no file parts, and that is
- * not a deviation: it is the common case, a JSON-only message. Every supplied
- * byte string then has no part to belong to and is refused, which is the
- * reading section 4.1 asks for and not an exception.
+ * The message's `parts`, or none. A message without parts is the common
+ * JSON-only case; every supplied entry is then refused.
  */
 function messageParts(message: unknown): unknown[] {
   if (!isPlainObject(message)) return [];
@@ -548,14 +297,7 @@ function messageParts(message: unknown): unknown[] {
   return Array.isArray(parts) ? [...parts] : [];
 }
 
-/**
- * The message-level named results, before any part is read.
- *
- * One condition reaches this today: a `parts` that is present, is not null and
- * is not an array. It gets a name rather than the silence it had (proof#156
- * gate), because a message with part-shaped content and no parts is exactly the
- * shape section 4.1's "one result per part" leaves nothing to say about.
- */
+/** Message-level results, before any part is read. */
 function messageResults(message: unknown): string[] {
   if (!isPlainObject(message)) return [];
   if (!hasOwn(message, "parts")) return [];
@@ -579,28 +321,14 @@ function asAscii(data: Uint8Array): string {
 }
 
 /**
- * Strict ASCII hex. Written out rather than delegated, because Python's
- * `bytes.fromhex` skips ASCII whitespace and a charset test does not: a decoder
- * the two kernels disagree about would put a record on one side of
- * `part_encoding_mismatch` in one language and the other side of it in the
- * other.
- *
- * EVERY GUARD HERE AND IN `base64Decode` IS PINNED BY A CORPUS VECTOR CARRYING
- * A HAND-WRITTEN EXPECTATION (proof#156 second gate, F3), named in the comment
- * beside it. Until that round, six of the seven produced no signal when
- * deleted: the whole ladder and the whole leg stayed green, so a third kernel
- * that delegated to `atob` or `base64.b64decode` reproduced the entire corpus
- * byte for byte, was conformant under `architecture.md` K3, and still put a
- * record on the other side of `part_encoding_mismatch`. An agreement case
- * cannot close that: the leg grades two kernels against each other, so a guard
- * deleted from both is invisible to it. Only a hand-written `expected` block
- * states which side of the boundary an input falls on.
+ * Strict ASCII hex, written out because library decoders differ (Python's
+ * `bytes.fromhex` skips whitespace), and a difference would move a record
+ * across `part_encoding_mismatch`. Each guard here and in `base64Decode` is
+ * pinned by a hand-written vector, named beside it, so deleting it goes red.
  */
 function hexDecode(data: Uint8Array): Uint8Array | null {
-  // An odd number of characters is not hex. Deleting this line lets `"ab0"`
-  // read as `0xab 0x00`, so a receiver handed a truncated hex string writes
-  // `part_encoding_mismatch` where it owes `part_mismatched` and a
-  // substitution: `parts-decoder-hex-odd-length-01`.
+  // Odd length is not hex; otherwise "ab0" reads as 0xab 0x00
+  // (`parts-decoder-hex-odd-length-01`).
   if (data.length === 0 || data.length % 2 !== 0) return null;
   const text = asAscii(data);
   if (!HEX_CHARSET.test(text)) return null;
@@ -612,33 +340,13 @@ function hexDecode(data: Uint8Array): Uint8Array | null {
 }
 
 /**
- * Strict base64, standard OR URL-safe, padded or not, canonical only.
- *
- * Written out for the same reason as `hexDecode`: Python's `base64.b64decode`
- * and JavaScript's `atob` disagree about padding, about the URL-safe alphabet
- * and about non-zero trailing bits, and each of those disagreements decides
- * whether a receiver refuses its own decoding defect or records a tamper
- * against an honest sender. The two alphabets are not mixed: a string carrying
- * one character from each is neither spelling and decodes to nothing.
- *
- * TWO GUARDS THAT STOOD HERE WERE DELETED IN THE PROOF#156 SECOND GATE'S
- * ROUND, because they could not change a decode for any input and so read as
- * protection that was not there:
- *
- *   * `pad > 0 && text.length % 4 !== 0` is the SAME PREDICATE as the
- *     `(body.length + pad) % 4` test below it. The strip loop above makes
- *     `text` exactly `body + "=".repeat(pad)`, so the two lengths are equal by
- *     construction and the two conditions are one condition written twice.
- *     Each masked the other, which is why deleting either alone changed
- *     nothing;
- *   * `body.includes("=")` is subsumed by the alphabet test three lines below
- *     it: `=` is in neither alphabet, so a body carrying one is refused there.
+ * Strict base64, standard or URL-safe (never mixed), padded or not, canonical
+ * only. Written out because `atob` and Python's `base64.b64decode` disagree on
+ * padding, the URL-safe alphabet and non-zero trailing bits.
  *
- * Checked exhaustively over every byte string of length 0 to 2 across all 256
- * byte values, exhaustively over lengths 3 to 6 on the 16-character alphabet
- * that reaches these branches, and over 500,000 random byte strings: zero
- * decodes move.
- * The remaining guards each carry the vector that pins them.
+ * There is no separate `pad > 0 && text.length % 4 !== 0` or
+ * `body.includes("=")` guard: the first is the alignment test below, and `=`
+ * fails the alphabet test.
  */
 function base64Decode(data: Uint8Array): Uint8Array | null {
   if (data.length === 0) return null;
@@ -649,32 +357,19 @@ function base64Decode(data: Uint8Array): Uint8Array | null {
     body = body.slice(0, -1);
     pad += 1;
   }
-  // At most two padding characters. Deleting this line lets `"===="` and any
-  // aligned body followed by four `=` decode as though the padding were not
-  // there: `parts-decoder-base64-four-pad-chars-01`.
+  // At most two padding characters (`parts-decoder-base64-four-pad-chars-01`).
   if (pad > 2) return null;
 
   const standard = [...body].every((c) => BASE64_STANDARD.includes(c));
   const urlsafe = [...body].every((c) => BASE64_URLSAFE.includes(c));
-  // One alphabet or the other, never a merge of the two. `"-/AA"` is neither
-  // spelling, and deleting this line does not merge the alphabets: it picks
-  // the URL-safe one and asks it for `/`, where `indexOf` answers -1 and
-  // garbles the arithmetic into `f7 f0 00`. TWO vectors pin that, one per
-  // shape of third kernel: `parts-decoder-base64-mixed-alphabet-01` commits
-  // the bytes a kernel that MERGES the alphabets reads, and
-  // `parts-decoder-base64-mixed-alphabet-02` commits the bytes this kernel's
-  // own -1 produces, which is the one that goes red HERE (proof#156 third
-  // gate, C2: deleting this line left all 2224 TypeScript tests green).
+  // One alphabet or the other, never both (`parts-decoder-base64-mixed-alphabet-01`
+  // and `-02`).
   if (!standard && !urlsafe) return null;
   const alphabet = standard ? BASE64_STANDARD : BASE64_URLSAFE;
-  // A lone trailing character carries six bits and no encoder emits one.
-  // Deleting this lets `"A"` read as the EMPTY blob, so any of the four
-  // characters whose low bits are zero could claim to be it:
-  // `parts-decoder-base64-single-character-01`.
+  // A lone trailing character carries six bits; otherwise "A" reads as the
+  // empty blob (`parts-decoder-base64-single-character-01`).
   if (body.length % 4 === 1) return null;
-  // Padding that does not align the string. Deleting this lets a 36-character
-  // body followed by one `=` decode as though the `=` were not there:
-  // `parts-decoder-base64-padding-misaligned-01`.
+  // Padding must align the string (`parts-decoder-base64-padding-misaligned-01`).
   if (pad > 0 && (body.length + pad) % 4 !== 0) return null;
 
   let bits = 0;
@@ -689,23 +384,15 @@ function base64Decode(data: Uint8Array): Uint8Array | null {
       bits = bits % 2 ** width;
     }
   }
-  // Canonical only: the unused low bits of the last character are zero in every
-  // encoder's output, and accepting them non-zero would let two spellings of one
-  // blob decode to one value. Both `atob` and `base64.b64decode` accept them,
-  // which is the sharpest reason this decoder is written out: deleting this
-  // line lets `"QR=="` read as `"A"`, so a receiver handed one of the sixteen
-  // non-canonical spellings of a one-byte part writes `part_encoding_mismatch`
-  // where it owes `part_mismatched` and a substitution:
-  // `parts-decoder-non-canonical-tail-01`.
+  // Canonical only: non-zero unused low bits would let two spellings decode to
+  // one blob, and `atob` accepts them (`parts-decoder-non-canonical-tail-01`).
   if (width > 0 && bits !== 0) return null;
   return new Uint8Array(out);
 }
 
 /**
- * The inverse of `base64Decode`, written out for the same reason: `btoa` and
- * Python's `base64` module differ in what they accept and in how they pad, and
- * this value is compared against a digest a sender committed, so the two
- * kernels have to emit the same characters.
+ * The inverse of `base64Decode`, written out so every implementation emits the
+ * same characters.
  */
 function base64Encode(data: Uint8Array, alphabet: string, pad: boolean): Uint8Array {
   let out = "";
@@ -734,27 +421,10 @@ function asciiBytes(text: string): Uint8Array {
 }
 
 /**
- * Every spelling of `data` an honest stack might have been handed.
- *
- * The ENCODING direction of the encoding guard. A receiver whose stack decoded
- * what it was given holds the decoded bytes while the sender committed the
- * encoded text, which is what a single-line DER attachment, a PEM body and a
- * JWT each are: the part's bytes ARE the base64 text. Guarding only the
- * decoding direction told that receiver it held a tamper and fired the
- * substitution, which is the one outcome this module calls worse than recording
- * nothing.
- *
- * The list is fixed and short, the same six spellings the decoder accepts, so
- * the two kernels try the same candidates in the same order and the cost is
- * linear in the length of the supply.
- *
- * A `data.length === 0` guard stood here and was deleted in the proof#156
- * second gate's round, for the same reason as the two in `base64Decode`: it
- * could not change an answer. This is reached only from `respellingExplains`,
- * and only after `sha256(data)` has already been compared to `contentHash` and
- * missed. Every spelling of the empty byte string is the empty byte string, so
- * the one candidate it would have produced is the digest that just failed. An
- * optimization written as a guard reads as protection that is not there.
+ * Every spelling of `data` an honest stack might have been handed: the
+ * encoding direction of the encoding guard. A receiver whose stack decoded a
+ * PEM, DER or JWT holds decoded bytes while the sender committed the text.
+ * No empty-input guard: an empty `data` already missed the digest.
  */
 function respellings(data: Uint8Array): Uint8Array[] {
   return [
@@ -768,10 +438,8 @@ function respellings(data: Uint8Array): Uint8Array[] {
 }
 
 /**
- * Whether a base64 or hex respelling of `data`, in EITHER direction, hashes to
- * `contentHash`. `contentHash` arrives lowercased: the charset is pinned and
- * the case is not (proof#135), so every comparison in this module is made on
- * one spelling.
+ * Whether a base64 or hex respelling of `data`, in either direction, hashes to
+ * `contentHash` (lowercase).
  */
 async function respellingExplains(data: Uint8Array, contentHash: string): Promise<boolean> {
   for (const decoded of [base64Decode(data), hexDecode(data)]) {
@@ -786,22 +454,11 @@ async function respellingExplains(data: Uint8Array, contentHash: string): Promis
 /**
  * What a receiver commits to, given the message and the bytes it holds.
  *
- * `supplied` is the bytes the receiver actually holds, each named by the index
- * of the part it belongs to. An empty list is the common case, a receiver that
- * holds no part's bytes, and it reads exactly as section 4.1 read before this
- * amendment: every file part is `PART_UNCHECKED` and the message a receiver
- * commits to is the message it was given.
- *
- * Where a part's bytes hash to something other than its `content_hash`, or
- * where their count is not its `content_length`, the returned `heldMessage`
- * carries that part's `content_hash` and `content_length` replaced by the held
- * bytes' own. The receiver commits `event.message_hash` over THAT, so its
- * record and the sender's disagree and the pair fails on `message_hash`.
- *
- * A refusal is scoped to the supplied entry it is about: the part it names is
- * not checked and not substituted, every other part reads as it would have, and
- * `heldMessage` is returned either way. Nothing a caller or a sender can do
- * denies the receiver a record.
+ * `supplied` names each byte string by its part index. With none, every file
+ * part is `PART_UNCHECKED` and the held message is the message given. Where a
+ * part's bytes miss its hash or length, `heldMessage` carries the held bytes'
+ * own values for that part, so the pair fails on `message_hash`. A refusal is
+ * scoped to its entry; `heldMessage` is always returned.
  */
 export async function commitHeldMessage(
   message: unknown,
@@ -809,7 +466,6 @@ export async function commitHeldMessage(
 ): Promise<HeldMessage> {
   const parts = messageParts(message);
   const classifications = parts.map(classify);
-  // The inline hash agreement, refined out of the shape pass because it hashes.
   for (let i = 0; i < parts.length; i++) {
     if (classifications[i] !== PART_INLINE_BYTES) continue;
     if (!(await inlineClaimsAgree(parts[i] as Record<string, unknown>))) {
@@ -824,15 +480,13 @@ export async function commitHeldMessage(
   supplied.forEach((item, entry) => {
     const index = item.part;
     if (!isSafeIndex(index) || (index as number) >= parts.length) {
-      // No part of this message: the only genuinely message-level refusal, and
-      // it still names itself rather than going quiet.
+      // No part of this message.
       refusals.push({ name: BYTES_FOR_UNKNOWN_PART, part: null, entry });
       return;
     }
     if (classifications[index as number] !== null) {
-      // A part that EXISTS and cannot be checked. Scoped to that part, so a
-      // sender cannot buy silence by emitting one uncheckable part beside the
-      // part it altered.
+      // A part that exists but cannot be checked. Scoped to that part, so one
+      // uncheckable part cannot hide an altered one.
       refusals.push({ name: BYTES_FOR_UNKNOWN_PART, part: index as number, entry });
       return;
     }
@@ -874,10 +528,7 @@ export async function commitHeldMessage(
     const contentLength = part.content_length as number;
     const digest = await sha256Hex(first.data);
     if (digest === contentHash) {
-      // The LENGTH is compared too, and a disagreement substitutes exactly as a
-      // hash disagreement does (proof#156 gate). Before that, a part whose
-      // stated length the receiver could see was false read `part_matched`, so
-      // the receiver certified the part and committed the false length with it.
+      // A matching hash with a false length still substitutes.
       if (first.data.length === contentLength) {
         readings.push({ index, result: PART_MATCHED });
         continue;
@@ -915,9 +566,7 @@ export async function commitHeldMessage(
 
   let held: unknown = message;
   if (replacements.size > 0) {
-    // Rebuilt rather than mutated in place: the message a caller handed in is
-    // the caller's, and a reading that edits its input is a reading that
-    // changes what the caller commits to on the honest path too.
+    // Rebuilt, not mutated: the caller's message is the caller's.
     const heldParts = parts.map((part, index) => {
       const replacement = replacements.get(index);
       if (replacement === undefined) return part;
@@ -944,55 +593,14 @@ export async function commitHeldMessage(
 }
 
 /**
- * The parts the receiver HELD bytes for and did NOT check.
- *
- * The gap between "nothing was substituted" and "every part is clean", named
- * so a caller does not have to re-derive it from the refusal list (proof#156
- * second gate, F5). A part is in here where a refusal NAMES it and its reading
- * is one of `HELD_UNCHECKED_RESULTS`: the receiver had bytes for that part,
- * the rule declined to grade them, and NOTHING about that reaches the
- * committed record.
- *
- * THE RULE, in one sentence, because a filter is not a rule. A part is in here
- * where the receiver held bytes for it AND the message itself does not commit
- * its content. `PART_UNCHECKED` is a refused supply;
- * `PART_MALFORMED_DESCRIPTOR` is a part whose content travels BESIDE the
- * message under a claim no receiver can use, so the receiver's bytes are
- * exactly as ungraded and the record says as little. The first cut of this
- * function omitted the second, which the third gate measured: a `kind: "file"`
- * part with a non-conformant `content_hash` or `content_length`, bytes held,
- * read `[]` here, so a caller following the rule this module prescribes wrote
- * `accepted` over a part it held bytes for and never checked. That is the
- * class the mechanism exists to close, and Phil named it in proof#162's
- * ratification as the gap that decision inherits unless it is closed here.
- *
- * Three results are excluded ON PURPOSE. An inline part (`PART_INLINE_BYTES`,
- * `PART_INLINE_MISMATCHED`) and a non-file part (`PART_NOT_A_FILE`) carry
- * their content INSIDE the message, and `message_hash` commits it on both
- * sides: bytes supplied beside one of those grade nothing and hide nothing,
- * because a reader of either pack reads the content itself. Naming them would
- * fire the caller's obligation on parts the swapped-bytes attack cannot reach
- * at all.
+ * The parts the receiver held bytes for and did not check: a refusal names the
+ * part and its result is in `HELD_UNCHECKED_RESULTS`, or the part is a URL part
+ * that reads `PART_NOT_A_FILE` and the refusal is `BYTES_FOR_UNKNOWN_PART`. A
+ * caller writes `accepted` only when this and `substituted` are both empty, and
+ * records the positions and their count when it is not zero.
  *
- * Why it is worth a function rather than a note. Delivering a tampered copy of
- * a part alone is `part_mismatched`, is substituted, and fails the pair on
- * `message_hash`. Delivering the tampered copy AND the true one is
- * `conflicting_part_bytes`, is never substituted, and the pair VERIFIES, so
- * adding data suppresses detection and the only trace is a refusal the
- * receiving side publishes at its own discretion.
- *
- * NOT the same as "this part reads `PART_UNCHECKED`". A receiver that holds no
- * bytes at all reads every file part that way, and that is the COMMON CASE,
- * unchanged by A18 and not a reason to withhold `accepted`. Only a part whose
- * bytes the receiver actually held and could not grade is in here.
- *
- * What this does NOT do: it cannot stop a caller writing `accepted` anyway.
- * This module reads and does not write the record. proof#162 ratified what the
- * record layer does instead (Phil, 2026-09-22): `accepted` keeps its meaning
- * and the COUNT of these parts rides in an additive `context` key, REQUIRED
- * when it is not zero, enforced against SDKs through conformance vectors. So a
- * part missing from this list is a part no record built on that rule will ever
- * mention.
+ * Not the same as "reads `PART_UNCHECKED`": a receiver holding no bytes reads
+ * every file part that way, which is the common case.
  */
 export function uncheckedHeldParts(reading: HeldMessage): number[] {
   const unchecked = new Set(
@@ -1000,9 +608,23 @@ export function uncheckedHeldParts(reading: HeldMessage): number[] {
       .filter((p) => HELD_UNCHECKED_RESULTS.includes(p.result))
       .map((p) => p.index),
   );
+  const held = reading.heldMessage;
+  const parts = isPlainObject(held) && Array.isArray(held.parts) ? held.parts : [];
+  const urlParts = new Set(
+    reading.parts
+      .filter((p) => p.result === PART_NOT_A_FILE && p.index < parts.length && isUrlPart(parts[p.index]))
+      .map((p) => p.index),
+  );
   const named = new Set<number>();
   for (const refusal of reading.refusals) {
-    if (refusal.part !== null && unchecked.has(refusal.part)) named.add(refusal.part);
+    if (refusal.part === null) continue;
+    if (unchecked.has(refusal.part)) named.add(refusal.part);
+    if (urlParts.has(refusal.part) && refusal.name === BYTES_FOR_UNKNOWN_PART) named.add(refusal.part);
   }
   return [...named].sort((a, b) => a - b);
 }
+
+/** A part with no `kind: "file"` whose `url` member is present and not `null`. */
+function isUrlPart(part: unknown): boolean {
+  return isPlainObject(part) && part.kind !== "file" && hasOwn(part, "url") && part.url !== null;
+}