@cosyte/dicom 0.0.8 → 0.0.11

package/CHANGELOG.md

@@ -6,6 +6,625 @@ All notable changes to `@cosyte/dicom` will be documented in this file. The form
 
 ### Fixed
 
+- **🩺 Repeated de-identification was not a fixed point: `(0012,0063)` grew by the whole method
+  string on every pass, for any `deidentificationMethod` ending in a SPACE or a NUL**
+  (`DICOM-DEIDENT-NOT-A-FIXED-POINT`). **`INTRODUCED` by the entry below and never published** - it
+  was found by a fourth graded pass while this release was still held, so no consumer ever saw it.
+  Measured in memory over four passes: `"ACME Anonymizer v3 "` read **19 -> 38 -> 57 -> 76** bytes
+  and `"Pass A\Pass B "` read **14 -> 21 -> 28 -> 35**, against a flat **19** and **14** on the
+  commit before. Over a real `parse -> deidentify -> serializeDicom -> parse` round trip a 16-byte
+  method read **16 -> 32 -> 48 -> 64 -> 80 -> 96** over six cycles. Growth continued to the
+  65,534-byte ceiling, where the guard **replaces the entire prior provenance chain** - the exact
+  loss the entry below exists to prevent, reached from a benign caller string.
+
+  One asymmetry caused it: the prior value was right-trimmed of `0x20`/`0x00` and the added one was
+  not, so a freshly supplied value never equalled its own prior copy - the library wrote the method,
+  the serializer's even-length pad folded the trailing byte in, the next parse trimmed it off, and
+  the next pass appended the method again. PS3.5 2026c **Table 6.2-1**, `LO` row: "A character string
+  that **may be padded with leading and/or trailing spaces**" - trailing spaces are padding, not
+  content, so the comparison cannot honour that on one side only.
+
+  **The trim is per VALUE at the comparison, and a graded pass is why.** A first remedy trimmed each
+  operand as a whole Value Field, which reaches only its last value, so a pad byte on an interior
+  value of a `1-n` method still regrew the attribute byte-identically: `"Pass A \Pass B"` beside a
+  prior `"Pass B "` read **14 -> 21 -> 28 -> 35 -> 42**, and the chain was still replaced at the
+  ceiling. Table 6.2-1 describes a **Value** and `LO` is `1-n`, so every value's trailing pad is
+  padding; **§6.4**'s "single padding character ... to the end of the Value Field (**to the last
+  Value**)" is about where the encoder writes its pad, which is why the value **written** is trimmed
+  once over the field. Leading spaces a caller wrote are still written through untouched. With both,
+  `deidentify` is a fixed point **from the first pass**. A `deidentificationMethod` that is padding
+  only records nothing.
+
+- **🩺 A prior `(0012,0063)` value surviving into de-identified output is no longer silent**, via
+  the new Tier-2 code **`DICOM_DEIDENT_METHOD_PRIOR_RETAINED`** on `report.warnings`. Keeping it is
+  what PS3.15 E.1.1 requires and nothing about the retention changes; the silence was the defect. A
+  name a sender wrote into `(0012,0063)` reached output stamped `(0012,0062) Patient Identity
+Removed = YES` with `report.warnings` empty **and** `report.retained` `[]` - an audit reading as a
+  scrub it had not performed, on an attribute Table E.1-1 does not list and no rule in the run
+  inspected. The code carries **no value, no length and no VR**: the retained text is the file's
+  own, the tag in the message is a constant of the code, and `position.byteOffset` locates the
+  element. It is deliberately **not** on `report.retained`, which lists the Annex E option sets
+  active for the run - a kept attribute is not an option set, and widening that type would break
+  every consumer switching over the nine names. Emitted by `deidentify()` only, so it never reaches
+  the parser's `{ strict: true }` escalation.
+
+- **🩺 A second copy of a MODELED `(0002,xxxx)` element left the parsed object with no warning and
+  no residue** (`DICOM-FILE-META-DROPS-DUPLICATE`, raised by `#70`'s gate). **`PRE-EXISTING`**, on
+  every released version including the current published `0.0.10`. This is `#70`'s shape one group
+  over, and **`(0002,xxxx)` is the group that decides how every following byte is read**, which
+  makes it the more dangerous of the two. Disclosed now by the new Tier-2 code
+  **`DICOM_DUPLICATE_FILE_META_ELEMENT`**, raised at the moment the projection drops the copy.
+
+  **It is lossy by a different route from the Data Set case, and the difference is the whole
+  entry.** The File Meta group is collected into an **array**, so nothing is overwritten and
+  `DICOM_DUPLICATE_TAG_IN_DATA_SET` never fired here - `#70`'s own JSDoc said exactly that, and
+  reading it as an all-clear was the defect. The eight tags `parseFileMeta` projects into typed
+  `FileMeta` fields are answered by a **first-match** search and are **excluded** from
+  `FileMeta.extraElements`, the verbatim residue that gives the group its byte-exact round trip. A
+  second copy of one is therefore in neither.
+
+  **So the two codes resolve a repeat the opposite way round, deliberately, because the two readings
+  do: the FIRST copy wins in the File Meta group, the LAST read wins in a Data Set.** Neither
+  reading moves in this release, **no value is guessed for the copy that lost**, and no residue is
+  invented for it - inventing one would make the serializer write a group it should not. A repeated
+  `(0002,xxxx)` tag this library does **not** model stays silent, because every copy of one is
+  already kept verbatim in `extraElements` and nothing is dropped. **Two `PRE-EXISTING` bounds a graded pass named, neither closed here**: `serializeDicom` re-emits BOTH copies of such a non-modeled repeat, which is where this package's round-trip promise and its spec-clean promise disagree; and the disclosure covers the group **as the parser delimits it**, so a copy an intermediary appended past an honest `(0002,0000)` group length is never a File Meta element to this parser at all and is relocated into the main Data Set, silently, on this tree and every earlier one.
+
+  **Measured on the published tarball rather than inferred from a version number.**
+  `npm pack @cosyte/dicom@0.0.10` (the registry's current `latest`; there is no `0.0.9`), a file
+  carrying `(0002,0010)` twice with two **different** Transfer Syntax UIDs:
+  `fileMeta.transferSyntaxUID` reads the first, `fileMeta.extraElements` is `[]`, `ds.warnings` is
+  `[]`, and `{ strict: true }` does **not** throw. Silent on every channel, on the released package.
+  **And the stakes are not hypothetical**: the same dataset bytes with only the ORDER of those two
+  UIDs swapped parse to two different objects, one of which raises `INVALID_FILE_META` out of the
+  dataset parser, because a length field read in the wrong encoding declares 1,199,696 bytes.
+
+  **The message names no tag, and the bound is the factory signature** -
+  `duplicateFileMetaElement(position)` - as for `DICOM_DUPLICATE_TAG_IN_DATA_SET`,
+  `DICOM_NONZERO_RESERVED_BYTES`, `DICOM_ITEM_CROSSES_SEQUENCE_END` and
+  `DICOM_DEIDENT_UNDEFINED_VR_NOT_AUDITABLE`. **Unlike the Data Set code, `position.byteOffset` here
+  is unambiguously file-absolute** - `parseFileMeta` is called once per parse with the whole buffer
+  and the group is never nested, so none of `Element.byteOffset`'s frame ambiguity can reach it - and
+  it locates the copy that was **dropped**, not the survivor.
+
+  **The citation, and the one that is deliberately absent.** PS3.5 2026c section 7.1, read from the
+  SHA-pinned `vendor/nema/part05/` and occurring **exactly once** in that document: "The Data
+  Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at
+  most once in a Data Set." **PS3.10, which governs the File Meta Information group, is NOT vendored
+  in this repo, so no PS3.10 sentence is cited here and no conformance verdict about a repeated
+  `(0002,xxxx)` is claimed.** The code's trigger is narrower and needs neither: it fires exactly when
+  a value the file carried does not reach the parsed object, and a `{ strict: true }` caller has
+  asked to be thrown at rather than handed a lenient reading.
+
+- **🩺 `deidentify()` REPLACED `(0012,0063)` De-identification Method where PS3.15 says it is
+  "inserted in or added to" it** (same item, second half). **`PRE-EXISTING`**, measured on `0.0.10`:
+  a file recording `"ACME Anonymizer v3 Basic Profile"` came out of `deidentify()` recording only
+  this library's own method, with the earlier one gone and nothing saying so. What that destroyed is
+  the **provenance chain** the attribute exists to carry, on a file whose earlier pass may be the one
+  a recipient was relying on.
+
+  PS3.15 2026c section **E.1.1 "De-identifier"**, read from the SHA-pinned `vendor/nema/part15/` and
+  occurring **exactly once**: "a text string describing the method used shall be **inserted in or
+  added to** De-identification Method (0012,0063)." Replacing is neither verb. This release appends
+  its own text as a further value of the `1-n` attribute after a `\`, copying the prior bytes through
+  **verbatim** so a value encoded under a `(0008,0005)` repertoire survives byte for byte. A value
+  that already records this method is left alone rather than growing the attribute. **The comparison
+  is per VALUE on both sides**: the method string is itself a `1-n` value, and a graded pass refuted
+  the draft that compared the whole string against each prior value - a caller method carrying a `\`
+  never matched one, and every pass appended a whole further copy (29 -> 59 -> 89 -> 119 bytes over
+  four passes, against a flat 29 on base). **Per value was necessary and not sufficient, and the
+  fixed-point claim as first written did not hold** - see the trailing-pad entry below, which is what
+  makes it true from the first pass.
+
+  **The join is bounded, and the bound is not cosmetic.** `LO` is a short-form VR, so
+  `encodeDatasetElement` writes its Value Length with a 16-bit field. A `(0012,0063)` carrying a legal
+  65,534-byte chain of `1-n` values - exactly the provenance chain this feature exists to build -
+  parses with no warnings, and an unbounded append produced a 65,611-byte value that `serializeDicom`
+  could not encode: a raw `RangeError` out of Node's `Buffer` internals, outside the documented
+  `DicomSerializeError` surface, taking the whole de-identified object down. When the join would
+  exceed the ceiling the prior value is **replaced** instead, which is what every released version did
+  on every file, and `report.warnings` carries the new `DICOM_DEIDENT_METHOD_NOT_ADDED`, so THAT
+  fallback is disclosed. Read the code as "the length ceiling was reached", never as "every fallback
+  is disclosed": the `PRE-EXISTING` non-`LO` replacement below is a second shape where `deidentify`
+  cannot add, and it is still silent. Truncating the sender's earlier records instead was refused: choosing
+  which to drop is a policy the standard does not state.
+
+  **`(0012,0062)` Patient Identity Removed is still REPLACED with `YES`, and the asymmetry is the
+  standard's own**: the sentence immediately above it, in the same list, says it "shall be **replaced
+  or added to** the Data Set with a value of YES". Different verbs, different attributes.
+
+  **The cost is disclosed rather than glossed, and a residual test asserts it.** `(0012,0063)` is
+  **not in Table E.1-1**, so the Basic Profile never acted on it and the incoming value reached the
+  insertion point untouched - the replacement was the only thing removing it, and removing it was an
+  action no profile asked for. A sender who wrote something identifying into `(0012,0063)` now sees
+  that text in de-identified output, which is the retained-by-omission posture every other unlisted
+  attribute already has. **Closing that direction is a product call about unlisted attributes, not a
+  fix to this insertion.** A `(0012,0063)` a file encoded under a VR other than `LO` is replaced
+  rather than appended to.
+
+  **The evidence, with its sha, because the base moves.** Re-measured at `e75fb38` after the last
+  test was added - and again after each conformance-gate remedy added more, which is the rule
+  and not a courtesy: **8 of the 12** tests in `test/integration/file-meta-duplicate.test.ts` and
+  **11 of the 19** in `test/deident/deident-method-add.test.ts` run red against that base, 19 of 31
+  in all. **Neither file can link against base `src/`** - none of
+  `WARNING_CODES.DICOM_DUPLICATE_FILE_META_ELEMENT`, `duplicateFileMetaElement`,
+  `WARNING_CODES.DICOM_DEIDENT_METHOD_NOT_ADDED` or `deidentMethodNotAdded` exists there - so both
+  figures are measured with those symbols substituted for their literals; unmodified they are 12 of
+  12 and 19 of 19 by construction, which is a fact about linking rather than about behaviour. The
+  ones that stay green on base are the controls that make the rest non-vacuous. **A figure taken this way is substitution-sensitive and the third pass read 9 rather than 8**, the delta being the factory-signature row, which is red or green purely by how the absent factory is stood in for. Read it as a floor, and re-derive it rather than quoting it. Quote such a figure
+  only with the sha it was run on.
+
+- **🩺 A Data Set that carries one tag twice DESTROYED the first element's value at parse time, and
+  said nothing** (`DICOM-TAG-COLLISION-DESTROYS-ELEMENT`). **`PRE-EXISTING`**, on every released
+  version including the current published `0.0.10`. A parsed Data Set is a `Map<Tag, Element>`, so
+  `Map.set` on a tag the map already holds **overwrites in place**: the earlier element's value is
+  gone from the object, and the survivor is indistinguishable from an element the sender wrote once.
+  No warning, no report entry, nothing a reader could query and nothing a round trip could reveal -
+  which is the same harm as a leak, in the other direction. It is now disclosed by the new Tier-2
+  code **`DICOM_DUPLICATE_TAG_IN_DATA_SET`**, raised at the moment of the replacement, in every Data
+  Set at every depth.
+
+  **Measured on the published tarball rather than inferred from a version number.**
+  `npm pack @cosyte/dicom@0.0.10` (the registry's current `latest`; `npm view` is the only source
+  for that, and there is no `0.0.9`), an Explicit VR LE file carrying `(0010,0020)` twice:
+  `ds.get("00100020")` reads the **second** value, `ds.warnings` is **empty**, and `{ strict: true }`
+  does **not** throw. Silent on every channel, on the released package.
+
+  **The remedy is the disclosure and nothing else.** The reading does not move: the last element read
+  still wins, exactly as in every released version, and **no value is invented for the one that was
+  replaced**. That is deliberate rather than modest. A file whose Item over-declares and a file whose
+  Sequence under-declares are byte-identical (pinned by `Buffer.equals` in
+  `test/integration/explicit-sq-item-bound.test.ts`), so a reader cannot choose the "right" element
+  from the bytes; what it can do is say that it had to choose.
+
+  **Citations, traced rather than stated.** PS3.5 2026c section 7.1 "Data Elements": "The Data
+  Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at
+  most once in a Data Set." Section 7.5.1 "Item Encoding Rules", one level down: "Within the context
+  of each Item, these Data Elements shall be ordered by increasing Data Element Tag value and appear
+  only once." Both read from the SHA-pinned `vendor/nema/part05/`, each occurring exactly once in
+  that document. **So this code cannot fire on a conformant file**, which is what makes it safe to add
+  under the `{ strict: true }` escalation every Tier-2 code takes.
+
+  **The message names no tag, and that is specific to this code.** A sender writing the same tag twice
+  is the rare route; the ordinary one is a length field that lies, so the second header's four tag
+  bytes are read out of the middle of some element's value. `renderTag` shape-checks a tag and
+  therefore cannot refuse one, so the bound is the factory signature, as it is for
+  `DICOM_NONZERO_RESERVED_BYTES` and `DICOM_ITEM_CROSSES_SEQUENCE_END`. `position.byteOffset` is the
+  offset of the header that replaced, which is the surviving element's own `Element.byteOffset` -
+  so at the **root** the tag is read off the model rather than out of a message. **Inside a
+  defined-length Sequence Item it is not a lookup at all**: `Element.byteOffset` is item-relative
+  there, so the same number can name an untouched root element, and no parser warning populates
+  `position.contextPath` to tell them apart. Read the code as "an element in this object was
+  destroyed" unless you have established the frame.
+
+  **What this cost, measured on `scripts/measure-sq-bound-grid.ts` against `0ead071`, because a
+  disclosure that changes a `{ strict: true }` parse is a behaviour change.** Of 83,037 cells, **349
+  differ and every difference is confined to the warning channels and `{ strict: true }`**: 0 cells
+  differ in the element tree, the `DeidentifyReport`, the de-identified bytes, which marker values
+  survive, or the root `(0010,0020)`; 0 new lenient fatals; leaking cells 11 -> 11; conformant tiling
+  controls 7 -> 7. **345 cells now report a collision that was silent on base** (295 Implicit VR LE,
+  25 Explicit VR LE, 25 Explicit VR BE), all of them in the grid's two hoist-collision families -
+  a fact about those fixtures, not a rate for real files. **9 cells that parsed under
+  `{ strict: true }` now throw** - element trees, reports, root identifiers and surviving markers
+  identical on both trees, taken from those per-field counters and **not** from the harness's
+  `...on an UNCHANGED lenient reading` line, which reads 0 by construction for any slice that adds a
+  code. A further **4** were already fatal there and now carry this code instead of
+  `INVALID_FILE_META`, because the escalation happens earlier in the parse. The shipped
+  `profiles.strict` preset is unchanged.
+
+  **Three more things a `{ strict: true }` caller should know, none of them fixed here.** (1) On the
+  one shape where the parse rolls a descent back - an Implicit VR LE defined-length `SQ` whose value
+  holds a duplicate and then a non-Item tag - `{ strict: true }` threw `DICOM_SQ_NOT_DESCENDED`
+  before and throws this code now, on a file where **nothing was destroyed**: both values survive in
+  `Element.rawBytes`. Both refuse the file, so no object is lost, but the older code was the more
+  accurate diagnosis. (2) The same shape streams the code to `onWarning` while `ds.warnings` never
+  receives it, which is the pre-existing D-03 ordering reached by one more code. (3) **"Names no tag"
+  is about the message.** Strict mode throws a `DicomParseError` whose `snippet` is 16 raw source
+  bytes at that offset, rendered as hex - measured on a plain duplicate:
+  `10 00 20 00 4c 4f 0e 00 53 4d 49 54 48 53 4f 4e`, the withheld tag plus eight bytes of the value.
+  That is the package-wide D-10 design. The same file does not throw at all on `0ead071` (this code is
+  what refuses it), but the same file with its even-length padding removed produces the identical 16
+  bytes there through `DICOM_ODD_LENGTH_VALUE_PADDED`, one length byte apart - which is why the
+  guarantee is worded about the message rather than about the channel.
+
+  **What the grid is NOT evidence for here, stated because it was read that way once.** It reaches
+  the collision only through a length lie, and it swept nothing that carries a tag twice honestly.
+  The plain duplicate, the duplicate inside an Item, the collision that lands on a sequence's own tag
+  and takes the whole `SQ` and everything nested in it out of the object, the frame the byte offset
+  is in, and the `{ strict: true }` behaviour are pinned in
+  `test/integration/tag-collision.test.ts` or nowhere: **14 of its 15 tests run red against
+  `origin/main` at `0ead071`** - re-measured after each gate pass added tests, and written with its sha
+  because the figure moves with every test added - the fifteenth being the no-duplicate
+  control, which is green there by design.
+
+  **Still open, and not touched here:** the private-`SQ` carve-out (`DICOM-PRIVATE-SQ-CARVE-OUT`),
+  and the structural relocation itself under `DICOM-EXPLICIT-VR-UNBOUNDED-ITEM-READ` - an
+  over-declaring Item still moves the element that follows the sequence. This slice makes the loss
+  observable; it does not make the file readable.
+
+- **🩺 The mirror of the above: a private value ejected OUT of a Sequence Item was retained on a
+  reservation it borrowed from the Data Set it landed in, in output stamped
+  `PatientIdentityRemoved = YES` with `report.removedPrivateTags` reading `[]`**
+  (`DICOM-ITEM-EJECT-ROUTE`). **`PRE-EXISTING`**, found by `#66`'s pass-2 `conformance-refuter`,
+  pinned by `#66` as residual tests that asserted the leaking behaviour, and re-measured on
+  `300af87` before anything changed. The **private-`SQ` carve-out** is still open (below). Read this
+  as "the eject direction is refused", never as "the class is closed".
+
+  **Measured on the published tarball, not inferred from a version number.**
+  `npm pack @cosyte/dicom@0.0.10` and the Explicit VR LE eject fixture:
+  `report.removedPrivateTags` is `[]`, `SECRET-PRIVATE-PHI` is in the serialized output,
+  `(0012,0062)` is `YES`, **`ds.warnings` is empty and `{ strict: true }` does not throw**. So on the
+  released package this route is silent on every channel, exactly as the item filed it.
+  **`0.0.9` is NOT on the registry** - `package.json` carried it, the publish never happened
+  (npm `E404`), and the current published version is `0.0.10`. Earlier entries in this file that say
+  "live on the published `0.0.9`" name a version that does not exist.
+
+  **On `main` it is no longer silent, and that difference is `#51` being unreleased.** With
+  `DICOM_ITEM_CROSSES_SEQUENCE_END` present, the Explicit VR shapes announce themselves on both
+  channels and throw under `{ strict: true }`; the Implicit VR LE shape raises the older
+  `DICOM_SQ_NOT_DESCENDED` and throws too. The leak was live beside those warnings, which is the
+  point: a warning about structure is not an all-clear about what was retained.
+
+  **The shape.** An `(FFFE,E000)` Item that declares **fewer** bytes than its content occupies ends
+  early, so the elements the sender encoded as Item content are read as elements of the **enclosing**
+  Data Set. A Private Creator that lands there reserves a `(gggg,00EE)` block for elements the sender
+  never put beside it, and the next private element is kept verbatim on it. **It is not
+  root-specific**: an inner sequence ejecting a creator into the still-usable Item that encloses it
+  reproduces the same leak one level down, and a root-scoped remedy would read green on it.
+
+  **Two predicates, because the parser records the same contradiction two different ways, and this is
+  why it is its own slice rather than a widening of the absorb rule.** Under **Explicit VR** the item
+  stream is bounded against the buffer, so it is read past the sequence's declared end and the span
+  shows up as `Element.rawBytes.length` exceeding `Element.length`. Under **Implicit VR LE** that path
+  slices the item stream to the declared Value Length, so **nothing over-runs at all**
+  (`rawBytes.length === length`); the item does not fit the slice, the descent is refused, and the
+  element carries `items === undefined` with `DICOM_SQ_NOT_DESCENDED`. Both are facts the parser had
+  already recorded: no re-parse, no scan, no cost that follows an attacker-chosen length. **The second
+  predicate is broader than the ejection it is here for, deliberately and in the fail-safe direction**
+  - it says the parser could not walk the sequence, which another unwalkable item stream also reaches.
+
+  **The remedy is positional, inside every Data Set, and it removes rather than downgrading the
+  stamp.** `settledBound` finds where a Data Set stops accounting for its own membership: the first
+  sequence whose own contents contradict its declared extent. Both the reservation map and the
+  retention decision are taken from the settled run, so a creator ejected into a Data Set reserves
+  nothing there and a private element read after that point is removed and named in
+  `report.removedPrivateTags`. An element read **before** the offending sequence cannot have come out
+  of it and is untouched. `processElements` derives this at every depth. **No parser file is touched
+  and no reading changes.**
+
+  **🛑 TWO BOUNDS, NOT ONE, BECAUSE A DATA SET IS A `Map<Tag, Element>`.** When the ejected element
+  carries a tag the Data Set **already holds**, `Map.set` overwrites in place and the newcomer
+  inherits the earlier element's **position**, ahead of the sequence it came out of. An index cut
+  alone reads it as settled and retains it: measured on a root holding a genuine
+  `(0009,0010)` + `(0009,1001)` reservation ahead of a sequence whose item ejects a second
+  `(0009,1001)`, which lands at index 2 with `byteOffset` 274 while the sequence sits at index 3 with
+  `byteOffset` 238. `Element.byteOffset` is the position the parser counted and the overwrite cannot
+  move it, so it is checked beside the index; the two are conjunctive because a hand-built
+  `Dataset` may carry no meaningful offsets at all, and there the index bound is what still
+  bites. **The grid is blind to this: the index-only and two-bound remedies differ on 0 of 83,037
+  cells**, because no `priv|` fixture collides tags. **3 tests, counted over the full suite, are the
+  whole pin**: the two collision rows and the creator-flip. Both offsets above are measured on the fixture pinned in `test/integration/deident-private-reservation.test.ts`, whose File Meta is the minimum **this parser** requires rather than PS3.10's - a fixture with more File Meta shifts every offset, and a pass-2 grade read 292 off one that did.
+
+  **🩺 AND THE COLLISION DESTROYS THE ROOT'S OWN VALUE ON THE WAY IN, WHICH THIS SLICE DOES NOT FIX.**
+  The overwrite replaces the reservation's genuine root element with the Item's, silently, at parse
+  time, with no warning naming it and no report entry - the `Map<Tag, Element>` substitution already
+  recorded for `(0010,0020)`, now reached on the private-retention path. `PRE-EXISTING`, identical on
+  both trees, **its own item**, and asserted in the tests so it cannot be mistaken for something this
+  remedy handled.
+
+  **The spec does the work, and both sentences were re-located in the pins rather than carried
+  forward.** PS3.5 2026c §7.8.1, one occurrence in `vendor/nema/part05/4dfd7b8c…`: "Items within a
+  sequence are self contained Data Sets ... The scope of the reservation is just within the Item.
+  Items do not inherit the Private Data Element reservations made by Private Creator Data Elements in
+  the Data Set in which the Item is nested." So the reservation's scope **is** the Item's boundary,
+  and a file that contradicts itself about where that boundary falls establishes no knowledge of which
+  Data Set an element is in. PS3.15 2026c §E.3.10, one occurrence in
+  `vendor/nema/part15/77d60b85…`: "Private Attributes that are known by the de-identifier to be safe
+  from identity leakage shall be retained, together with the Private Creator IDs that are required to
+  fully define the retained Private Attributes; all other Private Attributes shall be removed **or
+  processed in the element-specific manner recommended by Deidentification Action (0008,0307), if
+  present within Private Data Element Characteristics Sequence (0008,0300)**" - a two-branch clause,
+  quoted whole; this library does not implement `(0008,0307)`, so removal is the branch available to
+  it, and **"known"** is the load-bearing word.
+
+  **The price is measured, not asserted.** `scripts/measure-sq-bound-grid.ts` over **83,037** cells
+  against `300af87`: `priv: kept at ROOT, file CONTRADICTS` **78 -> 0**, of which the eject leaks
+  (`...whose honest control does NOT keep it`) are **22 -> 0** and the remaining **56 are the cost** -
+  root retentions on self-contradicting files whose honest control does keep the value. **That cost
+  has its own column and it is named rather than folded in: `de-identified OUTPUT lost a marker
+(cost)` reads 78**, which is the de-identify-boundary column; the `LOST` and `GAINED a marker value`
+  counters beside it are **parse**-tree columns and both read 0, and quoting those two without this
+  one is exactly the confusion this repo has paid for before. Retention on files that do **not**
+  contradict themselves is unchanged (**9 -> 9** at the root, **6 -> 6** inside an Item),
+  `no-creator` rows stay **0 -> 0**, `LEAKING a source value` is **11 -> 11** (the binary-carrier
+  residual, untouched), `conformant tiling control emptied` **7 -> 7**, and **0 cells differ in any
+  PARSE respect, 0 cells whose READING differs**, 0 new lenient fatals, 0 new strict fatals, 0 wrong
+  root `(0010,0020)`, 0 reports losing an attribute. **118 cells changed, every one of them in the
+  `priv|` family: 74 Implicit VR LE and 44 Explicit VR.** (`structural` also reads 118 by construction
+  - it counts any record difference, including the de-identify columns, so it is not a reading claim.)
+
+  **🛑 THE HARNESS COULD NOT REPORT THAT SPLIT AND NOW CAN.** `--diff` classified a cell's transfer
+  syntax by testing whether its key _starts with_ the syntax, which is true only of the sequence
+  sweep; the `carrier|`, `legit|` and `priv|` families put their own prefix in that position, so
+  **not one of their rows could ever be counted as Implicit VR LE**. This slice's 74 Implicit VR LE
+  cells were reported as `Implicit VR LE 0`. `transferSyntaxOf` fixes it, which also moves
+  `onWarning != ds.warnings, Explicit VR` from 43 to **0** - those 43 were Implicit VR LE rows in
+  other families, i.e. the pre-existing D-03 ordering residual, misattributed. **Any syntax split
+  quoted off that line for a slice touching those three families predates this fix; re-run the diff
+  rather than carrying the figure forward.**
+
+  **The whole-Data-Set variant was built and measured rather than argued about, and the grid cannot
+  tell it apart.** Refusing every private element in a Data Set that _contains_ a disputed sequence
+  produces a **byte-identical** grid diff (0 of 83,037 cells differ from what shipped), because every
+  `priv|` fixture writes its private block after the sequence. **It differs on exactly 5 tests,
+  counted over the full suite rather than one file**, and they are why it is not taken: it reds "a
+  root reservation the sender wrote at the root survives an over-running sequence" and both collision
+  tests, all three of which are genuine root reservations the sender wrote ahead of the disputed
+  sequence, and it also closes **both** private-`SQ` carve-out residuals, which belong to a different
+  item - the second of them in `test/integration/deident-unauditable-sequence.test.ts`, which a
+  per-file enumeration misses. **The tests are the pin for the positional cut, not the grid.**
+
+  **What is NOT closed, and is not asserted away.** The **private-`SQ` carve-out**: `keepsPrivate`
+  decides before `descendSequence`, so a private `SQ` inside the settled run that the profile vouches
+  for is kept **verbatim** and nothing inside it is examined. `PRE-EXISTING`, still pinned as a
+  residual test that asserts the leaking behaviour. And the `Map<Tag, Element>` substitution above.
+
+  **The base measurement, taken fresh rather than carried forward:** **8 of the 37** tests in
+  `test/integration/deident-private-reservation.test.ts` run red against `origin/main`'s `src/` at
+  `300af87`, and they are exactly the eight eject tests. The remaining private-`SQ` residual is
+  **green** on that base, by design. **The "10 of the 31" figure and the "both residual tests are red
+  against base" correction beside it are both retired**: the first was measured against a pre-`#66`
+  tree, and the second is false against today's `main`, because `DICOM_ITEM_CROSSES_SEQUENCE_END` has
+  been on `main` since `79e9f34`.
+
+  **No new public surface, deliberately** - no Tier-2 code, no report field, no snapshot change, the
+  same choice `#66` made. `report.removedPrivateTags` already names every removed tag and is the
+  channel this defect read `[]` on.
+
+- **🩺 A private value crossed the PS3.5 §7.8.1 reservation boundary and was retained under
+  `RetainSafePrivate`, in output stamped `PatientIdentityRemoved = YES`.** The **absorb** direction
+  is closed; the **eject** direction and the private-`SQ` carve-out were measured, pinned and **not**
+  closed by this entry. (The **eject** direction has since been closed by `DICOM-ITEM-EJECT-ROUTE`,
+  the entry above; the private-`SQ` carve-out is still open.)
+  (`DICOM-PRIVATE-CREATOR-RESERVATION-LEAK`). **`PRE-EXISTING`**; found by `#51`'s pass-6
+  `conformance-refuter` and measured **identical on `origin/main`**, so it was never introduced by
+  that branch. (This entry said "live on the published `0.0.9`". **`0.0.9` was never published** -
+  `package.json` carried it and the publish never happened, npm `E404`. The leak is measured on the
+  published `0.0.10` tarball.)
+
+  **The shape.** An `(FFFE,E000)` Item that declares more bytes than its enclosing `SQ` element's
+  Value Length allows reads past the end of its sequence and absorbs the element that followed it.
+  With a Private Creator in the Item's genuine content and the private data element written at the
+  **root** - where no creator reserved its block, so the Basic Profile removes it - the absorbed
+  element lands beside that creator and is kept verbatim. Measured on `164eb39`, Explicit VR LE and
+  BE, `deidentify(ds, { retain: ["RetainSafePrivate"], profile: profiles.ge })`:
+  `report.removedPrivateTags` is `[]`, `SECRET-PRIVATE-PHI` is in the serialized output,
+  `(0012,0062)` is `YES`, and **the file parses with no warning on either channel**. A stamp that
+  outruns the redaction is the worst shape this class has, because a consumer trusting it has no
+  signal at all.
+
+  **The remedy is at the de-identify boundary and it removes; it does not downgrade the stamp.**
+  PS3.5 2026c §7.8.1, read from the vendored pin (`4dfd7b8c…`), one occurrence in the document:
+  "Items within a sequence are self contained Data Sets ..., any Item in the sequence that contains
+  Private Data Elements shall also have Private Creator Data Element reserving a block of Elements
+  for those Private Data Elements. The scope of the reservation is just within the Item. Items do
+  not inherit the Private Data Element reservations made by Private Creator Data Elements in the
+  Data Set in which the Item is nested." The reservation's scope **is** the Item's boundary, so a
+  file that contradicts itself about where the Item ends does not determine which reservation
+  covers an element. PS3.15 2026c §E.3.10 "Retain Safe Private Option": "Private Attributes that
+  are known by the de-identifier to be safe from identity leakage shall be retained, together with
+  the Private Creator IDs that are required to fully define the retained Private Attributes; all
+  other Private Attributes shall be removed **or processed in the element-specific manner recommended by Deidentification Action (0008,0307), if present within Private Data Element Characteristics Sequence (0008,0300)**". **The clause licenses two dispositions and the
+  first draft of this entry closed the quote at "removed"**, reading a permissive clause as an
+  absolute; this library does not implement `(0008,0307)`, so removal is the branch available to it.
+  Nothing there is _known_, so the standard's own
+  default applies. Every private element **the recursion reaches** in such an Item, and at every
+  depth below it, is removed and named in `report.removedPrivateTags` - **with one carve-out, stated
+  in the sentence rather than only in a later paragraph**: a private `SQ` the profile vouches for is
+  settled before the descent and is kept verbatim (see below).
+  **The unit is the SEQUENCE, not the individual Item**: `descendSequence` decides once and
+  applies it to every item, so a two-item sequence where only item 1 over-runs also loses a genuine
+  block in the honest item 0 (measured and pinned; the grid sweeps single-item fixtures, so that
+  extra cost is NOT inside the priced 20).
+  **The unit is the SEQUENCE, not the individual Item**: `descendSequence` decides once and
+  applies it to every item, so a two-item sequence where only item 1 over-runs also loses a genuine
+  block in the honest item 0 (measured and pinned; the grid sweeps single-item fixtures, so that
+  extra cost is NOT inside the priced 20).
+
+  **It is NOT a parser bound, and no reading changes.** An over-declaring Item and an
+  under-declaring Sequence are byte-identical - `#51` reached that conclusion three times and its
+  refuter could build no predicate separating them. `scripts/measure-sq-bound-grid.ts` over
+  **83,037 cells** against `164eb39`: **0 cells differ in any PARSE respect**, **0 cells whose
+  READING differs** (a new counter; the existing parse-respect count folds both warning channels
+  in), 0 new lenient fatals, 0 new strict fatals, 0 markers lost or gained from the parsed object,
+  0 wrong root `(0010,0020)`, 0 reports that lose an attribute, and **0 Implicit VR LE cells
+  changed** - a free control, because that path slices the item stream so no Item can over-run.
+
+  **The fail-safe-direction argument `#51` made in five artifacts is RETRACTED, not reworded.** The
+  direction is not a property of the two readings; it is a property of **where the sender put the
+  Private Creator relative to the disputed bytes**. Both **absorb** placements are pinned by tests
+  and both are refused now: the creator inside the Item with the data element absorbed in, and the
+  data element inside the Item with the creator absorbed in. The **eject** placement is pinned as a
+  residual and is not refused.
+
+  **The price, measured rather than asserted.** The grid gained a `priv|` family - the first
+  population in that harness that runs `RetainSafePrivate` at all, which is why three earlier
+  refuter passes read "0 PHI regressions" off it while this was live. **58 -> 0** cells keep a
+  private value inside an Item on a self-contradicting file, and **20 of those 58 were not leaking
+  anything**: the creator and the data element were both genuine Item content and the reservation
+  was real. They pay for the guarantee, because nothing on the wire distinguishes them. Retention on
+  a file whose length fields agree is **unchanged** - 6 -> 6 inside an Item, **9 -> 9** at the root -
+  and 0 -> 0 rows are kept with no creator in scope, on either tree.
+
+  **🩺 Two routes are NOT closed, found by the pass-1 `conformance-refuter` grade.** Both are
+  `PRE-EXISTING`, reproduce identically on `164eb39`, and both produce the same false attestation
+  (`removedPrivateTags: []`, the value in the output, `(0012,0062) = YES`).
+  **(a) The eject direction.** An Item that _under_-declares pushes its trailing elements **out**
+  into the enclosing Data Set, which is not narrowed, so a Private Creator that lands there reserves
+  a block for elements the sender never gave it. **It is NOT root-specific and an earlier draft of
+  this entry said it was** - pass 2 reproduced it one level down, where an inner sequence ejects a
+  creator into the still-usable enclosing Item. The item filed for this must be scoped to every
+  still-usable Data Set or it will be built to the wrong bar. **It was silent on every channel and
+  under `{ strict: true }` when this shipped, and `DICOM-EXPLICIT-VR-UNBOUNDED-ITEM-READ` changed
+  that on the Explicit VR shapes and nowhere else, so do not carry the old sentence forward.**
+  Re-measured on this residual's own fixture: `DICOM_ITEM_CROSSES_SEQUENCE_END` on both channels and
+  a throw under `{ strict: true }`, beside an entirely unchanged leak (`removedPrivateTags: []`, the
+  value in the serialized output, `(0012,0062) = YES`). That warning is now the only signal on a file
+  whose de-identification audit is false, and it is never an all-clear. The 20 Implicit VR LE cells
+  stay silent: that path slices the item stream, so no over-run is recorded. **22 grid cells.** The widening was **built
+  and measured**: narrowing the flag whenever a Data Set _contains_ an over-running sequence costs
+  **24** root retentions and closes **2** of the 22, because the other 20 are Implicit VR LE where
+  the sequence records no over-run at all. A different mechanism, and its own item.
+  **(b) The private-`SQ` carve-out.** `keepsPrivate` decides **before** the descent, so a private
+  `SQ` the profile vouches for is kept **verbatim** and this rule is never consulted inside it. The
+  first draft of this entry said "every private element in such an Item ... is removed",
+  unconditionally, which is `#54`'s exact refusal repeated; the sentence is corrected rather than the
+  guard widened. Both routes are pinned as **residual tests that assert the leaking behaviour**, so
+  they go red when fixed.
+
+  **No new public surface**: no new warning code, no new report field, no snapshot change. The
+  action is already visible on `report.removedPrivateTags`, the channel this defect read `[]` on.
+  What is _not_ on any channel is the reason - a caller sees which private tags went, not that the
+  file contradicted itself. Disclosed rather than closed, because a new Tier-2 code would also have
+  to answer to `profiles.strict` escalation and to the per-element amplification bound `#48`
+  established.
+
+- **An unrecognized Explicit VR was read short-form, contrary to PS3.5 2026c §6.2's normative
+  "shall"** (`DICOM-UNRECOGNIZED-VR-SHORT-FORM`). It is now read - and written - long-form. **This
+  is a behaviour change on the read path**, and the trade is measured below rather than asserted.
+
+  **The clause, read from the vendored `vendor/nema/part05` pin (`4dfd7b8c…`), one occurrence in the
+  document.** §6.2 "Value Representation (VR)": "All new VRs defined in future versions of DICOM
+  **shall** be of the same Data Element Structure as defined in [§7.1.2] with reserved bytes after
+  the VR and a 32-bit unsigned integer VL (i.e., following the format for VRs such as OB or UT), and
+  may or may not permit Undefined Length." §6.2's **note** about an implementation choosing to
+  ignore unrecognized VRs is informative, and is deliberately not what this rests on.
+
+  **What a conformant future-VR file used to do: no sentence, deliberately.** Four attempts have
+  now been made to summarize that in one sentence and all four were wrong, the fourth by the first
+  draft of this entry. It is **shape-specific**: the short-form read took the carrier's length from
+  the two bytes §7.1.2 reserves (`0x0000`), got a zero-length value, and resumed inside the 32-bit
+  VL field - so what happened next depended on the payload's own bytes. Sometimes a whole-object
+  `INVALID_FILE_META`; sometimes a **clean parse into a tree the sender did not write**, with a
+  zero-length carrier plus an element manufactured out of the payload and, under Explicit VR BE,
+  **no warning on either channel**. `scripts/measure-unrecognized-vr.ts` is new here and prints the
+  per-shape table for both trees, including that case (`long-payload-tiles`). **Add a shape rather
+  than writing a summary.**
+
+  **What changed, and what deliberately did not.** `readExplicitElementHeader` and the File Meta
+  element reader take the 12-byte header for any VR outside the 34 this edition defines;
+  `serializeDicom` writes one. Everything after the header read is untouched - the same value read,
+  the same "declared length exceeds the remaining buffer" refusal, and the same undefined-length
+  refusal that `OB` / `UT` / `UN` already take. **This is one more VR class routed into an existing
+  bound, not a new bound**, which is the distinction four refusals in this family were about. No new
+  warning code was minted: a §6.2-conformant file is not something to warn about, and a new Tier-2
+  code would throw under `{ strict: true }` on exactly such a file.
+
+  **The reader and the writer had to move in one commit.** The short form's length field is 16 bits.
+  With the reader fixed alone, a 70,000-byte unrecognized-VR value would have been re-emitted
+  declaring **4,464**, silently. Pinned by a round-trip test at that size.
+
+  **The trade, on `scripts/measure-sq-bound-grid.ts` against `66f0c95` (76,611 cells).**
+  **1,221 recovered** (fatal before, parse now) against **932 newly refused**; 0 PHI regressions;
+  0 cells where the root `(0010,0020)` changes value; 0 reports that lose an attribute on a cell
+  that still parses; **0 Implicit VR LE cells changed at all** (a free control - there is no on-wire
+  VR there); leaking cells unmoved at 11 (`DICOM-BINARY-CARRIER-OVERDECLARE`, untouched here).
+  **All 932** of the newly refused had an unrecognized VR in their `66f0c95` parse tree, so every
+  file this refuses is one the old reader only "read" by manufacturing a Data Element header out of
+  the middle of somebody's value; the fabricated VRs across that population include `"CT"` - a
+  Modality value read as a VR.
+  The grid also reads **0 cells that parse on both trees and read differently**. Read that as a
+  statement about the grid's fixtures, **not** as "nothing is silently re-read": the
+  `long-payload-tiles` shape is exactly such a cell and it is outside anything the grid sweeps.
+  **The mirror shape is the honest cost**: a sender that ignores §6.2 and writes an unrecognized VR
+  in the 8-byte short form produced a readable object before and is refused now. That is pinned by a
+  test rather than left to be discovered.
+
+  **`deidentify()` is unchanged, and one of its claims was not.** The rule that empties an element
+  whose VR is not one of the 34 still fires - reading a header is not the same as knowing what its
+  value means, and Table E.1-1 acts per attribute. **Disclosed, not fixed**: it is the same
+  over-redaction trade the un-auditable-sequence rule makes, and re-deciding it is a product call.
+
+  **`#55` published "on a file conformant to PS3.5 2026c the cost is zero". It was never true**, and
+  no replacement account of the old reader belongs here: three were written while this entry was
+  drafted and the gate refuted all three. The harness prints what each shape does on each tree, and
+  the shape that refutes the shortest version of the story is a row in it
+  (`long-payload-tiles-future-vr`). **Add a shape rather than a sentence.**
+
+  **`DICOM_NONZERO_RESERVED_BYTES` no longer names a tag, and that is a PHI fix this slice owed.**
+  Reading an unrecognized VR long-form means landing on the two bytes §7.1.2 reserves, so this code
+  is newly reachable on a **fabricated** header - one built out of the middle of somebody's value.
+  Its message interpolated the four bytes it would call a tag: measured on an `ST` carrier holding
+  `"MR BRAIN  SMITHSON"` under-declared by 6, it streamed `Element (54495348) …` - the bytes
+  `"ITHS"` in wire order, four letters of the surname - where `66f0c95` emitted nothing naming that
+  element on the same file (its only warning there is `DICOM_ODD_LENGTH_VALUE_PADDED`, on a genuine
+  `(0010,0010)`). (Quote the payload **with** its tag: `"MR BRAIN SMITHSON "` produces `48544F53`
+  instead, and an earlier draft of this entry paired the two wrongly.) **The factory now takes no
+  tag parameter**, so the bound is the signature rather than a branch, and `position.byteOffset`
+  locates the element. This is exactly the remedy `#55` paid a blocker for in
+  `report.undefinedVrElements[].tag`, and the reason is the same: where the trigger is "these bytes
+  are not what they claim to be", `renderTag` checks shape and cannot refuse them. It also closes a
+  `PRE-EXISTING` instance on the same factory - a long-form VR fabricated the same way rendered its
+  tag on `66f0c95` too. Pinned with a name-bearing fixture and a non-vacuity assertion that the code
+  really fires.
+
+  **A second `DeidentifyReport` claim corrected rather than widened.** The report was described as
+  "value-free apart from `uidMap`". `removedPrivateTags` is a second exception: its entries are four
+  source bytes each, and on a malformed file those bytes can be document content. Measured
+  identically on **both** trees - an `OB` carrier holding `"SECRET-NOTE-"` followed by a well-formed
+  odd-group header reports `["41534342"]`, whose wire-order bytes read `"SABC"`. Reporting the tag
+  is the whole audit value of the field on a well-formed file, so it is documented as PHI rather
+  than withheld; narrowing it is a product decision that has not been made.
+
+- **A test asserted the machine it ran on rather than the code, and the script suites paid a
+  process start they did not need** (`PARSER-TESTTIMEOUT-ASSERTS-AN-IDLE-BOX`). This is a trim plus
+  two deletions and nothing else. Test and test-configuration only: no source, parser, de-identify,
+  serializer or public API change, and no number in this package moves.
+
+  **The trim.** Three suites spawned this repository's own TypeScript scripts through `tsx`. Node
+  strips types natively, so that process start bought nothing and was paid on every invocation.
+  They now go through `test/helpers/run-script.ts`, which runs them under `node`, measured with
+  byte-identical stdout and the same exit code from both runners. The suites are measurably faster;
+  no ratio is quoted here, because independent re-takes on one box do not agree with each other and
+  the gap moves with the workload as well as the box.
+
+  **The one script that cannot make that move, pinned rather than asserted.**
+  `scripts/generate-annex-e.ts` imports `"../src/dictionary/repeating-groups.js"`, and Node's ESM
+  resolver will not rewrite that `.js` specifier onto the `.ts` file; under `node` it exits 1 with
+  `ERR_MODULE_NOT_FOUND` at module resolution, before it opens a byte of DocBook or touches the
+  tracked `SHA.txt` this suite otherwise rewrites. It stays on `tsx`, and a new test asserts that
+  failure **by name**, so the carve-out goes red the day Node can resolve the specifier rather than
+  quietly outliving its reason. The rule and its single exception are stated once, in
+  `run-script.ts`, rather than copied into each suite: the sibling generator imports nothing from
+  `src/` and was measured green under `node` with byte-identical output, so the carve-out is one
+  script and not "the generators".
+
+  **Deletion one: a stopwatch that was already a false red.** `embedded-attribute.test.ts` carried
+  `expect(performance.now() - started).toBeLessThan(2_000)` over a 512 KiB value. It reads a couple
+  of hundred milliseconds on a quiet box, but on an ordinary loaded one it was measured at or over
+  that literal with the algorithm untouched. It was also the weakest cost claim in this package: its
+  fixture is half a megabyte of `0x41`, which yields zero tiling candidates, so every offset
+  short-circuits before the repertoire scan where the quadratic it named lived and the number it
+  produced was never a measurement of that cost. Deleted, and the test renamed to what it does
+  assert. The cost is still bounded, by `vitest.config.ts`'s per-test
+  timeout, which is the mechanism built for it.
+
+  **Deletion two: `hookTimeout: 10_000`, a verbatim no-op.** Measured rather than read: a `beforeAll`
+  that sleeps past it reds at "Hook timed out in 10000ms" on this repository's own Vitest with no
+  configuration at all, so the line restated the default exactly and said nothing. The one hook that
+  needs more (`docs-content.test.ts`, which shells out to `pnpm build`) already passes its own budget
+  at the call site.
+
+  **`testTimeout: 10_000` is UNCHANGED.**
+
+  **Disclosed residual, not fixed here.** The two `test/property/` fast-check suites can exceed that
+  10,000 ms global on a contended box, which reds them with the parser untouched. A per-test budget
+  for them was built and then **withdrawn**: the measurements offered for it did not survive
+  re-measurement, and the correct figures do not support the claim they were used to make. Those
+  suites therefore remain on the 10,000 ms global - **exactly where `main` is today** - so this
+  change neither fixes nor worsens that. It is a live false red and it needs its own slice, measured
+  from scratch.
+
 - **The `attw` publish gate exited 0 on a tarball carrying no type declarations, so a broken publish
   read as a pass** (`ATTW-FALSE-GREEN-PORT`). `pnpm attw` now runs `scripts/attw.mjs`, ported from
   `@cosyte/terminology` (#28, `bf153cb`), where the defect was diagnosed; `typecheck:exports` runs
@@ -92,6 +711,134 @@ All notable changes to `@cosyte/dicom` will be documented in this file. The form
 
 ### Security
 
+- **A Sequence Item under an Explicit VR transfer syntax can read past the end its own sequence
+  declared and swallow the element that followed the sequence, and did so silently. It now says so**
+  (`DICOM-EXPLICIT-VR-UNBOUNDED-ITEM-READ`, pre-existing and live on the published `0.0.10`, on both
+  Explicit VR Little Endian and Explicit VR Big Endian). New Tier-2 code
+  `DICOM_ITEM_CROSSES_SEQUENCE_END` (`WARNING_CODES` is **29, was 28**; the locked snapshot is the
+  pin and was updated deliberately), promoted to a throw under the `{ strict: true }` parse option.
+  **No reading changes, on any file.** That is the fix's whole shape, and the next paragraph is why.
+
+  **THE FACT THAT DECIDED THIS, AND IT IS PROVEN BY A TEST RATHER THAN ARGUED.** A file whose
+  **item over-declares** and a file whose **sequence under-declares** are **the same bytes**.
+  `test/integration/explicit-sq-item-bound.test.ts` builds both from two contradictory intentions and
+  asserts `Buffer.equals`. So "which of the two length fields is the lie?" has no answer on the wire,
+  and any bound that prefers section 7.5.2's extent for the first file imposes it on the second one
+  too, because there is no second file. **Five graded attempts at such a bound were refused on
+  `#51`.** This slice adds no bound, and that one fact is the entire reason.
+
+  **🛑 THE FAIL-SAFE-DIRECTION ARGUMENT IS DELETED, NOT REWORDED.** Five artifacts on this branch
+  said that following the Item's length field is the safe half of the ambiguity, because a Private
+  Creator swallowed **into** an item leaves the enclosing block unclaimed and an unclaimed block is
+  removed. **That is false, and it was the sixth refusal.** Which direction leaks is a property of
+  **where the sender put the Private Creator**, not of which length field a reader follows: with the
+  creator as genuine Item content, the absorb direction leaks too
+  (`DICOM-PRIVATE-CREATOR-RESERVATION-LEAK`, measured on `164eb39`, closed at the de-identify
+  boundary by `#66` and never in the parser). The eject direction is still open. Neither reading is
+  safe by construction, which is precisely why this code reports rather than decides. Per this
+  repo's own rule, a claim refuted twice is deleted rather than given a third wording.
+
+  Measured, on `0.0.10`: `(0008,1115)` holding one item that over-declares its length by 18 bytes,
+  followed by a root `(0010,0020)` Patient ID that is 18 bytes on the wire (an 8-byte Explicit VR
+  short-form header plus a 9-character value padded to 10). The Patient ID is **absent from the root**
+  and present instead as an attribute of the item; the `DeidentifyReport` names it with a
+  `contextPath` pointing at a sequence item it was never in. It is swallowed once and relocated, not
+  read twice: the parser resumes where the descent actually ended. The parse was silent about all of
+  it, including under `{ strict: true }`, and that silence is what is fixed. The mis-structure itself
+  is **not repaired here** and is pinned as a residual by a test.
+
+  **▶ AND IT IS THE ONLY SIGNAL ON A FILE WHOSE DE-IDENTIFICATION AUDIT IS FALSE.** `#66` recorded
+  the eject direction of `DICOM-PRIVATE-CREATOR-RESERVATION-LEAK` as silent on every channel. On the
+  **Explicit VR** shapes that is no longer true: re-measured on that residual's own fixture, this
+  code fires on both channels and throws under `{ strict: true }`, beside an unchanged leak
+  (`report.removedPrivateTags` `[]`, the private value in the serialized output, the object stamped
+  `(0012,0062) Patient Identity Removed = YES`). The leak is not closed here and the warning is not
+  an all-clear - **the troubleshooting row says so explicitly**, because the earlier draft of that
+  row told an operator "nothing is retained that would not be", which is false on exactly this file.
+  Implicit VR LE stays silent: that path slices the item stream, so no over-run is recorded.
+
+  PS3.5 2026c section **7.5.2** "Delimitation of The Sequence of Items" makes the `SQ` element's own
+  Value Length the exact extent of the item stream: "This length shall include the total length
+  resulting from the sequence of zero or more items conveyed by this Data Element." Section **7.5.1**
+  "Item Encoding Rules" governs each `(FFFE,E000)` Item's own length field. Both traced to the
+  SHA-pinned `vendor/nema/part05/`, each sentence unique in the document. **Neither clause says what
+  a decoder does when the two disagree**, so no reading is derived from them; where they disagree
+  this reader follows 7.5.1, which is what every released version does.
+
+  **Where the disclosure fires, exactly.** A defined-length `(FFFE,E000)` item, inside a
+  defined-length `SQ`, whose declared end is **not** the end of the buffer it is being read in -
+  which is what says the sequence sits inside a larger Data Set whose bytes are there to be taken.
+  A sequence handed a slice cut at its declared end (Implicit VR LE's `tryParseDefinedLengthSQ`,
+  CP-246's `tryParseUnAsSQ`), an undefined-length sequence, an undefined-length item, and a sequence
+  that ends its own buffer all have nothing to reach into and stay silent. Each is a test.
+
+  **🩺 The Item's declared length is WITHHELD from the message, and the bound is the factory
+  signature.** A diagnostic about a length field that lies is itself a PHI surface: the condition
+  that raises this code is exactly "these length fields are not what they claim to be", so the Item's
+  32-bit Value Length can be four bytes of somebody's value. Measured, an item header fabricated over
+  the payload `"SMITHSON"` rendered it as `1414090067`, `"SMIT"` in wire order, reversible with one
+  `readUInt32LE` - and it is emitted **above** the truncation guard, so the message reaches
+  `onWarning` on a file the parse then refuses. `itemCrossesSequenceEnd` takes no parameter for it,
+  the same remedy `#64` applied to `DICOM_NONZERO_RESERVED_BYTES` and `#55` to
+  `DICOM_DEIDENT_UNDEFINED_VR_NOT_AUDITABLE`; `position.byteOffset` locates the item. The bytes that
+  remained inside the sequence are still reported, and that asymmetry is structural rather than a
+  judgement call: the emit site's own `endLimit < buffer.length` conjunct bounds that count by the
+  buffer. Measured against the identical attack - fabricating the **`SQ`**'s length field over the
+  same name puts `endLimit` past the buffer, so the code does not fire at all. Both pinned with a
+  name-bearing payload and a mutation control; the shipped message said "no bytes off the wire", then
+  carried the length itself, and both are gone.
+
+  **The measurement, on `scripts/measure-sq-bound-grid.ts` against `2f0abd9`, 83,037 cells.** Both
+  sequence length fields and an element's own swept independently, across ten item shapes, both
+  Explicit VR syntaxes, an Implicit VR LE control, both `strict` postures, and `#66`'s `priv|`
+  private-reservation family:
+
+  |                                                            |                           |
+  | ---------------------------------------------------------- | ------------------------- |
+  | cells whose **reading** differs                            | **0**                     |
+  | cells newly emitting `DICOM_ITEM_CROSSES_SEQUENCE_END`     | 616                       |
+  | ...cells that LOSE it                                      | **0**                     |
+  | cells that newly fail under `{ strict: true }` (the price) | **576**                   |
+  | new lenient fatals                                         | **0**                     |
+  | values lost, values gained, wrong root `(0010,0020)`       | **0 / 0 / 0**             |
+  | PHI regressions                                            | **0**                     |
+  | reports that lose an attribute                             | **0**                     |
+  | Implicit VR LE cells changed                               | **0**                     |
+  | every `priv\|` column from `#66`                           | unchanged                 |
+  | cells leaking a source value, base -> now                  | 11 -> 11 (`PRE-EXISTING`) |
+
+  The other **16,396** of the 17,012 differing cells are **strict-fatal on both trees** and differ
+  only in the _class_ of the `{ strict: true }` throw, because the new Tier-2 code escalates before
+  the Tier-3 fatal those files already had. All 576 new strict fatals carry the new code, so none is
+  collateral. **Quote the reading count and the strict count together or neither** - a new warning is
+  a real behaviour change, and 576 files that parsed under `{ strict: true }` now do not. Every one
+  is a file whose two normative length fields contradict each other, which is what the strict posture
+  exists to refuse; the lenient reading of all 576 is byte-identical to before. `cells whose READING
+differs` is the counter that expresses this and it already exists on `main` (`#66` added it); the
+  earlier draft of this entry claimed to add it.
+
+  **Disclosed and NOT fixed, deliberately:**
+  - **The mis-structure.** An over-declaring item still relocates the element that follows the
+    sequence, and `deidentify()` still reports it under a `contextPath` naming an item it was never
+    in. Pinned by a test so the claim cannot drift from the code.
+  - **`ds.warnings` is uncapped, and "at most one per sequence" is not an amplification bound.** The
+    shape holds, but a file may carry as many sequences as it can encode. Pinned by a test that
+    asserts the growth. This is `#48`'s pre-existing, package-wide posture for parser warnings.
+  - **`profiles.strict` does not escalate this code.** The `{ strict: true }` option does. Adding a
+    code to a shipped preset moves every `profiles.strict` consumer's parse and is its own measured
+    change. Pinned by a test.
+  - **`position.byteOffset` is frame-dependent**, like `Element.byteOffset`: file-absolute for a
+    root-level sequence, slice-relative inside an enclosing item. Measured and pinned.
+  - **The undefined-length item with no `(FFFE,E00D)`** still runs to the end of the buffer. There is
+    no declared item length, so there is no disagreement to disclose.
+  - **`Element.byteOffset` inside a sequence item disagrees with itself between the two item forms,
+    and always has.** Measured identically on this branch and on `origin/main`: on a 210-byte file
+    with the `SQ` at 172, an element inside a **defined-length** item reads `0` (the item slice is its
+    own frame) and the same element inside an **undefined-length** item reads `192` (file-absolute,
+    because `parseSequence` hands that branch the outer buffer). `PRE-EXISTING`.
+  - **11 grid cells still leak a source value** - the over-declare swallow into an `OB`/`OW`/`US`/`UN`
+    leaf carrier, `PRE-EXISTING`, identical on both trees, its own item.
+
 - **A symbolic link under `test/fixtures/` pointing at a PHI-bearing file scanned CLEAN on BOTH of
   `scripts/phi-scan.ts`'s enumerating routes, so the commit gate passed it twice over**
   (`PHI-SCAN-SYMLINK-BLIND-ON-BOTH-ROUTES`; pre-existing). Reproduced on `0f898be` with a synthetic