# P17b — én kommisjon, flere kunnskapsbaser

**Ordre `20260915T014020Z-2912025275-from-.claude` (erstatter P17). Økt 123, 15.09.2026.**
Commits: `5e4c497` (DEL 1) · `da0ccd0` (DEL 2) · `c4e8800` (flaggdekningen) · denne rapporten.

Operatørdirektivet av 14.09: po skal beviselig virke sammen med DE bundlene — flertall — en gitt
kjøring sier den skal bruke. Dette er beviset for flertallsformen, og det er delt i tre: en
CLI-flate som ikke fantes, et kontekstsett som spenner to baser, og én betalt kjøring dømt per base.

---

## 1. Hva som ble målt FØR noe ble bygget

| Premiss | Kilde | Status |
|---|---|---|
| `run_mandate_across_bundles` finnes ferdig | `run.py:2216` | **BEKREFTET** |
| Flaten er unåbar fra CLI | `grep -n across-bundle run.py` = 0 treff | **BEKREFTET** |
| Alle fire kontekstsett har ÉN base | `bundle.txt` = to linjer i alle fire | **BEKREFTET** |
| Suite 1744/5, golden `ea8c534…` | `uv run pytest` | **BEKREFTET** |
| Dry-run-tilbud n200 ≈ 1 512 / r761 ≈ 2 332 | fri drill, § 4 | **BEKREFTET eksakt** |

Ett premiss i ordren ble **presisert**, ikke felt: ordren beskriver «live-dry-run-partisjonen» ved
siden av `report_forbidden` og `--portfolio`-partisjonen, men den tredje raden er ikke en NEKT.
Målt er den generiske `--live-dry-run`-grenen adressert til `args.project_id`/`args.bundle_dir` —
ingen av dem finnes i denne argv-en — så en utelatelse der er et stille DROPP av hele passet, ikke
en nekt. Raden er derfor en **wiring**: drillen går over HVER konfigurert base. Ordren sier selv
det samme i neste setning («skal drille ALLE baser»).

---

## 2. DEL 1 — CLI-flaten

`--across-bundle <dir>`, repeterbar. Krever `--mandate`, `--run-id` og `--outbox-dir`.

**Myntingsregelen `<run-id>-<bundle_id>` er operatørvalgt (14.09), ikke et valg denne økten tok.**
Den står likevel begrunnet, fordi begrunnelsen bestemte FORMEN: motorens egen docstring har siden
økt 58 sagt at N kjøringer trenger N `run_id`-er, og at å mynte dem der ville defaultet en nøkkel
repoet krever at en kaller oppgir. Motoren fikk derfor en **callback**
(`outbox_for(bundle_id) -> (dir, run_id)`), ikke en `outbox_dir`: det er dét kravet OPPFYLT, ikke
slakket, og regelen bor i `main()` der beslutningen ble tatt.

**Ordrens andre alternativ ble MÅLT og forkastet.** En kaller som kjørte `run_project` selv over
`route_by_bundle`s sub-mandater måtte re-implementere fem regler som hver har nøyaktig ett hjem:
id-avstemmingen, den delte `VerdictStore`-en, per-base-prosjektoppslaget (S7b søm 1s presedens),
kollisjonsregnskapet og begge S3.4-tennene. Kø-(p) over en mye større flate enn ett parameter.

`resolve_bundle_routing` er **ÉN oppløsning** delt av motoren og dry-run-armen. En gratis tur som
svarte med en annen `project_id`, eller tolererte en duplisert id den betalte kjøringen nekter,
ville vært en generalprøve på en annen kjøring.

