portfolio-optimiser/docs/2026-09-12-p13-okf-pin-r761.md

P13 — okf-pinnen v0.3.2 → v0.8.5 vurdert og målt, R761 gratis-navigasjon

Dato: 2026-09-12. Ordre 20260912T190444Z-8080128610-from-.claude. Forberedelse til stresstesten fra 18.09. Ingen modellkall, ingen Azure, NOK 0.

---

§ 0 — Hva som ER målt og hva som IKKE er det

Målt i denne økten

#	Påstand	Hvordan
1	po sender ALDRI llm_ingestion_okf.parse_frontmatter-retur videre til en YAML-leser	grep over src+tests: 53 parse_frontmatter-treff, ALLE mot po sin egen okf.py:125; 0 import yaml noe sted
2	Upushede commits = 0 (STATE påsto 3)	git log --oneline origin/main..main | wc -l
3	Innboksen hadde 2 meldinger (STATE påsto tom)	ls ~/.claude/coord/portfolio-optimiser/inbox/
4	okf v0.8.5 + guard v1.4.0 resolverer, installerer og importerer	uv lock/uv sync i worktree, 27/27 navn
5	Bumpen gjør 9 tester røde, alle fra ÉN emittert linje	full suite i worktree
6	Bumpen gjør write_concept_file-forfalskningsvakten INERT, uten at én test merker det	direkte kall på _carries_complete_ingest_stamp
7	R761 navigeres på 6,9–8,6 s / 131 MB, 5 514 filer, 0 hopp	/usr/bin/time -l, tre kjøringer
8	N100 navigeres på 0,20–0,22 s / 111 MB, 450 filer, 0 hopp	samme
9	--bundle-dir tar ÉN katalog; multi-base finnes kun som bibliotek-funksjon	grep på bundle_dirs= og run_mandate_across_bundles

IKKE målt

• Ingen levende modell har kjørt mot R761. Veggtid og RSS er navigate_bundle alene — ikke read_bundle, ikke list_bundles, ikke token-kostnad, ikke prompt-antall. At en modell navigerer R761 godt er ikke berørt (structured-output-grensens klasse).
• Bumpen er ikke landet, så ingen kjøring har brukt okf 0.8.5 i po. Alle tall om bumpen er fra worktreet.
• Guard-kalibreringen er målt kun gjennom suiten. test_ingest_content_gate_loadbearing sto grønn på 1.4.0, altså holder _ACCEPTED_DISPOSITION = "warn" for de dokumentene den kjører. Et bredere korpus er ikke prøvd.
• Ingen av de fire vegnormal-bundlene er gitt til en po-kjøring. § 3.2 er en beskrivelse av flaten som finnes, ikke en måling av at fire baser virker sammen.
• --docs-dir-ruten for «resten av basene» er IKKE prøvd — se ærlighets-grensen i § 3.2.

---

§ 1 — Innboks og STATE-avvik (DEL 1)

1a — de to meldingene fra llm-ingestion-okf

Begge reply-expected: no, begge lest i sin helhet, begge lukket med coord-done (ingen svar sendt: ingenting er bedt av po, og begge er rene FYI-er).

Melding	Innhold	Konsekvens for po
…145106Z… (K3-24)	Blokkform-sources leses nå av alle tre flate lesere i okf. Anbefaler consume.read_sources for tre-tilstands-svaret. Sier eksplisitt at po sin read_provenance (som svarer UnreadableProvenance(reason="block-sequence")) er grunnen okf ikke flyttet emitteren til blokkform.	Ingen. po kaller ingen av okf sine lesere.
…174754Z… (v0.8.5 tagget)	okf.parse_frontmatter returnerer nå en flow-STRENG for blokk-sources der den ga tom streng. Advarer: kode som sendte returverdien rett til en YAML-leser får nå en parse-feil.	Ingen. Se måling 1 under.

