Commit Graph

6 Commits

Author SHA1 Message Date
Bernt 303b79d4cd docs: Update Input/Select/Card to semantic aliases + raise maturity to 83%
- RFC-002 Input:
  - Token Dependencies updated to semantic aliases with primitives
  - All tokens now map through color.surface, color.border, color.text, color.status
  - No direct color references (e.g., semantic-red-500 → color.status.danger)
  - Helper/error text uses semantic tokens

- RFC-003 Select:
  - Token Dependencies updated to semantic aliases with primitives
  - Dropdown, option, and error states use semantic tokens
  - Selected option uses color.action.primary at 10% opacity
  - No direct color references

- RFC-004 Card:
  - Token Dependencies updated to semantic aliases with primitives
  - Surface, border, text hierarchy use semantic tokens
  - Shadow tokens mapped to elevation system
  - No direct color references

- COMPLIANCE_MATRIX.md:
  - Input: 33% → 83%
  - Select: 33% → 83%
  - Card: 33% → 83%
  - All now have Governance , Tokens , Motion , Accessibility , AI 

Rationale: Semantic model first. Components never reference primitives.
Token contracts (purpose, allowed, forbidden) ensure correct usage.
Dark mode implementable via token swap without component changes.
2026-07-02 11:04:00 +00:00
Bernt 3335edeed8 docs: Semantic Color System v1.0
- SEMANTIC_COLOR_SYSTEM.md (v1.0, DRAFT):
  - Three-layer architecture: Primitive → Semantic → Component Alias
  - Naming convention: color.{category}.{role}
  - Semantic tokens with contracts (purpose, allowed, not allowed):
    - Action colors (primary, secondary, ghost, disabled)
    - Surface colors (default, raised, overlay, inverted)
    - Text colors (primary, secondary, muted, inverted, link)
    - Border colors (default, focus, error, success)
    - Status colors (success, warning, danger, info)
    - Brand colors (primary, secondary)
  - State Matrix: all states for Button, Input, Select, Card with
    background, border, text, icon mappings
  - Component Aliases: button.*, input.*, select.*, card.* mapped
    to semantic tokens
  - Dark Mode: token value swapping without component code changes
  - Validation: component token audit (0 direct color references)

- COMPLIANCE_MATRIX.md: Semantic Color System 70%

Rationale: Semantic model first, not colors. Components never reference
primitives directly. Every token has a contract (purpose, allowed, forbidden).
Dark mode via token swap. State matrix derived from existing components.
2026-07-02 10:53:42 +00:00
Bernt 13fea4a301 docs: Brand Palette + Grid & Elevation + Compliance Matrix update
- BRAND_PALETTE.md (v1.0, DRAFT):
  - Token-specifikation (not a color list)
  - Semantic brand tokens: primary, secondary, tertiary
  - 12-step scale (50-950) with defined purposes
  - Usage rules: where brand colors are used (logo, buttons, focus, links)
  - Usage rules: where brand colors are NOT used (status, data viz, maps)
  - Dark mode strategy: shift lighter in dark mode
  - Contrast requirements: WCAG AA 4.5:1 for text, 3:1 for large text/focus
  - Placeholder values: awaiting brand color definition from Erik/Landvex
  - Token dependencies from components: Button, Input, Select, Link, Loading, Progress
  - Governance: no new brand colors without Architecture Review

- GRID_ELEVATION.md (v1.0, DRAFT):
  - Spacing scale: 13 primitive tokens (space-0 to space-12)
  - Semantic spacing: gap-xs to gap-xl, padding/margin tokens
  - Grid system: 12-column, responsive (4/8/12 columns)
  - Common layouts: full, two-column, three-column, four-column, sidebar, asymmetric
  - Border radius: 6 tokens (none to full) with component mapping
  - Elevation system: 5 shadow levels + 8 z-index levels
  - Component elevation mapping: resting, hover, active states
  - Responsive breakpoints: xs to 2xl (Tailwind-compatible)
  - Density principles: compact/default/comfortable (75%/100%/125%)
  - Z-index scale: 8 levels with rules
  - Token dependencies from components: Card, Button, Input, Select, Modal, Table, Tag, Page, Section

- COMPLIANCE_MATRIX.md: Brand Palette 40%, Grid & Elevation 60%

Rationale: Brand Palette driven by component token usage, not vice versa.
Grid & Elevation validated against Card and other components. Foundations
now complete enough to raise component maturity.
2026-07-02 10:51:59 +00:00
Bernt 558303784a docs: RFC-003 Select + RFC-004 Card + Compliance Matrix update
- RFC-003: Canonical Select Component:
  - Cognitive Purpose: choose one from predefined list
  - When to Use/NOT Use: clear boundaries vs Radio Group, Autocomplete, Multi-Select
  - Interaction Contract: click, arrow keys, type-to-search, escape
  - Failure Behaviour: empty, required, disabled, async loading, load failure
  - Accessibility Contract: combobox role, aria-expanded, aria-selected, focus management
  - AI Contract: when to choose Select vs alternatives
  - Token Dependencies: 21 tokens (trigger + dropdown + options)
  - Layout: trigger + dropdown with sections
  - Sizes (sm/md/lg), Variants (default/ghost/filled), States (10 states)
  - Keyboard: full navigation (Tab, Arrows, Enter, Escape, Home, End, letter keys)
  - Touch: 44px option targets, native scroll
  - Motion: dropdown open/close, option hover/select, chevron rotate
  - Anti-Patterns: < 4 options, > 50 options, no placeholder, clipping
  - Related Components: Input, Radio Group, Checkbox Group, Multi-Select, Autocomplete
  - DDR References: DDR-001 through DDR-004

