edfcore 0.4.490 → 0.4.492

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.490";
+export declare const VERSION = "0.4.492";
 //# 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.490';
+export const VERSION = '0.4.492';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,40 @@ 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.492
+
+- **Added** a test that runs the worked example on `reading-signals.md`. That page carries the
+  argument the whole indexing design exists for — `trimToWindow` compares integers taken from the
+  header as written, never `round(t * sampleRateHz)` — and it makes the case with six concrete
+  numbers and a footnote counting how often the two disagree. Nothing ran any of them.
+  `documented-examples.test-d.ts` compiles the snippets, which proves they are valid TypeScript
+  and says nothing about whether 8534 is the answer.
+- Numbers in prose rot in a direction that is hard to see. A value that was right when it was
+  written stays plausible for ever, because a reader checks it against their intuition rather than
+  against the library — and this page exists to correct an intuition. The footnote is the extreme
+  case: "1,000 of the first 3,001, always by exactly one sample" is a claim nobody can check by
+  reading, and the argument leans on it.
+- Every figure is read OUT OF THE PAGE and compared with what the library does, the way
+  `scaling-page-arithmetic.test.ts` reads the count it checks, so neither side can drift from the
+  other. All of them hold, footnote included: 1,000 disagreements over 3,001 second boundaries,
+  every one of them exactly one sample, and the float answer earlier every time.
+- Restoring the pre-0.3.56 rounding — the defect the code's own comment records — now fails this
+  file rather than only the unit tests written for it.
+
+## 0.4.491
+
+- **Added** the `maxMaterializeBytes` boundary for `toPhysical` and `clampToDigitalRange` — the
+  fifth module that compares a requirement against that budget, and the last one still untested at
+  the edge.
+- Finding them one at a time is the thing that kept going wrong. 0.4.464 covered three, found by
+  grepping for `resolveMaterializeBudget`; 0.4.482 found a fourth in `validate.ts` whose local
+  variable the grep walked past; this is the fifth. So the file now enumerates the refusal sites
+  out of `src/` and fails on a sixth until it is listed — which is the only way this stops being a
+  rule that most of the code follows.
+- Both array widths are checked here rather than one, because they are different numbers reached
+  through the same comparison: eight bytes a sample for the float64 result, four for the clamped
+  int32. A boundary correct for one and wrong for the other would look tested.
+
 ## 0.4.490
 
 - **Added** a check that every published export is reached by the suite a fresh clone actually

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.490",
+  "version": "0.4.492",
   "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.490';
+export const VERSION = '0.4.492';