portfolio-optimiser/docs/plan/2026-08-09-egnethetsreview-plan.md

Egnethetsreview → plan — funnene gjort varige, én økt av gangen

Hva dette er. Fable-reviewen (2026-08-09, kjørt fra 2026-08-09-fable-egnethetsreview-prompt.md) leverte funnene sine i et chat-transkript som forsvinner. Dette dokumentet er den varige formen: hvert funn i klarspråk, med belegget som produserte det, rangert som en plan STATE.md peker inn i økt for økt. Chatten kan glemmes — alt som trengs står her.

Slik brukes den: STATE.mds «👉 NESTE»-blokk peker alltid på det ØVERSTE ulukkede P-punktet her. En økt lukker et punkt → setter ✔ med commit-hash HER → overskriver STATE.md → neste økt leser videre. Demo-uke-planen (2026-08-06-demo-uke-plan.md) og innholdsgate-planen (2026-08-09-innholdsgate-og-aerlighet.md) BESTÅR uendret — denne planen føyer review-funnene inn i samme løp og flytter ingenting som er besluttet (O1–O4 står).

Voyage: småjobber (≤1 økt, kjent sti) kjøres direkte med /tdd-disiplin. Full Voyage-syklus (/trekbrief → /trekplan → /trekexecute → /trekreview) brukes der et punkt er merket [Voyage] — punktene med reell design-usikkerhet eller ≥2 økters bygging.

Revidert 2026-08-07 (planrevisjonen — seks innsigelser målt og avgjort, se §6): ukas største måletekniske risiko (S4.0-forankringen) er flyttet fra tirsdag til helgen, stderr-beslutningen tas FØR pinningen, [project.scripts] er flyttet ut av frysedagen, tirsdag har fått abortsti, og demoen har fått en runbook-post (P4.5). Datonote (I6): filnavnets 2026-08-09 beholdes (omdøping koster lenker), men øktene dokumentet daterer til 08-08/08-09 ble committet 2026-08-06 (målt 08-07: git show -s --format='%h %ad' --date=short c96ef90 0eb0f3d 295e966 688ee24 e93e921 d6f3359 → alle 2026-08-06).

0. TO SPOR (operatørbeslutning 2026-08-09 — overordner rekkefølgen under)

Operatøren har delt uka i to spor. P-punktene under består, men hører nå hjemme slik:

SPOR 1 — KOMPLETT VERSJON 1, klar til torsdag 13. (inkludert andre repo)

v1 = den målte kjernen (alle åtte steg wiret, 42 load-bearing-testfiler, 766/770 grønn — inventaret i 2026-08-06-v1-inventory.local.md) + to lukkinger + release-kuttet:

