# 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.** ```diff --- 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å»: ```json { "objective": "", "allow_own_proposals": true, "success_criteria": ["", "..."], "approaches": [ { "id": "", "label": "", "description": "", "affected_codes": ["", "..."], "claimed_saving_nok": 0, "bundle_id": "" } ] } ``` `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_loadbearing`s 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 ```bash # 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 ```