- RFC-004: Canonical Card Component:
  - Cognitive Purpose: group related information into bounded unit
  - When to Use/NOT Use: clear boundaries vs List Item, Modal, Page
  - Interaction Contract: click/hover/focus for actionable, none for static
  - Failure Behaviour: overflow, image load fail, action fail, loading, empty
  - Accessibility Contract: role, focus, label, keyboard activation
  - AI Contract: when to choose Card vs alternatives
  - Token Dependencies: 12 tokens (bg, border, radius, padding, shadows, text)
  - Layout: Header + Body + Footer with optional divider
  - Sizes (sm/md/lg/fluid), Variants (default/elevated/outlined/interactive)
  - States (7 states), Keyboard, Touch, Motion (with reduced motion)
  - Anti-Patterns: nested cards, excessive padding, no distinction, event collision
  - Related Components: Modal, Panel, List Item, Tile, KPI Card, Dataset Card
  - DDR References: DDR-001, DDR-002, DDR-003, DDR-005

- COMPLIANCE_MATRIX.md: Select and Card updated to 33%

Rationale: Validate RFC-001 template works for selection and container
component types. Three different component types (action, selection,
container) now tested. Mallen håller.
2026-07-02 10:41:19 +00:00
Bernt 54255eeae9 docs: RFC-002 Input + Definition of Done + Compliance Matrix update
- RFC_DEFINITION_OF_DONE.md (v1.0, LOCKED):
  - 12 criteria for every RFC component
  - Sign-off roles: Author, Reviewer, Automated, QA
  - Exit criteria: all 12 must pass

- RFC-002: Canonical Input Component:
  - Cognitive Purpose: captures free-form text/numeric data
  - When to Use/NOT Use: clear boundaries vs Select, Switch, Date Picker
  - Interaction Contract: click, type, tab, blur, enter, escape
  - Failure Behaviour: invalid, network, max length, required, disabled
  - Accessibility Contract: label, focus, error, required, screen reader
  - AI Contract: when to choose Input vs alternatives
  - Token Dependencies: 13 tokens (bg, border, text, padding, radius, sizes, states)
  - Layout, Sizes (sm/md/lg), Variants (default/ghost/filled), States (8 states)
  - Keyboard, Touch, Motion (with reduced motion)
  - Anti-Patterns: placeholder as label, validation only on submit, etc.
  - Related Components: Select, Textarea, Search, Form, Label
  - DDR References: DDR-001, DDR-002, DDR-003
  - Acceptance Criteria: 10 checklist items

- COMPLIANCE_MATRIX.md: Input updated to 33% (Governance 🟡, Tokens 🟡,
  Motion 🟡, Accessibility 🟡, AI , QA )

Rationale: Validate RFC-001 template works for different component types.
Definition of Done ensures consistent quality. Compliance Matrix tracks
progress visibly.
2026-07-02 10:38:23 +00:00
Bernt b0a1808b2b docs: AI Principles restructured + Compliance Matrix + Platform governance + RFC-001 Button
- AI_DESIGN_PRINCIPLES.md:
  - Restructured into 5 parts: A. Decision Process, B. Component Selection,
    C. Token Usage, D. Design Review, E. Escalation
  - All rules use RFC 2119 normative words (MUST/MUST NOT/SHOULD/MAY)
  - Clearer escalation path: when to create DDR, when to flag uncertainty

- COMPLIANCE_MATRIX.md:
  - Tracks readiness for all 29 components (Tier 1/2/3)
  - 6 dimensions: Governance, Tokens, Motion, Accessibility, AI, QA
  - Foundation documents tracked separately
  - Button at 82% (reference for others)

- docs/platform/README.md:
  - Reserved directory for cross-cutting governance
  - Future: AI Governance, Product Governance, Review Process,
    Quality Gates, Release Governance, Decision Frameworks
  - Separates platform governance from design system

- LANDVEX_DESIGN_SPECIFICATION.md:
  - Button renamed to RFC-001: Canonical Button Component
  - Structured with: Cognitive Purpose, When to Use/NOT Use,
    User Expectation, Interaction Contract, Failure Behaviour,
    Accessibility Contract, AI Contract
  - Sets standard for all future RFC component specs

Rationale: AI rules before components (AI writes components).
Compliance matrix makes progress visible. Platform governance
separates cross-cutting concerns from design system. RFC format
for components ensures production-ready specifications.
2026-07-02 09:06:08 +00:00