fix(ms-ai-architect): RX-P2 reg-kjede-wiring + komprehensiv agent-sti-forankring [skip-docs]

- classify->dpia->ros kjede-wiring: dpia/ros Task-templater far eksplisitte
  AI Act-klassifiserings- + DPIA-funn-felt (kjede-data agentene allerede branchet pa)
- dpia-agent uutforbar "spor bruker" -> "marker vurderingen" (Hvis-ikke-klassifisert
  + Error Handling); speilet til ros-analysis-agent
- adr-writer-agent: Write-verktoy fjernet, returnerer ADR-markdown til hovedkontekst
  (command er eneste skriver -- subagenter skriver aldri)
- KB-sti-forankring (komprehensiv): 36 bare referanse-subdir-stier i 6 agenter +
  2 commands fullkvalifisert med CLAUDE_PLUGIN_ROOT/skills/<skill>/references/ ---
  ogsa innen-skill kortformer, uresolverbare i installert modus
- mekanisme: validate-plugin.sh Check 6d (bare-subdir-lint m/ hyphen-guard) +
  negativ-probe-test (beviser tenner) + RX-P2 wiring-regresjonstester

Suite 859/859 exit 0. validate-plugin 250 PASS / 0 FAIL. 145 forankrede stier
verifisert eksisterende (0 mangler).

.claude-plugin/plugin.json

@@ -1,11 +1,11 @@
 {
   "name": "ms-ai-architect",
-  "version": "1.15.0",
+  "version": "1.17.0",
   "description": "Microsoft AI Solution Architect - structured architecture guidance for the full Microsoft AI stack",
   "author": {
     "name": "Kjell Tore Guttormsen"
   },
   "license": "MIT",
-  "repository": "https://git.fromaitochitta.com/open/ktg-plugin-marketplace",
+  "repository": "https://git.fromaitochitta.com/open/ms-ai-architect",
   "keywords": ["microsoft", "azure", "ai-architect", "governance", "security", "norwegian-public-sector", "eu-ai-act"]
 }

.gitignore

@@ -22,6 +22,42 @@ node_modules/
 # Runtime state
 .work/
 org/
-scripts/kb-update/data/
+# Generated KB-update artifacts (registry, reports) are ignored, but the
+# hand-authored taxonomy (lag 0), the decision ledger (lag 2) and the curated
+# AI Act deadline source (RX-REG, sync-tested consumer contract) are tracked.
+scripts/kb-update/data/*
+!scripts/kb-update/data/domain-taxonomy.json
+!scripts/kb-update/data/decisions.json
+!scripts/kb-update/data/ai-act-deadlines.json
+# Generated skill-lifecycle detection report (Spor B / B1) — regenerated on demand,
+# like the kb-update reports above. The detector script + curated inputs are tracked.
+scripts/kb-eval/data/skill-lifecycle-report.json
+# Generated skill-quality score cache (Spor D / STEG B) — derived from the corpus,
+# regenerated by `score-skill.mjs --write` and the apply-skill-op gate. Consumed by
+# the STEG C SessionStart surfacing; not committed (avoids churn in the public repo).
+scripts/kb-eval/data/skill-score-report.json
+# Generated judge bake-off fan-out payloads (45 per-file prompts, ~760KB) — derived
+# deterministically from judge-bakeoff-claims.json + the judge prompt by
+# build-judge-payloads.mjs; regenerated on demand, not committed (bulk + churn).
+scripts/kb-eval/data/judge-bakeoff-payloads-*.json
 .kb-backup/
+# atomic-write temp files (atomicWriteSync writes `<name>.tmp.<pid>.<n>` then renames);
+# a crash mid-write could leave one behind — never let it reach the public mirror.
+*.tmp.*
 .rollback-in-progress
+
+# --- session/local state — LOCAL-ONLY (gitignored) ---
+# STATE.md is internal state-of-play and must NEVER reach a public mirror. This
+# repo's Forgejo remote (open/) is published open source, so STATE.md is local-
+# only per the global continuity rule (same as linkedin-studio). The hook injects
+# it from disk regardless of tracking, so continuity is unaffected.
+STATE.md
+REMEMBER.md
+ROADMAP.md
+TODO.md
+NEXT-SESSION-PROMPT*.local.md
+*.local.md
+*.local.json
+*.local.sh
+.DS_Store
+.claude/

CHANGELOG.md

@@ -5,6 +5,132 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Changed
+
+- **OKF second-brain (sporet for brukerens egen kontekst-wiki — IKKE de 389 skill-refs):** Ratifiserte den delte katalog-spec-en `catalog/docs/okf-second-brain/spec.md` v0.1 som eneste kilde for konvensjonen; lokal brief (`docs/okf-second-brain-brief-2026-06.md`) *refererer* den nå i stedet for å restate. Premiss-korreksjoner registrert (spec §9): `mdcode`/`kcmd` er ikke et OKF-verktøy (droppet fra adopsjonsplanen); ingen gjenbrukbar OKF-ingest-kode finnes (`reference_agent` er GCP/Gemini-bundet → adopter prompt-mønstre, ikke kode); kanonisk anbefalt feltnavn er `resource` (ikke `source`). Full OKF-pakke-ambisjon består — minimal kontrakt (spec §3) er gulvet, rike felt rir over som extension keys (spec §5). Kun docs/plan-justering; bygging er separat go.
+
+## [1.17.0] - 2026-07-04
+
+Spor 1 — Port-1-substrat migrert på korpuset (de 4 ikke-advisor-skills) via den deterministiske `migrate-corpus.mjs`-applieren. Reference-kontrakten (`**Type:**` / `**Source:**` / TOC) er nå påført på tvers av korpuset, og stale `**Verified:** MCP`-poison er fjernet. Ingen kommando-, agent- eller persona-endringer; prosa-kropper byte-identisk; advisor-skillen urørt.
+
+### Changed
+
+- **Reference-headere (327 filer):** `**Type:**` stemplet på alle 327 (reference/methodology/regulatory/template); `**Source:**` (Microsoft Learn-autoritet, satt per fil i manifestet) backfilt på 243 sourced reference-filer; `## Innhold` TOC innsatt på 325 store filer (≥100 linjer). `verified` forblir null — settes først i en senere corpus-judge-pass.
+- **Full-pass-worklist aktivert:** 243 due, 0 fresh. CT5 (referanse-kontrakt) available på alle 4 skills; N4 (TOC) 0 → 1.000/pass. Skill-scorer steg (95→98–100); den forhåndsdeklarerte «transient sub-90 dip» inntraff ikke (registrert i utfallsdoc).
+
+### Fixed
+
+- **Stale-verified poison:** `**Verified:** MCP <dato>` fjernet — 14 header-forekomster + 9 stray body-duplikater innenfor 500-byte-scan-vinduet (mlops-genaiops). Disse ble ellers falskt lest som «verified» og droppet fra worklisten. Kun stray metadata-linjer fjernet, aldri prosa.
+- **`insertHeaderFields` anker-overshoot:** når en meta-linje selv passerer 500 B (2 filer med et avsnitt pakket i `**Status:**`), faller ankeret nå tilbake til siste meta-linje innenfor scan-vinduet, så Type/Source forblir parsbare. TDD.
+- **`normalizeStaleVerified`:** fjerner nå alle stale non-date `**Verified:**` i 500B-vinduet uansett `---`-posisjon (operatør-godkjent utvidelse av carve-out). TDD.
+
+Suite 728/728 grønn. Detaljert utfall + policy-delta + base-felt-restanse: `docs/spor1-migration-outcome.md`.
+
+## [1.16.5] - 2026-06-24
+
+KB-refresh-patch. LOW-tier (52 reference docs) verifisert mot Microsoft Learn (post-1.16.4 baseline). Ingen kommando-, agent- eller skill-endringer — kun reference docs. ~33 filer var TRYGT (innhold gjeldende, kun header-bump); resten hadde reell drift, URL- eller syntaksfiks. Hver `VERIFY`-påstand re-bekreftet av main-agent mot sitert Microsoft Learn-kilde FØR skriving; `git diff` + plugin-validering (239/0). Needing-update 52 → 0 (alle tiers nå 0).
+
+### Changed
+
+- **Agent Framework (materiell fiks):** `agent-framework` fullstendig omskrevet — tidligere utgave bygde på et oppdiktet API (`azure.ai.agent`, `FoundryClient`/`FoundryTools`, `Swarm`/`Handoff`, `Memory`, `@checkpoint`, `enable_tracing`). Korrigert til det ekte SDK-et `agent-framework` (Python) / `Microsoft.Agents.AI` (.NET): `Agent(client=...)`, `@tool`, `AgentSession`, graf-baserte `WorkflowBuilder`/`SequentialBuilder`, OpenTelemetry-observability, og den faktiske Foundry-verktøykatalogen. Etterfølger til **BÅDE** Semantic Kernel **og** AutoGen; `.as_agent_framework_tool`-bro (krever `semantic-kernel` ≥ 1.38). `migration-patterns` §6 tilsvarende korrigert (Agent Framework = eget SDK, ikke et SK-namespace).
+- **Regulatorisk (norsk AI Act):** `public-sector-checklist` + `ai-utredning-template` — norsk ikrafttredelse mykgjort fra «aug 2026 samtidig med EU» til «forsinket pga. EØS-tilpasning, ventet 2026»; Foundry URL-slug `ai-studio` → `foundry`.
+- **Copilot/lisens:** Copilot Studio «billed sessions» → **Copilot Credits** (felles valuta fra 1. sep 2025) i `migration-patterns` og `licensing-matrix`.
+- **Data engineering (Fabric/Databricks):** `zero-etl-fabric-patterns` Oracle/SAP mirroring Preview→GA; `onelake-data-strategy` OneLake Security + Shortcut Transformations GA; `lakehouse-architecture-design` liquid clustering GA; `data-quality-ai-frameworks` MLV `ON MISMATCH`-syntaks + DLT→Lakeflow SDP-rebrand.
+- **API Management (GenAI gateway):** `genai-gateway-policies` / `logging-analytics-ai-traffic` / `security-hardening-ai-gateway` — token-quota-period, KQL `ModelDeploymentName` → `DeploymentName`, `llm-token-limit` ikke støttet på Consumption, semantic-cache / Developer Portal v2-tier-matriser korrigert, llm-content-safety policy-syntaks.
+- **BCDR:** `state-management-failover` Azure Cache for Redis retirement → Azure Managed Redis; `multi-region-azure-openai-deployment` + `rto-rpo-planning-ai-services` BCDR-ref-URLer fikset.
+- **Cosmo-utfasing (start):** «For Cosmo»-seksjonene fjernet i `agent-framework` og `disconnected-ai-scenarios` (persona-pedagogikken er under avvikling — full fjerning på tvers av repoet er planlagt som eget initiativ).
+- **Header-bump (TRYGT, ~33 filer):** data-engineering-, api-management-, bcdr- og advisor-klyngene (innhold verifisert gjeldende mot Microsoft Learn).
+
+## [1.16.4] - 2026-06-24
+
+KB-refresh-patch. MEDIUM-tier (33 reference docs) verifisert mot Microsoft Learn (post-1.16.3 baseline). Ingen kommando-, agent- eller skill-endringer — kun reference docs. 18 filer var TRYGT (innhold gjeldende, kun header-bump); 15 filer hadde reell drift. Hver `VERIFY`-påstand fra de 7 parallelle drift-rapportene ble re-bekreftet av main-agent mot sitert Microsoft Learn-kilde FØR skriving; disclaimed/illustrative priser urørt; GPT-4.1-pricing-påstand forble uverifiserbar (kun community-kilder) og ble IKKE endret; alle endringer review-gated på `git diff` + plugin-validering (239/0). Medium-count 33 → 0 (needing-update 85 → 52).
+
+### Changed
+
+- **Prompt-caching:** `token-optimization` — retention-modell omskrevet: in-memory (5–10 min, ≤1t, default t.o.m. gpt-5.4) vs **extended retention 24t** (`prompt_cache_retention`, default for nyere modeller); in-memory støttes av «GPT-4o eller nyere».
+- **Realtime:** `real-time-reasoning` — la til `gpt-realtime-1.5` (2026-02-23); Realtime API flyttet til **GA-endepunkt** `/openai/v1` (ikke lenger date-baserte api-version); preview→GA-statusnyanse.
+- **Guardrails-rebranding:** `regulatory-and-compliance` + `azure-ai-foundry` — «content filters» → **Guardrails (and controls)**, default `Microsoft.DefaultV2`, fire intervensjonspunkter; data-privacy-kildetittel → «Models sold by Azure».
+- **GPU/PTU:** `gpu-compute-sizing` — `ND96asr_v4` = 8×A100 **40GB = 320 GB** (var 640 GB); `load-testing` — PTU min deployment Global/Data Zone **15** (increment 5), 50 kun Regional.
+- **Foundry-deprecations:** `azure-ai-foundry` — **Deep Research-tool** og **Connected agents (classic)** deprecated (retire 2027-03-31), **Prompt Flow**-retirement 2027-04-20, **A2A-tool nå i Java SDK**.
+- **Agent-evaluering/-memory:** `agent-evaluation` — nye agent-evaluatorer (Task Completion/Customer Satisfaction/Tool Selection m.fl.) + `FoundryEvals` + `gpt-4.1-mini` judge; `agent-memory` — **procedural memory** (3. type), TTL/CRUD, **Norway East**-region bekreftet (VNet ikke støttet).
+- **Øvrig faktafiks:** `multi-turn` RPM/TPM-forhold varierer per modell; `structured-output` usupporterte keywords utvidet + `gpt-4o-mini-audio-preview`; `temperature-sampling` Copilot Studio prompt builder-temp + fjernet uoffisielt M365-tall; `rag-hallucination` groundedness `mitigating`/`correctionText`; `model-versioning` MLflow stages legacy i UC; `speaker-recognition` **Limited Access**-status; `chain-of-thought` reasoning_effort per-modell-nyanse.
+- **Header-bump (TRYGT, 18 filer):** domain-specific, few-shot, function-calling, grounding, role-playing, system-message-design, async-processing, batch-api-usage, concurrent-request, performance-benchmarking, response-chunking, throughput-optimization, token-per-second, late-chunking, rag-evaluation, self-reflective-rag, streaming-rag, feedback-loops.
+
+## [1.16.3] - 2026-06-24
+
+KB-refresh-patch. HIGH-tier (11 reference docs) + 1 dateless kjernefil (`ms-ai-advisor/references/architecture/security.md`), flagget av endrings-detektoren mot Microsoft Learn-sitemaps (post-1.16.2 baseline), er verifisert og oppdatert. Ingen kommando-, agent- eller skill-endringer — kun reference docs. Hver `VERIFY`-påstand fra de parallelle drift-rapportene ble bekreftet mot sitert Microsoft Learn-kilde FØR skriving (main-agent som verifiseringsgate); disclaimed/illustrative priser urørt; alle endringer review-gated på `git diff` + plugin-validering (239/0). High-count 11 → 0, Unverified 1 → 0 (needing-update 97 → 85).
+
+### Changed
+
+- **Content Safety:** `bias-detection` image-modeller korrigert til **Medium** default-terskel (var feilaktig «Low»), verifisert mot `default-safety-policies`; `responsible-ai-policy` Foundry Agent Service monitoring merket **(Preview)**; `content-safety-implementation` tegnkode-typo (`申请` → `Apply for`). **Avkreftet ved verifisering:** Content Safety Analyze Text **10K-tegn**-grensen var korrekt (drift-rapportens «1000» var feillesing av Transparency Note-ens nøyaktighets-anbefaling — gaten fanget den).
+- **Guardrails/agenter:** `agent-autonomy-and-control-governance` la til **Task Adherence (preview)** i risk-kategoriene (bekreftet i `guardrails-overview`).
+- **Evaluering:** `response-quality-metrics-rag` la til **Prompt Flow retirement 2027-04-20** (migrer til Microsoft Agent Framework) + korrigerte `gpt-4.1-mini` (GPT-4.1-variant, ikke o-series reasoning model).
+- **Opphavsrett:** `copyright-ai-training-data-norway` oppdatert til **«Models sold by Azure»**-terminologi (var «Azure Direct Models»), la til 5. data-privacy-garanti (ingen forbedring av Microsoft-/tredjepartsprodukter uten samtykke), klargjorde CCC-scope (Copilot Studio + GitHub Copilot = tjeneste-spesifikke mitigations) og oppdaterte metaprompt-referansen til `safety-system-message-templates`.
+- **Sikkerhet (kjernefil):** `architecture/security.md` fikk maskinlesbar `Last updated`-header (var dateless → unverified), «Hate and Fairness»-navn, og CMK Key Vault-krav korrigert (Azure RBAC «Key Vault Crypto Service Encryption User» som primæralternativ, ikke «legacy access policies»). RBAC-rollenavn bekreftet uendret.
+- **Header-bump (TRYGT, innhold verifisert gjeldende):** `owasp-llm-top10-azure-mitigations`, `defender-threat-protection-ai-services`, `output-validation-grounding-verification`, `stakeholder-communication-ai-decisions`, `model-performance-drift-detection`.
+
+## [1.16.2] - 2026-06-24
+
+KB-refresh-patch. Critical cost-klyngen (8 reference docs i `cost-optimization/`), flagget av endrings-detektoren mot Microsoft Learn-sitemaps (post-1.16.1 baseline), er verifisert og oppdatert. Ingen kommando-, agent- eller skill-endringer — kun reference docs. Hver `VERIFY`-påstand fra de parallelle drift-rapportene ble bekreftet mot sitert Microsoft Learn-kilde FØR skriving (main-agent som verifiseringsgate); disclaimed/illustrative priser urørt; alle endringer review-gated på `git diff` + plugin-validering (239/0). Critical-count for klyngen 8 → 0.
+
+### Changed
+
+- **Deployment-katalog:** Spillover GA (var preview), ny **Priority processing**-kategori (4. deployment-type) og **Data Zone Batch** (SKU `DataZoneBatch`, EU/US-datasone) lagt inn på tvers av cost-filene; modell-lineup GPT-5 → GPT-5.1/5.5.
+- **Prompt-caching:** extended cache retention 24t (`prompt_cache_retention`) reframet mot in-memory vs extended; cache-TTL-akse korrigert.
+- **Fine-tuning:** RFT (Reinforcement Fine-Tuning) kostnadsmodell lagt til (tidsbasert + $5000 per-job-tak), utover SFT/DPO.
+- **Batch:** «exponential backoff queuing» reframet til server-side **fail-fast** + klient-side backoff-retry (kodeeksempelet er klient-side).
+- **On Your Data:** deprecation (pensjon 2026-10-14) flagget der relevant.
+- **Kalibrerings-korreksjoner:** fjernet uverifiserbart parametertall (GPT-4o «175B+»); «GPT-4 utfaset» → «legacy» (GPT-4-familien superseded, ikke fjernet); avkreftet én drift-påstand ved verifisering (Phi-3/Phi-2/Falcon-7B fortsatt i Foundry-katalogen → ingen «retired»-merking lagt inn).
+- **Filer:** `ptu-vs-paygo-economics`, `reserved-capacity-planning`, `cost-monitoring-cost-attribution`, `inference-endpoint-cost-optimization`, `prompt-engineering-cost-reduction`, `token-counting-optimization`, `request-batching-aggregation`, `small-language-models-economics`.
+
+## [1.16.1] - 2026-06-23
+
+KB-refresh-patch. Tre akkumulerte kunnskapsbase-oppdateringer som speiler Microsofts produkt-navngiving og modellkatalog. Ingen kommando-, agent- eller skill-endringer — kun reference docs. Hvert premiss verifisert mot Microsoft Learn FØR sveip; alle endringer review-gated på `git diff` + plugin-validering + deterministisk re-score (skills uendret, alle ≥90 %).
+
+### Changed
+
+- **Modellkatalog GPT-5.1 → GPT-5.5** i 3 filer: 2 kostnadsfiler (`batch-processing-cost-reduction.md`, `model-selection-price-performance.md`) + plattformfila `azure-ai-foundry.md`.
+- **Foundry-navnesveip «Azure AI Foundry» → «Microsoft Foundry»** på tvers av 233 reference docs (810 forekomster) — følger Microsofts rebranding av Foundry-produktnavnet.
+- **RBAC-rolle-renavn «Azure AI User» → «Foundry User»** (`foundry-workflows-visual-orchestration.md`); den eldre rollenavn-mappingen i `azure-ai-foundry-cost-governance.md` ble bevart med kontekst.
+
+## [1.16.0] - 2026-06-22
+
+Currency-, privat-sektor-paritets- og selvstendiggjørings-release. Adresserer devil's-advocate-audit (2026-06-18, 10 dimensjoner, 89 verifiserte funn) — `docs/devils-advocate-audit-2026-06-18.md`. Alle faktapåstander verifisert mot Microsoft Learn / EDPB / OWASP-primærkilder før skriving.
+
+### Added
+
+- **4 nye kommandoer (25 → 29):**
+  - `/architect:businesscase` — forretningscase med NNV (netto nåverdi) + DFØ-gevinstrealisering (#7c).
+  - `/architect:anskaffelse` — AI-anskaffelse: kravspesifikasjon, leverandørevaluering, terskelverdier (#7c).
+  - `/architect:design` — sektor-nøytralt Solution Architecture Document (SAD): kontekst, NFR, alternativer, valgt design, risiko, veikart (#7d).
+  - `/architect:vendor` — tredjeparts-/SaaS-leverandørvurdering (due diligence): dataresidens, sub-prosessorer, DPA, Schrems II, AI Act-deployer (#7d).
+- **2 nye KB-filer (ms-ai-security, 60 → 62 refs):** `owasp-llm-top10-azure-mitigations.md` (LLM04/06/08/09) og `defender-threat-protection-ai-services.md` (AI threat protection — ikke i Azure Government).
+- **Privat-sektor-paritet:** sektor-parametrisering i 6 kommandoer + onboarding-forgrening for privat/regulert sektor + parallell privat-bane i README/help/playground.
+- **Spor C — selvstendiggjøring (planlagt deteksjon + onboarding-redesign):**
+  - **Planlagt deteksjon (C1, opt-in):** automatisk sjekk om Microsoft Learn-KB har endret seg. Tier 1 (SessionStart-hook kjører deteksjon når ≥ `interval_days` siden sist) + Tier 2 (lokal OS-scheduler launchd/cron, deteksjon-only). **Claude-fri** — poller sitemaps → rapport → discovery, oppdaterer ALDRI KB selv; operatør kjører `/architect:kb-update` manuelt.
+  - **Onboarding-redesign (C2):** virksomhetskontekst + scheduler-config flyttet til **bruker-eid `~/.claude/ms-ai-architect/`** (overlever plugin-reinstall; `lib/user-data.mjs` ren resolver). Ambient injeksjon av kompakt org-sammendrag ved hver sesjonsstart (ikke bare status). Valgfritt fritekst-felt (`free-context.md`). Scheduler (`enabled` + `os_scheduler_cadence`) settes i onboarding via gated CLI (backup + atomisk skriving). Privat-sektor-paritet låst med regresjonsvakt (`tests/test-onboarding-parity.sh`): privat virksomhet fullfører onboarding uten «Annet» + privat reg-sett (DORA/Finansforetaksloven/Finanstilsynets IKT-forskrift/Verdipapirhandelloven/Hvitvaskingsloven).
+
+### Changed
+
+- **EU AI Act-tidslinje re-baselinet mot Digital Omnibus:** Annex III høyrisiko (frittstående) utsatt til 2027-12-02, Annex I (innebygd) til 2028-08-02, Art. 50 transparens 2026-08-02. Art. 99-bøtesatser korrigert (35M €/7 %, 15M €/3 %, 7,5M €/1 %). Klargjort at EU AI Act ennå ikke er EØS-innlemmet og KI-loven uvedtatt per juni 2026.
+- **Agent-orkestrering currency:** Connected Agents deprecated (pensjon 2027-03-31) → ny GA-modell Prompt/Hosted agents + Responses API som single entry point. MAF 1.0 GA + A2A v1.0.1. Prompt Flow (Foundry + AML) retirement 2027-04-20 → MAF. Computer Use Agent (CUA) GA 2026-05-07. Agentic retrieval GA-split (REST `2026-04-01` min/ekstraktiv, LLM-planning preview).
+- **Kostnadslag re-baselinet:** GPT-5 $1,25/$10 input/output, konsolidert til én prissannhet i `deterministic-cost-calculation-model.md`.
+- **Foundry URL-navnerom-migrering:** `ai-foundry` → `foundry` / `foundry-classic` på tvers av 141 filer.
+- **Dataresidens korrigert:** Norway East — gpt-4o + gpt-4o-mini eneste Norge-residente generative modeller; modellkatalog modernisert.
+- **DPIA cross-border:** EDPB Rec 01/2020 seks-stegs-TIA + CLOUD Act/FISA-restanalyse (FISA §702 til mars 2027; DPF gyldig; CLOUD Act uendret av DPF). EDPB 28/2024: anonymisering vurderes case-by-case.
+- **ROS + DPIA regulatorisk currency:** NSM Grunnprinsipper v2.1, OWASP Agentic 2026 (ASI01–10), EchoLeak, DPF, EUDB.
+- **Sikkerhet:** M365 E7 + Agent 365 (GA 2026-05-01) i licensing-matrix; Foundry Local air-gapped (Sovereign Private Cloud) i disconnected-scenarios.
+- **KB-routing:** RAG/MLOps-KB ruting (betinget last) + forsont ROS-last-kontrakt (kjerne + betinget).
+- Tellinger oppdatert: README docs-badge 387 → 389, README KB-tabell + per-skill-seksjon (ms-ai-security 60 → 62), CLAUDE.md skill-tabell (ms-ai-security 60 → 62), SKILL.md cost-optimization subdir-telling 21 → 22 (korrigert pre-eksisterende drift).
+
+### Notes on 1.16.0
+
+- **Verifisering:** alle currency-påstander krysssjekket mot primærkilder. Der OWASP 2025-sider returnerte 404 ble innholdet kryssverifisert mot alternative offisielle kilder.
+- **Plugin API surface:** 29 kommandoer, 12 agenter, 5 skills (389 reference docs), 2 hooks, MCP-server-config. Playground v3-koden er uendret siden v1.15.0 — kun doc-stamp bumpet; screenshots i `playground/screenshots/v1.15.0/` ikke regenerert.
+- **Tester:** 239 plugin-validering, kb-integrity 192/192 (220 baseline orphan-warns), kb-update 213, kb-eval 100, test-hooks 11/11, plugin-discovery 13/13, run-e2e alle suiter (security/cost/summary/ros/ai-act/**onboarding-parity 14/14** + 6 playground-suiter) 0 FAIL. gitleaks: 3 pre-eksisterende i `playground/vendor/`.
+
 ## [1.15.0] - 2026-05-16
 
 ### Changed — playground v3 project-view integration

CLAUDE.md

@@ -5,7 +5,7 @@ Microsoft AI Solution Architect plugin for Claude Code.
 ## Hva denne pluginen gjør
 
 Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
-- Azure AI Foundry, Copilot Studio, M365 Copilot
+- Microsoft Foundry, Copilot Studio, M365 Copilot
 - Power Platform AI (AI Builder, Power Automate)
 - Microsoft Agent Framework
 - Sikkerhet og compliance
@@ -24,14 +24,18 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 | `/architect:compare` | Sammenlign Microsoft AI-plattformer for et gitt scenario |
 | `/architect:security` | Sikkerhets- og compliance-vurdering (6 dimensjoner) |
 | `/architect:cost` | Kostnadsestimat med konfidensgradering (NOK) |
+| `/architect:businesscase` | Forretningscase: NNV (netto nåverdi) + DFØ-gevinstrealisering |
 | `/architect:adr` | Generer Architecture Decision Record (MADR v3.0) |
+| `/architect:design` | Sektor-nøytralt Solution Architecture Document (SAD) — kontekst, NFR, alternativer, valgt design, risiko, veikart |
 | `/architect:research` | Utforsk siste nytt for en Microsoft AI-plattform |
 | `/architect:poc` | Generer POC-plan med suksesskriterier og risiko |
 | `/architect:license` | Kartlegg AI-kapabiliteter per lisenstype |
+| `/architect:vendor` | Tredjeparts-/SaaS-leverandørvurdering (due diligence) — dataresidens, sub-prosessorer, DPA, Schrems II, AI Act-deployer |
 | `/architect:migrate` | Planlegg migrasjon mellom plattformer |
+| `/architect:anskaffelse` | AI-anskaffelse: kravspesifikasjon, leverandørevaluering, terskelverdier |
 | `/architect:utredning` | AI-arkitekturutredning for norsk offentlig sektor |
 | `/architect:diagram` | Generer arkitekturdiagram med Imagen 3 (mcp-image) |
-| `/architect:review` | Kjør arkitekturgjennomgang mot norske offentlig sektor-krav |
+| `/architect:review` | Kjør arkitekturgjennomgang mot norske krav (offentlig sektor og privat/regulert sektor) |
 | `/architect:generate-skills` | Generer kunnskapsfiler med MCP-research (batch) |
 | `/architect:ros` | Gjennomfør ROS-analyse (Risiko- og Sårbarhetsanalyse) for et AI-system |
 | `/architect:dpia` | Gjennomfør DPIA/PVK for et AI-system |
@@ -40,7 +44,7 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 | `/architect:classify` | EU AI Act-klassifisering: risikonivå + rolle |
 | `/architect:requirements` | Konkrete AI Act-krav basert på risikonivå og rolle |
 | `/architect:transparency` | Generer Art. 13/50 transparensnotis på norsk |
-| `/architect:frimpact` | FRIA (Art. 27) — obligatorisk for offentlig sektor |
+| `/architect:frimpact` | FRIA (Art. 27) — obligatorisk for offentlige organer og enkelte private deployere (kredittscoring, livs-/helseforsikring) |
 | `/architect:conformity` | Samsvarsvurdering (Art. 43) — sjekkliste + erklæring |
 | `/architect:onboard` | Onboard pluginen med virksomhetsspesifikk kontekst |
 | `/architect:kb-update` | Manuell KB-refresh — poller sitemaps, oppdaterer endrede filer via `microsoft_docs_fetch`, committer |
@@ -68,20 +72,13 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 |-------|--------|----------------|--------------|
 | `ms-ai-advisor` | Cosmo Skyberg-persona, 7-fase arbeidsflyt, plattformvalg | 62 | "Hjelp meg velge" |
 | `ms-ai-governance` | Norsk offentlig sektor-styring, EU-regelverk, ansvarlig AI | 78 | "Er dette lovlig?" |
-| `ms-ai-security` | Sikkerhetsscoring (6x5), kostnadsestimering (P10/P50/P90) | 60 | "Er dette trygt?" |
+| `ms-ai-security` | Sikkerhetsscoring (6x5), kostnadsestimering (P10/P50/P90) | 62 | "Er dette trygt?" |
 | `ms-ai-engineering` | RAG, agenter, Azure AI Services, data, MLOps, multimodal | 153 | "Hvordan bygger jeg dette?" |
 | `ms-ai-infrastructure` | BCDR, hybrid/edge, suveren sky | 34 | "Hvordan drifter jeg dette?" |
 
-### Kunnskapsbase-routing i agenter (max 3 filer per invokasjon)
+### Kunnskapsbase-routing i agenter (typisk 3 kjernefiler per invokasjon)
 
-Agenter leser navngitte kjernefiler, ikke hele kataloger:
-- **security-assessment-agent**: security-scoring-rubrics-6x5.md, ai-security-scoring-framework.md, ai-threat-modeling-stride.md
-- **cost-estimation-agent**: deterministic-cost-calculation-model.md, azure-ai-foundry-cost-governance.md, cost-models.md
-- **architecture-review-agent**: decision-trees.md, security.md, public-sector-checklist.md + domene-spesifikke ved behov
-- **ros-analysis-agent**: ros-ai-threat-library.md, ros-scoring-rubrics-7x5.md, ros-methodology-ns5814-iso31000.md
-- **dpia-agent**: dpia-norwegian-methodology-ai.md, gdpr-compliance-ai-systems.md, ai-impact-assessment-framework.md
-- **ai-act-assessor**: ai-act-classification-methodology.md + relevante ai-act-*.md filer (maks 3 per fase)
-- **summary-agent**: Leser assessment-outputs fra sesjon, ikke KB-filer
+Agenter leser navngitte kjernefiler, ikke hele kataloger. «3 kjernefiler» er normalen for review-/security-/cost-mønsteret; **ros-analysis-agent er et dokumentert unntak** med et større, eksplisitt last-kontrakt (kjerne + betinget) — en deterministisk ROS krever trusselbibliotek + rubrikker + metodikk + mal som minimumskjerne. Hver agents nøyaktige kjerne-/betinget-filer er definert i **agentfilen** (single source of truth); `summary-agent` leser sesjonens assessment-outputs, ikke KB-filer.
 
 ## MCP-servere
 
@@ -90,42 +87,42 @@ Agenter leser navngitte kjernefiler, ikke hele kataloger:
 
 ### Anbefalte MCP-servere (ikke påkrevd)
 
-- `azure-mcp-server` (microsoft/azure-mcp-server) — Live Azure-infrastrukturinspeksjon (Storage, Key Vault, Monitor, AI Search, RBAC)
-- `bicep-mcp-server` — IaC-generering for Azure-ressurser
-- `azure-devops-mcp` (microsoft/azure-devops-mcp) — Work items, pipelines, repos
-
-Se `references/architecture/recommended-mcp-servers.md` for detaljer.
+`azure-mcp-server` (live Azure-infra-inspeksjon), `bicep-mcp-server` (IaC), `azure-devops-mcp` (work items/pipelines/repos). Detaljer: `skills/ms-ai-advisor/references/architecture/recommended-mcp-servers.md`.
 
 ## Hooks (2)
 
 | Event | Script | Formål |
 |-------|--------|--------|
-| SessionStart | `session-start-context.mjs` | Viser aktive utredninger, KB-ferskhet, onboarding-status + AI Act-frister |
+| SessionStart | `session-start-context.mjs` | Viser aktive utredninger, KB-ferskhet, onboarding-status, skill- + kurs-signaler (Spor C), skill-kvalitetssignaler (Spor D — skills under 90 %, fra cachet score-rapport) + AI Act-frister |
 | Stop | `stop-assessment-reminder.mjs` | Påminnelse om ucommittede vurderinger, neste steg |
 
+> Spor D-signalet leser den **cachede** `scripts/kb-eval/data/skill-score-report.json` (aldri live — buildReport leser ~400 ref-filer); gitignored/regenererbar via `score-skill.mjs --write`, så fraværende i fersk klon → kun synlig for en vedlikeholder, og kun for skills <90 %.
+
 > Secrets scanning consolidated to llm-security plugin.
 
 ## Reference docs (read on demand)
 
 - **Utvikling, testing, KB-refresh-workflow:** `docs/development.md`
 - **Playground v3 (decision-builder + rapport-viewer):** `docs/playground.md`
-- **Recommended MCP servers (detail):** `references/architecture/recommended-mcp-servers.md`
+- **Recommended MCP servers (detail):** `skills/ms-ai-advisor/references/architecture/recommended-mcp-servers.md`
 
 ## Viktige frister (EU AI Act)
 
+> **NB — Digital Omnibus (vedtatt, avventer OJ):** Digital Omnibus utsetter høyrisiko-fristene i AI Act. Endringen er **formelt vedtatt** (Europaparlamentet 16. juni, Rådet 29. juni 2026) og trer i kraft tredje dag etter publisering i Official Journal — senest 2026-07-30 for anvendelse før 2026-08-02. Datoene under følger vedtatt tekst og bekreftes mot OJ ved publisering. Kjør `/architect:classify` for systemspesifikk vurdering.
+
 | Frist | Krav | Status |
 |-------|------|--------|
 | 2025-02-02 | Forbudte AI-praksiser (Art. 5) | Gjeldende |
-| 2025-08-02 | Governance og sanksjoner (Art. 99) | Gjeldende |
-| 2026-08-02 | GPAI-krav + Annex III høyrisiko | 161 dager |
-| 2027-08-02 | Alle høyrisiko-krav (full compliance) | 527 dager |
+| 2025-08-02 | GPAI-krav + governance/sanksjoner (Art. 99) | Gjeldende |
+| 2026-08-02 | Transparens (Art. 50): merking av syntetisk innhold | Fra 2026-08-02 |
+| 2026-12-02 | Art. 50(2): frist for maskinlesbar merking i eksisterende generative systemer | Overgang (Omnibus) |
+| 2027-12-02 | Annex III høyrisiko (frittstående) — utsatt fra 2026-08-02 | Vedtatt (Omnibus, avventer OJ) |
+| 2028-08-02 | Annex I høyrisiko (innebygd i regulerte produkter) | Vedtatt (Omnibus, avventer OJ) |
 
-**Tilsynsmyndigheter:** Datatilsynet (personvern), nasjonal AI-tilsynsmyndighet (under etablering), sektortilsyn.
+> Maskinlesbar kilde: `scripts/kb-update/data/ai-act-deadlines.json` — synk-testet mot denne tabellen, assessor-malen og hookene (`tests/kb-update/test-ai-act-deadlines-sync.test.mjs`). Oppdater kilden først.
+
+**Tilsynsmyndigheter:** Nkom (koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for AI-forordningen), Datatilsynet (personvern), sektortilsyn kan utpekes i tillegg.
 
 ## Relaterte plugins (fremtidig)
 
-- `ms-rag-architect` — RAG-spesialist (egen plugin)
-- `ms-power-automate-architect` — Power Automate deep-dive
-- `ms-azure-ai-architect` — Azure AI Services deep-dive
-- `ms-foundry-architect` — Azure AI Foundry spesialist
-- `ms-copilot-studio-architect` — Copilot Studio spesialist
+Planlagte søsken-plugins: `ms-rag-architect` (RAG), `ms-power-automate-architect`, `ms-azure-ai-architect`, `ms-foundry-architect`, `ms-copilot-studio-architect`.

README.md

@@ -6,9 +6,9 @@
 
 *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)*
 
-![Version](https://img.shields.io/badge/version-1.15.0-blue)
+![Version](https://img.shields.io/badge/version-1.17.0-blue)
 ![Platform](https://img.shields.io/badge/platform-Claude_Code_Plugin-purple)
-![Docs](https://img.shields.io/badge/reference_docs-387-green)
+![Docs](https://img.shields.io/badge/reference_docs-389-green)
 ![Agents](https://img.shields.io/badge/agents-12-orange)
 ![License](https://img.shields.io/badge/license-MIT-lightgrey)
 
@@ -37,7 +37,7 @@ A Claude Code plugin that provides structured architecture guidance across the f
 
 ## What Is This?
 
-This plugin gives you access to **Cosmo Skyberg**, a virtual Microsoft AI solution architect who guides you through structured decision-making across Azure AI Foundry, Copilot Studio, Power Platform AI, Microsoft 365 Copilot, and the broader Microsoft agent ecosystem.
+This plugin gives you access to **Cosmo Skyberg**, a virtual Microsoft AI solution architect who guides you through structured decision-making across Microsoft Foundry, Copilot Studio, Power Platform AI, Microsoft 365 Copilot, and the broader Microsoft agent ecosystem.
 
 Unlike a chatbot that answers questions, Cosmo follows a **7-phase advisory methodology**: understand the business need, map the technical context, assess team capability, validate against live documentation, integrate domain knowledge from 380 reference documents, deliver a concrete architecture recommendation, and optionally visualize it.
 
@@ -120,15 +120,18 @@ Cosmo will ask clarifying questions about your business need, licenses, data sou
 | `/architect:ros` | Risk and Vulnerability Analysis (ROS) with 7 dimensions and AI threat library |
 | `/architect:security` | Security and compliance assessment (6-dimension scoring) |
 | `/architect:cost` | Cost estimate with confidence grading in NOK |
+| `/architect:businesscase` | Business case with net present value (NPV) and DFØ benefits realization |
 | `/architect:review` | Architecture review against Norwegian public sector requirements |
 | `/architect:dpia` | DPIA/PVK for an AI system with risk matrix and mitigation table |
 | `/architect:license` | Map AI capabilities per license type (E3, E5, F1, G5, etc.) |
+| `/architect:vendor` | Third-party / SaaS vendor due diligence — data residency, sub-processors, DPA, Schrems II, AI Act deployer obligations |
 
 ### Documentation & Output
 
 | Command | Description |
 |---------|-------------|
 | `/architect:adr` | Generate Architecture Decision Record (MADR v3.0) |
+| `/architect:design` | Sector-neutral Solution Architecture Document (SAD) — context, NFRs, options, chosen design, risk, roadmap |
 | `/architect:summary` | Generate executive summary and decision memo from assessments |
 | `/architect:diagram` | Generate architecture diagram with Imagen 3 or Mermaid |
 | `/architect:export` | Export architecture document to PDF |
@@ -140,6 +143,7 @@ Cosmo will ask clarifying questions about your business need, licenses, data sou
 | `/architect:utredning` | Full AI architecture investigation for Norwegian public sector |
 | `/architect:poc` | Generate POC plan with success criteria and risk assessment |
 | `/architect:migrate` | Plan migration between Microsoft AI platforms |
+| `/architect:anskaffelse` | AI procurement plan — requirements spec, vendor evaluation, thresholds |
 
 ### Setup & Maintenance
 
@@ -166,7 +170,7 @@ The plugin delegates specialized work to 12 purpose-built agents. Each agent has
 | `license-mapper-agent` | Cross-reference licenses vs. platform capabilities | ms-ai-advisor | `/architect:license` |
 | `diagram-generation-agent` | Architecture diagrams via Imagen 3 / Mermaid | Prompt templates | `/architect:diagram` |
 | `summary-agent` | Executive summary and decision memo synthesis | All assessment outputs (incl. ROS) | `/architect:summary` |
-| `onboarding-agent` | 5-phase structured org interview | Writes org/*.md | `/architect:onboard` |
+| `onboarding-agent` | 5-phase structured org interview | Writes ~/.claude/ms-ai-architect/org/*.md (user-owned, survives reinstall) | `/architect:onboard` |
 | `ai-act-assessor` | EU AI Act classification, obligations, and compliance assessment | ms-ai-governance (ai-act-*) | `/architect:classify`, `/architect:requirements`, `/architect:transparency`, `/architect:frimpact`, `/architect:conformity` |
 
 ### Orchestration Pattern
@@ -200,14 +204,14 @@ The orchestrator creates a `.work/` directory for intermediate results, delegate
 
 ## Knowledge Base
 
-The plugin includes **387 reference documents** organized across 5 domain-specific skills:
+The plugin includes **389 reference documents** organized across 5 domain-specific skills:
 
 | Skill | Domain | Refs | User Intent |
 |-------|--------|------|-------------|
 | `ms-ai-advisor` | Cosmo persona, 7-phase workflow, platform selection | 62 | "Help me choose" |
 | `ms-ai-engineering` | RAG, agents, Azure AI Services, data, MLOps, multimodal | 153 | "How do I build this?" |
 | `ms-ai-governance` | Norwegian public sector governance, EU regulations, responsible AI, ROS | 78 | "Is this legal/safe?" |
-| `ms-ai-security` | Security scoring (6×5), cost estimation (P10/P50/P90) | 60 | "Is this safe?" |
+| `ms-ai-security` | Security scoring (6×5), cost estimation (P10/P50/P90) | 62 | "Is this safe?" |
 | `ms-ai-infrastructure` | BCDR, hybrid/edge, sovereign cloud | 34 | "How do I operate this?" |
 
 ### ms-ai-advisor (62 refs)
@@ -216,13 +220,13 @@ Architecture decision trees, platform comparison matrices, Cosmo persona definit
 
 ### ms-ai-engineering (153 refs)
 
-RAG implementation patterns, agent orchestration, Azure AI Foundry, Copilot Studio extensibility, AI Builder, multimodal processing, Semantic Kernel, MLOps pipelines.
+RAG implementation patterns, agent orchestration, Microsoft Foundry, Copilot Studio extensibility, AI Builder, multimodal processing, Semantic Kernel, MLOps pipelines.
 
 ### ms-ai-governance (78 refs)
 
 Norwegian public sector governance (Digdir, DFØ), EU AI Act (Annex III checklist), responsible AI frameworks, GDPR/Schrems II compliance, Utredningsinstruksen alignment. Includes a comprehensive **ROS analysis framework** with 7 new reference documents: AI threat library (49 threats across 7 categories), NS 5814/ISO 31000 methodology guide, 7×5 scoring rubrics, sector-specific checklists (health, transport, finance, justice, education), report templates, DPIA/security integration patterns, and MAESTRO multi-agent security model.
 
-### ms-ai-security (60 refs)
+### ms-ai-security (62 refs)
 
 6×5 security scoring rubrics, threat modeling for AI systems, content safety, cost optimization, deterministic cost calculation model, data residency patterns.
 
@@ -273,11 +277,28 @@ BCDR planning, hybrid and edge deployment, sovereign cloud (Norway regions), net
 /architect:export            # PDF for stakeholders
 ```
 
+### 5. Private Sector / Enterprise — Design → Security → Cost → ADR
+
+The same depth applies outside the public sector, without the Utredningsinstruksen/Digdir scaffolding:
+
+```
+/architect:classify          # AI Act applies to all providers/deployers — public and private
+/architect:design            # Sector-neutral Solution Architecture Document (not utredning)
+/architect:security          # 6-dimension security assessment
+/architect:cost              # Cost estimate with P10/P50/P90
+/architect:vendor            # Due diligence on external SaaS/AI vendors
+/architect:adr               # Formalize the decision
+```
+
+> For **regulated** private sector (finance), `/architect:ros` and `/architect:requirements` auto-surface DORA / Finanstilsynet / Finansforetaksloven coverage via the 17-point finance checklist in the KB. Note: FRIA (`/architect:frimpact`) is mandatory for private deployers in credit scoring (excl. fraud detection) and life/health-insurance pricing — not only public bodies.
+
 ---
 
 ## Norwegian Public Sector Features
 
-This plugin is specifically designed for Norwegian public sector governance requirements:
+This plugin's regulatory depth is calibrated for Norwegian public sector — but the core (security scoring, cost models, ROS, the finance/DORA checklist, RAG/engineering KB) is sector-agnostic. Private and regulated-sector users get a parallel path: see [Workflow Example 5](#workflow-examples) and `/architect:design` / `/architect:vendor`.
+
+The public sector framework coverage:
 
 ### Regulatory Frameworks
 
@@ -353,7 +374,7 @@ Two runtime hooks provide session context and safety guardrails:
 Interactive **decision-builder + report viewer** for Microsoft AI architecture decisions, runnable from `file://` without a server. Replaces the v2 5-step pipeline with a multi-surface app that persists state across sessions and visualizes parsed reports inline.
 
 - **File:** `playground/ms-ai-architect-playground.html` (~3870 lines, single-file v3 architecture)
-- **4 surfaces:** Onboarding (18 shared fields) → Home (project list + 3 entry tracks) → Catalog (24 commands grouped by 5 expansion categories with search) → Project (per-project tabs, command form prefill, paste-back report import + visualization)
+- **4 surfaces:** Onboarding (18 shared fields) → Home (project list + 3 entry tracks) → Catalog (29 commands grouped by 5 expansion categories with search) → Project (per-project tabs, command form prefill, paste-back report import + visualization)
 - **Persistent state:** IndexedDB primary store with localStorage fallback. Schema-versioned (`STATE_KEY = 'ms-ai-architect-state-v1'`) with eager `MIGRATIONS` pipeline.
 - **17 report renderers:** Each report-producing command has a parser (markdown → structured) and renderer (structured → HTML visualization: pyramid, matrix, radar, findings, distribution, capability-matrix, etc.) wired through a canonical archetype-routing table.
 - **Theme:** Dark default + light mode toggle, persisted in `localStorage('ms-ai-architect-theme')`. Both themes ship Aksel-aligned tokens (full WCAG AA contrast) as of v1.10.0; theme-bootstrap script in `<head>` prevents FOUC.
@@ -413,7 +434,7 @@ Screenshots of every surface in both themes live in `playground/screenshots/v1.1
 | 03 | `03-project-rapporter-tool-{dark,light}.png` | 7 tool commands (no report — pipeline-string builders) |
 | 04-06 | `04-project-oversikt-{dark,light}.png` etc. | Project screen-tabs (oversikt / kontekst / eksport) |
 | 07 | `07-home-{dark,light}.png` | Home with project list + 3 entry tracks |
-| 08 | `08-catalog-{dark,light}.png` | Catalog with 24 commands in 5 expansion-grupper |
+| 08 | `08-catalog-{dark,light}.png` | Catalog with 29 commands in 5 expansion-grupper |
 | 09 | `09-onboarding-prefilled-{dark,light}.png` | Onboarding with state from demo |
 
 Regenerate via `cd tests/screenshot && npm install && npx playwright install chromium && node run.mjs`.
@@ -422,7 +443,7 @@ Regenerate via `cd tests/screenshot && npm install && npx playwright install chr
 
 | Test | Command | Coverage |
 |------|---------|----------|
-| Static structure | `bash tests/test-playground-v3.sh` | 201 PASS — vendored CSS, surfaces, 24 commands, 14 parsers, 17 renderers (felles grunnskjelett), design-system classes, action handlers, Tier 3-bruk, onboarding field-distribution |
+| Static structure | `bash tests/test-playground-v3.sh` | 223 PASS — vendored CSS, surfaces, 29 commands, 14 parsers, 17 renderers (felles grunnskjelett), design-system classes, action handlers, Tier 3-bruk, onboarding field-distribution |
 | Parser fixtures | `bash tests/test-playground-parsers.sh` | 70 PASS — 17 fixtures × parser routing |
 | Migrations | `bash tests/test-playground-migrations.sh` | 7 PASS — v1→v2 idempotent migration |
 | Combined (E2E) | `bash tests/run-e2e.sh --playground` | static + parser suites |
@@ -444,7 +465,7 @@ The playground loads CSS from `playground/vendor/playground-design-system/` —
 |--------|-------------|
 | Copilot Family | Microsoft 365 Copilot, Copilot Studio, Sales Copilot, Service Copilot |
 | Power Platform | Power Automate, Power Apps, AI Builder |
-| Azure AI Foundry | Agent Service, Model Router, Prompt Flow, Model Catalog |
+| Microsoft Foundry | Agent Service, Model Router, Prompt Flow, Model Catalog |
 | Azure AI Services | Azure OpenAI, AI Search, Document Intelligence, Speech, Vision |
 | Development | Microsoft Agent Framework, Semantic Kernel, AutoGen |
 | Security | Microsoft Purview, Defender for Cloud, Content Safety |
@@ -581,7 +602,7 @@ bash tests/capture-fixture.sh <source-file> <section-header> <output-dir>
 
 ### Knowledge Base Maintenance
 
-The 387+ reference documents are actively maintained by the plugin author. Updated reference files are published as regular commits to the marketplace repository. If you installed via `claude plugin marketplace add`, updates are pulled automatically — no manual action needed.
+The 389+ reference documents are actively maintained by the plugin author. Updated reference files are published as regular commits to the marketplace repository. If you installed via `claude plugin marketplace add`, updates are pulled automatically — no manual action needed.
 
 For forks (or if you simply want to refresh the KB yourself), the plugin ships with a sitemap-based change-detection pipeline plus a slash command that drives the apply-fasen via the active Claude Code session.
 
@@ -630,7 +651,7 @@ node scripts/kb-update/build-registry.mjs [--merge]
 /architect:generate-skills
 ```
 
-Category-to-skill routing is defined in `scripts/skill-gen/category-skill-map.json` (20 categories mapped to 5 skills), used by the generate-skills workflow to place new reference documents in the correct skill directory.
+Category-to-skill routing is defined in `scripts/kb-update/data/domain-taxonomy.json` (the lag-0 single source of truth, read via `lib/taxonomy.mjs` → `getCategorySkill`). It uses physical-disk truth and supersedes the old `category-skill-map.json` (removed — it had drifted from disk and was consumed by no code).
 
 ---
 
@@ -638,6 +659,13 @@ Category-to-skill routing is defined in `scripts/skill-gen/category-skill-map.js
 
 | Version | Date | Highlights |
 |---------|------|-----------|
+| **1.17.0** | 2026-07-04 | **Spor 1 — Port-1-substrat migrert** på de 4 ikke-advisor-skills (327 filer). `**Type:**` stemplet på alle 327; `**Source:**` (Microsoft Learn-autoritet) backfilt på 243 sourced reference-filer; `## Innhold` TOC på 325 store filer. Stale `**Verified:** MCP`-poison fjernet (14 header + 9 stray body-dup i 500B-vinduet) → full-pass-worklist aktivert (243 due, 0 fresh). Prosa byte-identisk (fra første `##`), advisor-skillen urørt, `verified` null (settes i senere judge-pass). To applier-fixes TDD'd (`insertHeaderFields` giant-meta-anker, `normalizeStaleVerified` in-window body-dup). Suite 728/728. Utfall: `docs/spor1-migration-outcome.md`. |
+| **1.16.5** | 2026-06-24 | KB-refresh-patch (kun reference docs). **LOW-tier 52 filer** verifisert mot Microsoft Learn (post-1.16.4 baseline; ~33 TRYGT header-bump, resten reell drift/URL-/syntaksfiks). **Materiell fiks:** `agent-framework` fullstendig omskrevet (oppdiktet `azure.ai.agent`-API → ekte SDK `agent-framework`/`Microsoft.Agents.AI`: `Agent(client=...)`, `@tool`, `WorkflowBuilder`, OpenTelemetry; suksessor til SK **og** AutoGen) + `migration-patterns` §6 tilsvarende. **Norsk AI Act** ikrafttredelse mykgjort (forsinket pga. EØS). **Copilot Credits** (tidl. billed sessions). **Data eng:** Fabric mirroring / OneLake Security / liquid clustering Preview→GA, Lakeflow SDP-rebrand. **APIM:** KQL `DeploymentName`, token-quota, v2-tier-matriser. **BCDR:** Azure Cache for Redis → Managed Redis. **Cosmo-utfasing startet** («For Cosmo» fjernet i 2 filer; full fjerning som eget initiativ). `git diff` + validering 239/0. Needing-update 52 → 0 (alle tiers 0). |
+| **1.16.4** | 2026-06-24 | KB-refresh-patch (kun reference docs). **MEDIUM-tier 33 filer** verifisert mot Microsoft Learn (18 TRYGT header-bump, 15 reell drift). **Prompt-caching** in-memory vs extended 24t (`prompt_cache_retention`); **Realtime** `gpt-realtime-1.5` + GA-endepunkt `/openai/v1`; **Guardrails**-rebranding (tidl. content filters, `Microsoft.DefaultV2`); `ND96asr_v4` 320 GB (var 640); PTU min Global/Data Zone 15 (var 50); **Deep Research + Connected agents deprecated**, Prompt Flow-retirement 2027-04-20, A2A Java; nye agent-evaluatorer + `FoundryEvals`; **procedural memory** + Norway East; **Speaker Recognition Limited Access**. GPT-4.1-pricing forble uverifiserbar (community-kilder) → urørt. Hver `VERIFY` re-bekreftet av main-agent mot kilde FØR skriving; `git diff` + validering 239/0. Medium 33 → 0 (needing-update 85 → 52). |
+| **1.16.3** | 2026-06-24 | KB-refresh-patch (kun reference docs). **HIGH-tier 11 filer + 1 dateless kjernefil** verifisert mot Microsoft Learn. **Faktafiks:** Content Safety image-modeller Medium-terskel (ikke «Low»); `gpt-4.1-mini` = GPT-4.1-variant (ikke o-series reasoning); CMK Key Vault Azure RBAC «Key Vault Crypto Service Encryption User» som primæralternativ (ikke «legacy access policies»). **Lagt til:** Task Adherence (preview) i guardrails-risk-kategorier, Prompt Flow retirement 2027-04-20, 5. data-privacy-garanti, «Models sold by Azure»-terminologi, `security.md` maskinlesbar header. **Avkreftet ved verifisering:** Content Safety Analyze Text 10K-tegn-grensen var korrekt (drift-rapportens «1000» = feillesing av Transparency Note-anbefaling). Hver `VERIFY` bekreftet mot kilde FØR skriving; disclaimed priser urørt; `git diff` + plugin-validering 239/0. High 11 → 0, Unverified 1 → 0 (needing-update 97 → 85). |
+| **1.16.2** | 2026-06-24 | KB-refresh-patch (kun reference docs — ingen kommando-/agent-/skill-endringer). **Critical cost-klyngen** (8 filer i `cost-optimization/`) verifisert + oppdatert mot Microsoft Learn: Spillover GA, **Priority processing** (4. deployment-type), **Data Zone Batch** (SKU `DataZoneBatch`, EU/US-datasone), modell-lineup GPT-5 → 5.1/5.5, extended prompt-cache 24t, RFT-kostnadsmodell ($5000 per-job-tak), batch fail-fast-retry (server fail-fast + klient-side backoff), On Your Data-pensjon (2026-10-14). **Kalibrering:** fjernet uverifiserbart «175B+» (GPT-4o), «GPT-4 utfaset» → «legacy», og avkreftet én drift-påstand ved verifisering (Phi-3/Phi-2/Falcon-7B fortsatt i Foundry-katalogen → ingen «retired»-merking). Hver `VERIFY`-påstand bekreftet mot kilde FØR skriving; disclaimed priser urørt; `git diff` + plugin-validering 239/0. Critical-count 8 → 0. |
+| **1.16.1** | 2026-06-23 | KB-refresh-patch (kun reference docs — ingen kommando-/agent-/skill-endringer). **Modellkatalog** GPT-5.1 → GPT-5.5 i 3 filer (`batch-processing-cost-reduction.md`, `model-selection-price-performance.md`, `azure-ai-foundry.md`). **Foundry-navnesveip** «Azure AI Foundry» → «Microsoft Foundry» på tvers av 233 reference docs (810 forekomster). **RBAC** «Azure AI User» → «Foundry User» (`foundry-workflows-visual-orchestration.md`; cost-governance-mappingen bevart). Hvert premiss verifisert mot Microsoft Learn før sveip; `git diff` + plugin-validering + deterministisk re-score (skills uendret, alle ≥90 %). |
+| **1.16.0** | 2026-06-22 | Currency- og privat-sektor-paritets-audit (devil's-advocate-audit 2026-06-18, 10 dimensjoner, 89 verifiserte funn — `docs/devils-advocate-audit-2026-06-18.md`). **Regulatorisk:** EU AI Act-tidslinje re-baselinet mot Digital Omnibus (Annex III høyrisiko → 2027-12-02, Art. 50 → 2026-08-02) + Art. 99-bøtesatser (35M/7 %, 15M/3 %, 7,5M/1 %); EU AI Act ennå ikke EØS-innlemmet, KI-loven uvedtatt per juni 2026; DPIA cross-border med EDPB Rec 01/2020 seks-stegs-TIA + CLOUD Act/FISA-restanalyse + EDPB 28/2024 (anonymisering case-by-case). **Plattform:** Foundry URL-navnerom-migrering (`ai-foundry` → `foundry`/`foundry-classic`, 141 filer); Connected Agents deprecated (pensjon 2027-03-31) → Prompt/Hosted agents + Responses API; MAF 1.0 GA + A2A v1.0.1; Prompt Flow retirement 2027-04-20; CUA GA 2026-05-07; agentic retrieval GA-split. **Kostnad:** re-baselinet til GPT-5 $1,25/$10 med én prissannhet. **Dataresidens:** korrigert Norway East (gpt-4o + gpt-4o-mini eneste Norge-residente generative). **Sikkerhet:** Defender AI threat protection (ikke Azure Government) + OWASP LLM04/06/08/09-tiltak (2 nye KB-filer); M365 E7 + Agent 365 (GA 2026-05-01); Foundry Local air-gapped. **Privat-sektor-paritet:** sektor-parametrisering i 6 kommandoer + onboarding-forgrening + 4 nye kommandoer (`businesscase`, `anskaffelse`, `design`, `vendor` → 25 → 29 totalt). ROS/DPIA-currency (NSM v2.1, OWASP Agentic 2026, EchoLeak, DPF, EUDB). **Selvstendiggjøring (Spor C):** planlagt KB-deteksjon (opt-in, Claude-fri; Tier 1 SessionStart-hook + Tier 2 OS-scheduler launchd/cron) + onboarding-redesign (bruker-eid `~/.claude/ms-ai-architect/`, ambient org-injeksjon, valgfritt fritekst-felt, scheduler-kadens i onboarding, privat-sektor-paritet låst med regresjonsvakt). 389 reference docs (ms-ai-security 60 → 62). 239 plugin-validering · kb-integrity 192/192 · run-e2e alle suiter (+ onboarding-parity 14/14) 0 FAIL. Playground-koden uendret siden v1.15.0 (kun doc-stamp bumpet; screenshots ikke regenerert). |
 | **1.15.0** | 2026-05-16 | Playground v3 project-view integration — `renderProjectSurface` (v2 screen-tabs + category-tabs + per-command paste-cards) erstattet av `renderProjectView` (sidebar med 17 artifacts + main-area + import-modal overlay). `renderActive()` delegerer nå til `renderProjectSurfaceV3()`. Dead code fjernet: `renderCommandSubCard`, `rehydratePasteImports`, `currentProjectScreen`, `ACTIONS['project-screen']`, 5 v2-CSS-klasser (`.project-tabs`, `.project-tab`, `.project-tab__count`, `.sub-zone`, `.paste-import-row`, `.project-header__*`, `.command-cards`). 2 fingerprint-gap lukket: `requirements.headers` matcher nå "EU AI Act — Krav for høyrisiko..."; `license.headers` matcher "Lisens-kapabilitetsmatrise...". v2→v3 migrasjon utvidet med `parserFor` slik at demo-state med kun `raw_markdown` auto-parses inn i `project.artifacts[cid]`. `components-tier4-project-view.css` wired inn (var ikke loaded — modal-overlay og two-column layout virket ikke). `renderImportModal` setter `data-open="true"` (DS-kontrakt). 219 plugin-validering, 386 E2E playground (32 fingerprints, 219 v3-static, 70 parsers, 16 migrations, 30 project-view, 19 actions), 0 FAIL, 2 WARN (pre-eksisterende). 24 screenshots regenerert til `playground/screenshots/v1.15.0/`. Demo viser nå 17 artifacts navigerbare i sidebar, aggregate verdict (BLOKKERT), top-risks-liste, og fungerende re-importer/slett-knapper per artifact. |
 | **1.14.0** | 2026-05-08 | Playground root-cause refaktor — DS-konvensjon-adopsjon på tvers av 14 renderere over 6 sesjoner. Sesjon 2: B-DS-1/2/3 fikset i shared/ DS v0.4.0 (kanban-card word-break, expansion title-block, matrix-bubble cursor). Sesjon 3: renderDpia/Security/Ros til DS-summary-grid + ros-layout. Sesjon 4: 6 compliance/govern-renderere bytter `.report-meta`-wrapper mot DS-konvensjon (renderAiActPyramid, renderRequirements, renderConformity, renderTransparency, renderFria, renderReview). Sesjon 5: renderMigrate + renderPoc → expansion-list per fase (slett `.phase-detail`-CSS). Sesjon 5b: renderCost key-stats viste "[object Object]" (parser-output har p50/p90 = {monthly,yearly}-objekter — nå ekstrahert via `.monthly`); renderCompare distinctive-token-matching erstatter firstWord-heuristikk; renderUtredning droppet misvisende `role="tab"`-attributter. Lokal `<style>`-blokk: 191 → 122 effektive linjer (~36% reduksjon). 17 renderere PASS visuell QA mot demo-data. 219 plugin-validering, 272 E2E playground, 7 migrations PASS. 24 screenshots regenerert. |
 | **1.13.1** | 2026-05-06 | Playground visual bugs patch — 10 bugs identifisert post-v1.13.0 av maintainer i nettleser. Fixet: (B7) classify Forpliktelser indent via `.report-meta` CSS-reset; (B8a) `requirement-expand` ACTIONS-handler manglet — R-01..R-09-rader i AI Act-krav var ikke klikkbare; (B8b) expansion title-main + title-sub display:block så de stables; (B10) kanban-card `word-break:break-word` override DS' break-all; (B11) DPIA matrix-bobler match by description (Pass 1 first-cell exact + Pass 2 any-cell substring); (B12, B13, B15) defensive `display:block; clear:both; width:100%` på top-risks/suppressed-panel/phase-detail/aiact-timeline; (B14) Migrate/POC phases-summary-tabell over phase-detail-seksjoner. 23/23 smoke + 271 E2E + 219 plugin-validering. |

agents/adr-writer-agent.md

@@ -2,12 +2,12 @@
 name: adr-writer-agent
 description: |
   Generates Architecture Decision Records (ADR) in MADR v3.0 format from structured input.
-  Reads adr-template.md, fills in from session context, and writes to file.
+  Reads adr-template.md, fills in from session context, and returns the ADR markdown to the main context.
   Use when architect:adr needs to generate a complete ADR document.
   Triggers on: ADR generation, decision documentation, architect:adr delegation.
 model: opus
 color: orange
-tools: ["Read", "Write", "Glob"]
+tools: ["Read", "Glob"]
 ---
 
 # ADR Writer Agent
@@ -28,18 +28,19 @@ Generate complete, self-contained ADR documents that:
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Process
 
 ### 1. Read Template
 
-Read `skills/ms-ai-advisor/references/architecture/adr-template.md` for the MADR v3.0 format.
+Read `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/adr-template.md` for the MADR v3.0 format.
 
 ### 2. Parse Input
 
@@ -86,9 +87,9 @@ Fill in every section of the MADR template:
 
 **Validering og oppfølging**: Concrete next steps with responsible party.
 
-### 4. Write to File
+### 4. Return to Main Context
 
-Write the ADR to the location specified in the input. Default: `docs/adr/ADR-NNN-[slug].md`
+Return the complete ADR markdown as your final message. The main context (the `/architect:adr` command) writes it to file — do not write files yourself (you run as a subagent).
 
 ## Output Format
 
@@ -100,7 +101,7 @@ The generated ADR should be:
 
 ## Quality Checklist
 
-Before writing:
+Before returning:
 - [ ] All template sections filled (no placeholders)
 - [ ] Compliance section included (even if "Not assessed")
 - [ ] Confidence level reflects actual analysis quality

agents/ai-act-assessor.md

@@ -23,26 +23,27 @@ You are a Norwegian regulatory compliance specialist focused on EU AI Act assess
 ## Knowledge Base References
 
 Read relevant files from:
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` — **OBLIGATORISK:** 4-stegs klassifiseringsmetodikk
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` — Provider-forpliktelser Art. 9-27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-forpliktelser Art. 26-27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` — FRIA-mal Art. 27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` — Samsvarsvurdering Annex IV/VI/VII
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 transparensnotiser
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` — Artikkel-til-verktøy-mapping
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` — Generell compliance-veileder
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` — Annex III sjekkliste med beslutningstre
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/norge-ai-strategy-government.md` — Norsk AI-strategi
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md` — Forvaltningsloven og AI
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` — **OBLIGATORISK:** 4-stegs klassifiseringsmetodikk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` — Provider-forpliktelser Art. 9-27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-forpliktelser Art. 26-27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` — FRIA-mal Art. 27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` — Samsvarsvurdering Annex IV/VI/VII
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 transparensnotiser
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` — Artikkel-til-verktøy-mapping
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` — Generell compliance-veileder
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` — Annex III sjekkliste med beslutningstre
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/norge-ai-strategy-government.md` — Norsk AI-strategi
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md` — Forvaltningsloven og AI
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Assessment Workflow (6 faser)
 
@@ -58,7 +59,7 @@ Ekstraher fra brukerens input:
 
 ### Fase 2: Klassifisering (4-stegs)
 Les `ai-act-classification-methodology.md` og utfør:
-1. **Forbudt-sjekk (Art. 5):** Er noen av de 8 forbudte praksisene relevante?
+1. **Forbudt-sjekk (Art. 5):** Er noen av de forbudte praksisene relevante? (8 i kraft; i tillegg nudifiers/NCII/CSAM-forbudet — Digital Omnibus, anvendelse 2026-12-02, avventer OJ)
 2. **Annex III høyrisiko-sjekk:** Treffer systemet noen av de 8 kategoriene?
 3. **GPAI-sjekk:** Er systemet basert på generell AI-modell? Systemisk risiko?
 4. **Begrenset/Minimal:** Transparenskrav eller frivillig Code of Conduct?
@@ -139,9 +140,11 @@ Anbefal oppfølgingsaktiviteter:
 | Frist | Krav | Relevans |
 |-------|------|----------|
 | 2025-02-02 | Forbudte AI-praksiser (Art. 5) | [Gjelder/Gjelder ikke] |
-| 2025-08-02 | Governance og sanksjoner (Art. 99) | [Gjelder/Gjelder ikke] |
-| 2026-08-02 | GPAI-krav + Annex III høyrisiko | [Gjelder/Gjelder ikke] |
-| 2027-08-02 | Alle høyrisiko-krav (full compliance) | [Gjelder/Gjelder ikke] |
+| 2025-08-02 | GPAI-krav + governance/sanksjoner (Art. 99) | [Gjelder/Gjelder ikke] |
+| 2026-08-02 | Transparens (Art. 50, syntetisk innhold) | [Gjelder/Gjelder ikke] |
+| 2026-12-02 | Art. 50(2): maskinlesbar merking i eksisterende generative systemer | [Gjelder/Gjelder ikke] |
+| 2027-12-02 | Annex III høyrisiko — utsatt fra 2026-08-02 (Omnibus vedtatt, avventer OJ) | [Gjelder/Gjelder ikke] |
+| 2028-08-02 | Annex I høyrisiko innebygd (Omnibus vedtatt, avventer OJ) | [Gjelder/Gjelder ikke] |
 
 ### Referanser
 - [Liste over KB-filer og MCP-kilder brukt]
@@ -174,8 +177,8 @@ Bruk `microsoft_docs_search` for:
 ## Norwegian Public Sector Context
 
 - Alle vurderinger gjøres i norsk kontekst (EØS-implementering)
-- Datatilsynet er sannsynlig tilsynsmyndighet (personverndimensjon)
-- Nasjonal AI-tilsynsmyndighet er under etablering
+- Nkom er koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for AI-forordningen i Norge
+- Datatilsynet er tilsynsmyndighet for personverndimensjonen; sektortilsyn kan utpekes i tillegg
 - Forvaltningsloven gjelder i tillegg til AI Act for vedtakssystemer
 - Offentlig sektor er nesten alltid deployer, sjelden provider
 

agents/architecture-review-agent.md

@@ -63,7 +63,7 @@ For høyrisiko-systemer, verifiser:
 - [ ] **FRIA gjennomført (Art. 27):** Obligatorisk for offentlig sektor-deployers
 
 **Ekstra KB-referanse:**
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md`
 
 ### 3. Utredningsinstruksen (Analysis Requirements)
 - **Problem description**: Clear problem statement, affected parties identified
@@ -156,28 +156,31 @@ Read the architecture proposal. Extract:
 
 ### 2. Load Reference Knowledge
 Read relevant knowledge base files:
-- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — Platform selection validation
-- `skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
-- `skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance checklist
-- `skills/ms-ai-advisor/references/architecture/ai-utredning-template.md` — Utredningsinstruksen template
-- `skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost estimation patterns
-- `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — License requirements
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — Platform selection validation
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance checklist
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md` — Utredningsinstruksen template
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost estimation patterns
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — License requirements
 
 Load domain-specific references only when dimension requires depth (max 2-3 additional):
-- AI Act: `responsible-ai/ai-act-compliance-guide.md`, `responsible-ai/ai-act-annex-iii-checklist.md`
-- Governance: `responsible-ai/ai-governance-structure-framework.md`
-- Norwegian: `norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md`
-- Security: `ai-security-engineering/ai-threat-modeling-stride.md`
-- Cost: `cost-optimization/azure-ai-foundry-cost-governance.md`, `cost-optimization/deterministic-cost-calculation-model.md`
+- AI Act: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md`
+- Governance: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md`
+- Norwegian: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md`
+- Security: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md`
+- Cost: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md`
+- RAG-arkitektur (når løsningen er RAG-/gjenfinningsbasert): `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/agentic-rag-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md`
+- MLOps/GenAIOps (når løsningen har produksjons-/livssyklusfokus): `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/monitoring-observability-ml-systems.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/model-deployment-strategies-azure.md`
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ### 3. Validate Against Latest Guidance
 Use `microsoft_docs_search` to verify:
@@ -188,7 +191,7 @@ Use `microsoft_docs_search` to verify:
 Example queries:
 - "Azure Well-Architected Framework AI workloads"
 - "Copilot Studio governance best practices"
-- "Azure AI Foundry security configuration"
+- "Microsoft Foundry security configuration"
 
 ### 4. Assess Each Dimension
 For each of the 6 dimensions:

agents/cost-estimation-agent.md

@@ -20,7 +20,7 @@ You are a Microsoft AI cost analyst specializing in estimating and comparing cos
 
 ## Your Mission
 
-Provide accurate, comprehensive cost estimates for Microsoft AI solutions including Azure AI Foundry, Copilot Studio, Power Platform AI, and M365 Copilot. Always present costs in Norwegian Kroner (NOK) and clearly distinguish between verified and estimated pricing.
+Provide accurate, comprehensive cost estimates for Microsoft AI solutions including Microsoft Foundry, Copilot Studio, Power Platform AI, and M365 Copilot. Always present costs in Norwegian Kroner (NOK) and clearly distinguish between verified and estimated pricing.
 
 ## Cost Estimation Process
 
@@ -47,7 +47,7 @@ Provide accurate, comprehensive cost estimates for Microsoft AI solutions includ
 
 **ALWAYS start by reading:**
 ```bash
-Read skills/ms-ai-advisor/references/architecture/cost-models.md
+Read ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
 ```
 
 This file contains verified pricing data and calculation formulas.
@@ -55,23 +55,24 @@ This file contains verified pricing data and calculation formulas.
 ## Knowledge Base References (max 3 per invokasjon)
 
 Read these core files:
-- `skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` — **OBLIGATORISK:** Enhetspriser, beregningsformler, P10/P50/P90 konfidensintervaller
-- `skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md` — FinOps-rammeverk
-- `skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost model templates
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` — **OBLIGATORISK:** Enhetspriser, beregningsformler, P10/P50/P90 konfidensintervaller
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md` — FinOps-rammeverk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost model templates
 
 Load additional files only when estimate requires specific depth:
-- PTU: `cost-optimization/ptu-vs-paygo-economics.md`
-- Caching: `cost-optimization/semantic-caching-patterns.md`
-- Model selection: `cost-optimization/model-selection-price-performance.md`
+- PTU: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/ptu-vs-paygo-economics.md`
+- Caching: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/semantic-caching-patterns.md`
+- Model selection: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/model-selection-price-performance.md`
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ### 4. Verify Current Pricing
 
@@ -134,7 +135,7 @@ Brief description of what we're estimating.
 
 | Component | SKU/Tier | Quantity | Unit Price (NOK) | Monthly Cost (NOK) | Status |
 |-----------|----------|----------|------------------|-------------------|---------|
-| Azure OpenAI GPT-4 | S0 | 1M tokens | 0.50/1K | 500 | ✅ Verified |
+| Azure OpenAI GPT-4o-mini | Global Standard | per 1M tokens | $0.15/$0.60 (§1.1) | 500 | ✅ Verifisert |
 | AI Search | Standard S1 | 1 unit | 2 100 | 2 100 | ✅ Verified |
 | Storage | Standard LRS | 100 GB | 0.20/GB | 20 | ✅ Verified |
 | Copilot Studio | Capacity | 10 000 msgs | 200/1000 | 2 000 | ⚠️ Estimated |

agents/diagram-generation-agent.md

@@ -23,12 +23,13 @@ Du er en spesialisert diagramgenerator for Microsoft AI-arkitekturer. Du lager p
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Diagramtyper
 
@@ -44,7 +45,7 @@ Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
 
 Les prompt-maler fra:
 ```
-skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
+${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
 ```
 
 ## Azure-stilguide

agents/dpia-agent.md

@@ -14,26 +14,28 @@ tools: ["Read", "Glob", "Grep", "WebSearch", "mcp__microsoft-learn__microsoft_do
 
 You are a Norwegian data protection specialist conducting structured DPIAs for AI systems in Norwegian public sector. You assess privacy risks, evaluate necessity and proportionality, and ensure compliance with GDPR, Personopplysningsloven, and EU AI Act.
 
-## Knowledge Base References (max 3 per invokasjon)
+## Knowledge Base References (3 kjernefiler + betinget)
 
 Read these core files:
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` — DPIA-metodikk
-- `skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` — GDPR for AI
-- `skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` — Konsekvensvurdering
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` — DPIA-metodikk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` — GDPR for AI
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` — Konsekvensvurdering
 
 Load additional files only when assessment requires specific depth:
-- Bias: `responsible-ai/bias-detection-mitigation-strategies.md`
-- PII: `ai-security-engineering/pii-detection-norwegian-context.md`
-- Data leakage: `ai-security-engineering/data-leakage-prevention-ai.md`
+- Bias: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/bias-detection-mitigation-strategies.md`
+- PII: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/pii-detection-norwegian-context.md`
+- Data leakage: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/data-leakage-prevention-ai.md`
+- **Cross-border / Schrems II (OBLIGATORISK når data kan nås fra tredjeland — se Fase 3, risiko 7):** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` — EDPB seks-stegs-TIA, CLOUD Act/FISA 702/EO 12333-restanalyse, EO 14086/DPF-status, tekniske tilleggstiltak
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## AI Act-integrasjon
 
@@ -45,12 +47,12 @@ Før DPIA-vurderingen, sjekk om AI Act-klassifisering er utført:
 - Integrer deployer-forpliktelser fra `ai-act-deployer-obligations.md` som tiltak i Fase 4
 
 ### Hvis ikke klassifisert
-- Spør om det bør gjøres: "Er det gjennomført AI Act-klassifisering for dette systemet? Hvis nei, anbefaler vi `/architect:classify` — men DPIA fortsetter uansett."
+- Marker i rapporten at AI Act-klassifisering ikke er dokumentert, og anbefal `/architect:classify` som neste steg (du kjører som subagent uten brukertur — still ingen spørsmål)
 - Fortsett DPIA som normalt — klassifisering er ikke forutsetning
 
 ### Ekstra KB-referanser for AI Act
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-krav inkl. FRIA og logging
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 maler for transparenstiltak
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-krav inkl. FRIA og logging
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 maler for transparenstiltak
 
 ## DPIA Framework (5 Phases)
 
@@ -84,11 +86,24 @@ Risk categories for AI systems:
 4. Unauthorized access to personal data
 5. Function creep (purpose drift)
 6. Insufficient human oversight
-7. Cross-border data transfers (Schrems II)
+7. Cross-border data transfers (Schrems II) — **se obligatorisk TIA-prosedyre under**
 8. Model inversion / data extraction attacks
 9. Re-identification from anonymized data
 10. Automated decision-making without safeguards (GDPR Art. 22)
 
+#### Cross-border / Schrems II — obligatorisk TIA (risiko 7)
+
+Når systemet bruker en amerikansk-eid skyleverandør (Azure/Microsoft 365/Foundry) eller data på annen måte kan nås fra tredjeland, **er det ikke nok å navngi risikoen** — load `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` og gjennomfør EDPB seks-stegs Transfer Impact Assessment:
+
+1. Kartlegg overføringene (inkl. residual: support, troubleshooting, telemetri)
+2. Identifiser overføringsverktøyet (adekvansvedtak / SCCs / unntak)
+3. Vurder effektivitet mot mottakerlandets rett (FISA 702, EO 12333, CLOUD Act)
+4. Vedta tilleggstiltak — tekniske er sterkest (CMK, Customer Lockbox, Confidential Computing)
+5. Formelle prosedyresteg
+6. Revurder ved ny rettspraksis (Latombe-anken C-703/25 P) / §702-reautorisasjon
+
+**Nøkkelpoeng for DPO-svaret «kan amerikanske myndigheter nå disse dataene?»:** EU Data Boundary holder data i EØS, men fjerner ikke den juridiske tilgangsmuligheten — en amerikansk-eid leverandør forblir underlagt CLOUD Act/FISA uansett lagringsland. DPF-adekvansvedtaket (10. juli 2023) er gyldig per 2026-06, men er anket (mulig «Schrems III»), så restoverføringer krever dokumentert TIA med tekniske tiltak, ikke DPF alene.
+
 ### Phase 4: Measures and Residual Risk
 
 For each high/critical risk:
@@ -126,9 +141,9 @@ Read the AI system description or architecture proposal. Extract:
 
 ### 2. Load Reference Knowledge
 Core files are loaded via Knowledge Base References above. For deeper analysis:
-- Fairness: `responsible-ai/fairness-testing-measurement.md`
-- Transparency: `responsible-ai/transparency-documentation-standards.md`
-- Human oversight: `responsible-ai/human-in-the-loop-oversight.md`
+- Fairness: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/fairness-testing-measurement.md`
+- Transparency: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md`
+- Human oversight: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/human-in-the-loop-oversight.md`
 
 ### 3. Validate Latest Guidance
 Use `microsoft_docs_search` for:
@@ -210,7 +225,7 @@ Follow the output format below with all sections completed.
 
 If missing information:
 - State assumptions clearly
-- Request specific details needed
+- Note which specific inputs are missing rather than requesting them (you run as a non-interactive subagent with no user turn)
 - Provide conditional assessments
 - Note "Kan ikke vurdere [area] uten [info]"
 

agents/license-mapper-agent.md

@@ -20,12 +20,13 @@ You are a Microsoft licensing specialist that maps licenses to AI capabilities a
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Your Mission
 
@@ -40,11 +41,11 @@ Given a set of Microsoft license types, produce a complete capability map showin
 ### 1. Read Reference Data
 
 Read these files:
-- `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — master matrix
-- `skills/ms-ai-advisor/references/platforms/azure-ai-foundry.md` — Foundry capabilities
-- `skills/ms-ai-advisor/references/platforms/copilot-studio.md` — Copilot Studio capabilities
-- `skills/ms-ai-advisor/references/platforms/m365-copilot.md` — M365 Copilot capabilities
-- `skills/ms-ai-advisor/references/platforms/power-platform.md` — Power Platform capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — master matrix
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/azure-ai-foundry.md` — Foundry capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/copilot-studio.md` — Copilot Studio capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/m365-copilot.md` — M365 Copilot capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/power-platform.md` — Power Platform capabilities
 
 ### 2. Map Licenses to Capabilities
 
@@ -64,7 +65,7 @@ For each license type provided:
 5. AI Builder (document processing, prediction, text)
 6. Power Automate AI features
 7. Azure OpenAI Service
-8. Azure AI Foundry
+8. Microsoft Foundry
 9. Azure AI Search
 10. Microsoft Agent Framework
 

agents/onboarding-agent.md

@@ -2,7 +2,8 @@
 name: onboarding-agent
 description: |
   Conducts structured 5-category onboarding interview to collect org-specific context.
-  Writes context files to org/ directory for use by all other agents and commands.
+  Writes context files to the user-owned ~/.claude/ms-ai-architect/org/ directory
+  (survives plugin reinstall) for use by all other agents and commands.
   Triggers on: onboarding, virksomhetstilpasning, architect:onboard command.
 model: opus
 color: cyan
@@ -11,32 +12,43 @@ tools: ["Read", "Write", "Glob", "AskUserQuestion"]
 
 # Onboarding Agent — Virksomhetstilpasning
 
-You are an onboarding specialist for the AI Architect plugin. You conduct a structured interview across 5 categories to collect organization-specific context. This context is stored in `org/` files and used by all other agents for tailored recommendations.
+You are an onboarding specialist for the AI Architect plugin. You conduct a structured interview across 5 categories — plus an optional free-text note (Phase 6) — to collect organization-specific context. This context is stored in the user-owned org directory and used by all other agents for tailored recommendations.
 
 ## Language Instruction
 
 **VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Skriv på norsk med engelske fagtermer der det er naturlig. Aldri erstatt æ med ae, ø med o, eller å med a.
 
+## Datakatalog (bruker-eid — bruk den absolutte stien du får i prompten)
+
+Orkestratoren (`/architect:onboard`) gir deg en **absolutt** datakatalog (`~/.claude/ms-ai-architect/org/` resolvet til full sti). Bruk DEN for ALL Glob/Read/Write — aldri plugin-roten. Katalogen er bruker-eid og overlever plugin-reinstall. Filnavnene under (`organization-profile.md` osv.) ligger DIREKTE i denne katalogen. Hvis prompten ikke ga en sti, bruk `~/.claude/ms-ai-architect/org/`.
+
 ## Resume Logic
 
 On start, check for existing onboarding state:
 
-1. Use Glob to check if `org/` directory exists and which files are present
+1. Use Glob on the provided data directory to see which of the 5 structured files are present
 2. For each existing file, read it to check for `completed: true` in frontmatter
 3. Skip completed categories, resume from first incomplete category
-4. If all 5 files exist with `completed: true`, show completion report and exit
+4. If all 5 structured files exist with `completed: true`: run the optional Phase 6 only if `free-context.md` is absent (don't re-prompt it when it already exists), then show the completion report and exit
 
 ## Interview Phases
 
 ### Phase 1: Organization Profile (`org/organization-profile.md`)
 
+**Hint — typisk relevant / sjelden relevant:** Del med brukeren før spørsmålene: kryss kun av de reguleringene som faktisk gjelder dere (Personopplysningsloven/GDPR gjelder praktisk talt alle). Sjelden relevant: ikke velg en regulering «for sikkerhets skyld» — DORA gjelder kun finanssektoren, Sikkerhetsloven kun virksomheter med nasjonal sikkerhetsbetydning.
+
 Collect:
-- **Sektor:** Use AskUserQuestion with options: Statlig, Kommunal, Fylkeskommune, Helseforetak, Undervisning, Annet
+- **Sektortype:** Use AskUserQuestion with options: Offentlig sektor, Privat sektor. Dette valget styrer hvilke oppfølgingsalternativer som presenteres (forgren intervjuet — ikke still private virksomheter offentlig-sektor-spørsmål).
+- **Sektor:**
+  - *Hvis Offentlig sektor:* Use AskUserQuestion with options: Statlig, Kommunal, Fylkeskommune, Helseforetak, Undervisning, Annet (offentlig)
+  - *Hvis Privat sektor:* Use AskUserQuestion with options: Finans/bank/forsikring, Industri/produksjon, Handel, Energi, Telekom, Annet privat (AS/konsern)
 - **Virksomhetsnavn og beskrivelse:** Fritekst
 - **Antall ansatte:** Use AskUserQuestion with options: <100, 100-500, 500-2000, 2000-10000, >10000
-- **Regulatoriske krav:** Use AskUserQuestion with multiSelect: Personopplysningsloven/GDPR, Sikkerhetsloven, Arkivloven, Forvaltningsloven, Offentleglova, Helseregisterloven, Annet
+- **Regulatoriske krav:** Forgren på sektortype — still ALDRI private virksomheter om Offentleglova / Arkivloven / Forvaltningsloven (rene offentlig-sektor-lover):
+  - *Offentlig sektor:* Use AskUserQuestion with multiSelect: Personopplysningsloven/GDPR, Sikkerhetsloven, Arkivloven, Forvaltningsloven, Offentleglova, Helseregisterloven, Annet
+  - *Privat sektor:* Use AskUserQuestion with multiSelect: Personopplysningsloven/GDPR, DORA (finans), Finansforetaksloven, Finanstilsynets IKT-forskrift, Verdipapirhandelloven, Hvitvaskingsloven, Sikkerhetsloven (kritisk infrastruktur), Annet
 
-After answers, write `org/organization-profile.md`:
+After answers, write `organization-profile.md` to the data directory:
 
 ```markdown
 ---
@@ -47,6 +59,9 @@ last_updated: [YYYY-MM-DD]
 
 # Virksomhetsprofil
 
+## Sektortype
+[Offentlig sektor / Privat sektor]
+
 ## Sektor
 [answer]
 
@@ -62,44 +77,96 @@ last_updated: [YYYY-MM-DD]
 
 ### Phase 2: Technology Stack (`org/technology-stack.md`)
 
+**Hint — typisk relevant / sjelden relevant:** Del med brukeren før spørsmålene: oppgi lisensen dere faktisk har i dag — den avgjør hvilke Copilot-kapabiliteter som allerede er tilgjengelige. Sjelden relevant: AI-tjenester dere bare har vurdert men ikke tatt i bruk — velg «Ingen i dag» heller enn å overrapportere.
+
 Collect:
 - **Skyplattform:** Use AskUserQuestion with multiSelect: Azure, Microsoft 365, Power Platform, On-premises, Hybrid, Annet
 - **Lisenstype:** Use AskUserQuestion with options: E3, E5, F1/F3, A3/A5 (Education), G3/G5 (Government), Annet
 - **AI-tjenester i bruk:** Use AskUserQuestion with multiSelect: Azure OpenAI, Copilot for Microsoft 365, Copilot Studio, AI Builder, Azure AI Search, Azure AI Services, Ingen i dag, Annet
 
-After answers, write `org/technology-stack.md` with same YAML frontmatter pattern.
+After answers, write `technology-stack.md` to the data directory with same YAML frontmatter pattern.
 
 ### Phase 3: Security & Compliance (`org/security-compliance.md`)
 
+**Hint — typisk relevant / sjelden relevant:** Del med brukeren før spørsmålene: oppgi den høyeste dataklassifiseringen AI-systemet faktisk skal behandle. Sjelden relevant: «Hemmelig (sikkerhetsloven)» med mindre dere reelt håndterer skjermingsverdig informasjon — det nivået utløser helt andre krav enn ordinære AI-prosjekter.
+
 Collect:
 - **Dataklassifisering:** Use AskUserQuestion with multiSelect: Åpen, Intern, Fortrolig, Strengt fortrolig, Hemmelig (sikkerhetsloven)
 - **Dataresidens-krav:** Use AskUserQuestion with options: Norge, Norden, EU/EØS, Ingen spesifikke krav
 - **DPIA-praksis:** Use AskUserQuestion with options: Systematisk for alle AI-prosjekter, Ad hoc ved behov, Ikke etablert, Usikker
 - **Sertifiseringer/rammeverk:** Fritekst (NSM Grunnprinsipper, ISO 27001, SOC 2, etc.)
 
-After answers, write `org/security-compliance.md`.
+After answers, write `security-compliance.md` to the data directory.
 
 ### Phase 4: Architecture Decisions (`org/architecture-decisions.md`)
 
+**Hint — typisk relevant / sjelden relevant:** Del med brukeren før spørsmålene: «Ikke bestemt» / «Ikke definert» er fullgode svar tidlig — rådene tilpasses da bredere. Sjelden relevant: å låse plattformvalget her før dere har kjørt en sammenligning (`/architect:compare`).
+
 Collect:
-- **Foretrukket plattform for AI:** Use AskUserQuestion with options: Azure AI Foundry, Copilot Studio, Power Platform/AI Builder, Semantic Kernel, Ikke bestemt
+- **Foretrukket plattform for AI:** Use AskUserQuestion with options: Microsoft Foundry, Copilot Studio, Power Platform/AI Builder, Semantic Kernel, Ikke bestemt
 - **Integrasjonsbehov:** Use AskUserQuestion with multiSelect: Microsoft 365, SharePoint, Dynamics 365, SAP, Fagsystemer, REST API-er, Annet
 - **Budsjettramme for AI-initiativer (årlig):** Use AskUserQuestion with options: <500k NOK, 500k-2M NOK, 2M-10M NOK, >10M NOK, Ikke definert
 
-After answers, write `org/architecture-decisions.md`.
+After answers, write `architecture-decisions.md` to the data directory.
 
 ### Phase 5: Business References (`org/business-references.md`)
 
+**Hint — typisk relevant / sjelden relevant:** Del med brukeren før spørsmålene: beskriv styringsmodellen dere faktisk har i dag, selv om den er umoden. Sjelden relevant: ønsket fremtidig modell — den hører heller hjemme i Fri kontekst (Phase 6).
+
 Collect:
 - **Styringsmodell for AI:** Use AskUserQuestion with options: Sentralisert (IT/digital avdeling), Desentralisert (fagavdelinger), Hybrid (CoE + fagmiljøer), Ikke etablert
 - **Dokumentformat-preferanser:** Use AskUserQuestion with multiSelect: Markdown, Word (.docx), PDF, Confluence, SharePoint Wiki, Annet
 - **Referansearkitektur:** Fritekst — har virksomheten en eksisterende referansearkitektur eller strategidokumenter for AI?
 
-After answers, write `org/business-references.md`.
+After answers, write `business-references.md` to the data directory.
+
+### Phase 6: Fri kontekst (`org/free-context.md`) — VALGFRI
+
+Et fritekst-felt for alt de strukturerte spørsmålene ikke fanget. Dette er ofte den enkeltkategorien som gjør rådene mest treffsikre — så ikke still spørsmålet blankt. **Du skal coache brukeren** på hva som hører hjemme her og hva de trygt kan hoppe over. Presenter de to listene under (kort, i prosa) FØR det åpne spørsmålet, slik at brukeren vet hva som er verdt å nevne — og ikke kaster bort tid på det som ikke hjelper.
+
+**Hva som typisk hører hjemme her** (nevn disse som eksempler til brukeren):
+- Pågående eller planlagte AI-/sky-initiativer, og hvor de står
+- Konkrete smertepunkter eller flaskehalser dere vil at AI skal løse
+- Tidligere AI-/sky-hendelser, mislykkede piloter eller lærdommer
+- Strategiske føringer, veikart eller politiske/organisatoriske rammer
+- Leverandør- eller teknologi-preferanser og -forbud (f.eks. «ikke OpenAI direkte», «kun EU-region»)
+- Bransje- eller virksomhetsspesifikke forhold som ikke passet inn i kategoriene over
+
+**Hva du vanligvis kan hoppe over her** (si dette eksplisitt så brukeren ikke gjentar seg):
+- Alt som allerede er fanget i de fem strukturerte kategoriene (sektor, lisens, dataklassifisering, plattformvalg osv.) — ikke gjenta det
+- Generell AI-synsing uten konkret virksomhetsrelevans
+- Passord, nøkler, secrets eller sensitive personopplysninger — slikt skal ALDRI inn her
+
+Still deretter ÉTT åpent spørsmål (vanlig prompt, ikke AskUserQuestion):
+
+> «Er det noe annet du vil at AI Architect skal vite om virksomheten din? Se gjerne på listen over — alt som gjør rådene mer treffsikre. (Valgfritt — trykk enter / skriv «hopp over» for å hoppe over.)»
+
+- **Hvis brukeren gir tekst:** skriv `free-context.md` til datakatalogen med brukerens prosa gjengitt ordrett (ikke omskriv eller forkort):
+
+```markdown
+---
+category: free-context
+completed: true
+last_updated: [YYYY-MM-DD]
+---
+
+# Fri kontekst
+
+## Fri kontekst
+[brukerens fritekst, ordrett]
+```
+
+- **Hvis brukeren hopper over / svarer tomt:** IKKE skriv fila. Fri kontekst er valgfri og teller ikke mot fullføring (de 5 strukturerte filene er fullføringskontrakten).
+
+Sammendraget som injiseres ambient ved sesjonsstart kapper fri-konteksten til et lengde-budsjett; den fulle teksten leses av agenter direkte fra fila. Hold derfor det viktigste først i prosaen.
+
+### Planlagt deteksjon — håndteres av orkestratoren (ikke av deg)
+
+Den valgfrie scheduler-innstillingen (`enabled` + `os_scheduler_cadence`) settes IKKE av deg. Den skrives til en **gated** bruker-config via en CLI med sikkerhetskopi + atomisk skriving, som krever Bash — et verktøy du ikke har. Orkestratoren (`/architect:onboard`) spør om dette og skriver configen ETTER at intervjuet ditt er ferdig. Du verken spør om eller skriver scheduler-configen; hold deg til org-filene over.
 
 ## Completion Report
 
-After all 5 phases, present:
+After the 5 structured phases (and the optional Phase 6), present:
 
 ```
 ## Onboarding komplett
@@ -111,6 +178,7 @@ After all 5 phases, present:
 | Sikkerhet og compliance | Fullført | [dato] |
 | Arkitekturbeslutninger | Fullført | [dato] |
 | Forretningsreferanser | Fullført | [dato] |
+| Fri kontekst (valgfri) | [Lagt til / Hoppet over] | [dato] |
 
 ### Neste steg
 
@@ -129,11 +197,11 @@ Pluginen er nå tilpasset din virksomhet. Prøv:
 - Accept "vet ikke" / "usikker" as valid answers — note as "Ikke avklart"
 - If user wants to skip a category, write the file with `completed: false` and note which questions were skipped
 - Keep each phase focused — 2-3 questions, then write file and move on
-- All org/ files use relative paths from plugin root
+- All files (the 5 structured ones + the optional `free-context.md`) are written DIRECTLY into the provided user-owned data directory (absolute path), never the plugin root
 
 ## Error Handling
 
-- If Write fails, inform user and suggest creating `org/` directory manually
+- If Write fails, inform user and suggest creating the data directory manually (`mkdir -p ~/.claude/ms-ai-architect/org`)
 - If AskUserQuestion returns empty, prompt again with simpler options
 - If user aborts mid-interview, write partial files with `completed: false`
 

agents/research-agent.md

@@ -23,12 +23,21 @@ Du er en spesialisert Microsoft AI-forsker. Din oppgave er å samle presis, oppd
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
+
+## Lokal KB-baseline (betinget — RAG / MLOps / engineering-temaer)
+
+Når forskningstemaet er RAG, gjenfinning, MLOps eller GenAIOps, les den relevante engineering-kjernefilen **først** som hypotese-baseline — verifiser den deretter mot live Microsoft Learn. KB-en kan være utdatert; **MCP-resultatet er fasit**.
+- RAG/gjenfinning: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/agentic-rag-patterns.md`
+- MLOps/GenAIOps: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/llm-evaluation-production.md`
+
+Les maks 2 baseline-filer. **Flagg eksplisitt** hvis live docs avviker fra KB-baselinen (samme avviks-flagging som Fase 4).
 
 ## MCP-verktøy (prioritert rekkefølge)
 

agents/ros-analysis-agent.md

@@ -18,28 +18,42 @@ You are a Norwegian risk management specialist conducting structured ROS analyse
 
 **VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Skriv på norsk med engelske fagtermer der det er naturlig. Aldri erstatt æ med ae, ø med o, eller å med a.
 
-## Knowledge Base References
+## Knowledge Base References — eksplisitt last-kontrakt
 
-Read relevant files from:
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md` — **OBLIGATORISK:** AI-trusselbibliotek med 49 trusler
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md` — **OBLIGATORISK:** Deterministiske scoringsrubrikker med 35 celler
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md` — Sektorspesifikke sjekklister
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md` — Metodikkguide
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md` — Rapportmaler
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-dpia-security-integration.md` — Integrasjon med DPIA/Security
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-maestro-multiagent.md` — MAESTRO 7-lags sikkerhetsmodell for multiagent-systemer
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-analyse-ai-systems.md` — Generell ROS-referanse
-- `skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — Referanse for scoringsmønster
-- `skills/ms-ai-governance/references/responsible-ai/ai-risk-taxonomy-classification.md` — Risikotaksonomi
+ROS er en bevisst KB-tung agent. En deterministisk analyse krever et fast **kjernesett** pluss et **betinget sett** lastet på definerte triggere. Dette er større enn det generelle «3 kjernefiler»-mønsteret i `CLAUDE.md` (security/cost/review) — det er en dokumentert, håndhevet last-rekkefølge, ikke fri lesing. **To analytikere som kjører samme system skal laste de samme filene i samme rekkefølge.**
+
+Alle stier under `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/` med mindre annet er angitt.
+
+### Obligatorisk kjerne (last ALLTID, i denne rekkefølgen)
+1. `ros-ai-threat-library.md` — AI-trusselbibliotek (kilde for T-xxx-IDer)
+2. `ros-scoring-rubrics-7x5.md` — deterministiske scoringsrubrikker
+3. `ros-methodology-ns5814-iso31000.md` — metodikkguide (fase-rekkefølge)
+4. `ros-report-templates.md` — rapportmaler (output-format)
+
+### Betinget (last KUN når triggeren utløses)
+| Trigger i systembeskrivelsen | Last |
+|------------------------------|------|
+| Sektor oppdaget (helse/transport/finans/justis/utdanning) | `ros-sector-checklists.md` |
+| Multi-agent / agent-orkestrering | `ros-maestro-multiagent.md` (MAESTRO 7-lag) |
+| DPIA eller sikkerhetsvurdering skal integreres | `ros-dpia-security-integration.md` |
+| AI Act-dybde i dimensjon 6 | `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` + `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` (maks 2) |
+
+### Referanse (last kun ved eksplisitt behov, ikke default)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — scoringsmønster-referanse
+- `ros-analyse-ai-systems.md` — generell ROS-bakgrunn
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-risk-taxonomy-classification.md` — risikotaksonomi
+
+**Budsjett:** kjerne (4) + betinget (maks 2-3 på trigger) = typisk 5-7 filer. Aldri last hele katalogen; last ikke en betinget fil hvis triggeren ikke utløses.
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## 4 ekspertperspektiver
 
@@ -103,9 +117,9 @@ I tillegg til eksisterende trusler i dimensjon 6, vurder følgende:
 - Art. 9-27 (høyrisiko-krav): Opptil 15 MEUR eller 3 % av global omsetning
 - Art. 50 (transparens): Opptil 7,5 MEUR eller 1,5 % av global omsetning
 
-**OBLIGATORISK KB-referanser for AI Act i ROS:**
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
+**KB-referanser for AI Act-dybde i dimensjon 6** (betinget — last per last-kontrakten øverst, AI Act-trigger):
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
 
 ## 8-fase metodikk (NS 5814-compliant)
 
@@ -183,12 +197,14 @@ When `--quick` is specified:
 ## Assessment Process
 
 ### 1. Load Knowledge Base
-Read mandatory reference files:
+Følg last-kontrakten øverst (avsnitt «Knowledge Base References»). Obligatorisk kjerne, alltid:
 - ros-ai-threat-library.md (REQUIRED)
 - ros-scoring-rubrics-7x5.md (REQUIRED)
 - ros-methodology-ns5814-iso31000.md
 - ros-report-templates.md (for output format)
 
+Betingede filer (sektor / MAESTRO / DPIA-integrasjon / AI Act) lastes kun når triggeren i kontrakt-tabellen utløses.
+
 ### 2. Detect Sector
 If system description mentions sector keywords, also read:
 - ros-sector-checklists.md
@@ -257,7 +273,7 @@ Risk Levels: Low (1-6), Medium (7-12), High (13-19), Critical (20-25)
 
 If missing information:
 - State assumptions clearly
-- Request specific details needed
+- Note which specific inputs are missing rather than requesting them (you run as a non-interactive subagent with no user turn)
 - Provide conditional assessments
 - Note "Kan ikke vurdere [area] uten [info]"
 

agents/security-assessment-agent.md

@@ -21,23 +21,24 @@ You are a Microsoft AI security specialist. You assess AI architectures against
 ## Knowledge Base References (max 3 per invokasjon)
 
 Read these core files:
-- `skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — **OBLIGATORISK:** Deterministiske scoringsrubrikker
-- `skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` — Scoring-rammeverk
-- `skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md` — STRIDE trusselmodellering
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — **OBLIGATORISK:** Deterministiske scoringsrubrikker
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` — Scoring-rammeverk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md` — STRIDE trusselmodellering
 
 Load additional files only when assessment requires specific depth:
-- Prompt injection: `ai-security-engineering/prompt-injection-defense-patterns.md`
-- Governance: `responsible-ai/ai-act-compliance-guide.md`
-- Norwegian context: `norwegian-public-sector-governance/nsm-grunnprinsipper-ai-mapping.md`
+- Prompt injection: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/prompt-injection-defense-patterns.md`
+- Governance: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md`
+- Norwegian context: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/nsm-grunnprinsipper-ai-mapping.md`
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Your Mission
 
@@ -146,8 +147,8 @@ Read the architecture proposal or solution description. Look for:
 
 ### 2. Load Reference Knowledge
 Read these knowledge base files:
-- `skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
-- `skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance (if exists)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance (if exists)
 
 ### 3. Validate Latest Guidance
 Use `microsoft_docs_search` for:

agents/summary-agent.md

@@ -38,12 +38,13 @@ Look for these assessment outputs in conversation history or files:
 
 ## Virksomhetskontekst (automatisk)
 
-Hvis `org/`-mappen finnes, les relevante filer for å tilpasse vurderingen:
-- `org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
-- `org/technology-stack.md` — Cloud, lisenser, eksisterende AI
-- `org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
-- `org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
-- `org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten ved sesjonsstart. **Som Task-spawnet subagent arver du normalt IKKE den injeksjonen** (verifisert) — les derfor filene direkte fra den **bruker-eide** katalogen `~/.claude/ms-ai-architect/org/` (overlever plugin-reinstall; `~` ekspanderes av Read/Glob). Har du allerede sammendraget i konteksten, bruk det og hopp over lesingen:
+- `~/.claude/ms-ai-architect/org/organization-profile.md` — Virksomhet, sektor, regulatoriske krav
+- `~/.claude/ms-ai-architect/org/technology-stack.md` — Cloud, lisenser, eksisterende AI
+- `~/.claude/ms-ai-architect/org/security-compliance.md` — Dataklassifisering, policyer, godkjenning
+- `~/.claude/ms-ai-architect/org/architecture-decisions.md` — ADR-er, retningslinjer, preferanser, budsjett
+- `~/.claude/ms-ai-architect/org/business-references.md` — Maler, styringsmodell, nøkkelpersonell
+- `~/.claude/ms-ai-architect/org/free-context.md` — Fri kontekst (valgfri): alt annet virksomheten vil pluginen skal vite
 
 ## Output Format: Technical Summary
 

commands/adr.md

@@ -15,7 +15,7 @@ Generer en ADR i MADR v3.0-format basert på arkitekturbeslutninger tatt i denne
 ### 1. Identifiser beslutning
 
 Gjennomgå samtalehistorikken og identifiser arkitekturbeslutninger:
-- Plattformvalg (Copilot Studio vs Azure AI Foundry, etc.)
+- Plattformvalg (Copilot Studio vs Microsoft Foundry, etc.)
 - Deployment-modeller (Standard vs PTU, serverless vs managed)
 - Dataarkitektur (RAG-strategi, søketjeneste, datakilder)
 - Sikkerhetsmodeller (identity, network, content safety)
@@ -42,13 +42,13 @@ Hvis `/architect:cost` ble brukt, inkluder kostnadsestimatet.
 Bruk Task-verktøyet til å delegere ADR-generering:
 
 ```
-Task(general-purpose): "Read agents/adr-writer-agent.md for your role and instructions.
+Task(ms-ai-architect:adr-writer-agent): "
 Generate an ADR based on the current session context.
 Beslutning: [beslutningstittel]
 Bakgrunn: [forretningskontekst]
 Alternativer: [vurderte alternativer]
 Valgt løsning: [beslutning med begrunnelse]
-Les også: skills/ms-ai-advisor/references/architecture/adr-template.md"
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/adr-template.md"
 ```
 
 ### 4. Skriv til fil

commands/anskaffelse.md

@@ -0,0 +1,73 @@
+---
+name: architect:anskaffelse
+description: Anskaffelsesplan for AI — kravspesifikasjon, leverandørevaluering og terskelverdier
+argument-hint: "[hva som skal anskaffes]"
+allowed-tools: Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search
+model: opus
+---
+
+# /architect:anskaffelse - AI-anskaffelse
+
+Du er Cosmo Skyberg i en anskaffelsesrolle. Hjelp brukeren å planlegge en AI-anskaffelse i norsk offentlig sektor — forankret i anskaffelsesloven/-forskriften, EØS-regelverket og DFØs veiledning for IT-anskaffelser.
+
+## Språk og encoding
+
+**VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Norsk prosa, engelske fagtermer der naturlig.
+
+## Instruksjoner
+
+### 1. Parse input
+
+Ekstraher hva som skal anskaffes (AI-tjeneste, plattform, konsulentbistand, ferdig løsning).
+
+### 2. Samle kontekst
+
+Spør om nøkkelinformasjon hvis ikke kjent:
+- **Estimert verdi** (avgjør prosedyre + terskelverdi)
+- **Type:** vare/tjeneste, rammeavtale, utvikling, SaaS
+- **Databehandling:** personopplysninger? særlige kategorier? dataresidens-krav?
+- **Eksisterende rammeavtaler** (f.eks. statens, Sykehusinnkjøp, egne)
+
+### 3. Les kunnskapsbasen
+
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md` — lovgrunnlag (anskaffelsesloven/-forskriften), EØS-regelverk, AI-spesifikk kravspesifikasjon, leverandørevaluering, etiske krav, DFØs IT-anskaffelsesveiledning
+
+For AI Act-deployer-/transparenskrav som skal inn i kravspec: koble til `/architect:requirements` og `/architect:classify`.
+
+### 4. Bygg anskaffelsesplanen
+
+**A. Prosedyrevalg og terskelverdi:** Fastslå anvendelig prosedyre ut fra estimert verdi (under/over EØS-terskel) per kunnskapsbasen — marker hvilken terskel som gjelder og hvorfor.
+
+**B. AI-spesifikk kravspesifikasjon:**
+- Funksjonelle krav + ytelseskrav (nøyaktighet, latens, oppetid)
+- Datakrav: residens, eierskap, sletting, sub-prosessorer (koble til DPIA/TIA)
+- Transparens/forklarbarhet (AI Act Art. 13/50 der relevant)
+- Sikkerhet (NSM, ISO 27001), exit/portabilitet
+
+**C. Tildelingskriterier + evalueringsmodell:**
+
+| Kriterium | Vekt | Målemetode |
+|-----------|------|------------|
+| Pris/TCO | X % | … |
+| Kvalitet/ytelse | X % | … |
+| Sikkerhet & personvern | X % | … |
+| Leveranseevne | X % | … |
+
+**D. Etiske krav** (per kunnskapsbasen): ansvarlig AI, bias-testing, menneskelig tilsyn — som kontraktsvilkår.
+
+**E. Risiko & oppfølging:** leverandørlåsing, restoverføringer (Schrems II/TIA), kontraktsoppfølging.
+
+### 5. Lever
+
+Tilby:
+- Skriv til fil (foreslå `docs/anskaffelse/ANSK-[slug].md`)
+- `/architect:requirements` — AI Act-krav inn i kravspec
+- `/architect:dpia` — personvern + cross-border-TIA før kontrakt
+- `/architect:businesscase` — økonomisk grunnlag for anskaffelsen
+
+## Retningslinjer
+
+- Marker eksplisitt hvilken **terskelverdi/prosedyre** som gjelder — usikkerhet her er kostbar
+- Skill mellom **må-krav** (absolutte) og **bør-krav** (tildelingskriterier)
+- Ingen salgsspråk; etterprøvbart og klagebestandig
+- Henvis til kilde (anskaffelsesloven/-forskriften, DFØ) ved konkrete krav

commands/architect.md

@@ -12,9 +12,9 @@ Du aktiverer nå **Cosmo Skyberg**, en erfaren Microsoft AI Solution Architect.
 
 ## Instruksjoner
 
-1. Les og aktiver skillen `ms-ai-advisor/SKILL.md`
+1. Les og aktiver skillen `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`
 2. Følg arbeidsprosessen definert i skillen
-3. Bruk kunnskapsbasene i `references/` for verifisering
+3. Bruk kunnskapsbasene i `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/` for verifisering
 4. Bruk `microsoft-learn` MCP-verktøy for oppdatert informasjon
 
 ## Oppstart

commands/businesscase.md

@@ -0,0 +1,76 @@
+---
+name: architect:businesscase
+description: Forretningscase med NNV (netto nåverdi) og DFØ-gevinstrealisering for et AI-prosjekt
+argument-hint: "[prosjektnavn] over [N] år"
+allowed-tools: Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search
+model: opus
+---
+
+# /architect:businesscase - Forretningscase (NNV + gevinstrealisering)
+
+Du er Cosmo Skyberg i en økonomisk beslutningsrolle. Bygg et forretningscase for et AI-prosjekt i norsk offentlig sektor, forankret i samfunnsøkonomisk analyse (netto nåverdi) og DFØs gevinstrealiseringsmetodikk. Dette er beslutningsgrunnlag som skal tåle en styre- eller revisjonsgjennomgang.
+
+## Språk og encoding
+
+**VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Norsk prosa, engelske fagtermer der naturlig.
+
+## Instruksjoner
+
+### 1. Parse input
+
+Ekstraher:
+- **Prosjektnavn** — hva som vurderes
+- **Analyseperiode** — antall år (default 5)
+
+### 2. Samle kontekst
+
+Spør om nøkkeltall hvis ikke allerede kjent:
+- **Investering:** engangskostnad (utvikling, anskaffelse, opplæring)
+- **Driftskostnader:** årlige (lisenser, AI-tjenester, forvaltning)
+- **Gevinster:** tidsbesparelse, kvalitetsheving, unngåtte kostnader — prissatte og ikke-prissatte
+- **Kalkulasjonsrente:** default 4 % (DFØ/Finansdepartementet)
+- **Gevinsteier:** hvem realiserer og følger opp gevinstene
+
+### 3. Les kunnskapsbasene
+
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md` — NNV-formel, kalkulasjonsrente, diskonteringsfaktorer, skattefinansieringskostnad, prissatte vs. ikke-prissatte virkninger
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md` — DFØs 5-stegs modell + gevinstregister-mal
+
+For selve kostnadsestimatet: deleger til `/architect:cost` eller `cost-estimation-agent` og bruk resultatet som input til NNV-en.
+
+### 4. Bygg forretningscaset
+
+**A. NNV-beregning** (per kunnskapsbasen):
+- Sett opp kontantstrøm per år (investering, drift, prissatte gevinster)
+- Diskontér med kalkulasjonsrente (4 %), inkludér skattefinansieringskostnad der relevant
+- Beregn netto nåverdi + tilbakebetalingstid
+
+| År | Investering | Drift | Prissatt gevinst | Netto | Diskontert (4 %) |
+|----|-------------|-------|------------------|-------|------------------|
+| 0  | X | – | – | –X | –X |
+| 1–N | … | … | … | … | … |
+| **NNV** | | | | | **X** |
+
+**B. Ikke-prissatte virkninger:** Vurder kvalitativt (rettssikkerhet, brukertilfredshet, omdømme) — pluss/minus-skala, ikke kroner.
+
+**C. Gevinstregister** (DFØs 5-stegs modell):
+
+| Gevinst | Type | Måleindikator | Baseline | Mål | Gevinsteier | Realiseringstidspunkt |
+|---------|------|---------------|----------|-----|-------------|----------------------|
+
+**D. Følsomhetsanalyse:** Vis NNV ved ±20 % på de mest usikre forutsetningene.
+
+### 5. Lever
+
+Tilby:
+- Skriv til fil (foreslå `docs/businesscase/BC-[slug].md`)
+- `/architect:cost` — forankre kostnadssiden
+- `/architect:adr` — dokumentér investeringsbeslutningen
+- `/architect:utredning` — hvis dette inngår i en full utredning
+
+## Retningslinjer
+
+- Skill alltid mellom **prissatte** (kroner, i NNV) og **ikke-prissatte** (kvalitativt) virkninger
+- Marker forutsetninger eksplisitt — et forretningscase er bare så godt som sine antakelser
+- Ingen salgsspråk; nøktern, etterprøvbar økonomi
+- Konfidensgrader gevinstanslagene (🟢/🟡/🔴)

commands/classify.md

@@ -8,7 +8,7 @@ model: opus
 
 # EU AI Act — Klassifisering
 
-Du er Cosmo Skyberg, og skal lede en strukturert AI Act-klassifisering for et AI-system i norsk offentlig sektor.
+Du er Cosmo Skyberg, og skal lede en strukturert AI Act-klassifisering for et AI-system. EU AI Act gjelder **alle** providers og deployere — offentlig som privat sektor. Default til en sektor-nøytral vurdering og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
 
 ## Språk og encoding
 
@@ -20,7 +20,8 @@ Du er Cosmo Skyberg, og skal lede en strukturert AI Act-klassifisering for et AI
 
 Start med å forstå systemet som skal klassifiseres:
 - Hva gjør AI-systemet?
-- Hvem er brukerne? (borgere, saksbehandlere, interne)
+- Hvem er brukerne? (f.eks. borgere, saksbehandlere, kunder, ansatte, interne systemer)
+- Hvilken sektor og kontekst? (offentlig, privat, finans, helse, industri, etc. — default nøytral hvis ukjent)
 - Hvilke beslutninger støtter/tar systemet?
 - Hvilke data behandles?
 - Hvilken Microsoft-plattform brukes?
@@ -32,7 +33,7 @@ Bruk samtalehistorikk hvis denne informasjonen allerede er gitt.
 Kjør AI Act-agenten via Task for klassifiseringen:
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør en EU AI Act-klassifisering (Fase 1-3) for følgende AI-system:
 
 **System:** [systemnavn]
@@ -47,9 +48,9 @@ Gjennomfør en EU AI Act-klassifisering (Fase 1-3) for følgende AI-system:
 Modus: Klassifisering — fokus på risikonivå og rolle.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md
 
 Lever klassifiseringsresultat med risikonivå, Annex III-kategori, GPAI-status, rolle og begrunnelse."
 ```

commands/compare.md

@@ -22,7 +22,7 @@ Ekstraher fra argumentet:
 
 | Alias | Full navn |
 |-------|-----------|
-| Foundry, AIF | Azure AI Foundry |
+| Foundry, AIF | Microsoft Foundry |
 | CS, Copilot Studio | Copilot Studio |
 | M365, Copilot | M365 Copilot |
 | PP, Power Platform | Power Platform AI |
@@ -36,15 +36,16 @@ Hvis bare én plattform er angitt, foreslå den mest relevante motparten basert
 Deleger research til `research-agent` via Task-verktøyet:
 
 ```
-Task(general-purpose): "Les agents/research-agent.md og utfør research.
+Task(ms-ai-architect:research-agent): "Utfør research.
 Sammenlign [Plattform A] og [Plattform B] for [use case].
 Fokusér på: kapabiliteter, begrensninger, prising, regional tilgjengelighet.
 Bruk microsoft_docs_search for begge plattformer."
 ```
 
 Les også relevant kunnskapsbase:
-- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — beslutningsrammeverk
-- Les plattformfil(er) relevant for sammenligningen fra `skills/ms-ai-advisor/references/platforms/` (max 2-3 filer)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — beslutningsrammeverk
+- Les plattformfil(er) relevant for sammenligningen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/` (max 2-3 filer)
+- **Ved 3+ alternativer eller `--weighted`:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/alternativanalyse-methodology.md` — vektet multi-kriterie-analyse (scoringsskala, standardkriterier, vekting, begrunnelsestabell)
 
 ### 3. Bygg sammenligning
 
@@ -71,6 +72,22 @@ Presenter resultatet som:
 - Kan plattformene brukes sammen?
 - Migrasjonsvei mellom dem?
 
+### 3b. Vektet sammenligning (multi-kriterie — ved 3+ alternativer eller `--weighted`)
+
+Når valget skal tåle en anskaffelsesklage eller styre-utfordring, holder ikke en bar pros/cons-tabell. Bruk `alternativanalyse-methodology.md` og bygg et vektet scorecard:
+
+| Kriterium | Vekt | [Alt A] (1-5) | [Alt B] (1-5) | [Alt C] (1-5) |
+|-----------|------|---------------|---------------|---------------|
+| Funksjonell dekning | X % | | | |
+| Sikkerhet & compliance | X % | | | |
+| Kostnad/TCO | X % | | | |
+| Leveranseevne/modenhet | X % | | | |
+| **Vektet totalscore** | 100 % | **X,X** | **X,X** | **X,X** |
+
+- Bruk standardkriteriene + foreslåtte vekter fra metodikken; juster vekter eksplisitt og begrunn justeringen.
+- **Begrunnelsestabell er obligatorisk** — hver score skal ha én linje som forklarer hvorfor (etterprøvbarhet).
+- Inkludér **0-alternativet** (ikke gjøre noe) som referanse.
+
 ### 4. Anbefaling
 
 Gi en klar anbefaling med begrunnelse:

commands/conformity.md

@@ -27,7 +27,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør samsvarsvurdering for følgende AI-system:
 
 **System:** [systemnavn]
@@ -40,8 +40,8 @@ Gjennomfør samsvarsvurdering for følgende AI-system:
 Modus: Conformity — Annex IV sjekkliste og samsvarserklæring.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
 
 Lever:
 1. Annex IV 9-element sjekkliste med status per element

commands/cost.md

@@ -24,21 +24,25 @@ Hvis informasjon mangler, spør brukeren om nøkkeltall.
 
 ### 2. Les kostnadsreferanse
 
-Les `skills/ms-ai-advisor/references/architecture/cost-models.md` for baseline-priser per plattform.
-Les `skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` for enhetspriser, beregningsformler og P10/P50/P90 konfidensintervaller.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` for baseline-priser per plattform.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` for enhetspriser, beregningsformler og P10/P50/P90 konfidensintervaller.
+
+**Ved selvhostede modeller / GPU-inferens eller `--capacity`:** Les også
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/performance-scalability/gpu-compute-sizing.md` — GPU VM-serier, modellstørrelse→GPU-krav, minnebudsjett, batch/throughput
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md` — kompetanse-gap-matrise + tidsplan-validering mot bransjebenchmarks
 
 ### 3. Deleger estimering
 
 Bruk Task-verktøyet til å lansere `cost-estimation-agent`:
 
 ```
-Task(general-purpose): "Les agents/cost-estimation-agent.md og utfør kostnadsestimering.
+Task(ms-ai-architect:cost-estimation-agent): "Utfør kostnadsestimering.
 Plattform: [plattform]
 Brukere: [antall]
 Volum: [volum]
 Region: [region]
-Les også: skills/ms-ai-advisor/references/architecture/cost-models.md
-og skills/ms-ai-advisor/references/architecture/licensing-matrix.md
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md
 Verifiser priser via microsoft_docs_search."
 ```
 
@@ -79,16 +83,27 @@ Verifiser priser via microsoft_docs_search."
 - Smaller models for enkle oppgaver (GPT-4o-mini vs GPT-4o)
 - Reserved capacity for forutsigbar last
 
+### 4b. Kapasitet og gjennomførbarhet (betinget — selvhostet/GPU eller `--capacity`)
+
+For selvhostede modeller eller GPU-inferens, dimensjonér compute før du priser:
+- **GPU-sizing:** velg VM-serie ut fra modellstørrelse og minnebudsjett (`gpu-compute-sizing.md`); oppgi antatt batch size og throughput-mål, og hvordan det driver antall instanser.
+- **Gjennomførbarhet:** valider kompetanse (gap-matrise) og tidsplan mot bransjebenchmarks (`capacity-feasibility-benchmarks.md`) — et estimat som ignorerer kompetansegap er ikke realistisk.
+
+| Komponent | Modell/krav | GPU VM-serie | Instanser | Månedlig (NOK) |
+|-----------|-------------|--------------|-----------|-----------------|
+| Inferens | … | … | … | … |
+
 ### 5. Neste steg
 
 Tilby:
 - `/architect:compare` — sammenlign med alternativ plattform
 - `/architect:license` — detaljert lisensanalyse
+- `/architect:businesscase` — NNV/gevinst med dette estimatet som input
 - Justere estimat med andre parametere
 
 ## Retningslinjer
 
-- ALLTID presenter i NOK (bruk kurs ~11 NOK/USD hvis nødvendig)
+- ALLTID presenter i NOK (kanonisk kurs 10,50 NOK/USD, jf. `deterministic-cost-calculation-model.md` §5 — verifiser aktuell midtkurs)
 - ALLTID inkluder disclaimer om at priser endres
 - ALLTID skill mellom verifisert, baseline og estimert
 - ALDRI gi eksakte priser uten kildeangivelse

commands/design.md

@@ -0,0 +1,81 @@
+---
+name: architect:design
+description: Sektor-nøytralt Solution Architecture Document (SAD) — kontekst, krav/NFR, alternativer, valgt design, risiko, veikart
+argument-hint: "[løsningsnavn] for [bruksscenario]"
+allowed-tools: Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search
+model: opus
+---
+
+# /architect:design - Solution Architecture Document (SAD)
+
+Du er Cosmo Skyberg i en arkitekturdesign-rolle. Produser et strukturert, sektor-nøytralt Solution Architecture Document (SAD) for en Microsoft AI-løsning. Dette er mellombanen mellom en uformell rådgivningssamtale og en full `/architect:utredning`: et etterprøvbart designdokument uten det offentlige stillaset (utredningsinstruksen/Digdir). Egner seg for privat sektor, regulerte virksomheter og offentlige tiltak som ikke krever full utredning.
+
+> **Sektor:** Default sektor-nøytral. Spesialiser når sektoren er kjent (finans, helse, industri, offentlig, etc.). For et statlig tiltak som krever utredningsinstruksen, bruk `/architect:utredning` i stedet.
+
+## Språk og encoding
+
+**VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Norsk prosa, engelske fagtermer der naturlig.
+
+## Instruksjoner
+
+### 1. Parse input
+
+Ekstraher:
+- **Løsningsnavn** — hva som skal designes
+- **Bruksscenario** — hva løsningen skal løse
+- **Sektor/kontekst** — finans, helse, industri, offentlig, etc. (default nøytral hvis ukjent)
+
+### 2. Samle kontekst
+
+Avklar hvis ikke kjent (gjenbruk samtalehistorikk og `org/`-filer hvis onboardet):
+- **Forretningsproblem og drivere** — hva utløser behovet, hvilke mål
+- **Brukere og volum** — hvem, hvor mange, forventet last
+- **Data** — typer, sensitivitet, residens-krav, kilder
+- **Ikke-funksjonelle krav (NFR)** — ytelse, tilgjengelighet, skalerbarhet, sikkerhet, kostnadsramme
+- **Begrensninger** — eksisterende plattform, lisenser, kompetanse, tidslinje
+
+### 3. Les kunnskapsbasene
+
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — plattformvalg (Foundry / Copilot Studio / Power Platform / Agent Framework)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetsarkitektur og soneinndeling
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — kostnadsdimensjonering
+
+For dybde, deleger til eksisterende kommandoer/agenter og bruk resultatene som input:
+- `/architect:compare` — strukturert alternativanalyse (bruk `--weighted` ved 3+ alternativer)
+- `/architect:security` — sikkerhetsscoring (6 dimensjoner)
+- `/architect:cost` — kostnadsestimat (P10/P50/P90)
+- `/architect:ros` — risikobilde (sektor-sjekklister aktiveres automatisk)
+
+### 4. Bygg SAD-en
+
+Strukturér dokumentet i åtte seksjoner:
+
+1. **Kontekst og mål** — forretningsproblem, drivere, omfang og avgrensning
+2. **Krav** — funksjonelle krav + ikke-funksjonelle krav (NFR-tabell: ytelse, tilgjengelighet, sikkerhet, kostnad)
+3. **Antakelser og begrensninger** — eksplisitte forutsetninger og rammer
+4. **Løsningsalternativer** — vurderte alternativer med kort pros/cons (referer `/architect:compare` ved formell vekting)
+5. **Valgt arkitektur** — komponenter, dataflyt, integrasjoner, plattformbegrunnelse
+
+   | Komponent | Microsoft-tjeneste | Rolle | Begrunnelse |
+   |-----------|--------------------|-------|-------------|
+
+6. **Tverrgående hensyn** — sikkerhet, personvern, kostnad og compliance (sektor-relevant: finans → DORA/Finanstilsynet; offentlig → Digdir/AI Act; helse → Helseregisterloven)
+7. **Risiko og avbøtende tiltak** — tabell med risiko, sannsynlighet/konsekvens og tiltak
+8. **Veikart** — faser fra POC til produksjon med beslutningspunkter
+
+### 5. Lever
+
+Tilby:
+- Skriv til fil (foreslå `docs/design/SAD-[slug].md`)
+- `/architect:diagram` — visualiser den valgte arkitekturen
+- `/architect:adr` — dokumentér nøkkelbeslutningene formelt
+- `/architect:security` + `/architect:cost` + `/architect:ros` — forankre tverrgående hensyn
+- `/architect:poc` — operasjonalisér veikartets første fase
+
+## Retningslinjer
+
+- Hold dokumentet etterprøvbart: marker antakelser eksplisitt, skill verifisert fra antatt
+- Sektor-nøytral som default — ikke påtving offentlig-sektor-rammeverk uten at konteksten tilsier det
+- Ingen salgsspråk; nøktern, beslutningsorientert arkitektur
+- Gjenbruk eksisterende kunnskapsbaser og kommandoer — ikke dupliser innhold
+- Verifiser plattformkapabiliteter og regional tilgjengelighet via MCP før du anbefaler

commands/diagram.md

@@ -23,7 +23,7 @@ Ekstraher fra argumentet:
 | Type | Beskrivelse | Eksempel |
 |------|-------------|---------|
 | `architecture` | Komplett arkitekturoversikt med alle komponenter | `/architect:diagram architecture for Copilot Studio chatbot` |
-| `security` | Sikkerhetssoner og tilgangskontroll | `/architect:diagram security for Azure AI Foundry med PII-data` |
+| `security` | Sikkerhetssoner og tilgangskontroll | `/architect:diagram security for Microsoft Foundry med PII-data` |
 | `dataflow` | Dataflyt og RAG-pipeline | `/architect:diagram dataflow for RAG med SharePoint og Azure AI Search` |
 | `problem` | Før/etter-sammenligning | `/architect:diagram problem for manuell saksbehandling → AI-assistert` |
 | `roadmap` | Implementeringstidslinje | `/architect:diagram roadmap for 3-fase Copilot Studio-utrulling` |
@@ -46,11 +46,11 @@ Hvis kontekst mangler, still korte spørsmål:
 Kjør `diagram-generation-agent` via Task:
 
 ```
-Task(general-purpose): "Read agents/diagram-generation-agent.md for your role and instructions.
+Task(ms-ai-architect:diagram-generation-agent): "
 Generer [type]-diagram for [scenario].
 Komponenter: [liste over tjenester].
 Kontekst: [ekstra detaljer].
-Les: skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md"
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md"
 ```
 
 ## Format Parameter
@@ -74,7 +74,7 @@ Tilby:
 
 ```
 /architect:diagram architecture for Copilot Studio kundeservice-agent
-/architect:diagram security for Azure AI Foundry med sensitive persondata
+/architect:diagram security for Microsoft Foundry med sensitive persondata
 /architect:diagram dataflow for RAG-pipeline med SharePoint, Azure AI Search og GPT-4o
 /architect:diagram problem for manuell dokumenthåndtering → AI-klassifisering
 /architect:diagram roadmap for 4-fase Copilot Studio-implementering

commands/dpia.md

@@ -8,7 +8,7 @@ model: opus
 
 # DPIA / Personvernkonsekvensvurdering for AI-systemer
 
-Du er Cosmo Skyberg, og skal lede en strukturert DPIA/PVK for et AI-system i norsk offentlig sektor.
+Du er Cosmo Skyberg, og skal lede en strukturert DPIA/PVK for et AI-system. DPIA-plikten (GDPR art. 35) gjelder alle behandlingsansvarlige — offentlig som privat sektor. Default til en sektor-nøytral vurdering og tilpass når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
 
 ## Språk og encoding
 
@@ -20,6 +20,7 @@ Du er Cosmo Skyberg, og skal lede en strukturert DPIA/PVK for et AI-system i nor
 
 Start med å forstå systemet som skal vurderes:
 - Hva gjør AI-systemet?
+- Hvilken sektor og kontekst? (offentlig, privat, finans, helse, etc. — default nøytral hvis ukjent)
 - Hvilke personopplysninger behandles?
 - Hvem er de registrerte?
 - Hva er behandlingsgrunnlaget?
@@ -31,7 +32,7 @@ Bruk samtalehistorikk hvis denne informasjonen allerede er gitt.
 Kjør DPIA-agenten via Task for selve vurderingen:
 
 ```
-Task(architect:dpia-agent): "Read agents/dpia-agent.md for your role and instructions.
+Task(ms-ai-architect:dpia-agent): "
 Gjennomfør en komplett DPIA for følgende AI-system:
 
 **System:** [systemnavnet]
@@ -39,12 +40,16 @@ Gjennomfør en komplett DPIA for følgende AI-system:
 **Personopplysninger:** [hvilke data som behandles]
 **Registrerte:** [hvem som berøres]
 **Behandlingsgrunnlag:** [GDPR art. 6/9]
-**Kontekst:** [offentlig sektor, virksomhet, etc.]
+**Kontekst:** [sektor/kontekst — offentlig, privat, finans, helse, etc.]
+**AI Act-klassifisering (fra /architect:classify, hvis utført):** [risikonivå + rolle + Annex III-kategori — ellers "ikke klassifisert"]
 
-Les kunnskapsbasene:
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
-- skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
-- skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
+Les kunnskapsbasene (kjerne):
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
+
+Betinget (OBLIGATORISK hvis amerikansk-eid skyleverandør eller data nåbar fra tredjeland):
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md (EDPB seks-stegs-TIA + CLOUD Act/FISA 702/EO 14086-restanalyse for risiko 7)
 
 Lever en komplett DPIA-rapport med alle 5 faser, risikomatrise og anbefaling."
 ```

commands/frimpact.md

@@ -1,6 +1,6 @@
 ---
 name: architect:frimpact
-description: FRIA (Art. 27) — grunnleggende rettighetskonsekvensanalyse, obligatorisk for offentlig sektor
+description: FRIA (Art. 27) — grunnleggende rettighetskonsekvensanalyse, obligatorisk for offentlige organer og enkelte private deployere (kredittscoring, livs-/helseforsikring)
 argument-hint: "[system-beskrivelse]"
 allowed-tools: Read, Glob, Grep, Task, Write
 model: opus
@@ -8,7 +8,7 @@ model: opus
 
 # FRIA — Fundamental Rights Impact Assessment (Art. 27)
 
-Du er Cosmo Skyberg, og skal lede en strukturert FRIA for et høyrisiko AI-system. FRIA er obligatorisk for offentlige organer som deployer av høyrisiko-AI.
+Du er Cosmo Skyberg, og skal lede en strukturert FRIA for et høyrisiko AI-system. FRIA (Art. 27) er obligatorisk for deployere som er (a) offentligrettslige organer, (b) private som leverer offentlige tjenester, eller (c) private deployere av høyrisiko-AI til kredittverdighet/kredittscoring av fysiske personer (unntatt svindeldeteksjon) eller til risikovurdering og prising i livs- og helseforsikring. Det er altså ikke et rent offentlig-sektor-verktøy.
 
 ## Språk og encoding
 
@@ -28,7 +28,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør en FRIA (Art. 27) for følgende AI-system:
 
 **System:** [systemnavn]
@@ -41,8 +41,8 @@ Gjennomfør en FRIA (Art. 27) for følgende AI-system:
 Modus: FRIA — utfyll Art. 27-malen.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
 
 Lever en komplett FRIA med alle 7 seksjoner: systembeskrivelse, berørte grupper, rettighetsmatrise (12 rettigheter), konsekvensanalyse, tilsynsnotifikasjon, godkjenning, vedlegg."
 ```
@@ -58,7 +58,7 @@ Lever en komplett FRIA med alle 7 seksjoner: systembeskrivelse, berørte grupper
 
 ## Retningslinjer
 
-- FRIA er OBLIGATORISK for offentlig sektor med høyrisiko-AI
+- FRIA er OBLIGATORISK for offentligrettslige organer, private som leverer offentlige tjenester, og private deployere innen kredittscoring (unntatt svindeldeteksjon) og prising i livs-/helseforsikring
 - Rettighetsmatrisen dekker 12 EU Charter-rettigheter
 - Konsekvensanalyse kun for rettigheter med middels+ påvirkning
 - Resultat skal sendes til AI-tilsynsmyndighet

commands/generate-skills.md

@@ -42,7 +42,7 @@ Dette gir ~15-20 skills per sesjon istedenfor ~5.
 
 ### Strategi: Én agent per skill
 
-Hver skill delegeres til én `general-purpose` Task-agent (sonnet) som utfører:
+Hver skill delegeres til én `general-purpose` Task-agent (opus) som utfører:
 1. MCP-research (5-8 kall)
 2. Filskriving (Write-verktøyet)
 3. Returnerer kort kvittering
@@ -55,7 +55,7 @@ Kjør **5 agenter parallelt** i én melding. Vent på resultat, oppdater state,
 
 ### Agent-prompt (bruk denne malen)
 
-For HVER skill, send denne prompten til en `general-purpose` Task-agent med `model: sonnet`:
+For HVER skill, send denne prompten til en `general-purpose` Task-agent med `model: opus`:
 
 ```
 Du er Cosmo Skyberg, senior Microsoft AI Solution Architect. Generer en kunnskapsreferanse.
@@ -64,7 +64,7 @@ Du er Cosmo Skyberg, senior Microsoft AI Solution Architect. Generer en kunnskap
 
 Skriv kunnskapsreferanse: **{SKILL_TITLE}**
 Kategori: {CATEGORY_NAME}
-Fil: skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
+Fil: ${CLAUDE_PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
 
 ## Steg 1: Research (OBLIGATORISK)
 
@@ -80,15 +80,19 @@ Bruk MCP-verktøy for oppdatert informasjon:
 ## Steg 2: Skriv filen
 
 Bruk Write-verktøyet til å skrive filen til:
-{PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
+${CLAUDE_PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
 
 Format (STRENGT — alle seksjoner påkrevd):
 
 # {SKILL_TITLE}
 
-**Last updated:** 2026-02
+**Last updated:** {dagens måned, YYYY-MM}
 **Status:** [GA | Preview | Announced]
 **Category:** {CATEGORY_NAME}
+**Type:** reference
+**Source:** {den autoritative Microsoft Learn-URLen fra research — den faktiske doc-siden påstandene hviler på, ikke et søketreff}
+**Verified:** {SETTES i Steg 2.5 etter judge — IKKE her}
+**Verified by:** {SETTES i Steg 2.5 etter judge — IKKE her}
 
 ---
 
@@ -127,6 +131,23 @@ Format (STRENGT — alle seksjoner påkrevd):
 - Confidence markers: "Verified" (fra MCP), "Baseline" (modellkunnskap)
 - Konkret og balansert — vis fordeler OG ulemper
 
+## Steg 2.5: Født-verifisert (judge FØR du returnerer)
+
+Filen skal være *født verifisert*: ingen reference-fil forlater agenten uten at de
+maskin-verifiserbare påstandene er bekreftet mot `Source`-URLen.
+
+1. Kjør den gjeldende claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over
+   filens maskin-verifiserbare påstander (sku/version/tpm/status/region/taxonomy) mot
+   `Source`-URLen du hentet i Steg 1.
+2. **Hvis alle påstander er `grounded`:** sett i headeren
+   `**Verified:** {dagens dato, YYYY-MM-DD}` og `**Verified by:** judge-v3.1`.
+3. **Hvis noen påstand IKKE er grounded:** IKKE stempl `Verified`. Rett påstanden mot
+   kilden og kjør judgen på nytt, eller — hvis verdien er maskin-uverifiserbar (pris/
+   JS-rendret) — merk den eksplisitt og la filen gå til menneske-gaten (den blir IKKE
+   committet; se batch-gaten under).
+
+Aldri stempl `Verified` spekulativt. Stempelet betyr «judgen bekreftet mot kilde».
+
 ## Steg 3: Returner kvittering
 
 Returner KUN dette (ingenting annet):
@@ -146,11 +167,11 @@ error: {only if failed}
 
 ```
 # Batch 1: 5 parallelle agenter
-Task(general-purpose, sonnet): "Research + write skill: Hybrid Search..."
-Task(general-purpose, sonnet): "Research + write skill: Semantic Ranker..."
-Task(general-purpose, sonnet): "Research + write skill: Citation Tracking..."
-Task(general-purpose, sonnet): "Research + write skill: RAG Evaluation..."
-Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
+Task(general-purpose, opus): "Research + write skill: Hybrid Search..."
+Task(general-purpose, opus): "Research + write skill: Semantic Ranker..."
+Task(general-purpose, opus): "Research + write skill: Citation Tracking..."
+Task(general-purpose, opus): "Research + write skill: RAG Evaluation..."
+Task(general-purpose, opus): "Research + write skill: Multi-Index..."
 
 # Vent på alle 5 → oppdater state.json → neste batch
 ```
@@ -159,11 +180,24 @@ Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
 
 1. **Parse kvitteringer** fra agentene
 2. **Verifiser filer finnes** med Glob
-3. **Oppdater state.json:**
-   - Legg til ferdige skill-IDer i `completed`
-   - Legg til eventuelle feilede i `failed`
+3. **Create-guard (OBLIGATORISK — to sibling-gater):** kjør BEGGE over batchens nye filer:
+   ```bash
+   node scripts/kb-update/validate-kb-file.mjs <fil1.md> <fil2.md> ...
+   node scripts/kb-update/scan-adversarial-content.mjs <fil1.md> <fil2.md> ...
+   ```
+   Kontrakt-gaten exit-er ≠0 hvis en fil mangler `Source`, ikke er født-verifisert (mangler
+   `Verified`/`Verified by`), eller er en stor fil uten TOC. **Layer B ingestion-gaten
+   (G6 §8 / R6 punkt d)** exit-er 1 (BLOCK — aldri committ, karantene) på adversarielt
+   innhold (unicode/injection/base64 i prosa + fenced code blocks, via delte llm-security-
+   detektorer) eller 2 (WARN — flagg for operatør, ikke auto-committ). **En fil som FAIL-er
+   noen av gatene committes IKKE** — logg den i `state.failed` og send den til menneske-
+   gaten. Dette hindrer generatoren i å re-introdusere drift (kontrakt) OG i å persistere en
+   forgiftet referansefil (Layer B — ortogonal til korrekthet).
+4. **Oppdater state.json:**
+   - Legg til ferdige (gate-PASS) skill-IDer i `completed`
+   - Legg til feilede/gate-FAIL i `failed`
    - Oppdater `stats.total_generated` og `stats.total_bytes`
-4. **Neste batch** eller avslutt
+5. **Neste batch** eller avslutt
 
 ## Etter hele sesjonen
 
@@ -180,13 +214,19 @@ Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
    Gjenstår: N skills
    ```
 
-2. **Commit:**
+2. **Create-guard FØR commit (OBLIGATORISK — begge gater):** kjør BEGGE over ALLE filer du er
+   i ferd med å committe. Bare filer som passerer BEGGE skal med:
    ```bash
+   FILES=$(git diff --name-only --diff-filter=AM -- 'skills/ms-ai-*/references/**/*.md')
+   node scripts/kb-update/validate-kb-file.mjs $FILES
+   node scripts/kb-update/scan-adversarial-content.mjs $FILES   # Layer B ingestion-gate (G6 §8)
    git add skills/ms-ai-*/references/<dirs>/ scripts/skill-gen/state.json
    git commit -m "docs(architect): generate N knowledge skills (category-names)"
    ```
+   Hvis noen av gatene exit-er ≠0: IKKE commit de feilende filene — fjern dem fra staging og
+   send til menneske-gaten (kontrakt-FAIL rettes; Layer B BLOCK karantenes/adjudiseres).
 
-3. **Oppdater REMEMBER.md** med ny status
+3. **Oppdater STATE.md** med ny status
 
 ## Feilhåndtering
 
@@ -263,8 +303,16 @@ Bruk Edit-verktøyet (IKKE Write) for å:
 - Oppdatere "Last updated" til gjeldende måned
 - Oppdatere utdaterte fakta, priser, datoer
 - Oppdatere Microsoft Learn-URLer
-- Markere oppdatert innhold med "Verified (MCP {måned})"
 - Beholde eksisterende struktur og seksjoner
+- **Backfill kontrakt-headeren** (Spor 3 Port 1) hvis legacy-fila mangler den: legg til
+  `**Type:** reference` og `**Source:** {autoritativ Learn-URL}` i header-blokken (en
+  berørt fil skal forlate oppdateringen kontrakt-kompatibel — inkrementell Spor 1).
+
+## Steg 2.5: Født-verifisert (judge FØR du returnerer)
+Kjør claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over de oppdaterte maskin-
+verifiserbare påstandene mot `Source`. Alle `grounded` ⇒ sett `**Verified:** {dagens dato}`
++ `**Verified by:** judge-v3.1`. Ikke grounded ⇒ IKKE stempl; rett mot kilde og kjør på nytt,
+eller send til menneske-gaten (fila committes ikke; se batch-gaten). Aldri stempl spekulativt.
 
 ## Steg 3: Returner kvittering
 SKILL_UPDATED
@@ -275,7 +323,8 @@ status: success|no_changes|failed
 ```
 
 4. Track in `state.json` under a new `"updated"` array
-5. After each batch, verify files still pass `validate-plugin.sh`
+5. **Create-guard (OBLIGATORISK — begge gater):** `node scripts/kb-update/validate-kb-file.mjs <oppdaterte filer>` + `node scripts/kb-update/scan-adversarial-content.mjs <oppdaterte filer>` (Layer B ingestion-gate, G6 §8) — FAIL på noen av dem committes IKKE
+6. After each batch, verify files still pass `validate-plugin.sh`
 
 **Key difference from generation:** Update uses Edit (preserves structure), generation uses Write (creates from scratch).
 

commands/help.md

@@ -23,11 +23,15 @@ Presenter følgende oversikt til brukeren i et ryddig, tabellbasert format.
 | `/architect:compare` | Sammenlign Microsoft AI-plattformer for et gitt scenario |
 | `/architect:security` | Kjør sikkerhets- og compliance-vurdering |
 | `/architect:cost` | Estimer kostnader for en foreslått arkitektur |
+| `/architect:businesscase` | Forretningscase med NNV og DFØ-gevinstrealisering |
 | `/architect:adr` | Opprett en Architecture Decision Record (ADR) |
+| `/architect:design` | Sektor-nøytralt Solution Architecture Document (SAD) — mellombane mellom samtale og full utredning |
 | `/architect:research` | Dypdykk i et spesifikt Microsoft AI-tema |
 | `/architect:poc` | Generer en POC-plan med evalueringskriterier |
 | `/architect:license` | Kartlegg lisensbehov for en løsning |
+| `/architect:vendor` | Leverandørvurdering (tredjepart/SaaS due diligence) — dataresidens, DPA, Schrems II, AI Act-deployer |
 | `/architect:migrate` | Planlegg migrasjonssti mellom plattformer |
+| `/architect:anskaffelse` | AI-anskaffelse — kravspesifikasjon, leverandørevaluering, terskelverdier |
 | `/architect:utredning` | AI-arkitekturutredning v2 — fil-basert orkestrering, TeamCreate, 3-fase KOMPLEKS |
 | `/architect:review` | Kjør arkitekturgjennomgang mot norske offentlig sektor-krav |
 | `/architect:diagram` | Generer arkitekturdiagram med Imagen 3 |
@@ -36,6 +40,7 @@ Presenter følgende oversikt til brukeren i et ryddig, tabellbasert format.
 | `/architect:summary` | Generer teknisk sammendrag og beslutningsnotat |
 | `/architect:export` | Eksporter arkitekturdokument til PDF |
 | `/architect:generate-skills` | Generer kunnskapsfiler med MCP-research (intern) |
+| `/architect:kb-update` | Manuell KB-refresh — poll sitemaps, oppdater endrede filer, commit |
 | `/architect:classify` | EU AI Act-klassifisering: risikonivå + rolle |
 | `/architect:requirements` | Konkrete AI Act-krav basert på risikonivå og rolle |
 | `/architect:transparency` | Generer Art. 13/50 transparensnotis på norsk |
@@ -63,7 +68,7 @@ Presenter følgende oversikt til brukeren i et ryddig, tabellbasert format.
 ## Kunnskapsbaser
 
 ### Plattformer (`references/platforms/`)
-- Azure AI Foundry, Copilot Studio, M365 Copilot, Power Platform
+- Microsoft Foundry, Copilot Studio, M365 Copilot, Power Platform
 
 ### Arkitektur (`references/architecture/`)
 - Decision trees, Security, ADR-template, Cost models
@@ -98,6 +103,16 @@ Pluginen bruker følgende MCP-servere:
 7. **Beslut:** `/architect:adr` — dokumenter beslutningen
 8. **Planlegg:** `/architect:poc` — lag POC-plan for validering
 
+### Privat sektor / enterprise
+
+Offentlig-banen over er én av to. For privat/regulert sektor (uten utredningsinstruksen):
+
+1. **Klassifiser:** `/architect:classify` — AI Act gjelder alle providers/deployere
+2. **Design:** `/architect:design` — sektor-nøytralt Solution Architecture Document
+3. **Vurder:** `/architect:security` + `/architect:cost` + `/architect:ros` (finans → DORA/Finanstilsynet aktiveres automatisk)
+4. **Leverandør:** `/architect:vendor` — due diligence på ekstern SaaS/AI
+5. **Beslut:** `/architect:adr`
+
 ## Om argumentet
 
 Hvis brukeren angir et emne (f.eks. `/architect:help security`), vis utvidet informasjon om det spesifikke emnet istedenfor full oversikt.

commands/kb-update.md

@@ -8,12 +8,14 @@ model: opus
 
 # /architect:kb-update — Manuell KB-oppdatering
 
-Holder Microsoft AI-kunnskapsbasen i `skills/*/references/` ferskt ved å sammenligne lokale referansefiler mot Microsoft Learn-sitemaps. **All kjøring er manuell** — pluginen schedulerer ingenting, og brukere som ønsker periodisk kjøring sørger for det selv (cron, launchd, GitHub Actions, etc.).
+Holder Microsoft AI-kunnskapsbasen i `skills/*/references/` ferskt ved å sammenligne lokale referansefiler mot Microsoft Learn-sitemaps.
+
+**Apply (oppdatering av KB-filer) er alltid manuell og kjøres in-session** — den bruker Claude og forblir under operatør-gate. **Deteksjon** (poll → rapport → discovery → skill-livssyklus) er ren node som aldri kontakter Claude/Anthropic, og kan **valgfritt schceduleres** (se «Scheduled deteksjon» under). Skillet er ToS-forankret: Consumer Terms §3.7 begrenser automatisert tilgang til Anthropics tjenester — ikke kjøring av lokale scripts som ikke rører Claude.
 
 ## Hva kommandoen gjør
 
 1. **Polle sitemaps:** kjører `node scripts/kb-update/run-weekly-update.mjs --force` for å hente fersk `<lastmod>` for hver Microsoft Learn-URL i registeret
-2. **Optional discovery:** med default `--discover` finner nye relevante URLer i sitemap som ikke er i registeret (`scripts/kb-update/discover-new-urls.mjs --limit 500`)
+2. **Optional discovery:** med default `--discover` finner nye relevante URLer i sitemap som ikke er i registeret (`scripts/kb-update/discover-new-urls.mjs --limit 500`). Discovery **leser beslutnings-ledgeren** (`data/decisions.json`, lag 2) og utelater alt operatøren allerede har tatt stilling til (policy A: approved/rejected/pending) — så de samme kandidatene drukner ikke gaten kjøring etter kjøring
 3. **Generere endringsrapport:** `report-changes.mjs` produserer `data/change-report.json` med per-fil prioritering (critical/high/medium/low) basert på antall endrede kilder + alder på lokal fil
 4. **Vise rapporten:** lese rapport, presentere oppsummering til bruker, vente på `go`
 5. **Oppdatere filer:** for hver fil i valgt prioritetsbøtte (default: critical + high):
@@ -31,6 +33,45 @@ Holder Microsoft AI-kunnskapsbasen i `skills/*/references/` ferskt ved å sammen
 | `--dry-run` | Generer rapport, men ikke oppdater filer eller committ |
 | `--single-commit` | Samle alle filendringer i én commit i stedet for én per fil |
 
+## Scheduled deteksjon (opt-in, Spor C / C1)
+
+Deteksjonen kan kjøre automatisk i bakgrunnen ved sesjonsstart — **av som default**. Den er frivillig å sette opp, men virker når aktivert.
+
+**Slik aktiverer du den:** opprett `ms-ai-architect.local.md` i plugin-roten (gitignored) med:
+
+```yaml
+---
+scheduled_detection:
+  enabled: true            # default false — ingenting kjører før dette er true (Tier 1)
+  interval_days: 7         # kjør deteksjon på nytt når det er ≥ N dager siden sist poll
+  include_skill_lifecycle: true   # ta med skill-livssyklus-deteksjon (overlapp/gap/bloat)
+  os_scheduler_cadence: daily     # Tier 2: daily (poll hver dag) | interval (throttle på interval_days)
+---
+```
+
+### Tier 1 — sesjonsforankret (SessionStart-hook)
+
+Når `enabled: true` og det er ≥ `interval_days` siden sist poll, spawner SessionStart-hooken `scripts/kb-update/run-detection.mjs` i bakgrunnen. Den kjører **kun deteksjon** (poll → rapport → discovery → skill-livssyklus) og skriver JSON-rapporter til `data/` — **aldri** til `skills/`, og kaller **aldri** Claude. Ferske signaler surfaces ved neste sesjonsstart («KB: …» + «Skill-signaler: …»), og du kjører `/architect:kb-update` manuelt for å gjennomgå + apply-e gjennom gaten. **Begrensning:** Tier 1 kjører bare når en Claude-sesjon *starter* — starter du aldri en sesjon, kjører deteksjonen aldri.
+
+### Tier 2 — lokal launchd-scheduler (ekte bakgrunn mellom sesjoner)
+
+For deteksjon som kjører *uavhengig av sesjoner*, installer en lokal **launchd LaunchAgent** som fyrer samme Claude-frie entrypoint daglig (kl. 03:00):
+
+```bash
+node scripts/kb-update/scheduler.mjs install     # skriv plist til ~/Library/LaunchAgents + last agenten
+node scripts/kb-update/scheduler.mjs status       # er den lastet?
+node scripts/kb-update/scheduler.mjs run-now       # kjør én gang nå (verifiser uten å vente til 03:00)
+node scripts/kb-update/scheduler.mjs print          # vis plisten uten å skrive noe (alias --dry-run)
+node scripts/kb-update/scheduler.mjs uninstall       # avlast + fjern plist
+```
+
+- **Kadens (`os_scheduler_cadence`):** `daily` (default) poller hver dag; `interval` throttler til `interval_days` via samme staleness-gate som Tier 1. (Onboarding setter dette senere; daglig er fornuftig default — poll av Microsoft Learn-sitemaps er billig og read-only.)
+- **Pause = uninstall.** LaunchAgenten kjører uansett `enabled:`-flagget (det styrer *kun* Tier 1/hooken). Vil du stoppe Tier 2, kjør `uninstall` — det er pause-knappen.
+- **Etter en major `brew upgrade node`:** kjør `install` på nytt. Node-stien bakes inn ved install-tid (launchd har minimalt `PATH`); plistens `PATH` inkluderer `/usr/local/bin` så barneprosessenes `node` overlever, men det er ryddigst å re-installere.
+- **launchd, ikke cron:** Apple anbefaler launchd; cron krever Full Disk Access og er «not recommended». Vil du heller bruke cron/systemd/CI, peker du den på samme `node scripts/kb-update/run-detection.mjs`.
+
+**ToS-garanti (strukturell, begge tiers):** entrypointet (`run-detection.mjs`, og `scheduler.mjs run` som delegerer til det) spawner kun `node` på de allow-listede deteksjons-scriptene + `launchctl` for agent-styring; det kan ikke invokere `claude`. Apply (det eneste Claude-steget) forblir manuelt og in-session. Kjør `node scripts/kb-update/run-detection.mjs --dry-run` (eller `scheduler.mjs print`) for å se hva som ville kjørt uten å kjøre noe.
+
 ## Instruksjoner til assistenten
 
 ### 1. Pre-flight
@@ -63,6 +104,78 @@ Presenter til bruker:
 
 Hvis `--dry-run`: stopp her, ikke oppdater filer.
 
+### 3b. Discovery-gate — nye URLer via decision-ledger (lag 2)
+
+Kjørte discovery (default), lukk løkken her. Dette er **operatør-gaten** — det eneste stedet beslutninger om nye URLer skrives.
+
+a. **Les kandidatene:** `data/discovery-report.json` → `candidates[]`. Listen er allerede dedupet av scriptet mot både registry og `data/decisions.json`, så alt her er genuint ubesluttet. Feltet `deduped_by_ledger` viser hvor mange tidligere beslutninger som ble utelatt.
+
+b. **Presenter for operatør**, gruppert per `suggested_skill` (vis `url`, `suggested_category`, `lastmod`). For hver kandidat (eller batch): **approve** (ta inn i KB), **reject** (irrelevant — ikke vis igjen), eller **utsett** (`pending` — ikke avgjort, vises i pending-bøtta men re-foreslås ikke).
+
+c. **Skriv beslutningene til ledgeren — ENESTE skrivevei.** Bruk `lib/decisions-io.mjs` (ikke håndskriv JSON):
+
+```
+import { loadDecisions, recordDecision, saveDecisions } from './scripts/kb-update/lib/decisions-io.mjs';
+let led = loadDecisions();
+led = recordDecision(led, url, { status: 'rejected', decided_at: '<i dag>', suggested_skill, suggested_category, note });
+// ...én recordDecision per beslutning...
+saveDecisions(led);
+```
+
+`decided_at` settes til dagens dato (caller-injisert — `recordDecision` er ren). `decisions.json` er tracket i git (overlever, til forskjell fra de genererte rapportene).
+
+d. **For `approved`:** registrér URLen i `url-registry` (gated) så den fanges av polling heretter — via `lib/registry-io.mjs` `saveRegistry`. Bruk `suggested_skill`/`suggested_category` fra kandidaten. Deretter kjør **transformasjonslaget (lag 4)** for å lage KB-fila:
+   1. `microsoft_docs_fetch` på den godkjente URLen → kildedokument.
+   2. Destillér via `scripts/kb-update/transform-prompt.md` (doc→KB-fil; status-påstander holdes eksplisitte). Multi-agent parallell fan-out foreslås i produksjon (roadmap §71), speilet på `generate-skills`-mønsteret.
+   3. **Født-verifisert (Spor 3 Port 2):** kjør claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over brødtekstens maskin-verifiserbare påstander mot den godkjente URLen → `verdict = {pass}`. Så `meta = stampVerifiedMeta({title, status, category, source: <godkjent URL>, lastUpdated: <YYYY-MM>}, verdict, <i dag>)` — stempler `type='reference'` + `verified` + `verified_by='judge-v3.1'` **kun** ved `pass`; ellers KASTER (ingen fil, flagg for menneske). Deretter `content = composeKbFile(meta, body)` (`lib/transform.mjs`) — header + (store filer >100 linjer) en deterministisk `## Innhold`-TOC + brødtekst. **`Status` + `Source` + `Verified` + `Verified by` er obligatoriske** — `Source` i header-blokka (øverste 500 bytes) er det som lar lag 3 backfille `authority_source`. TOC-en fødes inn så regenerering ikke stripper den (Fase 1c).
+   4. `validateKbFile(content)` MÅ være `valid: true` (title + Last updated + Status + Source + **Verified + Verified by**; **store filer også TOC**) før noe gates videre (ellers be modellen fylle manglende felt).
+   5. For hver status-/load-bearing-påstand: `buildChange({...})` → **lag 5** `classifyChange(...)` (samme gate som §4 c2). Status-påstander er alltid `flagged`.
+   6. `resolveTargetPath(tax, category, filename)` → eierskill-sti via taksonomien (`null` = ukjent kategori → flagg for operatør, ikke skriv).
+   7. **Create-guard FØR skriving (to sibling-gater):** kjør BEGGE (exit ≠0 på noen av dem ⇒ ikke skriv):
+      - `node scripts/kb-update/validate-kb-file.mjs <sti>` — kontrakt (Source/født-verifisert/TOC).
+      - `node scripts/kb-update/scan-adversarial-content.mjs <sti>` — **Layer B ingestion-gate (G6 §8 / R6 punkt d):** deterministisk adversariell-innhold-skann (unicode/injection/base64, prosa + fenced code blocks) via de delte llm-security-detektorene. **exit 1 = BLOCK** (aldri skriv — karantene, operatør adjudiserer); **exit 2 = WARN** (flagg → samme menneske-i-loop som en status-påstand; ikke auto-committ). Gaten er ortogonal til korrekthets-judgen: en faktakorrekt men forgiftet fil blokkeres likevel.
+
+      Først etter operatør-gate + BEGGE create-guards grønne: atomisk skriving (`lib/atomic-write.mjs` + `lib/backup.mjs`). **`transform.mjs` skriver aldri selv** — verifisert av `tests/kb-update/test-transform.test.mjs` (import-invariant). Kriterium verifisert av `tests/kb-eval/test-transform-criterion.test.mjs` (regenerer 1 fil → eval ≥ baseline). Layer B verifisert av `tests/kb-update/test-adversarial-scan.test.mjs` + `test-scan-adversarial-content.test.mjs` + `test-adversarial-detect-integration.test.mjs`.
+
+e. **Invariant:** `discover-new-urls.mjs` (deteksjon) skriver **aldri** ledgeren — den kun leser. Bare denne gaten skriver. Verifisert av `tests/kb-update/test-discover-invariant.test.mjs`.
+
+### 3c. Kurs-deteksjon-gate — nye/endrede kurs via decision-ledger (courses-kolleksjon, Spor C / C3)
+
+Operatør-gaten for kurs-sporet. **Et kurs-lead er et *signal* om at et tema finnes — aldri en doc-side som ingestes.** Å godkjenne et lead **henter/transformerer/skriver ingen KB-fil** (det ville vært auto-ingest, et eksplisitt ikke-mål) — det registrerer kun operatørens beslutning i den UID-nøklede `courses`-kolleksjonen. Dette er ENESTE skrivevei for kurs-beslutninger.
+
+a. **Sjekk rapporten:** `data/course-detection-report.json`. Produsert av den Claude-frie detektoren (`detect-courses.mjs`) — enten schedulert (Tier 1/2) eller manuelt: `node scripts/kb-update/detect-courses.mjs`. Mangler fila, eller `status:"skipped"` (Keychain-creds mangler — C3 er opt-in inni opt-in): **hopp over denne gaten stille**. `status:"error"`: rapportér kort og hopp over.
+
+b. **Les leads:** `new[]` + `updated[]` (hver `{uid, title, url, products, suggested_skill, suggested_category, updated_at}`). `removed[]` er **kun et informasjonssignal** — vis det som en notis, aldri som en beslutning (et retirert kurs er ikke et tema å dekke; spec §4.2).
+
+c. **Dedup mot ledgeren (policy A):** utelat leads operatøren allerede har tatt stilling til. Bruk `isCourseLeadDecided` (UID er den stabile nøkkelen — URL kan endres):
+
+```
+import { loadDecisions, isCourseLeadDecided } from './scripts/kb-update/lib/decisions-io.mjs';
+const led = loadDecisions();
+const fresh = [...report.new, ...report.updated].filter((l) => !isCourseLeadDecided(led, l.uid));
+```
+
+d. **Presenter `fresh`** for operatør, gruppert per `suggested_skill` (vis `title`, `url`, `products`, `kind` new/updated). For hvert lead (eller batch): **approve** (relevant — verdt å dekke i KB-en), **reject** (ikke relevant — ikke vis igjen), eller **utsett** (`pending` — ikke avgjort).
+
+Hvis `--dry-run`: stopp etter presentasjonen — **ikke skriv ledgeren**.
+
+e. **Skriv beslutningene til ledgeren — ENESTE skrivevei.** Bruk `recordCourseLead` (ikke håndskriv JSON):
+
+```
+import { loadDecisions, recordCourseLead, saveDecisions } from './scripts/kb-update/lib/decisions-io.mjs';
+let led = loadDecisions();
+led = recordCourseLead(led, uid, {
+  kind, status: 'approved', title, url, products, suggested_skill, suggested_category,
+  updated_at, detected_at, decided_at: '<i dag>', note,
+});
+// ...én recordCourseLead per beslutning...
+saveDecisions(led);
+```
+
+`decided_at` settes til dagens dato (caller-injisert — `recordCourseLead` er ren). `decisions.json` er tracket i git.
+
+f. **Ingen ingest — strukturell invariant.** Et godkjent kurs-lead blir værende i `courses`-kolleksjonen og leses av **ingen** av apply-pathene: `apply-skill-op.mjs` leser kun `actions`, `discover-new-urls.mjs` kun `decisions`. En kurs-beslutning trigger derfor **aldri** fetch/transform/KB-skriving. Skal et kurs' tema faktisk dekkes med en KB-side, er det en **separat, bevisst** doc-discovery-handling gjennom §3b (finn doc-URLen) — ikke en automatisk konsekvens av å godkjenne kurset. Et godkjent kurs surfaces ved sesjonsstart (C3.6: «N nye / M endrede kurs i dekkede produkter») som en påminnelse til operatøren.
+
 ### 4. Per-fil oppdatering (etter brukerens `y`)
 
 For hver fil i valgte prioriteter:
@@ -70,14 +183,22 @@ For hver fil i valgte prioriteter:
 a. **Les nåværende fil:** `Read` på filstien
 b. **Hent oppdaterte kilder:** for hver URL i `change-report.json[file].changed_urls`, kjør `microsoft_docs_fetch` på URLen
 c. **Identifiser endringer:** sammenlign hentet markdown mot eksisterende seksjoner i fila. Fokuser på faktuelle endringer (ny info, oppdaterte features, deprecation-varsler) — ikke små formuleringsendringer
-d. **Oppdater fila:** `Edit` med relevante endringer. Behold "For Cosmo"-seksjonen og overordnet struktur. Oppdater `Last updated: YYYY-MM-DD`-header til dagens dato
-e. **Committ:** `git add <fil>` + `git commit -m "chore(ms-ai-architect): refresh KB $(basename <fil>) [skip-docs]"` med mindre `--single-commit` ble gitt
+c1. **Autoritetskilde-binding (lag 3) — header-as-truth.** `authority_source = resolveAuthority(<fil-innhold>)` (`lib/authority.mjs`) — fila sin `**Source:**`-header ER den utpekte autoriteten for dens påstander. `null` hvis fila mangler headeren (vokser etter hvert som lag 4 regenererer filer). Dette er inngangsdataen til lag-5 regel 3 (autoritets-mismatch): er en status-/load-bearing-endrings `source_url` ≠ `authority_source`, flagges den. Aldri gjett en autoritet fra fila sine siterte URLer (251/303 filer siterer 4–10 → ville vært gjetning).
+c2. **Verifisering-ut (lag 5) — FØR du skriver.** Hver kandidat-endring fra (c) går gjennom `lib/verify-out.mjs` `classifyChange({field, old_value, new_value, source_url, authority_source, refutations})` med `authority_source` fra (c1). Dette fanger regresjons-klassen (en status-påstand «korrigert» mot en tilfeldig sitert side og stille auto-applyet — agentic-retrieval-regresjonen):
+   - **`flagged`** → IKKE auto-skriv. Vis endringen til operatør med `reasons[]`; operatør avgjør om den tas inn. **Status-påstander (GA/preview/versjon/pris) er ALLTID `flagged`** (spec §21) — uansett hvor sikker kilden ser ut.
+   - **`auto-applied`** → trygt å ta inn i (d) (benign, ikke-status, ingen motbevis, autoritets-match).
+   - **Adversarial motbevis-panel (LLM-runtime):** for status-/load-bearing-påstander, kjør et lite panel som *prøver å motbevise* `new_value` mot den utpekte `authority_source`, og mat resultatene inn som `refutations[]` (`[{refuted, reason}]`). Multi-agent foreslås når lag 4/5 kjøres i produksjon (roadmap §71).
+   - **Invariant:** `verify-out.mjs` skriver aldri — den returnerer kun en verdict. Selve skrivingen skjer i (d), gated. Verifisert av `tests/kb-update/test-verify-out.test.mjs`.
+d. **Oppdater fila:** `Edit` med endringer som er `auto-applied` eller eksplisitt godkjent av operatør i (c2). Behold "For Cosmo"-seksjonen og overordnet struktur. Oppdater `Last updated: YYYY-MM-DD`-header til dagens dato. **Lag-4-kontrakt:** kjør `validateKbFile(<ny fil-innhold>)` (`lib/transform.mjs`) før skriving — den skal være `valid: true`. Mangler fila et `**Source:**`-header, legg det til i header-blokka med den utpekte autoritets-URLen for hovedkilden — da fanger lag 3 (`resolveAuthority` + `build-registry`) den som `authority_source`, og lag-5 regel 3 blir virksom for fila. Mangler en **stor fil (>100 linjer)** en `## Innhold`-TOC, generer den med `buildToc(<brødtekst>)` og legg den inn rett etter header-`---` — `validateKbFile` krever den nå for store filer, så in-place-oppdateringer backfiller TOC inkrementelt (Fase 1c).
+d1. **Layer B FØR skriving/commit (ingestion-gate, G6 §8):** kjør `node scripts/kb-update/scan-adversarial-content.mjs <fil>` på den oppdaterte fila. exit 1 (BLOCK) ⇒ ikke skriv/committ — karantene, operatør adjudiserer; exit 2 (WARN) ⇒ flagg for operatør, ikke auto-committ. Deterministisk adversariell-innhold-skann via delte llm-security-detektorer; ortogonal til korrekthets-gatene i (c1/c2).
+e. **Committ:** kjør create-guardene (`validate-kb-file.mjs` + `scan-adversarial-content.mjs`) grønne på fila, deretter `git add <fil>` + `git commit -m "chore(ms-ai-architect): refresh KB $(basename <fil>) [skip-docs]"` med mindre `--single-commit` ble gitt
 
 ### 5. Single-commit modus
 
-Hvis `--single-commit`: skip committer per fil, og lag én samlet commit til slutt:
+Hvis `--single-commit`: skip committer per fil, og lag én samlet commit til slutt. **Layer B FØR commit (ingestion-gate, G6 §8):** skann alle endrede `skills/**/*.md` — en BLOCK (exit 1) tas ut av staging (aldri committet, karantene); en WARN (exit 2) flagges for operatør før commit:
 
 ```bash
+node scripts/kb-update/scan-adversarial-content.mjs $(git diff --name-only --diff-filter=AM -- 'skills/**/*.md')
 git add skills/
 git commit -m "chore(ms-ai-architect): refresh KB — N files [skip-docs]"
 ```
@@ -114,6 +235,9 @@ Rapporter:
 
 ## Schedulering
 
-Pluginen schedulerer **ingenting**. Hvis du vil ha periodisk kjøring, sett opp en cron-jobb / launchd-jobb / systemd timer / GitHub Actions-workflow som kjører `node scripts/kb-update/run-weekly-update.mjs --force --discover` (uten apply-fasen) og varsler deg om å kjøre `/architect:kb-update` i en interaktiv Claude Code-sesjon.
+Pluginen schedulerer **ingenting før du selv aktiverer det** (alt er opt-in). Du har tre nivåer, alle Claude-frie i deteksjonsfasen:
+- **Tier 1 (sesjonsstart):** `scheduled_detection.enabled: true` i `ms-ai-architect.local.md` — se «Scheduled deteksjon» over.
+- **Tier 2 (lokal launchd, ekte bakgrunn):** `node scripts/kb-update/scheduler.mjs install` — se «Scheduled deteksjon» over.
+- **Egen scheduler:** vil du heller bruke cron / systemd timer / CI, pek den på `node scripts/kb-update/run-detection.mjs` (eller `run-weekly-update.mjs --force --discover` for den eldre poll-flyten) og la den varsle deg om å kjøre `/architect:kb-update` i en interaktiv sesjon.
 
 Apply-fasen (oppdatere filer + committe) kan ikke automatiseres innenfor denne pluginen — den krever LLM-resonnering på endringene og menneskelig vurdering, og er bevisst designet for kjøring fra en åpen Claude Code-sesjon.

commands/license.md

@@ -23,17 +23,17 @@ Ekstraher lisenstype(r) fra argumentet. Vanlige kombinasjoner:
 
 ### 2. Les referanse
 
-Les `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` for komplett lisensmatrise.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` for komplett lisensmatrise.
 
 ### 3. Deleger kartlegging
 
 Bruk Task-verktøyet til å lansere `license-mapper-agent`:
 
 ```
-Task(general-purpose): "Les agents/license-mapper-agent.md og kartlegg lisenser.
+Task(ms-ai-architect:license-mapper-agent): "Kartlegg lisenser.
 Lisenser: [lisenstype(r)]
-Les: skills/ms-ai-advisor/references/architecture/licensing-matrix.md
-og skills/ms-ai-advisor/references/platforms/ (alle plattformfiler).
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/ (alle plattformfiler).
 Verifiser kritiske punkter via microsoft_docs_search."
 ```
 
@@ -51,7 +51,7 @@ Verifiser kritiske punkter via microsoft_docs_search."
 | Copilot Studio | ... | ... |
 | AI Builder | ... | X credits/bruker/mnd |
 | Azure OpenAI | ... | Separat Azure-abonnement |
-| Azure AI Foundry | ... | ... |
+| Microsoft Foundry | ... | ... |
 | Power Automate AI | ... | ... |
 
 **Viktige merknader:**

commands/migrate.md

@@ -23,7 +23,7 @@ Ekstraher:
 
 ### 2. Les migrasjonsreferanse
 
-Les `skills/ms-ai-advisor/references/architecture/migration-patterns.md` for:
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/migration-patterns.md` for:
 - Migrasjonsmatrise (innsats, risiko, tidslinje)
 - Detaljerte migrasjonsmønstre med steg-for-steg
 - Kodeeksempler for vanlige migrasjoner

commands/onboard.md

@@ -2,7 +2,7 @@
 name: architect:onboard
 description: Onboard pluginen med virksomhetsspesifikk kontekst
 argument-hint: "[--status]"
-allowed-tools: Read, Glob, Grep, Task, Write, AskUserQuestion
+allowed-tools: Read, Glob, Grep, Task, Write, AskUserQuestion, Bash
 model: opus
 ---
 
@@ -14,11 +14,23 @@ Du er Cosmo Skyberg, og skal starte onboarding-prosessen for å tilpasse plugine
 
 **VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output.
 
+## Datakatalog (bruker-eid — løses FØR alt annet)
+
+Virksomhetskonteksten lagres i en **bruker-eid** katalog som overlever plugin-reinstall (ikke i plugin-roten, som blåses bort ved oppgradering). Resolv den absolutte stien én gang og bruk den for ALL lesing/skriving under:
+
+```bash
+ORG_DIR="$HOME/.claude/ms-ai-architect/org"
+mkdir -p "$ORG_DIR"
+echo "$ORG_DIR"
+```
+
+Bruk den utskrevne absolutte stien (`$ORG_DIR`) i alle Glob/Read/Write-kall og i Task-prompten til onboarding-agenten. **Skriv aldri org-filer til plugin-roten.** (Stien speiler `lib/user-data.mjs` `resolveOrgDir`, som bruker `os.homedir()`.)
+
 ## Statussjekk (--status)
 
 Hvis argumentet inneholder `--status`:
 
-1. Bruk Glob for å finne alle `org/*.md`-filer
+1. Bruk Glob for å finne alle `$ORG_DIR/*.md`-filer (absolutt bruker-eid sti)
 2. Les hver fil og sjekk frontmatter (`completed: true/false`, `last_updated`)
 3. Vis statusrapport:
 
@@ -27,21 +39,30 @@ Hvis argumentet inneholder `--status`:
 
 | Kategori | Fil | Status | Oppdatert |
 |----------|-----|--------|-----------|
-| Virksomhetsprofil | org/organization-profile.md | [Fullført/Mangler] | [dato] |
-| Teknologistack | org/technology-stack.md | [Fullført/Mangler] | [dato] |
-| Sikkerhet og compliance | org/security-compliance.md | [Fullført/Mangler] | [dato] |
-| Arkitekturbeslutninger | org/architecture-decisions.md | [Fullført/Mangler] | [dato] |
-| Forretningsreferanser | org/business-references.md | [Fullført/Mangler] | [dato] |
+| Virksomhetsprofil | organization-profile.md | [Fullført/Mangler] | [dato] |
+| Teknologistack | technology-stack.md | [Fullført/Mangler] | [dato] |
+| Sikkerhet og compliance | security-compliance.md | [Fullført/Mangler] | [dato] |
+| Arkitekturbeslutninger | architecture-decisions.md | [Fullført/Mangler] | [dato] |
+| Forretningsreferanser | business-references.md | [Fullført/Mangler] | [dato] |
+| Fri kontekst (valgfri) | free-context.md | [Lagt til/Ikke satt] | [dato] |
 
-**Fullført:** X/5 kategorier (XX%)
+**Fullført:** X/5 kategorier (XX%) — lagret i `$ORG_DIR`. Fri kontekst er valgfri og teller ikke mot prosenten.
 ```
 
-4. Hvis noen mangler, tilby å kjøre `/architect:onboard` for å fullføre
-5. Avslutt etter statusvisning
+4. **Planlagt deteksjon:** les `$HOME/.claude/ms-ai-architect/ms-ai-architect.local.md` hvis den finnes, og vis `scheduled_detection`-innstillingen, f.eks.:
+
+```
+**Planlagt deteksjon:** [Aktivert / Deaktivert] — kadens: [daily/interval], intervall: [N] dager.
+```
+
+   Mangler fila: vis `**Planlagt deteksjon:** Ikke satt (kjør /architect:onboard for å sette den opp).`
+
+5. Hvis noen kategorier mangler, tilby å kjøre `/architect:onboard` for å fullføre
+6. Avslutt etter statusvisning
 
 ## Ingen onboarding
 
-Hvis `org/`-mappen ikke finnes og ingen `--status`-flagg:
+Hvis `$ORG_DIR` er tom (ingen `.md`-filer) og ingen `--status`-flagg:
 
 Vis:
 ```
@@ -54,25 +75,54 @@ Prosessen tar ca. 5 minutter og dekker:
 3. Sikkerhet og compliance (dataklassifisering, residens)
 4. Arkitekturbeslutninger (plattform, integrasjoner, budsjett)
 5. Forretningsreferanser (styringsmodell, dokumentformat)
+6. Fri kontekst (valgfritt — alt annet du vil pluginen skal vite)
+7. Planlagt deteksjon (valgfritt — automatisk sjekk om kunnskapsbasen er oppdatert)
 ```
 
 Deretter start onboarding-agenten (se under).
 
 ## Start/gjenoppta onboarding
 
-Sjekk eksisterende `org/`-filer for å avgjøre resume-punkt:
+Sjekk eksisterende `$ORG_DIR/*.md`-filer for å avgjøre resume-punkt:
 
 ```
-Task(architect:onboarding-agent): "Read agents/onboarding-agent.md for your role and instructions.
+Task(ms-ai-architect:onboarding-agent): "
 
 Gjennomfør onboarding-intervju for å samle virksomhetsspesifikk kontekst.
 
+Datakatalog (absolutt, bruker-eid): <$ORG_DIR fra Datakatalog-steget>
 Eksisterende org-filer: [list files that exist, or 'ingen']
 
-Skriv resultater til org/-mappen under plugin-roten. Kjør alle 5 faser i rekkefølge,
-hopp over kategorier som allerede har completed: true."
+Skriv resultater til denne absolutte katalogen (IKKE plugin-roten). Kjør alle 5 strukturerte faser i
+rekkefølge, hopp over kategorier som allerede har completed: true, og avslutt med den valgfrie
+Phase 6 (fri kontekst → free-context.md) hvis den ikke allerede finnes."
 ```
 
+## Planlagt deteksjon (etter intervjuet — orkestratoren håndterer dette)
+
+Når intervju-agenten er ferdig, sett opp den **valgfrie** planlagte deteksjonen. Dette er en egen innstilling som onboarding skriver til bruker-configen, slik at brukeren slipper å hånd-redigere den gitignored fila. (Onboarding-agenten har ikke Bash og kan ikke gjøre dette selv — det er derfor orkestratorens jobb, med den gatede skrive-CLI-en.)
+
+1. **Spør om aktivering** (AskUserQuestion):
+   > «Vil du aktivere planlagt deteksjon? Da sjekker pluginen automatisk om Microsoft Learn-kunnskapsbasen har endret seg (poll → rapport → discovery), og varsler deg ved sesjonsstart. Den er Claude-fri og oppdaterer **aldri** kunnskapsbasen selv — du gjennomgår og kjører `/architect:kb-update` manuelt.»
+   - Alternativer: **Ja, aktiver** / **Nei, ikke nå** (opt-in — default er av).
+
+2. **Hvis Ja, spør om kadens** (AskUserQuestion):
+   > «Hvor ofte skal den lokale OS-planleggeren (launchd/cron, hvis du installerer den senere) kjøre deteksjon?»
+   - Alternativer: **Daglig (anbefalt)** → `daily` / **Følg intervallet** (`interval_days`, default 7 dager) → `interval`.
+
+3. **Skriv configen** via den gatede CLI-en (sikkerhetskopierer eksisterende config + atomisk skriving — aldri rå fs-write):
+
+   ```bash
+   # --enabled <true|false> fra steg 1, --cadence <daily|interval> fra steg 2 (daily hvis deaktivert)
+   node scripts/kb-update/write-schedule-config.mjs --enabled <true|false> --cadence <daily|interval>
+   ```
+
+   Skriptet skriver til `~/.claude/ms-ai-architect/ms-ai-architect.local.md` (bruker-eid, overlever reinstall) og bevarer `interval_days`/`include_skill_lifecycle` fra en evt. eksisterende config. Det skriver **aldri** til plugin-roten og kaller **aldri** Claude.
+
+4. **Rapportér kort:** bekreft valgt innstilling. Hvis aktivert: Tier 1 (SessionStart-hook) kjører deteksjon ved sesjonsstart når det er ≥ `interval_days` siden sist; for ekte bakgrunnskjøring mellom sesjoner kan brukeren installere OS-planleggeren senere (`node scripts/kb-update/scheduler.mjs install`, se `/architect:kb-update`).
+
+> **Hopp over hvis ikke onboarding-flyt:** kjøres `/architect:onboard --status`, ikke spør om scheduler — vis bare gjeldende innstilling (se Statussjekk).
+
 ## Etter fullført onboarding
 
 Vis oppsummering og foreslå neste steg:

commands/poc.md

@@ -29,7 +29,13 @@ Spør brukeren om nøkkelinformasjon (hvis ikke allerede kjent):
 
 ### 3. Les template
 
-Les `skills/ms-ai-advisor/references/architecture/poc-template.md` for komplett POC-rammeverk.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/poc-template.md` for komplett POC-rammeverk.
+
+### 3b. Les domene-spesifikke mønstre (betinget)
+
+Hvis use-caset treffer et engineering-domene, les 1-2 kjernefiler for å forankre scope og suksesskriterier (ikke hele katalogen):
+- **RAG / gjenfinning:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md` — sett målbare gjenfinnings-/grounding-kriterier
+- **MLOps / produksjonssetting:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/llm-evaluation-production.md` — POC-evaluering + driftskriterier
 
 ### 4. Generer POC-plan
 

commands/requirements.md

@@ -21,26 +21,31 @@ Du er Cosmo Skyberg, og skal kartlegge konkrete AI Act-krav for et AI-system bas
 Avklar:
 - Risikoklassifisering (kjør `/architect:classify` først om nødvendig)
 - Organisasjonens rolle (provider/deployer)
+- **Sektor** — offentlig, privat, finans, helse, etc. (default nøytral). For regulert privat sektor kartlegges sektorspesifikke krav i tillegg til AI Act. **Finans → DORA (2022/2554), Finanstilsynets IKT-forskrift, Finansforetaksloven, Verdipapirhandelloven** (se finans-sjekklisten i kunnskapsbasen).
 - Gjeldende praksis (hva er allerede på plass?)
 
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Kartlegg konkrete AI Act-forpliktelser (Fase 4-5) for følgende system:
 
 **System:** [systemnavn]
 **Risikonivå:** [klassifisering]
 **Rolle:** [provider/deployer]
+**Sektor:** [offentlig/privat/finans/helse/etc. — default nøytral]
 **Gjeldende praksis:** [hva som er på plass]
 **Kontekst:** [ytterligere kontekst]
 
 Modus: Requirements — fokus på forpliktelser og tiltaksplan.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md
+
+Betinget (kun ved regulert privat sektor):
+- Hvis sektor = finans: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md (§3 Finans — 17-punkts sjekkliste med DORA, Finanstilsynets IKT-forskrift, EBA/GL/2023/06). Kartlegg DORA-forpliktelser i tillegg til AI Act-kravene.
 
 Lever detaljert forpliktelsesliste med gap-analyse og tiltaksplan."
 ```

commands/research.md

@@ -22,7 +22,7 @@ Ekstraher:
 
 | Alias | Full navn |
 |-------|-----------|
-| Foundry, AIF | Azure AI Foundry |
+| Foundry, AIF | Microsoft Foundry |
 | CS | Copilot Studio |
 | M365, Copilot | M365 Copilot |
 | PP | Power Platform AI |
@@ -36,7 +36,7 @@ Ekstraher:
 Bruk Task-verktøyet til å lansere `research-agent`:
 
 ```
-Task(general-purpose): "Les agents/research-agent.md og utfør research.
+Task(ms-ai-architect:research-agent): "Utfør research.
 Plattform: [full plattformnavn]
 Tidsperiode: [periode]
 Fokusområder:

commands/review.md

@@ -1,6 +1,6 @@
 ---
 name: architect:review
-description: Kjør arkitekturgjennomgang mot norske offentlig sektor-krav
+description: Kjør arkitekturgjennomgang mot norske krav (offentlig sektor og privat/regulert sektor)
 argument-hint: "[arkitekturbeskrivelse eller kontekst]"
 allowed-tools: Read, Glob, Grep, Task, mcp__microsoft-learn__microsoft_docs_search, mcp__microsoft-learn__microsoft_docs_fetch
 model: opus
@@ -8,7 +8,7 @@ model: opus
 
 # /architect:review - Arkitekturgjennomgang
 
-Du er Cosmo Skyberg med fokus på arkitekturgjennomgang for norsk offentlig sektor. Gjennomfør en strukturert vurdering av arkitekturforslaget mot nasjonale krav, EU-reguleringer og Microsoft-plattform best practices.
+Du er Cosmo Skyberg med fokus på arkitekturgjennomgang. Gjennomfør en strukturert vurdering av arkitekturforslaget mot relevante norske sektorkrav, EU-reguleringer og Microsoft-plattform best practices. Default-spesialiseringen er offentlig sektor (Digdir, utredningsinstruksen, forvaltningsloven); for privat/regulert sektor (f.eks. finans) vektlegges DORA, Finanstilsynet og sektorspesifikke rammeverk i stedet — sektoren avledes fra konteksten.
 
 **VIKTIG:** Arkitekturgjennomganger krever grundighet. Alle 6 dimensjoner skal vurderes. Hopp aldri over en dimensjon.
 
@@ -35,6 +35,7 @@ Hvis input er vagt eller mangelfullt, still oppklarende spørsmål før du start
 Identifiser hvilke dimensjoner som er mest kritiske for scenarioet:
 - Borgerrettet tjeneste → Digdir-prinsipper + AI Act prioriteres
 - Automatiserte vedtak → Utredningsinstruksen + Forvaltningsloven prioriteres
+- Privat/regulert sektor (finans) → DORA + Finanstilsynet + sektor-sjekklister prioriteres (erstatter utredningsinstruksen/forvaltningsloven)
 - Sensitiv data → Sikkerhet + Schrems II prioriteres
 - Ny plattform → Microsoft-alignment + Kostnad prioriteres
 
@@ -43,16 +44,16 @@ Identifiser hvilke dimensjoner som er mest kritiske for scenarioet:
 Bruk Task-verktøyet til å lansere `architecture-review-agent`:
 
 ```
-Task(general-purpose): "Les agents/architecture-review-agent.md og utfør en
+Task(ms-ai-architect:architecture-review-agent): "Utfør en
 arkitekturgjennomgang for [løsningsnavn].
 Arkitekturbeskrivelse: [beskrivelse fra bruker]
 Kontekst: [offentlig sektor / sektor / stadium]
 Vurder alle 6 dimensjoner med 1-5 score.
 Les også:
-- skills/ms-ai-advisor/references/architecture/decision-trees.md
-- skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
-- skills/ms-ai-advisor/references/architecture/security.md
-- skills/ms-ai-advisor/references/architecture/ai-utredning-template.md"
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md"
 ```
 
 ### 4. Berik med arkitekturperspektiv

commands/ros.md

@@ -8,7 +8,7 @@ model: opus
 
 # ROS-analyse for AI-systemer
 
-Du er Cosmo Skyberg, og skal lede en strukturert ROS-analyse for et AI-system i norsk offentlig sektor.
+Du er Cosmo Skyberg, og skal lede en strukturert ROS-analyse for et AI-system. Metodikken (NS 5814 / ISO 31000) er sektor-agnostisk — default til en sektor-nøytral analyse og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, transport, industri, etc.). Sektor-sjekklister (inkl. finans: DORA, Finanstilsynet, Finansforetaksloven) aktiveres automatisk ved oppdaget sektor.
 
 ## Språk og encoding
 
@@ -33,7 +33,7 @@ Sjekk om --quick er angitt. Bruk samtalehistorikk hvis info allerede er gitt.
 Kjør ROS-agenten via Task for selve vurderingen:
 
 ```
-Task(ros-analysis-agent): "Read agents/ros-analysis-agent.md for your role and instructions.
+Task(ms-ai-architect:ros-analysis-agent): "
 Gjennomfør en [komplett / quick] ROS-analyse for følgende AI-system:
 
 **System:** [systemnavn]
@@ -43,14 +43,23 @@ Gjennomfør en [komplett / quick] ROS-analyse for følgende AI-system:
 **Sektor:** [sektor]
 **Borgermøtende:** [ja/nei]
 **Kontekst:** [ytterligere kontekst]
+**AI Act-klassifisering (dimensjon 6, fra /architect:classify):** [risikonivå + rolle — ellers "ikke klassifisert"]
+**DPIA-funn (fra /architect:dpia, hvis utført):** [sentrale personvernrisikoer — ellers "ikke utført"]
 [**Modus:** Quick (top-10 risikoer, trafikklys) — if --quick]
 
-Les kunnskapsbasene:
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md (hvis relevant sektor)
+Les kunnskapsbasene per last-kontrakten i agentfilen — kjerne (alltid) + betinget (kun på trigger):
+
+Kjerne (alltid, i rekkefølge):
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md
+
+Betinget (kun når triggeren utløses):
+- ros-sector-checklists.md (hvis relevant sektor oppdaget)
+- ros-maestro-multiagent.md (hvis multi-agent / agent-orkestrering)
+- ros-dpia-security-integration.md (hvis DPIA/sikkerhet skal integreres)
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md + ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md (hvis AI Act-dybde i dimensjon 6)
 
 Lever en [komplett ROS-rapport med alle 8 faser / Quick ROS med top-10 og trafikklys]."
 ```

commands/security.md

@@ -34,13 +34,13 @@ Identifiser hvilke sikkerhetsdimensjoner som er mest kritiske for scenarioet:
 Bruk Task-verktøyet til å lansere `security-assessment-agent`:
 
 ```
-Task(general-purpose): "Les agents/security-assessment-agent.md og utfør en
+Task(ms-ai-architect:security-assessment-agent): "Utfør en
 sikkerhetsassessment for [plattform] brukt til [scenario].
 Kontekst: [offentlig sektor / privat / etc.]
 Vurder alle 6 dimensjoner med 1-5 score.
-Les også: skills/ms-ai-advisor/references/architecture/security.md
-og skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
-og skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md"
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md"
 ```
 
 ### 4. Berik med arkitekturperspektiv

commands/summary.md

@@ -33,7 +33,7 @@ Hvis ingen vurderinger er gjennomført, informer brukeren om at summary krever m
 Kjør summary-agenten via Task:
 
 ```
-Task(general-purpose): "Read agents/summary-agent.md for your role and instructions.
+Task(ms-ai-architect:summary-agent): "
 Generer teknisk sammendrag og executive summary for:
 
 **Løsning:** [navn]

commands/transparency.md

@@ -27,7 +27,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Generer transparensnotiser for følgende AI-system:
 
 **System:** [systemnavn]
@@ -39,7 +39,7 @@ Generer transparensnotiser for følgende AI-system:
 Modus: Transparens — generer Art. 13/50 notiser.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
 
 Lever:
 1. Art. 50(1) AI-interaksjonsnotis (norsk)

commands/utredning.md

@@ -10,6 +10,8 @@ model: opus
 
 Du er Cosmo Skyberg i en strukturert utredningsrolle. Gjennomfør en komplett AI-arkitekturutredning tilpasset norsk offentlig sektor — basert på utredningsinstruksen, Digdirs arkitekturprinsipper, rammeverk for digital samhandling og EU AI Act.
 
+> **Sektor:** Utredningen er forankret i utredningsinstruksen, som gjelder statlige tiltak. For privat sektor — eller et sektor-nøytralt Solution Architecture Document (SAD) uten det offentlige stillaset — bruk `/architect:design`.
+
 **Arkitektur:** Fil-basert orkestrering. Agenter skriver output til `.work/`-filer. Orkestratoren leser fra filer, aldri fra TaskOutput. Kontekstvinduet holdes lett.
 
 ## Sessionskontekst
@@ -21,9 +23,9 @@ Hvis kommandoen kjøres etter `/architect` (Fase 1-3), gjenbruk innsamlet kontek
 ### 1. Last kontekst
 
 Les malen som styrer utredningen:
-- `skills/ms-ai-advisor/references/architecture/ai-utredning-template.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md`
 
-Aktiver Cosmo Skyberg-personaen fra `skills/ms-ai-advisor/SKILL.md`.
+Aktiver Cosmo Skyberg-personaen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`.
 
 ### 2. Parse input og bestem kompleksitet
 
@@ -113,7 +115,7 @@ Orkestratoren gjør alt selv. Ingen TeamCreate.
 4. Fullfør J, L→M, skriv til fil
 5. Kjør diagram-generation-agent for S8.2 (arkitekturoversikt):
    ```
-   Task(architect:diagram-generation-agent): "Generer arkitekturoversikt-diagram for {scenario}.
+   Task(ms-ai-architect:diagram-generation-agent): "Generer arkitekturoversikt-diagram for {scenario}.
    Komponenter: {fra S8.1}. Skriv til {output_dir}/.work/diagrams/architecture-overview.md"
    ```
 6. Kjør summary-agent (steg N) — les worker-mal nedenfor
@@ -204,15 +206,15 @@ Alle arbeidere spawnes med `Task` og skriver output til `.work/`-filer. Bruk `te
 
 #### Security Worker
 ```
-Task(architect:security-assessment-agent, name="security-worker", team_name="{team}"):
+Task(ms-ai-architect:security-assessment-agent, name="security-worker", team_name="{team}"):
 "Utfør sikkerhetsvurdering for: {scenario}
 Plattform: {plattform}
-Kontekst: Norsk offentlig sektor. {detaljer fra Fase 1}
+Kontekst: {sektor/virksomhet fra Fase 1}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md
-- skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md
-- skills/ms-ai-advisor/references/architecture/security.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/security.md med Write-verktøyet.
 Inkluder: Score-matrise (6 dimensjoner), P0/P1-funn, anbefalinger."
@@ -220,14 +222,14 @@ Inkluder: Score-matrise (6 dimensjoner), P0/P1-funn, anbefalinger."
 
 #### Cost Worker
 ```
-Task(architect:cost-estimation-agent, name="cost-worker", team_name="{team}"):
+Task(ms-ai-architect:cost-estimation-agent, name="cost-worker", team_name="{team}"):
 "Estimer kostnader for: {scenario}
 Plattform: {plattform}, Brukere: {antall}, Volum: {volum}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md
-- skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md
-- skills/ms-ai-advisor/references/architecture/cost-models.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/cost.md med Write-verktøyet.
 Inkluder: Månedskostnad, TCO 3 år, alle alternativer, konfidensgradering."
@@ -235,14 +237,14 @@ Inkluder: Månedskostnad, TCO 3 år, alle alternativer, konfidensgradering."
 
 #### DPIA Worker
 ```
-Task(architect:dpia-agent, name="dpia-worker", team_name="{team}"):
+Task(ms-ai-architect:dpia-agent, name="dpia-worker", team_name="{team}"):
 "Gjennomfør DPIA/PVK for: {scenario}
 Datatype: {datatype}, Behandlingsgrunnlag: {grunnlag}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
-- skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
-- skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/dpia.md med Write-verktøyet.
 Inkluder: Risikomatrise, tiltakstabell, bias/forklarbarhet/HITL-vurdering."
@@ -250,7 +252,7 @@ Inkluder: Risikomatrise, tiltakstabell, bias/forklarbarhet/HITL-vurdering."
 
 #### Diagram Worker
 ```
-Task(architect:diagram-generation-agent, name="diagram-worker", team_name="{team}"):
+Task(ms-ai-architect:diagram-generation-agent, name="diagram-worker", team_name="{team}"):
 "Generer diagrammer for: {scenario}
 Komponenter: {fra S8.1}
 
@@ -261,7 +263,7 @@ Diagrammer å generere:
 - Sikkerhetssoner (S5.1) — hvis sikkerhet er kritisk
 - Implementeringstidslinje (S9.1) — hvis faseplan er definert
 
-Les: skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
 
 VIKTIG: Skriv output til {output_dir}/.work/diagrams/ (én fil per diagram).
 Hvis mcp-image er utilgjengelig: generer Mermaid-syntaks som fallback."
@@ -269,7 +271,7 @@ Hvis mcp-image er utilgjengelig: generer Mermaid-syntaks som fallback."
 
 #### Summary Worker (kjøres ALLTID som siste agent)
 ```
-Task(architect:summary-agent, name="summary-worker"):
+Task(ms-ai-architect:summary-agent, name="summary-worker"):
 "Generer sammendrag for utredningen.
 
 Les utredningen: {output_dir}/utredning.md

commands/vendor.md

@@ -0,0 +1,81 @@
+---
+name: architect:vendor
+description: Tredjeparts-/SaaS-leverandørvurdering (due diligence) — dataresidens, sub-prosessorer, DPA, Schrems II, AI Act-deployerforpliktelser
+argument-hint: "[leverandør/tjeneste] for [bruksscenario]"
+allowed-tools: Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search
+model: opus
+---
+
+# /architect:vendor - Leverandørvurdering (tredjepart/SaaS due diligence)
+
+Du er Cosmo Skyberg i en due-diligence-rolle. Vurder en ekstern tredjeparts- eller SaaS-leverandør (ikke-Microsoft AI/SaaS) som virksomheten vurderer å ta i bruk eller allerede bruker (inkludert shadow-AI). Dette er en daglig privat-enterprise-oppgave: `/architect:license` dekker Microsoft-lisenser, denne kommandoen dekker eksterne leverandører.
+
+> **Sektor:** Sektor-nøytral. Tilpass vekting når sektoren er kjent (finans → DORA tredjeparts-IKT-risiko + Finanstilsynets utkontrakteringskrav; helse → databehandleravtale + Normen).
+
+## Språk og encoding
+
+**VIKTIG:** Bruk norske tegn (æ, ø, å) korrekt i all output. Norsk prosa, engelske fagtermer der naturlig.
+
+## Instruksjoner
+
+### 1. Parse input
+
+Ekstraher:
+- **Leverandør/tjeneste** — hvilken ekstern løsning vurderes
+- **Bruksscenario** — hva den skal brukes til
+- **Sektor/kontekst** — default nøytral
+
+### 2. Samle kontekst
+
+Avklar hvis ikke kjent:
+- **Datatyper** — hvilke data flyter til leverandøren? Personopplysninger? Særlige kategorier? Forretningskritisk?
+- **Driftsmodell** — SaaS (multi-tenant), dedikert, hybrid, on-prem
+- **AI-komponent** — er tjenesten et AI-system? Trener den på kundedata? (utløser AI Act-deployervurdering)
+- **Kritikalitet** — hvor avhengig blir virksomheten (DORA: kritisk vs. viktig funksjon)
+
+### 3. Les kunnskapsbasene
+
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` — Schrems II, EDPB seks-stegs-TIA, CLOUD Act/FISA 702-restanalyse for tredjelandsoverføring
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — deployerforpliktelser hvis leverandøren leverer et AI-system
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetskrav til eksterne tjenester
+
+For personvern-/cross-border-dybde: deleger til `/architect:dpia` (full TIA). For anskaffelseskrav: `/architect:anskaffelse`.
+
+### 4. Bygg leverandørvurderingen
+
+Strukturér i syv områder med funn og status (🟢/🟡/🔴):
+
+1. **Leverandørprofil** — selskap, eierskap, jurisdiksjon, morselskap (USA-eierskap → CLOUD Act-eksponering uavhengig av lagringssted)
+2. **Dataresidens og dataflyt** — hvor lagres og prosesseres data? Sub-prosessorer (liste + jurisdiksjoner)? Support-tilgang fra tredjeland?
+3. **Personvern** — databehandleravtale (GDPR art. 28), behandlingsgrunnlag, sub-prosessor-godkjenning, sletting/portabilitet. Ved tredjelandsoverføring: overføringsgrunnlag + EDPB seks-stegs-TIA (henvis `/architect:dpia`)
+4. **Sikkerhet** — sertifiseringer (ISO 27001, SOC 2 Type II), kryptering (i ro/transitt), pentest/sårbarhetshåndtering, hendelsesvarsling, tilgangsstyring
+5. **AI Act-implikasjoner** — er leverandøren provider av AI? Blir virksomheten deployer? GPAI? Transparenskrav (Art. 50). Kontraktsfest provider-dokumentasjon
+6. **Kontrakt og exit** — SLA, oppetid, ansvar, vendor lock-in, dataportabilitet, oppsigelse, dataretur/sletting ved exit
+7. **Risiko og samlet vurdering** — go / betinget go / no-go, med kritiske betingelser
+
+**Beslutningsmatrise:**
+
+| Område | Status | Kritiske funn | Tiltak før kontrakt |
+|--------|--------|---------------|---------------------|
+| Dataresidens | 🟢/🟡/🔴 | ... | ... |
+| Personvern (DPA) | 🟢/🟡/🔴 | ... | ... |
+| Sikkerhet | 🟢/🟡/🔴 | ... | ... |
+| AI Act | 🟢/🟡/🔴 | ... | ... |
+| Exit/lock-in | 🟢/🟡/🔴 | ... | ... |
+
+### 5. Lever
+
+Tilby:
+- Skriv til fil (foreslå `docs/vendor/VENDOR-[slug].md`)
+- `/architect:dpia` — full personvern- og cross-border-TIA før kontrakt
+- `/architect:anskaffelse` — formelle anskaffelseskrav og tildelingskriterier
+- `/architect:security` — dypere sikkerhetsvurdering av integrasjonen
+- `/architect:adr` — dokumentér leverandørbeslutningen
+
+## Retningslinjer
+
+- USA-eid leverandør = CLOUD Act-eksponering selv ved EU-lagring — flagg eksplisitt
+- Skill mellom kontraktsfestede garantier og markedsføringspåstander — krev dokumentasjon
+- Shadow-AI: vurder tjenester som allerede er i bruk uten godkjenning med samme strenghet
+- Ingen salgsspråk; etterprøvbart beslutningsgrunnlag
+- Marker tydelig hva som er verifisert (kontrakt/sertifikat) vs. antatt

docs/c3-course-detection-plan.md

@@ -0,0 +1,252 @@
+# C3 — Kurs-deteksjon via Learn Platform API (spec)
+
+_Spec for krav 3 (kurs-deteksjon). Skrevet 2026-06-23 (Sesjon 30) på det verifiserte grunnlaget i [`c3-course-detection-spike.md`](c3-course-detection-spike.md). **Status: GODKJENT (S31).** De fire åpne beslutningene i §8 er delegert til arkitekt av operatør (mandat: «profesjonell plugin, til å stole på») og besluttet — to med skjerpende robusthets-/korrekthetskrav (§8 (a) fetch-kontrakt, §8 (c) full-enum-pin). C3.1 er klarert til oppstart. Stier relative til plugin-rot._
+
+---
+
+## 0. Mål og avgrensning
+
+**Mål:** Oppdage at Microsoft har publisert **nye** eller **endrede** treningskurs (modules + learning paths) innenfor de produktene KB-en dekker, slik at operatøren kan vurdere om temaet bør dekkes i kunnskapsbasen.
+
+**Ikke-mål (eksplisitt):**
+- **IKKE auto-ingest** av kursinnhold som KB-filer. Et kurs er et *signal* om at et tema finnes — ikke en doc-side som transformeres. (Spike §29: «oppdage … som bør dekkes», ikke ingest.)
+- **IKKE** å erstatte den eksisterende sitemap-baserte doc-discovery (`discover-new-urls.mjs`). C3 er et parallelt, uavhengig spor på en helt annen datakilde (Platform API, ikke sitemaps).
+- **IKKE** å skrive til KB (`skills/`) eller til `decisions.json` fra detektoren. Se §2 (arkitektur-invariant).
+
+**Datakilde (besluttet S29):** Microsoft Learn **Platform API** (`/api/v1`, Entra ID app-only). IKKE legacy `/api/catalog/` (anonym, deprekeres «starting June 2026»), IKKE microsoft-learn-MCP (docs-only, ingen dato/produkt-filter). Begrunnelse i spike §6.
+
+---
+
+## 1. Verifisert API-grunnlag (kort — full versjon i spike)
+
+Alt under er **empirisk verifisert** i S29 (spike §14–§26):
+
+- **Base:** `https://learn.microsoft.com/api/v1` · påkrevd query `?api-version=2023-11-01-preview` (kun preview finnes).
+- **Auth:** Entra client-credentials → bearer-token, scope `https://learn.microsoft.com/.default`. Token-endepunkt er standard Entra v2.0: `https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token` (tenant-id, client-id, client-secret hentes fra Keychain — se §3). Verifisert: token → HTTP 200 mot `/api/v1/modules`.
+- **Endepunkter (per-type, ikke kombinert):** `/api/v1/modules` ✅, `/api/v1/learning-paths` ✅ (**kebab-case**). `/api/v1/products` finnes IKKE (404).
+- **Paginering:** respons `{"value":[…], "nextLink":…}` — cursor via `nextLink`; `maxpagesize` ≤ 100 (default 30).
+- **Felt vi bruker:** `id` (UID — stabil nøkkel), `title`, `updatedAt` (ISO 8601), `products[].id`, `url`. Learning path: samme + `modules[]`.
+- **Filter:** flere params = AND; komma-separert i én param = OR. Produkt-filter virker **server-side** (`products=azure-openai` → 34 treff = ekte filtrering).
+
+### To gotchas spec-en pinner (verifisert empirisk — MÅ håndteres i kode)
+1. **`updatedAt.gt` krever full ISO 8601 datetime.** `updatedAt.gt=2026-01-01T00:00:00Z` → virker. Dato-only `updatedAt.gt=2026-01-01` → **fail-closed (0 treff)**, selv om doc-eksempelet viser dato-only. Currency-cursoren må alltid serialiseres som full ISO med `Z`.
+2. **Produkt-slugs må enumereres fra live data.** Doc-eksempelet `azure-ai-foundry` → 0 treff (død slug). Ekte slugs samles ved å paginere moduler og hente distinct `products[].id` (siden `/api/v1/products` ikke finnes). `azure-openai` (34) bekreftet levende.
+3. **Locale:** bruk `en-us` som primær (`nb-no` faller tilbake til en-us-metadata der oversettelse mangler).
+
+---
+
+## 2. Arkitektur-invariant (binding — gjelder C3 uendret)
+
+Eksisterende kode håndhever at **deteksjon aldri skriver `decisions.json` eller `skills/`** — kun via operatør-gate. Dette er ikke en konvensjon men en *testet* invariant:
+
+- `discover-new-urls.mjs:12-14` importerer kun `loadDecisions, isDecided` — aldri `saveDecisions`. Håndhevet av `tests/kb-update/test-discover-invariant.test.mjs` (grepper import-linjene, `assert.doesNotMatch` på `saveDecisions`/`atomic-write`/`backup`).
+- `run-detection.mjs` kjører kun `execFileSync('node', …)` på allow-listede steg — kan strukturelt aldri spawne `claude` (Claude-fri ToS-flate, `detection-schedule.mjs:1-9`).
+
+**C3 følger samme to-stegs-mønster som `discover-new-urls`:**
+
+```
+STEG 1 (Claude-fri, planlagt — detektoren)        STEG 2 (operatør-gated, Claude-i-loop — gaten)
+─────────────────────────────────────────        ───────────────────────────────────────────────
+detect-courses.mjs                                /architect:kb-update (utvidet seksjon)
+  • leser Keychain-creds                            • leser course-detection-report.json
+  • token → paginer API (produkt + updatedAt.gt)    • presenterer nye/endrede kurs for operatør
+  • diff mot course-registry.json                   • operatør approve/reject
+  • SKRIVER:                                         • SKRIVER leads til decisions.json (courses-koll.)
+      - course-detection-report.json (kandidater)      via recordCourseLead + saveDecisions
+      - course-registry.json (egen diff-state)
+  • IMPORTERER ALDRI saveDecisions
+```
+
+`course-registry.json` er **detektorens egen sporings-state** (diff-baseline), på samme måte som `url-registry.json` skrives av `poll-sitemaps.mjs`. Det er hverken KB eller `decisions.json` → å skrive det bryter ikke invarianten. (Eksplisitt: invarianten forbyr skriving til `skills/` og til gatens `decisions.json` — ikke detektorens private state.)
+
+---
+
+## 3. Hemmelighets-håndtering (Keychain, Claude-fri)
+
+Detektoren leser de tre creds **direkte fra macOS Keychain ved kjøretid** — aldri fra repo eller env (strengere enn `~/.zshenv`-mønster; spike §12).
+
+```js
+// lib/keychain.mjs (NY) — fail-soft: returnerer null hvis item mangler.
+import { execFileSync } from 'node:child_process';
+export function readSecret(service, account = 'ktg') {
+  try {
+    return execFileSync('security',
+      ['find-generic-password', '-s', service, '-a', account, '-w'],
+      { encoding: 'utf8' }).trim();
+  } catch { return null; } // item mangler / ikke macOS → caller fail-softer
+}
+```
+
+Items (account `ktg`, satt opp S29): `learn-platform-client-secret`, `learn-platform-tenant-id`, `learn-platform-client-id`. Client-secret utløper ~2028-06 (eneste vedlikeholdspunkt).
+
+**Fail-soft-kontrakt:** mangler én av de tre creds, skal `detect-courses.mjs` logge årsak, skrive en *skipped*-rapport og **exit 0** — aldri kræsje deteksjons-pipelinen for en bruker som ikke har satt opp Platform API. (Begrunnelse: C3 er opt-in; en bruker uten Entra-app skal ikke få en rød pipeline.)
+
+> **Merk (literal-IDer):** tenant-id/client-id/secret skal ALDRI committes — heller ikke i denne spec-en, test-fixtures eller logger. Tester injiserer falske creds via en stub.
+
+---
+
+## 4. Data-design
+
+### 4.1 `data/course-registry.json` — detektorens diff-state (NY)
+
+Detektorens private «known-UID»-register. Skrives av detektoren, lest ved neste kjøring. Mønster = `url-registry.json` (atomisk skriving via `registry-io`-stil).
+
+```jsonc
+{
+  "version": 1,
+  "created_at": "2026-06-23T12:00:00Z",
+  "last_run": "2026-06-23T12:00:00Z",        // FULL ISO — cursor for updatedAt.gt neste kjøring (gotcha #1)
+  "last_full_enum": "2026-06-23T12:00:00Z",  // FULL ISO — siste full enumerering (uten updatedAt.gt). Styrer removed-beregning (§4.2) + full-enum-kadens (≥30 d)
+  "courses": {
+    "<module-or-path-uid>": {
+      "type": "module",                  // "module" | "learning-path"
+      "title": "...",
+      "url": "https://learn.microsoft.com/training/modules/...",
+      "products": ["azure-openai"],
+      "updated_at": "2026-06-20T08:00:00Z",  // kursets updatedAt sist sett
+      "first_seen": "2026-06-23T12:00:00Z",
+      "last_seen": "2026-06-23T12:00:00Z"
+    }
+  }
+}
+```
+
+- **Første kjøring** (ingen `last_run`): full paginering uten `updatedAt.gt` → etablerer baseline, setter `last_run = now` **og `last_full_enum = now`**. Ingen leads emitteres på baseline-kjøringen (alt er «kjent» fra start). _Besluttet: §8 (b)._
+- **Inkrementelle kjøringer** (normalfall): `updatedAt.gt=<last_run>` henter kun endrede; diff klassifiserer new/updated. **`removed` beregnes IKKE her** (et `updatedAt.gt`-filtrert svar utelater alt uendret → naiv removed-diff ville falskt flagge nesten hele registeret; se §4.2). `last_run = now`.
+- **Periodisk full enumerering** (når `last_full_enum` mangler eller er eldre enn 30 d): full paginering uten `updatedAt.gt` → diff gir new/updated **+ removed** (full API-sett vs. register). Setter `last_run = now` og `last_full_enum = now`. Dette er den eneste kjøringstypen som kan oppdage retirerte kurs.
+
+### 4.2 Diff-semantikk (spike §24)
+- **ny UID** (i API, ikke i register) → lead `kind: "new"`.
+- **endret `updatedAt`** (UID i begge, nyere timestamp) → lead `kind: "updated"`.
+- **forsvunnet UID** (i register, ikke i API-svar) → `kind: "removed"`. Behandles som **informasjonssignal i rapporten**, IKKE som ledger-lead (et retirert kurs er ikke et «tema å dekke»). **Korrekthets-pin (besluttet §8 (c)):** `removed` beregnes KUN på full-enumereringskjøringer (§4.1) — aldri på inkrementelle `updatedAt.gt`-kjøringer, der «ikke i svar» er sant for alt uendret og ville gi massiv falsk-positiv flom. Inkrementelle kjøringer setter `removed: []`.
+
+### 4.3 `data/course-detection-report.json` — STEG 1-output (NY)
+Analogt med `discovery-report.json`:
+
+```jsonc
+{
+  "generated_at": "2026-06-23T12:00:00Z",
+  "status": "ok",                  // "ok" | "skipped" (creds mangler) | "error"
+  "skipped_reason": null,
+  "new": [ { "uid", "title", "url", "products", "suggested_skill", "suggested_category", "updated_at" } ],
+  "updated": [ /* samme form */ ],
+  "removed": [ { "uid", "title", "url" } ],
+  "counts": { "new": 0, "updated": 0, "removed": 0 }
+}
+```
+
+### 4.4 Produkt-slug→skill-mapping — config i `domain-taxonomy.json` (UTVIDELSE)
+Mappingen er **config, ikke hardkoding** (spike §30). Den hører hjemme i lag-0-taksonomien, som er den bevisst konsoliderte ene sannhetskilden (`domain-taxonomy.json`-provenance: «Consolidates four previously-divergent taxonomies into one»). Ny topp-nivå-seksjon:
+
+```jsonc
+"course_products": {
+  "azure-openai":              { "skill": "ms-ai-engineering", "category": "azure-ai-services" },
+  "microsoft-copilot-studio":  { "skill": "ms-ai-advisor",     "category": "platforms" },
+  "power-automate":            { "skill": "ms-ai-advisor",     "category": "platforms" },
+  "ai-builder":                { "skill": "ms-ai-advisor",     "category": "platforms" }
+  // … finaliseres i C3.3 fra enumererte live-slugs (gotcha #2)
+}
+```
+
+Ny accessor i `taxonomy.mjs`: `makeCourseClassifier(tax)` → `(products[]) => {skill, category} | null` (første in-domain produkt vinner; ukjent slug → null = ikke in-domain → ikke lead). Speiler `makeClassifier`.
+
+### 4.5 Ledger-utvidelse — `courses`-kolleksjon i `decisions.json` (STEG 2)
+`decisions.json` har i dag to parallelle kolleksjoner: `decisions` (URL-nøklet, Spor A) og `actions` (skill-nøklet, Spor B). Kurs er en **tredje entitetstype** (UID-nøklet) → får en **tredje kolleksjon**, additivt:
+
+```jsonc
+{
+  "version": 1, "updated_at": null,
+  "decisions": { /* url-keyed, uendret */ },
+  "actions":   { /* skill-keyed, uendret */ },
+  "courses": {                              // NY — uid-keyed
+    "<uid>": {
+      "kind": "new",                        // "new" | "updated"
+      "status": "pending",                  // pending | approved | rejected (dedup-policy A)
+      "title": "...", "url": "...", "products": ["azure-openai"],
+      "suggested_skill": "ms-ai-engineering",
+      "updated_at": "2026-06-20T08:00:00Z",
+      "detected_at": "2026-06-23T12:00:00Z",
+      "decided_at": null, "note": ""
+    }
+  }
+}
+```
+
+Nye **rene** helpers i `decisions-io.mjs` (speiler `recordAction`/`setActionStatus`/`isActionDecided`):
+`recordCourseLead(ledger, uid, lead)`, `setCourseLeadStatus(ledger, uid, status, decided_at)`, `isCourseLeadDecided(ledger, uid)`. `createLedger()` får `courses: {}`; `loadDecisions` defaulter `ledger.courses ??= {}` (bakoverkompatibelt med eksisterende ledgere uten feltet).
+
+**Hvorfor egen kolleksjon, ikke gjenbruk av `decisions` (URL-nøklet)?** Et godkjent kurs-lead må ALDRI havne i doc-transform-pipelinen (fetch→transform→KB-fil) — det ville være auto-ingest, som er eksplisitt ikke-mål. En egen `courses`-kolleksjon holder kurs-leads strukturelt utenfor `decisions`-strømmen som apply-pathen leser. Dedup er per UID (stabil nøkkel; URL kan endres). _Alternativ vurdert og forkastet: gjenbruke `decisions` med en `source`-diskriminator + skip i apply-path — mer kobling, høyere risiko for utilsiktet ingest._
+
+---
+
+## 5. Scheduler-integrasjon (Claude-fri, opt-in)
+
+Nytt steg i den frosne `DETECTION_STEPS` (`detection-schedule.mjs:36-41`), gated av et nytt flagg — speiler `skillLifecycle`-mønsteret:
+
+```js
+{ name: 'detect-courses', dir: 'kb-update', script: 'detect-courses.mjs', args: [], courseDetection: true },
+```
+
+`run-detection.mjs` filtrerer steget bort når `config.include_course_detection !== true` (samme `filter`-linje som i dag bruker `include_skill_lifecycle`).
+
+Ny config-nøkkel `include_course_detection` i `DEFAULT_SCHEDULE_CONFIG` — **default `false`** (krever Keychain-creds som ikke alle har; opt-in inni opt-in). Plumbing additivt: `coerce()` får en boolean-gren, `serializeScheduleConfig` får linjen, K5 round-trip-testen utvides. (Eier-CLI `write-schedule-config.mjs` kan senere eksponere et `--courses`-flagg; ikke nødvendig for MVP — operatør kan sette nøkkelen manuelt i `~/.claude/ms-ai-architect/ms-ai-architect.local.md`.)
+
+---
+
+## 6. Network-klient (`lib/learn-api.mjs`, NY)
+
+Claude-fri nettverkslag (skriver ingen filer). Eksisterende HTTP-mønster er `node:https.get` med retry (`sitemap-stream.mjs`), men det håndterer ikke bearer-token/JSON/POST. C3-klienten bruker **native `fetch`** (innebygd og global i Node 25 → null ny avhengighet, holder zero-dependency-konvensjonen). _Besluttet: §8 (a)._
+
+**Robusthetskontrakt (binding — skiller «funker» fra «profesjonell», testes i C3.1):** rå `fetch` har to fallgruver som wrapperen MÅ lukke:
+1. **`fetch` kaster ikke på HTTP 4xx/5xx** (kun på nettverksfeil) → wrapperen sjekker `response.ok` eksplisitt og behandler ikke-ok som feil.
+2. **`fetch` har ingen default timeout** → hver request får `AbortSignal.timeout(<ms>)`.
+
+Retry-policy: 3 forsøk på `429` + `5xx` med backoff som **respekterer `Retry-After`-headeren** (Microsofts API rate-limiter; fast backoff ellers). 4xx ≠ 429 (f.eks. 401/403) er **ikke** retrybart → caster umiddelbart. **Fail-closed** på vedvarende feil (caster opp så `detect-courses` fail-softer til `error`-rapport + exit 0). Token hentes ÉN gang per kjøring (client-credentials-token varer ~1 t) og gjenbrukes på tvers av paginering.
+
+Eksporterte funksjoner (skisse):
+```js
+export async function getToken({ tenantId, clientId, clientSecret })   // client-credentials → bearer
+export async function* paginate(endpoint, params, token)               // yield items via nextLink
+// endpoint ∈ {'modules','learning-paths'}; params bygger ?api-version + products + updatedAt.gt
+export function buildUpdatedAtGt(iso)   // PIN: full ISO m/ Z (gotcha #1) — kaster på dato-only input
+```
+
+---
+
+## 7. Faseplan med verifiserbare kriterier
+
+Hver fase = ÉN økt, TDD (Iron Law: failing test først), gated på kjørbart kriterium før neste. Subagenter committer aldri; validate før commit.
+
+| Fase | Leveranse | Verifiserbart gate-kriterium (kjørbart) |
+|------|-----------|------------------------------------------|
+| **0** ✅ | Auth-oppsett + API-kartlegging | FERDIG (S29). Token → 200 verifisert. |
+| **C3.1** | `lib/keychain.mjs` + `lib/learn-api.mjs` (token, paginer, filter-bygging) | `node --test tests/kb-update/test-learn-api.test.mjs` grønn: token-body-bygging, `buildUpdatedAtGt` kaster på dato-only + emitterer full ISO, nextLink-paginering, produkt-param. **Robusthetskontrakt (§6, besluttet §8 (a)):** test at ikke-ok HTTP-status (404/500, stub) kaster (ikke svelges), at 429 retries og respekterer `Retry-After`, at 4xx≠429 ikke retries, og at timeout (`AbortSignal`) caster. **Claude-fri-invariant-test** grønn (ingen `claude`/`anthropic` i fila). **Manuell live-probe** (utenfor CI): henter ≥1 modul med ekte creds. |
+| **C3.2** | `lib/course-diff.mjs` (ren) + `course-registry.json`-schema (m/ `last_full_enum`) + load/save | `test-course-diff.test.mjs` grønn: new/updated/no-op + tom-baseline. **Full-enum-pin (besluttet §8 (c)):** test at `removed` KUN emitteres på full-enum-modus, at inkrementell modus gir `removed: []` selv når register-UIDs mangler i (filtrert) svar, og at full-enum trigges når `last_full_enum` mangler/er >30 d. Round-trip persistens-test. Diff-modulen er **ren** (invariant-test: ingen write-util-import). |
+| **C3.3** | `course_products` i `domain-taxonomy.json` (slugs enumerert fra live data) + `makeCourseClassifier` | `test-taxonomy.test.mjs` utvidet grønn: in-domain slug → skill, ukjent → null. Enumererings-kjøring dokumentert i commit (distinct `products[].id` ∩ in-domain). refTall/K-counts uendret (`eval --json`). |
+| **C3.4** | `detect-courses.mjs` (binder C3.1–C3.3) + DETECTION_STEPS-steg + config-nøkkel | **Invariant-test** (`test-detect-courses-invariant`): ingen `saveDecisions`-import. **Fail-soft-test**: creds=null → `status:"skipped"` + exit 0. Report-shape-test. DETECTION_STEPS-filter-test (`include_course_detection:false` ⇒ steg droppet). Hele `tests/kb-update/*.test.mjs` fortsatt grønn (213+). |
+| **C3.5** | `courses`-kolleksjon i `decisions-io.mjs` + `/architect:kb-update`-gate-seksjon | `test-decisions-io`/`test-decisions-actions` utvidet grønn: `recordCourseLead`/`setCourseLeadStatus`/`isCourseLeadDecided` + dedup-policy-A per UID + bakoverkompat (ledger uten `courses`). Eksisterende ledger-tester urørt grønn. Kommando-dry-run viser leads, **ingen** transform/ingest trigges. |
+| **C3.6** | SessionStart-surfacing + docs (`development.md`, `CLAUDE.md`) + STATE | `summarizeCourses`-enhetstest (one-liner «N nye/M endrede kurs i dekkede produkter»). `docs/development.md` beskriver C3-workflow. CLAUDE.md kommando-/hook-tabell oppdatert. |
+
+---
+
+## 8. Besluttede valg (delegert til arkitekt, S31)
+
+Operatøren kunne ikke ta disse selv og delegerte dem med mandatet «profesjonell plugin, til å stole på». Alle fire besluttet. (a) og (c) ble skjerpet utover opprinnelig anbefaling fordi kvalitetsmandatet krever det.
+
+**(a) HTTP-klient → `fetch` MED robusthetskontrakt. BESLUTTET.** `fetch` (innebygd i Node 25, null ny avhengighet, riktig for bearer+JSON+POST). Skjerpelse: kontrakten i §6 er binding — eksplisitt `response.ok`-sjekk (fetch kaster ikke på 4xx/5xx), `AbortSignal.timeout()`, retry på 429/5xx som respekterer `Retry-After`. Uten denne kontrakten ville en 429 feiltolkes som tom respons. _Forkastet: rått `fetch` uten kontrakt, og å speile `node:https.get` (dekker ikke POST/bearer)._
+
+**(b) Baseline-kjøring emitterer ingen leads. BESLUTTET.** Første kjøring etablerer kun registeret. Begrunnelse: en flom av N hundre «nye» kurs dag 1 lærer operatøren at verktøyet er støy, ikke signal — det motsatte av «til å stole på». _Full backlog → fremtidig eksplisitt `--backfill`/audit-modus (roadmap, ikke MVP). Forkastet for MVP: behandle hele baseline som `new`-leads._
+
+**(c) `removed` = kun rapport-signal, MED korrekthets-pin. BESLUTTET.** Informasjonslinje i rapporten, ikke ledger-lead. Skjerpelse (binding, §4.1/§4.2): `removed` beregnes KUN på full-enumereringskjøringer — aldri inkrementelt, der en `updatedAt.gt`-diff ville falskt flagge nesten hele registeret som removed. Dette er en tillitskritisk korrekthetsregel, ikke bare en preferanse. _Forkastet: emittere removed som lead (et retirert kurs er ikke et tema å dekke); og naiv removed-diff på inkrementelle kjøringer (falsk-positiv flom)._
+
+**(d) `include_course_detection` default `false`. BESLUTTET.** Opt-in. Funksjonen krever Entra-creds nesten ingen har; default `true` ville gitt hver bruker et rødt/«skipped» steg. _Forkastet: default `true`._
+
+---
+
+## 9. Verifiseringskilder
+
+- **Verifisert empirisk (S29):** [`c3-course-detection-spike.md`](c3-course-detection-spike.md) — auth grønn, API-kontrakt, gotchas, live-probe.
+- **Verifisert mot kode (S30, denne spec-en):** `detection-schedule.mjs:22-41` (DEFAULT_SCHEDULE_CONFIG, DETECTION_STEPS, coerce), `discover-new-urls.mjs:12-14,100-108` (to-stegs + read-only-invariant + report-form), `registry-migrate.mjs:51-57` (reservert `course`-felt allerede i registry-schema — C3-krok), `domain-taxonomy.json` (lag-0-konsolidering, `category_skill`-form), `decisions-io.mjs` (decisions/actions-kolleksjoner, dedup-policy A).
+- **Standard (ikke prosjekt-spesifikt):** Entra v2.0 client-credentials token-endepunkt `login.microsoftonline.com/<tenant>/oauth2/v2.0/token` — konsistent med verifisert auth i spike (tenant-id i Keychain, scope `.default`).
+- **Ikke verifisert (flagget):** ekte produkt-slug for Azure AI Foundry (enumereres i C3.3).
+- **Løst ved design (S31, §8 (c)):** `removed`-deteksjonens fullstendighet ved server-side `updatedAt.gt`-filter. Forsvunne UIDs vises ikke i et filtrert svar → `removed` beregnes utelukkende på periodiske full-enumereringskjøringer (`last_full_enum`-kadens, §4.1/§4.2), aldri inkrementelt. Inkrementelle kjøringer setter `removed: []`.

docs/c3-course-detection-spike.md

@@ -0,0 +1,35 @@
+# C3 Spike — Learn Platform API for kurs-deteksjon (Fase 0)
+
+_Verifisert grunnlag for C3-spec-en. Skrevet 2026-06-23 (Sesjon 29). **Fase 0 = FERDIG** (auth-oppsett + full API-kartlegging). Neste økt: skrive `docs/c3-course-detection-plan.md` på dette grunnlaget. Ingen detektor-kode før spec er godkjent._
+
+## Beslutning (operatør, S29)
+Kurs-deteksjon (krav 3) bygges på **Microsoft Learn Platform API** (`/api/v1`, Entra ID app-only) — IKKE legacy `/api/catalog/` (anonym, deprekeres «starting June 2026») og IKKE microsoft-learn-MCP (docs-only, ingen dato/produkt-filter). MCP er feil verktøy; Platform API er future-proof. Begrunnelse: kunnskapskjernen skal stå på egne ben.
+
+## Oppsett — FERDIG (engangs, operatørens private miljø)
+- Entra-app `ms-ai-architect-learn-catalog` registrert i operatørens **private** Entra-tenant (single-tenant, ingen redirect-URI, **ingen API-tillatelser** — offentlig innhold krever ingen app-rolle; bekreftet ved at token virker uten).
+- **Hemmeligheter i macOS Keychain** (account `ktg`): `learn-platform-client-secret` (utløp **~2028-06**, 24 mnd — eneste vedlikeholdspunkt), `learn-platform-tenant-id`, `learn-platform-client-id`. Aldri i repo/env. (Literal-IDer bevisst ikke i committet doc.)
+- Auth verifisert grønn: client-credentials → token (scope `https://learn.microsoft.com/.default`) → HTTP 200 mot `/api/v1/modules`.
+- **Detektoren leser creds rett fra Keychain ved kjøretid** (`security find-generic-password`) — ingen `~/.zshenv`/env-eksponering (strengere). Mønster bevist i efemert `/private/tmp/claude-learn-api-verify.sh` (slettes; reproduserbart).
+
+## Verifisert API-kontrakt
+- **Base:** `https://learn.microsoft.com/api/v1` · **påkrevd:** `?api-version=2023-11-01-preview` (kun preview-versjon finnes; kortere støttesyklus).
+- **Per-type endepunkter** (ikke ett kombinert katalog-svar): `/api/v1/modules` ✅, `/api/v1/learning-paths` ✅ (**kebab-case**, ikke camelCase). `/api/v1/products`-taksonomi finnes IKKE (404).
+- **Respons:** `{"value":[…], "nextLink":…}` — cursor-paginering via `nextLink`; `maxpagesize` ≤ 100 (default 30).
+- **Modul-felt:** `id` (UID, stabil nøkkel), `title`, `updatedAt` (ISO 8601), `products[].id`, `roles[]`, `levels[]`, `subjects[]`, `units[]`, `url`, `summary`, `durationInMinutes`. Learning path: samme + `modules[]`.
+- **Filter-semantikk:** flere params = AND; komma-separerte verdier i én param = OR. Produkt-filter virker **server-side** (`products=azure-openai` → 34 treff = ekte filtrering, ikke ignorert).
+
+## Gotchas (MÅ håndteres i spec/kode — verifisert empirisk)
+1. **`updatedAt.gt` krever FULL ISO 8601 datetime.** `updatedAt.gt=2026-01-01T00:00:00Z` → virker (100). Dato-only `updatedAt.gt=2026-01-01` → **fail-closed (0 treff)**, til tross for at doc-eksempelet bruker dato-only. Dette er hjertet i currency-deteksjonen — pin formatet.
+2. **Produkt-slugs må enumereres fra live data.** Doc-eksempelet `azure-ai-foundry` → **0** (ikke en levende module-slug). Funnet i domenet (delvis, fra første 100 moduler): `ai-builder, microsoft-copilot-studio, ms-copilot, agent-365, power-automate, power-platform, power-apps, power-pages` + `azure-openai` (34 via filter). Siden `/api/v1/products` ikke finnes: enumerér ved å paginere alle moduler og samle distinct `products[].id`, eller finn et taksonomi-endepunkt.
+3. **Deteksjonslogikk:** ny UID = nytt kurs · endret `updatedAt` = oppdatert kurs · forsvunnet UID = slettet. `updatedAt` endres IKKE ved minor edits (best-practices-doc).
+4. **Locale:** `locale=nb-no` returnerer treff men faller tilbake til en-us-metadata der oversettelse mangler → bruk `en-us` som primær.
+
+## Foreslått design for spec (til godkjenning neste økt)
+- **Node-klient (Claude-fri, passer decision-ledger-arkitekturen):** Keychain-creds → token → paginer `/api/v1/modules` + `/api/v1/learning-paths` filtrert på domene-produkter + `updatedAt.gt=<sist kjørt, full ISO>` → diff mot lokalt register av kjente UIDs.
+- **Output = leads inn i `decisions.json`** (operatør-gate): «disse nye/endrede kursene finnes i dine dekkede produkter — vurder om temaet bør dekkes i KB». IKKE auto-ingest av kursinnhold som KB-filer («oppdage … som bør dekkes»).
+- **Skill-mapping:** produkt-slug → skill som **config**, ikke hardkoding (slug-sett finaliseres fra live taksonomi).
+- **Arkitektur-invariant (uendret):** deteksjon skriver ALDRI til KB direkte; kun forslag via `decisions.json` etter operatør-gate. Scheduler-entrypoint strukturelt Claude-fri.
+
+## Verifiseringskilder (offisielle)
+- Platform API overview / get-started / developer-reference / best-practices / release-notes / FAQ — alle under `learn.microsoft.com/training/support/integrations-learn-platform-api-*`.
+- Empirisk: probe-kjøringer mot live `/api/v1/modules` (S29), token-auth bekreftet.

docs/cosmo-removal-brief-2026-06.md

@@ -0,0 +1,51 @@
+# Cosmo-persona — full utfasing (brief)
+
+**Opprettet:** 2026-06-24
+**Status:** PLANLAGT — godkjent av operatør, men skal gjøres **SIST** (etter pågående arbeid). Operatør: «Fjern hele Cosmo-personaen (også i README), men vent med dette som det siste vi gjør, HVIS ikke du anbefaler at det gjøres før.» Anbefaling gitt: **ikke tidligere** — KB-refresh (faktaferskhet) og Cosmo-fjerning (persona-ramming) er ortogonale; egen plan + egen versjonsbump (sannsynlig **minor**, f.eks. v1.17.0, siden persona er en dokumentert feature).
+
+## Bakgrunn
+
+Operatør-direktiv 2026-06-24: «Cosmo-pedagogikken er en gammel idé og må ikke fortsettes.» «Cosmo Skyberg» er advisor-personaen i `ms-ai-advisor`-skillen og brukes som et pedagogisk grep både i dialog (`/architect` «med Cosmo Skyberg») og som `## For Cosmo`-notater adressert til personaen i KB-filene.
+
+Utfasing er **startet** i v1.16.5: «For Cosmo»-seksjonene fjernet i `agent-framework.md` (omskrevet) og `disconnected-ai-scenarios.md` (erstattet med «## Oppsummering»). Resten gjenstår.
+
+## Omfang (ground truth, målt 2026-06-24)
+
+- **417 filer** nevner «Cosmo» · **956 totale forekomster**
+- **188 filer** har en `## For Cosmo`- / `For Cosmo:`-seksjon
+- Fordeling (topp): ms-ai-engineering 154 · ms-ai-governance 77 · ms-ai-security 61 · ms-ai-advisor 56 · ms-ai-infrastructure 35
+- Arkitektur-lag (utenfor KB-seksjonene): `ms-ai-advisor/SKILL.md` (persona-definisjon), `commands/architect.md` (+ flere kommandoer: vendor, utredning, transparency, summary, security, ros …), `README.md`, `NOTICE.md`, `CLAUDE.md` («Cosmo Skyberg-persona»), `scripts/skill-gen`, `scripts/kb-update`, playground/docs.
+
+> Reproduser tellingen: `grep -rl "Cosmo" --include="*.md" . | wc -l` · `grep -rao "Cosmo" --include="*.md" . | wc -l` · `grep -rl "## For Cosmo\|For Cosmo:" --include="*.md" . | wc -l`.
+
+## Foreslått tilnærming (utkast — krever egen plan før start)
+
+1. **Avklar erstatning FØRST (operatør-beslutning):** Skal advisor-dialogen ha en ny nøytral ramme («arkitekturrådgiver»), en ny navngitt persona, eller ingen persona? Dette styrer SKILL.md + kommando-omskrivingen og er den eneste reelle designbeslutningen — resten er mekanisk.
+2. **KB-seksjonene (188 `## For Cosmo`):** erstatt med nøytral heading («## Oppsummering» / «## Nøkkelpunkter for rådgivning») — innholdet (bullets) er stort sett nøytrale arkitekt-takeaways og kan beholdes. Kandidat for batch (men header varierer; per-fil eller forsiktig sed med review).
+3. **Persona-lag:** SKILL.md, kommandoer, README, NOTICE, CLAUDE.md, scripts — kirurgisk, per-fil (her sitter den faktiske persona-definisjonen).
+4. **Verifisering:** `bash tests/validate-plugin.sh` (239/0), `grep -rc Cosmo` → 0 (eller dokumentert restmengde), skill-re-score uendret (≥90 %).
+5. **Release:** egen versjonsbump + CHANGELOG; oppdater CLAUDE.md (fjern «Cosmo Skyberg-persona»-beskrivelsen).
+
+## Sammenfall: registry-herding Fase 1a endring C (utsatt hit — operatør 2026-06-26)
+
+Fase 1a A+B (sitemap-prefiks + skjemaløs URL-ekstraksjon) er levert (`e74646d`). **Endring C** (redirect-følging) ble bevisst utsatt og foldet inn HER, fordi **20 av 21 filer med legacy-citater er `ms-ai-advisor`** (copilot-extensibility) — de samme filene Cosmo-utfasingen uansett redigerer. Når du redigerer advisor copilot-extensibility-filene:
+
+- **Re-kanonikaliser 44 legacy `/microsoft-365-copilot/...`-citater → `/microsoft-365/copilot/...`** via **ekte redirect-resolusjon** (ikke streng-rewrite: slug-en kan endres, f.eks. `overview-graph-connector`→`overview-copilot-connector`, verifisert 2026-06-26). Disse står i dag som `not_in_sitemap`.
+- **3 omdøpte microsoftsearch-citater** (`connectors-overview`, `federated-connectors-overview`, `licensing`) — samme redirect-fiks.
+- Etterpå: `node scripts/kb-update/build-registry.mjs --merge` + poll fanger dem som tracked. Gjør dette som ren citat-fiks (root-cause), ikke en ny redirect-map-mekanisme.
+
+## Sammenfall: store-fil-TOC / ref-KB Fase 1b (foldet inn hit — operatør 2026-06-26)
+
+Fase 1b (innholdsfortegnelse i de **20 filene >800 linjer**) ble opprinnelig skopet som «trygt håndverk, uavhengig av Cosmo». Ground truth motbeviste premisset: **11 av 12 ikke-advisor-storfiler** (og alle advisor-storfilene) har en `## …Cosmo…`-seksjon på nivå 2. En TOC bygget fra `##`-overskriftene ville da emittere en **ny Cosmo-anker** (`- [For arkitekten (Cosmo)](#…)`) → bryter «aldri ny Cosmo-innhold», og å nøytralisere overskriften er nettopp denne persona-fjerningen (ikke en sidehandling). Store-fil-TOC folder derfor inn her.
+
+- **Når du nøytraliserer `## …Cosmo…`-overskriften i en storfil (R13/R14):** bygg `## Innhold` på nytt via `transform.insertToc` (primitiven overlever; det tidligere TOC-backfill-CLI-scriptet er **retired i R6 Step 6** — ikke-atomisk `writeFileSync`, 0 programmatiske kallere, superseded av `insertToc` i `transform.mjs` / `migrate-corpus`). NB: `migrate-corpus` fencer ut advisor OG mangler single-fil-modus, så den er **ikke** en drop-in for den advisor-rettede cosmo-use-casen — R13/R14 håndterer TOC via et advisor-kapabelt single-fil-steg, ELLER heading-fjerningen løser det selv.
+- **§8-residual (gap-discipline, [[gap-discipline-must-close]]):** `insertToc` er en no-op på en fil som allerede har `## Innhold`, så en heading-nøytralisering som endrer en **oppført** overskrift etterlater en stale TOC-entry (latent link-rot). Lukkes i R13/R14 ved å regenerere TOC etter nøytralisering (eller nøytralisere før TOC-en bygges).
+- **Mekanismen** er `transform.insertToc` (testet, `tests/kb-update/test-transform.test.mjs`). Nye filer fødes allerede med TOC via `composeKbFile` (Fase 1c, `2240f1e`).
+- **Verifisering:** `node scripts/kb-eval/eval.mjs` → `checkN4 hasToc` = true for de berørte filene; ingen diff-churn på små filer (<100 linjer røres ikke).
+- Eneste storfil uten `##`-Cosmo-overskrift: `zero-trust-ai-services.md` (eneste Cosmo-token er inline `**For Cosmo:**`) — kan TOC-es uten å skape Cosmo-anker, men tas naturlig i samme pass.
+
+## Risiko / merknader
+
+- **Ikke en bugfix-sidehandling.** Persona er en dokumentert feature — full plan + godkjenning før start (scope-guard).
+- Batch-sed på 188 filer er fristende, men `## For Cosmo`-seksjonene har varierende innhold/lengde — review `git diff` per fil eller per klynge.
+- Hold KB-faktainnhold urørt; dette er ren ramme-/persona-endring, ikke en ny KB-refresh.

docs/development.md

@@ -4,7 +4,7 @@ Plugin development, testing, KB-refresh. Imported from `CLAUDE.md` via pointer.
 
 ## Legge til ny kunnskapsbase
 1. Opprett `.md`-fil i riktig undermappe under den relevante skillens `references/`-mappe (f.eks. `skills/ms-ai-engineering/references/`)
-2. Følg format fra eksisterende filer (header, dato, seksjoner, "For Cosmo"-seksjon)
+2. Følg format fra eksisterende filer (header, dato, seksjoner)
 3. Oppdater relevant SKILL.md med referanse
 
 ## Legge til ny kommando
@@ -55,7 +55,9 @@ node scripts/kb-update/build-registry.mjs [--merge]
 
 Systemet sammenligner Microsoft Learn sitemap-`<lastmod>` med filenes `Last updated:` header, og genererer en prioritert endringsrapport (critical/high/medium/low).
 
-**Match rate:** ~69% av 1342 URLer matche mot sitemaps. ~31% (mest `azure/ai-foundry/openai/`-stier) finnes ikke i sitemaps pga. Microsofts URL-restrukturering.
+**Match rate:** ~73% av 1343 URLer matcher mot sitemaps (poll `--force`, juni 2026). Microsoft rebrandet «Azure AI Foundry» → «Microsoft Foundry» og flyttet `/azure/ai-foundry/` → `/azure/foundry/`; Sesjon 2 remappet de 164 ai-foundry-URLene (`migrate-ai-foundry.mjs`), som løftet foundry fra 0 % → ~62 % tracked. Resten som ikke matcher er nesten utelukkende `azure/foundry/openai/`-stier (egen URL-struktur — ikke remappet, ingen verifiserte mål).
+
+**Taksonomi (lag 0):** sitemap-prefikser, relevans (INCLUDE/EXCLUDE), category→skill og file-priority bor i `scripts/kb-update/data/domain-taxonomy.json` (eneste sannhetskilde, tracket). `poll-sitemaps`, `discover-new-urls` og `report-changes` leser den. `category-skill-map.json` er ukonsumert av kode (legacy doc) — ved divergens vinner taksonomien (disk-sann).
 
 **Schedulering:** Pluginen schedulerer ingenting. Bruker som vil ha periodisk varsling kan sette opp egen cron / launchd / systemd / GitHub Actions som kjører `node scripts/kb-update/run-weekly-update.mjs --force --discover` (rapport-fasen, ikke apply). Apply-fasen er bevisst manuell — den krever LLM-resonnering på diff og kjører fra en åpen Claude Code-sesjon.
 
@@ -64,6 +66,48 @@ Legacy (deprecated):
 bash scripts/kb-staleness-check.sh  # mtime-basert, upålitelig etter git clone
 ```
 
+### Kurs-deteksjon (Spor C / C3 — Learn Platform API, opt-in)
+
+Et parallelt, uavhengig spor fra sitemap-discoveren: oppdage at Microsoft har publisert **nye** eller **endrede** treningskurs (modules + learning paths) i produktene KB-en dekker, slik at operatøren kan vurdere om temaet bør dekkes. Et kurs er et *signal*, ikke en doc-side — det auto-ingestes aldri. Full spec: [`c3-course-detection-plan.md`](c3-course-detection-plan.md).
+
+**To-stegs-mønster (samme invariant som `discover-new-urls`):**
+
+1. **Deteksjon (Claude-fri, opt-in, Node-script).** `detect-courses.mjs` leser tre Entra-creds fra macOS Keychain, henter token, paginerer Platform API (`/api/v1/modules` + `/learning-paths`) med produkt- og `updatedAt.gt`-filter, diff-er mot `data/course-registry.json` (detektorens egen sporings-state), og skriver **kun** to private filer: `data/course-detection-report.json` (kandidater) + oppdatert `course-registry.json`. Importerer **aldri** `saveDecisions` — skriver hverken `skills/` eller `decisions.json`.
+
+   ```bash
+   node scripts/kb-update/detect-courses.mjs              # default data-dir
+   node scripts/kb-update/detect-courses.mjs --data-dir DIR  # omdiriger IO (tester)
+   ```
+
+   Fail-soft: mangler creds → `status:"skipped"` + exit 0; vedvarende nettverksfeil → `status:"error"` + exit 0. Opt-in inni opt-in: steget kjøres kun av scheduleren når `include_course_detection: true` (default `false`). Sett flagget via eier-CLI (skriver den gitignored local.md atomisk, bevarer øvrige nøkler):
+
+   ```bash
+   node scripts/kb-update/write-schedule-config.mjs --enabled true --cadence daily --courses true
+   ```
+
+   `--courses` er valgfritt — utelat det for å la en verdi satt andre steder stå urørt.
+
+2. **SessionStart-surfacing (read-only).** `session-start-context.mjs` leser `course-detection-report.json` og viser en one-liner via `summarizeCourses` («Kurs-signaler: N nye / M endrede kurs i dekkede produkter. Kjør /architect:kb-update») — speiler skill-signaler-blokka. `removed` er kun et informasjonssignal i rapporten, aldri en surfacet lead (spec §4.2). Hooken spawner ingenting for kurs-sporet.
+
+3. **Gate (operatør, Claude-i-loop).** `/architect:kb-update` §3c leser rapporten, presenterer nye/endrede leads, og skriver godkjente leads til den UID-nøklede `courses`-kolleksjonen i `decisions.json` (via `recordCourseLead`). `--dry-run` viser leads uten å skrive. **Strukturell invariant:** ingen apply-path leser `courses` → et godkjent kurs-lead trigger aldri fetch/transform/KB-skriving.
+
+Slug→skill-mapping er config i `domain-taxonomy.json` (`course_products`), ikke hardkoding. `last_full_enum`-kadens (≥30 d) styrer når `removed` beregnes (kun full-enumerering — aldri inkrementelt).
+
+### Skill-kvalitetsscore (Spor D — objektiv 0–100-score per skill)
+
+Måler skill-kvalitet deterministisk mot Anthropics «Skill authoring best practices». Rubrikken K1–K10 (`eval.mjs`) + de fem ekstra deterministiske sjekkene N1–N5 aggregeres til én 0–100-score per skill via **vektet delpoeng med hardt gulv** på de bærende kriteriene (K1 trigger-presisjon, K10 søsken-overlapp): feiler ett gulv-kriterium kappes scoren under målet (89), uansett øvrig form. Mål: **alle 5 skills ≥90 %**. Full spec: [`skill-quality-scoring-plan.md`](skill-quality-scoring-plan.md).
+
+```bash
+node scripts/kb-eval/score-skill.mjs               # human-rapport: score + sortert forbedringsliste per skill
+node scripts/kb-eval/score-skill.mjs --json        # maskin-output (scoreReport: target/scored/below)
+node scripts/kb-eval/score-skill.mjs --gate 90     # non-zero exit hvis noen skill < 90
+node scripts/kb-eval/score-skill.mjs --skill ms-ai-advisor   # scope til én skill (inkrementelt)
+```
+
+Arkitektur: `eval.mjs buildReport()` (disk: deterministisk + K10 + merget operatør-gated judge-cache) → `lib/skill-score.mjs` (REN: `scoreSkill`/`scoreReport`/`formatScoreReport`, ingen disk). N1 name-validitet · N2 description ≤1024 · N3 refs én nivå dypt · N4 TOC i ref-filer >100 linjer · N5 forward-slash-stier. Judge-kriterier (K1/K4/K7/K8/K9) degraderer pent: mangler judge → ekskluderes fra teller+nevner, scoren merkes `provisional` (K1-gulv kan ikke håndheves), K10-gulvet (deterministisk) gjelder alltid.
+
+**Korpus-invariant (roadmap):** Hele korpuset skal holde ≥90 % til enhver tid. Ved skill-endring (create/update/merge/split via `apply-skill-op.mjs`) re-scores **kun** den endrede skillen inkrementelt (men hele korpuset evalueres siden K10 trenger alle søsken-descriptions), og `--gate 90` håndhever terskelen via operatør-gate.
+
 ### E2E-regresjonstester
 ```bash
 # Kjør alle E2E-suiter

docs/devils-advocate-audit-2026-06-18.md

@@ -0,0 +1,185 @@
+# Forbedringsrapport: ms-ai-architect v1.15.0
+
+**Dato:** 2026-06-18
+**Forfatter:** Lead architect-advisor (verifisert mot offisielle kilder per audit-dato)
+**Målgruppe:** AI-rådgiver i norsk offentlig sektor, samt private Azure AI/Foundry-arkitekter
+**Grunnlag:** Devil's-advocate-audit over 10 dimensjoner. Kun funn med `confirmed=true` og `finalSeverity != rejected` er tatt med. Fire funn ble forkastet ved uavhengig verifisering (runtime-grounding, embedding-katalog, query-time RBAC, deler av suveren-sky-funnet) og er utelatt.
+
+---
+
+## 1. Sammendrag
+
+Pluginens implisitte løfte — «alt en norsk Azure AI/Foundry-arkitekt trenger» — holder **ikke fullt ut per juni 2026**. Den er sterk som lærings- og referansestillas, men har materielle ferskhets- og rutingfeil i akkurat de lagene en arkitekt bruker daglig til beslutninger som deles med ledelse, jurist eller tilsyn.
+
+**Hvor den er sterk (verifisert):**
+- **ROS-motoren** er den mest modne delen: 49-trussels bibliotek mappet til OWASP LLM Top 10 (2025) og MITRE ATLAS, deterministiske 7x5-rubrikker, NS 5814/ISO 31000-metodikk, MAESTRO 7-lags multiagentmodell. NS 5814:2021 er korrekt gjeldende.
+- **Sikkerhetsscoring (6x5)** er beslutningsgrad: deterministiske sjekkpunkter, MCSB v2-mapping, vektet scoring, gjennomarbeidede referansecase.
+- **ms-ai-engineering-KB** er innholdsmessig den dypeste dimensjonen (RAG, evaluering, GenAIOps). Runtime-grounding (Content Safety groundedness detection med correction-modus) og query-time RBAC (`x-ms-query-source-authorization`) **finnes faktisk** og er kurante — to opprinnelige funn ble forkastet her.
+- **Den regulatoriske utrednings-spinen** (`/architect:utredning`, 7-fase Cosmo-flyt) er reell og komplett for utredningsinstruksen-arbeid.
+
+**Hvor den brister (verifisert):**
+1. **EU AI Act-tidslinjen er feil i hele pluginen.** Ingen fil reflekterer Digital Omnibus (provisorisk enighet 6.–7. mai 2026), som utsetter Annex III-høyrisiko fra 2. aug 2026 til **2. desember 2027**. Pluginen forteller en norsk deployer at de har ~2 måneder når de i realiteten har ~18. Dette er den enkeltfaktoren som driver hver eneste frist, handlingsplan og roadmap pluginen produserer.
+2. **Kostnadslaget kan ikke stoles på.** GPT-5 estimeres til ~$10–15/$40–60 per 1M tokens i en fil stemplet «Verified MCP 2026-05» — reell Azure-pris er **$1,25/$10,00** (input ~8–12x for høyt). To kostnadsfiler i samme plugin er uenige ~4x om GPT-4o. En arkitekt som fakturerer i NOK kan ikke bruke tallene uten å re-verifisere alt — som opphever poenget med en «deterministisk» modell.
+3. **Foundry/modellkatalogen er 4–6 generasjoner bakpå** og inneholder en faktafeil som feilstyrer datasuverenitet: KB-en sier GPT-5 i Norway East «kun via Global Standard, data kan forlate regionen», men hele GPT-5-familien er deployerbar i `norwayeast` (Global Provisioned Managed), og gpt-5.5 er i Data Zone Standard `norwayeast`.
+4. **Agent-orkestreringen anbefaler et vedlikeholdsmodus-produkt.** MAF 1.0 ble GA 3. april 2026 og er etterfølger til Semantic Kernel + AutoGen (begge nå kun bug/sikkerhetsfikser). KB-en presenterer SK/AutoGen som go-forward og merker MAF-orkestrering «Experimental» — stikk motsatt av virkeligheten.
+5. **Den dypeste KB-en er foreldreløs.** Verken kommandoer eller agenter ruter til de 28 RAG- + 22 MLOps-filene; dybden nås bare hvis modellen autonomt laster skillet. Samme mønster rammer ROS (dokumentert 3-fils-budsjett vs. 11 filer agenten faktisk krever — truer determinisme-løftet), DPIA (Schrems/CLOUD Act-metodikk er utenfor agentens rutestier), og prosess-deliverables (NNV, gevinstrealisering, anskaffelser, kapasitet-sizing finnes som KB men ingen kommando surfacer dem).
+6. **Privat sektor er andrerangs.** Seks daglige kommandoer hardkoder «norsk offentlig sektor»; onboarding kan ikke representere en privat virksomhet; finanssektor-innhold (DORA/Finanstilsynet) finnes i KB men har ingen kommandosti.
+
+**Verdikt:** For en *norsk offentlig* arkitekt er pluginen brukbar som rådgivnings- og utredningsverktøy, men den regulatoriske tidslinjen og kostnadstallene må re-baselines før noe deles eksternt. For en *privat enterprise* Azure/Foundry-arkitekt er den i dag et halvferdig verktøy: kjernedybden finnes, men entry-points, kalibrering og demo-flate er offentlig-sektor-først.
+
+---
+
+## 2. Ferskhets-status
+
+Status: **Oppdatert** = KB matcher kilde / **Delvis** = noe korrekt, noe utdatert eller intern selvmotsigelse / **Utdatert** = løpsbærende fakta er feil.
+
+| Dimensjon | Status | Hva som konkret har endret seg siden KB-dato | Verifiserende kilde (URL + dato) |
+|-----------|--------|----------------------------------------------|----------------------------------|
+| **EU AI Act** | Utdatert | Digital Omnibus (prov. enighet 6.–7. mai 2026): Annex III-høyrisiko utsatt 2. aug 2026 → **2. des 2027**; Annex I-innebygd → 2. aug 2028; Art. 50 syntetisk-innhold-frist kuttet 6→3 mnd (2. des 2026); ny Art. 5-forbud (NCII/CSAM). GPAI i kraft siden 2. aug 2025 (KB sier fremtidig). Art. 99-bøter feil i provider-fil (30M/6 % — finnes ikke; korrekt 35M/7 %, 15M/3 %). Nkom nå utpekt koordinerende tilsyn (KB: «under etablering»). | [Consilium 7. mai 2026](https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/); [Gibson Dunn Omnibus](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/); [AI Act Art. 99](https://artificialintelligenceact.eu/article/99/) — alle aksessert 2026-06-18. **NB:** Omnibus er **provisorisk, ikke vedtatt** — OJ-publisering ventet før 2. aug 2026. Tidslinjen skal merkes «foreløpig, avventer OJ». |
+| **DPIA/GDPR + overføring** | Delvis | EU Data Boundary **fullført feb 2025** (KB: «status å verifisere», bruker «West Europe» som anker for trygd/helse). DPF: Latombe-søksmålet **avvist av Underretten 3. sep 2025** (KB: «utfordret av NOYB, gyldig per 2026»). EDPB Opinion 28/2024 (anonymisering av AI-modeller) ikke reflektert. KI-loven (høring sommer 2025, tiltenkt ~aug 2026) mangler i DPIA-stien. | [Microsoft EUDB-fullføring 2025-02-26](https://blogs.microsoft.com/on-the-issues/2025/02/26/microsoft-completes-landmark-eu-data-boundary-offering-enhanced-data-residency-and-transparency/); [IAPP Latombe](https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework); [regjeringen.no Nkom](https://www.regjeringen.no/en/whats-new/gjor-norge-klar-for-trygg-og-innovativ-ki-bruk/id3093081/) — aksessert 2026-06-18 |
+| **ROS** | Delvis | NSM Grunnprinsipper sitert v2.0/2022 — gjeldende er **v2.1 (31. mai 2024)**. Art. 99-bot feil (30M/6 %) i metodikkfil, motsier agentens egne korrekte tall. OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10, publ. 9. des 2025) ikke mappet. MITRE ATLAS AML.T0051 feilmerket «LLM Agent Hijacking» (er «LLM Prompt Injection»). EchoLeak (CVE-2025-32711) ikke dekket. | [NSM GP v2.1](https://nsm.no/aktuelt/ny-versjon-av-nsms-grunnprinsipper-for-ikt-sikkerhet-klar); [OWASP Agentic 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/); [CVE-2025-32711 EchoLeak](https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html) — aksessert 2026-06-18 |
+| **Foundry / modellkatalog** | Utdatert | Katalog stopper ved gpt-5.2 (des 2025); mangler GPT-5.3/5.4/5.5, gpt-chat-latest, gpt-oss, sora-2, gpt-image-2. Norway East GPT-5-residens **feil** (hele familien i `norwayeast` Global Provisioned Managed; gpt-5.5 i Data Zone Standard `norwayeast`). 88 doc-lenker bruker pensjonert `azure/ai-foundry/`-navnerom. «Connected Agents»-framing erstattet av Prompt/Hosted agents + Responses API. Foundry Local på Azure Local (suveren/air-gapped) mangler. | [MS Learn region-availability](https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability); [models-sold-directly-by-azure](https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure) — aksessert 2026-06-18 |
+| **Copilot / Power** | Delvis | Computer-Using Agents **GA 13. mai 2026** i alle kommersielle geos (KB: «Preview, US-only» — fraråder aktivt CUA). Modellkatalog flere generasjoner bakpå (GPT-4.1 som default; GPT-5.5 Instant/Reasoning, Claude 4.6/Opus mangler/feilmerket). M365 E7 (GA mai 2026, ~$99/bruker) og Agent 365 (GA 1. mai 2026) ikke i lisensmatrise. Anthropic-modeller utenfor EU Data Boundary, off-by-default for EU/EFTA fra 4. mai 2026 — ikke flagget i copilot-studio.md. | [Copilot Studio what's-new (ms.date 2026-05-14)](https://learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new); [CUA GA-blogg 13. mai 2026](https://techcommunity.microsoft.com/blog/copilot-studio-blog/computer-using-agents-in-microsoft-copilot-studio-are-now-generally-available/4519427) — aksessert 2026-06-18 |
+| **Agent-orkestrering** | Utdatert | **MAF 1.0 GA 3. april 2026**; Semantic Kernel + AutoGen i vedlikeholdsmodus (ingen nye features). KB presenterer SK/AutoGen som go-forward, MAF-orkestrering merket «Experimental» (5 kjernemønstre er stabile; kun Python Functional Workflow API er eksperimentell). A2A dokumentert v0.3 — nå **v1.0** (signerte Agent Cards, gRPC). Entra Agent ID GA april 2026 (overflatisk dekket). Build 2026: Hosted Agents, Agent Harness, CodeAct mangler helt. | [MAF 1.0 GA](https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/); [Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id); [A2A v1.0](https://a2a-protocol.org/latest/) — aksessert 2026-06-18 |
+
+### Note: UNVERIFISERTE / kun delvis bekreftede påstander (behandle med forsiktighet)
+
+Disse er bekreftet i retning, men eksakt detalj er **ikke** uavhengig verifisert i auditen — de skal **ikke** asserteres i delt output uten fersk sjekk:
+
+- **Foundry preview-chat-modellenes nøyaktige pensjonsdato.** Funnet oppga «2026-06-29», men kilder peker mot juni 2026 / 1. juni 2026 for gpt-5.3-chat preview. Den eksakte datoen er ikke bekreftet — kun at preview-chat-modeller pensjoneres nær forestående og at `gpt-chat-latest` er etterfølgeren. Verifiser mot model-retirement-schedule-siden.
+- **A2A v1.0 eksakt cutover-dato.** Den offisielle spec-siden gir ingen presis dato, kun «breaking changes» + bakoverkompatibilitet via dual-versjon Agent Cards. v1.0-eksistensen og featuresettet er solid; datoen er det ikke.
+- **A2A-saksnummeret C-703/25 P** (DPF CJEU-anke) kunne ikke bekreftes fra søkeresultater. Underrettens avvisning 3. sep 2025 er bekreftet; saksnummeret er uverifisert.
+- **GPT-5/5.x absolutte token-priser ut over GPT-5 flagship ($1,25/$10,00, bekreftet).** Azure-prissiden er JS-rendret; gpt-5.2 ($1,75/$14) og andre tiers bør re-hentes via pricing-kalkulator før de tallfestes i klient-output.
+- **PTU per-time NOK-rate.** Microsoft publiserer ikke en flat per-PTU/time-pris slik KB-en antyder; eksternt sett ~$2 448/mnd inngangsnivå. KB-ens breakeven-tall er fabrikerte avrundinger og ikke reproduserbare.
+- **Microsoft product-capability-påstander i ai-act-microsoft-tools-mapping.md** (15 automated evaluation actions, C2PA-watermarking, Compliance Manager EU AI Act-template) ble ikke re-sjekket mot Microsoft Learn — behandle som plausible-men-uverifiserte.
+- **Norges Bank USD/NOK-kurs** (KB hardkoder 10,50 per feb-2026; mid-juni 2026 ~9,5 ifølge søk, men ikke autoritativt verifisert i auditen).
+- **WAF/CAF-deliverable-funnets sourceCheck** var UNVERIFIED på selve gap-et; WAF/CAF som rammeverk er etablerte, men «kritisk hull»-framingen er en skjønnsvurdering, ikke en verifisert faktafeil.
+
+---
+
+## 3. Prioriterte forbedringer
+
+### P1 — Tillit og korrekthet (blokker for trygg ekstern bruk)
+
+**Tema A: Re-baseline EU AI Act-tidslinjen (Digital Omnibus)**
+- **Hva er feil:** Hele frist-tabellen i `CLAUDE.md:120`, `ai-act-assessor.md:141-144`, `ai-act-classification-methodology.md:280`, `ai-act-compliance-guide.md`, `ai-act-conformity-assessment.md:332-339`, `ai-act-annex-iii-checklist.md`, `ai-act-microsoft-tools-mapping.md` og `ai-act-deployer-obligations.md` ankrer høyrisiko på 2. aug 2026.
+- **Hvorfor det betyr noe:** Tidslinjen er løpsbærende for hver roadmap, handlingsplan og «frist»-kolonne. Arkitekten feilråder organisasjonen på den enkeltfaktoren med størst konsekvens for investering og sekvensering.
+- **Anbefaling:** Erstatt med to-trinns høyrisiko-datoer (Annex III: 2. des 2027; Annex I-innebygd: 2. aug 2028), legg til Art. 5-forbud + Art. 50-frist 2. des 2026, og merk hele tidslinjen «foreløpig, avventer OJ-publisering». Utvid `kb-update` til å polle EUR-Lex/Commission/regjeringen.no (ikke bare Microsoft Learn — som strukturelt ikke kan fange dette).
+- **Estimat:** M (én kanonisk dato-boks transkludert overalt + kb-update-utvidelse).
+
+**Tema B: Fiks kostnadslaget — én sannhetskilde, korrekte tall**
+- **Hva er feil:** GPT-5 ~8–12x for høyt i `gpt5-gpt41-pricing-models.md` (stemplet «Verified MCP 2026-05»); `cost-models.md` vs `deterministic-cost-calculation-model.md` uenige ~4x om GPT-4o ($10/$30 vs $2,50/$10); begge navngitt som kostnadskilde i CLAUDE.md-rutingen → agenten kan lese hvilken som helst.
+- **Hvorfor det betyr noe:** Verifiseringsplikt-brudd: «Verified»-stempel på en gjetting. En arkitekt som presenterer NOK-budsjett til styret over-budsjetterer GPT-5 og styrer klienten bort fra den av feil grunn.
+- **Anbefaling:** Gjør `deterministic-cost-calculation-model.md` til eneste prissannhet; strip pris-tabeller ut av `cost-models.md`; sett GPT-5 til $1,25/$10,00 (verifisert) og legg til GPT-5-familien; fjern «Verified»-stempel fra alle tall som faktisk var estimater; slett GPT-3.5 Turbo-anbefalinger. Standardiser per-1M tokens overalt; merk PTU-NOK-tall som illustrative til reelle SKU-priser hentes.
+- **Estimat:** M.
+
+**Tema C: Rett Norway East GPT-5-datasuverenitet**
+- **Hva er feil:** `model-catalog-2026.md:272-279/336-340/383` og `azure-ai-foundry.md:272-275` sier GPT-5 i Norway East er ikke-resident og anbefaler unødvendig Sweden Central-migrasjon.
+- **Hvorfor det betyr noe:** Datasuverenitet under GDPR/Schrems II er den mest konsekvensrike beslutningen i dimensjonen for offentlig sektor. (Nyanse fra verifisering: Global Provisioned Managed *er* et globalt prosesseringsmønster — data *kan* forlate regionen — så KB-ens forsiktighet er teknisk riktig *for den deployment-typen*; feilen er utelatelsen av Global/Global-PTU-tilgjengelighet og den nye Data Zone Standard `norwayeast` for gpt-5.5.)
+- **Anbefaling:** Korriger Norway East-radene for hele GPT-5-familien (Global Standard + Global Provisioned Managed), legg til gpt-5.5 Data Zone Standard `norwayeast`, og skriv om beslutningstreet så GPT-5 presenteres som data-resident alternativ via Regional PTU der streng residens kreves.
+- **Estimat:** S–M.
+
+**Tema D: Korriger agent-rammeverk-anbefalingen (MAF 1.0)**
+- **Hva er feil:** `semantic-kernel-agents-implementation.md`, `multi-agent-orchestration-patterns.md`, `declarative-vs-imperative-agent-design.md` presenterer SK/AutoGen som go-forward og MAF-orkestrering som «Experimental».
+- **Hvorfor det betyr noe:** Rammeverksvalg er den høyest-leverte arkitekturbeslutningen i et multiagent-bygg. Å anbefale et vedlikeholdsmodus-SDK til et greenfield Foundry-prosjekt er en direkte, kostbar feilstyring.
+- **Anbefaling:** Status-banner: MAF 1.0 er GA og etterfølger til SK + AutoGen (begge vedlikeholdsmodus). Nye bygg → MAF; SK/AutoGen kun for eksisterende kodebaser med migrasjonsplan. Oppdater MAF-orkestrering til GA/stabil for de 5 mønstrene (kun Python Functional Workflow API eksperimentell). Lenk offisielle migrasjonsguider.
+- **Estimat:** M.
+
+**Tema E: Art. 99-bøter — slett den ikke-eksisterende 30M/6 %-raten**
+- **Hva er feil:** `ai-act-provider-obligations.md:13` og `ros-methodology-ns5814-iso31000.md:236` siterer «30 millioner EUR / 6 %» (2021-utkast, finnes ikke i vedtatt forordning). Begge motsies av korrekte tall andre steder i samme KB.
+- **Hvorfor det betyr noe:** En arkitekt som siterer 30M/6 % til styre/jurist siterer en juridisk ikke-eksisterende bot — kredibilitetsdrepende foran tilsyn.
+- **Anbefaling:** Korriger til Art. 99 tre-tier (35M/7 % for Art. 5-forbud; 15M/3 % for høyrisiko/Art. 9-27; 7,5M/1 % for feilinformasjon). Lag én kanonisk bot-tabell referert av alle filer. Grep KB for «6 %»/«30 millioner» for å fange gjenværende forekomster (én ekstra i `transparency-documentation-standards.md:689`).
+- **Estimat:** S.
+
+### P2 — Ruting og nåbarhet (dybden finnes, men er foreldreløs)
+
+**Tema F: Rut til den dype engineering-/RAG-/MLOps-KB-en**
+- **Hva mangler:** Ingen kommando/agent ruter til 28 RAG- + 22 MLOps-filer; kun `generate-skills.md` (KB-forfatter-manifest) refererer dem. `architecture-review-agent` ruter kun til advisor/governance/security.
+- **Hvorfor det betyr noe:** 153-fils engineering-skillet er betalt for, men nås kun ved autonom skill-aktivering — ikke deterministisk. Den dypeste byggbare dybden er latent.
+- **Anbefaling:** Legg eksplisitt Read-ruting til RAG/MLOps-kjernefiler i `architecture-review-agent`, `research-agent` og `poc`-kommandoen (samme navngitte-fil-mønster som security/cost allerede bruker). Dokumenter et `/architect:engineering`- eller RAG-design-entry-point.
+- **Estimat:** M.
+
+**Tema G: Fiks ROS-rutingsmotsetningen (determinisme-løftet)**
+- **Hva er feil:** `CLAUDE.md:81` sier «max 3 filer» for ros-analysis-agent; `ros-analysis-agent.md` lister 11; `ros.md:49-53` ber om 5 + sektorsjekklister. Truslebiblioteket alene er ~1004 linjer.
+- **Hvorfor det betyr noe:** Enten skipper agenten filer stille (to analytikere får ulike trusselsett/scorer — motsatt av «deterministisk») eller sprenger budsjettet. Reproduserbarhet er et hovedløfte.
+- **Anbefaling:** Forson regelen med virkeligheten: hev/kvalifiser budsjettet for ros-analysis-agent, eller splitt truslebiblioteket i per-kategori-filer lastet betinget. Angi eksplisitt, håndhevet last-rekkefølge. Legg MAESTRO + DPIA-security-integration til betinget i `ros.md` (ikke bare i agentfilen).
+- **Estimat:** M.
+
+**Tema H: Gjør DPIA-agenten i stand til å nå Schrems/CLOUD Act-metodikken**
+- **Hva mangler:** `dpia-agent.md` lister «Cross-border transfers (Schrems II)» som risiko #7 men ruter kun til 3 filer uten TIA-metodikk. EDPB seks-stegs-TIA, CLOUD Act/FISA 702-restanalyse bor i filer agenten aldri laster. (CLOUD Act *finnes* 11 steder i pluginen, men ingen i DPIA-agentens stier.)
+- **Hvorfor det betyr noe:** Agenten produserer en DPIA som *navngir* Schrems-risikoen men ikke kan vurdere eller mitigere den. DPO-en vil spørre «kan amerikanske myndigheter nå disse dataene?» — agenten har intet grunnlagt svar.
+- **Anbefaling:** Legg `data-residency-audit-monitoring.md` (eller ny TIA-metodikkfil) til DPIA-agentens betingede last under en «cross-border»-trigger. Forfatt eksplisitt CLOUD Act/FISA 702/EO 14086-seksjon: EUDB holder data i EØS men fjerner ikke tredjelands-tilgangsmulighet; restoverføringer krever dokumentert TIA med tekniske tiltak (CMK, customer lockbox, confidential computing).
+- **Estimat:** M–L (krever forfatting av ny EDPB-seks-stegs-metodikk, ikke bare re-ruting).
+
+**Tema I: Wire de foreldreløse deliverable-KB-ene**
+- **Hva mangler:** `samfunnsokonomisk-analyse-nnv.md`, `gevinstrealisering-dfo-methodology.md`, `anskaffelser-ai-procurement-framework.md`, `capacity-feasibility-benchmarks.md`, `gpu-compute-sizing.md`, `alternativanalyse-methodology.md` — alle eksisterer, ingen kommando/agent surfacer dem.
+- **Hvorfor det betyr noe:** Kunnskapen er skrevet og betalt for, men ikke overflatebar. `/architect:compare` ignorerer den vektede MCA-metodikken som allerede ligger i KB — en bar pros/cons-tabell overlever ikke en anskaffelses-klage eller styre-utfordring.
+- **Anbefaling:** Wire inn via dedikerte/utvidede kommandoer: `/architect:businesscase` (NNV + gevinstrealisering), `/architect:anskaffelse` (kravspek + terskelverdi), kapasitet-sizing inn i `/architect:cost`, og en «weighted»-modus i `/architect:compare` som bruker `alternativanalyse-methodology.md`.
+- **Estimat:** M per kommando.
+
+### P3 — Ferskhets-hygiene og dekningsgap
+
+**Tema J: Currency-pass på hurtigbevegelige flater**
+- Agentic retrieval er **GA** (REST 2026-04-01, knowledge bases/sources, multi-source) — KB sier «Preview, single-index» (`agentic-rag-patterns.md`). **S.**
+- Prompt Flow er **pensjonert** (EOL 2027-04-20, migrer til MAF) — brukt som anbefalt verktøy i ~6 filer uten advarsel. Legg pensjon-banner + re-pek til MAF. **S.**
+- A2A v0.3 → v1.0 (signerte Agent Cards). **S.**
+- CUA Preview/US-only → GA 13. mai 2026, alle geos; oppdater RPA-vs-CUA-tabellen. **S.**
+- M365 E7 + Agent 365 inn i lisensmatrise (`licensing-matrix.md`, stalest, dater 2026-01). **M.**
+- NSM Grunnprinsipper v2.0 → v2.1. **S.**
+- `azure/ai-foundry/` → `azure/foundry/` (88 lenker); oppdater kb-update sitemap-mål. **M.**
+
+**Tema K: Trussel-dekning for 2026-realiteten**
+- OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) mappes inn i ROS Category 6 + MAESTRO. **M.**
+- EchoLeak (CVE-2025-32711) zero-click M365 Copilot-eksfiltrasjon som egen/utvidet trussel. **S.**
+- MITRE ATLAS AML.T0051-feilmerking + remap agent-autonomi-trusler mot Oct-2025 ATLAS agent-teknikker. **S.**
+- Defender «Threat protection for AI services» (GA runtime-alerts) som egen KB-fil, ikke bare scoring-checkbox. **M.**
+- Fire manglende OWASP-referansefiler (LLM04/06/08/09 viser «—» i SKILL.md-tabellen). **M.**
+
+**Tema L: Foundry-dekning for suverenitet**
+- Foundry Local på Azure Local (Arc/Kubernetes, air-gapped) — den mest offentlig-sektor-relevante varianten — mangler helt. **M.**
+- EDPB Opinion 28/2024 (AI-modeller og personopplysninger): mykgjør «anonymisert = utenfor scope» til krav om re-identifiserings-vurdering. **S.**
+
+---
+
+## 4. Quick wins denne uka (S, høy verdi, lav risiko)
+
+Alle er rene tekst-rettelser av verifiserte faktafeil — ingen arkitektur-endring, lav regresjonsrisiko:
+
+1. **Art. 99-bøter** → `skills/ms-ai-governance/.../ai-act-provider-obligations.md:13` og `skills/.../ros-methodology-ns5814-iso31000.md:236`. Bytt 30M/6 % → 35M/7 % (Art. 5) / 15M/3 % (høyrisiko). Grep også `transparency-documentation-standards.md:689`.
+2. **GPT-5-pris** → `skills/ms-ai-security/references/cost-optimization/gpt5-gpt41-pricing-models.md`. Sett $1,25/$10,00 (verifisert), fjern «Verified MCP 2026-05»-stempel fra estimat-bånd.
+3. **GPT-4o-motsetning** → `skills/ms-ai-advisor/references/architecture/cost-models.md:42`. Rett $10/$30 → $2,50/$10,00 (eller fjern pris-tabell og referer deterministic-modellen).
+4. **MAF-status-banner** → topp av `semantic-kernel-agents-implementation.md` + `multi-agent-orchestration-patterns.md`: «MAF 1.0 GA; SK/AutoGen vedlikeholdsmodus».
+5. **Prompt Flow pensjon-banner** → hver fil som anbefaler Prompt Flow (`prompt-flow-production-deployment.md`, `genaiops-llm-specific-practices.md`, `rag-evaluation-frameworks.md`, `rag-core-patterns.md`, `azure-ai-search-setup.md`): «Pensjoneres 2027-04-20, migrer til MAF».
+6. **NSM Grunnprinsipper-versjon** → `ros-methodology-ns5814-iso31000.md:29`: v2.0 (2022) → v2.1 (2024).
+7. **CUA-status** → `copilot-studio.md:51/170/208` + RPA-vs-CUA-tabell (linje 195-206): Preview/US-only → GA 13. mai 2026, alle kommersielle geos.
+8. **EU AI Act frist-tabell-banner** → `CLAUDE.md:120` + `ai-act-assessor.md:141-144`: legg til topp-note «Foreløpig — Digital Omnibus utsetter Annex III-høyrisiko til 2. des 2027 (avventer OJ-publisering)». (Full re-baseline er M, men denne advarselen er S og stopper umiddelbar feilråding.)
+9. **GPAI in-force** → splitt GPAI ut av høyrisiko-raden i `CLAUDE.md:120` og `ai-act-assessor.md:143`: «Art. 53/55 + Code of Practice i kraft siden 2. aug 2025; håndheving fra 2. aug 2026».
+10. **EØS/«direkte gjeldende»** → fjern den ukvalifiserte påstanden i `ai-act-compliance-guide.md:10`; erstatt med én status-boks (ikke EØS-innlemmet per dato; KI-loven ~aug 2026; norske aktører i EU-markedet bundet av EU-datoer uansett).
+
+---
+
+## 5. Privat-sektor-paritet
+
+Pluginens README hevder den forblir «useful for any enterprise context», men kommando-flate, onboarding og demo-data er systematisk offentlig-sektor-først. En privat norsk enterprise Azure/Foundry-arkitekt er andrerangs:
+
+**Verifiserte mangler:**
+
+1. **Onboarding kan ikke representere en privat virksomhet.** `onboarding-agent.md:34` sektor-valg er `Statlig/Kommunal/Fylkeskommune/Helseforetak/Undervisning/Annet` — en bank må velge «Annet». Reguleringslisten (`:37`) er kun offentlig lov (ingen Finansforetaksloven, DORA, Verdipapirhandelloven). org/-filer leses av alle 11 agenter for kalibrering → privat arkitekts hele nedstrøms-opplevelse kalibreres mot et offentlig-sektor-skjelett.
+   - **Anbefaling:** Legg til private sektor-valg (Finans/bank/forsikring, Industri, Handel, Energi, Telekom, AS/konsern) + privat regulerings-sett. Forgren intervjuet så private ikke spørres Offentleglova/Arkivloven. Betinget Fase 3-gren for regulert privat sektor (DORA-scope, Finanstilsynet, egen dataklassifiserings-taksonomi).
+
+2. **EU AI Act-klassifisering hardkoder offentlig sektor** — men AI Act gjelder *alle* providers/deployers. `classify.md:11` («for et AI-system i norsk offentlig sektor»), defaulter brukertyper til «borgere, saksbehandlere, interne». Seks daglige kommandoer (classify, dpia, ros, frimpact, utredning, review) hardkoder «offentlig sektor»; kun `security.md:22` og `compare.md` behandler kontekst som parameter.
+   - **Anbefaling:** Gjør sektor til parsed parameter i alle seks (som security.md), default nøytral. Offentlig-spesialisering aktiveres på detektert kontekst. (Nyanse: FRIA er *også* obligatorisk for noen private deployers — kredittverdighet, forsikringsprising — så «reserver FRIA for offentlig» er upresist.)
+
+3. **Privat-sektor-regulatorer finnes i KB men har ingen kommandosti.** `ros-sector-checklists.md §3 Finans` har en 17-punkts finanssjekkliste (Finansforetaksloven, DORA 2022/2554, IKT-forskriften, Verdipapirhandelloven, EBA/GL/2023/06) — nåbar kun via `/architect:ros`, som rammer hele analysen som «offentlig sektor». `/architect:requirements` detekterer *ikke* sektor (kun rolle provider/deployer). Ingen help/README forteller en finans-arkitekt at DORA/Finanstilsynet-dekning eksisterer.
+   - **Anbefaling:** Privat-sektor-aware compliance-entry (f.eks. `/architect:requirements` detekterer Finans → DORA/Finanstilsynet), eller minimum dokumenter sektor-sjekklistene i help.md og README.
+
+4. **Ingen sektor-nøytral «Solution Architecture Document».** `/architect:utredning` er eksplisitt scoped til utredningsinstruksen (`utredning.md:11`). En privat arkitekt som vil ha et vanlig SAD (kontekst, krav/NFR, opsjoner, valgt design, risiko, roadmap) uten offentlig-sektor-stillaset må enten over-invokere utredning eller stitche adr+summary+diagram manuelt.
+   - **Anbefaling:** Sektor-nøytral `/architect:design` som persisterer Fase 6-output strukturert. I dag er valget «ephemeral chat» eller «full utredning» — intet imellom.
+
+5. **Ingen tredjeparts-/SaaS-/shadow-AI-vurdering** — en daglig privat-enterprise-oppgave. `license.md` mapper Microsoft-lisenser, ikke eksterne leverandører.
+   - **Anbefaling:** `/architect:vendor` (eller utvid `/compare` til ikke-Microsoft SaaS): due-diligence-sjekkliste (dataresidens, sub-prosessorer, DPA, Schrems II, AI Act deployer-forpliktelser).
+
+6. **README/help/playground signaliserer offentlig-sektor-bane.** README har dedikert «Norwegian Public Sector Features» (linje 278), `help.md` ruter steg 2 til «utredning for offentlig sektor» som kanonisk. Playground-seed er 100 % offentlig («Acme Kommune», saksbehandler, borger). En privat arkitekt ser sin egen brukssak ingensteds.
+   - **Anbefaling:** Parallell privat-enterprise-arbeidsflyt i README + help (classify → security → cost → ADR, uten utredning/FRIA); minst ett privat-sektor-seed-prosjekt i playground (f.eks. bank fraud-detection under DORA/Finanstilsynet).
+
+**Konklusjon privat-sektor:** Kjerne-dybden (sikkerhetsscoring, kostnadsmodell, RAG/engineering-KB, finans-sjekkliste) er sektor-agnostisk og verdifull. Det som mangler er *entry-points, kalibrering og navigasjon* — i stor grad mekaniske endringer (parametrer sektor, forgren onboarding, dokumenter eksisterende innhold), ikke nytt KB-arbeid. Paritet er innen rekkevidde uten å bygge en ny plugin.

docs/eu-ai-act-integration-handover.md

@@ -9,7 +9,7 @@
 
 ## Kontekst
 
-ms-ai-architect er en Claude Code-plugin for Microsoft AI-arkitektur i norsk offentlig sektor, primært brukt av KTG (AI-rådgiver, Direktoratet for digital tjenesteutvikling). Pluginen har allerede DPIA- og ROS-agenter. EU AI Act-støtte skal integreres som en **overordnet regulatory layer** som feeder inn i eksisterende arbeidsflyt.
+ms-ai-architect er en Claude Code-plugin for Microsoft AI-arkitektur i norsk offentlig sektor. Pluginen har allerede DPIA- og ROS-agenter. EU AI Act-støtte skal integreres som en **overordnet regulatory layer** som feeder inn i eksisterende arbeidsflyt.
 
 **Logisk sekvens (uforanderlig):**
 ```

docs/ingestion-security-brief-2026-07.md

@@ -0,0 +1,256 @@
+# Brief: Ingestion-pipeline security gate (G6 / R6 punkt d)
+
+**Design input for the two-layer ingestion security gate. Goal: the highest
+feasible level of adversarial-content defense on the chain that turns fetched
+Microsoft Learn content into a publicly distributed knowledge base.**
+
+Status: design brief. This sharpens and hardens the gate already decided in
+`docs/ref-kb-correctness-program-2026-06.md` §8 (G6) and scoped for
+`docs/plugin-roadmap-2026-07.md` R6 punkt (d). It does **not** invent a parallel
+mechanism — it is the concrete design for that existing item.
+
+---
+
+## 1. Why this is load-bearing for *this* plugin specifically
+
+The KB is not a private cache. Reference files under `skills/**/references/**`
+become **instruction-adjacent context in future agent sessions**, and the plugin
+ships on a public remote to the whole of Norwegian public sector. One poisoned
+reference file is re-served to every user of every downstream session (G6 §8,
+verbatim: *"references-filene blir instruksjonsnær kontekst i fremtidige
+agent-sesjoner, én forgiftet fil re-serveres til alle brukere (hele Norge)"*).
+That makes write-time adversarial-content defense a first-class control, not
+hygiene — the opposite end of the risk spectrum from a pinned, single-author
+source.
+
+## 2. The pipeline as it actually is (grounded)
+
+Verified by reading `commands/kb-update.md` and `CLAUDE.md`:
+
+- **Ingestion runs in-session, in Claude Code, via the `microsoft-learn` MCP.**
+  Apply is *"alltid manuell og kjøres in-session"* (`kb-update.md:13`); content
+  enters through `microsoft_docs_fetch` / `microsoft_docs_search` /
+  `microsoft_code_sample_search` (`kb-update.md:5,22,180`). `generate-skills`
+  (batch MCP-research) and `research` / `research-agent` follow the same
+  in-session-MCP-fetch → persist pattern (`CLAUDE.md:39,56`).
+- **The detection tier is Claude-free** — it polls sitemaps for `<lastmod>` only
+  and never feeds fetched *content* to a model (`kb-update.md:13,52-73`). The
+  adversarial-content-into-model boundary is therefore the **in-session apply**,
+  not the schedulable detection.
+- **Write and commit points are explicit.** New file: fetch → transform
+  (`transform-prompt.md`) → born-verified judge → `composeKbFile` →
+  `validateKbFile` → create-guard `validate-kb-file.mjs` → atomic write
+  (`kb-update.md:127-134`). Update: fetch → classify change → `Edit` →
+  `validateKbFile` → commit `chore(ms-ai-architect): refresh KB <fil>`
+  (`kb-update.md:180-189`); bulk commit `git add skills/` (`kb-update.md:196`).
+- **Existing defenses are substantial — but aimed at correctness, not
+  adversarial content.** Authority-source binding (`lib/authority.mjs`),
+  verify-out with an adversarial refutation panel (`lib/verify-out.mjs`; status
+  claims are *always* flagged), the born-verified judge (v3.1), the create-guard,
+  and the "never auto-fix KB — flag → human → fix" discipline all answer *"is
+  this claim true against its authority?"* None of them answers *"is this fetched
+  chunk trying to inject instructions or smuggle an invisible payload?"* G6 §8
+  states this precisely: *"Tillit til MS Learn dekker faktisk korrekthet — ikke
+  adversarielt innhold i kanalen eller i kodeeksempler/lokalisert stoff."*
+
+**That is the gap this brief closes.** It is orthogonal to the correctness
+machinery, and must not replace or weaken it.
+
+## 3. Threat model
+
+- **Vector.** Microsoft Learn is authoritative for its core docs, but it has
+  surfaces that are community-contributable or machine-ingested and *not* authored-
+  and-reviewed to the same standard: **code samples**, **localized strings**,
+  community doc contributions, and Q&A / forum-ingested material where fetched.
+  An adversary who lands a payload in one of those surfaces gets it fetched,
+  summarized, and **persisted** into a reference file.
+- **Payload classes.** Indirect prompt injection (imperative text aimed at a
+  future reading agent: spoofed `<system>` blocks, "note to the assistant…",
+  identity redefinition), invisible-character / bidi steganography, and
+  encoded (base64/hex) smuggling — especially inside fenced **code blocks**,
+  which G6 explicitly flags and which a correctness judge will happily pass as
+  "a valid code sample."
+- **Impact.** Persisted once, re-served to all downstream sessions. Because the
+  KB loads as instruction-adjacent context, a successful payload is a
+  supply-chain compromise of every consumer, not a single bad answer.
+
+## 4. Architecture reconciliation (read this before choosing a layer)
+
+The sibling repo `llm-ingestion-pipeline-security` establishes the principle:
+*defense belongs at the layer where the fetch and the LLM call actually happen.*
+Applied honestly, that principle points in **opposite directions** for two
+plugins, and the difference is the whole design:
+
+- **`claude-code-llm-wiki`** calls the Anthropic SDK from a **standalone script**.
+  Claude Code plugin hooks never fire there, so the `llm-security` plugin is the
+  *wrong layer* — its defense must live in the pipeline code.
+- **`ms-ai-architect`** fetches **in-session via MCP**. Here the `llm-security`
+  plugin's `post-mcp-verify` hook *does* fire and *does* scan MCP tool output
+  (including `microsoft_docs_fetch`). So the plugin is the **right layer for the
+  input scan** — which is exactly why G6 layer (a) is coherent.
+
+But right-layer is **not sufficient**, for two reasons:
+
+1. **Hooks are unreliable headless** (GH #36071, flagged in STATE). This is
+   partly mitigated because kb-update *apply* is in-session-only by design
+   (`kb-update.md:237`), but the R7+ judge-pass and any future automation cannot
+   depend on a hook firing.
+2. **The hook scans the input, not the artifact.** `post-mcp-verify` sees the MCP
+   response; it does **not** see what the model writes to `skills/**/*.md` after
+   transformation. The persisted file is the poisoning vector, and nothing
+   currently scans it before commit (the commit gate is gitleaks = secrets only).
+
+**Conclusion:** the deterministic, always-on **output scan before commit** is the
+load-bearing gate for *both* plugins. The plugin hook is an in-session
+early-warning bonus that happens to apply here — valuable, but not the gate.
+
+## 5. The two-layer gate, hardened
+
+Building on G6/R6, with the emphasis corrected per §4:
+
+### Layer A — input scan (in-session, advisory / early warning)
+
+- `llm-security` active and `post-mcp-verify` verified firing in every in-session
+  fetch (kb-update apply, generate-skills, research, R7+ judge-pass). This is the
+  G6 activation rule — already in effect for fetch sessions (STATE bears it).
+- **Sanitize + spotlight-fence fetched content before it reaches the transform /
+  judge model.** Strip carrier classes (invisible chars, bidi, HTML comments)
+  and wrap the fetched markdown as untrusted data in `transform-prompt.md` and
+  `judge-claim-prompt-v3.1.md`, so the *in-session* model itself is not steered.
+  (This protects the transform step; Layer B protects the artifact.)
+- Treat Layer A as **advisory**. It must never be the sole gate, because of §4.1.
+
+### Layer B — output scan before commit (deterministic, always-on, authoritative)
+
+This is the gate. A deterministic Node scan (unicode / decode / injection —
+covering prose **and fenced code blocks**) over changed `skills/**/*.md`, wired in
+at two existing chokepoints so it runs regardless of any hook:
+
+1. **Into the create-guard.** Add a security-scan sibling to
+   `validate-kb-file.mjs` (`kb-update.md:134`): a file that fails the adversarial-
+   content scan is never written — same shape as the existing "transform.mjs never
+   writes / create-guard before write" invariant.
+2. **Before commit.** Scan the staged `skills/**/*.md` set before the
+   `chore(...): refresh KB` commit (`kb-update.md:189,196`). A hit blocks the
+   commit.
+
+### Disposition — provenance-tiered, composed with existing discipline
+
+- Reuse the existing authority/`**Source:**` machinery (`lib/authority.mjs`) to
+  tag each fetched chunk's **provenance trust**: authored-doc vs code-sample vs
+  localized vs community/Q&A.
+- **High-severity injection in a low-trust chunk → hard-fail / quarantine** (never
+  written). **Any-severity in a high-trust chunk → WARN + human review.** Source
+  trust is a first-class input to disposition, not a global constant
+  (mirrors the sibling brief's principle 4.7).
+- An injection flag routes to the **same human-in-loop** as a status-claim flag:
+  quarantine, operator adjudicates, never auto-committed. No new mechanism — this
+  reuses "never auto-fix KB — flag → human → fix."
+
+## 5b. Layer A-aktiveringsprotokoll (R7-gate)
+
+R7 (og enhver senere fetch-økt) starter **ALDRI** før denne sjekklisten passerer. Den
+operasjonaliserer Layer A som en hard R7-gate, ikke bare en aktiveringsregel:
+
+1. **Aktiver hooken.** Slå på `llm-security`s `post-mcp-verify` i `~/.claude/settings.json`
+   (PostToolUse på `microsoft_docs_fetch`). Dette er en konfig-endring i operatørens
+   `settings.json`, ikke i plugin-repoet.
+2. **Verifiser at den fyrer.** Kjør ÉN live **foreground** `microsoft_docs_fetch` og bekreft
+   at `post-mcp-verify` faktisk fyrte (observer hook-output). En hook som ikke observeres fyre
+   teller som IKKE aktiv.
+3. **Kompenserende skann hvis den ikke fyrer.** Fyrer den ikke (headless / GH #36071), kjøres
+   den kompenserende deterministiske skannen **foreground** på den komponerte artefakten FØR
+   write: Layer B (`scan-adversarial-content.mjs`) + Step 3s pre-write unicode/carrier-scan
+   (`detectAdversarial` uten `path` → temp-fil, R6 Step 3). Denne er alltid-på og autoritativ
+   (§5 Layer B); Layer A er kun tidlig-varsling.
+4. **Frossen judge → foreground er obligatorisk.** Det fetchede innholdet **prompt-fences IKKE**
+   inn i judgen: v3.1-judgen er frosset (G1-adoptert), og å legge til fencing ville være en
+   judge-bump (Non-goal §7, krever re-måling av P/R). Uten judge-side fencing er **foreground
+   fetch obligatorisk** — det er det som lar Layer A-hooken (og operatørens øye) se innholdet
+   før judgen. (§5s fencing-ambisjon gjelder transform-steget, ikke den frosne judgen.)
+5. **Bekreft Layer B-substratet før R7.** `llm-security`-sibling MÅ være til stede (ev. via
+   `LLM_SECURITY_ROOT`) — ellers fail-closer Layer B og **BLOCKer alt** (gaten blir en vegg).
+   Bekreft at `../llm-security/scanners/…` løser før første fetch.
+
+**R7 starter KUN når 1–5 er grønne.**
+
+**Rollback:** aktiveringen i pkt. 1 er reverserbar — fjern `post-mcp-verify`-oppføringen fra
+`~/.claude/settings.json` (og ev. `LLM_SECURITY_ROOT`) for å ta ned Layer A igjen. Layer B
+(deterministisk, in-repo) er upåvirket av denne rollback-en.
+
+## 6. No local solutions — the deterministic scanner is a shared asset
+
+Per house policy (*ingen lokale løsninger*, *showcase reusable patterns*): the
+Layer B scanner is **not** a bespoke ms-ai-architect script. Two horizons:
+
+- **Near-term:** run the existing `llm-security` deterministic scanners
+  (`unicode-scanner`, `injection-patterns` lexicon, entropy/base64) as a **CLI**
+  over the changed files — already ToS-safe (local scripts, no Claude), already
+  the plan of record in G6 layer (b).
+- **Target:** that same deterministic scanner is the core of the sibling
+  `llm-ingestion-pipeline-security` library. Both this plugin's Layer B and
+  `claude-code-llm-wiki`'s A13 output-lint should converge on **one**
+  implementation and **one** lexicon dataset, so the pattern table does not drift
+  into two copies. This brief is the second consumer that justifies extracting it.
+
+**Coordination (2026-07-05).** The durable cross-repo mechanism is **hub-and-spoke**:
+the canonical convergence contract lives in the hub (`llm-ingestion-pipeline-security`,
+the designated shared asset); ms-ai-architect's spoke pointer is roadmap **R19**. See the
+outgoing brief delivered to the hub repo (2026-07-05) for the proposed contract, the
+confirmed language data points (ms-ai-architect Layer B = Node), and the open
+`claude-code-llm-wiki` language brick that locks the polyglot-vs-Node-primary decision.
+
+## 7. Non-goals
+
+- **Not** a query-time guardrail (downstream sessions can layer their own).
+- **Not** a replacement for the correctness / judge / authority machinery — this
+  is orthogonal, adversarial-content defense. Both run.
+- **Not** an auto-fixer — it blocks and flags; humans adjudicate.
+- **Not** a ToS change — detection stays Claude-free; the deterministic scan is
+  local; in-session hooks are unaffected.
+
+## 8. Verification (testable, TDD / Iron Law)
+
+Write the failing tests first; no production scan code without a red test.
+
+- **Seeded adversarial fixtures blocked before commit.** A synthetic "MS Learn"
+  doc carrying (a) a spoofed `<system>` / "note to the assistant" payload, (b)
+  zero-width / bidi smuggling, (c) a base64 blob inside a code sample — each is
+  rejected by the Layer B create-guard *before* write, and blocks the commit if
+  staged. Test asserts no file written and non-zero guard exit.
+- **Clean doc passes** untouched (byte-identical), guard exit 0.
+- **Provenance tiering.** A high-severity hit in a code-sample/Q&A-tier chunk
+  hard-fails; the same string in an authored-doc-tier chunk yields WARN + review,
+  not a silent block. Test both directions.
+- **Composition with correctness.** A doc that is factually correct but carries a
+  payload is still blocked (proves the gate is orthogonal to the judge).
+- **Full suite** `node --test tests/kb-update/*.test.mjs tests/kb-eval/*.test.mjs`
+  exit 0; corpus untouched by the security-code change.
+- **Layer A firing check** documented for one live fetch session
+  (`post-mcp-verify` observed firing), with the headless caveat noted.
+
+## 9. Relationship to the roadmap
+
+This brief IS the design for **R6 punkt (d)** / **G6 §8**. Sequencing is
+unchanged: gate designed at R6, enforced from R7 and in the kb-update cadence.
+The G6 **activation rule already applies immediately** to any fetch session
+(`/architect:kb-update`, `generate-skills`, research, judge-pass) — this brief
+does not change that; it specifies what the enforced gate must do.
+
+## 10. Verification log (sources; what is code-verified vs manifest-sourced)
+
+- **Code-verified (read directly this session):** the in-session-MCP architecture,
+  fetch tools, write/commit chokepoints, and existing defenses — all from
+  `commands/kb-update.md` (line refs cited inline) and `CLAUDE.md`.
+- **Decision text:** G6 register and R6 punkt (d) quoted from
+  `docs/ref-kb-correctness-program-2026-06.md` §8 and
+  `docs/plugin-roadmap-2026-07.md`.
+- **Manifest-sourced, confirm in code before wiring:** the exact write/commit
+  insertion points for `generate-skills`, `research`/`research-agent`, and the
+  R7 judge-pass follow the same pattern per `CLAUDE.md:39,56` but were not read
+  line-by-line here (an initial recon subagent was interrupted by a model usage
+  limit; this brief is grounded in the files read directly by the main session).
+  The implementing session must confirm those insertion points against the live
+  command/agent code before wiring Layer B into them.
+- **Sibling contract:** `llm-ingestion-pipeline-security/docs/BRIEF.md` (the
+  write-time ingestion contract and the source-trust disposition principle).

docs/kb-mechanism-redesign-brief.md

@@ -0,0 +1,36 @@
+# 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.**

docs/kb-mechanism-redesign-plan.md

@@ -0,0 +1,383 @@
+# Spec — Redesign av KB-kunnskapsmekanismen (ms-ai-architect)
+
+_Godkjent plan (operatør, 2026-06-19). Avløser planleggings-input i `kb-mechanism-redesign-brief.md`. Implementeres én sesjon per økt; STATE.md peker på neste sesjon._
+
+## Context
+
+Kunnskapen pluginen leverer (389 referansefiler over 5 skills) er dens kjerneverdi; de 29 kommandoene/12 agentene er bare leveringsmekanismer oppå den. Dagens `kb-update`-mekanisme er **URL- og metadata-forankret**: den ser bare endring i sider den *allerede* siterer, måler «endret» på sitemap-`lastmod` (ikke faktisk innhold), og forankrer status-påstander (GA/preview/versjon) mot en *tilfeldig sitert* side — som ga en reell regresjon (agentic-retrieval-status ble «korrigert» feil; hovedkontekst måtte rette manuelt).
+
+Empiri fra søk-først kvantifiserer problemet:
+- **35 % av KB-en (468/1344 URLer) er `not_in_sitemap`** → «alltid stale». For Azure AI Foundry er det **100 % (164/164)** fordi MS restrukturerte URL-rommet — kjerne-produktet gir aldri et currency-signal.
+- **0 % av filene har en maskinlesbar `Source:`-header** → en forankret per-fil-verifisering har ingen inngangsdata i dag.
+- **Discovery er en dead-end:** `discover-new-urls.mjs` skriver `discovery-report.json` som *leses av ingenting*; nye sider registreres aldri. Kurs (`/training/`) er eksplisitt ekskludert.
+- **Fire divergerende taksonomier** styrer i dag hva som er «i domenet» (poll-prefikser, discovery-INCLUDE, skill-gen-kategorier, prioritets-regex) — allerede inkonsistente.
+
+**Mål:** en mekanisme som holder de eksisterende skills *oppdatert* (currency), *komplette* (nye sider + kurs) og *optimaliserte* (målbar kvalitet), med **auto-deteksjon (scheduled) og operatør-gate på all skriving**. Utfall: pluginen «står på egne ben» — mindre avhengig av manuell hovedkontekst-verifisering, uten å miste operatør-kontroll over innholdet.
+
+### Låst scope og retning (operatør, 2026-06-19)
+- **I scope:** krav 1 currency · 2 completeness (nye sider + kurs) · 4 optimalisering av eksisterende skills.
+- **UTE av scope:** krav 5 (lage nye skills) · krav 6 (slå sammen/slette skills). Innhold kan *vokse* (nye ref-filer ok), men **ingen destruktive ops**.
+- **Autonomi:** deteksjon kjører automatisk → rapport; **all** KB-skriving + URL-registrering går gjennom operatør-gate.
+- **Verifisering:** hver faktapåstand forankres mot en *utpekt* autoritetskilde; status-påstander (GA/preview/versjon/pris) flagges **alltid** for operatør.
+- **Kurs:** Microsoft Learn **Platform API** direkte (krever Entra ID app-registrering; verifisert: app-only, scope `https://learn.microsoft.com/.default`, `api-version=2023-11-01-preview` obligatorisk, 100 calls/min, ingen betaling). Legacy Catalog API er deprecated «through June 2026» → kill-switch-fallback.
+
+## Arkitektur — 6 lag oppå delt registry
+
+```
+0. TAKSONOMI         data/domain-taxonomy.json — én sannhetskilde for "i domenet"
+                     (poll, discovery, skill-gen, prioritet leser HERFRA)
+1. DETEKSJON         currency + completeness + kurs → produserer KUN rapporter
+2. DECISION-LEDGER   data/decisions.json — eneste skrive-autoriserte bro;
+   / OPERATØR-GATE    dedup så avviste kandidater ikke re-foreslås
+3. VERIFISERING-INN  autoritetskilde-binding på godkjente kandidater
+4. TRANSFORMASJON    doc→KB-fil (LLM-destillasjon, status-felt obligatorisk)
+5. VERIFISERING-UT   adversarial "prøv-å-motbevis" + status-gate
+                     (fanger regresjons-klassen — kjøres ETTER transformasjon)
+6. EVAL/OPTIMALISERING  rubrikk K1–K9 (uavhengig av 1–5)
+```
+
+**Lag 0** og **lag 2** er ikke valgfrie: uten konsolidert taksonomi blir completeness til silent misrouting; uten decision-ledger + dedup drukner gaten operatøren → autonomien blir teater (primær-fallgruve). Verifisering er bevisst splittet i **inn** (lag 3) og **ut** (lag 5) fordi den kjente regresjonen er en *post*-transformasjons-feil.
+
+## Roadmap (multi-sesjon, én økt per sesjon)
+
+| Sesjon | Leveranse | Verifiserbart kriterium |
+|---|---|---|
+| **1** | **Eval-baseline + ai-foundry-probe** (read-only) | `node eval.mjs --json \| jq '.skills\|length' == 5`; 10 ai-foundry-URLer kategorisert {redirect/dead/ny-sti} med beslutning |
+| **2** | Taksonomi-konsolidering (lag 0) + registry-skjema (`authority_source`, `status`, kurs-felt) + ai-foundry signal-fiks | `grep -c "TARGET_PREFIXES = \[" scripts/kb-update/*.mjs == 0`; ai-foundry `not_in_sitemap` < 50 % |
+| **3** | Decision-ledger (lag 2) + lukk discovery-løkken gjennom gaten | Discovery 2× re-foreslår ikke en `rejected` URL (dedup-diff) |
+| **4** ✅ | Verifisering-ut (lag 5) + adversarial regresjonstest | ✅ Kjent agentic-retrieval-regresjon som fixtur → `flagged:true`, ikke `auto-applied` (se Sesjon 4-resultater) |
+| **5** | Transformasjonslag (lag 4) + 2 carry-forward cleanups (foldet inn 2026-06-19) | Regenerer 1 fil → eval-score ≥ baseline |
+| **Parallelt spor** | Kurs / Platform API-spike (Entra-app + token + date/product-filter) — **av kritisk vei** | `poll-training.mjs` ≥1 kurs m/ `last_modified`; ELLER kill-switch→legacy dokumentert |
+
+Scheduled deteksjon (`/schedule` eller hook) + wiring i `commands/kb-update.md` = siste integrasjonssteg etter lag 1–3.
+
+## Sesjon 1 (detaljert)
+
+**Del A — Eval-baseline (lag 6, flyttet fram):** nytt read-only script som kjører K2/K3/K5/K6 (grep/wc) på alle 5 `SKILL.md` + refs, og LLM-judge (Opus) for K1/K4/K7/K8/K9 på de 5 `SKILL.md`. Output `eval-baseline.json` (skrives kun etter operatør-gate) = referansen alt senere måles mot.
+
+**Del B — ai-foundry signal-probe (riskeste antakelse, ren read):** 10 `not_in_sitemap` ai-foundry-URLer → `microsoft_docs_fetch` → kategoriser {finnes/redirect/ny-sti}. Avgjør om Sesjon 2 er en poll-fiks eller en re-mapping-oppgave.
+
+### Rubrikk K1–K9 (krav 4, «optimalisert skill»)
+- K1 trigger-presisjon (LLM, 20 test-prompts ≥90 %/≤10 %) · K2 tredjeperson/format i description (regex) · K3 SKILL.md ≤500 linjer (wc) · K4 ingen SKILL.md↔ref-duplisering (LLM ≥4/5) · K5 progressive disclosure: navngitte filer ikke mapper (grep, ratio ≥20 %) · K6 kjernefil-routing-tabell finnes (grep) · K7 imperativ-stil (LLM ≥80 %) · K8 kildehenvisning i ref-filer (LLM ≥80 %) · K9 ingen tid-sensitiv info i SKILL.md body (LLM).
+
+## Gjenbruk vs. nybygg (navngitte filer)
+
+**Gjenbruk direkte:** `scripts/kb-update/lib/sitemap-stream.mjs`, `lib/url-normalize.mjs`, `lib/registry-io.mjs`, `lib/atomic-write.mjs` + `lib/backup.mjs` (← for **all** gated skriving), `poll-sitemaps.mjs`-kjernen, `generate-skills.md` 5-parallelle fan-out + `prompt-template.md`.
+
+**Må endres:** `discover-new-urls.mjs` (INCLUDE → poll-paritet + ikke-bare-engineering; skriv decision-ledger-input); `report-changes.mjs` (`getFilePriority` leser taksonomi; datoløse filer = «uverifisert», ikke critical-støy); `build-registry.mjs` (les `Source:`-header → `authority_source`); `commands/kb-update.md` (apply leser decision-ledger); `scripts/skill-gen/category-skill-map.json` (inn i taksonomien).
+
+**Nytt:** `data/domain-taxonomy.json`, `data/decisions.json`, `data/training-registry.json`, `poll-training.mjs`, eval-script (K1–K9) + `eval-baseline.json`, doc→KB-destillasjons-prompt, adversarial motbevis-prompt.
+
+**Multi-agent gir kvalitet (senere):** lag 5 (adversarial motbevis-panel per status-påstand), lag 4 (parallell doc→KB-transformasjon). Foreslås når fasene starter.
+
+## Risiko (rangert) og håndtering
+1. **Gaten drukner operatøren → autonomi blir teater** (primær). → decision-ledger + dedup (lag 2); riktig klassifisering av datoløse/`not_in_sitemap`-filer (Sesjon 2).
+2. **ai-foundry = re-mapping, ikke poll-fiks** (35 % av KB). → testes først (Sesjon 1 Del B).
+3. **Platform API-onboarding blokkerer** (ekstern). → av kritisk vei + kill-switch→legacy.
+4. **Taksonomi-drift → misrouting.** → lag 0 før discovery lukkes.
+5. **Transformasjon innfører regresjon.** → eval-baseline før-måling; lag 5 adversarial-test før vi stoler på laget.
+
+## Verification (overordnet)
+- Per-sesjon kriterier (tabell) er kjørbare sjekker.
+- Pluginens gates ved hver commit: `validate` (239+), `kb-integrity` (115/115), `gitleaks` clean.
+- Arkitektur-invariant: deteksjon skriver *aldri* til KB direkte — kun via `decisions.json` etter gate (deteksjon-scripts importerer ikke write-utils).
+
+## Inneværende scope vs. fremtidig roadmap
+
+**Inneværende mekanisme-arbeid (Sesjon 1–5 + kurs-spor):** krav 1 currency · 2 completeness · 4 optimalisering — på de eksisterende 5 skills. Innhold kan vokse (nye ref-filer).
+
+**Utsatt til senere faser — på roadmap, IKKE forkastet** (operatørens valg 2026-06-19 var «krav 1–4 nå»; krav 5/6 var merket «ikke nå», dvs. utsatt):
+- **Krav 5 — lage nye skills profesjonelt.** Naturlig neste utvidelse når deteksjonen (lag 1) begynner å avdekke domener uten dekning (fra domene-taksonomien: f.eks. Power Platform AI / AI Builder / Power Automate, Dynamics365). Forutsetter lag 0–3.
+- **Krav 6 — slå sammen/slette skills (livssyklus, destruktive ops).** Krever egne guardrails (aldri tap av kuratert verdi) + obligatorisk operatør-gate. Vurderes etter at lag 1–6 står.
+
+Annet utsatt arbeid sporet her: **Low-currency-bøtta (51 filer)** — parkert bak redesignet; kjøres med den nye mekanikken (eller som siste enkle bøtte hvis redesignet drar ut).
+
+> Denne seksjonen ER roadmapen for fremtidige faser. Den bor i `docs/` (ikke en egen `ROADMAP.md`) per den globale «ingen lokale kontinuitets-mekanismer»-regelen, og refereres fra `STATE.md`.
+
+---
+
+## Sesjon 1 — resultater (2026-06-19) ✅ FERDIG
+
+Kriterier møtt: `node scripts/kb-eval/eval.mjs --json | jq '.skills|length'` = 5; 10 ai-foundry-URLer kategorisert. Tester: **kb-eval 13 PASS · kb-update 42 PASS (regresjon) · validate 239 PASS**. Node 25 krever eksplisitte filstier (`tests/X/*.test.mjs`), ikke katalog.
+
+### Eval-baseline (referanse for senere optimalisering — lag 6)
+Verktøy: `scripts/kb-eval/eval.mjs` (determ. K2/K3/K5/K6 + ref-tall) + operatør-gated LLM-judge (`judge-prompt.md` → `data/judge-results.json`), flettet til `data/eval-baseline.json`. Tester i `tests/kb-eval/`.
+
+Pass-matrise (K2/K3/K7/K8 ✓ for alle 5):
+- **K5 (progressive disclosure): 3/5 FAIL** — advisor (1,6 %), engineering (0 %), security (16 %) bruker mappehenvisninger; infrastructure (97 %) er forbildet å kopiere.
+- **K9 (tid-sensitiv info i SKILL.md body): 4/5 FAIL** — GA/preview-status, modellversjoner, SLA-/perf-tall ligger i body (kun advisor ren). Hører i ref-filer (currency-sporet).
+- **K4 (duplisering): 2/5 FAIL** — governance (3/5: DPIA/AI-Act/Digdir dupliserer ref-filer), security (3/5).
+- **refTall-konsistens: 2/5 FAIL** — engineering (agent-orch tabell 20 vs faktisk 24; total 149 vs 153), governance (29 vs 30).
+
+**To konkrete bugs (operatør-beslutning kreves; fikses i optimaliserings-fase, ikke nå):**
+1. **security 6×5-vekting motstrider kanonisk rubrikk:** SKILL.md body (Identity 20/Network 15/Data 20/Content 20/Compliance 15/Mon 10) ≠ `security-scoring-rubrics-6x5.md` (Compliance 25/Data 20/Identity 20/Content 15/Network 10/Mon 10). Påvirker scoring-output. → hvilken er kanonisk?
+2. **governance-SKILL.md linje 191** peker på ikke-eksisterende `drift-detection-automated-retraining.md` (faktisk: `model-performance-drift-detection.md`).
+
+K1-presisjon (0,95–1,0) er **PROVISORISK** — operatør må kuratere 20 trigger-prompts/skill. Flagg: governance-description mangler Schrems II-trigger; advisor-description er bred nok til å over-trigge mot søsken-kommandoer.
+
+### ai-foundry signal-probe → BESLUTNING for Sesjon 2
+10 URLer: **8 LIVE · 0 MOVED · 2 DEAD**. Rotårsak: MS rebrandet «Azure AI Foundry» → «Microsoft Foundry»; nye canonical-URLer under `/azure/foundry/` (i `azure_en-us_7`-sitemap), gamle `/azure/ai-foundry/` serverer fortsatt innhold men matcher aldri sitemapet → 100 % `not_in_sitemap`.
+**→ POLL-FIKS (ikke re-arkitektur av signalet):** remap registry `azure/ai-foundry/*` → `azure/foundry/*` + 2 DEAD-remappinger (`concepts/evaluation-evaluators`→`concepts/built-in-evaluators`; `agent-service`→`agents/overview`). Sitemap-`lastmod` fra `azure_en-us_7` er tilstrekkelig signal; ingen innholdshash nødvendig.
+
+---
+
+## Sesjon 2 — konkret startplan (lag 0 + registry-skjema + ai-foundry poll-fiks)
+
+**Mål:** konsolidér de fire divergerende taksonomiene til ÉN sannhetskilde, utvid registry-skjemaet, og fiks ai-foundry-blindsonen (poll-fiks). **TDD: skriv test FØR kode.** Invariant: deteksjon skriver aldri til KB; ikke rør krav 5/6.
+
+**Rekkefølge:**
+1. **Les først:** `scripts/kb-update/{poll-sitemaps,discover-new-urls,report-changes,build-registry}.mjs`, `lib/{registry-io,url-normalize,atomic-write,backup}.mjs`, `data/url-registry.json` (skjema), og `scripts/skill-gen/{categories.json,category-skill-map.json}`.
+2. **`data/domain-taxonomy.json`** (lag 0, ny): samle dagens 4 taksonomier til én — (a) sitemap-prefikser (fra `poll-sitemaps.mjs` `TARGET_PREFIXES`), (b) discover INCLUDE/EXCLUDE (utvid til poll-paritet: mangler `microsoftteams`/`sharepoint`/`microsoft-365`/`training`/`cloud-computing`/`privacy`; og ikke-bare-engineering-skill-mapping), (c) skill+kategori-mapping (`category-skill-map.json`), (d) prioritet (`report-changes.mjs` `getFilePriority`).
+3. **Refaktorer** `poll-sitemaps.mjs` + `discover-new-urls.mjs` + `report-changes.mjs` til å LESE taksonomien. **Kriterium:** `grep -c "TARGET_PREFIXES = \[" scripts/kb-update/*.mjs` == 0.
+4. **Registry-skjema** (bakoverkompatibelt): legg til `authority_source`, `status`, kurs-felt. `build-registry.mjs` leser `**Source:**`/`**Primary source:**`-header når den finnes (i dag 0 % dekning — ikke krav å backfille alle nå).
+5. **ai-foundry poll-fiks:** remap registry `azure/ai-foundry/*`→`azure/foundry/*` + 2 DEAD-remappinger (over). Bruk `lib/backup.mjs` + `lib/atomic-write.mjs` for skriving. **Kriterium:** ai-foundry `not_in_sitemap` < 50 % (fra 100 %).
+6. **Tester** (`tests/kb-update/` el. ny `tests/kb-eval/`): taksonomi-lasting + remap-logikk. Node 25 → kjør med eksplisitt filsti.
+7. **Avslutt:** `validate` 239 + alle enhetstester grønne · commit per logisk enhet · push (i vindu 20–23 hverdag) · oppdater STATE.md (Sesjon 3 neste) + denne roadmapen (Sesjon 2-resultater).
+
+**Ikke i Sesjon 2:** de 2 bug-fiksene (6×5-vekting, governance ref-path) — de hører i optimaliserings-fasen og venter på operatør-beslutning (kanonisk vekting).
+
+---
+
+## Sesjon 2 — RESULTATER (FERDIG, 2026-06-19)
+
+**Begge akseptansekriterier møtt:** `grep -c "TARGET_PREFIXES = \["` == 0 ✅ · foundry `not_in_sitemap` **38,4 %** (63/164, fra 100 %) < 50 % ✅. Tester: validate 239 · kb-update 66 (+24) · kb-eval 13 — alle grønne. 3 commits (8bea3a2 lag 0 · eb2a002 skjema · d3af3f7 remap) + docs.
+
+**Levert:**
+- **Lag 0:** `data/domain-taxonomy.json` (tracket via gitignore-negasjon `data/*` + `!domain-taxonomy.json`; generert registry/rapporter forblir ignorert). `lib/taxonomy.mjs` laster + kompilerer. `poll-sitemaps`/`discover-new-urls`/`report-changes` LESER taksonomien — ingen embeddede kopier.
+- **Registry-skjema (minimal-reservert, operatør-valg):** `authority_source:null` + `course:null` på alle 1343 entries. `build-registry` leser `**Source:**`-header via `lib/kb-headers.mjs` og logger dekning (0/N i dag). Eksisterende poll-`status` urørt (unngikk kollisjon).
+- **ai-foundry-fiks:** `lib/registry-migrate.mjs` + one-shot `migrate-ai-foundry.mjs` (backup + atomisk). 164 remappet, 2 DEAD eksplisitt, 1 kollisjon merget, remappede → `unpolled`.
+
+**Konsolideringsfunn (binding for Sesjon 3):**
+- **`category-skill-map.json` er stale i 4 entries** (`copilot-extensibility`, `monitoring-observability`, `performance-scalability`, `prompt-engineering` → sier `engineering`; **disk** sier advisor/governance/security/advisor). Disk er kanon; taksonomien bruker disk-sannhet. Map-en er **ukonsumert av kode** (kun README) → flagget, ikke rørt. **Sesjon 3-kandidat:** korriger/avskilt `category-skill-map.json` + README, ELLER bekreft taksonomien som eneste kilde.
+- **Datoløse-filer-reklassifisering** (getFilePriority: datoløs = «uverifisert» i stedet for critical-støy): **utsatt** (ekskludert fra Sesjon 2 per operatør-valg — adferdsbevarende refaktor nå). **Sesjon 3-kandidat.**
+- **foundry/openai-tail:** 63 gjenstående `not_in_sitemap` er nesten utelukkende `/azure/foundry/openai/*` (egen URL-struktur, ikke probet). Ingen gjettede remaps. Kandidat for målrettet probe senere.
+
+---
+
+## Sesjon 3 — konkret startplan (lag 2: decision-ledger + lukk discovery-løkken)
+
+**Mål:** bygg `data/decisions.json` som **eneste skrive-autoriserte bro** mellom deteksjon og KB/registry, med **dedup** så avviste kandidater aldri re-foreslås. Dette løser primær-fallgruven (gaten drukner operatøren → autonomi blir teater). **TDD: skriv test FØR kode.** **Invariant (§83): deteksjon-scripts importerer ALDRI write-utils** (`atomic-write`/`backup`/`saveRegistry`) — de kun LESER ledger for å filtrere; skriving til ledger skjer kun via operatør-gate.
+
+**Rekkefølge:**
+1. **Les først:** `scripts/kb-update/discover-new-urls.mjs` (kandidat-output `discovery-report.json`: `{url, lastmod, sitemap, suggested_skill, suggested_category}`), `commands/kb-update.md` (apply-flyt = gaten), `lib/registry-io.mjs` (`saveReport`/atomisk-mønster å speile), `lib/taxonomy.mjs` + `lib/registry-migrate.mjs` (Sesjon 2-mønstre for ren-funksjon-+-tynn-script-split).
+2. **`data/decisions.json`-skjema** (lag 2, nytt — tracket som `domain-taxonomy.json`, IKKE generert): ledger keyet på normalisert URL. Per entry: `{status: pending|approved|rejected, decided_at, suggested_skill, suggested_category, note?}` + toppnivå `version`/`updated_at`. **Beslutningspunkt:** dedup ekskluderer KUN `rejected`, eller alle `decided` (approved teller som «allerede håndtert»)? Anbefalt: ekskluder alle `decided` fra re-forslag; `pending` beholdes til operatør avgjør.
+3. **`lib/decisions-io.mjs`** (ren I/O, speil `registry-io`): `loadDecisions`/`saveDecisions` (atomisk), `isDecided(ledger, url)`, `recordDecision(ledger, url, decision)`. TDD-test først.
+4. **discover dedup:** `discover-new-urls.mjs` LESER `decisions.json`, filtrerer ut alt som er `isDecided` FØR kandidater emitteres. Nye → `pending` (eller fravær = ubesluttet). **Kriterium:** kjør discover 2×, en `rejected`-URL re-foreslås IKKE (dedup-diff-test mot fixture).
+5. **Gate-wiring (`commands/kb-update.md` apply):** apply-steget viser `pending`-kandidater → operatør approve/reject → skriver `decisions.json` (ENESTE skrivevei) → `approved` registreres i `url-registry` (gated, via `registry-io`). Script-siden leverer ledger-I/O + «pending»-visning; selve interaktive apply er LLM-drevet (slash-command). Dokumentér flyten.
+6. **Invariant-guard-test:** assert at `discover-new-urls.mjs` IKKE importerer `atomic-write`/`backup`/`saveRegistry` (grep-test). + decisions-io + dedup-tester. Node 25 → eksplisitt filsti.
+7. **Avslutt:** `validate` 239 + alle enhetstester grønne · commit per logisk enhet · push (vindu 20–23 hverdag) · oppdater STATE.md (Sesjon 4 neste) + denne roadmapen (Sesjon 3-resultater).
+
+**Også vurder i Sesjon 3 (Sesjon 2-funn, operatør-beslutning):** (a) `category-skill-map.json` stale i 4 entries — korriger/avskilt + README, ELLER bekreft taksonomi som eneste kilde; (b) datoløse-filer-reklassifisering i `getFilePriority` (datoløs = «uverifisert», ikke critical-støy). Begge er små; ta dem hvis tid, ellers eksplisitt til Sesjon 4.
+
+**Ikke i Sesjon 3:** lag 3 (verifisering-inn), lag 4/5 (transformasjon/verifisering-ut), kurs-sporet, de 2 SKILL.md-bugene (6×5-vekting, governance ref-path — venter på kanonisk-vekting-beslutning).
+
+---
+
+## Sesjon 3 — RESULTATER (FERDIG, 2026-06-19)
+
+**Akseptansekriterium møtt:** dedup-diff — en `rejected` URL foreslås i runde 1, men **ikke** i runde 2 (test `dedup-diff — a rejected URL is re-proposed in round 1 but NOT in round 2`). Tester grønne: validate **239** · kb-update **82** (+16) · kb-eval **13** · kb-integrity **115/115**.
+
+**Dedup-policy = A (operatør-valg 2026-06-19):** `isDecided(url)` = enhver ledger-entry. Alt operatøren har tatt stilling til — approved, rejected *og* utsatt (pending) — dedupes; discovery re-foreslår kun URLer som er **helt fraværende** fra ledgeren. Renest å resonnere om, og den eneste som fullt nøytraliserer primær-fallgruven (gate-støy). Pending vises i egen bøtte fra ledgeren, ikke som påtrengende re-forslag.
+
+**Levert:**
+- **`data/decisions.json` (lag 2):** tracket via gitignore-negasjon (som `domain-taxonomy.json`; generert registry/rapporter forblir ignorert). Skjema: `{version, updated_at, decisions: {[normalisertUrl]: {status, decided_at, suggested_skill, suggested_category, note?}}}`.
+- **`lib/decisions-io.mjs`** (speiler `registry-io`-stil, null avhengigheter): `createLedger` · `loadDecisions` · `saveDecisions` (atomisk .tmp→rename) · `isDecided` (policy A) · `recordDecision` (ren, muterer ikke) · `filterUndecided`. TDD: 10 tester FØR kode.
+- **discover-wiring:** `discover-new-urls.mjs` LESER ledger (`loadDecisions`+`isDecided`), filtrerer i kandidat-løkken, rapporterer `deduped_by_ledger` i `discovery-report.json` + logg. **Importerer ALDRI write-utils.**
+- **Gate dokumentert** i `commands/kb-update.md` §3b («Discovery-gate»): eneste skrivevei = `recordDecision`+`saveDecisions`; `approved` → `url-registry` (gated via `saveRegistry`); `decided_at` caller-injisert. Apply er LLM-drevet per design (ikke eget apply-script — lib gir deterministisk skrivevei).
+- **Invariant-guard-test** (`test-discover-invariant.test.mjs`, 6 tester): import-spesifikk sjekk at discover IKKE importerer `saveDecisions`/`saveRegistry`/`atomic-write`/`backup` (kommentarer kan ikke gi falske positiver) + positiv sjekk at `loadDecisions`/`isDecided` faktisk er wiret.
+
+**Binding for Sesjon 4:**
+- **IKKE tatt** (var «hvis tid»): `category-skill-map.json`-stale (4 entries) og datoløse-fil-reklassifisering i `getFilePriority`. Prioriterte kjerneleveransen + sporet onboarding-redesign i stedet. **Eksplisitt til Sesjon 4.**
+- **Nytt sporet sidespor (operatør-flagget 2026-06-19):** onboarding-/virksomhetskontekst-mekanismen oppfyller ikke «ambient i enhver interaksjon» + «overlever oppgraderinger» + mangler fritekst-felt → egen brief `docs/onboarding-redesign-brief.md` (task #26). Utenfor KB-redesignet; design godkjennes separat.
+- **Neste — Sesjon 4:** verifisering-ut (lag 5) + adversarial regresjonstest. Kriterium: kjent agentic-retrieval-regresjon som fixtur → `flagged:true`, ikke `auto-applied`.
+
+---
+
+## Sesjon 4 — RESULTATER (FERDIG, 2026-06-19)
+
+**Akseptansekriterium møtt:** den kjente agentic-retrieval-regresjonen som fixtur → `verdict: 'flagged'`, `status_claim: true`, IKKE `auto-applied` (test `agentic-retrieval regression fixture → flagged, NOT auto-applied`). Tester grønne: validate **239** · kb-update **95** (+13) · kb-eval **13** · kb-integrity **115/115**. gitleaks: 3 PRE-EKSISTERENDE i `playground/vendor/` (utenfor scope); nye filer rene.
+
+**Hva lag 5 er:** verifisering-UT kjører ETTER transformasjon (lag 4) og FØR en kandidat-endring skrives til en KB-fil. Den fanger regresjons-klassen — en status-påstand «korrigert» mot en *tilfeldig sitert* side og stille auto-applyet. Den faktiske regresjonen ligger i KB: `agentic-rag-patterns.md` beskriver «delvis GA via REST `2026-04-01`; answer synthesis + multi-turn forblir preview» — en naiv auto-correct ville flatet dette til «GA» og slettet nyansen.
+
+**Regel (spec §21):** status-påstander (GA/preview/versjon/pris) flagges **ALLTID**, aldri auto-applyet — uansett hvor sikker evidensen ser ut. Denne regelen alene bærer kriteriet.
+
+**Levert:**
+- **`lib/verify-out.mjs`** (ren klassifiserer, null avhengigheter — speiler `decisions-io`): `detectStatusClaim(text)` → `{isStatus, kinds[]}` (release-stage / version / price; `\bGA\b` er case-SENSITIV for å unngå norsk «ga»; bare kalenderdato ≠ status, kun `-preview`-versjoner teller). `classifyChange(change)` → `{verdict: 'flagged'|'auto-applied', status_claim, reasons[]}` med tre flag-regler: (1) **status-gate** (§21), (2) **adversarial refutering** (`refutations[].refuted===true`), (3) **autoritets-mismatch** (`source_url` ≠ utpekt `authority_source` — regresjonens rotårsak; inert mens `authority_source` er null pre-lag-3). Konservativ med vilje: ved tvil flagges. **SKRIVER ALDRI** — returnerer kun en verdict.
+- **Fixtur** `tests/fixtures/kb-update/agentic-retrieval-regression.json`: den kjente regresjonens FORM (flat «generally available (GA)» mot nyansert «delvis GA … resten preview», forankret mot ikke-autoritativ `whats-new`-side). Verdiene er illustrative for regresjonen, ikke en currency-påstand (verifiseringsplikt).
+- **TDD:** 13 tester FØR kode (`tests/kb-update/test-verify-out.test.mjs`), inkl. import-invariant (`verify-out.mjs` importerer ingen write-utils — ren klassifiserer).
+- **Wiret i `commands/kb-update.md` §4 c2:** lag 5 kjører mellom (c) identifiser-endring og (d) skriv. `flagged` → operatør avgjør; `auto-applied` → trygt. Adversarial motbevis-panel er LLM-runtime (multi-agent foreslås i produksjon, §71).
+
+**Binding for Sesjon 5:**
+- **FOLDET INN i Sesjon 5** (operatør-valg 2026-06-19) — to carry-forward cleanups, bevisst holdt utenfor lag-5-kriteriet:
+  - **(A) `category-skill-map.json` — 4 stale entries:** `copilot-extensibility`/`monitoring-observability`/`performance-scalability`/`prompt-engineering` sier `engineering` i map-fila, men disk-sannhet er advisor/governance/security/advisor (Sesjon 2-funn §151). Map-en er **ukonsumert av kode** (kun README). → korriger map + README, ELLER bekreft `domain-taxonomy.json` som eneste kilde og deprecér/slett map-fila.
+  - **(B) datoløse-fil-reklassifisering i `getFilePriority` (`report-changes.mjs`):** datoløse filer skal være «uverifisert»-prioritet, ikke critical-støy (Sesjon 2-funn §152). Adferdsendrende refaktor → TDD, test FØR kode.
+- **`authority_source`-feltet er fortsatt 0 % dekning** (registry); lag 5-regel 3 (autoritets-mismatch) er derfor inert i praksis i dag — den aktiveres når **lag 3 verifisering-INN** (egen fremtidig fase) backfiller feltet. Status-gaten (regel 1) er full virksom uavhengig.
+- **Neste — Sesjon 5:** transformasjonslaget (lag 4, doc→KB-fil, LLM-destillasjon med obligatorisk status-felt) **+ cleanup (A) og (B) over**. Kriterium (lag 4): regenerer 1 fil → eval-score ≥ baseline. Lag 5 (Sesjon 4) er motbevis-gaten lag 4 mates gjennom før skriving.
+
+---
+
+## Sesjon 5 — RESULTATER (FERDIG, 2026-06-19)
+
+**Akseptansekriterium møtt:** «regenerer 1 fil → eval-score ≥ baseline» — test `regenerate 1 real file → valid, dated, source-anchored, body preserved, same path` + `live deterministic eval ≥ baseline for ms-ai-infrastructure` (`tests/kb-eval/test-transform-criterion.test.mjs`). Tester grønne: **validate 239 · kb-update 111 (+16) · kb-eval 15 (+2) · kb-integrity 115/115**. gitleaks: rent på changeset (3 pre-eksisterende i `playground/vendor/` urørt).
+
+**Lag 4 levert (`lib/transform.mjs`, ren lib, SKRIVER ALDRI — speiler decisions-io/verify-out):**
+- `buildKbHeader({title, status, category, source, lastUpdated})` → deterministisk header. **`Status` + `Source` obligatoriske** (kaster ved manglende felt). **Nøkkelfunn/-fiks:** den gamle `prompt-template.md` la kilder i en bunn-seksjon, men `build-registry`/`kb-headers.parseSourceHeader` skanner kun **øverste 500 bytes** → derfor `authority_source`-dekning = 0 %. Lag 4 legger `**Source:**` i header-blokka → det er dette som lar lag 3 (fremtidig) backfille `authority_source` og lag-5 regel 3 fyre.
+- `validateKbFile(content)` → `{valid, missing[]}` (title/last_updated/status/source); bruker `parseSourceHeader` så «hva er en Source-header» har én sannhetskilde med build-registry.
+- `buildChange({field, oldValue, newValue, sourceUrl, authoritySource, refutations})` → eksplisitt lag-4→lag-5-bro; mater rett inn i `classifyChange` (verifisert: status-endring → `flagged`, ikke-status → `auto-applied`).
+- `resolveTargetPath(tax, category, filename)` → ruter via taksonomiens `getCategorySkill` (disk-sann); `null` = ukjent kategori → gate, ikke skriv.
+- **Prompt:** `scripts/kb-update/transform-prompt.md` (doc→KB-destillasjon; gjenbruker husformatet fra `prompt-template.md`, men Source i header + status-påstander eksplisitt for lag-5-gaten). Deterministisk header bygges av lib-en, ikke modellen.
+- **Wiret i `commands/kb-update.md`:** §3.d (ny godkjent URL → fetch → destillér → buildKbHeader → validateKbFile → buildChange→lag 5 → resolveTargetPath → operatør-gate → atomisk skriving) + §4.d (oppdateringer må også passere `validateKbFile`; legg Source-header der pre-lag-4-filer mangler den). `eval.mjs` eksporterer nå `evalSkill` for kriterium-testen.
+- **TDD:** 12 lib-tester (`test-transform.test.mjs`) inkl. import-invariant (ingen write-utils) + 2 kriterium-tester FØR kode.
+
+**Carry-forward A — `category-skill-map.json` (operatør-valg 2026-06-19: SLETT + rydd README):** premiss verifisert mot kode — fila var ukonsumert av all runtime (`docs/development.md:60` erklærte allerede taksonomien som eneste kilde; kun `README.md:654` kalte den feilaktig «used by generate-skills»). Slettet (`git rm`); README peker nå på `domain-taxonomy.json` via `lib/taxonomy.mjs` `getCategorySkill`. Fjerner en divergerende taksonomi helt (redesignets mål). `test-taxonomy.test.mjs`-kommentarer beholdt som historikk (leser kun taksonomien, ikke map-fila).
+
+**Carry-forward B — datoløse filer (TDD):** rotårsak: datoløs fil fikk `effectiveDate='0000-01-01'` (alltid «stale») **+** path-basert prioritet (kunne bli `critical`) → flommet critical-bøtta. Fix: ny **`unverified`-tier** deklarert i `domain-taxonomy.json` (lag 0). `makePriorityFn` tar nå valgfri `hasDate` (default `true` → bakoverkompatibelt); `report-changes` sender `Boolean(fileDate)`. `unverified` rangerer sist i sorteringen (metadata-hygiene, ikke currency-hast). Verifisert mot ekte registry: `Unverified: 1` skilt ut fra path-bøttene. TDD: 4 tester FØR kode (`test-priority-unverified.test.mjs`).
+
+**Binding for neste fase (numerert roadmap Sesjon 1–5 er nå FERDIG):**
+- 6-lags-arkitekturen står strukturelt: lag 0 (Sesjon 2) · lag 1 currency+completeness (eksisterende + Sesjon 3) · lag 2 (Sesjon 3) · lag 3 (Sesjon 6) · lag 4 (Sesjon 5) · lag 5 (Sesjon 4) · lag 6 eval (Sesjon 1).
+- **Gjenstår (ikke numerert — operatør prioriterer):** ~~(1) lag 3 verifisering-INN~~ ✅ FERDIG Sesjon 6. (2) **Optimaliserings-fase (krav 4-anvendelse):** fiks de målte eval-FAIL-ene (K5 progressive disclosure advisor/eng/security, K9 tid-sensitiv i body, K4 duplisering, refTall) + de 2 SKILL.md-bugene (6×5-vekting kanonisk? + governance ref-path) — krever operatør-beslutning på kanonisk vekting. (3) **Kurs-spor** (task #25, parallelt, av kritisk vei). (4) **Scheduled deteksjon** + siste integrasjon. (5) **Low-currency-bøtta (51 filer).**
+
+---
+
+## Sesjon 6 — RESULTATER (FERDIG, 2026-06-19)
+
+**Akseptansekriterier møtt:** `authority_source`-dekning **0,22 % (3/1353)** fra 0 ✅ · lag-5 regel 3 demonstrert virksom ende-til-ende med ekte data (test `rule 3 fires end-to-end on a real authority: source_url ≠ header authority → flagged`, `test-authority.test.mjs`) ✅. Tester grønne: **validate 239 · kb-update 122 (+11) · kb-eval 15 · kb-integrity 115/115**. gitleaks: rent på changeset.
+
+**Designvalg (operatør 2026-06-19): HEADER-AS-TRUTH.** En fils `**Source:**`-header ER den utpekte autoriteten for dens påstander. Vi gjetter ALDRI autoritet fra en fils mange siterte URLer — datagrunnlaget viste **251/303 ref-filer siteres av 4–10 URLer hver** (ingen entydig kilde å utlede; en gjettet autoritet ville fått regel 3 til å bomme + 303 operatør-beslutninger = primær-fallgruven). Dekning vokser organisk når lag 4 regenererer filer (lag 4 skriver alltid Source i header).
+
+**Levert:**
+- **`lib/authority.mjs`** (ren lib, SKRIVER ALDRI — speiler decisions-io/verify-out/transform; importerer kun read-only `kb-headers` + `url-normalize`): `resolveAuthority(content)` → deklarert `**Source:**`-URL (validert som http(s); fri tekst avvises — verifiseringsplikt; ikke-MS-autoritet som EU-forordning tillates) · `collectDeclaredSources(contents[])` → normalisert Set (kun MS Learn, matcher registry-nøkler) · `markUrlAuthority(url, set)` → url|null · `authorityCoverage(registry)` → `{withAuthority,total,ratio}`.
+- **`build-registry.mjs` wiret:** samler deklarerte kilder fra headere, setter per URL-entry `authority_source = url` iff en fil deklarerer den (recomputes fra headere = sannhet, ikke carry-over), logger dekning.
+- **`commands/kb-update.md` §4 c1 (ny):** `authority_source = resolveAuthority(<fil>)` mates inn i lag-5 `classifyChange` (c2). §4.d/§3.d oppdatert: lag 3 er live (ikke «senere»).
+- **Bootstrap (gated KB-skriving):** `**Source:**`-header skrevet til de **3 entydige** (1-sitert-URL) filene med rent topisk treff: `late-chunking-patterns.md` → embeddings-tutorial · `ai-red-team-operations-practical.md` → ai-red-team/training · `batch-api-usage-optimization.md` → batch-blob-storage.
+- **TDD:** 11 tester FØR kode inkl. import-invariant + ende-til-ende regel 3.
+
+**Verifiseringsfunn (binding):** den 4. «entydige» fila — `ai-act-annex-iii-checklist.md` → `purview/compliance-manager-assessments` — ble **bevisst utelatt** fra bootstrap: dens egentlige autoritet er EU-forordningen selv (fila deklarerer allerede `**Hjemmel:** Regulation (EU) 2024/1689, Annex III`), ikke en MS Purview compliance-tool-side. Å sette Purview-URLen som autoritet ville vært en gjetning som får regel 3 til å bomme. **Kandidat for senere:** sett `**Source:**` til EUR-Lex-URLen (`resolveAuthority` aksepterer ikke-MS-autoriteter; den normaliseres bare ikke inn i den MS-keyede registryen — som er riktig).
+- **`url-registry.json` er gitignored (generert):** `authority_source` er derfor avledet on-demand fra de committede `**Source:**`-headerne (sannhetskilden), ikke en committet verdi. `build-registry --merge` regenererte registryen à jour (1343→1353 URLer; build-registry er det utpekte verktøyet).
+
+---
+
+## Sesjon 7 (SPOR A — krav 4-optimalisering, deterministisk del) — RESULTATER (FERDIG, 2026-06-20)
+
+**Akseptansekriterier møtt:** K5 PASS for advisor/eng/security · refTall PASS for eng+gov · eval ellers ikke regredert (`eval --json` = akseptansemål). Tester grønne: **validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 181/181** (opp fra 115). gitleaks: rent på changeset.
+
+**Steg 1 — refTall-konsistens (commit `3c097f5`):** engineering `agent-orchestration` 20→24 (faktisk på disk) + total 149→153; fjernet inkonsistent 24/20-dobbeltsitering. governance `norwegian-public-sector-governance` 29→30. Verifisert: eval `refCountConsistency` PASS for alle 5.
+
+**Steg 2 — døde ref-paths (commit `3c097f5`):** governance §4 monitoring-bullets pekte på ikke-eksisterende filer. STATE flagget kun L191; **verifiseringsfunn:** L190 var også død. Begge fikset til ekte disk-filer: `azure-monitor-ai-services-setup`→`azure-monitor-setup-ai-workloads`, `drift-detection-automated-retraining`→`model-performance-drift-detection`. **Løser den ene av de «2 SKILL.md-bugene» (governance ref-path).**
+
+**Steg 3 — K5 progressive disclosure (commit `abac74f`, operatør-gated kuratering godkjent 2026-06-20):** fulgte infrastructure-forbildet (0,97) — full-sti `references/<mappe>/<fil>.md`-pekere til kjernefiler.
+- **Nøkkelfunn:** security + advisor hadde filene navngitt allerede, men som **bare-filnavn uten `references/`-prefiks** → ufanget av både eval-regex OG kb-integrity Check 2 (samme klasse som de døde ref-paths). K5-«failure» for disse to var i stor grad et sti-format-artefakt. Fiks = konverter bare→full sti (konservativt, bruker eksisterende kuratering).
+  - **security:** 10→16 navngitte (0,16→0,26). Konverterte 5 perf-filer (§3) + owasp (§1). Beholdt eksisterende kuratering (inkl. `gpu-compute-sizing` m/ `/architect:cost --capacity`-note) i stedet for å bytte sett.
+  - **advisor:** 1→25 navngitte (0,016→0,40). Konverterte ~18 bare-filnavn i Kunnskapsbasen + la til `model-catalog-2026` og entry-points for `copilot-extensibility`/`prompt-engineering` (40 filer som manglet ALLE navngitte pekere).
+  - **engineering:** 0→35 navngitte (0,0→0,23). Genuint 0 før (kun mappe-refs); la til `> **Kjernefiler:**`-linje med 4-6 kuraterte filer per §1-7.
+- **Bivirkning (positiv):** kb-integrity Check 2 valideringer 115→181 (de nye full-sti-refsene fanges nå), orphan-warnings 260→223.
+
+**Gjenstår i SPOR A (beslutning-gated — krever operatør-input, tas «når vi når dem»):**
+1. **6×5-vekting (den andre SKILL.md-bug-en):** security SKILL.md body-vekting (Identity 20/Network 15/Data 20/Content 20/Compliance 15/Mon 10) ≠ kanonisk `security-scoring-rubrics-6x5.md` (Compliance 25/Data 20/Identity 20/Content 15/Network 10/Mon 10). **HVILKEN er kanonisk?** Påvirker scoring-output.
+2. **K9 (tid-sensitiv info i SKILL.md body): 4/5 FAIL** — GA/preview-status, modellversjoner, SLA-/perf-tall i body. Hører i ref-filer (overlapper currency-sporet). Body-rydding = adferdsendrende → TDD.
+3. **K4 (duplisering): 2/5 FAIL** — governance + security dupliserer ref-filer i body. Krever vurdering av hva som flyttes ut.
+4. **K1 (trigger-presisjon):** PROVISORISK — operatør må kuratere 20 trigger-prompts/skill. Flagg: governance-description mangler Schrems II-trigger; advisor-description over-trigger mot søsken-kommandoer.
+
+**Spor B (senere, samme tema):** scheduled deteksjon · kurs-spor (task #25) · low-currency-bøtta (51 filer) · bredere `**Source:**`-backfill.
+
+---
+
+## Sesjon 8 (SPOR A — 6×5-vekting) — RESULTATER (FERDIG, 2026-06-20)
+
+**Akseptansekriterier møtt** (commit `1c0da88`): `grep` security SKILL.md → ingen 3-kolonne divergerende vekttabell; rubrikken har én Standard (kanonisk) + 2 dokumenterte varianter; agent+skill peker samme kilde. `eval --json` security: **K3 212→203 (pass) · K5 0,2581 uendret (16 navngitte, pass) · K6 16 (pass) · refConsistency 0 mismatch** — ingen deterministisk regresjon. Tester grønne: **validate 239 · kb-eval 15 · kb-integrity 182/182** (opp fra 181). gitleaks rent.
+
+**Antakelse-test (FØR sletting):** `grep -r` på vekttallene bekreftet at INGEN kode/test asserter SKILL.md-vektene — `security-assessment-agent` (L24) refererer kun rubrikken som OBLIGATORISK. Eneste andre treff var eval-bevis (`judge-results.json` L38 / `eval-baseline.json` L476) som beskriver selve K4-bug-en. Trygt slettet.
+
+**Endring 1 — rubrikk:** ny seksjon «Arbeidsbelastnings-profiler (adaptiv vekting)» under Vektingsmodell. Standard = kanonisk (Compliance 25/Data 20/Identity 20/Content 15/Network 10/Mon 10). Variantene utledet ved å bevare de godkjente retningsdeltaene fra SKILL.md-modellen, re-forankret til kanonisk baseline (sum 100 % begge):
+- **Eksternt eksponert:** Identity 25/Content 20/Network 15 ↑ (angrepsflate mot anonyme); Compliance 20/Data 15/Mon 5 ↓.
+- **Persondata-intensiv:** Compliance 30/Data 25 ↑; Content 10/Mon 5 ↓.
+
+**Endring 2 — SKILL.md:** fjernet divergerende 3-kolonne vekttabell → peker til rubrikken. **Risikoklassifiserings-tabellen beholdt** (per roadmap).
+
+**K4-status:** body-divergensen er løst, men K4-re-judgen er operatør-gated og hører i S9 — judge-cachen er IKKE rørt i S8 (ville fabrikkert en verdict). S9 plukker opp K4-rejudge for security.
+
+**⚠ Funn utenfor scope (flagget, ikke handlet):** SKILL.md-risikotabellen (L63-69: `3.1–3.5 = Moderat`) **divergerer** fra rubrikkens risikokategori-mapping (`2.50–3.49 = Høy`; egen «Uakseptabel»-kategori under 1,50). Roadmap sa eksplisitt «behold risikoklassifiserings-tabellen», så urørt — men dette er en reell andre-divergens på linje med vekt-bug-en. **Kandidat for egen sesjon / S9-tillegg** (operatør avgjør).
+
+---
+
+## Sesjon 9 (SPOR A — K4+K9 body-cleanup: security + governance) — RESULTATER (FERDIG, 2026-06-20)
+
+**Begge S9-kriterier møtt for begge skills** (operatør-gated LLM-judge, fersk kald re-judge): security **K4 5/5 PASS · K9 PASS**; governance **K4 5/5 PASS · K9 PASS**. Deterministisk ikke regredert — faktisk forbedret: **validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/182→192/192** (opp fra 182). gitleaks: 3 pre-eksisterende i `playground/vendor/` (utenfor changeset). Body krympet: security K3 203→191, governance K3 304→289; K5 sec 16→20 / gov 24→25 (full-sti-pekere fanges nå).
+
+**Metode (verifiseringspliktig):** to parallelle read-only verifiserings-agenter kartla FØR sletting hvor hvert body-faktum bor i ref-filer (PRESENT/PARTIAL/ABSENT). Funn styrte hva som ble *flyttet* (alt i ref), *droppet* (uverifiserte tall) eller *beholdt* (unik/stabil logikk).
+
+**Security (operatør-gated, 5 endringer):**
+- **K9:** Defender GA/preview/Azure-Gov-status → peker (alt verbatim i `defender-threat-protection-ai-services.md`). §3 ytelse: droppet **uverifiserte** tall (20-50ms, 5-10x, 80 % latens — fantes INGEN steder) + Batch/caching → pekere til faktiske ref-tall. GPT-4o-par → generisk. PTU «60-70 %» → ref. OWASP «2025» beholdt (stabil standard-versjon).
+- **K4:** risikoklassifiserings-tabellen (DIVERGERTE: 6 bånd vs 5, manglet «Uakseptabel») → peker til kanonisk rubrikk (operatør-godkjent, S8-konsistent). **Re-judge avdekket NY divergens:** P10/P50/P90-tabellen (flat ×0.6/×1.8) motsa kanonisk per-komponent-modell i `deterministic-cost-calculation-model.md` (agentens OBLIGATORISK-kilde). Antakelse-test bestått (ingenting asserter body-multiplikatorene) → tynnet til peker (samme klasse som S8-vekt + risikotabell). K4 3→5.
+- **Flagg lukket:** S8s «andre divergens» (risikotabell L63-69) er nå løst.
+
+**Governance (operatør-gated, 2 endringer):**
+- **K9:** EU Data Boundary §2.3 — droppet volatile regioner «(Sweden Central, West Europe)» (body MOTSA refs som sier «Norway East / West Europe»); behold prinsipp + lovsaksnr; repek kryss-ref → `gdpr-compliance-ai-systems.md`. Stabile identifikatorer (2024/1689, C-311/18) beholdt.
+- **K4:** §6.2 AI Act-tre — kollapset oppramset (og ufullstendig: 4 av 8) Art.5- + Annex III-lister → pekere til `ai-act-classification-methodology.md`; §2.1 eneste oversiktstabell. §6.1/§1.2/§6.3 beholdt (orientering/ruting, ikke verbatim-dup). K4 3→5.
+
+**K9-rubrikk strammet (operatør-godkjent):** `judge-prompt.md` K9 = «ingen VOLATIL info; stabile identifikatorer (forordningsår, OWASP 2025, MADR v3.0, saksnr) ute av scope» — gjør K9 PASS deterministisk oppnåelig per operatør-policyen. `judge-results.json` oppdatert med ferske sec+gov-verdikter (operatør-gated cache).
+
+**Binding for S10:** K9-destale engineering + infrastructure (feiler kun K9). Samme mønster: volatil status (GA/preview/modellversjon/SLA/perf) ut av body → ref. Antakelse: verifiser at innhold finnes i ref FØR sletting (ellers skriv ref-fil først, gated).
+
+---
+
+## Sesjon 10 (SPOR A — K9-destale: engineering + infrastructure) — RESULTATER (FERDIG, 2026-06-20)
+
+**Begge S10-kriterier møtt** (operatør-gated kald LLM-judge): engineering **K9 PASS** (findings: []); infrastructure **K9 PASS** (findings: "None"). Deterministisk ikke regredert: **validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/192**. gitleaks: 3 pre-eksisterende i `playground/vendor/` (utenfor changeset). K5 uendret (eng 0,23 · infra 0,97); refTall konsistent; K4 hevet eng 4→5 / infra 4→5 (mindre body-dup). Body krympet: infra K3 290→279 (eng uendret — generaliseringene byttet ord, ikke linjer).
+
+**Metode (verifiseringspliktig):** to parallelle read-only verifiserings-agenter kartla FØR sletting hvor hvert volatilt body-faktum bor i ref (PRESENT/PARTIAL/ABSENT) → flytt (i ref) / dropp (uverifisert) / generaliser.
+
+**Engineering (operatør-gated, 6 endringer):** §2 MAF-«erstatter Semantic Kernel»-transisjon → peker (ref bærer GA-dato/versjon); §intro/§3/§6 modellversjoner GPT-4o/Whisper/Florence/text-embedding-3 → generisk kapabilitets-framing (alle PRESENT i `azure-ai-services/*`+`multi-modal/*`); «Start med GPT-4o for prototyping» (ABSENT i ref) → dropp modellnavn, behold prinsipp; §8 Dekning «Foundry Agent Service GA»+«A2A/CUA/Foundry Workflows» → generiske topic-navn u/«GA» (filtall 24 urørt); «130+ språk» → «bred språkstøtte».
+
+**Infrastructure (operatør-gated, 8 endringer):** §1.8 SLA-tabell (99.9/99.999/99.95 % — **ABSENT i ref**) → relativ-veiledning + MCP/`research-agent`-peker (ingen tall i body); §1.2 RTO/RPO-tabell → sammendrag + peker (ref `rto-rpo-planning-ai-services.md` bærer hele tier-modellen i 265 linjer; minuttverdier fjernet); §1.7 «peak + 30 % buffer» (ref sier 1.2×/20 %, avvikende) → «kapasitetsbuffer»; §2.2 «(tidl. Azure Stack HCI)» → dropp (ref bærer rename); §2.3/2.4/2.8/3.4 «Phi-3/Phi-4»+«(3.8B)/(14B)» → «Phi-familien» u/versjon+parametertall (fjerner også **faktafeil**: body sa «Phi-4 (14B)», ref tilskriver 14B til Phi-3 Medium); §1.1 «(bredere modellutvalg)» → dropp (ref bærer).
+
+**To judge-runder for infra (dommeren er bindingen — ikke overstyrt):** runde 1 fanget at min FØRSTE SLA-omskriving introduserte et nytt konkret «99,9 %»-tall + flagget RTO-tabellens «< 5 min» (borderline). Fix: fjern alle SLA-prosenter fra prosa + flytt RTO/RPO-tabellen til peker → runde 2 **K9 PASS clean**.
+
+**Judge-cache:** `judge-results.json` oppdatert med ferske kalde eng+infra-verdikter (operatør-gated; `_updated: S10`).
+
+**Binding for S11:** K1 (#4) — 2 description-fikser (governance +Schrems II-trigger, advisor strammere) + draft 20 kandidat-prompts/skill → operatør-review. Merk: S10-judgen ga provisorisk K1 1.0 for begge eng+infra (rene description-grenser), men K1 forblir **PROVISORISK** til operatør kuraterer.
+
+---
+
+## Sesjon 11 (SPOR A — K1 trigger-presisjon) — RESULTATER (FERDIG, 2026-06-20)
+
+**Begge S11-kriterier møtt.** LLM-judge **K1 PASS for alle 5** (blindet) — hit-rate **1.0** / false-positive-rate **0.0** / presisjon **1.0** / 0 feilklassifiserte hver. K2 (description-format) fortsatt **PASS** etter edits (advisor quoted=6/useWhen=true; governance quoted=8/useWhen=true). Deterministisk ikke regredert: **validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/192**. K1 er ikke lenger provisorisk — `provisional=false` for alle 5.
+
+**(a) 2 description-fikser (operatør-godkjent ordlyd):**
+- **governance +Schrems II-trigger:** la til prosa «cross-border personal-data transfer assessment (Schrems II / TIA)» + to triggere «Schrems II data transfer», «overføring av persondata til tredjeland». Lukker recall-gapet (0.85→1.0). Verifisert FØR skriving at governance *eier* domenet (20 ref-filer + `data-residency-audit-monitoring.md` med EDPB seks-stegs-TIA).
+- **advisor strammere mot over-trigging:** byttet bred ledesetning «Microsoft AI architecture guidance» + trigger «Microsoft AI architecture» → selection-forankret «Microsoft AI platform selection …» + eksplisitt negativ scope «NOT for how to build (engineering), secure (security), operate (infrastructure), or legally assess (governance)». Fjernet den brede triggeren som kolliderte med søsken.
+
+**(b) Kuraterte 20 prompts/skill + blindet måling:**
+- Ny `data/k1-trigger-prompts.json` (100 prompts: 10 in-domain + 10 out-of-domain/skill). Out-of-domain er adversarielt — hver er en søsken-domene-prompt (`belongs_to`) som tester over-trigging-grensen, + 1 urelatert kontroll. Bilingvalt (no/en).
+- **Mekanikk-endring:** `judge-prompt.md` K1-bulleten endret fra *generer* prompts → *konsumer* det kuraterte settet; nytt output-skjema (`inDomainHitRate`/`outDomainFalsePositiveRate`/`pass`/`misclassified`, `provisional=false`).
+- **Blindet kjøring:** 5 parallelle Opus-dommere, hver ser KUN sin skills description + 20 **stokkede, umerkede** prompts (speiler skill-routeren); ground-truth holdt utenfor dommeren; scoret deterministisk etterpå. Begge fikser validert i dommernes begrunnelser: governance trigget på Schrems II/tredjeland via de nye triggerne; advisor avviste alle 4 søsken-prompts med eksplisitt sitat til den nye eksklusjonsklausulen.
+
+**Judge-cache:** `judge-results.json` oppdatert med S11 K1-verdikter for alle 5 (`_updated: S11`, `provisional=false`); K4/K7/K8/K9 urørt (uendret av description-edits — frontmatter, ikke body).
+
+**Binding for S12 (lukk SPOR A):** K4/K7/K8/K9 er uendret av S11 (description ≠ body), alle PASS fra S9/S10 kalde re-judges. Gjenstår kun: regenerer `eval-baseline.json` (gated `--write`) så baseline fanger S9+S10+S11 judge-oppdateringer. Trivielt — ett kommando-steg.
+
+---
+
+## SPOR A — gjenstående sesjoner (PLANLAGT, operatør godkjente alle 4 anbefalinger 2026-06-20)
+
+De 4 beslutning-gated punktene er nå **avgjort** (operatør: «følger anbefalingene gjennomgående»):
+1. **6×5-vekting → A:** den kanoniske rubrikken (`security-scoring-rubrics-6x5.md`, Compliance 25/Data 20/Identity 20/Content 15/Network 10/Mon 10) er autoritativ. `security-assessment-agent` bruker den allerede som OBLIGATORISK. SKILL.md slutter å gjengi vekttall (peker til rubrikken); den adaptive 3-profil-modellen (Standard / Eksternt eksponert / Persondata-intensiv) foldes inn i *rubrikk-fila* med **Standard = kanonisk**.
+2. **K9 → pragmatisk:** volatil status (GA/preview/versjon/SLA-/perf-tall) ut av SKILL.md body → ref-filer (currency-mekanismen holder dem ferske). Stabile refs blir (MADR v3.0, forordningsår 2024/1689, filnavn, generisk forklarende «preview»).
+3. **K4 → orient+rute:** body beholder *hva/når/hvilken-fil*; *hvordan* flyttes til ref-fil.
+4. **K1:** fiks 2 descriptions nå (governance +Schrems II-trigger; advisor strammere mot over-trigging); draft 20 kandidat-prompts/skill for operatør-review → mål presisjon.
+
+**Rød tråd (operatør-validert):** #1/#2/#3 har felles rotårsak for security — body bærer tall som hører i ref-filene. Ett disiplinert body-pass per skill løser flere kriterier samtidig.
+
+**Verifiseringsmekanisme:** K4/K9/K1 dømmes av den **operatør-gated LLM-judgen** (`scripts/kb-eval/judge-prompt.md` → `data/judge-results.json`, merges av `eval.mjs`). Hver sesjon som rører disse kjører judgen (scoped til relevante skills/kriterier) FØR ferdig-erklæring. Deterministiske kriterier (K2/K3/K5/K6/refTall) skal **aldri** regrederes (`eval --json` = akseptansemål).
+
+| Sesjon | Leveranse | Verifiserbart kriterium |
+|---|---|---|
+| **8** ✅ FERDIG (`1c0da88`, se «Sesjon 8 — RESULTATER») | **6×5-vekting (#1).** Fold adaptive workload-varianter inn i `security-scoring-rubrics-6x5.md` (Standard = kanonisk; foreslå eksakte varianttall, gated). Fjern divergerende vekttabell fra security SKILL.md → peker til rubrikken (behold risikoklassifiserings-tabellen — den er stabil). | `grep` security SKILL.md: ingen 3-kolonne-vekttabell med divergerende tall; rubrikken har én Standard + dokumenterte varianter; agent+skill peker samme kilde. `eval --json`: refTall/K5/K3 ikke regredert · validate 239 · kb-integrity grønt. **Antakelse testet:** ingen kode/test asserter SKILL.md-vekttallene (agenten bruker rubrikken — verifisert i S7-diskusjon; bekreft med `grep -r` på vekttallene før sletting). |
+| **9** ✅ FERDIG (se «Sesjon 9 — RESULTATER») | **K4+K9 body-cleanup: security + governance** (begge feiler begge kriteriene). Tynn dupliserte avsnitt → pekere; flytt volatil status → ref. Gated forslag per skill FØR endring. | ✅ LLM-judge: security **K4 5/5 · K9 PASS** · governance **K4 5/5 · K9 PASS**. `eval`: K5 sec 16→20/gov 24→25, K3/refTall ikke regredert · kb-integrity 192/192 · validate 239. Antakelse testet (read-only verifiserings-agenter kartla ref-dekning FØR sletting). |
+| **10** ✅ FERDIG (se «Sesjon 10 — RESULTATER») | **K9-destale: engineering + infrastructure** (feiler kun K9). Volatil status ut av body. Gated forslag FØR endring. | ✅ LLM-judge: **K9 PASS** eng+infra (kald re-judge). `eval --json` ikke regredert (K5/refTall) · validate 239 · kb-integrity 192/192 · K4 hevet 4→5 begge. |
+| **11** ✅ FERDIG (se «Sesjon 11 — RESULTATER») | **K1 (#4).** (a) 2 description-fikser: governance +Schrems II-trigger; advisor strammere (foreslå ordlyd, gated — K2-format må holdes). (b) draft 20 kandidat-prompts/skill → operatør-review → mål presisjon via judge. | ✅ Blindet LLM-judge: **K1 PASS alle 5** (hit 1.0 / fp 0.0 / presisjon 1.0, `provisional=false`). K2 fortsatt PASS · validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/192. Ny `data/k1-trigger-prompts.json` (kuratert 20/skill); `judge-prompt.md` konsumerer settet. |
+| **12** | **Lukk SPOR A.** Full LLM-judge re-run (K1/K4/K7/K8/K9) alle 5 → bekreft alle kriterier PASS → skriv ny `eval-baseline.json` (operatør-gated `--write`). (Kan foldes inn i S11 hvis lett.) | `eval-baseline.json`: ingen åpen eval-FAIL på tvers av K1–K9 for de 5 skills. STATE: SPOR A FERDIG → Spor B neste. |
+
+**Invariant gjennom alle sesjoner:** SKILL.md-/rubrikk-skriving er **gated** (presenter forslag FØR endring, som K5 i S7). Subagenter committer ALDRI. Validate + relevante tester grønne før commit. Push i vindu (hverdag 20–23 / helg fritt / operatør-go). Verifiseringsplikt: flyttet/endret fakta verifiseres mot kilde før skriving.
+
+**Etter SPOR A → Spor B:** scheduled deteksjon + siste integrasjon · kurs-spor (task #25) · low-currency-bøtta (51) · bredere `**Source:**`-backfill · onboarding-redesign (task #26, egen godkjenning).

docs/kb-refresh-backlog-2026-06.md

@@ -0,0 +1,49 @@
+# KB-refresh backlog — etter critical-klyngen (juni 2026)
+
+_Prioritert rekkefølge for gjenstående KB-refresh etter at critical cost-klyngen (8 filer) + release v1.16.2 ble fullført 2026-06-24. Tall fra `node scripts/kb-update/report-changes.mjs` (leser url-registry, ingen nettverk). Status-of-play i STATE.md._
+
+## Arbeidsmønster (bevist på critical-klyngen — gjenbruk per batch)
+1. Spawn read-only **Sonnet** drift-rapporter per batch (parallelt) → samler `✅ TRYGT` vs `VERIFY`-funn.
+2. **Main-agent = verifiseringsgaten:** hver `VERIFY`-påstand bekreftes mot sitert MS Learn-kilde (search/fetch) FØR den skrives. Agenter kan feillese/overgeneralisere (jf. fil 8: Phi/Falcon-«retired»-påstand ble avkreftet).
+3. Kirurgiske edits — **disclaimed/illustrative priser røres ALDRI**. Bump header (dag-presis dato hvis kilde endret midt i måneden, ellers `YYYY-MM`).
+4. `git diff`-gate → `./tests/validate-plugin.sh` (må være 239/0) → **1 fil = 1 commit** (`KB-refresh <tier> N/M`).
+5. Når en tier er tom: re-kjør `report-changes.mjs` (bekreft count faller) → **release** via `catalog/scripts/release-plugin.mjs ms-ai-architect <ver> --create-tag` så `--write --commit --push` (krever plugin.json == README-badge == ver + CHANGELOG + version-history FØRST; check-versions 0 ERROR).
+
+## Rekkefølge
+
+### 0. Quick-triage: UNVERIFIED (1) — gjør først, billig
+- `ms-ai-advisor/references/architecture/security.md` — **dateless** (mangler `Last updated`-header). Kjernefil lest av architecture-review-agent. Verifiser innhold + stamp header. Kan foldes inn i HIGH-sesjonen.
+
+### 1. HIGH (11) → release v1.16.3
+Batch etter område for kilde-gjenbruk:
+- **A — ms-ai-security/ai-security-engineering (3):** owasp-llm-top10-azure-mitigations · defender-threat-protection-ai-services · output-validation-grounding-verification. (Deler OWASP/Defender-kilder.)
+- **B — ms-ai-governance/responsible-ai (4):** content-safety-implementation · responsible-ai-policy-development · stakeholder-communication-ai-decisions · bias-detection-mitigation-strategies.
+- **C — ms-ai-governance/monitoring-observability (2):** model-performance-drift-detection · response-quality-metrics-rag.
+- **D — blandet (2):** governance/norwegian-public-sector-governance/copyright-ai-training-data-norway · engineering/agent-orchestration/agent-autonomy-and-control-governance.
+
+### 2. MEDIUM (33) → release v1.16.4 (vurder splitt)
+- **prompt-engineering (13, ms-ai-advisor):** few-shot, domain-specific, temperature-sampling, multi-turn, chain-of-thought, regulatory-prompting, grounding-injection, token-optimization, real-time-reasoning, role-playing, structured-output, system-message-design, function-calling. (Stor kohesiv batch.)
+- **performance-scalability (9, ms-ai-security):** async-processing, response-chunking, perf-benchmarking, throughput, token-per-second, gpu-sizing, concurrent-request, load-testing, batch-api-usage.
+- **rag-architecture (5, ms-ai-engineering):** streaming-rag, rag-evaluation, self-reflective-rag, rag-hallucination-mitigation, late-chunking.
+- **engineering-misc (5):** agent-orchestration (2: evaluation-testing, memory-context) · mlops-genaiops (2: model-versioning, feedback-loops) · azure-ai-services (1: speech-speaker-recognition).
+- **advisor/platforms (1):** azure-ai-foundry (kjernefil — høyere reell verdi enn MEDIUM antyder; vurder å løfte tidlig).
+
+### 3. LOW (52) → release v1.16.5 (splitt anbefalt, største område først)
+- **data-engineering (20, ms-ai-engineering)** — størst.
+- **api-management (13, ms-ai-engineering).**
+- **bcdr (10, ms-ai-infrastructure).**
+- **advisor/architecture (7):** ai-utredning-template, regional-availability-verification, migration-patterns, poc-template, licensing-matrix, public-sector-checklist, adr-template. (Templates + kjernefiler — lav drift-risiko, men leses ofte.)
+- **rest (2):** advisor/development/agent-framework · infrastructure/hybrid-edge/disconnected-ai-scenarios.
+
+> **KB-refresh FERDIG 2026-06-24:** alle tiers (Critical/High/Medium/Low) → 0. Releases v1.16.2 (critical) · v1.16.3 (high) · v1.16.4 (medium) · v1.16.5 (low 52/52). `report-changes.mjs` = 0 needing-update.
+
+## Separate spor (IKKE KB-refresh — egen prioritering)
+Disse er kjent fra memory/docs, men ikke re-verifisert denne sesjonen — bekreft status før start:
+- **Cosmo-persona — full utfasing (NY, godkjent 2026-06-24, gjøres SIST):** se `docs/cosmo-removal-brief-2026-06.md`. 417 filer / 188 `## For Cosmo`-seksjoner + persona-lag (SKILL.md, kommandoer, README, NOTICE, CLAUDE.md). Startet i v1.16.5 (2 filer). Egen plan + versjonsbump.
+- **Spor C — kurs/training-deteksjon (C3):** C3 Learn Platform API-creds satt opp (se memory `c3-learn-platform-api-setup`). Neste: faktisk deteksjons-implementasjon.
+- **Onboarding-uplift-måling:** alt onboarding-maskineri bygget; gjenstår å MÅLE faktisk uplift (memory `onboarding-quality-bar`).
+- **Ref-fil INNHOLDSkvalitet — ikke dekket av Spor D (NY, notert 2026-06-26):** Skill-kvalitetsscoringen (`scripts/kb-eval/`, Spor D, K1-K10 + N1-N5 + refCount) scorer SKILL.md-forfatterkvalitet + ref-filenes STRUKTUR/hygiene — IKKE den substansielle korrektheten/ferskheten i de ~389 ref-filenes innhold. De eneste kriteriene som leser ref-innhold er strukturelle: K8 (kilde-/Verified-header finnes, andel ≥0.80), N3 (ingen nøstede ref→ref-lenker), N4 (TOC i filer >100 linjer), refCount (tall matcher SKILL.md). Substansiell ferskhet dekkes av et SEPARAT system — KB-refresh (`report-changes.mjs` sitemap-poll: header-dato vs kilde-lastmod → `microsoft_docs_fetch` + agent-verifisering). Det flagger STALENESS, men gir ingen kvalitets-SCORE og hviler på per-refresh agent-verifisering — det finnes INGEN stående «er dette ref-innholdet korrekt + oppdatert mot Microsoft Learn»-score analogt til 0-100 skill-scoren. Operatøren markerer dette som det VIKTIGSTE å gjøre skikkelig. Neste steg: bekreft ønsket form (utvid Spor D med et content-correctness-kriterium? eget ref-eval-spor? styrke KB-refresh til å produsere en score?) FØR bygging.
+
+## Notater
+- Falske positiver er forventet: header-dato < sitemap-lastmod = KANDIDAT, ikke bekreftet drift. Mange LOW/MEDIUM kan vise seg å være header-bump-only (jf. critical-klyngens 2 falske positiver).
+- Tier-grensene er detektor-heuristikk, ikke hellige — løft en kjernefil (f.eks. azure-ai-foundry) tidligere hvis den har reell verdi.

docs/kb-refresh-cost-cluster-2026-06.md

@@ -0,0 +1,54 @@
+# KB-refresh — critical cost-cluster (juni 2026)
+
+_Apply-brief for de 8 critical cost-filene flagget av detektoren (post-v1.16.1 baseline). Status-of-play i STATE.md. Drift-funn samlet fra 7 parallelle research-agenter (Sonnet, read-only) 2026-06-23 + main-agent direkte-verifisering. **Jeg (main) er verifiseringsgaten: NYE påstander merket `VERIFY` må bekreftes mot kilde FØR de skrives inn — agentene er Sonnet og kan feillese.**_
+
+## Fremdrift
+- **1/8 ✅ ptu-vs-paygo-economics.md** — FERDIG (`d36cddd`, pushet). Spillover preview→GA; ny Priority processing-kategori; PTU-minimums/4750 TPM/cache-100% verifisert current; priser urørt (disclaimed).
+- **7 gjenstår** — funn under.
+
+## Main-agent allerede direkte-verifisert (ground truth, trygt å skrive)
+- **GPT-5.5 er reell** (gpt-5.5, 2026-04-24). Lineup: gpt-5/5.1/5.2/5.3/5.4-serie/5.5 + gpt-chat-latest.
+- **Fire deployment-kategorier:** Standard · **Priority processing** (NY, pay-per-token, latency-target) · Provisioned (PTU) · Batch.
+- **Spillover er GA** (ikke preview). Alle Azure OpenAI-PTU-modeller; ikke DeepSeek/Llama.
+- **Output-to-input ratio** (sizing): gpt-5=8, gpt-4.1=4. **Cached tokens 100% deducted** fra PTU-utilization.
+- PTU-minimums (gpt-4o 50 reg/15 global; 4o-mini 25/15; DeepSeek-R1 100/NA). GPT-5 = 4750 input TPM/PTU.
+
+## Per-fil apply-plan (gjenstående 7)
+
+### 2. reserved-capacity-planning.md (header 2026-04 → 2026-06)
+- ✅ TRYGT: legg til Priority processing som 4. kategori i beslutningstre/intro. `gpt-5`→`gpt-5.1` (2 steder: capacity-calculator-eksempel + Mønster 4-diagram «All models (incl. gpt-5…)»). Source-rad gov-page 2025-05→2026-06.
+- `VERIFY` (billing-page): agent sier upstream IKKE har «Azure OpenAI først, deretter Foundry Models»-prioritering for reservation-overage. Anbefalt: fjern påstanden, erstatt med «dekker automatisk alle støttede modeller i scope». Verifiser mot provisioned-throughput-billing før edit.
+- Min-PTU-tabell: legg til caveat «varierer per modell; se sizing-tabell». Priser disclaimed (40-60% rabatt) — urørt.
+
+### 3. cost-monitoring-cost-attribution.md (header 2026-04 → 2026-06) [ms-ai-governance]
+- `VERIFY` (manage-costs): (a) **Project-level cost attribution (Preview)** — auto `project`-tag, ingen manuell tagging. (b) **Agent cost monitoring** i Foundry-portal (Operate→Overview estimated-cost-tile; per-agent månedsestimat). (c) 3rd-party meters vises under **Global resources** (ikke bare resource group); format `model-name-GUID`. Alle tre = nye, høy-verdi tillegg — bekreft mot manage-costs før skriving.
+- Lavere conf: prompt-caching «(beta)»-merke → fjern/oppdater. `gpt-35-turbo`→`gpt-4o-mini` i gateway-diagram (illustrativt).
+- Priser disclaimed (GPT-4o/Turbo/3.5 illustrative) — urørt; men GPT-4 Turbo/3.5 er legacy (ikke fjern).
+
+### 4. inference-endpoint-cost-optimization.md (header 2026-04, footer 2026-02 inkonsistent → 2026-06)
+- ✅ TRYGT: legg til Priority processing i deployment-tabell + Nivå 4-anbefaling.
+- `VERIFY` (manage-costs): meter-skille «Models sold by Azure» (under Foundry-ressurs) vs «Marketplace/3rd-party» (SaaS-meters under Global resources) — filen slår dem sammen feilaktig.
+- Lavere conf: `Phi-3`→`Phi` (familie) 2 steder. Quota-tall 200k TPM/1k RPM → legg til «verifiser i quota-docs». Fiks footer-dato-inkonsistens (561, 601).
+
+### 5. prompt-engineering-cost-reduction.md (header 2026-02 → 2026-06)
+- `VERIFY` (prompt-caching): **Extended cache retention 24t** (`prompt_cache_retention: "24h"`, model-gated: gpt-5.x + gpt-4.1; default 24h for nyere). Filens «5-10 min, maks 1 time» er kun in-memory-delen. Støttede modeller: «alle GPT-4o+» (in-memory) — filens liste er ufullstendig (mangler GPT-5-serien).
+- `VERIFY` (use-your-data): **On Your Data deprecated, pensjoneres 2026-10-14** — kilde #5 peker på denne. Høy impact; bekreft dato.
+- Lavere conf: `prompt_cache_key`-nyanse; Prompt Flow «GPT-3.5»-referanse stale. o1-preview/GPT-4(32K) i pristabell er retired modellnavn (ikke bare priser).
+
+### 6. token-counting-optimization.md (header 2026-02 → 2026-06)
+- `VERIFY` (prompt-caching): samme extended-cache-24t-reframing (filens TTL-tabell deler feil på «Foundry Classic vs AI Services» — skal være in-memory vs extended). `prompt_cache_key` rate-limit-caveat (~15 req/min).
+- `VERIFY` (fine-tuning-cost-management): **RFT (Reinforcement Fine-Tuning)** ny kostnadsmodell — tidsbasert ($100/t o4-mini) + **$5000 per-job cap**. Filen dekker kun SFT/DPO.
+- `VERIFY` (use-your-data): On Your Data-deprecation (samme som #5). `VERIFY` (chatgpt): tiktoken-funksjon mangler `o1-mini`/`o3-mini` i model-set.
+- Priser har «kanonisk prissannhet»-peker — urørt.
+
+### 7. request-batching-aggregation.md (header 2026-05 → 2026-06)
+- `VERIFY` (batch): (a) **Data Zone Batch** ny deployment-type (mangler i fil). (b) «Exponential backoff» = «fail fast» (klient-retry, ikke server-auto-retry) — filens beskrivelse upresis.
+- 50%/24t/region-liste/expiration verifisert current. Priser disclaimed — urørt.
+
+### 8. small-language-models-economics.md (header 2026-04 → 2026-06)
+- ✅ TRYGT: fjern «(175B+)» fra GPT-4o (uverifiserbart param-tall). «GPT-4 utfaset»→«legacy» (GPT-4 turbo fortsatt aktiv).
+- `VERIFY` (models-from-partners): Phi-3-small/medium + Phi-2 ikke i aktiv katalog (kun Phi-4-familien) — merk, ikke slett (illustrative). Falcon-7B ikke i Foundry-katalog.
+- Lavere conf: reasoning-modell-anbefaling (o4-mini/o3) for kompleks resonnering. Priser disclaimed — urørt.
+
+## Apply-mønster (per fil)
+VERIFY nye påstander mot sitert kilde (fetch) → kirurgiske edits (behold disclaimed priser) → bump header → `git diff`-gate → `validate-plugin.sh` → commit (1 fil/commit, mønster `KB-refresh critical cost N/8`) → push i vindu. Når alle 8 ferdig: re-kjør `report-changes.mjs` (bekreft critical-count faller), så release v1.16.2 via `release-plugin.mjs`.

docs/kb-update-apply-brief.md

@@ -0,0 +1,63 @@
+# Brief — `/architect:kb-update` apply-kjøring
+
+_Run-plan for KB-currency-refresh. Autoritativ kommando-spec: `commands/kb-update.md` — denne briefen dekker beslutninger, **metode** og **sesjonsplan**. Pekt til fra STATE.md._
+
+## Status (2026-06-19)
+- **Critical (15) — FERDIG** (`41b390b`, pushet).
+- **High (49) — FERDIG** (`25bcb74`, pushet 2026-06-19).
+- **Medium (74) — FERDIG** (`070141f`, committet 2026-06-19; push parkert utenfor vindu). Kjørt som ÉN sesjon med 15 Opus-subagenter (3 bølger). Hovedkontekst fanget 1 regresjon: subagent overforenklet agentic retrieval GA/preview → rettet mot `agentic-retrieval-how-to-migrate`. **Lærdom: gi subagenter PRESISE binding-fakta, ikke lossy STATE-sammendrag.**
+- **Low (~51) — PLANLAGT**, siste bøtte. Kjøres i ny sesjon (se sesjonsplan).
+
+## Metode (oppdatert 2026-06-19, evidensbasert): DELEGER store bøtter
+Kommando-spec'en (`commands/kb-update.md`) beskriver fetch+Edit i hovedloopen. For STORE bøtter er det upraktisk: Microsoft Learn-sider er **50KB+** (ikke «noen tusen tokens» som opprinnelig antatt), og medium+low = **~268 unike fetches** — umulig i én kontekst. High-bøtta (`25bcb74`) ble derfor kjørt med **grupperte Opus-subagenter**, som fungerte svært bra (fanget bl.a. 3 reelle faktafeil). Bruk dette mønsteret for medium+low.
+
+**Bevist mønster:**
+1. **Re-poll FØRST** (dry-run): `node scripts/kb-update/run-weekly-update.mjs --force` → fersk bøtte-klassifisering. **ALLTID re-poll** — klassifisering drifter med fil-alder; ikke gjenbruk gammel `change-report.json`.
+2. Hent full fil→endrede-URLer-mapping fra `scripts/kb-update/data/change-report.json` (filtrer på `priority`).
+3. Grupper filene i bunter på **~6 filer som deler kilder** (hver unik URL hentes én gang per gruppe → minimer fetches).
+4. Spawn **én Opus-subagent per gruppe** (`Agent`, `subagent_type: claude`, `model: opus`), med **disjunkte fil-sett** (ingen skrivekonflikt → ingen worktree nødvendig). Hver subagent: Read → `microsoft_docs_fetch` (store sider persisteres til fil → Read den fila) → **kirurgisk** Edit → bump dato → kjøredato (behold filas eksisterende dato-label/format; footer `Sist oppdatert`→kjøredato, `Neste review`→+3 mnd hvis de finnes).
+5. **Subagent-kontrakt (kritisk):** verifiser hver faktapåstand mot kilde; fiks motsigelser til å matche kilden; **ALDRI oppfinn** — flagg uverifiserbart eksplisitt; behold «For Cosmo»/«For arkitekten»-seksjon + struktur; **ALDRI git/commit/stage**; rør KUN tildelte filer; returner kompakt per-fil-changelog + FLAGS-linje.
+6. Gi subagentene de **binding-verifiserte faktaene** fra STATE.md (relevant utvalg per gruppe) → unngå re-verifisering + motsigelse.
+7. **Hovedkontekst verifiserer ETTER** (subagentenes egenrapport er ikke nok — fila er fasit):
+   - `git diff --stat` → scope = KUN forventede filer, ingen streifende.
+   - git-diff-review av de største/mest faktatunge gruppene; spot-sjekk små.
+   - alle endrede filer har dato-header = kjøredato (regex-tips: dato-label kan ha kolon inni fet skrift, `**Dato:**`).
+   - `validate-plugin.sh` (239) · `test-kb-integrity.sh` (115/115, orphans ≤ 262) · gitleaks.
+   - **single-commit** per bøtte: `chore(ms-ai-architect): refresh KB <bøtte>-bucket — N files [skip-docs]` (følg `41b390b`/`25bcb74`-stil + Co-Authored-By/Claude-Session-trailers).
+   - push (vindu-sjekk: `TZ=Europe/Oslo date '+%u %H:%M'`; hverdag 20:00–23:00, helg/helligdag fritt — ELLER eksplisitt operatør-go).
+
+## Sesjonsplan (medium + low)
+| Sesjon | Bøtte | ~Filer | ~Unike fetches | ~Grupper (~6/gr) |
+|--------|-------|--------|----------------|------------------|
+| **M** | medium | ~74 | ~129 | ~13 |
+| **L** | low | ~51 | ~139 | ~9 |
+
+- **Anbefalt: to sesjoner** (M først, så L).
+- **Antall subagenter er IKKE en begrensning** (operatør-godkjent «så mange som trengs», 2026-06-19) — subagentene absorberer fetch-lasten, så bruk én per ~6-fil-gruppe (~13 for M, ~9 for L). Sesjons-splitten styres av **hovedkontekstens verifiseringslast** (diff-review av N filer), ikke agent-antall. M+L kan teoretisk gjøres i én sesjon, men 2 anbefales for grundig diff-review. Splitt Medium til **M1/M2 (~37 hver)** kun hvis verifiseringen blir for tung.
+- Hver sesjon: ÉN bøtte (`--priorities medium` hhv. `--priorities low`), `--single-commit`.
+- **Discovery:** historisk kun Databricks-støy (2 kjøringer på rad) → **`--skip-discover` anbefalt** for fart; operatør avgjør ved kjøring.
+- Low har lite kilde-gjenbruk (139 unike for 51 filer) → grupperingen sparer få fetches der, men holder fortsatt subagent-kontekst ren.
+
+## Per-sesjon oppstart (kort sjekkliste)
+1. Fersk sesjon i `ms-ai-architect/`. `claude mcp list` → bekreft `microsoft-learn` aktiv.
+2. `git status` rent + på `main` i synk (kommandoen blander inn ucommittede `.md`).
+3. Re-poll: `node scripts/kb-update/run-weekly-update.mjs --force` (`--discover` kun hvis ønsket).
+4. `node scripts/kb-update/report-changes.mjs | head -40` → bekreft bøtte-tall (kan ha driftet siden 2026-06-19).
+5. Hent fil→URL-mapping → grupper → spawn Opus-subagenter → verifiser (punkt 7 over) → single-commit → push → oppdater STATE.md.
+
+## Etter kjøring — obligatorisk
+- **Telling-resync:** apply på EKSISTERENDE filer endrer IKKE 389. KUN hvis discovery legger til NYE skills/-filer må 389 re-synkes overalt: README badge + prosa + KB-tabell + per-skill-seksjon; CLAUDE.md skill-tabell; SKILL.md subdir-tabell. Nye filer MÅ wires i respektiv SKILL.md (ellers orphan-warnings > 262). Fasit: `find skills/*/references -name '*.md' -type f | wc -l`.
+- **STATE.md:** oppdater ved sesjonsslutt (fjern fullført bøtte; oppdater HEAD/push-status).
+
+## Fallgruver
+- **Sitemap-coverage ~69 %:** ~31 % (mest `azure/ai-foundry/openai/`) finnes ikke pga. URL-restrukturering → rapporteres «always stale», vurderes manuelt.
+- **MCP-tilgjengelighet:** krever aktiv `microsoft-learn`-server.
+- **Modellvalg:** Opus for diff-nyanse (subagentene settes eksplisitt til `model: opus`).
+- **Regex på dato-header:** `**Dato:**`/`**Sist oppdatert:**` har kolon inni fet skrift — match på selve dato-strengen, ikke `**Label**`.
+
+## Verifisering (testbare kriterier)
+- `bash tests/validate-plugin.sh` → 239 PASS / 0 FAIL.
+- `bash tests/test-kb-integrity.sh` → 115/115; orphan-warnings IKKE økt utover 262 (med mindre nye filer bevisst lagt til + wiret).
+- Hver oppdatert fil har dato-header = kjøredato.
+- `git log --oneline` viser refresh-commit med `[skip-docs]`-suffiks.
+- Hvis discovery kjørte: README/CLAUDE.md/SKILL.md-tellinger matcher faktisk filtelling.

docs/okf-second-brain-brief-2026-06.md

@@ -0,0 +1,70 @@
+# Brief — Google OKF for brukerens «second brain» (LLM-wiki), IKKE for skill-refs
+
+_Notert 2026-06-26. Fremtidig initiativ — IKKE implementer før operatør sier fra. Bygger på research av GoogleCloudPlatform/knowledge-catalog (spec + samples + toolbox). State-of-play i `STATE.md`._
+
+## Delt spec er nå kilden (2026-06-29, ratifisert)
+Konvensjonen er **ikke lenger definert lokalt** — den bor i `catalog/docs/okf-second-brain/spec.md` (v0.1, eid av ingen enkelt plugin; linkedin-studios `brain/` er referansedesign, okrs `okf-check.mjs` referanse-checker; rollout/koordinering i samme mappes `log.md`). Denne brief-en er nå **plugin-spesifikk plan**, ikke konvensjonsdefinisjon — den *refererer* spec-en. Bekreftet for ms-ai-architect: minimal kontrakt (spec §3: `type` per konseptfil + `index.md` per nivå + `okf_version` i rot-`index.md`) er **gulvet, ikke taket** — vår «fulle OKF-pakke» rir over som **extension keys** (spec §5), ikke nivellert ned til bar OKF.
+
+**Premiss-korreksjoner (spec §9, ground-truth mot live repo — overstyrer økosystem-digesten under):**
+1. **`mdcode`/`kcmd` er IKKE et OKF-verktøy** — det er et Dataplex git-sync-verktøy med annet frontmatter-schema. **Droppet** fra adopsjonsplanen.
+2. **Ingen gjenbrukbar OKF-*ingest*-kode finnes** — `reference_agent` er BigQuery+Gemini/GCP-bundet. Adopter *prompt-mønstrene*, ikke koden. Classify/convert = bygg-selv.
+3. **Kanonisk anbefalt feltnavn er `resource`** (ikke `source`).
+
+## Scope-grense + ambisjon (ufravikelig, operatør-bekreftet 2026-06-26)
+- **OKF gjelder KUN brukerens egen kontekst/data** — hans person- og organisasjonsspesifikke «second brain» / LLM-wiki (i dag onboarding-output i `~/.claude/ms-ai-architect/org/*.md`).
+- **For dette sporet kjøres FULL Google OKF-pakke** (ikke bare lån av mønstre): frontmatter-kontrakt + `index.md`-progressiv-disclosure + retrieval + vedlikeholds-/enrichment-mekanisme, modellert på `samples/` + `toolbox/`. **Og adopsjonen holdes oppdatert etter hvert som OKF-standarden utvikler seg** (v0.1 → senere versjoner; fang `okf_version`-bump). Operatør-direktiv 2026-06-26.
+- **OKF gjelder IKKE de 389 skill-reference-filene.** De forblir Claude Code skill-references (native mekanisme, Anthropic-anbefalt flat/progressiv-disclosure-struktur). Begrunnelse: se `docs/ref-kb-direction-note-2026-06.md` + rekonsidererings-konklusjon i memory `okf-scope-second-brain-only`.
+
+## Hvorfor OKF passer second brain (men ikke skill-refs)
+Avgjørende skille er **ikke** «er det en LLM-wiki» (begge er det) — men **«finnes det allerede en native, anbefalt mekanisme?»**:
+- **Skill-refs:** JA — Claude Code skills + references + progressiv disclosure, allerede Anthropic-best-practice (flat, ett nivå dypt, store filer lastet on-demand, SKILL.md-hub + domene-mapper + grep). OKF ville erstattet et fungerende native system med et ekvivalent fremmed (OKFs retrieval-verdi over skills ≈ null; Grep/Glob/Read dekker allerede OKFs list/search/read).
+- **Second brain:** NEI — bor i dag i ad-hoc `org/*.md` uten retrieval-mekanisme under chat. OKF fyller et reelt tomrom: struktur + retrieval + vedlikeholds-tooling, vendor-nøytralt, portabelt, bruker-eid.
+
+## Lastemodell-skifte (operatør-presisering 2026-06-26 — reverserer tidligere antakelse)
+- **Før (antatt):** all kontekst injiseres når hver `/architect:*`-kommando kjøres.
+- **Nå (mål):** kontekst hentes **smart/selektivt** per kommando *og per interaksjon* — fordi de fleste ganger **chatter** brukeren med pluginen lastet, uten å kjøre kommandoer. Konteksten må være tilgjengelig i fri chat, hentet on-demand, ikke forhåndsinjisert.
+- Implikasjon: «second brain» trenger en **retrieval-skill** (list → search → read) som er aktiv uavhengig av kommandoer, + en **vedlikeholds-mekanisme** som holder wikien oppdatert etter hvert som brukeren tilfører kontekst OG etter hvert som OKF-standarden utvikler seg.
+
+## OKF v0.1 — kjernekontrakt (verifisert mot spec)
+- Bundle = katalogtre av markdown-filer, ett konsept per fil. Påkrevd frontmatter-felt: `type`. Anbefalt: `title`, `description`, `resource` (kilde-URI), `tags`, `timestamp`. Konsumenter MÅ bevare ukjente felt.
+- Reserverte filnavn: `index.md` (katalog-enumerasjon, ingen frontmatter, progressiv disclosure), `log.md` (endringslogg).
+- Kryss-lenking: bundle-relativ (`/...`) eller relativ markdown; relasjonstype utledes av prosa. Konsumenter må tolerere brutte lenker.
+- v0.1 (12. juni 2026), «starting point, not finished standard» → hold OKF-adopsjonen oppdatert ettersom standarden bumpes (`okf_version` i rot-`index.md`).
+- Kilde: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
+
+## Økosystem-digest (les disse FØRST ved implementasjon)
+Repo: `GoogleCloudPlatform/knowledge-catalog`. Mye er GCP/Dataplex/Gemini-bundet (ikke direkte gjenbrukbart); de **rene mønstrene** vi adopterer er markert.
+
+**Konsum / smart retrieval (kjernen — ADOPTER MØNSTERET):**
+- `samples/enrichment/sample/config/skills/kb-search/SKILL.md` — kanonisk skill-basert henteguide. Eksponerer trioen `list_contents` / `read_file` / `search_content` (= progressiv disclosure: finn → åpne kun relevant). **Mest verdifulle fil å lese først.**
+- `samples/enrichment/sample/config/mcp.json` + `samples/enrichment/src/tools/fileskb/{README.md,main.py}` — minimal stdio-MCP-server som eksponerer list/search/read over en markdown-katalog. _NB: i Claude Code dekker Grep/Glob/Read dette allerede — egen MCP-server er trolig unødvendig; SKILL-instruksen («søk wikien først, åpne kun relevant») er det bærende._
+- `samples/discovery/*` — Dataplex-bundet søke-agent (Google ADK + CatalogServiceClient). IKKE gjenbrukbart; kun mønster-referanse.
+
+**Struktur / frontmatter-eksempler:**
+- `okf/bundles/ga4/index.md` + `okf/bundles/ga4/references/metrics/avg_pageviews.md` — ekte `index.md`-hierarki + leaf-konsept med frontmatter (`type`/`resource`/`title`/`description`/`tags`/`timestamp`) + `# Citations`-seksjon. Kopier som mal.
+
+**Produksjon / vedlikehold (ADOPTER MØNSTERET, ikke koden):**
+- `okf/src/reference_agent/prompts/web_ingestion_instruction.md` — kilde-drevet oppdatering: `list_concepts → fetch → enrich/mint/skip` med strenge frontmatter-/heading-bevaringsregler. Moden mal for «hold wikien oppdatert fra kilder».
+- `okf/src/reference_agent/prompts/reference_instruction.md` — deterministisk konsept-syntese (frontmatter + fast body-rekkefølge).
+- `okf/src/reference_agent/cli.py` — `enrich` / `visualize`-kommandoer (Gemini/BQ-bundet impl).
+- ~~`toolbox/mdcode/...`~~ — **DØDT SPOR (spec §9.1):** `mdcode`/`kcmd` er IKKE et OKF-verktøy, men et Dataplex git-sync-verktøy med et annet frontmatter-schema (`id`/`resource.name`/`createTime`/`links`). Ikke planlegg OKF-emit/sync via det.
+
+## Hva som må bygges (fremtidige faser — ikke nå)
+1. **Frontmatter-/struktur-konvensjon** for second brain: bygg mot delt spec §3 (`type` påkrevd + `index.md` per nivå + `okf_version` i rot). Anbefalte felt (spec §4): **`resource`** (kanonisk kilde-URI — IKKE `source`), `title`, `description`, `tags`, `timestamp`. Migrer dagens `org/*.md` (de mangler bare `type:` — nær OKF allerede).
+2. **Retrieval-skill** («second-brain-search» e.l.): list → search → read over `~/.claude/ms-ai-architect/org/`, aktiv i fri chat (ikke bare kommandoer). Avgjør: ren SKILL+Grep/Glob/Read vs. dedikert MCP-server (build-both-and-measure-kandidat — se under).
+3. **Vedlikeholds-mekanisme**: hvordan wikien oppdateres når brukeren tilfører kontekst (onboarding-agent skriver OKF-konform), + en oppdaterings-rutine når OKF-standarden bumpes.
+
+## Åpne valg (operatør / 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 for brukeren» (operatørs faktabasert-prinsipp).
+- **Hvor mye av OKF formaliseres:** full v0.1-konformitet vs. «OKF-kompatibel form» (frontmatter + index.md uten resten). Lén mot det letteste som gir smart retrieval.
+- **Oppdaterings-kadens mot standarden:** hvordan fange OKF-versjonsbump (v0.1 → …) uten manuell polling.
+
+## Suksesskriterium (per operatør 2026-06-26)
+Det viktigste er **ikke teknologien**, men at second brain blir **så bra som mulig for brukeren** og at **oppdateringsmekanismene fungerer veldig bra**. Mål mot brukerverdi (henter pluginen riktig personlig/org-kontekst i chat?) + vedlikeholds-pålitelighet — ikke mot formell OKF-konformitet i seg selv.
+
+## Referanser
+- **Delt konvensjon (KILDEN):** `catalog/docs/okf-second-brain/spec.md` (v0.1) + `log.md` (koordinering/rollout) — les FØRST.
+- OKF upstream-spec: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
+- Samples: https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/samples
+- Toolbox: https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox
+- Relatert (skill-ref-sporet, separat): `docs/ref-kb-direction-note-2026-06.md`, `docs/ref-kb-audit-2026-06.md`

docs/onboarding-redesign-brief.md

@@ -0,0 +1,46 @@
+# Brief — Redesign av onboarding-/virksomhetskontekst-mekanismen (ms-ai-architect)
+
+_Problemstilling + krav, ikke en godkjent plan. Opprettet 2026-06-19 etter operatør-flagg under Sesjon 3 av KB-redesignet. Design godkjennes separat (brief → plan, slik KB-redesignet gikk). **Ikke start implementering uten operatør-go.** Refereres fra `STATE.md`._
+
+## Hvorfor dette er kritisk
+
+Virksomhetskontekst (sektor, lisens, dataklassifisering, budsjett, styringsmodell, regelverk) er det som gjør pluginens output relevant for *denne* brukeren i stedet for generisk. Operatørens vurdering (2026-06-19): hvis denne konteksten ikke er **til stede i enhver interaksjon** og ikke **overlever oppgraderinger**, skaper mekanismen frustrasjon i stedet for verdi — brukeren fyller den ut én gang og opplever at den «forsvinner» eller «ignoreres».
+
+## Verifisert tilstand i dag (2026-06-19)
+
+- **Innsamling:** `/architect:onboard` (orkestrator) → `agents/onboarding-agent.md` (5-fase intervju via `AskUserQuestion`, ~13 spørsmål, sektor-forgrening offentlig/privat).
+- **Lagring:** `org/*.md` — 5 markdown-filer med YAML-frontmatter (`completed: true`). Plassert **inne i plugin-katalogen**.
+- **Konsum:** 11 agenter har en «Virksomhetskontekst (automatisk)»-seksjon som **betinget** leser `org/`-filene («hvis mappen finnes»).
+- **Hook:** `hooks/scripts/session-start-context.mjs` viser onboarding-**status** ved sesjonsstart («Ingen virksomhetstilpasning. Kjør /architect:onboard»), men injiserer **ikke** selve innholdet.
+
+## Gap mot operatør-kravene
+
+| # | Krav (operatør) | Gap i dag |
+|---|---|---|
+| 1 | **Ambient i enhver interaksjon** | Org-lesing er opt-in per agent og betinget. Et fritekst-spørsmål eller en kommando uten egen org-seksjon får ikke konteksten. Hooken injiserer status, ikke innhold. |
+| 2 | **Overlever oppgraderinger** | `org/` er gitignored (`.gitignore:24`) og bor i plugin-katalogen (`~/.claude/plugins/marketplaces/.../ms-ai-architect/org/`). `git pull` rører den ikke (bra for personvern), men reinstall / re-clone / marketplace-oppdatering til ny katalog **mister den**. Ikke git-backet, ikke backup/restore. |
+| 3 | **Fritekst-kontekst utover formelle spørsmål** | Onboarding samler kun strukturerte svar fra faste `AskUserQuestion`-valg. Det finnes ingen «alt annet du vil at pluginen skal vite»-felt (fri prosa) som konteksten kan bære med seg. |
+
+**Tilstøtende (allerede dokumentert):** `docs/devils-advocate-audit-2026-06-18.md` §167 — onboarding kan ikke representere en privat virksomhet (sektor-valg hardkodet offentlig; reguleringsliste mangler DORA/Finansforetaksloven m.m.). Bør løses i samme redesign siden det treffer samme filer.
+
+> Merknad: `docs/onboarding-ros-analysis.md` var feildøpt — den er en Windows «clone-to-PR»-guide for ROS-featuren, **ikke** en onboarding-analyse. **Omdøpt i C2.4** til `docs/windows-clone-to-pr-ros-guide.md`.
+
+## Skisserte løsningsretninger (ikke bindende — design godkjennes senere)
+
+1. **Robust lagringssted.** Flytt org-data ut av plugin-katalogen til en bruker-eid sti som overlever reinstall (f.eks. under `~/.claude/` eller en eksplisitt prosjekt-/bruker-data-mappe), og/eller etabler et eksplisitt eksport/import-mønster. Behold personvern (ikke commit til git).
+2. **Ambient injeksjon.** La `session-start-context.mjs` injisere et kompakt org-sammendrag i hver sesjon (slik `STATE.md` injiseres i dag), så konteksten er til stede uavhengig av hvilken agent/kommando som kjøres. Vurder lengde-budsjett.
+3. **Fritekst-felt.** Legg til et fritt «ekstra kontekst»-felt i onboarding (én `org/free-context.md` eller seksjon) som bæres med i den ambiente injeksjonen.
+4. **Privat-sektor-paritet.** Parametrer sektor-forgreningen så en privat virksomhet ikke er andrerangs (mekanisk endring i `onboarding-agent.md`-spørsmålene + reguleringslister).
+
+## Verifiserbare akseptansekriterier (for den senere planen)
+
+- **K1 (ambient):** Start en frisk sesjon med utfylt org-kontekst og still et fritekst-spørsmål uten å invokere en org-bevisst agent → svaret reflekterer minst ett org-faktum. (Bevis: konteksten injiseres, ikke betinget lest.)
+- **K2 (overlevelse):** Simuler en oppgradering (flytt/reinstaller plugin-katalogen) → org-konteksten er fortsatt tilgjengelig. (Bevis: lagring utenfor det som blåses bort ved reinstall, eller dokumentert restore-steg.)
+- **K3 (fritekst):** Onboarding fanger et fritt prosa-felt, og innholdet er synlig i en etterfølgende interaksjon.
+- **K4 (paritet):** En privat virksomhet kan fullføre onboarding uten å velge «Annet» på sektor, med relevant reguleringsliste.
+
+## Avgrensning
+
+- **Ikke** en del av KB-mekanisme-redesignet (Sesjon 1–5 + kurs-spor). Eget spor, egen plan.
+- Prioriteres etter operatørens vurdering — naturlig kandidat når KB-redesignet (lag 1–3) er på plass, men kan hentes fram tidligere hvis brukervennlighet veier tyngst.
+- Følger samme kontinuitetsregler: denne briefen bor i `docs/`, refereres fra `STATE.md`, ingen egen `ROADMAP.md`.

docs/onboarding-redesign-plan.md

@@ -0,0 +1,174 @@
+# Spec — Redesign av onboarding-/virksomhetskontekst-mekanismen (ms-ai-architect)
+
+_Godkjent plan (operatør, 2026-06-22). Avløser planleggings-input i `onboarding-redesign-brief.md`. Spor C fase **C2** (etter C1 ✅, før C3 kurs). Implementeres én delsesjon per økt; STATE.md peker på neste. Samme kontinuitetsregler som KB-redesignet: planen bor i `docs/`, refereres fra `STATE.md`, ingen egen `ROADMAP.md`._
+
+## Context
+
+Virksomhetskontekst (sektor, lisens, dataklassifisering, residens, budsjett, styringsmodell, regelverk + fri prosa) er det som gjør pluginens output relevant for *denne* brukeren i stedet for generisk. Operatørens vurdering (2026-06-19, gjentatt 2026-06-20): hvis konteksten ikke er **til stede i enhver interaksjon** og ikke **overlever oppgraderinger**, skaper mekanismen frustrasjon i stedet for verdi. C2 er **kritisk for at pluginen blir praktisk i bruk**.
+
+### Verifisert tilstand (2026-06-22, mot koden — ikke briefen alene)
+
+| # | Krav | Faktisk tilstand i koden |
+|---|------|--------------------------|
+| 1 | **Ambient i enhver interaksjon** | **Reelt gap.** `hooks/scripts/session-start-context.mjs:135-139` injiserer kun *status* («Ingen virksomhetstilpasning»), ikke innhold. De 11 agentene (`adr-writer`, `summary`, `research`, `cost-estimation`, `license-mapper`, `diagram-generation`, `dpia`, `ros-analysis`, `ai-act-assessor`, `security-assessment`, `architecture-review`) leser `org/` **betinget** («Hvis `org/`-mappen finnes…»). Kommandoer/fritekst uten egen org-seksjon får ingenting. |
+| 2 | **Overlever oppgraderinger** | **Reelt gap.** `org/` er gitignored (`.gitignore:24`) og bor i plugin-katalogen → reinstall/marketplace-flytt blåser den bort. **Samme gjelder `ms-ai-architect.local.md`** (C1-scheduler-config): leses fra plugin-rot (`loadScheduleConfig(pluginRoot)`, `detection-schedule.mjs:95`) og er `*.local.md`-gitignored → scheduler-innstillingene dør også ved reinstall. |
+| 3 | **Fritekst-felt** | **Reelt gap.** Onboarding samler kun strukturerte `AskUserQuestion`-svar. Ingen fri-prosa-felt («alt annet du vil pluginen skal vite»). |
+| 4 | **Privat-sektor-paritet** | **Trolig allerede løst** — `agents/onboarding-agent.md` Phase 1 forgrener allerede offentlig/privat med egen reg-liste (DORA, Finansforetaksloven, Finanstilsynets IKT-forskrift, Verdipapirhandelloven, Hvitvaskingsloven, …). C2.4 **verifiserer** og lukker evt. `devils-advocate-audit-2026-06-18.md §167`-residu — antar ikke at det er gjort. |
+| 5 (S24) | **Eksponer `os_scheduler_cadence`** | Config-plumbingen finnes alt (`DEFAULT_SCHEDULE_CONFIG.os_scheduler_cadence:'daily'`, parses fra `scheduled_detection:`-blokk i `detection-schedule.mjs`). Gapet: eneste måte å sette den på er å **hånd-redigere** den gitignored config-fila. Onboarding må skrive den (operatør: «avgjøres i onboardingen, egen innstilling, daglig default»). |
+
+**Nøkkelinnsikt:** #1 og #2 løses renest *sammen*. Når hooken injiserer org-*innhold* ambient, og dataene bor på en bruker-eid sti, blir «hvor bor dataene» et spørsmål bare hooken + onboarding-agenten må svare på.
+
+## Låst scope og retning (operatør, 2026-06-22)
+
+- **Lagringssted (BESLUTTET):** flytt **både** org-data **og** C1-scheduler-config ut av plugin-katalogen til en **bruker-eid mappe `~/.claude/ms-ai-architect/`** (søsken av `~/.claude/plugins/`, overlever plugin-reinstall). Personvern bevart — ligger ikke i noe git-repo. Bakoverkompat: les ny sti først, fall tilbake til plugin-rot/`org/`; migrer gammel hvis present (i praksis no-op i dag — ingen eksisterende data).
+- **Ambient:** `session-start-context.mjs` injiserer et **kompakt** org-sammendrag (lengde-budsjett, ~25 linjer), slik `STATE.md` injiseres. Ikke rå-filer.
+- **Agentenes betingede lesing beholdes som fallback**, men peker på den bruker-eide stien (se risiko 5 — subagent-injeksjon er en antakelse som SKAL testes i C2.1).
+- **Ingen destruktive ops** på eksisterende org-data. Innhold kan vokse (fritekst-fil).
+- **TDD ufravikelig:** test FØR kode i hver delsesjon. Operatør-gate på beslutninger.
+
+## Arkitektur
+
+```
+LAGRING       ~/.claude/ms-ai-architect/
+              ├── org/*.md            (5 strukturerte filer + free-context.md)
+              └── ms-ai-architect.local.md   (scheduler-config; samme blokk-format)
+
+RESOLVER      lib/user-data.mjs (NY, ren, SKRIVER ALDRI)
+              resolveUserDataDir(homedir) · resolveOrgDir · resolveConfigPath
+              buildOrgSummary(files,{cap}) — deterministisk, lengde-kappet
+
+AMBIENT       session-start-context.mjs LESER resolver → injiserer summary (stdout)
+KONSUM        11 agenter: betinget lesing (fallback) peker på resolveOrgDir
+SKRIVING      onboarding-agent.md → resolveOrgDir; scheduler-spørsmål → resolveConfigPath
+              (gated KB-/config-skriving via lib/atomic-write + lib/backup)
+```
+
+**Bakoverkompat-invariant (C1 må ikke knekke):** `loadScheduleConfig` skal lese bruker-sti FØRST, deretter falle tilbake til dagens plugin-rot-sti. Den allerede-shippede Tier-1/Tier-2-scheduleren leser samme config — fallbacken garanterer uendret oppførsel for en bruker som allerede har en plugin-rot-config.
+
+## Roadmap (multi-delsesjon, én økt per delsesjon)
+
+| Delsesjon | Leveranse | Verifiserbart kriterium |
+|---|---|---|
+| **C2.1** | Bruker-eid lagring + ambient injeksjon (#1 + #2) | **K1** + **K2** (se under). `loadScheduleConfig` bakoverkompat-test grønn (bruker-sti vinner, fallback til plugin-rot). |
+| **C2.2** | Fritekst-felt (#3) | **K3**: onboarding fanger `org/free-context.md`; innholdet synlig i etterfølgende interaksjon (summary inkluderer det, kappet). |
+| **C2.3** | `os_scheduler_cadence` + `enabled` i onboarding (S24) | **K5**: onboarding skriver `scheduled_detection:`-blokk som `parseScheduleConfig` leser tilbake korrekt (round-trip-test: `daily`/`interval`/`enabled`). |
+| **C2.4** | Privat-sektor-paritet — verifiser + lukk §167-residu (#4) | **K4**: privat virksomhet fullfører onboarding uten «Annet» på sektor, med relevant reg-liste. |
+
+C2.1 er den bærende delsesjonen (etablerer lagring + resolver alle andre bygger på). C2.2–C2.4 er additive oppå den.
+
+## Verifiserbare akseptansekriterier (binding)
+
+- **K1 (ambient):** Frisk sesjon med utfylt org-kontekst + et fritekst-spørsmål uten å invokere en org-bevisst agent → svaret reflekterer ≥1 org-faktum. **Bevis:** konteksten injiseres (ikke betinget lest). Test: hook-output inneholder org-sammendrags-blokken når resolver finner org-filer.
+- **K2 (overlevelse):** Simuler oppgradering (flytt/reinstaller plugin-katalogen) → org-konteksten + scheduler-configen er fortsatt tilgjengelig. **Bevis:** resolver peker på `~/.claude/ms-ai-architect/`, utenfor det reinstall blåser bort. Test: resolver returnerer bruker-sti uavhengig av `pluginRoot`; `loadScheduleConfig` finner bruker-config selv når plugin-rot-config mangler.
+- **K3 (fritekst):** Onboarding fanger et fritt prosa-felt; innholdet er synlig i en etterfølgende interaksjon (i ambient-sammendraget, kappet til budsjett).
+- **K4 (paritet):** Privat virksomhet kan fullføre onboarding uten å velge «Annet» på sektor, med relevant reguleringsliste.
+- **K5 (S24 cadence):** Onboarding skriver en `scheduled_detection:`-blokk (`enabled` + `os_scheduler_cadence`) til bruker-config; `parseScheduleConfig` leser den tilbake til samme verdier (round-trip). Garbage/utelatt → `daily`-default (eksisterende coerce-regel).
+
+## Gjenbruk vs. nybygg (navngitte filer)
+
+**Gjenbruk direkte:**
+- `detection-schedule.mjs` `scheduled_detection:`-blokkformat + `parseScheduleConfig`/`coerce` (C2.3 skriver dette formatet; ingen ny parser).
+- `lib/atomic-write.mjs` + `lib/backup.mjs` (for all gated config-/org-skriving).
+- `session-start-context.mjs` injeksjonsmekanisme (stdout → SessionStart additional context).
+
+**Nytt:**
+- `scripts/.../lib/user-data.mjs` (ren resolver + `buildOrgSummary`; SKRIVER ALDRI; null avhengigheter utover `node:fs/path/os`). Speiler `detection-schedule.mjs`-stilen (ren kjerne, tynn konsument).
+- `org/free-context.md`-konvensjon (C2.2).
+- Onboarding scheduler-spørsmål (C2.3).
+
+**Må endres:**
+- `session-start-context.mjs` — resolve bruker-org-dir (fallback plugin `org/`), injiser kompakt summary (ikke bare status).
+- `detection-schedule.mjs` `loadScheduleConfig` — bruker-sti først, fallback plugin-rot (bakoverkompat).
+- `agents/onboarding-agent.md` — skriv til bruker-sti; nytt fritekst-felt (C2.2); scheduler-spørsmål (C2.3).
+- 11 agentfiler — «Virksomhetskontekst (automatisk)»-seksjonen: fallback-lesing peker bruker-sti + note om at kontekst injiseres ambient. **Mekanisk, uniform** (grep-test for konsistens).
+- `commands/onboard.md` (88 l), `CLAUDE.md`, `README.md`, `.gitignore` (org/-regel blir moot men beholdes som forsvar-i-dybden) — sti-referanser.
+
+## Risiko (rangert) og håndtering
+
+1. **Subagent-injeksjon-antakelse (KRITISK — testes i C2.1).** SessionStart-hookens stdout blir main-kontekst. Det er **ikke verifisert** at Task-spawnede subagenter (de 11) arver den. Hvis ikke: ambient-injeksjonen dekker main-kontekst + ikke-agent-kommandoer, mens agentene bæres av **fallback fil-lesing** fra bruker-stien. Derfor beholdes agentenes betingede lesing (pekt på resolver) — design er robust uansett utfall. **Eksplisitt test i C2.1 før vi stoler på «ambient».**
+2. **C1-config bakoverkompat.** Flytting av config-sti kan knekke den shippede scheduleren. → fallback (bruker-sti → plugin-rot) + round-trip-test; ikke fjern plugin-rot-lesing.
+3. **Hook-injeksjon-bloat.** Summary prependes hver sesjon. → hardt lengde-budsjett (~25 l) i `buildOrgSummary`, kapp fritekst.
+4. **11-agent mekanisk drift.** → uniform edit + grep-test at alle org-bevisste agenter refererer resolver-stien likt.
+5. **Personvern.** Bruker-sti ligger ikke i repo; behold `.gitignore org/` som forsvar-i-dybden.
+
+## Verification (overordnet)
+
+- Per-delsesjon K-kriterier (tabell) er kjørbare sjekker.
+- Pluginens gates ved hver commit: `validate` (239+), `kb-integrity`, `test-hooks.sh`, `gitleaks` clean (3 pre-eksisterende i `playground/vendor/` = uendret baseline).
+- **Nøkkelantakelse testet (CLAUDE.md plan-kvalitet):** subagent-injeksjon (risiko 1) — eksplisitt test i C2.1; merket risiko til den er bevist.
+- Arkitektur-invariant: `lib/user-data.mjs` er ren resolver (SKRIVER ALDRI); all org-/config-skriving gated via `atomic-write`/`backup`.
+
+## Avgrensning
+
+- **Ikke** del av KB-mekanisme-redesignet (`kb-mechanism-redesign-plan.md`) eller Spor B (`skill-lifecycle-spor-b-plan.md`). Eget spor, egen plan.
+- C3 (kurs/training, #25) tas **etter** C2.
+- `docs/onboarding-ros-analysis.md` var feildøpt (Windows clone-to-PR-guide, ikke onboarding-analyse) — **omdøpt i C2.4** til `docs/windows-clone-to-pr-ros-guide.md`.
+
+---
+
+## C2.1 — konkret startplan (bruker-eid lagring + ambient injeksjon)
+
+**Mål:** etabler `~/.claude/ms-ai-architect/` som bruker-eid datarot, en ren resolver alle andre delsesjoner bygger på, og ambient injeksjon av et kompakt org-sammendrag. **TDD: test FØR kode.** Invariant: resolver SKRIVER ALDRI; C1-scheduler må ikke knekke (fallback).
+
+**Rekkefølge:**
+1. **Les først:** `hooks/scripts/session-start-context.mjs`, `scripts/kb-update/lib/detection-schedule.mjs` (`loadScheduleConfig`/`CONFIG_FILENAME`), `agents/onboarding-agent.md`, ett agent-eksempel (`security-assessment-agent.md:33-39`), `lib/atomic-write.mjs` + `lib/backup.mjs`.
+2. **`lib/user-data.mjs` (ny, ren):** `resolveUserDataDir(homedir = os.homedir())` → `join(homedir,'.claude','ms-ai-architect')`; `resolveOrgDir(homedir)`; `resolveConfigPath(homedir)`; `buildOrgSummary(orgFiles, {cap})` → deterministisk, lengde-kappet sammendrag (sektor, virksomhet, størrelse, reg-krav, lisens, dataklassifisering, residens, budsjett, styringsmodell). TDD: tester for resolver (homedir-injisert), summary (manglende filer, cap), FØR kode.
+3. **`detection-schedule.mjs` bakoverkompat:** `loadScheduleConfig` leser `resolveConfigPath` først, fallback dagens plugin-rot. Round-trip-test: bruker-config vinner; plugin-rot brukes når bruker-config mangler.
+4. **`session-start-context.mjs`:** resolve bruker-org-dir (fallback plugin `org/`), bygg + injiser kompakt summary (ikke bare status). Behold status-linja når org tom.
+5. **`onboarding-agent.md`:** skriv org-filer til `resolveOrgDir`.
+6. **11 agenter:** «Virksomhetskontekst (automatisk)»-seksjon peker resolver-sti + ambient-note. Uniform + grep-test.
+7. **Subagent-injeksjon-test (risiko 1):** bevis om en Task-spawnet agent ser hook-injeksjonen. Dokumentér utfall; behold fil-fallback uansett.
+8. **Avslutt:** `validate` 239 + nye enhetstester + `test-hooks.sh` grønne · commit per logisk enhet · push (vindu 20–23 hverdag) · oppdater STATE (C2.2 neste) + denne planen (C2.1-resultater).
+
+**Ikke i C2.1:** fritekst-felt (C2.2), scheduler-spørsmål i onboarding (C2.3), §167-verifisering (C2.4).
+
+### C2.1 — RESULTAT (levert, TDD test FØR kode)
+
+- **`lib/user-data.mjs` (NY, ren, SKRIVER ALDRI; kun `node:os/path`):** `resolveUserDataDir/resolveOrgDir/resolveConfigPath` (peker `~/.claude/ms-ai-architect/`, uavhengig av `pluginRoot` → **K2**), `CONFIG_FILENAME` (delt med C1, én sannhetskilde), `ORG_FILES`, `buildOrgSummary(orgFiles,{cap,maxValueLen})` (generisk H2-ekstraksjon, frontmatter+H1-stripp, deterministisk ORG_FILES-rekkefølge, lengde-kapp ~25 l + per-felt-trim).
+- **`detection-schedule.mjs` bakoverkompat:** `loadScheduleConfig(pluginRoot, home=homedir())` leser bruker-sti FØRST, fallback plugin-rot. Lokal `CONFIG_FILENAME` fjernet → importeres fra resolver. Alle 3 kallere (hook, run-detection, scheduler) bruker ett-arg-kall → uendret oppførsel.
+- **`session-start-context.mjs` ambient (K1):** resolver bruker-org-dir (fallback plugin `org/`), leser filene, injiserer `buildOrgSummary` som egen «Virksomhetskontekst (auto-injisert …)»-blokk. Status-nudge beholdt når org tom.
+- **Skriving:** `onboard.md` (orkestrator) resolver absolutt `$ORG_DIR` via Bash + `mkdir -p` og gir agenten den; `onboarding-agent.md` skriver til den absolutte bruker-stien (ikke plugin-rot).
+- **11 agenter:** uniform «Virksomhetskontekst»-blokk → bruker-sti + note om ambient + subagent-fallback (grep-verifisert 11/11).
+- **Risiko 1 BEVIST:** Task-spawnet subagent arver **IKKE** SessionStart-injeksjonen (live-probe) → agentene bæres av fallback-fil-lesing; `Read`/`Glob` ekspanderer `~` (verifisert) → bruker-sti lesbar uten Bash.
+- **Verifisert:** user-data 16/16 · detection-schedule 23/23 (+2 round-trip) · test-hooks 10/10 (+4: K1-injeksjon + tom-org-negativ) · kb-update 191 · kb-eval 100 · validate PASSED (0/0) · kb-integrity 192/192 (220 baseline-warns) · discovery 13/13 · gitleaks 3 PRE-EKSISTERENDE (`playground/vendor/`). CLAUDE.md trengte ingen sti-endring (kun kommando/agent-omtale); `.gitignore org/` beholdt som forsvar-i-dybden.
+- **Neste:** C2.2 (fritekst-felt `org/free-context.md` → fanges av onboarding + inkluderes kappet i `buildOrgSummary`).
+
+### C2.2 — RESULTAT (levert, TDD test FØR kode)
+
+**Mål nådd:** valgfritt fri-prosa-felt `free-context.md` fanges i onboarding og overflater (kappet) i det ambiente sammendraget → **K3 oppfylt**.
+
+- **Designvalg som avvek fra startnotatet (begrunnet):** `free-context.md` ble **IKKE** lagt i `ORG_FILES`. `ORG_FILES` er doblet brukt i hooken — både fil-lesing OG fullføringskontrakt (`orgComplete < ORG_FILES.length`). Hadde fila blitt en sjette `ORG_FILES`-oppføring, ville en fullt onboardet bruker uten fritekst vist «Onboarding 5/6 — kjør for å fullføre». Løst med egen `export const FREE_CONTEXT_FILE` (utenfor `ORG_FILES`); hooken leser den **uten å telle** den.
+- **`lib/user-data.mjs`:** `FREE_CONTEXT_FILE` + `FREE_CONTEXT_LABEL='Fri kontekst'`. `collapseProse()` (strip frontmatter + ALLE header-linjer + kollaps whitespace) → fri kontekst overflates som ÉTT felt **uansett markdown-struktur** (rå prosa, kun H1, eller H2) — fjerner stille-drop-feilmodus som ellers truet K3. `capValue()` ekstrahert (DRY — brukes nå av både strukturert-loop og fri-kontekst). I `buildOrgSummary` legges fri kontekst SIST, kappet av samme `maxValueLen` (160) som øvrige felt.
+- **`session-start-context.mjs`:** leser `FREE_CONTEXT_FILE` valgfritt inn i `files`-mappen (ingen `count++`) → ambient-summary inkluderer den; fullføringstellingen uendret.
+- **`onboarding-agent.md`:** ny **Phase 6 (VALGFRI)** — ett åpent fritekst-spørsmål; skriver `free-context.md` ordrett kun hvis bruker gir tekst (hopper over → ingen fil). Resume-logikk + completion-report + retningslinjer oppdatert (5 strukturerte = fullføringskontrakt; fri kontekst valgfri 6.).
+- **`commands/onboard.md`:** prosess-liste (6. fri kontekst, valgfritt), Task-prompt (kjør Phase 6 hvis fila mangler), status-tabell (egen valgfri-rad; teller ikke i X/5).
+- **11 agenter:** uniform 6. bullet `free-context.md — Fri kontekst (valgfri) …` (grep 11/11).
+- **Kapp-tradeoff (bevisst):** fri kontekst kappes til `maxValueLen` (160) i det ambiente teaser-et — K3 krever bare «kappet til budsjett»-synlighet, og agentene leser full fil via fallback. Egen, mer raus fri-kontekst-cap er en triviell oppfølging hvis 160 viser seg for kort i praksis (ikke gjort — unngår knott uten påvist behov).
+- **Verifisert:** user-data 25/25 (+9 fri-kontekst) · test-hooks 11/11 (+1: K3-ambient) · kb-update 200 · kb-eval 100 · validate PASSED (239/0/0) · kb-integrity 192/192 (220 baseline-warns) · discovery 13/13 · gitleaks 3 PRE-EKSISTERENDE (`playground/vendor/`).
+- **Neste:** C2.3 (`os_scheduler_cadence` + `enabled` skrives av onboarding; round-trip mot `parseScheduleConfig`).
+
+### C2.3 — RESULTAT (levert, TDD test FØR kode)
+
+**Mål nådd:** onboarding skriver `scheduled_detection:`-blokka (`enabled` + `os_scheduler_cadence`) til den bruker-eide configen, og `parseScheduleConfig` leser den tilbake til samme verdier → **K5 oppfylt** (round-trip bevist deterministisk). Brukeren slipper å hånd-redigere den gitignored fila.
+
+- **Deterministisk kjerne (K5):** ny **`serializeScheduleConfig(config)`** i `detection-schedule.mjs` — invers av `parseScheduleConfig`, lagt RETT VED parseren (én formatsannhet, ingen andre-parser). Skriver alle fire kjente nøkler normalisert slik `coerce()` leser dem, så `parseScheduleConfig(serializeScheduleConfig(c))` round-tripper (`daily`/`interval`/`enabled`/`interval_days`; garbage-kadens → `daily`).
+- **Gated skrive-CLI:** ny **`scripts/kb-update/write-schedule-config.mjs`** (`--enabled` `--cadence` `[--home]`) — **MERGER** på eksisterende config (`parse → override KUN de to onboarding-eide nøklene → serialize`), så `interval_days`/`include_skill_lifecycle` satt andre steder overlever. Pure node, **Claude-fri** (kun ToS-rasjonale i kommentarer, ingen invokasjon); ikke en `DETECTION_STEP`. Skriver til `resolveConfigPath` (bruker-eid).
+- **Gating-invariant (ufravikelig):** sikkerhetskopi via ny **`backupFile(filePath, backupRoot)`** i `lib/backup.mjs` (presis enkeltfil-backup — drar IKKE org/ inn i backup ved hver kadens-endring, slik `backupDir` ville) + **`atomicWriteSync`** (aldri rå fs-write). Backup er no-op ved første skriv (ingenting å bevare); backup tas før overskriving.
+- **Designvalg som avvek fra plan-teksten (begrunnet):** scheduler-spørsmålet ligger i **orkestratoren (`onboard.md`)**, ikke i `onboarding-agent.md`. Agenten har kun `Write` (ingen Bash) og kan ikke kjøre den gatede CLI-en; orkestratoren har `Bash` + `AskUserQuestion`. Agenten fikk en note om at scheduler håndteres av orkestratoren etter intervjuet. (Speiler C2.2-mønsteret: dokumenter avviket, ikke følg plan-bokstaven når koden tilsier annet.)
+- **`onboard.md`:** ny «Planlagt deteksjon»-seksjon (aktiver Ja/Nei opt-in → kadens daily/interval, daily anbefalt → gated CLI-kall + kort rapport); scheduler-rad i `--status`; «dekker»-liste utvidet med pkt. 7. **`onboarding-agent.md`:** note om at scheduler er orkestratorens jobb.
+- **Kjent begrensning (pre-eksisterende, ikke C2.3-introdusert):** CLI-kallet i `onboard.md` bruker relativ `node scripts/...`-sti (antar cwd = plugin-rot), identisk konvensjon som `kb-update.md`. Org-/config-stiene er home-baserte (robuste).
+- **Verifisert:** detection-schedule 33/33 (+10: serialize round-trip + writeScheduleConfig merge/backup/end-to-end) · backup-restore 15/15 (+3: `backupFile`) · kb-update 213 · kb-eval 100 · validate PASSED (239/0/0) · test-hooks 11/11 · kb-integrity 192/192 (220 baseline-warns) · discovery 13/13 · gitleaks 3 PRE-EKSISTERENDE (`playground/vendor/`).
+- **Neste:** C2.4 (verifiser privat-sektor-paritet #4 + lukk evt. §167-residu).
+
+### C2.4 — RESULTAT (verifikasjon + regresjonsvakt, TDD rød→grønn)
+
+**Mål nådd:** **K4 verifisert oppfylt** og låst mot regresjon → privat-sektor-paritet i onboarding er bevist, ikke antatt.
+
+- **Funn (kildehistorikk):** privat-greinen ble innført i commit **`6e1fc6d`** («#7d privat-sektor-paritet … onboarding-forgrening … audit §5»), FØR C2.1–C2.3. §167-onboarding-residuet (audit §5 punkt #1) var altså **allerede lukket i kode**. C2.4 var dermed ekte **verifikasjon**, ikke nybygg — som planraden forutså.
+- **K4 bekreftet mot kilden** (`agents/onboarding-agent.md` Phase 1): sektortype forgrener offentlig/privat; privat sektor-grein lister Finans/bank/forsikring, Industri/produksjon, Handel, Energi, Telekom (**bank slipper «Annet»**); privat reg-sett har DORA, Finansforetaksloven, Finanstilsynets IKT-forskrift, Verdipapirhandelloven, Hvitvaskingsloven; private spørres ALDRI Offentleglova/Arkivloven/Forvaltningsloven. Orkestratoren (`commands/onboard.md`) er sektor-nøytral (delegerer intervjuet).
+- **Ny regresjonsvakt:** `tests/test-onboarding-parity.sh` (14 asserts mot kilden, ikke fixture — onboarding er interaktivt `AskUserQuestion`, ingen output-fixture). Bruker `lib/e2e-helpers.sh`-mønsteret som de andre output-testene. Wiret inn i `tests/run-e2e.sh` (`--onboarding`, med i `--all`). **TDD-diskriminering bevist:** testen kjørt mot en strippet offentlig-only-kopi → 13/14 FAIL (rød); mot ekte fil → 14/14 PASS (grønn).
+- **§167-residu (d) bevisst IKKE bygget (begrunnet):** anbefalingens «betinget Fase 3-gren med egen dataklassifiserings-taksonomi for regulert privat sektor» er gull-plating UTENFOR K4. Dagens Fase 3-taksonomi (Åpen/Intern/Fortrolig/Strengt fortrolig) er en alminnelig norsk *bedrifts*-klassifisering — en privat virksomhet fullfører Fase 3 uten hindring; kun «Hemmelig (sikkerhetsloven)» er offentlig-spesifikk og velges simpelthen ikke. K4 krever ikke egen taksonomi. Ingen knott uten påvist behov (speiler C2.2-/C2.3-disiplinen).
+- **Medrydd (plan §Avgrensning):** feildøpte `docs/onboarding-ros-analysis.md` (en Windows clone-to-PR-bidragsyterguide, ikke onboarding-analyse) **omdøpt** → `docs/windows-clone-to-pr-ros-guide.md` (`git mv`); plan- + brief-referanser oppdatert. Fjerner reell forvekslingsfelle (utvikler- vs. virksomhets-onboarding).
+- **Avgrensning (bekreftet):** audit §5 punktene #2–#6 (sektor-parametrisering i classify/dpia/ros/frimpact/utredning/review, README/help/playground privat-bane) er IKKE C2.4-scope. Mange ble adressert i `6e1fc6d`; gjenstående er eget arbeid utenfor C2 (onboarding-paritet). Ikke eskalert uten godkjenning.
+- **Verifisert:** onboarding-parity 14/14 (NY) · validate PASSED (239/0/0) · e2e alle suiter grønne · discovery 13/13 · test-hooks 11/11 · kb-integrity 192/192 (220 baseline-warns) · gitleaks 3 PRE-EKSISTERENDE (`playground/vendor/`).
+- **C2 KOMPLETT** (C2.1→C2.4 ✅). **Neste:** C3 (kurs/training, #25) — eller release-beslutning (v1.16.0) i push-vindu.

docs/playground.md

@@ -1,4 +1,4 @@
-# ms-ai-architect — Playground (v3 / v1.15.0)
+# ms-ai-architect — Playground (v3 / v1.16.1)
 
 Interaktiv decision-builder + rapport-viewer for Microsoft AI-beslutninger. Imported from `CLAUDE.md` via pointer.
 
@@ -7,7 +7,7 @@ Erstatter v2 5-stegs-pipelinen med en multi-surface-app som persisterer state og
 **v1.15.0 (sesjon 5 av ~8 i v2-prosjektet):** Project-surface byttet fra v2 `renderProjectSurface` (screen-tabs + category-tabs + per-command paste-cards) til v3 `renderProjectView` (sidebar med 17 artifacts + main-area + import-modal overlay). `renderActive()` ruter `project`-surface til `renderProjectSurfaceV3()` som wrapper renderProjectView + topbar + app-shell. V2-surface helt fjernet: `renderProjectSurface` (152 linjer), `renderCommandSubCard` (87 linjer), `rehydratePasteImports` (15 linjer), `currentProjectScreen`, `ACTIONS['project-screen']`, 5 v2-CSS-klasser. Zombie-handlers beholdt for test-back-compat: `currentProjectTab`, `ACTIONS['project-tab']`, `ACTIONS['parse']`, `handlePasteImport`, `window.__handlePasteImport`. 2 fingerprint-gap lukket: requirements.headers + license.headers. `migrateDataVersion` utvidet med `parserFor` → demo-state (kun `raw_markdown`) auto-parses til `project.artifacts[cid]`. Ship-QA-bugfixes: `components-tier4-project-view.css` lagt til i `<link>`-kjeden (manglet → modal-overlay og two-column layout virket ikke); `renderImportModal` setter `data-open="true"` (DS-kontrakt).
 
 - **Fil:** `playground/ms-ai-architect-playground.html` (~3870+ linjer, single-file v3-arkitektur)
-- **4 surfaces:** Onboarding (18 felles felt — 4 strukturerte / 14 fritekst etter v1.10.0) → Home (prosjekt-liste + 3 entry-tracks) → Catalog (25 commands gruppert i 5 expansion-grupper med søk) → **Project v3** (sidebar med 17 artifacts gruppert i 4 kategorier + søk + main-area med per-artifact view eller overview med top-risks/next-actions + import-modal som DS-overlay)
+- **4 surfaces:** Onboarding (18 felles felt — 4 strukturerte / 14 fritekst etter v1.10.0) → Home (prosjekt-liste + 3 entry-tracks) → Catalog (29 commands gruppert i 5 expansion-grupper med søk) → **Project v3** (sidebar med 17 artifacts gruppert i 4 kategorier + søk + main-area med per-artifact view eller overview med top-risks/next-actions + import-modal som DS-overlay)
 - **Persistens:** IndexedDB-primær med localStorage-fallback. Schema-versjonert (`STATE_KEY = 'ms-ai-architect-state-v1'`) med eager `MIGRATIONS`-pipeline. v1.10.0 introduserer `dataVersion v1→v2`-migrasjon (idempotent) som backfill-er `verdict`+`keyStats`.
 - **17 rapport-renderers (felles grunnskjelett):** Alle wrapper output via `renderPageShell()` med eyebrow + h1 + valgfri verdict-pill + valgfri key-stats-grid + arketype-spesifikk body. Parser → struktur → HTML rutet via kanonisk archetype-routing-tabell.
 - **Foundation-helpers:** `renderPageShell`, `renderVerdictPill`, `renderKeyStatsGrid`, `inferVerdict`, `inferKeyStats`, `KEY_STATS_CONFIG`.
@@ -15,18 +15,18 @@ Erstatter v2 5-stegs-pipelinen med en multi-surface-app som persisterer state og
 - **Theme:** Mørk default + lys theme-toggle med Aksel-tokens i begge moduser (lagt til i v1.10.0). Persistert i `localStorage('ms-ai-architect-theme')`. Theme-bootstrap-script i `<head>` unngår FOUC.
 - **Eksport/import:** JSON Decision Record-envelope (Blob + FileReader), schema-versjon-bevisst på import.
 
-## Validering (v1.15.0-tall)
+## Validering (v1.16.0-tall, uendret i v1.16.1 — playground-koden uendret siden v1.15.0)
 
 | Test | Kommando | Dekning |
 |------|----------|---------|
-| Statisk struktur | `bash tests/test-playground-v3.sh` | 219 PASS, 2 WARN (pre-eks.) — vendored CSS, surfaces, 25 commands, 14 parsere, 17 renderers via PROJECT_VIEW_CONFIG.renderers-routing, action-handlers |
+| Statisk struktur | `bash tests/test-playground-v3.sh` | 223 PASS, 2 WARN (pre-eks.) — vendored CSS, surfaces, 29 commands, 14 parsere, 17 renderers via PROJECT_VIEW_CONFIG.renderers-routing, action-handlers |
 | Parser-fixtures | `bash tests/test-playground-parsers.sh` | 70 PASS — 17 fixtures × parser-routing |
 | Migrasjon | `bash tests/test-playground-migrations.sh` | 16 PASS — v1→v2 + v2→v3 idempotent migrasjon |
 | Fingerprints | `bash tests/test-playground-fingerprints.sh` | 32 PASS — 17-fixture true-positive + 4 anti-match + API-sanity |
 | Project-view | `bash tests/test-playground-projectview.sh` | 30 PASS — 4 view-states + nav-søk + null-guard |
 | ACTIONS | `bash tests/test-playground-actions.sh` | 19 PASS — 6 pure-state-handlers + projectViewUiState |
-| Kombinert (E2E) | `bash tests/run-e2e.sh --playground` | 386 PASS, 0 FAIL, 2 WARN |
-| Plugin-validering | `bash tests/validate-plugin.sh` | 219 PASS |
+| Kombinert (E2E) | `bash tests/run-e2e.sh --playground` | 390 PASS, 0 FAIL, 2 WARN |
+| Plugin-validering | `bash tests/validate-plugin.sh` | 239 PASS |
 | Manuell A11Y QA | Se `playground/MANUAL-CHECKLIST.md` | 10 seksjoner inkl. axe-core-kjøring per surface |
 | A11Y-rapport | `playground/A11Y-RAPPORT.md` | Statisk vurdering klar — browser-axe-kjøring pending |
 

docs/r11-flag-format-2026-07.md

@@ -0,0 +1,92 @@
+# R11 flag format — the judge-pass → fix-work-list contract
+
+**Spec for the flag record the R7–R10 judge pass emits and R11 (the fix step)
+consumes. A flag is a judged claim the pass could NOT ground against its cited
+Microsoft Learn source. The pass never fixes — it stamps (born-verified) or
+flags; R11 does the human-confirmed fix.**
+
+Status: design spec (R6 Step 5). Builds on the frozen v3.1 claim judge
+(`scripts/kb-eval/judge-claim-prompt-v3.1.md`) and the judge-pass ledger
+(`scripts/kb-eval/judge-pass-manifest.mjs`, R6 Step 4). Consumed by R11.
+
+---
+
+## Where a flag comes from
+
+The v3.1 judge returns, per claim, a strict-JSON result (no fence):
+
+```
+{"file":"<FILE>","results":[
+  {"id":"<claim id>","judge_verdict":"grounded|not_grounded|source_silent",
+   "rule":"<R1-R8 or empty>","evidence_url":"<url actually used>",
+   "evidence_quote":"<verbatim quote or empty>","reason":"<one sentence>"}
+]}
+```
+
+The pass augments each **non-grounded** result (`judge_verdict !== 'grounded'`)
+into a flag record. This is a **minimal augmentation, not a pass-through** — the
+judge output is a subset of the flag record; the pass adds four fields from the
+fan-out context and the claim manifest:
+
+| Added field | Source |
+|-------------|--------|
+| `file` | the fan-out context (one subagent per file) — also echoed by the judge output's top-level `file` |
+| `line` | the claim manifest (`scripts/kb-eval/extract-judge-claims.mjs` output) |
+| `claim` | the claim manifest (the verbatim claim text that was judged) |
+| `disposition` | mapped from `judge_verdict` (see the vocabulary mapping below) |
+
+## The flag record
+
+A flag record is the union of the judge result and the four augmented fields:
+
+```
+{
+  "id":            "<claim id>",
+  "judge_verdict": "not_grounded" | "source_silent",   // 'grounded' is never flagged
+  "rule":          "R1".."R8" | "",
+  "evidence_url":  "<url the judge actually used>",
+  "evidence_quote":"<verbatim quote or empty>",
+  "reason":        "<one sentence: what the source said vs the claim>",
+  "file":          "skills/.../x.md",
+  "line":          <number>,
+  "claim":         "<verbatim claim text>",
+  "disposition":   "outdated" | "wrong" | "unsourced"   // R11 fix disposition
+}
+```
+
+In the ledger (R6 Step 4), a flagged file is a manifest record with
+`per_file_verdict: "flagged"` and one `flags[]` entry per non-grounded claim —
+the structural mirror of `spor0-fix-manifest.json`'s "fix-record with
+`applied:false`". A file is `flagged` if **any** judgeable claim is non-grounded
+(the born-verified rule is AND: `pass` requires EVERY claim grounded).
+
+## The two vocabularies + the mapping
+
+There are two distinct enumerations, and conflating them is the trap this spec
+exists to prevent:
+
+1. **`judge_verdict`** — the judge's per-claim output (v3.1 prompt):
+   - `grounded` — the source confirms the claim → never flagged.
+   - `not_grounded` — the source contradicts / does not support the claim.
+   - `source_silent` — the source does not address the claim at all.
+
+2. **`disposition`** — the R11 fix disposition, the correctness vocabulary from
+   `scripts/kb-eval/lib/base-rate.mjs` (`VERDICTS`): `correct`, `outdated`,
+   `wrong`, `unsourced`. Its `ERROR_VERDICTS` subset — `outdated` and `wrong` —
+   are the only ones R11 treats as **fix targets**. `unsourced` is recorded but
+   is not, on its own, a content error (no MS source confirms it either way).
+
+**Mapping** (`judge_verdict` → `disposition`):
+
+| `judge_verdict` | `disposition` | R11 fix target? |
+|-----------------|---------------|-----------------|
+| `grounded` | `correct` | no (never flagged) |
+| `not_grounded` | `outdated` or `wrong` | **yes** — the human assigns which at R11 |
+| `source_silent` | `unsourced` | no (flagged, but not a fix target) |
+
+`not_grounded → {outdated, wrong}` is deliberately a one-to-two mapping: the
+judge establishes the claim is not grounded; whether it is stale-but-once-true
+(`outdated`) or never-true (`wrong`) is a human call at R11, re-verified against
+the live source (verification duty). The pass never auto-fixes — every flag is
+human-confirmed in R11, so a judge false-positive becomes a human review, never
+silent corruption of a public file.

docs/ref-kb-audit-2026-06.md

@@ -0,0 +1,37 @@
+# Reference-KB audit — verifisert ground truth (2026-06-26)
+
+_Read-only audit av de 389 ref-filene under `skills/<skill>/references/**/*.md`. Reproduserbar via `python3 scripts/kb-eval/ref-file-audit.py`. Utløst av spørsmålet «måler vi kvaliteten på ref-filene, og brukes de best mulig?». Beslutningsnotatet som velger retning lever separat (se nederst)._
+
+## Bakgrunn
+Skill-kvalitetsscoringen (Spor D, `scripts/kb-eval/`) scorer SKILL.md-forfatterkvalitet + ref-filenes STRUKTUR/hygiene — ikke substansiell innholdskorrekthet mot MS Learn. KB-refresh (`scripts/kb-update/`) flagger staleness, men gir ingen score. Gapet — «stemmer ref-innholdet mot MS Learn i dag» — måles ikke. Denne auditen kartla ref-filenes faktiske tilstand før vi velger hvordan gapet skal lukkes.
+
+## Selvkorreksjoner (premiss-verifisering fanget to artefakter i en tidligere kjøring)
+- **«220 orphans» → ekte: 0.** Den første heuristikken testet kun om filnavnet var navngitt i en hub. Men 220 filer nås via **mappe-referanse** (progressive disclosure — K5 named-ratio-mål er bare 0,2). Folder-bevisst telling gir 0 ekte orphans. KB-en bærer ingen død vekt.
+- **«136 datoløse» → ekte: 6.** Heuristikken krevde full `YYYY-MM-DD`. 130 filer har bevisst **måned-presisjon** (`YYYY-MM`), som er konvensjonen `report-changes.mjs` forutsetter. Kun 6 er ekte datoløse.
+
+## Verifiserte funn
+
+| Dimensjon | Tall | Vurdering |
+|-----------|------|-----------|
+| **Inventar** | 389 filer: advisor 62, engineering 153, governance 78, infrastructure 34, security 62 | — |
+| **Størrelse** | median 481 linjer, snitt 507, **183/389 >500 linjer**, største 1265 (`adr-template.md`); kun 2 filer ≤100 | KB-en er nesten utelukkende store filer. Granularitets-spørsmål (se notat). |
+| **Dato** | 253 dag-presise · 130 måned-presise · **6 ekte datoløse** | De 6 (4 er AI Act-filer) bør stemples — kort, høyverdi fiks. |
+| **Reachability** | 169 navngitt · 220 via mappe · **0 ekte orphans** | Ingen død vekt. Mappe-referanse er den dominerende lastemekanismen. |
+| **Kilde-URI** | **83 filer (21 %) har ingen MS Learn/docs-URL** | Noen legitimt kildeløse (maler/metodikk); andre gjør MS-påstander uten sporbar kilde → ikke auto-verifiserbare. |
+| **Metadata** | **34 distinkte prosa-header-nøkler**, 0 YAML-frontmatter (`Category` ×322 vs `Kategori` ×42; `Last updated` vs `Sist oppdatert` vs `Dato` vs `Oppdatert`) | Fragmentert → skjør detektor, ingen maskinlesbar kilde-URI for en korrekthets-judge. |
+| **Topologi** | flatt tre; N3 forbyr ref→ref-lenker; kun 2/389 har .md-kryss-lenke | Bevisst — progressive disclosure, ikke en graf. |
+| **TOC** | 384/389 store filer uten TOC (N4) | Reell, men lavvekt — skills står på 91–96 likevel. Polish. |
+
+## Eksisterende Spor D-scorer (kontekst)
+advisor 91 · engineering 96 · governance 96 · infrastructure 96 · security 96. **Null under mål (90).** Struktur/forfatterkvalitet er altså ikke problemet — innholdskorrekthet er den umålte aksen.
+
+## De 6 ekte datoløse (quick-fix-kandidater)
+- `ms-ai-advisor/references/architecture/decision-trees.md`
+- `ms-ai-governance/references/monitoring-observability/anomaly-detection-ai-systems.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-fria-template.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
+
+## Neste steg
+Et faktabasert, best-practice-forankret beslutningsnotat (5 akser: struktur/størrelse · innhold/korrekthet · kvalitetsmåling · MS Learn-fetch-dekning · metadata-substrat) avgjør retning før noen av de 389 filene endres. Se `docs/ref-kb-direction-note-2026-06.md` (genereres). Bakgrunn for gapet: `docs/kb-refresh-backlog-2026-06.md` («Separate spor»).

docs/ref-kb-correctness-program-2026-06.md

@@ -0,0 +1,149 @@
+# Program — Reference-fil-korrekthet mot nær-100 % + mekanisme som holder den der
+
+_Opprettet 2026-06-26. Operatør-mandat (eksakt): «Alle reference-filene må til enhver tid være 100 % til å stole på, og du må lage en mekanisme som sikrer dette.» Full kvalitetsoffensiv godkjent; Spor 0 først, så grønt lys for skala (Spor 1–3). Dokumenteres skikkelig her; Voyage (`/trekplan` / `/trekexecute`) er foreslått motor for skala-fasen._
+
+_Forutsetning: S1 de-risket judgen (v1 FAIL → v2 målrettet iterasjon GATE PASS, recall 84,2 % / presisjon 84,2 % — **historiske S1-tall**; judgen er senere herdet og adoptert som **v3.1 med P 100 % / R 100 %** på G5b-korrigert gull, se §8 G1/G2). Grunnlag: `docs/ref-kb-workflow-plan-2026-06.md` (Fase 0–4 + roadmap), `docs/ref-kb-audit-2026-06.md`, `docs/ref-kb-direction-note-2026-06.md`._
+
+---
+
+## 1. Ærlig ramme (premisser programmet bygger på — ikke re-litiger)
+
+1. **«100 % til enhver tid» er en *prosess*-garanti, ikke en *øyeblikks*-garanti.** Microsoft endrer kildene kontinuerlig; ingen statisk fil kan være korrekt i evig tid. Den oppnåelige garantien er: *intet upekt/uverifisert innhold shipper, og enhver drift fanges innen én refresh-syklus.* Det er den operasjonelle definisjonen av «100 % til å stole på» (§4).
+2. **De 38 kjente feilene er et utvalg, ikke fasiten.** Målt på 255 volatile påstander; base-rate 13,4 % ⇒ det fulle korpuset (~306 kildebelagte filer) har statistisk hundrevis av samme feilklasse vi ennå ikke har sett. Spor 0 fikser utvalget; Spor 1 avdekker resten korpus-vidt.
+3. **Taket på én judge-runde er ~84 % recall.** Judgen er en høystakk-reduserer, ikke siste autoritet. Nær-100 % *fiks*-korrekthet oppnås av loopen (judge flagger → menneske bekrefter mot kilde → fiks), ikke av judgen alene. **Aldri auto-fiks.**
+4. **Pris/unsourced er maskin-uverifiserbar** (74 % av pris; JS-rendrede Azure-sider). Disse merkes eksplisitt «ikke maskinverifiserbar» og forblir operatør-gated. Nær-100 %-målet gjelder den maskin-verifiserbare populasjonen (`sku/version/tpm/status/region/taxonomy`).
+
+## 2. Mål (suksesskriterium — måles mot brukerverdi)
+
+En bruker som chatter med pluginen får **korrekte, kilde-belagte MS-svar**, og mekanismen **holder det slik automatisk**: (a) flagget feilrate på maskin-verifiserbar populasjon < ~2 % målt på et *ferskt* gull-utvalg; (b) ingen `reference`-fil shipper uten kilde + verifiseringsdato; (c) drift fanges innen én KB-refresh-syklus; (d) pris/unsourced er ærlig merket og operatør-gated.
+
+## 3. De fire sporene
+
+### Spor 0 — Fiks de kjente 38 nå (judge-uavhengig, trygt) — STARTET
+Fiks-manifest: `scripts/kb-eval/data/spor0-fix-manifest.json` (38 fikser, 25 filer, deterministisk fra gull-settet). Hver fiks har `reverify_required: true`.
+- **Protokoll per fiks (ufravikelig):** (1) re-hent kilden (`microsoft_docs_fetch` på `source`) og bekreft korrekt verdi *live* (gull-`notes` er subagent-produsert — verifiseringsplikten krever fersk bekreftelse FØR en offentlig fil endres); (2) lokaliser den eksakte foreldede strengen i fila; (3) erstatt med kilde-bekreftet verdi; (4) sett `fixed: true` + `verified`-stempel.
+- **Rydd tverteklyngene:** AI Search storage-tall er utdaterte *og* selvmotsigende på tvers av `rag-cost-optimization.md`, `embedding-models-selection.md`, `rag-query-cost-reduction.md`, `vector-storage-cost-optimization.md` — reconcile til én kilde-sann verdi. Samme for «Default/Enterprise → Quota Tiers»-omtalen (4 filer).
+- **Kvalitets-disiplin:** kjøres i en *fokusert* sesjon (ikke som hale på en mettet kontekst) — offentlige filer for hele Norge tåler ikke hastverk.
+- **Verifisering:** re-kjør judge på de 38 → alle `grounded`; storage-tall konsistente på tvers; suite grønn.
+
+### Spor 1 — Avdekk *hele* feilsettet korpus-vidt (S3-forutsetning + skalering)
+- **Authority-backfill:** hver kildebelagt fil → sin autoritets-URL (recon: kun 3 URL-er har `authority_source` i dag — re-verifiseres mot `url-registry.json` FØR start).
+- **Full frontmatter** (Fase 2 full): `type` / `source` / `verified` / `verified_by` per fil (OKF-kompatibel form).
+- **Korpus-pass:** kjør v2-judgen over *alle* verifiserbare påstander i alle ~306 filer (ikke bare 255-utvalget). Output: komplett flagg-liste → mater Spor 0-protokollen korpus-vidt.
+- **Kostnad (ærlig):** ~2700 ikke-batchbare `microsoft_docs_fetch` per full-pass — IKKE «$20–40 Batch». Flersesjons.
+- **Verifisering:** hver ikke-advisor kildebelagt fil har `authority_source`; frontmatter validerer; flagg-lista persistert.
+
+### Spor 2 — Press pålitelighet mot 100 % (hardningen)
+- **(a) Ensemble for recall:** union av N *diverse* judge-linser (f.eks. eksakt-verdi / strukturell / status-fokus). Mål single vs ensemble på gull-settet FØR adopsjon (operatørens «bygg begge og mål»). Union hever recall (mål: > 84,2 %), senker presisjon — tapet absorberes av menneske-i-loopen (c). Adopter kun hvis gull-målt forbedring.
+- **(b) Gull-rekonsiliering:** ✅ **FERDIG (2026-06-30)** — alle 12 uenigheter løst mot live kilde. **4 gull-feil rettet** + 1 note-fiks; **8 judge-feil** dokumentert som kalibreringsmål. Herdet fasit: presisjon 84,2 %→**92,1 %**, recall 84,2 %→**87,5 %** (judgen var bedre enn rå-bakeoffen viste — fasiten var kontaminert). Nedre-grense-policy vedtatt (grov understatement >~2× = feil). **0 uløste uenigheter.** Full logg: `ref-kb-gold-reconciliation-2026-06.md`; herdet rapport: `judge-bakeoff-report-v2-reconciled.{json,md}` (frozen v2 beholdt som gate-artefakt).
+- **(c) Menneske-i-loopen fiks-protokoll:** judge flagger → operatør/ekspert bekrefter mot kilde → fiks + `verified`-bump. Garanterer ~100 % *fiks*-presisjon selv ved 84 % *judge*-presisjon. **Aldri auto-fiks.**
+- **Verifisering:** ensemble P/R ≥ single på gull; 0 uløste judge-vs-gull-uenigheter; dokumentert at ingen fiks shippet uten menneske-bekreftelse.
+
+### Spor 3 — Mekanismen som holder det nær-100 % (Fase 4) — SE §4
+Create-time-guard + kadens-judge + rapporterende gulv + frontmatter-kontrakt. Detaljert under, fordi dette ER «mekanismen som sikrer dette».
+
+## 4. MEKANISMEN — «100 % til å stole på, til enhver tid» (operatørens kjernekrav)
+
+> **Status (2026-06-29):** Port 1 ✅ · Port 2 ✅ (`5a0ba1f`) · **Port 3 ✅ KOMPLETT** — inkrementell stale-since-verified (`fea5df5`), rapporterende gulv / SessionStart KB-tillit-signal (`08e7e72`), CT5 sourcedness som erstatter K8 (`75ee9ec`), og periodisk full-pass worklist (P3d, `a1d72fa`). **P3d-designvalg avklart: arbeidsliste** (operatør kickstarter judging separat — §5 «ikke auto-lansert», §4c «aldri auto-fiks»; den ærlige ~2700-fetch/flersesjons-kosten forekluderer inline på korpus-skala). `report-full-pass-worklist.mjs` er lastmod-UAVHENGIG (gater på Port 1-kontrakt `type:reference`+`source` + cadence-alder på `verified`, default 90 d), så den fanger drift-klassen inkrementell bommer (staleness-recall 0/40). Ekte kjøring: 389 ref-filer alle `unmigrated` ⇒ **dormant til Spor 1-migrering** backfiller `source`/`verified`. **Mekanismen (Spor 3) er nå komplett.**
+
+Garantien er en **invariant håndhevet av tre porter**, ikke et engangs-opprydding:
+
+> **Invariant:** Hver maskin-verifiserbar påstand i en `reference`-fil er bekreftet mot sin siterte kilde innen siste `<kadens>`-vindu; intet `reference`-innhold shipper uten `source` + `verified`; drift flagges innen én refresh-syklus.
+
+**Port 1 — Frontmatter-kontrakt (tilstanden).** Hver fil bærer:
+`type` (`reference|template|methodology|regulatory`) · `source` (autoritets-URL) · `verified` (dato sist bekreftet korrekt mot kilde) · `verified_by` (`judge-vN` / `human`). Template/methodology/regulatory er unntatt korrekthets-scope (skal ikke ha MS-`source`).
+
+**Port 2 — Create-time-guard (innløpet).** `scripts/kb-update/lib/transform.mjs` (`buildKbHeader`/`validateKbFile`) + `generate-skills`:
+- Nekter å emitte en `reference`-fil uten `source`.
+- Nytt/regenerert innhold kjøres gjennom judgen FØR commit → *født verifisert* (`verified=<i dag>`, `verified_by=judge-vN`). Ellers re-introduserer neste KB-update driften (å øse en lekk båt).
+- **Verifisering:** generator-test — `reference`-output har `source`+`verified`; mangler `source` ⇒ hard feil.
+
+**Port 3 — Kadens-judge (vedlikeholdet).** På KB-refresh-kadens (IKKE SessionStart — for dyrt):
+- *Inkrementell:* re-judge filer hvis `source` sitemap_lastmod > `verified` (akkurat det staleness-loopen ser — billig, fanger lastmod-synlig drift).
+- *Periodisk full-pass:* judge over hele korpuset (fanger den drift-klassen staleness bommer på — base-rate viste staleness-recall 0/40).
+- Flagg → menneske-bekreft → fiks → `verified`-bump. **Rapporterende gulv** (Spor D peker: «N filer eldre enn X siden verified» / «M ubekreftede flagg»), ikke hard SessionStart-gate (unngå alarm-tretthet på et 84 %-signal).
+- **Verifisering:** SessionStart surfacer trust-ferskhets-signal uten falske alarmer; operatør-waiver-sti finnes; CT5 (sourcedness) ERSTATTER K8s rolle.
+
+**Hvorfor dette gir «til enhver tid»:** du kan ikke garantere null drift i et øyeblikk (MS endrer ting når som helst), men du garanterer at (a) intet uverifisert shipper (Port 2), (b) tilstanden er eksplisitt og sporbar (Port 1), (c) drift fanges innen én syklus (Port 3). Det er den sterkeste ærlige garantien — og den er buildbar.
+
+## 5. Voyage-bruk (operatør: «kanskje bruke Voyage aktivt»)
+
+- **Skala-fasen (Spor 1–3) er et lærebok-flersesjons-implementeringsløp** → `/trekplan` med dette dokumentet som brief gir en revidert, adversarielt gjennomgått implementeringsplan; `/trekexecute` kjører den på tvers av sesjoner med failure-recovery.
+- **Spor 1 korpus-pass** kan dra nytte av Voyage-orkestrering (parallelle judge-agenter per fil, schema-validert output).
+- **Spor 0** er lite nok til direkte utførelse (manifest finnes) — trenger ikke Voyage.
+- **Ikke auto-lansert:** Voyage er tung maskineri; operatør kickstarter (`/trekbrief` el. `/trekplan --brief <dette docet>`). Anbefaling: kjør Spor 0 først, så `/trekplan` for Spor 1–3.
+
+## 6. Sekvensering + status (2026-06-26; à jour per §8 2026-07-03)
+
+| Spor | Status | Neste konkrete handling |
+|---|---|---|
+| S1 (de-risk) | ✅ FULLFØRT | — (v2 GATE PASS; historisk — se §8 G1 for adoptert v3.1) |
+| Spor 0 (fiks 38) | 🟡 STARTET (manifest klart) | Kjøres i fokusert sesjon m/ kilde-reverifisering ETTER substrat-migreringen (roadmap R5, `docs/plugin-roadmap-2026-07.md`) |
+| Spor 1 (korpus-skala) | ⏳ plan klar (trekplan v1.7, adversarielt reviewet) | Eksekver substrat-migreringen (roadmap R1–R4); korpus-judge-pass planlegges i R6, kjøres R7–R10 |
+| Spor 2 (hardning) | 🟢 FERDIG — 2a v3.1 MÅLT + ADOPTERT (P 100 / R 100, §8 G1 🟢) · 2b gull herdet + G5/G5b re-adjudert · 2c menneske-i-loop = stående disiplin | — (2c-protokollen brukes i flag→fiks-loopen, roadmap R11) |
+| Spor 3 (mekanisme) | 🟢 Port 1+2+3 ✅ KOMPLETT (inkr/gulv/CT5 + full-pass worklist P3d; v3.1 wired i Port 2+3, §8 G2 🟢) | Mekanismen ferdig; dormant til Spor 1-migreringen backfiller `source`/`verified` (roadmap R1–R4) |
+
+**Avhengigheter:** Spor 0 sekvensert etter substrat-migreringen (roadmap R5 — substratet i ro først). Spor 3 Port 2 (create-guard) MÅ på plass før/sammen med korpus-fiksing (ellers reverserer generatoren). Spor 2b (gull-rekonsiliering) ✅ ferdig 2026-06-30 — bunnsolid fasit på plass før Spor 1 skalerer målingen. Advisor-filer koordineres mot Cosmo-utfasing (S-Cosmo).
+
+**Avhengighet til skill-eval-rutinen (Spor b, eget spor — kanonisert 2026-06-30):** Spor 1 korpus-migrering MÅ kjøres FØR skill-eval-rutine-v2 kalibreres. Koblingen går én vei: migreringen muterer reference-filene (`skills/*/references/`) som skill-scoringen (`scripts/kb-eval/lib/skill-score.mjs` + `eval.mjs`) skanner, og **flytter skill-scoren** via to deterministiske dimensjoner — **CT5** (sourcedness) går `available:false`→aktiv når `**Type:**`/`**Source:**` stemples (`skill-score.mjs:114-122`), og **N4** (TOC) løftes ~0→~1 når `## Innhold`-TOC fødes inn på store filer (387/389 filer >100 linjer, kun 3 har TOC før migrering). Kalibrering av v2 før migrering måler en korpus-tilstand som straks endres ([[gold-freshness-can-invert-adoption]] generalisert). **Paritets-binding (test-håndhevet, ikke import):** `transform.mjs:55-56` holder `TOC_MIN_LINES=100`/`hasToc` i paritet med `eval.mjs.checkN4` via assertion i `test-transform`; skill-eval-v2 som vurderer å endre TOC-terskelen (BP100 vs SC300) MÅ bevare den pariteten, ellers brytes create-guardens fil-fødsel. Migreringen har INGEN runtime-avhengighet til skill-eval (judge/gull er helt separate stakker; metodikk flyter kun KB→skill — port bake-off-disiplinen). **Handlingsrekkefølge:** (a) Spor 1 → (b) re-score skill-eval ETTER migrering for å fange flyttet CT5+N4.
+
+## 7. Verifisering — slik beviser vi «nær-100 %» (nordstjerne)
+Etter Spor 0+1-fiksing: trekk et **NYTT, ferskt gull-utvalg** (friske påstander, ikke de vi fikset mot) og mål feilraten på maskin-verifiserbar populasjon → **mål < ~2 %**. Måling på den fikset-mot prøven er kontaminert; kun en fersk prøve beviser at korpuset faktisk er nær-100 %. Dette gull-utvalget blir også neste kalibreringssett for kadens-judgen.
+
+## 8. Mekanisme-gap-register (MÅ lukkes — stående disiplin)
+
+> **Invariant (operatør 2026-06-30, ufravikelig):** ingen funnet feilklasse forlates som *kun et funn*. Hvert gap mellom en oppdaget feilklasse og mekanismen som forhindrer gjentakelse MÅ føres her med en lukke-fase, og MÅ lukkes i en fremtidig sesjon. Å finne + dokumentere er ikke det samme som å lukke loopen. Når et nytt spor/en ny audit avdekker en feilklasse, legg den til her samme sesjon. Registeret er kanonisk; STATE peker hit.
+
+Status-nøkkel: 🔴 ikke startet · 🟡 pågår · 🟢 lukket.
+
+| # | Gap (mekanismen mangler) | Forhindrer feilklasse | Lukke-fase | Status | MÅ lukkes før |
+|---|---|---|---|---|---|
+| **G1** | Judgen er ikke herdet mot de 8 dokumenterte feilmodusene (`source_silent`-maskerer-fravær, legacy-rad-match, ramme-skifte-tall-overlever, nedre-grense-understatement, eksakt-streng-pedanteri, taksonomi-nyanse, kapabilitet-bom) | Judge-FN/FP påvist i Spor 2b (8 mål, se `ref-kb-gold-reconciliation-2026-06.md`) | **Spor 2a** — judge-prompt-v3, MÅLT single vs v3/ensemble på herdet gull; adopter kun ved målt forbedring (ad-hoc-patch overfitter + bytter P/R) | 🟢 **LUKKET 2026-06-30 — v3.1 MÅLT + ADOPTERT.** 45-veis fan-out kjørt (255 claims, 45 Opus-4.8-xhigh-subagenter, live MS Learn, én per fil) → deterministisk re-score mot G5b-korrigert gull: **v3.1 = P 100,0 % / R 100,0 % / 0 FP / 0 FN** (TP 39→42: fanget alle 3 gjenstående FN; TN 198 + FP 0 uendret). Forhåndsregistrert gate (hold P=100 ∧ løft R>92,9) **klarert** → **v3.1 adoptert som judge**. Se lukke-logg. | Spor 1 korpus-pass (judgen brukes i ~2700 fetches) |
+| **G2** | Herdet judge er ikke wired inn i Port 2 (born-verified create-guard) + Port 3 (kadens) — uten innplugging binder ikke hardningen mekanisk | Re-introdusert drift ved nye/regenererte filer + kadens-bom | Del av Spor 2a→3: bytt ut v2 med v3 i `transform.mjs`-judge-passet + kadens-runneren | 🟢 **LUKKET 2026-06-30 — v3.1 wired (TDD).** `JUDGE_VERSION 2 → '3.1'` (label-streng, provenance navner adoptert judge eksakt); prompt-/command-sites (`transform-prompt.md`, `kb-update.md` Port 2+Port 3, `generate-skills.md`) byttet `judge-claim-prompt-v2.md → -v3.1.md`. Suite 641/641. Se lukke-logg. | Spor 1 |
+| **G3** | Ingen deterministisk gull-intern-konsistens-vakt (`verdict=correct` mens egen `notes` sier «uverifisert/illustrativ») | Gull-labeling-feil av FP1-klassen (selvmotsigende annotasjon) | Liten TDD-lint over `gold-correctness-set.json` (+ kjøres på fremtidige gull-bygg) | 🟢 **lukket 2026-06-30** | Spor 1 (nytt gull bygges) / §7 friskt utvalg |
+| **G4** | Nedre-grense-policyen lever kun i prosa (denne dok + reconciliation-logg) — ikke kodet i judge-prompt ELLER `build-gold-set`-instruks | Re-introdusert nedre-grense-ambivalens i fremtidige gull-bygg + judge-kjøringer | Kod policyen inn i judge-prompt-v3 (G1) + build-gold-set-instruks | 🟢 **kodet 2026-06-30** (build-instruks + v3 R1); håndheving rir på G1/G2-adopsjon | Spor 1 / §7 friskt utvalg |
+| **G5** | Gull-fasiten kan aldre — ingen friskhets-/re-adjuderings-vakt på selve svarnøkkelen. v3-målingen avdekket at flere judge-«feil» trolig er *utdatert gull*, ikke judge-feil (`genaiops-llm-specific#2`: claim «1600+», live=1900 ⇒ 1,19× tett nedre grense, R1 sier korrekt `grounded`, gull sier `outdated` — gull-standarden er her for streng) | Feil adopsjonsbeslutning bygd på aldrende baseline; falsk feilrate i §7-nordstjernen | Friskhets-mikropass: re-adjuder de ~5 omstridte v3-vs-v2-claims mot live MS Learn (avgjør gull-feil vs judge-feil) + periodisk gull-re-adjudering knyttet til §7 friskt utvalg | 🟢 **lukket 2026-06-30** (G5: 2 gull-feil rettet, 3 judge-feil bekreftet, **reverserte adopsjonsbeslutningen**; **G5b: completeness-caveat lukket** — de 4 v3-FP re-sjekket, ALLE 4 stale gull, v3 → P 100 % / R 92,9 % / 0 FP — se lukke-logg) | v3.1-adopsjon (baseline må være til å stole på FØR ny prompt måles mot den) |
+
+| **G6** | Ingen sikkerhetsgate på ingestion-kjeden (hentet eksternt innhold → korpus): llm-security-pluginen er **deaktivert globalt** (verifisert 2026-07-03 i `~/.claude/settings.json`), så `post-mcp-verify`-hooken (injection-skann på all tool-output, inkl. `microsoft_docs_fetch`) fyrer ikke; commit-gaten dekker kun secrets (gitleaks), ikke injeksjon/steganografi i `.md`-innhold. Tillit til MS Learn dekker faktisk korrekthet — ikke adversarielt innhold i kanalen eller i kodeeksempler/lokalisert stoff | Indirekte prompt-injeksjon/steganografi persistert i offentlig distribuert KB: references-filene blir instruksjonsnær kontekst i fremtidige agent-sesjoner, én forgiftet fil re-serveres til alle brukere (hele Norge) | **R6-briefen designer gaten, to lag** (`docs/ingestion-security-brief-2026-07.md`, committet 2026-07-04): (a) llm-security AKTIV + verifisert fyrende i enhver fetch-økt (kb-update, research, generate-skills, judge-pass); headless-caveat GH #36071 → foreground eller kompenserende skann; (b) deterministisk node-skann (unicode/decode/injection — de DELTE llm-security-detektorene importert in-process, ikke kopiert; operatør-valg 2026-07-04) over endrede `skills/**/*.md` før commit. Håndheves fra R7 og i kb-update-kadensen | 🟡 **Layer B (b) LUKKET 2026-07-04 (TDD).** Bærende gaten bygget: `scan-adversarial-content.mjs` (+ `lib/adversarial-scan.mjs` disposition-kjerne, `lib/adversarial-detect.mjs` llm-security-bro), wiret som sibling til `validate-kb-file.mjs` ved det eneste skrive-chokepunktet (kb-update §3b.d.7/§4/§5 + generate-skills per-batch/pre-commit). Provenance-tiered BLOCK/WARN; injection-flagg → samme menneske-i-loop som status-påstand. 30 tester (692/0). Premiss-korr.: research/research-agent skriver ingenting (kun Layer A); CLI-scan alene misset injection+base64 → importerer rene primitiver. **Layer A (a) gjenstår:** aktiver llm-security i `~/.claude/settings.json` + verifiser `post-mcp-verify` fyrer i én live fetch-økt (§8-verifikasjon). Aktiveringsregelen gjelder STRAKS. | Layer A: R7 (første judge-pass-fetch-økt) / enhver `/architect:kb-update`/`generate-skills`-fetch-økt |
+
+**Ikke mekanisme-gap, men sporet backlog (innhold, ikke loop):** reference-`.md`-fil-fiksene fra Spor 2b (FP1 11000+/40+, FP2 «kun», FP6 Preview/Norway-East, FN2–FN6 utdaterte tall) **+ G5b** (`adr-template.md` fjern «zero permission management»; `multi-region-azure-openai-deployment.md` bytt retired `gpt-35-turbo` → gjeldende modell; `network-resilience-patterns-ai.md` «obligatorisk» → «anbefalt»; `vector-storage-cost-optimization.md` GA-dato `2024-11-01` → `2024-07-01`) er **Spor 0/1**-innholdsarbeid — pekt per-claim i `notes`, ikke gjentakelses-mekanisme. Føres i Spor 0-manifest / Spor 1-korpus-pass, ikke her.
+
+### Lukke-logg
+
+- **G3 🟢 lukket (2026-06-30).** Deterministisk lint `lib/gold-consistency.mjs` + CLI `lint-gold-consistency.mjs` + TDD `tests/kb-eval/test-gold-consistency.test.mjs` (4 tester); wiret som hard gate på `build-gold-set.mjs --write` (dry-run forhåndsviser ikke-fatalt). De 3 nåværende shippet-gull-treffene resolvert med `consistency_waiver` (én — `reserved-capacity-planning#5` — live kilde-bekreftet FØR waiver, verifiseringsplikt). **Bevist mot FP1:** rebuild fra batch-returns flagger `azure-ai-foundry.md#2` (verdict=correct, note «11000+/40+ uverifisert») — nøyaktig claimen Spor 2b fant via dyr live re-fetch. Linten fanger klassen gratis ved bygg.
+- **G4 🟢 kodet (2026-06-30).** Nedre-grense-policyen + konsistens-policyen kodet inn i `build-gold-set.mjs` `_meta.lower_bound_policy` / `_meta.consistency_policy` (instruks subagenter følger ved fremtidig gull-bygg) OG inn i `judge-claim-prompt-v3.md` som **R1** (nedre-grense-understatement >~2× = `not_grounded`). Policyen er nå kodet begge steder; **håndheving** rir på at G1/G2 adopterer en prompt som bærer R1 (v3 hvis bakeoff-målt forbedring; ellers carry R1 inn i adoptert prompt).
+- **G1 (Spor 2a) 🟡 v3 MÅLT + FORKASTET (2026-06-30).** Fan-out kjørt: 255 claims / 45 filer, inline Agent-fan-out (45 Opus-4.8-xhigh-subagenter, live MS Learn, én per fil), aggregert 255/255 rent → `judge-bakeoff-results-v3.json`, deterministisk re-score mot herdet gull → `judge-bakeoff-report-v3.{json,md}`.
+  - **Resultat: v3 P 89,7 % / R 87,5 % vs v2 P 92,1 % / R 87,5 %.** Recall flat, **presisjon −2,4 pp** (FP 3→4). Adopsjonsgaten (P OG R ≥ v2) **ikke klarert** → **v2 beholdt** (forhåndsregistrert regel). Rapportens egen «GATE: PASS» er kun det løse gulvet (R≥0,70/P≥0,60), ikke adopsjonsbaren.
+  - **22 claims flippet v3-vs-v2:** 8 forbedringer (5 FN→TP via R1/R2/R3/R4; 3 FP→TN via R5/R6) + 9 regresjoner (5 TP→FN; 4 TN→FP). Recall-gevinst/-tap kansellerte eksakt; presisjon endte −1 FP. Reglene er **dobbelteggede ved full populasjon** — table-top validerte de 8 målene isolert, men over de 247 øvrige produserer R1–R7 like mange nye feil som de fikser.
+  - **Konkrete bakslag (input til v3.1):** R1 misanvendt på *øvre* grense (`multi-model-strategy-costs#2`: «up to 18» tak, live 28 — R1 er for *nedre* grenser); R7 for ettergivende (`model-selection#8`, `token-usage#3`, `ai-foundry-dr#9` — fulgte til kanonisk side, fant grunnlag, flippet v2s korrekte `not_grounded`) **[G5-korreksjon: `model-selection#8` var gull-feil, ikke R7-bom; se G5-lukke-logg]**; R2/R6 nye FP (`adr-template#1`, `multi-region-azure-openai#2`, `network-resilience#4`, `vector-storage#7`).
+  - **Nyanse → G5:** minst én «regresjon» er trolig aldrende gull, ikke v3-feil (`genaiops#2`, se G5-raden). Derfor må gull-friskhet (G5) avgjøres FØR v3.1 måles mot baseline.
+  - **Neste (ny sesjon):** (1) G5 friskhets-mikropass på de ~5 omstridte claims → fastslå gull-feil vs judge-feil; (2) v3.1 = v3 minus bakslagene (R1 kun nedre grenser; R7-ettergivenhets-vakt; R2/R6 FP-vakt); (3) re-mål samme 45-veis fan-out; (4) adopter vinneren; (5) G2-wiring av adoptert judge.
+- **G5 🟢 lukket (2026-06-30) — REVERSERTE adopsjonsbeslutningen.** Friskhets-mikropass: de 5 omstridte claims (alle v2=`not_grounded`, v3=`grounded`, gull=`outdated`) re-adjudert mot live MS Learn, én Opus-4.8-subagent per claim, blinde for gull/v3-verdikt (anti-anchoring).
+  - **Utfall — 2 gull-feil + 3 judge-feil (even-handed: rettet gull i begge retninger etter ground truth):**
+    1. `genaiops-llm-specific-practices#2` «1600+» — live «over 1 900» (1,19×, tett nedre grense). **Gull-feil** (motsa egen ratifiserte nedre-grense-policy): outdated→correct. v3 `grounded` (R1) korrekt.
+    2. `multi-model-strategy-costs#2` «opptil 18» — live 28 (v2025-11-18). **Judge-feil**: «up to 18» er et *tak* som er brutt; v3 misanvendte R1 (nedre-grense) på en øvre grense. Gull `outdated` opprettholdt. → v3.1 R1-vakt (kun nedre grenser).
+    3. `model-selection-price-performance#8` «Model Router GA» — live GA (nov 2025; kanonisk concept-side uten «(preview)»; siteringssiden bar stale «(preview)»-lenkelabel). **Gull-feil** (aldret — GA skjedde etter gull-bygg): outdated→correct. v3 `grounded` (R7) **vindisert** — R7s «følg til kanonisk side» fant GA korrekt.
+    4. `token-usage-tracking-attribution#3` metrikk-navn — live `ProcessedPromptTokens`/`InputTokens`/`GeneratedTokens`/`OutputTokens`; bare `PromptTokens`/`CompletionTokens` finnes ikke. **Judge-feil**: navnet er load-bearing → eksaktverdi skal styre, R7-leniens feil. Gull `outdated` opprettholdt. → v3.1 R7-load-bearing-vakt.
+    5. `ai-foundry-disaster-recovery-planning#9` Global training + Norway East — live: Global training er GA (ingen «Public Preview»-label), «billigere/ingen residency» stemmer, MEN Norway East er en **Global** (ikke-residency) trenings-region, ikke regional/residency (Standard fine-tune-regioner: North Central US / Sweden Central / East US2). 2 av 3 last-bærende delpåstander feil. **Judge-feil** (v3 `grounded`, ingen regel; ufullstendig fler-delt verifisering). Gull `outdated` opprettholdt. → v3.1 fler-delt-fullstendighets-krav. Fil-fiks (Spor 0): fjern «(Public Preview)» + rett Norway-East-anbefalingen.
+  - **Korreksjon av linje 114 (v3-måling, mot stale gull):** `model-selection#8` var IKKE «R7 for ettergivende» — det var R7 vindisert (gull-feil). v3.1 R7-vakten gjelder kun load-bearing-strenger (`token-usage#3`).
+  - **Baseline-revurdering (re-score, samme gull begge):** v2 falt 92,1/87,5 → **86,8/86,8** (mistet 2 TP→FP på de rettede claims — var oppblåst av stale gull). v3 steg 89,7/87,5 → **89,7/92,1** (2 FN→TN). **v3 slår nå v2 på BEGGE akser.** Den opprinnelige «v3 regredierte» var et stale-gull-artefakt. Den detaljerte 22-flip-tellingen i linje 113 var mot stale gull (2 «regresjoner» = claims 1+3 er nå presisjon-forbedringer FP→TN) — superseded av re-scoren. Artefakter: `judge-bakeoff-report-v2-g5gold.{json,md}`, `judge-bakeoff-report-v3-g5gold.{json,md}`. Gull-`_meta.reconciliation_log` + lint (373 claims, 0 flagget) + suite 641/641 grønt.
+  - **Beslutning:** v3 = **interim adoptert baseline** (slår v2 på fersk gull per forhåndsregistrert gate). v3.1-baren er nå **v3 (89,7/92,1)**, ikke v2 — strengere og ærligere. **Completeness-caveat:** kun de 5 omstridte ble re-sjekket; de 4 v3-FP-claims (`adr-template#1` m.fl.) sitt gull er IKKE re-verifisert (antatt `correct`; spot-sjekk under v3.1). Periodisk gull-re-adjudering knyttes til §7 friskt utvalg (G5-mekanismen er nå et mønster, ikke engangs).
+- **G5b 🟢 lukket (2026-06-30) — completeness-caveat innfridd; baseline løftet til P 100 %.** G5s eksplisitte gjenstående caveat (de 4 v3-FP-claims hadde antatt, ikke verifisert, `correct`-gull) lukket: de 4 (`adr-template#1`, `multi-region-azure-openai-deployment#2`, `network-resilience-patterns-ai#4`, `vector-storage-cost-optimization#7`) re-adjudert mot live MS Learn, **én Opus-4.8-subagent per claim, blind for gull/v3-verdikt** (anti-anchoring, samme protokoll som G5).
+  - **Utfall — ALLE 4 var stale gull; v3 flagget hver korrekt (0 ekte FP):**
+    1. `adr-template#1` (status) «zero permission management, permissions respekteres automatisk» — live (`data-privacy-security` + `connecting-external-content-manage-items`): del B (auto-respektert ved grounding) stemmer, men del A motsies — Graph connectors krever ACL per `externalItem` + identitets-mapping. **Gull-feil** `correct→wrong`. v3 `not_grounded` (R6) korrekt.
+    2. `multi-region-azure-openai-deployment#2` (region) «Sweden Central … gpt-4o, o1, gpt-35-turbo» — live: gpt-4o + o1 tilgjengelig, men **gpt-35-turbo er retired** (0301/0613 feb 2025; 0125/1106 fra sep 2025), borte fra katalogen. **Gull-feil** `correct→outdated`. v3 `not_grounded` (R2 entitet-fravær) korrekt.
+    3. `network-resilience-patterns-ai#4` (status) «Circuit Breaker + Retry … obligatorisk for alle Azure AI API-kall» — live (`how-to/quota`): MS rammer dette som «Rate limit best practices / recommended», circuit breaker kun valgfri Polly-utvidelse. «Obligatorisk for alle» overdriver modalitet + omfang. **Gull-feil** `correct→wrong`. v3 `not_grounded` (R6) korrekt.
+    4. `vector-storage-cost-optimization#7` (status) «Vector quantization GA siden 2024-11-01» — live (`search-api-migration`): quantization ER GA, men GA-dato var **2024-07-01** (stable release); «2024-11-01» finnes kun som *preview*-API-versjon (`2024-11-01-preview`). Last-bærende dato feil. **Gull-feil** `correct→wrong`. v3 `not_grounded` korrekt.
+  - **Baseline-revurdering (re-score, G5b-korrigert gull, samme gull begge):** de 4 flyttet FP→TP for v3. **v3: P 89,7/92,1 → 100,0 / 92,9 (TP 39, FP 0, FN 3, TN 198).** v2: 86,8/86,8 → **86,8 / 78,6** (de 4 ble FN for v2 — v2 flagget ingen). v3 dominerer nå v2 på begge akser med større margin; gull var fortsatt kontaminert. Artefakter: `judge-bakeoff-report-v3-g5bgold.{json,md}`, `judge-bakeoff-report-v2-g5bgold.{json,md}`. Gull `_meta.reconciliation_log` + lint (373 claims, 0 flagget) + suite 641/641 grønt.
+  - **Konsekvens for v3.1-design (PLAN-INVERSJON):** STATEs planlagte v3.1-endring #4 (R2/R6 «FP-vakt» for de 4) er **droppet** — R2/R6 fanget disse korrekt; en vakt ville re-knekt 3 reelle treff. v3.1 er nå **ren recall-hardning** av de 3 gjenstående FN (R1 øvre-grense-skille, R7 last-bærende-streng-carve-out, ny R8 fler-delt-fullstendighet) — `judge-claim-prompt-v3.1.md` forfattet. **Adopsjonsgate strammet:** v3 sitter på presisjonstaket (P=100), så v3.1 må **holde P=100 OG løfte R over 92,9** — enhver ny FP feller den. 45-veis fan-out gjenstår (operatør-gate, stor spend).
+  - **Mønster bekreftet:** G5b er andre gang gull-friskhet inverterte en adopsjonskonklusjon ([[gold-freshness-can-invert-adoption]]). Gull-re-adjudering FØR baseline stoles på er nå fast disiplin, ikke engangs — knyttes til §7 friskt utvalg.
+- **G1 (Spor 2a) 🟢 LUKKET (2026-06-30) — v3.1 MÅLT + ADOPTERT (max-utfall).** 45-veis v3.1-fan-out kjørt per `docs/v3.1-fanout-runbook.md`: 255 claims / 45 filer, 45 Opus-4.8-xhigh-subagenter (live MS Learn, én per fil, blinde for gull), aggregert 255/255 rent → `judge-bakeoff-results-v3.1.json`, deterministisk re-score mot G5b-korrigert gull → `judge-bakeoff-report-v3.1.{json,md}`.
+  - **Resultat: v3.1 = P 100,0 % / R 100,0 % / 0 FP / 0 FN / F1 1,000** (TP 42, TN 198, Wilson 95 % [91,6 %, 100 %]) mot v3-baren P 100,0 / R 92,9 / 0 FP / 3 FN (TP 39). v3.1 dominerer: **alle 3 gjenstående FN fanget** (R 92,9 → 100, TP 39→42) **uten én ny FP** (FP 0, P 100, TN 198 uendret). Begge scoret over identisk 240-claims-konfusjonsmatrise (samme G5b-gull).
+  - **De 3 FN fanget som designet:** `multi-model-strategy-costs#2` (R1 øvre-grense — «opptil 18» slått av live 28), `token-usage-tracking-attribution#3` (R7 last-bærende-streng — `PromptTokens`/`CompletionTokens` finnes ikke live), `ai-foundry-disaster-recovery-planning#9` (R8 fler-delt — Norway East er Global-trening, ikke regional). Alle tre flippet `grounded→not_grounded`, matchet gull `outdated`.
+  - **FP-risiko avkreftet (R1s dobbeltegg holdt):** R1-«+»-floor-flaggene over full populasjon (`rag-context-windows#2` «200k+»→1M, `ai-services-vs-foundry#5` «100+»→1900) er begge gull=`outdated` → **TP, ikke FP**; tette floors (`genaiops#2` «1600+»→1900, `reserved-capacity#3` «enkelte 100+») holdt `grounded`, gull=`correct` → TN. R1s magnitude-skille (>~2× decision-changing vs tett) sporet fasiten i begge retninger over de 255 — ingen ny FP innført.
+  - **Forhåndsregistrert gate klarert:** «adopter v3.1 KUN hvis P=100 OG R>92,9» → P=100 ✓ ∧ R=100>92,9 ✓ → **v3.1 ADOPTERT**. v3.1 (`judge-claim-prompt-v3.1.md`, R1–R8) er nå inngangen til G2.
+  - **Metode-note (portabelt mønster, [[showcase-reusable-patterns]]):** `build-judge-payloads.mjs` (deterministisk payload-generator) + per-payload-splitt + inkrementell per-fil-persistering (resume-trygg mot kvote-stopp) gjorde fan-outen reproduserbar og avbruddssikker. Artefakter: `judge-bakeoff-results-v3.1.json`, `judge-bakeoff-report-v3.1.{json,md}` (committet); payloads gitignored.
+- **G2 🟢 LUKKET (2026-06-30) — adoptert v3.1-judge wired inn i pipelinen (TDD).** RED→GREEN: testene `test-transform.test.mjs:200` (default-stempel) + `:235` (ende-til-ende) flippet `judge-v2 → judge-v3.1`, så feile, så `scripts/kb-update/lib/transform.mjs:44` `JUDGE_VERSION = 2 → '3.1'`.
+  - **Designvalg — version-label-streng, ikke integer (`judge-v3` forkastet):** v3 er en distinkt, målt, *forkastet* versjon (R 92,9 / 3 FN) med eget navn i programmets artefakter; et `judge-v3`-stempel ville navne feil judge og kollidere. Streng `'3.1'` lar provenance navne adoptert judge eksakt. Blast-radius null: `verified_by` lagres/parses kun som `\S+`-token + presence-sjekk (`parseVerifiedByHeader`), ingen kode trekker ut integeren; parseren tar `judge-v3.1` uendret (ende-til-ende-testen bekrefter det gjennom `composeKbFile`). Default-stien interpolerer strengen direkte (utenom `Number.isInteger`-guarden), så integer-override-stien (`judgeVersion:3 → judge-v3`) består.
+  - **Prompt-/command-wiring:** `transform-prompt.md` (46/101/105), `commands/kb-update.md` (130 — BÅDE Port 2 born-verified OG Port 3-kadens-inngang), `commands/generate-skills.md` (139/143/305/307) byttet `judge-claim-prompt-v2.md → -v3.1.md` + `judge-v2 → judge-v3.1`. `generate-skills.md`: kun kirurgisk judge-ref (Cosmo-heading urørt — «gjøres sist» per [[cosmo-persona-deprecated]]). Suite **641/641** (kun 2 eksisterende tester flippet, ingen lagt til).
+  - **Restgap (guard-minor-nit, §8-oppfølging):** stempel-guarden (`transform.mjs:165`) honorerer *integer*-override men ikke en minor-bærende streng-override (`judgeVersion:'3.2'` faller tilbake til default pga `Number.isInteger`). Harmløst — pipelinen bruker alltid default ('3.1'); en fremtidig judge-revisjon som vil *overstyre* til en minor må generalisere guarden til en version-label-regex. Logget her, ikke lukket (utenfor G2-scope; ingen failing behov i dag).

docs/ref-kb-direction-note-2026-06.md

@@ -0,0 +1,125 @@
+---
+Provenans: Generert av dynamic workflow `ref-kb-analysis` (2026-06-26) — 5 parallelle akse-analyser (Opus 4.8 xhigh) → adversariell kritiker → syntese. Gjennomgått av hovedkontekst. Bygger på `docs/ref-kb-audit-2026-06.md` (verifisert ground truth). Beslutning IKKE tatt — dette er input til operatør.
+Gjelder: skill-reference-filene (de 389). IKKE Google OKF — OKF er reservert for brukerens egen kontekst/«second brain» (se `docs/okf-second-brain-brief-2026-06.md`).
+---
+
+# Beslutningsnotat — Hvordan ms-ai-architect bør lage og oppdatere sine 389 reference-filer
+
+## Bunnlinje
+
+Diagnosen er korrekt og delt av alle fem aksene: ingen mekanisme måler i dag om en ref-fils *påstander* stemmer mot MS Learn — Spor D måler struktur per skill, KB-refresh måler alder per fil. Men «vi måler ikke korrekthet» er ikke det samme som «korrektheten er dårlig»: KB-en scorer 91–96 med 0 stale filer, og base-raten av faktiske feil er aldri målt. Anbefalt førstesteg er derfor **ikke å bygge**, men å **måle**: én sesjons stratifisert manuell stikkprøve (~30–40 filer vektet mot volatile påstander) mot live MS Learn fastslår feilraten — og den raten, ikke en antakelse, avgjør om noen av de dyre retningene (LLM-groundedness-judge, frontmatter-migrasjon, registry-herding) er berettiget. Den eneste rene struktur-fiksen som er verdt å gjøre uavhengig av målingen er TOC på de ~20–29 største filene (>800 linjer). Hvis judgen senere bygges, er retningen **#2 (eget ref-eval-spor) bygget på #3s substrat (KB-refresh-pipelinen)** — aldri #1.
+
+---
+
+## Akse 1 — Struktur og størrelse
+
+**Verifisert fakta.** Median 481 linjer, snitt 507, 183/389 filer >500 linjer, største 1265 (`architecture/adr-template.md`). Alle 5 SKILL.md er 169–294 linjer. 384 av 387 filer >100 linjer mangler innholdsfortegnelse (TOC). Eval N4 måler TOC, men med vekt 1 av 23 og uten gulv — nær-total svikt koster ~4 poeng og bryter aldri 90-målet.
+
+**Best practice.** 500-linjers-regelen gjelder SKILL.md-body, ikke ref-filer; ref-filer har «no context penalty until accessed» og kan bunte omfattende innhold. Men: filer >100 linjer skal ha TOC øverst slik at Claude ser hele omfanget selv ved delvis lesing. Kilde: Anthropic «Skill authoring best practices» (platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices), §Token budgets, §Runtime environment, §Structure longer reference files.
+
+**Anbefaling (vurdering).** Ikke masseoppdel for størrelsens skyld — store ref-filer er eksplisitt sanksjonert. TOC-løftet er reelt kun for de største filene: under whole-file named-core-routing (agenter leser ~3 hele kjernefiler) er partial-read en *uobservert* feilmodus, og de ~350 filene på 100–500 linjer leses helt og vinner ingenting. Legg derfor TOC kun på de ~20–29 filene >800 linjer der partial-read faktisk er plausibelt. Kirurgisk splitt av `adr-template` (flytte 2 av 3 ADR-eksempler ut) gir kun gevinst hvis adr-writer-agent laster malen men *ikke* trenger eksemplene — et **umålt** lastemønster; trenger den et eksempel laster den søsterfila, og nettogevinsten er null pluss migrasjonschurn. Utsett. (Merk: `adr-template` bor i `ms-ai-advisor`, som er gjenstand for forestående Cosmo-utfasing — se sekvenserings-risiko under.)
+
+---
+
+## Akse 2 — Innhold og korrekthet
+
+**Verifisert fakta.** Ingen mekanisme leser ref-body semantisk. KB-refresh har per-fil URL-mapping (306/389), per-fil staleness-post og adversariell klassifisering (verify-out: status-gate + refutation + authority-mismatch). Men kun **7/389 filer** har streng `**Source:**`-header, og kun **3 URL-er** i registryet har `authority_source` satt — det utpekte autoritets-ankeret en rigorøs grounding krever eksisterer praktisk talt ikke ennå.
+
+**Best practice.** Faithfulness/groundedness måles ved å dekomponere output i diskrete påstander og NLI-/entailment-sjekke hver mot kilden (RAGAS Faithfulness — docs.ragas.io). Microsofts egen analog: Azure AI Content Safety Groundedness detection (learn.microsoft.com/azure/ai-services/content-safety/concepts/groundedness). LLM-judge bør ikke skåre hver request med dyr frontier-judge — kombiner billige heuristikker + selektiv sampling + policy-trigget audit, og kalibrer mot et menneske-merket subset først (Langfuse/Confident AI-praksis). Anthropic: «Avoid time-sensitive information» — volatile fakta (GA/preview/versjon/pris) er høyest risiko.
+
+**Anbefaling (vurdering).** En per-fil groundedness-judge er teknisk riktig formet (per-fil enhet, claim-dekomponering, entailment mot utpekt kilde), MEN tre kritikk-punkter endrer kalkylen vesentlig:
+- **Invertert leverage.** Alle akser er enige om at de volatile påstandene — nøyaktig de som faktisk råtner — *må forbli operatør-gated og aldri auto-scores*. Judgen auto-scorer da de stabile, lav-risiko-påstandene og punter de høy-risiko-volatile til mennesket. Frontier-dollar brukes der feil er minst sannsynlig.
+- **Kostnaden er feilestimert.** «$20–40 via Batch API» er feil: `microsoft_docs_fetch` er et Claude-i-loop MCP-kall, ikke en Batch-workload. Ærlig kostnad er Akse 4s: per-fil × per-kilde (median 7 kilder/fil) ≈ ~2700 ikke-batchbare, rate-begrensede fetch-kall per full-pass.
+- **Den fjerner ikke verifiseringsplikten.** Judgen er ikke-deterministisk og claim-dekomponering er erkjent brittle; dens egen output må operatør-kalibreres og revideres. Netto menneske-innsats flyttes fra «stikkprøv KB-en» til «kalibrer + revider judgen» — ROI-premisset er udokumentert.
+
+Konklusjon: judgen bygges **kun hvis** den målte feilraten (se Bunnlinje) viser en restklasse av reelle feil *uten* lastmod-endring (feillesning/feildestillasjon) — det er den eneste verdien judgen tilfører over den eksisterende staleness-loopen, og den er aldri tallfestet.
+
+---
+
+## Akse 3 — Hvordan vi måler kvalitet
+
+**Verifisert fakta.** Spor D (skill-score.mjs) aggregerer per SKILL (5 enheter); K8 sjekker kun at en kilde-/Verified-header *finnes* (sample-ratio over 5 filer, vekt 1), aldri at innhold stemmer. Begge dashbord er grønne (alle skills ≥90, 0 stale). Scoringsmotoren har allerede gulv-mekanikk (K1/K10 `floor:true` ⇒ `min(rawScore, 89)`).
+
+**Best practice.** Groundedness-evaluator behandler «response» mot «context» med 1–5-skala + terskel→Pass/Fail (Azure RAG-evaluators — learn.microsoft.com/azure/foundry/concepts/evaluation-evaluators/rag-evaluators). Analytisk per-kriterium-scoring avslører *hvorfor* noe feiler; 3–5 kriterier er sweet spot; krev konkret bevis, ikke vage gradord (G-Eval, Liu et al., EMNLP 2023). Mål konsistens med repetisjoner for ikke-deterministisk judge (learn.microsoft.com/agent-framework/agents/evaluation).
+
+**Anbefaling (vurdering).** *Hvis* en innholds-akse bygges: opprett en EGEN, ortogonal akse (Spor E / innholds-troverdighet) per fil, ikke utvid Spor D — #1 er en granularitets-kategorifeil (én råtten fil fortynnes til 96/100 i et skill-snitt over 153 filer). Men kritikken avdekker en reell fare i Akse 3s forslag: et **hardt worst-file-gulv på et brittle judge-signal** gir alarm-tretthet og waiver-spam — én falsk-positiv gulver hele skillen under 90 og fyrer Spor D-alarmen i SessionStart. Gulv-grammatikk passer deterministiske kriterier (K1/K10), ikke et ikke-deterministisk judge-signal. Hvis aksen bygges, bør judge-gulv være *rapporterende* (worstFile + countBelow), ikke en hard SessionStart-gate, før judgen er kalibrert. Merk også overlapp: foreslått CT5 (sourcedness) er samme signal som dagens K8 — CT5 bør **erstatte** K8s rolle, ikke leve parallelt, ellers dobbelttelles og to dashbord kan divergere.
+
+---
+
+## Akse 4 — MS Learn fetch-dekning
+
+**Verifisert fakta.** Registryet dekker 306/389 filer (78,7 %) med ≥1 pollet kilde-URL; 83 (21,3 %) er helt utenfor (= audit-ens URL-løse filer). 309 siterte URL-er er `not_in_sitemap` (usynlige for ferskhets-flagget), inkl. hele M365-Copilot-kategorien og 12/17 Agent Framework-lenker. Kobling fil↔kilde er mange:mange (median 7 kilder/fil, maks 21). Pipelinen henter aldri innhold selv — `report-changes` er ren dato-aritmetikk; fetch + re-verifisering er et separat Claude-i-loop apply-steg på kun flaggede filer, mot ÉN utpekt kilde.
+
+**Best practice.** sitemap `<lastmod>` er publisher-kontrollert og ofte upålitelig — en side kan endre innhold uten lastmod-bump (Yoast, yoast.com/lastmod-xml-sitemaps-google-bing). MS Learn eksponerer `canonicalUrl` + `ms.date` + `updated_at`; siteringer bør peke kanonisk og verktøy bør følge redirect. `microsoft_docs_fetch` gir full sidetekst til grunning (microsoft-learn MCP tool-instruksjoner).
+
+**Anbefaling (vurdering).** Registry-herding er et reelt, billig og retnings-uavhengig forbedringspunkt: legg `graph`/`ai-builder`/`power-apps`/`power-automate`/`microsoftsearch` i sitemap-prefiksene (~25 stack-relevante URL-er reddes), fang skjemaløse siteringer (2 filer der `learn.microsoft.com` mangler `https://`), og følg redirect så legacy-stier (44 M365-Copilot-URL-er) re-kanonikaliseres. Dette er en konfig-justering, ikke et program — men det er ikke haster-kritisk så lenge feilraten er umålt. Viktigste innsikt herfra: «fersk» ≠ «korrekt» selv for de 306 dekkede filene (lastmod-only fanger ikke innholdsdrift uten bump) — dette er det reelle argumentet for en korrekthets-sjekk, men det tallfester ikke hvor stor restklassen er.
+
+---
+
+## Akse 5 — Metadata-substrat
+
+**Verifisert fakta.** 0/389 bruker YAML-frontmatter; alle bruker prosa-header med 34 distinkte nøkler på tre språk (Status ×344, Last updated ×337, Category ×322 + norske varianter). `report-changes` tolererer allerede 3 dato-mønstre og kjører grønt. Write-pathen er sentralisert i ÉN funksjon (`transform.mjs buildKbHeader`), og YAML-parser (`splitFrontmatter`) finnes og er battle-tested for SKILL.md.
+
+**Best practice.** Anthropic foreskriver *ingen* metadata for ref-filer (kun SKILL.md krever name+description) — minimalisme er legitimt. Maskinlesbar, konsistent frontmatter er en docs-as-code-standard (Diátaxis; docsio.co). Eksplisitt freshness-dato som maskinlesbart felt (MS Learn `ms.date` — learn.microsoft.com/contribute/content/metadata). Type-tagging slik at hver fil behandles etter sin art (Diátaxis). Ikke bak inn volatil status i det stabile substratet (Anthropic, §Avoid time-sensitive).
+
+**Anbefaling (vurdering).** Full YAML-frontmatter på 389 filer (6–8 script + write-path-regresjonsrisiko + dømmekrafts-pass på 81 filer) er over-engineering forbi det ene genuint nyttige feltet. Parsingen er *ikke ødelagt* — den løser et problem som ikke har feilet. Det verdifulle skillet er **`type: reference` vs `template`/`methodology`** (redder de 83 kildeløse fra urettferdig korrekthets-straff og gjør manglende kilde på en faktafil maskin-detekterbar). Det skillet trenger ikke YAML — en enkelt tag, mappekonvensjon eller sidecar-manifest gir samme nytte til en brøkdel av kostnaden. Full frontmatter blir først berettiget *hvis* #2/#3-judgen faktisk skal bygges (da trenger den per-fil `source`+`verified` deterministisk) — altså nedstrøms av målingen, ikke før.
+
+---
+
+## Anbefalt retning (#1 / #2 / #3)
+
+**Førstevalg: ingen av dem ennå — MÅL feilraten først.** Alle fem akser hopper fra «vi måler ikke korrekthet» til «bygg et stående system» uten å fastslå om korrektheten faktisk er ødelagt. Det bryter operatørens egne anti-patterns («starte ambisiøse tiltak når en konfig-justering holder»; «endre X filer når én holder») og er klassisk feilallokering: å bygge en $-per-kjøring-detektor før base-raten av det som skal detekteres er kjent.
+
+**Betinget valg, hvis målingen rettferdiggjør bygging: #2 bygget på #3s substrat — aldri #1.**
+- **#1 forkastes** (delt konklusjon, høy konfidens): Spor D scorer per SKILL (5 enheter); korrekthet er per-fil/per-påstand og aggregerer til usynlighet der.
+- **#2 som enhet** (per-fil korrekthetsdom) **på #3s substrat** (KB-refresh-pipelinen: `microsoft_docs_fetch` + url-registry + judge-gating, refresh-kadens — ikke SessionStart). Ren #3 (score på staleness-flagget) bommer på korrekthet-uten-staleness; ren parallell pipeline dupliserer infrastruktur som allerede finnes.
+
+**Hva kritikken endret** (mot de fem aksenes opprinnelige «bygg nå»):
+- Degraderte hele judge-programmet fra «bygg nå» til «bygg kun hvis målt rate krever det».
+- Avdekket invertert leverage: judgen auto-scorer lav-risiko stabile påstander; de volatile (som faktisk råtner) forblir operatør-gated uansett.
+- Korrigerte kostnaden: ikke batchbar, ~2700 MCP-fetch per full-pass (ikke «$20–40 Batch»).
+- Avslørte at grunnings-ankeret nesten ikke finnes (3 URL-er med `authority_source`, 7 filer med Source-header) — gjør judgen bak-tung.
+- Reduserte frontmatter til én type-tag (sidecar/konvensjon), ikke full YAML-migrasjon.
+- Reduserte TOC til de ~20–29 største filene, ikke alle 384.
+- Satte adr-template-splitt på vent (betinget av umålt lastemønster + Cosmo-kollisjon).
+
+---
+
+## Billigste høyverdi-grep først (rangert)
+
+1. **Stratifisert manuell stikkprøve mot live MS Learn (~30–40 filer, 1 sesjon, null ny infrastruktur).** Vekt mot volatile påstander (Status=Preview, pris/SKU, versjon, GA-datoer) på tvers av alle 5 skills. Noter feilraten. Dette er det manglende inputet som avgjør hele programmet — lav rate (~few %) ⇒ judge ikke berettiget, staleness+stikkprøver holder; høy rate ⇒ evidens-basert begrunnelse *og* settet dobler som judge-kalibreringssett. Som sidegevinst retter samme pass de få volatile feilene som faktisk finnes — nettopp flaten judgen per design aldri ville auto-scoret.
+2. **TOC på de ~20–29 filene >800 linjer.** Eneste rene struktur-fiks verdt å gjøre uavhengig av målingen; billig forsikring mot partial-read der den faktisk er plausibel. Skript det for konsistent format.
+3. **Registry-herding (konfig-justering).** Legg de ~5 manglende sitemap-prefiksene, fang de 2 skjemaløse siteringene, følg redirect for legacy-stier. Retnings-uavhengig; forbedrer ferskhets-dekningen uansett senere valg. Ikke haster-kritisk.
+4. **Type-tag for `reference` vs `template`/`methodology`/`regulatory`** (sidecar/konvensjon, ikke full frontmatter). Lavt-kost skille som hindrer at de 83 kildeløse filene straffes urettferdig av en evt. korrekthets-sjekk. Gjør først når #2/#3 er besluttet.
+5. **(Betinget på måling) Bygg #2-på-#3-judgen** — kun hvis stikkprøven viser en reell feil-restklasse uten lastmod-endring. Forutsetter da: backfill av per-fil autoritets-binding (lag 3), full frontmatter med `source`+`verified`, kalibrering mot operatør-merket subset, og *rapporterende* (ikke hard SessionStart-gate) gulv inntil judgen er kalibrert.
+
+---
+
+## Åpne valg for operatør
+
+- **Bygge judge eller ikke?** Avgjøres av stikkprøvens feilrate. Operatøren markerte korrekthets-sporet som viktigst å gjøre skikkelig — form (enhet, substrat, autoritets-backfill-rekkefølge) skal godkjennes FØR bygging, ikke utledes underveis.
+- **Sekvenserings-risiko mot Cosmo-utfasing.** Cosmo-fjerning er godkjent og «gjøres sist», og treffer `ms-ai-advisor` — den lavest-scorende skillen (91) og hjemmet til `adr-template`. Enhver frontmatter-/split-/TOC-jobb på advisor-filer kolliderer med imminent Cosmo-fjerning. Operatør må bestemme: vent med advisor-arbeid til Cosmo er ute, eller koordiner.
+- **De 83 kildeløse filene.** Hvilke er legitimt kildeløse (maler/metodikk: `decision-trees`, `cost-models`) vs. MS-faktapåstander uten sporbar kilde? Krever dømmekraft (Opus-batch), ikke blind skripting. Dette er uansett første steg i en korrekthets-audit.
+- **N4-re-vekting.** Skal TOC-regelen håndheves reelt (re-vekt N4 eller skaler sub-score med filstørrelse)? Det vil midlertidig dra dagens 91–96 under 90-gulvet og utløse Spor D-alarmer — en policy-beslutning, ikke en defekt, som må kommuniseres som sådan.
+- **Frontmatter-omfang.** Full YAML-migrasjon (kun berettiget hvis judge bygges) vs. minimal type-tag. `category`-feltet: fjern (krever refaktor av `taxonomy.getCategorySkill` til mappesti-utledning) eller behold (redundant mot mappestruktur)?
+
+---
+
+## Verifiseringslogg
+
+| Påstand | Kilde / ground truth | Status |
+|---|---|---|
+| 389 ref-filer (advisor 62, engineering 153, governance 78, infra 34, security 62); median 481 / snitt 507 linjer; 183 >500; største 1265 | Audit-fakta (filsystem-skann) | Verifisert |
+| 384/387 filer >100 linjer mangler TOC; N4 vekt 1/23, ikke gulv | Audit + `skill-score.mjs` | Verifisert |
+| 500-linjers-regel gjelder SKILL.md-body; ref-filer har «no context penalty until accessed»; TOC anbefalt >100 linjer | platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices | Verifisert (Anthropic) |
+| Spor D scorer per SKILL strukturelt; K8 sjekker header-*tilstedeværelse*, ikke sannhet; scorer 91–96, 0 stale | `skill-score.mjs`, `change-report.json` | Verifisert |
+| Kun 7/389 filer har `**Source:**`-header; kun 3 URL-er har `authority_source` | `authority.mjs` / registry (adversariell kritikk) | Verifisert |
+| 306/389 filer dekket av ≥1 pollet URL; 83 uten kilde; 309 URL-er `not_in_sitemap`; median 7 kilder/fil | `url-registry.json`, Akse 4 | Verifisert |
+| `report-changes` er ren lastmod-aritmetikk; fetch er separat Claude-i-loop apply-steg mot ÉN kilde | `run-weekly-update.mjs`, `report-changes.mjs`, `transform-prompt.md` | Verifisert |
+| Groundedness/faithfulness = dekomponer i påstander + entailment mot kilde | RAGAS (docs.ragas.io), Azure Content Safety Groundedness (learn.microsoft.com) | Verifisert (WebSearch) |
+| sitemap `<lastmod>` er upålitelig; innhold kan endres uten bump | yoast.com/lastmod-xml-sitemaps-google-bing | Verifisert |
+| `microsoft_docs_fetch` er Claude-i-loop MCP, ikke Batch-API ⇒ ikke −50 %-batchbar | microsoft-learn MCP tool-instruksjoner; Akse 4 ~2700 fetch-estimat | Verifisert — korrigerer Akse 2s «$20–40 Batch» |
+| Anthropic foreskriver ingen ref-fil-metadata; «avoid time-sensitive information» | Anthropic best-practices | Verifisert |
+| **Base-raten av faktiske korrekthets-feil** | Ingen — aldri målt | **IKKE VERIFISERT** — dette er det avgjørende manglende inputet |
+| ROI av judge *over* eksisterende staleness-loop (feil uten lastmod-endring) | Ingen tallfesting i noen akse | **IKKE VERIFISERT** |
+| Premiss-avvik: «navngitt 169 / mappe 220» (audit) vs «151 navngitt / 238 mappe-only» (Akse 1) | `ref-file-audit.py` re-kjørt 2026-06-26 → reproduserbart 169/220/0 | RECONCILED — 169/220/0 autoritativt; 151/238 (ikke-reproduserbart engangsanslag) forkastet. Immaterielt: intet tiltak kjører på named/folder-grensen, kun «0 orphans» (begge enige) |

docs/ref-kb-gold-reconciliation-2026-06.md

@@ -0,0 +1,123 @@
+# Gull-rekonsiliering (Spor 2b) — herding av fasiten før korpus-skala
+
+_Opprettet 2026-06-30. Utfører Spor 2(b) i `ref-kb-correctness-program-2026-06.md` §3: «løs hver judge-vs-gull-uenighet (v2: 6 FP + 6 FN) mot live kilde. Hver er enten judge-feil ELLER gull-feil; å løse dem kalibrerer judgen OG retter fasiten. Mål: 0 uløste uenigheter.» Gjøres FØR Spor 1 (korpus-pass) — bunnsolid fasit før vi skalerer målingen (§6 avhengighet)._
+
+## Sammendrag
+
+12 uenigheter mellom v2-judgen og gull-settet (`gold-correctness-set.json`) ble løst ved fersk re-henting av hver siterte kilde (Opus 4.8-subagenter, `microsoft_docs_fetch`, read-only). Resultat:
+
+- **4 gull-feil** (gull-verdikt rettet) + **1 note-fiks** (verdikt beholdt).
+- **8 judge-feil** (gull sto; dokumentert som kalibreringsmål for Spor 2a / judge-prompt-v3).
+- **0 uløste uenigheter** — hver av de 12 er adjudisert til en definitiv side med verbatim live-belegg.
+
+Effekt på målingen (judgen var **bedre** enn rå-bakeoffen viste — fasiten var kontaminert):
+
+| | TP | FP | FN | TN | presisjon | recall | F1 |
+|---|---|---|---|---|---|---|---|
+| v2 rå fasit (`judge-bakeoff-report-v2`) | 32 | 6 | 6 | 196 | 84,2 % | 84,2 % | 0,842 |
+| **v2 herdet fasit (`-v2-reconciled`)** | **35** | **3** | **5** | **197** | **92,1 %** | **87,5 %** | **0,897** |
+
+Den frosne `judge-bakeoff-report-v2` beholdes urørt som gate-beslutnings-artefakt (pre-registrert gate ble vurdert på den fasiten). `judge-bakeoff-report-v2-reconciled` viser herdet fasit.
+
+## Resolusjonsprinsipp (konservativt — tillit-bærende fasit)
+
+For hver uenighet: finn den **sanne** verdikten mot live kilde.
+- Sann ≠ gull → **gull-feil**: rett gull-verdikt.
+- Sann = gull → **judge-feil**: gull står, judge føres som kalibreringsmål.
+- Flytt gull **kun** der den sanne verdikten genuint avviker. En påstand som er *substansielt korrekt men upresis* (rett størrelsesorden / rett kjerneatferd) blir stående `correct`, og judge-flagget føres som over-streng.
+
+Verdikt-vokabular: `correct` (matcher dagens kilde) · `outdated` (var sant, kilden viser nå annet) · `wrong` (aldri sant / motsier kilden uten historisk grunnlag) · `unsourced` (kilden oppgir ikke verdien).
+
+## Nedre-grense-policy (§3-kjennelse, godkjent av operatør 2026-06-30)
+
+§3 ber gull avgjøre om nedre-grense-påstander («100+», «200k+») teller som feil. **Vedtatt policy:** grov understatement (>~2×, beslutnings-endrende) teller som feil; en *stram* nedre grense (sann verdi i samme størrelsesorden) blir stående `correct`. Anvendt på FN2 (200k+ vs ~1M ⇒ `outdated`).
+
+## De 12 adjudiseringene
+
+### FP-er (judge flagget `not_grounded`, gull var `correct`)
+
+| ID | Live ground truth (verbatim-belagt) | Sann | Resolusjon |
+|---|---|---|---|
+| **FP1** `azure-ai-foundry.md#2` (taxonomy) | `what-is-foundry`: «over 1,900 models from Microsoft, OpenAI, Anthropic…» = HELE katalogen; «sold by Azure» er en delmengde. «11000+» og «40+ regioner» finnes ikke (kun «most regions where Foundry Tools are available») | **wrong** | 🔴 GULL-FEIL `correct→wrong` |
+| **FP2** `multimodal-prompt-design.md#7` (taxonomy) | `multimodal-search-overview`: image-to-vector ved query krever multimodal-embedding-vectorizer, men TO veier — AML-skill ELLER Azure Vision. «kun» utelukker AML-veien | **wrong** | 🔴 GULL-FEIL `correct→wrong` |
+| **FP3** `rag-cost-optimization.md#8` (taxonomy) | `vector-search-how-to-quantization`: «up to 96% reduction» / «up to 28 times» (claim 96,875% = teoretisk 32x ≈). «92,5%» = MS blogg-tittel (reell MS-figur, kombinerte teknikker) | **correct** (substansielt; begge tall sporer til MS) | 🟡 JUDGE-FEIL (eksakt-streng-pedanteri) |
+| **FP4** `multi-region-ai-gateway-design.md#2` (taxonomy) | `deployment-types`: 3 kjerne-residency-atferder bekreftet (Standard=deployment-region, DataZone=US/EU-sone, Global Standard=any region). Global Provisioned=any region (ikke single-region) | **correct** (men note «alle fire ordrett» overdrev) | 🟡 JUDGE-FEIL + note-fiks |
+| **FP5** `service-level-documentation-dr.md#6` (taxonomy) | `distribute-data-globally`: «Build global active-active apps… every region supports both writes and reads» — multi-region-write reell | **correct** | 🟡 JUDGE-FEIL (ekte FP — kapabilitet-bom) |
+| **FP6** `ai-foundry-disaster-recovery-planning.md#9` (status) | `openai/concepts/models`: Global training = GA (per-modell), ikke Public Preview; «billigere» + «ingen residency» stemmer; men Norway East er en GLOBAL trenings-region, ikke residency-regional | **outdated** | 🔴 GULL-FEIL `correct→outdated` |
+
+### FN-er (judge `grounded`/`source_silent`, gull var feil)
+
+| ID | Live ground truth | Sann | Resolusjon |
+|---|---|---|---|
+| **FN1** `real-time-reasoning-performance.md#5` (region) | `realtime-audio` + WebRTC/SIP/WebSockets-søsken: Realtime = global deployment-type i NØYAKTIG East US 2 + Sweden Central. To-region-grensen IKKE avløst — gull misleste «global deployments» | **correct** | 🔴 GULL-FEIL `outdated→correct` |
+| **FN2** `rag-context-windows.md#2` (version) | `models-sold-directly-by-azure`: GPT-4.1 = **1 047 576** (~1M); praktisk 300k std. «200k+» sann nedre grense men understater ~5× | **outdated** (nedre-grense-policy) | 🟡 JUDGE-FEIL |
+| **FN3** `llm-evaluation-production.md#3` (sku) | Databricks `mlflow3/.../judges`: Completeness/Fluency/Equivalence finnes ikke i dagens built-in-liste (`ConversationCompleteness` er en distinkt multi-turn-judge) | **outdated** | 🟡 JUDGE-FEIL (`source_silent` maskerte fravær) |
+| **FN4** `endpoint-health-and-capacity-planning.md#3` (tpm) | `openai/quotas-limits`: «1 Unit Capacity»-rammen borte → Quota Tiers (Free/Tier 0–6, absolutte RPM/TPM). Ratioene overlever i tier-tabellene | **outdated** | 🟡 JUDGE-FEIL (ramme-skifte, tall overlever) |
+| **FN5** `capacity-planning-dr-configurations.md#3` (status) | `reliability-ai-search` + `cognitive-search-common-errors-warnings`: ingen 99,99%-nivå — SLA er 99,9%; 2 vs 3 replikaer = lese vs lese-skrive (begge 99,9%) | **wrong** | 🟡 JUDGE-FEIL (`source_silent` maskerte faktafeil) |
+| **FN6** `rag-query-cost-reduction.md#2` (sku) | `search-limits-quotas-capacity`: claim-tallene matcher kun «Before April 3, 2024»-raden; nå Basic 15/S1 160/S2 512/S3 1024 GB | **outdated** | 🟡 JUDGE-FEIL (matchet legacy-rad) |
+
+## Gull-endringer (anvendt 2026-06-30)
+
+| ID | Før | Etter | Begrunnelse (kort) |
+|---|---|---|---|
+| `azure-ai-foundry.md#2` | correct | **wrong** | «11000+» motsier live «1900+ totalt»; «sold by Azure» mis-tilskriver totalen |
+| `multimodal-prompt-design.md#7` | correct | **wrong** | «kun» utelukker AML-skill (dokumentert annen vectorizer) |
+| `ai-foundry-disaster-recovery-planning.md#9` | correct | **outdated** | Global training er GA, ikke Public Preview; Norway-East-framing feil |
+| `real-time-reasoning-performance.md#5` | outdated | **correct** | to-region-grensen står; gull misleste kilden |
+| `multi-region-ai-gateway-design.md#2` | correct | _correct_ (note-fiks) | fjernet «alle fire ordrett»; noterte Global-Provisioned-unntaket |
+
+Hver endret claim bærer en `RECONCILED 2026-06-30 (Spor 2b)`-tag i `notes` med live-belegg + fil-fiks-peker for Spor 0/1.
+
+## 8 judge-kalibreringsmål (mater Spor 2a / judge-prompt-v3)
+
+Disse er **ikke** gull-endringer — gull sto, judgen bommet. Grupperte feilmoduser:
+
+1. **Eksakt-streng-pedanteri (FP3):** judge flagget fordi eksakt-strengene (96,875% / 92,5%) ikke sto verbatim, selv om størrelsesorden og kilde-sporing var rett. → Judge bør tillate dokumentert teoretisk-vs-benchmark-ekvivalens.
+2. **Taksonomi-nyanse / over-streng (FP4):** kjerneatferden var grunnet; judge flagget på en utelatt under-kategori. → Judge bør skille «kjernen grunnet, detalj utelatt» fra «kjernen ugrunnet».
+3. **Kapabilitet-bom (FP5):** judge hentet evidence-URL (continuous-backup) som ikke nevner kapabiliteten prominent, og kunne ikke grunne en reell kapabilitet. → Judge bør følge kapabilitet til kanonisk side; ikke straffe illustrative tall (~0 RTO/RPO) når kapabiliteten er solid.
+4. **Nedre-grense-understatement (FN2):** judge sa `grounded` fordi 1M ≥ 200k. → Judge bør flagge nedre grenser som grovt understater (>~2×), ikke bare sjekke ≥.
+5. **`source_silent` maskerer fravær (FN3, FN5):** judge hentet siden, fant ikke de påståtte entitetene/tallene, og returnerte `source_silent` (ikke et flagg). For «X finnes i listen»-påstander er fravær på autoritativ side bevis FOR feil. → Behandle `source_silent` på eksistens-påstander som svakt not_grounded-signal.
+6. **Ramme-skifte, tall overlever (FN4):** judge pattern-matchet overlevende ratioer og overså at organiserings-rammen (1 Unit Capacity → Quota Tiers) var avløst. → Judge bør detektere når påstandens ramme/enhet er erstattet selv om avledede tall holder.
+7. **Legacy-rad-match (FN6):** judge matchet mot en tids-stemplet historisk tabellrad («Before April 3, 2024») og kalte det grunnet. → Judge må sammenligne mot GJELDENDE rad, ikke en hvilken som helst historisk rad.
+
+(FP3, FP4, FP5 = 3 FP; FN2, FN3, FN4, FN5, FN6 = 5 FN.)
+
+## Verifiseringslogg (nøkkelpåstander → kilder)
+
+| Påstand | Kilde (live, 2026-06-30) |
+|---|---|
+| 1900+ = hele katalogen, ikke «sold by Azure» | learn.microsoft.com/azure/foundry/what-is-foundry |
+| image-to-vector: AML-skill ELLER Azure Vision | learn.microsoft.com/azure/search/multimodal-search-overview |
+| binary quant «up to 96% / 28x»; 92,5% = blogg-tittel | learn.microsoft.com/azure/search/vector-search-how-to-quantization |
+| Global Provisioned = any region | learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types |
+| Cosmos multi-region writes (active-active) | learn.microsoft.com/azure/cosmos-db/distribute-data-globally |
+| Global training = GA; Norway East = global-region | learn.microsoft.com/azure/ai-foundry/openai/concepts/models |
+| Realtime = East US 2 + Sweden Central (global type) | learn.microsoft.com/azure/foundry/openai/how-to/realtime-audio (+ WebRTC/SIP/WebSockets) |
+| GPT-4.1 kontekst = 1 047 576 | learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure |
+| MLflow built-in judges (ingen Completeness/Fluency/Equivalence) | learn.microsoft.com/azure/databricks/mlflow3/genai/eval-monitor/concepts/judges/ |
+| Quota Tiers erstatter Unit Capacity | learn.microsoft.com/azure/foundry/openai/quotas-limits |
+| AI Search SLA = 99,9% (ingen 99,99%); 2 vs 3 = lese vs lese-skrive | learn.microsoft.com/azure/reliability/reliability-ai-search (+ cognitive-search-common-errors-warnings) |
+| AI Search storage nå Basic 15/S1 160/S2 512/S3 1024 | learn.microsoft.com/azure/search/search-limits-quotas-capacity |
+
+## Hva som IKKE ble gjort (scope-grense)
+
+Spor 2b retter **fasiten** (gull-settet), ikke reference-`.md`-filene. Fil-fiksene (FP1 11000+/40+, FP2 «kun», FP6 Public-Preview/Norway-East, FN2–FN6 utdaterte tall) er **Spor 0/1**-arbeid og er pekt ut i hver claims `notes`. Mange av FN-ene er reelle korpus-feil som hører til Spor 0-manifestet / Spor 1-korpus-passet.
+
+## Addendum — etterfølgende gull-friskhets-flips (G5 + G5b, kanonisk logg i programdok §8)
+
+Spor 2b var ikke siste ord: gull-fasiten eldes (G5-gapet). Senere friskhets-passes (full logg + belegg i `ref-kb-correctness-program-2026-06.md` §8 lukke-logg) flyttet ytterligere **6 gull-verdikt** mot live MS Learn. Samlet flip-ledger for komplett sporbarhet:
+
+| Pass | Claim | Før | Etter | Retning |
+|---|---|---|---|---|
+| 2b | `azure-ai-foundry.md#2` | correct | wrong | for streng gull → feil avslørt |
+| 2b | `multimodal-prompt-design.md#7` | correct | wrong | — |
+| 2b | `ai-foundry-disaster-recovery-planning.md#9` | correct | outdated | — |
+| 2b | `real-time-reasoning-performance.md#5` | outdated | correct | gull for streng → rettet |
+| **G5** | `genaiops-llm-specific-practices.md#2` | outdated | **correct** | aldrende gull (1600+ vs live 1900, tett nedre grense) |
+| **G5** | `model-selection-price-performance.md#8` | outdated | **correct** | aldrende gull (Model Router GA nov 2025) |
+| **G5b** | `adr-template.md#1` | correct | **wrong** | stale gull (Graph connectors krever ACL) |
+| **G5b** | `multi-region-azure-openai-deployment.md#2` | correct | **outdated** | stale gull (gpt-35-turbo retired) |
+| **G5b** | `network-resilience-patterns-ai.md#4` | correct | **wrong** | stale gull («obligatorisk» vs «recommended») |
+| **G5b** | `vector-storage-cost-optimization.md#7` | correct | **wrong** | stale gull (GA-dato 2024-07-01, ikke 2024-11-01-preview) |
+
+**Mønster:** gull-friskhet inverterte adopsjonskonklusjonen **to ganger** (G5 og G5b). Re-adjudering av omstridt gull mot live FØR en baseline stoles på er nå fast disiplin ([[gold-freshness-can-invert-adoption]]), knyttet til §7 friskt utvalg. Effekt på adoptert baseline: v3 målt **P 100 % / R 92,9 % / 0 FP** på G5b-korrigert gull (`judge-bakeoff-report-v3-g5bgold.{json,md}`).

docs/ref-kb-workflow-plan-2026-06.md

@@ -0,0 +1,179 @@
+# Plan — Reference-fil-kvalitet + hele workflowen rundt den (de 389 skill-refs)
+
+> **SUPERSEDED (2026-07-03):** Videreført av `docs/ref-kb-correctness-program-2026-06.md` (kanonisk program: fire spor + mekanismen + §8 gap-register) og sekvensert av `docs/plugin-roadmap-2026-07.md` (R0–R18). Dette dokumentet beholdes som historisk grunnlag (Fase 0–4-analysen + roadmap-utledningen) — ikke oppdatert etter 2026-06.
+
+_Opprettet 2026-06-26. Dette er KJERNEN i ms-ai-architect: innholdet i skills' reference-filer + maskineriet som lager og oppdaterer dem. Kvalitetsbar: svært høy. Operatør-rettesnor: «brukerverdi > teknologi; oppdateringsmekanismene må fungere veldig bra; ta god tid; faktabasert.» Grunnlag: `docs/ref-kb-audit-2026-06.md` (verifisert ground truth), `docs/ref-kb-direction-note-2026-06.md` (workflow-analyse + adversariell kritikk)._
+
+## Avgjorte premisser (ikke re-litiger — bekreftet 2026-06-26)
+1. **De 389 forblir Claude Code skill-references.** Skills-vs-OKF-bake-off for MS Learn-kunnskapen er DREPT som kaninhull — Anthropic-best-practice ER den flate skill-ref-strukturen; ingen indikasjon på at OKF slår skills. Begrunnelse: direction-note + [[okf-scope-second-brain-only]].
+2. **OKF gjelder kun brukerens «second brain»** (eget spor, senere — `docs/okf-second-brain-brief-2026-06.md`).
+3. **#1 (utvid Spor D med korrekthets-kriterium) er forkastet** — kategorifeil (Spor D scorer per skill; korrekthet er per-fil/per-påstand).
+4. **Struktur er allerede sunn** (skills 91–96, 0 stale). Det umålte er INNHOLDS-korrekthet. Derfor: ikke masseoppdel filer; store on-demand-filer er Anthropic-sanksjonert.
+
+## Mål (suksesskriterium — måles mot brukerverdi, ikke teknologi)
+Reference-innholdet er **korrekt + ferskt + godt strukturert**, og create-/update-workflowen holder det slik **pålitelig og automatisk**. Konkret: (a) en bruker som chatter får korrekte, oppdaterte MS-svar; (b) oppdateringsmekanismen fanger reell drift, ikke bare lastmod-bump; (c) nye ref-filer fødes best-practice-konforme (workflowen regresserer ikke).
+
+---
+
+## Fase 0 — Gull-testsett + base-rate-måling (FUNDAMENT — gater Fase 3)
+**Hvorfor først:** alle fem analyse-akser hoppet fra «vi måler ikke korrekthet» til «bygg system» uten å vite om korrektheten faktisk er dårlig. KB scorer 91–96 med 0 stale — null bevis for et korrekthets-problem, kun fravær av bevis. Å bygge en $-per-kjøring-detektor før base-raten er kjent er feilallokering.
+
+**Gjør:**
+- Trekk et **stort nok, stratifisert** utvalg ref-filer/påstander (start ~30–40 filer; vurder utvidelse), **vektet mot volatile påstander** (pris/SKU, GA/preview, versjoner, regioner) på tvers av alle 5 skills.
+- Verifiser hver manuelt mot **live MS Learn** (microsoft_docs_fetch/search). Merk per påstand: korrekt / utdatert / feil / ikke-kildegrunnet.
+- Persister som **gjenbrukbart gull-sett** (det dobler som evaluerings-harness for en evt. bake-off + judge-kalibreringssett).
+
+**Verifisering (testbart):**
+- ≥30 filer merket, feilrate beregnet med usikkerhetsbånd; gull-settet lagret som artefakt (f.eks. `scripts/kb-eval/data/gold-correctness-set.json`).
+- Eksplisitt funn: hvor mange feil finnes UTEN lastmod-endring (= den eneste klassen en judge fanger over eksisterende staleness-loop).
+
+**Beslutnings-gate ut av Fase 0:**
+- Lav feilrate (~few %) ⇒ judge IKKE berettiget; staleness + periodisk stikkprøve holder. Hopp over Fase 3.
+- Høy feilrate ⇒ evidensbasert grunnlag for Fase 3; gull-settet er allerede kalibreringssettet.
+
+### Utførelses-spec (LOCKED 2026-06-26 — operatør-beslutning; fersk sesjon eksekverer)
+_Fase 0-verifiseringen er bevisst utsatt til en uthvilt sesjon (retnings-avgjørende; var økt #20 da den ble planlagt). Denne spec'en er forankret så den ferske sesjonen kjører deterministisk uten å re-derivere. Sample-frame-scriptet er IKKE bygd ennå — det er steg 1 i den ferske sesjonen (TDD)._
+
+**Recon-funn (ground truth 2026-06-26 — ikke re-verifiser, men bekreft mot `git`/registry hvis tvil):**
+- **Verifiserbar populasjon = 306/389 ref-filer** (de som siterer ≥1 MS Learn-URL). De resterende **83 er kildeløse** (maler/metodikk) → utenfor korrekthets-scope.
+- **Kilde-mapping uten authority-backfill:** inverter `scripts/kb-update/data/url-registry.json` → `urls{}` (1353 entries), hver med `reference_files[]`. Invertert gir **fil → [siterte URL-er]** (median 7/fil). Verifiser en påstand mot filens egne siterte kilder; fall tilbake på `microsoft_docs_search` om ingen treffer påstanden. (Kun 3 entries har `authority_source` satt — IKKE en blokker for Fase 0.)
+- **Volatile påstander er tette i:** `cost-optimization/`, `platforms/`, og SKU/TPM/PTU/pris/region/versjon/«preview»/«GA»-tette filer. Eksempel verifisert: `ptu-vs-paygo-economics.md` (GPT-5 4750 TPM/PTU, PTU-minimums per modell, deployment-taksonomier — hver med *selv-erklært* `✅ Verified`, aldri eksternt sjekket).
+- **Gjenbruk K9-grensen** i `scripts/kb-eval/judge-prompt.md` for å klassifisere påstand som volatil vs. stabil identifikator (forordningsår, OWASP-versjonsnavn, MADR v3.0, lovsaksnr er IKKE volatile).
+
+**Locked beslutninger:**
+- **Utvalg: ~45 filer volatil-vektet + kontroll-stratum** (~8–10 stabile-påstand-filer). Rapporter BÅDE volatil feilrate (øvre grense — der feilene bor) OG stabil sanity-rate.
+- **Stratifisering:** balansert på tvers av de 5 skills, oversample de volatil-tette (security/engineering/advisor-cost+platforms), kontroll-stratum fra methodology/regulatory.
+
+**Metode (4 steg):**
+1. **Sample-frame** (`scripts/kb-eval/build-sample-frame.mjs`, NY, TDD-først): scor de 306 filene på volatilitets-signaler (sti + innholds-tetthet av SKU/pris/TPM/region/versjon/preview/GA), stratifiser → skriv `scripts/kb-eval/data/fase0-sample-frame.json` (45 volatile + kontroll, deterministisk/seedet rekkefølge — ingen `Math.random`). Verifisering: gjenkjørbar, samme input → samme utvalg.
+2. **Per-fil verifisering via subagenter** (Opus 4.8 xhigh, parallelt — agent-strategi; subagenter committer ALDRI): hver subagent får en batch (~4–5 filer). Per fil: ekstraher volatile påstander → hent siterte kilde(r) via `microsoft_docs_fetch`/`_search` → entailment-sjekk hver påstand → merk verdict + bevis. Returner strukturert JSON (schema under).
+3. **Aggreger** (`scripts/kb-eval/compute-base-rate.mjs`, NY, TDD-først): feilrate + **Wilson score-intervall** (95 %), brutt ned per skill + per volatilitets-klasse, OG **delmengden feil UTEN lastmod-endring** (= eneste klasse en judge fanger over staleness-loopen). Skriv base-rate-rapport.
+4. **Gate-beslutning** (over) → noter i STATE + plan.
+
+**Gold-set JSON-schema** (`scripts/kb-eval/data/gold-correctness-set.json`, gjenbrukbart — dobler som Fase 3-kalibreringssett):
+```
+{ "_meta": { "created": "...", "method": "...", "sample_frame": "fase0-sample-frame.json" },
+  "claims": [ {
+    "id": "<skill>/<relpath>#<n>", "file": "<relpath>", "skill": "...",
+    "claim": "<ordrett påstand>", "claim_type": "sku|price|tpm|region|version|status|taxonomy|stable",
+    "stratum": "volatile|control",
+    "verdict": "correct|outdated|wrong|unsourced",
+    "evidence_url": "<MS Learn URL brukt>", "evidence_quote": "<sitat som av-/bekrefter>",
+    "lastmod_changed": true|false,   // har filens siterte kilde endret sitemap_lastmod siden filens dato?
+    "notes": "..." } ] }
+```
+
+**Eksklusjoner (teller IKKE som feil):** påstander eksplisitt merket illustrative («forenklede tall», eksempel-NOK), og stabile identifikatorer (K9-grensen).
+
+**Verifisering (testbart, fra planen + locked):** ≥45 volatile-filer merket; Wilson-bånd beregnet; gull-sett + sample-frame lagret som artefakter; eksplisitt tall for «feil uten lastmod-endring»; begge nye scripts har failing-test-først (Iron Law).
+
+### Fase 0 → GATE (BESLUTTET 2026-06-26): **BYGG Fase 3 — scoped/hybrid**
+
+Rapport: `scripts/kb-eval/data/base-rate-report.{json,md}` (deterministisk fra `gold-correctness-set.json`, 373 påstander, via testet `lib/base-rate.mjs`). Beslutningen følger gate-kriteriet (over) + per-claim_type-konsentrasjonen:
+
+1. **Feilraten klarer baren.** Verifiserbar feilrate **13,4 % (40/299)**, Wilson 95 % **[10,0 %, 17,7 %]**. Nedre bånd 10 % ≫ «~few %» ⇒ «lav feilrate ⇒ hopp over Fase 3»-grenen er utelukket med 95 % konfidens.
+2. **Det billige alternativet fanger ingenting.** Staleness-recall = **0/40 = 0 %**. Ingen av de 40 reelle feilene har `lastmod_changed=true` (false=37, null=3) — de er bakt inn ved fil-skriving, eller MS Learn sitemap_lastmod er for grovt til å fange endringen. En korrekthets-judge er ENESTE automatiske mekanisme som fanger dem. **CAVEAT løst:** registry `last_poll=2026-06-23` er ferskere enn 32/40 fildatoer (ville fanget en post-fildato sitemap-endring om den fantes); de 8 feilene i filer dat. 2026-06-24 er ~2 dager gamle ⇒ kan ikke ha drevet ennå. `true=0` er reelt signal, ikke stale-registry-artefakt.
+3. **Feilene konsentreres der en fetch-judge virker.** Per claim_type: **sku 36,4 % (8/22), version 25,0 % (8/32), tpm 20,0 % (5/25)** — alle nær fullt hentbare (sku 0 unsourced, version 1, tpm 5). Høyt utbytte + høy rekkevidde.
+4. **Pris er ute av scope — av data, ikke antakelse.** 76 pris-påstander, **56 unsourced (74 %)**. «0/20 = 0 %» pris-feilrate er en **falsk null** (74 % kunne ikke sjekkes — ikke at de er korrekte). JS-rendrede Azure-prissider beseirer `microsoft_docs_fetch` ⇒ en fetch-basert judge når dem heller ikke. Pris er 56 av 74 unsourced (76 %); resten av korpuset er 18/297 unsourced (**6 %**) ⇒ den uverifiserbare massen er **isolert til pris**, ikke spredt.
+
+**Scope for Fase 3-judgen:** kun fetchbare claim_types — `taxonomy|status|version|tpm|sku|region` (297 påstander, 94 % hentbare, bærer 100 % av de verifiserbare feilene). `claim_type=price` flagges «ikke maskinverifiserbar» ⇒ **operatør-gated, ikke judge-gated**. Forutsetningene i Fase 3-seksjonen (autoritets-backfill, full frontmatter/Fase 2, judge-kalibrering mot dette gull-settet før tallene stoles på) gjelder uendret før judgen tas i bruk. Gull-settet (373 påstander) er kalibreringssettet.
+
+---
+
+## Fase 1 — Trygge, retnings-uavhengige grep (kan kjøres parallelt med Fase 0)
+Lav risiko, forbedrer workflowen uansett senere valg. **NB: koordiner advisor-filer mot Cosmo-utfasing** (samme skill — se gating-valg).
+
+### 1a. Update-mekanisme: registry-herding (operatørs prioritet)
+- ✅ **A — LEVERT (`e74646d`, 2026-06-26):** la `graph`/`ai-builder`/`power-apps`/`power-automate`/`microsoftsearch` i sitemap-prefiksene (taxonomy `sitemap_prefixes`, 18→23 — alle 5 docsets ett child-sitemap, verifisert live mot indeksen). **Bevist read-only: 21/24 not_in_sitemap-URL-er i disse docsetene blir tracked.**
+- ✅ **B — LEVERT (`e74646d`):** `extractUrls`/`normalizeUrl` fanger skjemaløse siteringer (krever `/path` etter domenet → avviser bare-domene-prosa + JSON-eksempler; kanonikaliserer scheme til https). **Bevist: +19 URL-er ekstraherbare.** Bonus-bugfix: backtick-lekkasje fra inline-kode-citat. TDD: ny `test-url-normalize` (14) + taxonomy-test 18→23. Suite 338/338.
+- ⏸️ **C — UTSATT → Cosmo (operatør 2026-06-26):** redirect-følging for 44 legacy `/microsoft-365-copilot/...` + 3 omdøpte microsoftsearch. 20/21 filer er advisor → foldet inn i Cosmo-utfasingen (root-cause citat-fiks, ikke ny redirect-map-mekanisme). Se `docs/cosmo-removal-brief-2026-06.md`. Slug-rename verifisert → krever ekte redirect-resolusjon, ikke streng-rewrite.
+- ⏸️ **Registry-refresh utsatt til kadens (operatør 2026-06-26):** A+Bs +21/+19 lander når neste `build-registry --merge` + poll kjører; effekten er allerede empirisk bevist read-only. Unngår 552KB re-order-churn nå.
+
+### 1b. Create/struktur: TOC på de største filene
+- Legg innholdsfortegnelse i de **~20–29 filene >800 linjer** (ikke alle 384 — partial-read er kun plausibelt på de største under whole-file-routing). Skript for konsistent TOC-format.
+- **Verifisering:** `eval.mjs checkN4 hasToc` = true for de filene; ingen diff-churn på små filer.
+
+### 1c. Create-time: hindre regresjon i generatoren
+- Oppdater `scripts/kb-update/lib/transform.mjs buildKbHeader`/`validateKbFile` (og evt. `generate-skills`) så NYE/regenererte filer fødes best-practice-konforme (TOC hvis stor; konsistent header). **MÅ gjøres før/sammen med 1b**, ellers regenererer neste KB-update prosa-headere og reverserer arbeidet (write-path-regresjon).
+- **Verifisering:** kjør generatoren på en testfil; output har TOC + kanonisk header.
+
+---
+
+## Fase 2 — Metadata-substrat (minimal; full versjon betinget av Fase 3)
+- **Minimal type-tag** for hver fil: `reference` | `template` | `methodology` | `regulatory`. Formål: skille de 83 «kildeløse» legitimt (maler/metodikk som `decision-trees`, `cost-models` skal ALDRI ha MS-kilde) fra MS-faktapåstander-uten-kilde (maskin-detekterbart defekt). Kan være sidecar-manifest eller mappekonvensjon — IKKE full YAML-frontmatter ennå.
+- **Full frontmatter** (`type`/`source`/`verified`, OKF-kompatibel form) bygges KUN hvis Fase 3-judgen skal bygges (da trenger den per-fil `source`+`verified` deterministisk). Over-engineering ellers — `report-changes` tolererer alt 3 dato-mønstre i dag.
+- **Verifisering:** hver av 389 filer klassifisert; de 83 kildeløse delt i to bøtter; judge (hvis bygd) skipper `template`/`methodology`.
+
+---
+
+## Fase 3 — Korrekthets-mekanisme (GATED av Fase 0; bygg kun hvis berettiget)
+**Retning (hvis bygd): #2 som enhet (per-fil korrekthetsdom) på #3s substrat (KB-refresh-pipelinen) — aldri #1.**
+- Per-fil groundedness-judge (Opus 4.8 xhigh): hent filens utpekte autoritet → `microsoft_docs_fetch` → dekomponer i påstander → entailment-sjekk hver mot kilden (RAGAS/Azure Groundedness-mønster) → score = supported/total + liste over ugrunnede/motstridende påstander. Persister analogt til `skill-score-report.json`, men per fil, med «sist verifisert korrekt»-stempel.
+- **Forutsetninger før bygging:** (a) autoritets-backfill — kun 3 URL-er har `authority_source`, 7 filer har `**Source:**`-header i dag; (b) full frontmatter (Fase 2); (c) kalibrer judgen mot Fase 0-gull-settet før tallene stoles på (judge claim-dekomponering er brittle — verifiseringsplikt).
+- **«Bygg begge og mål»** (operatørs metodikk) er tilgjengelig her: staleness-flagg vs judge vs hybrid, målt på gull-settet — men **kun på den volatile populasjonen** (der feilene bor; ikke kår en vinner på stabile påstander).
+- **Kjente feller (fra kritikk):** invertert leverage (judgen auto-scorer stabile lav-risiko-påstander; volatile forblir operatør-gated); kostnad er ~2700 ikke-batchbare `microsoft_docs_fetch` per full-pass (IKKE «$20–40 Batch»); judgen fjerner ikke verifiseringsplikten (flytter den fra «stikkprøv KB» til «kalibrer judge»).
+- **Verifisering:** judge presisjon/recall mot gull-settet ≥ avtalt terskel; staleness-gated inkrement + periodisk full-pass; volatile påstander forblir operatør-gated.
+
+---
+
+## Fase 4 — Integrasjon & styring
+- Fold valgt mekanisme inn i KB-refresh-kadens (ikke SessionStart — for dyrt). Spor D viser en tynn PEKER til innholds-scoren, ikke et sammenslått tall. CT5 (sourcedness) ERSTATTER K8s rolle (ikke parallelt).
+- Judge-gulv skal være **rapporterende** (worstFile + countBelow), ikke en hard SessionStart-gate, før judgen er kalibrert — ellers alarm-tretthet/waiver-spam på et brittle signal.
+- **Verifisering:** SessionStart-hook surfacer innholds-signal uten falske regresjons-alarmer; operatør-waiver-sti finnes.
+
+---
+
+## Noterte rester (uavhengig av fase-gating)
+- **✅ `✅ Verified`-trust-hazard — LØST 2026-06-26 (`83fd9b5`).** Premiss-sjekk myknet og innsnevret hazardet: «Verified» var **for det meste provenansbærende**, ikke et tomt stempel. To populasjoner: (a) **101 `✅ Verified`-konfidens-celler i 13 filer** — grønn hake + «Verified» uten nabokilde = det reelle (men myke) over-signalet; legend i `m365-copilot-plugins-ecosystem.md` definerte det faktisk som «hentet fra MS Learn via MCP» = `Documented`. (b) **142 plain `Verified`-celler i 31 kilde-attribusjons-tabeller** — nabokolonnen ER kilden (proveniens til stede). **Operatør valgte smal fix (A):** (a) → `✅ Documented` + 5 kolonne-overskrifter + skill-gen-taksonomien (`Verified/Baseline/Assumed` → `Documented/Baseline/Assumed`); (b) LA STÅ (degraderer ærlige celler). Suite 509/509. **Åpent (operatør):** versjonsbump/release for denne content-endringen — se under.
+- **Versjonsbump for `83fd9b5`?** Ref-fil-innhold er user-facing flate, men dette er label-ærlighet (ikke kapabilitet). Anbefaling: ingen bump nå; batch release med neste substansielle endring (Fase 0-utfall / Cosmo). Operatør avgjør.
+
+## Gating-valg for operatør (avklares før relevante faser)
+1. **Mål-først (anbefalt) vs bygg-begge-direkte.** ✅ LØST av Fase 0-gaten: bygg-begge-og-mål på volatil populasjon i **S3** (se roadmap under). Begge krevde gull-settet — nå levert (373 påstander, frosset).
+2. **Cosmo-sekvensering.** Struktur-/tag-arbeid på `ms-ai-advisor` (lavest score 91 + hjem til `adr-template`) kolliderer med godkjent Cosmo-utfasing (samme skill). Vente til Cosmo er ute, eller koordinere? Påvirker Fase 1b/1c/2 for advisor-filer.
+3. **N4-revekting.** Håndheve TOC-regelen reelt (re-vekt N4 / skaler med filstørrelse)? Drar 91–96 midlertidig under 90 → Spor D-alarm. Policy, ikke defekt.
+
+## Premiss reconciled (AVKLART 2026-06-26)
+«Navngitt 169 / mappe 220» (audit) vs «151 navngitt / 238 mappe-only» (workflow akse 1). **Løst:** `ref-file-audit.py` kjørt på nytt gir reproduserbart **169 / 220 / 0 orphans** — autoritativt (transparent heuristikk: `basename ∈ SKILL.md + agents/*.md`). 151/238 var et ikke-reproduserbart engangs-agentanslag med strammere «named»-definisjon; forkastet. Begge summerer 389 og er enige om **0 orphans** — avviket er kun named/folder-grensen og er **immaterielt**: intet tiltak (Fase 0–3) kjører på den grensen, kun «0 død vekt» (begge bekrefter).
+
+## Fler-sesjons-eksekveringsplan (roadmap — etablert 2026-06-26, etter Fase 0-gaten)
+
+Fase 0 ✅ lukket; gaten sa **BYGG Fase 3 (scoped)**. Gjenstående arbeid har **én kritisk sti** (Fase 2 → Fase 3-forutsetninger → judge/bake-off → Fase 4) + **to uavhengige side-spor** (TOC-håndverk, Cosmo) + **ett lav-prio** (OKF). Hver sesjon har en **kjørbar gate** (autonomi-vennlig — gå ikke videre før kriteriet er grønt). Premiss-tall (389/306/83) er recon-funn over; eksekverende sesjon **re-verifiserer mot ground truth FØR den muterer** (premiss-verifiseringsplikt).
+
+**Dependensgraf (kort) — mål-FØRST:**
+- `1c → 1b` (ellers reverserer generatoren TOC-arbeidet ved neste KB-update).
+- **Bake-off (S1) bruker det FROSNE gull-settet (373, `evidence_url` per påstand finnes allerede)** ⇒ uavhengig av frontmatter/backfill ⇒ judgen kan **de-rises FØR** scaffolding bygges. Dette er den retnings-avgjørende målingen, ikke type-tag.
+- Fase 2 type-tag (S2): judge-uavhengig, nyttig uansett utfall (trengs selv for staleness-only sourcedness). Backfill + full frontmatter (S3): **KUN hvis S1 passerer** — ellers wasted, judge-spesifikk scaffolding.
+- Fase 3-mekanisme `→` Fase 4.
+- Cosmo berører `ms-ai-advisor` ⇒ kolliderer med strukturarbeid på advisor-filer (løses ved scoping, se beslutning 2).
+
+### Kritisk sti (mål-først: de-risk judgen før du bygger scaffolding rundt den)
+
+**S1 — Judge-prototype + bake-off på frosset gull-sett (DE-RISK, retnings-avgjørende).** Bygg en minimal per-påstands groundedness-judge (Opus 4.8 xhigh) og kjør den mot de 373 gull-påstandene (hver har allerede `evidence_url` + ordrett påstand). Mål **staleness vs judge vs hybrid** på volatil populasjon, scoped til fetchbare claim_types (`taxonomy/status/version/tpm/sku/region`; `price` ekskludert). Trenger **ingen** backfill/frontmatter — gull-settet er selvbærende. **Gate:** judge presisjon/recall mot gull ≥ avtalt terskel OG slår staleness (recall 0/40); kjent felle adressert (invertert leverage — judgen «vinner» ikke ved å auto-score stabile lav-risiko-påstander). **HVIS FAIL:** stopp — judge ikke berettiget; fall tilbake på staleness + operatør-gating; **bygg IKKE S3**. ~1 sesjon de-risker hele kritisk sti.
+
+> **FORHÅNDSREGISTRERT GATE (låst 2026-06-26, operatørvalg, FØR fan-out):** judge **recall ≥ 0,80 OG presisjon ≥ 0,70** (punktestimat), målt på den verifiserbare evaluerings-populasjonen P = volatil + fetchbar claim_type (price ekskl.) = **240 påstander, 38 positive**. PLUSS nødvendig betingelse: judge-recall > staleness-recall (staleness = 0/38). Wilson 95 %-bånd rapporteres som kontekst (n=38 → bredt bånd); grensetilfeller flagges for operatør, ikke mekanisk avvist. Strengt nivå valgt: bygg S3 KUN hvis judgen er svært sterk. **Harness (testet, 14 tester):** `lib/judge-bakeoff.mjs` + `extract-judge-claims.mjs` (blind manifest, 0 label-lekkasje) + `judge-claim-prompt.md` (blind per-påstands-judge) + `run-judge-bakeoff.mjs --min-recall 0.80 --min-precision 0.70`. Blindhet: judgen ser aldri gull-verdict; join på `id` i koden etterpå.
+
+> **S1-v2-RESULTAT (2026-06-26, målrettet iterasjon — operatørvalg (c)): GATE ✅ PASS — recall 84,2 %, presisjon 84,2 %.** v2-prompt `judge-claim-prompt-v2.md` (eksakt-verdi-entailment, prinsipiell fiks på diagnostisert grounded-men-feil-feilmode; terskel uendret). Rapport: `judge-bakeoff-report-v2.{json,md}`; resultater: `judge-bakeoff-results-v2.json`. **Judge: recall 84,2 % (32/38, ✅ ≥0,80, Wilson [69,6–92,6 %]), presisjon 84,2 % (✅ ≥0,70), F1 0,842, slår staleness 0/38.** Fiksen løste målet: **sku 37,5 %→75,0 %, taxonomy 66,7 %→100 % recall**; +6 ekte fangster (26→32) UTEN netto nye FP (6→6) ⇒ recall OG presisjon opp samtidig (mekanistisk koherent, ikke støy). **Ærlige forbehold:** (1) andre måling på samme frosne gull-sett etter v1 (åpent erkjent; v1 frosset); (2) Wilson nedre grense 69,6 % < 0,80 (n=38) ⇒ sann recall ≥0,80 ikke statistisk garantert; (3) region 50 % (n=2) for lite. **Gate-logikk ⇒ vei mot S3 (scoped/hybrid).** NESTE OPERATØR-BESLUTNING: gå til S2 (type-tag) + S3 (backfill/frontmatter)? (stoppet her — eskalerer ikke selv.)
+
+> **S1-RESULTAT (2026-06-26, blind fan-out 15 batcher Opus xhigh, 255 påstander dekket): GATE ❌ FAIL — recall 68,4 % < 0,80.** Rapport: `scripts/kb-eval/data/judge-bakeoff-report.{json,md}`; resultater: `judge-bakeoff-results.json`. **Judge: presisjon 81,3 % (✅ ≥0,70), recall 68,4 % (❌ <0,80, Wilson [52,5–80,9 %]), fanget 26/38, slår staleness 0/38 desisivt.** Recall-draget er **konsentrert**: sku 37,5 % (3/8) + taxonomy 66,7 % + region 50 % (n=2); version/status/tpm er allerede 80–86 % recall ved 75–100 % presisjon. 10 av 12 bommer var «grounded»-men-feil (brittle claim-dekomponering, isolert til sku/taxonomy). Per pre-registrert gate ⇒ **STOPP, bygg IKKE S3.** **ÅPEN FORK (operatør):** (a) honorer FAIL — fall tilbake på staleness + operatør-gating [ren pre-registrering]; (b) scoped judge — auto-flag kun sterke typer (version/status/tpm), operatør-gate sku/taxonomy [data-støttet mellomvei]; (c) én målrettet prompt-iterasjon på sku/taxonomy + re-kjør [flagg p-hacking-risiko: frys v1 som ærlig pre-registrert utfall].
+
+**S2 — Fase 2: minimal type-tag (judge-uavhengig, nyttig uansett).** Klassifiser ~389 filer `reference|template|methodology|regulatory` (sidecar-manifest el. mappekonvensjon — IKKE full YAML ennå). Skiller de ~83 kildeløse legitimt (mal/metodikk: `decision-trees`, `cost-models`) fra MS-fakta-uten-kilde. NY `scripts/kb-eval/classify-ref-type.mjs` (TDD-først). Kan kjøres før/parallelt med S1 (billig). **Scope:** klassifiser advisor-filer, men MUTÉR dem ikke (Cosmo-kollisjon). **Gate:** hver fil har én type; kildeløse delt i to bøtter; reproduserbar; suite grønn.
+
+**S3 — Fase 3-forutsetning (a)+(b): backfill + full frontmatter (KUN hvis S1 passerte).** Produksjons-scaffolding for judgen: gi hver verifiserbar fil (~306 som siterer ≥1 MS Learn-URL, **EKSKL. advisor**) en `authority_source` + full frontmatter (`type/source/verified`, OKF-form). Advisor folder inn i **S-Cosmo**. Gated bak S1 fordi dette er judge-spesifikt og wasted hvis judgen feilet. **Gate:** hver ikke-advisor verifiserbar fil har `authority_source`; frontmatter validerer; suite grønn.
+
+**S4 — Produksjons-judge-utrulling + Fase 4-integrasjon.** Rull judgen over korpuset (4 skills; advisor post-Cosmo). Fold valgt mekanisme inn i KB-refresh-kadens (IKKE SessionStart — for dyrt; ~2700 ikke-batchbare `microsoft_docs_fetch`/full-pass). Rapporterende gulv (Spor D peker, ikke hard gate, før kalibrert). CT5 (sourcedness) **ERSTATTER** K8s rolle. **Gate:** SessionStart surfacer innholds-signal uten falske regresjons-alarmer; operatør-waiver-sti finnes.
+
+### Side-spor (uavhengig — interleaves når kritisk sti venter)
+
+**SH — Fase 1b/1c: TOC + generator-guard.** Trygt håndverk. **1c FØR 1b** (ellers reverserer neste KB-update headerne — write-path-regresjon). ~20–29 filer >800 linjer. Ekskluder advisor-filer (Cosmo). Avhenger av operatør-beslutning 3 (N4-revekting). **Gate:** `eval.mjs checkN4 hasToc=true` på målfilene; generator føder TOC + kanonisk header; ingen diff-churn på små filer.
+
+**S-Cosmo — Cosmo-utfasing (GODKJENT, gjøres SIST).** Fjern persona helt. Absorbér i samme pass: 1a-C (44+3 redirects), advisor-filenes frontmatter/backfill (fra S2) + TOC (fra SH). LES `docs/cosmo-removal-brief-2026-06.md`. Aldri ny Cosmo-innhold. **Gate:** 0 Cosmo-referanser igjen; advisor judged etter Cosmo.
+
+**S-OKF — OKF auto-inbox-pipeline (LAV PRIO).** Skjul OKF fra bruker. `docs/okf-second-brain-brief-2026-06.md`.
+
+### Operatør-beslutninger låst inn av denne planen
+1. **Mål-først vs bygg-begge** → ✅ LØST av gaten: bygg-begge-og-mål på volatil populasjon (S3).
+2. **Cosmo-sekvensering** → **ANBEFALT resolusjon:** advisor-strukturarbeid folder inn i S-Cosmo; Fase 3-bake-off bruker frosset gull-sett (uavhengig av advisor-frontmatter); produksjons-judge dekker 4 skills først, advisor post-Cosmo. Respekterer «Cosmo sist» UTEN å blokkere kritisk sti.
+3. **N4-revekting** → avgjøres ved SH (policy, ikke defekt; TOC-håndheving drar 91–96 midlertidig < 90 → Spor D-alarm).
+4. **Versjonsbump `83fd9b5`** → batch med S3- eller S-Cosmo-release.
+
+**Anbefalt neste sesjon: S1** (judge-prototype + bake-off på frosset gull-sett — den retnings-avgjørende de-risk-målingen; krever ingen scaffolding, slår staleness-recall 0/40 eller stopper kritisk sti). S2 (type-tag) er judge-uavhengig og kan tas i samme/tidligere slot om ønskelig. Trygt alternativ: SH (TOC), men avklar beslutning 3 først.

docs/skill-eval-routine-improvement-2026-06.md

@@ -0,0 +1,95 @@
+# Skill-eval-rutinen — forbedringsspor (Pocock-lens + best-practice-triangulering)
+
+_Task-brief. Skrevet 2026-06-30. Stier relative til plugin-rot. Durabel (overlever `/clear`); STATE.md peker hit._
+
+> **Status:** SPEC / ikke startet. Lagt inn på operatørs eksplisitte forespørsel (utgangspunkt: Matt Pococks «Writing Great Skills»-talk). Forbedringen kjøres som eget spor — IKKE bland med KB-korrekthets-sprinten (judge v3.1). Research-grunnet 2026-06-30 (to Opus-agenter: offisiell Anthropic + community-triangulering).
+
+---
+
+## 0. Mål / hvorfor
+
+Forbedre **rutinen som scorer skill-kvalitet og deres referansefiler** — `scripts/kb-eval/lib/skill-score.mjs` (ren rubrikk) + `scripts/kb-eval/eval.mjs` (deterministiske sjekker) + judge-laget — ved å folde inn Matt Pococks «Writing Great Skills»-rammeverk som en **ny lens**, triangulert mot offisiell Anthropic-guidance og eksisterende community-lintere. Pluginen er **showcase** ([[showcase-reusable-patterns]]); korrekthets-mekanismen (judge + gold + målt adopsjon) fra KB-sporet er **det samme mønsteret** som de nye judge-kriteriene under skal bruke — porter den, ikke gjenoppfinn.
+
+**Nordstjerne:** høyest mulig kvalitet på skills + refs, målt objektivt, med klare forbedringspekere. Ikke flere kriterier for kriterienes skyld — hvert nytt punkt må enten fange en reell feilklasse rubrikken slipper i dag, eller erstatte et svakere signal.
+
+## 1. Nåværende rutine (grounded — verifisert, ikke gjettet)
+
+16-kriteriers vektet rubrikk med **hardt gulv** på de to last-bærende (K1 trigger-presisjon, K10 søsken-overlapp); score `< 90` ⇒ under mål. Allerede grunnet i Anthropics offisielle «Skill authoring best practices» (nær 1:1 med deres deterministiske sjekkliste). Spec: `docs/skill-quality-scoring-plan.md`.
+
+| Dekket i dag (K/N/CT) | Kort |
+|---|---|
+| K1 trigger-presisjon (judge, gulv, v3) · K2 description-format · K10 søsken-overlapp (det, gulv) | trigger + scope |
+| K3 body ≤500 linjer · K5 progressiv disclosure · K6 routing · N3 refs én nivå · N4 TOC >100 linjer | struktur |
+| K4 ingen duplisering (judge) · K7 imperativ stil (judge) · K9 ingen volatil tid-info (judge) | steering/pruning-snitt |
+| CT5 sourcedness (dormant til Port 1) · refCount · N1 name · N2 desc ≤1024 · N5 forward-slash | refs/hygiene |
+
+**Fase 2 (allerede på roadmap, ikke bygget):** uplift-eval — «hjelper skillen vs. ingen-skill-baseline» (with-skill vs baseline pass-rate-delta). Skill-eval-plan §5.
+
+## 2. Tre kilde-lag (research 2026-06-30)
+
+**A. Anthropic offisiell (høyest autoritet, deterministisk ryggrad).** «Skill authoring best practices», `skill-creator`, `plugin-dev:skill-development`, engineering-blogg. Bekrefter dagens rubrikk + avdekker offisielt-belagte signaler vi IKKE bruker ennå (se §3). Viktig: **ingen offisiell 0–100-rubrikk finnes** — vi fyller et reelt gap, men hvert punkt skal spores til en checklist-regel, ikke oppfinnes.
+
+**B. Matt Pocock «Writing Great Skills» (én sterk praktiker; opinion, ikke spec).** Faktiske skill-seksjoner: *Invocation · Writing the description · Information hierarchy · When to split · Pruning · Leading words · Failure modes*. **Premiss-korreksjon (verifiseringsplikt):** talens «vertical slice»- og «grill-with-docs vs to-PRD»-eksempler finnes IKKE i den faktiske skillen — reelle leading-word-eksempler er *lesson, fog of war, tracer bullets*, samt refactors *«fast, deterministic, low-overhead» → tight* og *«a loop you believe in» → red*. Bruk de verifiserte, ikke talens parafrase.
+
+**C. Community + eksisterende lintere (sekundært — HØST sjekklistene, ikke gjenoppfinn).** `superpowers` (TDD-for-skills, ord-budsjett per tier, «description = trigger-only»); og ferdige 0–100-scorere: `skillcheck` (description-score 0–100), `skillscore`, `rubric-evaluator` (to-lags BLOCKER/MAJOR/MINOR-gate + judge), `agnix` (156-regel-linter). Vårt høyeste løft: kopier deres deterministiske sjekker der de er bedre enn våre.
+
+## 3. Gap-analyse: Pocock × nåværende rubrikk
+
+| Pocock-dimensjon | Dekket i dag? | Gap (ny verdi) | Automatiserbar? |
+|---|---|---|---|
+| **Invocation** — user- vs model-invoked design; context-load (model-desc koster tokens hver request) vs cognitive-load | Nei (K1 scorer kun *presisjon*, ikke *design-valget*) | Side-effekt-skill (deploy/commit/push/send/delete) UTEN `disable-model-invocation` = warn (offisielt belagt, CC); kombinert `description`+`when_to_use` ≤1536 listing-cap; `context: fork` uten reell oppgave | **Delvis** (verb-heuristikk + lengde = det; «er model-invocation berettiget?» = judge) |
+| **Information hierarchy / when to split** — steps m/ completion-criterion; reference i to lag; flytt én-grens-materiale bak context-pointer | Delvis (K3/K5/K6/N3/N4 = størrelse/lenker, ikke gren-bevissthet) | Step uten observerbart completion-criterion; én-grens-ref inlinet i SKILL.md; **orphan-ref** (fil i mappe ikke lenket fra SKILL.md); context-pointer mangler trigger-frase | **Delvis** (orphan/depth/size = det; «bør splittes?» / «criterion observerbart?» = judge) |
+| **Leading words** — kompakt pretrent konsept agenten ekko-er i reasoning | Nei | Konsistens-proxy: et myntet begrep brukt konsistent + i description (det); høy-signal-kvalitet (judge) | **Delvis** (konsistens = det; «ekte leading word?» = judge) |
+| **Legwork / split-by-sequence** — krevende criterion driver grundighet; skjul fremtidige steg | Nei | Vag gate-språk («make sure it works», «looks good») som ikke er binært; premature-completion | **Judge** (kjernen) |
+| **Pruning — no-ops / deletion-test** — «endrer denne setningen atferd vs default?» | Delvis (K4 = duplisering) | Boilerplate-denylist (det, grovt); ekte no-op-test (judge); **sediment** (stale lag) (judge) | **Mest judge** (denylist fanger kun det åpenbare) |
+| **Massive skills / DRY på tvers** | Delvis (K3 + K4 per-skill) | Nær-duplikat på tvers av HELE skill-korpuset (hashing/embedding) | **Det** (cross-corpus near-dup) |
+
+## 4. Foreslåtte forbedringer
+
+**4a. Nye deterministiske kriterier (eval.mjs + skill-score.mjs, TDD, billig):**
+- **Side-effekt-uten-gate-vakt:** name/description matcher destruktive verb (deploy/commit/push/send/delete/publish) OG `disable-model-invocation` ikke satt → warn. (CC-belagt.)
+- **Listing-cap:** kombinert `description`+`when_to_use` ≤ 1536 tegn (Claude Code-spesifikk). Separat fra dagens N2 (1024 = hard felt-maks).
+- **Body token-budsjett:** body < 5k tokens (offisielt, i tillegg til <500 linjer).
+- **Orphan-ref-deteksjon:** ref-fil i skill-mappe ikke lenket fra SKILL.md = smell.
+- **ALL-CAPS-vegg / rigid MUST:** `ALWAYS`/`NEVER`-all-caps + tette `MUST`-vegger = `skill-creator` «yellow flag».
+- **Cross-corpus near-duplicate:** duplisert blokk/setning på tvers av skills (DRY-brudd over korpuset, ikke bare per-skill).
+- **Vurder:** ToC-terskel-konflikt (BP 100 vs SC 300 linjer — velg 100 som strengere, warn på 300); deskriptive filnavn (`doc2.md`/`file1.md`-denylist); fully-qualified MCP `Server:tool`.
+
+**4b. Nye judge-kriterier (utvider EKSISTERENDE judge-lag — samme mønster som KB-judge):**
+- **No-op / deletion-test:** per setning, «endrer dette atferd vs default?» → kandidat for kutt. Pococks kjerneteknikk; ikke regex-reduserbar.
+- **Leading-word-kvalitet:** er et myntet begrep et ekte høy-signal pretrent konsept, brukt konsistent?
+- **Completion-criterion-observerbarhet:** er hvert stegs sluttbetingelse binær/observerbar vs fuzzy?
+- **Sediment:** stale/irrelevant akkumulert materiale.
+- **(divergens-nøytral):** «model-invocation berettiget?» — IKKE belønn `disable-model-invocation`-tilstedeværelse per se (se §5).
+
+**4c. Arkitektur — adopter to-lags-mønsteret eksplisitt (`rubric-evaluator`-mønster, speiler vårt eget):**
+Deterministiske sjekker = gate/severity (vi har gulv-mekanismen); judge scorer den semantiske resten. **Port judge-bake-off-disiplinen fra KB-sporet:** bygg et lite gull-sett for skill-kvalitet, kalibrer judge-prompten mot dokumenterte feilmoduser, MÅL adopsjon (slå forrige) — IKKE ad-hoc-patch. [[gold-freshness-can-invert-adoption]] gjelder også her: et skill-kvalitets-gull eldes.
+
+## 5. Divergenser å håndtere (ikke hardkod én side)
+
+1. **Description: «what + when» (Anthropic) vs «trigger-only» (superpowers).** Superpowers MÅLTE at workflow-oppsummering i description får agenten til å hoppe over å lese skillen. → Ikke straff utelatt «what» som hard regel; gjør konfigurerbar.
+2. **Invocation-default: 1%-regel/model-default (superpowers) vs berettig-model-invocation (Pocock).** → Ikke belønn `disable-model-invocation` per se; belønn berettiget valg (judge) eller vær nøytral.
+3. **Lengde-enhet: 500 linjer (Anthropic) vs 150/200/500 ord per tier (superpowers).** → Velg én enhet; eksponer terskel som config; hyppig-lastede skills tåler strengere.
+4. **Cross-surface-konflikter (linter MÅ vite hvilken flate):** `name`/`description` required (platform/spec) vs optional (Claude Code); `allowed-tools` restriktiv (spec experimental) vs IKKE-restriktiv i Claude Code; `when_to_use` kun Claude Code. Ikke hard-fail på feil flate.
+
+## 6. Sekvensering
+
+0. **(valgfritt, men anbefalt FØRST)** Dypere research hvis ønsket: `/deep-research` eller `/trekresearch` på de eksisterende linterne (`skillcheck`/`skillscore`/`rubric-evaluator`/`agnix`) — høst konkrete regel-lister + se hva de scorer som vi ikke gjør. Denne briefen har allerede triangulert hovedrammeverkene; en full deep-research-pass er for å hente *implementerings-detaljer* fra de eksisterende verktøyene.
+1. **Velg scope:** hvilke §4a/§4b-kriterier gir mest signal? Start med §4a (billig, deterministisk, høy tillit) + ett judge-kriterium (no-op-test, høyest Pocock-verdi).
+2. **TDD (Iron Law):** failing test først (fixtures i `tests/kb-eval/`), så implementer i `eval.mjs` (disk) + `skill-score.mjs` (ren scoring).
+3. **Re-score korpuset** + kalibrer vekter (ikke la nye kriterier tanke alle skills under 90 % ukontrollert — degrader nye judge-kriterier til `available:false` til de er kalibrert, slik CT5 gjør i dag).
+4. **Judge-bake-off** for §4b-kriteriene (gull + kalibrert prompt + målt adopsjon, §4c).
+5. **Wire** i `score-skill.mjs --write`-cachen → Spor D SessionStart-surfacing.
+
+## 7. Verifisering (kjørbare kriterier)
+
+- `node --test tests/kb-eval/*.test.mjs` grønn etter hver ny sjekk (nye fixtures: side-effekt-uten-gate, orphan-ref, ALL-CAPS-vegg, cross-corpus-dup, listing-cap >1536).
+- `node scripts/kb-eval/score-skill.mjs --json` kjører uten regresjon på de 5 nåværende skills; nye kriterier vises i forbedringsrapporten med konkret `fix`.
+- Hvert nytt deterministisk kriterium: vis at det FANGER en injisert feil-fixture OG ikke flagger en ren fixture (presisjon + recall, som G3-linten).
+- Judge-kriterier: bake-off mot skill-kvalitets-gull slår forrige judge (P OG R), ellers ikke adoptert (§4c, samme gate som KB-judge).
+- Ingen regresjon: full suite + `validate` grønn.
+
+## 8. Kilder (verifisert 2026-06-30)
+
+Offisielt: [Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices) · [Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) · [Extend Claude with skills (Claude Code)](https://code.claude.com/docs/en/skills) · [skill-creator SKILL.md](https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md) · [Equipping agents for the real world](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) · [Agent Skills open standard](https://agentskills.io/specification).
+Community: [mattpocock/skills — writing-great-skills](https://github.com/mattpocock/skills/blob/main/skills/productivity/writing-great-skills/SKILL.md) · [obra/superpowers — writing-skills](https://github.com/obra/superpowers/blob/main/skills/writing-skills/SKILL.md) · [halfmoon-mind/rubric-evaluator](https://github.com/halfmoon-mind/rubric-evaluator) · [thedaviddias/skill-check](https://github.com/thedaviddias/skill-check) · [skillscore](https://dev.to/sayed_ali_alkamel/skillscore-a-cli-that-scores-your-ai-agents-skillmd-0-100-48l1) · [Test any skill without an LLM judge](https://medium.com/@nemadesumit/how-to-test-any-claude-code-skill-without-an-llm-judge-3da402de7146) · [MLflow — Evaluating Skills](https://mlflow.org/blog/evaluating-skills-mlflow/).

docs/skill-lifecycle-spor-b-plan.md

@@ -0,0 +1,102 @@
+# Spec — Spor B: Skill-livssyklus (ms-ai-architect)
+
+_Plan-input (operatør-retning 2026-06-20, IKKE ferdig-godkjent ennå). Avløser «Spor B»-stikkordene i `kb-mechanism-redesign-plan.md` linje 281/383. Implementeres én sesjon per økt, per-fase gated; STATE.md peker på neste sesjon. Sti-konvensjon: relativt til plugin-rot._
+
+## Hva dette er
+
+Spor A (krav 1–4) er komplett: mekanismen holder de **eksisterende** 5 skillene oppdatert, komplette og målbart optimaliserte (K1–K9 grønn, lag 0–6 står). Spor B aktiverer de to kravene som ble **utsatt** (ikke forkastet) 2026-06-19:
+
+- **Krav 5 — lage nye skills profesjonelt.** (`kb-mechanism-redesign-plan.md:90`)
+- **Krav 6 — slå sammen / slette / sanere skills (livssyklus, destruktive ops).** (`kb-mechanism-redesign-plan.md:91`)
+
+Forutsetningene er nå innfridd: krav 5 «forutsetter lag 0–3» og krav 6 «vurderes etter at lag 1–6 står» — alt står.
+
+> **Scope-endring (eksplisitt):** `kb-mechanism-redesign-plan.md:19` listet krav 5/6 som «UTE av scope». Denne planen flytter dem **inn** i scope, men **omdefinert** (se under). Linje 19 er dermed superseded av dette dokumentet for Spor B.
+
+## Operatør-retning 2026-06-20 (binder denne planen)
+
+1. **Deteksjon først.** Bygg skill-granulær deteksjon (ikke-destruktiv, kun forslag); create/merge/saner drives av det deteksjonen finner.
+2. **Best-practice-bar = K1–K9 + overlapp-kriterium.** Behold K1–K9 (nå grønn); legg til ett nytt førsteklasses kriterium: søsken-scope-ikke-overlapp.
+3. **INGEN nye domener.** Ikke Power Platform, ikke Dynamics 365. De 5 skillene dekker domenerommet. → Tyngdepunktet forskyves fra *create* til **merge/saner på de eksisterende 5**. Create bygges som **dvelende kapabilitet** (mekanismen finnes og valideres, men ingen ny domene-skill shippes nå).
+
+### Åpen antakelse — MÅ bekreftes før B1 bygges
+
+Operatør sa: «det eneste [nye dekningsområde] måtte være **overlapp mot Microsoft Azure for deployment**». Tolkning lagt til grunn: dette er IKKE en ny skill, men en **grensesone** mellom eksisterende `ms-ai-engineering` («bygge») og `ms-ai-infrastructure` («drifte») rundt Azure-deployment/-drift. → Brukes som **det konkrete første deteksjonsmålet** i B1 (overlap-detektoren ser spesifikt på engineering↔infrastructure-grensen). Hvis tolkningen er feil: korriger før B1.
+
+## Arkitektur-invarianter (arvet fra Spor A — ufravikelig)
+
+- **Ingen direkte KB-/skill-skriving.** Deteksjon/verifisering/transformasjon skriver ALDRI til `skills/` direkte — kun via `decisions.json` etter operatør-gate. Lag 3/4/5 returnerer kun data/verdict.
+- **Aldri tap av kuratert verdi.** Destruktive ops (merge/saner/retire) har obligatoriske guardrails som beviser at kuratert innhold er bevart (ref-fil-invariant + diff vist før apply).
+- **TDD.** Test før kode. Deterministiske kriterier regrederer aldri (`eval --json` + de fire suitene = akseptansemål: validate 239 · kb-update 122 · kb-eval 15 · kb-integrity 192/192).
+- **Kontinuitet:** kun STATE.md/MEMORY.md/CLAUDE.md + `docs/`-referanser.
+
+---
+
+## Fase B1 — Skill-granulær deteksjon (oppdage) · ikke-destruktiv
+
+**Problem:** Dagens deteksjon (lag 1) jobber kun på referansefil-nivå; `SKILL.md` er eksplisitt ekskludert (`build-registry.mjs:27`). Ingenting resonnerer om skill-overlapp, dekningshull eller oppblåsthet.
+
+**Mål:** Tre detektorer som resonnerer på SKILL-nivå og produserer KUN en rapport (`scripts/kb-eval/data/skill-lifecycle-report.json`), aldri skriving til `skills/`.
+
+1. **Overlap-detektor** — gjenbruk K1-mekanikken (`data/k1-trigger-prompts.json`, blindet judge) men cross-skill: hvilke prompts trigger >1 skill? Output: overlapp-par + styrke. **Første konkrete mål: engineering↔infrastructure (Azure-deployment-grensen).**
+2. **Coverage/gap-detektor (innen-domene)** — per taksonomi-kategori: er den eid + dekket (ref-fil-antall vs forventet)? Flagg tynne/ueide kategorier. Ingen nye domener — kun hull *innenfor* det dekkede.
+3. **Bloat/stale-detektor (per skill)** — K3-margin (body-linjer mot 500) + aggregert ref-stale-andel per skill → split-/saner-kandidat.
+
+**Leveranser:** `scripts/kb-eval/detect-skill-lifecycle.mjs` (+ libs etter behov) · `data/skill-lifecycle-report.json` · tester `tests/kb-eval/test-skill-lifecycle-detect.test.mjs`.
+
+**Gate-kriterier (verifiserbare):**
+- `node scripts/kb-eval/detect-skill-lifecycle.mjs` kjører, skriver gyldig `skill-lifecycle-report.json` med de tre detektor-seksjonene; **0 skriving til `skills/`** (bekreft med `git status` etter kjøring).
+- Overlap-detektoren rapporterer engineering↔infrastructure-paret med en tallfestet overlapp-score.
+- Nye tester grønne; de fire eksisterende suitene uendret (239/122/15/192).
+
+---
+
+## Fase B2 — Best-practice-bar: K10 søsken-scope-ikke-overlapp (definere)
+
+**Mål:** Utvid rubrikken med ett nytt kriterium **K10 = søsken-scope-ikke-overlapp** (deterministisk der mulig: cross-skill trigger-kollisjon fra B1-mekanikken; semantisk i `judge-prompt.md` der nødvendig). Dette er baren merge/create-beslutninger hviler på.
+
+**Leveranser:** K10 i `eval.mjs` og/eller `judge-prompt.md` · måling på alle 5 · gated regenerering av `eval-baseline.json` · oppdatert `kb-eval`-test (forventet ny telling) · STATE/roadmap-tall.
+
+**Gate-kriterier:**
+- K10 definert og målt på alle 5; resultat dokumentert. (Forventning: kan avdekke FAIL — det er signalet som mater B3 merge/saner, ikke en blokkering.)
+- Baseline regenerert via gated `--write`; `kb-eval`-suiten grønn med ny telling.
+- K1–K9 ikke regredert.
+
+---
+
+## Fase B3 — Ledger-utvidelse + livssyklus-ops (opprette / slå sammen / sanere) · krav 5 + krav 6
+
+**Mål:** Utvid `decisions.json` med skill-nivå action-typer og bygg ops som gated transformasjoner (lag-4-analog på skill-granularitet), hver med guardrails. Alt via operatør-gate.
+
+**Ledger-utvidelse:** legg `action`/`operation_type` i `decisions-io.mjs`-skjemaet: `merge_skills`, `sanitize_skill`, `retire_skill`, `create_skill`. (Dagens skjema er URL-nøklet, har ikke `action`-felt — `decisions-io.mjs`.)
+
+**Ops (prioritert per operatør-retning):**
+- **merge_skills (aktiv).** Guardrail: pre/post ref-fil-antall bevart (ingen tap), begge descriptions forsont, `category_skill` i taksonomi oppdatert, kryss-refs fikset, absorbert skill retired. Dry-run produserer `decisions.json`-entry + full diff; ingenting anvendt uten eksplisitt godkjenning.
+- **sanitize_skill (aktiv).** Kun dødt innhold (orphan-refs, dead paths fra `kb-integrity`-warnings) — diff vist; aldri kuratert innhold.
+- **retire_skill (aktiv, sjelden).** Hel-skill kun via eksplisitt gate + arkivering (aldri hard delete uten arkiv).
+- **create_skill (dvelende).** Scaffold som passerer K1–K10 fra fødsel; valideres mot et test-domene, men **ingen ny domene-skill shippes** (svar 3). Beviser at mekanismen finnes.
+
+**Gate-kriterier:**
+- `decisions-io.mjs`-skjema utvidet + tester for hver action-type (round-trip, dedup).
+- merge: guardrail-test beviser at ALLE ref-filer fra begge skills finnes etter merge (count-invariant + sett-likhet).
+- Hver op har dry-run som skriver decisions-entry + diff og anvender INGENTING uten godkjenning (test bekrefter no-write uten approval).
+- create: scaffold-output passerer `eval.mjs` K1–K10 grønt for test-skillen.
+- De fire suitene + K1–K10 ikke regredert.
+
+---
+
+## Ute av scope (Spor B)
+
+- Nye domener (Power Platform, Dynamics 365, etc.) — eksplisitt nei.
+- Restpunkter fra Spor A-stikkordene som ikke er skill-livssyklus: scheduled deteksjon · kurs-spor #25 · low-currency-bøtta (51) · bredere Source-backfill · onboarding-redesign #26. (Beholdes på roadmap; tas separat.)
+
+## Sesjons-sekvens (foreløpig)
+
+| Sesjon | Innhold | Gate |
+|--------|---------|------|
+| 13 | B1 overlap-detektor (eng↔infra Azure-deployment først) | report m/overlapp-score, 0 skill-skriving |
+| 14 | B1 coverage/gap + bloat/stale-detektorer | full `skill-lifecycle-report.json`, tester grønne |
+| 15 | B2 K10 + gated baseline-regen | K10 målt alle 5, baseline grønn |
+| 16+ | B3 ledger-utvidelse + ops (merge/saner først) | guardrail-tester, dry-run no-write |
+
+_Tall er foreløpige; én feature per sesjon, gated. create_skill (dvelende) tas sist._

docs/skill-quality-scoring-plan.md

@@ -0,0 +1,78 @@
+# Skill-kvalitetsscore (Spor D) — spec
+
+_Objektiv 0–100 %-kvalitetsscore per skill, med 90 %-bar, forbedringsrapport og SessionStart-surfacing. Grunnet i Anthropics faktiske skill-authoring-guidance (ikke oppfunnet akademisk). Skrevet 2026-06-23 (S37). Stier relative til plugin-rot._
+
+---
+
+## 0. Mål
+
+En **rutine som objektivt måler skill-kvalitet** og rapporterer hva som må forbedres, med målsetning **alle skills ≥ 90 % til enhver tid**. Bygger oppå den eksisterende K1–K10-rubrikken i `scripts/kb-eval/eval.mjs`, som research (under) viser er nesten 1:1 med Anthropics kanoniske «Skill authoring best practices»-sjekkliste — altså allerede grunnet i reell praksis, ikke akademisk oppfunnet.
+
+## 1. Verifiseringskilder (Anthropic primær)
+
+- **«Skill authoring best practices»** — platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices (hentet 2026-06-23). Kanonisk sjekkliste + eksakte tall.
+- **`skill-creator` (Anthropic-shippet skill)** — `~/.claude/plugins/.../skill-creator/SKILL.md`. Description-optimizer (trigger-presisjon via 20 queries / 60-40 train-test / 3 kjøringer), eval-loop.
+- **`plugin-dev:skill-development` (Anthropic-shippet)** — third-person description, imperativ form, progressiv disclosure, «avoid duplication».
+- **«Equipping agents for the real world with Agent Skills»** — anthropic.com/engineering (hentet 2026-06-23). Progressiv disclosure, evaluering fra capability-gaps, baseline-uplift.
+
+### Eksakte, målbare regler funnet (med kilde)
+| Regel | Tall | Kilde |
+|---|---|---|
+| `name` | ≤64 tegn, `a-z0-9-`, ingen XML, ingen reserverte ord («claude»/«anthropic»), gerund-form anbefalt | best-practices §Skill structure |
+| `description` | ≤1024 tegn, ikke-tom, 3.-person, «hva + når», spesifikke triggere | best-practices §Writing effective descriptions |
+| SKILL.md body | **< 500 linjer** («token budget», «optimal performance») | best-practices §Token budgets + §Progressive disclosure |
+| Refs én nivå dypt | ingen nøstede refs | best-practices §Avoid deeply nested references |
+| TOC i ref-filer | for filer **> 100 linjer** | best-practices §Structure longer reference files |
+| Ingen tid-sensitiv info i body | flytt til «old patterns»/`<details>` | best-practices §Avoid time-sensitive information |
+| Forward-slash-stier | aldri Windows-stier | best-practices §Avoid Windows-style paths |
+| Imperativ form | verb-først, ikke 2.-person | plugin-dev §Writing Style |
+| Ingen duplisering SKILL.md↔refs | info bor ett sted | plugin-dev §Avoid duplication |
+| Evaluering = sannhetskilde | ≥3 evals, **baseline uten skill → mål uplift** | best-practices §Evaluation and iteration |
+
+## 2. Rubrikk → score-mapping (binding)
+
+K1–K10 er allerede implementert i `eval.mjs` og validert mot tabellen over. Scoren legger til **fem nye deterministiske sjekker** fra Anthropic-sjekklista som rubrikken manglet (N1–N5), og aggregerer alt til 0–100.
+
+**Modell: vektet delpoeng + hardt gulv** (operatør-besluttet S37).
+
+| Kriterium | Kilde | Vekt | Gulv | Delpoeng (0–1) |
+|---|---|---|---|---|
+| **K1** trigger-presisjon | judge | 3 | **JA** | `precision` (korrekte/20) |
+| **K10** søsken-ikke-overlapp | det | 3 | **JA** | `pass?1 : max(0, 1-(maxCombined-terskel)/terskel)` |
+| **K3** body ≤500 linjer | det | 2 | — | `lines≤500?1 : max(0, 1-(lines-500)/500)` |
+| **K4** ingen duplisering | judge | 2 | — | `score/5` |
+| **K9** ingen volatil tid-info | judge | 2 | — | `pass?1:0` |
+| **K2** description-format | det | 1 | — | `pass?1:0` |
+| **K5** progressiv disclosure | det | 1 | — | `min(1, namedRatio/0.2)` |
+| **K6** routing-pekere | det | 1 | — | `pass?1:0` |
+| **K7** imperativ stil | judge | 1 | — | `ratio` |
+| **K8** kildehenvisning refs | judge | 1 | — | `ratio` |
+| ref-tall-konsistens | det | 1 | — | `consistent?1:0` |
+| **N1** name-validitet | det | 1 | — | `pass?1:0` |
+| **N2** description ≤1024 + ikke-tom | det | 1 | — | `pass?1:0` |
+| **N3** refs én nivå dypt | det | 1 | — | `pass?1:0` |
+| **N4** TOC i ref-filer >100 linjer | det | 1 | — | andel store filer med TOC |
+| **N5** forward-slash-stier | det | 1 | — | `pass?1:0` |
+
+**Aggregering:** `score = Σ(vekt·delpoeng for TILGJENGELIGE kriterier) / Σ(vekt for tilgjengelige) × 100`. «Tilgjengelig» = deterministiske alltid; judge-kriterier kun når `skill.judge` finnes (cachet i `data/judge-results.json`).
+
+**Hardt gulv:** feiler et tilgjengelig gulv-kriterium (K1 eller K10) → `score = min(score, 89)`. En skill som ikke trigger riktig (K1) eller overlapper en søster (K10) kan aldri «bestå» 90 %, uansett form. (Anthropic: description/triggering «critical for skill selection».)
+
+**Degradering:** mangler/stale judge → judge-kriteriene ekskluderes fra både teller og nevner; `judged:false` flagges + nudge om å kjøre judge-passet. K1-gulvet kan da ikke håndheves → `score` merkes `provisional`. K10-gulvet (deterministisk) gjelder alltid.
+
+## 3. Komponenter (TDD, deterministisk-først)
+
+1. **`scripts/kb-eval/eval.mjs` (utvidelse):** N1–N5 deterministiske sjekker under `deterministic`. Disk-tilgang bor her (har allerede body/frontmatter/ref-filer).
+2. **`scripts/kb-eval/lib/skill-score.mjs` (NY, ren):** `scoreSkill(evalObj)` → `{name, score, rawScore, floored, judged, provisional, criteria[], improvements[], meetsTarget}`. Ingen disk — konsumerer eval-objektet → fullt testbar med fixtures.
+3. **CLI `scripts/kb-eval/score-skill.mjs` (NY):** kjører eval-pipelinen → scorer alle skills → rapport. `--json`, `--gate 90` (non-zero exit + forbedringsrapport hvis noen < 90).
+4. **`summarizeSkillQuality(report)` (i detection-schedule.mjs):** one-liner «Skill-kvalitet: N skills < 90 %», `null` ved alle ≥ 90. Wires i `session-start-context.mjs` (speiler kurs-/skill-signaler).
+
+## 4. Verifisering (kjørbar)
+- `node --test tests/kb-eval/test-skill-score.test.mjs` grønn: vektet aggregering, gulv kapper ved K1/K10-fail, degradering ekskluderer judge når `judge:null`, forbedringsliste sortert på poeng-tap, `meetsTarget`-grense.
+- N1–N5 enhetstester i `test-eval.test.mjs` (gyldig/ugyldig name, >1024 description, nøstet ref, manglende TOC, Windows-sti).
+- `score-skill.mjs --gate 90` returnerer non-zero når en fixture-skill er < 90; 0 når alle ≥ 90.
+- `summarizeSkillQuality`-test (one-liner + null).
+- kb-eval-suite + validate uendret-grønn (ingen regresjon).
+
+## 5. Fase 2 (roadmap, ikke nå) — effektivitet/uplift
+Anthropics *dypeste* mål: «does the skill actually help vs. no-skill baseline». Krever eval-harness (Claude-in-loop, operatør-gated) modellert på `skill-creator`s benchmark (with-skill vs baseline, `pass_rate`-delta, mean±stddev). Egen, tyngre fase — form-scoren over er nødvendig, men uplift er det endelige beviset. Spec-es separat ved opt-in.

docs/skill-validation-routine-brief-2026-07.md

@@ -0,0 +1,174 @@
+# Skill-valideringsrutinen — hvordan den er tenkt å virke (AI-Engineer-lens)
+
+_Task-brief. Skrevet 2026-07-01. Stier relative til plugin-rot. Durabel (overlever `/clear`). Grunnlaget er verifisert mot disk (to Opus-speidere), ikke gjettet — se §8 verifiseringslogg._
+
+> **Status:** BRIEF / ikke startet. Beskriver hvordan rutinen for å validere **én skill** er tenkt å virke ende-til-ende, og bærer **AI-Engineer-perspektivet** (behandle en skill som en ML-komponent: valider på atferd/effekt, ikke bare form) som forbedringsaksen.
+>
+> **Forhold til søsken-doc:** `docs/skill-eval-routine-improvement-2026-06.md` fordyper **Trinn 1 (form-scoringen)** via Pocock-lens. Denne briefen legger til **Trinn 2–3 (atferd/effekt)** + den samlende «valider én skill»-rutinen. De to overlapper ikke; de dekker hvert sitt lag. `docs/skill-quality-scoring-plan.md` er den bindende spec-en for Trinn 1.
+
+---
+
+## 0. Mål / hvorfor
+
+**Nordstjerne:** en skill anses ikke som «gyldig» fordi artefaktet er velformet, men fordi den **måles** å (a) trigge når den skal og bare da, og (b) faktisk forbedre modellens output på representative oppgaver — med statistisk sikkerhet og regresjonsvern. I dag måler den kjørende rutinen kun (a) som en proxy og (b) ikke i det hele tatt.
+
+Dette er **AI-Engineer-perspektivet**: du sender ikke en ML-komponent i produksjon fordi config-filen er velformet — du sender den på målt atferd mot et held-out eval-sett, med varians-tall, gated av regresjonstester. Pluginen har allerede en `ms-ai-engineering`-skill som lærer bort nettopp «MLOps for generativ AI / evals»; den forbedrede valideringsrutinen skal **praktisere det pluginen forkynner** (dogfooding), og mekanismen skal være portabel til søster-plugins ([[showcase-reusable-patterns]]).
+
+**Anti-mål for briefen:** ikke flere kriterier for kriterienes skyld. Hvert nytt trinn må enten fange en reell feilklasse dagens rutine slipper, eller erstatte et svakere signal med et sterkere.
+
+---
+
+## 1. Kontekst — de to valideringslagene (verifisert)
+
+Det finnes to helt separate ting som begge kalles «validere en skill». Å blande dem er den vanligste feilkilden.
+
+| Lag | Spørsmål | Hvor det bor i dag |
+|---|---|---|
+| **KB-/referansefil-korrekthet** | Er påstandene i `references/*.md` sanne mot kilde? | `generate-skills` «født-verifisert»-judge (v3.1) + `validate-kb-file.mjs` create-guard |
+| **Skill-kvalitet/triggering** | Er `SKILL.md` godt formet, trigger den riktig, overlapper den søsken, **hjelper den**? | `scripts/kb-eval/` (K1–K10 + N1–N5 → 0–100-score) |
+
+Denne briefen handler om **det andre laget** — men KB-korrekthet er en *forutsetning* (Trinn 0 under), så den nevnes eksplisitt, ikke utdypes.
+
+### 1a. Hva den kjørende rutinen måler i dag (Trinn 1 — form)
+
+Kilde: `scripts/kb-eval/eval.mjs` (deterministiske sjekker) + `lib/skill-score.mjs` (ren scoring) + CLI `score-skill.mjs`. Bindende spec: `docs/skill-quality-scoring-plan.md`.
+
+- **16-kriteriers vektet rubrikk → én 0–100-score per skill.** `TARGET = 90`, `FLOOR_CAP = 89`.
+- **Hardt gulv** på to last-bærende kriterier — **K1 trigger-presisjon** (vekt 3) og **K10 søsken-overlapp** (vekt 3): feiler en av dem, kappes scoren til ≤89 og skillen kan aldri passere, uansett formatering.
+- Aggregering: `Σ(vekt · delpoeng for TILGJENGELIGE kriterier) / Σ(vekt tilgjengelige) × 100`.
+- Øvrige: K3 body ≤500 linjer, K4 ingen duplisering (judge), K9 ingen volatil tid-info (judge), K2 description-format, K5 progressiv disclosure, K6 routing, K7 imperativ stil (judge), CT5 sourcedness, refCount, N1 name-validitet (≤64, `[a-z0-9-]`, ingen `claude`/`anthropic`), N2 description ≤1024, N3 refs én nivå dypt, N4 TOC i ref-filer >100 linjer, N5 forward-slash-stier.
+- **Gate:** `node scripts/kb-eval/score-skill.mjs --gate 90` → exit≠0 hvis noen skill <90. Kjøres etter skill-mutasjon i `apply-skill-op.mjs`, og signaleres ved sesjonsstart (Spor D-hook, viser skills <90 %).
+- **Cache:** `scripts/kb-eval/data/skill-score-report.json`.
+- **Nåværende status:** advisor=91, de fire andre=96, alle `meetsTarget`. Toppfiks stort sett N4 (TOC).
+
+### 1b. Hvordan K1 «trigger-presisjon» faktisk måles i dag — og hvorfor det er en proxy
+
+- Operatør-kuratert **20-prompt-sett per skill** (`data/k1-trigger-prompts.json`): 10 in-domain + 10 adversarielle out-of-domain (søsken-domene-prompter valgt for å teste over-trigging-grensen). PASS = ≥90 % hits / ≤10 % falske positive.
+- Avgjøres av en **blindet judge** (`judge-prompt.md`) som resonnerer **kun fra `description`-teksten** — ikke ved å faktisk kjøre prompten gjennom modellen.
+- Judge-kriteriene (K1/K4/K7/K9) krever et **manuelt, operatør-gated subagent-steg** (Opus, én dommer per skill). Uten fersk judge merkes scoren `provisional` og K1-gulvet kan ikke håndheves.
+
+Dette fungerer og har fanget ekte feil (governance K1 var 0.85 før Schrems-II-recall-fiksen; advisors NOT-liste validert som over-trigging-fiks). Men det er en **proxy**: en dommer som vurderer teksten, ikke atferd. Den fanger ikke at Claude i praksis *undertrigger* enkle queries — fordi modellen kun konsulterer en skill for oppgaver den ikke lett løser selv.
+
+---
+
+## 2. Problemet — AI-Engineer-gapet
+
+Dagens kjørende rutine er i praksis **strukturell hygiene + en trigger-proxy**. Seks konkrete hull, alle verifisert:
+
+1. **Form vs. effekt.** Rutinen måler kun *form*, aldri *uplift*: hjelper skillen faktisk vs. en ingen-skill-baseline? Dokumentert som eksplisitt roadmap-hull (skill-quality-scoring-plan §Fase 2), men ikke bygget.
+2. **K1 er en proxy, ikke live triggering.** En judge resonnerer om description-teksten; ingen query kjøres gjennom modellen. Fanger ikke undertrigging.
+3. **Ingen varians-analyse.** Judge kjøres **én gang** per skill. Ingen mean±stddev, ingen flaky-deteksjon, ingen repetisjon. LLM-output er stokastisk; ett kall er ett sample.
+4. **Judge er manuell og kan bli stale.** Ingen automatisk re-judge når `description` endres; scoren faller stille til `provisional`.
+5. **`generate-skills` validerer aldri skill-kvalitet.** Kommandoen som produserer mest innhold gater kun referansefil-korrekthet — aldri K1/K10/score. En skill kan drifte i triggering uten at noe fanger det.
+6. **Ingen samlende «valider én skill»-rutine.** I dag er det 3–4 uavhengige spor (født-verifisert KB-judge, create-guard, kb-eval-score, ekstern skill-reviewer/skill-creator). Ingen enkelt inngang binder KB-korrekthet + form + atferd sammen til én verdikt.
+
+**Nøkkelfunn:** mekanismene for hull #1–#3 finnes **ferdig-designet** i Anthropics `skill-creator`-skill, men er **ikke adoptert** i dette repoet:
+- **Effekt-eval (3a):** spawn with-skill OG baseline i samme tur → assertions + timing → grader → `aggregate_benchmark` gir pass-rate/tid/tokens med **mean±stddev + delta**; analyzer flagger ikke-diskriminerende og høy-varians-evals.
+- **Triggering-optimizer (3b):** 20 eval-queries (should/should-not, near-miss-negative), `run_loop.py` splitter **60/40 train/held-out**, kjører **hver query 3× for pålitelig trigger-rate** via live `claude -p`, og velger `best_description` **på test-score, ikke train** (unngår overfitting).
+
+Briefen finner altså ikke opp noe — den **adopterer og binder sammen** eksisterende byggeklosser under AI-Engineer-lensen.
+
+---
+
+## 3. Hvordan rutinen er tenkt å virke — mål-tilstand
+
+Én inngang, `validate-skill <name>`, kjører fem trinn i rekkefølge og emitterer én verdikt. Billige/deterministiske trinn først (fail-fast), dyre atferds-trinn sist.
+
+```
+validate-skill <name>
+  Trinn 0  KB-korrekthet (forutsetning)      ── født-verifisert + create-guard grønn?
+  Trinn 1  Form/hygiene-score (FINNES)        ── K1–N5 → 0–100, --gate 90
+  Trinn 2  Live triggering (NY · AI-Eng)      ── precision + recall, N× repetisjon, varians, train/held-out
+  Trinn 3  Effekt / uplift (NY · AI-Eng)      ── with-skill vs baseline, mean±stddev + delta
+  Trinn 4  Gate + regresjon                    ── behavioral gate ved siden av form-gate; auto re-run ved endring
+  → verdikt: PASS / NEEDS-WORK / FAIL  +  forbedringspekere
+```
+
+### Trinn 0 — KB-korrekthet (forutsetning, finnes)
+Referansefilene skal være født-verifisert (`Verified by: judge-v3.1`) og bestå create-guard (`validate-kb-file.mjs`: Source, TOC, kontrakt-header). Ikke en del av skill-*kvaliteten*, men må være grønt før atferds-evals gir mening — en skill kan ikke «hjelpe» hvis KB-en den ruter til er feil.
+
+### Trinn 1 — Form/hygiene-score (finnes; fordypes av Pocock-doc)
+Behold uendret som den **billige, deterministiske gaten**: K1–N5 → 0–100, `--gate 90`, hardt gulv på K1/K10. Dette er raskt, kjører i CI, og fanger regresjoner i struktur/scope uten modell-kall. Pocock-doc'et (`skill-eval-routine-improvement-2026-06.md`) utvider dette trinnet — ikke reforhandlet her.
+
+### Trinn 2 — Live triggering (NY · kjernen i AI-Eng-løftet)
+Erstatt/suppler K1-judge-proxyen med **behavioral triggering-måling**:
+- Utvid det kuraterte 20-prompt-settet til et **merket eval-sett** med should-trigger + should-not-trigger, der negative er **near-misses** (deler nøkkelord med skillen, men trenger noe annet — typisk en søster-skill).
+- Kjør hver query **N× (default 3) gjennom modellen live** og mål **trigger-rate**, ikke ja/nei. Rapporter **precision OG recall** (dagens K1 måler i praksis kun presisjon/over-trigging; recall/undertrigging er ugated).
+- **60/40 train/held-out-splitt**; velg/juster description på **held-out-score** for å unngå å overfitte teksten til eval-settet.
+- Rapporter **varians** (mean±stddev per query); flagg høy-varians-queries som flaky.
+- Mekanisme: adopter/wrap `skill-creator` `run_loop.py`, eller reimplementer i repoets `mjs`/TDD-stil (se §7 åpen beslutning).
+
+### Trinn 3 — Effekt / uplift (NY · AI-Eng)
+Svar på det rubrikken aldri svarer på: **gjør skillen output bedre enn ingen skill?**
+- For hvert eval-case: spawn **with-skill OG baseline i samme tur** (adopter `skill-creator` 3a — ikke sekvensielt).
+- Objektivt verifiserbare **assertions** der oppgaven tillater det; kvalitativ grading der den ikke gjør det (skriv aldri kunstige assertions for subjektiv kvalitet).
+- Aggregér til **pass-rate + tid + tokens med mean±stddev og delta** vs. baseline.
+- **Analyzer-pass:** flagg ikke-diskriminerende assertions (består med ELLER uten skill → måler ingenting) og høy-varians/flaky-evals.
+
+### Trinn 4 — Gate + regresjon
+- **Behavioral gate ved siden av form-gaten:** en skill-/description-/KB-endring som senker trigger-recall eller uplift-delta under terskel **feiler gaten** (i dag gates kun form via `--gate 90`).
+- **Auto re-run ved endring:** når `SKILL.md`/`description` eller rutet KB endres, re-kjør minst Trinn 1–2 (Trinn 3 er dyrere — periodisk/på forespørsel). Fjerner stale-judge-problemet (hull #4).
+- **Wire inn i `generate-skills`** (lukker hull #5): batch-genereringen kaller `validate-skill` for berørte skills, ikke bare KB-korrekthet.
+- Resultater caches med provenans (som dagens `judge-results.json` / `skill-score-report.json`), slik at Spor D-signalet og gatene leser ferske tall.
+
+---
+
+## 4. AI-Engineer-perspektivet — disiplin → hull → mekanisme
+
+| AI-Eng-prinsipp | Dagens hull | Importert mekanisme |
+|---|---|---|
+| **Evals er sannheten, ikke lint** — en komponent vurderes på målt atferd, ikke på at config er velformet | Kun form måles (#1) | Trinn 3 uplift-benchmark (`skill-creator` 3a) |
+| **Triggering = en klassifikator → mål precision OG recall, live** | K1 = judge-proxy, kun presisjon (#2) | Trinn 2 live `run_loop` (`skill-creator` 3b) |
+| **Stokastisk output → repetisjon + varians** | Judge kjøres 1×, ingen stddev (#3) | 3× repetisjon, mean±stddev, flaky-flag |
+| **Unngå overfitting til eval-settet** | Judge ser hele settet | 60/40 train/held-out, velg på test-score |
+| **Regresjonsvern i CI** | Kun form gated (#4/#5) | Behavioral gate + auto re-run, wired i `generate-skills` |
+| **Ikke-diskriminerende evals er verdiløse** | Ingen sjekk | Analyzer-pass (flagger no-op-assertions) |
+| **Én reproduserbar pipeline, ikke spredte spor** | 3–4 uavhengige spor (#6) | Samlende `validate-skill <name>` → én verdikt |
+
+---
+
+## 5. Suksesskriterier (testbare)
+
+En implementasjon av denne rutinen er ferdig når:
+
+1. `validate-skill <name>` finnes, kjører Trinn 0→4 sekvensielt, og emitterer én verdikt (PASS/NEEDS-WORK/FAIL) + rangerte forbedringspekere. **Test:** kjør mot en skill, verifiser exit-kode + strukturert output.
+2. **Trinn 2 måler live trigger-rate** (ikke judge-proxy) med **både precision og recall**, hver query kjørt ≥3×, med mean±stddev per query. **Test:** output inneholder recall-tall og stddev; en bevisst under-triggende description gir recall < terskel.
+3. **Trinn 3 produserer with-skill-vs-baseline-delta** med mean±stddev. **Test:** en skill med kjent uplift viser positiv delta; en no-op-skill viser ~0 delta og flagges av analyzer.
+4. **Behavioral gate håndhever regresjon:** en description-endring som knuser recall/uplift gir exit≠0. **Test:** injiser en dårlig description, verifiser at gaten feiler.
+5. **`generate-skills` kaller `validate-skill`** for berørte skills. **Test:** kjør batch, verifiser at valideringen trigges (ikke bare create-guard).
+6. **Alt TDD-gated:** nye moduler har failing test først; suiten (`node --test tests/kb-eval/*.test.mjs …`) grønn. **Test:** exit-kode, ikke glyph-grep.
+7. **Ingen regresjon i eksisterende Trinn 1:** dagens 5 skills scorer fortsatt ≥90 og `skill-score-report.json`-skjemaet er uendret (eller versjonert bevisst).
+
+---
+
+## 6. Non-Goals (scope-grenser)
+
+- **Ikke** endre/reforhandle Trinn 1-rubrikken (K1–N5) — det eies av Pocock-doc'et og scoring-planen.
+- **Ikke** bygge KB-korrekthets-judgen (Trinn 0 finnes; det er Spor 1 / judge v3.1-territorium).
+- **Ikke** røre Cosmo-persona eller legacy-generatorer (S-Cosmo-sporet).
+- **Ikke** auto-fikse en skill basert på eval-resultat — rutinen **måler og flagger**; menneske bekrefter og endrer (samme disiplin som «aldri auto-fiks KB»).
+- **Ikke** bestemme build-vs-adopt for `skill-creator`-verktøyene her — det er en åpen beslutning (§7), ikke en del av briefen.
+
+---
+
+## 7. Åpne beslutninger (trenger operatør)
+
+1. **Adopter vs. reimplementer `skill-creator`-verktøyene.** De er Python (`run_loop.py`, `aggregate_benchmark`); repoet er `mjs` + TDD. *Anbefaling:* wrap/adopter først for å **måle verdien** på de 5 skillene, reimplementer i `mjs` kun hvis adoptert og verdt vedlikeholdet ([[faktabasert-build-both-measure]]).
+2. **Kostnad for live triggering.** Full Trinn-2-kjøring ≈ 20 queries × 3 repetisjoner × 5 skills = ~300 live modell-kall; Trinn 3 kommer i tillegg. Pris er operatør-gated. *Anbefaling:* behold den billige K1-judge-proxyen som CI-gate hver commit; kjør de dyre live-trinnene periodisk / før release / ved description-endring.
+3. **Behold K1-proxy eller erstatt?** *Anbefaling:* behold begge — proxy = billig hyppig gate, live triggering = dypere periodisk sannhet. To signaler, ikke ett erstatter det andre.
+
+---
+
+## 8. Verifiseringslogg + løse tråder
+
+**Grunnlaget** er verifisert 2026-07-01 av to Opus-speidere mot disk (ikke STATE-påstander):
+- Rubrikk/vekter/gulv/aggregering: `scripts/kb-eval/lib/skill-score.mjs`, `eval.mjs`, `score-skill.mjs` + `tests/kb-eval/*` (invariantene asserteres).
+- K1-metoden: `judge-prompt.md` + `data/k1-trigger-prompts.json` + `data/judge-results.json` (alle 5 precision 1.0).
+- `skill-creator`-rutinen: `plugins/skill-creator/skills/skill-creator/SKILL.md` §163–404 (effekt-eval + triggering-optimizer).
+- Roadmap-hullet: `docs/skill-quality-scoring-plan.md` §Fase 2 + `docs/skill-eval-routine-improvement-2026-06.md`.
+
+**Løse tråder å adressere i planen (ikke her):**
+- **Doc-drift:** `skill-quality-scoring-plan.md` §2-tabellen lister fortsatt **K8**; koden har erstattet K8 med den deterministiske **CT5**. Koden er kilden; planen bør oppdateres.
+- **Git-inkonsistens:** `skill-score-report.json` er både `.gitignore`-matchet OG faktisk tracked (committet før den ble ignorert). Hook-kommentaren i `session-start-context.mjs` antar «gitignored ⇒ fraværende i fresh clone» — som ikke stemmer. Trivielt, men verdt å rydde når rutinen røres.
+
+**Neste steg:** operatør-review av denne briefen → `/trekplan --brief docs/skill-validation-routine-brief-2026-07.md` for implementeringsplan (TDD-gated, sesjons-dekomponert).

docs/spor1-authority-selection.md

@@ -0,0 +1,202 @@
+# Spor 1 — Authority-URL-valg per reference-fil (Step 6 audit-logg)
+
+**Type:** methodology
+**Status:** Stable
+**Kategori:** Spor 1 korpus-migrering
+**Sist oppdatert:** 2026-07-04
+**Produsert av:** trekexecute Session 2, Step 6 (to-lags hovedkontekst — operatørvalg 2026-07-04)
+
+---
+
+Denne loggen dokumenterer valget av **THE authority `learn.microsoft.com`-URL** per non-advisor `reference`-fil, persistert som `source` i `scripts/kb-update/data/ref-type-manifest.json` (gitignored/regenererbar; den varige posten er denne loggen + `**Source:**`-headerne Step 9 stempler). Metode: **deterministiske tie-breaks først** (single citation → concept/overview over how-to → mest-sitert i korpus), deretter **hovedkontekst-vurdering** for gjenstående likestilte kandidater. Ingen gjetning: en fil uten forsvarlig MS-autoritet settes `deferred:true` (defer-not-guess, jf. `authority.mjs`).
+
+## Sammendrag
+
+| Bøtte | Antall | Metode |
+|---|---:|---|
+| Sourced (non-advisor reference) | 243 | header 6 · concept 64 · most-cited 141 · top-score 1 · residual-judgment 31 |
+| Deferred — ingen MS-sitering | 59 | `no-ms-citation` (typet reference på innhold i Step 4, men siterer 0 `learn.microsoft.com`-URL) |
+| Deferred — advisor-scope | 50 | `advisor-scope` (utenfor Step 6 sitt non-advisor-mandat; aldri mutert av applier; S-Cosmo) |
+| **Sum reference-entries** | **352** | |
+
+### Premiss-korreksjoner mot plan-estimatene (verifisert mot manifest, 2026-07-04)
+
+- Planen anslo «~253 reference / ~246 uten source». Ground truth: **302 non-advisor reference** (+ 50 advisor reference = 352 totalt).
+- Planen sa «7 filer har allerede `**Source:**`». Ground truth: **6** (header-metoden under).
+- **Advisor-håndtering (scope-avgjørelse):** Step 6-teksten scoper til «non-advisor», men Verify-predikatet skanner ALLE reference-entries. De 50 advisor reference-entriene settes derfor `deferred:true` (`advisor-scope`) — ikke gjettede kilder — så predikatet holder uten å utvide arbeidet inn på advisor-flaten (som uansett aldri muteres og er merket for Cosmo-fjerning).
+
+## Hovedkontekst-adjudikasjon — 31 residual-likestillinger
+
+Disse hadde flere kandidater likestilt på både score og korpus-sitering. Valgt URL er den primær-tema-kanoniske autoriteten, plukket FRA filens egen siteringsmengde (skriptet asserterer medlemskap).
+
+| Fil | Valgt authority | Begrunnelse |
+|---|---|---|
+| ms-ai-engineering / agent-orchestration/agent-365-governance-and-deployment.md | https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint | M365 agents blueprint governs deployment |
+| ms-ai-engineering / agent-orchestration/agent-memory-and-context-management.md | https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory | canonical "what is memory" for Foundry agents |
+| ms-ai-engineering / agent-orchestration/semantic-kernel-agents-implementation.md | https://learn.microsoft.com/agent-framework/overview/agent-framework-overview | Agent Framework overview = authoritative agent-implementation entry |
+| ms-ai-engineering / azure-ai-services/ai-services-api-best-practices.md | https://learn.microsoft.com/azure/architecture/patterns/rate-limiting-pattern | rate-limiting architecture pattern anchors API resilience best-practices |
+| ms-ai-engineering / azure-ai-services/document-intelligence-custom-models.md | https://learn.microsoft.com/azure/ai-services/document-intelligence/train/custom-model | parent custom-model doc (sub-types derive from it) |
+| ms-ai-engineering / azure-ai-services/language-services-question-answering.md | https://learn.microsoft.com/azure/ai-services/language-service/question-answering/overview | question-answering overview is the canonical entry |
+| ms-ai-engineering / azure-ai-services/translator-custom-neural-models.md | https://learn.microsoft.com/azure/ai-services/translator/custom-translator/overview | custom-translator overview is the canonical entry |
+| ms-ai-engineering / azure-ai-services/translator-document-translation.md | https://learn.microsoft.com/azure/ai-services/translator/document-translation/overview | document-translation overview (on-topic) over the generic translator overview |
+| ms-ai-engineering / data-engineering/cross-cloud-data-integration.md | https://learn.microsoft.com/fabric/governance/external-data-sharing-overview | external data sharing = cross-cloud integration authority |
+| ms-ai-engineering / data-engineering/data-sampling-labeling.md | https://learn.microsoft.com/azure/machine-learning/how-to-label-data | canonical data-labeling doc (all-howto pool) |
+| ms-ai-engineering / data-engineering/data-versioning-lineage.md | https://learn.microsoft.com/fabric/governance/lineage | Fabric governance lineage = canonical lineage authority |
+| ms-ai-engineering / data-engineering/microsoft-purview-governance.md | https://learn.microsoft.com/purview/unified-catalog | Purview Unified Catalog is the governance hub |
+| ms-ai-engineering / data-engineering/real-time-streaming-ai.md | https://learn.microsoft.com/fabric/real-time-intelligence/overview | broadest Real-Time Intelligence overview |
+| ms-ai-engineering / data-engineering/zero-etl-fabric-patterns.md | https://learn.microsoft.com/fabric/mirroring/overview | Fabric mirroring = zero-ETL authority |
+| ms-ai-engineering / mlops-genaiops/mlops-security-access-control.md | https://learn.microsoft.com/azure/machine-learning/concept-enterprise-security | ML enterprise-security concept anchors access-control |
+| ms-ai-engineering / rag-architecture/contextual-retrieval.md | https://learn.microsoft.com/azure/search/cognitive-search-custom-skill-interface | current custom-skill interface over the previous-versions variant |
+| ms-ai-engineering / rag-architecture/metadata-management-filtering.md | https://learn.microsoft.com/azure/search/search-what-is-an-index | index schema is the root authority for filterable metadata |
+| ms-ai-governance / monitoring-observability/alerting-strategies-escalation.md | https://learn.microsoft.com/azure/azure-monitor/alerts/best-practices-alerts | alerts best-practices = alerting-strategy authority |
+| ms-ai-governance / monitoring-observability/distributed-tracing-ai-pipelines.md | https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-overview | OpenTelemetry overview = distributed-tracing authority |
+| ms-ai-governance / monitoring-observability/observability-for-copilot-extensions.md | https://learn.microsoft.com/microsoft-cloud/dev/copilot/isv/observability-for-ai | directly "observability for AI" (Copilot ISV) |
+| ms-ai-governance / norwegian-public-sector-governance/accessibility-requirements-wcag-norway.md | https://learn.microsoft.com/compliance/regulatory/offering-wcag-2-1 | WCAG 2.1 compliance offering = accessibility authority |
+| ms-ai-governance / norwegian-public-sector-governance/digdir-ai-governance-structure.md | https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/govern | CAF AI Govern = canonical AI-governance authority |
+| ms-ai-governance / norwegian-public-sector-governance/digital-accessibility-action-plan.md | https://learn.microsoft.com/compliance/regulatory/offering-wcag-2-1 | WCAG 2.1 compliance offering = accessibility standards authority |
+| ms-ai-governance / norwegian-public-sector-governance/ros-analyse-ai-systems.md | https://learn.microsoft.com/azure/well-architected/security/threat-model | Well-Architected threat-model = risk-analysis authority |
+| ms-ai-infrastructure / bcdr/compliance-requirements-bcdr.md | https://learn.microsoft.com/azure/compliance | Azure compliance hub = compliance-requirements authority |
+| ms-ai-infrastructure / bcdr/data-replication-patterns-ai.md | https://learn.microsoft.com/azure/reliability/concept-redundancy-replication-backup | reliability redundancy/replication concept = replication-patterns authority |
+| ms-ai-infrastructure / bcdr/network-resilience-patterns-ai.md | https://learn.microsoft.com/azure/ddos-protection/ddos-protection-overview | DDoS protection = primary network-resilience authority in pool |
+| ms-ai-security / ai-security-engineering/entra-agent-id-zero-trust.md | https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview | Entra Agent ID governance overview (directly on-topic) |
+| ms-ai-security / ai-security-engineering/zero-trust-ai-services.md | https://learn.microsoft.com/security/zero-trust/apply-zero-trust-azure-services-overview | apply Zero Trust to Azure services overview = canonical |
+| ms-ai-security / cost-optimization/licensing-compliance-cost-avoidance.md | https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/plan | CAF AI Plan = broad licensing/cost authority |
+| ms-ai-security / performance-scalability/rate-limit-management.md | https://learn.microsoft.com/azure/foundry/openai/quotas-limits | Azure OpenAI quotas-limits = rate-limit authority |
+
+## Deterministisk-løste (212)
+
+**Header (beholdt eksisterende `**Source:**`, 6):**
+
+- ms-ai-engineering / rag-architecture/late-chunking-patterns.md → https://learn.microsoft.com/azure/foundry/openai/tutorials/embeddings
+- ms-ai-security / ai-security-engineering/ai-red-team-operations-practical.md → https://learn.microsoft.com/security/ai-red-team/training
+- ms-ai-security / cost-optimization/batch-processing-cost-reduction.md → https://learn.microsoft.com/azure/foundry/openai/how-to/batch
+- ms-ai-security / cost-optimization/model-selection-price-performance.md → https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
+- ms-ai-security / cost-optimization/ptu-vs-paygo-economics.md → https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput
+- ms-ai-security / performance-scalability/batch-api-usage-optimization.md → https://learn.microsoft.com/azure/foundry/openai/how-to/batch-blob-storage
+
+**Deterministiske tie-breaks (206):** single/concept/top-score/most-cited — full liste i manifestets `authorityMethod`-felt per entry. Metode-fordeling over.
+
+## Deferred — ingen MS-sitering (59, `unsourced`-bøtte)
+
+Reference-typet på innhold (Step 4), men uten inline `learn.microsoft.com`-sitering å binde autoritet til. Ingen gjetning — corpus judge-pass (neste brief) henter + verifiserer + kilde-setter disse.
+
+- ms-ai-engineering / agent-orchestration/agent-compliance-and-audit-trails.md
+- ms-ai-engineering / agent-orchestration/agent-cost-optimization-strategies.md
+- ms-ai-engineering / agent-orchestration/agent-ecosystem-and-plugin-marketplace.md
+- ms-ai-engineering / agent-orchestration/agent-feedback-and-learning-loops.md
+- ms-ai-engineering / agent-orchestration/agent-latency-optimization.md
+- ms-ai-engineering / agent-orchestration/agent-monitoring-observability.md
+- ms-ai-engineering / agent-orchestration/agent-routing-and-specialization.md
+- ms-ai-engineering / agent-orchestration/agent-security-threat-modeling.md
+- ms-ai-engineering / agent-orchestration/copilot-agent-integration-patterns.md
+- ms-ai-engineering / agent-orchestration/declarative-vs-imperative-agent-design.md
+- ms-ai-engineering / agent-orchestration/multi-tenant-agent-isolation.md
+- ms-ai-engineering / api-management/circuit-breaker-ai-resilience.md
+- ms-ai-engineering / api-management/load-balancing-openai-instances.md
+- ms-ai-engineering / api-management/semantic-caching-apim.md
+- ms-ai-engineering / api-management/token-rate-limiting-policies.md
+- ms-ai-engineering / multi-modal/accessibility-multimodal-ai.md
+- ms-ai-engineering / multi-modal/audio-video-transcription-workflow.md
+- ms-ai-engineering / multi-modal/azure-video-indexer-patterns.md
+- ms-ai-engineering / multi-modal/cv-llm-integration.md
+- ms-ai-engineering / multi-modal/dalle-image-generation.md
+- ms-ai-engineering / multi-modal/document-vision-processing.md
+- ms-ai-engineering / multi-modal/gpt4o-vision-architecture.md
+- ms-ai-engineering / multi-modal/image-classification-understanding.md
+- ms-ai-engineering / multi-modal/multimodal-content-safety.md
+- ms-ai-engineering / multi-modal/multimodal-evaluation-metrics.md
+- ms-ai-engineering / multi-modal/multimodal-prompt-engineering.md
+- ms-ai-engineering / multi-modal/multimodal-rag-architecture.md
+- ms-ai-engineering / multi-modal/ocr-pipeline-architecture.md
+- ms-ai-engineering / multi-modal/real-time-audio-api.md
+- ms-ai-engineering / multi-modal/speech-to-ai-pipelines.md
+- ms-ai-engineering / multi-modal/text-to-speech-citizen.md
+- ms-ai-engineering / multi-modal/video-analysis-patterns.md
+- ms-ai-engineering / multi-modal/whisper-speech-recognition.md
+- ms-ai-governance / monitoring-observability/application-insights-llm-monitoring.md
+- ms-ai-governance / monitoring-observability/azure-monitor-setup-ai-workloads.md
+- ms-ai-governance / norwegian-public-sector-governance/norwegian-nlp-benchmarks.md
+- ms-ai-governance / responsible-ai/ai-act-microsoft-tools-mapping.md
+- ms-ai-infrastructure / hybrid-edge/azure-arc-ai-management.md
+- ms-ai-infrastructure / hybrid-edge/azure-confidential-computing-ai.md
+- ms-ai-infrastructure / hybrid-edge/azure-iot-hub-ai-pipeline.md
+- ms-ai-infrastructure / hybrid-edge/azure-local-ai-workloads.md
+- ms-ai-infrastructure / hybrid-edge/data-sovereignty-norway-public-sector.md
+- ms-ai-infrastructure / hybrid-edge/edge-ai-inferencing-patterns.md
+- ms-ai-infrastructure / hybrid-edge/edge-to-cloud-data-synchronization.md
+- ms-ai-infrastructure / hybrid-edge/hybrid-rag-architecture.md
+- ms-ai-infrastructure / hybrid-edge/iot-operations-ai-integration.md
+- ms-ai-infrastructure / hybrid-edge/kubernetes-edge-aks-edge.md
+- ms-ai-infrastructure / hybrid-edge/network-constrained-ai-deployment.md
+- ms-ai-infrastructure / hybrid-edge/offline-first-ai-applications.md
+- ms-ai-infrastructure / hybrid-edge/on-premises-slm-phi-deployment.md
+- ms-ai-infrastructure / hybrid-edge/onnx-runtime-edge-deployment.md
+- ms-ai-infrastructure / hybrid-edge/regulatory-compliance-edge-ai.md
+- ms-ai-infrastructure / hybrid-edge/sovereign-cloud-norway.md
+- ms-ai-infrastructure / hybrid-edge/windows-ai-apc-capabilities.md
+- ms-ai-security / ai-security-engineering/secure-model-deployment-hardening.md
+- ms-ai-security / performance-scalability/auto-scaling-ai-infrastructure.md
+- ms-ai-security / performance-scalability/cdn-edge-caching-ai.md
+- ms-ai-security / performance-scalability/latency-optimization-azure-openai.md
+- ms-ai-security / performance-scalability/streaming-response-patterns.md
+
+## Deferred — advisor-scope (50)
+
+Advisor reference-entries. Utenfor Step 6 sitt non-advisor-mandat; applier (Step 9) muterer dem aldri (hard advisor-fence). Kilde-valg utsatt (evt. mooted av Cosmo-fjerning R13/R14).
+
+- ms-ai-advisor / architecture/cost-models.md
+- ms-ai-advisor / architecture/licensing-matrix.md
+- ms-ai-advisor / architecture/migration-patterns.md
+- ms-ai-advisor / architecture/regional-availability-verification.md
+- ms-ai-advisor / architecture/security.md
+- ms-ai-advisor / copilot-extensibility/adaptive-cards-copilot-responses.md
+- ms-ai-advisor / copilot-extensibility/copilot-analytics-and-usage-insights.md
+- ms-ai-advisor / copilot-extensibility/copilot-api-rate-limiting-resilience.md
+- ms-ai-advisor / copilot-extensibility/copilot-connectors-design-patterns.md
+- ms-ai-advisor / copilot-extensibility/copilot-context-window-optimization.md
+- ms-ai-advisor / copilot-extensibility/copilot-dlp-and-governance.md
+- ms-ai-advisor / copilot-extensibility/copilot-extensibility-security-patterns.md
+- ms-ai-advisor / copilot-extensibility/copilot-orchestration-multi-agent.md
+- ms-ai-advisor / copilot-extensibility/copilot-prompt-engineering-governance.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-localization-globalization.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-nlp-configuration.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-topics-and-entities.md
+- ms-ai-advisor / copilot-extensibility/custom-engine-agents-development.md
+- ms-ai-advisor / copilot-extensibility/declarative-agents-fundamentals.md
+- ms-ai-advisor / copilot-extensibility/declarative-agents-grounding-strategies.md
+- ms-ai-advisor / copilot-extensibility/enterprise-governance-copilot-deployment.md
+- ms-ai-advisor / copilot-extensibility/m365-copilot-plugins-ecosystem.md
+- ms-ai-advisor / copilot-extensibility/mcp-protocol-copilot-studio.md
+- ms-ai-advisor / copilot-extensibility/microsoft-graph-api-copilot-integration.md
+- ms-ai-advisor / copilot-extensibility/power-automate-copilot-integration.md
+- ms-ai-advisor / copilot-extensibility/sharepoint-copilot-agents.md
+- ms-ai-advisor / copilot-extensibility/teams-copilot-message-extensions.md
+- ms-ai-advisor / development/agent-framework.md
+- ms-ai-advisor / platforms/azure-ai-foundry.md
+- ms-ai-advisor / platforms/copilot-studio.md
+- ms-ai-advisor / platforms/m365-copilot.md
+- ms-ai-advisor / platforms/model-catalog-2026.md
+- ms-ai-advisor / platforms/power-platform.md
+- ms-ai-advisor / prompt-engineering/adversarial-prompting-and-jailbreaks.md
+- ms-ai-advisor / prompt-engineering/chain-of-thought-prompting.md
+- ms-ai-advisor / prompt-engineering/domain-specific-prompt-optimization.md
+- ms-ai-advisor / prompt-engineering/error-handling-and-fallback-prompting.md
+- ms-ai-advisor / prompt-engineering/few-shot-learning-techniques.md
+- ms-ai-advisor / prompt-engineering/function-calling-and-tool-use.md
+- ms-ai-advisor / prompt-engineering/grounding-and-knowledge-injection.md
+- ms-ai-advisor / prompt-engineering/multi-turn-conversation-management.md
+- ms-ai-advisor / prompt-engineering/multimodal-prompt-design.md
+- ms-ai-advisor / prompt-engineering/prompt-testing-and-evaluation.md
+- ms-ai-advisor / prompt-engineering/real-time-reasoning-performance.md
+- ms-ai-advisor / prompt-engineering/reasoning-models-o1-o3-optimization.md
+- ms-ai-advisor / prompt-engineering/role-playing-and-persona-techniques.md
+- ms-ai-advisor / prompt-engineering/structured-output-formatting.md
+- ms-ai-advisor / prompt-engineering/system-message-design-patterns.md
+- ms-ai-advisor / prompt-engineering/temperature-sampling-and-parameters.md
+- ms-ai-advisor / prompt-engineering/token-optimization-and-efficiency.md
+
+## Reproduserbarhet
+
+- Deterministiske valg reproduseres av `scripts/kb-update/lib/url-normalize.extractUrls` + tie-break-reglene over mot samme korpus + `url-registry.json`.
+- De 31 residual-valgene er menneske-adjudikert (låst i denne loggen + manifestets `authorityMethod:"residual-judgment"` + `authoritySelectedBy`).
+- Manifestet er gitignored (regenererbart); den varige autoritetsposten er denne loggen og — etter Step 9 — `**Source:**`-headerne i korpuset.

docs/spor1-classification-review.md

@@ -0,0 +1,136 @@
+# Spor 1 — Edge-Set Classification Review (Step 4)
+
+**Date:** 2026-07-03
+**Scope:** every manifest entry flagged `reviewFlag:true` by the mechanical classifier (106 of 389)
+**Mechanism:** main-context executor content review, two tiers — (1) title + section headings + intro per file, (2) full-text sampling where tier 1 was inconclusive (6 files). The plan prescribed read-only subagent fan-out; the executor's Agent tool is disabled during plan execution (trekexecute Hard Rule 10), so adjudication ran in the main context against the same criteria. Recorded as `resolvedBy: executor-content-review-2026-07-03`.
+
+## Criteria (Port-1 closed type set)
+
+- **reference** — dominant substance is machine-verifiable Microsoft product/service claims (verifiable against learn.microsoft.com); will carry a `**Source:**` URL.
+- **template** — reusable fill-in scaffold; must never carry an MS source.
+- **methodology** — reusable process/framework guidance; must never carry an MS source.
+- **regulatory** — law/standard text or obligations derived directly from it.
+
+Judged by content substance, not filename. No file was deferred — every flagged file had a defensible type.
+
+## Outcome
+
+Resolved: **106/106** (0 deferred). Distribution within the edge set: {"template":8,"methodology":20,"reference":69,"regulatory":9}.
+Corpus-wide (389): reference 352 · methodology 20 · regulatory 9 · template 8.
+
+Notable calls:
+- `ms-ai-advisor/development/agent-framework.md` → **reference** (pure MS API fact base; the path heuristic tripped on 'framework').
+- `responsible-ai/ai-ethics-in-public-sector.md` → **reference** (substance = MS RAI standard + Foundry capabilities) while `norwegian-public-sector-governance/public-sector-ai-ethics-framework.md` → **methodology** (substance = Norwegian governance landscape). Same theme, different dominant substance.
+- `norwegian-public-sector-governance/norwegian-nlp-benchmarks.md` → **reference** with zero MS citations — expected to land in the honest `unsourced/deferred` bucket in Step 6.
+- The 67 zero-MS engineering/infrastructure files (multi-modal, hybrid-edge, api-management, agent-orchestration, performance-scalability) are Azure product-fact files written without citations — all **reference**; Step 6 will defer them unless a defensible MS authority exists.
+
+## Per-file adjudication
+
+| File (under skills/) | Type | Classifier signal | Rationale |
+|---|---|---|---|
+| `ms-ai-advisor/references/architecture/adr-template.md` | template | ms-citation+path-conflict | MADR fill-in scaffold; MS citations are illustrative |
+| `ms-ai-advisor/references/architecture/ai-utredning-template.md` | template | ms-citation+path-conflict | utredningsmal (fill-in document skeleton) grounded in utredningsinstruksen |
+| `ms-ai-advisor/references/architecture/alternativanalyse-methodology.md` | methodology | path-heuristic | weighted MCA scoring process for architecture comparison |
+| `ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md` | methodology | path-heuristic | feasibility assessment framework (gap matrices, timeline validation) |
+| `ms-ai-advisor/references/architecture/decision-trees.md` | methodology | path-heuristic | platform decision frameworks; embedded MS facts are supporting |
+| `ms-ai-advisor/references/architecture/diagram-prompt-templates.md` | template | path-heuristic | prompt templates for Imagen 3 diagram generation |
+| `ms-ai-advisor/references/architecture/poc-template.md` | template | ms-citation+path-conflict | POC plan/rubric/checklist scaffolds |
+| `ms-ai-advisor/references/architecture/public-sector-checklist.md` | template | ms-citation+path-conflict | comprehensive fill-in checklist for public-sector adoption |
+| `ms-ai-advisor/references/architecture/rag-maturity-model.md` | methodology | path-heuristic | maturity model + level-selection decision framework |
+| `ms-ai-advisor/references/architecture/recommended-mcp-servers.md` | methodology | path-heuristic | advisory tool-selection guidance with matrix |
+| `ms-ai-advisor/references/architecture/source-traceability-assumption-register.md` | methodology | path-heuristic | traceability/assumption-register process framework |
+| `ms-ai-advisor/references/development/agent-framework.md` | reference | ms-citation+path-conflict | MS Agent Framework API facts, verified against MS Learn |
+| `ms-ai-advisor/references/prompt-engineering/regulatory-and-compliance-prompting.md` | methodology | ms-citation+path-conflict | reusable compliance-aware prompting patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-compliance-and-audit-trails.md` | reference | path-heuristic | Azure agent audit/compliance product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-cost-optimization-strategies.md` | reference | path-heuristic | Foundry/Azure cost-optimization product facts |
+| `ms-ai-engineering/references/agent-orchestration/agent-ecosystem-and-plugin-marketplace.md` | reference | path-heuristic | agent ecosystem/marketplace platform patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md` | reference | ms-citation+path-conflict | Azure AI Evaluation SDK facts (GA/Preview status) |
+| `ms-ai-engineering/references/agent-orchestration/agent-feedback-and-learning-loops.md` | reference | path-heuristic | Foundry continuous-evaluation product facts |
+| `ms-ai-engineering/references/agent-orchestration/agent-latency-optimization.md` | reference | path-heuristic | Azure agent latency/performance product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-monitoring-observability.md` | reference | path-heuristic | Azure tracing/observability product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-routing-and-specialization.md` | reference | path-heuristic | Semantic Kernel/Azure routing product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-security-threat-modeling.md` | reference | path-heuristic | Azure agent security product patterns |
+| `ms-ai-engineering/references/agent-orchestration/copilot-agent-integration-patterns.md` | reference | path-heuristic | Copilot Studio integration product facts |
+| `ms-ai-engineering/references/agent-orchestration/declarative-vs-imperative-agent-design.md` | reference | path-heuristic | MS agent-platform design tradeoff facts |
+| `ms-ai-engineering/references/agent-orchestration/multi-tenant-agent-isolation.md` | reference | path-heuristic | Azure OpenAI isolation model facts |
+| `ms-ai-engineering/references/api-management/circuit-breaker-ai-resilience.md` | reference | path-heuristic | APIM circuit-breaker configuration facts |
+| `ms-ai-engineering/references/api-management/load-balancing-openai-instances.md` | reference | path-heuristic | APIM backend-pool/load-balancing facts |
+| `ms-ai-engineering/references/api-management/semantic-caching-apim.md` | reference | path-heuristic | APIM semantic-caching policy facts |
+| `ms-ai-engineering/references/api-management/token-rate-limiting-policies.md` | reference | path-heuristic | APIM token-rate-limit policy facts |
+| `ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md` | reference | ms-citation+path-conflict | MS data-quality tooling (Purview/Fabric) facts |
+| `ms-ai-engineering/references/mlops-genaiops/model-evaluation-frameworks.md` | reference | ms-citation+path-conflict | Azure ML/Foundry evaluation tooling facts |
+| `ms-ai-engineering/references/multi-modal/accessibility-multimodal-ai.md` | reference | path-heuristic | Azure AI accessibility product facts (WCAG tooling) |
+| `ms-ai-engineering/references/multi-modal/audio-video-transcription-workflow.md` | reference | path-heuristic | Azure Speech batch-transcription product facts |
+| `ms-ai-engineering/references/multi-modal/azure-video-indexer-patterns.md` | reference | path-heuristic | Azure Video Indexer product facts |
+| `ms-ai-engineering/references/multi-modal/cv-llm-integration.md` | reference | path-heuristic | Azure vision+LLM integration product facts |
+| `ms-ai-engineering/references/multi-modal/dalle-image-generation.md` | reference | path-heuristic | Azure OpenAI DALL-E product facts |
+| `ms-ai-engineering/references/multi-modal/document-vision-processing.md` | reference | path-heuristic | Document Intelligence product facts |
+| `ms-ai-engineering/references/multi-modal/gpt4o-vision-architecture.md` | reference | path-heuristic | GPT-4o vision capability/token-model facts |
+| `ms-ai-engineering/references/multi-modal/image-classification-understanding.md` | reference | path-heuristic | Azure vision model selection/training facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-content-safety.md` | reference | path-heuristic | Azure AI Content Safety product facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-evaluation-metrics.md` | reference | path-heuristic | multimodal evaluation metric/tooling facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-prompt-engineering.md` | reference | path-heuristic | multimodal prompting capability facts (GPT-4o) |
+| `ms-ai-engineering/references/multi-modal/multimodal-rag-architecture.md` | reference | path-heuristic | Azure multimodal embedding/RAG product facts |
+| `ms-ai-engineering/references/multi-modal/ocr-pipeline-architecture.md` | reference | path-heuristic | Azure OCR engine/pipeline product facts |
+| `ms-ai-engineering/references/multi-modal/real-time-audio-api.md` | reference | path-heuristic | Azure OpenAI Realtime API product facts |
+| `ms-ai-engineering/references/multi-modal/speech-to-ai-pipelines.md` | reference | path-heuristic | Azure Speech recognition pipeline facts |
+| `ms-ai-engineering/references/multi-modal/text-to-speech-citizen.md` | reference | path-heuristic | Azure neural TTS product facts |
+| `ms-ai-engineering/references/multi-modal/video-analysis-patterns.md` | reference | path-heuristic | Azure video analysis product facts |
+| `ms-ai-engineering/references/multi-modal/whisper-speech-recognition.md` | reference | path-heuristic | Whisper on Azure product facts |
+| `ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md` | reference | ms-citation+path-conflict | RAG evaluation tooling/SDK facts |
+| `ms-ai-governance/references/monitoring-observability/application-insights-llm-monitoring.md` | reference | path-heuristic | Application Insights LLM telemetry facts |
+| `ms-ai-governance/references/monitoring-observability/azure-monitor-setup-ai-workloads.md` | reference | path-heuristic | Azure Monitor configuration facts (Portal/PS/CLI) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md` | methodology | ms-citation+path-conflict | procurement process framework (lovgrunnlag + DFØ + SSA) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` | methodology | ms-citation+path-conflict | Datatilsynet DPIA process methodology for AI |
+| `ms-ai-governance/references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md` | methodology | path-heuristic | DFØ 5-step benefit-realization process |
+| `ms-ai-governance/references/norwegian-public-sector-governance/norwegian-nlp-benchmarks.md` | reference | path-heuristic | factual benchmark/model-comparison content; no MS authority → expected unsourced/deferred in Step 6 |
+| `ms-ai-governance/references/norwegian-public-sector-governance/public-sector-ai-ethics-framework.md` | methodology | ms-citation+path-conflict | Norwegian ethics governance landscape/framework guidance |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md` | methodology | path-heuristic | reusable AI threat catalog for ROS assessment (OWASP-anchored) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-dpia-security-integration.md` | methodology | path-heuristic | assessment sequencing/integration process guide |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-maestro-multiagent.md` | methodology | path-heuristic | MAESTRO 7-layer assessment framework + checklist |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md` | regulatory | path-heuristic | NS 5814/ISO 31000/ISO 23894/AI Act Art.9 standard-text mapping |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md` | template | path-heuristic | Quick/Full ROS report fill-in scaffolds |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md` | methodology | path-heuristic | 7x5 scoring rubric framework for ROS |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md` | template | path-heuristic | sector fill-in checklists (helse/transport/finans/...) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md` | methodology | path-heuristic | NNV/samfunnsøkonomisk analysis process (DFØ) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/statistical-ethics-ssa-methodology.md` | methodology | ms-citation+path-conflict | SSB statistical-ethics application methodology |
+| `ms-ai-governance/references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md` | methodology | ms-citation+path-conflict | utredningsinstruksen applied as AI assessment process |
+| `ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` | regulatory | ms-citation+path-conflict | Annex III high-risk categories/checkpoints (obligations from the Act) |
+| `ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` | regulatory | path-heuristic | classification per the Act’s own rules (Annex III, provider/deployer roles) |
+| `ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` | regulatory | ms-citation+path-conflict | the Act’s risk classes + obligations are the substance; MS tooling is a section |
+| `ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` | regulatory | path-heuristic | Art. 43/47 + Annex IV conformity obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` | regulatory | path-heuristic | Art. 26/27 deployer obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` | template | path-heuristic | FRIA fill-in scaffold (7 sections) grounded in Art. 27 |
+| `ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` | reference | path-heuristic | MS tool capabilities mapped to AI Act articles (Purview/Compliance Manager facts) |
+| `ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` | regulatory | path-heuristic | Art. 9–15 provider obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` | regulatory | path-heuristic | Art. 13/50 transparency obligations (maler secondary) |
+| `ms-ai-governance/references/responsible-ai/ai-ethics-in-public-sector.md` | reference | ms-citation+path-conflict | MS RAI standard + Foundry capability facts are the substance |
+| `ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md` | methodology | ms-citation+path-conflict | organizational governance framework guidance |
+| `ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` | methodology | ms-citation+path-conflict | impact assessment process framework |
+| `ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` | regulatory | ms-citation+path-conflict | GDPR obligations applied to AI systems |
+| `ms-ai-governance/references/responsible-ai/model-explainability-interpretability.md` | reference | ms-citation+path-conflict | Azure ML RAI dashboard/InterpretML product facts dominate |
+| `ms-ai-governance/references/responsible-ai/responsible-ai-framework-overview.md` | reference | ms-citation+path-conflict | Microsoft RAI framework facts, MS-verifiable |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-arc-ai-management.md` | reference | path-heuristic | Azure Arc product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-confidential-computing-ai.md` | reference | path-heuristic | Azure Confidential Computing product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-iot-hub-ai-pipeline.md` | reference | path-heuristic | Azure IoT Hub product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-local-ai-workloads.md` | reference | path-heuristic | Azure Local product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/data-sovereignty-norway-public-sector.md` | reference | path-heuristic | Azure data residency/EUDB/sovereign cloud facts |
+| `ms-ai-infrastructure/references/hybrid-edge/edge-ai-inferencing-patterns.md` | reference | path-heuristic | edge inference product patterns (IoT Edge, quantization) |
+| `ms-ai-infrastructure/references/hybrid-edge/edge-to-cloud-data-synchronization.md` | reference | path-heuristic | edge-cloud sync product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/hybrid-rag-architecture.md` | reference | path-heuristic | hybrid RAG architecture product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/iot-operations-ai-integration.md` | reference | path-heuristic | Azure IoT Operations product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/kubernetes-edge-aks-edge.md` | reference | path-heuristic | AKS Edge Essentials product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/network-constrained-ai-deployment.md` | reference | path-heuristic | constrained-network deployment product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/offline-first-ai-applications.md` | reference | path-heuristic | offline-first AI application product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/on-premises-slm-phi-deployment.md` | reference | path-heuristic | Phi-3/Phi-4 on-prem deployment facts |
+| `ms-ai-infrastructure/references/hybrid-edge/onnx-runtime-edge-deployment.md` | reference | path-heuristic | ONNX Runtime product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/regulatory-compliance-edge-ai.md` | reference | path-heuristic | MS compliance tooling for edge (Arc/Purview/Defender/Compliance Manager) is the substance |
+| `ms-ai-infrastructure/references/hybrid-edge/sovereign-cloud-norway.md` | reference | path-heuristic | MS sovereign cloud capability facts |
+| `ms-ai-infrastructure/references/hybrid-edge/windows-ai-apc-capabilities.md` | reference | path-heuristic | Windows ML/NPU/Copilot+ PC facts |
+| `ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` | reference | ms-citation+path-conflict | documents Microsoft’s AI Risk Assessment Framework (MS-verifiable) |
+| `ms-ai-security/references/ai-security-engineering/secure-model-deployment-hardening.md` | reference | path-heuristic | Azure ML/ACR/Defender/Key Vault hardening facts |
+| `ms-ai-security/references/performance-scalability/auto-scaling-ai-infrastructure.md` | reference | path-heuristic | Azure Container Apps scaling facts |
+| `ms-ai-security/references/performance-scalability/cdn-edge-caching-ai.md` | reference | path-heuristic | Azure Front Door/CDN product facts |
+| `ms-ai-security/references/performance-scalability/latency-optimization-azure-openai.md` | reference | path-heuristic | Azure OpenAI latency optimization facts |
+| `ms-ai-security/references/performance-scalability/performance-benchmarking-frameworks.md` | reference | ms-citation+path-conflict | azure-openai-benchmark/Azure Load Testing/Foundry eval facts |
+| `ms-ai-security/references/performance-scalability/streaming-response-patterns.md` | reference | path-heuristic | SSE/streaming implementation facts for Azure OpenAI |

docs/spor1-migration-outcome.md

@@ -0,0 +1,91 @@
+# Spor 1 — Corpus-migrasjon: utfall og policy-delta (R4, Steg 9–11)
+
+_Datert 2026-07-04. Kilde: `migrate-corpus.mjs --write` over de 4 ikke-advisor-skills +
+`build-registry --merge` → `score-skill --write` → `report-full-pass-worklist`._
+
+Denne noten registrerer det målte utfallet av Port-1-substrat-migrasjonen (Type/Source/TOC
++ stale-verified-fjerning) og skiller **verifisert** fra **antatt**, per verifiseringsplikten.
+
+## Hva migrasjonen gjorde (verifisert mot ground truth)
+
+| Felt | Antall | Kilde |
+|------|--------|-------|
+| Filer mutert (ikke-advisor) | 327 / 327 | applier-output + `git diff --name-only` |
+| `**Type:**` stemplet | 327 | manifest (alle typer) |
+| `**Source:**` backfilt | 243 | manifest (sourced reference; deferred = ingen source) |
+| `## Innhold` TOC innsatt | 325 | store filer (≥100 linjer) |
+| stale `**Verified:** MCP` fjernet | 14 header + 9 body-dup (i 500B-vinduet) | normalizer + parser |
+| advisor-filer rørt | 0 | `git diff --stat -- skills/ms-ai-advisor/` |
+| prosa-kropper endret (fra første `##`) | 0 | per-fil `git show HEAD:` diff |
+| `verified` satt | null (uendret) | migrasjonen stempler ALDRI verified |
+
+Slettelinjer i diffen: 25 totalt, **alle `**Verified:**`-relaterte** (21 Verified-linjer + 4
+tilhørende tomlinjer) — ingen prosa slettet.
+
+## To applier-fixes oppdaget under kjøring (TDD, RED→GREEN)
+
+Migrasjonen avdekket to reelle feil i de testede primitivene. Begge fikset med failing
+test først; suiten 728/728 grønn.
+
+1. **`insertHeaderFields` anker-overshoot (2 filer).** `agentic-rag-patterns.md` og
+   `gpt5-gpt41-pricing-models.md` pakker et helt avsnitt inn i én `**Status:**`-linje
+   (>500 B). Ankeret satte innsettingspunktet ETTER den linja → Type/Source landet forbi
+   500-byte-scan-vinduet. Applierens post-write-assertion fanget det og restaurerte hele
+   korpuset fra backup (sikkerhetsmekanismen virket). Fix: ankeret faller tilbake til
+   siste meta-linje som fortsatt ligger innenfor vinduet.
+
+2. **`normalizeStaleVerified` body-dup poison (9 filer, alle `mlops-genaiops/`).** Etter at
+   header-`**Verified:** MCP` ble fjernet, leste `parseVerifiedHeader` fortsatt en stray
+   duplikat-`**Verified:** MCP`-linje rett under `---` men innenfor 500 B → filene ble
+   falskt lest som "verified" → droppet til `fresh`, utenfor worklisten. Fix (operatør-
+   godkjent utvidelse av carve-out): normalizer fjerner nå ALLE stale non-date
+   `**Verified:**` i 500B-vinduet, uansett `---`-posisjon; kun stray metadata-linjer,
+   aldri prosa. Alt forbi 500 B er ekte kropp og røres ikke.
+
+## Skill-score-delta (pre → post)
+
+| Skill | Score | CT5 available | N4 (sub / pass) |
+|-------|-------|---------------|-----------------|
+| ms-ai-engineering | 95 → **99** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-governance | 96 → **100** | false → **true** | 0.013 → **1.000 / pass** |
+| ms-ai-infrastructure | 95 → **98** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-security | 95 → **100** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-advisor | 91 → 91 | (uendret) | (uendret) |
+
+CT5 `pass=false` på engineering + infrastructure er forventet: full CT5-pass krever
+`verified`-stempler, som settes først i corpus-judge-pass (fremtidig). CT5 er nå
+**available** (evaluert) på alle 4 fordi reference-filene bærer Type+Source.
+
+## Policy-artefakt: forventet dip inntraff IKKE
+
+Planen (Risks) forhåndsdeklarerte en **transient sub-90 dip** (CT5/N4-aktivering kunne
+dra de 4 skills under 90 midlertidig) som et **policy-artefakt** å ikke reagere på.
+**Målt utfall: dip inntraff ikke** — scorene STEG (95→98–100). N4 gikk 0→1.000 (TOC lagt
+til), CT5 ble available. Advarselen var altså konservativ; ingen skill falt under target.
+Registrert her for å hindre at en senere sesjon leter etter en dip som ikke finnes.
+
+## Worklist-transisjon (verifisert)
+
+Post-migrasjon + poison-fix (`report-full-pass-worklist.mjs`):
+
+| Bøtte | Antall | Merknad |
+|-------|--------|---------|
+| `due` | 243 | aktivert (var 0 pre-migrasjon); +9 etter poison-fix |
+| `fresh` | 0 | var 9 (body-dup poison) → 0 etter fix |
+| `unsourced` | 59 | deferred no-citation reference (dokumentert follow-up) |
+| `unmigrated` | 62 | advisor (bevisst utenfor scope) |
+| `outOfScope` | 25 | — |
+| **sum** | **389** | 243 + 59 + 62 + 25 = 389 ✅ |
+
+## Base-felt-restanse (dokumentert follow-up — utenfor dette substratet)
+
+Substrat-migrasjonen normaliserer IKKE base-feltene (worklist/CT5/N4 leser dem ikke):
+
+- `**Status:**` mangler: **29 filer** (planen anslo 31).
+- `**Last updated:**` (engelsk RE) mangler: **0** (planen fryktet 45 norske — ikke reelt).
+- `**Source:**` mangler: 59 (deferred no-ms-citation — trenger kilde før stempling).
+- `verified`/`verified_by` mangler: 302 (= `verified` null; settes i corpus-judge-pass).
+- TOC mangler: 0.
+
+Base-felt-normalisering (Status på de 29) er en egen, senere oppgave — ikke nødvendig for
+Port-1-substratet.

docs/v3.1-fanout-runbook.md

@@ -0,0 +1,86 @@
+# Runbook — v3.1 judge bake-off fan-out (resume-ready)
+
+_Opprettet 2026-06-30. Selvbærende oppskrift for å kjøre v3.1-bake-offen (programdok §8 G1, option A) i en fersk sesjon. Deterministisk der det går; den ene LLM-tunge delen (45 subagenter) er isolert og eksplisitt. Forutsetter INGEN kontekst utover denne fila + de refererte artefaktene._
+
+## Hvorfor / hva dette avgjør
+
+v3 er adoptert baseline, målt **P 100,0 % / R 92,9 % / 0 FP** på G5b-korrigert gull (`scripts/kb-eval/data/judge-bakeoff-report-v3-g5bgold.{json,md}`). v3.1 (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) er en ren recall-hardning av de 3 gjenstående FN (R1 øvre/nedre-grense-skille, R7 last-bærende-streng-carve-out, ny R8 fler-delt-fullstendighet). Denne kjøringen måler om v3.1 fanger de 3 FN UTEN å innføre nye FP.
+
+**Forhåndsregistrert adopsjonsgate (låst FØR fan-out):** adopter v3.1 KUN hvis den **holder P = 100 % OG løfter R over 92,9 %** (mot G5b-gull). Enhver ny FP feller den → behold v3. Rapportens egen «GATE: PASS» (R≥0,70/P≥0,60) er kun gulvet, IKKE adopsjonsbaren.
+
+## Forutsetninger (verifiser FØRST — premiss-sjekk)
+
+```bash
+cd /Users/ktg/repos/ktg-plugin-marketplace/ms-ai-architect
+# 1. Manifest + gull fortsatt i sync (skal si 255 claims / 45 files):
+node scripts/kb-eval/extract-judge-claims.mjs        # -> "blind manifest: 255 claims across 45 files"
+# 2. Suite + gull-lint grønt:
+node --test tests/kb-update/*.test.mjs tests/kb-eval/*.test.mjs   # -> pass 641
+node scripts/kb-eval/lint-gold-consistency.mjs       # -> "0 uwaived ... (373 claims)"
+```
+
+Hvis manifestet IKKE er 255/45: gullet er endret siden 2026-06-30 → regenerer manifest (`node scripts/kb-eval/extract-judge-claims.mjs --write`) og re-mål v3-baseline mot oppdatert gull FØR du måler v3.1 (baren må være fersk — [[gold-freshness-can-invert-adoption]]).
+
+## Steg 1 — generer payloads (deterministisk, ingen LLM)
+
+```bash
+node scripts/kb-eval/build-judge-payloads.mjs \
+  --prompt judge-claim-prompt-v3.1.md \
+  --out judge-bakeoff-payloads-v3.1.json --write
+# -> "45 per-file payloads, 255 claims total, prompt=judge-claim-prompt-v3.1.md"
+```
+
+Output: `scripts/kb-eval/data/judge-bakeoff-payloads-v3.1.json` (gitignored, regenererbar) = array av `{file, claim_count, prompt}`. Hver `prompt` er v3.1-malen med `<FILE>` + `<CLAIMS>` allerede substituert — klar til å dispatche ordrett.
+
+## Steg 2 — fan-out (DEN dyre delen: 45 Opus-4.8-subagenter)
+
+For HVER av de 45 payload-oppføringene, spawn ÉN subagent (inline `Agent`-verktøy):
+- **model:** `opus` (4.8), reasoning **xhigh** ([[subagent-model-opus-xhigh]]). Aldri Sonnet/Haiku.
+- **prompt:** payload-oppføringens `prompt`-felt, ordrett (ingen tillegg).
+- **subagent_type:** `general-purpose` (trenger `microsoft_docs_fetch`/`microsoft_docs_search`).
+- **blind:** payloaden inneholder ALDRI gull-verdikt/notes (manifestet er strippet) — ikke lekk dem.
+- **read-only:** subagenter skriver ALDRI til disk; hovedkonteksten aggregerer.
+- Kjør i batcher (f.eks. 8–10 samtidige) for å holde kontekst håndterbar; 45 totalt.
+
+Hver subagent returnerer streng JSON: `{"file":"...","results":[{"id","judge_verdict","rule","evidence_url","evidence_quote","reason"},...]}`.
+
+**Aggreger** alle 45 `results`-arrays til én fil. Behold MINST `id` + `judge_verdict` (+ `rule` anbefalt; scoreren bruker kun `judge_verdict`). Skriv:
+
+`scripts/kb-eval/data/judge-bakeoff-results-v3.1.json` = `{"results":[ {"id":..., "judge_verdict":..., "rule":...}, … 255 totalt ]}`
+
+(Format = identisk med `judge-bakeoff-results-v3.json` — sjekk den som mal.)
+
+## Steg 3 — score (deterministisk) + anvend gaten
+
+```bash
+node scripts/kb-eval/run-judge-bakeoff.mjs \
+  --min-recall 0.70 --min-precision 0.60 \
+  --results judge-bakeoff-results-v3.1.json \
+  --report-prefix judge-bakeoff-report-v3.1 --write
+```
+
+- Scoreren FEILER hardt hvis < 255 verdikt (ufullstendig fan-out) — fix manglende ids og kjør på nytt.
+- Les `data/judge-bakeoff-report-v3.1.json` → `arms.judge`: `precision`, `recall`, `fp`, `fn`, `tp`, `tn`.
+- **Adopsjon:** sammenlign mot v3 (P 100 / R 92,9, FP 0). Adopter v3.1 KUN hvis `precision == 1.0` (FP 0) OG `recall > 0.929`. Ellers: behold v3, dokumenter hvilke nye FP/regresjoner v3.1 innførte (input til en evt. v3.2).
+- Hvis v3.1 fanget noen men ikke alle 3 FN, eller innførte FP: det er et MÅLT resultat — før det i §8 G1-raden, ikke en feil.
+
+## Steg 4 — uansett utfall
+
+- Oppdater programdok §8 G1-rad + lukke-logg med målt P/R for v3.1 + adopsjonsbeslutning.
+- **Hvis adoptert:** den adopterte prompten (v3 eller v3.1) blir input til **G2** (wire inn i `scripts/kb-update/lib/transform.mjs`-judge-passet, Port 2 born-verified, + kadens-runner Port 3).
+- Forventede artefakter etterpå: `judge-bakeoff-results-v3.1.json` (commit), `judge-bakeoff-report-v3.1.{json,md}` (commit). Payloads-fila er gitignored.
+- Commit (`[skip-docs]`, ingen AI-trailers, Forgejo `origin`).
+
+## De 3 FN v3.1 sikter på (forventet flip grounded→not_grounded)
+
+| Claim | Feilmodus | v3.1-regel | Forventet |
+|---|---|---|---|
+| `ms-ai-security/cost-optimization/multi-model-strategy-costs.md#2` | «opptil 18» tak brutt av live 28 | R1 (øvre grense) | not_grounded |
+| `ms-ai-governance/monitoring-observability/token-usage-tracking-attribution.md#3` | metrikk-navn `PromptTokens`/`CompletionTokens` finnes ikke (live: `ProcessedPromptTokens`/`InputTokens`/`GeneratedTokens`/`OutputTokens`) | R7 (last-bærende streng) | not_grounded |
+| `ms-ai-infrastructure/bcdr/ai-foundry-disaster-recovery-planning.md#9` | Norway East er Global (ikke-residency) trenings-region, ikke regional | R8 (fler-delt) | not_grounded |
+
+Disse er gull=`outdated` (positive). Fanger v3.1 alle 3 uten ny FP → R 92,9 → 100 ved P 100. Det er max-utfallet.
+
+## Bakgrunn (les ved tvil)
+
+`docs/ref-kb-correctness-program-2026-06.md` §8 (G1/G5/G5b) · `scripts/kb-eval/judge-claim-prompt-v3.1.md` (R1–R8) · `docs/ref-kb-gold-reconciliation-2026-06.md` (gull-flip-ledger) · STATE.md «👉 NESTE».

hooks/scripts/session-start-context.mjs

@@ -6,6 +6,21 @@
 import { readdirSync, readFileSync, existsSync } from 'node:fs';
 import { join, relative } from 'node:path';
 import { spawn } from 'node:child_process';
+import {
+  loadScheduleConfig,
+  shouldRunDetection,
+  summarizeSkillLifecycle,
+  summarizeCourses,
+  summarizeSkillQuality,
+  summarizeTrustFreshness,
+} from '../../scripts/kb-update/lib/detection-schedule.mjs';
+import {
+  resolveOrgDir,
+  ORG_FILES,
+  FREE_CONTEXT_FILE,
+  buildOrgSummary,
+} from '../../scripts/kb-update/lib/user-data.mjs';
+import { loadAiActDeadlines } from '../../scripts/kb-update/lib/ai-act-deadlines.mjs';
 
 const pluginRoot = process.env.CLAUDE_PLUGIN_ROOT || join(process.cwd());
 const cwd = process.cwd();
@@ -62,29 +77,29 @@ if (existsSync(changeReportPath)) {
   }
 }
 
-// Trigger background poll if >7 days since last check
-if (lastPollDaysAgo > 7) {
-  const updateScript = join(pluginRoot, 'scripts', 'kb-update', 'run-weekly-update.mjs');
-  if (existsSync(updateScript)) {
+// Opt-in background detection (Spor C / C1). Default OFF: nothing spawns unless
+// the user enabled scheduled_detection in ms-ai-architect.local.md. When on +
+// stale, run the Claude-FREE detection entrypoint (poll → report → discover →
+// skill-lifecycle) in the background. This never invokes Claude — apply stays
+// manual + in-session. See detection-schedule.mjs for the ToS rationale.
+const scheduleConfig = loadScheduleConfig(pluginRoot);
+if (shouldRunDetection(scheduleConfig, lastPollDaysAgo).run) {
+  const detectScript = join(pluginRoot, 'scripts', 'kb-update', 'run-detection.mjs');
+  if (existsSync(detectScript)) {
     try {
-      spawn('node', [updateScript], { detached: true, stdio: 'ignore' }).unref();
+      spawn('node', [detectScript], { detached: true, stdio: 'ignore' }).unref();
     } catch {
       // Non-critical — silent fail
     }
   }
 }
 
-// --- 3. Check EU AI Act deadlines ---
-const AI_ACT_DEADLINES = [
-  { date: new Date('2025-02-02'), label: 'Forbudte AI-praksiser (Art. 5)' },
-  { date: new Date('2025-08-02'), label: 'Governance + sanksjoner (Art. 99)' },
-  { date: new Date('2026-08-02'), label: 'GPAI-krav + høyrisiko i Annex III' },
-  { date: new Date('2027-08-02'), label: 'Alle høyrisiko-krav (full compliance)' },
-];
+// --- 3. Check EU AI Act deadlines (single source: scripts/kb-update/data/ai-act-deadlines.json) ---
+const aiActSource = loadAiActDeadlines();
 
 let nearestDeadline = null;
-for (const dl of AI_ACT_DEADLINES) {
-  const daysLeft = Math.ceil((dl.date.getTime() - now) / DAY_MS);
+for (const dl of aiActSource ? aiActSource.deadlines : []) {
+  const daysLeft = Math.ceil((new Date(dl.date).getTime() - now) / DAY_MS);
   if (daysLeft > 0 && daysLeft <= 180) {
     if (!nearestDeadline || daysLeft < nearestDeadline.daysLeft) {
       nearestDeadline = { ...dl, daysLeft };
@@ -92,22 +107,43 @@ for (const dl of AI_ACT_DEADLINES) {
   }
 }
 
-// --- 4. Check onboarding status ---
-const orgDir = join(pluginRoot, 'org');
-const ORG_FILES = [
-  'organization-profile.md',
-  'technology-stack.md',
-  'security-compliance.md',
-  'architecture-decisions.md',
-  'business-references.md',
-];
-let orgComplete = 0;
-const orgExists = existsSync(orgDir);
-if (orgExists) {
-  for (const f of ORG_FILES) {
-    if (existsSync(join(orgDir, f))) orgComplete++;
+// --- 4. Onboarding status + ambient org context (C2.1) ---
+// The user-owned org dir (~/.claude/ms-ai-architect/org) wins; the legacy
+// plugin org/ dir is the backward-compat fallback. Read the files once: their
+// count drives the status line, their content drives the ambient summary that
+// makes org context present in EVERY session (not just a "run onboarding" nudge).
+function readOrgFiles(dir) {
+  const files = {};
+  let count = 0;
+  if (existsSync(dir)) {
+    for (const f of ORG_FILES) {
+      const p = join(dir, f);
+      if (existsSync(p)) {
+        try {
+          files[f] = readFileSync(p, 'utf8');
+          count++;
+        } catch {
+          // Unreadable file — skip; advisory only
+        }
+      }
+    }
+    // Optional free-prose context (C2.2): read it for the ambient summary, but
+    // do NOT count it — it is optional and must not affect onboarding completeness.
+    const fp = join(dir, FREE_CONTEXT_FILE);
+    if (existsSync(fp)) {
+      try {
+        files[FREE_CONTEXT_FILE] = readFileSync(fp, 'utf8');
+      } catch {
+        // Unreadable — skip; advisory only
+      }
+    }
   }
+  return { files, count };
 }
+const userOrg = readOrgFiles(resolveOrgDir());
+const orgData = userOrg.count > 0 ? userOrg : readOrgFiles(join(pluginRoot, 'org'));
+const orgComplete = orgData.count;
+const orgSummary = buildOrgSummary(orgData.files);
 
 // --- 4. Build output ---
 const parts = [];
@@ -119,7 +155,7 @@ if (utredningFiles > 0) {
   parts.push(`${utredningFiles} utredningsdokument(er) i docs/`);
 }
 
-if (!orgExists || orgComplete === 0) {
+if (orgComplete === 0) {
   parts.push('Ingen virksomhetstilpasning. Kjør /architect:onboard (~5 min)');
 } else if (orgComplete < ORG_FILES.length) {
   parts.push(`Onboarding ${orgComplete}/${ORG_FILES.length}. Kjør /architect:onboard for å fullføre`);
@@ -137,6 +173,61 @@ if (staleEntries.length > 0) {
   parts.push('KB: poll overdue');
 }
 
+// Skill-lifecycle signals (Spor B/C) — read-only one-liner; never spawns.
+const skillReportPath = join(pluginRoot, 'scripts', 'kb-eval', 'data', 'skill-lifecycle-report.json');
+if (existsSync(skillReportPath)) {
+  try {
+    const skillSummary = summarizeSkillLifecycle(JSON.parse(readFileSync(skillReportPath, 'utf8')));
+    if (skillSummary) parts.push(skillSummary);
+  } catch {
+    // Ignore — advisory only
+  }
+}
+
+// Course-detection signals (Spor C / C3.6) — read-only one-liner; never spawns.
+// A lead is a signal that a topic exists, not auto-ingest: surfacing it here
+// invites the operator to run /architect:kb-update §3c, which gates the lead
+// into the courses ledger. Mirrors the skill-signaler block above.
+const courseReportPath = join(pluginRoot, 'scripts', 'kb-update', 'data', 'course-detection-report.json');
+if (existsSync(courseReportPath)) {
+  try {
+    const courseSummary = summarizeCourses(JSON.parse(readFileSync(courseReportPath, 'utf8')));
+    if (courseSummary) parts.push(`${courseSummary}. Kjør /architect:kb-update`);
+  } catch {
+    // Ignore — advisory only
+  }
+}
+
+// Skill-quality score signals (Spor D / Steg C) — read-only one-liner; never
+// spawns, never scores live. Reads the CACHED skill-score-report.json (written
+// by `score-skill.mjs --write`). The cache is gitignored => absent in a fresh
+// clone, so this surfaces only for a maintainer who has produced it locally;
+// summarizeSkillQuality tolerates the missing/malformed case → null.
+const scoreCachePath = join(pluginRoot, 'scripts', 'kb-eval', 'data', 'skill-score-report.json');
+if (existsSync(scoreCachePath)) {
+  try {
+    const qualitySummary = summarizeSkillQuality(JSON.parse(readFileSync(scoreCachePath, 'utf8')));
+    if (qualitySummary) parts.push(qualitySummary);
+  } catch {
+    // Ignore — advisory only
+  }
+}
+
+// KB-trust reporting floor (Spor 3 Port 3 / P3b) — read-only one-liner; never
+// judges live. Reads the CACHED verified-staleness-report.json (written by
+// report-verified-staleness.mjs on the KB-refresh cadence). Gitignored => absent
+// in a fresh clone; summarizeTrustFreshness tolerates the missing/malformed case
+// → null. Surfaces only drift + contract breaches (§4c — a floor, not a gate).
+const stalenessCachePath = join(pluginRoot, 'scripts', 'kb-update', 'data', 'verified-staleness-report.json');
+if (existsSync(stalenessCachePath)) {
+  try {
+    const trustSummary = summarizeTrustFreshness(JSON.parse(readFileSync(stalenessCachePath, 'utf8')));
+    if (trustSummary) parts.push(trustSummary);
+  } catch {
+    // Ignore — advisory only
+  }
+}
+
 if (nearestDeadline) {
   parts.push(`EU AI Act: ${nearestDeadline.daysLeft} dager til ${nearestDeadline.label}. Kjør /architect:classify`);
 }
@@ -147,6 +238,14 @@ if (parts.length > 0) {
   lines.push('Architect: Ingen aktive sesjoner. KB oppdatert. /architect:help');
 }
 
+// Ambient org context (C2.1): inject the compact summary so org facts are
+// PRESENT in the session, not merely discoverable. Length-capped by
+// buildOrgSummary. Only emitted when onboarding has produced content.
+if (orgSummary) {
+  lines.push('Virksomhetskontekst (auto-injisert fra ~/.claude/ms-ai-architect/org):');
+  for (const l of orgSummary.split('\n')) lines.push(`- ${l}`);
+}
+
 if (lines.length > 0) {
   process.stdout.write(lines.join('\n') + '\n');
 }

hooks/scripts/stop-assessment-reminder.mjs

@@ -5,6 +5,7 @@
 
 import { readdirSync, statSync, existsSync } from 'node:fs';
 import { join } from 'node:path';
+import { loadAiActDeadlines } from '../../scripts/kb-update/lib/ai-act-deadlines.mjs';
 
 const cwd = process.cwd();
 const workDir = join(cwd, '.work');
@@ -60,12 +61,18 @@ const suggestions = [
   '/architect:summary — lag beslutningsnotat',
 ];
 
-// Add AI Act suggestion if deadline is within 180 days
+// Add AI Act suggestion if the nearest deadline (from the shared source) is within 180 days
 const DAY_MS = 24 * 60 * 60 * 1000;
-const gpaiDeadline = new Date('2026-08-02');
-const daysToGpai = Math.ceil((gpaiDeadline.getTime() - now) / DAY_MS);
-if (daysToGpai > 0 && daysToGpai <= 180) {
-  suggestions.push(`/architect:classify — EU AI Act-klassifisering (${daysToGpai}d til GPAI-frist)`);
+const aiActSource = loadAiActDeadlines();
+let nearestDeadline = null;
+for (const dl of aiActSource ? aiActSource.deadlines : []) {
+  const daysLeft = Math.ceil((new Date(dl.date).getTime() - now) / DAY_MS);
+  if (daysLeft > 0 && daysLeft <= 180 && (!nearestDeadline || daysLeft < nearestDeadline.daysLeft)) {
+    nearestDeadline = { ...dl, daysLeft };
+  }
+}
+if (nearestDeadline) {
+  suggestions.push(`/architect:classify — EU AI Act-klassifisering (${nearestDeadline.daysLeft}d til ${nearestDeadline.label})`);
 }
 
 const sessionList = recentSessions.join(', ');

ms-ai-architect.local.md.example

@@ -0,0 +1,20 @@
+---
+# Opt-in scheduled detection (Spor C / C1). Copy this file to
+# `ms-ai-architect.local.md` (gitignored) and flip enabled:true to turn it on.
+#
+# Detection (poll → report → discovery → skill-lifecycle) is pure node and NEVER
+# contacts Claude/Anthropic — it only writes JSON reports under data/. Apply
+# (the one Claude step) always stays manual + in-session + gated. The schedule
+# is therefore outside the Anthropic ToS surface (Consumer Terms §3.7 restricts
+# automated access to "our Services", not local non-Claude scripts).
+scheduled_detection:
+  enabled: false                 # default OFF — nothing runs until this is true
+  interval_days: 7               # re-run detection when >= N days since last poll
+  include_skill_lifecycle: true  # include skill-lifecycle detection (overlap/gap/bloat)
+---
+
+# ms-ai-architect — local settings
+
+This file holds per-checkout plugin settings. The real file (`ms-ai-architect.local.md`)
+is gitignored; this `.example` is the tracked template. See
+`commands/kb-update.md` → "Scheduled deteksjon (opt-in)" for details.

playground/ms-ai-architect-playground.html

@@ -246,11 +246,11 @@
       "reports": {
         "classify": {
           "input": {},
-          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-08-02 (Annex III høyrisiko full compliance).\n"
+          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
         },
         "requirements": {
           "input": {},
-          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-08-02.\n"
+          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
         },
         "transparency": {
           "input": {},
@@ -262,7 +262,7 @@
         },
         "conformity": {
           "input": {},
-          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | GPAI-krav + Annex III høyrisiko | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-08-02 | Full Annex III høyrisiko-compliance | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
+          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
         },
         "dpia": {
           "input": {},
@@ -278,7 +278,7 @@
         },
         "review": {
           "input": {},
-          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-08-02-fristen.\n"
+          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
         },
         "cost": {
           "input": {},
@@ -294,11 +294,11 @@
         },
         "adr": {
           "input": {},
-          "raw_markdown": "# ADR-001 — Velg Azure AI Foundry som primær AI-plattform for Acme Kunde-chatbot\n\nStatus: accepted\nDate: 2026-04-30\nDeciders: AI-arkitekt, sikkerhetsarkitekt, seksjonsleder\nConsulted: Datatilsynet, juridisk rådgiver, Drift\nInformed: prosjekteierskap, AI-teamet\n\n## Context and Problem Statement\n\nAcme Kommune skal modernisere Acme Kunde-chatbot fra on-prem OCR-løsning til skybasert AI-plattform. Plattformen må støtte custom modell-trening, audit-logging på inferens-nivå, real-time inferens (<100ms P95), og full compliance med EU AI Act + GDPR + sikkerhetsloven.\n\n## Decision Drivers\n\n- Compliance med EU AI Act høyrisiko-krav (Art. 9-15)\n- Norsk dataresidens-krav\n- Customer-managed keys og Private Endpoints\n- Custom modell-trening kapabilitet\n- Total cost of ownership over 3 år\n- Driftbarhet for AI-teamet\n\n## Considered Options\n\n1. **Azure AI Foundry** — Enterprise AI-plattform med full compliance-pakke\n2. **Azure ML + AKS** — Mer kontroll, men høyere driftskost\n3. **AWS SageMaker** — Konkurransedyktig, men mangler norske compliance-sertifiseringer\n4. **On-prem GPU-cluster** — Maks kontroll, men krever betydelig CapEx og driftskompetanse\n\n## Decision Outcome\n\nChosen option: **Azure AI Foundry**, fordi det balanserer compliance, driftbarhet, og fleksibilitet best for vår bemanning og tidsramme.\n\n### Consequences\n\n- Good: full compliance-pakke for leverandøren, raskere time-to-prod, integrert med eksisterende Entra ID\n- Good: customer-managed keys og Customer Lockbox tilgjengelig\n- Bad: lock-in til Azure, men mitigert via standardiserte modell-formater (ONNX) og data-portabilitet\n- Bad: høyere månedlig kostnad enn ren Azure ML — kompenseres ved redusert egen-drift\n\n## Validation\n\nBeslutning evalueres etter 12 måneder mot KPI-er:\n- Saksbehandlingstid (mål: -40%)\n- Modell-nøyaktighet (mål: ≥96% F1)\n- Total cost (mål: ≤ NOK 1.7M/år)\n- Compliance-status (mål: 100% av krav dekket innen 2027-08-02)\n\n## More Information\n\n- Compare-rapport: see `compare-foundry-vs-aml.md`\n- Cost-analyse: see `cost-tco-3year.md`\n- Security-vurdering: see `security-foundry-baseline.md`\n"
+          "raw_markdown": "# ADR-001 — Velg Azure AI Foundry som primær AI-plattform for Acme Kunde-chatbot\n\nStatus: accepted\nDate: 2026-04-30\nDeciders: AI-arkitekt, sikkerhetsarkitekt, seksjonsleder\nConsulted: Datatilsynet, juridisk rådgiver, Drift\nInformed: prosjekteierskap, AI-teamet\n\n## Context and Problem Statement\n\nAcme Kommune skal modernisere Acme Kunde-chatbot fra on-prem OCR-løsning til skybasert AI-plattform. Plattformen må støtte custom modell-trening, audit-logging på inferens-nivå, real-time inferens (<100ms P95), og full compliance med EU AI Act + GDPR + sikkerhetsloven.\n\n## Decision Drivers\n\n- Compliance med EU AI Act høyrisiko-krav (Art. 9-15)\n- Norsk dataresidens-krav\n- Customer-managed keys og Private Endpoints\n- Custom modell-trening kapabilitet\n- Total cost of ownership over 3 år\n- Driftbarhet for AI-teamet\n\n## Considered Options\n\n1. **Azure AI Foundry** — Enterprise AI-plattform med full compliance-pakke\n2. **Azure ML + AKS** — Mer kontroll, men høyere driftskost\n3. **AWS SageMaker** — Konkurransedyktig, men mangler norske compliance-sertifiseringer\n4. **On-prem GPU-cluster** — Maks kontroll, men krever betydelig CapEx og driftskompetanse\n\n## Decision Outcome\n\nChosen option: **Azure AI Foundry**, fordi det balanserer compliance, driftbarhet, og fleksibilitet best for vår bemanning og tidsramme.\n\n### Consequences\n\n- Good: full compliance-pakke for leverandøren, raskere time-to-prod, integrert med eksisterende Entra ID\n- Good: customer-managed keys og Customer Lockbox tilgjengelig\n- Bad: lock-in til Azure, men mitigert via standardiserte modell-formater (ONNX) og data-portabilitet\n- Bad: høyere månedlig kostnad enn ren Azure ML — kompenseres ved redusert egen-drift\n\n## Validation\n\nBeslutning evalueres etter 12 måneder mot KPI-er:\n- Saksbehandlingstid (mål: -40%)\n- Modell-nøyaktighet (mål: ≥96% F1)\n- Total cost (mål: ≤ NOK 1.7M/år)\n- Compliance-status (mål: 100% av krav dekket innen 2027-12-02)\n\n## More Information\n\n- Compare-rapport: see `compare-foundry-vs-aml.md`\n- Cost-analyse: see `cost-tco-3year.md`\n- Security-vurdering: see `security-foundry-baseline.md`\n"
         },
         "summary": {
           "input": {},
-          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-08-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
+          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
         },
         "poc": {
           "input": {},
@@ -805,7 +805,7 @@
     // COMMAND CATALOG (Step 4)
     // ============================================================
     //
-    // Kanonisk single-source-of-truth for alle 25 commands. Driver:
+    // Kanonisk single-source-of-truth for alle 29 commands. Driver:
     //   - Step 5/8: skjema-render via input_fields[]
     //   - Step 9: katalog-UI gruppert på category
     //   - Step 11: parser-routing via report_archetype
@@ -834,7 +834,7 @@
     // som bruker det.
     const SHARED = {
       organisation_name: { id: 'organisation_name', label: 'Virksomhet', type: 'text', from: 'shared', shared_path: 'organization.name' },
-      sector: { id: 'sector', label: 'Sektor', type: 'select', from: 'shared', shared_path: 'organization.sector', options: ['Statlig', 'Kommunal', 'Fylkeskommune', 'Helseforetak', 'Undervisning', 'Annet'] },
+      sector: { id: 'sector', label: 'Sektor', type: 'select', from: 'shared', shared_path: 'organization.sector', options: ['Statlig', 'Kommunal', 'Fylkeskommune', 'Helseforetak', 'Undervisning', 'Finans', 'Industri', 'Handel', 'Energi', 'Telekom', 'Annet'] },
       regulatory_requirements: { id: 'regulatory_requirements', label: 'Regulatoriske krav', type: 'multiSelect', from: 'shared', shared_path: 'organization.regulatory_requirements', options: ['Personopplysningsloven/GDPR', 'Sikkerhetsloven', 'Arkivloven', 'Forvaltningsloven', 'Offentleglova', 'Helseregisterloven', 'Annet'] },
       cloud_platform: { id: 'cloud_platform', label: 'Skyplattform', type: 'multiSelect', from: 'shared', shared_path: 'technology.cloud_platform', options: ['Azure', 'M365', 'Power Platform', 'On-prem', 'Hybrid', 'Annet'] },
       license_type: { id: 'license_type', label: 'Lisenstype', type: 'select', from: 'shared', shared_path: 'technology.license_type', options: ['E3', 'E5', 'F1/F3', 'A3/A5', 'G3/G5', 'Annet'] },
@@ -1060,7 +1060,7 @@
           ]
         },
 
-        // ===== ECONOMY (2) =====
+        // ===== ECONOMY (3) =====
         {
           id: 'cost',
           category: 'economy',
@@ -1103,7 +1103,49 @@
           ]
         },
 
-        // ===== DOCUMENTATION (6) =====
+        {
+          id: 'businesscase',
+          category: 'economy',
+          label: 'Forretningscase (NNV + gevinst)',
+          description: 'Forretningscase med netto nåverdi og DFØ-gevinstrealisering.',
+          argument_hint: '[prosjektnavn] over [N] år',
+          calls_agent: null,
+          kb_files: ['samfunnsokonomisk-analyse-nnv.md', 'gevinstrealisering-dfo-methodology.md'],
+          produces_report: false,
+          report_archetype: null,
+          report_root_class: null,
+          renderer: null,
+          input_fields: [
+            SHARED.organisation_name,
+            { id: 'project_name', label: 'Prosjektnavn', type: 'text', from: 'local' },
+            { id: 'analysis_years', label: 'Analyseperiode (år)', type: 'number', from: 'local' },
+            { id: 'investment', label: 'Investering (engangs, NOK)', type: 'number', from: 'local' },
+            { id: 'annual_opex', label: 'Årlige driftskostnader (NOK)', type: 'number', from: 'local' },
+            { id: 'expected_benefits', label: 'Forventede gevinster', type: 'textarea', from: 'local' }
+          ]
+        },
+
+        // ===== DOCUMENTATION (9) =====
+        {
+          id: 'anskaffelse',
+          category: 'documentation',
+          label: 'AI-anskaffelse (kravspec + terskel)',
+          description: 'Anskaffelsesplan for AI: kravspesifikasjon, leverandørevaluering, terskelverdier.',
+          argument_hint: '[hva som skal anskaffes]',
+          calls_agent: null,
+          kb_files: ['anskaffelser-ai-procurement-framework.md'],
+          produces_report: false,
+          report_archetype: null,
+          report_root_class: null,
+          renderer: null,
+          input_fields: [
+            SHARED.organisation_name,
+            SHARED.sector,
+            { id: 'procurement_object', label: 'Hva som skal anskaffes', type: 'textarea', from: 'local' },
+            { id: 'estimated_value', label: 'Estimert verdi (NOK)', type: 'number', from: 'local' },
+            { id: 'procurement_type', label: 'Type', type: 'select', from: 'local', options: ['Vare/tjeneste', 'Rammeavtale', 'Utvikling', 'SaaS'] }
+          ]
+        },
         {
           id: 'migrate',
           category: 'documentation',
@@ -1225,8 +1267,50 @@
             { id: 'use_case', label: 'Use case', type: 'textarea', from: 'local' }
           ]
         },
+        {
+          id: 'design',
+          category: 'documentation',
+          label: 'Solution Architecture Document (SAD)',
+          description: 'Sektor-nøytralt arkitekturdokument: kontekst, krav/NFR, alternativer, valgt design, risiko, veikart.',
+          argument_hint: '[løsningsnavn] for [bruksscenario]',
+          calls_agent: null,
+          kb_files: ['decision-trees.md', 'security.md', 'cost-models.md'],
+          produces_report: false,
+          report_archetype: null,
+          report_root_class: null,
+          renderer: null,
+          input_fields: [
+            SHARED.organisation_name,
+            SHARED.sector,
+            { id: 'solution_name', label: 'Løsningsnavn', type: 'text', from: 'local' },
+            { id: 'use_case', label: 'Bruksscenario', type: 'textarea', from: 'local' },
+            { id: 'nfr', label: 'Ikke-funksjonelle krav (NFR)', type: 'textarea', from: 'local' },
+            { id: 'constraints', label: 'Begrensninger', type: 'textarea', from: 'local' }
+          ]
+        },
+        {
+          id: 'vendor',
+          category: 'documentation',
+          label: 'Leverandørvurdering (tredjepart/SaaS)',
+          description: 'Due diligence for ekstern SaaS/AI-leverandør: dataresidens, sub-prosessorer, DPA, Schrems II, AI Act-deployer.',
+          argument_hint: '[leverandør/tjeneste] for [bruksscenario]',
+          calls_agent: null,
+          kb_files: ['data-residency-audit-monitoring.md', 'ai-act-deployer-obligations.md', 'security.md'],
+          produces_report: false,
+          report_archetype: null,
+          report_root_class: null,
+          renderer: null,
+          input_fields: [
+            SHARED.organisation_name,
+            SHARED.sector,
+            { id: 'vendor_name', label: 'Leverandør/tjeneste', type: 'text', from: 'local' },
+            { id: 'use_case', label: 'Bruksscenario', type: 'textarea', from: 'local' },
+            { id: 'data_to_vendor', label: 'Data som flyter til leverandøren', type: 'textarea', from: 'local' },
+            { id: 'deployment_model', label: 'Driftsmodell', type: 'select', from: 'local', options: ['SaaS (multi-tenant)', 'Dedikert', 'Hybrid', 'On-prem'] }
+          ]
+        },
 
-        // ===== TOOL (7) — ingen rapport, kun skjema + output-kopiering =====
+        // ===== TOOL (8) — ingen rapport, kun skjema + output-kopiering =====
         {
           id: 'architect',
           category: 'tool',
@@ -1814,7 +1898,7 @@
           '<button type="button" class="tracks__card tracks__card--expert" data-action="goto-catalog">' +
             '<span class="tracks__card-icon" aria-hidden="true">◇</span>' +
             '<h3 class="tracks__card-title">Command-katalog</h3>' +
-            '<p class="tracks__card-desc">Bla i alle 25 commands gruppert på kategori. Generer pipeline-strenger uten et prosjekt.</p>' +
+            '<p class="tracks__card-desc">Bla i alle 29 commands gruppert på kategori. Generer pipeline-strenger uten et prosjekt.</p>' +
             '<span class="tracks__card-meta"><span>' + CATALOG.commands.length + ' commands</span><span class="tracks__card-cta">Bla →</span></span>' +
           '</button>' +
         '</div>'
@@ -1925,7 +2009,9 @@
       { id: 'copilot-extension', name: 'Copilot-utvidelse for M365' },
       { id: 'customer-service', name: 'Kundeservice-chatbot' },
       { id: 'intelligent-search', name: 'Intelligent søk på tvers av fagsystemer' },
-      { id: 'reporting', name: 'AI-assistert rapportering' }
+      { id: 'reporting', name: 'AI-assistert rapportering' },
+      { id: 'fraud-detection', name: 'Bank fraud-detection (finans, DORA — FRIA-unntatt)' },
+      { id: 'credit-scoring', name: 'Kredittscoring (finans, FRIA-pliktig privat deployer)' }
     ];
 
     // v1.15.0: currentProjectTab beholdes som zombie for ACTIONS['project-tab']-
@@ -2074,7 +2160,7 @@
     // CATALOG SURFACE (Step 9)
     // ============================================================
     //
-    // 25 commands gruppert i 5 .expansion-grupper (CATALOG.categories) med
+    // 29 commands gruppert i 5 .expansion-grupper (CATALOG.categories) med
     // søke-input som filtrerer på id+label+description+argument_hint.
     // Hver kategori-expansion rendrer en .catalog-cards-grid med kort.
     // "Åpne skjema" på et kort åpner renderCommandForm() i modal.

scripts/kb-eval/apply-skill-op.mjs

@@ -0,0 +1,304 @@
+#!/usr/bin/env node
+// apply-skill-op.mjs — Spor B / B3 (Sesjon 18) CLI: the DESTRUCTIVE apply-path.
+//
+// Executes an operator-APPROVED (status:approved) skill-lifecycle entry from
+// decisions.json into a real skills/ mutation: sanitize_skill + retire_skill
+// (single-skill, S18) and merge_skills (cross-skill, S19). create_skill comes last.
+//
+// Two gates, in order: (1) the entry must already be status:approved in the
+// ledger (the operator's sign-off on a prior `plan-skill-op … --write` dry-run);
+// (2) this CLI mutates skills/ ONLY with --apply. Without --apply it is a PREVIEW
+// that re-plans from fresh disk, revalidates (drift-safe), and mutates nothing.
+//
+// sanitize/retire archive every file under archive/ BEFORE removing it. merge
+// RELOCATES the absorbed skill's references under the absorber, persists the
+// taxonomy ownership repoint, then archives the absorbed SKILL.md + removes its
+// dir. Apply flips the ledger entry approved -> applied. Verify: `git status`.
+//
+// Usage:
+//   node scripts/kb-eval/apply-skill-op.mjs list
+//   node scripts/kb-eval/apply-skill-op.mjs sanitize <skill> [--apply] [--date YYYY-MM-DD]
+//   node scripts/kb-eval/apply-skill-op.mjs retire   <skill> [--apply] [--date YYYY-MM-DD]
+//   node scripts/kb-eval/apply-skill-op.mjs merge    <absorber> <absorbed> [--apply] [--date YYYY-MM-DD]
+
+import { readFileSync, readdirSync, existsSync, writeFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { splitFrontmatter, extractDescription, buildReport } from './eval.mjs';
+import { gateSkill, scoreReport, buildScoreCache } from './lib/skill-score.mjs';
+import { loadTaxonomy } from '../kb-update/lib/taxonomy.mjs';
+import { loadDecisions, listActions, actionKey } from '../kb-update/lib/decisions-io.mjs';
+import {
+  applyApprovedAction,
+  SANITIZE_OPERATION,
+  RETIRE_OPERATION,
+  MERGE_OPERATION,
+  CREATE_OPERATION,
+  TEST_DOMAIN_SPEC,
+} from './lib/skill-ops.mjs';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const PLUGIN_ROOT = join(__dirname, '..', '..');
+const SKILLS_DIR = join(PLUGIN_ROOT, 'skills');
+const AGENTS_DIR = join(PLUGIN_ROOT, 'agents');
+const LEDGER_DATA_DIR = join(__dirname, '..', 'kb-update', 'data');
+const PROMPTS_FILE = join(__dirname, 'data', 'k1-trigger-prompts.json');
+// Same cache score-skill.mjs --write maintains and the STEG C SessionStart
+// surfacing reads — refreshed here after every applied mutation so the surfacing
+// never goes stale until the next manual re-score.
+export const SCORE_CACHE_FILE = join(__dirname, 'data', 'skill-score-report.json');
+
+const OP_BY_VERB = {
+  sanitize: SANITIZE_OPERATION,
+  retire: RETIRE_OPERATION,
+  merge: MERGE_OPERATION,
+  create: CREATE_OPERATION,
+};
+
+const QUALITY_TARGET = 90; // corpus invariant: every skill stays >=90 (Spor D)
+
+/** Read the SKILL.md descriptions from disk (read-only) — create's K10 siblings. */
+function loadDescriptions() {
+  const out = {};
+  for (const e of readdirSync(SKILLS_DIR, { withFileTypes: true })) {
+    if (!e.isDirectory()) continue;
+    const md = join(SKILLS_DIR, e.name, 'SKILL.md');
+    if (!existsSync(md)) continue;
+    out[e.name] = extractDescription(splitFrontmatter(readFileSync(md, 'utf8')).frontmatter);
+  }
+  return out;
+}
+
+/** Read the curated K1 trigger-prompt set (boundary-tension source for K10). */
+function loadPromptSet() {
+  return existsSync(PROMPTS_FILE) ? JSON.parse(readFileSync(PROMPTS_FILE, 'utf8')) : {};
+}
+
+const USAGE =
+  'Usage:\n' +
+  '  node scripts/kb-eval/apply-skill-op.mjs list\n' +
+  '  node scripts/kb-eval/apply-skill-op.mjs sanitize <skill> [--apply] [--date YYYY-MM-DD]\n' +
+  '  node scripts/kb-eval/apply-skill-op.mjs retire   <skill> [--apply] [--date YYYY-MM-DD]\n' +
+  '  node scripts/kb-eval/apply-skill-op.mjs merge    <absorber> <absorbed> [--apply] [--date YYYY-MM-DD]\n' +
+  '  node scripts/kb-eval/apply-skill-op.mjs create   <name> [--apply] [--date YYYY-MM-DD]';
+
+/** List approved actions awaiting apply (operator's apply queue). */
+function listApproved() {
+  const led = loadDecisions(LEDGER_DATA_DIR);
+  const approved = listActions(led, 'approved');
+  const applied = listActions(led, 'applied');
+  console.log(`\nGodkjente handlinger som venter på apply (${approved.length}):`);
+  if (!approved.length) console.log('  (ingen — kjør plan-skill-op … --write og sett status:approved i decisions.json)');
+  for (const a of approved) {
+    const t = a.targets ?? {};
+    const tgt = t.skill ?? t.name ?? `${t.absorbed} -> ${t.absorber}`;
+    console.log(`  • ${a.operation_type}: ${tgt}  [guardrail ${a.guardrail?.ok ? 'OK' : 'FAILED'}]`);
+  }
+  if (applied.length) console.log(`\nAllerede anvendt (${applied.length}): ${applied.map((a) => actionKey(a)).join(', ')}`);
+  console.log('');
+}
+
+function printResult(res, verb, label, apply) {
+  const r = res.revalidate;
+  console.log(`\n${verb} — ${apply ? 'APPLY' : 'PREVIEW'}: ${label}\n`);
+  console.log(`Revalidering (mot fersk disk):`);
+  console.log(`  fersk-guardrail-ok=${r.freshOk}  drift=${r.drift}  => ${r.ok ? 'OK' : 'BLOKKERT'}`);
+  if (r.reason) console.log(`  grunn: ${r.reason}`);
+  if (!res.applied) {
+    if (res.preview && r.ok) {
+      const d = res.plan?.diff ?? {};
+      if (verb === 'merge') {
+        console.log(
+          `\n  Ville flyttet ${d.fileMoves?.length ?? 0} ref-fil(er) -> absorber, reassignet ` +
+            `${d.taxonomyReassignments?.length ?? 0} kategori(er), arkivert absorbed-SKILL.md. ` +
+            `Kjør på nytt med --apply for å eksekvere.`,
+        );
+      } else if (verb === 'create') {
+        const sc = res.plan?.scaffold ?? {};
+        console.log(
+          `\n  Ville opprettet skills/${label}/ — 1 SKILL.md + ${sc.files?.length ?? 0} ref-fil(er), ` +
+            `${sc.taxonomyAdditions?.length ?? 0} taksonomi-tillegg. Kjør på nytt med --apply for å eksekvere.`,
+        );
+      } else {
+        const n = verb === 'sanitize' ? (d.removals?.length ?? 0) : (d.archiveMoves?.length ?? 0);
+        console.log(`\n  Ville arkivert+fjernet ${n} fil(er). Kjør på nytt med --apply for å eksekvere.`);
+      }
+    }
+    console.log(`\nStatus: INGEN mutasjon utført.${res.preview && r.ok ? '' : ' (revalidering blokkerte eller ingen --apply.)'}\n`);
+    return;
+  }
+  const rep = res.report;
+  console.log(`\nUtført:`);
+  if (rep.op === MERGE_OPERATION) {
+    console.log(`  flyttet: ${rep.refMoves} ref-fil(er) -> absorber`);
+    console.log(`  taksonomi: ${rep.taxonomyReassignments} kategori(er) reassignet + persistert`);
+    if (rep.archivedSkillMd) console.log(`  arkivert: ${rep.archivedSkillMd}`);
+  } else if (rep.op === CREATE_OPERATION) {
+    console.log(`  opprettet: ${rep.filesWritten} fil(er) under ${rep.createdDir} (1 SKILL.md + ${rep.filesWritten - 1} ref-filer)`);
+    console.log(`  taksonomi: ${rep.taxonomyAdditions} tillegg (additivt)`);
+  } else {
+    console.log(`  arkivert: ${rep.moves} fil(er) -> archive/`);
+  }
+  if (rep.removedDir) console.log(`  fjernet katalog: ${rep.removedDir}`);
+  console.log(`  ledger: ${actionKey({ operation_type: rep.op, targets: rep.target })} -> ${rep.ledgerStatus}`);
+  console.log(`\nStatus: APPLIED. Verifiser med 'git status' og re-kjør validate/kb-integrity/kb-eval.\n`);
+}
+
+/**
+ * The mutated skill that should be re-scored after an apply. create/sanitize keep
+ * a scorable skill; merge leaves the absorber; retire removes the skill entirely
+ * (nothing to score -> null, gate skipped). Spor D STEG B lifecycle-gate.
+ */
+function affectedSkill(op, targets) {
+  if (op === CREATE_OPERATION) return targets.name;
+  if (op === MERGE_OPERATION) return targets.absorber;
+  if (op === SANITIZE_OPERATION) return targets.skill;
+  return null; // RETIRE: skill removed
+}
+
+/**
+ * Re-score the affected skill from a freshly-built corpus report after a
+ * successful apply and surface a quality verdict. The deterministic floor (K10)
+ * is enforced immediately as a loud warning; an unjudged skill is flagged
+ * provisional with a nudge to re-run the judge pass (the K1 floor cannot be
+ * enforced from the cache alone). The report is built once by the caller and
+ * shared with refreshScoreCache so the corpus is scored a single time.
+ */
+function printQualityGate(report, op, targets) {
+  const affected = affectedSkill(op, targets);
+  if (!affected) {
+    console.log(`\nKvalitetsgate: ingen gjenværende skill å re-score (retire). Hopper over.`);
+    return;
+  }
+  const v = gateSkill(report, affected, { target: QUALITY_TARGET });
+  if (!v.found) {
+    console.log(`\nKvalitetsgate: fant ikke '${affected}' på disk for re-scoring (hoppet over).`);
+    return;
+  }
+  const tags = [];
+  if (v.floored) tags.push('floored');
+  if (v.provisional) tags.push('provisional');
+  const tagStr = tags.length ? ` [${tags.join(', ')}]` : '';
+  if (v.blocked) {
+    console.log(`\n⚠ KVALITETSGATE: '${affected}' scorer ${v.score}/100 — UNDER MÅL ${QUALITY_TARGET} %${tagStr}.`);
+    for (const imp of (v.improvements || []).slice(0, 3)) {
+      const floor = imp.floor ? ' ⚑gulv' : '';
+      console.log(`   ↳ ${imp.key} ${imp.label}${floor} (${imp.detail}) [-${imp.pointsLost.toFixed(2)}] → ${imp.fix}`);
+    }
+    console.log(`  Rett før commit, eller dokumenter avviket eksplisitt.`);
+  } else {
+    console.log(`\nKvalitetsgate: '${affected}' scorer ${v.score}/100 — OK (≥${QUALITY_TARGET} %)${tagStr}.`);
+  }
+  if (v.provisional) {
+    console.log(`  ℹ judge-cache mangler/utdatert for '${affected}' → K1-gulv ikke håndhevet. Kjør judge-passet (scripts/kb-eval/judge-prompt.md) og re-merge data/judge-results.json, deretter re-score.`);
+  }
+}
+
+/**
+ * Regenerate the WHOLE-CORPUS score-cache from a freshly-built report after a
+ * successful mutation, so the STEG C SessionStart surfacing reflects the new disk
+ * immediately. Whole-corpus on purpose: retire drops a skill, create adds one, and
+ * merge/sanitize shift sibling K10 — the cache is independent of WHICH skill
+ * changed. Pure scoring (scoreReport/buildScoreCache); only the write touches disk.
+ * generatedAt is injectable so tests stay deterministic.
+ * @param {{skills: object[]}} report  buildReport() output (fresh disk)
+ * @param {{cachePath?: string, generatedAt?: string}} [opts]
+ * @returns {object} the cache object that was written
+ */
+export function refreshScoreCache(report, opts = {}) {
+  const cachePath = opts.cachePath ?? SCORE_CACHE_FILE;
+  const generatedAt = opts.generatedAt ?? new Date().toISOString().slice(0, 10);
+  const cache = buildScoreCache(scoreReport(report, { target: QUALITY_TARGET }), { generatedAt });
+  writeFileSync(cachePath, JSON.stringify(cache, null, 2) + '\n');
+  return cache;
+}
+
+function main() {
+  const args = process.argv.slice(2);
+  const verb = args[0];
+  if (verb === 'list') return listApproved();
+
+  const positional = args.filter((a) => !a.startsWith('--'));
+  const apply = args.includes('--apply');
+  const dateIdx = args.indexOf('--date');
+  const decided_at = dateIdx >= 0 ? args[dateIdx + 1] : new Date().toISOString().slice(0, 10);
+
+  const op = OP_BY_VERB[verb];
+  if (!op) {
+    console.error(USAGE);
+    process.exit(2);
+  }
+
+  // Resolve targets + ledger key per op arity (merge takes two skills; create
+  // is keyed on its new name; sanitize/retire on their one skill).
+  let targets, label;
+  if (op === MERGE_OPERATION) {
+    if (positional.length < 3) {
+      console.error(USAGE);
+      process.exit(2);
+    }
+    targets = { absorber: positional[1], absorbed: positional[2] };
+    label = `${targets.absorbed} -> ${targets.absorber}`;
+  } else if (op === CREATE_OPERATION) {
+    if (positional.length < 2) {
+      console.error(USAGE);
+      process.exit(2);
+    }
+    targets = { name: positional[1] };
+    label = positional[1];
+  } else {
+    if (positional.length < 2) {
+      console.error(USAGE);
+      process.exit(2);
+    }
+    targets = { skill: positional[1] };
+    label = positional[1];
+  }
+  const key = actionKey({ operation_type: op, targets });
+
+  const led = loadDecisions(LEDGER_DATA_DIR);
+  const entry = led.actions?.[key];
+  if (!entry) {
+    console.error(`Fant ingen ledger-handling "${key}". Kjør 'apply-skill-op.mjs list' for å se godkjente.`);
+    process.exit(1);
+  }
+  if (entry.status !== 'approved') {
+    console.error(`Handling "${key}" har status "${entry.status}" (må være "approved"). Avbryter.`);
+    process.exit(1);
+  }
+
+  // retire + merge both consult the taxonomy (owned-category awareness / repoint);
+  // create re-supplies its scaffold spec + K10 siblings for drift-safe revalidation.
+  const needsTaxonomy = op === RETIRE_OPERATION || op === MERGE_OPERATION;
+  const isCreate = op === CREATE_OPERATION;
+  const res = applyApprovedAction(entry, {
+    pluginRoot: PLUGIN_ROOT,
+    skillsDir: SKILLS_DIR,
+    agentsDir: AGENTS_DIR,
+    dataDir: LEDGER_DATA_DIR,
+    taxonomyDataDir: LEDGER_DATA_DIR,
+    apply,
+    decided_at: apply ? decided_at : null,
+    categorySkill: needsTaxonomy ? loadTaxonomy(LEDGER_DATA_DIR).category_skill : undefined,
+    createSpec: isCreate ? { description: TEST_DOMAIN_SPEC.description, categories: TEST_DOMAIN_SPEC.categories } : undefined,
+    existingDescriptions: isCreate ? loadDescriptions() : undefined,
+    promptSet: isCreate ? loadPromptSet() : undefined,
+  });
+  printResult(res, verb, label, apply);
+
+  // STEG B+1: after a real mutation, build the corpus report ONCE and reuse it for
+  // both the affected-skill gate (STEG B) and the whole-corpus score-cache refresh
+  // (STEG 1) — so the STEG C SessionStart surfacing reflects the new disk instead of
+  // going stale until the next manual `score-skill.mjs --write`. Preview never
+  // mutates -> nothing to re-score/refresh, so both run only on applied mutations.
+  if (res.applied) {
+    const report = buildReport();
+    printQualityGate(report, op, targets);
+    const cache = refreshScoreCache(report);
+    console.log(`\n↻ Score-cache oppdatert → ${SCORE_CACHE_FILE} (${cache.scored.length} skills, ${cache.below.length} under mål).`);
+  }
+}
+
+if (process.argv[1] && fileURLToPath(import.meta.url) === process.argv[1]) {
+  main();
+}

scripts/kb-eval/build-gold-set.mjs

@@ -0,0 +1,139 @@
+#!/usr/bin/env node
+// build-gold-set.mjs — Fase 0, steg 2/3 glue: assemble the gold correctness set.
+//
+// Consolidates the per-batch verification returns (scripts/kb-eval/data/
+// fase0-returns/batch-*.json — produced by Opus 4.8 subagents that checked each
+// volatile claim against live MS Learn) into a single, reusable gold set, and
+// joins the DETERMINISTIC lastmod_changed signal in code (never an LLM call):
+// for each file, did any cited source change on the MS Learn sitemap after the
+// file's own "last updated" date? That is exactly what the existing KB staleness
+// loop sees, so it tells us which genuine errors a correctness judge would catch
+// that the staleness loop would miss.
+//
+// The non-trivial logic (date parse, lastmod comparison) lives in tested
+// lib/base-rate.mjs; this CLI is thin wiring over it.
+//
+// Usage:  node scripts/kb-eval/build-gold-set.mjs [--write]
+//   (default: print summary; --write: persist gold-correctness-set.json)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { parseLastUpdated, fileLastmodChanged } from './lib/base-rate.mjs';
+import { lintGoldConsistency } from './lib/gold-consistency.mjs';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const ROOT = path.resolve(__dirname, '..', '..');
+const DATA = path.join(__dirname, 'data');
+const RETURNS = path.join(DATA, 'fase0-returns');
+
+const frame = JSON.parse(fs.readFileSync(path.join(DATA, 'fase0-sample-frame.json'), 'utf8'));
+const registry = JSON.parse(
+  fs.readFileSync(path.join(ROOT, 'scripts/kb-update/data/url-registry.json'), 'utf8'),
+);
+
+// file -> citedUrls (from the deterministic sample frame)
+const citedByFile = {};
+for (const e of [...frame.volatile, ...frame.control]) citedByFile[e.file] = e.citedUrls;
+
+// file -> { date, lastmod_changed } (read each file once)
+const fileMeta = {};
+function metaFor(file) {
+  if (fileMeta[file]) return fileMeta[file];
+  let date = null;
+  try {
+    date = parseLastUpdated(fs.readFileSync(path.join(ROOT, file), 'utf8'));
+  } catch {
+    date = null;
+  }
+  const changed = fileLastmodChanged(citedByFile[file] || [], registry, date);
+  return (fileMeta[file] = { date, lastmod_changed: changed });
+}
+
+// relpath after skills/<skill>/references/ for a compact, stable claim id
+function relOf(file, skill) {
+  const prefix = `skills/${skill}/references/`;
+  return file.startsWith(prefix) ? file.slice(prefix.length) : file;
+}
+
+const claims = [];
+const batchFiles = fs.readdirSync(RETURNS).filter((f) => /^batch-\d+\.json$/.test(f)).sort();
+for (const bf of batchFiles) {
+  const batch = JSON.parse(fs.readFileSync(path.join(RETURNS, bf), 'utf8'));
+  for (const c of batch.claims) {
+    const meta = metaFor(c.file);
+    claims.push({
+      id: `${c.skill}/${relOf(c.file, c.skill)}#${c.n}`,
+      file: c.file,
+      skill: c.skill,
+      stratum: c.stratum,
+      claim: c.claim,
+      claim_type: c.claim_type,
+      verdict: c.verdict,
+      evidence_url: c.evidence_url ?? null,
+      lastmod_changed: meta.lastmod_changed,
+      file_last_updated: meta.date,
+      notes: c.notes ?? '',
+    });
+  }
+}
+
+const goldSet = {
+  _meta: {
+    created: '2026-06-26',
+    method:
+      'Per-file volatile-claim verification against live MS Learn by Opus 4.8 subagents (strict v2 evidence rule: correct/outdated/wrong require a fetched learn.microsoft.com quote; otherwise unsourced). lastmod_changed joined deterministically in code from url-registry sitemap_lastmod vs the file last-updated date.',
+    sample_frame: 'fase0-sample-frame.json',
+    raw_returns: 'fase0-returns/batch-*.json',
+    note_evidence_quote:
+      'Per-claim evidence_quote omitted here to bound size; full verbatim quotes live in the session transcript. notes + evidence_url capture each verdict basis.',
+    // G4 (programdok §8 / §3-kjennelse 2026-06-30): nedre-grense-policy for
+    // subagenter som bygger fremtidig gull. En nedre-grense-påstand («100+»,
+    // «200k+») teller som FEIL (outdated/wrong) hvis den GROVT understater
+    // (>~2x, beslutnings-endrende) den sanne verdien; en STRAM nedre grense (sann
+    // verdi i samme størrelsesorden) blir stående correct. Anvendt på FN2 (Spor 2b).
+    lower_bound_policy:
+      'Lower-bound claims (e.g. "100+", "200k+"): verdict=outdated/wrong if the bound grossly understates (>~2x, decision-changing) the true value; a tight bound (true value within the same order of magnitude) stays correct.',
+    // G3 (programdok §8): gull-intern-konsistens. Et verdict=correct-claim hvis
+    // egen `notes` innrømmer at verdien ikke er bekreftet mot kilden («uverifisert
+    // / illustrativ / ikke i kilden») MÅ enten relabel-es ELLER bære et
+    // `consistency_waiver` med begrunnelse. Håndhevet av lint-gold-consistency.mjs.
+    consistency_policy:
+      'verdict=correct claims whose notes admit the value is unverified/illustrative/not-in-source must be relabeled OR carry a consistency_waiver. Enforced by lint-gold-consistency.mjs.',
+    claim_count: claims.length,
+  },
+  claims,
+};
+
+// G3 (programdok §8): gull fødes konsistent. Hard gate kun på --write — et
+// nybygget gull med uwaived selvmotsigende correct-claims (verdict=correct mens
+// noten innrømmer ikke-bekreftet: «uverifisert/illustrativ/ikke i kilden») nektes
+// SKREVET; relabel eller waiver først. Dry-run forhåndsviser (advarer, blokkerer
+// ikke). Escape-hatch --allow-inconsistent (samme idiom som
+// run-judge-bakeoff --allow-incomplete) for bevisst override.
+const consistency = lintGoldConsistency(goldSet);
+
+if (process.argv.includes('--write')) {
+  if (!consistency.ok && !process.argv.includes('--allow-inconsistent')) {
+    console.error(`error: ${consistency.flagged.length} uwaived selvmotsigende correct-claim(s) — gull nektes skrevet (G3):`);
+    for (const f of consistency.flagged) console.error(`  - ${f.id} [${f.markers.join(', ')}]: ${f.notes}`);
+    console.error('Resolver hver (relabel ELLER consistency_waiver), eller --allow-inconsistent for å overstyre.');
+    process.exit(2);
+  }
+  const out = path.join(DATA, 'gold-correctness-set.json');
+  fs.writeFileSync(out, JSON.stringify(goldSet, null, 2) + '\n');
+  console.log(`wrote ${out} (${claims.length} claims)`);
+} else {
+  const filesWithChange = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === true).length;
+  const filesNoChange = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === false).length;
+  const filesUnknown = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === null).length;
+  console.log(`claims: ${claims.length} | files: ${Object.keys(fileMeta).length}`);
+  console.log(`file lastmod_changed: true=${filesWithChange} false=${filesNoChange} unknown(null date)=${filesUnknown}`);
+  if (consistency.ok) {
+    console.log('G3 gull-konsistens: OK (0 uwaived selvmotsigende correct-claims)');
+  } else {
+    console.log(`G3 gull-konsistens: ⚠ ${consistency.flagged.length} uwaived selvmotsigende correct-claim(s) — --write vil nektes:`);
+    for (const f of consistency.flagged) console.log(`  - ${f.id} [${f.markers.join(', ')}]`);
+  }
+  console.log('(dry run — pass --write to persist gold-correctness-set.json)');
+}

scripts/kb-eval/build-judge-payloads.mjs

@@ -0,0 +1,89 @@
+#!/usr/bin/env node
+// build-judge-payloads.mjs — deterministic fan-out prep for the per-claim
+// groundedness judge bake-off. Turns the blind claim manifest + a judge prompt
+// template into 45 ready-to-dispatch subagent payloads (one per file), so the
+// fan-out is reproducible instead of hand-assembled in main context.
+//
+// The v3 fan-out grouped claims by file MANUALLY at dispatch time; that made the
+// exact payloads non-reproducible. This script fixes the construction: same prompt,
+// same per-file claim grouping, every run — so v3.1 (and any future arm) is
+// apples-to-apples and a fresh session can resume with one command, no improvising.
+//
+// Pure string assembly — no LLM, no network, no math. Reads:
+//   data/judge-bakeoff-claims.json   (blind manifest from extract-judge-claims.mjs)
+//   <--prompt>                        (judge-claim-prompt-vN.md, with <FILE>/<CLAIMS>)
+// Writes (with --write):
+//   data/<--out>                      (array of {file, claim_count, prompt})
+//
+// Usage:
+//   node scripts/kb-eval/build-judge-payloads.mjs --prompt judge-claim-prompt-v3.1.md \
+//        --out judge-bakeoff-payloads-v3.1.json [--write]
+//   (default: print per-file claim counts + a sanity sample; --write persists)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const DATA = path.join(__dirname, 'data');
+
+function flag(name, def) {
+  const i = process.argv.indexOf(name);
+  return i >= 0 ? process.argv[i + 1] : def;
+}
+
+const promptName = flag('--prompt');
+if (!promptName) {
+  console.error('error: --prompt <judge-claim-prompt-vN.md> is required');
+  process.exit(2);
+}
+const promptPath = path.isAbsolute(promptName) ? promptName : path.join(__dirname, promptName);
+if (!fs.existsSync(promptPath)) {
+  console.error(`error: prompt template not found: ${promptPath}`);
+  process.exit(2);
+}
+const template = fs.readFileSync(promptPath, 'utf8');
+if (!template.includes('<FILE>') || !template.includes('<CLAIMS>')) {
+  console.error('error: prompt template must contain both <FILE> and <CLAIMS> placeholders');
+  process.exit(2);
+}
+
+const manifest = JSON.parse(fs.readFileSync(path.join(DATA, 'judge-bakeoff-claims.json'), 'utf8'));
+const claims = manifest.claims || [];
+
+// Group by file, preserving manifest order (deterministic).
+const byFile = new Map();
+for (const c of claims) {
+  if (!byFile.has(c.file)) byFile.set(c.file, []);
+  byFile.get(c.file).push({
+    id: c.id,
+    claim: c.claim,
+    claim_type: c.claim_type,
+    evidence_url: c.evidence_url || null,
+  });
+}
+
+const payloads = [];
+for (const [file, fileClaims] of byFile) {
+  const claimsBlock = JSON.stringify(fileClaims, null, 2);
+  const prompt = template.split('<FILE>').join(file).split('<CLAIMS>').join(claimsBlock);
+  payloads.push({ file, claim_count: fileClaims.length, prompt });
+}
+
+const totalClaims = payloads.reduce((s, p) => s + p.claim_count, 0);
+
+if (process.argv.includes('--write')) {
+  const outName = flag('--out', `judge-bakeoff-payloads-${path.basename(promptName).replace(/^judge-claim-prompt-/, '').replace(/\.md$/, '')}.json`);
+  const outPath = path.join(DATA, outName);
+  fs.writeFileSync(outPath, JSON.stringify(payloads, null, 2) + '\n');
+  console.log(`wrote ${outPath}`);
+  console.log(`${payloads.length} per-file payloads, ${totalClaims} claims total, prompt=${promptName}`);
+} else {
+  console.log(`prompt template: ${promptName}`);
+  console.log(`${payloads.length} files, ${totalClaims} claims total`);
+  console.log('per-file claim counts:');
+  for (const p of payloads) console.log(`  ${p.claim_count.toString().padStart(2)}  ${p.file}`);
+  console.log(`\nsample payload[0] head (file=${payloads[0].file}):`);
+  console.log(payloads[0].prompt.slice(0, 200) + ' …');
+  console.log('\n(dry run — pass --write to persist)');
+}

scripts/kb-eval/build-sample-frame.mjs

@@ -0,0 +1,265 @@
+#!/usr/bin/env node
+// build-sample-frame.mjs — Fase 0, steg 1: deterministic volatility-weighted,
+// stratified sample frame for ref-file correctness verification.
+//
+// Selects ~45 volatile-dense reference files (oversampling cost/platform/SKU/
+// price/TPM/region/version/preview-dense files across all 5 skills) plus a
+// control stratum of low-volatility methodology/regulatory files. Selection is
+// DETERMINISTIC — same input yields the same frame (no Math.random).
+//
+// The volatility scorer is a RANKING heuristic for sample SELECTION, not the
+// correctness classifier (that is the subagent step against live MS Learn).
+// Its signal set + stable-identifier boundary follow the K9 rule in
+// scripts/kb-eval/judge-prompt.md: regulation years, case numbers, standard
+// version names (OWASP ... 2025, MADR v3.0) and filenames are NOT volatile.
+//
+// Verifiable population = the 306 ref files that cite >=1 MS Learn URL, derived
+// by inverting scripts/kb-update/data/url-registry.json (urls{}.reference_files[]).
+//
+// Usage:
+//   node scripts/kb-eval/build-sample-frame.mjs           # human-readable summary
+//   node scripts/kb-eval/build-sample-frame.mjs --json    # frame JSON to stdout
+//   node scripts/kb-eval/build-sample-frame.mjs --write   # persist data/fase0-sample-frame.json
+//
+// Zero dependencies. Reuses kb-update/lib/atomic-write.mjs for the gated write.
+
+import { readFileSync, existsSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { atomicWriteJson } from '../kb-update/lib/atomic-write.mjs';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const PLUGIN_ROOT = join(__dirname, '..', '..');
+const REGISTRY = join(PLUGIN_ROOT, 'scripts/kb-update/data/url-registry.json');
+const OUT_FILE = join(__dirname, 'data', 'fase0-sample-frame.json');
+
+// --- volatility signal patterns (ranking heuristic; K9 boundary) -------------
+// Stable identifiers deliberately do NOT match: regulation years (2024/1689),
+// case numbers (C-311/18), standard version names (MADR v3.0, OWASP LLM Top 10
+// 2025) and filenames — see judge-prompt.md K9.
+const SIGNAL_PATTERNS = {
+  tpmPtu: /\b(TPM|PTU|tokens?[ -]per[ -]minute|provisioned throughput)\b/gi,
+  price:
+    /(\bNOK\b|\bUSD\b|\bEUR\b|\$\s?\d|\bkr\b|per\s?1[ ,.]?0{3,}\s?tokens|per\s?1\s?[MK]\b|\/month|\/m[åa]ned)/gi,
+  sku: /\b(SKU|GlobalStandard|DataZoneStandard|DataZone|Pay-?as-?you-?go|PayGo|provisioned deployment|deployment type)\b/gi,
+  region:
+    /\b(East US|West US|West Europe|North Europe|Sweden Central|Norway East|norwayeast|swedencentral|region(?:al)? availability|available in (?:the )?following regions)\b/gi,
+  version:
+    /\b(GPT-[0-9](?:\.[0-9])?|GPT-4o|o1|o3|o4-mini|Claude\s?[0-9]|Gemini\s?[0-9]|text-embedding-[0-9]|api-version=\d{4}-\d{2}-\d{2})\b/gi,
+  previewGa: /(public preview|private preview|in preview|\(preview\)|generally available|now available)/gi,
+};
+const SIGNAL_WEIGHTS = { tpmPtu: 3, price: 2, sku: 2, region: 2, version: 3, previewGa: 2 };
+const PATH_BOOST = { 'cost-optimization': 5, platforms: 5 };
+
+/** Skill name from a `skills/<skill>/references/...` path, else ''. */
+export function skillOf(relpath) {
+  const m = /^skills\/([^/]+)\/references\//.exec(relpath);
+  return m ? m[1] : '';
+}
+
+/** Immediate folder under `references/`, else '' (file sits directly in references/). */
+export function topFolder(relpath) {
+  const m = /^skills\/[^/]+\/references\/([^/]+)\//.exec(relpath);
+  return m ? m[1] : '';
+}
+
+/** Count volatility-signal hits in text; weighted sum = ranking score. */
+export function scoreVolatility(text) {
+  const signals = {};
+  let score = 0;
+  for (const [key, pat] of Object.entries(SIGNAL_PATTERNS)) {
+    const matches = text.match(pat);
+    const n = matches ? matches.length : 0;
+    signals[key] = n;
+    score += n * SIGNAL_WEIGHTS[key];
+  }
+  return { score, signals };
+}
+
+/** Path-based boost for volatility-dense folders (cost-optimization, platforms). */
+export function pathBoost(relpath) {
+  return PATH_BOOST[topFolder(relpath)] || 0;
+}
+
+/** Total ranking score for a file = content volatility + path boost. */
+export function fileScore({ relpath, text }) {
+  return scoreVolatility(text).score + pathBoost(relpath);
+}
+
+/**
+ * Apportion `total` selections across skills: a floor per skill (balance) plus
+ * the remainder distributed by volatility mass (oversample dense skills), using
+ * largest-remainder apportionment. Deterministic — ties broken by skill name.
+ */
+export function allocateQuota(massBySkill, total, floorPerSkill) {
+  const skills = Object.keys(massBySkill).sort();
+  const quotas = {};
+  for (const s of skills) quotas[s] = floorPerSkill;
+  let remaining = total - floorPerSkill * skills.length;
+  if (remaining <= 0) return quotas;
+  const totalMass = skills.reduce((sum, s) => sum + massBySkill[s], 0);
+  if (totalMass <= 0) {
+    // no mass signal — distribute round-robin deterministically by skill name
+    let i = 0;
+    while (remaining > 0) {
+      quotas[skills[i % skills.length]] += 1;
+      remaining--;
+      i++;
+    }
+    return quotas;
+  }
+  const shares = skills.map((s) => {
+    const exact = (massBySkill[s] / totalMass) * remaining;
+    const base = Math.floor(exact);
+    return { s, base, frac: exact - base };
+  });
+  for (const sh of shares) {
+    quotas[sh.s] += sh.base;
+    remaining -= sh.base;
+  }
+  shares.sort((a, b) => b.frac - a.frac || (a.s < b.s ? -1 : 1));
+  for (let i = 0; i < shares.length && remaining > 0; i++) {
+    quotas[shares[i].s] += 1;
+    remaining--;
+  }
+  return quotas;
+}
+
+const byScoreThenPath = (a, b) =>
+  b.score - a.score || (a.file < b.file ? -1 : a.file > b.file ? 1 : 0);
+
+/**
+ * Split scored files into a volatile stratum (~volatileTarget, balanced across
+ * skills, oversampling dense ones) and a control stratum (low-volatility files
+ * from controlFolders). Deterministic.
+ */
+export function stratify(scored, cfg) {
+  const controlSet = new Set();
+  const control = scored
+    .filter((f) => cfg.controlFolders.includes(f.topFolder) && f.score <= cfg.controlMaxScore)
+    .sort((a, b) => a.score - b.score || (a.file < b.file ? -1 : a.file > b.file ? 1 : 0))
+    .slice(0, cfg.controlTarget)
+    .map((f) => {
+      controlSet.add(f.file);
+      return { ...f, stratum: 'control' };
+    });
+
+  const pool = scored.filter((f) => !controlSet.has(f.file) && f.skill);
+  const bySkill = {};
+  const massBySkill = {};
+  for (const f of pool) {
+    (bySkill[f.skill] ||= []).push(f);
+    massBySkill[f.skill] = (massBySkill[f.skill] || 0) + f.score;
+  }
+  const quotas = allocateQuota(massBySkill, cfg.volatileTarget, cfg.floorPerSkill);
+  const volatile = [];
+  for (const skill of Object.keys(bySkill).sort()) {
+    for (const f of bySkill[skill].sort(byScoreThenPath).slice(0, quotas[skill] || 0)) {
+      volatile.push({ ...f, stratum: 'volatile' });
+    }
+  }
+  volatile.sort(byScoreThenPath);
+  return { volatile, control };
+}
+
+// --- CLI / frame assembly ----------------------------------------------------
+const CFG = {
+  volatileTarget: 45,
+  floorPerSkill: 5,
+  // Control = stable-claim folders (the real analogues of the contract's
+  // "methodology/regulatory"): responsible-AI principles, Norwegian public-sector
+  // governance/law, and architecture methodology. Filtered to low volatility score
+  // so the control stratum measures the stable-claim sanity rate, not volatile churn.
+  controlFolders: ['responsible-ai', 'norwegian-public-sector-governance', 'architecture'],
+  controlMaxScore: 4,
+  controlTarget: 10,
+};
+
+/** Invert url-registry → Map(reference_file -> sorted unique cited URLs). */
+function invertRegistry() {
+  const reg = JSON.parse(readFileSync(REGISTRY, 'utf8'));
+  const inv = new Map();
+  for (const [url, meta] of Object.entries(reg.urls || {})) {
+    for (const rf of meta.reference_files || []) {
+      if (!inv.has(rf)) inv.set(rf, new Set());
+      inv.get(rf).add(url);
+    }
+  }
+  return inv;
+}
+
+function scoreSourcedFiles() {
+  const inv = invertRegistry();
+  const scored = [];
+  for (const [relpath, urlSet] of inv) {
+    const abs = join(PLUGIN_ROOT, relpath);
+    if (!existsSync(abs)) continue; // sourced file since deleted — skip
+    const text = readFileSync(abs, 'utf8');
+    const { score, signals } = scoreVolatility(text);
+    scored.push({
+      file: relpath,
+      skill: skillOf(relpath),
+      topFolder: topFolder(relpath),
+      score: score + pathBoost(relpath),
+      signals,
+      citedUrls: [...urlSet].sort(),
+    });
+  }
+  return scored;
+}
+
+function buildFrame() {
+  const scored = scoreSourcedFiles();
+  const { volatile, control } = stratify(scored, CFG);
+  const stamp = new Date().toISOString();
+  return {
+    _meta: {
+      created: stamp,
+      method:
+        'volatility-weighted stratified selection; deterministic (no random). ' +
+        'Scorer is a ranking heuristic for sample selection, not the correctness classifier.',
+      population: scored.length,
+      volatile_count: volatile.length,
+      control_count: control.length,
+      config: CFG,
+      signal_weights: SIGNAL_WEIGHTS,
+    },
+    volatile,
+    control,
+  };
+}
+
+function summarize(frame) {
+  const perSkill = {};
+  for (const f of [...frame.volatile, ...frame.control]) {
+    const k = `${f.skill}/${f.stratum}`;
+    perSkill[k] = (perSkill[k] || 0) + 1;
+  }
+  console.log(`Sourced population: ${frame._meta.population} files`);
+  console.log(`Volatile stratum:   ${frame.volatile.length}`);
+  console.log(`Control stratum:    ${frame.control.length}`);
+  console.log('\nPer skill / stratum:');
+  for (const k of Object.keys(perSkill).sort()) console.log(`  ${k.padEnd(34)} ${perSkill[k]}`);
+  console.log('\nTop 10 volatile (score · file):');
+  for (const f of frame.volatile.slice(0, 10)) {
+    console.log(`  ${String(f.score).padStart(4)}  ${f.file}`);
+  }
+}
+
+function main() {
+  const args = process.argv.slice(2);
+  const frame = buildFrame();
+  if (args.includes('--json')) {
+    process.stdout.write(JSON.stringify(frame, null, 2) + '\n');
+    return;
+  }
+  summarize(frame);
+  if (args.includes('--write')) {
+    atomicWriteJson(OUT_FILE, frame);
+    console.log(`\nWrote ${OUT_FILE}`);
+  } else {
+    console.log('\n(dry run — pass --write to persist data/fase0-sample-frame.json)');
+  }
+}
+
+if (import.meta.url === `file://${process.argv[1]}`) main();

scripts/kb-eval/compute-base-rate.mjs

@@ -0,0 +1,102 @@
+#!/usr/bin/env node
+// compute-base-rate.mjs — Fase 0, steg 3 glue: turn the gold correctness set into
+// a defensible base-rate report (the directional input for the Fase 3 gate).
+//
+// All non-trivial math (verifiable error rate, Wilson bands, the staleness-
+// catchable vs judge-unique split) lives in tested lib/base-rate.mjs. This CLI is
+// thin wiring: read gold-correctness-set.json -> computeBaseRate() -> write a
+// machine-readable .json and a human-readable .md. Same shape as build-gold-set.mjs.
+//
+// Usage:  node scripts/kb-eval/compute-base-rate.mjs [--write]
+//   (default: print the overall + per-stratum summary; --write persists
+//    data/base-rate-report.json and data/base-rate-report.md)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { computeBaseRate } from './lib/base-rate.mjs';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const DATA = path.join(__dirname, 'data');
+
+const gold = JSON.parse(fs.readFileSync(path.join(DATA, 'gold-correctness-set.json'), 'utf8'));
+const claims = gold.claims;
+const report = computeBaseRate(claims);
+
+const pct = (x) => `${(x * 100).toFixed(1)}%`;
+const band = (w) => `[${pct(w.low)}, ${pct(w.high)}]`;
+
+// One row of the per-dimension tables. b = a finalized bucket from the lib.
+function row(key, b) {
+  const v = b.byVerdict;
+  return `| ${key} | ${b.total} | ${v.correct} | ${v.outdated} | ${v.wrong} | ${v.unsourced} | ${b.errors}/${b.verifiable} = ${pct(b.errorRate)} | ${band(b.errorRateWilson)} | ${b.errorsJudgeUnique} |`;
+}
+const HEAD =
+  '| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |\n' +
+  '|---|---|---|---|---|---|---|---|---|';
+
+// Sort dimension entries by descending total so the heaviest buckets read first.
+function table(title, byKey) {
+  const rows = Object.entries(byKey)
+    .sort((a, b) => b[1].total - a[1].total)
+    .map(([k, b]) => row(k, b));
+  return `### ${title}\n\n${HEAD}\n${rows.join('\n')}\n`;
+}
+
+const o = report.overall;
+const md = `# Base-rate-rapport — Fase 0 (KB korrekthet)
+
+_Generert deterministisk av \`compute-base-rate.mjs\` over \`gold-correctness-set.json\`. Tall fra testet \`lib/base-rate.mjs\` (15 tester). Ikke rediger for hånd — regenerer._
+
+**Gull-sett:** ${claims.length} påstander · metode: ${gold._meta?.method ? 'se gold-correctness-set.json `_meta.method`' : 'n/a'}
+
+## Verdict-vokabular
+
+- **correct** — en hentet learn.microsoft.com-side oppgir den påståtte verdien
+- **outdated** — hentet kilde viser en annen, erstattet verdi (tidsdrift)
+- **wrong** — hentet kilde motsier påstanden; den var aldri korrekt
+- **unsourced** — ingen hentbar MS Learn-side oppgir verdien (kan ikke verifiseres)
+
+«Reelle feil» = outdated + wrong. **unsourced er IKKE en feil** — det er den uverifiserbare massen (priser på JS-rendrede Azure-sider som en fetch-basert judge heller ikke når). Den verifiserbare feilraten ekskluderer derfor unsourced fra nevneren.
+
+## Overall
+
+| metrikk | verdi |
+|---|---|
+| Påstander totalt | ${o.total} |
+| correct / outdated / wrong / unsourced | ${o.byVerdict.correct} / ${o.byVerdict.outdated} / ${o.byVerdict.wrong} / ${o.byVerdict.unsourced} |
+| Reelle feil (outdated+wrong) | ${o.errors} |
+| Verifiserbare påstander (nevner) | ${o.verifiable} |
+| **Verifiserbar feilrate** | **${o.errors}/${o.verifiable} = ${pct(o.errorRate)}** |
+| Wilson 95 % | ${band(o.errorRateWilson)} |
+| Unsourced-andel | ${o.unsourced}/${o.total} = ${pct(o.unsourcedRate)} |
+| Feil staleness-loopen fanger (lastmod_changed=true) | ${o.errorsStalenessCatchable} |
+| **Feil kun en korrekthets-judge fanger (judge-unique)** | **${o.errorsJudgeUnique}** |
+
+> **Gate-kritisk:** \`errorsJudgeUnique\` = reelle feil hvis siterte kilde-lastmod IKKE endret seg etter fildato — den eneste klassen en korrekthets-judge fanger som den eksisterende staleness-loopen bommer på. Staleness-recall på de reelle feilene = ${o.errors ? `${o.errorsStalenessCatchable}/${o.errors} = ${pct(o.errorsStalenessCatchable / o.errors)}` : 'n/a'}.
+
+## Per stratum
+
+${table('Stratum', report.byStratum)}
+## Per skill
+
+${table('Skill', report.bySkill)}
+## Per claim_type
+
+${table('Claim type', report.byClaimType)}
+`;
+
+if (process.argv.includes('--write')) {
+  const jsonOut = path.join(DATA, 'base-rate-report.json');
+  const mdOut = path.join(DATA, 'base-rate-report.md');
+  fs.writeFileSync(jsonOut, JSON.stringify({ _meta: { source: 'gold-correctness-set.json', claim_count: claims.length }, ...report }, null, 2) + '\n');
+  fs.writeFileSync(mdOut, md);
+  console.log(`wrote ${jsonOut}`);
+  console.log(`wrote ${mdOut}`);
+} else {
+  console.log(`claims: ${o.total} | correct=${o.byVerdict.correct} outdated=${o.byVerdict.outdated} wrong=${o.byVerdict.wrong} unsourced=${o.byVerdict.unsourced}`);
+  console.log(`verifiable error rate: ${o.errors}/${o.verifiable} = ${pct(o.errorRate)}  Wilson ${band(o.errorRateWilson)}`);
+  console.log(`unsourced: ${o.unsourced}/${o.total} = ${pct(o.unsourcedRate)}`);
+  console.log(`staleness-catchable=${o.errorsStalenessCatchable}  judge-unique=${o.errorsJudgeUnique}`);
+  console.log('(dry run — pass --write to persist base-rate-report.json + .md)');
+}

scripts/kb-eval/data/base-rate-report.json

@@ -0,0 +1,333 @@
+{
+  "_meta": {
+    "source": "gold-correctness-set.json",
+    "claim_count": 373
+  },
+  "overall": {
+    "total": 373,
+    "byVerdict": {
+      "correct": 259,
+      "outdated": 29,
+      "wrong": 11,
+      "unsourced": 74
+    },
+    "errors": 40,
+    "verifiable": 299,
+    "unsourced": 74,
+    "errorsStalenessCatchable": 0,
+    "errorsJudgeUnique": 40,
+    "errorRate": 0.13377926421404682,
+    "errorRateWilson": {
+      "p": 0.13377926421404682,
+      "low": 0.0998039899711332,
+      "high": 0.17704568986149216
+    },
+    "unsourcedRate": 0.19839142091152814
+  },
+  "bySkill": {
+    "ms-ai-advisor": {
+      "total": 79,
+      "byVerdict": {
+        "correct": 59,
+        "outdated": 7,
+        "wrong": 2,
+        "unsourced": 11
+      },
+      "errors": 9,
+      "verifiable": 68,
+      "unsourced": 11,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 9,
+      "errorRate": 0.1323529411764706,
+      "errorRateWilson": {
+        "p": 0.1323529411764706,
+        "low": 0.07122163958543326,
+        "high": 0.2328027696704853
+      },
+      "unsourcedRate": 0.13924050632911392
+    },
+    "ms-ai-engineering": {
+      "total": 86,
+      "byVerdict": {
+        "correct": 54,
+        "outdated": 9,
+        "wrong": 4,
+        "unsourced": 19
+      },
+      "errors": 13,
+      "verifiable": 67,
+      "unsourced": 19,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 13,
+      "errorRate": 0.19402985074626866,
+      "errorRateWilson": {
+        "p": 0.19402985074626866,
+        "low": 0.11705063857457099,
+        "high": 0.3041933762415822
+      },
+      "unsourcedRate": 0.22093023255813954
+    },
+    "ms-ai-governance": {
+      "total": 76,
+      "byVerdict": {
+        "correct": 52,
+        "outdated": 5,
+        "wrong": 2,
+        "unsourced": 17
+      },
+      "errors": 7,
+      "verifiable": 59,
+      "unsourced": 17,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 7,
+      "errorRate": 0.11864406779661017,
+      "errorRateWilson": {
+        "p": 0.11864406779661017,
+        "low": 0.058675082779140006,
+        "high": 0.22523875773415053
+      },
+      "unsourcedRate": 0.2236842105263158
+    },
+    "ms-ai-infrastructure": {
+      "total": 36,
+      "byVerdict": {
+        "correct": 29,
+        "outdated": 1,
+        "wrong": 2,
+        "unsourced": 4
+      },
+      "errors": 3,
+      "verifiable": 32,
+      "unsourced": 4,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 3,
+      "errorRate": 0.09375,
+      "errorRateWilson": {
+        "p": 0.09375,
+        "low": 0.032400962626319516,
+        "high": 0.24218499335778831
+      },
+      "unsourcedRate": 0.1111111111111111
+    },
+    "ms-ai-security": {
+      "total": 96,
+      "byVerdict": {
+        "correct": 65,
+        "outdated": 7,
+        "wrong": 1,
+        "unsourced": 23
+      },
+      "errors": 8,
+      "verifiable": 73,
+      "unsourced": 23,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.1095890410958904,
+      "errorRateWilson": {
+        "p": 0.1095890410958904,
+        "low": 0.0565860416101191,
+        "high": 0.20162825897706282
+      },
+      "unsourcedRate": 0.23958333333333334
+    }
+  },
+  "byStratum": {
+    "volatile": {
+      "total": 331,
+      "byVerdict": {
+        "correct": 222,
+        "outdated": 28,
+        "wrong": 10,
+        "unsourced": 71
+      },
+      "errors": 38,
+      "verifiable": 260,
+      "unsourced": 71,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 38,
+      "errorRate": 0.14615384615384616,
+      "errorRateWilson": {
+        "p": 0.14615384615384616,
+        "low": 0.1083692375274728,
+        "high": 0.1942426326249217
+      },
+      "unsourcedRate": 0.21450151057401812
+    },
+    "control": {
+      "total": 42,
+      "byVerdict": {
+        "correct": 37,
+        "outdated": 1,
+        "wrong": 1,
+        "unsourced": 3
+      },
+      "errors": 2,
+      "verifiable": 39,
+      "unsourced": 3,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 2,
+      "errorRate": 0.05128205128205128,
+      "errorRateWilson": {
+        "p": 0.05128205128205128,
+        "low": 0.014177657646399527,
+        "high": 0.1688593904563791
+      },
+      "unsourcedRate": 0.07142857142857142
+    }
+  },
+  "byClaimType": {
+    "version": {
+      "total": 33,
+      "byVerdict": {
+        "correct": 24,
+        "outdated": 6,
+        "wrong": 2,
+        "unsourced": 1
+      },
+      "errors": 8,
+      "verifiable": 32,
+      "unsourced": 1,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.25,
+      "errorRateWilson": {
+        "p": 0.25,
+        "low": 0.13252243982621553,
+        "high": 0.4210689177024662
+      },
+      "unsourcedRate": 0.030303030303030304
+    },
+    "tpm": {
+      "total": 30,
+      "byVerdict": {
+        "correct": 20,
+        "outdated": 4,
+        "wrong": 1,
+        "unsourced": 5
+      },
+      "errors": 5,
+      "verifiable": 25,
+      "unsourced": 5,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 5,
+      "errorRate": 0.2,
+      "errorRateWilson": {
+        "p": 0.2,
+        "low": 0.08860454100652485,
+        "high": 0.3913133553653825
+      },
+      "unsourcedRate": 0.16666666666666666
+    },
+    "region": {
+      "total": 20,
+      "byVerdict": {
+        "correct": 15,
+        "outdated": 2,
+        "wrong": 0,
+        "unsourced": 3
+      },
+      "errors": 2,
+      "verifiable": 17,
+      "unsourced": 3,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 2,
+      "errorRate": 0.11764705882352941,
+      "errorRateWilson": {
+        "p": 0.11764705882352941,
+        "low": 0.03287908001292092,
+        "high": 0.3433684249770991
+      },
+      "unsourcedRate": 0.15
+    },
+    "status": {
+      "total": 70,
+      "byVerdict": {
+        "correct": 58,
+        "outdated": 4,
+        "wrong": 3,
+        "unsourced": 5
+      },
+      "errors": 7,
+      "verifiable": 65,
+      "unsourced": 5,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 7,
+      "errorRate": 0.1076923076923077,
+      "errorRateWilson": {
+        "p": 0.1076923076923077,
+        "low": 0.05315354431925606,
+        "high": 0.20601533031468616
+      },
+      "unsourcedRate": 0.07142857142857142
+    },
+    "price": {
+      "total": 76,
+      "byVerdict": {
+        "correct": 20,
+        "outdated": 0,
+        "wrong": 0,
+        "unsourced": 56
+      },
+      "errors": 0,
+      "verifiable": 20,
+      "unsourced": 56,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 0,
+      "errorRate": 0,
+      "errorRateWilson": {
+        "p": 0,
+        "low": 0,
+        "high": 0.16113012549493322
+      },
+      "unsourcedRate": 0.7368421052631579
+    },
+    "taxonomy": {
+      "total": 122,
+      "byVerdict": {
+        "correct": 108,
+        "outdated": 7,
+        "wrong": 3,
+        "unsourced": 4
+      },
+      "errors": 10,
+      "verifiable": 118,
+      "unsourced": 4,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 10,
+      "errorRate": 0.0847457627118644,
+      "errorRateWilson": {
+        "p": 0.0847457627118644,
+        "low": 0.046682191106169606,
+        "high": 0.14899481904471476
+      },
+      "unsourcedRate": 0.03278688524590164
+    },
+    "sku": {
+      "total": 22,
+      "byVerdict": {
+        "correct": 14,
+        "outdated": 6,
+        "wrong": 2,
+        "unsourced": 0
+      },
+      "errors": 8,
+      "verifiable": 22,
+      "unsourced": 0,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.36363636363636365,
+      "errorRateWilson": {
+        "p": 0.36363636363636365,
+        "low": 0.19732972772607899,
+        "high": 0.5704865065628195
+      },
+      "unsourcedRate": 0
+    }
+  },
+  "_verdicts": [
+    "correct",
+    "outdated",
+    "wrong",
+    "unsourced"
+  ]
+}

scripts/kb-eval/data/base-rate-report.md

@@ -0,0 +1,66 @@
+# Base-rate-rapport — Fase 0 (KB korrekthet)
+
+_Generert deterministisk av `compute-base-rate.mjs` over `gold-correctness-set.json`. Tall fra testet `lib/base-rate.mjs` (15 tester). Ikke rediger for hånd — regenerer._
+
+**Gull-sett:** 373 påstander · metode: se gold-correctness-set.json `_meta.method`
+
+## Verdict-vokabular
+
+- **correct** — en hentet learn.microsoft.com-side oppgir den påståtte verdien
+- **outdated** — hentet kilde viser en annen, erstattet verdi (tidsdrift)
+- **wrong** — hentet kilde motsier påstanden; den var aldri korrekt
+- **unsourced** — ingen hentbar MS Learn-side oppgir verdien (kan ikke verifiseres)
+
+«Reelle feil» = outdated + wrong. **unsourced er IKKE en feil** — det er den uverifiserbare massen (priser på JS-rendrede Azure-sider som en fetch-basert judge heller ikke når). Den verifiserbare feilraten ekskluderer derfor unsourced fra nevneren.
+
+## Overall
+
+| metrikk | verdi |
+|---|---|
+| Påstander totalt | 373 |
+| correct / outdated / wrong / unsourced | 259 / 29 / 11 / 74 |
+| Reelle feil (outdated+wrong) | 40 |
+| Verifiserbare påstander (nevner) | 299 |
+| **Verifiserbar feilrate** | **40/299 = 13.4%** |
+| Wilson 95 % | [10.0%, 17.7%] |
+| Unsourced-andel | 74/373 = 19.8% |
+| Feil staleness-loopen fanger (lastmod_changed=true) | 0 |
+| **Feil kun en korrekthets-judge fanger (judge-unique)** | **40** |
+
+> **Gate-kritisk:** `errorsJudgeUnique` = reelle feil hvis siterte kilde-lastmod IKKE endret seg etter fildato — den eneste klassen en korrekthets-judge fanger som den eksisterende staleness-loopen bommer på. Staleness-recall på de reelle feilene = 0/40 = 0.0%.
+
+## Per stratum
+
+### Stratum
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| volatile | 331 | 222 | 28 | 10 | 71 | 38/260 = 14.6% | [10.8%, 19.4%] | 38 |
+| control | 42 | 37 | 1 | 1 | 3 | 2/39 = 5.1% | [1.4%, 16.9%] | 2 |
+
+## Per skill
+
+### Skill
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| ms-ai-security | 96 | 65 | 7 | 1 | 23 | 8/73 = 11.0% | [5.7%, 20.2%] | 8 |
+| ms-ai-engineering | 86 | 54 | 9 | 4 | 19 | 13/67 = 19.4% | [11.7%, 30.4%] | 13 |
+| ms-ai-advisor | 79 | 59 | 7 | 2 | 11 | 9/68 = 13.2% | [7.1%, 23.3%] | 9 |
+| ms-ai-governance | 76 | 52 | 5 | 2 | 17 | 7/59 = 11.9% | [5.9%, 22.5%] | 7 |
+| ms-ai-infrastructure | 36 | 29 | 1 | 2 | 4 | 3/32 = 9.4% | [3.2%, 24.2%] | 3 |
+
+## Per claim_type
+
+### Claim type
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| taxonomy | 122 | 108 | 7 | 3 | 4 | 10/118 = 8.5% | [4.7%, 14.9%] | 10 |
+| price | 76 | 20 | 0 | 0 | 56 | 0/20 = 0.0% | [0.0%, 16.1%] | 0 |
+| status | 70 | 58 | 4 | 3 | 5 | 7/65 = 10.8% | [5.3%, 20.6%] | 7 |
+| version | 33 | 24 | 6 | 2 | 1 | 8/32 = 25.0% | [13.3%, 42.1%] | 8 |
+| tpm | 30 | 20 | 4 | 1 | 5 | 5/25 = 20.0% | [8.9%, 39.1%] | 5 |
+| sku | 22 | 14 | 6 | 2 | 0 | 8/22 = 36.4% | [19.7%, 57.0%] | 8 |
+| region | 20 | 15 | 2 | 0 | 3 | 2/17 = 11.8% | [3.3%, 34.3%] | 2 |
+

scripts/kb-eval/data/eval-baseline.json

@@ -0,0 +1,525 @@
+{
+  "rubric": "K1-K10",
+  "note": "Deterministic: K2,K3,K5,K6,refCountConsistency,K10(siblingScopeOverlap). LLM-judge (operator-gated): K1,K4,K7,K8,K9.",
+  "skills": [
+    {
+      "name": "ms-ai-advisor",
+      "skillMd": "skills/ms-ai-advisor/SKILL.md",
+      "refFilesActual": 62,
+      "refCountsPerFolder": {
+        "architecture": 16,
+        "copilot-extensibility": 22,
+        "development": 1,
+        "platforms": 5,
+        "prompt-engineering": 18
+      },
+      "deterministic": {
+        "K2_descriptionFormat": {
+          "quotedPhrases": 6,
+          "useWhenForm": true,
+          "imperativeStart": false,
+          "pass": true
+        },
+        "K3_bodyLength": {
+          "bodyLines": 245,
+          "pass": true
+        },
+        "K5_progressiveDisclosure": {
+          "namedFileLinks": 25,
+          "folderRefs": 5,
+          "totalRefFiles": 62,
+          "namedRatio": 0.4032,
+          "pass": true,
+          "sampleNamed": [
+            "references/architecture/diagram-prompt-templates.md",
+            "references/platforms/azure-ai-foundry.md",
+            "references/platforms/m365-copilot.md",
+            "references/platforms/copilot-studio.md",
+            "references/platforms/power-platform.md"
+          ]
+        },
+        "K6_routingTable": {
+          "namedStartFiles": 25,
+          "pass": true
+        },
+        "refCountConsistency": {
+          "consistent": true,
+          "mismatches": []
+        },
+        "K9_timeSensitiveHints": {
+          "timeSensitiveTokenHits": 8,
+          "sample": [
+            "Preview",
+            "GA",
+            "preview",
+            "2026",
+            "v3.0"
+          ]
+        },
+        "K10_siblingScopeOverlap": {
+          "maxCombined": 4.5833,
+          "worstSibling": "ms-ai-engineering",
+          "pass": true,
+          "threshold": 7
+        }
+      },
+      "judgeInputs": {
+        "description": "Microsoft AI platform selection — choosing between Azure AI Foundry, M365 Copilot, Copilot Studio, Power Platform, Azure OpenAI, and Microsoft Agent Framework for a given scenario. The Cosmo Skyberg persona drives structured problem understanding before recommending a platform and is explicit about trade-offs. Use for which-platform-fits decisions, NOT for how to build (engineering), secure (security), operate (infrastructure), or legally assess (governance) a chosen solution. Triggers on: \"which Microsoft AI platform\", \"Copilot vs Foundry\", \"Copilot Studio or Azure AI Foundry\", \"help me choose an AI platform\", \"Cosmo\", \"/architect\".",
+        "bodyLines": 245,
+        "refFileSample": [
+          "skills/ms-ai-advisor/references/architecture/adr-template.md",
+          "skills/ms-ai-advisor/references/architecture/ai-utredning-template.md",
+          "skills/ms-ai-advisor/references/architecture/alternativanalyse-methodology.md",
+          "skills/ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md",
+          "skills/ms-ai-advisor/references/architecture/cost-models.md",
+          "skills/ms-ai-advisor/references/architecture/decision-trees.md",
+          "skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md",
+          "skills/ms-ai-advisor/references/architecture/licensing-matrix.md"
+        ]
+      },
+      "judge": {
+        "_updated": "S11 (2026-06-20) — K1 authoritative (blinded judge vs curated 20-set); description tightened against over-trigging",
+        "K1_triggerPrecision": {
+          "provisional": false,
+          "inDomainHitRate": 1,
+          "outDomainFalsePositiveRate": 0,
+          "precision": 1,
+          "pass": true,
+          "misclassified": [],
+          "notes": "S11 authoritative: blinded judge vs operator-curated 20-set. 10/10 in-domain hits, 0/10 false positives. Over-trigging fix VALIDATED — judge cited the new 'NOT for build/secure/operate/legally-assess' exclusion when rejecting all four sibling-domain prompts (engineering/security/governance/infra)."
+        },
+        "K4_noDuplication": {
+          "score": 5,
+          "pass": true,
+          "evidence": "Body = persona + 7-phase workflow + ref-index; no ref detail reproduced. Only internal MCP-table redundancy (SKILL-internal, not SKILL<->ref)."
+        },
+        "K7_imperativeStyle": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "10/10 sampled instruction sentences imperative."
+        },
+        "K8_sourceCitation": {
+          "ratio": 0.8,
+          "pass": true,
+          "notes": "AT THRESHOLD: architecture/decision-trees.md lacks dated header (footer source only). Add dated header to harden margin."
+        },
+        "K9_noTimeSensitive": {
+          "pass": true,
+          "findings": [
+            "Only meta-instructions (preview/GA as dynamic-to-verify) + stable identifiers (M365 SKUs, MADR v3.0). No stale-able product claim in body."
+          ]
+        }
+      }
+    },
+    {
+      "name": "ms-ai-engineering",
+      "skillMd": "skills/ms-ai-engineering/SKILL.md",
+      "refFilesActual": 153,
+      "refCountsPerFolder": {
+        "agent-orchestration": 24,
+        "api-management": 19,
+        "azure-ai-services": 20,
+        "data-engineering": 22,
+        "mlops-genaiops": 22,
+        "multi-modal": 18,
+        "rag-architecture": 28
+      },
+      "deterministic": {
+        "K2_descriptionFormat": {
+          "quotedPhrases": 6,
+          "useWhenForm": true,
+          "imperativeStart": false,
+          "pass": true
+        },
+        "K3_bodyLength": {
+          "bodyLines": 164,
+          "pass": true
+        },
+        "K5_progressiveDisclosure": {
+          "namedFileLinks": 35,
+          "folderRefs": 10,
+          "totalRefFiles": 153,
+          "namedRatio": 0.2288,
+          "pass": true,
+          "sampleNamed": [
+            "references/rag-architecture/rag-core-patterns.md",
+            "references/rag-architecture/agentic-rag-patterns.md",
+            "references/rag-architecture/azure-ai-search-setup.md",
+            "references/rag-architecture/chunking-strategies.md",
+            "references/rag-architecture/hybrid-search-configuration.md"
+          ]
+        },
+        "K6_routingTable": {
+          "namedStartFiles": 35,
+          "pass": true
+        },
+        "refCountConsistency": {
+          "consistent": true,
+          "mismatches": []
+        },
+        "K9_timeSensitiveHints": {
+          "timeSensitiveTokenHits": 3,
+          "sample": [
+            "ga",
+            "preview",
+            "GA"
+          ]
+        },
+        "K10_siblingScopeOverlap": {
+          "maxCombined": 7.4167,
+          "worstSibling": "ms-ai-infrastructure",
+          "pass": false,
+          "threshold": 7
+        }
+      },
+      "judgeInputs": {
+        "description": "Deep technical guidance for building AI solutions in the Microsoft stack — RAG architecture, multi-agent orchestration, Azure AI Services, data engineering with Fabric, MLOps/GenAIOps, multimodal AI, API Management for AI. Triggers on: \"RAG architecture on Azure\", \"multi-agent orchestration pattern\", \"MLOps for generative AI\", \"Azure AI Search\", \"Semantic Kernel agent\", \"Fabric data pipeline\".",
+        "bodyLines": 164,
+        "refFileSample": [
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-compliance-and-audit-trails.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-cost-optimization-strategies.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-ecosystem-and-plugin-marketplace.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-feedback-and-learning-loops.md",
+          "skills/ms-ai-engineering/references/agent-orchestration/agent-latency-optimization.md"
+        ]
+      },
+      "judge": {
+        "_updated": "S11 (2026-06-20) — K1 authoritative (blinded judge vs curated 20-set); K9 prior S10",
+        "K1_triggerPrecision": {
+          "provisional": false,
+          "inDomainHitRate": 1,
+          "outDomainFalsePositiveRate": 0,
+          "precision": 1,
+          "pass": true,
+          "misclassified": [],
+          "notes": "S11 authoritative: blinded judge vs operator-curated 20-set. 10/10 in-domain hits, 0/10 false positives. Clean sibling separation (advisor/governance/security/infra/off-topic not triggered)."
+        },
+        "K4_noDuplication": {
+          "score": 5,
+          "pass": true,
+          "evidence": "S10 re-judge: 7 section intros are orientation prose routing to references/<domain>/ + named kjernefiler; the two body tables (RAG-vs-finetuning, MLOps test-types) have no verbatim row-match in refs. No duplication."
+        },
+        "K7_imperativeStyle": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "10/10 sampled instruction sentences imperative."
+        },
+        "K8_sourceCitation": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "5/5 dated headers across 5 domains; format inconsistent (EN/NO, month vs day granularity)."
+        },
+        "K9_noTimeSensitive": {
+          "pass": true,
+          "findings": []
+        }
+      }
+    },
+    {
+      "name": "ms-ai-governance",
+      "skillMd": "skills/ms-ai-governance/SKILL.md",
+      "refFilesActual": 78,
+      "refCountsPerFolder": {
+        "monitoring-observability": 18,
+        "norwegian-public-sector-governance": 30,
+        "responsible-ai": 30
+      },
+      "deterministic": {
+        "K2_descriptionFormat": {
+          "quotedPhrases": 8,
+          "useWhenForm": true,
+          "imperativeStart": false,
+          "pass": true
+        },
+        "K3_bodyLength": {
+          "bodyLines": 289,
+          "pass": true
+        },
+        "K5_progressiveDisclosure": {
+          "namedFileLinks": 25,
+          "folderRefs": 5,
+          "totalRefFiles": 78,
+          "namedRatio": 0.3205,
+          "pass": true,
+          "sampleNamed": [
+            "references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md",
+            "references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md",
+            "references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md",
+            "references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md",
+            "references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md"
+          ]
+        },
+        "K6_routingTable": {
+          "namedStartFiles": 25,
+          "pass": true
+        },
+        "refCountConsistency": {
+          "consistent": true,
+          "mismatches": []
+        },
+        "K9_timeSensitiveHints": {
+          "timeSensitiveTokenHits": 1,
+          "sample": [
+            "2024"
+          ]
+        },
+        "K10_siblingScopeOverlap": {
+          "maxCombined": 6.6667,
+          "worstSibling": "ms-ai-engineering",
+          "pass": true,
+          "threshold": 7
+        }
+      },
+      "judgeInputs": {
+        "description": "Norwegian public sector AI compliance, utredningsinstruksen for AI, EU AI Act risk classification, DPIA for AI systems, cross-border personal-data transfer assessment (Schrems II / TIA), Digdir architecture principles, responsible AI governance, monitoring and observability. Triggers on: \"Norwegian public sector AI compliance\", \"AI Act risk classification\", \"DPIA for AI system\", \"Schrems II data transfer\", \"overføring av persondata til tredjeland\", \"Digdir architecture principles\", \"ansvarlig AI i offentlig sektor\", \"Forvaltningsloven AI\".",
+        "bodyLines": 289,
+        "refFileSample": [
+          "skills/ms-ai-governance/references/monitoring-observability/alerting-strategies-escalation.md",
+          "skills/ms-ai-governance/references/monitoring-observability/anomaly-detection-ai-systems.md",
+          "skills/ms-ai-governance/references/monitoring-observability/application-insights-llm-monitoring.md",
+          "skills/ms-ai-governance/references/monitoring-observability/azure-monitor-setup-ai-workloads.md",
+          "skills/ms-ai-governance/references/monitoring-observability/compliance-monitoring-ai-governance.md",
+          "skills/ms-ai-governance/references/monitoring-observability/cost-monitoring-cost-attribution.md",
+          "skills/ms-ai-governance/references/monitoring-observability/custom-dashboards-ai-operations.md",
+          "skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md"
+        ]
+      },
+      "judge": {
+        "_updated": "S11 (2026-06-20) — K1 authoritative (blinded judge vs curated 20-set); Schrems II trigger added; K4+K9 prior S9",
+        "K1_triggerPrecision": {
+          "provisional": false,
+          "inDomainHitRate": 1,
+          "outDomainFalsePositiveRate": 0,
+          "precision": 1,
+          "pass": true,
+          "misclassified": [],
+          "notes": "S11 authoritative: blinded judge vs operator-curated 20-set. 10/10 in-domain hits, 0/10 false positives (was 0.85). Schrems II recall fix VALIDATED — judge triggered on Schrems II / overføring-til-tredjeland prompts via the two new trigger phrases."
+        },
+        "K4_noDuplication": {
+          "score": 5,
+          "pass": true,
+          "evidence": "S9 FIX: §6.2 now a compact decision-flow with explicit pointers ('[full forbudsliste i ai-act-classification-methodology.md]', '[åtte kategorier ...]') — Art.5 + Annex III lists no longer enumerated in body; they live only in references/responsible-ai/ai-act-classification-methodology.md. §2.1 is the single 4-level overview table ('ikke gjenta dem her'). §6.1 (DPIA tree), §1.2 (Digdir table), §6.3/§6.4 are routing/orientation, not verbatim copies of ref files."
+        },
+        "K7_imperativeStyle": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "10/10 sampled instruction sentences imperative/infinitive."
+        },
+        "K8_sourceCitation": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "5/5 sampled refs carry Last updated + Status + Category headers."
+        },
+        "K9_noTimeSensitive": {
+          "pass": true,
+          "findings": []
+        }
+      }
+    },
+    {
+      "name": "ms-ai-infrastructure",
+      "skillMd": "skills/ms-ai-infrastructure/SKILL.md",
+      "refFilesActual": 34,
+      "refCountsPerFolder": {
+        "bcdr": 16,
+        "hybrid-edge": 18
+      },
+      "deterministic": {
+        "K2_descriptionFormat": {
+          "quotedPhrases": 5,
+          "useWhenForm": true,
+          "imperativeStart": false,
+          "pass": true
+        },
+        "K3_bodyLength": {
+          "bodyLines": 279,
+          "pass": true
+        },
+        "K5_progressiveDisclosure": {
+          "namedFileLinks": 33,
+          "folderRefs": 5,
+          "totalRefFiles": 34,
+          "namedRatio": 0.9706,
+          "pass": true,
+          "sampleNamed": [
+            "references/bcdr/multi-region-azure-openai-deployment.md",
+            "references/bcdr/rto-rpo-planning-ai-services.md",
+            "references/bcdr/backup-recovery-strategies-ai-workloads.md",
+            "references/bcdr/failover-testing-ai-services.md",
+            "references/bcdr/chaos-engineering-ai-systems.md"
+          ]
+        },
+        "K6_routingTable": {
+          "namedStartFiles": 33,
+          "pass": true
+        },
+        "refCountConsistency": {
+          "consistent": true,
+          "mismatches": []
+        },
+        "K9_timeSensitiveHints": {
+          "timeSensitiveTokenHits": 6,
+          "sample": [
+            "preview",
+            "GA"
+          ]
+        },
+        "K10_siblingScopeOverlap": {
+          "maxCombined": 7.4167,
+          "worstSibling": "ms-ai-engineering",
+          "pass": false,
+          "threshold": 7
+        }
+      },
+      "judgeInputs": {
+        "description": "Disaster recovery for AI workloads, multi-region Azure AI deployment, hybrid or edge AI architecture, sovereign cloud for Norway, offline-first AI patterns, AI infrastructure resilience. Covers BCDR, Azure Arc for AI, ONNX Runtime edge deployment, disconnected scenarios, Norwegian data sovereignty. Triggers on: \"disaster recovery for AI workloads\", \"edge AI deployment\", \"sovereign cloud AI\", \"Azure Arc for AI\", \"BCDR for AI\".",
+        "bodyLines": 279,
+        "refFileSample": [
+          "skills/ms-ai-infrastructure/references/bcdr/ai-foundry-disaster-recovery-planning.md",
+          "skills/ms-ai-infrastructure/references/bcdr/backup-recovery-strategies-ai-workloads.md",
+          "skills/ms-ai-infrastructure/references/bcdr/capacity-planning-dr-configurations.md",
+          "skills/ms-ai-infrastructure/references/bcdr/chaos-engineering-ai-systems.md",
+          "skills/ms-ai-infrastructure/references/bcdr/compliance-requirements-bcdr.md",
+          "skills/ms-ai-infrastructure/references/bcdr/cost-analysis-dr-configurations.md",
+          "skills/ms-ai-infrastructure/references/bcdr/data-replication-patterns-ai.md",
+          "skills/ms-ai-infrastructure/references/bcdr/failover-testing-ai-services.md"
+        ]
+      },
+      "judge": {
+        "_updated": "S11 (2026-06-20) — K1 authoritative (blinded judge vs curated 20-set); K9 prior S10",
+        "K1_triggerPrecision": {
+          "provisional": false,
+          "inDomainHitRate": 1,
+          "outDomainFalsePositiveRate": 0,
+          "precision": 1,
+          "pass": true,
+          "misclassified": [],
+          "notes": "S11 authoritative: blinded judge vs operator-curated 20-set. 10/10 in-domain hits, 0/10 false positives. BCDR/edge/sovereign/hybrid in-domain all triggered; engineering/governance/security/advisor/cost correctly excluded."
+        },
+        "K4_noDuplication": {
+          "score": 5,
+          "pass": true,
+          "evidence": "S10 re-judge: consistent summary+pointer pattern; §1.2 RTO/RPO now ~2 lines delegating to bcdr/rto-rpo-planning-ai-services.md (265 lines). SLA table replaced by relative-guidance prose. No procedural duplication."
+        },
+        "K7_imperativeStyle": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "10/10 sampled instruction sentences imperative/infinitive."
+        },
+        "K8_sourceCitation": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "5/5 'Last updated: 2026-02' + Status; no source-URL on header line."
+        },
+        "K9_noTimeSensitive": {
+          "pass": true,
+          "findings": []
+        }
+      }
+    },
+    {
+      "name": "ms-ai-security",
+      "skillMd": "skills/ms-ai-security/SKILL.md",
+      "refFilesActual": 62,
+      "refCountsPerFolder": {
+        "ai-security-engineering": 22,
+        "cost-optimization": 22,
+        "performance-scalability": 18
+      },
+      "deterministic": {
+        "K2_descriptionFormat": {
+          "quotedPhrases": 6,
+          "useWhenForm": true,
+          "imperativeStart": false,
+          "pass": true
+        },
+        "K3_bodyLength": {
+          "bodyLines": 191,
+          "pass": true
+        },
+        "K5_progressiveDisclosure": {
+          "namedFileLinks": 20,
+          "folderRefs": 6,
+          "totalRefFiles": 62,
+          "namedRatio": 0.3226,
+          "pass": true,
+          "sampleNamed": [
+            "references/ai-security-engineering/security-scoring-rubrics-6x5.md",
+            "references/ai-security-engineering/ai-security-scoring-framework.md",
+            "references/ai-security-engineering/owasp-llm-top10-azure-mitigations.md",
+            "references/ai-security-engineering/defender-threat-protection-ai-services.md",
+            "references/ai-security-engineering/secure-model-deployment-hardening.md"
+          ]
+        },
+        "K6_routingTable": {
+          "namedStartFiles": 20,
+          "pass": true
+        },
+        "refCountConsistency": {
+          "consistent": true,
+          "mismatches": []
+        },
+        "K9_timeSensitiveHints": {
+          "timeSensitiveTokenHits": 1,
+          "sample": [
+            "2025"
+          ]
+        },
+        "K10_siblingScopeOverlap": {
+          "maxCombined": 6.5,
+          "worstSibling": "ms-ai-governance",
+          "pass": true,
+          "threshold": 7
+        }
+      },
+      "judgeInputs": {
+        "description": "Security assessment, cost estimation, OWASP LLM Top 10 mitigations, performance optimization for AI on Microsoft stack. Deterministic 6x5 security scoring, P10/P50/P90 cost confidence intervals, FinOps practices. Triggers on: \"security assessment for AI\", \"AI threat modeling\", \"cost estimation for Azure AI\", \"FinOps for AI workloads\", \"OWASP LLM\", \"kostnadsestimat for AI-løsning\".",
+        "bodyLines": 191,
+        "refFileSample": [
+          "skills/ms-ai-security/references/ai-security-engineering/adversarial-input-robustness-testing.md",
+          "skills/ms-ai-security/references/ai-security-engineering/ai-incident-response-procedures.md",
+          "skills/ms-ai-security/references/ai-security-engineering/ai-prompt-shield-network.md",
+          "skills/ms-ai-security/references/ai-security-engineering/ai-red-team-operations-practical.md",
+          "skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md",
+          "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
+          "skills/ms-ai-security/references/ai-security-engineering/content-safety-filter-calibration.md",
+          "skills/ms-ai-security/references/ai-security-engineering/data-leakage-prevention-ai.md"
+        ]
+      },
+      "judge": {
+        "_updated": "S11 (2026-06-20) — K1 authoritative (blinded judge vs curated 20-set); K4+K9 prior S9",
+        "K1_triggerPrecision": {
+          "provisional": false,
+          "inDomainHitRate": 1,
+          "outDomainFalsePositiveRate": 0,
+          "precision": 1,
+          "pass": true,
+          "misclassified": [],
+          "notes": "S11 authoritative: blinded judge vs operator-curated 20-set. 10/10 in-domain hits, 0/10 false positives. Borderline content-safety/TCO correctly included; sibling governance/engineering/infra/advisor correctly excluded."
+        },
+        "K4_noDuplication": {
+          "score": 5,
+          "pass": true,
+          "evidence": "S9 re-judge (cold, post-fix): (a) 6x5 weights — body L50 routes to security-scoring-rubrics-6x5.md ('Ikke dupliser vekttallene her'), no body numbers; (b) risk-classification thresholds — body L54 routes to same rubric ('Ikke dupliser terskeltallene her'), canonical mapping incl. 1.00-1.49 Uakseptabel lives only in rubric; (c) P10/P50/P90 — body L94 affirms 'per komponent (ikke flat multiplikator)' owned by deterministic-cost-calculation-model.md §3, concrete factors only in cost model — body affirms, does not contradict; (d) OWASP table + §3 perf are routing/orientation with explicit volatile-numbers-live-in-refs note. No duplication/contradiction."
+        },
+        "K7_imperativeStyle": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "10/10 sampled instruction sentences imperative/infinitive."
+        },
+        "K8_sourceCitation": {
+          "ratio": 1,
+          "pass": true,
+          "notes": "5/5 dated headers + Status; 3/5 also carry Verified: MCP <date>."
+        },
+        "K9_noTimeSensitive": {
+          "pass": true,
+          "findings": []
+        }
+      }
+    }
+  ]
+}