v0.2.1

A corrective release. Nothing on the wire changed, and nothing that worked before works differently.

A filename outside ASCII now works on Linux

A name with a Japanese character in it is stored decomposed by the filesystem it was typed on, and composed everywhere the id then travels — the roster, the panel, the URL a browser sends. One name, two strings. macOS resolves the difference in the kernel and never notices; Linux compares bytes, so on the machine a broadcast actually runs on:

• a document was missing from its own roster — the scan composed the id and then spelled a path back out of it, asking the directory for a name it does not hold
• reading a document's words found nothing, on the same guess
• the bytes 404'd, because the static server compared the URL to the directory byte for byte
• a script was listed in the panel and then refused to run

The scan now keeps the name the directory holds and stats that, Decks.file reads the directory again for an id the last scan did not have, the script reader resolves through the listing, and the static server falls back to a normalisation-insensitive lookup — only after a miss, only for a name that has a second spelling, and still inside the one root guard it has always had.

The tests assert the resolved path rather than that a lookup succeeded. An existence check cannot fail on macOS, where the composed path opens either way, so it could not have caught this and did not.

The MCP version comes from the manifest

The version the adapter introduces itself with is displayed by an MCP client, so it is a published number. It was written out a second time in the source, where it stays correct until the release nobody remembers to edit it in. It is now read from package.json, and the manifest is the only place the number appears.