edfcore 0.4.512 → 0.4.515

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.4.512";
+export declare const VERSION = "0.4.515";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.512';
+export const VERSION = '0.4.515';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,65 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.4.515
+
+- **Added** the thirteen pairs behind one sentence on `cli.md`: "Each is accepted and ignored by
+  the commands it does not name." It is the only claim on the page about pairs rather than about a
+  command, it is what lets a wrapper pass one fixed flag set to every command instead of branching,
+  and nothing checked it.
+- The two halves rot differently. "Accepted" fails loudly — `parseArgs` refuses an unknown flag, so
+  a flag dropped from the parser exits 2. "Ignored" fails silently, and in the worst direction:
+  `--patient` gates identification, so a flag that started reaching `events`, `signals` or `gaps`
+  would print the identification a caller passed it to withhold. Each pair now runs the command
+  twice and compares the bytes, having first asserted the command printed something — two empty
+  outputs are equal.
+- The last clause is the same test in the same shape: the counted `events` listing is never capped,
+  so `--limit 1` must return it unchanged, while `events --list --limit 1` must not. A cap on a
+  census truncates it into something that reads as complete.
+- Which commands each flag names is read out of the page's own "Flags:" paragraph, not written in
+  the test, so a flag that gains or loses a command in the prose changes what is checked. The
+  paragraph needs splitting at each flag to read: only two of the three carry a parenthesised list,
+  and one pattern across the whole paragraph reads the third one's list as the second one's.
+
+## 0.4.514
+
+- **Added** a check of what is in the six columns `edfcore signals` prints. `cli.md` tabulates them
+  by name and position and ends the sixth row with the instruction the command exists for — "the
+  authoritative count; index by this, never by the rate" — and the only test was that there are six
+  columns and one line per signal, which six columns of anything satisfy.
+- That is the defect the page records against itself. Until 0.2.42 it described a column list the
+  command did not emit: samples per record where the command printed `kind`, and the authoritative
+  field in no column at all. A count of six would not have caught it then either. The order is now
+  read out of the page's table rather than written in the test, so the two cannot drift apart.
+- The fixture gives its two data signals different sample counts and different units, so 4 Hz, 1.5
+  Hz, 8 and 3 are all distinct — no pair of columns can be swapped and still match.
+- The three qualified rows are checked as qualified. `sampleRateHz` is empty on a legal zero record
+  duration, where `undefined`, `0` and `NaN` would each be a number a script divides by. `label`
+  and `physicalDimension` are both called trimmed, and are trimmed by different things: the parser
+  strips EDF padding from both, the command adds `String.trim` to the dimension — which reaches a
+  tab — and passes the label through `printable`, which turns a tab into `.`. Removing either
+  fails now; before this, removing the first put a tab in the dimension and removing the second put
+  a seventh column in the row, handing `cut -f6` a unit where it expected a sample count.
+
+## 0.4.513
+
+- **Added** a bounds check on the evidence a diagnostic points at: the byte range is inside the
+  file, the signal index names a signal, and the record index is inside the records that were
+  read. 0.4.510 checks that `raw` matches the bytes at the offset, which settles the offset for
+  every diagnostic carrying text to compare. `PARTIAL_FINAL_RECORD` and `TRAILING_BYTES` carry
+  none — they point at samples, and quoting samples as text says nothing — so nothing reached
+  their offsets at all beyond three hand-picked sizes.
+- An offset past the end of the file is not a crash. `subarray` clamps, so an evidence block
+  renders short or empty and the reader concludes the bytes were empty. Both codes are now checked
+  across a range of truncations and appends, including one byte and one byte short of a whole
+  record, and both are asserted to end exactly at the end of the file — which is what "the rest of
+  the file after the last whole record" means.
+- The TAL side is read from record 2 rather than record 0. A TAL diagnostic reports
+  `records.start + position` while its buffer offset uses `position` alone, and on a read starting
+  at record 0 those are the same number — which is what almost every fixture does, so the one
+  arithmetic that can confuse a file position with a buffer position was exercised only where the
+  two agree.
+
 ## 0.4.512
 
 - **Added** a read behind each of the four header-recovery diagnostics. When the header's numbers

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.512",
+  "version": "0.4.515",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.512';
+export const VERSION = '0.4.515';