tegwick
36f7b9f7b9
A deliberately-unfinished second adapter that consumes the same ir/ and honours the same adapters/ADAPTER_CONTRACT.md (token full-gen + write-once stubs + drift roll-up shape + exit codes), with zero changes to ir/. Every IR component is 'new' for a fresh stack → 10 class stubs + tokens.css (80 props). Not a usable plain-CSS kit — the deliverable is confidence the boundary holds so the architecture can be lifted into a coulomb-level tool later. make adapt-plain-css. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
plain-css adapter — second-adapter smoke (WHYNOT-WP-0002 · T10)
This is not a finished stack. It exists to prove the IR/adapter boundary: that a second, non-Lit adapter can consume the same
ir/and honour the sameadapters/ADAPTER_CONTRACT.md. The deliverable is confidence in the seam, so the architecture can later be lifted into a coulomb-level tool — not a usable plain-CSS component kit.
Run with make adapt-plain-css (adapters/plain-css/adapt.mjs).
What it proves
| Contract concern | This adapter | Same as Lit? |
|---|---|---|
Input is ir/ only |
reads ir/tokens.json + ir/components/*.json |
✓ identical inputs |
| Tokens fully generated | → adapters/plain-css/tokens.css (CSS custom properties, deterministic no-op re-run) |
✓ same discipline, different target |
| New component → stub | write-once class stub adapters/plain-css/stubs/<tag>.css (base + variant modifier classes from the contract) |
✓ write-once, into a staging dir |
| Drift roll-up | adapters/plain-css/_report.json in the contract's report shape (stack, generatedAt, components[]) |
✓ portable shape |
| Exit codes | 0 ok · 2 usage · 3 new/drift · 5 internal |
✓ shared convention |
Because plain-CSS has no hand-authored source, every IR component reports
status: "new" and gets a stub — exactly the contract's new-component path. That a
totally different stack reuses the same IR, the same report shape, and the same exit
codes — with zero changes to ir/ — is the proof the boundary holds.
What it deliberately does NOT do
No real CSS appearance, no parity, no full component set, no integration into the
repo's build. Finishing a plain-CSS (or Vue/Svelte/…) stack is future work; the seam
is what T10 validates. See DesignSystemIntroduction.md §5.1 and the Lit reference
adapter (adapters/lit/) for the full implementation.