docs(plan): utrulling D-F–D-I — sesjonsplan (D-F–D-I i §2, S3.5/S3.6/S5.4, graf+T0), roadmap-revisjonsblokk, commons-amendment-utkast (Step-1-analyse: NEI → minimal amendment), toolkit-repo-brief
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0145ZKPLMVeqM47z2jxxokym
This commit is contained in:
parent
f133bd4a65
commit
12e7f6aabc
5 changed files with 889 additions and 7 deletions
|
|
@ -7,6 +7,10 @@
|
||||||
> (S2.0–S5.3 + beslutnings-kø D-A–D-E + operatør-milepæler M1–M3). Denne fila forblir
|
> (S2.0–S5.3 + beslutnings-kø D-A–D-E + operatør-milepæler M1–M3). Denne fila forblir
|
||||||
> task-definisjonen/gap-analysen; sesjonsplanen er utførelses-nivået.
|
> task-definisjonen/gap-analysen; sesjonsplanen er utførelses-nivået.
|
||||||
>
|
>
|
||||||
|
> **Revisjon 2026-07-14:** en intensjonsanalyse (utover F1–F14) ga fem intensjonsfunn F-INT-1–5 +
|
||||||
|
> fire operatør-beslutninger D-F–D-I, protokollert i
|
||||||
|
> [revisjonspakka](2026-07-14-revisjonspakke-DF-DI.md), innplassert i planverket 2026-07-15 (se §5).
|
||||||
|
>
|
||||||
> **Kilde:** operatør-scenario 2026-07-06 + [gap-analyse](#) forankret i målbilde §2–§4,
|
> **Kilde:** operatør-scenario 2026-07-06 + [gap-analyse](#) forankret i målbilde §2–§4,
|
||||||
> ingest-målbilde §11/§12, research §15. Ingen modell-kostnad påløpt.
|
> ingest-målbilde §11/§12, research §15. Ingen modell-kostnad påløpt.
|
||||||
|
|
||||||
|
|
@ -115,6 +119,32 @@ større arbeidsbolk, aldri one-shot.
|
||||||
> F7/F11), **S2.7** (validator-stramming, F2), **S4.0** (kostbaseline-forankring, F3); Fase 4/6
|
> F7/F11), **S2.7** (validator-stramming, F2), **S4.0** (kostbaseline-forankring, F3); Fase 4/6
|
||||||
> splittet i offline-sesjoner (S4.0–S4.2) + operatør-milepæler **M1–M3**.
|
> splittet i offline-sesjoner (S4.0–S4.2) + operatør-milepæler **M1–M3**.
|
||||||
|
|
||||||
|
> **Revisjon 2026-07-14 (intensjonsanalyse → planverk-oppgradering):** En intensjonsnivå-analyse
|
||||||
|
> (utover F1–F14) fant fem intensjonsfunn **F-INT-1–5** — kunnskapsinnholdet underspesifisert
|
||||||
|
> (kaldstart), OKF-duplikasjon på 6 kodesteder + spec-avvik, manglende «ferdig»-definisjon,
|
||||||
|
> «betydelig verdi» ikke operasjonalisert, kjøringskost = CFO-beslutning — og fire
|
||||||
|
> operatør-beslutninger **D-F–D-I**, protokollert i
|
||||||
|
> [revisjonspakka](2026-07-14-revisjonspakke-DF-DI.md):
|
||||||
|
>
|
||||||
|
> - **D-F — Kunnskapsinnholdsmodell:** delt, kildebelagt dimensjonsbibliotek (tiltaksmønstre/
|
||||||
|
> erfaringer/råd) som KUN lesestoff for forslagsstilleren, materialisert inn i hver bundle via
|
||||||
|
> ingest, trinnvis lesing (sammendrag-først); shipped energi-eksempel i realistisk skala med rådata.
|
||||||
|
> - **D-G — OKF felles modul + fabrikk + evaluator i eget repo (`okf-toolkit`):**
|
||||||
|
> standard-kompatibel; bundle-innboks → AI-fabrikk bygger base → evaluator scorer teknisk
|
||||||
|
> korrekthet + tilstrekkelighet.
|
||||||
|
> - **D-H — Oppsett + brukervennlighet:** en **oppskrift** (dokumentert team-prosess), ikke
|
||||||
|
> veiviser; fagpersonen leverer filer i egne formater, fabrikken AI-oversetter dommer til strengt
|
||||||
|
> format (stikkprøve-godkjenning).
|
||||||
|
> - **D-I — Verdibevis + kostnadsstyring:** nivå-2-påstand (modellerte tall); **verdirapport per
|
||||||
|
> kjøring** (hovedbok-basert, læringseffekt tallfestet) + **kostnadssimulering FØR kjøring**
|
||||||
|
> (what-if over modell-map, MÅ-krav).
|
||||||
|
>
|
||||||
|
> Innplassert 2026-07-15 (revisjonspakka §5): nye sesjoner **S3.5**
|
||||||
|
> (bibliotek/innholdsmodell, D-F), **S3.6** (kostnadssimulering, D-I) og **S5.4** (verdirapport,
|
||||||
|
> D-I) + eget **toolkit-repo** (D-G) i [sesjonsplanen](2026-07-10-sesjonsplan-fase2-6.md); D-H
|
||||||
|
> utvider S5.3 (oppskrift-dok); commons-amendment (D-F/D-G) via PULL-ONLY. **S2.0/S2.1/S2.5 forblir
|
||||||
|
> uendret byggbare.**
|
||||||
|
|
||||||
- **Fase 0 — Dyp planlegging + research.** Voyage trekbrief/trekplan per etterfølgende fase; ekstern
|
- **Fase 0 — Dyp planlegging + research.** Voyage trekbrief/trekplan per etterfølgende fase; ekstern
|
||||||
research på vektor-stores, MCP-connector-mønstre, Foundry-deployment. Avklar §4-beslutningene.
|
research på vektor-stores, MCP-connector-mønstre, Foundry-deployment. Avklar §4-beslutningene.
|
||||||
*Output:* per-fase-briefer. *Kostnad:* ingen (planlegging).
|
*Output:* per-fase-briefer. *Kostnad:* ingen (planlegging).
|
||||||
|
|
|
||||||
|
|
@ -3,6 +3,10 @@
|
||||||
> **Status:** GJELDENDE sesjonsplan. Forfattet som re-plan-forslag av kryssmodell-reviewen
|
> **Status:** GJELDENDE sesjonsplan. Forfattet som re-plan-forslag av kryssmodell-reviewen
|
||||||
> 2026-07-09 (Fable 5); **promotert til gjeldende plan 2026-07-10 på operatør-instruks.**
|
> 2026-07-09 (Fable 5); **promotert til gjeldende plan 2026-07-10 på operatør-instruks.**
|
||||||
> Roadmapen (`2026-07-06-reell-kjoring-analyse-plan.md`) er revidert med kryssreferanser hit.
|
> Roadmapen (`2026-07-06-reell-kjoring-analyse-plan.md`) er revidert med kryssreferanser hit.
|
||||||
|
> **Revidert 2026-07-14:** beslutningene D-F–D-I (kunnskapsinnholdsmodell, OKF-modul/fabrikk/evaluator,
|
||||||
|
> oppsett/brukervennlighet, verdibevis/kostnadsstyring) ble truffet i operatør-samtale og er flettet inn
|
||||||
|
> her (§2-oppføringer + nye sesjoner S3.5/S3.6/S5.4 + S5.3-utvidelse); fasit i
|
||||||
|
> [revisjonspakke D-F–D-I](../2026-07-14-revisjonspakke-DF-DI.md).
|
||||||
> Funn-referanser (F1–F14, P1–P6, U-1–U-4) peker til [reviewen](../review-2026-07.md).
|
> Funn-referanser (F1–F14, P1–P6, U-1–U-4) peker til [reviewen](../review-2026-07.md).
|
||||||
> **Beslutnings-sesjonene D-A–D-E er fortsatt ÅPNE (operatør-kø):** bygg-sesjoner gated på dem
|
> **Beslutnings-sesjonene D-A–D-E er fortsatt ÅPNE (operatør-kø):** bygg-sesjoner gated på dem
|
||||||
> starter ikke før beslutning foreligger; **S2.0/S2.1/S2.5 er byggbare NÅ** (ingen
|
> starter ikke før beslutning foreligger; **S2.0/S2.1/S2.5 er byggbare NÅ** (ingen
|
||||||
|
|
@ -85,6 +89,59 @@ UTENFOR dette repoets sesjoner; flagges i hver berørt sesjon.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
**D-F–D-I — BESLUTTET 2026-07-14** (operatør-samtale, intensjonsanalyse). Til forskjell fra D-A–D-E
|
||||||
|
over er disse fire allerede avgjort; fasit-protokoll + innplassering i
|
||||||
|
[revisjonspakke D-F–D-I](../2026-07-14-revisjonspakke-DF-DI.md). Frosne dokumenter er IKKE endret ennå
|
||||||
|
— amendments skjer via commons (PULL-ONLY) i egne økter. Oppføringene under oppsummerer beslutningen +
|
||||||
|
hva den blokkerer/åpner (ikke hele fasiten).
|
||||||
|
|
||||||
|
### D-F — Kunnskapsinnholdsmodell `[BESLUTTET 2026-07-14]`
|
||||||
|
- **Status:** BESLUTTET 2026-07-14. Fasit: [revisjonspakke §1](../2026-07-14-revisjonspakke-DF-DI.md).
|
||||||
|
- **Kjerne:** ny delt innholdsmodell i commons (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 materialiseres inn i hver bundle via ingest-mønsteret (`generated: true`,
|
||||||
|
flat navigasjon — ikke kryssbundle-lenker); dimensjonskatalog som skjema-validert konfig; trinnvis
|
||||||
|
lesing (sammendrag-først) er nytt krav.
|
||||||
|
- **Blokkerer/åpner:** gated på commons-amendment FØRST (PULL-ONLY; D7-speiling flagges) → åpner
|
||||||
|
**S3.5** (koordineres med S3.2). Realistisk energi-innhold (§1 pkt. 7) = egen senere innholds-
|
||||||
|
produksjonsjobb, ikke del av S3.5. Fabrikk-avhengige deler venter på toolkit-repoet (D-G).
|
||||||
|
|
||||||
|
### D-G — OKF: felles modul, fabrikk, evaluator `[BESLUTTET 2026-07-14]`
|
||||||
|
- **Status:** BESLUTTET 2026-07-14. Fasit: [revisjonspakke §2](../2026-07-14-revisjonspakke-DF-DI.md)
|
||||||
|
(+ kryssrepo-inventar §0.2).
|
||||||
|
- **Kjerne:** standard-kompatibel OKF (F4/`/`-lenkeformen rettes — forsterker **D-A pkt. 3**), egne
|
||||||
|
utvidelser dokumenteres eksplisitt som utvidelser. **Felles OKF-kode JA** (endrer D7s «from spec
|
||||||
|
alone» bevisst; gir Claude-repoet skrive-halvdelen A2 mangler i dag). Nytt tredje signatur-repo
|
||||||
|
(arbeidstittel `okf-toolkit`): delt les/naviger/skriv-kjerne + conformance-testsett + bundle-evaluator
|
||||||
|
+ bundle-fabrikk. Rekkefølge: modul + formatprøve først (fjerner 6-steders-duplikasjonen), fabrikk +
|
||||||
|
evaluator deretter mot energi-caset.
|
||||||
|
- **Blokkerer/åpner:** toolkit lever i EGET repo utenfor denne sesjonskøen → **ekstern avhengighet (T0)**
|
||||||
|
som blokkerer fabrikk-avhengige deler av D-F/D-H. Guard forblir eget sikkerhets-repo (avhengighet).
|
||||||
|
|
||||||
|
### D-H — Oppsett og brukervennlighet `[BESLUTTET 2026-07-14]`
|
||||||
|
- **Status:** BESLUTTET 2026-07-14. Fasit: [revisjonspakke §3](../2026-07-14-revisjonspakke-DF-DI.md).
|
||||||
|
- **Kjerne:** oppsett gjøres ALLTID av et lite team (teknisk + fag); leveransen er en **oppskrift**
|
||||||
|
(dokumentert prosess), ikke en veiviser (B9-onboarding + guidet dom-kommando FORKASTET). Fagpersonen
|
||||||
|
leverer filer i egne formater — aldri skjema/JSON; **fabrikken** (D-G) AI-oversetter fri-format-dommer
|
||||||
|
til strengt format, godkjenning i praksis = stikkprøver med provenance-peker til ekspertens originalfil.
|
||||||
|
Demo-sti: klon → unzip energi-eksempel i bundle-innboks → fabrikk bygger → hele sløyfa kjører.
|
||||||
|
Obsidian/VS Code som lese-løsning først.
|
||||||
|
- **Blokkerer/åpner:** oppskrift-dokumentet (§3 pkt. 1) legges til **S5.3** som dokumentleveranse;
|
||||||
|
dom-oversettelse + demo-sti er fabrikk-avhengige (D-G/T0), blokkert til toolkit finnes.
|
||||||
|
|
||||||
|
### D-I — Verdibevis + kostnadsstyring `[BESLUTTET 2026-07-14]`
|
||||||
|
- **Status:** BESLUTTET 2026-07-14. Fasit: [revisjonspakke §4](../2026-07-14-revisjonspakke-DF-DI.md).
|
||||||
|
- **Kjerne:** publiserings-påstand = **nivå 2** (realistisk case, modellerte tall, aldri salgsspråk over
|
||||||
|
beleggsnivået); nivå 3 (ekte pilot) er åpen invitasjon. **Verdirapport per kjøring** (kjerne):
|
||||||
|
hovedbok-basert modellert→korrigert→realisert, målprogresjon, tallfestet læringseffekt, kost-mot-verdi.
|
||||||
|
**Kostnadssimulering FØR kjøring** (MÅ-krav): what-if over modell-mappet (modeller × effortnivåer),
|
||||||
|
prisdata som skjema-validert konfig (aldri hardkodet), kvalitetsutsagn merket som veiledning med kilde.
|
||||||
|
- **Blokkerer/åpner:** åpner **S5.4** (verdirapport, etter S2.1-outbox + ledger) og **S3.6**
|
||||||
|
(kostnadssimulering, fri/offline). README oppdateres FØRST når nivå-2-beviset finnes (pkt. 1).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## 3. Opus-sesjons-specs (offline, autonome)
|
## 3. Opus-sesjons-specs (offline, autonome)
|
||||||
|
|
||||||
> Felles for alle: Iron Law (failing test først); `uv run pytest` / `uv run ruff check .` /
|
> Felles for alle: Iron Law (failing test først); `uv run pytest` / `uv run ruff check .` /
|
||||||
|
|
@ -283,6 +340,68 @@ UTENFOR dette repoets sesjoner; flagges i hver berørt sesjon.
|
||||||
(klient-mock som teller kall — kallet skal ALDRI skje).
|
(klient-mock som teller kall — kallet skal ALDRI skje).
|
||||||
- **Verifisering:** nye tester grønne + detach → rød; full gate grønn.
|
- **Verifisering:** nye tester grønne + detach → rød; full gate grønn.
|
||||||
|
|
||||||
|
### S3.5 `[NY]` Innholdsmodell + fagbibliotek-materialisering (D-F; gated: commons-amendment)
|
||||||
|
- **Mål:** delt kunnskapsinnholdsmodell (tiltaksmønstre/erfaringsnotater/faglige råd med kildebelegg)
|
||||||
|
materialiseres inn i prosjekt-bundles som rent lesestoff for forslagsstilleren — uten å røre
|
||||||
|
validatoren og uten å blande seg med dommene.
|
||||||
|
- **Scope (revisjonspakke §1 pkt. 1–6):** (1) nye kunnskapstyper i delt spec (commons-amendment FØRST —
|
||||||
|
PULL-ONLY, D7-speiling flagges); (2) dimensjonskatalog som skjema-validert konfig (id, label,
|
||||||
|
allowed_measure_types, allowed_code_prefixes) + fail-fast loader — rammeverket shipper eksempel-katalog,
|
||||||
|
deployer eier sin; (3) bibliotek-materialisering via ny ingest-kildefamilie (`generated: true`,
|
||||||
|
manifest-ref, re-materialisering eier egne filer — flat/same-dir navigasjon, IKKE kryssbundle-lenker,
|
||||||
|
IKKE manuell duplisering); (4) trinnvis lesing i `bundle_context`: sammendrag-først (én linje per
|
||||||
|
kunnskapsfil), fulltekst hentes ved behov. Streng separasjon håndheves: bibliotek via `bundle_context`,
|
||||||
|
organisasjonens korreksjoner KUN via ExpeL-folden. **IKKE i scope:** energi-innholdet i realistisk skala
|
||||||
|
(§1 pkt. 7 = egen senere innholds-produksjonsjobb, avhengig leveranse); validator↔bibliotek-kobling
|
||||||
|
(framtidig beslutning); toolkit-fabrikken (D-G, eget repo).
|
||||||
|
- **Avhengigheter:** commons-amendment for innholdsmodellen (D-F-utkast operatør-godkjent + `git subtree
|
||||||
|
pull`) FØRST; koordineres med **S3.2** (multi-kandidat — deler seed/frontmatter-stien). Etter
|
||||||
|
S2.0/S2.1/S2.5.
|
||||||
|
- **Filer:** `okf.py` (trinnvis lesing / sammendrag-seam — MAF-fri, håndhevet av `test_okf_is_maf_free`),
|
||||||
|
ny `dimension_catalog.py` (loader, fail-fast), `ingest.py` (bibliotek-kildefamilie), commons-spec +
|
||||||
|
eksempel-katalog (i commons — flagg), repo-lokal bibliotek-fixture under `data/`, nye tester.
|
||||||
|
- **TDD:** (1) RØD: dimensjonskatalog med ugyldig felt (ukjent `allowed_measure_type`-referanse) →
|
||||||
|
fail-fast ved lasting — detach-punkt: fjern skjema-valideringen → passerer → rød; (2) RØD: materialisert
|
||||||
|
bibliotek-fil når forslags-prompten via `bundle_context` (markør fraværende fra bundelen ellers) —
|
||||||
|
detach materialiseringen → markøren forsvinner → rød; (3) RØD: trinnvis lesing gir sammendraget i
|
||||||
|
navigert kontekst men IKKE fulltekst før eksplisitt henting — detach sammendrag-seamen → hele
|
||||||
|
fullteksten stuffes inn → rød; (4) RØD: en bibliotek-fil MÅ ALDRI nå hypotese-prompten via dom-kanalen
|
||||||
|
(separasjons-kontroll — biblioteket lekker aldri inn i ExpeL-folden).
|
||||||
|
- **Nøkkelantakelser:** trinnvis-lesing-kravet (D-F pkt. 6) kan realiseres uten å bryte method-spec §3
|
||||||
|
Steg 1s render-kontrakt — HVIS ikke, er sammendrag-seamen del av commons-amendmenten (flagges
|
||||||
|
eksplisitt, jf. revisjonspakke §6-nøkkelantakelsen). Bibliotek-fixture ligger repo-lokalt under `data/`
|
||||||
|
(aldri i `shared/`) til energi-innholdet materialiseres.
|
||||||
|
- **Verifisering:** nye tester grønne + hvert detach-punkt → rød; `test_okf_is_maf_free` utvidet grønn;
|
||||||
|
full suite + ruff + mypy grønne. **Flagg:** commons-amendment + D7-speiling (egen sesjon i søsken-repoet).
|
||||||
|
|
||||||
|
### S3.6 `[NY]` Kostnadssimulering før kjøring (D-I pkt. 3; offline, ikke gated)
|
||||||
|
- **Mål:** operatøren ser estimert kost for en portefølje-kjøring FØR den startes — what-if over
|
||||||
|
modell-mappet (modeller × effortnivåer) — så kjøringskost blir en informert beslutning, ikke en
|
||||||
|
overraskelse etterpå.
|
||||||
|
- **Scope (revisjonspakke §4 pkt. 3):** `python -m portfolio_optimiser.costsim` (+ funksjons-API):
|
||||||
|
estimér tokens/kost for en gitt portefølje under valgt modell + effortnivå; **prisdata som skjema-
|
||||||
|
validert konfig** (kr/1k tokens per modell, med kilde- + dato-felt — ALDRI hardkodet; fail-fast ved
|
||||||
|
manglende/ugyldig pris); kvalitets-avveininger per modellvalg merket som **veiledning med kilde**, aldri
|
||||||
|
målt fakta uten belegg; output = estimat-tabell (per rolle/modell/effort) + `kost-mot-verdi`-felt klart
|
||||||
|
for verdirapporten (S5.4). Deler tak-begreper med budsjettmaskineriet (`PortfolioBudget` /
|
||||||
|
`BudgetMiddleware` fra S3.4), men estimerer FØR kall. Adopsjonssti dokumenteres (start liten → eskaler
|
||||||
|
med tilliten). IKKE: live prisoppslag (nettverk), faktisk modellkall (rent offline), kvalitets-benchmarking.
|
||||||
|
- **Avhengigheter:** ingen commons-avhengighet (offline, stack-lokalt); drar nytte av **S3.4**
|
||||||
|
(budsjett-typer) og mater **S5.4** (verdirapport). Kan bygges før S3.5.
|
||||||
|
- **Filer:** ny `costsim.py` (ren stdlib + pydantic — MAF-fri, legg i `_MAF_FREE_MODULES`),
|
||||||
|
`data/pricing.example.json` (skjema + eksempelpriser med kilde/dato), `budget.py` (deling av
|
||||||
|
tak-begreper), nye tester.
|
||||||
|
- **TDD:** (1) RØD: konfig uten pris for en modell i mappet → fail-fast «missing price for <modell>» —
|
||||||
|
detach-punkt: fjern pris-valideringen → estimatet gjettes → rød; (2) RØD: estimatet er deterministisk og
|
||||||
|
skalerer med modell × effort (to modeller, samme portefølje → forskjellig, reproduserbart estimat) —
|
||||||
|
detach effort-faktoren → identisk estimat → rød; (3) RØD: hardkodet pris i kildekode fanges av
|
||||||
|
grep-guard (pris MÅ komme fra konfig).
|
||||||
|
- **Nøkkelantakelser:** token-estimatet kan bygges fra portefølje-formen (antall prosjekter × runder ×
|
||||||
|
tak) uten et modellkall — deterministisk øvre-grense-estimat, ikke prediksjon; merkes eksplisitt som
|
||||||
|
estimat i output.
|
||||||
|
- **Verifisering:** nye tester grønne + detach → rød; `uv run python -m portfolio_optimiser.costsim` gir
|
||||||
|
estimat-tabell uten nettverk (grep-guard: ingen socket-sti i modulen); full gate grønn.
|
||||||
|
|
||||||
### S4.0 `[NY]` Validator-forankring mot kostbaseline (F3, F8; gated: D-A pkt. 2)
|
### S4.0 `[NY]` Validator-forankring mot kostbaseline (F3, F8; gated: D-A pkt. 2)
|
||||||
- **Mål:** `affected_items` avstemmes fail-closed mot prosjektets faktiske kostbaseline — den
|
- **Mål:** `affected_items` avstemmes fail-closed mot prosjektets faktiske kostbaseline — den
|
||||||
deterministiske gaten kan ikke lenger mates med hallusinerte kostlinjer.
|
deterministiske gaten kan ikke lenger mates med hallusinerte kostlinjer.
|
||||||
|
|
@ -359,12 +478,43 @@ UTENFOR dette repoets sesjoner; flagges i hver berørt sesjon.
|
||||||
- **Scope:** `main()` (+ evt. `portfolio`-subkommando): `--dimension-config`, `--ledger`,
|
- **Scope:** `main()` (+ evt. `portfolio`-subkommando): `--dimension-config`, `--ledger`,
|
||||||
`--goals`, `--bundle-dir`, `--verdict-dir`, `--outbox-dir`; README/extending.md/CHANGELOG-sync;
|
`--goals`, `--bundle-dir`, `--verdict-dir`, `--outbox-dir`; README/extending.md/CHANGELOG-sync;
|
||||||
ærlighets-grep (ingen «learning loop»-claims på stier uten fold).
|
ærlighets-grep (ingen «learning loop»-claims på stier uten fold).
|
||||||
|
- **Scope (D-H pkt. 1, tillegg):** oppsett-**oppskrift** som dokumentleveranse — dokumentert team-prosess
|
||||||
|
(teknisk + fag) for å bygge en kunnskapsbase, med ærlig README-forventning (en god base tar 1–2 uker
|
||||||
|
dedikert arbeid; kvaliteten på investeringen avgjør resultatet); IKKE en veiviser / B9-onboarding-
|
||||||
|
intervju (FORKASTET).
|
||||||
- **Avhengigheter:** S2.0, S2.1 (og drar nytte av alt over).
|
- **Avhengigheter:** S2.0, S2.1 (og drar nytte av alt over).
|
||||||
- **Filer:** `run.py`, `README.md`, `docs/extending.md`, `CHANGELOG.md`, CLI-tester.
|
- **Filer:** `run.py`, `README.md`, `docs/extending.md`, `CHANGELOG.md`, CLI-tester.
|
||||||
- **TDD:** RØD: CLI-kjøring med goals+ledger på fixtures → GoalReached-stopp observerbar i output.
|
- **TDD:** RØD: CLI-kjøring med goals+ledger på fixtures → GoalReached-stopp observerbar i output.
|
||||||
- **Verifisering:** CLI-tester grønne; full gate grønn; manuell `uv run python -m
|
- **Verifisering:** CLI-tester grønne; full gate grønn; manuell `uv run python -m
|
||||||
portfolio_optimiser.run …`-røyk på fixtures dokumentert i STATE.
|
portfolio_optimiser.run …`-røyk på fixtures dokumentert i STATE.
|
||||||
|
|
||||||
|
### S5.4 `[NY]` Verdirapport per kjøring (D-I pkt. 2)
|
||||||
|
- **Mål:** hver kjøring (og porteføljepass) produserer en deterministisk verdirapport —
|
||||||
|
modellert → ekspert-korrigert → realisert per prosjekt/dimensjon, målprogresjon, tallfestet
|
||||||
|
læringseffekt og kost-mot-verdi — som artefakt, uten et eneste modellkall.
|
||||||
|
- **Scope (revisjonspakke §4 pkt. 2):** hovedbok-basert rapportgenerator over ledgeren + outbox (S2.1):
|
||||||
|
(a) besparelses-kolonner modellert/korrigert/realisert per prosjekt + dimensjon; (b) målprogresjon mot
|
||||||
|
GoalContract; (c) **læringseffekt tallfestet** — godkjenningsandel per kjøring + om modellert-vs-
|
||||||
|
forventet-gapet krymper over kjøringer; (d) **kost-mot-verdi** («kjøringen kostet X, identifiserte
|
||||||
|
kvalitetssikret modellert besparelse Y» — X fra S3.6-estimat / faktisk token-forbruk). Rapport =
|
||||||
|
deterministisk artefakt (JSON + markdown-render; sort_keys / indent / LF / byte-stabil). Ærlighet:
|
||||||
|
realiserte tall KUN der dom finnes; modellerte merkes som modellert (aldri salgsspråk over
|
||||||
|
beleggsnivået, D-I pkt. 1). IKKE: web-dashboard, live-oppdatering, modellkall.
|
||||||
|
- **Avhengigheter:** **S2.1** (outbox — forslag/utfall-artefakter) + ledger (S2.0-læringssløyfe);
|
||||||
|
konsumerer **S3.6**-kostestimat for kost-mot-verdi-feltet.
|
||||||
|
- **Filer:** ny `valuereport.py` (ren stdlib + pydantic — MAF-fri, `_MAF_FREE_MODULES`), `run.py`
|
||||||
|
(opt-in `--value-report`), nye tester.
|
||||||
|
- **TDD:** (1) RØD: to kjøringer med økende godkjenningsandel → læringseffekt-metrikken stiger og
|
||||||
|
gap-krympingen rapporteres — detach-punkt: fjern gap-beregningen → flat/feil → rød; (2) RØD: prosjekt
|
||||||
|
uten dom → «realisert» er tomt/umerket, ALDRI lik modellert — detach ærlighets-grensen →
|
||||||
|
realisert = modellert → rød; (3) RØD: byte-determinisme (samme ledger + outbox → identisk rapport,
|
||||||
|
`diff`).
|
||||||
|
- **Nøkkelantakelser:** ledgeren + outbox bærer allerede alt rapporten trenger (modellert fra proposal,
|
||||||
|
korrigert/realisert fra dommene, kost fra token-forbruk / S3.6) — rapporten er ren projeksjon, ingen ny
|
||||||
|
tilstand (test: bygg rapport fra committede fixtures uten kjøring).
|
||||||
|
- **Verifisering:** nye tester grønne + detach → rød; `run.py --value-report` på fixtures gir byte-stabil
|
||||||
|
rapport uten nettverk; full gate grønn.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4. Operatør-gatede milepæler (IKKE autonome Opus-sesjoner)
|
## 4. Operatør-gatede milepæler (IKKE autonome Opus-sesjoner)
|
||||||
|
|
@ -406,6 +556,8 @@ flowchart TB
|
||||||
S31["S3.1 semantisk henting"]; S32["S3.2 multi-kandidat (F5)"]; S33["S3.3 concurrent (F6)"]; S34["S3.4 kost på tvers (F10)"]
|
S31["S3.1 semantisk henting"]; S32["S3.2 multi-kandidat (F5)"]; S33["S3.3 concurrent (F6)"]; S34["S3.4 kost på tvers (F10)"]
|
||||||
S40["S4.0 kostbaseline-forankring (F3)"]; S41["S4.1 preflight"]; S42["S4.2 live-drill"]
|
S40["S4.0 kostbaseline-forankring (F3)"]; S41["S4.1 preflight"]; S42["S4.2 live-drill"]
|
||||||
S51["S5.1 ruting/sporing"]; S52["S5.2 varsling"]; S53["S5.3 CLI-paritet"]
|
S51["S5.1 ruting/sporing"]; S52["S5.2 varsling"]; S53["S5.3 CLI-paritet"]
|
||||||
|
S35["S3.5 innholdsmodell/bibliotek (D-F)"]; S36["S3.6 kostnadssimulering (D-I)"]; S54["S5.4 verdirapport (D-I)"]
|
||||||
|
DFC["D-F commons-amendment (PULL-ONLY)"]; T0[["T0 toolkit-repo (eget repo — okf-toolkit)"]]
|
||||||
M1{{"M1 tenant+smoke"}}; M2{{"M2 første live-kjøring"}}; M3{{"M3 pilot"}}
|
M1{{"M1 tenant+smoke"}}; M2{{"M2 første live-kjøring"}}; M3{{"M3 pilot"}}
|
||||||
|
|
||||||
DA --> S27; DA --> S32; DA --> S40
|
DA --> S27; DA --> S32; DA --> S40
|
||||||
|
|
@ -415,6 +567,9 @@ flowchart TB
|
||||||
S41 --> M1; S40 --> M2; S42 --> M2; M1 --> M2
|
S41 --> M1; S40 --> M2; S42 --> M2; M1 --> M2
|
||||||
S51 --> S52; S20 --> S53; S21 --> S53
|
S51 --> S52; S20 --> S53; S21 --> S53
|
||||||
S33 --> M3; S34 --> M3; S52 --> M3; M2 --> M3; S31 --> M3; S32 --> M3
|
S33 --> M3; S34 --> M3; S52 --> M3; M2 --> M3; S31 --> M3; S32 --> M3
|
||||||
|
DFC --> S35; S32 -. koordineres .-> S35
|
||||||
|
S21 --> S54; S34 -. kost .-> S54; S36 -. kost-mot-verdi .-> S54
|
||||||
|
T0 -. fabrikk .-> M3
|
||||||
```
|
```
|
||||||
|
|
||||||
**Anbefalt sesjonssekvens** (parallellitet mulig der grafen tillater; én fase = Voyage-syklus):
|
**Anbefalt sesjonssekvens** (parallellitet mulig der grafen tillater; én fase = Voyage-syklus):
|
||||||
|
|
@ -422,10 +577,18 @@ flowchart TB
|
||||||
1. **D-A, D-B** (kan tas i samme operatør-bolk; D-C/D-D/D-E kan vente)
|
1. **D-A, D-B** (kan tas i samme operatør-bolk; D-C/D-D/D-E kan vente)
|
||||||
2. **S2.0 → S2.1 → S2.5** (ingen beslutnings-avhengighet — kan starte FØR/parallelt med D-runden)
|
2. **S2.0 → S2.1 → S2.5** (ingen beslutnings-avhengighet — kan starte FØR/parallelt med D-runden)
|
||||||
3. **S2.7** (etter D-A + commons-pull) · **S2.2 → S2.3 → S2.4** (etter D-B)
|
3. **S2.7** (etter D-A + commons-pull) · **S2.2 → S2.3 → S2.4** (etter D-B)
|
||||||
4. **D-C, D-D, D-E** → **S3.1 → S3.2 → S3.4 → S3.3**
|
4. **D-C, D-D, D-E** → **S3.1 → S3.2 → S3.4 → S3.3**; **S3.5** etter D-F commons-amendment +
|
||||||
|
koordinert med S3.2; **S3.6** fritt (offline, når som helst — mater S5.4)
|
||||||
5. **S4.1** (når som helst) → **M1** (operatør) · **S4.0 → S4.2** → **M2** (operatør)
|
5. **S4.1** (når som helst) → **M1** (operatør) · **S4.0 → S4.2** → **M2** (operatør)
|
||||||
6. **S5.1 → S5.2 → S5.3** → **M3** (operatør; krever også D-B-amendment + ekte ekspert)
|
6. **S5.1 → S5.2 → S5.3** · **S5.4** etter S2.1 + ledger → **M3** (operatør; krever også
|
||||||
|
D-B-amendment + ekte ekspert + toolkit-fabrikken T0)
|
||||||
|
|
||||||
**Offline-fullførings-grensen** går etter S5.3: alt over den linjen er gratis, autonomt og
|
**Ekstern avhengighet (T0 toolkit-repo, eget repo — `okf-toolkit`, D-G):** delt OKF-modul + conformance
|
||||||
load-bearing-testbart; M1–M3 er de eneste stegene som koster penger, krever tenant eller krever
|
+ bundle-evaluator + bundle-fabrikk lever i sitt eget signatur-repo, utenfor denne sesjonskøen.
|
||||||
et menneske.
|
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; S3.5/S3.6/S5.4 er valgt slik at de IKKE er fabrikk-gatede.
|
||||||
|
|
||||||
|
**Offline-fullførings-grensen** går etter S5.3/S5.4: alt over den linjen er gratis, autonomt og
|
||||||
|
load-bearing-testbart (også de nye S3.5/S3.6/S5.4). To ikke-autonome forbehold blant det nye: S3.5s
|
||||||
|
commons-amendment (operatør-godkjenning + PULL-ONLY) og T0 toolkit-repoet (eget repo). M1–M3 er fortsatt
|
||||||
|
de eneste stegene som koster penger, krever tenant eller krever et menneske.
|
||||||
|
|
|
||||||
488
docs/plan/2026-07-14-commons-amendment-utkast.md
Normal file
488
docs/plan/2026-07-14-commons-amendment-utkast.md
Normal file
|
|
@ -0,0 +1,488 @@
|
||||||
|
# Commons-amendment-utkast — kunnskapsinnholdsmodell + utvidelses-policy (2026-07-14)
|
||||||
|
|
||||||
|
> **Status:** UTKAST til operatør-godkjenning. Kilde: [revisjonspakke D-F–D-I](2026-07-14-revisjonspakke-DF-DI.md)
|
||||||
|
> §1 (D-F) + §2 (D-G). Dette dokumentet er en **komplett, innlimings-klar** amendment til de to
|
||||||
|
> delte spec-ene i `portfolio-optimiser-commons` (`method-spec.md` + `ingest-spec.md`). Ingenting er
|
||||||
|
> committet i commons, og `shared/` i dette repoet er **ikke** rørt — overføringen er manuell,
|
||||||
|
> PULL-ONLY, i egen økt ETTER at operatøren har godkjent teksten under.
|
||||||
|
>
|
||||||
|
> **Provenance:** amendment-tekst = AI-forfattet (Fable 5, 2026-07-14), forankret i faktisk lest
|
||||||
|
> spec + kode (`method-spec.md`, `ingest-spec.md`, `okf.py`, `dimension.py`,
|
||||||
|
> `test_method_spec_loadbearing.py`). Beslutningene bak (D-F/D-G) er operatørens, protokollert i
|
||||||
|
> revisjonspakka. Spec-teksten er engelsk (RFC-2119, framework-nøytral — samme regel som resten av
|
||||||
|
> de delte spec-ene, håndhevet av `test_method_spec_is_framework_neutral`). Rammetekst er norsk.
|
||||||
|
|
||||||
|
## 0. Slik brukes utkastet
|
||||||
|
|
||||||
|
Fire leveranser, i den rekkefølgen operatøren bør lese dem:
|
||||||
|
|
||||||
|
1. **§1 — Innholdsmodell-amendment til `method-spec.md`** (engelsk spec-tekst i innlimings-blokker):
|
||||||
|
tre nye konsepttyper, separasjonsregelen, dimensjonskatalog-kontrakten, cross-check-utvidelser.
|
||||||
|
2. **§2 — Bibliotek-materialisering som ny ingest-kildefamilie `library`** (eget under-utkast til
|
||||||
|
`ingest-spec.md`, med korrekt §-referanse).
|
||||||
|
3. **§3 — Trinnvis-lesing-analysen** (revisjonspakka §6 nøkkelantakelse): kan sammendrag-først
|
||||||
|
spesifiseres UTEN å endre `method-spec.md` §3 Step 1s render-kontrakt? **Eksplisitt JA/NEI +
|
||||||
|
begrunnelse forankret i siterte spec-linjer.**
|
||||||
|
4. **§4 — Utvidelses-policy** (D-G pkt. 1) og **§5 — Konsekvens-liste** (spec-integrity-test,
|
||||||
|
D7-speiling, golden-suite).
|
||||||
|
|
||||||
|
Hver engelsk innlimings-blokk er avgrenset med `--- BEGIN SPEC INSERT ---` / `--- END SPEC INSERT ---`
|
||||||
|
og merket med nøyaktig hvilken §-plassering den hører til, slik at overføringen til commons er
|
||||||
|
mekanisk. Tabeller er ekte markdown (ikke code-fenced) så de rendrer i commons uendret.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Innholdsmodell-amendment til `method-spec.md`
|
||||||
|
|
||||||
|
**Plassering:** ny toppseksjon `## 13. The knowledge library (content-model extension)` (bakerst, så
|
||||||
|
eksisterende §-numre ikke forskyves — `_REQUIRED_MARKERS` i integrity-testen er presence-asserts, se
|
||||||
|
§5), pluss tre målrettede inserts i eksisterende seksjoner (§2, §10, §12) og render-kontrakt-endringen
|
||||||
|
i §3 Step 1 (den siste hører til §3-analysen, se **§3** under).
|
||||||
|
|
||||||
|
### 1.1 Ny toppseksjon — de tre konsepttypene + separasjonsregelen
|
||||||
|
|
||||||
|
Rasjonale (norsk, ikke del av innlimingen): D-F pkt. 1 krever kunnskapstyper for *tiltaksmønstre,
|
||||||
|
erfaringsnotater, faglige råd*, alt med **påkrevd kildebelegg**. D-F pkt. 3 krever **streng separasjon
|
||||||
|
fra dommene**: biblioteket flyter via `bundle_context`, korreksjonene KUN via den gatede folden — aldri
|
||||||
|
blandet. Typene er kontekst-lag-innhold (`method-spec.md` §2: "This layer holds project documents,
|
||||||
|
methodology, verified literature, constraints..."), altså **kun lesestoff for forslagsstilleren** (D-F
|
||||||
|
pkt. 2 — validatorens regler røres ikke).
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → new `## 13.`) ---
|
||||||
|
|
||||||
|
## 13. The knowledge library (content-model extension)
|
||||||
|
|
||||||
|
The context layer (§2) MAY carry a **knowledge library**: curated, source-attested domain
|
||||||
|
knowledge about how savings are found within a dimension (§13.3), shared across the projects of a
|
||||||
|
portfolio and materialized into each project bundle (the ingest `library` source family — ingest
|
||||||
|
spec §4a). The library is **read-only input to the proposer**: it feeds hypothesis generation as
|
||||||
|
context, and it MUST NOT alter the deterministic validator's rules (§4), which remain the sole
|
||||||
|
authority over the numbers. Coupling the library to the validator is explicitly out of scope for
|
||||||
|
this version.
|
||||||
|
|
||||||
|
Three library concept types are defined. Each is an ordinary OKF concept file (§2, §3 Step 1) — the
|
||||||
|
only additions are required frontmatter fields:
|
||||||
|
|
||||||
|
- **`type: measure-pattern`** — a reusable cost-saving *pattern*: what the measure is, the
|
||||||
|
parameters that drive its modelled saving, and the realization caveats a proposer should know.
|
||||||
|
- **`type: experience-note`** — an operational *experience* (the writable part of tacit knowledge):
|
||||||
|
what happened when such a measure was carried out, and the gotchas. Genuinely tacit knowledge is
|
||||||
|
NOT forced here — it is captured by the verdicts' rationale prose (§4), the learning loop's
|
||||||
|
existing channel.
|
||||||
|
- **`type: expert-advice`** — an expert *heuristic or recommendation* scoped to a dimension.
|
||||||
|
|
||||||
|
**Required frontmatter (all three types):**
|
||||||
|
|
||||||
|
| Field | Rule |
|
||||||
|
|---|---|
|
||||||
|
| `type` | One of `measure-pattern`, `experience-note`, `expert-advice`. |
|
||||||
|
| `title` | Single-line human-readable title (the `## {type}: {title}` heading, §3 Step 1). |
|
||||||
|
| `description` | A **single-line** summary of the file — this is the one-line summary the read-context's summary tier renders (§3 Step 1, the library-tier rule). REQUIRED and non-empty. |
|
||||||
|
| `dimension` | The catalog dimension `id` (§13.3) this knowledge is scoped to. MUST match a catalog entry; an unknown dimension is a fail-fast error (§13.3). |
|
||||||
|
| `sources` | The source attestation: a non-empty list of citations, each identifying a verifiable source (a reference plus a locator — URL, document id, or file+span). A library file with an **empty or missing `sources`** MUST be rejected at materialization (§13.2). |
|
||||||
|
| `provenance` | Who authored the file and its verification status (e.g. machine-authored-with-source-verification vs. expert-authored). Machine-authored content MUST be labelled as such (§1 honesty rule). |
|
||||||
|
|
||||||
|
`tags` and `timestamp` are OPTIONAL and follow the existing bundle convention. Unknown frontmatter
|
||||||
|
fields are preserved (§3 Step 1, OKF robustness rule).
|
||||||
|
|
||||||
|
**Source attestation (normative).** Every library concept file MUST carry at least one verifiable
|
||||||
|
source in `sources`. This mirrors the provenance discipline of §9 ("at least one citation into the
|
||||||
|
source documents"): unsourced domain claims MUST NOT enter the library. Enforcement is fail-fast at
|
||||||
|
materialization (ingest spec §4a/§8a), never a runtime check inside the loop.
|
||||||
|
|
||||||
|
### 13.1 The separation rule (unwaivable)
|
||||||
|
|
||||||
|
The knowledge library and the verdict layer reach the hypothesis prompt through **two disjoint
|
||||||
|
carriers that are never crossed**:
|
||||||
|
|
||||||
|
- Library files (`measure-pattern`, `experience-note`, `expert-advice`) are context-layer content.
|
||||||
|
They reach the prompt **ONLY** via context rendering (§3 Step 1's read-context) — **never** via
|
||||||
|
the experience fold. They are not `type: verdict`, so seeding (§3 Step 1) never turns them into
|
||||||
|
store entries, and retrieval never ranks over them.
|
||||||
|
- Prior verdicts reach the prompt **ONLY** via the gated experience fold (§3 Step 1) — **never** via
|
||||||
|
context rendering (the existing verdict-layer exclusion). This is unchanged.
|
||||||
|
|
||||||
|
The two directions are symmetric and both load-bearing: an organisation's realization-rate
|
||||||
|
corrections (verdicts) MUST NOT leak into the read-context, and library knowledge MUST NOT be
|
||||||
|
injected as if it were an approved verdict. Conflating the carriers would either re-leak the gated
|
||||||
|
learning signal or inject un-gated "approved" knowledge around the promotion gate (§6) — the
|
||||||
|
self-contamination the layer separation exists to prevent (§2).
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
### 1.2 Dimensjonskatalog-kontrakten (D-F pkt. 5)
|
||||||
|
|
||||||
|
Rasjonale (norsk): D-F pkt. 5 krever en **dimensjonskatalog som konfig**, skjema-validert fail-fast,
|
||||||
|
med feltene *id, label, allowed_measure_types, allowed_code_prefixes*. Dette er **eksakt** den
|
||||||
|
eksisterende `Dimension`-modellen (`src/portfolio_optimiser/dimension.py`) — amendmenten løfter den fra
|
||||||
|
"konstrueres kun i tester" (revisjonspakka §0 F-INT-1) til en spec'et startup-kontrakt, uten å endre
|
||||||
|
feltene. Katalogen hører til startup-kontrakt-disiplinen i §10 ("ALL configuration MUST be
|
||||||
|
schema-validated fail-fast at startup").
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → new `### 13.3` under §13, and an §10 cross-reference) ---
|
||||||
|
|
||||||
|
### 13.3 The dimension catalogue (startup contract)
|
||||||
|
|
||||||
|
A **dimension** is one cost axis a project is reduced along (energy, paving, ...). A conforming
|
||||||
|
implementation MUST define a **dimension catalogue**: configuration, schema-validated fail-fast at
|
||||||
|
startup (§10), listing the dimensions the run recognises. Each entry:
|
||||||
|
|
||||||
|
| Field | Rule |
|
||||||
|
|---|---|
|
||||||
|
| `id` | Stable dimension identifier (string). Library files reference it via `dimension:` frontmatter (§13). |
|
||||||
|
| `label` | Human-readable label; non-empty. |
|
||||||
|
| `allowed_measure_types` | The set of `measure_type` values that belong to this dimension. |
|
||||||
|
| `allowed_code_prefixes` | The set of affected-code prefixes constraining the dimension; MAY be empty (no code constraint). |
|
||||||
|
|
||||||
|
**Scoping gate (normative):** a candidate measure *belongs* to a dimension iff its `measure_type` is
|
||||||
|
in `allowed_measure_types` **and** either `allowed_code_prefixes` is empty **or** at least one
|
||||||
|
affected code starts with an allowed prefix. *(reference: `dimension.admits`.)*
|
||||||
|
|
||||||
|
**Catalogue reference (normative):** every library file's `dimension:` MUST resolve to a catalogue
|
||||||
|
`id`; a library file scoped to an unknown dimension is a fail-fast materialization error (ingest
|
||||||
|
spec §4a). The framework SHIPS an example catalogue (the energy dimension); the deploying
|
||||||
|
organisation owns its own catalogue.
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → append one bullet to `## 10. Startup contracts`) ---
|
||||||
|
|
||||||
|
- the dimension catalogue (§13.3), when the run uses a knowledge library — each entry REQUIRING
|
||||||
|
`id`, `label`, and `allowed_measure_types` (with `allowed_code_prefixes` defaulting to empty).
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
### 1.3 §2-insert (peker fra arkitektur-seksjonen) + §12 cross-check-rader
|
||||||
|
|
||||||
|
Rasjonale (norsk): §2 lister kontekst-lagets innhold; den bør nevne biblioteket eksplisitt så
|
||||||
|
separasjonsregelen er synlig der de tre lagene defineres. Og §12 cross-check-tabellen er
|
||||||
|
**completeness-håndhevet** av integrity-testen (`test_spec_documents_every_contract_field` — hvert
|
||||||
|
felt koden konsumerer må stå i spec-en som `` `felt` ``). Når D-F bygges vil koden konsumere de nye
|
||||||
|
feltene; radene under sikrer at test 3 forblir grønn da (se §5).
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → append to the context-layer bullet in `## 2.`) ---
|
||||||
|
|
||||||
|
The context layer MAY additionally carry a **knowledge library** (§13): source-attested
|
||||||
|
`measure-pattern` / `experience-note` / `expert-advice` files. Like all context-layer content the
|
||||||
|
library reaches the prompt only by navigation/rendering (§3 Step 1), never through the experience
|
||||||
|
fold — and, symmetrically, verdicts never reach it through rendering (§13.1).
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → append rows to the `## 12. Cross-check table`) ---
|
||||||
|
|
||||||
|
| Field | Contract | Section |
|
||||||
|
|---|---|---|
|
||||||
|
| `description` | library concept frontmatter (summary tier) | §13, §3 Step 1 |
|
||||||
|
| `dimension` | library concept frontmatter / dimension catalogue reference | §13, §13.3 |
|
||||||
|
| `sources` | library concept frontmatter (source attestation) | §13 |
|
||||||
|
| `provenance` | library concept frontmatter | §13 |
|
||||||
|
| `id`, `label` | dimension catalogue entry | §13.3, §10 |
|
||||||
|
| `allowed_measure_types`, `allowed_code_prefixes` | dimension catalogue entry | §13.3 |
|
||||||
|
| `measure-pattern`, `experience-note`, `expert-advice` | knowledge-library OKF types | §13 |
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
> Merk (norsk): `description`, `type` og `measure_type` er allerede i §12; radene over er additive og
|
||||||
|
> peker de NYE bruksstedene. Ved innliming: slå `description`-raden sammen med den eksisterende hvis
|
||||||
|
> commons foretrekker én rad per feltnavn (integrity-testen krever bare at `` `description` ``
|
||||||
|
> finnes, ikke antall rader).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Bibliotek-materialisering som ingest-kildefamilie `library` (`ingest-spec.md`)
|
||||||
|
|
||||||
|
**Plassering:** ny kildefamilie `type: "library"` i `ingest-spec.md` §4 (polymorf på `source.type`,
|
||||||
|
ved siden av `file`/`sql`/`http`), pluss en materialiserings-regel i §5 og en gate-regel i §8. Skrevet
|
||||||
|
som eget under-utkast med korrekt §-referanse, jf. oppdraget.
|
||||||
|
|
||||||
|
Rasjonale (norsk): D-F pkt. 4 sier det delte dimensjonsbiblioteket **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. Ingest-spec §1 er allerede rammen: "data reaches the model ONLY via OKF bundles ...
|
||||||
|
materializes the extract as a bundle". `library` er en ny kilde i den rammen. Den skiller seg fra
|
||||||
|
`file`/`sql` på ett punkt: den materialiserer **kuraterte kunnskaps-konseptfiler** (prosa med
|
||||||
|
frontmatter), ikke rader i en tabell — parallelt med hvordan `http` har sin egen body-render-regel.
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (ingest-spec.md → new `### 4a. The `library` source family` under §4) ---
|
||||||
|
|
||||||
|
### 4a. The `library` source family (extension)
|
||||||
|
|
||||||
|
`type: "library"` materializes a **curated dimension library** (method spec §13) into a project
|
||||||
|
bundle: shared, source-attested `measure-pattern` / `experience-note` / `expert-advice` files. It
|
||||||
|
reuses the whole ingest contract (deterministic, zero model calls §1; provenance stamping §7;
|
||||||
|
index generation §6; replacement semantics §3/§5). It exists so shared cross-project knowledge is
|
||||||
|
**materialized in**, not cross-linked and not hand-duplicated (navigation stays flat/same-dir, OKF
|
||||||
|
§3 Step 1 rule).
|
||||||
|
|
||||||
|
**`source` fields** (in addition to the common `id`, §4):
|
||||||
|
|
||||||
|
- Field `root`: the directory the curated library entries resolve against. Path resolution MUST be
|
||||||
|
boundary-checked against `root`, fail-closed (the OKF path rule) — an extraction can never read
|
||||||
|
outside the catalogue.
|
||||||
|
|
||||||
|
**`extractions` — each entry** for a `library` source (all required):
|
||||||
|
|
||||||
|
| Field | Meaning |
|
||||||
|
|---|---|
|
||||||
|
| `id` | Unique within the manifest, matching `[a-z0-9][a-z0-9-]*`; names the generated file (`library-{id}.md`, §5a). |
|
||||||
|
| `title` | Single-line title; becomes the `title` frontmatter and the index link label (§6). |
|
||||||
|
| `query` | A relative path (within `root`) to one curated library entry (a markdown file with frontmatter). |
|
||||||
|
| `okf_type` | The generated file's OKF `type`. MUST be one of `measure-pattern`, `experience-note`, `expert-advice` (case-insensitive) and MUST NOT be `verdict` (§3 verdict-layer reservation). |
|
||||||
|
| `dimension` | The dimension catalogue `id` (method spec §13.3) the entry is scoped to. Stamped as the generated file's `dimension` frontmatter. |
|
||||||
|
| `max_rows` | Required positive integer cap; for `library`, the cap on entries drawn from a single curated file (§8). |
|
||||||
|
|
||||||
|
**Source attestation is enforced here (normative).** A curated entry whose frontmatter carries an
|
||||||
|
empty or missing `sources` list (method spec §13) MUST be rejected fail-fast at manifest/source
|
||||||
|
validation — the machine-generated library never ships unsourced domain claims. This is the
|
||||||
|
content model's teeth at ingest time, mirroring §8's other fail-fast caps.
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (ingest-spec.md → new `### 5a. `library` materialization` under §5) ---
|
||||||
|
|
||||||
|
### 5a. `library` materialization (deterministic)
|
||||||
|
|
||||||
|
For a `library` source, each extraction produces one concept file named `library-{extraction id}.md`
|
||||||
|
(the `library-` prefix keeps the namespace disjoint from `index.md`, `ingest-*`, and
|
||||||
|
`promoted-verdict-*`, §3). Materialization is deterministic and takes the same three explicit inputs
|
||||||
|
as §5 (manifest, target bundle, `ingested_at`).
|
||||||
|
|
||||||
|
- **Frontmatter** — the curated entry's own OKF frontmatter (`type` = the extraction's `okf_type`,
|
||||||
|
plus `title`, `description`, `dimension`, `sources`, `provenance` per method spec §13), extended
|
||||||
|
with the ingest provenance layer (§7): `source_system`, `source_query`, `ingested_at`,
|
||||||
|
`ingest_manifest`, `generated: true`. The provenance layer is ADDITIVE — it never overwrites the
|
||||||
|
curated `description`/`sources`/`provenance` fields (two separate contracts, never mixed, §7).
|
||||||
|
- **Body rendering** — the curated entry's markdown body verbatim (LF-only, exactly one trailing
|
||||||
|
newline). Unlike `file`/`sql` (a table) or `http` (a fenced block), a library entry is already
|
||||||
|
authored prose; it is carried through unchanged.
|
||||||
|
- **Replacement semantics (§3/§5):** library files carry the ingest stamp, so re-materialization
|
||||||
|
replaces EXACTLY the ingest-owned files and MUST NOT touch curated or promoted files. A
|
||||||
|
`library-{id}.md` collision with an unstamped existing file MUST fail — never overwrite curated
|
||||||
|
content.
|
||||||
|
- **Index generation (§6):** each generated file gets one index cross-link
|
||||||
|
`- [{title}](library-{id}.md)`, preserving all curated and promoted links verbatim.
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (ingest-spec.md → cross-check table `## 12.`, append rows) ---
|
||||||
|
|
||||||
|
| Field | Contract | Section |
|
||||||
|
|---|---|---|
|
||||||
|
| `root` | manifest source (`library`) | §4a |
|
||||||
|
| `dimension` | manifest extraction (`library`) / generated frontmatter | §4a, §5a |
|
||||||
|
| `okf_type` | manifest extraction (`library`, restricted set) | §4a, §3 |
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
> Merk (norsk): `root`, `title`, `query`, `okf_type`, `max_rows`, `id` finnes allerede i §12
|
||||||
|
> (delt med `file`/`sql`/`http`); kun de genuint nye radene (`root` for library-source, `dimension`)
|
||||||
|
> er additive. `library` arver §11-load-bearing-sømmene (provenance-stamping, navigerbarhet,
|
||||||
|
> verdict-reservasjon, re-ingest-lag-sikkerhet) uendret — en ny golden-case
|
||||||
|
> `examples/ingest-golden-library/` legges til (endrer ikke `file`/`sql`-goldens; se §5).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Trinnvis-lesing-analysen (revisjonspakka §6 nøkkelantakelse)
|
||||||
|
|
||||||
|
**Spørsmål (revisjonspakka §6):** kan sammendrag-først / fulltekst-ved-behov (D-F pkt. 6)
|
||||||
|
spesifiseres UTEN å endre `method-spec.md` §3 Step 1s render-kontrakt — «index body + hver konseptfil
|
||||||
|
som `## {type}: {title}`-seksjon»?
|
||||||
|
|
||||||
|
### 3.1 Konklusjon: **NEI** — det krever en minimal, bakoverkompatibel Step-1-amendment.
|
||||||
|
|
||||||
|
Ikke gjettet — forankret i to siterte spec-linjer og render-koden.
|
||||||
|
|
||||||
|
**Bevis 1 — render-kontrakten mandaterer full body per konseptfil.** `method-spec.md` §3 Step 1:
|
||||||
|
|
||||||
|
> «The rendered read-context is the index body (the summary) followed by each non-index concept file
|
||||||
|
> as a `## {type}: {title}` section; empty sections are dropped.» (method-spec.md:76–77)
|
||||||
|
|
||||||
|
Referanse-implementasjonen fyller den seksjonen med **hele** filkroppen — `bundle_context` i
|
||||||
|
`okf.py:150-151`:
|
||||||
|
|
||||||
|
> `title = f.frontmatter.get("title", f.name).strip('"')`
|
||||||
|
> `sections.append(f"## {f.type or 'document'}: {title}\n{f.body}")` — `f.body` er hele body.
|
||||||
|
|
||||||
|
Med 15–30 tiltak i biblioteket (D-F pkt. 7) er «render hver konseptfil sin fulle body» **nettopp**
|
||||||
|
prompt-drukningen D-F pkt. 6 avviser («Dagens 'render alt navigert' skalerer ikke»). Å rendre
|
||||||
|
sammendrag først (én linje per fil) og full tekst kun for et utvalg er per definisjon *ikke* det
|
||||||
|
kontrakten sier i dag → kontrakten må endres.
|
||||||
|
|
||||||
|
**Bevis 2 — den eneste alternative bæreren for «fulltekst ved behov» er forbudt.** «Ved behov»
|
||||||
|
antyder at agenten henter full tekst ved forespørsel. Men et query-time retrieval-verktøy mot bundelen
|
||||||
|
er **eksplisitt forbudt** i samme Step 1:
|
||||||
|
|
||||||
|
> «Prior verdicts reach the hypothesis prompt ONLY via the gated experience fold below — never via
|
||||||
|
> context rendering, and **never via a query-time retrieval tool pointed at the bundle** (which would
|
||||||
|
> re-leak the verdict layer).» (method-spec.md:78–81)
|
||||||
|
|
||||||
|
Forsterket, arkitektur-definerende, i `ingest-spec.md` §1:
|
||||||
|
|
||||||
|
> «The method spec (§3 Step 1) forbids query-time retrieval against the bundle. ... **data reaches
|
||||||
|
> the model ONLY via OKF bundles** ... not RAG, not live lookups inside the agent loop, no retrieval
|
||||||
|
> tools in the run path.» (ingest-spec.md:21–25)
|
||||||
|
|
||||||
|
Så «fulltekst ved behov» kan **ikke** realiseres som et agent-kalt oppslagsverktøy. Det etterlater
|
||||||
|
kun én lovlig mekanisme: et **deterministisk, pre-run utvalg** av hvilke filer som får full body —
|
||||||
|
og det er nettopp en endring av render-kontrakten.
|
||||||
|
|
||||||
|
**At det finnes presedens** (som gjør amendmenten liten, ikke prinsipielt ny): `bundle_context` har
|
||||||
|
allerede et deterministisk `dimension`-filter (`okf.py:133, 146-149`) — «only concept files whose
|
||||||
|
frontmatter `dimension` matches ... are rendered». Det beviser at arkitekturen allerede tåler et
|
||||||
|
deterministisk pre-run-utvalg over hvilke filer som rendres, uten retrieval-verktøy. (Sidefunn: det
|
||||||
|
filteret finnes i KODEN, men står ikke i method-spec §3 Step 1 i dag — en udokumentert utvidelse
|
||||||
|
amendmenten samtidig bør folde inn i spec-en, jf. utvidelses-policyen §4.)
|
||||||
|
|
||||||
|
### 3.2 Foreslått minimal Step-1-amendment (in-place i §3 Step 1)
|
||||||
|
|
||||||
|
Endrer KUN seksjons-**innholdet** for bibliotek-tier-filer; beholder index-først, `## {type}: {title}`-
|
||||||
|
overskriften, verdict-eksklusjonen og no-retrieval-invarianten. **Default (ingen bibliotek-tier-filer)
|
||||||
|
er byte-identisk med dagens oppførsel** — så eksisterende bundler (f.eks. `bygg-energi-mikro`) rendres
|
||||||
|
uendret og eksisterende tester forblir grønne (§5).
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → REPLACE the render bullet in §3 Step 1) ---
|
||||||
|
|
||||||
|
- The rendered read-context is the index body (the summary) followed by each non-index concept file
|
||||||
|
as a `## {type}: {title}` section. A **library-tier** concept file (§13:
|
||||||
|
`measure-pattern` / `experience-note` / `expert-advice`) contributes only its single-line
|
||||||
|
`description` frontmatter as the section body by default — the **summary tier**, one line per
|
||||||
|
library file, so the library can grow large without prompt-drowning. Its **full body** is rendered
|
||||||
|
ONLY for the bounded subset chosen by a DETERMINISTIC pre-run selector (e.g. the candidate's
|
||||||
|
dimension, §13.3) — never by a query-time retrieval tool pointed at the bundle (the no-retrieval
|
||||||
|
invariant above). Non-library concept files render their full body as before. Empty sections are
|
||||||
|
dropped. *(reference: with no library-tier files present, this is byte-identical to rendering
|
||||||
|
every concept file's full body — the pre-existing behaviour.)*
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
> Norsk presisering: «deterministisk pre-run selector» = samme klasse som det eksisterende
|
||||||
|
> `dimension`-filteret (kandidatens dimensjon avgjør hvilke bibliotekfiler som får full body).
|
||||||
|
> Ingen ny modell-runde, intet oppslagsverktøy, ingen ny løkke — utvalget skjer FØR generering, på
|
||||||
|
> IR-projeksjonens kandidat-features (som allerede er tilgjengelig pre-hypotese, §3 Step 1 fold).
|
||||||
|
> Verdict-eksklusjonen er urørt: bibliotek-tier er en delmengde av `context_files` (aldri
|
||||||
|
> `type: verdict`), så `test_bundle_context_excludes_verdict_layer` + empty-store-kontrollen forblir
|
||||||
|
> røde-ved-detach som før.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Utvidelses-policy (D-G pkt. 1)
|
||||||
|
|
||||||
|
**Plassering:** ny normativ note, enten som `### 2a. Relationship to Google OKF v0.1` i `method-spec.md`
|
||||||
|
§2, eller som delt avsnitt i begge spec-enes §1. Kort, normativ.
|
||||||
|
|
||||||
|
Rasjonale (norsk): D-G pkt. 1 — «standard-kompatibel»; egne utvidelser (innboks-konseptet,
|
||||||
|
ingest-sikkerhet, evaluator-felt) dokumenteres **eksplisitt som utvidelser** av Google OKF v0.1 og
|
||||||
|
**pensjoneres** hvis standarden senere dekker dem. Ingen permanent fork.
|
||||||
|
|
||||||
|
--- BEGIN SPEC INSERT (method-spec.md → new `### 2a. Relationship to Google Open Knowledge Format v0.1`) ---
|
||||||
|
|
||||||
|
### 2a. Relationship to Google Open Knowledge Format v0.1
|
||||||
|
|
||||||
|
The bundle format is **Google Open Knowledge Format (OKF) v0.1**. This method adds capabilities ON
|
||||||
|
TOP of the base format; each such capability is a **local extension**, not part of the standard, and
|
||||||
|
MUST be documented as one:
|
||||||
|
|
||||||
|
- the **verdict layer** and the **promotion gate** (§2, §6): `type: verdict` files, the
|
||||||
|
`promoted-verdict-*` filename namespace, and the neutral-label index rule;
|
||||||
|
- the **inbox/outbox folder contract** (§5): the async long-loop file interface;
|
||||||
|
- the **ingest provenance layer** and the **security frame** (ingest spec §7–§9):
|
||||||
|
`generated`/`ingest_manifest`/`source_system`/`source_query`/`ingested_at`, and the network
|
||||||
|
opt-in;
|
||||||
|
- the **knowledge library** and the **dimension catalogue** (§13);
|
||||||
|
- **evaluator fields** (future work): any conformance/sufficiency scoring frontmatter a bundle
|
||||||
|
evaluator introduces.
|
||||||
|
|
||||||
|
**Retirement rule (normative):** if a future OKF version standardises an equivalent of a local
|
||||||
|
extension, the implementation MUST migrate to the standard mechanism and RETIRE the local extension —
|
||||||
|
no permanent divergence from the format. Extensions MUST NOT change the meaning of any base-format
|
||||||
|
field; they only add reserved types, reserved filename namespaces, and additive frontmatter, all of
|
||||||
|
which base-format consumers preserve as unknown fields.
|
||||||
|
|
||||||
|
--- END SPEC INSERT ---
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Konsekvens-liste
|
||||||
|
|
||||||
|
### 5.1 Spec-integrity-testen (`tests/test_method_spec_loadbearing.py`)
|
||||||
|
|
||||||
|
Verifisert mot faktisk lest test. Amendmenten er konstruert for å holde alle fem testene grønne:
|
||||||
|
|
||||||
|
- **`test_method_spec_exists_with_required_structure` (test 1):** asserter at `_REQUIRED_MARKERS`
|
||||||
|
(`## 1.`–`## 12.` + `### Step 1..8` + `MUST`) FINNES. Markørene er presence-asserts, ikke
|
||||||
|
forbud mot ekstra seksjoner → ny `## 13.` og `### 2a` bryter ingenting. Render-bullet-endringen i
|
||||||
|
§3 Step 1 beholder `### Step 1 — ` intakt. **Grønn.**
|
||||||
|
- **`test_method_spec_is_framework_neutral` (test 2):** grep-guard mot `_FRAMEWORK_NAMES` (MAF,
|
||||||
|
Claude, Azure, Foundry, OpenAI, Ollama, ...) over BEGGE spec-ene + persona-treet. All engelsk
|
||||||
|
spec-tekst i §1–§4 er bevisst framework-nøytral (ingen leverandørnavn; «a query-time retrieval
|
||||||
|
tool», ikke et produktnavn). **Grønn — forutsatt at innlimingen ikke introduserer et
|
||||||
|
leverandørnavn.** (Sjekk før commons-commit: `grep -nE '<_FRAMEWORK_NAMES>' method-spec.md
|
||||||
|
ingest-spec.md` → 0 treff.)
|
||||||
|
- **`test_spec_documents_every_contract_field` (test 3):** completeness-drevet fra REELLE artefakter
|
||||||
|
+ serializer — hvert felt koden konsumerer må stå som `` `felt` `` i spec-en. **I dag konsumerer
|
||||||
|
ingen kode D-F-feltene (D-F er ikke bygget)** → test 3 krever dem ikke ennå. Men §1.3s
|
||||||
|
cross-check-rader (`description`, `dimension`, `sources`, `provenance`, `id`, `label`,
|
||||||
|
`allowed_measure_types`, `allowed_code_prefixes`, de tre typene) sikrer at når koden lander
|
||||||
|
(dimensjonskatalog-loader, bibliotek-frontmatter-modell), er feltene ALLEREDE dokumentert → test 3
|
||||||
|
forblir grønn i byggeøkta. **Grønn nå; forhånds-dekket for byggetid.**
|
||||||
|
- **`test_ingest_spec_exists_with_required_structure` (test 4):** asserter `_INGEST_REQUIRED_MARKERS`
|
||||||
|
(`## 1.`–`## 12.`) + verdict-reservasjonen (`` `type: verdict` `` + `promoted-verdict-`) +
|
||||||
|
`` `ingested_at` ``. Nye `### 4a`/`### 5a` bryter ingen markør; `library`-`okf_type` STYRKER
|
||||||
|
reservasjonen (MUST NOT be `verdict`). **Grønn.**
|
||||||
|
- **`test_ingest_spec_documents_every_contract_field` (test 5):** drevet fra `ManifestV1` +
|
||||||
|
source-modellenes `model_fields`. **I dag finnes ingen `LibrarySource`-modell** → test 5 krever
|
||||||
|
ikke `library`-feltene ennå. §2s cross-check-rader (`root`, `dimension`, `okf_type`) forhånds-dekker
|
||||||
|
byggetid, akkurat som test 3. **Grønn nå; forhånds-dekket.**
|
||||||
|
|
||||||
|
**Netto:** amendmenten er ren dokument-endring i commons; ingen av de fem integrity-testene i DETTE
|
||||||
|
repoet blir røde av å hente den ned (pull), fordi ingen NY kode konsumerer feltene før byggeøkta —
|
||||||
|
og da er feltene allerede dokumentert.
|
||||||
|
|
||||||
|
### 5.2 D7-søsken-speiling (flagges, utenfor scope her)
|
||||||
|
|
||||||
|
Amendmenten endrer de **delte** spec-ene begge stacker bygger fra. Per D-G pkt. 2 er OKF-formatlaget
|
||||||
|
nå bevisst delt/speilet (endrer D7s «from spec alone» for formatlaget). Konsekvens: når method-spec
|
||||||
|
+ ingest-spec får denne innholdsmodellen, må **begge** implementasjoner re-implementere fra den nye
|
||||||
|
spec-en — særlig Claude-SDK-søskenet, hvis `okf.py` (A2, revisjonspakka §0.2) i dag mangler skrive-
|
||||||
|
halvdelen. **Dette utkastet leverer KUN spec-teksten; selve speilingen/byggingen er senere økt** (D-F
|
||||||
|
innplassering: Fase 3-bolken; toolkit-repo blokkerer fabrikk-avhengige deler). Flagget her, ikke
|
||||||
|
utført.
|
||||||
|
|
||||||
|
### 5.3 Golden-suiten uberørt (begrunnet)
|
||||||
|
|
||||||
|
- **`method-spec.md` §7 golden-suite** fryser VALIDATOR-utfallet (`validator` + `learning_surface`)
|
||||||
|
over IR-projeksjonen (`validator-input.json`). Innholdsmodellen legger til kontekst-lag-typer +
|
||||||
|
en summary-tier-render + dimensjonskatalog + `library`-ingest — **ingen** av dem rører
|
||||||
|
IR-projeksjonen, validator-semantikken eller `learning_surface`. `golden.json` +
|
||||||
|
`test_bygg_energi_mikro.py` er derfor uendret grønne.
|
||||||
|
- **Render-endringen** påvirker `bundle_context`-output, men den er **ikke** golden-frosset (golden
|
||||||
|
fryser validator-tall, ikke read-context-strengen). De load-bearing invariantene som FINNES på
|
||||||
|
render (verdict-eksklusjon + empty-store-kontroll) bevares eksplisitt av amendmenten (§3.2:
|
||||||
|
bibliotek-tier er ikke-verdict, default byte-identisk). **Grønn.**
|
||||||
|
- **`ingest-spec.md` §11 golden-extractions** er per-kildetype. `library` legger til en NY case
|
||||||
|
(`examples/ingest-golden-library/`); `file`/`sql`-goldens er uendret. **Grønn.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Verifisering (utkastets egne kriterier)
|
||||||
|
|
||||||
|
Testbare sjekker FØR commons-commit (etter operatør-godkjenning, i overførings-økta):
|
||||||
|
|
||||||
|
1. **Framework-nøytralitet:** `grep -nE
|
||||||
|
'\bagent[_ -]framework\b|\bMAF\b|\bClaude\b|\bAnthropic\b|\bMicrosoft\b|\bAzure\b|\bFoundry\b|\bOpenAI\b|\bOllama\b|\bLangChain\b|\bAutoGen\b|\bSemantic Kernel\b|\bCrewAI\b|\bMagentic\b'`
|
||||||
|
over de amendede spec-ene → **0 treff** (samme regex som `_FRAMEWORK_NAMES`).
|
||||||
|
2. **Struktur intakt:** `grep -n '### Step 1 — ' method-spec.md` → treff (render-bullet-endringen brøt
|
||||||
|
ikke Step-1-overskriften); `grep -n '## 13. The knowledge library' method-spec.md` → treff.
|
||||||
|
3. **Verdict-reservasjon styrket:** ingest-spec `library`-`okf_type` MUST NOT be `verdict` er
|
||||||
|
verbatim i teksten (`grep -n 'MUST NOT be `verdict`' ingest-spec.md` → treff).
|
||||||
|
4. **Cross-check-completeness forhånds-dekket:** hvert nytt felt (`sources`, `dimension`,
|
||||||
|
`provenance`, `allowed_measure_types`, `allowed_code_prefixes`, `root`) står som `` `felt` `` i
|
||||||
|
riktig spec (så integrity-test 3/5 blir grønn i byggeøkta).
|
||||||
|
5. **Ingen kodeendring i denne økta:** `git status` i portfolio-optimiser viser kun den nye
|
||||||
|
`docs/plan/2026-07-14-commons-amendment-utkast.md`; `shared/` urørt; full suite fortsatt grønn.
|
||||||
|
|
||||||
|
**Nøkkelantakelse (revisjonspakka §6), avgjort:** trinnvis-lesing **kan IKKE** spesifiseres uten å
|
||||||
|
endre §3 Step 1s render-kontrakt (§3.1, forankret i method-spec.md:76–81 + ingest-spec.md:21–25 +
|
||||||
|
okf.py:150-151). Den minimale, bakoverkompatible amendmenten er levert (§3.2) — merket som del av
|
||||||
|
commons-amendmenten, slik pakka §6 krever ved NEI.
|
||||||
|
|
@ -157,7 +157,7 @@ flagges). Amendment-utkastet skrives i utrullings-økta (§5).
|
||||||
Adopsjonssti dokumenteres: start liten (én dimensjon, ett prosjekt, lavt tak) → eskaler
|
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.
|
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å)
|
## 5. Innplassering i planverket (apply-liste — status 2026-07-15: pkt. 1, 2, 4 UTFØRT; pkt. 3 = utkast skrevet, venter operatør-godkjenning; pkt. 5–6 uendret)
|
||||||
|
|
||||||
1. **Sesjonsplanen** (`2026-07-10-sesjonsplan-fase2-6.md`): nye §2-oppføringer D-F–D-I med
|
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*
|
status BESLUTTET (fasit her); nye sesjoner skisseres: S3.5+ *bibliotek/innholdsmodell*
|
||||||
|
|
|
||||||
201
docs/plan/2026-07-14-toolkit-repo-brief.md
Normal file
201
docs/plan/2026-07-14-toolkit-repo-brief.md
Normal file
|
|
@ -0,0 +1,201 @@
|
||||||
|
# Program-brief: `okf-toolkit` — delt OKF-verktøykasse (modul + formatprøve + evaluator + fabrikk)
|
||||||
|
|
||||||
|
> **Status: BRIEF, ikke plan.** Skrevet 2026-07-14 som utrulling av
|
||||||
|
> [revisjonspakke D-F–D-I](2026-07-14-revisjonspakke-DF-DI.md) §5 pkt. 4. Kilden er pakkas
|
||||||
|
> **§0.2** (kryssrepo-OKF-inventar), **§2 D-G** (felles modul + fabrikk + evaluator) og
|
||||||
|
> **§3 D-H** (oppsett/oversettelse). Dette dokumentet er *input* til et NYTT, eget repo utenfor
|
||||||
|
> dette repoets sesjonskø. Programmets to første leveranser er et repo-init + et målbilde/gated
|
||||||
|
> sesjonsplan — lages i det nye repoet, ikke her. Ingenting bygges før den planleggingssesjonen
|
||||||
|
> har kjørt og operatør har godkjent.
|
||||||
|
>
|
||||||
|
> **Provenance:** anbefalinger = AI (Opus, denne økten 2026-07-14); beslutningene D-G/D-H =
|
||||||
|
> operatør, protokollert i revisjonspakka. Arbeidstittel `okf-toolkit` — **operatør navngir**.
|
||||||
|
> Gjenbruksmal: `llm-ingestion-guard` (verifisert: pip-pakke, `dependencies = []` stdlib-only
|
||||||
|
> kjerne, valgfrie extras bak flagg, ærlige begrensninger shippet som kontroll).
|
||||||
|
|
||||||
|
## 1. Formål (hvorfor repoet må finnes)
|
||||||
|
|
||||||
|
Én delt, **standard-kompatibel OKF-verktøykasse** — for alle repoene i denne familien OG for
|
||||||
|
alle som tar i bruk Google Open Knowledge Format (v0.1). I dag rulles formatet ut på ≥6
|
||||||
|
kodelokasjoner (revisjonspakke §0.2, verifisert mot ground truth 2026-07-14):
|
||||||
|
|
||||||
|
| # | Lokasjon | Størrelse | Delmengde |
|
||||||
|
|---|---|---|---|
|
||||||
|
| A1 | `portfolio-optimiser/.../okf.py` | 202 l | les + naviger + **skriv** (Steg 8-primitiver) |
|
||||||
|
| A2 | `portfolio-optimiser-claude/.../okf.py` | 134 l | **kun les** — mangler skrive-halvdelen |
|
||||||
|
| C1 | `claude-code-llm-wiki/tools/wiki_ingest/bundle.py` | 436 l | OKF-produsent (ingest→bundle) |
|
||||||
|
| C2 | `llm-ingestion-pipeline-security/.../okf.py` | 579 l | defensiv validator, reject-by-default |
|
||||||
|
| B1/B2 | `ktg-plugin-marketplace/` (`.mjs`/`.ts`) | JS/TS | index-generering + conformance |
|
||||||
|
|
||||||
|
≥4 uavhengige Python-`parse_frontmatter` + 2 i JS. Konsekvensene (F-INT-2): duplisert
|
||||||
|
vedlikehold, og at Claude-søskenet (A2) **mangler skrive-halvdelen** A1 har — så det ikke kan
|
||||||
|
være «minst like godt» som MAF-repoet (operatørens favoritt). D-G vedtar én delt modul, og
|
||||||
|
**reverserer bevisst** de to tidligere «del spec, ikke kode»-beslutningene (marketplace-brief
|
||||||
|
2026-06-26 + D7) for den tolerante kjernen — operatør-godkjent 2026-07-14. Formatlaget ligger
|
||||||
|
UNDER det D7-sammenligningen måler, så delt kode her forurenser ikke sammenligningen.
|
||||||
|
|
||||||
|
## 2. Arkitektonisk premiss (arvet fra D-G/D-H — ufravikelig)
|
||||||
|
|
||||||
|
- **Standard-kompatibel først.** Kjernen retter seg etter Google OKF v0.1 — inkludert
|
||||||
|
`/`-lenkeformen som method-spec i dag avviker fra (review F4 / D-A pkt. 3; D-G pkt. 1
|
||||||
|
forsterker denne). **Egne utvidelser oppå** (innboks-konseptet, ingest-sikkerhet,
|
||||||
|
evaluator-felt) dokumenteres EKSPLISITT som utvidelser og pensjoneres hvis standarden senere
|
||||||
|
løser dem.
|
||||||
|
- **Installerbar pakke, avhengighetsfri kjerne, Forgejo** — guard-malen én-til-én:
|
||||||
|
`dependencies = []`, stdlib-only kjerne, valgfrie adaptere bak extras. Potensielt nyttig for
|
||||||
|
ALLE som tar i bruk Google OKF, ikke bare denne familien.
|
||||||
|
- **Ren stdlib, framework-nøytral.** Kjernen importerer aldri `agent_framework`/`mcp` (arver
|
||||||
|
A1s `test_okf_is_maf_free`-invariant + guard-malens stdlib-first). Samme modul konsumeres
|
||||||
|
uendret av begge stacker (D7-portabel).
|
||||||
|
- **Fabrikken lever UTENFOR optimalisererens deterministiske kjøresti** (ærlighets-grense,
|
||||||
|
§6). Den er et *pre-run ingest-steg* som materialiserer en bundle FØR en kjøring — ikke et
|
||||||
|
query-time-oppslag i agent-løkka (samme grense som ingest-brief §2; ikke RAG).
|
||||||
|
- **Guard (C2) konsolideres IKKE inn.** Motsatt sikkerhetsfilosofi by design (reject-by-default
|
||||||
|
vs. tolerant les). Guard forblir eget repo og **brukes som avhengighet** av fabrikkens
|
||||||
|
sikkerhetsvask-steg — komponert, ikke kopiert.
|
||||||
|
|
||||||
|
## 3. Scope — to faser
|
||||||
|
|
||||||
|
### Fase T1 — `okf-core`-modul + formatprøve (først; liten jobb, fjerner duplikasjonen)
|
||||||
|
|
||||||
|
1. **`okf-core`-modul:** tolerant **les / naviger / skriv**-kjerne som erstatter A1/A2/C1-
|
||||||
|
duplikatene. Skrive-halvdelen (`render_frontmatter`, `write_concept_file`, `link_in_index`
|
||||||
|
— verifisert å finnes i A1, fraværende i A2) blir delt, så Claude-søskenet får den det
|
||||||
|
mangler. Pip-pakke, stdlib-only, guard-malen.
|
||||||
|
2. **Formatprøve (conformance-testsett):** kjørbart testsett mot Google OKF v0.1 + våre
|
||||||
|
utvidelser, som ALLE konsumenter kan kjøre mot sine egne bundles. Testsettet er
|
||||||
|
**språknøytral data** — så B-paret (JS/TS) kan konsumere formatprøven selv om det ikke kan
|
||||||
|
importere Python-modulen. Load-bearing: en gyldig bundle passerer; en bevisst malformert
|
||||||
|
(feil lenkeform, manglende frontmatter) FEILER.
|
||||||
|
|
||||||
|
### Fase T2 — evaluator + fabrikk (bygget mot energi-caset som første kunde)
|
||||||
|
|
||||||
|
3. **Bundle-evaluatoren — to jobber** (D-G pkt. 5):
|
||||||
|
- **(a) Teknisk korrekthet (deterministisk):** konformitet, navigerbarhet, lenke-integritet,
|
||||||
|
kildedekning, ferskhet, sikkerhet, sammendragsdisiplin. Samme input → samme score.
|
||||||
|
- **(b) Tilstrekkelighet (AI-vurdert, åpne kriterier):** «omfattende nok til å være nyttig?
|
||||||
|
hva mangler?» — output er fagekspertens arbeidsliste under oppbygging, merket som
|
||||||
|
maskin-vurdering/veiledning, aldri deterministisk fakta.
|
||||||
|
4. **Bundle-fabrikken (operatørs viktigste nå):** bruker slipper filer/mapper i en
|
||||||
|
**bundle-innboks** → prosessen strukturerer, oppsummerer, lenker, stempler og
|
||||||
|
**sikkerhetsvasker** (guard som avhengighet) → ferdig base som evaluatoren scorer høyt på de
|
||||||
|
deterministiske dimensjonene. **Dom-oversettelse (D-H pkt. 3):** eksperten leverer
|
||||||
|
fri-format-fil → fabrikken AI-oversetter til det strenge domsformatet; den strukturerte
|
||||||
|
dommen peker **ALLTID på ekspertens originalfil** (provenance), så en stikkprøve kan
|
||||||
|
sammenligne «hva eksperten skrev» mot «hva systemet forsto». Dommen er menneskets; AI er
|
||||||
|
oversetter.
|
||||||
|
|
||||||
|
## 4. Konsumenter + migreringsrekkefølge
|
||||||
|
|
||||||
|
1. **`portfolio-optimiser` (A1)** → importér `okf-core`; A1s skrive-primitiver flyttes inn i
|
||||||
|
modulen. Full suite (baseline 279/4) skal forbli grønn etter migreringen.
|
||||||
|
2. **`portfolio-optimiser-claude` (A2)** → importér `okf-core`; **får skrive-halvdelen det
|
||||||
|
mangler i dag** (Steg 8-primitiver). Dette er hovedgevinsten for D-Gs «minst like godt»-mål.
|
||||||
|
3. **`claude-code-llm-wiki` (C1)** → senere; produsent-stien (ingest→bundle) legges på
|
||||||
|
`okf-core` + fabrikken.
|
||||||
|
4. **`ktg-plugin-marketplace` (B1/B2)** → forblir JS/TS (kan ikke dele Python-kode), men
|
||||||
|
konsumerer **formatprøven** som delt data.
|
||||||
|
5. **`llm-ingestion-guard` (C2)** → migreres IKKE; forblir eget repo og trekkes inn som
|
||||||
|
**avhengighet** i fabrikkens sikkerhetsvask.
|
||||||
|
|
||||||
|
Rekkefølge (D-G pkt. 6): modul + formatprøve FØRST (fjerner 6-steders-duplikasjonen), fabrikk +
|
||||||
|
evaluator DERETTER — bygget mot energi-caset (D-F pkt. 7) som første kunde. Demo-stien (D-H
|
||||||
|
pkt. 4): fersk klon → unzip energi-eksemplet i innboksen → fabrikken bygger → hele sløyfa kjører.
|
||||||
|
|
||||||
|
## 5. Ærlighets-grenser (§1 målbilde — ufravikelig)
|
||||||
|
|
||||||
|
- **Fabrikken bruker AI og lever utenfor den deterministiske kjøringen.** Alt den produserer
|
||||||
|
merkes maskingenerert (`generated: true` + manifest-ref + provenance til kilden).
|
||||||
|
Kontrollen er evaluatoren + ekspertens stikkprøve — ikke fabrikkens egen tillit.
|
||||||
|
- **Evaluatorens (b)-output er maskin-vurdering**, ikke målt fakta. Deterministisk (a) og
|
||||||
|
AI-vurdert (b) holdes tydelig fra hverandre i rapporten.
|
||||||
|
- **Dom-oversettelsen endrer aldri hvem dommen tilhører.** Provenance-lenken til originalfila
|
||||||
|
er vaktposten mot at AI-oversettelsen stille forvrenger ekspertens vurdering.
|
||||||
|
- **Toolkit-repoet påstår ikke å bevise besparelser.** Det bygger kunnskapsbasen (input til
|
||||||
|
verdibeviset, D-I) — verdipåstanden lever i optimaliserer-repoene, ikke her.
|
||||||
|
|
||||||
|
## 6. Ikke-mål (dokumentert grense)
|
||||||
|
|
||||||
|
- **Ingen erstatning av C2s reject-by-default-parser.** Den tolerante kjernen og den defensive
|
||||||
|
validatoren er bevisst ULIKE verktøy; fabrikken komponerer begge, den slår dem ikke sammen.
|
||||||
|
- **Ingen RAG / query-time-oppslag.** Fabrikken er write-time ingest FØR kjøring (ingest-brief
|
||||||
|
§2-grensen står).
|
||||||
|
- **Ingen compliance-funksjoner.** Rent teknisk verktøykasse (DPIA/ROS eies av deployer).
|
||||||
|
- **Ingen dedikert lese-visning i første scope.** Obsidian/VS Code holder (bundles er ren
|
||||||
|
markdown, D-H pkt. 5); en dedikert lese-visning er en SENERE byggekloss i repoet, ikke nå.
|
||||||
|
- **Ingen endring i optimalisererens agent-atferd eller modell-map.**
|
||||||
|
|
||||||
|
## 7. Avhengigheter og blokkeringer
|
||||||
|
|
||||||
|
- **Energi-caset er første kunde** (D-F pkt. 7): fabrikk + evaluator bygges og bevises mot
|
||||||
|
energi-eksemplet i tilnærmet realistisk skala. T2 kan derfor koordineres med D-F-innholds-
|
||||||
|
arbeidet, men T1 (modul + formatprøve) er uavhengig og kan starte umiddelbart.
|
||||||
|
- **Blokkerer** fabrikk-avhengige deler av D-F (materialisering av dimensjonsbiblioteket) og
|
||||||
|
D-H (demo-stien, dom-oversettelsen).
|
||||||
|
- **D7-speiling:** begge stacker skal konsumere `okf-core` uendret; migreringen av A1 og A2 er
|
||||||
|
koblet (ikke uavhengige økter).
|
||||||
|
- **Guard-avhengighet:** fabrikkens sikkerhetsvask krever `llm-ingestion-guard` som publisert/
|
||||||
|
installerbar avhengighet.
|
||||||
|
|
||||||
|
## 8. Åpne spørsmål til operatør (må avklares før/i repo-init)
|
||||||
|
|
||||||
|
- **Navn:** arbeidstittel `okf-toolkit` — operatør fastsetter endelig pakkenavn (påvirker
|
||||||
|
`pip install <navn>` + importsti).
|
||||||
|
- **Lisens:** guard-presedens er MIT (S12-linja). Bekreft MIT for toolkit, eller avvik.
|
||||||
|
- **Publiseringsrekkefølge:** publiseres `okf-core` (T1) som egen pakke-release FØR fabrikken
|
||||||
|
(T2) finnes, eller samtidig? (Guard-malen taler for tidlig, liten kjerne-release.)
|
||||||
|
- **Repo-plassering:** eget Forgejo-repo bekreftes (som guard), ikke undermappe.
|
||||||
|
|
||||||
|
## 9. Verifisering (for planleggingssesjonen som konsumerer denne briefen)
|
||||||
|
|
||||||
|
**Fase T1:**
|
||||||
|
- [ ] Premissene i §1/§2 kontrollert mot ground truth FØR skriving (§0.2-tallene A1=202/
|
||||||
|
A2=134/C1=436/C2=579 gjenfunnet med `wc -l`; A2 mangler `write_concept_file`/`link_in_index`
|
||||||
|
bekreftet med `grep`). ✅ (utført i denne briefen 2026-07-14)
|
||||||
|
- [ ] `okf-core` installerbar med null avhengigheter: i rent venv `pip install <navn>` +
|
||||||
|
`python -c "import okf_core"` lykkes; `pyproject.toml` viser `dependencies = []`.
|
||||||
|
- [ ] Kjernen framework-nøytral: en `test_okf_is_maf_free`-ekvivalent grønn (`grep -R
|
||||||
|
"agent_framework\|import mcp" src/` tomt).
|
||||||
|
- [ ] Formatprøven load-bearing: gyldig energi-bundle passerer HELE settet; en bevisst
|
||||||
|
malformert bundle (feil lenkeform / manglende frontmatter) gjør minst én conformance-test
|
||||||
|
RØD. Standard-kompatibilitet: `/`-lenkeformen passerer, den gamle formen flagges.
|
||||||
|
- [ ] Migrering: `portfolio-optimiser` importerer `okf-core`, den lokale `okf.py`-duplikaten er
|
||||||
|
borte/delegerer, og full suite fortsatt grønn (baseline 279/4). Samme for A2 — som nå
|
||||||
|
EKSPONERER skrive-primitivene (verifiser at `write_concept_file`/`link_in_index` er
|
||||||
|
importérbare i Claude-repoet, der de i dag mangler).
|
||||||
|
|
||||||
|
**Fase T2:**
|
||||||
|
- [ ] Evaluator (a) deterministisk + reproduserbar: samme bundle → samme score to kjøringer; en
|
||||||
|
bundle med én brutt intern lenke scorer lavere på lenke-integritet enn samme bundle uten.
|
||||||
|
- [ ] Evaluator (b) merket: tilstrekkelighets-output er tydelig stemplet maskin-vurdering/
|
||||||
|
veiledning, adskilt fra (a) i rapporten.
|
||||||
|
- [ ] Fabrikk demo-sti: unzip energi-eksemplet i innboks → kjør fabrikk → resultat-bundle
|
||||||
|
scorer høyt på ALLE deterministiske evaluator-dimensjoner; `grep -RL "generated:"
|
||||||
|
<bundle>/` er tomt (hver fil merket maskingenerert).
|
||||||
|
- [ ] Dom-oversettelse provenance load-bearing: gitt en fri-format dom-fil i innboksen, har den
|
||||||
|
genererte strukturerte dommen et provenance-felt = kildefilnavnet (en stikkprøve kan åpne
|
||||||
|
begge). Detach provenance-feltet → testen RØD.
|
||||||
|
- [ ] Sikkerhetsvask via guard load-bearing: en innboks-fil med kjent injection-payload fanges
|
||||||
|
(fail-secure) FØR den når bundelen; koble fra guard-avhengigheten → payloaden lander i
|
||||||
|
bundelen (testen RØD).
|
||||||
|
- [ ] Ærlighets-grense: optimaliserer-repoenes suiter kjører fortsatt uten nøkkel/nettverk og
|
||||||
|
importerer IKKE fabrikken i kjørestien (`grep -R "import.*factory" src/` i kjørestien tomt).
|
||||||
|
|
||||||
|
## 10. Prompt for å starte programmet (kjør i det NYE toolkit-repoet, ikke her)
|
||||||
|
|
||||||
|
```
|
||||||
|
Les <dette repoets>/docs/plan/2026-07-14-toolkit-repo-brief.md (kopier inn) samt
|
||||||
|
revisjonspakke §0.2/§2 D-G/§3 D-H. Dette er repo-init + PROGRAM-PLANLEGGING for
|
||||||
|
okf-toolkit — det rører IKKE optimaliserer-repoenes sesjonskø.
|
||||||
|
|
||||||
|
1. Verifiser briefens premisser mot ground truth på nytt (§0.2-tallene + at A2 mangler
|
||||||
|
skrive-halvdelen) FØR noe skrives.
|
||||||
|
2. repo-init som eget Forgejo-repo etter guard-malen (pip-pakke, dependencies = [],
|
||||||
|
MIT med mindre operatør avviker, stdlib-only kjerne).
|
||||||
|
3. Lag i plan-modus: (a) målbilde for okf-toolkit (standard-kompatibilitet + utvidelses-
|
||||||
|
policy + de to fasene), (b) gated sesjonsplan der HVER sesjon har mål + verifisering
|
||||||
|
per §9. T1 (modul + formatprøve) FØR T2 (fabrikk + evaluator). Presenter for
|
||||||
|
godkjenning FØR noe committes.
|
||||||
|
4. Avklar de åpne spørsmålene i §8 (navn, lisens, publiseringsrekkefølge) med operatør
|
||||||
|
i klarspråk før repo-init låses.
|
||||||
|
```
|
||||||
Loading…
Add table
Add a link
Reference in a new issue