Post	Innhold	Kost	Nedgradering hvis tid/kvote ryker
S1.a = P1	Steg 7-innboksen inn i demoløpet	1 økt	ærlig etikett (0,1 økt)
S1.b = P2	Innholdsgaten (Spor B) ✔ (2026-08-09, c255662) — alle seks kriterier grønne; 801 → 810 tester. JA-varianten i ærlighets-teksten gjelder dermed.	1–2 økter	NEI-varianten i ærlighets-teksten (ferdigskrevet) — ikke i bruk
S1.c (ny)	Release-kuttet: versjon 1.0.0 synket FIRE steder (pyproject/__init__/uv.lock/test_smoke) + CHANGELOG ([Unreleased] → 1.0.0; Steg-5-API-endringen står alt der) + tag v1.0.0 ETTER grønn generalprøve. ⚠️ «PÅ BEGGE REMOTES» ER FELT (2026-08-10) — TAGGEN GÅR TIL origin ALENE. open/-speilet mangler 26 commits (53 filer / 6087 innsettelser, målt: open/main = 520e741 = v0.1.0), så en tag DER er ikke en tag-operasjon men en offentlig publisering — og eksponerings-gjennomgangen viste at den krever seks plandokument-beslutninger: 2026-08-06-intensjons-qa + 2026-08-06-demo-uke-plan (åpen sak, stående anbefaling NEI) pluss FIRE aldri vurdert (2026-08-07-planrevisjon-prompt, 2026-08-09-egnethetsreview-plan, 2026-08-09-fable-egnethetsreview-prompt, 2026-08-09-innholdsgate-og-aerlighet). Seks publiseringsbeslutninger på frysedagen er nøyaktig det denne planen forbyr. Speilet synkes i P5-vinduet, med READMEen som forklarer commitene — kode publisert foran sin README leser som forlatt. Onsdag er dermed ETT trekk: CHANGELOG-stempel + git tag -a v1.0.0 -m "<ordrett fra runbookens §5 punkt 10>" + git push origin v1.0.0. -m er PÅKREVD, ikke pynt — uten den er kommandoen ikke kjørbar (målt: GIT_EDITOR=true ⇒ fatal: no tag message?, exit 128, ingen tag; uten GIT_EDITOR åpner den en editor). Taggen er ANNOTERT (tir 11. økt 14, målt): repoets eneste andre tag er det (git cat-file -t v0.1.0 → tag, melding v0.1.0 — first tagged release), så en lettvekts v1.0.0 ville gjort hovedreleasen til den eneste taggen uten forfatter, dato eller melding. Meldingsteksten står literalt ÉTT sted — runbookens §5 punkt 10 — så den verken improviseres på enveis-dagen eller får en andre kopi å drifte fra. Formen er tørrkjørt i eget engangs-repo; ingen av de tre bekreftelses-kommandoene i punkt 11 endrer forventning av -a. ([project.scripts] er flyttet videre til P4 pkt. 5 i HELGEN (I3): en ny entry point endrer install-flaten, så den må ligge FØR fresh-clone-målingen — aldri på frysedagen.) SYNK + CHANGELOG ✔ (2026-08-10, a41272d) — forskuttert fra ons kveld; TAGGEN gjenstår, frys-gatet. Overskriften står bevisst på [Unreleased]: STATE hjemler innholdet nå, ikke release-stempelet, og et forhåndsdatert [1.0.0] - <dato> ville påstått en hendelse som ikke har skjedd. Ingen test leser CHANGELOG (målt), så paret er ikke maskin-gatet. Tag-dagen = ETT trekk: døp om overskriften, stemple dato, tagge. «ETT trekk» er MÅLT (2026-08-10), ikke antatt: grep -c '^## \[Unreleased\]$' CHANGELOG.md → 1 (verbatim og unik; kun to ## -overskrifter, og ## [0.1.0] - 2026-08-06 er historikk), og ingen link-refs nederst (grep -nE '^\[.+\]:' → tomt) som måtte følges med. Bar en dato, eller stod overskriften to steder, ville «det ene trekket» blitt improvisasjon på frysedagen. Re-locken ble gatet, ikke antatt: uv lock kjørt EKSPLISITT og diffet FØR noen test, ellers ville neste uv run re-locket usynlig mot en range-dep mens de to ExperimentalWarning-linjene er byte-pinnet i stderr-goldenen. Diffen = kun versjonslinja. Målt at fire ER alle: ingen README-badge; CHANGELOG-ens [0.1.0] er historikk.	0,5–0,75 økt (ons kveld)	tag fredag i stedet — aldri tag før grønn generalprøve

Andre repo — hva som faktisk MÅ gjøres der (målt, ikke antatt):

• commons: energieksemplet MED cost-baseline.json — ALLEREDE bestilt (frist tir 11., coord 20260806T112037Z…); GO/NO-GO tirsdag står. Reserven (mikro) gjør at v1 ALDRI blokkeres av commons: rammeverket er v1, innholdet er data.
• llm-ingestion-okf: ingenting — pinnet v0.3.2 gjennom v1 (målt at den holder).
• guard-repoet: ingenting — v0.3.4 finnes, stdlib-only; wiringen skjer HER (S1.b).
• po-claude: PARKERT (ramme B) — v1 er MAF-siden alene, og det SIES i release-notatet.

→ Ingen ny coord-melding trengs. Alt andre-repo-arbeid er enten bestilt eller ikke nødvendig.

Flagget konflikt (operatøren eier den): O4 sier README-løftet kommer ETTER demoen (fre–lør). Anbefaling: tag v1.0.0 onsdag med nøktern README-status; nivå-2-påstanden inn i README fre/lør som besluttet. Beviset først, påstanden etterpå — det gjelder også taggen.

EKSPLISITT UTE av v1 (sies i release-notatet, ikke i en fotnote): CLI-porteføljetak (P6), commons-amendmentene (P7), metode-skillen (P8), bestiller-flaten (åpen beslutning i STATE), bundle-fabrikken (O1), søsken-repoet (parkert), okf v0.4.0+.

SPOR 2 — KOMPLETT OG OVERBEVISENDE DEMO av alle åtte steg

= P3 (GO-dag + re-måling av kostnads-sjekken) + P4 (forankret prøvekjøring + fresh-clone-/stderr-/golden-kriterier + to ærlighets-setninger) + P4.5 (demo-runbook — SKREVET man 10., FYLLES UT ved frysen; se P4.5-blokka) + generalprøven + én muntlig mandat-setning (bestillingsflyten er svaret på «kan vi styre hva som analyseres?» — docs/bestille-en-kjoring.md). ✔ SETNINGEN ER SKREVET (man 10. økt 7, c7a57d8) — den sto her som en plassholder for en beslutning, ikke som en beslutning: ingen steder fantes ordlyden. Nå formulert i runbookens §2, forankret i bestillingsdokumentet: bestillingen styrer hva som vurderes, aldri hva som godkjennes — validatoren gjelder uendret, og avvisningen kommer tilbake med begrunnelsen. Stderr-dempingen er BESLUTTET (I2, 2026-08-07): JA — utføres i HELGEN som del av P4-forskuddet, FØR stderr-pinningen (demping etter pinning ville ugyldiggjort fasiten på frysedagen). Målt 08-07: stderr er SEKS linjer — de fire støylinjene (to ExperimentalWarning + to «forcing completion») pluss blanklinje + arbeidskopi:-linja, som er bevisst ikke-deterministisk (simulation.py:531-534) og IKKE skal dempes. Dempingen rører ikke stdout (kriterium 6). Faller den: NEI-fallback = pin de fire linjene som fasit, med arbeidskopi:-linja normalisert på prefiks.

Økt-regnskap for uka i dette repoet (revidert 08-07): S1.a (1) + S1.b (1–2) + S1.c (0,5–0,75) + P3 (0,25) + P4/generalprøve — utvidet med forankret prøvekjøring, 10 %-prøven, [project.scripts] og dempingen (0,75–1,25) + P4.5 runbook (0,25) ≈ 3,75–5,5 økter på seks dager (fre 7.–ons 12., ny full ukeskvote). Totalen går opp med slakk i normal drift (1–2 økter/dag). Første kutt hvis den ikke gjør det: S1.b → NEI-varianten i ærlighets-teksten (nedgraderingskolonnen — ferdigskrevet, frigjør 1–2 økter, og Spor B er ikke en frys-betingelse). Deretter gjelder nedgraderingskolonnen rad for rad — v1 forblir ærlig komplett på hvert nivå, den blir aldri stille ufullstendig.

1. Funnene i klarspråk

Reviewen fant ingen brann i koden: suiten er grønn (766 passed / 4 skipped), demo-outputen er byte-identisk over to kjøringer, og alle åtte steg har sin merkede linje. Det den fant, er fire steder der demoen lover mer enn den viser, og noen hull i sikkerhetsnettet rundt torsdag.

Funn 1 — kostnads-sjekken har aldri kjørt på ekte innhold. Validatoren KAN avstemme et forslag mot prosjektets faktiske kostnadstall (S4.0), men sjekken aktiveres bare når kunnskapsbasen shipper cost-baseline.json — og ingen demo-bundle under shared/examples/ har den fila (målt, §4 rad 3). (Korrigert 08-07, I1: den opprinnelige formuleringen «ingen bundle i repoet» var målt for smalt — repoet shipper en fungerende, format-definerende baseline-bundle i src/portfolio_optimiser/data/bundles/bygg-energi-baseline-mikro/, i bruk av S4.0-testens målte mutasjoner, og kjørestien leser fila: run.py:516.) I dagens demo regner validatoren derfor kun på tall forslaget selv oppgir. Bestillingen til commons krever fila (bra) — men slik planen sto, ville sjekken møtt ekte innhold FØRSTE gang på leveransedagen; avviker manus-tallene mer enn 5 % fra de leverte kostnadstallene, avvises BÅDE det overdrevne og det korrigerte forslaget på scenen. Derfor er forankringen flyttet til helgen (P4 pkt. 0): reserven kan ikke få fila I shared/ (pull-only subtree + kriterium 8 krever goldenene byte-uendret), men det er en plasserings-begrensning, ikke en umulighet — demoen kjører uansett på en KOPI av bundelen (simulation.py:316), så en repo-lokal kopier-og-utvid-variant gir en forankret kjøring uten å røre commons. NO-GO-setningen i P4 pkt. 4 er omskrevet tilsvarende.

Funn 2 — demoen sier «fil-innboks for ekspertdommer», men bruker den ikke. Steg 7-linja i demoen sier «lang fil-løkke». I virkeligheten leveres dommen som et funksjonsargument — simulate_learning_loop kaller run_project uten verdict_dir (§4 rad 4). Fil-innboksen finnes og er testet (test_step7_async_loop_loadbearing.py), men demoen kjører den ikke. Dette er samme klasse som Steg 5 var før 7. august: et steg som omtales er ikke vist.

Funn 3 — «last ned og kjør» er aldri testet fra en fersk nedlasting. Ingen av de åtte demo-kriteriene kjører fra en ren klone. uv.lock finnes, så beviset er én kommandosekvens — og den fanger miljøavhengigheter (PORTFOLIO_SHARED_ROOT re-peker kunnskapsbasen!), utrackede filer og lokal .venv-drift.

Funn 4 — små presisjonshull i det som sies og vises. Kjøring A kalles «fersk kunnskapsbase, ingen tidligere dommer», men bundelen shipper ett dom-frø, og Kjøring B viser «2 dommer» der bare én kom fra sløyfa — én muntlig setning retter det. Stderr-støyen (to warnings + to «forcing completion») er det første publikum ser.

Etter demoen (feature-settet):

• Funn 5: porteføljekjøring fra kommandolinja har ikke noe samlet token-tak — taket finnes i biblioteket (PortfolioMeter, seks målte mutasjoner), men main() kobler det aldri på; koden sier det selv (§4 rad 6).
• Funn 6: spec-gjelden mot commons/søskenet vokser — seks lokale semantikk-beslutninger er uspeilet (D7-speiling ÅPEN i CLAUDE.md), og «rettferdig sammenligning» (A6) blir mindre sann for hver av dem.
• Funn 7: «metoden som Agent Skill» er en CLAUDE.md-konvensjon uten realisering — kun ekspert-personaen finnes (§4 rad 5).
• Funn 8: [project.scripts] mangler (release-hygiene, målbilde §11 pkt. 7).
• Null-funn: bytte av orkestrering (Sequential/Handoff/graf-laget/checkpointing) skal IKKE gjøres — målt: debatten er i praksis en fast sekvens og Group Chat beholdes av byttekost-grunner, gevinsten er kosmetisk, kostnaden er re-verifisering av hele offline-beviskjeden (§4 rad 7–8).

2. Plan FØR demoen (P1–P4, i utførelsesrekkefølge)

P1 — Steg 7-innboksen kobles på i demoen ✔ (2026-08-09)

[1 økt · Opus 5/high · TDD direkte · MÅ lande før onsdags-frysen] Rute persona-dommen gjennom en faktisk verdict_dir-katalog i simulate_learning_loop — sømmene finnes allerede (run_project(verdict_dir=…) + write_verdict er offentlig primitiv). Ny load-bearing-test: detach innboks-lesingen → markør-/Steg 7-linja endres → RØD. Kriterium 6 (byte-identisk stdout) måles på nytt etterpå. Faller den på tid: minimumsvarianten = ærlig etikett i _run_trace_lines («dom levert direkte her; fil-innboksen er samme søm, bevist i test») + én muntlig setning. 0,1 økt.

UTFØRT — men IKKE slik punktet var formulert, og forskjellen er bærende. Å rute persona-dommen gjennom innboksen ville gitt ÉN markør på to veier: Steg 7 (innboks) og Steg 8 (promotering) ender begge i Run B's hypotese-prompt, så hver av dem kunne båret markøren alene — og test_simulation_loadbearing.pys promoterings-assert ville stått GRØNN med promoteringen detached. Punktet ville altså gjort en eksisterende load-bearing test vakuøs for å lukke seg selv. Utført i stedet: en ANDRE dom, med sin egen markør (realiseringsgrad=0.66), skrives som fil med write_verdict MELLOM kjøringene, og Run B får verdict_dir=. simulate_learning_loop raiser ValueError hvis de to markørene er like. 766 → 769 grønne (773 kollektert).

• Kriterium 6 re-målt: stdout byte-identisk over to kjøringer (diff tomt). Stderr uendret 6 linjer. (Lærdom: første stderr-måling ga 62 linjer — 2>&1 >/dev/null under zsh MULTIOS blander stdout inn. Formen som holder er >/dev/null 2>fil. Målefeilen, ikke koden.)
• Mutasjoner MÅLT mot hele suiten (~110 s hver), fire røde + grønn kontroll: detach verdict_dir= (2 røde) · la Run B lese en TOM mappe mens fila fortsatt skrives (2 røde) · markør = realization_rate: 0.82, målt til stede i dom-frøet (1 rød) · markør = energy performance gap, målt til stede i en navigert konseptfil (1 rød) · godartet omdøping av innboks-katalogen (grønn kontroll).
• Ærlighets-grense funnet UNDER målingen: de to siste mutasjonene felte kausalitets-asserten (markøren finnes i bundelen), IKKE Run A-kontrollen — fordi genererings-prompten bærer Project: {id} - {name} + debatt-outputen, ikke bundle-konteksten. Run A-kontrollen kan altså ikke alene fange en bundle-tilstedeværende markør; det er kausalitets-asserten som lukker det hullet. Paret holder, men det er verdt å vite hvilken av dem som faktisk bærer hvilken egenskap.
• Lærdom, samme klasse som 08-06: første markør-mutasjon satte realiseringsgrad=0.82 og gikk GRØNN — bundelen bærer realization_rate: 0.82, ikke den strengen. Mutasjonen endret ingen betingelse og beviste ingenting. En mutasjon må måles mot hva fila FAKTISK inneholder, ikke mot hva STATE kaller verdien.

P2 — Spor B: innholdsgaten ✔ (2026-08-09, c255662)

[1–2 økter · Opus 5/high · TDD direkte · følger innholdsgate-planen §3–§4 uendret] Reviewens skjerpelse, ellers ingen endring: §4-beslutning 2 (avvisning per dokument eller per bundle?) tas FØR bygging, og innholdsgate-planens kriterium 5 (byte-uendret demo-stdout) måles ETTER wiring. Målt frys-sikker: verken run.py eller simulation.py importerer ingest.

P3 — GO/NO-GO + kostnads-sjekken (nå RE-måling, med abortsti) ✔ (2026-08-09, 02ddc67) — GO

UTFØRT SØNDAG 09.08, ikke tirsdag 11. Rekkefølge-avviket er uttalt i STATE: commons leverte to døgn før fristen, og et golden-transkript (P4 pkt. 3) pinnet mot RESERVEN ville blitt ugyldig i det øyeblikk main() pekte på levert bundle. Å pulle først gjør pkt. 3 én gang i stedet for to.

Abortstien ble fulgt i rekkefølge. Pre-pull-hash 7acd331 notert FØR pull (verifisert med git rev-parse, ikke lest fra STATE). Pull av 002f000+27cdce9. Kriterium 8 grønt, målt to uavhengige veier: git diff --stat på begge nav-golden-katalogene → tomt, OG shasum -c mot et pre-pull-manifest → 15/15 OK. Full suite etter pull: 785 passed / 4 skipped — identisk med før. Ingen reset, ingen NO-GO. Pullen var ren tilføyelse pluss ÉN endret fil (ingest-spec.md, se åpent punkt under).

(b) Retningen er snudd. _CANDIDATES har nå en VEGLYS-FV-SOER-oppføring hvis kostlinjer er skrevet FRA shared/examples/veglys-fv-soer/cost-baseline.json; baseline_from_scripted_candidate brukes IKKE på denne stien (main() leser levert fil via okf.load_optional_cost_baseline). Det korrigerte svaret ER den leverte IR-projeksjonen ordrett — inkludert assumptions-bandet, så Monte Carlo-en er ekte og ikke degenerert.

(4) Overdrivelsen: 2 100 000. Målt fraværende fra bundelen (også som 2 100 000/2.100.000), og over BEGGE terskler — målt P90 er 1 769 915 (commons' anslag var ~1 770 000; vår seedede MC er fasit, og de traff). 600 000/900 000 ville klarert gaten.

(a) Demo-kriterium 1+2 mot NY bundle: åtte steg-linjer står; hypotese #1 REJECTED (2100000 exceeds P90 feasible 1769915) og den korrigerte VALIDATED (445500) — samme kandidat, og det er P90-stagen som feller, ikke stage 0. Begge læringsveiene lukkes også på levert innhold (Steg 8-markøren og Steg 7-innboksmarkøren når begge Kjøring B's prompt; Kjøring A har ingen).

(c) 10 %-prøven mot levert innhold er test_a_deviating_delivered_baseline_forkaster_the_run_before_the_solver: levert baseline avviket 10 % → FORKASTET i stage 0 med avstemmings-grunnen, ikke P90-grunnen.

Måling felte en defekt reserven skjulte: :g slår over i eksponentform ved 7. signifikante siffer, så den leverte baselinen printet 4.38615e+06. Reservens 300000 har seks siffer og nådde aldri overgangen — syntetiske tall skjulte den, levert innhold avslørte den på FØRSTE kjøring. _num erstatter :g begge steder.

Load-bearing MÅLT mot hele suiten, fem mutasjoner alle røde + grønn kontroll: detach main-wiringen · reverter _num til :g · drift registeret ETT siffer (4386151 — innenfor 5 %-toleransen, og fanget av ingenting i 792 tester bortsett fra den nye) · sett flip_key til et token som finnes i bundelen · detach forankringen på bundle-stien. 785 → 793.

Abortstien står fortsatt: reserven har sin registeroppføring, og materialize_anchored_bundle er urørt — NO-GO er tre linjer i main().

Planteksten slik den sto før utførelse

**[0,25 økt, del av tirsdagsøkta · Opus 5/medium]** Som demo-uke-planen — men etter planrevisjonen 08-07 (I1) er dette en **re-måling mot nytt innhold, ikke førstegangskjøring**: S4.0-forankringen og 10 %-avviks-prøven kjøres første gang i HELGEN mot den lokalt forankrede reserven (P4 pkt. 0). Tirsdag: (a) kjør demo-kriterium 1+2 (åtte steg-linjer; REJECTED- og VALIDATED-linje for samme kandidat) mot den NYE bundelen; (b) skriv manus-registerets tall FRA den leverte `cost-baseline.json`, aldri ved siden av den; (c) gjenta 10 %-prøven mot levert innhold (mekanismen er alt bevist — dette måler INNHOLDET): bevisst avvik → FORKASTET; korrigert → FORESLÅTT. **Abortsti (I4, ufravikelig rekkefølge) — ⚠️ HISTORISK per man 10. økt 6: BEGGE pullene er landet (innholdet søn 09., personaen man 10.), ingen NO-GO utløst, og 18:00-fristen under er utløpt i betydningen «ikke lenger noe å rekke». Regelen står som mønster, ikke som en levende instruks. Én måling er verdt å ta med videre: `git reset --hard` BLOKKERES av hooken — `--keep` slipper:** (1) FØR pull: noter `git rev-parse HEAD` i STATE; (2) pull → kriterium 8 (`git diff --stat` på goldens → tomt) + full suite; (3) rødt utfall → `git reset --hard ` (squash-pullen er lokale commits uten push — resetten fjerner dem helt) og NO-GO er UTLØST — **senest kl. 18:00 tirsdag, uten videre diskusjon**: reserven ER demoinnholdet (den forankrede varianten fra helgen), ærlighets-setningen per P4 pkt. 4. NO-GO er et planlagt utfall, ikke en krise — generalprøve nr. 0 mandag har allerede verifisert det.

P4 — Forankret prøvekjøring + fire kriterier + to setninger ✔ (2026-08-10, d306929)

[0,75–1,25 økt · Opus 5/low–medium · alt under bygges/måles mot mikro-reserven i helgen — se §5] LUKKET man 10. (økt 5). Punktene 0–5 falt 08-09; generalprøve nr. 0 (08-10) re-målte alt mot levert innhold — unntatt pkt. 1 (fersk klon), som ikke inngår i prøven (den måler arbeidskopien). Pkt. 1 var derfor målt på ab7f45a, elleve commits tilbake, og re-målingen ble kjørt 08-10 på c9787cf — se UTFØRT-tillegget under pkt. 1. Onsdagens rad sa «P4 re-målt mot valgt innhold» uten å si hva det var; det var dette, og det er gjort. Frysesekvensen starter dermed på generalprøve ×2. 0. Forankret prøvekjøring ✔ (2026-08-09) — se UTFØRT-blokka under punkt 5. (NY 08-07, I1 — ukas største måletekniske risiko, nå TIDLIGST): lag en repo-lokal kopier-og-utvid-bundle — mikro-reservens innhold + cost-baseline.json i S4.0-formatet fixturen definerer (project_id + items{code:{quantity,unit_cost}}), med baseline-tall avledet FRA manus-registerets tall (samme disiplin som P3 b, speilvendt). Kjør HELE demoløpet mot den: simulate_learning_loop tar bundle_dir som argument og kopierer den (simulation.py:280/:316), og run.py:516 leser fila. Inkluder 10 %-avviks-prøven (flyttet hit fra P3): bevisst avvik → FORKASTET i stage 0; korrigert → FORESLÅTT. Ligger utenfor shared/ → kriterium 8 urørt; kriterium 6 er selv-identitet og påvirkes ikke. Ved NO-GO tirsdag kjører demoen denne varianten (call-site-valg i main() — samme søm GO-utfallet uansett bruker). Faller den: fallback = uforankret reserve + den gamle NO-GO-setningen — ingenting tapt mot planen slik den sto før revisjonen.

1. Fresh-clone-kriterium ✔ (2026-08-09, ab7f45a) — se UTFØRT-blokka under punkt 5.
2. Stderr: FØRST beslutningen, SÅ pinningen (I2) ✔ (2026-08-09, ab7f45a) — beslutningen er tatt og målt; se UTFØRT-blokka under punkt 5. Konsekvens for pinningen (pkt. 3): fasiten kan IKKE være literal — de to gjenstående ExperimentalWarning-linjene bærer en absolutt sti inn i .venv/…/site-packages, som er ulik i fersk klon og arbeidskopi (målt). Normaliser på BEGGE: site-packages-stien OG po-sim--suffikset. Pinnet stderr er da fire linjer, ikke to.
3. Golden-transkript ✔ (2026-08-09) — se UTFØRT-blokka under punkt 4. (Planteksten:) sjekk inn demo-outputen som fasit-fil og diff mot den — selvidentitet (kriterium 6) fanger ikke-determinisme, men ikke regresjon mellom onsdag og torsdag. Transkriptet er også demoens abortsti (gjort eksplisitt i P4.5).
4. To ferdigskrevne setninger ✔ (2026-08-09) inn i ærlighets-teksten (mønsteret fra innholdsgate-planen §5). NO-GO-varianten er OMSKREVET etter I1: «kostnads-forankringen er aktiv også i reserve-eksemplet, men kostnadstallene der er syntetiske — avledet av manuset, ikke levert av et fagmiljø» (fallback hvis pkt. 0 faller: den gamle setningen «kostnads-forankringen er ikke aktiv i reserve-eksemplet»). Frø-setningen står: «én av de to tidligere dommene i Kjøring B fulgte med eksempelet — den andre er den demoen lærte».
5. [project.scripts] (flyttet HIT fra S1.c, I3) ✔ (2026-08-09, ab7f45a) — se UTFØRT-blokka rett under.

UTFØRT — punkt 3 og 4 (2026-08-09). 793 → 801 passed / 4 skipped. Punktene ble gjort i ÉN økt og i denne rekkefølgen fordi pkt. 4 endrer stdout: en fasit pinnet før den ville vært foreldet i samme økt. Testene ble skrevet FØR begge (målt rød: pkt. 3 på manglende fasit-fil, pkt. 4 på manglende _verdict_origin_line), og fasiten ble generert til slutt — ETTER at P3-kriteriene var re-verifisert mot den nye outputen (åtte steg-linjer; REJECTED på P90-stagen og VALIDATED 445500 for samme kandidat; begge markører False i Kjøring A og True i B; kostbaselinen erklært).

Punkt 3: tests/golden/demo-transcript.stdout er ORDRETT (ingen normalisering, ingen toleranse) — det gjør fila brukbar som abortsti, siden den ER det operatøren ville sett. …​.stderr normaliserer nøyaktig de to spannene som ble målt miljø-avhengige: site-packages-prefikset og temp-katalogen bak (arbeidskopi: …). po-sim--prefikset holdes SYNLIG — det tilhører programmet, ikke miljøet — mens TMPDIR-rota og suffikset maskeres. Pinnet stderr = fire linjer, som pkt. 2 forutsa. Bredden på maskeringen er selv under test: test_normalisation_does_not_mask_a_new_warning mater en syntetisk EKSTRA linje gjennom samme normaliserer og krever at den slutter å matche.

Punkt 4 — den forhåndsskrevne frø-setningen var FEIL, og målingen fanget det. Planen sa «én av de to tidligere dommene i Kjøring B fulgte med eksempelet». Målt mot levert VEGLYS-bundle henter Kjøring B tre: den frøsatte (verdict-veglys-fro.md), Steg-8-promoteringen og Steg-7-innboksen — altså én fulgte med, to er demoens egne, én per tidsskala. Setningen ville vært en falsk påstand sagt på scenen om et tall som står printet linja over. Splitten er derfor avledet (_verdict_origin_line), ikke skrevet ned: en håndskrevet «én av tre» er den andre kopien som drifter (samme regel som punkt 0), og ville blitt sagt uendret etter at en framtidig bundle shipper en andre frøsatt dom. GO-varianten av provenans-setningen sto allerede live som _VEGLYS_PROVENANCE siden P3; den var IKKE positivt asserted noe sted (anker-testen utelukker bare reservens setning), så den er nå pinnet mot fasiten.

Load-bearing MÅLT mot HELE suiten (~123 s hver), fem mutasjoner alle røde + grønn kontroll: ett byte i en stdout-linje (FORSTÅ→FORSTA) · detach rund-taks-dempingen i main() · over-normaliser stderr (drop advarsels-linjene) med fasiten regenerert under den — begge likhets-testene forble GRØNNE, kun kontrollen felte den, som er hele grunnen til at kontrollen finnes · literal splitt i stedet for avledet · detach frø-setningens print. To målinger er verdt å merke: byte-mutasjonen og detach-mutasjonen ble fanget av kun golden-testen — 800 andre tester merket ingenting, som er nøyaktig gapet kriterium 6 ikke dekker; og den literale splitten ble fanget av kun skille-testen (golden-testen forble grønn, siden literalen printer identisk tekst for den leverte bundelen).

UTFØRT — punkt 5, 2 og 1 (2026-08-09, ab7f45a). 775 → 785 passed / 4 skipped.

Punkt 5: to konsoll-kommandoer — portfolio-optimiser (run:main) og portfolio-optimiser-demo (simulation:main). Bevisst to av fem main(): costsim/hitl/preflight beholder -m-formen; hvert navn her er et navn frysen må bære. Testen leser den INSTALLERTE distribusjonens metadata, ikke TOML-en — en [project.scripts]-linje som aldri er uv sync-et er en påstand, ikke en kommando. Målt: stdout er byte-identisk mellom uv run portfolio-optimiser-demo og uv run python -m portfolio_optimiser.simulation.

Punkt 2 — den åpne beslutningen, avgjort ved måling: rund-taks-linjene dempes, de to ExperimentalWarning-linjene gjør det ikke. Loggeren er lest ut av MAFs kilde (logger.warning i _base_group_chat_orchestrator), ikke gjettet; filteret er nøklet på MELDINGEN og installeres i main(), aldri ved import. Hvorfor de to andre ikke dempes: de fyrer mens portfolio_optimiser/__init__.py importerer run → agent_framework — alltid FØR simulation sin egen importblokk, under BEGGE kjøreformer. Å dempe dem ville krevd et warnings-filter inne i bibliotekpakken, altså at rammeverket bestemmer hva MAF får si til enhver konsument. En wrapper bak konsoll-kommandoen ble avvist av en andre grunn: de to kjøreformene ville da skrevet ULIK stderr, og en byte-fasit ville pinnet kommandoen i stedet for programmet. stderr 6 → 4 linjer. Første implementasjon ble FJERNET etter måling: en scoped mute rundt simulations egen agent_framework-import kan aldri fyre (pakken har allerede importert den) — en grønn-men-død søm.

Punkt 1 — fresh-clone, målt mot ab7f45a: klon fra origin → uv sync → uv run portfolio-optimiser-demo. stdout byte-identisk med arbeidskopien; stderr identisk normalisert på site-packages-sti + po-sim--suffiks. READMEens egen verifikasjon kjørt i klonen: 785 passed / 4 skipped. (Merk: open/-speilet står fortsatt på 520e7412 = v0.1.0. Korrigert 2026-08-10: publisering dit er IKKE S1.c onsdag — den er FELT og flyttet til P5-vinduet; se S1.c-raden i §0. Uansett ikke en del av denne målingen.)

RE-MÅLT 2026-08-10 på c9787cf (økt 5) — og det var ikke en formalitet. Målingen over sto på ab7f45a, elleve commits tilbake, altså FØR commons-subtree-pullen, FØR P3/GO (demoen kjørte ennå ikke levert bundle), FØR det pinnede transkriptet, FØR innholdsgaten (som gjorde guarden til en deklarert runtime-dep) og FØR versjonssynken (som endret uv.lock). En ny runtime-dep og en endret låsefil er nøyaktig det en fersk installasjon feller — og planens eget prinsipp (§5) sier at slikt legges FØR tirsdag, ikke på frysedagen. Målt, hver påstand av sin egen kommando: klon fra origin → HEAD = c9787cf · uv sync exit 0 og git status --short tomt (ingen stille re-lock i et ferskt miljø — den faren S1.c gatet, nå bekreftet utenfor arbeidskopien) · uv run pytest -q → 810 passed / 4 skipped (126,72 s) · ruff rent + mypy src 31 filer · PYTHONIOENCODING=utf-8 uv run portfolio-optimiser-demo → exit 0, og diff mot tests/golden/demo-transcript.stdout tomt · 61 stdout- / 4 stderr-linjer · K1 distinkt = 8. (Amendert man 10. økt 6 — HOLDBARHETEN sagt eksplisitt, siden dette er samme premiss-klasse som re-målingen selv felte: persona-pullen (71b7b66+d0e8bb0) landet ETTER c9787cf, så tallene over står på et tre som er to commits gammelt. Målingen står likevel, og grunnen er målt: deltaet er prosa i shared/ + en regenerert fasit, med git diff --stat på pyproject.toml og uv.lock tomt — altså ingen ny dep og ingen endret låsefil, som er nøyaktig de to tingene en fersk installasjon feller. Onsdagens generalprøve ×2 er bekreftelsen; en tredje fersk klon er den ikke verdt.)

Load-bearing MÅLT mot HELE suiten, fem mutasjoner alle røde + grønn kontroll: fjern [project.scripts] · typo i target · detach main()-kallet · la filteret droppe alt · installer filteret ved import. Typo-mutasjonen felte en TEST: resolve-asserten resolverte det FORVENTEDE targetet mot seg selv; den leser nå det distribusjonen faktisk installerer. Fjerde gang på fem økter at mutasjonsmålingen feller testen, ikke koden.

UTFØRT — punkt 0 (2026-08-09). materialize_anchored_bundle kopierer reserven og legger til cost-baseline.json utenfor shared/; main() kjører den varianten, og hele demoløpet er kjørt mot den. Baselinen avledes i KODE fra manus-registeret (baseline_from_scripted_candidate), ikke skrevet ved siden av det — på GO-dagen snus retningen (punkt b i P3), og en håndskrevet kopi ville vært den andre kilden som drifter. Begge skriptede svar må oppgi samme kostlinjer, ellers ValueError: var de ulike, ville hypotese #1 blitt avvist av stage 0 istedenfor av P90, og demoens REJECTED-linje kommet fra en annen mekanisme enn den den forteller om.

10 %-prøven, målt: bevisst avvik (baseline ×1,10) → FORKASTET — quantity 300000 for cost code 'ENERGI-TOTAL-EL' is outside the 5.0% tolerance around the baseline quantity 330000, i stage 0, FØR løseren. Korrigert (manus = baseline) → FORESLÅTT — LED-retrofit av kontorbelysning: 30000 NOK. Kontroll: hypotese #1 avvises fortsatt av P90-stagen, så demo-kriterium 2 viser samme mekanisme som før. Suite 769 → 775 passed / 4 skipped.

Kriterium 6 re-målt: stdout byte-identisk mellom to kjøringer; stderr uendret 6 linjer. Eneste diff mot uforankret demo er den nye fire-linjers KUNNSKAPSBASE-blokka — alt annet er byte-identisk, og det er selve problemet: forankringen er usynlig, derfor må den printes, og derfor er provenance et påkrevd argument (kallstedet som velger bundelen er det eneste som vet hvor tallene kom fra). Punkt 4s NO-GO-setning står nå ordrett på skjermen.

Målingen felte TESTEN først. Første form av entry-point-testen asserterte "kostbaseline erklært" in stdout — men den uforankrede grenen sa «ingen kostbaseline erklært», som INNEHOLDER strengen; og ENERGI-TOTAL-EL står allerede i Steg 2-linja. Detach-mutasjonen gikk GRØNN. De to grenene deler nå ingen ordlyd, og asserten navngir hele linja. Fem mutasjoner røde + grønn kontroll (tests/test_anchored_reserve_loadbearing.py).

GO-dagens endring er ÉN blokk i main(): bundle = materialize_anchored_bundle(...) + provenance = _RESERVE_PROVENANCE byttes mot den leverte bundelens sti og dens egen provenans. Kjørestien er uendret — run.py leser baselinen fra hvilken som helst bundle-katalog.

P4.5 — Demo-runbook: ÉN side operatøren følger på scenen (NY 08-07, I5) ✔ SKREVET (man 10.), §6 TILFØYD (tir 11.), FYLLES UT ons 12.

[0,25 økt · Opus 5/low · produseres VED frysen onsdag — se amendementet rett under]

AMENDERT man 10. økt 7 (c7a57d8): runbooken er SKREVET, og onsdag FYLLER DEN UT. Gaten «produseres VED frysen» ble lest på nytt mot sin egen begrunnelse — «så den matcher frosset output». Det gater hashen X og verbatim output-utdrag, ikke forfatter-dømmekraften. Og onsdagsradens egen regel sier at dagen skal måle og utføre, ikke avgjøre: en runbook skrevet fra bunnen på en enveis-dag under tidspress er nøyaktig det den regelen forbyr. Delingen er derfor bevisst to-trinns:

• Skrevet mandag: kjøresekvensen, hva som sies ved hver skjermlinje (forankret i linjenumre i det pinnede transkriptet), ærlighets-avsnittet i JA-varianten, abortstien, forventede spørsmål — og mandat-setningen, som fantes ingen steder som tekst (Spor 2 sa bare «én muntlig setning»; en udraftet setning til en live demo er ikke en beslutning som er tatt).
• Fylles onsdag: to målte felt (X, prøve-tidspunkt) — se §5-amendementet tir 11. økt 12 for hvorfor tag-bekreftelsen IKKE er et tredje felt.
• Tilføyd tirsdag 11. (økt 10) — §6, torsdagens pre-flight. Runbooken hadde ingen sjekk operatøren kjører før han går på. Mekanismen fantes allerede: golden-transkriptet ble sjekket inn nettopp for å fange «regresjon mellom onsdag og torsdag» (pkt. 3 over). Men i runbooken sto kommandoen under overskriften «Hvis du vil vise at outputen er den frosne» — altså som et show-element under demoen, og kjørt der oppdager den regresjonen samtidig med publikum. Samme defektklasse som frys-gaten (×1 → ×2) og CHANGELOG-datoen (lest på feil HEAD): kommandoen var riktig, tidspunktet var det ikke. §6 flytter den til før rommet fylles og legger til et tag-anker. Ankeret er IDENTITET (git describe --tags --exact-match HEAD → v1.0.0), ikke frys-gatens diff-med-unntak — og den forskjellen ble felt i review: de to unntakene (docs/, CHANGELOG.md) var begrunnet i at onsdagen skriver nøyaktig dem. Torsdag skriver ingenting, så arvet dit ville de gjort gaten fail-OPEN mot den ene skriveren vi vet er aktiv — den parallelle sesjonen som eier docs/presentasjon-portfolio-optimiser.html. Samme klasse som da frys-gaten selv ble snudd fra positiv liste til eksklusjonsform. Målt fail-closed begge veier: no tag exactly matches '<sha>' (exit 128) når HEAD ikke er tagget, bad revision når taggen ikke finnes. Feiler den, er den en BESKJED: git diff --stat v1.0.0..HEAD uten unntak viser hva som landet — kjøresti-filer = abort til §3, kun docs/ = demoen upåvirket, men da vitende. Steg 1 er likeledes en REGEL, ikke et øyeblikksbilde (--untracked-files=no → TOMT), så den fremmede HTML-fila ikke lærer operatøren å ignorere gaten. Kommandoen for selve outputen står fortsatt kun ÉN gang i dokumentet (§6 peker på §1-blokka), så det er ikke laget en andre kopi å drifte fra. Ingen ny placeholder: utfyllings-gaten står uendret på 3. Tatt tirsdag med vilje — onsdagen skal måle og utføre, ikke avgjøre.
• Amendert tirsdag 11. (økt 12) — §0s tag-felt og §5s haker var SIRKULÆRE, og begge landet på torsdag. Tag-feltet i §0 hentet sin verdi fra git tag -l v1.0.0 etter push, altså etter §5s siste punkt — mens §5s punkt 6 krever at utfyllings-gaten er tom, altså før. Punkt 6 var dermed gatet på informasjon som først finnes etter punkt 10, og ingen av utveiene holdt: fylt ærlig krever den en commit etter taggen (da står HEAD ikke lenger på Z, og torsdagens §6 steg 2 — git describe --tags --exact-match HEAD → v1.0.0 — er rød på demo-morgenen), og ufylt bryter den gaten i punkt 6. Sekvensen modellerer heller ikke en tredje commit: STATE og frys-blokka sier X → Y → Z → tag. Tvillingen ble funnet ved å lese videre: §5s haker settes i selve fila, og punkt 7–10 skjer etter runbook-commiten Y — målt gir det M docs/plan/2026-08-12-demo-runbook.md, altså rød §6 steg 1, eller en commit etter taggen, altså rød §6 steg 2. Samme motsigelse, samme to gater. Løsningen bevarer identiteten (§6 steg 2 var dyr å vinne — den er den eneste gaten som fanger bevegelse over natta): §0 mistet tag-raden, §5 fikk et ellevte punkt som bekrefter taggen der den settes (git tag -l · git ls-remote --tags origin · git describe --tags --exact-match HEAD, det siste = torsdagens anker kjørt et døgn tidlig), og §5s ingress sier at hakene aldri settes i fila. Ingenting skrives etter taggen. Målt: utfyllings-gaten 3 → 2 (begge gjenværende felt er kjennbare før Y) · §5 ti → elleve punkter · §0-tabellen 4 pipes per rad · §1 og §2 byte-urørt (shasum likt før/etter — økt 9s 67 målinger er gjort mot de bytene, og §6 peker på §1 nettopp for å slippe en andre kopi). Sjuende defekt i denne dokumentfamilien på sju økter, og fjerde gang klassen er «kommandoen var riktig, tidspunktet var det ikke».
• En ÅTTENDE falt ut av gjennomlesningen, og den er økt 11s egen bom: §5 punkt 9 sa «Steg 2 målte en tilstand som ikke lenger finnes», mens første frys-gate-kjøring er punkt 5. Verifisert mot 818b55a: da linja ble skrevet var frysen TO kommandoer og gaten var nr. 2 — økt 11 gjorde den til tre, men grep-passen den økta lette etter strengen «to kommandoer», så en referanse formulert som «Steg 2» slapp forbi. Økt 11 konkluderte eksplisitt at «ingen kryssreferanse pekte på frys-blokkas gamle nummerering»; det var én. Nå forankret i §5s EGEN nummerering, som ikke kan drifte med frys-blokkas telling. Alle 20 numeriske kryssreferanser i runbooken deretter sveipet (§5s punkt 6/10/11 · §6s steg 1/2/3 · §2s «punkt 2 i åpningen» · planens «pkt. 3» = golden-transkriptet) — ingen flere.
• En NIENDE, funnet i review etter første commit, og den var ukas alvorligste: Y og Z navngis fem steder i §5 — men ingen av de elleve punktene opprettet dem. Punkt 6 sa «Runbooken fylt ut», punkt 7 «CHANGELOG-overskriften stemplet»; ingen sa git commit, og punkt 8 forutsatte at Z fantes. Målt mot gate-definisjonene: frys-gaten unntar BÅDE docs/ og CHANGELOG.md, så to ucommitterte endringer passerer punkt 5 og 9 stille; punkt 11s anker passerer også, fordi HEAD da fortsatt er X og X er det taggede; v1.0.0 ville blitt tagget med ## [Unreleased] fortsatt i CHANGELOG — en RELEASE-defekt, ikke bare en gate-defekt; og først torsdagens §6 steg 1 ville ropt, foran demoen. Rettet som klausuler PÅ punkt 6 og 7, ikke som nye punkter — commiten er det som gjør handlingen varig, og å skille dem er nøyaktig defekten. Fortsatt elleve punkter. Klassen er ny for uka: ikke «feil tidspunkt», men «handlingen var riktig, steget som gjør den varig var implisitt» — den overlevde både gjennomlesningen og propagerings-passen, fordi begge lette etter tall og referanser, ikke fravær. Utfyllingen er gjort til et SJEKKET steg, ikke et husket: to greppbare placeholders (tre til og med tir 11. økt 11 — se amendementet over), og grep-en er selv-sikker — mønsteret '<<[A-ZÆØÅ-]*>>' matcher ikke sin egen tekst (målt: 2 treff, ingen av dem kommandolinjene i dokumentet). Et uutfylt felt er samme drift-klasse som plan-radene økt 4, 5 og 6 hver for seg fant. docs/ er unntatt frys-gaten, så utfyllingen tripper ingenting. Vedlegget feller tre STATE-premisser: de tre «scene-kosmetiske» punktene er målt mot det pinnede transkriptet og ingen er synlige — 23700 NOK/aar klippes bort (rationale 389 tegn, beløpet ca. tegn 370, klipp på 300 → pga. overes…; grep -c → 0), 0.82 hører til bygg-goldenen (grep -c → 0), og ekspert-svar.md leses ikke av demoen. Torsdagen slipper tre setninger den var fortalt at den måtte bære. (Planteksten under står uendret som opphav.) Det som skal SIES torsdag ligger i dag på fire steder: demo-uke-planen §1 (tre ærlighets-punkter), innholdsgate-planen §5 (opplesnings-avsnittet), P4 pkt. 4 (to setninger) og §0 Spor 2 (muntlig mandat-setning). Runbooken samler dem på én side: kjøresekvens (kommandoen + forventede steg-linjer), hva som sies hvor, og abortstien: feiler live-kjøringen, vis golden-transkriptet fra P4 pkt. 3 og si høyt at det er gårsdagens frosne kjøring. Sti: docs/plan/2026-08-12-demo-runbook.md (datert sti — utenfor _LIVE_DOCS-gaten). Runbooken er lesestoff, ikke kjøresti — den kan skrives etter frysen uten å røre den.

3. Plan ETTER demoen (P5–P10, i verdirekkefølge)

P5 — README + nivå-2-påstanden (O4, fre 14.–lør 15.) ☐

[1 økt · Opus 5/medium] Allerede besluttet (O4). Reviewens tillegg: G5-forbeholdet skal stå i teksten som løftes — sammenligningen mot søskenet gjelder den spec-ede kjernen, ikke hele dette repoet (mandat/hovedbok/portefølje-budsjett m.m. er utenfor spec-ene, målt 0 treff).

P6 — Globalt token-tak inn i CLI-en ☐

[1 økt · Opus 5/high · TDD direkte] --budget-dør i main(): PortfolioMeter + read_spend/write_spend-wiring + BudgetRefused inn i except-tuplen (TRAP-kommentaren i run.py sier selv at den ikke fanges i dag). Feller: CLI-test med spend-fil nær taket + --portfolio → strukturert refusal; detach flagget → rød.

P7 — Amendment-pakken til commons — ÉN samlet bestilling ☐

[1 økt · Fable 5/high (spec-review er formen) · leveres via coord-send, ALDRI arbeid i commons] D-A-restene samlet i én tekst: F2/F3-validator-semantikken, S3.2-seedingregelen, S4.0-baseline-formatet, (p)-kvantiseringen, Steg-5-returtypen. Feller: amendmentet gir spec-tester/goldens som binder semantikken på tvers av stackene — i dag kan søskenet følge spec-en korrekt og likevel divergere fra dette repoet.

P8 — Metoden som Agent Skill (B6) ☐ [Voyage]

[/trekbrief først; bestilling til commons + liten konsum-søm her] Målt: kun shared/skills/expert-reviewer/SKILL.md finnes. Innholdet eies av commons (bestilling som tekst); konsum-sømmen her er liten (MAF SkillsProvider er experimental — pin versjon). [Voyage] fordi formen har reell design-usikkerhet — hva av metoden som skal være skript vs. referanse er ikke avgjort.

P9 — Småting ☐

[0,5 økt samlet · Opus 5/low] Kapabilitetskartets to korreksjoner (topologi-notatet fra funn «null»: debatten er en fast sekvens, Group Chat beholdes av byttekost; checkpointing-raden nedgraderes fra «ADOPT (later)» til «NEI med begrunnelse» — pass-nivå-gjenopptakelse er allerede levert via spend-fila). ([project.scripts] er flyttet inn i v1-release-kuttet, §0 S1.c.)

P10 — Eksplisitt NULL (ingen økt) ✔

Ingen Sequential-swap, ingen Handoff, ingen graf-adopsjon, ingen checkpointing. Står her så ingen senere økt «oppdager» dem på nytt. Falsifisering av selve null-beslutningen: forsvinner «forcing completion»-linjene en dag uten bytte, var topologi-analysen feil.

4. Belegg (kommandoene bak påstandene — RE-MÅLT 2026-08-07 på HEAD bb3df79; opprinnelig måling 2026-08-06, se datonoten øverst)

#	Påstand	Kommando → resultat
1	Suiten grønn	uv run pytest -q → 766 passed / 4 skipped (107 s) — re-målt 08-07
2	Demo deterministisk + 8 steg	to kjøringer 08-07, stdout adskilt fra stderr: diff → tom; grep -cE "^ *Steg [1-8]" → 8. Stderr målt: 6 linjer — 2 ExperimentalWarning + 2 «forcing completion» + blanklinje + ikke-deterministisk arbeidskopi:-linje (bevisst, simulation.py:531-534)
3	(KORRIGERT 08-07, I1) Ingen bundle under shared/examples/ shipper kostbaseline — men REPOET gjør, og kjørestien leser den	ls shared/examples/bygg-energi-mikro/ → 8 filer, ingen baseline (re-målt, står — men var målt for SMALT: én katalog). find . -name 'cost-baseline.json' -not -path './.git/*' → src/portfolio_optimiser/data/bundles/bygg-energi-baseline-mikro/cost-baseline.json (gyldig S4.0-format, merket SYNTHETIC); i bruk: grep -n BASELINE_BUNDLE tests/test_s40_cost_baseline_loadbearing.py → :42/:162/:242; kjørestien: run.py:516 load_optional_cost_baseline; bundelen er kopiert parameter: simulation.py:280/:316
4	Steg 7 vises uten fil-innboksen	re-målt 08-07: run_project kalles uten verdict_dir (simulation.py:328-338/:356-366); dommen er argumentet verdict_input (:322); etiketten «lang fil-løkke» står i :478
5	Metode-skill finnes ikke	find shared -name "SKILL.md" → kun expert-reviewer (re-målt 08-07)
6	CLI-porteføljen uten pass-tak	run.py:1679-1686 (re-lest 08-07): budget-stop-armen «currently UNREACHABLE from here»; TRAP-kommentar: BudgetRefused (RuntimeError) utenfor except-tuplen
7	Debatten er en fast sekvens	workflow.py:99-108 (re-lest 08-07): round-robin-selector, terminerings-nett = max_rounds*2+1 = 7 > 3 dispatcher → fyrer aldri; «forcing completion» ×2 målt i dagens stderr
8	MAF-alternativene gir ikke gevinst	re-målt 08-07: installert _group_chat.py:145-155 har round-robin kun som docstring-eksempel; inspect.signature(SequentialBuilder.__init__) → checkpoint_storage direkte. (Handoff = modelldreven ruting: 08-06-introspeksjonen, ikke re-målt)
9	[project.scripts] mangler — bygges i HELGEN (P4 pkt. 5, I3)	grep -n scripts pyproject.toml → 0 treff (re-målt 08-07)
10	Spor B er frys-sikker	grep -nE '^(from|import).*ingest' src/portfolio_optimiser/{run,simulation}.py → 0 treff (re-målt 08-07, skarpere grep — treffene som finnes er kommentarer/hjelpetekst, ingen import)
11	(NY 08-07) Begge baseline-loaderne finnes	grep -n 'def load_optional_cost_baseline|def load_cost_baseline' src/portfolio_optimiser/okf.py → :305 + :323
12	(NY 08-07, I6) Daterings-avvik	git show -s --format='%h %ad' --date=short c96ef90 0eb0f3d 295e966 688ee24 e93e921 d6f3359 → ALLE 2026-08-06; date → 2026-08-07 (fredag); 13. aug = torsdag

5. Ukens kalender (hvor punktene lander)

Justert fre 7. aug (operatør): arbeid starter I DAG, helg inkludert, ny full ukeskvote — full sti er hovedsporet, nedgraderingene i §0 er forsikring. Prinsippet bak fordelingen: alt som IKKE krever det nye commons-innholdet gjøres FØR tirsdag, så tirsdag/onsdag er tynne og risikoen ligger tidlig med slakk bak seg.

Dag	Innhold
fre 7.	Planrevisjonen (I1–I6) ✔ + P1/S1.a: Steg 7-innboksen inn i demoløpet (økt 1)
lør 8.–søn 9.	P2/S1.b: innholdsgaten (økt 2, evt. 3) + P4-forskuddet UTVIDET (0,75–1,25 økt), i denne rekkefølgen: forankret prøvekjøring + 10 %-prøven (pkt. 0, I1) ✔ 08-09 → [project.scripts] (pkt. 5, I3) → stderr-demping FØR pinning (pkt. 2, I2) → fresh-clone (pkt. 1) → golden-transkript-mekanikk (pkt. 3) → de to ærlighets-setningene (pkt. 4) — alt bygges og måles mot den FORANKREDE mikro-reserven NÅ
man 10.	SYV ØKTER, alle ✔. (1) Generalprøve nr. 0 — kjørt mot LEVERT VEGLYS-FV-SOER, ikke reserven: P3 falt to døgn før fristen, så prøven målte demoinnholdet selv. Se UTFØRT-blokka under tabellen. (2) S1.c synk + CHANGELOG (a41272d) — forskuttert fra ons kveld; TAGGEN gjenstår, frys-gatet. (3) open/-beslutningen TATT — taggen til origin ALENE; speilet til P5-vinduet (se S1.c-raden i §0). (4) Planen gjort sann (c9787cf) — to open/-instrukser felt, P2 lukket, kalenderen rettet. (5) Frysedagens to udefinerte steg lukket — P4 ✔ (fersk klon re-målt på c9787cf, elleve commits etter forrige måling) og FRYS gjort kjørbar (frys-blokka under). (6) Persona-pullen landet (71b7b66+d0e8bb0) — commons svarte to døgn før fristen, så tirsdagens eneste punkt ble tatt mandag; fasiten re-målt mot en prediksjon skrevet FØR pullen. Ingenting kodemessig gjenstår før onsdag, og tirsdagen er tom. (7) P4.5-runbooken SKREVET (c7a57d8) — beslutnings-innholdet forskuttert fra onsdag (gaten dekker målingene, ikke forfatterskapet), inkludert mandat-setningen som aldri fantes som tekst; onsdag fyller tre to målte felt (tag-feltet felt tir 11. økt 12 — det var sirkulært). Vedlegget felte tre «scene-kosmetiske» STATE-premisser: ingen av dem er synlige på skjermen (målt). Frysen ble VURDERT flyttet fram og bevisst IKKE flyttet — onsdag er en dato-beslutning på en enveis-handling, og risikoen den ville hedget er retirert av økt 6 (samme kjøresti målt grønn; d0e8bb0..HEAD er dokumenter alene).
tir 11.	IKKE TOM — SEKS ØKTER (8, 9, 10, 11, 12, 13), alle måling/dokument, null kodeendring. Frysen ble VURDERT flyttet fram og bevisst IKKE flyttet: et frysevindu er en forpliktelse, ikke slakk — å tagge tirsdag ville forbudt kjørestien et døgn lenger og gjort ethvert onsdagsfunn til en v1.0.1-beslutning på demo-aften. Tirsdagen er verdt mer som lovlig-fiks-dag. (8) generalprøve som PRØVE, alt grønt på 818b55a; X bevisst IKKE notert; pre-flight mot stale tag ren. (9) runbookens §2 målt mot fasiten — 67 påstander + hver kommando kjørt, null feil; §1s stderr felte én defekt (/tmp/po-sim-… kan aldri vises, TMPDIR = /var/folders/…/T/). (10) runbookens §6 — torsdagens pre-flight — tilføyd (se P4.5). (11) to en-linjes herdinger av onsdagen/torsdagen: §5 manglet en arbeidstre-sjekk ved X (frys-gaten er commit-til-commit, prøven leser treet — en ucommittet src/-endring ville gjort X til en beskrivelse av noe som aldri ble prøvd, usynlig for BEGGE gate-kjøringene), og §3s abortsti brukte relativ sti til fasit-fila, altså feilet av nøyaktig den «feil katalog»-årsaken prosaen selv navngir (målt). Frysen er nå tre kommandoer. (12) §0s tag-felt var SIRKULÆRT og §5s haker var tvillingen — feltet kunne først fylles etter §5s siste punkt, mens punkt 6 krever at gaten er tom; hakene settes i fila, og punkt 7–10 skjer etter runbook-commiten Y. Begge utveier gjorde en av torsdagens to gater rød (ucommittet → §6 steg 1; commit etter taggen → §6 steg 2s identitet). Tag-raden fjernet, ellevte §5-punkt bekrefter taggen der den settes, hakene forlot fila. Se P4.5-amendementet. (13) §5s punkt 5 var en gate som ikke kunne feile — <X> er HEAD der, så <X>..HEAD er tom per konstruksjon (målt med en endret src/-fil i treet: fortsatt tom). Den målte altså ingen tilstand, mens økt 7s begrunnelse sa «en tilstand som ikke lenger finnes». Punktet beholdt (fjerning ville renummerert elleve punkter og brutt fem kryssreferanser på frys-eve), men gitt en andre arm mot fast hash c255662 → ikke tomt (6 filer), som beviser at kommandoen kan diskriminere før punkt 9 hviler på at den er tom — uten den ville en ødelagt pathspec gitt grønt på feil grunnlag. Punkt 9s tilbakereferanse og §5s ingress rettet i samme pass. Se frys-blokkas økt-13-amendement. (Raden sa «TOM — GÅ RETT PÅ ONSDAG»; det var sant da den ble skrevet man 10. og sluttet å være det samme uke. Samme drift-klasse som radene økt 4, 5 og 6 hver for seg fant.) (Amendert man 10. økt 6: tirsdagens ENESTE åpne punkt var commons-svaret på persona-formuleringen — «i kontorbygg» på et veglys-prosjekt, printet ordrett i Steg 7. Svaret kom to døgn før fristen og ble tatt samme dag: subtree pull av commons 73136eb → «i tilsvarende anlegg», marker byte-uendret (71b7b66), fasiten re-målt (d0e8bb0). Abortstien I4 ble aldri utløst — men den ble verifisert KJØRBAR først: git reset --hard blokkeres av hooken, --keep slipper. Rød-settet etter pullen var NØYAKTIG én test, det pinnede transkriptet; goldenene (kriterium 8) uendret; pyproject.toml/uv.lock urørt. Denne raden instruerte om arbeid som var utført — samme drift-klasse som økt 4 felte.)
ons 12.	FRYSESEKVENSEN, i denne rekkefølgen. P4 ER LUKKET (man 10., økt 5 — fersk-klon-målingen var det eneste som gjensto, og den er kjørt på c9787cf), så sekvensen starter på prøven, ikke på en udefinert re-måling: generalprøve ×2 (bruk distinkt-tellingen grep -oE "^ *Steg [1-8]" | tr -d ' ' | sort -u | wc -l → 8; linje-tellingen gir 9, se avviket under tabellen) → FRYS → P4.5: FYLL UT demo-runbooken (docs/plan/2026-08-12-demo-runbook.md — den er SKREVET man 10. økt 7, c7a57d8; onsdag setter inn to målte felt (X + prøve-tidspunkt) og følger §5s elleve punkter i terminalen — hakene settes ALDRI i fila, og taggen bekreftes i punkt 11, ikke som et felt i §0; begge deler ville krevd en skriving etter taggen og gjort torsdagens identitets-anker rødt (tir 11. økt 12). Utfyllings-gaten: grep -n '<<[A-ZÆØÅ-]*>>' docs/plan/2026-08-12-demo-runbook.md → TOMT) → S1.c-TAGGEN sist (CHANGELOG-stempel + git tag -a v1.0.0 -m "<ordrett fra runbookens §5 punkt 10>" — ANNOTERT, som v0.1.0; -m er PÅKREVD (uten den: exit 128, ingen tag), og meldingsteksten står literalt i §5 punkt 10 og skal ikke skrives på nytt her — + push til origin ALENE — synk + CHANGELOG-innhold er alt gjort man 10.; [project.scripts] lå i helgen, I3). Punkt 11s bekreftelse tåler nå en rate-limitet origin (tir 11. økt 14, målt): tom utskrift er tvetydig, og exit-koden er det som skiller «taggen mangler» (0) fra «kom ikke fram» (128). Alle beslutninger er tatt på forhånd — onsdag skal MÅLE og UTFØRE, ikke avgjøre. FRYSEN ER TRE PUNKTER, ikke en holdning — se frys-blokka under tabellen (rent tre → noter X → gaten; arbeidstre-sjekken tilføyd tir 11. økt 11, fordi gaten er commit-til-commit og prøven leser treet). Punkt 3 er to armer siden økt 13 — kjøringen mot <X> er tom per konstruksjon og beviser ingenting alene; diskriminerings-armen mot c255662 er den som gjør den siste gate-kjøringen meningsfull.
tor 13.	DEMO = v1 vises (runbooken i hånda). FØRST runbookens §6 — pre-flighten, før noen er i rommet: rent tre (git status --short --untracked-files=no → TOMT) · tag-ankeret git describe --tags --exact-match HEAD → v1.0.0 (IDENTITET, ikke frys-gatens diff-med-unntak — de unntakene er onsdagens, og arvet hit ville de vært fail-open mot den parallelle docs/-sesjonen) · golden-diffen TOM. Feiler ankeret: les git diff --stat v1.0.0..HEAD UTEN unntak — kjøresti-filer = §3, kun docs/ = upåvirket men vitende. Golden-diff ikke tom = §3, vis fasit-fila; aldri debugging på scenen. (Tilføyd tir 11. — goldenen ble bygget for å fange regresjon onsdag→torsdag, men kommandoen sto som et show-element UNDER demoen; kjørt der oppdager den regresjonen samtidig med publikum.)
fre 14.–lør 15.	P5: README (O4)
deretter	P6 → P7 → P8 → P9, ett punkt per økt; STATE.md peker på øverste åpne

FRYSEN, OPERASJONELT (skrevet 2026-08-10, økt 5 — den var UDEFINERT, og en udefinert frys er nettopp en beslutning tatt på frysedagen). «Frys» går igjen gjennom hele planverket — 40 treff i åtte plandokumenter, målt — og er ett eneste sted forsøkt definert: demo-uke-planen linje 93, «etter generalprøven: ingen endringer i kjørestien» — en regel, ikke en handling. Det gjorde ett av onsdagens fire steg innholdsløst. Problemet er konkret: sekvensen er generalprøve ×2 (commit X) → runbook (commit Y) → CHANGELOG-stempel + tag (commit Z), så taggen lander på Z mens prøven målte X. At Y og Z bare er dokumenter er sant i dag, men sto ingen steder som noe onsdagen SJEKKER. Tre kommandoer:

1. Rent tre — FØR X noteres — git status --short --untracked-files=no → TOMT. (TILFØYD tir 11. økt 11 (advisor-review). Gaten i punkt 3 er git diff <X>..HEAD — commit-til-commit — mens generalprøven kjører fra arbeidstreet. En ucommittet endring i src/ ved prøvetidspunktet gjør X til en beskrivelse av noe som aldri ble prøvd, og BEGGE kjøringene av gaten står tomme: de kan ikke se den. Verre om endringen er dét som gjør prøven grønn — da er den taggede koden rød, som er nøyaktig hullet kriterium 6 ikke dekker. Samme argument som ga §6 steg 1 sin plass (økt 10): rent tre er en REGEL, ikke et øyeblikksbilde — det gjelder identisk ved X. Samme kommando, tredje tidspunkt, egen jobb.)

2. Noter X rett etter grønn generalprøve ×2 — git rev-parse HEAD — og skriv hashen inn i runbooken (P4.5). (Amendert man 10. økt 6: setningen sa «X er ikke mandagens HEAD — lander tirsdagens persona-pull, flytter X seg». Pullen ER landet, d0e8bb0. X måles altså fra d0e8bb0 og framover — men den skal fortsatt LESES av git rev-parse HEAD etter grønn prøve, aldri skrives av her: en hash notert i en plan er et premiss, ikke en måling.)

3. Før taggen, kjør frys-gaten:

   git diff --stat <X>..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md'   # → TOMT
   

   Tomt = alt mellom prøven og taggen er dokumenter, altså er det prøvde treet det taggede treet. Ikke tomt = IKKE tag — kjør generalprøven om igjen på en ny X.

   AMENDERT man 10. økt 7 (advisor-review): gaten kjøres TO GANGER — rett etter X, og ÉN GANG TIL rett før git tag. Sekvensen er X → Y (runbook) → Z (CHANGELOG-stempel), så en gate kjørt kun ved X måler en tilstand som ikke lenger finnes når taggen settes. Kommandoen er den samme; det er tidspunktet som gjør den til et bevis om det TAGGEDE treet i stedet for om et mellomsteg. Samme review flyttet CHANGELOG-datoen fra veggklokka til git log -1 --format=%cs.

   AMENDERT tir 11. økt 8 (advisor-review): datoen må RE-LESES etter at Z finnes. Formuleringen «leses av commiten som tagges» beskrev ikke sekvensen den står i: når kommandoen kjøres, står HEAD på Y — og Y blir aldri tagget. Verdien skrives så inn i Z. Det holder når Y og Z lander samme dag (også ved en samlet skli til torsdag morgen, som var tilfellet setningen påberopte seg), men brekker ved midnatt mellom Y og Z: da bærer den taggede commiten gårsdagens stempel. Retteslen er ett re-lesningssteg i runbookens §5 — git log -1 --format=%cs én gang til ETTER commit av Z og FØR git tag, med --amend ved avvik. Samme klasse som gaten over: kommandoen var riktig, tidspunktet var det ikke.

   AMENDERT tir 11. økt 13 (målt): kjøringen ved X er tom PER KONSTRUKSJON, ikke bare foreldet. Økt 7s formulering over — «måler en tilstand som ikke lenger finnes» — er for snill. Ved den første kjøringen er <X> HEAD (punkt 2 leste den nettopp, og ingenting er committet siden), så <X>..HEAD er tom uansett hva treet inneholder. Målt med en endret src/-fil liggende i treet: gaten sto fortsatt tom. Den måler altså ingen tilstand — den er en lime-inn-sjekk av hashen (fatal: bad revision hvis den er feil). Frysen selv bæres av punkt 1 (rent tre) og kjøringen etter Y og Z; de to er tilstrekkelige, og den første kjøringen er strukturelt overflødig. Å la en gate som bare kan bli grønn stå udeklarert er nøyaktig det repoet forbyr i testene sine («en gate som bare kan bli grønn beviser ingenting»), og en operatør som ser den grønn ved X kan under tidspress lese den siste kjøringen som en gjentakelse. Retteslen er ikke å fjerne den — det ville renummerert §5s elleve punkter og brutt fem kryssreferanser på frys-eve — men å gi den en arm den kan feile på. Runbookens punkt 5 kjører nå gaten mot en fast historisk hash i tillegg:

   git diff --stat c255662..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md'   # → IKKE tomt (målt: 6 filer)
   

   Den beviser at kommandoen kan diskriminere før den siste kjøringen hviler på at den er tom. Uten den ville en feilskrevet ':(exclude)…' eller en quoting som ikke overlevde skallet (MULTIOS-lærdommen, 08-09) gitt en grønn gate på feil grunnlag — og et utestet tre tagget. c255662 ligger fast bak både Y og Z, så armen forblir ikke-tom uansett hvor HEAD står onsdag.

Gaten LISTER HVA SOM ER UNNTATT, ikke hva den vokter — den feiler LUKKET. Første form listet kjørestien positivt (src/ tests/ shared/ pyproject.toml uv.lock), og en slik gate er blind for alt den ikke rakk å regne opp: målt på 1522e2a^..1522e2a rapporterer inklusjonsformen to filer og slipper README.md OG CLAUDE.md rett igjennom, mens eksklusjonsformen tar alle fire. På en enveis-dag er det feil vei å feile — en ny fil skal trippe gaten, ikke passere den fordi ingen forutså den. De to unntakene er nøyaktig det onsdagen SKAL skrive: runbooken (docs/) og CHANGELOG.md, som stemples i samme trekk som taggen — en gate som dekket den kunne aldri blitt grønn. (STATE.md er gitignorert og kan ikke dukke opp i en diff.)

Gaten er MÅLT at den diskriminerer (08-10), ikke antatt — en gate som bare kan bli grønn beviser ingenting: c255662..HEAD (treet generalprøve nr. 0 faktisk kjørte på → HEAD) gir fire filer (pyproject.toml · __init__.py · test_smoke.py · uv.lock) — versjonssynken som landet ETTER prøven, altså akkurat den klassen gaten finnes for — mens a41272d..HEAD gir tomt. Begge målt på BEGGE former, med samme svar; det er kun README/CLAUDE-vinduet over som skiller dem.

UTFØRT — GENERALPRØVE NR. 0 (2026-08-10). BESTÅTT, ingen kodeendring. Ingen fil i repoet ble rørt av prøven; den er ren måling. Planen forutsatte at prøven kjørte mot den forankrede reserven — den kjørte mot levert VEGLYS-FV-SOER, fordi P3 falt 08-09. Det er en STRENGERE prøve enn planlagt (reserven validerer mekanikk, aldri presentasjon — P3s lærdom 2), og reserve-stien er fortsatt målt: den lever i suiten som test_anchored_reserve_loadbearing.py, ikke som demoens call-site-valg.

Målt, hver påstand av sin egen kommando:

• Golden-diff (selve prøven): diff -u tests/golden/demo-transcript.stdout <kjøring> → tomt, exit 0. Målt for BEGGE kjøringene, ikke bare den første.
• K6 selv-identitet: to kjøringer, diff på stdout tomt. Eneste stderr-diff er po-sim-y6x0kxp_ → po-sim-rfbjsl86 — nøyaktig det spannet pkt. 3-normaliseringen dekker, og prefikset står synlig i begge, som pkt. 3 krever.
• K1 åtte steg: alle åtte distinkte (Steg1…Steg8). Tellingen er 9, ikke 8 — se avviket under.
• K2: hypotese #1: REJECTED (claimed saving 2100000 exceeds P90 feasible 1769915) + etter forbedring: VALIDATED (påstått 445500 <= P90 1769915) — samme kandidat, P90-stagen.
• K4: uv run pytest -q → 810 passed / 4 skipped (814 kollektert) på 122,52 s. Uendret fra 08-09.
• K5: ruff check . → All checks passed; mypy src → no issues found in 31 source files.
• K8: git diff --stat på shared/examples/bygg-energi-mikro/ + nav-golden-* → tomt.
• Exit 0, stdout 61 linjer, stderr 4 linjer — de fire pkt. 2/3 forutsa.

ÉTT AVVIK, og det er kriteriets BOKSTAV, ikke demoen. Demo-uke-planen §5 pkt. 1 sier grep -cE "^ *Steg [1-8]" → 8; målt gir den 9. Årsaken er P1/S1.a: Steg 7 har nå TO merkede linjer (kort løkke i kjøringen + Steg 7 (lang løkke) — EN EKSPERT LEGGER EN DOM I INNBOKSEN), fordi de to tidsskalaene ble skilt og hver fikk sin markør. Kriteriets INTENSJON — «én merket linje per steg 1–8», dvs. at ingen steg mangler — er oppfylt: sort -u gir Steg1…Steg8, åtte distinkte. Tellingen = 8 var skrevet 08-06, før Steg 7 fikk to linjer. Kriteriet oppdateres ikke her — det bor i demo-uke-planen, og en telling justert i samme økt som den feiler er ikke lenger en gate. Onsdagens generalprøve ×2 skal bruke distinkt-tellingen (sort -u → 8), ikke linje-tellingen.

6. Planrevisjonen 2026-08-07 — seks innsigelser, avgjørelser med belegg

Kjørt på Fable 5/xhigh uten advisor; hvert premiss fra innsigelses-prompten er derfor re-målt i økta med egne kommandoer (§4 + kolonnen her) — ingen tall er gjenbrukt.

#	Innsigelse	Avgjørelse	Nøkkelmåling (kjørt 08-07)
I1	Funn 1 målt for smalt; «reserven kan aldri få fila» feil som formulert	TAS INN — forankret prøvekjøring + 10 %-prøve flyttet til helgen (P4 pkt. 0); §1/§4 korrigert	find . -name 'cost-baseline.json' → fixturen finnes (gyldig S4.0-format); run.py:516 wirer loaderen; simulation.py:280/:316 — bundelen er kopiert parameter
I2	Demping (ons) etter pinning (helg) ugyldiggjør fasiten	TAS INN, SKJERPET — beslutning JA tatt nå; demping i helgen FØR pinning; målt at stderr uansett trenger definert form	to sim-kjøringer: stderr = 6 linjer, ikke 4 — arbeidskopi:-linja er ikke-deterministisk (simulation.py:531-534)
I3	[project.scripts] på frysedagen endrer install-flaten ETTER fresh-clone-målingen	TAS INN — flyttet til P4 pkt. 5 (helg), FØR fresh-clone; S1.c = synk + CHANGELOG + tag	grep -n scripts pyproject.toml → 0 treff
I4	Tirsdagens pull mangler avbruddssti	TAS INN — pre-pull-hash + reset-regel + NO-GO senest kl. 18:00 skrevet inn i P3 og §5	kriterium 8 finnes (demo-uke-plan §5 pkt. 8, lest 08-07), men ingen revert-regel sto i noe dokument
I5	Ingen demo-runbook allokert	TAS INN — ny post P4.5 (0,25 økt, VED frysen); golden-transkriptet gjort eksplisitt til abortsti	de fire spredte kildene bekreftet (demo-uke-plan §1, innholdsgate §5, P4 pkt. 4, §0 Spor 2 — lest 08-07)
I6	Datoene ligger 2–3 dager fram i tid	TAS INN — §4 re-datert til faktisk måling; STATE-loggen korrigert; filnavnet står med datonote	git show -s --format='%h %ad' → alle refererte commits 2026-08-06; date → 2026-08-07 (fredag)

Avvist: ingen. I1s mot-spørsmål ble målt, ikke antatt: ingen kollisjon med _default_bundle_dir()/PORTFOLIO_SHARED_ROOT (bundelen er et funksjonsargument, og demoen kjører på en kopi — simulation.py:280/:316/:492), ingen kollisjon med kriterium 6 (selv-identitet: en forankret kjøring diffes mot seg selv) eller kriterium 8 (den lokale bundelen ligger utenfor shared/), og syntetisk forankring beviser MEKANISMEN live — tall-ærligheten dekkes allerede av nivå 2-regelen (demo-uke-planen §1 pkt. 3) og fixture-notatet «SYNTHETIC». Kostnaden (~0,25–0,5 økt ekstra i helgen) er dekket av ny full ukeskvote og kjøpes tilbake ved at tirsdag/onsdag blir tynnere.