user-journeys

Dette dokumentet er auto-synket fra kildefilene i boligassistent-repoet. Endringer her vil overskrives ved neste sync. Rediger kildefilen direkte.

J1 — “Hva må jeg faktisk gjøre med huset det neste året?”

(B1 — Vedlikeholdsplanlegging)

Scope: MVP (Fase 4 — AI-assistent)

Entiteter:

• Issue — alle åpne avvik, filtrert på TG2/TG3 og severity=high/critical
• Task — alle todo/in_progress-oppgaver med frist
• MaintenancePlan — sesongbaserte sjekkpunkter
• BuildingSystem — systemer med status=trenger_tilsyn eller kritisk

AI-kontekst som assembleres:

Eiendom: [navn, byggeår, areal]
Kritiske avvik (TG3): [liste med tittel, kategori, anbefalt tiltak]
Høyprioritets avvik (TG2): [liste]
Åpne oppgaver med frist: [liste]
Systemer som trenger tilsyn: [liste]
Sesongplan: [gjeldende sesong + kommende]

Forventet output: Prioritert 12-måneders handlingsplan med forklaring av risiko og konsekvens.

---

J2 — “Hva er farlig for barnet mitt akkurat nå?”

(B2 — Barnesikkerhet)

Scope: MVP (Fase 2 — ConditionLayer)

Entiteter:

• SafetyItem — alle med affects_children=true og status=open/in_progress
• Room — rom der SafetyItems er lokalisert
• OutdoorSpace — uteområder med sikkerhetsforhold
• InteriorAsset — møbler med child_safe=false

AI-kontekst som assembleres:

Barnets alder: [fra brukerprofil om tilgjengelig]
Kritiske sikkerhetsforhold: [SafetyItems med risk_level=critical]
Øvrige åpne sikkerhetsforhold: [sortert etter risk_level]
Møbler merket ikke barnesikre: [kategori + rom]

Forventet output: Gruppert liste per rom med konkrete tiltaksforslag (rekkverk, grinder, festing).

---

J3 — “Hvorfor er inneklimaet dårlig – og hva gjør jeg med det?”

(B3 — Inneklima)

Scope: MVP (Fase 2+3)

Entiteter:

• Measurement — radon, CO2, fukt, temperatur (siste verdier per rom)
• Issue — avvik med kategori=health, moisture, ventilation
• BuildingSystem — ventilasjonssystem og varmesystem
• Observation — observasjoner med category=indoor_climate

AI-kontekst som assembleres:

Målinger inneklima: [radon Bq/m³, CO2 ppm, fukt%, temperatur] per rom
Grenseverdier: [Folkehelseinstituttets anbefalinger]
Relevante avvik: [fukt, ventilasjon]
Ventilasjons- og varmesystem: [alder, status, beskrivelse]
Brukerens observasjoner: [inneklima-kategoriserte]

Forventet output: Årsaksanalyse + konkrete tiltak (f.eks. radontiltak, ventilasjonsjustering).

---

J4 — “Hvordan bruker vi faktisk huset – og hva bør vi endre?”

(B4 — Bruksmønstre)

Scope: MVP (Fase 3 — ExperienceLayer)

Entiteter:

• Observation — alle observasjoner gruppert per rom, over tid
• Room — romdimensjoner og funksjon
• LayoutIntent — nåværende intensjon for rombruk

AI-kontekst som assembleres:

Observasjoner per rom (siste 2 sesonger): [gruppert med kategori]
Tilbakevendende mønstre: [rom med flest observasjoner]
Nåværende LayoutIntent: [funksjonssoner, trafikkflyt]

Forventet output: Innsikt om mønstre (f.eks. “stuen brukes primært som lekerom, men er møblert for TV-titting”), forbedringsforslag.

---

J5 — “Hvilke oppgraderinger bør vi gjøre – og i hvilken rekkefølge?”

(B5 — Prosjektprioritering)

Scope: MVP (krever ImprovementDependency fra Spec 005)

Entiteter:

• ImprovementIdea — alle med status=idea/considering/planned
• ImprovementDependency — avhengigheter mellom idéer
• Issue — avvik som bør løses som forutsetning for forbedringer
• DesignDirection — hvilken retning forbedringer bør støtte

