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

MEMORY.md

@@ -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."

docs/design/LANDVEX_DESIGN_CONSTITUTION.md

@@ -0,0 +1,368 @@
+# LANDVEX DESIGN CONSTITUTION
+
+## DEL 1.4 — ENTERPRISE UX DOCTRINE
+
+**"Designing for Professionals, Not Visitors"**
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Status** | LOCKED |
+| **Scope** | Landvex Enterprise Platform |
+| **Authority** | Highest authority for UX, UI, Design System, Interaction Design, Visual Language, Information Architecture |
+
+---
+
+## 1. INTRODUKTION
+
+Landvex är inte en traditionell webbplats.
+
+Den är inte byggd för att konsumera innehåll.
+
+Den är inte byggd för att sälja en produkt.
+
+Den är byggd för att människor ska kunna fatta beslut snabbare, säkrare och med högre precision.
+
+Det innebär att UX-designen måste utgå från professionellt arbete.
+
+Målet är inte "en trevlig upplevelse".
+
+Målet är:
+
+- snabbare beslut
+- färre misstag
+- högre precision
+- mindre mental belastning
+- bättre situationsförståelse
+
+---
+
+## 2. DEN PROFESSIONELLA ANVÄNDAREN
+
+Vi designar inte för en genomsnittlig internetanvändare.
+
+Vi designar för personer som arbetar.
+
+Exempel:
+
+- analytiker
+- kommuner
+- entreprenörer
+- fastighetsägare
+- infrastrukturförvaltare
+- driftorganisationer
+- beslutsfattare
+- operatörer
+- projektledare
+- inspektörer
+
+De använder systemet under längre arbetspass.
+
+De kommer tillbaka dag efter dag.
+
+UX ska därför bli bättre ju mer systemet används.
+
+---
+
+## 3. MENTAL ENERGI ÄR DEN VIKTIGASTE RESURSEN
+
+Varje onödigt beslut kostar energi.
+
+Exempel på onödiga beslut:
+
+- "Var finns knappen?"
+- "Är detta klickbart?"
+- "Vad betyder den här ikonen?"
+- "Vilken sida är jag på?"
+- "Vad händer om jag klickar?"
+
+Designens uppgift är att eliminera dessa frågor.
+
+---
+
+## 4. LANDVEX SKA ALDRIG KÄNNAS SOM EN WEBBPLATS
+
+När användaren arbetar ska känslan vara:
+
+**"Jag arbetar i ett professionellt system."**
+
+Inte:
+
+**"Jag surfar runt."**
+
+Det påverkar:
+
+- navigation
+- layout
+- komponenter
+- animationer
+- laddning
+- återkoppling
+- arbetsflöden
+
+---
+
+## 5. DEVICE ADAPTIVE — INTE DESKTOP FIRST ELLER MOBILE FIRST
+
+Landvex är **Device Adaptive**.
+
+Samma identitet. Olika optimeringar.
+
+| Enhet | Fokus |
+|-------|-------|
+| **Telefon** | Touch-first, snabb navigering, förenklade arbetsflöden |
+| **Surfplatta** | Hybrid, balans mellan översikt och detalj |
+| **Desktop** | Hög informationsdensitet, multitasking, avancerade paneler |
+
+Konflikt mobil/desktop: **kontexten bestämmer**, inte enhetsförsta princip.
+
+---
+
+## 6. KONTINUITET
+
+När användaren går mellan:
+
+Dashboard → Kartor → Objekt → Rapporter → Inställningar → Administration
+
+ska hjärnan aldrig behöva "ställa om".
+
+Det ska kännas som samma arbetsyta.
+
+---
+
+## 7. INFORMATION HAR HÖGST STATUS
+
+Information ska alltid dominera designen.
+
+Design ska aldrig dominera informationen.
+
+Om något konkurrerar med datan ska det reduceras.
+
+---
+
+## 8. VISUELL TYSTNAD
+
+Landvex ska kännas lugnt.
+
+Det betyder inte tomt.
+
+Det betyder kontrollerat.
+
+Undvik:
+
+- blinkande element
+- starka gradients
+- färgexplosioner
+- stora illustrationer
+- marknadsföringsgrafik
+
+Eftersträva:
+
+- lugn
+- precision
+- rytm
+- balans
+
+---
+
+## 9. ANVÄNDAREN SKA ALDRIG TVEKA
+
+Varje arbetsflöde ska vara självförklarande.
+
+Om en användare behöver fundera på nästa steg har designen misslyckats.
+
+---
+
+## 10. KARTAN ÄR EN DEL AV IDENTITETEN
+
+Landvex arbetar med geodata.
+
+Det ska märkas.
+
+Men subtilt.
+
+Kartlagren ska fungera som ett visuellt DNA.
+
+Inte som innehåll.
+
+Mapbox används för att skapa:
+
+- geometrier
+- koordinater
+- topografi
+- lågmälda vägnät
+- diskreta höjdlinjer
+
+Allt med mycket låg visuell intensitet.
+
+---
+
+## 11. MIKROINTERAKTIONER
+
+Mikrointeraktioner ska ge användaren trygghet.
+
+Exempel:
+
+Hover → Visuell respons → Klick → Omedelbar återkoppling → Laddning → Slutfört
+
+Användaren ska aldrig undra om systemet registrerade en handling.
+
+---
+
+## 12. FEL SKA VARA PEDAGOGISKA
+
+Felmeddelanden ska:
+
+- förklara problemet
+- förklara varför
+- förklara lösningen
+- undvika teknisk jargong när den inte behövs
+
+Fel ska hjälpa användaren vidare.
+
+Inte stoppa användaren.
+
+---
+
+## 13. TOMMA LÄGEN ÄR PRODUKTEN
+
+En tom lista är inte ett undantag.
+
+Den är en designad upplevelse.
+
+Varje tom vy ska:
+
+- förklara varför den är tom
+- visa nästa steg
+- inte kännas trasig
+
+---
+
+## 14. LADDNING ÄR EN DESIGNUPPGIFT
+
+Visa aldrig:
+
+- vit sida
+- tom sida
+- hoppande layout
+
+I stället:
+
+- Skeletons
+- Placeholder-data
+- Progress
+- Stegindikatorer
+- Mjuk övergång
+
+---
+
+## 15. HASTIGHET ÄR EN UX-FUNKTION
+
+All design ska stödja upplevd snabbhet.
+
+Målet är inte bara hög teknisk prestanda.
+
+Målet är att användaren upplever systemet som omedelbart.
+
+---
+
+## 16. FOKUS
+
+Varje sida ska ha ett primärt syfte.
+
+Om användaren öppnar en vy ska det vara uppenbart:
+
+- Vad är huvuduppgiften?
+- Vad är sekundärt?
+- Vad är historik?
+- Vad kräver handling?
+
+---
+
+## 17. DASHBOARDS SKA BERÄTTA EN HISTORIA
+
+Dashboarden ska inte vara en samling widgets.
+
+Den ska guida användaren genom:
+
+Situation → Analys → Prioritering → Beslut → Åtgärd → Resultat
+
+---
+
+## 18. AI SKA KÄNNAS NATURLIG
+
+AI ska förstärka arbetsflödet. Inte dominera det.
+
+AI ska:
+
+- föreslå
+- sammanfatta
+- prioritera
+- flagga avvikelser
+- identifiera risker
+
+AI ska aldrig ta över användarens kontroll utan tydlig återkoppling.
+
+---
+
+## 19. INGEN SIDAS DESIGN ÄR "KLAR"
+
+Varje release ska innehålla:
+
+- UX-review
+- Design-review
+- Screenshot-review
+- Regression-review
+- Accessibility-review
+- Performance-review
+
+Varje förbättring ska göra hela systemet mer sammanhållet.
+
+---
+
+## 20. ENTERPRISE DEFINITION
+
+Landvex uppnår enterprise-nivå när användaren:
+
+- inte tänker på designen
+- inte letar efter funktioner
+- inte tvekar
+- inte tvivlar på systemets stabilitet
+
+utan kan fokusera helt på sitt arbete.
+
+Det är den högsta formen av användarupplevelse.
+
+---
+
+## 21. DOKTRIN
+
+Landvex ska inte imponera genom effekter.
+
+Landvex ska imponera genom att upplevas:
+
+- genomtänkt
+- pålitligt
+- konsekvent
+- snabbt
+- precist
+- och självklart.
+
+När användaren glömmer att gränssnittet finns och enbart fokuserar på uppgiften har designen uppnått sitt syfte.
+
+---
+
+## ÄNDRINGSHISTORIA
+
+| Version | Datum | Beskrivning |
+|---------|-------|-------------|
+| 1.0 | 2026-07-02 | Ursprunglig version, baserad på Erik Svensson Design Constitution DEL 1.4 |
+
+---
+
+## STATUS
+
+**LOCKED**
+
+- Mindre revideringar: 1.x-serien
+- Brytande ändringar: Kräver Architecture Review, ny major-version (2.0+)

