v2 seam: extract the CSS layer behind a preset interface

[Schmandarine]

Groundwork for create --preset=bootstrap|tailwind|scss.

Not three starters. One core with interchangeable CSS bridges — the block factory, the ten skills and the deploy toolchain never needed to know which framework was chosen. CSS framework × block implementation is a 2-axis matrix, not a list of products; shipping three forks would bake the wrong mental model into the repo permanently.

This is also the backwards-compatibility mechanism. components/gutenberg-blocks.scss (258 lines, 11 !important) cannot be deleted — delivered sites depend on that contract. Presets are the only way to change the layout model without breaking them: bootstrap keeps the bridge verbatim, indefinitely, while new projects on a token-native preset never need most of it.

Acceptance test — this is the whole point

--preset=scss ships without touching a single file in AGENTS/, packages/cli/tools/, or my-acf-blocks/loader.php.

If that fails, the abstraction is in the wrong place — and three separate starters would have been three maintenance burdens.

• Define what a preset owns: the SCSS layer, the variables bridge, the class-output convention, the theme.json emitter
• Extract Bootstrap into a preset with no behaviour change
• Modularise our own SCSS with @use/@forward — moved here from Stale pre-migration repo URLs and package name after move to brmbh/wordpress #5, because the justification is clean module boundaries for extraction, not the Dart Sass deprecation. Our layer is small: _tokens, _variables, _wp-css-variables, _globals, _fonts, _grid-utilities, components/
• Add scss
• Tailwind only after the seam holds — v4 is CSS-first, so it is a token emitter rather than a config generator

Sizing note

The Bootstrap dependency is shallower than it looks: ~45 class usages across 12 PHP files (container 11x, row 1x, zero col-*) and one JS import (Collapse, for the navbar). The navbar is the only real component dependency.

Prior art in our own vault

Semantic Framework's architecture/target-environments.md already specifies this build-output matrix (Bootstrap-extending / standalone / Tailwind config), and ADR 002 already names the cost: "doubles the test surface: both builds need visual parity." Worth reading before starting. Note also that _grid-utilities.scss is already a CUBE Composition layer in all but name.

Agent surface — the largest of the eight

Every AGENTS/*.md skill that mentions Bootstrap classes or the SCSS layer becomes preset-aware, and /create-block must emit different class conventions per preset. If that turns out to mean editing all ten skills, the abstraction is wrong — which is what the acceptance test measures.

---

Context: vault .../Development/Stack-Assessment-2026.md §6 and §7