docs(P4.5): §5s frys-gate ved X kunne aldri feile

Punkt 5 kjørte frys-gaten mot <X> rett etter at punkt 4 leste X som
`git rev-parse HEAD`. På det tidspunktet ER X lik HEAD, og ingenting er
committet imellom — så <X>..HEAD er tom uansett hva treet inneholder.

Målt, ikke resonnert: med en endret src/-fil liggende i arbeidstreet
(` M src/portfolio_optimiser/__init__.py`) sto gaten fortsatt tom. Den
måler ingen tilstand.

Økt 7s begrunnelse for to kjøringer sa «den første måler en tilstand som
ikke lenger finnes når taggen settes». Det er for snill: den finner ingen
tilstand å måle. Dette er repoets egen defektklasse, anvendt på repoets
egen runbook — «en gate som bare kan bli grønn beviser ingenting» er
standarden hver load-bearing test måles mot.

Alvorlighet, uttalt presist: falsk trygghet, ikke falsk grønt. Punkt 3
(rent tre) og punkt 9 (etter Y og Z) dekker den faktiske risikoen, så
ingenting ved onsdagen blir rødt av dette. Men en gate operatøren ser
grønn ved X kan under tidspress gjøre punkt 9 til en gjentakelse man
hopper over — samme argument som ga §6 steg 1 sin `--untracked-files=no`.

Punktet er BEHOLDT, ikke fjernet: fjerning renummererer 6→5 … 11→10 og
bryter fem kryssreferanser (§0s «punkt 10» og «punkt 6», punkt 9s
tilbakereferanse, STATEs «elleve punkter», planens ons-12-rad) — på
frys-eve. I stedet har punkt 5 fått en arm den kan feile på:

    git diff --stat c255662..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md'

→ ikke tomt (målt: 6 filer). Den beviser at kommandoen kan diskriminere
FØR punkt 9 hviler på at den er tom. Uten den ville en feilskrevet
':(exclude)…' eller en quoting som ikke overlevde skallet (MULTIOS,
08-09) gitt 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.

To rettelser i samme pass, begge nødvendige for at teksten ikke skal lyve
på en ny måte:

- punkt 9 sa «Punkt 5 målte en tilstand som ikke lenger finnes» — under
  det nye punkt 5 er det galt på en ny måte, siden punkt 5 ikke målte noe
- §5s ingress sa «Fila skrives ÉN gang onsdag (punkt 6)», mens punkt 4
  instruerer om å skrive X inn i §0. Den bærende egenskapen er at
  ingenting skrives ETTER Y, ikke antallet skrivinger — nå sagt slik.
  Punkt 4 er operasjonelt riktig: å bære en hash i hodet gjennom tre
  gate-kjøringer er verre.

Begge gate-kommandoene er EKSTRAHERT LITERALT fra runbooken og kjørt
(ikke gjenskapt for hånd — repoets MULTIOS-lærdom): arm 1 tom, arm 2
seks filer.

Målt: utfyllings-gaten 2 · §5 elleve punkter · §0/§1/§2/§3/§4/§6/vedlegg
byte-urørt mot 24b5ed2 (kun §5 endret, så økt 9s 67 målinger av §2 står) ·
planens kalender-rader 3 usiterte pipes · frys-gaten mot HEAD TOM ·
810 passed / 4 skipped · ruff + format + mypy rene.

Pre-flighten er re-målt HELT på 24b5ed2, ikke arvet fra 4b9e5d9:
stale tag 0/0 · [Unreleased] 1, null link-refs · frys-gaten d0e8bb0..HEAD
TOM og diskriminerende (c255662..HEAD = 6 filer) · demo exit 0, golden-diff
TOM, 61 linjer, K1 distinkt 8 / linjer 9.

Åttende defekt i denne dokumentfamilien på åtte økter. Ny klasse: ikke
«feil tidspunkt» og ikke «implisitt steg», men en gate hvis utfall var
avgjort av sin egen plassering i sekvensen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0192WLzngWK5aFDYpkXWuLVh
This commit is contained in:
Kjell Tore Guttormsen 2026-08-11 21:51:23 +02:00
commit c50fd2edb4
2 changed files with 52 additions and 8 deletions

View file

