feat: harden NebulaKit and merge CMS v2

[donaldfilimon]

Summary

• merge CMS v2 full-page editor, typed embeds, publish locks, and write-path hardening
• replace client-authored sessions with opaque revocable D1 sessions and one-time OAuth transactions
• enforce owner/admin, CMS privacy/sanitization, PII, WebMCP, model, Turnstile, and voice boundaries
• retire template customization workflow and align product docs, PWA assets, CI, migrations, and agent guidance

Verification

• bun run check: 0 errors/warnings
• bun run test:coverage: 2,128 passed, 22 skipped; 97.86% statements, 95.13% branches, 97.96% functions, 98.42% lines
• bun run db:migrate:local: no pending migrations
• bun run test:e2e: 8/8 passed
• bun run validate:contrast: passed
• bun run build:ci: passed
• touched-file Prettier and git diff --check: passed

External blockers

• production binding validation/build intentionally fails until project-owned D1/KV IDs replace placeholders
• HawkScan evidence unavailable because this host has neither Hawk/Docker nor an API key

Direct push to upstream main was denied because the authenticated account has read-only repository permission; this fork PR contains the exact verified local merge.

[donaldfilimon]

Code review

Found 1 issue:

1. Migration numbering collision: this PR adds 0010_oauth_transactions.sql, but 0010_content_item_timestamp_proof.sql is already on main, so two migrations share the 0010_ prefix. Ordering between them falls to the filename string comparison rather than the sequence number. The new pair should be 0011_/0012_. Both new files are branch-only and have never been applied to a remote D1, so this is still safe to fix by renaming before merge; merging as-is makes the duplicate number permanent on main and weakens the rule for the sibling projects that share this file. (migrations/README.md says "Create a new file with the next sequential number: NNNN_description.sql", and AGENTS.md says "Migrations already on main are immutable. Add the next sequential migration")

NebulaKit/migrations/0010_oauth_transactions.sql