**Samlefila `<outbox>/<run-id>-multibase.json` skrives fra en `finally`** og hver rad bygges av
RESOLUSJONEN + DISK — de konfigurerte basene, kallerens egen myntingsregel, og hver bases egen
`{run_id}-coverage.json`. Den kjøringen som mest trenger regnskapet er den et tak eller en
leverandør kappet, og motorens dokumenterte grense er at en base som RAISER propagerer. `completed`
er et EGET påkrevd felt (`ExplorationTrace.completed`s grunn ordrett): «ingenting ble uoppnådd» og
«vi fikk aldri vite» må ikke være samme verdi. `stop_reason` LESES TILBAKE fra coverage-fila, aldri
utledet på nytt — P19 D2 la faktumet der, og en andre utledning ville stått fritt til å være uenig
med den dommeren leser.

`BudgetExceeded` er i nekt-tuppelen av enkeltprosjekt-stiens målte grunn: den er en `RuntimeError`,
og den FØRSTE tilnærmingen som treffer taket re-raiser ved design. Over flere baser er dét ikke et
kanttilfelle — runde 3 målte `stop_reason: rounds` i 5 av 5 — så uten armen er det vanligste
utfallet av et multi-base-pass en traceback.

### 2.1 Flaggdekningen — et stille dropp jeg selv innførte, målt ETTER den betalte kjøringen

Den første DEL 1-commiten æret fjorten flagg og nektet fem. Det etterlot **åtte akseptert og
droppet**, og det er F4-klassen jeg selv hadde skrevet inn. Verst var `--mcp-config` (konfigurert
egress med ingenting printet, som repoet forbyr utrykkelig) og `PROJECT_ID`/`--docs-dir`, som ville
SETT ut som æret mens dispatchen leste hver bases prosjekt fra DEN basens egen IR-projeksjon.

Rettet i `c4e8800`: `PROJECT_ID`, `--docs-dir`, `--mcp-config`, `--semantic-retrieval`,
`--embedder-config`, `--checkpoint-dir` og `--review-inbox` nektes **ved navn**; de to
forankringsflaggene (`--derive-cost-baseline`, `--require-cost-baseline`) **WIRES**, fordi de er
BASE-anliggender og dispatchen gir `run_project` én base om gangen, så de komponerer eksakt — og
fordi `--require-cost-baseline` er den navngitte løsningen på nøyaktig den defekten denne øktens
egen betalte kjøring målte (§ 5). De to `requires --bundle-dir`-vaktene svarer ikke lenger FOR denne
modusen: gjennomfall ville bedt operatøren legge til det ene flagget modusen også nekter.

### 2.2 Load-bearing, MÅLT

`tests/test_across_bundles_cli_loadbearing.py`, 24 armer. **Fem mutasjoner, alle røde mot HELE
suiten**, grønn kontroll **1781/5** (fra 1744/5, strengt supersett, 0 fjernet), golden
`demo-transcript.stdout` BYTE-UENDRET (`shasum -a 1` av INNHOLDET =
`ea8c534773acdbe41ae68f2c55724d69aaf8be4f`, aldri git-blob-id-en):

| # | Mutasjon | Røde |
|---|---|---|
| (i) | samlefila droppes | 2 |
| (ii) | myntingen kollapser til bart `<run-id>` | 3 |
| (iii) | `report_forbidden` slipper flagget stille | 1 |
| (iv) | `opened`/`requirements`-sinkene deles mellom basene | **5** (fire i tester ELDRE enn dette arbeidet) |
| (v) | forankringskravet når dispatchen, aldri per-base-kjøringene | 1 |

Mutasjon (iv) er den sterkeste: fire av de fem røde ligger i
`test_debate_navigation_cost_loadbearing`, `test_prepass_run_seam_loadbearing` og
`test_scripted_explore_door_loadbearing` — uavhengige vitner på at sinkene er per kjøring.

**En arm måtte skrives om under målingen.** (v) ble først skrevet som «`--require-cost-baseline`
nekter», men på fixturene har `tunnel-hauglia` en `cost-baseline.json` og `bygg-energi-mikro` ikke.
En arm som bare asserterte rc 1 kunne ikke skille «flagget virket» fra «ingen av dem er forankret»;
den asserterer nå at INGEN artefakter ble skrevet (nekten fyrte før betalingen) og har en kontroll
på at samme argv uten flagget kjører til rc 0.

