portfolio-optimiser/docs/plan/2026-08-07-planrevisjon-prompt.md

# Prompt: planrevisjon før Go — vurder seks innsigelser, endre planen

> **Til:** en fersk sesjon på **Fable 5 / xhigh**, i `portfolio-optimiser`.
> **Fra:** Opus-5-sesjon 2026-08-07, som gjennomgikk planen på operatørens spørsmål
> «er planen god nok til å bli gjennomført med høy kvalitet til torsdag?».
> **Lim inn alt under streken som første melding.**

---

Du skal **vurdere seks innsigelser mot ukeplanen, avgjøre hver enkelt, og endre planen deretter.**
Du bygger ingen produksjonskode i denne økten. Produktet er dømmekraft + redigerte plandokumenter.

## Rammer som ikke er dine å endre

- **Frist: live demo av alle åtte steg torsdag 13. august. Frys onsdag 12.** Fristen flyttes ikke.
- **O1–O4 og A/B/C står** (`docs/plan/2026-08-06-demo-uke-plan.md` §0). Du gjenåpner dem ikke.
- **Aldri arbeid i et annet repo.** commons er pull-only; `coord-send` er mekanismen.
- **`docs/presentasjon-portfolio-optimiser.html` eies av en annen sesjon.** Rør den aldri,
  `git add -A` aldri.
- **Scope-vakt:** du foreslår planendringer og skriver dem inn i plandokumentene. Du starter ikke
  implementeringen av dem.

## Denne økten kjører uten advisor — derfor denne regelen

En Fable-økt kan ikke bruke advisor. Kompenser i arbeidet: **hvert tall og hvert faktapremiss du
bruker skal produseres av en kommando du faktisk kjører i denne økten.** Skriv kommandoen og
resultatet inn i planen ved siden av påstanden. Du får en liste med belegg under — den er *påstander
fra en annen sesjon*, altså premisser, ikke fakta. **Verifiser hver enkelt selv før du handler på
den.** Én av innsigelsene under er nettopp at planen bygger på en for smalt målt kommando; ikke gjenta
den feilen i din egen revisjon.

## Les først (primærkilder, i denne rekkefølgen)

1. `STATE.md` — «👉 NESTE»-blokka er sannheten om hvor vi står
2. `docs/plan/2026-08-09-egnethetsreview-plan.md` — **hoveddokumentet du skal endre** (§0 to spor,
   §1 funn, §2 P1–P4, §4 belegg, §5 kalender)
3. `docs/plan/2026-08-06-demo-uke-plan.md` — eier kjørestien + de åtte verifiseringskriteriene (§5)
4. `docs/plan/2026-08-09-innholdsgate-og-aerlighet.md` — Spor B / P2

## Kontekst: hva som ER bra i planen (ikke riv det ned)

Målt i dag (2026-08-07): `uv run pytest -q` → **766 passed / 4 skipped på 110 s**. Grunnpremisset
«v1 = den målte kjernen» holder. Planen har konkrete verifiseringskriterier framfor «sjekk at det
virker», en nedgraderingskolonne per post, en beleggstabell, to-spors-delingen, og front-lasting av
alt som ikke krever nytt innhold. Innsigelsene under er justeringer av rekkefølge og ett målefeil-
funn — ikke en underkjenning av planen.

---

## Innsigelse 1 (viktigst) — Funn 1 er målt for smalt, og én følgesetning er feil

**Planens påstand.** §1 Funn 1 + §4 rad 3: «ingen bundle i repoet har `cost-baseline.json`», målt
med `ls shared/examples/bygg-energi-mikro/`. Og §1 linje 78: «reserven (mikro-eksemplet) **kan aldri
få fila**», som er grunnen til at NO-GO-tilfellet trenger sin egen ærlige setning.

**Belegg som motsier den (verifiser selv):**

| Kommando | Resultat |
|---|---|
| `find . -name 'cost-baseline.json' -not -path './.git/*'` | `src/portfolio_optimiser/data/bundles/bygg-energi-baseline-mikro/cost-baseline.json` |
| `cat` på den fila | gyldig S4.0-format: `project_id` + `items{code:{quantity,unit_cost}}` |
| `grep -n BASELINE_BUNDLE tests/test_s40_cost_baseline_loadbearing.py` | `:42` — fixturen er alt i bruk, seks mutasjoner målt røde |
| `sed -n '505,525p' src/portfolio_optimiser/run.py` | `:516` `baseline = okf.load_optional_cost_baseline(bundle_dir)` — bundle-stien er wiret |
| `grep -n 'bundle_dir\|copytree' src/portfolio_optimiser/simulation.py` | `:280` argument, `:316` `shutil.copytree`, `:492` default — bundelen er en parameter, og den kopieres før kjøring |

**Innsigelsen.** Beleggskommandoen så på ÉN katalog under `shared/examples/`. Repoet shipper en
fungerende, format-definerende kostbaseline-bundle, og kjørestien leser den. Den ekte hindringen er
ikke at fila er umulig å skaffe — det er at `shared/` er **pull-only subtree** og at kriterium 8
krever goldenene byte-uendret. Det er en *plasserings*-begrensning, ikke en umulighet: en repo-lokal
demo-bundle, eller et kopier-og-utvid-steg før kjøring, gir en forankret kjøring uten å røre commons.

**Hvorfor det betyr noe for uka.** Slik planen står, møter S4.0-forankringen ekte innhold for
**første gang tirsdag 11.** — to dager før demo, én dag før frys — og planen sier selv at et avvik
over 5 % da feller BÅDE det overdrevne og det korrigerte forslaget på scenen. Ukas største enkeltrisiko
er plassert sist. Den kan flyttes til helgen for lav kostnad.

