Read a comment in a tenant theme as a comment, not as something the theme defines

[kevin9327]

Put the line a hand-written stylesheet opens with at the top of a tenant package's theme.css:

/* Acme brand colours. Regenerate from the design tokens, do not hand-edit. */
:root { --primary: oklch(0.32 0.09 250); }

and the deployment does not start. loadTenantPackage is a top-level await in
server/src/index.ts, so the throw comes out before anything is listening. What it says is:

comment above the blocks:            Tenant theme may only define :root and .dark blocks
comment inside a block:              Tenant theme variable /* the one colour */
                                       --primary is not an approved theme variable
trailing comment on a declaration:   Tenant theme variable /* flat * is not an approved theme variable

(verbatim, from calling validateThemeCss on origin/main.)

None of those sentences mentions a comment, so the thing to remove is not in the message. The middle
one quotes the comment back as the name of a variable.

Why

docs/configuration.md states the rule as: "Theme CSS may define only :root and .dark blocks,
approved theme variables, and no @import or url()." Every clause of that is about what a theme
defines. A comment defines nothing — but validateThemeCss applies all three checks to the raw
file, so a comment is read as a definition:

• Above or between the blocks, it survives css.replace(/(:root|\.dark)\s*\{[^{}]*\}/g, "") and lands
  in remaining, which is the test for a second selector.
• Inside a block, body.split(";") hands it to the variable loop as a declaration, and it is
  refused under whatever the comment happens to say.

The fix

One line, before the three checks: take the comments out, then read what is left as definitions.

Removing them first is stricter than leaving them, not weaker, which is the part worth checking:

• A comment wedged into the middle of url makes something a browser does not tokenise as a URL, and
  the url\s*\( test did not read it as one either. With the comment gone, both do, and it is
  refused.
• A comment that is never closed does not match, so it is not removed, stays as the nonsense it is,
  and is still refused.
• What a comment cannot do here is hide anything: what is left once they are gone is exactly what a
  browser would act on.

No doc change: the sentence in docs/configuration.md was already true, and is still true.

Measured

bun test server/tests/tenant-package.test.ts

• Against origin/main with only the new tests applied: 30 pass, 19 fail.
  • The three new cases fail: accepts a comment above the blocks, accepts a comment inside a block, accepts a comment between the blocks.
  • The other 16 are pre-existing on this machine — this file's describes for package
    synchronisation talk to Postgres, and there is none here. They fail identically on unmodified
    main (29 pass, 16 fail before any of my tests were added).
• With the change: 33 pass, 16 fail — the same 16 Postgres failures, and nothing else.

The fourth new test, still refuses what a comment is wrapped around, is the guard against
over-correcting and passes both before and after: a url() in a value is still refused, a comment
followed by body { } is still refused as a selector, and an unterminated comment is still refused.
So do the two theme tests that were already there.

Also run, all green:

• bun run --filter server typecheck — exit 0
• bunx biome check on both changed files — clean

Note on the CHANGELOG

A deployment that would not start now starts, so there is an entry. It goes at the top of
## Unreleased, the one line every entry goes at, so it will conflict with any other PR open against
that anchor. Happy to rebase whenever it suits you.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[davidmckayv]

Deep-reviewed against live code (correctness, governance, no vendor/secret/scale issues). Composed build+tests green. CHANGELOG/format rebase on CI-validated substance.