Address the openchamber-ai review's non-blocking notes:
- Concurrency evidence: the torn-write test now injects a slow, chunked
writeFile (one open handle, file grows prefix->full) so a torn read is
deterministically observable in the 30ms window. A companion test runs the
naive direct writer under the same load and asserts torn reads ARE produced,
proving the atomicity test can actually fail on the pre-fix writer.
- Windows fallback comment: no longer claims the copyFile fallback is atomic;
it is called out as a last resort confined to Windows.
- Module map: document cli-settings-accessors.js in bin/lib/DOCUMENTATION.md.
The CLI's settings accessors wrote settings.json directly with writeFile and
read it leniently, with no strict-reader gate on relay identity. Running
'openchamber connect-url' while the desktop app is up could:
- tear the file for a concurrent reader in the app, tripping the relay
service's read and mapping it to {} (first-run);
- then regenerate the relay signing/encryption keys, changing serverId and
orphaning every paired device and push binding.
Move the accessors into a dedicated module that mirrors the settings
runtime's guarantees: atomic tmp+rename writes (with the Windows fallback)
so no reader can observe a partial file, and a strict reader that throws on
corrupt/unreadable payloads so identity regeneration is gated exactly like
the server runtime. Wire the strict reader into the CLI relay identity path.
Adds unit tests covering atomic writes under concurrent readers, strict-read
behavior, and that a corrupt settings file makes getRelayIdentity fail
instead of minting a replacement keypair.
quiz152