prd
Dette dokumentet er auto-synket fra kildefilene i boligassistent-repoet. Endringer her vil overskrives ved neste sync. Rediger kildefilen direkte.
- Gi huseieren én strukturert modell av boligen som samler all relevant kunnskap
- Støtte bevisst og gradvis forståelse av huset over tid — ikke forhastede beslutninger
- Prioritere sikkerhet og nødvendig vedlikehold tydelig over ønsker og idéer
- Støtte langsiktig backlog-tenkning for forbedringsprosjekter
- Gi AI-assistenten riktig kontekst til å gi relevante og spesifikke råd
- Støtte helhetlig stilutvikling for interiør, eksteriør og hage
Non-goals (v1)
Section titled “Non-goals (v1)”Se docs/product/non-goals.md for fullstendig liste. Kort oppsummert:
- Ingen BIM/CAD-funksjonalitet
- Ingen smarthus-integrasjon
- Ingen prediktive modeller for vedlikehold
- Ingen avansert økonomimodellering
- Ingen SaaS-distribusjon i første fase
Primærbruker
Section titled “Primærbruker”Produktet er bygget for par 35–55 år som eier enebolig med tomt og hage i Norge/Skandinavia. Ressurssterke, proaktive, langsiktige. Paret består av to komplementære roller:
- Planleggeren (Preben) — tenker helhet, strukturerer, vedlikeholder, planlegger flere år frem. Jobber typisk på desktop.
- Observatøren (Partner) — registrerer ting i forbifarten, fokuserer på stil og utvikling, foretrekker enkel oversikt. Jobber typisk på mobil.
Begge brukere er knyttet til samme hus og deler ett felles arbeidsrom. Paret koordinerer seg imellom ved å snakke sammen — appen skal ikke spore, synliggjøre eller organisere fordelingen mellom dem. Ingen attribusjon, ingen aktivitetsfeed, ingen partner-varsler.
Fullstendige personas, rollearketyper (Vaktmester/Arkitekt) og anti-patterns:
docs/ux/personas.md.
Brukerbehov
Section titled “Brukerbehov”Behovene er organisert etter scope: MVP (Fase 0–4), Post-MVP (Fase 5+). Hvert behov er koblet til entitetene som realiserer det, og et representativt brukereksempel.
MVP-behov
Section titled “MVP-behov”| # | Brukereksempel | Behov | Primærentiteter | Prioritet |
|---|---|---|---|---|
| B1 | ”Hva må jeg faktisk gjøre med huset det neste året?” | Strukturert oversikt over nødvendig vedlikehold, prioritert etter risiko og kost | Issue, Task, MaintenancePlan, BuildingSystem | Høy |
| B2 | ”Hva er farlig for barnet mitt akkurat nå?” | Rask identifikasjon av barnesikkerhetsrisikoer i hus og hage med konkrete tiltaksforslag | SafetyItem, Room, OutdoorSpace, InteriorAsset | Høy |
| B3 | ”Hvorfor er inneklimaet dårlig – og hva gjør jeg med det?” | Forstå og håndtere radon, fukt og ventilasjonsproblemer ved å koble målinger, observasjoner og systemer | Measurement, Issue, BuildingSystem, Observation | Høy |
| B4 | ”Hvordan bruker vi faktisk huset – og hva bør vi endre?” | Forstå reell bruk av rom gjennom observasjoner over tid, identifisere mønstre og friksjon | Observation, Room, LayoutIntent | Høy |
| B5 | ”Hvilke oppgraderinger bør vi gjøre – og i hvilken rekkefølge?” | Skille mellom feil (Issue) og ønsker (ImprovementIdea), analysere avhengigheter og timing | ImprovementIdea, ImprovementDependency, Task, Issue | Høy |
| B6 | ”Hvordan skaper vi en helhetlig stil i huset?” | Lagre stilpreferanser, koble møbler og materialvalg til designretning, evaluere nye kjøp mot eksisterende stil | DesignDirection, InteriorAsset, LayoutIntent | Medium |
| B7 | ”Hva har vi allerede kjøpt – og hva mangler vi?” | Oversikt over inventar per rom, med status eid / vurderes / ønskeliste | InteriorAsset, Room | Medium |
| B8 | ”Hva vet jeg egentlig om huset mitt?” | Samle dokumenter, bilder, takstrapport og notater på ett søkbart sted. Bilder knyttes direkte til rom, avvik, observasjoner og idéer — ikke til et separat bildearkiv. | Document, Photo, KnowledgeLayer | Medium |
| B9 | ”Hva bør jeg sjekke denne måneden?” | Sesongbasert vedlikeholdssjekkliste koblet til systemer og rom | MaintenancePlan, Task, BuildingSystem | Medium |
| B10 | ”Hvordan utvikler huset seg over tid?” | Lagre historikk om observasjoner, tiltak og beslutninger for langsiktig læring | Observation, DecisionNote, Task, Issue | Medium |
| B11 | Registrere rom, etasjer og uteområder | Strukturert romlig modell av boligen som grunnlag for alle andre lag | Property, Floor, Room, OutdoorSpace, SupportSpace | Høy |
| B12 | Registrere tekniske systemer og utstyr | Teknisk infrastruktur med vedlikeholdsbehov og koblinger til rom | BuildingSystem, Equipment, Manual | Høy |
| B13 | Statusoversikt over avvik, oppgaver og forbedringsidéer | Samlet dashboard som gir et øyeblikksbilde av boligens tilstand og prioriteringsliste | Issue, Task, ImprovementIdea, SafetyItem | Høy |
| B14 | Rask registrering av observasjoner fra mobil | Lav friksjon for å logge noe man legger merke til, direkte fra telefonen — inkludert å ta bilde på stedet. Bildet knyttes automatisk til det registrerte avviket, observasjonen eller idéen. | Observation, Issue, ImprovementIdea, Photo | Medium |
Onboarding-behov (MVP — Spec 007)
Section titled “Onboarding-behov (MVP — Spec 007)”Disse behovene oppstår ved første gangs bruk av systemet, og er kritiske for time-to-value. Uten en god onboarding-flyt tar manuell oppsett 2–4 timer — for lang tid.
| # | Brukereksempel | Behov | Primærentiteter | Prioritet |
|---|---|---|---|---|
| B22 | ”Jeg vil laste opp salgsoppgave og takstrapport og få huset satt opp automatisk” | Last opp PDF, AI ekstraherer og strukturerer data til Property, SpatialModel og BuildingSystems | Document, ExtractionJob, ExtractedFact | Høy |
| B23 | ”Jeg vil se hva AI har tolket – før det lagres” | Preview av uttrukket data med confidence-score og kildehenvisning. Bruker godkjenner, redigerer eller forkaster hvert funn. | ExtractedFact | Høy |
| B24 | ”Jeg vil enkelt kunne rette feil AI gjør” | Inline redigering av uttrukket data med godkjenn/endre/forkast per funn. Systemet husker korreksjoner. | ExtractedFact | Høy |
| B25 | ”Jeg vil forstå sammenhengen i det som er hentet ut” | Visualiser etasjer → rom → funksjon og systemer → plassering som en enkel trestruktur | ExtractedFact, Room, BuildingSystem | Medium |
| B26 | ”Jeg vil få en komplett første versjon av huset mitt – raskt” | Etter godkjenning bootstrappes hele modellen: romstruktur, systemer, første avvik fra takst, første vedlikeholdsoppgaver | Property, Room, BuildingSystem, Issue, Task | Høy |
| B27 | ”Jeg vil kunne laste opp nye dokumenter senere og få oppdateringsforslag” | Levende modell — nye takstrapporter og fagrapporter analyseres og gir forslag til oppdateringer | Document, ExtractionJob, ExtractedFact | Medium |
| B28 | “Jeg vil samle referansebilder for stilen vi vil ha i stuen” | Moodboard for designretning: bilder som viser ønsket stilretning. Visuell input for AI stilbeskrivelse og kjøpsvurdering. | DesignDirection, Photo | Medium | | B29 | “Jeg vil dokumentere hva vi drømmer om og hva vi vil endre” | Forbedringsidéer med bilder: inspirasjonsbilde som viser ønsket sluttresultat, og bilde av dagens situasjon som motiverer idéen. | ImprovementIdea, Photo | Medium | | B30 | “Jeg ser en lampe i nettbutikken — jeg vil knytte den til idéen min” | AI-drevet utfylling av forbedringsidé fra produktlenke, inkludert automatisk henting av produktbilde som inspirasjonsbilde. | ImprovementIdea, Photo | Medium | | B31 | “Hvilke konkrete produkter skal vi kjøpe for å realisere idéen?” | Kobling mellom forbedringsidé og planlagte innkjøp (InteriorAsset). Idékortet viser produktet med pris og bilde. | ImprovementIdea, InteriorAsset | Medium |
B22–B27 er implementert (Fase 1–2, Spec 007 + 011). B28–B31 er i Fase 4-backlog: B28 → Spec 036, B29 → Spec 035, B30 → Spec 037, B31 → Spec 038.
Kritisk designprinsipp: AI fyller aldri databasen direkte. Flyten er alltid: AI foreslår → bruker godkjenner → system lagrer.
Post-MVP-behov (Fase 5+)
Section titled “Post-MVP-behov (Fase 5+)”| # | Brukereksempel | Behov | Primærentiteter | Avhengighet |
|---|---|---|---|---|
| B15 | ”Hvilke lamper bør jeg kjøpe – og passer de faktisk i rommet?” | Produktsøk med evaluering mot romstørrelse, funksjonssoner, designretning og lysbehov. Prissporing over tid. | ProductCandidate, LightingPlan, ShoppingTracker, DesignDirection | Brave Search API, ShoppingTracker-implementasjon |
| B16 | ”Hvilken sofa bør vi velge – og vil den passe i rommet?” | Hente dimensjoner, validere mot trafikkflyt, vurdere stilmatch og barnevennlighet, foreslå alternativer | ProductCandidate, LayoutIntent, DesignDirection | ProductCandidate-implementasjon |
| B17 | ”Hvordan bør vi innrede TV-stuen?” | Romanalyse med dimensjoner og lysforhold, generere 2–4 layoutforslag med møbelplassering og trafikkflyt | LayoutOption, Room, LayoutIntent, InteriorAsset, DesignDirection | LayoutOption-implementasjon |
| B18 | ”Hvordan kan dette rommet faktisk se ut?” | Realistisk romvisualisering basert på faktiske mål og møbler, med stilalternativer | DesignScenario, RoomGeometry, LayoutIntent, InteriorAsset | DALL-E 3-integrasjon |
| B19 | ”Hva vil dette prosjektet koste og ta av tid?” | Estimere materialkost, arbeid og tidsbruk basert på historikk og standardverdier, justert for kompleksitet | ImprovementIdea, Task, ProjectEstimate | Historikkdata fra MVP |
| B20 | ”Hvilke prosjekter bør vi gjøre samtidig?” | Analysere fysiske relasjoner, rør/elektro-overlapp og støynivå for å foreslå samkjøring og riktig rekkefølge | ImprovementIdea, ImprovementDependency, Task | Strukturerte avhengigheter (ImprovementDependency) |
| B21 | ”Hva bør vi IKKE gjøre nå?” | Identifisere premature beslutninger og manglende avhengigheter — foreslå å vente eller gjøre noe annet først | ImprovementIdea, ImprovementDependency, DecisionNote | AI-resonnering + avhengighetsdata |
Produktmeta-behov (Fase 5+)
Section titled “Produktmeta-behov (Fase 5+)”Disse behovene gjelder produktet selv — ikke boligforvaltning. De realiseres via AI-assistenten som gjenkjenningskanal og lagres som strukturert backlog-input for videre produktutvikling.
| # | Brukereksempel | Behov | Primærentiteter | Avhengighet |
|---|---|---|---|---|
| B32 | ”Jeg vil gi tilbakemelding om noe som er vanskelig uten å forlate appen” | AI-assistenten gjenkjenner produktfeedback naturlig i samtale, foreslår kategorisering og lar bruker bekrefte med ett klikk. Støtter valgfritt skjermbilde. | UserFeedback | AI-assistent (Spec 042 + 047) |
MVP-scope
Section titled “MVP-scope”Se docs/product/scope-mvp.md for detaljert avgrensning.
MVP dekker:
- Spatial model (eiendom, etasjer, rom, uteområder)
- Tekniske systemer
- Avvik og sikkerhetsproblemer (ConditionLayer)
- Observasjoner (ExperienceLayer, grunnleggende)
- Forbedringsidéer og oppgaver (PlanningLayer)
- Designretning og interiørobjekter (DesignLayer + InteriorLayer, grunnleggende)
- Brukerautentisering med huskobling
- Bildelagring og dokumentopplasting (KnowledgeLayer)
- AI-assistent: kontekstuell rådgivning basert på romdata
Fremtidig scope (ikke MVP)
Section titled “Fremtidig scope (ikke MVP)”- AI-genererte romvisualiseringer (DALL-E 3)
- Produktsøk via Brave Search
- Sesongbaserte vedlikeholdsplaner
- Eksport av boligdokumentasjon
- Multi-hus-støtte
- Utvidet rapportering og statistikk
- Integrasjon mot fagrapporter og offentlige registre
Styrende prinsipper
Section titled “Styrende prinsipper”- Forenkling over alt — Produktet skal gjøre mindre, ikke mer. Hver ny funksjon må kjempe for eksistensretten. Minimum viable surface per skjerm; progressiv avsløring som systemprinsipp; default lavt detaljnivå. Se
docs/product/vision.mdogdocs/ux/personas.mdseksjon 3. - Separasjon av begreper — Problem ≠ Ønske. Observasjon ≠ Oppgave. Equipment ≠ Møbel.
- Kildebevissthet — All data skal ha kilde og konfidensgrad
- Gradvis modning — Systemet skal tåle at data revideres over tid, ikke bare legges til
- Praktisk brukbarhet — Modellen skal gjøre det lettere å ta beslutninger, ikke vanskeligere
- AI-kontekstoptimalisert — Datastrukturen skal designes for at AI kan hente riktig kontekst
- Skalerbarhet — Designet for å støtte flere hus uten store omskrivinger. Multi-user-koordinering er eksplisitt ikke en produktambisjon.
- AI-first, ikke CRUD-first — Systemet skal minimere antall manuelle CRUD-operasjoner brukeren trenger. AI skal generere, foreslå og vedlikeholde data basert på domenemodellen. Manuell input er fallback, ikke default.
- AI foreslår — bruker godkjenner — system lagrer — AI fyller aldri databasen direkte. All AI-skriving går gjennom eksplisitt godkjenning med mulighet for korreksjon og undo (ADR-010).
- Boligen er et hjem, ikke et prosjekt — Tone, farge, typografi og språk skal reflektere dette. Ikke enterprise-dashboard, ikke productivity-hub.
- Appen er ikke et koordineringsverktøy mellom brukerne — Paret koordinerer ved samtale. Ingen attribusjon, assignee, aktivitetsfeed eller partner-varsler.
- Bilder er kontekstuell dokumentasjon — Bilder vises der dataen finnes, ikke i et separat bildearkiv. Hvert bilde har semantisk rolle (hva det dokumenterer og formålet): dokumentasjon av avvik, nåtilstand av idé, inspirasjon for designretning, produktfoto av inventar. Rollen bestemmer hvor bildet vises og hvordan AI bruker det.