Wire allium-lsp in plugin.json for live .allium diagnostics (#39)

[yavorpanayotov]

What

Wires the allium-lsp language server into the Claude Code plugin so Claude receives live diagnostics, go-to-definition and hover for .allium files immediately after each edit — without a separate allium check run. Closes #39.

Changes

1. .claude-plugin/plugin.json — add the lspServers entry (exact config from the issue):

   "lspServers": {
     "allium": {
       "command": "allium-lsp",
       "extensionToLanguage": { ".allium": "allium" }
     }
   }

2. README.md — note in the Verification section that allium-lsp is not bundled and must be installed separately and be on PATH, with a pointer to allium-tools.

Acceptance criteria (#39)

• plugin.json includes an lspServers entry wiring allium-lsp to .allium
• README notes allium-lsp must be installed separately
• Cannot verify here that diagnostics actually flow — that requires the allium-lsp binary on PATH and a Claude Code session; the binary work lives in juxt/allium-tools and is out of scope for this repo.

🤖 Generated with Claude Code

[yavorpanayotov]

Sanity-check of the issue's suggested config — two corrections

I verified the request against the Claude Code plugin schema and the actual allium-lsp source in juxt/allium-tools. The intent is sound and the plugin system supports it, but the issue's exact config has two problems, now fixed in this PR:

1. Missing --stdio arg. allium-lsp calls createConnection(ProposedFeatures.all) (packages/allium-lsp/src/server.ts), which requires a transport flag on argv or it errors on startup. allium-tools CONTRIBUTING confirms clients launch allium-lsp --stdio. The issue's "command": "allium-lsp" with no args would fail. → added "args": ["--stdio"]. (args is a documented optional field in the plugin lspServers schema.)

2. npm install -g allium-lsp does not work. The package is not published to npm — the bare name and @juxt/-scoped name both 404. The source exists (packages/allium-lsp, bin allium-lsp, v3.4.2) but is unpublished. → README now points to allium-tools for installing the server onto PATH instead of a command that 404s.

The field names command / extensionToLanguage and the .allium key (with leading dot) are correct, so the rest of the config stands.

⚠️ Blocker for actually using this

Until allium-lsp is installable via a published artifact (npm/brew/nix), users can't get the binary onto PATH, so the LSP integration won't activate — it'll fall back to CLI checking. This PR is correct and safe to merge (no effect when the binary is absent), but the feature isn't usable end-to-end until allium-tools ships an install path. Tracking deps in the issue: juxt/allium-tools#16 (nix/brew), #17 (standalone binary).

[yavorpanayotov]

Upstream dependency now in progress: juxt/allium-tools#54 makes allium-lsp installable via npm install -g allium-lsp (adds a publish-npm job to the release workflow). Once that merges and a tagged release publishes the package (plus the maintainer adds an NPM_TOKEN secret and claims the npm name), the lspServers wiring in this PR becomes fully usable end-to-end.

[yavorpanayotov]

Correction — #48 is not blocked by npm publishing (allium-tools#54).

The lspServers entry only needs allium-lsp on PATH; it doesn't care how it got there. The existing release tarball already provides that — download allium-lsp-<version>.tar.gz, extract, put the self-contained binary on PATH, and it runs allium-lsp --stdio. So this PR works today via the current tarball/source install and can merge independently.

allium-tools#54 (npm install -g) is a convenience that makes install a one-liner — not a prerequisite. My earlier comment saying this becomes usable only after #54 was wrong.