Skip to content

fix: resolve remaining advisory, derive version from package.json, te… - #82

Open
mazze93 wants to merge 1 commit into
mainfrom
chore/babel-version-and-stele-core-tests
Open

mazze93 wants to merge 1 commit into
mainfrom
chore/babel-version-and-stele-core-tests

Conversation

@mazze93

@mazze93 mazze93 commented Sep 21, 2026

Copy link
Copy Markdown
Owner

…st stele-core

Dependabot. #42 cleared the three stele-core advisories, including the Hono CORS ReDoS, which mattered here because that middleware is what guards /api/*. The last one was @babel/core, transitive via eslint-plugin-react-hooks — lint and build time only, never in bundle.html, hence LOW. Pinned with a pnpm override to ^7.29.7 rather than left open; the lockfile now resolves 7.29.7.

Version. This was not an ambiguity, it was rot. v1.1.0 was tagged and released on 2026-06-06, package.json was bumped for it, and src/lib/version.ts was not — zero commits touched it between the two tags. Since STELE_VERSION is stamped into every narrative export as steleVersion, exports from the shipped 1.1.0 build claimed to be 1.0.0. package.json is authoritative because it is what the tag and release.yml publish against, so the constant is now injected from it by vite's define and cannot drift again. A test asserts the wiring holds, since a removed define would silently make it undefined rather than fail.

