@cosyte/astm 0.0.15 → 0.0.17

package/CHANGELOG.md

@@ -9,8 +9,226 @@ this file is maintained by hand (Changesets handles the version bump and publish
 
 ## [Unreleased]
 
+### Added
+
+- **Two parse-path warning codes for two readings the parser could not defend, both landing on the
+  profile safety gate** (`ASTM-FRAME-RESIDUALS`, defects 4 and 11). Both are additive: no existing
+  warning was removed or renamed, no split changed, and every extracted value is byte-identical to
+  what it was. What changed is that each condition is now reported by a code **no profile may
+  tolerate**, so `{ strict: true }` refuses a stream carrying it whatever profile is in force.
+  - `ASTM_RECORD_DELIMITER_ROLE_COLLISION`: an `H` record declared one character in two of the
+    repeat, component and escape roles, so the boundary between those two roles is not in the bytes.
+    A declaration whose **field** separator is one of the other three was already refused (the
+    `ASTM_RECORD_UNDECLARED_DELIMITERS` fatal on the first header, `ASTM_RECORD_UNREADABLE_REDECLARATION`
+    on a later one), so this covers the three unordered pairs among the rest: repeat/component,
+    repeat/escape, component/escape. The declaration is still honored and no record is dropped.
+    Measured: under `H|^^&` the field `A^B^C^D` reads back as four repeats of one component each, so
+    a two-repeats-of-two-components reading is unrecoverable; under `H|\&&` the same character
+    splits (`A&B` is two components) or opens an atom (`A&F&B` is the single component `A|B`)
+    depending only on what follows it. Emit has always refused these sets
+    (`ASTM_EMIT_INVALID_DELIMITERS`), which is how the gap became visible from the outside.
+  - `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`: an escape sequence whose body was **not** a
+    recognized mnemonic held a character that is one of the three splitting delimiters in force, so
+    the atom rule kept it out of the split and the record was read with one fewer division than its
+    bytes carry. Measured on the canonical set: `R|1|^^^687|28.6&|&U/L||||F` reads a value of
+    `28.6&|&U/L`, with **no units** and status `unspecified` rather than `final`. It fires alongside
+    `ASTM_UNKNOWN_ESCAPE_SEQUENCE`, which stays and stays tolerable, because it remains true and
+    benign of every unrecognized body that is not a delimiter in force.
+
+  **The measure that discriminates is strict-accepted-under-a-gate-legal-profile, and "silent" was
+  never available here.** Both conditions always raised a tolerable code already
+  (`ASTM_NONSTANDARD_DELIMITERS` for the first, since any colliding set is by definition
+  non-canonical; `ASTM_UNKNOWN_ESCAPE_SEQUENCE` for the second), so `warnings: []` was structurally
+  unreachable for either class and "it is never silent" was true and told you nothing. What it hid is
+  that a profile tolerating the weaker code left a strict parse accepting the reading.
+
+  Measured against the corpus constants committed with the tests, not against a sweep whose
+  parameters are not in the tree. Over `DELIMITER_ALPHABET` and `sweepStream` in
+  `test/records/delimiter-role-collision.test.ts` (the twelve characters `|` `\` `^` `&` `~` `:` `#`
+  `*` `!` `@` `$` `%`, a header plus a terminator), 15,972 of the 20,736 four-role tuples resolve;
+  4,092 of those name one character in two roles and 11,880 do not. Under a gate-legal profile
+  tolerating `ASTM_NONSTANDARD_DELIMITERS` and `{ strict: true }`, **4,092 of the 4,092 were accepted
+  before and 0 are now**, while all 11,880 non-colliding sets are accepted exactly as before. Over
+  `BODY_ALPHABET` and `bodyStream` in `test/records/swallowed-delimiter.test.ts` (the same twelve
+  characters as escape bodies in one spec-clean result record, read identically in all twelve cases),
+  **3 report the new code, enumerated as `|`, `\` and `^`**, the field, repeat and component roles of
+  the canonical set; the escape role `&` is deliberately not among them, because nothing splits on
+  it, and the other eight are not delimiters at all. Under `referenceCorpus` and `{ strict: true }`,
+  12 of 12 were accepted before and 9 are now.
+
+  **Two things these codes do not do, stated so they are not read into them.** Neither repairs a
+  reading: the atom rule is unchanged, because it is what keeps `&F&` one token under a set that
+  names `F` as a delimiter, and a colliding declaration is still honored rather than refused. And the
+  second does not survive a re-emit: the serializer rewrites the preserved sequence into recognized
+  mnemonics, and that stream says the same value unambiguously, so a second-generation read is silent
+  and is correct about its own bytes. The first read of the wire bytes is where the condition exists
+  to be caught, and that is where the refusal lands.
+
+  This is a **narrowing on a published package**, on the strict path only: a lenient parse of the
+  same stream returns the same records with one more warning on them. New public surface:
+  `hasCollidingRoles`, the `delimiterRoleCollision` and `delimiterSwallowedByEscape` warning
+  factories, the `SwallowedDelimiterSink` type, and a trailing optional sink parameter on
+  `decodeEscapes`, `tokenizeRecord` and `tokenizeHeader`.
+
+- **A third parse-path warning code, for a boundary the reading may have GAINED**
+  (`ASTM-FRAME-RESIDUALS`, defect 15, the mirror of defect 11). `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`
+  fires where the escape character that **closed** an unrecognized escape sequence could instead have
+  **opened** one whose body is the delimiter that split, so the same bytes carry two alignments that
+  disagree by exactly one field, repeat or component boundary. Measured on the canonical set:
+  `R|1|^^^687|28.6&Z&|&U/L||||F` reads a value of `28.6&Z&` and units of `&U/L` under the leftmost
+  alignment, and reads as one unsplit field carrying both under the other. It is not tolerable, so
+  `{ strict: true }` refuses such a record whatever profile is in force.
+
+  **The direction is why it needed a code rather than being left to its sibling.** That one reports a
+  boundary the reading lost; this one reports a boundary the reading may have gained, which is the
+  more dangerous half, because a gained boundary hands a consumer a value and a units string the
+  sender's bytes do not unambiguously carry. Both codes the condition raised before
+  (`ASTM_UNKNOWN_ESCAPE_SEQUENCE` and `ASTM_UNPAIRED_ESCAPE_CHARACTER`) are on the profile
+  allow-list, so a gate-legal profile naming them left a strict parse accepting the altered reading.
+  Both stay on the list and stay true of the cases that cost nothing.
+
+  **Additive, and the split is unchanged.** The leftmost alignment is still the one taken and every
+  decoded byte is identical. Picking the other alignment was considered and rejected: it is a
+  different guess with no more evidence behind it, and it would move values on a package that is
+  already published. Two exclusions are deliberate, and the first is **wider than the argument for
+  it**, which is stated rather than left to be found. A **recognized** mnemonic before the delimiter
+  raises nothing, because the reading taken interprets a construct (`&F&` is the sender escaping a
+  field separator, which is what the mechanism is for) while the competitor's body is a delimiter
+  character this codec usually cannot interpret, so its own vocabulary prefers the reading taken.
+  That is not the same as the reading taken being conformant, and two cases fall in the gap, both
+  measured and both left open as their own defect rather than closed by widening the test:
+  `28.6&F&|&U/L` reads a value of `28.6|` and units of `&U/L` under a bare escape character that this
+  package reports only as the tolerable `ASTM_UNPAIRED_ESCAPE_CHARACTER`, and a declared set naming a
+  mnemonic letter as a splitting delimiter leaves both alignments interpreting exactly one construct
+  with neither preferred. The criterion that would cover them is a different one (counting what each
+  alignment interprets), and swapping criteria moves which streams a published package refuses. The
+  second exclusion is a delimiter with no escape character two positions past it, which raises
+  nothing because there is no competing alignment. What does fire is a subset of the records that
+  already raise `ASTM_UNKNOWN_ESCAPE_SEQUENCE`.
+
+  **Measured against the corpus constants committed with the test**, on the same
+  strict-accepted-under-a-gate-legal-profile tier, because "silent" is structurally unreachable here
+  too. Over `ALIGNMENT_ALPHABET` and `neutralStream` in
+  `test/records/escape-alignment-ambiguity.test.ts` (twelve characters: the four mnemonics `F` `S`
+  `R` `E`, the three splitting roles `|` `\` `^`, the escape role `&`, and `~` `:` `#` `*`, swept in
+  both positions of the pair that decides this, carried on a comment record so no result-semantics
+  warning masks the count), of 144 tuples **24 raise the new code**, being the eight unrecognized
+  bodies against the three splitting roles. Under a profile built from the whole tolerable
+  allow-list, which is the widest a gate-legal profile can be, and `{ strict: true }`, **108 of 144
+  were accepted before and 93 are now**. The fire count and the acceptance delta are **not the same
+  number**: of the 24 that fire, 9 were already refused by
+  `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`, so 15 is what moved.
+
+  **It does not repair the reading and it does not survive a re-emit**, the same residue its sibling
+  disclosed: the serializer rewrites the preserved characters into recognized mnemonics, and that
+  stream carries the alignment that was taken with no competitor left in it, so a second-generation
+  read is silent and is correct about its own bytes. The first read of the wire bytes is where the
+  ambiguity exists to be caught.
+
+  This is a **narrowing on a published package**, on the strict path only: a lenient parse of the
+  same stream returns the same records with one more warning on them. New public surface:
+  `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`, the `ambiguousEscapeAlignment` warning factory, the
+  `AmbiguousAlignmentSink` type, and a trailing optional sink parameter on `splitEscapeAware`,
+  `tokenizeRecord` and `tokenizeHeader`.
+
+- **A fourth parse-path warning code, for the first of these that moves a MODELED CLINICAL SLOT
+  rather than a boundary** (`ASTM-FRAME-RESIDUALS`, defect 17(a)).
+  `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS` fires where two escape alignments disagree about a **field**
+  boundary, the reading taken keeps it, and the escape character that reading resumes on heads **no
+  escape sequence at all**, which is exactly the character the competing alignment uses to close its
+  own sequence. A gained field boundary shifts every later field one place. It is not tolerable, so
+  `{ strict: true }` refuses such a record whatever profile is in force.
+
+  **What the shift costs, measured on the canonical set.** `R|1|^^^687|28.6&F&|&U/L||||F` reads
+  **nine** fields under the alignment taken and **eight** under the other, so the sender's trailing
+  `F` lands in field 9, the result status, under the first and in **no field at all** under the
+  second. The parse hands back units of `&U/L` and a status of **`final`**, and both are consequences
+  of the alignment rather than values the sender placed in those slots. A downstream system reading
+  `final` acts on a result these bytes do not say was finalised. The only warning on that stream
+  before this code was the tolerable `ASTM_UNPAIRED_ESCAPE_CHARACTER`, so the widest gate-legal
+  profile plus `{ strict: true }` accepted it. **The predecessor entry above lists that `final` among
+  the values read without saying it is fabricated; this is that correction.**
+
+  **It is a second question about the same position, not a widening of the code above.** That one
+  asks whether this codec's own vocabulary prefers the alignment taken _at_ the contested position,
+  and is silent where the earlier body is a recognized mnemonic. This one asks what the alignment
+  taken makes of the bytes _after_ the boundary, and does not consult the earlier body at all. The
+  earlier code's exclusions are untouched, and the two fire alongside each other where both apply.
+
+  **Additive, and the split is unchanged.** Every decoded byte is identical, including the status,
+  which is still read as `final`: this reports the shift, it does not repair it. Picking the other
+  alignment was rejected for the same reason as before, and withholding the shifted slots was
+  weighed and deferred, because declining to model a slot changes an extracted value on a published
+  package and wants its own measurement of the population it moves.
+
+  **Two bounds, both deliberate, and neither is a claim that nothing was lost outside it.** It is
+  wired to the **field** separator only, because a gained repeat or component boundary divides one
+  field and so moves no **field-indexed** slot: the units and the status stay put. **That is a choice
+  and not a consequence, and stating it as a consequence would be false.** Components are modeled
+  _inside_ a field, so a gained **component** boundary does move a modeled slot:
+  `R|1|&F&^&GLU^L^687|28.6|U/L||||F` reads a Universal Test ID coding scheme of `L` and local code of
+  `687` under the alignment taken, and `687` as the **coding scheme** under the other, while
+  `DOE&F&^&JANE^A` reads `&JANE` as a first name under one and `A` under the other. Both raise only
+  the tolerable `ASTM_UNPAIRED_ESCAPE_CHARACTER` and are strict-accepted under the widest gate-legal
+  profile, and both are **`PRE-EXISTING`** (byte-identical on the base of this slice), so they are
+  disclosed here as a separate open condition rather than covered: wiring this sink to another
+  delimiter role is a different criterion and wants its own population measurement. On the repeat role
+  what is lost is the value, also not reported here. And the tail is weighed **one construct deep**: where
+  the escape character past the boundary heads a **recognized** sequence, the alignment taken
+  interprets it while the competing one would leave it bare, so the bytes prefer the alignment taken
+  (under a set naming the field separator `F`, `28.6&F&F&F&U/L` is that separator escaped, written and
+  escaped again, entirely well formed, and refusing it is the over-refusal that sank a criterion
+  measured for this same family); and where it heads an **unrecognized** sequence, the alignment taken
+  still consumes it while the competing one would leave two escape characters bare, so the preference
+  is stronger again. That second case still shifts the fields and is silent here. It is recorded as a
+  residue, measured, not overlooked.
+
+  **Measured against the corpus constants committed with the test**, on the same
+  strict-accepted-under-a-gate-legal-profile tier. Over `DECLARATION_ALPHABET`, `SPLITTING_ROLES`,
+  `BODY_ALPHABET` and `TAIL_SUFFIXES` in `test/records/alignment-shifted-fields.test.ts`, **864
+  tuples**: the code fires on **96**, moves **32** from accepted to refused under a profile built from
+  the whole tolerable allow-list, and moves **0** back. It fires on **none** of the 96 escape-clean
+  tuples, and cannot: firing requires an escape character heading no sequence, which this package
+  already reports as a deviation of its own. The criterion measured and rejected on this same corpus
+  would have refused 48 of them. The 32 that move are exactly the population the code above left
+  silent through its recognized-body exclusion.
+
+  **It does not survive a re-emit**, the same residue its siblings disclosed: the serializer rewrites
+  the preserved characters into recognized mnemonics, so a second-generation read is silent and is
+  correct about its own bytes. The first read of the wire bytes is where this exists to be caught, and
+  a clean re-read is not evidence.
+
+  This is a **narrowing on a published package**, on the strict path only: a lenient parse of the same
+  stream returns the same records, with the same values, and one more warning on them. New public
+  surface: `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, the `alignmentShiftedFields` warning factory, the
+  `ShiftedFieldsSink` type, and a trailing optional sink parameter on `splitEscapeAware`,
+  `tokenizeRecord` and `tokenizeHeader`.
+
 ### Fixed
 
+- **A header that is not short no longer reports that it is too short** (`ASTM-FRAME-RESIDUALS`,
+  defect 16). `readDelimiters` had four ways to fail and the first header's fatal described all of
+  them with one sentence. Three were accurate; the fourth was not. `H||^&` is a full-length header
+  whose delimiter-definition field is empty because its own field separator ends the definition where
+  it begins, and it raised `ASTM_RECORD_UNDECLARED_DELIMITERS` reading "Header record is too short to
+  declare the four delimiters", which sent a reader counting characters instead of looking at the
+  declaration. `readDelimiterDeclaration` is `readDelimiters` with the reason kept, and the fatal now
+  carries the message for the reason it hit.
+
+  **The fatal code is unchanged and no stream's disposition moved.** A consumer switching on
+  `ASTM_RECORD_UNDECLARED_DELIMITERS` sees exactly what it saw before; only the human-readable
+  sentence changed. Splitting the code in two was considered and rejected: it would move a published
+  code for a stream whose outcome is already right, which is a breaking change bought for a sentence.
+
+  The reader's field-separator-reused branch is **unreachable** and stays. Such a separator ends the
+  delimiter definition where it appears, so the under-three-characters rule answers first, every
+  time, and that is now measured rather than argued: over `FIELD_SEPARATOR_ALPHABET` and
+  `DEFINITION_POSITIONS` in `test/common/delimiter-declaration-faults.test.ts`, all 36 collision-shaped
+  headers classify as a truncated definition and none as a reuse. Deleting the branch would leave the
+  invariant unstated and a change to how the definition field is bounded silent. New public surface:
+  `readDelimiterDeclaration`, the `DelimiterDeclarationFault` type, and a `fault` on the failure arm
+  of the previously unused `DelimiterReadResult`.
+
 - **The escape encoder protected the escape character it introduced but not the `E`/`F`/`S`/`R`
   mnemonics, so a delimiter set naming one of those letters in another role altered the values it
   emitted** (`ASTM-FRAME-RESIDUALS` follow-up, defect 12). `PRE-EXISTING`, byte-identical on

package/README.md

@@ -177,15 +177,93 @@ package's serializer emits, so a stream it produced never trips the code. The co
 so a vendor profile can expect it on a feed that sends bare ampersands and still parse
 `{ strict: true }`.
 
-**One escape shape still costs a field boundary, and it is a different code.** A real three-character
-sequence is opaque by design, which is what keeps `&F&` one token under a set that names `F` as a
-delimiter. So where the body is itself a delimiter (`&|&` under the canonical set) that delimiter
-does not split, and every field after it shifts: `R|1|^^^687|28.6&|&U/L||||F` reads a value of
-`28.6&|&U/L` with no units and status `unspecified`. It is never silent, but the only report is
-`ASTM_UNKNOWN_ESCAPE_SEQUENCE`, which is **tolerable**, so a profile expecting that code (including
-the shipped `referenceCorpus`) will let a `{ strict: true }` parse accept it. Narrowing the atom to
-close this would break the guarantee the atom exists for, so it is written down rather than papered
-over.
+**One escape shape still costs a field boundary, and it has a code of its own.** A real
+three-character sequence is opaque by design, which is what keeps `&F&` one token under a set that
+names `F` as a delimiter. So where the body is an **unrecognized** character that is itself a
+delimiter in force (`&|&` under the canonical set)
+that delimiter does not split, and every field after it shifts: `R|1|^^^687|28.6&|&U/L||||F` reads a
+value of `28.6&|&U/L` with no units and status `unspecified`. That reading is unchanged, and
+narrowing the atom to change it would break the guarantee the atom exists for. What such a record now
+raises, alongside the tolerable `ASTM_UNKNOWN_ESCAPE_SEQUENCE`, is
+`ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`, which **no profile may tolerate**, so a
+`{ strict: true }` parse refuses it even under the shipped `referenceCorpus`. The narrower code fires
+only where the unrecognized body is one of the three splitting roles in force. Two exclusions are
+deliberate: the escape role, because nothing splits on it, and every **recognized** mnemonic, because
+`&F&` under a set naming `F` as the repeat delimiter is the sender escaping the field separator on
+purpose, and reporting that would report the escape mechanism working as a defect.
+
+Read it as a report, not a repair. It also does not survive a re-emit: the serializer rewrites the
+preserved sequence into recognized mnemonics, and that stream says the same value unambiguously, so a
+second-generation read is silent and is right about its own bytes. The first read of the wire bytes
+is where the condition exists to be caught.
+
+**The mirror of it costs a boundary in the other direction, and it also has a code of its own.**
+Sequences are matched greedily and leftmost, so the escape character that closes one cannot also open
+the next. Where it could have, the same bytes carry two alignments that disagree by one boundary:
+`R|1|^^^687|28.6&Z&|&U/L||||F` reads a value of `28.6&Z&` and units of `&U/L` under the alignment
+taken, and reads as a single unsplit field carrying both under the other. Every byte is preserved and
+the leftmost reading is kept (picking the other one would be a different guess with no more evidence
+behind it), but the boundary it hands you is a choice, so it raises
+`ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`, which **no profile may tolerate**. Both codes the condition
+raised before (`ASTM_UNKNOWN_ESCAPE_SEQUENCE` and `ASTM_UNPAIRED_ESCAPE_CHARACTER`) are tolerable, so
+a strict parse under a profile naming them used to accept it. Two exclusions again. A **recognized**
+mnemonic before the delimiter is silent, because the reading taken interprets a construct (`&F&` is
+the sender escaping a separator, which is what the mechanism is for) while the competitor's body is a
+delimiter character the codec usually cannot interpret, so its own vocabulary prefers the reading
+taken. That is **not** the same as the reading taken being conformant, and the exclusion is wider
+than that argument: `28.6&F&|&U/L` reads a value of `28.6|` and units of `&U/L` while raising only
+the tolerable `ASTM_UNPAIRED_ESCAPE_CHARACTER`, and a declared set naming a mnemonic letter as a
+splitting delimiter makes both alignments interpret one construct each with neither preferred. The
+first of those is covered by a second code, below; the second is measured and recorded as an open
+residue. The other exclusion is a delimiter with no escape character two positions past it, which is
+no competing alignment at all. What does fire is a subset of what already raises
+`ASTM_UNKNOWN_ESCAPE_SEQUENCE`. It does not survive a re-emit either, for the same reason as its
+mirror: catch it on the first read.
+
+**And where that gained boundary is a FIELD boundary, it moves a result's status, which is a
+different question and so a different code.** The two alignments resume one character apart, so they
+disagree about every byte after the boundary, not only about it. Where the escape character the
+reading taken resumes on heads no sequence at all, that reading bought the boundary with a byte it
+cannot read while the competing alignment is the one that can use it. On the field separator that
+matters clinically: `R|1|^^^687|28.6&F&|&U/L||||F` reads **nine** fields under the alignment taken
+and **eight** under the other, so the sender's trailing `F` lands in field 9, the result status,
+under the first and in no field at all under the second. The parse hands back units of `&U/L` and a
+status of **`final`**, and both are consequences of the alignment rather than values the sender put
+in those slots. That raises `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, which **no profile may
+tolerate**; before it existed the only warning on that stream was the tolerable
+`ASTM_UNPAIRED_ESCAPE_CHARACTER`, so a strict parse under a legal profile accepted it. The reading is
+unchanged: it reports the shift rather than repairing it. It is wired to the **field** separator
+only, because a gained repeat or component boundary divides one field and so moves no field-indexed
+slot. **That bound is a choice, not a consequence**: components are modeled inside a field, so a
+gained **component** boundary does move a modeled slot, and `R|1|&F&^&GLU^L^687|28.6|U/L||||F` reads
+`687` as a local code under one alignment and as the coding scheme under the other, with only a
+tolerable code raised. That is a separate open condition, not something this code covers. It is also
+silent where the trailing escape character heads a sequence of its own, recognized or not; that case
+still shifts the fields and is the recorded residue. It does not survive a re-emit either: catch it
+on the first read.
+
+### A header that names one character in two delimiter roles
+
+ASTM messages are self-describing: the `H` record declares the four delimiters and a conformant
+reader follows them. A declaration whose **field** separator is also one of the other three is
+refused outright, because the four roles would be indistinguishable. A declaration where two of the
+_remaining_ three agree is still read, because the stream is readable and refusing it would drop
+records the sender did send, but the boundary between those two roles is no longer in the bytes.
+
+Under `H|^^&`, where the repeat and component roles are both `^`, a field a canonical sender would
+have written as two repeats of two components reads back as four repeats of one component each.
+Under `H|\&&`, where the component and escape roles are both `&`, the same character splits
+(`A&B` is two components) or opens an escape atom (`A&F&B` is the single component `A|B`) depending
+only on what follows it.
+
+Such a header now raises `ASTM_RECORD_DELIMITER_ROLE_COLLISION`, at the header that put the set into
+force, once rather than once per colliding pair. A later header restating the set already in force
+warns nothing, on the same rule that governs the other delimiter warnings. The code is **not** tolerable. That matters
+because every such set is by definition non-canonical, so the only warning it used to raise was
+`ASTM_NONSTANDARD_DELIMITERS`, which is tolerable: a profile expecting an ordinary vendor set left a
+`{ strict: true }` parse accepting a declaration whose own field tree cannot be recovered. Emit has
+always refused these sets (`ASTM_EMIT_INVALID_DELIMITERS`), which is how the gap first showed: a
+message that parsed clean threw when it was serialized back against its own declared delimiters.
 
 ### Several messages in one stream
 
