feat(fase2a): thread bundle_dir/verdict_dir i run_portfolio — kryssprosjekt-læring load-bearing (S2.0)

src/portfolio_optimiser/data/bundles/bygg-energi-mikro-a/bygg-kontor-a.md

@@ -0,0 +1,22 @@
+---
+type: project
+title: "Kontorbygg A — energibaseline (repo-lokal fixture)"
+description: "Syntetisk energibaseline for den repo-lokale mini-A-bundelen. Ett kontorbygg, ett kandidat-tiltak (LED-retrofit). Utviklings-fixture for S2.0 kryssprosjekt-lærings-testene."
+timestamp: 2026-07-15
+---
+
+# Kontorbygg A (repo-lokal test-fixture)
+
+Et lite syntetisk kontorbygg med én dokumentert energibaseline. Bygget bærer én kandidat-kostpost
+(`ENERGI-TOTAL-EL`) der et energieffektiviseringstiltak (LED-retrofit) kan foreslås og deretter
+deterministisk valideres. Dette er **concept-filen** OKF-navigasjonen leser inn som lese-kontekst
+(og som `bundle_citations` siterer) — den holder bundelen kjørbar på bundle-stien.
+
+## Energibaseline
+
+- Årlig elektrisk energikostnad (`ENERGI-TOTAL-EL`): ~180 000 NOK/år (syntetisk).
+- Kandidat-tiltak: LED-retrofit av 120 lysrørarmaturer i kontorfløy A (90 W → 40 W).
+- Modellert besparelse: ~18 000 NOK/år (innenfor validatorens feasibelt-område).
+
+> Syntetisk fixture — ikke ekte data. En produksjons-deployer erstatter dette med en reell
+> datakilde og ekte HITL-dommer.

src/portfolio_optimiser/data/bundles/bygg-energi-mikro-a/index.md

@@ -19,6 +19,8 @@ fold fyrer på portefølje-stien og en dom fanget på prosjekt *k* materielt nå
 
 ## Innhold (progressiv disclosure)
 
+- [bygg-kontor-a.md](bygg-kontor-a.md) — `type: project` — bygget og energibaseline. Concept-filen
+  OKF-navigasjonen leser inn som lese-kontekst (og `bundle_citations` siterer).
 - [verdict-seed.md](verdict-seed.md) — `type: verdict` — frøsatt realiseringskorreksjon. Ekskludert
   fra lese-konteksten (`bundle_context`); prior dommer når hypotesen KUN via den gatede ExpeL-folden.
 

src/portfolio_optimiser/run.py

@@ -443,8 +443,12 @@ async def run_portfolio(
     """Fan out over a portfolio of independent projects SEQUENTIALLY, composing ``run_project``
     as-is (every project's execution state — meter, debate, retrieval context — is built fresh
     per call, so sequential reuse is inherently isolated). ONE ``VerdictStore`` is threaded
-    across every run, so a verdict on project k informs the ExpeL retrieval of project k+1 (the
-    cross-project learning loop). ``project_ids`` defaults to every loaded project; an unknown id
+    across every run, AND each project's ``bundle_dir``/``verdict_dir`` are threaded into
+    ``run_project`` (Fase 2a S2.0): a bundle-backed project's ``bundle_dir``-gated Step-1 ExpeL fold
+    then folds the store's prior verdicts into its hypothesis prompt, so a verdict captured on
+    project k materially reaches project k+1's hypothesis — the cross-project learning loop is
+    delivered, not merely asserted. ``verdict_dir`` also lets each project merge its async file inbox
+    (Steg 7) on the portfolio path. ``project_ids`` defaults to every loaded project; an unknown id
     raises ``ValueError``. ``meter_factory`` (test seam) supplies a per-project meter — inject a
     shared meter to make the isolation guard go red (SC3).
 
@@ -498,6 +502,8 @@ async def run_portfolio(
             profile,
             docs_dir=project.docs_dir,
             verdict_input=project.verdict_input,
+            bundle_dir=project.bundle_dir,
+            verdict_dir=project.verdict_dir,
             dimension=dimension,
             store=store,
             client_factory=client_factory,