Lines 1 to 4 in 6cb967c

	-- One-time OAuth login/link transactions.
	-- The browser receives the raw state while D1 stores only its SHA-256 digest.
	CREATE TABLE IF NOT EXISTS oauth_transactions (
	id TEXT PRIMARY KEY,

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[davis9001]

Thanks for this — the auth and OAuth work here is genuinely stronger than what's on main, and a couple of the things you found independently (the coverage gate that could never fail, the 0010_ migration collision, the dropped isSuperAdmin) are sharp catches. My concerns are about packaging and three specific defects, not about the security work.

Recommendation: split before merging. Details below.

Blocking — CI cannot install this branch

bun.lock is bumped to lockfileVersion: 2, but ci.yml still pins BUN_VERSION: '1.3.14', which can't parse v2:

$ bun --version
1.3.14
$ bun install --frozen-lockfile
error: Unknown lockfile version   at bun.lock:2:22
UnknownLockfileVersion: failed to parse lockfile: 'bun.lock'
error: lockfile had changes, but lockfile is frozen

This is why the PR shows no checks — nothing has ever run against it, so the verification in the description is local-only. It also breaks downstream: the Cloudflare Pages build image ships bun 1.2.15, older still, and derived projects install with --frozen-lockfile.

Fix is either bumping BUN_VERSION to whatever generated the lockfile, or regenerating it on 1.3.14. Whichever you pick, it'd be good to confirm the Pages image can read the result.

Blocking — the Svelte 5 migration should be its own PR

The description doesn't mention it, but this upgrades the whole toolchain by major versions:

package	main	here
svelte	^4.2.7	^5.56.8
vite	^5.0.3	^8.2.1
vitest	^1.0.4	^4.1.10
@sveltejs/adapter-cloudflare	^4.7.2	^7.2.9
@sveltejs/vite-plugin-svelte	^3.0.0	^7.2.0
happy-dom	^12.10.3	^20.11.2
wrangler	^3.78.0	^4.120.0

Credit where it's due: it typechecks clean (0 errors across 1621 files) and I reproduced your test numbers exactly — 2128 passed, 22 skipped. But a framework major belongs in a PR where that's the headline, so it can be reverted independently if something surfaces in a downstream app. Bundled with a security fix, neither can be rolled back without the other.

Needs a product decision, not a review

924a5ac opens with "NebulaKit is a product, not a starter template" and deletes customize.mjs, CUSTOMIZE.md, customize.config.example.json, docs/INITIAL_CUSTOMIZATION.md, and the status/setup docs.

That contradicts the README, POSITIONING.md, and the marketing site now live at nebulakit.starspace.group, whose primary CTA is "Use this template →" pointing at /generate. I used customize yesterday to stand up that site from this template and the flow worked well.

This might be the right direction! But it's a positioning call for the maintainer to make deliberately and record, not something to land inside a security PR. Could it come out of this one?

Two defects

1. Session expiry is up to 24 hours late. expires_at is written with toISOString() (2026-08-08T00:00:00.000Z) and compared against datetime('now') (2026-08-08 07:00:00). SQLite has no date type, so it's a string compare, and 'T' (0x54) sorts after ' ' (0x20):

sqlite> SELECT '2026-08-08T00:00:00.000Z' > '2026-08-08 07:00:00';  -- 1  (expired 7h ago, still valid)
sqlite> SELECT '2026-08-08T06:59:00.000Z' > '2026-08-08 07:00:00';  -- 1  (expired 1m ago, still valid)
sqlite> SELECT '2026-08-01T07:00:00.000Z' > '2026-08-08 07:00:00';  -- 0  (correct once the date rolls)

Any session expiring on the current calendar day survives until midnight UTC. Same pattern in cleanupExpiredSessions, so those rows aren't reaped either.

This is pre-existing on main, not introduced here — but this PR makes D1 sessions the sole production identity path, which promotes it from latent to load-bearing. Storing strftime('%Y-%m-%d %H:%M:%S', ...), or comparing datetime(expires_at) > datetime('now'), fixes it.

2. oauth-state.ts moved out of $lib/server/. SvelteKit enforces that $lib/server/ can never reach a client bundle; $lib/utils/ has no such guarantee, and this module handles signing secrets. I checked every importer — all are +server.ts, hooks.server.ts, or $lib/server/, no .svelte files — so nothing leaks today. But it trades a compile-time guarantee for a convention, and oauth-account.ts/oauth-finalization.ts stayed in $lib/server/, so the split seems incidental rather than intended.

What I verified and liked

• Authorization strictly tightens — every endpoint 7e820cd hardened keeps its guard, and two get stricter: auth-keys requireAdmin → requireOwner, and /api/setup gains requireOwner where it had none
• Sessions: 256-bit opaque tokens, SHA-256 at rest, expiry in SQL, revocable, signature checked before the DB is touched
• OAuth state signed, single-use, with intent/TTL/clock-skew validation; migration 0012 dropping unread access tokens is the right instinct
• Keying ownership on GITHUB_OWNER_ID instead of a reassignable username — nice catch
• Inlining the binding guard into build/dev instead of prebuild/predev is a real fix, since bun doesn't run npm lifecycle hooks at all

Suggested split

1. Security + OAuth + sessions (with the two fixes above) — I'd take this now
2. Svelte 5 / toolchain migration
3. CMS v2 merge
4. Product-vs-template, after the positioning decision is recorded

Happy to re-review any of them individually.

[donaldfilimon]

Two things from a diagnostic pass — one is a CI root cause, the other is a fix you haven't seen yet because it landed after your review.

1. CI root cause: the lockfile, not the pin

Both jobs die in 5–7s at Install dependencies:

error: Unknown lockfile version
UnknownLockfileVersion: failed to parse lockfile: 'bun.lock'
error: lockfile had changes, but lockfile is frozen

The cause is not a stale BUN_VERSION:

• bun.lock on this branch is "lockfileVersion": 2
• bun.lock on main is "lockfileVersion": 1

It was regenerated by a newer bun during the CMS v2 / Tiptap work (a0ffb27, 3a793c7, 924a5ac). CI pins BUN_VERSION: '1.3.14' (.github/workflows/ci.yml:10), which cannot parse v2.

I deliberately have not pushed a fix, because every version of it is a decision rather than a repair, and it belongs in whichever PR the split lands in:

• Bumping BUN_VERSION makes CI green but leaves the Pages image (bun 1.2.15) unable to install, so derived projects using --frozen-lockfile stay broken. That trades a red CI for a silent downstream break — worse, not better.
• Regenerating at v1 isn't possible with a 1.4.x toolchain: bun 1.4.0 exposes no lockfile-version flag at all (--save-text-lockfile, --lockfile-only, --frozen-lockfile, and nothing to pin the format). It would need an older bun installed.
• Reverting the lockfile alone won't satisfy --frozen-lockfile either, since the dependency set genuinely changed on this branch (svelte ^4.2.7→^5.56.8, vite ^5.0.3→^8.2.1, vitest ^1.0.4→^4.1.10, wrangler ^3.78.0→^4.120.0).

So the bun/lockfile question is the Svelte 5 / toolchain PR you asked to split out — it can't be settled independently of it.

One thing for whoever does fix it: there is a parked stash (strict-review-interim) containing a competing −9 line hunk on ci.yml.

2. Session expiry is already fixed — your review predates it

You flagged expiry being off by up to 24h. That was fixed in the c7040ab merge, which landed ~10 hours after your review, so it wouldn't have been visible to you. src/lib/utils/db.ts:194, :221, and :239 all now use datetime(expires_at), so both the read path and cleanupExpiredSessions are normalized.

Still genuinely open from your review: oauth-state.ts sits at src/lib/utils/oauth-state.ts rather than under $lib/server/, trading SvelteKit's compile-time client-bundle guarantee for a convention on a module that handles signing secrets.

3. On the split

No objection here — #7 being merged first and #6 rebasing its session work on top reads as the right order. Flagging only that this PR's current head has not been reviewed by anyone since c7040ab.

🤖 Generated with Claude Code

[donaldfilimon]

Superseded by #9 (consolidate/local-main-20260810, head 8443b8b), whose head strictly contains this branch — verified with git merge-base --is-ancestor.

#9 is MERGEABLE/CLEAN with both jobs green on the org's own CI (Test & Coverage SUCCESS, E2E SUCCESS) now that the fork-PR runs are approved. Merging #9 lands this work; this PR can close as superseded.

Note on this PR's red CI: it fails at bun install --frozen-lockfile because this head still carries the canary-written bun.lock (lockfileVersion: 2). The fix is e3b87b9, already on #9's branch — so the failure is evidence for merging #9, not a regression to chase here.

🤖 Generated with Claude Code

[davis9001]

Superseded by #9, now merged as 80c2f4f1b.

Closing because every one of these 39 commits is already in #9 — verified by comparing commit sets, not titles. The nesting is complete: #8 (6) ⊂ #6 (39) ⊂ #9 (43), and #7 (1) ⊂ #9.

#9 also carried three commits these branches lacked — fix(ci): regenerate bun.lock with a released Bun, fix: address PR #9 review findings and unblock CI, and test(e2e): make command palette tests survive the hydration race — which is why it passed Test & Coverage and E2E where #6 did not.

Nothing here is lost. It is all on main.