open/okr
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity Actions
okr/docs/okf-second-brain-note-2026-06.md

8.9 KiB
Raw Blame History

Retningsnotat — Google OKF for brukerens «second brain» (LLM-wiki) i okr-pluginen

Notert 2026-06-26. Fremtidig initiativ — IKKE implementer før plan er laget og godkjent. Dette notatet er grunnlagsmateriale for neste sesjons /trekbrief → /trekplan. Bygger på (a) verifisert lesning av OKF SPEC v0.1 og (b) det ferdige referansedesignet i søsken-pluginen ms-ai-architect (docs/okf-second-brain-brief-2026-06.md, operatør-bekreftet 2026-06-26). State-of-play i STATE.md.

Hva oppgaven er (operatør 2026-06-26)

Adopter Google Open Knowledge Format (OKF) som formatet brukeren lagrer sin egen kontekst i — en bruker-eid «LLM-wiki» / «second brain» utenfor pluginen. Brukeren legger inn så mye org-/strategisk kontekst som ønskes; deler av den injiseres/hentes smart når okr-pluginen brukes — både i fri chat (plugin lastet) og når /okr:*-kommandoer kjøres. Speiler arbeidet som nå designes i ms-ai-architect.

Scope-grense (ufravikelig — speiler architects operatør-bekreftede grense)

  • OKF gjelder KUN brukerens egen kontekst/data — okr-pluginens «second brain»: i dag org-profilen ~/.claude/okr/org/profil.md (maskin-global, skrevet av scripts/write-org-profile.mjs i Fase 3) + kontekst-treet .claude/okr/ (strategisk-kontekst/, syklus/[id]/, historikk/, dokumenter/) + prosjekt-lokal .claude/okr.local.md.
  • OKF gjelder IKKE pluginens 17 domene-referansefiler (skills/okr-offentlig-sektor/references/*). De forblir Claude Code skill-references (native, Anthropic-anbefalt progressiv-disclosure-mekanisme). Avgjørende skille (architects begrunnelse, overføres): ikke «er det en LLM-wiki» (begge er det), men «finnes det allerede en native, anbefalt mekanisme?» — for skill-refs JA (skills + references + grep), for second brain NEI (bor i dag i ad-hoc org/-/.claude/okr/-filer uten retrieval-mekanisme under chat). OKF fyller et reelt tomrom kun for second brain.

Lastemodell-skiftet (kjernen i hvorfor dette er ikke-trivielt)

  • I dag (Fase 3): hooks/scripts/inject-okr-context.mjs (UserPromptSubmit) for-injiserer org-profil + syklus-sammendrag når prompten er OKR-relevant (topic-guard regex). Hybrid resolusjon: prosjekt-lokal .claude/okr.local.md → hjem ~/.claude/okr/org/profil.md (mest-spesifikk-vinner).
  • Mål (OKF): kontekst hentes smart/selektivt on-demand — fordi en rik second-brain-wiki er for stor til å for-injisere i sin helhet, og fordi brukeren oftest chatter med pluginen lastet uten å kjøre kommandoer. Trenger en retrieval-skill (list → search → read) aktiv i fri chat, + en vedlikeholds-mekanisme som holder wikien oppdatert når brukeren tilfører kontekst OG når OKF-standarden bumpes.
  • For-injeksjons-hooken og on-demand-retrieval er komplementære, ikke konkurrerende: hooken kan beholde et lite «alltid-relevant» kjerne-sammendrag; retrieval-skillen dekker dybden.

OKF v0.1 — kjernekontrakt (verifisert mot SPEC 2026-06-26)

  • Kilde: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md (v0.1, 12. juni 2026 — «starting point, not finished standard»).
  • Bundle = katalogtre av markdown-filer, ett konsept per fil. Concept ID = filsti uten .md (f.eks. strategi/tillitsreform).
  • Frontmatter: påkrevd type (fri streng, f.eks. «Strategidokument», «Tildelingsbrev», «Org-enhet»). Anbefalt: title, description, resource (kanonisk kilde-URI), tags, timestamp. Konsumenter MÅ tolerere/bevare ukjente felt og ukjente type-verdier.
  • Reserverte filnavn: index.md (katalog-enumerasjon, ingen frontmatter, bærer progressiv disclosure) og log.md (endringslogg).
  • Kryss-lenking: markdown-lenker (bundle-relative /... eller relative); relasjonstype utledes av prosa. Konsumenter må tolerere brutte lenker.
  • Agent-konsum: «parseable by agents without bespoke SDKs» — traverser katalogen, parse frontmatter for ruting/filtrering, følg lenker. I Claude Code dekker Grep/Glob/Read allerede list/search/read — egen MCP-server er trolig unødvendig; den bærende mekanismen er en SKILL-instruks («søk wikien først, åpne kun relevant»).

Hvor det plugger inn i okr (forankringspunkter — verifiser i /trekbrief)

  • Lese-sømmen finnes: inject-okr-context.mjs + den hybride org-sti-resolusjonen (Fase 3) er allerede on-disk. OKF-retrieval bygger på/ved siden av denne.
  • Skrive-sømmen finnes: scripts/write-org-profile.mjs (atomisk temp+rename) skriver org-profilen i dag — naturlig sted å la onboarding skrive OKF-konform frontmatter (org/*.md mangler i praksis bare type: for å være nær-OKF).
  • Onboarding: /okr:oppsett full/mvp samler org-konteksten — kandidat for å produsere OKF-bundle-struktur i stedet for (eller i tillegg til) dagens flate profil.

Hva som må bygges (fremtidige faser — ikke nå; planlegges i /trekplan)

  1. Frontmatter-/struktur-konvensjon for okr-second-brain: minimal OKF-konform (type påkrevd + resource/timestamp), index.md per nivå. Migrer/utvid dagens ~/.claude/okr/org/ + .claude/okr/-tre.
  2. Retrieval-skill (f.eks. «okr-second-brain-search»): list → search → read over wikien, aktiv i fri chat (ikke bare kommandoer). Avgjør: ren SKILL + native Grep/Glob/Read vs. dedikert MCP-server.
  3. Vedlikeholds-mekanisme: hvordan wikien oppdateres når brukeren tilfører kontekst (onboarding/oppsett skriver OKF-konform), + rutine når OKF-standarden bumpes (okf_version i rot-index.md).

Åpne valg (avklares i /trekbrief / måling)

  • Retrieval-mekanisme: SKILL + native Grep/Glob/Read vs. dedikert fileskb-MCP-server. Ekte tvil → kandidat for «implementer begge, mål hvilken gir best kontekst-treff» (operatørs faktabasert-prinsipp). I Claude Code lener det mot ren SKILL (Grep/Glob/Read dekker OKFs list/search/read).
  • Grad av OKF-formalisme: full v0.1-konformitet vs. «OKF-kompatibel form» (frontmatter + index.md uten resten). Lén mot det letteste som gir smart retrieval.
  • For-injeksjon vs. on-demand: hva hooken beholder som «alltid-på kjerne» vs. hva retrieval-skillen henter ved behov.
  • Oppdaterings-kadens mot standarden: hvordan fange OKF-versjonsbump uten manuell polling.

Suksesskriterium (per operatør, overført fra architect-sporet)

Det viktigste er ikke teknologien/OKF-konformitet i seg selv, men at second brain blir så bra som mulig for brukeren (henter pluginen riktig personlig/org-kontekst i chat og kommandoer?) og at vedlikeholds-/oppdateringsmekanismene fungerer veldig bra. Mål mot brukerverdi + vedlikeholds-pålitelighet.

Voyage-vurdering (operatør ba om dette eksplisitt)

Anbefaling: JA — bruk Voyage, med ett forbehold om research-fasen.

  • For: Hele okr-referansegrad-løftet (Fase 1–3, nettopp fullført) kjørte ende-til-ende på Voyage (/trekbrief → /trekresearch → /trekplan → /trekexecute) over 4+ sesjoner. OKF-integrasjon treffer Voyages kjerneformål: fler-sesjons, krever grundig adversarial-revidert plan, krever deterministisk kontekst mellom sesjoner (STATE-bootstrap), og egner seg for session-dekomponering. ms-ai-architect kjører samme mønster (brief → plan → faser).
  • Forbehold (ikke bare bekreftelse): Research-delen (lese OKF samples/ + toolbox/) er allerede gjort og digerert i architect-briefens «Økosystem-digest» (kanoniske filer markert: samples/enrichment/.../kb-search/SKILL.md = retrieval-mønsteret; okf/bundles/ga4/... = frontmatter-mal; okf/src/reference_agent/prompts/* = vedlikeholds-mal). → Neste sesjons /trekresearch kan være lett eller hoppes over ved å arve den digesten; ikke betal for full research på nytt.
  • Hvis scope viser seg lite (f.eks. kun type:-frontmatter + én retrieval-SKILL): vurder i /trekbrief om full Voyage-maskineri er overkill — men architect-briefen viser at dette genuint er fler-delt (konvensjon + retrieval + vedlikehold + mål-MCP-vs-native + standard-tracking), så Voyage passer.
  • Anbefalt pipeline neste sesjon: /trekbrief (avgrens scope + de åpne valgene over) → arve architect-digest (lett/ingen /trekresearch) → /trekplan (fler-sesjons med .session-state, proaktiv kutting før compaction) → /trekexecute --session N foreground. Ny fase = minor-bump 1.5.0 → 1.6.0.

Referanser (les ved planlegging)