v0.1.3

Let the gates in CI actually run

The quality job typechecked tsconfig.build.json, which excludes tests,
and ran the suite without coverage — so a type error in a test file
reached nothing, and the thresholds in vitest.config.ts gated nothing.
They were pinned at 85/85/80/85 while the suite reaches 97/95/100/98.

Raised to just under the real figures, lint extended over tests/, and
@vitest/coverage-v8 added with the same overrides pin the other packages
carry: CI clones this package standalone and resolves fresh, so a
devDependency the workspace happened to provide is a devDependency CI
does not have.

Refuse the envelopes the spec refuses, and the errors that only look like ours

isRpcShapedError decided whether a thrown value could be shown to the
caller by asking whether it had a numeric code. A DOMException has one:
20 for AbortError, 23 for TimeoutError. So a handler whose outbound
fetch was cancelled or timed out answered the caller with its own code
and its own message — in production, past the guard the binding puts two
branches below to keep internal failures off the wire. A gRPC status
(0..16) arrives the same way. An RpcError is now always honoured,
whatever its code, and a foreign object only when its code is a negative
integer: the space §5.1 gives errors, and the space a handler picks a
domain code from.

Three envelope rules the spec writes as a MUST were not enforced. §4.2:
params, when present, is a Structured value — an Array or an Object.
A string reached the handler as a valid request. §5.1: an error code is
an integer; 1.5 passed, and so did NaN, which does not survive
JSON.stringify and arrives with no code at all. And buildRequest
emitted a params member holding undefined when there were none,
which JSON hides and a worker or an in-process bus does not.

The batch client numbered its entries from zero on every send, so two
batches sent the same ids and a single call was live on one of them.
Over HTTP the transport pairs each response with its own request and
nothing shows; over the multiplexing transport that injecting the
transport exists to allow, the id is the only correlation there is. Both
paths now draw from one counter and each call keeps the id it was sent
under. And a parse that rejected its result rejected the whole batch
promise, taking every other settled entry with it — including the ones
that had already come back fine; it settles as that entry's failure now,
with what the validator threw on error.data.

Reformat what the strictness pass reflowed

Two files-worth of blank lines and one long call the formatter wraps
differently now that a helper sits above them. CI resolves biome from a
caret range and installs a newer one than the lockfile pins.

Release 0.1.3

Turn on noUncheckedIndexedAccess

It was not missing here — it was explicitly false, in sixteen of the
seventeen tsconfigs. eon alone had it on, which is why nobody had seen
what it finds.

It stays a named deviation from upstream: @adonisjs/tsconfig sets
strictNullChecks and noImplicitAny but not this one. We keep it because
turning it on is what caught an as asserting a possibly-absent regex
group was a known value — the exact shape the flag exists to find. Doing
better than upstream is kept and written down, not reverted to parity.

Every site is restated rather than silenced: no !, no cast, no ?? 0
standing in for a branch that cannot happen. A reversed copy read by
value where an index walked a callback list backwards, the winner of a
scan kept as the value it found rather than its position, destructuring
where a length check was doing the proving, and an explicit break where a
loop condition already bounds the read.

---

Changes since v0.1.2.

v0.1.2

Turn on noUnusedLocals/noUnusedParameters

Refuse a JSON-RPC response carrying both result and error

§5 makes them mutually exclusive: "Either the result member or error member
MUST be included, but both members MUST NOT be included." Such a response was
read as an error response, which is guessing at which half the sender meant.
Refused now, the way a bad jsonrpc/id envelope already was — on the single-call
path and per item in a batch.

Release 0.1.2

Check a batch envelope the way a single call is checked

call verifies the JSON-RPC version, that the id echoes the one it sent, and
that a success carries result — because a stale, mis-routed or forged
response would otherwise satisfy the wrong call. batch verified none of it:
it matched by id and read result/error straight off, so a { jsonrpc: "1.0", id: 0 } came back as { ok: true, value: undefined }.

Each item now goes through the same three checks, and two responses claiming
one id are refused rather than silently resolved to the last — keeping the
last is how a response answers a call it was not for. A null result is still a
value.

Create the GitHub release from the publish workflow

A published version arrived with no notes: npm showed a number, GitHub showed
nothing, and the only way to learn what changed was to read a diff. The commit
messages already carry the reasoning, so the release is built from the commits
the tag contains rather than written twice.

Skips a pure version bump, leaves an existing release alone, and does nothing
when the run was not built from a tag. The job takes contents:write for this;
the workflow default stays read.

---

Changes since v0.1.1.

comet v0.1.1

comet 0.1.1

v0.1.1

b788937

CI: @biomejs/biome devDep + src-only typecheck standalone

5e7396e

client/protocol audit fixes + CI quality gate

93519fa

---

Changes since v0.1.0.