Resolve last advisory, derive version from package.json, give stele-core a test suite

[mazze93]

Reopens #45, which was closed without merging — the branch's remote copy had been auto-deleted on close, but it was still live in a local worktree, unmerged. Original description:

---

Three things.

Dependabot — all clear

#42 cleared the three stele-core advisories: Hono CORS ReDoS (which mattered specifically because that middleware guards /api/*), fast-uri host confusion, and find-my-way HTTP/2 DDoS. Verified against the new stele-core CI job before merging.

The last one was @babel/core, transitive via eslint-plugin-react-hooks — lint/build time only, never in bundle.html, hence LOW. Pinned with a pnpm.overrides entry to ^7.29.7 rather than left open; the lockfile now resolves 7.29.7.

Version — this was rot, not an ambiguity

The 1.1.0 vs 1.0.0 split has been sitting in the journal as "needs a human decision on which is authoritative". It doesn't:

• v1.1.0 was tagged and released 2026-06-06 (f1a5c2e chore: bump version to 1.1.0).
• git log v1.0.0..v1.1.0 -- src/lib/version.ts → 0 commits. It was simply forgotten.

package.json is authoritative because it's what git tag v* and release.yml publish against. The harm was concrete: STELE_VERSION is stamped into every narrative export as steleVersion, so exports from the shipped 1.1.0 build claimed to be 1.0.0 — wrong provenance in the one artifact whose purpose is provenance.

Fixed structurally rather than by editing a literal: vite define injects it from package.json, so it can't drift again. A test guards the wiring, since a removed define would make the constant undefined rather than fail loudly.

stele-core — 39 tests, no database

It had none. That's why it reached main with live type errors, and why the injectivity fix was covered on the browser side but not the server side.

Coverage: the chain encoding (injectivity witnesses, replay verification, session binding, client-supplied-hash rejection), the /api/* perimeter (scheme handling, prefix/suffix tokens, fail-closed on unset and empty API_SECRET, preflight passes untokened, non-/api/* untouched), the schema invariants (integrityHash stripped, secretsDetected boolean-only), and the write-conflict classifier.

No service container needed — the chain is pure and the perimeter runs through Hono's request handler.

node:test, not vitest, deliberately. tsx is already a devDependency, so this adds zero packages to a security-sensitive service whose own review flagged install-time supply-chain risk.

Mutation-tested, not assumed: dropping the P2034 check fails 2 cases; letting an empty API_SECRET fall open fails 1; reverting the chain to a delimiter join fails 1. Baseline 39/39.

CI verified green on this branch at the time (tsc, stele-core) — note main has advanced since (#44, #46, dependabot merges), so CI needs to re-run here before merging.

🤖 Generated with Claude Code

Greptile Summary

This change derives the application version from package metadata, adds stele-core regression coverage, and updates the Babel resolution. The production build and version tests confirmed that the emitted bundle uses the package version and contains no unresolved version token. However, clean frozen root dependency installation now fails because the package override configuration and committed lockfile are incompatible with the repository's pnpm version. This prevents CI and other reproducible installs from proceeding.

Confidence Score: 4/5

Not safe to merge until the pnpm override configuration and lockfile are aligned, because the expected frozen installation path fails before builds or tests can run.

The installation failure was reproduced using the actual frozen pnpm command in an isolated worktree, with pnpm reporting the exact configuration mismatch. The version injection behavior was also exercised through a production build and passing version tests.

Files Needing Attention: package.json and pnpm-lock.yaml need attention; place the @babel/core override in a configuration location supported by pnpm 11 and regenerate the lockfile accordingly.

T-Rex Logs

What T-Rex did

• A reproducible frozen-install test was prepared and executed to validate the P1 finding, capturing inputs before execution, the installation failure with an ignored override, and a disposable frozen-lockfile reproduction runner.
• The production build path was run in isolated revisions and the version test reported 66 passing tests across 7 files, confirming the emitted bundle uses steleVersion 1.1.0 and that __STELE_VERSION__ is not present.
• A second proof was produced to corroborate the P1 finding, ensuring parallel coverage of the same finding.
• During a frozen install attempt, the override configuration caused a pnpm lockfile mismatch and the disposable worktree was removed, with input hashes remaining identical.
• The release‑version wiring was verified by inspecting the production bundle: steleVersion is 1.1.0 and __STELE_VERSION__ is absent; a noted caveat mentions a stale after-log and that a successful verifier run did not get captured in the artifact.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Frozen pnpm installation is blocked by ignored package override

   • Bug
     • A root frozen-lockfile installation fails with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH. pnpm 11.9.0 reports that pnpm.overrides in package.json is ignored, yet the checked-in lockfile has an overrides section, so CI and other reproducible installs cannot proceed.
   • Cause
     • package.json:84-87 stores the override in the deprecated/ignored pnpm package field, while pnpm-lock.yaml:7-8 retains it as active lockfile configuration. The runtime configuration and lockfile configuration therefore differ.
   • Fix
     • Move the override to pnpm 11’s supported configuration location and regenerate/commit pnpm-lock.yaml with the repository’s pinned pnpm version; alternatively align the supported active configuration with the lockfile before requiring frozen installs.

   _{Ran code and verified through T-Rex}

Prompt To Fix All With AI

### Issue 1
package.json:84-87
**Frozen pnpm installation is blocked by ignored package override**

`pnpm install --frozen-lockfile` now fails before dependencies are installed. pnpm 11.9.0 reports that it no longer reads `pnpm.overrides` from `package.json`, while the committed lockfile still records that override, and exits with `ERR_PNPM_LOCKFILE_CONFIG_MISMATCH`. Move the override to pnpm 11's supported configuration location and regenerate the lockfile so CI and clean reproducible installs can run.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix: resolve remaining advisory, derive ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Frozen pnpm installation is blocked by ignored package override

pnpm install --frozen-lockfile now fails before dependencies are installed. pnpm 11.9.0 reports that it no longer reads pnpm.overrides from package.json, while the committed lockfile still records that override, and exits with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH. Move the override to pnpm 11's supported configuration location and regenerate the lockfile so CI and clean reproducible installs can run.

Artifacts

Frozen-install inputs before execution

• A disposable worktree captured the override declaration, matching lockfile entry, and input hashes before the installation attempt, showing the configuration state being tested.

Frozen installation failure with ignored override

• The executed CI frozen installation reports that pnpm ignores package.json pnpm.overrides and exits 1 with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH, confirming the blocking mismatch.

Disposable frozen-lockfile reproduction runner

• The review-authored runner creates and removes an isolated Git worktree, executes the frozen install, and writes the paired command-output captures, so no repository dependency changes are retained.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: package.json
Line: 84-87

Comment:
**Frozen pnpm installation is blocked by ignored package override**

`pnpm install --frozen-lockfile` now fails before dependencies are installed. pnpm 11.9.0 reports that it no longer reads `pnpm.overrides` from `package.json`, while the committed lockfile still records that override, and exits with `ERR_PNPM_LOCKFILE_CONFIG_MISMATCH`. Move the override to pnpm 11's supported configuration location and regenerate the lockfile so CI and clean reproducible installs can run.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.