---

## 3. DEL 2 — femte kontekstsett, `contexts/dekke-og-kontrakt-lindaas-2027`

Fire tilnærminger over TO baser: a1 (forsterkningslag) og a2 (filterlag) mot `n200-2024`,
a3 (riggomfang) og a4 (`must_refuse`, indeksregulering) mot `r761-2025`.

`bundle.txt` fikk **én blokk per base**; hver `name:` åpner en blokk, hver blokk må lukkes med sin
egen `bundle_id:`. Et sett som navngir ÉN base er én blokk, så de fire eldre filene parses
byte-identisk — multi-base-formen er en utvidelse, ikke et nytt format.

**Leseren har nå ETT hjem.** Den hadde to private kopier: én i P14-gaten og én løsere inne i
`stress.main`. Multi-base-formen er nøyaktig endringen som ville latt dem drifte til to svar om ett
sett (kø-(p)). Begge kaller nå `stress.read_bundle_declarations`.

**Regel U ble UNIONEN av hver erklærte base, og det er ingen formalitet.** MÅLT 15.09: `enhetspris`
er fraværende fra n200-2024 og båret av **70 av r761-2025s 2 756** konsepter. Ankre admittert per
base ville derfor admittert et spørsmål passet som HELHET kan grunne. Ordet ble forkastet fra
settets ankre av den grunnen, og målingen står i settets eget `honesty`-felt.

**Dommeren dømmer per base, og får vite hvilken.** `score_context_set(bundle_id=…)` begrenser til
tilnærmingene rutet dit. Uten det rapporterer dommingen av n200-utboksen r761-tilnærmingen som
`not_evaluated`/`absent` — et **falskt funn**, for den tilnærmingen BLE evaluert, mot den andre
basen, under den andre `run_id`-en. Ordren tilbød en `--multibase <samlefil>`-modus; målt mot formen
artefaktene faktisk tar, har hver per-base-kjøring allerede sitt fulle artefaktsett og sin egen
`run_id`, så det dommeren manglet var ikke en ny fil å lese, men det ene mandatet allerede vet.
`stress`-CLI-en NEKTER å gjette når et sett erklærer flere baser (`--bundle`, med rc-0-kontroll).

Arm (d) fikk en andre halvdel: hver ERKLÆRT base må navngis av en tilnærming, fordi en base ingen
tilnærming navngir aldri kjøres (`route_by_bundle`s egen regel).

**Seks mutasjoner, hver rød på sin egen arm** (grønn kontroll 45 armer i P14-gaten):
M1 fasit-sti basen ikke bærer (2 røde) · M2 tilnærming rutet mot en uerklært base (3) ·
M3 anker r761 FAKTISK bærer — `enhetspris` (1, ALENE på regel U) · M5 erklært `bundle_id` driftet
(4) · M6 registrert tittel driftet (1) · dommer-restriksjonen detached (2, pluss de to nye
stress-armene). P14s egne kjent-positiver er fortsatt røde.

**P19/B2-nevneren flyttet 26 → 32** og ASSERTERES, ikke droppes: seks nye referanser, hvorav to
bare `prosessnr` (`12.11`, `12.12`) — B1s punktum-og-siffer-form er nå øvet av en fasit og ikke
bare av en kjent-positiv.

---

## 4. DEL 3a–3b — instrumentet, og den frie drillen

Klientproben `tests/test_foundry_profile_live.py`: **1 passed** (ikke skipped), endepunktet hentet
INLINE fra `az`, aldri i sporet fil.

Den frie drillen over begge basene, `--max-rounds 3 --max-tokens 600000`:

