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.

docs/platform/README.md

@@ -0,0 +1,57 @@
+# Platform Governance
+
+**Cross-Cutting Governance for Landvex & quiXzoom**
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Status** | DRAFT |
+| **Scope** | All Landvex & quiXzoom products, AI agents, and human contributors |
+
+---
+
+## Purpose
+
+This directory contains governance that spans design, engineering, product, and AI. It is not design-specific (see `/docs/design`) nor engineering-specific (see `/docs/architecture`).
+
+## Contents
+
+| Document | Status | Description |
+|----------|--------|-------------|
+| `AI_GOVERNANCE.md` | ⏳ | Rules for AI agent behavior, decision rights, escalation |
+| `DESIGN_GOVERNANCE.md` | ✅ | Document hierarchy, review gates, version control |
+| `PRODUCT_GOVERNANCE.md` | ⏳ | Product decision framework, roadmap gates |
+| `REVIEW_PROCESS.md` | ⏳ | How design reviews, code reviews, and AI reviews work |
+| `QUALITY_GATES.md` | ⏳ | Definition of done, acceptance criteria, release criteria |
+| `RELEASE_GOVERNANCE.md` | ⏳ | Release process, versioning, rollback |
+| `DECISION_FRAMEWORKS.md` | ⏳ | When to use DDR, ADR, RFC, and other decision records |
+
+## Relationship to Other Directories
+
+```
+/docs
+├── /architecture    → Engineering constitution, system design
+├── /design          → Design system, components, tokens
+├── /platform        → Cross-cutting governance (this directory)
+└── /products        → Product-specific documentation
+```
+
+**Rule:** If a decision affects multiple domains, it belongs in `/docs/platform`. If it is domain-specific, it belongs in the relevant directory.
+
+## Status
+
+This directory is a placeholder for future governance. Current priority is completing the design system (see `/docs/design/RELEASE_DEFINITION.md`).
+
+---
+
+## ÄNDRINGSHISTORIA
+
+| Version | Datum | Beskrivning |
+|---------|-------|-------------|
+| 1.0 | 2026-07-02 | Initial placeholder for platform governance |
+
+---
+
+## STATUS
+
+**DRAFT — Under development**