v0.8.2 — npm install verification + Railway deploy port fix

[0.8.2] — 2026-07-03

Added

• verify-npm-install job in npm-publish.yml — after each publish, installs bookie-mcp from the registry into a disposable Neon project, pushes the bundled schema, and confirms the server responds over stdio via the MCP inspector CLI; the project is always deleted after (pass or fail — a try/finally). Requires a NEON_API_KEY repo secret.
• verify-npm-install now files (or comments on an existing open) a GitHub issue when it fails, titled verify-npm-install failed for <tag> — previously a failure was only visible as a red check in the Actions tab, easy to miss. Dedups by title via gh issue list --search, so repeated failures for the same version comment on one issue instead of spamming duplicates. Needs issues: write permission, scoped to just this job.

Changed

• README.md: document the npm/npx install path alongside the source npm run setup flow, including adding another machine to an existing ledger without cloning; add npm version badge; tip to use OAuth (not email+password) when signing up for Neon for the first time via npm run setup's browser auth step
• README.md: add a "Publish to npm" GitHub Actions status badge next to the npm version badge — reflects the pass/fail of the release pipeline, including verify-npm-install
• vitest.config.ts: exclude .claude/** from test discovery — a stray agent worktree under .claude/worktrees/ was silently double-running the entire suite via its own nested copy of test/**

Fixed

• npm audit fix: bumped hono (4.12.23 → 4.12.27) and esbuild (0.28.0 → 0.28.1, transitive via tsx/vitest) to patched versions. Neither vulnerability was reachable in bookie's actual usage (no cors()/serveStatic()/Lambda adapter imports; esbuild's dev server never runs in this project), but both were safe in-range bumps.
• scripts/setup.ts: neonctl projects create requires an --org-id; without one it drops into an interactive org picker that hangs indefinitely once stdout isn't a real TTY (always true under execSync) — every brand-new Neon account hit this on first-ever npm run setup, since a fresh account has no cached "current org." Now resolves the org via neonctl orgs list first (auto-selects when there's exactly one, errors with guidance to set NEON_ORG_ID when there's more than one) and passes --org-id explicitly. Same fix applied to scripts/verify-published-install.ts, which had the identical bug and would have hung on every GitHub Actions run (no TTY at all there).
• scripts/setup.ts: Neon allows multiple projects with the same name in one org — running npm run setup a second time (deliberately, for a second independent ledger, or by accident after losing .env) silently created a second, empty, identically-named bookie project with no warning. Now checks for an existing project with the target name first and aborts with guidance (reuse the existing one's connection strings, or set NEON_PROJECT_NAME to deliberately create a second ledger) instead of silently duplicating.
• scripts/setup.ts: npm run setup never actually worked on Windows. buildEnvContent split its .env.example template on "\n" only; git on Windows checks that file out with CRLF line endings by default, leaving a trailing \r on every line. Since . doesn't match \r and $ requires true end-of-string, the per-line substitution regex silently failed to match every line — .env was written back out as the raw, unmodified template (literal USER/PASSWORD/ep-xxxx.REGION placeholder text, empty secrets), with no error. The only symptom was a downstream prisma db push failure (P1001: Can't reach database server) pointing at a placeholder hostname — nothing in the failure indicated the real cause. Fixed by normalizing \r\n → \n before splitting. Added a retry (scripts/setup.ts's new shared retry() helper, also used by verify-published-install.ts) around the db push step regardless, since genuine Neon compute cold-start on a just-created project is a real, separate, already-documented characteristic (see vitest.config.ts's testTimeout comment) — but note that specific failure, when it happens, is not what this CRLF fix addresses.
• scripts/verify-published-install.ts: replaced a spawnSync(cmd, argsArray, { shell: true }) call (Node's DEP0190: unescaped args concatenated into a shell command) with a plain execSync string, matching the run() helper already used for every other external command in the file.
• Dockerfile: the README's "Deploy on Railway" button produced a container that never actually served traffic. Railway's public domain for the one-click template defaulted its target port to 3000, but the container (with no EXPOSE) bound whatever PORT Railway happened to inject (8080) — every request 502'd ("Application failed to respond") even though the deploy log showed the server starting cleanly and the container stayed healthy. Confirmed via a real deploy: fixed by pinning ENV PORT=8080 + EXPOSE 8080 in the Dockerfile so Railway's target-port auto-detection has something to key off. docs/DEPLOYING.md updated with the new default and a troubleshooting note.
• README.md: "Quick start (remote, HTTP — for Claude.ai mobile)" opened with a npm run build && npm start snippet binding to localhost:3000 — leftover from before the Railway one-click badge existed (present since the very first commit), never revisited when the badge was added. It was actively misleading (localhost isn't reachable by Claude.ai mobile; no tunnel is documented anywhere) and unnecessary for either deploy path (the badge pulls a pre-built image; "from source" has Railway build it). Removed — the section now opens directly with the badge.