@cosyte/astm 0.0.18 → 0.0.20

package/CHANGELOG.md

@@ -11,6 +11,49 @@ this file is maintained by hand (Changesets handles the version bump and publish
 
 ### Added
 
+- **The PHI commit-gate now reads a stream written as a source string literal, and refuses a sweep
+  that did not observe its corpus.** Two separate holes, closed together because closing one alone
+  buys only the cross-cutting SSN/email floor.
+  - **Scan roots.** The all-mode walk covers `src`, `test` and `scripts`, where it previously
+    covered `src` and `test/fixtures` only. Measured against `git ls-files` on the commit before
+    this change: 106 of 165 tracked files were scanned by neither enumerating route, 66 of them
+    under `test/`, and 33 of those 66 contain a patient-record literal. Those fixtures were read by
+    hand before.
+  - **A source-embedded view.** The record-aware detector splits on newlines and asks whether a line
+    begins with the patient-record type letter. Most of this package's streams are string literals,
+    so every one of them arrived as a single line beginning with a quote and was never read,
+    including inside `src`, which the walk already covered. The detector now also runs over a view
+    with the source escape sequences decoded and the string-literal delimiters treated as record
+    boundaries, in addition to the raw bytes. Both are needed: an escape sequence supplies a
+    boundary only for a stream written whole in one literal, and this package also writes a single
+    record per literal and a stream as array elements joined at run time. The decode is one
+    left-to-right pass that consumes an escaped backslash as a pair; it runs only on a closed set of
+    source file extensions, so it cannot invent a record boundary in wire data whose backslash is
+    the repeat delimiter; and delimiters are read from the line view only, so a quoted fragment of
+    prose cannot redefine the delimiter set for a whole file.
+  - **An observation rule.** A sweep refuses (exit 2) when a declared root observed no files, when
+    the invocation as a whole observed none, and when git tracks in-scope files under a root that
+    the walk did not observe. A missing root, an emptied root, a dangling symbolic link as a root,
+    and a root that is a regular file are all covered; the last previously raised an uncaught
+    `ENOTDIR`, which exits 1, the code that means hits were found.
+  - **Two precision guards, each with its bound stated where it is applied.** A line that merely
+    starts with the patient-record type letter is not read as a patient record: its second field
+    must be a short digit run, which this package's own builder always writes there. And a name
+    component of one character is not read, so a bare middle initial does not have to be exempted
+    by name for the whole repository.
+  - What a green from the scan means is now written out in one place, `scanTarget`, with every
+    locus, record shape, token and file it does not cover named there. No other surface restates
+    it.
+  - The scanner resolves its repository from its own file location rather than from the working
+    directory, and every `git` subprocess it runs is pinned to that repository. Run from a parent
+    checkout it previously walked that tree and reported clean about this package having never
+    opened it.
+- **`pnpm check`, a gate-coverage check** (`scripts/check-gate-coverage.ts`). It asserts that every
+  command this repository's own workflows run is reachable as a `pnpm run` script or is declared
+  with the reason it is not, that every `run-<x>: true` input passed to a shared pipeline has the
+  script that pipeline will call, and that the two gates whose names carry no recognisable prefix
+  still exist. Every declared-unreachable entry is printed on every run.
+
 - **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
@@ -136,7 +179,8 @@ this file is maintained by hand (Changesets handles the version bump and publish
   `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
+  own sequence. (**That tail bound is widened later in this same release**, to any tail this reader
+  cannot interpret; the entry below carries the change and its measurement.) 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
@@ -180,16 +224,20 @@ this file is maintained by hand (Changesets handles the version bump and publish
   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.
+  was read as stronger again, and this shipped silent there while the fields shifted just the same.
+  **That residue is closed later in this same release** (see the tail-bound entry below), which
+  corrects the reason rather than the code: the preference comparison is true and is not the question
+  this code asks.
 
   **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
+  tuples**: as this code shipped it fired on **96**, moved **32** from accepted to refused under a
+  profile built from the whole tolerable allow-list, and moved **0** back. **The tail-bound widening
+  below takes those to 192 and 64 on the same corpus**, which is what the committed test asserts now.
+  It fires on **none** of the 96 escape-clean tuples, and cannot, before or after: firing requires an
+  escape character heading no sequence this reader can interpret, and this package already reports
+  each of those 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.
 
@@ -207,9 +255,9 @@ this file is maintained by hand (Changesets handles the version bump and publish
 - **A parse-path warning code for a field a competing escape alignment read short**
   (`ASTM-FRAME-RESIDUALS`, defect 17b). `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` fires where two
   escape alignments of the same bytes disagree about a **repeat** boundary, the reading taken keeps
-  it, and the escape character that reading resumes on heads **no sequence at all**. It lands on the
-  profile safety gate, so `{ strict: true }` refuses a stream carrying it whatever profile is in
-  force.
+  it, and the escape character that reading resumes on heads **no sequence at all**. (**That tail
+  bound is widened later in this same release**; see the entry below.) It lands on the profile safety
+  gate, so `{ strict: true }` refuses a stream carrying it whatever profile is in force.
 
   **Nothing shifts, and that is not the same as nothing being lost, which is the correction this
   entry carries.** No field-indexed slot moves: the units slot and the result-status slot are read
@@ -244,20 +292,23 @@ this file is maintained by hand (Changesets handles the version bump and publish
 
   **Two further bounds, both deliberate.** It is wired to the **repeat** separator only: a gained
   **component** boundary reaches a modeled slot too, and differently, moving it one slot along rather
-  than dropping it, and that stays the separate open condition disclosed above. And the tail is
+  than dropping it, which is the entry below. And the tail is
   weighed **one construct deep**, on the same test the shift report uses: where the escape character
   past the boundary heads a **recognized** sequence the bytes prefer the reading taken and the two
   repeats are the ones the sender wrote (`28.6&R&\&R&U/L` is the canonical repeat separator
   escaped, written and escaped again, and refusing it is the over-refusal that sank a criterion
   measured for this same family), and where it heads an **unrecognized** one the competing alignment
-  would leave two escape characters bare, so the preference is stronger again. That second case still
-  truncates and is silent here: recorded as a residue, measured, not overlooked.
+  would leave two escape characters bare, so the preference was read as stronger again, and this
+  shipped silent there while the field truncated just the same. **That residue is closed later in
+  this same release** (see the tail-bound entry below).
 
   **Measured against the corpus constants committed with the test**, on the same
   strict-accepted-under-a-gate-legal-profile tier and the same **864 tuples** as the two measurements
-  before it, in `test/records/alignment-truncated-field.test.ts`: the code fires on **96**, moves
-  **32** from accepted to refused under a profile built from the whole tolerable allow-list, moves
-  **0** back, and fires on **none** of the 96 escape-clean tuples. The pair-count criterion measured
+  before it, in `test/records/alignment-truncated-field.test.ts`: as this code shipped it fired on
+  **96**, moved **32** from accepted to refused under a profile built from the whole tolerable
+  allow-list, moved **0** back, and fired on **none** of the 96 escape-clean tuples. **The
+  tail-bound widening below takes the first two to 192 and 64 on the same corpus**, which is what the
+  committed test asserts now, and leaves the escape-clean zero where it is. The pair-count criterion measured
   and rejected on this same corpus would have refused 48 of them, which is why the tail is what gets
   weighed. **Unlike that rejected criterion's population, this one is not confined to a set naming a
   mnemonic letter as a delimiter**: the canonical repeat separator reaches it, on 12 of the 108
@@ -276,6 +327,211 @@ this file is maintained by hand (Changesets handles the version bump and publish
   factory, the `TruncatedFieldSink` type, and a further trailing optional sink parameter on
   `splitEscapeAware`, `tokenizeRecord` and `tokenizeHeader`.
 
+- **A parse-path warning code for components a competing escape alignment moved one slot along**
+  (`ASTM-FRAME-RESIDUALS`, defect 17c). `ASTM_RECORD_ALIGNMENT_SHIFTED_COMPONENTS` fires where two
+  escape alignments of the same bytes disagree about a **component** boundary, the reading taken
+  keeps it, and the escape character that reading resumes on heads **no sequence at all**. (**That
+  tail bound is widened later in this same release**; see the entry below.) It lands on the profile
+  safety gate, so `{ strict: true }` refuses a stream carrying it whatever profile is in force. With it the three roles a split is taken on are all wired; there is no fourth, because
+  nothing splits on the escape role.
+
+  **Nothing shifts between fields and nothing leaves the record: the slots MOVE.** That is the third
+  answer to the one question the two entries above ask, and it is why neither of them could carry it.
+  Components are modeled **inside** a field, so every component after the gained boundary sits one
+  place further right than the competing alignment puts it, and the slots that indexes into are named
+  things. Both costs are reachable on the **canonical** set, so no unusual declaration is needed:
+  - **A code system and a vendor's local code swap places.** `R|1|&F&^&GLU^L^687|28.6|U/L||||F`
+    reads a Universal Test ID of four components, so `L` is the coding scheme and `687` the local
+    code; the competing alignment reads three, and `687` is the **coding scheme**. A code-system
+    selector and a vendor's local code are not the same thing, so a consumer routing on either is
+    routing on the alignment.
+  - **A given name and a middle name shift along.** `P|1||MRN-0001||DOE&F&^&JANE^A||19700101|F`
+    reads a given name of `&JANE` and a middle name of `A`; under the competing alignment `A` is the
+    **given** name and there is no middle name at all.
+
+  Before this code the only warning on either stream was the tolerable
+  `ASTM_UNPAIRED_ESCAPE_CHARACTER`, so the widest gate-legal profile plus `{ strict: true }` accepted
+  both. **This closes a claim that had been recorded as false and shipped**: "a gained repeat or
+  component boundary divides one field and reaches nothing outside it, so it cannot move a modeled
+  slot". The first clause is true and the inference is not.
+
+  **Every gained boundary at or before the LAST MODELED COMPONENT INDEX moves those slots, not only
+  the first**, because the shift propagates from it to the end of the component list. That is the one
+  structural asymmetry with the repeat-separator code above, where a field is modeled out of its
+  first repeat alone and only the first gained boundary reaches a modeled slot. **Two bounds run the
+  other way and this fires inside both**, which is over-reporting relative to the named slots and
+  never under-reporting, measured rather than assumed: past the last modeled component index a model
+  reads a fixed number of components (a patient name three, a Universal Test ID four), so a contested
+  boundary further right shifts the components after it while every named slot reads the same under
+  both alignments; and inside a LATER repeat nothing modeled moves at all, because `components` is
+  the first repeat. Narrowing the sink to either would change which streams a published package
+  refuses and wants its own measurement, so both bounds are written down instead.
+
+  **Additive, and the split is unchanged.** Every decoded byte is identical and the components read
+  are the components that were always read: this reports the moved slots, it does not repair them.
+  Picking the other alignment was rejected for the same reason as before, on a published package, and
+  **withholding the moved slots stays a separate question**: declining to model a slot changes an
+  extracted value for every consumer already on the registry.
+
+  **The tail is weighed one construct deep**, on the same test the two codes above use. Where the
+  escape character past the boundary heads a **recognized** sequence the bytes prefer the reading
+  taken and the components are the ones the sender wrote (`&F&^&F&GLU` is a field separator escaped,
+  a component separator written, and a field separator escaped again, which raises no warning at all,
+  and refusing it is the over-refusal that sank a criterion measured for this same family); where it
+  heads an **unrecognized** one the competing alignment would leave two escape characters bare, so
+  the preference was read as stronger again, and this shipped silent there while the slots moved just
+  the same. **That residue is closed later in this same release** (see the tail-bound entry below).
+
+  **Measured against the corpus constants committed with the test**, on the same
+  strict-accepted-under-a-gate-legal-profile tier and the same **864 tuples** as the three
+  measurements before it, in `test/records/alignment-shifted-components.test.ts`: as this code
+  shipped it fired on **96**, moved **32** from accepted to refused under a profile built from the
+  whole tolerable allow-list, moved **0** back, and fired on **none** of the 96 escape-clean tuples.
+  **The tail-bound widening below takes the first two to 192 and 64 on the same corpus**, which is
+  what the committed test asserts now, and leaves the escape-clean zero where it is. The pair-count
+  criterion measured and rejected on this same corpus would have refused 48 of them, which is why the
+  tail is what gets weighed. Its column is **disjoint from both** earlier tail reports, asserted on
+  the shared corpus rather than reasoned from the wiring: the three partition the splitting roles.
+
+  **The index axes that corpus holds fixed are swept beside it, because a criterion measured only
+  there inherits its blind spot.** Across every component position of the first repeat the reading
+  taken reads exactly one component more than the competing alignment, so the harm is not bounded to
+  the first boundary. And the identical 864-tuple alphabet re-run with a clean first repeat in front
+  of the contested construct gives the same column and the same delta (**96 fire, 32 move, 0 back, 0
+  escape-clean**) while on **all 96** the modeled component list is identical under both alignments,
+  which states the over-reporting bound as a measurement rather than as prose.
+
+  **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. Catch it on the first read of the wire bytes.
+
+  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_COMPONENTS`, the `alignmentShiftedComponents`
+  warning factory, the `ShiftedComponentsSink` type, and a further trailing optional sink parameter
+  on `splitEscapeAware`, `tokenizeRecord` and `tokenizeHeader`.
+
+- **The three alignment tail reports now fire on a tail they cannot READ, not only on one they cannot
+  CONSUME** (`ASTM-FRAME-RESIDUALS`, defect 17, the disclosed residue). No new code and no rename:
+  `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` and
+  `ASTM_RECORD_ALIGNMENT_SHIFTED_COMPONENTS` all keep their names, their claims and their roles. What
+  changes is the one predicate behind them: a contested boundary is now reported where the escape
+  character the reading taken resumes on heads **no sequence this reader can interpret**, which is
+  two cases rather than one.
+  - It heads **no sequence at all** and is kept as a bare literal
+    (`ASTM_UNPAIRED_ESCAPE_CHARACTER`). Reported before, reported now.
+  - It heads a sequence whose body is **not a recognized mnemonic**, so the triple is preserved
+    verbatim and never guessed at (`ASTM_UNKNOWN_ESCAPE_SEQUENCE`). **This is what was silent.**
+
+  **The correction is to the reason, which is why it is worth stating.** The recorded ground for the
+  silence was a comparison of preferences: in that case the competing alignment would leave **two**
+  escape characters bare while the reading taken carries one unreadable body, so the bytes prefer the
+  reading taken more strongly than in the case that already fired. That comparison is true. It is not
+  the question these codes ask. They report a **cost**, a modeled slot decided by a boundary the
+  bytes do not force, and the cost is the same one: on the canonical set
+  `R|1|^^^687|28.6&F&|&Z&U/L||||F` still reads nine fields against the competing alignment's eight
+  and still hands back a status of `final` the sender put in no slot; `28.6&S&\&Z&U/L` still reads a
+  value of `28.6^`; `&F&^&Z&GLU^L^687` still reads `687` as a vendor local code where the competing
+  alignment reads it as the **coding scheme**. Each raised only the tolerable
+  `ASTM_UNKNOWN_ESCAPE_SEQUENCE` before, so the widest gate-legal profile plus `{ strict: true }`
+  accepted all three. **Consuming a triple is not interpreting one.**
+
+  **Exactly one tail is still excluded, and it is the one that carries the whole over-refusal
+  argument.** Where the escape character heads a sequence this reader **recognizes**, the reading
+  taken interprets a construct and nothing is reported: 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. That
+  is the **only** tail on which a stream's escaping can be clean at all, so it is the only exclusion
+  that could ever protect conformant traffic, and refusing it is the over-refusal that sank a
+  criterion measured and rejected for this same family. The widened predicate **cannot** refuse an
+  escape-clean stream: every position it now rejects already raises an escape deviation of its own.
+
+  **That remaining silence is a TRADE, and it is not a claim that nothing was lost there.** On the
+  excluded tail the gained boundary is exactly as real, and it is not merely under-reported: it is
+  `warnings: []`, so a lenient consumer sees nothing at all. On the canonical set,
+  `R|1|^^^687|28.6&F&|&F&U/L||||F` reads **nine** fields against the competing alignment's eight and
+  hands back a status of **`final`**; `28.6&S&\&S&U/L` reads a value of `28.6^` and `^U/L` leaves
+  every modeled slot; `&F&^&F&GLU^L^687` reads one component more, so `687` is a vendor local code
+  under one reading and the **coding scheme** under the other. All three are `PRE-EXISTING`, all
+  three are now pinned by tests rather than by prose, and **read the raw line when an escape
+  character sits next to a delimiter, whether or not anything fired.**
+
+  **Additive in behaviour terms and still a report, not a repair.** No split changed, every decoded
+  byte is identical, and no tolerable code was struck off and no code became tolerable. **What the
+  three codes CLAIM about their role did have to move, and that is recorded rather than glossed**:
+  see the entry below. It still does not survive a re-emit:
+  the serializer rewrites the preserved characters into recognized mnemonics, so a second-generation
+  read is silent and correct about its own bytes. Catch it on the first read of the wire bytes.
+
+  **Measured against the corpus constants committed with the tests**, on the same
+  strict-accepted-under-a-gate-legal-profile tier as every measurement in this family. On the shared
+  **864-tuple** corpus each of the three codes now fires on **192** where it fired on 96, moves
+  **64** from accepted to refused where it moved 32, moves **0** back, and fires on **0** of the 96
+  escape-clean tuples exactly as before. The two reported tails contribute equally, so neither half
+  of a column carries the other.
+
+  **The axis that corpus holds fixed is swept beside it**, because a criterion measured only there
+  inherits its blind spot: that corpus varies whether the tail is bare, recognized or unrecognized,
+  but uses a single character as the unrecognized body. `test/records/alignment-unrecognized-tail.test.ts`
+  crosses `DECLARATION_ALPHABET`, `SPLITTING_ROLES` and `BODY_ALPHABET` with the same alphabet as the
+  **tail** body: **3,456 tuples**, of which **2,304** fire, **528** move from accepted to refused,
+  **0** move back, and **384** are escape-clean with **0** of them refused. Every tuple's observed
+  disposition is asserted against a predicate derived from those alphabets rather than against a
+  count, and the harness is failed on purpose against a perturbed mnemonic set in both directions.
+
+  **One universal that sweep refuted, recorded because it is the obvious thing to write.** "The
+  reading taken reads exactly one more segment than the competing alignment" is **false**. Where the
+  tail sequence's body is the delimiter the split is being taken on, the reading taken keeps that
+  character inside an opaque atom while the competing alignment splits on it, so the two readings
+  produce the **same** number of segments in **different** places: under `H~\^&`, `28.6&F&~&~&U/L`
+  reads `28.6&F&` + `&~&U/L` against the competitor's `28.6&F&~&` + `&U/L`. That is 144 of the 2,304
+  firing tuples. What holds on all of them is that the two readings **disagree** and that both
+  consume every byte, so neither is forced.
+
+  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. **No new
+  public surface**: no code, type, factory or parameter was added, removed or renamed.
+
+- **The three alignment tail reports now state the one class in which nothing moves index**
+  (`ASTM-FRAME-RESIDUALS`, defect 17, the claim correction the widening above forced). Widening the
+  predicate widened the firing population past the point where each code's own cost claim held
+  everywhere, and the claims did not move with it. They do now. Where a surface states the cost, it
+  names the exception: the three sink docs in `src/common/escapes.ts`, the three code entries, the
+  three factory leads and the three **runtime warning messages** in `src/common/warnings.ts`,
+  `src/profiles/safety.ts`, the `referenceCorpus` rationale string, `README.md`,
+  `docs-content/quickstart.md`, `docs-content/limitations.md` and
+  `docs-content/troubleshooting.md`. Where a surface only paraphrased a cost, the paraphrase was
+  **removed** rather than re-qualified, so there is one place to keep true: the `@param` text on
+  `splitEscapeAware` in `src/common/escapes.ts` and on `tokenizeRecord` in `src/records/tokenize.ts`
+  now defers to the sink docs instead of restating them.
+
+  **The class, named rather than left to be found.** Where the sequence past the contested boundary
+  carries **the splitting delimiter itself** as its body, the reading taken holds that character
+  inside an opaque atom while the competing alignment splits on it, so the two readings return the
+  **same number** of segments in **different places**. Nothing moves index, and what differs is the
+  contents. On the canonical set `R|1|^^^687|28.6&F&|&|&U/L||||F` reads **nine** fields under both,
+  with the status `F` in field 9 under both and units of `&|&U/L` against `&U/L`; `28.6&F&\&\&U/L`
+  reads **two** repeats under both; `DOE&F&^&^&JANE^A` reads **three** components under both, with
+  `A` the middle name under both. So "every later field is one place further right", "the field is
+  read as more repeats than the other reading gives it" and "every later component sits one place
+  further right" were each false on that class, in `dist/index.d.ts`, in the immutable docs tarball,
+  and in three runtime messages.
+
+  **The class is bounded, and the bound is measured against constants committed with the test, not
+  argued.** `test/records/alignment-unrecognized-tail.test.ts` crosses `DECLARATION_ALPHABET`,
+  `SPLITTING_ROLES`, `BODY_ALPHABET` and `TAIL_BODY_ALPHABET` with two further constants,
+  `PAYLOAD_PREFIXES` and `PAYLOAD_SUFFIXES`, so the carrier shape is not held fixed the way every
+  earlier corpus in this family held it: **55,296 tuples**, of which **36,864** fire and **2,304**
+  are the class. **0** of those lack `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` and **0** were
+  accepted before this release, because that tail body is a splitting delimiter in force. So the
+  three codes over-report relative to the indexes there and never under-report, and the class costs
+  no stream its disposition. The class is exactly "the tail body is the delimiter being split on",
+  with **0** counterexamples in either direction. Every figure is derived from those six constants
+  inside its own assertion; **never quote one against a different sha or a different corpus.**
+
+  **What holds on every firing tuple**, and it is what the claims now lead with: the two readings
+  **disagree**, and both **consume every byte**, so neither reading is forced. No code, message
+  identity, type, factory or parameter changed, and no stream's disposition moved.
+
 ### Fixed
 
 - **A header that is not short no longer reports that it is too short** (`ASTM-FRAME-RESIDUALS`,
@@ -599,10 +855,13 @@ this file is maintained by hand (Changesets handles the version bump and publish
   unchanged, still `test/fixtures/**` and `src/**.ts`, so a staged link outside it is still not
   looked at; narrowing what a scope admits is not widening the scope. That scope also bounds the
   gitlink half: a submodule staged at `test/fixtures/nested` is refused, while one at `src/nested` is
-  a directory name that fails the `.ts` suffix and is not looked at. `R` (rename) and `C` (copy) are
-  still **not** enumerated by `--staged` at all, so a staged rename that also appends PHI passes that
+  a directory name that fails the `.ts` suffix and is not looked at. **`R` (rename) and `C` (copy)
+  are still not enumerated by `--staged` at all, so a staged rename that also appends PHI passes that
   route; pre-existing, unchanged here, and admitting it needs the two-path record shape handled,
-  which is a scope decision rather than this one. A tracked file **absent from the worktree** is
+  which is a scope decision rather than this one.** That last sentence was true when it was written
+  and is **superseded later in this same release**: the entry below closes it, and it turned out to
+  need no two-path record shape at all. It is kept rather than rewritten because the measurement it
+  records is what the later entry starts from. A tracked file **absent from the worktree** is
   still caught at `git add` time only.
 
   **And this scanner still has no rule that a sweep observing ZERO targets must refuse**, which is
@@ -627,6 +886,87 @@ this file is maintained by hand (Changesets handles the version bump and publish
   is not, which makes closing it a separate slice with its own argument rather than a rider on a PHI
   blindness fix. It is a different defect and it fails in the safe direction.
 
+- **The PHI scanner's staged route no longer lets git decide what it is safe not to look at, so a
+  `git mv` into a fixture directory can no longer carry PHI past the pre-commit gate**
+  (`PHI-SCAN-RENAME-BLIND-AT-PRECOMMIT`). Development tooling only: `scripts/phi-scan.ts` ships in no
+  tarball and the package's public surface is unchanged.
+
+  Reproduced on `427af85` before any fix, on git 2.39.5, with the same synthetic name-bearing payload
+  the symlink cases use (an ASTM `P` record carrying a patient name, a mother's maiden name and a
+  birthdate, plus a dashed SSN and an email at a non-test domain). Four ways the enumeration could be
+  emptied before any of the refusals above were reached, each measured as its own throwaway index:
+  - **A staged rename.** `git mv test/fixtures/original.astm test/fixtures/renamed.astm` on a file
+    carrying the payload paired as a single record with **two** paths and a status letter of `R`, and
+    `--diff-filter=AMT` returned nothing for it, so `pnpm phi-scan --staged` printed `OK: no hits`
+    and exited **0**. The same move with the payload **edited into the destination in the same
+    staging** passed identically, because git still pairs it when enough of the old content survives.
+    No similarity score is quoted here: it moves with how much survives, so a number taken from one
+    fixture is wrong in the next, and what is load-bearing is that the record was paired at all.
+  - **A staged rename of a symbolic link.** `git mv` of a tracked link into `test/fixtures/` put a
+    mode-`120000` entry under a scan root. The mode refusal added by the previous entry already knew
+    how to refuse that; the pairing deleted the record before the mode could be read, and the run
+    exited **0**.
+  - **A gitlink the caller's config hid.** `diff.ignoreSubmodules = all` in the caller's git config
+    dropped a staged gitlink under `test/fixtures/` from the raw output entirely. The **same index**
+    refused at exit 2 without that config and reported `OK: no hits` at exit **0** with it.
+  - **An unmerged path.** An in-scope path recorded unmerged, with the payload on one side, was
+    returned by neither `AM` nor `AMT`, and the run printed `OK: no hits` and exited **0** over an
+    index it could not read: such a path is recorded at one or more of stages 1/2/3 and never at
+    stage 0, and stage 0 is exactly what the `:<path>` form this route reads with names, so there is
+    no one blob for it to read. **Nothing rests on what `git show` does with such a path**: the route
+    refuses before it would call it, and an earlier draft that pinned that exit code did not
+    reproduce across git versions.
+
+  **The remedy is entirely in the argv, and it is one rule: stop trusting the caller's git config,
+  and stop letting the filter decide what is safe not to look at.** The route now reads
+  `git diff --cached --raw -z --no-renames --ignore-submodules=none --diff-filter=AMTUB`.
+  `--no-renames` makes a paired record impossible, so the destination arrives as an ordinary
+  single-path `A` and the source as a `D` the filter drops; verified under `diff.renames` at
+  `true`, `copies` and `false` and under `diff.renameLimit=1`, every one yielding the same
+  single-path record, so the two-field record stride is now **structural** rather than conditional on
+  the caller's config. `--ignore-submodules=none` restores a record the config could delete.
+  `U` is in the filter **so it can be refused, not scanned**, with its own message: an unmerged
+  record's destination mode is `000000`, so the existing refusal would have described it with a
+  sentence about symbolic links and gitlinks that is false for it. That case builds the unmerged
+  index directly, with `git update-index --index-info`, rather than provoking it with a real merge:
+  whether a merge conflicts depends on the merge machinery and on the caller having a git identity,
+  and the index state is the thing under test. Staged as a real conflict it did not reproduce on
+  every git version. None of the four costs the record
+  stride anything, because each carries a single path.
+
+  **Be exact about what that changes.** The new enumeration is a **superset** of the old one, not a
+  strictly larger set: the two are **equal** whenever nothing is renamed, copied, unmerged or hidden
+  by that config, and larger only when something is. Nothing the old argv enumerated stops being
+  enumerated. The `--staged` path scope is **unchanged**, still `test/fixtures/**` and `src/**.ts`, so
+  an unmerged or renamed path outside it is still not looked at, and both of those are pinned.
+
+  **`B` is in the filter because `-B` is not inert, and the mechanism is sharper than "a `B` record
+  the filter drops".** A complete rewrite under `-B` prints a **single-path record whose status
+  letter is `M`**, with a break score, which the record regex parses happily, so a reader checking
+  the raw output concludes the record is an `M` and that `AMTU` therefore keeps it. It does not:
+  `--diff-filter` classifies a broken pair as `B` **whatever letter it prints**. Measured on one
+  index, over a wholly rewritten in-scope fixture carrying a dashed SSN: `-B --diff-filter=AMTU`
+  returns empty while `-B --diff-filter=B` and `-B --diff-filter=AMTUB` each return the same record,
+  and a copy of the scanner with `-B` injected exits **0** with `OK: no hits` on the superseded
+  filter and **1** with the hit on the shipped one. `B` costs the enumeration nothing today, since
+  git only breaks a pair when `-B` is given, so it is there to stop the flag ever being a silent
+  blindfold. `-M`, `-C` and `--find-copies-harder` each turn detection back on over the top of
+  `--no-renames` and empty the route again, which is measured beside it; none of the four may be
+  added.
+
+  **6 of the file's 41 cases are red on `427af85`**, and the premises each rests on are pinned beside
+  it, so a case cannot quietly stop testing anything. Refusal messages still name only the entry's own
+  repo-relative path and an engine-owned reason, never a link target or any stream content, and that
+  is asserted on the new refusal too.
+
+  **What this does not cover, stated narrowly.** The all-mode walk is untouched: it has no concept of
+  a rename, and nothing here widens or narrows what it enumerates. The scan roots' own paths are still
+  outside the `--staged` scope, so a staged blob, link or gitlink at exactly `test/fixtures`, `test`
+  or `src` is still not looked at by that route. Neither route reaches `test/**/*.test.ts`, where this
+  package keeps most of its inline fixtures, so those are still read by hand. And this scanner still
+  has no rule that a sweep observing zero targets must refuse, exactly as recorded above. Each of
+  those is a scope decision with its own argument, not a consequence of anything here.
+
 - **The frame encoder no longer writes a different character than the one it was handed**
   (`ASTM-FRAME-BYTE-RESIDUALS`, closing known defect 7). `composeAstmFrames` turned a record given
   as a `string` into bytes with `charCodeAt(i) & 0xff`, so any character above `U+00FF` was replaced

package/README.md

@@ -1,7 +1,9 @@
-<picture>
-  <source media="(prefers-color-scheme: dark)" srcset="https://cosyte.com/tile/cosyte-lockup-tile-on-dark-1200x300.png">
-  <img alt="Cosyte: a plus mark set in two overlapping rounded squares, one solid and one outlined, beside the Cosyte wordmark" src="https://cosyte.com/tile/cosyte-lockup-tile-on-light-1200x300.png">
-</picture>
+<a href="https://cosyte.com">
+  <picture>
+    <source media="(prefers-color-scheme: dark)" srcset="https://cosyte.com/tile/cosyte-lockup-tile-on-dark-1200x300.png">
+    <img alt="Cosyte: a plus mark set in two overlapping rounded squares, one solid and one outlined, beside the Cosyte wordmark" src="https://cosyte.com/tile/cosyte-lockup-tile-on-light-1200x300.png">
+  </picture>
+</a>
 
 # @cosyte/astm
 
@@ -222,9 +224,12 @@ 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
+disagree about the bytes after the boundary, not only about it (they can resync later, and the
+class where they do is named below). Where the escape character the
+reading taken resumes on heads no sequence this reader can _interpret_ (none at all, or one whose
+body is not a recognized mnemonic and is therefore preserved verbatim rather than read), that
+reading bought the boundary with bytes it cannot read while the competing alignment is the one that
+can use them. 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
@@ -235,9 +240,24 @@ tolerate**; before it existed the only warning on that stream was the tolerable
 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 repeat or component boundary does reach a modeled slot. 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.
+gained repeat or component boundary does reach a modeled slot, and each of those two has a code of
+its own below. It stays silent in exactly one case,
+where the trailing escape character heads a sequence this reader RECOGNIZES: that is the escape
+mechanism working, and refusing it would refuse well-formed traffic. That is the only tail on which
+a stream's escaping can be clean, which is why it is the only exclusion. **That silence is a trade
+and not a claim that nothing was lost there**: the gained field boundary is exactly as real, and on
+that tail it is `warnings: []`, so `R|1|^^^687|28.6&F&|&F&U/L||||F` reads nine fields against the
+competing alignment's eight and hands back a status of `final` with nothing reported at all. Read
+the raw line when an escape character sits next to a delimiter, whether or not anything fired.
+**The shift has one measured exception, and it is named rather than left to be found**: where the
+sequence past the boundary carries the field separator itself as its body, the reading taken holds
+that character inside an opaque atom while the competing alignment splits on it, so the two readings
+read the **same number** of fields in **different places**. `R|1|^^^687|28.6&F&|&|&U/L||||F` reads
+nine fields under both, with the status `F` in field 9 under both, and what differs is the units.
+The code still fires there, which is over-reporting relative to the field indexes and never
+under-reporting, and that class costs no stream its disposition, because
+`ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` has already refused it. It does not survive a re-emit
+either: catch it on the first read.
 
 **And where that gained boundary is a REPEAT boundary, nothing shifts and the field can still be
 read short.** What the report says is that the field is read as more repeats than the competing
@@ -253,12 +273,44 @@ legal profile accepted a truncated value and an emptied test identity. The readi
 reports the gained boundary rather than repairing it. **At a LATER boundary it fires and no modeled
 slot moves**, because the first repeat is then the same under both readings; that is over-reporting
 relative to the modeled slots and never under-reporting, and it is measured rather than assumed. Its
-tail bound is the shift report's, for the same reason: `28.6&R&\&R&U/L` is the repeat separator
-escaped, written, and escaped again, and refusing it would refuse a well-formed stream. It is wired to the **repeat** separator only; a gained
-**component** boundary reaches a modeled slot differently, moving it one slot along rather than
-dropping it (`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), and that is a separate
-open condition. It does not survive a re-emit either: catch it on the first read.
+tail bound is the shift report's, for the same reason, and so is its one exclusion:
+`28.6&R&\&R&U/L` is the repeat separator escaped, written, and escaped again, and refusing it would
+refuse a well-formed stream. **That silence is a trade, not a claim that nothing was lost**:
+`28.6&S&\&S&U/L` still reads a value of `28.6^` with `warnings: []`. **The truncation has the same
+one exception as the shift**: where the sequence past the boundary carries the repeat separator
+itself, the two readings read the same number of repeats in different places, so the field is not
+read as more repeats at all, and that class was already refused by
+`ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`. It is wired to the **repeat** separator only; a gained
+**component** boundary reaches a modeled slot differently, and has its own code below. It does not
+survive a re-emit either: catch it on the first read.
+
+**And where that gained boundary is a COMPONENT boundary, nothing leaves the record and the slots
+MOVE.** Components are modeled inside a field, so every component after the gained boundary sits one
+place further right than the competing alignment puts it. On the canonical set,
+`R|1|&F&^&GLU^L^687|28.6|U/L||||F` reads a Universal Test ID of four components, so `L` is the coding
+scheme and `687` the vendor's local code; the competing alignment reads three, and `687` is the
+**coding scheme**. A code-system selector and a vendor's local code are not the same thing.
+`P|1||MRN-0001||DOE&F&^&JANE^A||19700101|F` reads a given name of `&JANE` and a middle name of `A`,
+where the competing alignment makes `A` the **given** name with no middle name at all. That raises
+`ASTM_RECORD_ALIGNMENT_SHIFTED_COMPONENTS`, which **no profile may tolerate**; before it existed the
+only warning on either stream was the tolerable `ASTM_UNPAIRED_ESCAPE_CHARACTER`, so a strict parse
+under a legal profile accepted both. The reading is unchanged: it reports the moved slots rather than
+repairing them. **Every gained boundary at or before the last modeled component index moves them,
+not only the first**, because the shift propagates to the end of the component list, which is where
+this differs from the repeat role. **Two bounds run the other way and it fires inside both**,
+over-reporting and never under: past the last modeled index nothing named moves (a name models three
+components, a Universal Test ID four), and inside a later repeat nothing modeled moves at all. Its
+tail bound is the other two reports', for the same reason, and so is its one exclusion, **and that
+silence is a trade rather than a claim that nothing was lost**: `&F&^&F&GLU^L^687` still reads one
+component more than the competing alignment, with `warnings: []`. **A THIRD bound runs the other way
+here, and unlike the two above it is about the bytes past the boundary rather than where the
+boundary sits**: where the sequence past it carries the component separator itself, the two readings
+read the same number of components in different places, so `DOE&F&^&^&JANE^A` reads three components
+under both with `A` the middle name under both, and that class was already refused by
+`ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`. What holds wherever any of the three codes fires is
+that the two readings disagree and that both consume every byte, so neither is forced. It does not
+survive a re-emit either: catch it on the first read. With this the three splitting roles are all
+wired, and there is no fourth: nothing splits on the escape role.
 
 ### A header that names one character in two delimiter roles
 
@@ -355,12 +407,17 @@ outside it:
   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
+  an escape character heading no sequence it can interpret, 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. Where it is a **repeat** boundary
   nothing shifts, but the field is read out of its first repeat alone, so a gained first boundary
   truncates a value and costs a test identity or a patient name the components that sat after it:
-  that raises `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`, not tolerable either.
+  that raises `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`, not tolerable either. Where it is a
+  **component** boundary nothing leaves the record and every component after it moves one slot
+  along, so a coding scheme, a vendor local code or a given name is read out of a position the other
+  alignment does not put it in: that raises `ASTM_RECORD_ALIGNMENT_SHIFTED_COMPONENTS`, 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