edfcore 0.4.227 → 0.4.229

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

package/docs/CHANGELOG.md

@@ -6,6 +6,33 @@ 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.229
+
+- **Added** a check that the Node floor is one number. It is written down eleven times — the
+  README's compatibility line, four statements on `installation.md`, two on
+  `design-decisions.md`, the `llms.txt` summary handed to agents, and the docblocks in
+  `src/index.ts` and `src/cli.ts`, which `removeComments: false` ships verbatim into `dist/*.d.ts`
+  as an editor's hover text — and one of the eleven is not prose. The CI matrix's lowest entry is
+  the version the suite is actually proven against, while `engines.node` is the version consumers
+  are told to have; raising one without the other gives either a package that installs where it
+  was never run, or a matrix job on a version nobody may use, and nothing said which. All of them
+  are now read against `engines.node`. The scan recognises a requirement and deliberately not
+  `Node v24.4.0`, which is the shape `src/bytes/latin1.ts` uses for "the runtime this was verified
+  on" — the `v` is what separates a version someone ran from one someone requires.
+
+## 0.4.228
+
+- **Added** a test that actually runs `require()` of the built package from CommonJS. That it
+  works is the claim the Node floor rests on, stated five times — the README's compatibility
+  list, `installation.md`, `design-decisions.md`, the docblock in `src/index.ts`, and the comment
+  pinning 22.12 in the CI matrix — and nothing ran it. Nothing else in the suite could: the whole
+  repository is ESM under vitest, where a top-level `await` is ordinary and the condition that
+  breaks `require()` is invisible from inside. A child process now requires each of `dist/`'s
+  three entry points from a CommonJS realm, which makes Node itself the oracle — a graph with a
+  top-level `await` anywhere in it throws `ERR_REQUIRE_ASYNC_MODULE`, with no heuristic to agree
+  with the same mistake a reader of the source would. A negative control in the same run proves
+  the harness can fail.
+
 ## 0.4.227
 
 - **Fixed** `npm run lint` not seeing any JavaScript in the repository. Biome's `files.includes`

package/package.json

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