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