@ -214,8 +214,11 @@ og feilsøking på scenen koster mer enn fila.
fra punkt 7 og ut skjer *etter* den. Et hake satt der havner enten ucommittet i treet — målt:
`git status --short --untracked-files=no` svarer da ` M docs/plan/2026-08-12-demo-runbook.md`, så
torsdagens §6 steg 1 blir rød — eller i en commit **etter** taggen, som gjør §6 steg 2s identitet
rød. Samme motsigelse som §0s manglende tag-rad, samme to gater. **Fila skrives ÉN gang onsdag
(punkt 6) og røres ikke etterpå.** Bruk papir, en annen skjerm eller hukommelsen.
rød. Samme motsigelse som §0s manglende tag-rad, samme to gater. **Fila skrives i punkt 4 og punkt 6
— begge FØR runbook-commiten `Y` — og røres ikke etter den.** Det er *etterpå* som er den bærende
egenskapen, ikke antallet skrivinger: en hash notert i punkt 4 og først skrevet ned tre steg senere
er en hash båret i hodet gjennom tre gate-kjøringer. Bruk papir, en annen skjerm eller hukommelsen
til **hakene** — de er det eneste som ellers ville havnet i fila etter `Y`.
- [ ] Generalprøve ×2 grønn — golden-diff tom begge ganger
- [ ] K1: `grep -oE "^ *Steg [1-8]" <stdout> | tr -d ' ' | sort -u | wc -l` → **8**
@ -231,7 +234,25 @@ rød. Samme motsigelse som §0s manglende tag-rad, samme to gater. **Fila skrive
og gå videre: den commiten flytter HEAD, så **X** ville pekt på et tre prøven aldri så. Ved X
er ingenting redigert ennå — runbooken (Y) og CHANGELOG (Z) skrives *etter* dette punktet.
- [ ] **X** notert (`git rev-parse HEAD`) og skrevet inn i tabellen i §0
- [ ] Frys-gaten grønn: `git diff --stat <X>..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md'` → TOMT
- [ ] **Frys-gaten prøvekjørt — BEGGE armer.**
```
git diff --stat <X>..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md' # → TOMT
git diff --stat c255662..HEAD -- . ':(exclude)docs/' ':(exclude)CHANGELOG.md' # → IKKE tomt
```
Den første armen er **tom, og kan ikke være annet**: `<X>` **er** HEAD her — punkt 4 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 er altså en
**lime-inn-sjekk** av hashen (`fatal: bad revision` hvis du bommet), ikke en frys-sjekk.
Frysen selv måles av punkt 3 (rent tre) og punkt 9 (etter Y og Z).
**Den andre armen er den som gir punkt 9 mening** — den beviser at kommandoen *kan* bli
ikke-tom, før punkt 9 hviler på at den er tom. Målt: **6 filer**. `c255662` ligger fast bak
både Y og Z, så den forblir ikke-tom uansett hvor HEAD står i morgen.
**Er den andre armen også tom, er det pathspec-en som er ødelagt** — feilskrevet
`':(exclude)…'`, eller quoting som ikke overlevde skallet (repoets MULTIOS-lærdom: en kommando
som ser riktig ut kan lyve). Punkt 9 ville da vært grønn på feil grunnlag, og du ville tagget
et utestet tre. **Ikke gå videre før den andre armen er ikke-tom.**
- [ ] Runbooken fylt ut (§0s to felt) + `grep -n '<<[A-ZÆØÅ-]*>>' docs/plan/2026-08-12-demo-runbook.md`
→ TOMT — **og så `git commit`. Den commiten ER `Y`.** Uten den er runbooken en ucommittet
endring resten av sekvensen ikke kan se: frys-gaten (punkt 5 og 9) ekskluderer `docs/`, så den
@ -248,9 +269,11 @@ rød. Samme motsigelse som §0s manglende tag-rad, samme to gater. **Fila skrive
du gårsdagens dato inn i commiten som faktisk tagges. Avvik = `git commit --amend`
overskriften, les på nytt, ikke tag før de er like. *(Sklir HELE sekvensen til torsdag morgen,
er alt i orden — Y og Z er da samme dag. Det er bare midnatt MELLOM dem som brekker enigheten.)*
- [ ] **Frys-gaten kjøres ÉN GANG TIL, rett før taggen** — samme kommando som over. **Punkt 5** målte
en tilstand som ikke lenger finnes: runbook-commiten (Y) og CHANGELOG-stempelet (Z) kom etterpå.
Tom her = **det taggede treet er beviselig det prøvde treet**. Ikke tomt = IKKE tag.
- [ ] **Frys-gaten kjøres ÉN GANG TIL, rett før taggen** — samme kommando som punkt 5s første arm.
**Dette er den første kjøringen som kan si noe.** Punkt 5s arm mot `<X>` var tom *per
konstruksjon* (X var HEAD da); her har runbook-commiten (Y) og CHANGELOG-stempelet (Z) flyttet
HEAD forbi X, så en `src/`-endring imellom ville dukket opp. Tom her = **det taggede treet er
beviselig det prøvde treet**. Ikke tomt = IKKE tag.
- [ ] `git tag v1.0.0` + `git push origin v1.0.0` (**`origin` alene** — `open/` er P5-vinduet)
- [ ] **Taggen bekreftet der den ble satt**`git tag -l v1.0.0``v1.0.0` · `git ls-remote --tags
origin v1.0.0` → **én linje** · `git describe --tags --exact-match HEAD` → `v1.0.0`.