Måling 1 — sender po parse_frontmatter-retur til en YAML-leser? Nei, og ikke fordi po er forsiktig, men fordi po aldri kaller funksjonen.

grep -rn "parse_frontmatter" src tests   -> 53 treff

Alle 53 er okf.parse_frontmatter / portfolio_optimiser.okf — po sin EGEN linjeorienterte leser (src/portfolio_optimiser/okf.py:125). grep -rn "llm_ingestion_okf" src gir 9 treff, fordelt på nøyaktig to filer (ingest.py, ingest_mcp.py), og parse_frontmatter er ikke blant navnene som importeres. grep -rn "import yaml\|yaml.safe_load\|yaml.load" src tests gir 0. po har ingen YAML-leser i det hele tatt, så den beskrevne regresjonen har ingen sti hit.

1b — STATE-avvikene rettet

STATE påsto	Målt 12.09	Kommando
«UPUSHET = 3 (c623498, a629902, 9f14c64); ls-remote = 6eb58e5»	0 upushet; ls-remote origin main = 9f14c64 (= lokal HEAD)	git log --oneline origin/main..main | wc -l
«📬 INNBOKS TOM (= 0)»	2 meldinger, begge fra llm-ingestion-okf, begge nå lukket	ls ~/.claude/coord/portfolio-optimiser/inbox/

Operatøren pushet altså etter at STATE ble skrevet, og to meldinger landet etterpå. Begge er rettet i STATE.

---

§ 2 — okf-pinnen v0.3.2 → v0.8.5 (DEL 2)

2a — utgangspunktet

pyproject.toml:68  llm-ingestion-okf   = { git = ...llm-ingestion-okf.git, rev = "v0.3.2" }
pyproject.toml:72  llm-ingestion-guard = { git = ...pipeline-security.git, rev = "v0.3.4" }
uv.lock            okf v0.3.2 = f14c075 · guard v0.3.4 = adf93e47
installert          okf 0.3.2 · guard 0.3.4

okf v0.8.5 (pyproject.toml fra taggen) erklærer dependencies = ["llm-ingestion-guard>=1.2,<2.0"] — guarden er okf sin ENE runtime-avhengighet, så å løfte okf TVINGER guarden opp.

Guard-tagger som finnes (git ls-remote --tags): 0.1.0 … 0.7.0, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0. Laveste som tilfredsstiller >=1.2,<2.0 er 1.2.0.

PREMISS FELT (1 av 2): «laveste 1.x» er ikke valgbar. okf v0.8.5 pinner guarden i sin EGEN [tool.uv.sources] til tag = "v1.4.0", og uv behandler det som et direkte-URL-krav. Med po på v1.2.0:

x Failed to resolve dependencies for `llm-ingestion-okf` (v0.8.5)
  Requirements contain conflicting URLs for package `llm-ingestion-guard`
  - ...pipeline-security.git@v1.4.0
  - ...pipeline-security.git@v1.2.0

PREMISS FELT (2 av 2): rev = og tag = er ULIKE URL-er for uv, selv med samme verdi. Med po på rev = "v1.4.0" — altså samme tag som okf — nekter uv fortsatt, og skriver ut to identiske strenger som «conflicting». Først tag = "v1.4.0" resolverer. Konsekvensen for en framtidig bump er en konkret skrivemåte, ikke et valg: po må skrive tag = "v1.4.0", ikke rev =, og ikke en lavere 1.x.

Guardens brudd mot po sine fire importer (Channel, Origin, format_log_entry, import_bundle). Ingen. Guardens CHANGELOG [1.0.0] fryser den eksporterte flaten under semver — «no name exported from llm_ingestion_guard is removed, renamed or given a different meaning without a 2.0.0», og målt før taggen: «four names added, none removed or renamed» siden 0.3.4. Men samme seksjon holder deteksjons-ATFERD utenfor frysen: «Severities, thresholds, lexicon entries and the dispositions they produce are calibration, and calibration moves in minor and patch releases.» Det er nøyaktig det ingest._ACCEPTED_DISPOSITION = "warn" hviler på (ingest.py:235-239). Målt utfall: test_ingest_content_gate_loadbearing sto GRØNN på guard 1.4.0, så kalibreringen har ikke flyttet seg for de dokumentene den kjører — men det er en måling med en smal nevner, ikke en garanti.

