edfcore 0.4.437 → 0.4.439

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.437";
+export declare const VERSION = "0.4.439";
 //# 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.437';
+export const VERSION = '0.4.439';
 //# 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.439
+
+- **Added** a check that everywhere a stranger learns what this package does, it says it reads.
+  `design-decisions.md` gives the constraint a heading of its own — "edfcore does not write EDF,
+  and will not before 1.0. A writer exists in the test suite and is not exported" — and four other
+  places carry it, each reaching a different reader: AGENTS.md tells an agent, the README tells
+  someone deciding whether to install, `comparison.md` sends a would-be writer to pyEDFlib, and the
+  npm description tells everyone who opens none of them.
+- The `keywords` array is the one that can quietly say otherwise. It is metadata nobody reviews
+  closely, it exists to be matched against searches, and adding `edf-writer` for discoverability is
+  a plausible thing to do. It would work: the package would surface for a search it cannot serve,
+  and the people it brought in are exactly the ones `comparison.md` is written to send elsewhere.
+  No code change, and nothing to fail.
+- So the keywords are checked from both directions — every format the package reads is listed, so a
+  search for `bdf+` finds it, and nothing in the list advertises writing.
+
+## 0.4.438
+
+- **Added** tests for `--limit 0` and the blank line that belongs to the rows rather than to the
+  notice. A truncated listing has to say so, since a silently shortened one reads as a complete
+  one, so every capped command prints a notice naming what it withheld, separated from the rows
+  above it by a blank line.
+- That blank line belongs to the rows. With `--limit 0` there are none, and emitting it anyway left
+  two blank lines and a notice hanging under the count, as though the rows had failed rather than
+  been asked for (fixed in 0.4.181). It is one ternary, and the only thing distinguishing it from a
+  stray newline nobody would defend is knowing what the blank line is for.
+- `--limit 0` is not a contrived argument. It is what a script passes to ask "how many are there?"
+  without paying to print them, and what `--limit "$N"` becomes when `N` is empty. The count line
+  and the notice are then the whole of the useful output.
+- The notice is also pinned to name what was withheld rather than what was shown, and to stay
+  absent when nothing was — across the events listing and the header's diagnostics, which cap the
+  same way through different formatters.
+
 ## 0.4.437
 
 - **Added** a check that the throwaway probes stay runnable and cannot reach the suite, the

package/package.json

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