Viktige beslutninger

Prosjektet har 10 dokumenterte Architecture Decision Records (ADR-er). Her er de syv som best illustrerer de viktigste arkitekturelle valgene.

Se den fullstendige beslutningsloggen for alle 10.

ADR-001: PostgreSQL fremfor grafdatabase

Domenemodellen er naturlig en property graph med mange relasjoner. Grafdatabaser (Neo4j) ville modellert dette naturlig.

Beslutning: PostgreSQL med fremmednøkler og polymorfiske referanser.

Begrunnelse: Relasjonene i dette systemet er ikke komplekse nok til å rettferdiggjøre graftraversal. pgvector gir semantisk søk uten ekstern vector store. Enklere drift og backup.

ADR-007: pgvector fremfor ekstern vector store

Semantisk søk kan løses med Pinecone, Weaviate eller Qdrant.

Beslutning: pgvector som PostgreSQL-utvidelse.

Begrunnelse: Holder alt i én database. Ingen ny infrastruktur i MVP. Cosine similarity er tilstrekkelig for dette bruksomfanget. Kan migreres til ekstern vector store uten store kodeendringer.

ADR-002: Issue og ImprovementIdea som separate entiteter

Begge handler om “ting som bør gjøres med boligen”. Man kunne brukt én tabell med type-enum.

Beslutning: Separate entiteter med separate tabeller.

Begrunnelse: Issue er et faktum (noe er galt). ImprovementIdea er et ønske (noe kan bli bedre). De har ulike felter, ulik livssyklus og krever ulik prioritering. AI-en trenger å skille mellom dem.

ADR-003: Equipment og InteriorAsset som separate entiteter

Begge er fysiske objekter i et rom. Man kunne brukt én generisk “asset”-tabell.

Beslutning: Separate entiteter.

Begrunnelse: En varmepumpe og en sofa har fundamentalt ulike datamodeller. Equipment tilhører BuildingSystem og har vedlikeholdsbehov. InteriorAsset tilhører DesignLayer og har stilattributter. AI-kontekst for interiørrådgivning skal ikke inkludere teknisk utstyr.

ADR-006: Polymorfiske referanser for stedskobling

Issue, Observation, Task kan knyttes til Room, OutdoorSpace, BuildingSystem eller SupportSpace. Alternativet er separate nullable fremmednøkkelkolonner for hver type.

Beslutning: location_ref_type TEXT + location_ref_id UUID.

Begrunnelse: Separate fremmednøkler gir mange nullable kolonner og komplisert spørringslogikk. Polymorfisk referanse er enklere å lese og vedlikeholde. Svakhet: ingen DB-integritet — kompenseres med applikasjonsvalidering.

ADR-009: ImprovementDependency fremfor separat Project-entitet

Brukerbehov B20 (“Kan vi kombinere kjøkken og bad-oppussing?”) krevde strukturert modellering av avhengigheter mellom forbedringsprosjekter. Et utkast foreslo en separat Project-entitet.

Beslutning: Ingen Project. En ny ImprovementDependency-junction-tabell i stedet.

Begrunnelse: Project var nesten identisk med ImprovementIdea — duplikat-problem. ImprovementDependency med dependency_type (must_before / should_group / independent) gir den strukturerte avhengighetsmodelleringen som trengs, uten å introdusere tvetydighet.

ADR-010: Ingestion Engine — “AI foreslår, bruker godkjenner”

Onboarding via takstrapport krever AI-ekstraksjon av strukturerte data. Spørsmålet var om AI kan skrive direkte til databasen, eller om brukeren alltid må godkjenne.

Beslutning: AI fyller aldri databasen direkte. Flyten er alltid: AI foreslår → bruker godkjenner → system lagrer.

Begrunnelse: AI gjør feil — særlig på norske takstrapporter med ustrukturert layout. Brukeren må ha tillit til at data er korrekt. Feil data i kjernemodellen er verre enn ingen data.

ADR-005: Spec-driven development med filbasert prosjektminne

Spørsmålet var hvordan man sikrer at Claude Code jobber kontrollert og konsistent gjennom hele prosjektets levetid.

Beslutning: Filbasert spec-driven development. CLAUDE.md definerer arbeidsregler. Specs i specs/ definerer krav. Evaluations i evaluations/ dokumenterer verifikasjon.

Begrunnelse: Claude Code leser filer direkte — filbasert minne er mer pålitelig enn instruksjoner i minnet. Specs versjonskontrolleres. Strukturert arbeidsflyt reduserer risiko for at Claude tar uønskede arkitekturavgjørelser.