2b — rød test først (Iron Law)

tests/test_okf_version_guard.py skrevet mot målet v0.8.5/v1.2.0 og kjørt FØR noen produksjonskode ble rørt: 3 failed / 2 passed på dagens installasjon (de to installerte versjonene + pyproject- halvdelen røde). Dermed er vakten bevist i stand til å bli rød.

2c — målingene i worktree

Alt under kjørt i git worktree add --detach (aldri i det sporede treet). Kontrollkjøring FØR bumpen, samme worktree: 1579 passed / 3 failed / 5 skipped, der de tre røde er vaktens egne. 1577 (STATE-basislinje) + 2 grønne vakt-armer = 1579, altså er kontrollen avstemt mot basislinjen.

Én forstyrrelse måtte ryddes først, og den er en egenskap ved WORKTREET, ikke ved bumpen: test_package_leaks_no_local_or_secret_files har en KONTROLL på at STATE.md finnes lokalt (ellers kan gaten ikke diskriminere), og STATE.md er local-only, altså ikke i et worktree. Kopiert inn → 10/10 grønne. Uten den kopien ville nevneren vært 1 for lav.

(i) Importerer alle navnene fortsatt? JA — 27 av 27. Ordren sa «13 navn»; den målte nevneren er 27 fordelt på fem moduler (14 fra llm_ingestion_okf, 5 …connectors, 1 …manifest, 3 …render, 4 llm_ingestion_guard.okf). 0 manglende.

(ii) Hele suiten: 1573 passed / 9 failed / 5 skipped. IKKE grønn.

(iii) Begge demo-goldener BYTE-UENDRET. ea8c534773acdbe41ae68f2c55724d69aaf8be4f (stdout) og ede3e2f685ce6a14ad9888e9de421d1a66f6c611 (stderr) — shasum -a 1 av INNHOLDET, ikke git-blob-id.

(iv) De tre portene: ruff check --exclude scratchpad → All checks passed! · mypy src → Success, 37 filer · ruff format --check → 211 filer formatert, 1 ville reformateres, og det var vaktfila jeg nettopp hadde skrevet (rettet i det sporede treet).

(v) Door A-goldenen: ETT avvik, én linje, rad for rad.

--- examples/ingest-golden-file/expected-bundle/ingest-costs.md
@@ -8 +8 @@
-generated: true
+generated: { by: process:okf-ingest, at: 2026-07-03T12:00:00Z }

Identisk diff i alle sju genererte konseptfiler. Dette er pre-V1 → V1-formen ordren forutså, og det er samme flow-mapping guarden åpnet for i sin 1.2.0.

Alle ni røde tester, med årsak:

#	Test	Årsak
1	test_ingest_golden::…bit_deterministic	byte-diff, ingest-costs.md + ingest-edge.md
2	test_ingest_golden_http::…	byte-diff, ingest-report.md + ingest-status.md
3	test_ingest_golden_sql::…	byte-diff, ingest-costs.md + ingest-meta.md
4	test_ingest_golden_mcp::…	byte-diff, ingest-cost-docs.md
5	test_ingest_loadbearing::test_every_generated_file_carries_the_provenance_layer	fm["generated"] == "true"
6	test_ingest_materialize::test_provenance_roundtrips_via_unchanged_parse_frontmatter	samme assert
7	test_ingest_mcp::test_mcp_source_materializes_a_bundle_through_the_http_family	"generated: true" in text
8	test_ingest_sql::test_sql_manifest_materializes_with_provenance	fm["generated"] == "true"
9	test_okf_version_guard::test_pyproject_pins_both_revisions	vaktens egen konstant (v1.2.0 → v1.4.0)

