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 — 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.mds «👉 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.