docs/products/quixzoom/QUIXZOOM_UX_DOCTRINE.md

@@ -0,0 +1,364 @@
+# QUIXZOOM UX DOCTRINE
+
+**"Field-First. Speed-First. Mission-First."**
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Status** | LOCKED |
+| **Scope** | quiXzoom Mobile Application (iOS/Android) |
+| **Authority** | Highest authority for quiXzoom UX, UI, Interaction Design |
+
+---
+
+## 1. INTRODUKTION
+
+quiXzoom är inte en app man "använder".
+
+Den är ett verktyg man **arbetar med**.
+
+Zoomers (aldrig "fotografer") använder appen i fält — i rörelse, i väder, under tidspress.
+
+Varje sekund räknas. Varje tryck ska vara meningsfullt.
+
+Målet är inte "en trevlig app".
+
+Målet är:
+
+- snabbare uppdrag
+- färre fel
+- högre kvalitet på inskick
+- mindre friktion
+- mer intäkt per tidsenhet
+
+---
+
+## 2. DEN PROFESSIONELLA ZOOMERN
+
+Vi designar för personer som arbetar i fält.
+
+Exempel:
+
+- studenter som vill tjäna extra
+- pensionärer med flexibel tid
+- deltidsarbetare mellan uppdrag
+- professionella fältarbetare
+- personer som rör sig mycket i sin vardag
+
+De använder appen:
+
+- i rörelse (gående, cyklande, bil)
+- med en hand
+- i solljus och regn
+- under tidspress
+- med begränsad batteritid
+
+UX ska bli snabbare ju mer de använder appen.
+
+---
+
+## 3. MOBILE-FIRST ÄR UNDERDRIVET
+
+quiXzoom är **Mobile-Only**.
+
+Det finns ingen desktop-version.
+
+Det finns ingen webbportal för Zoomers.
+
+Allt sker i appen.
+
+Därför gäller:
+
+- iPhone-first (benchmark: Apple Maps, Apple Wallet, Apple Weather)
+- En hand, en tumme, tre sekunder
+- Ljust tema default
+- Ingen mörk cyberpunk-estetik
+- Konflikt mobil/desktop: **mobil vinner alltid**
+
+---
+
+## 4. KAMERA-FIRST UX
+
+Kameran är inte en funktion.
+
+Kameran är **huvudgränssnittet**.
+
+Varje uppdrag börjar med att rikta kameran.
+
+Designprinciper:
+
+- Kamera alltid ett tryck bort
+- Förhandsgranskning ska vara kristallklar
+- Fokus, exponering, HDR — automatiskt optimerat
+- Burst-läge för snabb dokumentation
+- Video-stöd där det krävs
+
+---
+
+## 5. OFFLINE-FIRST
+
+Zoomers har inte alltid täckning.
+
+Appen ska fungera fullt ut offline.
+
+Principer:
+
+- Missions cache:as lokalt
+- Bilder sparas lokalt, laddas upp vid anslutning
+- GPS-data loggas kontinuerligt
+- Status synkroniseras vid återanslutning
+- Användaren ska aldrig undra "försvann mitt uppdrag?"
+
+---
+
+## 6. MISSION-FIRST NAVIGATION
+
+Zoomerns mentala modell:
+
+**"Vad ska jag göra nu? → Gör det → Få betalt"**
+
+Navigation ska spegla detta:
+
+- Tillgängliga uppdrag (nära mig, nu, passar min nivå)
+- Pågående uppdrag (vad jag håller på med)
+- Inskickade uppdrag (vad som väntar granskning)
+- Godkända uppdrag (vad jag fått betalt för)
+
+Inga undervattenmenyer. Inga gömda funktioner.
+
+---
+
+## 7. SNABB INFÅNGST — MINIMAL FRIKTION
+
+Varje uppdrag ska gå från start till inskick på minsta möjliga tid.
+
+Mål: **Under 60 sekunder för enkel uppdragstyp**
+
+Eliminera:
+
+- onödiga bekräftelser
+- obligatoriska fritextfält (använd AI, GPS, metadata)
+- flera steg för att spara
+- väntetider vid övergångar
+
+---
+
+## 8. GPS ÄR EN FUNKTION, INTE EN BÖRDA
+
+GPS ska kännas transparent.
+
+- Automatisk positionering vid fototagning
+- Automatisk spårning under uppdrag
+- Användaren ska inte behöva "aktivera GPS"
+- Tydlig indikation när precision är otillräcklig
+
+---
+
+## 9. BETALNING ÄR BELOPP, INTE PROCESS
+
+Zoomern ska se:
+
+- Vad ett uppdrag betalar (innan acceptans)
+- Vad de tjänat totalt
+- När betalning kommer
+
+Inte:
+
+- Stripe Connect-teknikaliteter
+- "pending"/"processing"-tillstånd som kräver förklaring
+- Dolda avgifter (det finns inga — 100% till Zoomern)
+
+---
+
+## 10. VISUELL TYSTNAD I FÄLT
+
+quiXzoom ska vara läsbar i direkt solljus.
+
+- Hög kontrast
+- Stora tryckytor
+- Tydliga ikoner
+- Ingen finlirig detalj som försvinner i solljus
+
+Men också:
+
+- Diskret nog att inte dra uppmärksamhet
+- Ingen blinkande reklam
+- Ingen onödig animation som drar batteri
+
+---
+
+## 11. MIKROINTERAKTIONER = TRYGGHET
+
+Varje handling ska ge omedelbar återkoppling:
+
+- Kamera-shutter-animation
+- Uppdrag accepterat: tydlig bekräftelse
+- Bild sparad: visuell indikator
+- Inskick skickat: progress + bekräftelse
+- Betalning mottagen: celebration (men diskret)
+
+Användaren ska aldrig undra: "Tog det fotot? Sparades det? Fick jag uppdraget?"
+
+---
+
+## 12. FEL I FÄLT
+
+Fel ska vara:
+
+- Tydliga (stor text, tydlig ikon)
+- Handlingsbara ("Gå närmare", "Vänd på telefonen", "Försök igen")
+- Kontextuella (förstå varför det misslyckades)
+
+Undvik:
+
+- Tekniska felkoder
+- "Något gick fel"
+- Krångliga omvägar för att komma tillbaka
+
+---
+
+## 13. TOMMA LÄGEN ÄR MÖJLIGHETER
+
+Inga tillgängliga uppdrag? Visa:
+
+- Varför (t.ex. "Inga uppdrag inom 5 km just nu")
+- Vad användaren kan göra (t.ex. "Utöka sökradien", "Aktivera notifikationer")
+- När nästa uppdrag kan komma (t.ex. "Nya uppdrag läggs ut varje morgon 08:00")
+
+Tom lista = inte trasig. Tom lista = chans att engagera.
+
+---
+
+## 14. HASTIGHET ÄR INTE EN FUNKTION — DET ÄR PRODUKTEN
+
+Varje millisekund räknas.
+
+- App-start under 2 sekunder
+- Kamera redo under 1 sekund
+- Uppdrag accepterat utan fördröjning
+- Bild sparad omedelbart
+- Inskick skickat i bakgrunden
+
+Upplevd hastighet > teknisk hastighet.
+
+Skeletons, progress-indikatorer, mjuka övergångar — allt ska få det att kännas snabbt.
+
+---
+
+## 15. FOKUS PÅ ETT UPPDRAG I TAGET
+
+Zoomern ska aldrig behöva välja mellan flera aktiva uppdrag.
+
+- Ett pågående uppdrag åt gången
+- Tydlig primär action: "Fotografera", "Skicka in", "Acceptera"
+- Sekundärt: historik, inställningar, profil
+- Historik: lättåtkomligt men inte i vägen
+
+---
+
+## 16. AI SOM OSYNLIG ASSISTENT
+
+AI ska inte synas som "AI".
+
+AI ska:
+
+- Föreslå bästa vinkel baserat på uppdragstyp
+- Auto-granska bildkvalitet innan inskick
+- Föreslå närmaste uppdrag baserat på rutt
+- Sammanfatta uppdragshistorik
+
+AI ska aldrig:
+
+- Ta över kameran
+- Göra beslut åt Zoomern
+- Kräva extra interaktion
+
+---
+
+## 17. IDENTITETSNIVÅER SKA KÄNNAS MENINGSFULLA
+
+Zoomer-nivåer ska ge tydlig progression:
+
+| Nivå | Fördelar |
+|------|----------|
+| **Supplementary** | 2-4 uppdrag/vecka, standardkategorier |
+| **Active** | 8-12 uppdrag/vecka, prioritetsåtkomst |
+| **Professional** | 15+ uppdrag/vecka, premium-uppdrag, prestationsbaserad ersättning |
+
+UI ska tydligt visa:
+
+- Nuvarande nivå
+- Vad som krävs för nästa nivå
+- Vilka fördelar som väntar
+
+---
+
+## 18. TILLGÄNGLIGHET ÄR INTE EN BONUS
+
+quiXzoom ska fungera för alla:
+
+- Dynamisk textstorlek (iOS/Android systeminställning)
+- VoiceOver/TalkBack-stöd för navigation
+- Tillräcklig kontrast för synnedsättning
+- Haptisk feedback för hörselskadade
+- Ingen funktion som enbart förlitar sig på färg
+
+---
+
+## 19. INGEN VERSION ÄR "KLAR"
+
+Varje release ska innehålla:
+
+- Field-test med riktiga Zoomers
+- Performance-review på lågpresterande enheter
+- Battery-drain-test
+- Offline-scenario-test
+- Accessibility-review
+- Screenshot-review på olika skärmstorlekar
+
+---
+
+## 20. FIELD DEFINITION
+
+quiXzoom uppnår optimal UX när Zoomern:
+
+- inte tänker på appen
+- inte tvekar på nästa steg
+- inte oroar sig för om uppdraget sparades
+- inte behöver läsa instruktioner
+- kan fokusera helt på att dokumentera
+
+När appen känns som en förlängning av Zoomerns hand — då har vi lyckats.
+
+---
+
+## 21. DOKTRIN
+
+quiXzoom ska inte imponera genom effekter.
+
+quiXzoom ska imponera genom att:
+
+- försvinna i bakgrunden
+- vara snabbare än förväntat
+- aldrig överraska negativt
+- alltid fungera när det behövs
+- göra Zoomern mer effektiv
+
+När Zoomern glömmer att appen finns och enbart fokuserar på uppdraget — då har designen uppnått sitt syfte.
+
+---
+
+## ÄNDRINGSHISTORIA
+
+| Version | Datum | Beskrivning |
+|---------|-------|-------------|
+| 1.0 | 2026-07-02 | Ursprunglig version, baserad på Landvex Design Constitution DEL 1.4, anpassad för quiXzoom fältarbetsflöde |
+
+---
+
+## STATUS
+
+**LOCKED**
+
+- Mindre revideringar: 1.x-serien
+- Brytande ändringar: Kräver Architecture Review, ny major-version (2.0+)