fix: make the published manifest installable, and stop VERSION lying

[NSchatz]

Two defects that together made @cosyte/cli unusable, plus a third found while verifying the first.

1. The published manifest was uninstallable

0.0.1 and 0.0.2 both published with all ten @cosyte/* siblings declared as file:vendor/*.tgz local paths. vendor/ is not in files and there is no bundledDependencies, so the tarball shipped none of them.

Negative control, run first, on the current published version:

$ npm install @cosyte/cli@0.0.2
npm error code ENOENT
npm error path .../node_modules/@cosyte/cli/vendor/cosyte-fhir-0.0.0.tgz
npm error enoent ENOENT: no such file or directory

Every version was derived from the live registry, never from a file. The siblings are now real ranges: @cosyte/hl7 ^0.0.7 and @cosyte/terminology ^0.0.9 as hard dependencies; the six breadth parsers plus @cosyte/transform ^0.0.4 as optionalDependencies.

Verified by installing, which a dry-run cannot do

$ npm install ../cosyte-cli-0.0.2.tgz
added 111 packages, and audited 112 packages in 4s          # exit 0

$ cosyte --version
0.0.2                                                       # exit 0   (published 0.0.2 prints 0.0.0)

$ cosyte parse adt.hl7                                      # exit 0
$ cosyte inspect claim.x12                                  # exit 0
$ node -e 'import("@cosyte/cli").then(m=>console.log(m.VERSION))'
ESM ok  VERSION=0.0.2  exports=48
$ node -e 'console.log(require("@cosyte/cli").VERSION)'
CJS ok  VERSION=0.0.2  exports=48

$ printf '<initialize>' | cosyte-mcp
{"result":{...,"serverInfo":{"name":"cosyte","version":"0.0.2"}},"jsonrpc":"2.0","id":1}

What still blocks a fully-featured install, stated rather than papered over

@cosyte/fhir could not be de-vendored and is not declared at all. It is a registry 404 (FHIR-NPM-NAME, a persistent unexplained E403; the name-similarity reading was retracted ecosystem-wide today, so no rename is proposed and the publish was not re-tested). Decision: @cosyte/fhir is undeclared, @cosyte/transform is declared optional. That was measured, not reasoned:

root manifest declares	npm install
optional @cosyte/fhir alone	exit 0
optional @cosyte/transform alone	exit 0
both	ERESOLVE, exit 1
@cosyte/fhir as an optional peer + transform	ERESOLVE, exit 1

So the two cannot both be named. transform is declared because it is real and starts resolving by itself the day fhir publishes, with no release here. Not attributed to a missing peerDependenciesMeta.optional flag: measured across the suite, that flag does not decide the outcome (synth marks all seven peers optional and still ERESOLVEs; deid declares the same optional fhir peer and installs cleanly). The mechanism is unexplained; only the measurements are recorded.

Consequence, stated on every consumer surface: an installed copy has no FHIR support. That required a code change, because shipping the manifest swap alone would have been worse than the install break. Both packages were loaded with a bare await import(), so an install without them raised a raw resolver error and a stack frame, which the value-free posture forbids. loadOptionalPackage(detail, load) now sits under loadOptional (which takes a CosyteFormat and hardcodes "parser", wrong for both cases), plus loadFhir():

$ cosyte parse patient.json
cosyte: CLI_PARSER_UNAVAILABLE: the @cosyte/fhir parser is not installed, and it is not currently on
the npm registry, so it cannot be installed from there; FHIR support is unavailable in this install
exit=69

$ cosyte convert adt.hl7 --to fhir
cosyte: CLI_PARSER_UNAVAILABLE: the @cosyte/transform conversion library is not installed, so convert
is unavailable; it requires @cosyte/fhir, which is not currently on the npm registry, so npm skips
transform as an unresolvable optional dependency and installing it directly fails for the same reason
exit=69

Neither says "install it", deliberately: npm install @cosyte/transform fails E404 on its own peer, so that advice would point at a command that cannot succeed.

@cosyte/fhir is kept as a devDependency on the vendored tarball so this repo's FHIR/convert tests still run. Note precisely: devDependencies are published, so one file: specifier does remain in the manifest, harmlessly, because a consumer never installs a dependency's devDependencies, verified by the exit-0 install above.

The dependabot config keeps its honesty and gains coverage: the siblings are now watchable for the first time; @cosyte/fhir is the one it still cannot see, and the comment says so rather than implying cover.

2. The VERSION export lied

src/core/version.ts exported "0.0.0" against a 0.0.2 manifest, and its JSDoc already claimed a Changesets sync step that did not exist. Confirmed independently in the published tarball:

$ npm pack @cosyte/cli@0.0.2 && tar xzf ... && grep -o 'VERSION = "[0-9.]*"' package/dist/index.mjs
VERSION = "0.0.0"
$ node -p "require('./package/package.json').version"
0.0.2

It reached two user-visible surfaces: cosyte --version and the MCP server's advertised serverInfo.version.

Proof the new test fails on the unfixed tree, as required:

FAIL  test/sanity.test.ts > toolchain sanity > package exports VERSION matching package.json
AssertionError: expected '0.0.0' to be '0.0.2' // Object.is equality
Expected: "0.0.2"
Received: "0.0.0"

FAIL  test/sanity.test.ts > toolchain sanity > declares VERSION in the exact shape scripts/sync-version.mjs rewrites
AssertionError: expected null not to be null

Tests  2 failed | 2 passed (4)

scripts/sync-version.mjs is ported from @cosyte/transform (87b5282), and test/sanity.test.ts narrows the parsed manifest **without an as cast`.

Both named traps closed

• A smoke test that asserts a TYPE asserts nothing. docs-content/installation.md did exactly what synth's docs did: typeof VERSION; // => "string", true of every wrong value, executed against built dist/ by test/docs-content.test.ts on every release. It now asserts VERSION; // => "0.0.2", a real toStrictEqual, and the sync script rewrites that literal as a second target so the docs gate stays load-bearing instead of going stale.
• The : string annotation. It was absent entirely; it is now present and pinned by its own test. Verified that disarming it reds only that assertion:

$ sed -i 's/^export const VERSION: string = /export const VERSION = /' src/core/version.ts
× declares VERSION in the exact shape scripts/sync-version.mjs rewrites
  Tests  1 failed | 3 passed (4)
$ node scripts/sync-version.mjs
sync-version: could not find `export const VERSION: string = "...";` in src/core/version.ts.
sync-version exit=1

3. Pre-existing, and NOT fixed by either of the above

npx @cosyte/cli never worked, independent of the packaging defect. npx runs the executable matching the package name's last segment (cli); this package ships cosyte and cosyte-mcp. Reproduced on published 0.0.2 and on the fixed tarball, whose bin block is byte-identical, so the swap provably cannot have changed it:

$ npx @cosyte/cli --help
npm error could not determine executable to run

$ npx --package @cosyte/cli cosyte --version     # the form the docs now use
0.0.2

Docs (README, installation.md, both MCP registration snippets) now use the measured working form. A cli bin alias would fix the short form and is deliberately not added, because npm install -g would then claim the name cli on every user's PATH. That trade is a founder call, not a packaging tidy-up.

Gate

gate-refuter (not conformance-refuter: no healthcare-data parsing is touched), 2 passes.

• Pass 1: VERDICT: REFUTED: two INTRODUCED majors, both documentation-honesty, no code defects. (a) README.md still said "the swap is blocked... until @cosyte/fhir can be published under a name npm accepts", stale and restating the retracted diagnosis, 44 lines below new text saying the swap was done. (b) the convert diagnostic said "install it to use convert", advice that fails E404, while three documents claimed it said the opposite, and in a plain install that is the only branch convert reaches. Plus four minors. Remedied in 7b2b596; the fix was text plus one diagnostic string, and neither the loader nor the guard was grown.
• Pass 2: VERDICT: NOT REFUTED: all seven findings resolved or accepted, re-measured in a clean room. One new minor inside the remedy: my source-extraction regexes silently dropped each constant's last line (182 of 270 chars), so the negative assertions had a blind spot exactly where a re-introduced "install it" tail would land. Fixed in 4778919 (one token, ;?) with a test pinning both strings' final words; negative control confirms restoring the old regex reds that assertion and only it.

Filed, not fixed here (PRE-EXISTING, reproduces on c858cb0): the built dist/bin/cosyte.mjs imports @modelcontextprotocol/sdk statically at top level, so --omit=optional yields an install where every command, --version included, dies with ERR_MODULE_NOT_FOUND and a raw stack trace. It also falsifies src/bin/cosyte.ts's "a plain cosyte parse never pulls it" and the test/mcp-isolation.test.ts claim. This release makes it reachable for the first time, because the package could not be installed at all before. Three docs pages now say not to use that flag rather than implying it is supported. It needs its own change.

Verification

scripts/verify.sh cli green. typecheck, lint (--max-warnings=0), format:check, check:no-emdash, check:no-internal-refs, phi-scan, attw, smoke all green. 361 tests, 29 files. Coverage 97.7 / 92.28 / 93.87 / 98.56, per-directory ≥ 90 on core and commands. Treat this PR's own check runs as authoritative.

Changeset included (patch, 0.0.x ladder). The open "Version Packages" PR #26 is deliberately untouched: the release is the coordinator's to drive once this is on main. No umbrella pointer bump, no operations/, documentation/, .gitmodules or other submodule touched.