docs: Landvex Design Constitution + quiXzoom UX Doctrine

- Add docs/design/LANDVEX_DESIGN_CONSTITUTION.md (v1.0, LOCKED) - Enterprise UX Doctrine: 21 principles for professional GIS platform - Device Adaptive (not Desktop First nor Mobile First) - Add docs/products/quixzoom/QUIXZOOM_UX_DOCTRINE.md (v1.0, LOCKED) - Field-first UX: Camera-First, Offline-First, Mission-First - Mobile-Only, One Hand, Three Seconds - Update MEMORY.md with DESIGN GOVERNANCE section (0c) - References to both doctrines - Shared DNA: components, tokens, colors, typography, motion, icons - LOCKED status with version governance
2026-07-02 08:14:26 +00:00
parent bae705aa97
commit f756b63fe2
3 changed files with 997 additions and 0 deletions
@@ -49,6 +49,40 @@ Använd alltid **USD ($)** eller **EUR (€)**.

 ---

+## 0c. DESIGN GOVERNANCE (LÅST 2026-07-02, Erik)
+
+**Canonical Design Constitution:** `docs/design/LANDVEX_DESIGN_CONSTITUTION.md`
+
+Detta dokument är den högsta auktoriteten för:
+- UX
+- UI
+- Design System
+- Interaction Design
+- Visual Language
+- Information Architecture
+
+**Ingen implementation får bryta mot Design Constitution.**
+
+**Produktspecifika doktriner:**
+- **Landvex Enterprise:** `docs/design/LANDVEX_DESIGN_CONSTITUTION.md` — Device Adaptive, inte Desktop First
+- **quiXzoom Field App:** `docs/products/quixzoom/QUIXZOOM_UX_DOCTRINE.md` — Mobile-Only, Camera-First, Offline-First
+
+**Delat DNA:**
+- Komponentbibliotek
+- Design tokens
+- Färgsystem
+- Typografi
+- Animationer
+- Ikonografi
+
+**Status:**
+- Landvex Design Constitution: LOCKED v1.0
+- quiXzoom UX Doctrine: LOCKED v1.0
+- Mindre revideringar: 1.x-serien
+- Brytande ändringar: Kräver Architecture Review, ny major-version (2.0+)
+
+---
+
 ## 1. EKONOMISK ÅTERHÅLLSAMHET (UPPDATERAD 2026-06-21 04:51 UTC, Erik)

 **Denna regel override:ar allt annat utom säkerhet.**
@@ -594,3 +628,234 @@ ZOOMERS (Reality Collection Layer)
 ### Traditionell BI vs Landvex
 Traditionell BI: Data → Dashboard → Rapport → Beslut
 Landvex: Officiell statistik + QUIXZOOM-observationer + Extern data → Kontradiktionsanalys → Kontrollintelligens → Beslut
