docs(4·): containeren er bygget — og wheelen er ikke installerbar alene

Fullfører spikens siste måling etter at docker-tillatelsen kom på plass.

7.1 — `docker build --platform linux/amd64` grønn på python:3.12-slim-bookworm.
`uv sync --frozen` resolverte inne i containeren, inkludert begge git-pinnene,
og siste lag ga `import OK`. Det lukker gapet uv-resolusjonen ikke kunne lukke:
at avhengighetene LØSER for linux beviser ikke at koden KJØRER der.

7.2 — Andre måling bygde wheelen, SLETTET kilden, og installerte kun wheelen.
Den feilet: `llm-ingestion-guard was not found in the package registry`.
Wheelens metadata bærer de to avhengighetene som BARE NAVN — [tool.uv.sources]
er uv-konfig og reiser ikke med wheelen, og navnene finnes ikke på PyPI. En
nedlaster som får et wheel (f.eks. fra release-objektet fase 3 skal lage)
treffer denne veggen. Med direct references ved siden av: 65 pakker, exit 0.

Dette er den skarpeste friksjonskanten spiken fant, og ingen hadde spurt om den.

7.3 — Samme bygg beviste fase 4a i container: shared_root() peker på
site-packages/portfolio_optimiser/_shared, 80 filer, persona-skillen lesbar —
uten arbeidstre, siden /build var slettet før installasjonen. Invarianten er
dermed målt i situasjonen den ble bygget for, ikke bare i enhetstest.

Byggekonteksten er `git archive HEAD` (311 sporede filer) — det en fremmed
faktisk laster ned, ikke arbeidstreet.

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

docs/2026-08-13-fase4-research-spike.md

@@ -11,9 +11,10 @@ med URL. Det som ikke lot seg verifisere står under **Ikke verifisert** — ikk
 
 ## 0. Sammendrag for den som bare leser ett avsnitt
 
-Fire spørsmål ble stilt. Tre er besvart med kommandoer og kilder. Ett — om containeren faktisk
-bygger — er **ikke fullført**, fordi byggekommandoen ble blokkert av tillatelsesoppsettet etter at
-verktøykjeden var på plass.
+Alle fire spørsmål er besvart med kjørte kommandoer og siterte kilder, og containeren er bygget på
+`linux/amd64` (§7). Underveis kom det ett funn ingen hadde spurt om: **wheelen er ikke installerbar
+alene** — dens metadata bærer to avhengigheter som bare navn, og de finnes ikke på PyPI (§7.2). Det
+er den skarpeste friksjonskanten spiken fant.
 
 Spiken felte **tre premisser i planen**:
 
@@ -323,15 +324,63 @@ linja ble fjernet (backup: `~/.docker/config.json.bak-20260813-213134`).
 
 ---
 
-## 7. Det som IKKE ble målt
+## 7. Containeren er bygget — to målinger
 
-**Containeren er ikke bygget.** Byggekonteksten er klar (`git archive HEAD`, 311 sporede filer,
-3,7 MB — altså det en fremmed faktisk laster ned), daemonen kjører, og en måle-Dockerfile er
-skrevet. `docker build` ble avvist av tillatelsesklassifisereren i auto-modus, to ganger.
+Byggekonteksten er `git archive HEAD` (311 sporede filer, 3,7 MB), altså **det en fremmed faktisk
+laster ned** — ikke arbeidstreet med `.venv` og lokale artefakter.
 
-Det gjenstående gapet er presist: uv-resolusjon viser at avhengighetene **løser** for linux, ikke
-at koden **importerer og kjører** der. For fase 4d er det forskjellen mellom en Dockerfile vi kan
-shippe og en påstand vi ikke kan stå inne for.
+### 7.1 Bygger og importerer på `linux/amd64`
+
+```bash
+docker build --platform linux/amd64 --build-arg PYVER=3.12 -f Dockerfile.measure -t po-measure:py312 .
+```
+
+Exit 0. `uv sync --frozen --no-dev` resolverte inne i containeren — inkludert de to git-pinnede
+avhengighetene — og siste lag ga `import OK`. Det lukker gapet §3/§4 ikke kunne lukke: uv-resolusjon
+viser at avhengighetene *løser* for linux; dette viser at koden *importerer og kjører* der.
+
+### 7.2 Wheelen er IKKE installerbar alene — målt
+
+Andre måling bygde wheelen, **slettet kilden**, og installerte kun wheelen i et rent miljø. Den
+feilet:
+
+```
+× No solution found when resolving dependencies:
+╰─▶ Because llm-ingestion-guard was not found in the package registry
+    and portfolio-optimiser==1.0.0 depends on llm-ingestion-guard …
+    your requirements are unsatisfiable.
+```
+
+**Dette er den viktigste friksjonsobservasjonen i hele spiken.** Wheelens metadata bærer de to
+avhengighetene som *bare navn*, fordi `[tool.uv.sources]` er uv-konfigurasjon og ikke reiser med
+wheelen. Navnene finnes ikke på PyPI (§3). En nedlaster som får et wheel — f.eks. fra et
+release-objekt, som er fase 3-raden — treffer denne veggen med mindre de to git-kravene oppgis ved
+siden av. Det må stå i installasjonsdokumentasjonen, eller løses ved publisering.
+
+Med direct references ved siden av virker det:
+
+```bash
+uv pip install /dist/*.whl \
+  "llm-ingestion-okf @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v0.3.2" \
+  "llm-ingestion-guard @ git+https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security.git@v0.3.4"
+```
+
+→ `Installed 65 packages`, exit 0.
+
+### 7.3 Fase 4a holder i container
+
+Samme bygg verifiserte pakkede data uten arbeidstre — `/build` var slettet før installasjonen:
+
+```
+pakke:       /app/venv/lib/python3.12/site-packages/portfolio_optimiser
+shared_root: /app/venv/lib/python3.12/site-packages/portfolio_optimiser/_shared
+filer under shared_root: 80
+PAKKEDE DATA OK
+```
+
+`shared/skills/expert-reviewer/SKILL.md` er lesbar derfra. Fase 4a-invarianten — wheelen bærer
+`shared/` som pakkede data, arbeidstreet er kun en overstyring — er dermed målt i den situasjonen
+den ble bygget for, ikke bare i enhetstest.
 
 ---