@@ -251,9 +329,17 @@ outside it:
   and the damage then varies. A mis-split component can cost a test identity while the value and
   units survive. The escape role's worst case has **narrowed, not gone**: a bare escape character no
   longer merges the rest of the record (it reads as a literal and raises
-  `ASTM_UNPAIRED_ESCAPE_CHARACTER`), but an `&X&` sequence whose body is a delimiter is an opaque
+  `ASTM_UNPAIRED_ESCAPE_CHARACTER`), but an `&X&` sequence whose body is an unrecognized character
+  that is itself a delimiter in force is an opaque
   atom, so that delimiter does not split and the value, the units and the status can still go
-  together. That one is reported only by the tolerable `ASTM_UNKNOWN_ESCAPE_SEQUENCE`.
+  together. That one raises `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`, which is not tolerable,
+  alongside the tolerable `ASTM_UNKNOWN_ESCAPE_SEQUENCE`. The split itself is unchanged. Its mirror,
+  where the leftmost alignment lets a delimiter split that a competing alignment would have held,
+  gains a boundary instead of losing one and raises `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`, also
+  not tolerable. Where that gained boundary is a **field** boundary and the reading taken resumes on
+  an escape character heading no sequence, every later field shifts one place and a result's units
+  and status are read out of slots the other alignment does not put them in: that raises
+  `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, not tolerable either.
 
 All are accepted limits, for two different reasons: widening the field-separator check would mean
 deciding which set a record ought to have had, which is the same guess the parser declines to make