CI: verify the generated dijit-dotcms/dotcms.css matches its SCSS source

Description

dotCMS/src/main/webapp/html/css/dijit-dotcms/dotcms.css is a generated artifact committed to git. It is produced by:

nx run dotcms-scss:publish
# sass libs/dotcms-scss/jsp/scss/dotcms.scss ../dotCMS/src/main/webapp/html/css/dijit-dotcms/dotcms.css --no-source-map

Nothing verifies that the committed file matches what compiling the SCSS actually produces. Because the artifact is what ships and the SCSS is what everyone reads, editing the CSS directly "works" — the change goes live and nobody notices the source no longer agrees with it. The next person to run publish silently reverts it.

This was found while working #32954.

This is not hypothetical. Of the 8 commits that touched dotcms.css in the last 12 months, 3 did not touch the SCSS source at all:

The repo already has this exact convention for a different generated file — openapi.yaml is auto-generated and "the CI verifies the committed file matches what the build produces" (see CLAUDE.md). dotcms.css should be held to the same standard.

Second, related problem: stale build output committed by accident

core-web/libs/dotcms-scss/jsp/css/ contains three tracked files:

core-web/libs/dotcms-scss/jsp/css/dotcms.css
core-web/libs/dotcms-scss/jsp/css/document.css
core-web/libs/dotcms-scss/jsp/css/pattern-library.css

These are output of the dotcms-scss:serve watch target (sass .../scss/:.../jsp/css --watch), committed by accident and never gitignored. They are 10 months stale (last touched 76fb121bdd, 2026-04-24) and dotcms.css there now differs from the current source by 10,382 lines. Nothing consumes them — they are pure noise in diffs and a trap for anyone who greps the repo and finds the wrong copy of a rule.

These do not need a sync check. They need to be deleted and ignored.

Acceptance Criteria

• CI verifies that dotCMS/src/main/webapp/html/css/dijit-dotcms/dotcms.css matches the result of compiling libs/dotcms-scss/jsp/scss/dotcms.scss
• On mismatch the build fails and the job output shows the actual diff, plus the command to fix it (nx run dotcms-scss:publish)
• The check only runs when it can matter — the SCSS sources, the committed CSS, or the sass version changed — so unrelated PRs are not slowed down
• The check pins/derives the same sass version the publish target uses, so CI and local runs cannot disagree (see Additional Context — this is load-bearing)
• core-web/libs/dotcms-scss/jsp/css/{dotcms,document,pattern-library}.css are deleted from the repo
• core-web/libs/dotcms-scss/jsp/css/ is added to .gitignore so the serve target cannot re-commit it
• Deleting those files does not break nx run dotcms-scss:serve (it recreates them locally on demand)
• A PR that edits dotcms.css without regenerating it from SCSS fails CI — verified with a deliberate test PR
• A PR that edits the SCSS and regenerates the CSS passes CI

Priority

Medium

Additional Context

The sass version is load-bearing — do not skip that AC.

Root sass is pinned at 1.56.2 (Nov 2022). Compiling the same unchanged source with 1.101.0 produces 9 different lines, all serialization-only:

• darken($red, 10%) ×2 → #b02023 becomes rgb(175.6812749004, 32.3187250996, 34.8047808765) (rounds to the same colour)
• hsla(230deg, …) ×7 → hsla(230, …) (1.56 was appending the unit; deg is the default)

If CI compiles with a different sass than the developer's publish run, every PR fails on a diff nobody introduced. Note also that the root sass CLI is used by exactly three commands, all in libs/dotcms-scss/project.json, all compiling this bundle — Angular resolves its own via @angular/build and Stencil via @stencil/sass, so this version is effectively private to this check.

Verified starting state: as of 688afe8059, compiling dotcms.scss with sass 1.56.2 reproduces the committed dotcms.css byte for byte. The check can be introduced without a reconciliation commit first.

Not in scope: the @import → @use migration of this bundle — that is #32954. The two are independent; this check is worth having regardless of when that migration lands, and will in fact make it safer to verify.

Start with libs/dotcms-scss/project.json to confirm the publish command and Sass version, then read CLAUDE.md for the existing openapi.yaml verification convention. Inspect the committed dotCMS/src/main/webapp/html/css/dijit-dotcms/dotcms.css and the three files under core-web/libs/dotcms-scss/jsp/css/. Done means the CI check reports diffs and its regeneration command, stale outputs are ignored and removed, and both mismatch and regenerated cases are verified.