open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 1 Activity

feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Browse source 
Add /ultraresearch-local for structured research combining local codebase
analysis with external knowledge via parallel agent swarms. Produces research
briefs with triangulation, confidence ratings, and source quality assessment.

New command: /ultraresearch-local with modes --quick, --local, --external, --fg.
New agents: research-orchestrator (opus), docs-researcher, community-researcher,
security-researcher, contrarian-researcher, gemini-bridge (all sonnet).
New template: research-brief-template.md.

Integration: --research flag in /ultraplan-local accepts pre-built research
briefs (up to 3), enriches the interview and exploration phases. Planning
orchestrator cross-references brief findings during synthesis.

Design principle: Context Engineering — right information to right agent at
right time. Research briefs are structured artifacts in the pipeline:
ultraresearch → brief → ultraplan --research → plan → ultraexecute.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-04-08 08:58:35 +02:00
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

254
skills/ms-ai-advisor/references/architecture/source-traceability-assumption-register.md Normal file
View file

@ -0,0 +1,254 @@
# Kildesporing og antakelsesregister
**Sist oppdatert:** 2026-02 (v1.0)
**Målgruppe:** Arkitekter som utarbeider AI-arkitekturvurderinger og utredninger
**Formål:** Sikre sporbarhet, transparens og etterprøvbarhet i arkitekturvurderinger
---
## Om dette dokumentet
Enhver arkitekturvurdering bygger på en blanding av verifiserte fakta, kunnskapsbase-informasjon, eksperterfaring og antakelser. Denne referansefilen gir rammeverk for å klassifisere, dokumentere og validere kildene — slik at beslutningstakere vet hva de kan stole på og hva som må verifiseres.
---
## 1. Kildeklassifisering
### 1.1 Klassifiseringsnivåer
| Klasse | Betegnelse | Tillitsnivå | Definisjon | Eksempler | Holdbarhet |
|--------|-----------|-------------|------------|-----------|------------|
| **V** | **Verifisert** | Høyest | Bekreftet via MCP-verktøy (microsoft-learn, tavily) eller offisiell dokumentasjon i nåværende sesjon | MCP-søk i microsoft-learn som bekrefter GA-status for Azure OpenAI i Norway East; prisdata fra azure.microsoft.com/pricing | 1-6 måneder (avhenger av tjenestens modenhet) |
| **KB** | **Kunnskapsbase** | Høy | Fra plugin-kunnskapsbasen (references/). Kvalitetssikret ved opprettelse, men kan være foreldet. | Informasjon fra `platforms/copilot-studio.md`, `cost-models.md`, `security.md` | Sjekk "Sist oppdatert"-dato. Stale etter 6+ måneder. |
| **E** | **Ekspert** | Middels | Basert på arkitektens erfaring og fagkunnskap. Ikke verifisert mot offisiell kilde i denne sesjonen. | Arkitektens vurdering av integrasjonskompleksitet; erfaringsbaserte tidsestimater; beste-praksis-anbefalinger | Varierer. Mest robust for etablerte mønstre, minst for nye tjenester. |
| **A** | **Antakelse** | Lavest | Uverifisert antakelse. Kan være rimelig, men er ikke bekreftet. Må valideres. | "Vi antar at virksomheten har M365 E5-lisenser"; "Vi antar at Azure AI Search støtter semantic ranker i Norway East" | Må valideres før den brukes i beslutning. |
### 1.2 Visuelle markører
For bruk i utredningsdokumenter:
```markdown
Denne tjenesten er tilgjengelig i Norway East [V: microsoft-learn MCP, 2026-02-13]
Copilot Studio støtter custom topics med GPT-4o [KB: platforms/copilot-studio.md, 2026-01]
Integrasjonen med fagsystemet tar typisk 4-6 uker [E: erfaringsbasert]
Virksomheten har tilgjengelig Azure-abonnement [A: ikke verifisert — må avklares]
```
### 1.3 Regler for kildeklassifisering
1. **Alltid bruk høyest tilgjengelig klasse.** Hvis du kan verifisere via MCP, gjør det — ikke nøy deg med KB.
2. **Nedgrader ved usikkerhet.** Hvis KB-informasjon er eldre enn 6 måneder, vurder å verifisere via MCP eller nedgrader til E.
3. **Vær ærlig om antakelser.** Det er bedre å merke noe som A enn å presentere det som V.
4. **Verifiser kritiske antakelser.** Antakelser som påvirker anbefalingen må valideres — enten i sesjonen eller som oppfølgingspunkt.
---
## 2. Antakelsesregister — mal
### 2.1 Registertabell
```markdown
### Antakelsesregister
**Prosjekt:** [Prosjektnavn]
**Sist oppdatert:** YYYY-MM-DD
| ID | Antakelse | Kilde | Klasse | Konsekvens hvis feil | Sannsynlighet for feil | Valideringsplan | Status | Validert dato |
|----|-----------|-------|--------|---------------------|----------------------|-----------------|--------|---------------|
| A01 | Virksomheten har M365 E5-lisenser | Oppdragsbeskrivelse | A | Copilot-løsningen krever E5, uten den trengs separat lisensanskaffelse (+3 mnd, +X NOK) | Lav | Bekreft med IT-avdeling | ⬜ Åpen | — |
| A02 | Azure OpenAI GPT-4o er GA i Norway East | KB: platforms/azure-ai-foundry.md | KB | Må bruke Sweden Central → dataresidenskonsekvens, mulig DPIA-påvirkning | Lav | Verifiser via MCP: microsoft-learn | ✅ Validert | 2026-02-13 |
| A03 | SharePoint-innhold er strukturert og klassifisert | Ikke verifisert | A | RAG-kvalitet blir lav → POC-tid øker med 4-6 uker for datakuratering | Middels | Be om tilgang til SharePoint, gjennomfør stikkprøve | ⬜ Åpen | — |
| A04 | Integrasjon med fagsystem [X] er mulig via REST API | Muntlig fra prosjektleder | E | Uten API kreves custom connector-utvikling (+8 uker, +Y NOK) | Middels | Be om API-dokumentasjon, gjennomfør teknisk spike | ⬜ Åpen | — |
| A05 | AI Act risikoklasse er "begrenset" (ikke "høy") | Arkitektens vurdering | E | Høyrisikoklassifisering utløser conformity assessment (+3-6 mnd, +Z NOK) | Lav-Middels | Gjennomgå med juridisk rådgiver | 🔄 Under arbeid | — |
```
### 2.2 Status-verdier
| Status | Betydning | Neste steg |
|--------|-----------|------------|
| ⬜ **Åpen** | Ikke påbegynt validering | Prioriter basert på konsekvens |
| 🔄 **Under arbeid** | Validering pågår | Vent på resultat |
| ✅ **Validert** | Bekreftet korrekt | Oppgrader kildeklasse (A→V eller A→E) |
| ❌ **Avkreftet** | Antakelsen var feil | Revurder arkitekturbeslutning |
| ⏳ **Utløpt** | Valideringen er foreldet | Re-valider |
---
## 3. Konsekvensanalyse per antakelse
### 3.1 Konsekvens-kategorier
Når du dokumenterer "Konsekvens hvis feil" i antakelsesregisteret, bruk disse kategoriene:
| Kategori | Beskrivelse | Eksempel |
|----------|-------------|---------|
| **Tidskonsekvens** | Forsinkelse i prosjektplan | "+4 uker for å anskaffe manglende lisenser" |
| **Kostnadskonsekvens** | Uforutsett kostnad | "+200 000 NOK for alternativ komponent" |
| **Arkitekturkonsekvens** | Endring i valgt løsning | "Må bytte fra Norway East til Sweden Central → DPIA-oppdatering" |
| **Regulatorisk konsekvens** | Compliance-implikasjon | "Høyrisiko iht. AI Act → conformity assessment nødvendig" |
| **Organisatorisk konsekvens** | Krav til organisasjonen | "Trenger ekstern data engineer → anskaffelsesprosess" |
| **Prosjektkonsekvens** | Påvirkning på prosjektet som helhet | "Prosjektet bør stoppes/omfangsreduseres" |
### 3.2 Konsekvensmatrise
Prioriter validering basert på konsekvens × sannsynlighet:
| Prioritet | Når | Handling |
|-----------|-----|---------|
| **P1 — Kritisk** | Høy konsekvens + middels/høy sannsynlighet | Valider **før** beslutning. Blokkerer anbefaling. |
| **P2 — Viktig** | Middels konsekvens + middels sannsynlighet, ELLER høy konsekvens + lav sannsynlighet | Valider i **POC-fase**. Dokumenter som risiko. |
| **P3 — Ønskelig** | Lav konsekvens ELLER lav sannsynlighet | Valider **underveis**. Dokumenter, men blokker ikke. |
---
## 4. Valideringsarbeidsflyt
### 4.1 Valideringsprosess
```
1. Identifiser antakelse under utredningsarbeid
↓
2. Registrer i antakelsesregisteret med kildeklasse og konsekvens
↓
3. Vurder prioritet (P1/P2/P3)
↓
4. For P1: Forsøk å validere umiddelbart
│
├─ MCP-verifiserbar? → Bruk microsoft-learn, tavily, eller azure-mcp
├─ Krever tilgang/info fra virksomhet? → Dokumenter som oppfølgingspunkt
└─ Krever ekstern ekspertise? → Registrer som avhengighet
↓
5. Oppdater status og kildeklasse
↓
6. Hvis avkreftet: Revurder berørte beslutninger
```
### 4.2 MCP-verifiseringsprotokoll
For antakelser som kan verifiseres med MCP-verktøy i sesjonen:
| Verktøytype | MCP-verktøy | Egnet for |
|-------------|-------------|-----------|
| **Microsoft-dokumentasjon** | `microsoft_docs_search`, `microsoft_docs_fetch` | GA-status, regional tilgjengelighet, prismodeller, konfigurasjon |
| **Kodeeksempler** | `microsoft_code_sample_search` | API-tilgjengelighet, SDK-støtte |
| **Generelt web** | `tavily_search`, `tavily_extract` | Nyheter, annonserte endringer, community-erfaringer |
| **Azure-infrastruktur** | `azure-mcp-server` (hvis tilgjengelig) | Faktisk konfigurasjon, RBAC, ressursstatus |
### 4.3 Valideringsmal per antakelse
```markdown
### Validering av A01: [Antakelse]
**Antakelse:** [Beskrivelse]
**Kilde:** [Original kilde]
**Prioritet:** P1/P2/P3
**Valideringsmetode:** [MCP/Dokumentgjennomgang/Intervju/Teknisk spike]
**Valideringsresultat:**
- [ ] Bekreftet korrekt → Oppgrader til klasse [V/KB/E]
- [ ] Delvis korrekt → Oppdater antakelse: [ny formulering]
- [ ] Avkreftet → Konsekvens: [beskrivelse], Tiltak: [handling]
**Ny kildeklasse:** [V/KB/E]
**Validert av:** [Navn/rolle]
**Dato:** YYYY-MM-DD
**Notater:** [Evt. tilleggsinfo]
```
---
## 5. Integrasjon med utredningsdokumentet
### 5.1 Kildesporing i tekst
I utredningsdokumentet, bruk inline-kildemarkører:
```markdown
Azure OpenAI tilbyr GPT-4o i Norway East [V: MCP microsoft-learn 2026-02-13].
Copilot Studio kan integreres med Azure AI Search for RAG [KB: platforms/copilot-studio.md].
Vi estimerer at integrasjon med fagsystemet tar 4-6 uker [E: erfaringsbasert].
Vi antar at virksomheten har tilstrekkelig Azure-budsjett [A01: Må valideres med IT-avdeling].
```
### 5.2 Antakelsessammendrag i utredningen
Inkluder dette i utredningens sammendrag (S1):
```markdown
### Antakelser og konfidens
| Antall | Kategori | Konsekvens |
|--------|----------|------------|
| [X] | Verifisert (V) | Høy tillit — dokumentert i sesjonen |
| [X] | Kunnskapsbase (KB) | Høy tillit — sjekk "sist oppdatert" |
| [X] | Ekspert (E) | Middels tillit — basert på erfaring |
| [X] | Antakelse (A) | Lav tillit — må valideres |
**P1-antakelser (kritiske, blokkerende):**
- A01: [Beskrivelse] — Valideringsplan: [Plan]
- A05: [Beskrivelse] — Valideringsplan: [Plan]
**Overordnet konfidensgrad:** 🟢 Høy / 🟡 Medium / 🔴 Lav
```
### 5.3 Antakelsesregister som vedlegg
Fullt antakelsesregister (seksjon 2.1) bør inkluderes som vedlegg i utredningsdokumentet, referert fra S10 (Vedlegg).
---
## 6. Livssyklus for antakelser
### 6.1 Antakelsens livssyklus
```
Identifisert (A) → Prioritert (P1/P2/P3) → Validering pågår (🔄) → Validert (✅) / Avkreftet (❌)
↓ (med tid)
Utløpt (⏳) → Re-validering
```
### 6.2 Re-valideringsregler
| Kildeklasse | Re-valider etter | Trigger |
|-------------|-----------------|---------|
| V (Verifisert) | 3-6 måneder | Ny major release, prisendring, regional utvidelse |
| KB (Kunnskapsbase) | 6 måneder | KB-staleness-sjekk (`scripts/kb-staleness-check.sh`) |
| E (Ekspert) | Ved ny informasjon | Ny erfaring, tilbakemelding fra prosjekt |
| A (Antakelse) | Umiddelbart — bør valideres snarest | Alltid |
---
## For Cosmo Skyberg
Denne referansefilen er ditt verktøy for å sikre transparens og etterprøvbarhet i arkitekturvurderinger. Slik bruker du den:
### Under arkitekturvurderinger:
1. **Klassifiser alltid kilder** med [V], [KB], [E], eller [A] inline i teksten. Dette tar sekunder og gir enorm verdi for beslutningstaker.
2. **Opprett antakelsesregister** for hvert prosjekt. Start med de mest kritiske antakelsene.
3. **Verifiser P1-antakelser i sesjonen** ved hjelp av MCP-verktøy (microsoft-learn, tavily).
4. **Presenter konfidensoversikt** i sammendragseksjonen.
### Når du bruker MCP-verktøy for verifisering:
- **microsoft_docs_search** → Oppgrader til klasse V med dato og søkeord
- **tavily_search** → Oppgrader til klasse V, men noter at web-kilder er mindre stabile enn offisiell docs
- **Kunnskapsbasen** → Bruk klasse KB, men sjekk "Sist oppdatert"-dato i filen
### Vanlige antakelser å registrere:
1. Lisenssituasjon (M365 E3/E5, Copilot Studio, Azure-abonnement)
2. Regional tilgjengelighet (Norway East vs. Sweden Central)
3. Datakvalitet og tilgjengelighet (SharePoint, fagsystemer)
4. Kompetansenivå i organisasjonen
5. Budsjettramme og tidsfrist
6. Regulatorisk klassifisering (AI Act risikoklasse)
7. Integrasjonsmuligheter (API-er i fagsystemer)
### Integrasjon med andre referansefiler:
- **Alternativanalyse** (`alternativanalyse-methodology.md`): Score-begrunnelser bør ha kildeklassifisering
- **Regional tilgjengelighet** (`regional-availability-verification.md`): Verifiseringslogg er kildeklasse V
- **Gjennomførbarhet** (`capacity-feasibility-benchmarks.md`): Tidsestimater er typisk klasse E eller A
- **Utredningsmal** (`ai-utredning-template.md`): Antakelsesregister er vedlegg i utredningen