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

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>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md
+++ b/skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md
@ -0,0 +1,642 @@
+# Zero-ETL Patterns with Microsoft Fabric
+
+**Last updated:** 2026-02
+**Status:** GA (Database Mirroring), Preview (Open Mirroring for some sources)
+**Category:** Data Engineering for AI
+
+---
+
+## Introduksjon
+
+Zero-ETL i Microsoft Fabric representerer et paradigmeskifte i hvordan organisasjoner integrerer og konsoliderer data. I stedet for komplekse Extract-Transform-Load (ETL) pipelines, tilbyr Fabric **Mirroring** — en nær-sanntids, kontinuerlig replikeringsløsning som speilser operasjonelle data direkte inn i OneLake som Delta Lake-tabeller.
+
+### Hva er Mirroring i Fabric?
+
+Mirroring er en **zero-ETL, SaaS-basert løsning** som:
+- Kontinuerlig replikerer data fra operasjonelle systemer til OneLake
+- Konverterer data automatisk til Delta Lake format (åpen standard)
+- Holder data synkronisert i nær-sanntid (ned til 15 sekunders latens)
+- Eliminerer behov for kompleks dataintegrasjon og pipeline-vedlikehold
+- Ikke påvirker ytelsen til kildesystemet (spesielt Azure Cosmos DB — ingen RU consumption)
+
+**Confidence marker:** [HIGH] — GA-funksjonalitet for de fleste støttede kilder, dokumentert i offisiell Microsoft-dokumentasjon (februar 2026).
+
+---
+
+## Kjernekomponenter
+
+### 1. Database Mirroring
+
+Database mirroring replikerer **hele databaser og tabeller** til OneLake. Dette er den primære zero-ETL-tilnærmingen for de fleste kilder.
+
+**Støttede kilder (februar 2026):**
+
+| Kilde | Status | Type | Latens |
+|-------|--------|------|--------|
+| Azure SQL Database | GA | Database mirroring | Nær-sanntid |
+| Azure SQL Managed Instance | GA | Database mirroring | Nær-sanntid |
+| Azure Database for PostgreSQL | GA | Database mirroring | Nær-sanntid |
+| SQL Server (on-prem/VM) | GA | Database mirroring | Nær-sanntid |
+| Azure Cosmos DB (NoSQL) | GA | Database mirroring | Nær-sanntid (ingen RU-påvirkning) |
+| Snowflake | GA | Database mirroring | Nær-sanntid |
+| Azure Databricks | GA | Metadata mirroring | Nær-sanntid |
+| Oracle | Preview | Database mirroring | Nær-sanntid |
+| SAP | Preview | Database mirroring | Nær-sanntid |
+| Google BigQuery | Preview | Database mirroring | Nær-sanntid |
+
+**Confidence marker:** [HIGH] — Offisiell dokumentasjon oppdatert januar 2026, bekreftet med `microsoft_docs_search`.
+
+### 2. Metadata Mirroring
+
+Metadata mirroring replikerer **kun metadata** (katalog, schema, tabeller) uten å fysisk flytte data. Data aksesseres via **OneLake shortcuts** fra kildesystemet.
+
+**Eksempel:** Azure Databricks Unity Catalog
+- Fabric speiler kataloghierarkiet fra Databricks
+- Underliggende data forblir i Databricks
+- Tilgang via shortcuts sikrer sanntidssynkronisering uten datakopiering
+
+**Fordeler:**
+- Minimerer lagringskostnader
+- Eliminerer dataduplisering
+- Sanntidstilgang til kildedata
+- Ideell for kilder med stor datamengde eller høy endringsfrekvens
+
+**Confidence marker:** [HIGH] — Azure Databricks-integrasjon dokumentert i offisielle Microsoft Learn-ressurser.
+
+### 3. Open Mirroring
+
+Open mirroring lar **egenutviklede applikasjoner eller tredjepartsløsninger** skrive endringer direkte til en mirrored database i Fabric. Basert på **åpen Delta Lake-standard**.
+
+**Bruksområder:**
+- Custom CDC-implementasjoner
+- Tredjeparts datareplikasjonsverktøy
+- Legacy-systemer uten nativ Fabric-støtte
+- Event-drevet dataintegrasjon
+
+**Prosess:**
+1. Opprett en open mirrored database via Fabric Portal eller REST API
+2. Hent landing zone URL i OneLake
+3. Skriv change data til landing zone i spesifisert format (Delta Lake CDC)
+4. Fabric replicator engine håndterer automatisk merge (INSERT, UPDATE, DELETE)
+
+**Confidence marker:** [MEDIUM] — Open mirroring er GA, men økosystemet av tredjeparts-integrasjoner er fortsatt voksende (per februar 2026).
+
+---
+
+## Arkitekturmønstre
+
+### Mønster 1: Operasjonell-til-Analytisk (HTAP)
+
+**Scenario:** Organisasjonen har en Azure Cosmos DB for transaksjonell OLTP og ønsker sanntids BI/AI uten å påvirke produksjonsytelse.
+
+**Løsning:**
+```
+Azure Cosmos DB (OLTP)
+    │
+    └─► Fabric Mirroring (ingen RU-kostnad)
+            │
+            ├─► OneLake (Delta Lake)
+            │       │
+            │       ├─► Power BI Direct Lake
+            │       ├─► Eventstream (real-time alerting)
+            │       ├─► Notebook (data science)
+            │       └─► SQL Analytics Endpoint
+            │
+            └─► Near real-time (15 sek latens)
+```
+
+**Fordeler:**
+- Null RU consumption for analytiske queries
+- Near real-time insights (ikke batch-basert)
+- Full HTAP-isolasjon (transaksjon/analytikk)
+- Åpen Delta Lake for multi-tool tilgang
+
+**Confidence marker:** [HIGH] — Azure Cosmos DB mirroring er eksplisitt designet for HTAP-scenarier.
+
+### Mønster 2: Multi-Source Konsolidering (Data Mesh)
+
+**Scenario:** Organisasjonen har data spredt på Azure SQL, PostgreSQL, Snowflake, og Cosmos DB. Ønsker én felles analytisk platform.
+
+**Løsning:**
+```
+Azure SQL Database ────┐
+PostgreSQL ────────────┤
+Snowflake ─────────────┼─► Fabric Mirroring ─► OneLake (unified lakehouse)
+Cosmos DB ─────────────┤                             │
+Oracle (on-prem) ──────┘                             ├─► Cross-database queries (T-SQL)
+                                                       ├─► Power BI semantic models
+                                                       └─► Machine learning (MLflow, Spark)
+```
+
+**Fordeler:**
+- Single source of truth for analytikk
+- Cross-database queries via T-SQL (3-part naming)
+- Felles governance og security (RLS, OLS, Purview)
+- Ingen ETL-vedlikehold
+
+**Eksempel T-SQL cross-database query:**
+```sql
+SELECT
+    sql.CustomerName,
+    cosmos.OrderTotal,
+    pg.ProductName
+FROM
+    AzureSQLMirror.dbo.Customers AS sql
+INNER JOIN
+    CosmosMirror.dbo.Orders AS cosmos ON sql.CustomerID = cosmos.CustomerID
+INNER JOIN
+    PostgreSQLMirror.public.Products AS pg ON cosmos.ProductID = pg.ProductID
+WHERE
+    cosmos.OrderDate >= '2026-01-01';
+```
+
+**Confidence marker:** [HIGH] — Cross-database queries er dokumentert i offisiell Fabric-dokumentasjon.
+
+### Mønster 3: Medallion Architecture med Mirroring
+
+**Scenario:** Organisasjonen ønsker å implementere Bronze-Silver-Gold lakehouse, men vil unngå komplekse ingestion-pipelines.
+
+**Løsning:**
+```
+Operational Sources (SQL, Cosmos, PostgreSQL)
+    │
+    └─► Fabric Mirroring ─► Bronze Layer (OneLake, raw Delta Lake)
+                                │
+                                └─► Materialized Lake Views ─► Silver Layer (cleansed, joined)
+                                                                    │
+                                                                    └─► Gold Layer (aggregated, BI-ready)
+```
+
+**Implementasjon med Materialized Lake Views:**
+```sql
+-- Bronze: Mirrored raw data (automatically managed)
+
+-- Silver: Cleansed and joined
+CREATE MATERIALIZED VIEW SilverCustomers AS
+SELECT
+    CustomerID,
+    UPPER(TRIM(CustomerName)) AS CustomerName,
+    CAST(RegistrationDate AS DATE) AS RegistrationDate
+FROM Bronze.RawCustomers
+WHERE CustomerID IS NOT NULL;
+
+-- Gold: Aggregated for BI
+CREATE MATERIALIZED VIEW GoldCustomerSummary AS
+SELECT
+    c.CustomerName,
+    COUNT(o.OrderID) AS TotalOrders,
+    SUM(o.OrderTotal) AS TotalRevenue
+FROM SilverCustomers c
+LEFT JOIN Bronze.RawOrders o ON c.CustomerID = o.CustomerID
+GROUP BY c.CustomerName;
+```
+
+**Fordeler:**
+- Deklarative pipelines (SQL, ikke kompleks orchestration)
+- Automatisk dependency management (Fabric håndterer refresh-rekkefølge)
+- Built-in data quality constraints
+- Optimal refresh (incremental/full/none basert på analyse)
+
+**Confidence marker:** [HIGH] — Materialized Lake Views er dokumentert som anbefalt tilnærming for medallion architecture i Fabric.
+
+### Mønster 4: Legacy System Integration (Open Mirroring)
+
+**Scenario:** Organisasjonen har et legacy ERP-system (ikke-støttet kilde) og ønsker å integrere data i Fabric.
+
+**Løsning:**
+```
+Legacy ERP System
+    │
+    └─► Custom CDC Application (Python/Node.js)
+            │
+            └─► Open Mirroring Landing Zone (OneLake)
+                    │
+                    └─► Fabric Replicator Engine ─► Delta Lake tables
+                                                        │
+                                                        └─► Analytics (Power BI, Spark, SQL)
+```
+
+**Eksempel Python CDC writer:**
+```python
+from azure.storage.filedatalake import DataLakeServiceClient
+import json
+import pandas as pd
+
+# Get landing zone URL from Fabric (after creating open mirrored database)
+landing_zone_url = "https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>/LandingZone"
+
+# Authenticate with bearer token (Entra ID)
+credential = DefaultAzureCredential()
+service_client = DataLakeServiceClient(account_url=landing_zone_url, credential=credential)
+
+# Write CDC data in required format (Delta Lake CDC schema)
+cdc_data = {
+    "op": "INSERT",  # INSERT, UPDATE, DELETE
+    "ts_ms": 1709280000000,
+    "before": None,
+    "after": {
+        "CustomerID": 12345,
+        "CustomerName": "Acme Corp",
+        "Country": "Norway"
+    }
+}
+
+file_client = service_client.get_file_client(file_system="LandingZone", file_path="customers/batch_001.parquet")
+file_client.upload_data(cdc_data, overwrite=True)
+```
+
+**Confidence marker:** [MEDIUM] — Open mirroring-spesifikasjonen er offentlig tilgjengelig, men kodeeksemplene over er forenklet (faktisk format er mer komplekst).
+
+---
+
+## Beslutningsveiledning
+
+### Når bruke Mirroring vs. tradisjonell ETL?
+
+| Faktor | Bruk Mirroring | Bruk ETL (Pipelines/Dataflows) |
+|--------|----------------|--------------------------------|
+| Datakilde | Støttet kilde (SQL, Cosmos, Snowflake, etc.) | Ustrukturert data (loggfiler, JSON, XML) |
+| Latens-krav | Near real-time (< 1 minutt) | Batch (timesvis/daglig oppdatering) |
+| Kompleksitet | Enkel 1:1 replikering | Kompleks transformasjonslogikk (aggregering, pivots) |
+| Vedlikehold | Minimal (SaaS-managed) | Manuell pipeline-vedlikehold |
+| Datavolumet | Stort (TB/PB) | Lite til medium (GB-nivå) |
+| Kildepåvirkning | Minimal/ingen | Avhengig av query load |
+
+**Anbefaling:**
+Start med Mirroring for operasjonelle databaser, bruk ETL for edge cases (unstructured, komplekse transformations).
+
+### Mirroring Type Decision Tree
+
+```
+Har du en støttet kilde (SQL, Cosmos, Snowflake)?
+│
+├─► JA → Er kilden Azure Databricks Unity Catalog?
+│        │
+│        ├─► JA → Bruk Metadata Mirroring (shortcuts)
+│        │
+│        └─► NEI → Bruk Database Mirroring
+│
+└─► NEI → Finnes det en tredjeparts connector?
+         │
+         ├─► JA → Bruk Open Mirroring + partner solution
+         │
+         └─► NEI → Utvikle custom CDC → Open Mirroring
+```
+
+**Confidence marker:** [HIGH] — Basert på offisiell Fabric-dokumentasjon for beslutningsdiagrammer.
+
+---
+
+## Integrasjon med Microsoft-stakken
+
+### 1. Azure AI Foundry
+
+**Scenario:** RAG-basert chatbot som trenger sanntidstilgang til produktkatalog i Azure SQL.
+
+```
+Azure SQL Database (product catalog)
+    │
+    └─► Fabric Mirroring ─► OneLake Delta Lake
+                                │
+                                └─► Azure AI Search (indexing)
+                                        │
+                                        └─► Azure AI Foundry (RAG)
+                                                │
+                                                └─► Chatbot (GPT-4o)
+```
+
+**Fordeler:**
+- Ingen manuell synkronisering av search index
+- Incremental updates (kun endrede produkter re-indexes)
+- Åpent Delta Lake format kan brukes av andre AI-verktøy
+
+### 2. Power BI Direct Lake
+
+Mirrored databases i Fabric er **automatisk tilgjengelig i Direct Lake mode** for Power BI:
+
+```
+Mirrored Database (OneLake Delta Lake)
+    │
+    └─► Power BI Direct Lake Mode (ingen import, ingen DirectQuery overhead)
+            │
+            ├─► Semantic model (auto-generated)
+            └─► Real-time reports (< 1 min latens)
+```
+
+**Fallback:** Hvis en query ikke støttes av Direct Lake, faller systemet automatisk tilbake til DirectQuery.
+
+**Confidence marker:** [HIGH] — Direct Lake for mirrored databases er GA-funksjonalitet.
+
+### 3. Real-Time Intelligence (Eventstream)
+
+Kombiner Mirroring med Eventstream for **hybrid batch + streaming**:
+
+```
+Azure SQL Database (orders)
+    │
+    ├─► Fabric Mirroring ─► OneLake (batch, historical orders)
+    │
+    └─► Eventstream (CDC connector) ─► KQL Database (real-time orders, last 24h)
+                                            │
+                                            └─► Fabric Activator (alerts)
+```
+
+**Når bruke denne kombinasjonen:**
+- Du trenger historisk analyse (batch) OG real-time alerting (streaming)
+- Eksempel: Fraud detection (historisk modell, real-time scoring)
+
+---
+
+## Offentlig sektor (Norge)
+
+### Compliance og Datahåndtering
+
+**GDPR Article 17 (Right to Erasure):**
+Mirroring støtter **soft delete** og **hard delete**:
+- Soft delete: Rad markeres som slettet i Delta Lake (_change_type = 'delete')
+- Hard delete: VACUUM-kommando fjerner gamle versjoner
+
+**Eksempel:**
+```sql
+-- Check retention policy (default 1 day for new mirrors, 7 days for legacy)
+-- Adjust in Fabric Portal: Mirrored Database → Settings → Maintenance → Retention
+
+-- Manual vacuum (remove deleted rows older than 7 days)
+VACUUM table_name RETAIN 168 HOURS;
+```
+
+**NSM Grunnprinsipper:**
+- **Tilgangskontroll:** Row-level security (RLS) og Object-level security (OLS) støttes i SQL Analytics Endpoint
+- **Logging:** Fabric Audit Logs sporer all datahåndtering (inkl. queries og deletes)
+- **Kryptering:** Data-at-rest (OneLake) og data-in-transit (TLS 1.2+)
+
+**Confidence marker:** [HIGH] — Security features dokumentert i offisiell Fabric-dokumentasjon.
+
+### Kostnadsfordeling (Offentlig Sektor)
+
+Mirroring har **særegne kostnadsfortrinn** for offentlige virksomheter:
+
+| Kostnadselement | Tradisjonell ETL | Mirroring |
+|------------------|------------------|-----------|
+| Compute (replication) | Betalt (pipeline runs) | **GRATIS** (inkludert i Fabric capacity) |
+| Storage (replicated data) | Standard OneLake-pris | **1 TB gratis per CU** (F64 = 64 TB gratis) |
+| Pipeline-vedlikehold | DevOps-timekostnad | Minimal (SaaS-managed) |
+
+**Eksempel:** F64 capacity (64 CU)
+- Gratis mirroring-lagring: 64 TB
+- Hvis du replikerer 50 TB data: Ingen ekstra lagringskostnad
+- Hvis du replikerer 80 TB: Betaler kun for 16 TB (over grensen)
+
+**Confidence marker:** [HIGH] — Prising bekreftet i Azure Pricing Calculator og Microsoft Fabric-dokumentasjon.
+
+---
+
+## Kostnad og Lisensiering
+
+### Fabric Capacity-krav
+
+| Scenario | Minimum Capacity | Anbefalt Capacity |
+|----------|------------------|-------------------|
+| POC (< 10 GB, 1 database) | F2 (2 CU) | F8 (8 CU) |
+| Produksjon (< 100 GB, 5 databases) | F16 (16 CU) | F32 (32 CU) |
+| Enterprise (> 1 TB, 20+ databases) | F64 (64 CU) | F128+ (128+ CU) |
+
+**Trial:** Fabric Trial inkluderer gratis mirroring (60 dager, begrenset lagring).
+
+### Kostnadselementer
+
+1. **Replication compute:** GRATIS (inkludert i capacity)
+2. **Storage:**
+   - Første 1 TB per CU: GRATIS
+   - Over grensen: Standard OneLake-pris (~$0.023/GB/måned, Norge-region)
+3. **Query compute:**
+   - SQL queries: Standard Fabric compute (CU consumption)
+   - Power BI Direct Lake: Standard Power BI-prising
+   - Spark queries: Standard Spark compute (CU consumption)
+
+**Viktig:** Capacity må kjøre kun for **initial setup** av Mirroring. Etter oppsett kan du pause capacity, men da konsumeres lagring (ikke lenger gratis).
+
+**Confidence marker:** [HIGH] — Prising bekreftet i offisiell Microsoft Fabric Pricing-dokumentasjon (januar 2026).
+
+### Kostnadsoptimalisering
+
+**Tips:**
+1. **Selektiv replikering:** Speilvend kun tabeller du trenger (ikke hele databasen)
+2. **Retention tuning:** Senk retention fra 7 dager til 1 dag (reduserer lagring)
+3. **Cross-database queries:** Unngå datakopiering mellom mirrors (bruk T-SQL joins)
+4. **Direct Lake:** Bruk Direct Lake i Power BI (ikke import mode) for å unngå duplikatlagring
+
+---
+
+## For arkitekten (Cosmo)
+
+### Key Decision Points
+
+1. **Kildetype:**
+   - Operasjonell database (OLTP) → Database Mirroring
+   - Data lakehouse (Databricks) → Metadata Mirroring
+   - Legacy/custom → Open Mirroring
+
+2. **Latenskrav:**
+   - < 1 minutt → Mirroring (near real-time)
+   - Timesvis/daglig → Vurder ETL (billigere for lave frekvenser)
+
+3. **Transformasjonskompleksitet:**
+   - 1:1 replikering → Mirroring
+   - Komplekse joins/pivots → Mirroring + Materialized Lake Views eller ETL
+
+4. **Governance:**
+   - Trenger RLS/OLS? → Mirroring + SQL Analytics Endpoint (støtter RLS/OLS)
+   - Trenger audit log? → Fabric Audit Logs (integrert)
+
+### Performance Tuning (PostgreSQL eksempel)
+
+Hvis du speilvenner Azure Database for PostgreSQL:
+
+```sql
+-- Check replication lag
+SELECT * FROM azure_cdc.tracked_publications;
+
+-- Check which batches are uploaded
+SELECT * FROM azure_cdc.tracked_batches;
+
+-- Tune batch frequency (reduce latency)
+ALTER SERVER PARAMETER azure_cdc.change_batch_export_timeout = 15; -- default 30 sekunder
+
+-- Increase parallel snapshot workers (faster initial load)
+ALTER SERVER PARAMETER azure_cdc.max_snapshot_workers = 5; -- default 3
+```
+
+**Confidence marker:** [HIGH] — PostgreSQL mirroring server parameters dokumentert i offisiell Azure-dokumentasjon.
+
+### When NOT to Use Mirroring
+
+1. **Kompleks business logic:** Hvis transformasjonen krever komplekse Python/C#-scripts, bruk Fabric Pipelines eller Dataflows.
+2. **Unstructured data:** Mirroring er for strukturerte databaser. Bruk Eventstream for IoT/logs.
+3. **On-prem kilder uten nettverkstilgang:** Mirroring krever nettverkstilgang til OneLake (bruk On-Premises Data Gateway eller VPN).
+
+---
+
+## Tekniske Detaljer
+
+### Change Data Capture (CDC) Mekanismer
+
+| Kilde | CDC-mekanisme | Latens |
+|-------|---------------|--------|
+| SQL Server | Change Feed (transaction log scanning) | 15+ sekunder |
+| PostgreSQL | Logical replication (azure_cdc extension) | 15+ sekunder |
+| Azure Cosmos DB | Change Feed API (ingen RU consumption) | 15+ sekunder |
+| Snowflake | Streams (Snowflake Streams API) | 30+ sekunder |
+
+**Hvordan virker det (PostgreSQL eksempel):**
+
+```
+1. Initial snapshot:
+   PostgreSQL → Parquet files → OneLake Landing Zone → Fabric Replicator → Delta tables
+
+2. Ongoing changes:
+   PostgreSQL WAL (Write-Ahead Log) → azure_cdc extension → Parquet batches → Landing Zone → Delta merge
+```
+
+**Confidence marker:** [HIGH] — Arkitektur-diagram hentet fra offisiell Azure-dokumentasjon.
+
+### Delta Lake Format
+
+All mirrored data lagres som **Delta Lake** (ikke bare Parquet):
+
+**Fordeler:**
+- ACID-transaksjoner (no data corruption)
+- Time travel (query historical versions)
+- Schema evolution (add/remove columns uten å ødelegge historikk)
+- Z-Ordering og V-Order optimalisering (raskere queries)
+
+**Eksempel time travel:**
+```sql
+-- Query data as it was 7 days ago
+SELECT * FROM MirroredDatabase.dbo.Orders
+VERSION AS OF (CURRENT_TIMESTAMP - INTERVAL 7 DAY);
+```
+
+---
+
+## Praktisk Eksempel: End-to-End Setup
+
+### Scenario: Azure SQL til Power BI (5 minutters setup)
+
+1. **Opprett Mirrored Database i Fabric:**
+   - Fabric Portal → Create → Mirrored Database → Azure SQL Database
+   - Angi connection string og credentials (Entra ID eller SQL auth)
+   - Velg tabeller å speilvende (eller hele databasen)
+
+2. **Vent på initial snapshot** (5-30 minutter avhengig av datavolumet)
+
+3. **Koble Power BI til SQL Analytics Endpoint:**
+   - Power BI Desktop → Get Data → SQL Server
+   - Server: `<workspace>.datawarehouse.fabric.microsoft.com`
+   - Database: `<mirrored-database-name>`
+   - Velg Direct Lake mode (anbefalt)
+
+4. **Bygg rapport:**
+   - Dra tabeller inn i rapport
+   - Data er nå live-synkronisert (< 1 minutts latens)
+
+**Total tid:** < 1 time (inkl. initial snapshot)
+
+**Confidence marker:** [HIGH] — Prosedyre bekreftet i offisiell Microsoft Learn-dokumentasjon.
+
+---
+
+## Vanlige Feil og Løsninger
+
+### Problem 1: Mirroring feiler med "Internal error"
+
+**Årsak:** Manglende permissions på kilde-databasen.
+
+**Løsning (PostgreSQL):**
+```sql
+-- Grant required permissions
+GRANT azure_cdc_admin TO fabric_user;
+GRANT CREATE ON DATABASE mydb TO fabric_user;
+ALTER TABLE orders OWNER TO fabric_user; -- fabric_user must own tables
+```
+
+### Problem 2: Høy storage-kostnad
+
+**Årsak:** Retention er satt for høyt (default 7 dager for legacy mirrors).
+
+**Løsning:**
+- Fabric Portal → Mirrored Database → Settings → Maintenance → Retention → 1 day
+- Eller via REST API: `PATCH /v1/mirroring/databases/{id}` med `retentionInDays: 1`
+
+### Problem 3: Query fallback til DirectQuery (langsom)
+
+**Årsak:** Power BI-query bruker en funksjon som ikke støttes av Direct Lake.
+
+**Løsning:**
+- Sjekk Power BI Performance Analyzer for fallback-årsak
+- Omskriv query til å unngå ikke-støttede funksjoner (eks: CONCATENATE → "&")
+- Eller aksepter DirectQuery for komplekse queries (fortsatt raskere enn import mode for store datasets)
+
+**Confidence marker:** [MEDIUM] — Troubleshooting-tips basert på community-dokumentasjon og Microsoft Learn.
+
+---
+
+## Fremtidige Utvidelser (Roadmap)
+
+**Følgende kilder er ikke støttet i februar 2026, men er på roadmap:**
+
+- **MongoDB:** Planlagt Q2 2026 (per Microsoft Ignite 2025-announcements)
+- **SAP HANA:** Preview forventet Q1 2026
+- **IBM Db2:** Ingen offentlig timeline
+- **MySQL:** CDC-basert mirroring (current: kun Azure Database for MySQL via Open Mirroring)
+
+**Confidence marker:** [LOW] — Roadmap-informasjon er basert på konferanse-announcements, ikke offisiell produktdokumentasjon.
+
+---
+
+## Kilder og Verifisering
+
+**Primærkilder (MCP: microsoft-learn):**
+1. [What is Mirroring in Fabric?](https://learn.microsoft.com/en-us/fabric/mirroring/overview) — Sist oppdatert januar 2026
+2. [Azure Database for PostgreSQL mirroring in Fabric](https://learn.microsoft.com/en-us/azure/postgresql/integration/concepts-fabric-mirroring) — GA-status bekreftet
+3. [Medallion lakehouse architecture for Fabric with OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) — Materialized Lake Views
+4. [Microsoft Fabric Pricing](https://azure.microsoft.com/pricing/details/microsoft-fabric/) — Prising bekreftet januar 2026
+
+**Kodeeksempler (MCP: microsoft_code_sample_search):**
+- SQL Server Resource Governor for Fabric mirroring
+- PostgreSQL CDC monitoring functions (`azure_cdc.list_tracked_publications()`)
+- Delta Lake time travel queries
+
+**Søk brukt:**
+- `microsoft_docs_search`: "Fabric mirroring", "zero ETL Fabric", "database mirroring OneLake"
+- `microsoft_docs_fetch`: Mirroring overview, PostgreSQL architecture
+- `microsoft_code_sample_search`: "Fabric mirroring OneLake Delta Lake"
+
+**Sist verifisert:** 2026-02-11
+
+---
+
+## Oppsummering for Cosmo
+
+**Zero-ETL med Fabric Mirroring er riktig valg når:**
+- Kilden er en støttet database (SQL, Cosmos, Snowflake, PostgreSQL)
+- Du trenger near real-time data (< 1 minutt latens)
+- Du vil eliminere ETL-vedlikehold
+- Du vil ha en åpen, multi-tool lakehouse (Delta Lake)
+
+**Ikke bruk Mirroring hvis:**
+- Data er ustrukturert (loggfiler, JSON, XML) → Bruk Eventstream eller Pipelines
+- Transformasjonslogikken er svært kompleks → Bruk Dataflows Gen2 eller Pipelines
+- Kilden er on-prem uten nettverkstilgang → Bruk On-Premises Data Gateway + Pipelines
+
+**Kostnadsoptimalisering:**
+- Start med F16/F32 for produksjon
+- Bruk 1 dag retention (ikke 7 dager)
+- Speilvend kun nødvendige tabeller
+- Bruk Direct Lake i Power BI (ikke import mode)
+
+**Next steps for kunden:**
+1. Identifiser kritiske operasjonelle databaser
+2. Vurder latens-krav per datakilde
+3. Beregn lagringsbehov (free tier: 1 TB per CU)
+4. Kjør POC med Fabric Trial (60 dager gratis)