| Base | `project_id` (og hvorfra) | Forankret | `Grounding offer` |
|---|---|---|---|
| `vegnormal-n200-2024` | fra basens ERKLÆRTE `bundle_id` (`declared-index`) | NEI | **1 512** identifikatorer / **0** kostlinjer over 1 442 150 tegn |
| `vegnormal-r761-2025` | fra basens ERKLÆRTE `bundle_id` (`declared-index`) | NEI | **2 332** identifikatorer / **0** kostlinjer over 6 562 243 tegn |

Begge tallene treffer ordrens forhåndsmålte anslag eksakt. **Ingen av de to basene har
`validator-input.json`**, så `project_id` faller tilbake på den erklærte `bundle_id`-en — S7b søm
1s presedens, og grunnen til at dispatchen ikke tar noen `project_id` i argv: en kaller-oppgitt
konstant kunne uansett bare vært riktig for én base av N. Begge basene erklærer dessuten en id som
er ULIK monteringsnavnet (`vegnormal-n200-2024` vs `n200-2024`), og kjøringen SIER det —
S7a-3-varselet, per base.

---

## 5. DEL 3c–3d — den betalte kjøringen

Én kommisjon, to baser, `--profile azure --max-rounds 3 --max-tokens 600000`, rc **0**.
Veggtid **453 s** totalt (n200 139 s, r761 314 s; lest av artefaktenes mtime).

### 5.1 Per base

| | `vegnormal-n200-2024` | `vegnormal-r761-2025` |
|---|---|---|
| `token_usage` | **217 326** | **340 019** |
| `stop_reason` | `""` (ingenting kappet den) | `""` |
| parse-feil | **0** (ingen `-parse-failures.json`) | **0** |
| `filter_calls` / `paged_calls` | 10 / 13 | 13 / 5 |
| verktøykall | 40 | 46 |
| gjettede lesestier | **9** | **3** |
| konsepter i basen | 1 133 | 2 756 |
| siteringer stemplet | 2 266 (`whole-base`) | 5 512 (`whole-base`) |

`collisions: []`, `unreached: []`, `stopped_early: false`, `completed: true`.

**Runde 3s dominerende funn gjentok seg IKKE.** Der målte P19 `stop_reason: rounds` i 5 av 5 og
`kontrakt-sorasen-2027-04` døde etter 11 parse-feil; her er begge basene `""` med null parse-feil.
Det er ett datapunkt, ikke en motsigelse av P19 F3/F4 — det er en annen kommisjon over andre baser —
men det er verdt å skrive ned at taket ikke bandt her.

### 5.2 Dom per tilnærming

| Tilnærming | Base | Utfall | Kode foreslått | Grunnet | `requirement_hit` | `named` | Hallusinasjoner | `prose_codes` |
|---|---|---|---|---|---|---|---|---|
| a1-tynnere-forsterkningslag | n200 | rejected | `forsterkningslag_m3` | nei | nei | nei | `code:forsterkningslag_m3` | `forsterkningslag_m3` |
| a2-filterlag-sprengstein | n200 | rejected | `510-100` | nei | nei | nei | `code:510-100` | — |
| own-proposal | n200 | rejected | `GROUND_INV`, `GEO_DESIGN` | nei | — | — | — | — |
| a3-riggomfang | r761 | rejected | `R761-Prosesskoden-rigg` | nei | nei | nei | `code:R761-Prosesskoden-rigg` | — |
| **a4-indeksregulering** | r761 | **validated** | `1.10.4` | nei | nei | nei | `code:1.10.4` | — |
| own-proposal | r761 | rejected | `TMP_TRAFFIC_MGMT`, `TEMP_CONS_ROADS` | nei | — | — | — | — |

Fem av seks forslag falt på P7s stadium 0b (ugrunnet identifikator) — nøyaktig det
`Grounding offer` forutsa på den FRIE turen: 0 kostlinjer i begge basene, så hver kode proposeren
finner på blir avvist.

