Context
Evaluation of the @siemens-iris/iris-core package (0.10.0–0.11.0) as consumed by this sandbox: can consumers load *specific parts* of iris-core rather than the full bundle, can they *extend or override* themes, and what CSS-architecture patterns should iris-core adopt from the dual-architecture POC and Siemens iX? This is the sandbox-side validation for the CSS organization & component-token refactor (DESYS-434), tracked as DESYS-1286 / DESYS-1287 / DESYS-1140.
The direction is **additive adoption into iris-core, using the iris namespace** — dual (shadow-DOM + light-DOM) output from a single SCSS source, SUIT class naming, a color-only component-token tier, token cleanup, and iX-sourced status colors — **without merging the POC, dropping Stencil/Shadow DOM, or introducing a separate dual namespace.**
Findings
The full research corpus and the executable build plans live in research/ — start with research/README.md (the folder guide) and research/BUILD-PLANS.md (the consolidated roadmap). Summary of the evaluation:
- **Selective loading — partial today.** Per-component JS (
./components/*.js + the Stencil lazy
loader) and granular SCSS layers (./scss/*) are selectively loadable; compiled CSS is monolithic (./iris.css only), and its bytes are dominated by token duplication (663 semantic custom properties emitted 5×).
- **Theme extension — supported, no first-class API.** Override
--iris-* custom properties (they
inherit through the shadow boundary) or compose the SCSS theme-* mixins; there is no public "register a named theme" surface.
- **Biggest gap — the near-absent component-token tier.** iris-core ships ~0 component tokens vs
Siemens iX's ~1,529; restyling a single component means reverse-engineering ~40 semantic dependencies. The verdict is **GO** on adopting the POC's $namespace dual-output model and a color-only component-token tier, sequenced first, phased.
Entry
interactive/iris-css-overview.html is the iris-core CSS-delivery overview (monolithic-vs-per-file delivery). The interactive comparisons sit beside it in interactive/:
interactive/ix-css-overview.html — how Siemens iX delivers CSS/theme/component files separately.interactive/iris-ix-comparison.html — side-by-side iris vs iX token architecture, with thealignment-path roadmap (DESYS-1287).
interactive/dual-iris-ix-comparison.html, interactive/dual-output-architecture.html,interactive/dual-token-architecture.html, interactive/dual-suitcss-conventions.html — the dual-architecture POC demos (the $namespace dual-output mechanism, three-tier tokens, and SUIT conventions the research recommends iris-core adopt under the iris namespace).
Keep-in-sync rule — build-plan files ↔ interactive overview
The demo entry [interactive/build-plan-overview.html](interactive/build-plan-overview.html) walks the iris-core plan (research/build-plan-iris-core/ P0–P7) and mirrors each phase's file tables and pipeline. It therefore drifts if a plan file changes without it.
**Rule:** when any research/build-plan-iris-core/pN-build-plan.md (or the overview page itself) changes, update interactive/build-plan-overview.html in the **same change**, then re-run npm run generate:demos from the repo root so the demo index reflects it. This is the interactive analogue of the research-corpus link-integrity rule — the page is a rendering of the plan, not a second source of truth.