edfcore 0.4.333 → 0.4.335

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

package/docs/CHANGELOG.md

@@ -6,6 +6,36 @@ 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.335
+
+- **Added** a check over the console output `quick-start.md` prints. Between two `text` blocks the
+  page pins the whole shape of a read — variant, record geometry, three channels with their kinds
+  and sample counts, and `2560 samples, 6040 bytes read` — and the fixture is now built from the
+  block's own description of the file rather than from a fixture that happens to resemble it.
+- The byte count is the number worth holding. The page stops to explain that 6040 "is more than
+  the 5120 bytes those 2560 samples occupy", because a record is the smallest readable unit and
+  every channel is interleaved into it — so the overhead a reader budgets from this page follows
+  from the annotation channel's width, three lines further up the same block. That subtraction is
+  checked, not just the total.
+- The individual sample values are deliberately not checked. They come from a recording nobody
+  here has, and a fixture reproducing them would be asserting against its own generator.
+
+## 0.4.334
+
+- **Added** a check over the `validateHeader` table on `api-validate.md`, which was one of the four
+  pages no test named. The table lists ten codes; the sentence under it does the real work, saying
+  four of them "exist nowhere else in edfcore" and that "the other six are also emitted by the
+  parser, so a report stands on its own instead of only making sense next to
+  `header.diagnostics`."
+- That claim rots silently in both directions. Moving one of the four into the parser makes a
+  validation report redundant for that code while the page still calls it exclusive; moving one of
+  the six out breaks the sentence the other way. Both halves are now settled by asking which
+  modules under `src/` name each code. Also checked: none of the ten is fatal, since a fatal code
+  here would let `validateHeader` condemn a file the parser opened without complaint, and the
+  fourteen label types the page spells out are read out of `STANDARD_LABEL_TYPES` in order.
+- `diagnostic-docs.test.ts` covers how severe a code is across every page. This is the narrower
+  question it does not ask: who is entitled to emit one.
+
 ## 0.4.333
 
 - **Added** the rest of `migrating-to-0-3.md`: the difference the page calls structural. `sampleAt`

package/package.json

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