docs(plan): revisjonspakke D-F–D-I — intensjonsanalyse 2026-07-14 (innholdsmodell, felles OKF-modul/toolkit-repo, team-oppskrift, verdibevis + kostnadssimulering)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0145ZKPLMVeqM47z2jxxokym

docs/plan/2026-07-14-revisjonspakke-DF-DI.md

@@ -0,0 +1,189 @@
+# Revisjonspakke — D-F–D-I: intensjonsanalyse → planverk-oppgradering (2026-07-14)
+
+> **Status:** BESLUTTET i operatør-samtale 2026-07-14. Denne pakka er fasit-protokollen +
+> innplasserings-planen. **Ingenting frosset er endret ennå** — amendments skjer bevisst via
+> commons (PULL-ONLY) og egne økter, med denne pakka som kilde. Operatøren har gitt
+> klarsignal for HELE oppgraderingen («du får lov til å gjøre alt som trengs»); utførelsen
+> er parkert på Fable-kvote (92 % brukt før torsdag) — gjenopptas 2026-07-16+.
+> **Provenance:** anbefalinger = AI (Fable 5, intensjonsanalyse-økt #8 2026-07-14);
+> beslutninger = operatør, protokollert punktvis under. Grunnlag: dokumentanalyse (målbilde,
+> method-spec, ingest-målbilde, research §15, review 2026-07, sesjonsplan) + to
+> Opus-kartlegginger (kode/bundle-innhold; kryssrepo-OKF-inventar — fanget i §0.2, finnes
+> ellers kun i samtalen).
+
+---
+
+## 0. Funnene som utløste pakka (intensjonsnivå — ikke implementasjon; F1–F14 er dekket)
+
+1. **F-INT-1 Kunnskapsinnholdet er underspesifisert → kaldstart-problem.** Method-spec §2
+   lister kontekst-lagets innhold generisk; intet krav om historisk fagkunnskap om
+   sparemåter per dimensjon. Substrat i dag: ÉN mikro-bundle (`bygg-energi-mikro`), de 4
+   porteføljeprosjektene er ikke bundles; `Dimension` konstrueres kun i tester (ingen
+   katalog/loader). Delt kryssprosjekt-fagkunnskap har ingen arkitekturplass (kontekst-laget
+   er strengt per-prosjekt). Kobler til F5/S3.2 (multi-kandidat).
+2. **F-INT-2 OKF-duplikasjon + spec-avvik.** 6 kodelokasjoner håndruller formatet (§0.2);
+   method-spec avviser OKF-spec-ens anbefalte `/`-lenkeform (review F4/U-1, ligger i D-A).
+3. **F-INT-3 Brukervennlighet mangler «ferdig»-definisjon.** Research B9
+   (onboarding-intervju) falt ut av målbildet; `main()` driver ikke Fase-1-featurene (P6);
+   README-ens eneste inngang er simuleringen.
+4. **F-INT-4 «Betydelig verdi» er ikke operasjonalisert.** Ingen suksesskriterier for
+   verdibevis; syntetisk domene (D4) kan ikke bevise besparelser; pilot (M3) = 1×1.
+5. **F-INT-5 Kjøringskost er en CFO-beslutning.** Reell skala = 50k–1M+ NOK per
+   signering → kostnadsestimat/simulering FØR kjøring er en produktegenskap, ikke nice-to-have.
+
+### 0.2 Kryssrepo-OKF-inventar (Opus-kartlegging 2026-07-14, komprimert)
+
+| # | Lokasjon | Språk/størrelse | Delmengde |
+|---|---|---|---|
+| A1 | `portfolio-optimiser/src/portfolio_optimiser/okf.py` | Py, 202 l | les + skriv + validér |
+| A2 | `portfolio-optimiser-claude/src/portfolio_optimiser_claude/okf.py` | Py, 134 l | **kun les** (mangler skrive-halvdelen/Steg 8-primitiver) |
+| B1 | `ktg-plugin-marketplace/okr/` (lib+scripts `.mjs`) | JS | index-generering + validering |
+| B2 | `ktg-plugin-marketplace/linkedin-studio/scripts/brain/` | TS | emit + conformance-test |
+| C1 | `claude-code-llm-wiki/tools/wiki_ingest/bundle.py` | Py, 436 l | OKF-produsent (ingest→bundle) |
+| C2 | `llm-ingestion-pipeline-security/src/llm_ingestion_guard/okf.py` | Py, 579 l | defensiv validator, **reject-by-default** |
+
+≥4 uavhengige Python-`parse_frontmatter` + 2 i JS. Ingen kopier: A-paret og B-paret er
+bevisste spec-ikke-kode-søsken; C1/C2 uavhengige med annet formål. C2 konsolideres IKKE
+(motsatt sikkerhetsfilosofi by design). To eksisterende konvergens-beslutninger («del spec,
+ikke kode»: marketplace-brief 2026-06-26 + D7) **reverseres bevisst av D-G for den tolerante
+kjernen** — operatør-godkjent 2026-07-14. Gjenbruksmal: `llm-ingestion-guard` (pip-pakke,
+stdlib-only kjerne, valgfrie adaptere). Terminologi: **Google Open Knowledge Format v0.1**.
+
+---
+
+## 1. D-F — Kunnskapsinnholdsmodell (BESLUTTET)
+
+**Operatør-fasit:**
+1. Ny innholdsmodell i delt spec (commons): kunnskapstyper for **tiltaksmønstre,
+   erfaringsnotater, faglige råd** — alt med påkrevd kildebelegg. Målet: alt fageksperter
+   har av eksplisitt kunnskap + mest mulig taus kunnskap, erfaringer, råd — «så mye kontekst
+   som mulig som KAN være relevant», systematisert så det forblir håndterlig.
+2. **Kun lesestoff** for AI-forslagsstilleren. Kalkulatorens (validatorens) regler røres
+   ikke — evt. bibliotek→validator-kobling er en egen framtidig beslutning.
+3. **Streng separasjon fra dommene** (ufravikelig): bibliotek flyter via `bundle_context`;
+   organisasjonens korreksjoner KUN via den gatede ExpeL-folden. Blandes aldri.
+4. Delt **dimensjonsbibliotek materialiseres inn** i hver prosjekt-bundle via ingest-mønsteret
+   (`generated: true`, manifest-ref, re-materialisering eier egne filer) — IKKE
+   kryssbundle-lenker (navigasjonen forblir flat/same-dir), IKKE manuell duplisering.
+5. **Dimensjonskatalog som konfig** (skjema-validert fail-fast: id, label,
+   allowed_measure_types, allowed_code_prefixes). Rammeverket shipper eksempel-katalog;
+   deployer eier sin. Biblioteksfiler tagges med eksisterende `dimension:`-frontmatter.
+6. **Trinnvis lesing (nytt krav):** sammendrag-først (én linje per kunnskapsfil),
+   fulltekst hentes ved behov — så basen kan bli stor uten prompt-drukning. Dagens
+   «render alt navigert» skalerer ikke til ambisjonen.
+7. **Shipped eksempel: energi-dimensjonen i tilnærmet realistisk skala** — flere
+   bygg/prosjekter, 15–30 tiltak i biblioteket, **med rådataene** (målinger,
+   kostnadslinjer, notater som filer/DB-fixtures) så HELE kjeden testes/demonstreres:
+   rådata → ingest → base → forslag → validering → dom → læring. AI forfatter innholdet
+   med kildeverifisering (søk-først + provenance; operatør er ikke domeneekspert).
+8. Taus kunnskap: biblioteket tar det nedskrivbare; genuint taus kunnskap fanges via
+   dommene (rationale-prosaen) — det er læringssløyfas eksisterende kanal.
+
+**Innplassering:** beslutning nå; bygging i Fase 3-bolken (etter S2.0/S2.1/S2.5),
+koordinert med S3.2 (multi-kandidat, F5). Spec-amendment i commons FØRST (D7-speiling
+flagges). Amendment-utkastet skrives i utrullings-økta (§5).
+
+## 2. D-G — OKF: felles modul, fabrikk, evaluator (BESLUTTET)
+
+**Operatør-fasit:**
+1. **Standard-kompatibel** («vi må være kompatibel med standarden») — F4/`/`-lenkeformen
+   må rettes (forsterker D-A pkt. 3). **Egne utvidelser oppå** (innboks-konseptet,
+   ingest-sikkerhet, evaluator-felt) dokumenteres eksplisitt SOM utvidelser — pensjoneres
+   hvis standarden senere løser dem.
+2. **Felles OKF-kode: JA.** Begge søsknene deler én modul (endrer D7s «from spec
+   alone»-avgrensning bevisst — formatlaget ligger under det som sammenlignes). Claude-repoet
+   skal være **minst like godt** som MAF-repoet (operatørens favoritt); delt modul gir det
+   skrive-halvdelen det mangler i dag (A2).
+3. **Eget nytt repo** (tredje signatur-repo, arbeidstittel `okf-toolkit` — operatør
+   navngir): delt modul (tolerant les/naviger/skriv-kjerne) + **formatprøve**
+   (conformance-testsett alle konsumenter kjører) + **bundle-evaluatoren** +
+   **bundle-fabrikken**. Guard-malen: installerbar pakke, avhengighetsfri kjerne,
+   Forgejo. Potensielt nyttig for alle som tar i bruk Google OKF. Guard forblir eget repo
+   (sikkerhetskomponent, brukes som avhengighet).
+4. **Bundle-fabrikken (viktigst nå, operatør):** bruker slipper filer/mapper i en
+   **bundle-innboks** → prosessen gjør ALT (strukturerer, oppsummerer, lenker, stempler,
+   sikkerhetsvasker — standarden + våre utvidelser) → ferdig base som evaluatoren scorer
+   høyt på alle dimensjoner. **Ærlighets-grense:** fabrikken bruker AI og lever UTENFOR
+   optimalisererens deterministiske kjøresti; alt merkes maskingenerert; evaluator +
+   ekspert er kontrollen.
+5. **Evaluatoren har to jobber:** (a) teknisk korrekthet (deterministisk: konformitet,
+   navigerbarhet, lenke-integritet, kildedekning, ferskhet, sikkerhet, sammendragsdisiplin);
+   (b) **tilstrekkelighet** («omfattende nok til å være nyttig? hva mangler?») —
+   AI-vurdert med åpne kriterier. (b) er fagekspertens arbeidsliste under oppbygging.
+6. **Rekkefølge:** modul + formatprøve først (liten jobb, fjerner 6-steders-duplikasjonen),
+   fabrikk + evaluator deretter — bygget mot energi-caset (D-F pkt. 7) som første kunde.
+
+## 3. D-H — Oppsett og brukervennlighet (BESLUTTET)
+
+**Operatør-fasit:**
+1. **Oppsett gjøres ALLTID av et lite team** av tekniske eksperter + fageksperter sammen
+   (spesielt MAF-siden er komplisert). Leveransen er en **oppskrift** (dokumentert
+   team-prosess), IKKE en veiviser. Ærlig forventning i README: en god kunnskapsbase tar
+   **1–2 uker dedikert arbeid** — kvaliteten på investeringen avgjør resultatet.
+   (Onboarding-intervju/B9 og guidet dom-kommando: FORKASTET.)
+2. **Fagpersonens grensesnitt er kun:** hva de skal bidra med faglig, hvordan og hvor.
+   De leverer **filer i egne formater** — aldri skjema/JSON. Evaluatorens
+   tilstrekkelighets-feedback styrer bidragene.
+3. **Dommer:** eksperten leverer fri-format-fil → **fabrikken** AI-oversetter til det
+   strenge domsformatet (store volum gjør manuell oversettelse urealistisk). Godkjenning i
+   praksis = **stikkprøver** i generert bundle. Vaktpost: den strukturerte dommen peker
+   ALLTID på ekspertens originalfil (provenance), så stikkprøven kan sammenligne «hva
+   eksperten skrev» mot «hva systemet forsto». Dommen er menneskets; AI er oversetter.
+4. **Demo-stien:** fersk klon → unzip energi-eksemplet i bundle-innboksen → fabrikken
+   bygger → hele sløyfa kjører. Demoen er ærlig fordi den viser den reelle prosessen med
+   ferdig innhold.
+5. **Lese-løsning:** Obsidian/VS Code holder først (bundles er ren markdown). Dedikert
+   lese-visning = senere byggekloss i toolkit-repoet.
+
+## 4. D-I — Verdibevis + kostnadsstyring (BESLUTTET)
+
+**Operatør-fasit:**
+1. **Nivå 2 som publiserings-påstand:** «på et realistisk case finner og kvalitetssikrer
+   systemet reelle besparelses-kandidater» (modellerte tall, ærlig formulert — aldri
+   salgsspråk over beleggsnivået). **Nivå 3** (ekte referanse/pilot) er uttalt håp —
+   målgruppen er LinkedIn-nettverket som skal VILLE teste det (generelt problem, åpen
+   invitasjon). Pilot står åpen; alt bygges klart for den som kommer først (operatør kan
+   ikke starte internt; krever CFO-signert budsjett).
+2. **Verdirapport per kjøring = kjerne** (løftet fra review-forslag 1): hovedbok-basert —
+   modellert → ekspert-korrigert → realisert per prosjekt/dimensjon, målprogresjon,
+   **læringseffekt tallfestet** (godkjenningsandel per kjøring; krymper
+   modellert-vs-forventet-gapet?), og **kost-mot-verdi** («kjøringen kostet X,
+   identifiserte kvalitetssikret modellert besparelse Y»).
+3. **Kostnadssimulering FØR kjøring (MÅ-krav, operatør):** what-if over modell-mappet —
+   estimert kost for en gitt portefølje-kjøring under ulike **modeller og effortnivåer**,
+   med dokumenterte kvalitets-avveininger per modellvalg. Ærlighetsregler: prisdata som
+   konfig (aldri hardkodet; verifiseres mot leverandørpriser med kilde+dato);
+   kvalitetsutsagn merkes som veiledning med kilde, aldri som målt fakta uten belegg.
+   Adopsjonssti dokumenteres: start liten (én dimensjon, ett prosjekt, lavt tak) → eskaler
+   med tilliten. Kobler til S3.4/S3.5 (kost på tvers) og M1/M2.
+
+## 5. Innplassering i planverket (apply-liste for utrullings-økta — INTET utført ennå)
+
+1. **Sesjonsplanen** (`2026-07-10-sesjonsplan-fase2-6.md`): nye §2-oppføringer D-F–D-I med
+   status BESLUTTET (fasit her); nye sesjoner skisseres: S3.5+ *bibliotek/innholdsmodell*
+   (etter commons-amendment; koordinert S3.2), S3.x *kostnadssimulering* (S3.4-familien),
+   S5.x *verdirapport* (etter S2.1-outbox + ledger), S5.3 utvides med oppskrift-dok;
+   avhengighetsgraf + sekvens oppdateres. **S2.0/S2.1/S2.5 forblir uendret byggbare.**
+2. **Roadmapen** (`2026-07-06-reell-kjoring-analyse-plan.md`): revisjonsblokk 2026-07-14
+   (D-F–D-I + F-INT-funnene).
+3. **Commons** (egen økt, PULL-ONLY): amendment-utkast for innholdsmodellen (D-F pkt. 1–6)
+   + utvidelses-policy (D-G pkt. 1) — operatør godkjenner utkastet FØR commons-commit;
+   D7-søsken-speiling flagges.
+4. **Toolkit-repo:** egen brief + repo-init (utenfor dette repoets sesjonskø; blokkerer
+   fabrikk-avhengige deler av D-F/D-H).
+5. **README:** oppdateres først når nivå-2-beviset finnes (D-I pkt. 1 — ingen påstander før
+   belegg).
+6. Frosne dokumenter røres KUN via pkt. 3-regimet. D-A/D-B-køen står uendret (D-A pkt. 3
+   får forsterket begrunnelse fra D-G).
+
+## 6. Verifisering (pakkas egne kriterier)
+
+- Hver D-beslutning over har: operatør-fasit + belegg/kobling til eksisterende funn-ID-er. ✅
+- Utrullings-økta er ferdig når: sesjonsplanen viser D-F–D-I + nye sesjoner med
+  TDD/detach-punkt per husregel; roadmapen har revisjonsblokk; commons-amendment-utkast
+  foreligger til operatør-godkjenning; toolkit-brief foreligger. Testbart: `grep -n "D-F"
+  docs/plan/2026-07-10-sesjonsplan-fase2-6.md` treffer; full suite fortsatt grønn (ingen
+  kodeendring i denne pakka).
+- Nøkkelantakelse å teste i utrullings-økta: trinnvis-lesing-kravet (D-F pkt. 6) kan
+  spesifiseres uten å bryte method-spec §3 Steg 1s render-kontrakt — hvis ikke, er det
+  del av commons-amendmenten (flagges eksplisitt).