Åtte av ni har SAMME enkeltårsak. Alle sju golden-filene ligger under po sin egen examples/ — 0 under shared/, altså treffer en framtidig bump ikke den pull-only subtree-kontrakten.

2c′ — FUNNET som avgjør: forfalskningsvakten går INERT, og suiten sier ingenting

okf._carries_complete_ingest_stamp (okf.py:1239) er halvdelen av invarianten «kuraterte skrivere kan ikke forfalske ingest-stempelet»: write_concept_file reiser IngestStampError når frontmatter bærer BEGGE halvdeler av eierskaps-stempelet. generated-halvdelen leses mot _YAML_TRUE_LITERALS = {"true", "yes", "on"}.

Målt på guard 1.4.0 / okf 0.8.5:

pre-V1 form  ({"generated": "true", ...})                                -> True
V1 flow-mapping ({"generated": "{ by: process:okf-ingest, at: ... }"})  -> False

Emitteren skriver nå nøyaktig den formen vakten IKKE gjenkjenner. Konsekvensen er at en kuratert skriver kunne skrevet generated: { by: … } + ingest_manifest og ikke blitt nektet — vakten slutter å vokte. Og test_ingest_stamp_fail_closed_loadbearing.py sto GRØNN gjennom hele bump-kjøringen, fordi den bruker literalformene. Dette er ordrett den fella invariant-raden i CLAUDE.md ble skrevet for: «en fremtidig uv sync mot en skrivemåte som yes/on ville latt vakten slutte å vokte uten én lokal diff» — bare med en annen skrivemåte enn den forutså.

Dette er ikke «et avvik å navngi rad for rad». Det er en gate som slutter å gate, og den er ikke dekket av noen test.

2d — BESLUTNING: INGEN BUMP

(ii) er rød, og 2c′ er den ekte grunnen: å lande bumpen nå ville shippet en avvæpnet sikkerhets-invariant med suiten grønn på nøyaktig den sømmen. Ordrens regel er fulgt («Er noe rødt: INGEN bump»), og begge utfall er godkjent leveranse.

Hva som må endres i po FØR bumpen kan landes — komplett, målt liste:

1. okf._carries_complete_ingest_stamp + _YAML_TRUE_LITERALS må gjenkjenne V1-flow-mapping- formen i tillegg til literalene. FØRST — dette er den eneste raden som er sikkerhetsbærende.
2. tests/test_ingest_stamp_fail_closed_loadbearing.py utvides med en mutasjon for den nye formen, ellers gjentar raden 1 seg ved neste emitter-endring.
3. 7 golden-konseptfiler regenereres (1 linje hver): examples/ingest-golden-file/expected-bundle/ ingest-costs.md, ingest-edge.md · …-http/…/ingest-report.md, ingest-status.md · …-sql/…/ingest-costs.md, ingest-meta.md · …-mcp/…/ingest-cost-docs.md. Regenerering er en BESLUTNING, ikke opprydding — de pinner formen Door A ble målt mot.
4. 4 tester som asserterer generated == "true": test_ingest_loadbearing, test_ingest_materialize, test_ingest_mcp, test_ingest_sql.
5. 2 prosa-steder som navngir den gamle formen: ingest_mcp.py:29, okf.py:1278.
6. pyproject.toml: okf rev = "v0.8.5" OG guard tag = "v1.4.0" — tag=, ikke rev=, og ikke v1.2.0 (§ 2a).
7. pyproject.toml:40-kommentaren («zero runtime deps») er allerede usann for v0.8.5 og må rettes i samme trekk: okf-kjernen har nå ÉN runtime-avhengighet, guarden.
8. tests/test_okf_version_guard.py: pinnene og kostnads-meldingene oppdateres.

