docs(plan): six objections to the week plan, as a prompt the next session must measure before acting

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

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

@@ -0,0 +1,146 @@
+# 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.