AI-kontekst som assembleres:

Forbedringsidéer (prioritert): [tittel, kategori, estimert kost, status]
Avhengigheter: [hvilke idéer har must_before/should_group-relasjoner]
Relevante åpne avvik: [som bør løses først]
Designretning: [hvilken stil forbedringene skal støtte]

Forventet output: Anbefalt sekvens med forklaring av avhengigheter, forslag til samkjøring.

---

J6 — “Hvordan skaper vi en helhetlig stil i huset?”

(B6 — Stilkonsistens)

Scope: MVP (Fase 3)

Entiteter:

• DesignDirection — aktiv retning for interiør (stilord, prinsipper, farger, hva unngå)
• InteriorAsset — eksisterende møbler og dekor med stil-tagger
• LayoutIntent — romintensjon og funksjonssoner

AI-kontekst som assembleres:

Aktiv designretning: [stilord, materialer, farger, unngå]
Eksisterende møbler: [kategori, stil-tagger, farger, rom]
Romintensjon: [funksjonssoner per rom]

Forventet output: Analyse av stilkonsistens, identifisering av elementer som avviker, forslag til helhetlig retning.

---

J7 — “Finn 3 lamper til stuen som passer stilen og gir riktig lys”

(B15 — Produktsøk med lysplanlegging — Post-MVP)

Scope: Post-MVP (krever Brave Search API + LightingPlan)

Entiteter:

• Room — areal, takhøyde, window_count, natural_light
• LayoutIntent — funksjonssoner (sofa-sone, spisesone, etc.)
• DesignDirection — stilord, foretrukne materialer
• InteriorAsset — eksisterende lamper og møbler

AI-kontekst som assembleres:

Romdata: [areal, takhøyde, lysforhold, funksjonssoner]
Lysbehov beregnet: [lux per sone basert på funksjon]
Designretning: [stilord, materialer, farger]
Eksisterende belysning: [hva finnes allerede]

Forventet output: 3 konkrete lampeanbefalinger med type, plassering, lumen-spesifikasjon og stilbegrunnelse. Produktlenker via Brave Search.

---

J8 — “Hvilken sofa bør vi velge – og vil den passe?”

(B16 — Produktvurdering — Post-MVP)

Scope: Post-MVP (krever ProductCandidate-utvidelse)

Entiteter:

• Room — areal, dimensjoner
• LayoutIntent — trafikkflyt, funksjonssoner
• DesignDirection — stil, materialer
• InteriorAsset (considering) — sofaer som vurderes med dimensjoner og pris

AI-kontekst som assembleres:

Romstørrelse: [areal, dimensjoner]
Trafikkflyt: [LayoutIntent.traffic_flow]
Designretning: [stilord, materialer, hva unngå]
Kandidatprodukter: [dimensjoner, pris, stil-tagger]
Barnevennlighet: [child_safe-krav]

Forventet output: Vurdering av om sofaen passer dimensjonsmessig og stilmessig, alternativforslag.

---

J9 — “Lag 3 forslag til TV-stue med møbler vi liker”

(B17 — Layoutgenerering — Post-MVP)

Scope: Post-MVP (krever LayoutOption-implementasjon)

Entiteter:

• Room — areal, takhøyde, window_orientation, door_count
• LayoutIntent — nåværende intensjon og funksjonssoner
• InteriorAsset — møbler brukeren allerede har (status=owned)
• DesignDirection — stil

AI-kontekst som assembleres:

Romgeometri: [areal, vinduer, dører, lysretning]
Eksisterende møbler: [som beholdes i forslaget]
Ønskede funksjonssoner: [TV/sofa, lek, lesekrok]
Barnesikkerhetskrav: [trafikkflyt, hjørner]

Forventet output: 3 LayoutOption-forslag med pros/cons, møbelplassering og score.

---

J10 — “Kan vi kombinere kjøkken og bad-oppussing?”

(B20 — Prosjektsamkjøring — Post-MVP)

Scope: Post-MVP (krever ImprovementDependency med should_group)

Entiteter:

• ImprovementIdea — kjøkken- og bad-oppussing
• ImprovementDependency — should_group-relasjon mellom dem
• BuildingSystem — rør og elektro (delte systemer)
• Task — overlappende deloppgaver

