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

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 mdcodes «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).