edfcore 0.4.374 → 0.4.376

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

package/docs/CHANGELOG.md

@@ -6,6 +6,39 @@ 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.376
+
+- **Fixed** a gap in `.gitignore`: `.venv/` was not in it. `scripts/golden/README.md` tells you to
+  build a virtualenv at the repository root and install pyedflib and mne into it, and
+  `scripts/release.mjs` stages with `git add -A` — whose docblock says that `-A` honours
+  `.gitignore`, "which is what keeps `dist/`, `node_modules/` and `tests/scratch/` out". A
+  regeneration run followed by a release would have put a few hundred megabytes of Python into a
+  release commit, by following two sets of documented instructions in order.
+- **Added** the check that found it, over the rest of what that README promises. The regeneration
+  block has to name four scripts that exist and every script in the directory, so none is
+  undocumented and none is named that is not there. "The venv is not committed and CI never builds
+  it" is checked both ways: the ignore rule, and no workflow step that installs or runs Python.
+- And the claim the whole harness rests on — "Nothing in `tests/corpus/golden/` is produced by
+  edfcore" — is read off the files rather than trusted. Every golden carries a `producer`, and no
+  producer names this package: a golden regenerated with edfcore's own writer would compare edfcore
+  against itself and pass no matter what either did.
+
+## 0.4.375
+
+- **Added** `tests/property/read-agreement.test.ts`: the two ways to read the same records return
+  the same samples. `readWindow` resolves a time window and splits it; `readRecords` is handed a
+  range directly. Every worked example in the documentation uses whichever is more convenient, so a
+  caller who computes a range with `resolveTimeWindow` and reads it with `readRecords` has to get
+  exactly what `readWindow` would have returned — and nothing said so.
+- Each has thorough tests of its own and they share a decoder, but the layer above the decoder is
+  separate, and a divergence there is not a decode bug: the samples would be individually correct
+  and attached to the wrong records, which is the failure mode this package treats as the worst
+  kind because nothing about the numbers looks wrong.
+- So the fixture's generator makes every sample a function of its own record and position, and the
+  second property checks each returned value against where the chunk says it came from — over
+  arbitrary geometries, since the interesting windows are the awkward ones: shorter than a record,
+  starting mid-record, running off the end.
+
 ## 0.4.374
 
 - **Added** a check over what `installation.md` says each entry point contains. The page names

package/package.json

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