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
This commit is contained in:
parent
d0571ca408
commit
1e11dcb96c
5 changed files with 252 additions and 15 deletions
15
CLAUDE.md
15
CLAUDE.md
|
|
@ -267,6 +267,21 @@ Python ≥3.10. MAF (`agent-framework-core` 1.9.0). Pakkehåndtering: `uv`. To b
|
|||
lever på Claude-SDK-siden (minimal API-kjøring). Skriptet klient = MAF-side stillas, IKKE delt
|
||||
(`shared/` forblir framework-nøytralt). Kjøres `uv run python -m portfolio_optimiser.simulation`.
|
||||
Load-bearing: `tests/test_simulation_loadbearing.py` blir RØD når promoteringen detaches.
|
||||
- **Demoen KJØRER begge tidsskalaer, og de bæres av HVER SIN markør (P1/S1.a):** Steg 7-linja sa
|
||||
«lang fil-løkke», men `simulate_learning_loop` kalte `run_project` UTEN `verdict_dir` — dommen kom
|
||||
som funksjonsargument (`verdict_input`, den KORTE i-kjøring-fangsten). Nå skriver en ekspert en
|
||||
faktisk fil (`write_verdict`) i en innboks MELLOM kjøringene, og Run B får `verdict_dir=`.
|
||||
**Hvorfor en ANDRE markør og ikke persona-dommen gjennom innboksen:** Steg 7 (innboks) og Steg 8
|
||||
(promotering) er to ULIKE mekanismer som begge ender i Run B's hypotese-prompt — med én delt
|
||||
markør kunne hver av dem båret den alene, og `test_simulation_loadbearing.py`s promoterings-assert
|
||||
ville stått GRØNN med promoteringen detached, altså blitt vakuøs. `simulate_learning_loop` raiser
|
||||
derfor `ValueError` når `inbox_marker == marker`. Innboksen ligger VED SIDEN AV bundle-kopien,
|
||||
aldri inni: en dom-fil inne i bundelen når neste kjøring som navigerbar kontekst, som er en annen
|
||||
mekanisme i denne sin forkledning. Sentinel-`id` (aldri myntet) — `_mint_id` hasher kandidat-
|
||||
featurene, så en myntet id kolliderer med den promoterte dommens, og `VerdictStore.add` er
|
||||
first-write-wins per id. Load-bearing MÅLT (`tests/test_step7_demo_inbox_loadbearing.py`), tre
|
||||
mutasjoner røde + grønn kontroll: detach `verdict_dir=` · la Run B lese en TOM mappe · sett
|
||||
innboks-markøren til en verdi som FINNES i bundelen.
|
||||
- **Det skriptede manuset nøkles på PROSJEKT-ID-en, og det er MÅLT:** `scripted_proposer(candidates)`
|
||||
bygger simuleringens proposer fra et `ScriptedCandidate`-register, så et nytt prosjekt er en
|
||||
data-oppføring (demo-uke-plan §4 risiko 2) — ikke et andre håndskrevet manus. **Hvorfor ikke
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue