v0.5.64

A project can say once which transport notify uses (#353)

0.5.61 removed the fake default, because defaulting a human channel to test plumbing meant an agent discovered it had no channel at the moment it needed one. That stands. But its refusal says "no human channel is configured by default" — which implies a thing you can configure, and there was none. The only remedy was remembering a flag on every call, forever, including inside whatever agent was driving the run. A person forgets that; an agent cannot persist it.

{ "notify": { "transport": "even-realities" } }

--transport on the call still wins; the file is consulted only when the flag is absent; and with neither, notify refuses exactly as it did in 0.5.61, byte for byte.

A configured fake is allowed. It is a legitimate choice for a demo or a test, and refusing it would be the config second-guessing an operator who named it deliberately. What 0.5.61 removed was inheriting a stub by saying nothing. notify ask still says what fake is when it answers nothing, so a configured stub is never mistaken for a delivered question.

An unknown name is refused when the file is read, naming the known transports — not at the first notify ask of an unattended run, which is the same failure with a longer fuse.

The broker's host and token are deliberately not here. A transport name is a property of this checkout; the device's address and token are properties of the MACHINE, shared by every project that reaches the same glasses — so a per-project copy is the value most likely to be stale when the device moves.

Two tests that held because of the machine, not the behaviour

Both caught by CI, on two different platforms, and worth recording because neither was flakiness and both looked exactly like a passing test everywhere else.

One compared two runs' stderr for equality. stderr carries (node:<pid>) ExperimentalWarning when this source is run directly, and the pid differs between runs — so the assertion was that two processes shared a pid. It passed on every platform where that warning does not fire, and failed on the Node floor, which still emits it. The comparison now drops Node's own warnings, because they are the harness speaking rather than conclave.

The other proved a follower had not exited and then read its stderr, which had not been written yet. Proving a process stayed up answers a different question from whether it has said anything, and one second was enough on every machine fast enough. It now waits for the line, with a generous timeout because that bounds a FAILURE: when the line is coming it returns as it arrives, and when it is not the test should fail slowly rather than flakily.

Neither repair widens a bound. One removes a value that was never conclave's to compare; the other waits for an event instead of guessing how long it takes.