+
+---
+
+## SIL — System Intelligence Layer (2026-07-01)
+
+Erik-feedback: Bygg inte en "resonemangsmotor", bygg ett **System Intelligence Layer** — ett lager mellan kodbasen och alla AI-agenter. Fyra ansvarsområden: Observera, Resonera, Planera, Verifiera.
+
+### Viktiga beslut från Erik (2026-07-01)
+
+**1. Experiment-fas, inte utrullning**
+- Samla data i 2-4 veckor innan aktivering
+- Mät diagnostiska metriker: recall, precision, false negative rate, false positive rate, confidence calibration
+- Gold Set: 50-100 historiska PR:er med känt facit
+
+**2. False negatives är farligare än false positives**
+- En extra varning kostar lite tid
+- En missad kritisk beroendekedja kan orsaka produktionsfel
+- Prioritera recall över precision
+
+**3. Provenance (revisionsspår) för varje slutsats**
+- Vilka observationer användes?
+- Vilka regler aktiverades?
+- Vilka grafnoder traverserades?
+- Vilka relationer användes?
+- Vilka confidence-värden påverkade slutsatsen?
+- Vilken del var verifierad och vilken del var inferens?
+
+**4. Webhook-baserad arkitektur (inte cron)**
+- Event-driven när PR öppnas/uppdateras
+- Lägre latens, mindre onödigt arbete
+
+**5. Aktiveringskriterier (hårda)**
+- Recall > 85%
+- Precision > 80%
+- False Negative Rate < 10%
+- Calibration Error < 10%
+
+### Implementation (v0.4)
+- `SIL/pr-analyzer.mjs` — PR-analys med provenance + uncertainty + decision engine
+- `SIL/provenance.mjs` — Revisionsspår
+- `SIL/metrics.mjs` — Diagnostiska metriker
+- `SIL/gold-set.mjs` — Ground truth-byggare
+- `SIL/webhook-server.mjs` — Event-driven triggning
+- `SIL/experiment-report.mjs` — Veckovis rapport
+- `SIL/graph-version.mjs` — Versionera kunskapsgrafen
+- `SIL/stability.mjs` — Mät stabilitet och determinism
+- `SIL/uncertainty.mjs` — Osäkerhet som förstklassig signal
+- `SIL/decision-engine.mjs` — Beslutsunderlag för PR:er
+- `SIL/observability.mjs` — Dashboard och metriker för SIL självt
+- `SIL/reasoning-suite.mjs` — Regressionstester för resonemang (30+ frågor)
+- `SIL/architecture-policy.mjs` — Arkitekturregler som kod (10 regler)
+- `SIL/historical-analysis.mjs` — Trender och långsiktiga mönster
+- `SIL/README.md` — Komplett dokumentation
+
+Status: Experiment-fas pågår. Samlar data. Inte aktiverad för merge-beslut ännu.
+
+### Principer (från Erik 2026-07-01)
+**"Varje ny funktion i SIL ska också göra SIL enklare att mäta, testa eller förklara."**
+- Mätbarhet > nya AI-funktioner
+- Reproducerbarhet > komplexitet
+- Tydliga revisionsspår > black box-beteende
+
+### Mål för v1.0 (från Erik 2026-07-01)
+**"SIL ska kunna ta en okänd pull request, utan README eller mänsklig förklaring, analysera den utifrån kod, arkitektur, tester och telemetri och producera ett beslutsunderlag som en erfaren staff engineer skulle kunna använda för att fatta ett merge-beslut."**
+
+### Engineering Validation Program (från Erik 2026-07-01)
+v1.0 = Feature Complete. 6–8 veckors empirisk validering.
+
+**Fråga 1: Hjälper SIL verkligen människor?**
+- Mät: tid till merge, regressionsbuggar, följsamhet, rätt vs fel
+- Success: 20% färre regressionsfel, 15% snabbare merge
+
+**Fråga 2: Kan SIL motivera sina slutsatser?**
+- Granska 50 slumpmässiga analyser
+- Checklista: regel, observation, artefakter, noder, verifierat, inferens
+- Success: >90% completeness
+
+**Fråga 3: Hur robust är SIL mot förändring?**
+- Simulera: rename, move, split, add dependency, change structure
+- Success: <10% degradation
+
+**Fråga 4: Kan SIL analysera okända projekt?**
+- Testa på 3 open source-projekt
+- Success: >70% recall
+
+**Två-lagers arkitektur:**
+- Deterministiskt lager (confidence: 0.99-1.00): graf, regler, AST, policyer
+- Probabilistiskt lager (confidence: <0.99): LLM, heuristik, uppskattningar
+
+### Hypoteser (från Erik 2026-07-01)
+**"Vilka hypoteser försöker vi falsifiera?"**
+- H1: SIL minskar regressionsfel med minst 20%
+- H2: SIL upptäcker fler arkitekturöverträdelser än code review
+- H3: SIL hittar fler beroenden än senior utvecklare
+- H4: Confidence korrelerar med faktisk korrekthet
+- H5: UNKNOWN används när systemet saknar tillräcklig evidens
+
+### Failure Review (från Erik 2026-07-01)
+**"Varje gång SIL har fel ska ni klassificera felet."**
+- Knowledge Error: Grafen saknade en relation
+- Parsing Error: AST missade en import
+- Runtime Drift: Driftmiljön skiljde sig från modellen
+- Policy Error: Arkitekturregel felaktigt formulerad
+- LLM Error: Felaktig inferens
+- Confidence Error: För hög confidence trots svag evidens
+
+### Replay Mode (från Erik 2026-07-01)
+**"Samma grafversion, samma regler, samma observer-version, samma reasoner-version."**
+- Återskapa exakt hur en analys såg ut vid ett specifikt tillfälle
+- Ovärderligt vid felsökning av beslut
+
+### Teknisk specifikation (från Erik 2026-07-01)
+**"Skriv en teknisk specifikation som om ni tänkte publicera den."**
+- Problemformulering, systemmodell, deterministiskt/probabilistiskt lager
+- Confidence-modell, valideringsmetodik, begränsningar, kända felkällor
+- Fil: `SIL/SIL_TECHNICAL_SPECIFICATION.md`
+
+### Engineering Operating System (EOS) (från Erik 2026-07-01)
+**"Ingen agent får någonsin fatta ett irreversibelt beslut utan att kunna motivera det, reproducera det och återställa det."**
+
+**Byggstenar:**
+1. **Immutable Truth** — exakt en sanningskälla för varje sak (Git, IaC, migrationer, OpenAPI, kunskapsgraf)
+2. **Engineering Contract** — hårda regler med konsekvenser (STOP/ESCALATE)
+3. **Event-Driven Memory** — minne uppdateras av händelser (commit, PR, merge, deploy)
+4. **Project Memory** — varför beslut fattades, vad som testades, buggar, arkitektur
+5. **Goal Graph** — vision, produktmål, epics, features, arkitekturprinciper, tekniska/affärsmål
+
+**Engineering Constitution** — 30 regler som alla agenter måste följa:
+- Git är den enda sanningskällan för kod
+- Produktion är skrivskyddad för agenter
+- Alla ändringar ska vara reproducerbara
+- Alla beslut ska kunna motiveras
+- Alla slutsatser ska ha provenance
+- Alla ändringar ska kunna återställas
+- Ingen komponent får skapa en egen version av sanningen
+- Om osäkerheten är hög ska agenten eskalera istället för att gissa
+- Affärsmål väger tyngre än lokal kodoptimering
+- Projektminnet är långlivat och versionshanterat
+
+### Engineering Readiness (från Erik 2026-07-01)
+**"EOS borde inte bara säga STOP. Det borde också kunna ge ett mognadsindex."**
+
+- 10 områden med viktade poäng (Git 20%, CI/CD 20%, Backup 15%, IaC 15%, Testing 10%, Security 10%, API 5%, DB 3%, Observability 1%, Agent Safety 1%)
+- Critical (<60%): STOP, Warning (60-79%): ESCALATE, Ready (≥80%): Godkänt
+- quixzoom-resultat: 8% CRITICAL (viktad)
+
+### Policy Enforcement (från Erik 2026-07-01)
+**"Om en agent försöker deploya utan pipeline ska EOS förhindra åtgärden."**
+
+- Blockera direkt skrivning till produktion
+- Blockera deployment utan pipeline
+- Blockera redigering på server
+- Blockera ändring utan commit
+- Blockera databasändring utan migration
+- Blockera API-ändring utan kontrakt
+- Kräv mänskligt godkännande för kritiska åtgärder
+- Förklara VARFÖR och HUR man häver blockering
+
+### STOP Register (från Erik 2026-07-01)
+**"Risk = Sannolikhet × Konsekvens × Exponering"**
+
+- Varje STOP har riskvärde för prioritering
+- Sorteras efter risk (högst först)
+- Exit Criteria: Inga CRITICAL STOP öppna
+
+### Release Gate (från Erik 2026-07-01)
+**"Innan en release får starta kör EOS en kontroll"**
+
+- Engineering Readiness ≥60%
+- Inga CRITICAL STOP
+- Inga policybrott senaste 24h
+- Kunskapsgraf uppdaterad
+- Tester passerar
+- Rollback verifierad
+
+### EOS Meta-Rules (från Erik 2026-07-01)
+**"EOS får inte kunna kringgå sina egna regler"**
+
+- Policyer versionshanterade
+- Policyändringar kräver samma granskning som kod
+- Undantag lämnar revisionsspår
+- EOS kan inte inaktiveras av agent
+- EOS loggar alla egna ändringar
+
+### Arkitektur — Fyra nivåer (från Erik 2026-07-01)
+**"Varje lager bara känner till lagret under."**
+
+- Layer 1: Foundation (Git, Terraform, OpenAPI, K8s, CI/CD, Secrets, Logging)
+- Layer 2: EOS (Constitution, Policies, Knowledge Graph, Project Memory, Goal Graph)
+- Layer 3: Agents (Planner, Reviewer, Developer, Security, QA, Architect)
+- Layer 4: Applications (quiXzoom, LandveX, ...)
+
+**Isoleringsprincip:** Inget i Layer N får direkt påverka Layer N+2 eller högre.
+**quiXzoom får aldrig känna till EOS.** Det är EOS som känner till quiXzoom.
+
+### Capability Registry (från Erik 2026-07-01)
+**"Inte komponentregister. Inte service registry. Capability Registry."**
+
+- Resonera i verksamhetsförmågor: Mission Management, User Management, Payment Processing
+- Varje capability: services, APIs, databas, tester, dashboards, ägare
+- Gör att systemet växer i verksamhetsförmågor snarare än tekniska komponenter
+
+### Dependency Budget (från Erik 2026-07-01)
+**"Precis som prestandabudgetar."**
+
+- Max direkta beroenden per service
+- Max externa API:er
+- Max databaser
+- Om PR överskrider budget → blockeras
+- Hindrar gradvis arkitekturell erosion
+
+### Moratorium (från Erik 2026-07-01)
+**"Sluta utveckla EOS under 2 sprintar. Mäta istället."**
+
+Mätvärden:
+- Hur många gånger användes EOS?
+- Hur många STOP-regler utlöstes?
+- Hur många undantag begärdes?
+- Hur lång tid tog det att lösa ett STOP?
+- Hur många regressionsfel undveks?
+- Hur många gånger ändrade en utvecklare sitt beslut efter EOS-analys?
+
+**Mål:** Om utvecklare frivilligt använder EOS för att det sparar tid och minskar misstag — då har vi lyckats.
+
+### Sprint-mål (från Erik 2026-07-01)
+**"0 omotiverade STOP-regler i den del av systemet som omfattas av sprinten."**
+
+**Sprint: Engineering Readiness v1**
+- Leverabler: Engineering Readiness Score (viktad), Policy Enforcement, STOP Register (med risk), Release Gate, Meta-Rules
+- Exit Criteria: Varje STOP är eliminerad, har dispens, eller ersatts av kontrollerad process
+- EOS-regel: "EOS får aldrig blockera något utan att kunna förklara exakt varför och vilken minsta åtgärd som krävs för att häva blockeringen."