**Foreslått endring (din avgjørelse).** Nytt punkt i P4-forskuddet (helg): kjør hele demoløpet mot en
lokalt forankret bundle, inkludert 10 %-avviks-prøven som i dag ligger i P3. Da blir tirsdag en
*re-måling mot nytt innhold* i stedet for en førstegangskjøring. Korriger samtidig §1 Funn 1, §1 linje
78 og §4 rad 3 til det som faktisk er målt.

**Vurder mot:** koster dette en ekstra økt vi ikke har? Kolliderer en repo-lokal demo-bundle med
`_default_bundle_dir()`-sømmen (`simulation.py:48-51`, `PORTFOLIO_SHARED_ROOT`) eller med kriterium 6
(byte-identisk stdout)? Er en syntetisk forankring godt nok bevis, eller flytter den bare
usikkerheten? Avvis innsigelsen hvis svaret er nei — men avvis den med en kommando.

## Innsigelse 2 — Rekkefølgedefekt: stderr-demping vs. stderr-pinning

P4 pkt. 2 pinner de fire kjente stderr-linjene som fasit i **helgen**. §0 Spor 2 lister demping av de
samme fire linjene som «valgfritt før frys» — altså **onsdag**. Demping etter pinning ugyldiggjør
pinnet på frysedagen. **Foreslått endring:** ta demping-beslutningen i helgen, før pinningen, og skriv
den inn som en beslutning (ja/nei), ikke som et valgfritt tillegg sent i uka.

## Innsigelse 3 — `[project.scripts]` ligger på frysedagen, men endrer install-flaten

§0 S1.c legger `[project.scripts]` inn onsdag kveld, etter at P4 pkt. 1 (fresh-clone-kriteriet) er
målt. `grep -n scripts pyproject.toml` → 0 treff i dag. En ny entry point endrer det `uv sync` /
install produserer, så «last ned → kjør»-beviset må strengt tatt måles på nytt etter frysen — som er
selvmotsigende. **Foreslått endring:** flytt `[project.scripts]` til P4-forskuddet i helgen, slik at
onsdag kun er versjonssynk (fire steder) + CHANGELOG + tag.

## Innsigelse 4 — Tirsdagens subtree-pull mangler avbruddssti

Kriterium 8 sjekker at goldenene er uendret etter pull, men ingen sted står det hva som skjer hvis
pullen gjør suiten rød dagen før frys. **Foreslått endring:** skriv inn pre-pull-hash-notering, en
eksplisitt revert-regel, og et klokkeslett på tirsdag der NO-GO utløses uten videre diskusjon.

## Innsigelse 5 — Ingen demo-runbook er allokert

Det som skal SIES torsdag ligger spredt over fire steder: demo-uke-plan §1 (tre ærlighets-punkter),
innholdsgate-plan §5, P4 pkt. 4 (to ferdigskrevne setninger), og §0 Spor 2 (muntlig mandat-setning).
Ingen post i planen produserer ÉN side operatøren kan følge på scenen — kjøresekvens, hva som sies
hvor, og hva som gjøres hvis kjøringen feiler live. Golden-transkriptet fra P4 pkt. 3 er den naturlige
aborten, men det står ikke som abortsti noe sted. **Foreslått endring:** egen post, ~0,25 økt,
produseres VED frysen onsdag så den matcher frosset output.

## Innsigelse 6 (lav) — datohygiene svekker beleggstabellen

Plandokumentet heter `2026-08-09-…`, STATE-loggen daterer økter til 2026-08-09, og §4 sier «målt
2026-08-09 på HEAD `c96ef90`» — men `git log -6 --format='%h %ad' --date=short` gir **2026-08-06** for
`c96ef90`, og i dag er **2026-08-07**. Datoene ligger 2–3 dager fram i tid. Ikke en økt verdt, men en
beleggstabell mister etterprøvbarhet når datoen ikke stemmer med commit-datoen. **Foreslått endring:**
korriger datoene i §4 og i STATE-loggen; la filnavnet stå (omdøping koster lenker) med en note.

---

## Det du skal levere

1. **En avgjørelse per innsigelse: TAS INN / AVVISES / ENDRES TIL <x>** — hver med kommandoen du
   kjørte for å avgjøre den. Avvisning er et fullt legitimt utfall; en avvisning uten måling er ikke.
2. **`docs/plan/2026-08-09-egnethetsreview-plan.md` redigert** — §1/§4 korrigert der målingen krever
   det, §2 P3/P4 og §5-kalenderen omorganisert etter avgjørelsene, §0-økt-regnskapet oppdatert hvis
   summen endres.
3. **Et oppdatert økt-regnskap mot kalenderen fre 7. – ons 12.** Si eksplisitt om totalen fortsatt går
   opp, og hva som er første kutt hvis den ikke gjør det (nedgraderingskolonnen er alt skrevet — bruk
   den, ikke finn opp en ny).
4. **`STATE.md`s «👉 NESTE»-blokk overskrevet** med den reviderte første handlingen for i dag (fredag),
   inkludert board-linja og route-linja.
5. **Commit** med `docs(plan):`-prefiks. Ikke `feat:` (den krever staget README + CLAUDE.md).
   `git add` i eget Bash-kall, aldri sammen med `git commit`. Eksplisitt filliste — aldri `-A`.

## Kriteriet på at denne økten lyktes

Planen som ligger der etterpå har **ukas største måletekniske risiko tidligst, ikke sist**, og hver
påstand i §4 er produsert av en kommando som er kjørt i dag. Hvis du konkluderer med at planen skal
stå uendret, er det et gyldig utfall — men da skal §4 bære målingene som viser hvorfor.