**Falsifiseringsarmen a4 SLAPP GJENNOM.** `must_refuse` feiler: `a4-indeksregulering was VALIDATED
— the base carries no ground for it`. Koden er `1.10.4` — et R761-**prosessnummer**, altså
nøyaktig P19 F1 («kravnummer godtas som kostkode»), nå reprodusert på en andre base og med en andre
identifikatorform. Ordren sa: rapportér, fiks ikke. Det er gjort.

**Løsningen finnes og er nå MÅLT på disse to basene** (fritt, § 2.1 wiret den):
`--across-bundle × 2 --require-cost-baseline` gir **rc 1 på 2,1 s, null modellkall, null
per-base-artefakter**, og samlefila står igjen med `completed: false` og `stop_reason: absent` for
begge. Å slå den på er en OPERATØRBESLUTNING, ikke min: den ville nektet begge basene før første
kall, altså gjort hele denne målingen ukjørbar.

### 5.3 Kryss-base-læring (P14 § 4.1) — nei, og hvorfor

**Base 2 SÅ IKKE base 1s dom, fordi ingen dom ble myntet.** Kjøringen ble startet uten
`--decision`/`--rationale`, og F2 (økt 66) er at stillhet mynter INGEN `Verdict` — stdout sier det
per base: `no expert verdict given (verdict key=…)`. `VerdictStore`-en var altså tom hele veien, og
`collisions: []` er sant av samme grunn.

Det er en egenskap ved KJØRINGEN, ikke ved sømmen. At sømmen bærer, er bevist gratis og offline av
`test_the_second_base_sees_the_verdict_the_first_base_minted`: den kjører CLI-en over to baser med
`--decision/--rationale`, asserterer at de to kjøringene fikk SAMME store-objekt (`is`, aldri `==` —
`VerdictStore` er en pydantic-modell med verdi-likhet, så tre tomme stores er alle like: økt 58s
målte vakuitet), og at base 2 startet med base 1s dom-id allerede i den. En fersk-store-per-base-
implementasjon kan ikke produsere det.

### 5.4 Hva én kjøring over to baser kjøpte mot to enkeltkjøringer

Målt, ikke antatt:

1. **Én kommisjon, ett regnskap.** Samlefila gir rekkefølge, per-base `run_id`, `unreached`,
   `collisions`, `budget_stop` og per base `stop_reason` i én fil. To enkeltkjøringer gir to
   utbokser og ingen som sier at de hørte sammen.
2. **Ruting i stedet for kopiering.** Mandatet skrives ÉN gang; `route_by_bundle` partisjonerer det.
   To enkeltkjøringer krever to mandatfiler, og to kopier av et mandat er kø-(p) på operatørens
   flate.
3. **Én delt `VerdictStore` er MULIG** (ikke utøvd her, § 5.3). To enkeltkjøringer kan ikke dele
   den i det hele tatt uten en Steg-7-innboks imellom.
4. **Ingen tokengevinst.** 557 345 tokens er det samme to enkeltkjøringer ville brukt; hver base
   navigeres for seg. Dette er en regnskaps- og rutingsgevinst, aldri en kostnadsgevinst.

### 5.5 Kostnad

**557 345 målte tokens** (217 326 + 340 019) ≈ **NOK 4**. **UTTALT ANTAKELSE:** anslaget bruker
samme regnestykke som P19 (listepris for `gpt-4-1-mini`, prompt og completion ikke skilt), fordi
`provenance.token_usage` er kjøringens ENE teller og ikke deler dem. Ingen faktura er lest.

---

## 6. Funn som står igjen, hver med en navngitt løsning