Punkt 7 er IKKE rettet nå. Kommentaren beskriver den pinnede v0.3.2, som faktisk har null runtime- avhengigheter; å skrive om den mens pinnen står ville gjort den usann i den andre retningen.

Leveransen fra DEL 2 er tests/test_okf_version_guard.py, som nå pinner det MÅLTE (0.3.2/0.3.4) i to halvdeler — installert distribusjon + pyproject — og hvis nekt-meldinger NAVNGIR kostnaden over, slik at neste økt ikke løfter pinnen uten å re-måle.

Fire mutasjoner, hver med sin egen signatur, alle røde, deretter restaurert grønn:

#	Mutasjon	Utfall
M1	okf-asserten reiser aldri	1 rød (nekt-armen)
M2	okf-asserten reiser alltid	1 rød (installert-kontrollen)
M3	guard-asserten reiser aldri	1 rød (guardens nekt-arm)
M4	pinne-konstanten drives til 0.3.3	2 røde — installert-armen OG pyproject-armen, altså er avledningen levende og ikke to literaler

Sporet tre: 1582 passed / 5 skipped (fra 1577/5, strengt supersett, 0 fjernet) · begge goldener byte-uendret · ruff check All checks passed · ruff format 212 filer · mypy 37 filer.

---

§ 3 — R761 gratis-navigasjon (DEL 3)

3a — målingene

portfolio_optimiser.okf.navigate_bundle, tre kjøringer hver, /usr/bin/time -l. po hadde ALDRI sett R761 før denne økten (grep -rln "R761\|r761" docs src tests = 0).

Base	Navigasjon (s)	Prosess-real (s)	Maks RSS (MB)	files	context_files	verdicts	skipped
n100-2023	0,219 · 0,201 · 0,210	2,01 · 2,03 · 2,06	110,9 · 111,2 · 111,4	450	446	0	0
r761-2025	8,580 · 6,889 · 7,108	10,39 · 8,59 · 9,03	131,2 · 131,1 · 131,9	5 514	2 756	0	0

Prosess-real inkluderer ~1,8 s tolkerstart (uv run python); navigasjonstallet er perf_counter rundt navigate_bundle alene.

Avstemming av nevneren. R761 på disk: 2 758 index.md + 2 756 andre .md = 5 514 filer i 2 758 kataloger. navigate_bundle når alle 5 514 og hopper over null lenker; context_files = 2 756, altså faller nøyaktig de 2 758 nestede/rot-indeksene bort (navigasjon, ikke innhold), og verdicts = 0. Ordrens «2 757 seksjoner» = de 2 757 underkatalogene; den målte konsept-tellingen er 2 756.

Leseretning. R761 er ~12× N100 i filer og koster ~34× i navigasjonstid (7,1 s mot 0,21 s) men bare +18 % RSS (131 mot 111 MB). Tiden er I/O-dominert (sys-tid 2,7–3,1 s mot N100s 0,35 s; 2 758 katalog-traverseringer), ikke minne. Ingen av dem er i nærheten av et problem for en gratis oppstart: verste målte navigasjon av R761 er 8,6 s, én gang per verktøykall.

Ikke målt her, og det er den interessante kostnaden: hva R761 koster i TOKENS gjennom stigen (list_bundles → read_bundle → read_dir → read_file). S7a-3 målte K2s 629 konsepter til 42 761 o200k-tokens i flat form, og hierarkiet tok rota ned til 1 495. R761 har 4,4× så mange konsepter som K2, og det tallet er ikke tatt.

3b — hvordan fire bundler gis til ÉN kjøring i dag

Målt flate, ikke forslag:

• --bundle-dir tar ÉN katalog (run.py:2444). CLI-en mater utforskningen med en 1-tuppel: bundle_dirs=(args.bundle_dir,) (run.py:3606) — det er det eneste bundle_dirs=-kallstedet i hele run.py.
• run_mandate_across_bundles (run.py:2124) TAR N baser og partisjonerer et mandat over dem via mandate.route_by_bundle, men har ingen CLI-flate: ingen kaller i main(), kun tester og explore.py-prosa refererer den. Dette er den bevisste grensen fra multi-base-raden.
• --docs-dir er en ANNEN søm: den mater retrieve_chunks/make_retrieval_tool (run.py:1194/1204), altså keyword-chunk-henting — ikke OKF-navigasjon. På bundle-stien settes docs_dir=bundle_dir (run.py:678, :2263).
• Repeterbart --bundle-dir er NEI i STATE og bygges ikke her.

--mandate-JSON-formatet (run.py:2459, mandate.py) — utgangspunktet for «hva man ønsker å optimalisere på»:

{
  "objective": "<fri prosa: hva kjøringen er til for>",
  "allow_own_proposals": true,
  "success_criteria": ["<fri prosa>", "..."],
  "approaches": [
    {
      "id": "<unik, ikke 'own-proposal'>",
      "label": "<ekspertens ord; blir SavingsProposal.measure VERBATIM>",
      "description": "<ekspertens begrunnelse; går ordrett i proposer-prompten>",
      "affected_codes": ["<kostkode>", "..."],
      "claimed_saving_nok": 0,
      "bundle_id": "<rutingsnøkkel; tom = 'ingen base navngitt'>"
    }
  ]
}

Approach.bundle_id ER multi-base-nøkkelen og finnes allerede, default "". Tallmålet hører IKKE hjemme her — det bor i contracts.GoalContract / --goals.

Hva P14 må VELGE mellom (ikke avgjort her):

Alternativ	Hva det koster	Hva det kjøper
(a) Én bundle per kjøring, fire kjøringer	Fire run_id-er, fire utbokser, ingen kryss-base-læring i én VerdictStore med mindre en kaller tråder den; ingen kodeendring	Virker I DAG, uendret CLI. Den eneste som er nåbar uten ny flate.
(b) --docs-dir for «resten»	Er en ANNEN mekanisme — keyword-chunks, ikke navigasjon; §4.1a-dimensjonsgaten og verdict-gaten sitter på navigatør-verktøyene, ikke på chunk-verktøyet	Billig å skrive. Men den omgår stigen og to gater — jeg fraråder den, og den er uprøvd.
(c) CLI-flate for run_mandate_across_bundles	NY operatørflate (repeterbart --bundle-dir eller --bundle-dirs), altså en egen beslutning STATE i dag sier NEI til; dispatchen er sekvensiell, N kjøringer trenger N run_id-er, og outboxen er ikke wiret	Den ENESTE som gir ett mandat rutet over fire baser med én delt VerdictStore. Motoren finnes ferdig og er load-bearing-testet; det som mangler er argparse + run_id-mynting.

P14 skriver kontekstsettet; valget mellom (a) og (c) er operatørens, og (c) er en bygge-ordre — ikke noe denne økten har mandat til.

---

§ 4 — Honesty limits

1. Bumpen er ikke prøvd mot et EKTE ingest-kjør utover suitens fixturer. At okf 0.8.5 oppfører seg riktig på et levende manifest er ikke vist.
2. Guard-kalibreringen (_ACCEPTED_DISPOSITION = "warn") er bekreftet kun gjennom test_ingest_content_gate_loadbearings egne dokumenter. Guardens egen CHANGELOG sier at dispositions er fri til å flytte i enhver 1.x; en bredere måling er ikke gjort.
3. De sju golden-filene er TALT, ikke regenerert. At regenereringen gir nøyaktig den ene linje-endringen i alle sju er målt for ingest-golden-file (to filer, direkte diff) og utledet for de fem andre fra deres feilmeldinger — http/sql/mcp-goldenene kan ikke materialiseres utenfor testenes stubber (de krever PORTEFOLJE_SQL_DSN / nettverks-opt-in).
4. R761-tallene er ÉN maskin, tre kjøringer, varm filsystem-cache. Første R761-kjøring var 8,58 s mot 6,89/7,11 s for de to neste; spredningen er oppgitt, ikke bortsnittet.
5. Bundle.skipped = 0 på begge baser betyr at hver kryss-lenke ble fulgt — ikke at basene er komplette. Det er et utsagn om navigasjonen, ikke om innholdet.
6. Ingen modellkall, ingen Azure, NOK 0. Ingenting her sier hva en modell gjør med R761.
7. § 3.2 (b) er frarådet uten å være målt. Begrunnelsen er kodelesning (gatene sitter på navigatør-verktøyene), ikke en kjøring.

