feat(simulation): the demo now RUNS the Step-7 file inbox it narrates (P1/S1.a)

The Step-7 trace line said "lang fil-løkke" while the verdict arrived as a
function argument (`verdict_input`) — the short, in-run capture. The long loop
was tested but never exercised by the thing on stage.

An expert now drops a real verdict FILE (`write_verdict`) into an inbox between
the runs, and Run B is given `verdict_dir=`, so `run_project` merges it into the
store before the Step-1 fold.

Not done as the plan point was worded, and the difference is load-bearing:
routing the PERSONA verdict through the inbox would have put ONE marker on two
paths — Step 7 (inbox) and Step 8 (promotion) both end in Run B's prompt, so
either could carry it alone and `test_simulation_loadbearing.py`'s promotion
assertion would have stayed green with promotion detached. A second verdict with
its own marker keeps both seams independently red-able; `simulate_learning_loop`
raises when the two markers are equal. The inbox sits beside the bundle copy,
never inside it, and the id is an explicit sentinel (a minted id would collide
with the promoted verdict's, and `VerdictStore.add` is first-write-wins).

766 -> 769 passed (773 collected). Criterion 6 re-measured: stdout byte-identical
across two runs; stderr unchanged at 6 lines. Mutations measured against the full
suite, four red + a green control: detach `verdict_dir=` · point Run B at an empty
folder while the file is still written · marker set to `realization_rate: 0.82`
(measured present in the verdict seed) · marker set to `energy performance gap`
(measured present in a navigated concept file) · benign rename of the inbox dir.

Honesty limit found while measuring: the last two mutations fell on the causality
assertion, not the Run A control — generation prompts carry the debate output, not
the bundle context. The pair holds, but each assert defends a different property.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVYDeJ9evZicgU5r3roZVW

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

@@ -135,7 +135,7 @@ det. Stderr-støyen (to warnings + to «forcing completion») er det første pub
 
 ## 2. Plan FØR demoen (P1–P4, i utførelsesrekkefølge)
 
-### P1 — Steg 7-innboksen kobles på i demoen ☐
+### 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).
@@ -144,6 +144,33 @@ Ny load-bearing-test: detach innboks-lesingen → markør-/Steg 7-linja endres
 **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.py`s 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 ☐
 **[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