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
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:
- Oppdage hva som er NYTT og må oppdateres (currency) — finnes delvis i dag (
kb-update). - Oppdage NYE MS Learn-sider innenfor pluginens domene (completeness/gap) — mangler.
- Oppdage NYE eller forbedrede MS Learn-KURS / training modules som bør dekkes — mangler (ny innholdstype, ikke bare docs).
- Oppdatere EKSISTERENDE skills på best mulig måte.
- Lage NYE skills profesjonelt.
- 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
- Søk-først: kartlegg eksisterende OSS (inkrementell KB / doc-sync / coverage-audit) + hva microsoft-learn-MCP faktisk eksponerer (docs + code samples + evt. courses).
- Skarp problemdefinisjon + domene-taksonomi.
/harness planeller plan-mode → spec med verifiserbare kriterier. INGEN kode før godkjent plan.