---

§ 5 — Reproduksjon

# DEL 1
git log --oneline origin/main..main | wc -l
ls ~/.claude/coord/portfolio-optimiser/inbox/*.md | wc -l
grep -rn "parse_frontmatter" src tests | wc -l
grep -rn "llm_ingestion_okf" src | wc -l
grep -rn "import yaml\|yaml.safe_load\|yaml.load" src tests | wc -l

# DEL 2a
grep -n "llm-ingestion-okf\|llm-ingestion-guard" pyproject.toml uv.lock
git -C ~/repos/llm-ingestion-okf show v0.8.5:pyproject.toml | grep -A2 "tool.uv.sources"
git ls-remote --tags https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security.git

# DEL 2b (rød FØRST, på dagens pinne -- men vaktfila er nå oppdatert til å pinne 0.3.2/0.3.4,
# så re-kjøring i dag er GRØNN; RED-beviset var mot v0.8.5/v1.2.0-konstantene)
uv run pytest tests/test_okf_version_guard.py -q

# DEL 2c (worktree -- ALDRI i det sporede treet)
git worktree add --detach /tmp/po-wt HEAD
cp STATE.md /tmp/po-wt/STATE.md   # handover-gatens egen kontroll trenger den
cd /tmp/po-wt
uv sync && uv run pytest -q                       # kontroll: 1579/3/5
sed -i '' 's|okf.git", rev = "v0.3.2"|okf.git", rev = "v0.8.5"|' pyproject.toml
sed -i '' 's|security.git", rev = "v0.3.4"|security.git", tag = "v1.4.0"|' pyproject.toml
uv lock && uv sync && uv run pytest -q             # etter: 1573/9/5
shasum -a 1 tests/golden/demo-transcript.stdout tests/golden/demo-transcript.stderr
uv run ruff check . --exclude scratchpad && uv run mypy src

# DEL 2c' -- funnet
uv run python -c "
from portfolio_optimiser.okf import _carries_complete_ingest_stamp as f
print(f({'generated':'true','ingest_manifest':'m.json'}))
print(f({'generated':'{ by: process:okf-ingest, at: 2026-07-03T12:00:00Z }','ingest_manifest':'m.json'}))"

# DEL 3a
for b in n100-2023 r761-2025; do for i in 1 2 3; do
  /usr/bin/time -l uv run python - "$HOME/repos/vegnormal-okf/build/ferdig/$b" <<'PY'
import sys, time
from portfolio_optimiser import okf
t0 = time.perf_counter(); b = okf.navigate_bundle(sys.argv[1]); dt = time.perf_counter() - t0
print(f"WALL={dt:.3f}s FILES={len(b.files)} CONTEXT={len(b.context_files)} "
      f"VERDICTS={len(b.verdicts)} SKIPPED={len(b.skipped)}")
PY
done; done

# DEL 3b
grep -n '"--bundle-dir"\|"--docs-dir"\|"--mandate"' src/portfolio_optimiser/run.py
grep -n "bundle_dirs=" src/portfolio_optimiser/run.py
grep -rn "run_mandate_across_bundles" src tests