AI-kontekst som assembleres:

Idé A (kjøkken): [beskrivelse, estimert kost, tasks]
Idé B (bad): [beskrivelse, estimert kost, tasks]
Avhengigheter: [delte systemer: rør, ventilasjon]
Potensielle besparelser: [ved samkjøring]

Forventet output: Analyse av samkjøringsgevinst (kostnadsbesparelse, håndverker-overlap), anbefalt rekkefølge og timing.

---

J11 — “Jeg vil laste opp takstrapport og få huset satt opp automatisk”

(B22–B27 — Onboarding / Ingestion Engine — Spec 007)

Scope: MVP (Fase 4 — Spec 007)

Flyt fra brukerens perspektiv:

1. Bruker laster opp salgsoppgave.pdf + takstrapport.pdf
2. Systemet viser "Analyserer dokumenter..." (async jobb)
3. Review-skjerm vises med alle uttrukne fakta gruppert:
   - Boligdata (adresse, byggeår, areal) — confidence-indikator
   - Romstruktur (etasjer, rom, arealer)
   - Tekniske systemer
   - Avvik (TG2/TG3 fra takst)
4. Bruker godkjenner, redigerer eller forkaster hvert faktum
5. Klikker "Bekreft og sett opp huset"
6. Systemet persisterer alle godkjente fakta til ordinære tabeller
7. Bruker lander på dashboard med ferdig utfylt boligmodell

Entiteter involvert:

• Document — PDF lagret i MinIO, ingestion_status oppdatert underveis
• ExtractionJob — sporer pipeline-tilstand og statistikk
• ExtractedFact — hvert enkelt faktum med confidence, kilde og brukerhandling
• → persisteres til: Property, Floor, Room, OutdoorSpace, BuildingSystem, Equipment, Issue

Review-UI — nøkkelkrav:

• Vis hvert faktum med: verdi, sidenummer, tekstutdrag fra kildedokument
• Farge-koding: grønn (høy confidence), gul (medium), rød (lav)
• Inline redigering av verdi før godkjenning
• Trevisning: etasjer → rom → funksjon, systemer → plassering
• Kort oppsummering etter parsing: størrelse, antall rom, teknisk standard, viktigste avvik

AI-kontekst for ekstraksjon (Claude tool use):

System: Du er ekspert på norske takstrapporter. Ekstraher strukturerte data.
        Sett confidence basert på tekstens klarhet. Lav confidence ved usikre tolkninger.
Input:  [Dokumenttekst i bolker, side for side]
Output: [Strukturert JSON med ExtractedFact-liste]

Forventet resultat: Bruker har en komplett boligmodell på 5–10 minutter, inklusive alle TG2/TG3-avvik fra takstrapporten og grunnleggende romstruktur.

---

J12 — “Skriv en brief til rørlegger for badet”

(Håndverkerbrief — Post-MVP)

Scope: Post-MVP (krever Fase 4 AI-assistent + modne Task-data)

Entiteter:

• ImprovementIdea — baderomsoppussing med beskrivelse og motivasjon
• Task — tilknyttede deloppgaver med execution_type=professional
• Room — romdimensjoner og tilstand
• Issue — eventuelle avvik i samme rom
• BuildingSystem — rørlegger-relevante systemer (plumbing, drainage)

AI-kontekst som assembleres:

Romdata: [areal, tilstand, beskrivelse]
Relevante avvik: [TG-kode, beskrivelse, anbefalt tiltak]
Planlagte tiltak: [Task-liste med execution_type=professional]
Kostnadsintervall: [cost_min_nok / cost_max_nok fra ImprovementIdea]
Systemer involvert: [plumbing, drainage — alder og status]

Forventet output: Strukturert håndverkerbrief med: scope-beskrivelse, teknisk tilstand, hva bruker ønsker, hva avvikene krever, og spørsmål bruker bør stille leverandøren.

---

J13 — “Jeg er ny i huset — hjelp meg å gå gjennom det rom for rom”

(Walkthrough-modus — Post-MVP)

Scope: Post-MVP (naturlig forlengelse etter Spec 007 ingestion er fullført)

Flyt fra brukerens perspektiv:

1. Bruker velger "Walkthrough-modus" (tilgjengelig etter PDF-onboarding)
2. AI guider gjennom hvert rom med 4 spørsmål per rom:
   - Hva fungerer bra?
   - Hva er usikkert eller bør sjekkes?
   - Er det noe akutt?
   - Hva vil du endre eller forbedre?
3. Svarene lagres som Observations (kategori: daily_use) og ImprovementIdeas
4. Etter alle rom: oppsummering med anbefalte førsteskritt

Entiteter involvert:

• Room — strukturerer walkthrough-rekkefølge
• Observation — lagrer funn per rom
• ImprovementIdea — lagrer forbedringsønsker som oppstår underveis
• SafetyItem — AI identifiserer og foreslår fra walkthrough-svar

Forventet output: Utfylt observasjonslogg og forbedringsbacklog etter første runde. Dashboardet (Spec 008) vil umiddelbart vise nyttige data.

---

J14 — “Det er vår — hva bør jeg sjekke?”

(Sesongassistent — Post-MVP)

Scope: Post-MVP (krever observasjonsdata over minst én sesong)

Entiteter:

• MaintenancePlan — sesongbaserte sjekkpunkter (sesong=vår)
• SeasonalNote — forrige vår/vinter-oppsummering
• Issue — åpne avvik som sesongvis kan forverres
• BuildingSystem — systemer med sesongbehov (drenering, fasade, uteanlegg)
• Observation — forrige sesongs funn som er relevante å følge opp

AI-kontekst som assembleres:

Gjeldende sesong og dato: [vår 2026]
Sesongspesifikke sjekkpunkter: [MaintenancePlan for vår]
Forrige sesongs funn: [SeasonalNote vinter 2025/2026]
Åpne avvik med sesongrisiko: [fukt, drenering, fasade]
Systemer som trenger sesongsjekk: [drenering, utomhus]

Forventet output: Konkret liste med 5–8 sesongspesifikke tiltak for denne måneden, rangert etter hastegrad. Hvert punkt kobles til eksisterende entiteter i modellen.

---

AI-kontekstbygger — prinsipper

Basert på brukerreisene ovenfor følger disse prinsippene for kontekstbygging:

0. Brukerprofil alltid med

UserPreferences for innlogget bruker inkluderes alltid øverst i system-prompten, uavhengig av spørringstype. Det er den første linjen AI-assistenten leser.

Format i system-prompt:

Brukerens preferanser:
- Budsjettstrategi: [low_cost | balanced | premium]
- Arbeidsstrategi: [diy | hybrid | full_service]
- Tidshorisont: [short_term | balanced | long_term]
- Livssituasjon: [lifestyle_tags, f.eks. "småbarn", "travel"]

Tilpass alle råd, prioriteringer og forslag til disse preferansene.

Eksempel på effekt: “Hva bør vi gjøre med badet?” gir ett svar til en DIY/low_cost-bruker (“utsett totalrenovering, gjør disse 3 enkle forbedringene”) og et helt annet til en full_service/premium-bruker (“totalrenover nå, samkjør med kjøkken”).

1. Spørringstype bestemmer kontekst

Ikke send all data alltid. Identifiser spørringstypen og hent kun relevant kontekst:

Spørringstype	Primære entiteter	Sekundære entiteter
Vedlikehold/sikkerhet	Issue, SafetyItem, Task	BuildingSystem, Equipment
Inneklima	Measurement, Observation	BuildingSystem, Issue
Interiør/stil	DesignDirection, InteriorAsset	LayoutIntent, Room
Prosjektplanlegging	ImprovementIdea, ImprovementDependency	Task, Issue
Produktsøk	Room, LayoutIntent, DesignDirection	InteriorAsset (owned)

2. Kontekststørrelse

• Maks ~4 000 tokens primærkontekst (strukturerte data)
• Maks ~2 000 tokens for pgvector-semantisk tilleggsinnhold
• Rom-spesifikke spørsmål: kun det aktuelle rommet + direkte relasjoner

3. Kildebevissthet i kontekst

Inkluder alltid source_type og confidence i Issue/Measurement/BuildingSystem så AI kan si “ifølge takstrapporten” vs. “du observerte selv”.

4. Norsk output alltid

Systemprompten spesifiserer norsk svar, uansett hvilke entitetsfelt som er på engelsk.