v0.5.67

Nothing in this release changes what conclave does. It is one test fixture. Installing it is optional.

A test that could not tell a slow start from a failed one (#382)

Four #303 boot-cleanup tests failed on macos-15-intel with:

the stand-in never wrote <path>: it did not start at all

Twice — once on a branch, and once on the release workflow for v0.5.66, where it left a tag with green CI and no release page and no archives until the job was rerun. A test fixture blocked a release.

The fixture read existsSync once. The report is written by a stand-in process as its first action after node boots, and the only clock in sight was the adapter's readiness window — which bounds how long the adapter waits and says nothing about how long node takes to start in the child. Independent clocks. On the smallest runner in the matrix, running four test files that each spawn real processes, a cold node start plus a pty fork can outlast that window.

So the assertion conflated two different things:

• the stand-in never spawned — a real failure
• the stand-in spawned and had not finished booting when the test looked — not a failure at all

It waits for the report now, bounded by a constant named and commented as the child's boot rather than readiness, so the two clocks do not get conflated again.

And the message stops diagnosing. "it did not start at all" was a conclusion the test had no way to reach. The comment says why the replacement does not try:

Absence after REPORT_MS is still not a diagnosis: a spawn that failed and a child that started but never reached its first JS action look the same from here, so the message says only what was observed.

This is not a widened tolerance, and that was checked rather than assumed: with the stand-in altered to write nothing at all, the four tests still fail, with the honest message, by assertion and well inside the test timeout rather than by hanging.

What it does not claim. That those CI failures were boot races. The failure was never reproduced — the machine it was fixed on is far faster than the one that reports it — so the repair fixes what was demonstrably wrong and leaves the open question open. If that runner is exhausting resources, the next occurrence now says so in terms that can be acted on, which is the useful outcome available without a reproduction.