@cosyte/test-utils@0.0.4

PERF-P2: add @cosyte/test-utils/perf, the throughput scaling gate.

A new subpath export, and a sixth runner family alongside the conformance runners on the root entry.
It exists so every @cosyte/* package can prove, in its own CI and without bespoke code, that it
has not silently acquired an algorithmic-complexity regression. Zero dependencies, hand-rolled on
node:perf_hooks.

• scalingGate(options): takes a workload generator and a parse function (never a file
  path, which is what keeps PHI out of the benchmark path by construction), does time-budgeted warmup
  with a stability rule, sampling, and sink accumulation, then asserts
  RATIO_FLOOR ≤ min(scaled)/min(base) ≤ RATIO_CEILING on two axes.
• Both axes, and size-scaling is not optional. count scales the number of inputs at fixed
  length; size scales each input's length at fixed count. An O(n²)-in-length tokenizer is invisible
  to the count axis by construction: at fixed message size a quadratic parser still scores ≈4 there
  , so there is no way to ask for one axis.
• assertScalingGateFires(options, injection): the per-package self-check, and the load-bearing
  half. The ceiling of 8 sits between a constant (the worst false alarm across 3,200 clean ratios,
  6.649) and a non-constant: the weakest real O(n²) signal climbs 4.69 → 8.09 → 8.84 → 10.68 as
  the base fixture grows 125 → 250 → 500 → 1000 segments. At the smallest, a genuine quadratic is
  inside the noise and the gate reads green while broken. The self-check takes the same options
  object the real gate is given, so "run it at the sizes your real gate uses" is structural rather
  than remembered, and it fails the build when the fixture is too small. It also checks the clean
  parse can produce a ratio at those sizes, not just the regressed one, since the regressed parse is
  the slower of the two and would otherwise mask a permanently-skipping gate.
• Fail-safe. Typed, loud skips (phase-too-short, warmup-unstable) on stderr with
  status: "skipped", a measurement never reports a confident wrong answer, and a skip is not a
  pass. Both bounds are hard failures. The floor's claim is deliberately narrow: it catches the two
  phases received the same workload, not dead-code elimination, which stays at ≈4 on the count axis
  and is prevented structurally by the sink.
• PERF_CONTRACT: the frozen constants, readable, printable, and deliberately not overridable.

Every constant is fixed by documentation/decisions/0001-perf-measurement-contract.md, each tagged
measured or judgement. What it does not catch, stated because it will be quoted:
constant-factor regressions (a 10% slowdown passes and always will: from a single cloud instance
only 17–22% of configurations reliably detect one), complexity regressions whose fixture is too
small, and anything that only manifests under real I/O, network or concurrency.

No change to the root entry point: a parser importing the conformance runners does not pull
node:perf_hooks in with them.

One limitation this slice measured rather than inherited, and which every adopting package needs:
the ceiling is calibrated to a runner class. Across three 200-run sweeps on a CPU-quota-throttled
container the gate fired on a linear workload 4 times in 600 runs, at ratios of 8.94–11.01: above the
weakest real O(n²) signal at hl7's own fixture size (8.84). A same-process ratio cancels JIT state,
but the two phases are separated in time and a cgroup's throttling state changes between them. So
assertScalingGateFires proves your fixture is big enough and says nothing about whether your
runner is quiet enough; establish both before adopting.

Install

npm install @cosyte/test-utils@0.0.4

npm: https://www.npmjs.com/package/@cosyte/test-utils/v/0.0.4

@cosyte/script-utils@0.0.1

First release of @cosyte/script-utils: zero-dependency helpers for the gate scripts every cosyte
repo keeps in scripts/.

It ships isCliEntrypoint(import.meta.url), which answers "is this module the file Node was pointed
at" by comparing canonical paths. It replaces the raw string comparison those gates spelled by hand,
import.meta.url === `file://${resolve(process.argv[1])}`, which compares two strings rather
than two paths and so answers false for three ordinary invocations: an extension-less specifier
that Node or tsx resolved, a checkout under a path containing a space, and a symlinked invocation.
In each of those the gate exits 0 having checked nothing, which is indistinguishable from a clean
pass.

The package has no runtime dependencies and no build step, because the gates that import it run
before pnpm install on purpose.

Install

npm install @cosyte/script-utils@0.0.1

npm: https://www.npmjs.com/package/@cosyte/script-utils/v/0.0.1

@cosyte/vitest-config@0.0.4

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/vitest-config@0.0.4

npm: https://www.npmjs.com/package/@cosyte/vitest-config/v/0.0.4

@cosyte/tsup-config@0.0.3

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/tsup-config@0.0.3

npm: https://www.npmjs.com/package/@cosyte/tsup-config/v/0.0.3

@cosyte/tsconfig@0.0.4

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/tsconfig@0.0.4

npm: https://www.npmjs.com/package/@cosyte/tsconfig/v/0.0.4

@cosyte/test-utils@0.0.3

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/test-utils@0.0.3

npm: https://www.npmjs.com/package/@cosyte/test-utils/v/0.0.3

@cosyte/prettier-config@0.0.4

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/prettier-config@0.0.4

npm: https://www.npmjs.com/package/@cosyte/prettier-config/v/0.0.4

@cosyte/eslint-config@0.0.6

The bundled CHANGELOG.md no longer heads already-shipped content [Unreleased].

Every section now carries the version it shipped in, dated from that release's tag, so a reader of
the published tarball can tell which release a given entry belongs to. Previously the newest entries
sat under [Unreleased] in the file that shipped, which meant each release republished the previous
release's notes under a heading saying they had not shipped yet.

Nothing else in the tarball changes: no rule, setting, compiler option, build option, or runner
behaviour is different in any of the six packages.

Install

npm install @cosyte/eslint-config@0.0.6

npm: https://www.npmjs.com/package/@cosyte/eslint-config/v/0.0.6

@cosyte/vitest-config@0.0.3

Added

vite is now declared as a peer dependency (^6 || ^7 || ^8). Vitest 4 requires vite 6 or newer, and without this declaration a resolver could keep an incompatible vite 5, which is missing the ./module-runner export. If your install previously resolved vite 5 alongside this config, expect a peer warning telling you to upgrade.

A doc/code-agreement harness on a new @cosyte/vitest-config/snippets subpath: docSnippetSuite(), plus the primitives it is built from (extractRunnableSnippets, rewriteAssertions, remapImports, runSnippet).

It extracts every fenced ```ts runnable block from a package's docs-content/, compiles it, executes it against the package, and asserts its inline // => value results. It is the documentation analog of the conformance runners: a green docs build can no longer carry a snippet that silently disagrees with the code.

It is devDependency-only, and Vitest is already a peer, so it adds no new dependency.

Changed

Documentation and source comments were repunctuated to drop em dashes, in line with the cosyte brand voice. No config or behaviour change.

@cosyte/tsup-config@0.0.2

Changed

Documentation was repunctuated to drop em dashes, in line with the cosyte brand voice.

No build-option change. The README ships inside the tarball and renders on the npm package page, which is why a text-only change is versioned at all. If you are upgrading from 0.0.1, your bundles are unchanged.