| # | Funn | Løsning | Anslag |
|---|---|---|---|
| **F1** | `1.10.4` (R761-prosessnummer) godtas som kostkode; a4 valideres. P19 F1 reprodusert på base nr. 2 | `--require-cost-baseline` — MÅLT her: rc 1, 2,1 s, 0 modellkall. **OPERATØRBESLUTNING**, 0 kodelinjer | 0 |
| **F2** | `requirement_hit` 0/4. Begge basene erklærte ETT krav hver, to ganger, og ingen av dem var fasitens | P19 F2 uendret — instruksjonen ber om erklæringen, ikke om at den skal være den bindende. Egen ordre | ~1 økt |
| **F3** | 12 gjettede lesestier (9 + 3) tross P18/A3s navngitte nekt | Nekten VIRKER (den navngir nærmeste listbare katalog); det som mangler er at modellen bruker svaret. Måling, ikke kode | ~0,5 økt |
| **F4** | `citation_scope: whole-base` i begge basene, så (a)-grunning kan bare komme av ÅPNEDE stier — og `opened` er tom for hver rad | Et erklært pre-pass-kutt (`--prepass-payload`) er den ene formen som smalner siteringslista. Uavklart om det passer en multi-base-kjøring: egen ordre | ~1 økt |
| **F5** | `announce` sier «the portfolio» når ingen `project_id` er gitt, også i across-bundle-modus | Én linje: la den navngi de rutede basene. Kosmetisk, men det er en påstand flaten gjør om seg selv | ~0,2 økt |

---

## 7. Ærlighetsgrenser, uttalt

- **En base som RAISER propagerer.** Motorens egen dokumenterte grense — `collect-and-continue`
  tilhører `run_portfolio`, der kalleren sendte inn en batch uavhengige prosjekter. De etterfølgende
  basene kjøres da ikke, og samlefila sier `completed: false`. Ikke truffet i denne kjøringen.
- **Ingen tokengevinst** (§ 5.4 pkt. 4). Flertallsformen er ruting og regnskap.
- **Kryss-base-læring ble ikke UTØVD betalt** (§ 5.3), bare gratis og offline.
- **Ett datapunkt.** Én betalt kjøring, én modell, ett deployment, ett konstruert prosjekt. At
  `stop_reason` var tomt her motsier ikke P19 F3.
- **Prosjektet fv. 218 Lindås er OPPDIKTET** — navn, lengde, ÅDT og alle fire kostlinjene. Kravene
  og prosessene i fasiten er lest ordrett ut av basenes egen frontmatter. Settets eget
  `honesty`-felt sier det samme.
- **Den hostede flaten er BEVISST urørt.** `--across-bundle` er i ingen av hostings tre sett, så den
  generiske 400-en svarer og Fase 4es to halvdeler står.
- **`--proposal-review` trås gjennom til ÉN terminal** delt av alle basene (motorens egen
  begrunnelse: dispatchen er sekvensiell, og forespørselen bærer både approach-label og
  `project_id`). Ikke utøvd betalt.
- **`tests/test_scripted_explore_door_loadbearing.py` er uformatert ved HEAD** og er IKKE rørt —
  pre-eksisterende drift, ikke min å rydde i en annen ordre (kirurgiske endringer).

---

## 8. Reproduksjon

```bash
source scratchpad/p19/env.sh          # endepunktet hentes INLINE fra az, aldri fra fil
uv run pytest tests/test_foundry_profile_live.py -q          # skal gi 1 passed

uv run python -m portfolio_optimiser.run \
  --across-bundle ~/repos/vegnormal-okf/build/ferdig/n200-2024 \
  --across-bundle ~/repos/vegnormal-okf/build/ferdig/r761-2025 \
  --mandate contexts/dekke-og-kontrakt-lindaas-2027/mandate.json \
  --run-id lindaas-01 --outbox-dir scratchpad/p17b-multibase/lindaas \
  --profile azure --max-rounds 3 --max-tokens 600000

for b in n200-2024 r761-2025; do
  uv run python -m portfolio_optimiser.stress contexts/dekke-og-kontrakt-lindaas-2027 \
    --outbox-dir scratchpad/p17b-multibase/lindaas \
    --run-id "lindaas-01-vegnormal-$b" --bundle "$b"
done
```

Artefaktene fra denne kjøringen ligger i `scratchpad/p17b-multibase/` (usporet).