# Intensjons-QA — forståelsen av repoet, lagt fram som korrigerbare påstander > **Hva dette er.** Operatøren stoppet planleggingen 2026-08-06 fordi briefen til demo-uken var > skrevet av en økt som *leste seg til* intensjonen fra dokumenter andre økter hadde skrevet — og to > av rammene ble snudd av primærkildene innenfor én samtale. Denne økten leste primærkildene selv og > legger forståelsen fram som **påstander med kilde**, slik at det koster operatøren én linje å rette > hver enkelt. > > **Slik brukes den:** svar med nummer. «A3 er feil — det er slik: …». Alt du ikke kommenterer, > regnes som bekreftet og blir grunnlag for planen. > > **Ingen påstand her er hentet fra `STATE.md` eller fra hukommelse.** Hver påstand står med kilden, > og hvert tall med kommandoen som produserte det. ## 0. Kilder lest i sin helhet, og målinger gjort Lest i sin helhet i dag: `docs/plan/2026-06-26-maalbilde-agentic-loop.md` · `shared/method-spec.md` · `shared/ingest-spec.md` · `shared/CONCEPT.md` · `docs/plan/2026-07-03-sammenligningsprotokoll.md` · `docs/research/2026-06-23-prior-art-platform.md` §11–§15 · `docs/plan/2026-08-06-v1-inventory.local.md` · `docs/plan/2026-08-06-v1-demo-brief.local.md`. Lest strukturelt (overskrifter + de avsnittene påstandene nedenfor hviler på): `docs/review-2026-07.md` · `docs/plan/2026-07-10-sesjonsplan-fase2-6.md` · `docs/extending.md`. Målinger kjørt i denne økten, på HEAD `520e741`: ``` $ uv run pytest -q --collect-only | tail -1 759 tests collected in 0.49s # = inventarets 755 passed + 4 skipped ✔ $ uv run python -m portfolio_optimiser.simulation # exit 0, offline, uten nøkkel/nettverk ✔ # output identisk med inventarets gjengivelse $ ls ~/repos | grep -iE "okf|toolkit|commons|portfolio" _okf-interim _okf-upstream llm-ingestion-okf llm-ingestion-pipeline-security portfolio-optimiser portfolio-optimiser-claude portfolio-optimiser-commons # MERK: ingen okf-toolkit (se G2) $ grep -ci -- "" shared/method-spec.md shared/ingest-spec.md mandate 0/0 · notify 0/0 · ledger 0/0 · "value report" 0/0 · "cost simulation" 0/0 · dimension 0/0 · "portfolio budget" 0/0 · concurren 0/0 · preflight 0/0 # se G5 ``` To inventar-tall er altså stikkprøvet uavhengig (test-antall, simuleringen), og begge holdt. --- ## A. Intensjonen — hva repoet skal være **A1. Metoden er produktet, ikke koden.** Leveransen er en metode: sverm av agenter genererer kandidat-tiltak → obligatorisk deterministisk validator avgjør tallene → fageksperter dømmer via HITL → systemet lærer av dommene. *(målbilde §1; `method-spec` §1)* **A2. Problemet er *inne i* hvert prosjekt, aldri på tvers.** Porteføljen er uavhengige prosjekter; å behandle porteføljen som ett system er eksplisitt anti-scope. *(målbilde §1; research §15.5 A8; README «Not a portfolio-level reallocator»)* **A3. Differensiatoren er læringssløyfa, og den krever et domene med lærings-overflate.** Energi ble valgt fordi det finnes et ekte gap mellom det *beregnbare* (modellert besparelse) og det *ekspert-kjennbare* (realiseringsgapet). FinOps ble forkastet som «for deterministisk» — der ville sløyfa blitt dekorativ. *(målbilde §10 D-DOMENE; `CONCEPT.md` «Konkret»)* **A4. Tillitsankeret er at agentene aldri får avgjøre verdien.** Validatoren er den ene endpoint-frie dommeren, og den er obligatorisk og blokkerende — aldri en anbefalt plugin. *(målbilde §6; `method-spec` §3 Steg 4; research §15.5 A5)* **A5. Formålet er operatørens læring, men kvalitetskravet er publiseringsklart.** Grunnregelen er at koden ikke får påstå mer enn den gjør — en docstring som lover læring over en usammenkoblet sløyfe er i seg selv en defekt. *(målbilde §1; `method-spec` §1 «Honesty rule (unwaivable)»)* **A6. Sluttleveransen på programnivå er en *rettferdig sammenligning* av to stacker på identisk metode og identisk datagrunnlag — men hver implementasjon skal også stå selvstendig som brukbar.** *(målbilde §1; `sammenligningsprotokoll` §1–§2)* **A7. Liveness-asymmetrien er en låst programbeslutning, ikke et kostnadsvalg som kan revurderes.** MAF-siden kjøres ALDRI mot ekte modell; dens bevis er et skriptet offline-bevis av plumbing, deterministisk ryggrad og lukket læringssløyfe. Claude-siden kjører ÉN minimal ekte API-kjøring som programmets eneste genuine modell-atferdsbevis. Erklæringen gjengis **ordrett** i sluttrapporten. *(`sammenligningsprotokoll` §3 — dette er kilden som snudde min forrige ramme)* **A8. Rammeverket er rent teknisk.** Deployeren eier DPIA/ROS/behandlingsformål; vi bygger kun de tekniske forutsetningene (lokal-only default, provenance, ingen stille egress) + disclaimer. *(målbilde §6; `method-spec` §1 «Boundary»; `ingest-spec` §1)* **A9. Det delte eksemplet er felles og bygges én gang.** OKF-bundles + golden-suite + ekspert-persona er delt kjerne mellom de to repoene; `shared/` her er pull-only subtree av `portfolio-optimiser-commons`. *(målbilde §8–§9; CLAUDE.md konvensjoner)* --- ## B. Prosessen — hvordan arbeidet faktisk styres **B1. Det finnes to nivåer, med vilje.** Program-nivå = målbildet (definerer «ferdig», endres sjelden). Fase-nivå = én Voyage-syklus per inkrement (`/trekbrief → /trekresearch → /trekplan → /trekexecute → /trekreview`), der `/trekreview` er anti-drift-mekanismen. *(målbilde §0)* **B2. Spec-ene er normative og skrevet for å kunne implementeres «from this spec alone».** De er framework-nøytrale ved regel, håndhevet av guard-tester. Det er dét som gjør en rettferdig sammenligning mulig i det hele tatt. *(`method-spec` topptekst + §11; `ingest-spec` topptekst)* **B3. «Ferdig» er definert som load-bearing-tester, ikke som features.** En søm regnes ikke som bygget før en test **feiler** når sømmen kobles fra — «grønn-men-død» er den navngitte fellen. *(målbilde §6–§7; `method-spec` §11 med 12 påkrevde rød-betingelser)* **B4. Ingen ubegrenset løkke, noe sted, og tak kreves ved oppstart.** All konfig valideres fail-fast FØR noen modellklient konstrueres. *(målbilde §6; `method-spec` §8 + §10)* **B5. Kostnadsdisiplin er en designramme, ikke en preferanse.** Utvikling skjer offline/lokalt; M1–M3 er de eneste stegene som koster penger, krever tenant eller krever et menneske. *(`sesjonsplan-fase2-6` §4 + §5-fotnote; CLAUDE.md)* **B6. Metoden skal kunne konsumeres av andre som en Agent Skill, og ekspert-personaen ER en slik skill.** `shared/skills/expert-reviewer/` er den ene delte artefakten begge stacker instansierer reviewer-en fra; `shared/` forblir ren data. *(`method-spec` §4.3; CLAUDE.md)* **B7. Datatilgangen har én arkitektonisk konsekvens som binder alt annet: data når modellen KUN via OKF-bundles.** Ingen query-tid-retrieval mot bundelen, ingen RAG i kjørestien. Konnektorene lever derfor i et deterministisk ingest-steg FØR optimalisereren. *(`ingest-spec` §1–§2; `method-spec` §3 Steg 1)* --- ## C. Hvilke features som faktisk finnes (målt, ikke antatt) **C1. Alle åtte steg er wiret, og målbildets egen «ferdig»-definisjon er oppfylt for løkka.** De fem load-bearing-testene målbilde §7 krever (steg 1, 3/4, 5, 7, 8) finnes som egne filer og suiten er grønn (759 kollektert, 755 passed / 4 skipped). *(målbilde §7; inventaret + min egen måling)* **C2. Simuleringen er det primære metode-beviset, den kjører, og den er allerede demo-formet.** `uv run python -m portfolio_optimiser.simulation` kjører offline til exit 0 og viser to kjøringer adskilt av en promotering, der markøren `realiseringsgrad=0.79` er `False` i Run A og `True` i Run B. *(målt i dag; `simulation.py`-docstring)* **C3. Ingest-laget er reelt, men implementasjonen bor i et ANNET repo.** `llm-ingestion-okf` er en deklarert runtime-dep («the shared implementation of `shared/ingest-spec.md`»), og dette repoets `ingest.py` (202 linjer) er konsument-sømmen over den. Fire golden-ekstraksjoner finnes lokalt (`file`, `sql`, `http`, `mcp`). *(`pyproject.toml`; `examples/ingest-golden-*`)* **C4. Repoet er vesentlig større enn de åtte stegene.** 31 moduler / 7871 linjer i `src/`, 88 testfiler, 42 load-bearing-filer — mot `method-spec` §11s 12 påkrevde sømmer. Overskuddet er ekte kapasiteter: mandat (`mandate.py`), outbox (`outbox.py`), hovedbok (`ledger.py`), verdirapport (`value_report.py`), kostnadssimulering (`costsim.py`), semantisk henting (`semretrieval.py`), dimensjons-gating (`dimension.py`), HITL-ruting (`hitl.py`), varsling (`notify.py`), portefølje-budsjett (`budget.py`), concurrent fan-out, Foundry-preflight (`preflight.py`), MCP-verktøy i kjørestien (`mcp_tools.py`). *(inventaret; docstring-måling i denne økten)* **C5. Det finnes ingen konsoll-kommando.** `[project.scripts]` er tom/fraværende i `pyproject.toml` — alt kjøres som `uv run python -m …`. Målbilde §11 pkt. 7 fører `[project.scripts]` opp som release-hygiene, og det er ikke gjort. *(målt: `grep -n scripts pyproject.toml` → ingen treff)* **C6. Eksempelet som finnes i dag er mikro, og hele det delte laget er lite.** `shared/` har 45 filer, hvorav eksempel-bundelen `bygg-energi-mikro` er 8 filer (én kandidat, ett frø-verdict). Simuleringen kjører dessuten i en temp-katalog, ikke på noe som ligger igjen i repoet. *(målt; inventaret pkt. 2)* **C7. Steg 2 og 6 kan gjøres synlige fra data som allerede finnes; steg 5 kan det IKKE.** Hele presentasjonen er ~30 `print`-linjer (`simulation.py:295–326`) over et `RunResult` som bærer `outcome` (typet `ValidatedProposal | Rejection`), `verdict`, `retrieved`, `debate_output`, `checker_verdict` og `coverage`. Men `generate_via_llm` returnerer bare sluttresultatet — den mellomliggende avvisningen (`last`) forbrukes internt og forlater aldri funksjonen. **Og i demoen i dag validerer forslaget på FØRSTE forsøk**, så forbedrings-løkka trigges ikke i det hele tatt. Å vise steg 5 krever derfor både en ny søm og et nytt skriptet avvis-så-korriger-forløp — ikke bare en `print`. *(målt i `simulation.py`, `run.py:115–133`, `generate.py:134–196`)* **C8. Kosmetikken i inventaret er bekreftet.** To `GroupChatOrchestrator reached max_rounds=3; forcing completion.`-linjer og to MAF `ExperimentalWarning`-linjer skrives FØR banneret. *(målt i dag, identisk med inventaret)* --- ## D. Fem gap i bildet briefen hviler på — det QA-en fant Rammene A/B/C i briefen står. Det som var galt, var **bildet under dem**. **G1. Intensjonen har en andre akse som ikke sto på listen over primærkilder.** STATE pekte på fem kilder (målbilde, research §15, `method-spec`, sammenligningsprotokoll, `ingest-spec`). Ingen av dem nevner roadmap-aksen — og det er DEN de fleste modulene i C4 kommer fra: `docs/review-2026-07.md` (uavhengig kryssmodell-review, funn F1–F14 langs fire akser) og `docs/plan/2026-07-10-sesjonsplan-fase2-6.md` (S2.0–S5.4, beslutningene D-A–D-I, milepælene M1–M3, roadmap C/D/E). Målt kobling: 20 S-numre, 18 av dem med treff i `src/`+`tests/`. **Konsekvens:** en plan skrevet fra de fem kildene alene ville beskrevet et repo med åtte steg, og ikke gjenkjent to tredeler av det som står der. **G2. Den besluttede demo-stien er fabrikk-avhengig, og fabrikken finnes ikke.** D-H (BESLUTTET 2026-07-14) definerer demo-stien ordrett: «klon → unzip energi-eksempel i bundle-innboks → fabrikk bygger → hele sløyfa kjører». Fabrikken er D-G/T0 — et eget repo med arbeidstittel `okf-toolkit`, som per måling **ikke eksisterer** (`ls ~/repos`). Sesjonsplanen sier eksplisitt at fabrikk-avhengige deler av D-F/D-H — «realistisk energi-innhold via fabrikken, ekspert-dom- oversettelse, **demo-sti**, M3-pilot» — er blokkert til T0 finnes. Briefens krav «enhver som laster ned repoet skal kunne kjøre nøyaktig det samme» ER den demo-stien. **Konsekvens:** planen må velge eksplisitt — ferdigbygd bundle sjekket inn i commons (fabrikk ute av 13.-august-stien), eller akseptere at stien er blokkert. Briefen min nevnte T0 ikke med ett ord. **G3. Innholdsmodellen for det realistiske eksemplet er allerede besluttet.** D-F (BESLUTTET 2026-07-14, fasit i `2026-07-14-revisjonspakke-DF-DI.md` §1): kunnskapstyper (tiltaksmønstre / erfaringsnotater / faglige råd) **alle med påkrevd kildebelegg**, kun lesestoff for forslagsstilleren, validatorens regler urørt, streng separasjon fra dommene (bibliotek via `bundle_context`, korreksjoner KUN via ExpeL-folden), delt dimensjonsbibliotek materialisert inn i hver bundle via ingest-mønsteret, trinnvis lesing. Samme beslutning sier at **realistisk energi-innhold er «egen senere innholds-produksjonsjobb»** — altså en allerede planlagt jobb i programmet, ikke ny scope. **Konsekvens:** bestillingen til commons skal referere D-F, ikke definere en innholdsmodell på nytt. En bestilling som finner opp sin egen struktur ville satt commons i konflikt med sin egen beslutning. **G4. Demoen er programmets nivå-2-bevis, med et forhåndsavtalt ærlighetstak.** D-I (BESLUTTET 2026-07-14): publiserings-påstanden er **nivå 2** — realistisk case, modellerte tall, aldri salgsspråk over beleggsnivået; nivå 3 (ekte pilot) er en åpen invitasjon. Og: «README oppdateres FØRST når nivå-2-beviset finnes». **Konsekvens:** 13. august er ikke bare en presentasjon, det er milepælen som utløser en README-oppdatering — og formuleringene i demoen er bundet av et tak som allerede er avtalt. Det gjør ærlighets-leveransen i ramme A til et *eksisterende* krav, ikke et nytt påfunn. **G5. Den delte spec-en dekker løkka + ingest — ingenting av C4-overskuddet.** Målt: `method-spec` og `ingest-spec` nevner *ikke* mandat, varsling, hovedbok, verdirapport, kostnadssimulering, dimensjon, portefølje-budsjett, concurrency eller preflight (0 treff hver). **Konsekvens for A6:** sammenligningen er en sammenligning av den **spec-ede kjernen**, ikke av dette repoet. Et søsken bygget «from spec alone» ville ikke hatt disse. Det er ikke nødvendigvis feil — men det er en påstand om sammenligningens rekkevidde som må stå eksplisitt i sluttrapporten, og D7-speilings- gjelden (CLAUDE.md: S2.7, S3.2, S4.0, (p), (a)/(i), `mandate.py`, A5, B4 — søskenet har ikke svart) er den samme saken sett fra andre siden. **G6 (mindre, men styrer en formulering).** S3.5 er i praksis ikke bygget: eneste treff i kode er en kommentar i `hitl.py:169` om en «minimal MVP stand-in for the S3.5 dimension catalog», og S3.5 er gated på et commons-amendment som per CLAUDE.md aldri kom. Dimensjonskatalogen er altså et stand-in, ikke den besluttede delte modellen. *(målt: `grep -rn S3.5 src/ tests/`)* --- ## E. Det jeg IKKE kunne verifisere — ingen hull fylt med antakelser 1. **CHANGELOG-ens `[0.1.0]`** — ~30 tekniske påstander, allerede publisert, ikke uavhengig kontrollert av noen. Jeg har ikke gått gjennom dem i denne økten. 2. **Commons' egen tilstand og beslutningskø.** Jeg ser bare de 45 filene subtree-en har hentet, og `shared/docs/plan/` viser at commons har en aktiv egen beslutnings-prosess (ti plan-dokumenter, nyeste 2026-08-02). Om commons har kapasitet 7.–13. august, vet jeg ikke — og jeg kan ikke se det herfra. 3. **Søsken-repoets faktiske tilstand.** `portfolio-optimiser-claude` eksisterer som katalog; hva som er bygget der, har jeg ikke undersøkt (ramme B parkerer det uansett). 4. **Om `_okf-interim` / `_okf-upstream` er forløpere til T0** eller noe annet. Jeg har ikke sett i dem — de ligger utenfor dette repoet. 5. **Realiserings-kostnaden av C7** (ny søm for steg 5) er ikke estimert; det hører i planen. --- ## F. Hva denne QA-en endrer for planleggingsøkten Ikke rammene — de står. Men fire ting planen nå må gjøre som briefen ikke ba om: 1. **Behandle T0/fabrikken eksplisitt (G2):** velg ferdigbygd bundle, og si at fabrikk-stien er utsatt — ellers planlegges det mot en blokkert avhengighet. 2. **Bestillingen til commons refererer D-F (G3)** i stedet for å definere innhold på nytt. 3. **Steg 5 er ikke presentasjonslag (C7):** ny søm + nytt skriptet forløp. Steg 2 og 6 er presentasjon. 4. **Nivå-2-taket (G4)** blir demoens ærlighets-ramme, og README-oppdateringen er en konsekvens som skal med i planen — eller eksplisitt utsettes. --- ## G. Operatørens svar (2026-08-06) — de fire beslutningene planen bygger på Påstandene A1–C8 ble lagt fram og **ingen ble korrigert** → alle 20 står som bekreftet, slik dokumentets egen regel sier. Det operatøren derimot avgjorde, var de fire valgene QA-en avdekket: **O1 (svar på G2) — FERDIGBYGD EKSEMPEL.** Energi-eksemplet bygges for hånd og sjekkes inn i commons. **Fabrikk-stien (D-G/T0 `okf-toolkit`) er eksplisitt utsatt** og er ute av 13.-august-stien. Demoen viser fortsatt «last ned → kjør» — men innholdet er kuratert, ikke fabrikkert, og det er dét som skal sies høyt. Konsekvens: D-Hs demo-sti pkt. 4 er **delvis oppfylt** i denne demoen, og avviket hører i ærlighets-avsnittet, ikke i en fotnote. **O2 (svar på C7) — STEG 5 BYGGES OG VISES LIVE.** Ny søm som slipper den mellomliggende avvisningen ut av `generate_via_llm`, pluss et nytt skriptet avvis-så-korriger-forløp i simuleringen. Estimert én økt. Begrunnelsen er fristen selv: kravet er ALLE ÅTTE STEG, og et steg som bare omtales er ikke vist. Testbevis-varianten og den muntlige varianten ble vurdert og valgt bort. **O3 (svar på E2) — BESTILL NÅ MED FRIST 11. AUGUST, OG PLANLEGG RESERVE.** Bestillingen sendes til commons i dag via `coord-send`; planen får et fall-tilbake her (kjør demoen på `bygg-energi-mikro`) som utløses hvis eksemplet ikke er hentbart 11. august. Ingen jobber i commons' repo fra denne taben. **O4 (svar på G4) — README OPPDATERES ETTER DEMOEN (14.–15. august).** Rekkefølgen D-I krever holdes: beviset først, påstanden etterpå. Planen reserverer tid, men README røres ikke før torsdag. ### Målinger gjort etter beslutningene (grunnlag for bestillingens størrelse) ``` $ uv run python -c "okf.navigate_bundle('shared/examples/bygg-energi-mikro') → bundle_context" context_files: 4 · chars: 12005 · ≈ 3001 tokens kilder-realiseringsgap.md (reference) 3519 · bygg-kontor-nord.md (project) 1594 tiltak-led-retrofit.md (hypothesis) 3007 · metode-ipmvp-a.md (methodology) 1759 ``` To konsekvenser bestillingen MÅ bære, begge målt og ingen av dem valgfrie: - **`bundle_context` rendrer HELE brødteksten i hver navigert fil** (`okf.py:206–233`), og **trinnvis sammendrags-lesing (D-F pkt. 6) er ikke bygget.** D-F pkt. 7s fulle ambisjon — 15–30 tiltak i ett bibliotek — ville derfor gitt 40–90 000 tegn (10–22 k tokens) inn i HVER hypotese-prompt, under harde token-tak. `dimension`-filteret hjelper ikke, siden alt her er samme dimensjon. Bestillingen må derfor være **størrelses-kappet**, og det fulle biblioteket forblir den «egne senere innholds-produksjonsjobben» D-F pkt. 7 selv navngir. - **D-F pkt. 4 løser dette strukturelt:** delt bibliotek *materialiseres inn i hver prosjekt-bundle*. Flere prosjekter = flere bundles, ikke én stor. Det holder per-kjøring- konteksten nede OG gir porteføljestien (bølger, budsjett, hovedbok) noe ekte å kjøre på. **Innplasserings-funn (godt nytt for planen):** `simulate_learning_loop(bundle_dir, …)` (`simulation.py:183`, kalt `:293`) tar bundle-katalogen som **parameter** og kopierer den til en arbeidskatalog. Et nytt eksempel plugges altså inn i en eksisterende søm. **Men** de skriptede svarene er skrevet mot LED-caset, så nytt innhold krever nytt manus — den koblingen er planens egentlige kostnad ved O1, ikke selve bundle-innlesingen. ### Fortsatt ubesvart (ikke blokkerende — anbefaling gjelder ved taushet) - Dette dokumentet til den offentlige speilingen? **Anbefaling: nei** (intern analyse). - Tracking av `.claude/projects/`? **Anbefaling: nei** (uendret fra tidligere økter).