docs(okr): innboks-ingestion veivalg + avstemming mot convergence-brief

Operatør-låst posisjon (2026-06-26): innboks-ingestion er OBLIGATORISK for okr (ikke 'defer'), krever grundig planlegging, eget Voyage-løp. linkedin-studio er IKKE en mal (annen tilnærming) -> omstøter convergence-briefens 'rise to the reference design' for okr. Skiller verifiserte tekniske premisser (beholdes: ingen Google inbox->OKF-pipeline, mdcode ikke OKF, relasjoner=md-lenker, OKF v0.1 paa okf/SPEC.md) fra strategisk framing (avvises for okr). Lister gap som maa bygges + gjenbruk fra 1.6.0 + aapne /trekbrief-spoersmaal (zero-dep-konflikt for dok-konvertering flagget). STATE.md peker hit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SFW5scLL7oEwWWTv1fPQG6

docs/innboks-ingestion-veivalg-2026-06.md

@@ -0,0 +1,92 @@
+# Innboks-ingestion — veivalg og posisjon (2026-06-26)
+
+> **Operatør-låst retning for okr-pluginens innboks-ingestion.** Avstemmer okr-STATE mot den
+> cross-cutting convergence-briefen (`linkedin-studio/docs/okf-convergence-brief.md`). Self-bearing —
+> leses ved oppstart av ingestion-løpet. **Teknisk grunnlag (web-verifisert):**
+> `docs/innboks-ingestion-funn-2026-06.md`. Status-of-play: `STATE.md`.
+
+## 1. Låste beslutninger (operatør, 2026-06-26)
+
+1. **Innboks-ingestion SKAL bygges for okr.** Ikke valgfritt, ikke «defer». Krever **grundig
+   planlegging** — eget Voyage-løp (`/trekbrief` → `/trekplan` → execute), egen minor-bump
+   (1.7.0-kandidat). Start når operatør sier fra (scope-guard).
+2. **linkedin-studio er IKKE en mal for okr.** Deres second-brain har en *annen tilnærming*
+   (provenans-vektet læring, episodisk/semantisk split, evidens-terskel-promotering) som vi
+   **ikke kopierer**. okr bygger sin egen sti.
+3. **Delt cross-repo OKF-skill: ikke nå.** Stage 3 (betinget) i convergence-briefen — utsatt.
+   okr-ingestion er okr-eid og ikke gated på en delt skill.
+
+## 2. Avstemming mot convergence-briefen (hva gjelder for okr)
+
+Convergence-briefen er linkedin-studio-sentrert og cross-cutting. For **okr** skiller vi
+verifiserte tekniske fakta (beholdes) fra strategisk framing (avvises):
+
+**BEHOLD — verifiserte tekniske premisser (gjelder uansett strategi):**
+- Google `knowledge-catalog` har **ingen** innboks→OKF-pipeline (funn §2, brief §2). Vi får spec +
+  byggeklosser, ikke en ferdig løype.
+- `mdcode` er **ikke** et OKF-verktøy — det er Dataplex git-sync med et *annet* frontmatter-schema
+  (`id`/`resource.name`/`createTime`/`links`). **Ikke** planlegg `kcmd` til å emittere/synke OKF.
+- Googles `reference_agent` ER en OKF-produsent, men leser **BigQuery + seed-URLer**, ikke en
+  dokumentmappe, og er Gemini/GCP-bundet. Gjenbrukbare (GCP-frie) deler: SPEC, emit/serialize/
+  validate-kjernen, `index.md`-syntese.
+- **Dokument-klassifisering/-konvertering av vilkårlige filer: Google gir INGENTING** — 100 % bygg
+  selv.
+- OKF-relasjoner = **vanlige markdown-lenker i body** (ikke frontmatter-felt); konsumenter MÅ
+  tolerere brutte lenker (funn §4, brief §5).
+- **OKF v0.1-spec finnes** på `okf/SPEC.md` (distinkt fra `mdcode`s «Metadata as Code» for Dataplex).
+  Kun `type` påkrevd; `index.md` reservert (ingen frontmatter); `okf_version` i rot-`index.md`.
+  *(NB: okr 1.6.0 pinnet bevisst til «Documents/kb Layout» og kalte det IKKE en formell standard —
+  ingestion-løpet bør re-verifisere `okf/SPEC.md` ved brief-tid og avgjøre hvor tett vi konformer.)*
+
+**AVVIS for okr — strategisk framing som IKKE styrer okr-ingestion:**
+- «Defer auto-classify/convert; build only on demonstrated need» → **avvist** (beslutning 1: skal bygges).
+- «linkedin-studio is the reference design; siblings rise to it» → **avvist for okr** (beslutning 2).
+- «Inbox forblir en manuell drop-zone uten auto-klassifiserer» → det var linkedin-studios stance;
+  okr-målet er det motsatte: **auto-oppdage + konvertere + tilordne OKF**.
+
+## 3. Hva som faktisk skal bygges (gap, fra funn-grunnlaget §5)
+
+1. **Dokument-konvertering** — PDF/Word/e-post/tekst → markdown. Finnes ikke i Google-repoet
+   (`fileskb`/`md-fileset` antar markdown og er read-only).
+2. **Konsept-ekstraksjon + frontmatter-tilordning** — splitte vilkårlige dokumenter til «konsepter»,
+   sette `type`/`resource`/`title`/`description`/`tags`/`timestamp`.
+3. **Generalisert relasjons-oppdagelse** — Googles relasjons-prompt er BQ-joins/web-spesifikk; må
+   generaliseres til vilkårlig dokumentkorpus (relasjoner som markdown-lenker i body).
+4. **Innboks-orkestrering** — oppdage nye filer, **beholde original + plassere markdown-peker**,
+   idempotent re-kjøring, plassering i riktig nivå av treet, regenerere berørt `index.md`.
+
+## 4. Gjenbrukbart fra OKF-fasen (1.6.0 — bygger ikke fra null)
+
+- `scripts/okf-index.mjs` — kildeagnostisk, idempotent `index.md`-regen (speiler Googles
+  `regenerate_indexes`). Innboks-pipelinen kaller den etter skriv (som tre-skriverne i `oppsett.md`).
+- `lib/frontmatter.mjs` (parse/skrive) + `scripts/okf-check.mjs` (validering) dekker skrive- og
+  verifiserings-siden.
+- Googles `Source`-ABC viser et rent adapter-mønster — en «innboks-kilde» som lister konsepter fra en
+  mappe kan mate eksisterende skrive-/index-/kryss-lenke-maskineri.
+
+## 5. Åpne spørsmål til `/trekbrief` (avgjøres da, ikke nå)
+
+- **Konverterings-motor:** okr er i dag **zero-dependency Node ESM** (kun `node:`-builtins). PDF/Word→md
+  krever realistisk enten et eksternt verktøy (pandoc/libreoffice/markitdown) eller en avhengighet —
+  **bryter zero-dep-invarianten**. Dette er et reelt arkitekturvalg (dokumentert prerequisite à la
+  `export-pdf.py`/weasyprint? egen avhengighet? hvilke formater i v1?).
+- **Konsept-ekstraksjon:** LLM-drevet (Claude i kommando) vs. heuristisk splitting — og hvor deterministisk.
+- **Relasjons-oppdagelse:** hvor generalisert; hvordan holde testbart.
+- **Innboks-plassering:** prosjekt-`.claude/okr/innboks/`? home? begge røtter? Original-bevaring + peker-layout.
+- **Mål-format:** full OKF v0.1 (`okf/SPEC.md`) vs. dagens lettere «OKF-kompatible form» okr emitterer.
+- **Idempotens + sikkerhet:** re-kjøring uten dubletter; ikke ødelegge brukerens originaler.
+
+## 6. Forhold til søsken-pluginer
+
+- `ms-ai-architect` har samme oppgave (designet, ikke bygget). **Vurder felles abstraksjon før
+  dobbel-implementasjon** — men felles ≠ kopiere linkedin-studio. Eventuell deling skjer på okr-egne
+  premisser.
+- En delt OKF-**spec** (convergence-briefens Stage 1, katalog-nivå) er grei interop og ikke i konflikt
+  med dette løpet; okr-ingestion er ikke blokkert på den.
+
+## 7. Kilder
+
+- `docs/innboks-ingestion-funn-2026-06.md` — web-verifisert Google-repo-analyse (kilder i §9 der).
+- `linkedin-studio/docs/okf-convergence-brief.md` — cross-cutting convergence (avstemt over).
+- OKF v0.1: `github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md`.
+- Leveranse vi bygger på: okr 1.6.0 (`scripts/okf-*`, `lib/frontmatter.mjs`, skill `okr-second-brain-search`).