docs(fase1a): «uansett modell» hvilte på en måling jeg aldri leste ferdig

Advisor felte påstanden ETTER at forrige commit var pushet. Rapporten sa at
600 s-taket er bindende «UANSETT modell», med `llama3.2:1b brukte OGSÅ >10 min»
som belegg. Men den målingen sprengte Bash-timeouten, gikk til bakgrunnen, og
ble aldri lest til slutt — «>10 min» var det jeg SÅ ved én kikk, ikke et resultat.

Målt nå ved manuell stopp: prosessen sto på 18 min 54 s UTEN å fullføre, og
loggen har ingen `POST "/api/generate"` for kallet. Det gir en NEDRE grense
(kallet oversteg taket med god margin) og ingen øvre.

Påstanden er derfor snevret til «på denne maskinen i denne tilstanden», med
konfunderingen uttalt: CPU-en strupet seg 62 % → 54 % underveis, og to fremmede
Python-prosesser holdt ~1,8 kjerner. Et generelt utsagn om modellstørrelse ville
krevd en ren maskin og en fullført måling; ingen av delene finnes her.
Verifiseringsloggen har fått raden + en eksplisitt «ikke verifisert»-note.

Samme defektklasse som grep-en samme økt, ett nivå opp: der var instrumentet i
stykker, her var det i orden og jeg leste det bare aldri.

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

docs/2026-08-13-fase1a-lokal-ende-til-ende.md

@@ -129,9 +129,18 @@ framfor å brenne det tredje forsøket mot et kjent utfall.
 Ett funn ble likevel lukket: **null trunkering** i loggen. Det større kontekstvinduet løser funn 4.
 
 **Diagnosen flyttet seg, og det er den viktigste setningen i rapporten:** flaskehalsen er ikke
-tankemodusen. Det er at 600-sekunders-taket er bindende på denne maskinvaren **uansett modell**.
+tankemodusen. Det er at 600-sekunders-taket er bindende **på denne maskinen i denne tilstanden**,
-En kontrollmåling med `llama3.2:1b` — en modell på 1,3 GB — brukte også over ti minutter på ett
+også for modeller som er langt mindre enn den shippede.
-kall med denne kontekststørrelsen, mens maskinen strupet seg fra 62 % til 54 % klokkefrekvens.
+
+Kontrollmålingen: `llama3.2:1b` — en modell på 1,3 GB — sto **18 min 54 s uten å fullføre ett
+enkelt kall** med denne kontekststørrelsen, og ble så stoppet manuelt. **Presist hva dette er:**
+den nedre grensen er målt (kallet overskred 600-sekunders-taket med god margin), men den øvre er
+det ikke — målingen ble aldri lest til slutt, så det finnes ikke noe totaltall for den.
+
+**Og påstanden er bevisst snevret til denne maskinen i denne tilstanden**, ikke «uansett modell»:
+målingen er konfundert av at CPU-en strupet seg fra 62 % til 54 % klokkefrekvens underveis, og at
+to fremmede Python-prosesser holdt ~1,8 kjerner samtidig. Et generelt utsagn om modellstørrelse
+ville krevd en ren maskin og en fullført måling; ingen av delene finnes her.
 
 ## Hva som er bevist, og hva som ikke er
 
@@ -180,3 +189,8 @@ Claude-deployment. Foundry-tilgjengeligheten er dokumentert; klient-kompatibilit
 | Prompt 4388 tokens, kuttet mot 4096 | Ollamas `truncating input prompt`-advarsel |
 | `_DEFAULT_MAX_ROUNDS = 3`, `_DEFAULT_MAX_TOKENS = 100_000` | `run.py:110-111`; CLI-en har ingen `--max-*` |
 | Haiku 4.5-priser; Claude på Foundry til standard API-rater | Anthropics modell-/prisdokumentasjon (`claude-api`-skillen) |
+| `llama3.2:1b` 18 min 54 s **uten å fullføre** — nedre grense, ikke totaltid | `ps -o etime=` ved manuell stopp; ingen `POST "/api/generate"` i loggen for kallet |
+
+**Ikke verifisert, uttalt:** at taket ville vært bindende på en URØRT maskin, eller for en vilkårlig
+liten modell. Kontrollmålingen ble kjørt under termisk struping og fremmed last, og ble aldri
+fullført. Påstandene over gjelder denne maskinen i denne tilstanden.