{
  "context": "Tests whether the agent turns a theme brief into a production-grade CSS token system, not just a list of obvious colors and fonts. The strongest answers create a stable semantic token architecture, eliminate raw reusable design values from component guidance, define exactly four recurring motifs, and explain variant, accessibility, responsive, and performance behavior as reusable implementation rules.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Semantic token architecture",
      "description": "The CSS custom properties use stable semantic role names for implementation-facing tokens, with any primitive palette layer kept separate from component usage. Component guidance should consume semantic tokens rather than literal color, font, or material names.",
      "max_score": 8
    },
    {
      "name": "Complete reusable value coverage",
      "description": "The :root block tokenizes all reusable design decisions needed to build components: color roles, RGB channels or alpha helpers, typography roles, type scale, spacing rhythm, radii, border widths, surface/depth, focus offsets, hit sizes, font weights, durations, easings, and transform distances.",
      "max_score": 14
    },
    {
      "name": "No raw design values in component guidance",
      "description": "Reusable component CSS rules and component-mapping guidance do not introduce raw design values such as hex colors, rgba() values, font family names, fixed spacing, numeric font weights, border widths, transform distances, focus offsets, or repeated opacity values unless those values are defined as tokens first. Do not penalize prose-only motif discussion or structural CSS keywords/literals that are not reusable design decisions.",
      "max_score": 14
    },
    {
      "name": "Interactive and accessibility states tokenized",
      "description": "Hover, focus-visible, selected, disabled, error, and high-contrast or contrast-sensitive states are represented with tokens or token-derived expressions, including minimum control hit size and a real prefers-reduced-motion override that changes motion tokens rather than only documenting intent.",
      "max_score": 12
    },
    {
      "name": "Signature motifs exactly four",
      "description": "The implementation notes identify exactly four named signature motifs. Palette, typography, geometry, texture, and motion may all matter, but they must be folded into those four motifs rather than scattered as extra motif-like ideas.",
      "max_score": 10
    },
    {
      "name": "Motifs mapped to recurring component behavior",
      "description": "Each motif is mapped to concrete behavior across multiple component families such as navigation, cards, forms, data tables, metadata labels, selected rows, empty states, and calls to action. The motif guidance should explain repeated behavior, not just decoration.",
      "max_score": 12
    },
    {
      "name": "Variant strategy with stable names",
      "description": "The token file or implementation notes state the default mode and show how light/dark mode or density variants override token values while preserving semantic token names. Acceptable mechanisms include prefers-color-scheme, a theme class, data-theme, or data-density selectors.",
      "max_score": 10
    },
    {
      "name": "Rules-based responsive identity",
      "description": "Responsive behavior is expressed through systematic token rules such as clamp() values, breakpoint token overrides, density changes, or invariant/recomposed motif behavior. Mobile and dense component views should keep the cartographic identity instead of falling back to page-specific exceptions; explicit component examples are helpful but not required if the invariant/recomposition rules are clear. Do not penalize literal values inside token declarations or breakpoint token overrides when component rules still consume stable token names.",
      "max_score": 8
    },
    {
      "name": "Core Web Vitals and performance constraints",
      "description": "The implementation notes explicitly address at least two performance constraints tied to Core Web Vitals or perceived responsiveness, such as LCP, INP, CLS, font loading, image loading, shadow/paint cost, animation compositing, or avoiding layout shift.",
      "max_score": 6
    },
    {
      "name": "Developer handoff completeness",
      "description": "The deliverables explain naming conventions, usage boundaries, motif behavior, and a production-readiness checklist clearly enough that a frontend developer can build new components without re-deriving values from the prose brief.",
      "max_score": 6
    }
  ]
}