stele-core tests. It had none — the reason it reached main with live type errors, and the reason the injectivity fix was only ever covered on the browser side. 39 cases over the chain encoding, the /api/* perimeter, the schema invariants, and the write-conflict classifier. No database needed: the chain is pure and the perimeter goes through Hono's request handler, so the suite runs in CI without a service container.

node:test rather than 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 rather than assumed: dropping the P2034 check fails 2, letting an empty API_SECRET fall open fails 1, reverting the chain to a delimiter join fails 1. The suite discriminates.

What

Integrity

  • Group: 1 / 2 / 3 / 4 / 5
  • Tesserae resolved: T-xxx / none
  • Tesserae opened: T-xxx / none

Test

  • npx tsc --noEmit passes
  • Dev server starts clean

RetriggerConfidence Score: 3/5

Not safe to merge until the clean-checkout test failure and production perimeter coverage gap are addressed.

Fix All in Claude CodeFindings

  1. P1 Clean test setup fails
  2. P1 Production perimeter untested
Fix with agent prompt
### Issue 1
stele-core/test/serialization.test.ts:10
This import loads the sessions route, which initializes Prisma's generated client. That client is gitignored and neither installation nor the test script generates it, so a clean `npm ci && npm test` fails before the serialization tests run. This blocks clean-checkout verification until Prisma is generated separately; move the classifier into a dependency-free module or make generation part of the test setup.

### Issue 2
stele-core/test/auth.test.ts:14-25
`makeApp()` recreates a separate, reduced Hono stack instead of exercising the production `createApp()` wiring. When production CORS was placed after bearer authentication, these tests still passed while a real browser preflight returned a server error with no CORS headers, preventing authenticated browser clients from reaching the API. Test the production app directly, or share the complete perimeter setup.

---

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

This change adds stele-core coverage for serialization failures and bearer/CORS behavior, but it is not safe to merge yet. The new core test command fails from a clean checkout without generated Prisma output, and the CORS/authentication test can pass even when the production browser-access perimeter is broken.

Reviews (1) · Last reviewed commit: "fix: resolve remaining advisory, derive ..."

…st stele-core

**Dependabot.** #42 cleared the three stele-core advisories, including the Hono
CORS ReDoS, which mattered here because that middleware is what guards /api/*.
The last one was @babel/core, transitive via eslint-plugin-react-hooks — lint
and build time only, never in bundle.html, hence LOW. Pinned with a pnpm
override to ^7.29.7 rather than left open; the lockfile now resolves 7.29.7.

**Version.** This was not an ambiguity, it was rot. v1.1.0 was tagged and
released on 2026-06-06, package.json was bumped for it, and src/lib/version.ts
was not — zero commits touched it between the two tags. Since STELE_VERSION is
stamped into every narrative export as `steleVersion`, exports from the shipped
1.1.0 build claimed to be 1.0.0. package.json is authoritative because it is
what the tag and release.yml publish against, so the constant is now injected
from it by vite's `define` and cannot drift again. A test asserts the wiring
holds, since a removed define would silently make it undefined rather than fail.

**stele-core tests.** It had none — the reason it reached main with live type
errors, and the reason the injectivity fix was only ever covered on the browser
side. 39 cases over the chain encoding, the /api/* perimeter, the schema
invariants, and the write-conflict classifier. No database needed: the chain is
pure and the perimeter goes through Hono's request handler, so the suite runs
in CI without a service container.

node:test rather than 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 rather than assumed: dropping the P2034 check fails 2, letting
an empty API_SECRET fall open fails 1, reverting the chain to a delimiter join
fails 1. The suite discriminates.

import { describe, it } from "node:test";
import assert from "node:assert/strict";
import { isSerializationFailure } from "../src/routes/sessions.js";

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Clean test setup fails

This import loads the sessions route, which initializes Prisma's generated client. That client is gitignored and neither installation nor the test script generates it, so a clean npm ci && npm test fails before the serialization tests run. This blocks clean-checkout verification until Prisma is generated separately; move the classifier into a dependency-free module or make generation part of the test setup.

Artifacts

Clean-install reproduction script

  • The executed script copies only tracked and unignored package files into a temporary directory, removes generated output, and runs the clean-install test path; it captures the missing-client condition.

Clean-install failure output

  • The captured command output shows npm ci exit 0 followed by npm test exit 1 with ERR_MODULE_NOT_FOUND from lib/prisma.ts for generated/prisma/client.js; the claimed failure is reproducible.

Generated-client verification script

  • The executed script repeats the isolated clean install, supplies a validation-only datasource URL for Prisma generation, and runs the identical test command; generation restores the module required by the new test import.

Generated-client passing output

  • The captured output shows Prisma Client 7.9.1 generation, generated client presence, and npm test exit 0 with 39 passing tests; Prisma generation resolves the load failure.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: stele-core/test/serialization.test.ts
Line: 10

Comment:
**Clean test setup fails**

This import loads the sessions route, which initializes Prisma's generated client. That client is gitignored and neither installation nor the test script generates it, so a clean `npm ci && npm test` fails before the serialization tests run. This blocks clean-checkout verification until Prisma is generated separately; move the classifier into a dependency-free module or make generation part of the test setup.

---

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

Fix in Claude Code

Comment on lines +14 to +25
function makeApp() {
const app = new Hono();
app.use("/api/*", cors({
origin: ["http://localhost:5173"],
allowMethods: ["GET", "POST", "PATCH", "OPTIONS"],
allowHeaders: ["Content-Type", "Authorization"],
}));
app.use("/api/*", requireBearer);
app.get("/api/thing", (c) => c.json({ ok: true }));
app.get("/health", (c) => c.json({ status: "ok" }));
return app;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Production perimeter untested

makeApp() recreates a separate, reduced Hono stack instead of exercising the production createApp() wiring. When production CORS was placed after bearer authentication, these tests still passed while a real browser preflight returned a server error with no CORS headers, preventing authenticated browser clients from reaching the API. Test the production app directly, or share the complete perimeter setup.

Artifacts

Production wiring verification script

  • The captured script temporarily moves production CORS after authentication, runs the isolated test and production endpoint probes, and restores the source file; it demonstrates the exact validation method.

Baseline production preflight output

  • The baseline run shows 11 passing auth tests and a production OPTIONS request returning HTTP 204 No Content with the required CORS headers; production wiring works before mutation.

Production wiring divergence output

  • The mutation run shows the duplicate auth tests still pass 11/11 while the production OPTIONS request returns HTTP 500 with no CORS headers; the test misses a browser-blocking production regression.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: stele-core/test/auth.test.ts
Line: 14-25

Comment:
**Production perimeter untested**

`makeApp()` recreates a separate, reduced Hono stack instead of exercising the production `createApp()` wiring. When production CORS was placed after bearer authentication, these tests still passed while a real browser preflight returned a server error with no CORS headers, preventing authenticated browser clients from reaching the API. Test the production app directly, or share the complete perimeter setup.

---

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

Fix in Claude Code

@greptile-apps

greptile-apps Bot commented Sep 21, 2026

Copy link
Copy Markdown

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

  • P1 Serialization test requires ungenerated ignored Prisma client after a clean install

    • Bug
      • stele-core/test/serialization.test.ts:10 imports isSerializationFailure from the sessions route. Loading that route imports stele-core/lib/prisma.ts:2, which imports ../generated/prisma/client.js. The generated/ directory is ignored and package.json has no lifecycle hook or test pre-step that invokes Prisma generation. Consequently, a clean npm ci && npm test fails before the serialization test can execute.
    • Cause
      • The unit test imports a route module that has a top-level persistence-client dependency, while the Prisma client is generated into gitignored generated/ and is not generated by the install or test scripts.
    • Fix
      • Make the test dependency-free by moving isSerializationFailure to a standalone utility module and importing that utility from both the route and test; alternatively, add a reliable Prisma generation step (including required configuration) before tests. The former preserves unit-test isolation.
  • P1 Auth test does not cover production CORS/auth middleware wiring

    • Bug
      • makeApp() in stele-core/test/auth.test.ts:14-25 recreates a reduced Hono stack. When production createApp() was temporarily mutated so CORS was placed after requireBearer, the test suite remained green (11 passing tests), but an actual production-app preflight to OPTIONS /api/sessions returned HTTP 500 with {"error":"server_not_configured"} and no CORS headers. Baseline production behavior was HTTP 204 No Content with the expected allowed origin and Authorization header.
    • Cause
      • The test instantiates its own app and middleware configuration instead of importing and exercising createApp() from stele-core/src/server.ts; changes to production middleware ordering/configuration therefore do not affect the test fixture.
    • Fix
      • Replace the hand-built makeApp() fixture with createApp() (or add a focused integration test that calls createApp().request(...)) and assert the actual CORS preflight contract against a real routed /api/* endpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant