fix(ms-ai-architect): #7d privat-sektor-paritet — sektor-parametrisering + onboarding-forgrening + 2 nye kommandoer (audit §5)
Audit §161-185: kjerne-dybden var sektor-agnostisk, men entry-points/kalibrering/ navigasjon var systematisk offentlig-sektor-først. Operatørvalg: full audit (kjerne + begge nye kommandoer). Telling 27→29 kommandoer. Ingen versjonsbump (→ #9-release). Mekanisk kjerne: - Sektor parametrisert i 6 kmd (classify/dpia/ros/review default nøytral m/offentlig- spesialisering; utredning beholder utredningsinstruksen + peker privat til :design; review får privat/regulert-gren DORA/Finanstilsynet). frontmatter-desc for review synket i CLAUDE/help. - FRIA-scope KORRIGERT (verifisert mot AI Act Art. 27(1), WebSearch 2026-06-18): obligatorisk for (a) offentligrettslige organer, (b) private som leverer offentlige tjenester, (c) private deployere i kredittscoring (UNNTATT svindeldeteksjon) + livs-/helseforsikringsprising. Ikke lenger feilrådet som rent offentlig-verktøy. - onboarding-agent forgrenet: sektortype (offentlig/privat) → private sektor-valg + privat reg-sett (DORA/Finansforetaksloven/IKT-forskrift/Verdipapirhandelloven); stiller ALDRI private om Offentleglova/Arkivloven. Sektortype skrevet til org-fil. - requirements detekterer finans → DORA/Finanstilsynet (betinget §3-sjekkliste). Nye kommandoer (refererer kun eksisterende kjerne-KB → ingen nye orphans): - /architect:design — sektor-nøytralt Solution Architecture Document (mellombane mellom samtale og full utredning). - /architect:vendor — tredjeparts/SaaS due diligence (dataresidens, sub-prosessorer, DPA, Schrems II/EDPB-TIA, AI Act-deployer). Navigasjon/wiring: - README: privat-enterprise-arbeidsflyt (eksempel 5) + DORA/FRIA-nyanse + design/vendor i tabeller + "Beyond Public Sector"-note. - help.md: privat-bane i arbeidsflyt + design/vendor + manglende kb-update lagt til. - CLAUDE.md-tabell: design/vendor + synket review/frimpact-desc. - playground: katalog-oppføringer (produces_report:false), SHARED.sector utvidet med private sektorer, 2 privat-seeds (fraud-detection FRIA-unntatt + kredittscoring FRIA-pliktig). Telling 25/27→29 i playground/docs/README/test. Tester: validate 239 PASS · playground v3 223 static / 390 kombinert · kb-integrity 115/115 · run-e2e alle suiter — 0 FAIL. CHANGELOG-«24 commands» bevart (historiske notater). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
This commit is contained in:
parent
20c1be6531
commit
6e1fc6d37c
16 changed files with 291 additions and 33 deletions
|
|
@ -26,14 +26,16 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
|
|||
| `/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 |
|
||||
|
|
@ -42,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 |
|
||||
|
|
|
|||
27
README.md
27
README.md
|
|
@ -124,12 +124,14 @@ Cosmo will ask clarifying questions about your business need, licenses, data sou
|
|||
| `/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 |
|
||||
|
|
@ -275,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
|
||||
|
||||
|
|
@ -355,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.
|
||||
|
|
@ -415,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`.
|
||||
|
|
@ -424,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 |
|
||||
|
|
|
|||
|
|
@ -31,10 +31,15 @@ On start, check for existing onboarding state:
|
|||
### Phase 1: Organization Profile (`org/organization-profile.md`)
|
||||
|
||||
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`:
|
||||
|
||||
|
|
@ -47,6 +52,9 @@ last_updated: [YYYY-MM-DD]
|
|||
|
||||
# Virksomhetsprofil
|
||||
|
||||
## Sektortype
|
||||
[Offentlig sektor / Privat sektor]
|
||||
|
||||
## Sektor
|
||||
[answer]
|
||||
|
||||
|
|
|
|||
|
|
@ -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?
|
||||
|
|
|
|||
81
commands/design.md
Normal file
81
commands/design.md
Normal file
|
|
@ -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
|
||||
|
||||
- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — plattformvalg (Foundry / Copilot Studio / Power Platform / Agent Framework)
|
||||
- `skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetsarkitektur og soneinndeling
|
||||
- `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
|
||||
|
|
@ -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?
|
||||
|
|
@ -39,7 +40,7 @@ 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.]
|
||||
|
||||
Les kunnskapsbasene (kjerne):
|
||||
- skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.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
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -25,9 +25,11 @@ Presenter følgende oversikt til brukeren i et ryddig, tabellbasert format.
|
|||
| `/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 |
|
||||
|
|
@ -38,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 |
|
||||
|
|
@ -100,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.
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ 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
|
||||
|
|
@ -32,6 +33,7 @@ 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]
|
||||
|
||||
|
|
@ -42,6 +44,9 @@ Les kunnskapsbasene:
|
|||
- 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
|
||||
|
||||
Betinget (kun ved regulert privat sektor):
|
||||
- Hvis sektor = finans: 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."
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -207,7 +209,7 @@ Alle arbeidere spawnes med `Task` og skriver output til `.work/`-filer. Bruk `te
|
|||
Task(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
|
||||
|
|
|
|||
81
commands/vendor.md
Normal file
81
commands/vendor.md
Normal file
|
|
@ -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
|
||||
|
||||
- `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
|
||||
- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — deployerforpliktelser hvis leverandøren leverer et AI-system
|
||||
- `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
|
||||
|
|
@ -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 (27 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`.
|
||||
|
|
@ -19,14 +19,14 @@ Erstatter v2 5-stegs-pipelinen med en multi-surface-app som persisterer state og
|
|||
|
||||
| Test | Kommando | Dekning |
|
||||
|------|----------|---------|
|
||||
| Statisk struktur | `bash tests/test-playground-v3.sh` | 219 PASS, 2 WARN (pre-eks.) — vendored CSS, surfaces, 27 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 |
|
||||
|
||||
|
|
|
|||
|
|
@ -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'] },
|
||||
|
|
@ -1125,7 +1125,7 @@
|
|||
]
|
||||
},
|
||||
|
||||
// ===== DOCUMENTATION (7) =====
|
||||
// ===== DOCUMENTATION (9) =====
|
||||
{
|
||||
id: 'anskaffelse',
|
||||
category: 'documentation',
|
||||
|
|
@ -1267,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',
|
||||
|
|
@ -1856,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>'
|
||||
|
|
@ -1967,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']-
|
||||
|
|
@ -2116,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.
|
||||
|
|
|
|||
|
|
@ -151,10 +151,10 @@ for f in "$PLUGIN_ROOT"/commands/*.md; do
|
|||
fail "Command-ID '${cmd_id}' mangler i v3 HTML"
|
||||
fi
|
||||
done
|
||||
if [ "$cmd_count" -eq 27 ]; then
|
||||
pass "27 command-filer funnet i commands/ (forventet 27)"
|
||||
if [ "$cmd_count" -eq 29 ]; then
|
||||
pass "29 command-filer funnet i commands/ (forventet 29)"
|
||||
else
|
||||
fail "Forventet 27 command-filer, fant $cmd_count"
|
||||
fail "Forventet 29 command-filer, fant $cmd_count"
|
||||
fi
|
||||
|
||||
# -------------------------------------------------------
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue