ms-ai-architect/docs/kb-mechanism-redesign-brief.md
Kjell Tore Guttormsen e70f76b95e docs(ms-ai-architect): scope-brief for KB-mekanisme-redesign (neste fase)
Operatør har låst scope for neste fase: forbedre kunnskapsmekanismen i denne
pluginen så den står på egne ben (currency + completeness/gap-deteksjon + nye
MS Learn-kurs + skill-livssyklus inkl. merge/slett). Fanger krav + åpne
designvalg + søk-først-første-steg som input til en dedikert
planleggingssesjon. Currency-refresh: Critical/High/Medium ferdig; Low utsatt
bak redesignet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
2026-06-19 14:24:13 +02:00

3.5 KiB

Brief — Redesign av KB-kunnskapsmekanismen (ms-ai-architect)

Scope & krav. INPUT til en dedikert planleggingssesjon — IKKE planen selv. Pekt til fra STATE.md. Skrevet 2026-06-19 ved avslutning av Medium-currency-bøtta.

Premiss (hvorfor dette er fase n+1)

Kunnskapen pluginen bruker er dens største verdi — hele den samlede evnen (29 kommandoer, 12 agenter, 5 skills) er leveringsmekanismer oppå kunnskapsbasen. Mekanismen for å holde kunnskapen fersk, komplett og profesjonelt strukturert skal forbedres slik at pluginen kan «stå på egne ben»: selvforsynt, med mindre avhengighet av at hovedkontekst gjør tung manuell verifisering.

Krav til mekanismen (fra operatør 2026-06-19)

Mekanismen skal kunne:

  1. Oppdage hva som er NYTT og må oppdateres (currency) — finnes delvis i dag (kb-update).
  2. Oppdage NYE MS Learn-sider innenfor pluginens domene (completeness/gap) — mangler.
  3. Oppdage NYE eller forbedrede MS Learn-KURS / training modules som bør dekkes — mangler (ny innholdstype, ikke bare docs).
  4. Oppdatere EKSISTERENDE skills på best mulig måte.
  5. Lage NYE skills profesjonelt.
  6. Slå sammen eller SLETTE skills når nødvendig (livssyklus / destruktive ops).

Hva finnes i dag (utgangspunkt)

kb-update: sitemap-polling → sammenlign Last updated → prioritetsbøtter → grupperte Opus-subagenter → kirurgisk merge → hovedkontekst verifiserer. Currency-refresh kjørt: Critical/High/Medium FERDIG (138 filer, til 070141f); Low (51) UTSATT bak dette arbeidet.

Kjente strukturelle gap (empiri fra Medium-kjøringen)

  • URL-forankret blindhet: mekanismen sjekker bare sider filene ALLEREDE siterer → ser ikke manglende dekning (completeness) eller nye domener. Dette er rot-gapet bak krav 2 og 3.
  • Regresjons-klasse: status-påstander (GA/preview/versjon) «korrigeres» mot tilfeldig-sitert side; autoritativ nyanse kan bo på en annen side. Skjedde med agentic retrieval — hovedkontekst måtte rette manuelt. Status-påstander trenger en utpekt autoritetskilde (whats-new/migration).
  • Sync-laget er commodity (mye OSS finnes) → skal IKKE gjenoppfinnes; innsatsen til transformasjon + gap-deteksjon + verifisering.
  • Verifisering er samplet, ikke uttømmende i dag; «stå på egne ben» krever et verifiseringslag som ikke avhenger av menneskelig forkunnskap.

Åpne designvalg planleggingssesjonen MÅ avgjøre

  • Domeneavgrensning: hva er presist «innenfor pluginens område»? En taksonomi/domenegrense er forutsetningen for en gap-finder.
  • Kurs/training som innholdstype: eksponerer microsoft-learn-MCP-en training/courses i det hele tatt, eller trengs annen kilde? Hvordan mappes et kurs til skills?
  • Skill-livssyklus: guardrails for merge/slett (destruktivt; aldri tap av kuratert «For Cosmo»-verdi); telling-resync (389 = find skills/*/references -name '*.md' | wc -l); orphan-/SKILL.md-wiring.
  • «Stå på egne ben»: hvor mye automatiseres (hooks/scheduled) vs. operatør-i-loop? Hvilket verifiseringslag erstatter dagens manuelle hovedkontekst-review?
  • Bygge lite (len på eksisterende OSS) vs. mye (egen kapabilitet) — avgjøres ETTER søk-først-kartlegging.

Første steg i planleggingssesjonen

  1. Søk-først: kartlegg eksisterende OSS (inkrementell KB / doc-sync / coverage-audit) + hva microsoft-learn-MCP faktisk eksponerer (docs + code samples + evt. courses).
  2. Skarp problemdefinisjon + domene-taksonomi.
  3. /harness plan eller plan-mode → spec med verifiserbare kriterier. INGEN kode før godkjent plan.