diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ec1bdf..b260ef5 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,19 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
## [Unreleased]
+### Changed — Design system: flatter, white-first look (v1)
+- Surfaces go white: `--ds-bg-page` and `--ds-bg-subtle` are now `#ffffff`, with a light `--ds-bg-muted` (`#f4f6f6`) reserved for hover/disabled/neutral fills
+- Subtler hairline borders (`--ds-border-default` `#e3e8e8`, `--ds-border-subtle` `#edf0f0`) and tighter radii (`md` 4→3px, `lg` 6→4px, `xl` 10→5px, `2xl` 14→6px)
+- Tables are now flat: no header fill, no zebra striping — horizontal rules only, with a slightly stronger border under the header row
+- Button/ghost hover and disabled-input/neutral-alert fills repointed from the now-white `--ds-bg-subtle` to `--ds-bg-muted` so they stay visible; `card-elevated` keeps its opt-in shadow
+- Updated `tokens.md` reference table and radius scale to match
+
+### Added — Fælles Skabelonløsning Project
+- Analysis and proposal for an open source alternative to DynamicTemplate (DSG Scenario 3) — built on open standards (ODF/DOCX/PDF) and shareable via OS2, addressing Aarhus Kommune's 2.464 templates and 10.000+ phrases
+- Report (`index.md`) with background, eight core components, a Mermaid architecture diagram, open-standards landscape, the team's two caveats (glidende overgang + komplekse skabeloner) as a warning callout, open questions and success criteria
+- Estimeringsnotat with a phased hour estimate (Fase 0 afklaring → 1 POC → 2 MVP → 3 fuld løsning), a dedicated Claude Code-acceleration section explaining where the estimate is reduced (and where it is not), and a drift/economics note
+- Interactive admin-interface mock (`docs/public/projects/skabelonloesning/mocks/index.html`) visualising skabelonregister, frasebibliotek, a template detail with kolofon data and a complex guided input-flow (macro replacement), and a simulated dokumentmotor preview — design-system opt-in, client-side only
+
### Changed — Whitelisted municipality sign-up (ai-bibliotek)
- Sign-up's "Myndighed eller organisation" field is now a select limited to whitelisted municipalities, and registration enforces that the email domain matches the selected municipality's domain (shared `MUNICIPALITIES` list in `auth.js`)
- Documented the intended access model in `index.md`: whitelisted email domains, account verification via email link on sign-up, and a per-domain admin who can delete and promote users (these remain design intent — the `localStorage` mock does not implement them)
diff --git a/CLAUDE.md b/CLAUDE.md
index ce5d42b..1942e01 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -52,6 +52,7 @@ Taskfile.yml # Task automation (dev, build, lint
| `roboway` | Roboway | No |
| `dansk-viden-til-dansk-ai` | Dansk Viden til Dansk AI | No |
| `ai-bibliotek` | AI Bibliotek | No |
+| `skabelonloesning` | Fælles Skabelonløsning | No |
## Conventions
diff --git a/docs/.vitepress/sidebar.mts b/docs/.vitepress/sidebar.mts
index c07ede6..e49c41f 100644
--- a/docs/.vitepress/sidebar.mts
+++ b/docs/.vitepress/sidebar.mts
@@ -119,6 +119,17 @@ const aiBibliotek: DefaultTheme.SidebarItem[] = [
},
]
+const skabelonloesning: DefaultTheme.SidebarItem[] = [
+ {
+ text: 'Fælles Skabelonløsning',
+ items: [
+ { text: 'Overview', link: '/projects/skabelonloesning/' },
+ { text: 'Estimeringsnotat', link: '/projects/skabelonloesning/estimeringsnotat' },
+ { text: 'Interactive Mocks', link: '/projects/skabelonloesning/mocks' },
+ ],
+ },
+]
+
const designSystem: DefaultTheme.SidebarItem[] = [
{
text: 'Design System',
@@ -146,6 +157,7 @@ export function sidebar(): DefaultTheme.Sidebar {
'/projects/roboway/': roboway,
'/projects/dansk-viden-til-dansk-ai/': danskVidenTilDanskAi,
'/projects/ai-bibliotek/': aiBibliotek,
+ '/projects/skabelonloesning/': skabelonloesning,
'/projects/design-system/': designSystem,
}
}
diff --git a/docs/index.md b/docs/index.md
index 00307a3..6121449 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -50,4 +50,8 @@ features:
details: Fælles bibliotek hvor danske myndigheder kan dele og hjemtage AI-assistenter — med katalog, søgning, modelkort, vidensopskrift og versioneret JSON-eksport, så lokale use cases kan skaleres nationalt.
link: /projects/ai-bibliotek/
linkText: View project
+ - title: Fælles Skabelonløsning
+ details: Analyse og oplæg til et open source-alternativ til DynamicTemplate — bygget på åbne standarder og delbart via OS2. Med løsningsbeskrivelse, faseopdelt timeestimat og en interaktiv visualisering af administrationsgrænsefladen.
+ link: /projects/skabelonloesning/
+ linkText: View project
---
diff --git a/docs/projects/design-system/tokens.md b/docs/projects/design-system/tokens.md
index a7049ed..1aa6300 100644
--- a/docs/projects/design-system/tokens.md
+++ b/docs/projects/design-system/tokens.md
@@ -77,10 +77,12 @@ shifts.
| `--ds-text-secondary` | `--ds-gray-700` |
| `--ds-text-muted` | `--ds-gray-600` |
| `--ds-text-link` | `--ds-teal-600` |
-| `--ds-bg-page` | `--ds-gray-50` |
+| `--ds-bg-page` | `#ffffff` |
| `--ds-bg-surface` | `--ds-white` |
-| `--ds-bg-subtle` | `--ds-gray-100` |
-| `--ds-border-default` | `--ds-gray-300` |
+| `--ds-bg-subtle` | `#ffffff` |
+| `--ds-bg-muted` | `#f4f6f6` |
+| `--ds-border-default` | `#e3e8e8` |
+| `--ds-border-subtle` | `#edf0f0` |
| `--ds-border-focus` | `--ds-teal-500` |
| `--ds-color-primary` | `--ds-teal-500` |
| `--ds-color-success` | `--ds-green-500` |
@@ -120,8 +122,8 @@ Line heights: `--ds-lh-tight` (1.25), `--ds-lh-snug` (1.4),
## Radii
-`--ds-radius-sm` (3px), `--ds-radius-md` (6px), `--ds-radius-lg` (10px),
-`--ds-radius-xl` (16px), `--ds-radius-2xl` (24px), `--ds-radius-pill`
+`--ds-radius-sm` (2px), `--ds-radius-md` (3px), `--ds-radius-lg` (4px),
+`--ds-radius-xl` (5px), `--ds-radius-2xl` (6px), `--ds-radius-pill`
(fully rounded), `--ds-radius-full` (alias for `pill`).
## Shadows
diff --git a/docs/projects/skabelonloesning/estimeringsnotat.md b/docs/projects/skabelonloesning/estimeringsnotat.md
new file mode 100644
index 0000000..3b3bc9e
--- /dev/null
+++ b/docs/projects/skabelonloesning/estimeringsnotat.md
@@ -0,0 +1,72 @@
+**Project:** Fælles Skabelonløsning · **Status:** Estimat (oplæg)
+
+# Fælles Skabelonløsning — Estimeringsnotat
+
+**Dato:** juni 2026
+**Projekt:** Open source-alternativ til DynamicTemplate (DSG Scenarie 3)
+**Fase:** Analyse / oplæg
+
+::: warning Bemærkning
+Notatet er bevidst holdt på et overordnet niveau. Det er et oplæg, ikke et tilbud — formålet er at give en størrelsesorden og efterlade manøvrerum i den videre proces. Estimaterne er grove og afhænger af de afklaringer, der er beskrevet i [hovednotatet](./). Scenarie 3 er, jf. DSG-indstillingen, det scenarie med størst usikkerhed.
+:::
+
+---
+
+## Overordnet estimat
+
+Estimatet er delt i faser, så projektet kan startes småt og udvides, efterhånden som koncept og behov afklares. Timetallene er **nedjusteret for udvikling med Claude Code** — se afsnittet [Claude Code-acceleration](#claude-code-acceleration) for antagelsen bag.
+
+| Fase | Indhold | Estimat | Tidshorisont |
+|---|---|---|---|
+| **Fase 0 — Afklaring** | Lagringsmodel (DMS vs. git vs. andet), standard for skabelon-/fraseformat, governance-model, strategi for komplekse skabeloner, fagsystem-snitflader, juridisk afklaring af deling | 120–200 t. | 1–2 mdr. |
+| **Fase 1 — POC** | Dokumentmotor: JSON → DOCX/PDF på 1–2 reelle Aarhus-skabeloner, simpel datamodel, simpel lagring, test af krav om komplekse skabeloner | 250–400 t. | 1,5–2,5 mdr. |
+| **Fase 2 — MVP** | Skabelonregister (versionering, rettigheder, publicering), frasebibliotek, adminmodul-UI, web-editor-integration (OnlyOffice/Collabora), første fagsystem-integration | 700–1.100 t. | 4–6 mdr. |
+| **Fase 3 — Fuld løsning** | Integrations-API til Cura/GetOrganized/Modulus Social, Word add-in + LibreOffice-extension, komplekse skabeloner/input-flows, migreringsværktøj (2.464 skabeloner + 10.000 fraser), OS2-udgivelse | 1.200–2.200 t. | Løbende |
+| **Sum (fase 0–2)** | | **1.070–1.700 t.** | **ca. 6–10 mdr.** |
+| **Sum (fase 0–3)** | | **2.270–3.900 t.** | **ca. 12–18 mdr.** |
+
+### Anbefalet første skridt
+
+**Fase 0 + Fase 1** leverer afklaring og en fungerende POC, der opfylder succeskriteriet: data flettet ind i reelle Aarhus-skabeloner med DOCX/PDF-output, og en afklaring af, om motoren kan bære kravet om komplekse skabeloner. Estimat **370–600 t.**, tidshorisont **ca. 3–4 måneder**.
+
+Det giver et konkret beslutningsgrundlag for, om der skal investeres i fase 2 og 3 — uden at binde sig til hele løsningen på forhånd.
+
+---
+
+## Claude Code-acceleration
+
+Udviklingsteamet anvender nu **Claude Code**, og estimaterne ovenfor er allerede nedjusteret for den produktivitetsgevinst. Gevinsten er konkret for netop dette projekt:
+
+- **Analyse af de eksisterende skabeloner og fraser.** En `.docx` er reelt en zip med XML (OOXML). De 2.464 skabeloner og 10.000+ fraser kan derfor udtrækkes, kategoriseres og analyseres programmatisk — fx hvilke placeholders, kolofon-felter og makroer der faktisk bruges. Claude Code er stærkt til at skrive og iterere på den slags udtræks- og analysescripts.
+- **Migreringsværktøjet (fase 3).** Konverteringsscripts fra eksisterende skabeloner til det åbne målformat er gentaget, mønsterbaseret arbejde — netop hvor Claude Code accelererer mest. Det er den tungeste post i fase 3, og den hvor gevinsten er størst.
+- **Scaffolding.** Dokumentmotor, REST-API, datamodel og adminmodul-UI har genkendelige mønstre, der kan stilladseres hurtigt med god testdækning fra start.
+- **Test og dokumentation.** Testdækning og teknisk dokumentation kan genereres og holdes ved lige løbende.
+
+::: warning Hvor gevinsten ikke ligger
+Claude Code accelererer **kode**, ikke **afklaring**. Fase 0 — governance, juridisk afklaring af deling af skabeloner/datagrundlag, fagsystem-snitflader og brugerdialog om den glidende overgang — drives af mennesker og er ikke nedjusteret. Det samme gælder verifikation af, at de migrerede skabeloner er korrekte: udtrækket kan automatiseres, men den faglige kvalitetskontrol kan ikke.
+:::
+
+---
+
+## Drift og driftsomkostninger
+
+En løsning af denne type er ikke et "byg og glem"-projekt. Den væsentligste langsigtede omkostning er **drift**, ikke selve udviklingen. Følgende skal afklares tidligt:
+
+- **Hosting og ejerskab.** Hvem driver og betaler for platformen — et OS2/fælleskommunalt fællesskab, en værtskommune eller en central aktør? Driften skal have en fast ejer, ellers forfalder løsningen.
+- **Løbende vedligehold.** Sikkerhedsopdateringer, afhængigheder, brugerstyring og support koster typisk **15–25 % af udviklingsestimatet pr. år**. For fase 0–2 svarer det groft til **160–425 t./år**.
+- **Migrering som engangs-storopgave.** Udfasning af DynamicTemplate vil — uanset scenarie — involvere medarbejdere i stort set alle afdelinger. Selve det tekniske udtræk kan automatiseres, men den faglige gennemgang og godkendelse af 2.464 skabeloner og 10.000+ fraser er en betydelig, manuel opgave.
+- **Governance og kvalitet.** Delte skabeloner og fraser skal kunne reviewes — fagligt ejerskab, rettigheder og korrekthed. Det kræver en proces og dermed tid, ikke kun teknik.
+- **Projektledelse.** DSG-indstillingen forudsætter en dedikeret projektleder til implementering (ca. **1 årsværk**) for scenarie 2, 3 og 4. Det ligger ud over udviklingsestimatet ovenfor.
+
+**Konklusion:** udviklingsomkostningen er en engangsinvestering; driften, governance og migreringen er løbende forpligtelser, der skal have et budget og en ejer fra dag ét.
+
+---
+
+## Forudsætninger og forbehold
+
+- Estimaterne forudsætter genbrug af eksisterende ITKdev-fundament (auth, hosting-mønstre, design) og udvikling med Claude Code.
+- De forudsætter, at en open source-dokumentmotor kan dække kravet om **komplekse skabeloner** (betingede felter, gentagelige sektioner, input-flows). Hvis ikke, vokser fase 1–3 markant — dette er den største enkeltstående usikkerhed og skal verificeres i POC'en.
+- Lagrings- og versioneringsmodellen er uafklaret (git er uegnet til binære formater) og påvirker både fase 2 og driften.
+- Fagsystem-integration (Cura, GetOrganized, Modulus Social) afhænger af systemernes API'er og af, om der overhovedet skal integreres eller bruges indbyggede løsninger — dette afklares i fase 0 og kan flytte væsentligt på fase 3.
+- Migreringsvolumen (2.464 skabeloner + 10.000 fraser) er stor; estimatet antager, at en høj andel kan automatiseres, men den faglige verifikation kan ikke.
+- Tallene er grove oplægs-estimater og skal kvalificeres i fase 0.
diff --git a/docs/projects/skabelonloesning/index.md b/docs/projects/skabelonloesning/index.md
new file mode 100644
index 0000000..6d18530
--- /dev/null
+++ b/docs/projects/skabelonloesning/index.md
@@ -0,0 +1,150 @@
+**Project:** Fælles Skabelonløsning · **Status:** Analyse / oplæg · **Date:** juni 2026
+
+# Fælles Skabelonløsning
+
+**Et open source-alternativ til DynamicTemplate — en delbar skabelonløsning bygget på åbne standarder, som kan udvikles i fællesskab via OS2 og frigøre kommunerne fra dyr leverandørafhængighed.**
+
+---
+
+## Baggrund
+
+Aarhus Kommune har i 12 år anvendt **DynamicTemplate** fra Dania Software som fælles skabelonløsning. Løsningen integrerer med Office-produkterne og fagsystemerne Cura, GetOrganized og Modulus Social. I dag er der:
+
+- **2.263 unikke brugere**, der aktivt anvender løsningen
+- **2.464 unikke skabeloner**
+- **mere end 10.000 fraser**
+
+Dania Software er opkøbt af Omnidocs, som har lanceret **Create** — en cloudbaseret erstatning for DynamicTemplate med en annonceret, væsentlig prisstigning. Det har fået Digitaliseringsstyregruppen (DSG) til at tage stilling til fire scenarier for den fremtidige skabelonløsning:
+
+| Scenarie | Indhold |
+|---|---|
+| 1 | Fortsæt med DynamicTemplate |
+| 2 | Skift til cloudløsningen Create |
+| 3 | **Udvikling af en alternativ, åben løsning** |
+| 4 | Brug kun skabelonløsninger i fagsystemerne |
+
+Dette notat behandler **Scenarie 3**. Scenariet er behæftet med de største usikkerheder og kræver — jf. DSG-indstillingen — yderligere analyse samt eventuelt et tilbud fra ITK. Formålet her er at levere netop den analyse, som grundlag for en ansøgning om økonomi til at bygge løsningen.
+
+::: info Hvorfor Scenarie 3?
+En åben løsning reducerer afhængigheden af dyre Office-licenser og af en enkelt leverandør, understøtter et længe ønsket behov for integration i Microsoft 365 Online, og kan — bygget på åbne standarder — deles og samudvikles med andre kommuner via OS2. Det er i tråd med den fællesoffentlige digitaliseringsstrategi, EU's interoperabilitetsprincipper og ønsket om digital suverænitet.
+:::
+
+## Formål
+
+Notatet undersøger spørgsmålet: **Hvordan kan en åben, delbar skabelonløsning bygget på åbne standarder se ud i praksis — og hvad koster det at bygge den?**
+
+Output er, jf. oplægget:
+
+- en **løsningsbeskrivelse** (dette dokument)
+- **spørgsmål der skal afklares** yderligere
+- et **estimat med usikkerheder** (se [Estimeringsnotat](./estimeringsnotat))
+- en **visualisering af administrationsgrænsefladen** (se den [interaktive prototype](#interaktiv-prototype))
+
+## Kernekomponenter
+
+Løsningen består af otte kernekomponenter:
+
+| Komponent | Formål |
+|---|---|
+| **Skabelonregister** | Versionering, rettigheder, ejerskab, metadata, gyldighed og publicering af skabeloner |
+| **Frasebibliotek** | Centrale tekstblokke med versionering, fagligt ejerskab og adgangsstyring |
+| **Datamodel** | Fælles struktur for afsender, modtager, organisation, sagsdata, CPR/CVR-data og fagsystemdata |
+| **Dokumentmotor** | Genererer DOCX, ODT, PDF og evt. HTML fra skabelon og data |
+| **Integrations-API** | Gør det muligt for Cura, GetOrganized, Modulus Social og andre systemer at kalde løsningen |
+| **Klienter** | Word add-in, LibreOffice-extension, webportal og integration til onlinekontorpakker |
+| **Adminmodul** | Skabelonredigering, test, publicering, statistik, logning og governance |
+| **Migreringsværktøj** | Udtræk, analyse og konvertering af eksisterende skabeloner og fraser |
+
+## Arkitektur
+
+Arkitekturen bygger på åbne standarder og open source-komponenter. Data hentes fra fagsystemer via API'er, flettes ind i en skabelon af en dokumentmotor og leveres som DOCX, ODT eller PDF — med et separat lag til redigering, lagring og versionering af selve skabelonerne.
+
+```mermaid
+flowchart TD
+ subgraph kilder["Datakilder"]
+ fag["Fagsystemer
(Cura, GetOrganized,
Modulus Social)"]
+ cpr["CPR / CVR"]
+ org["Organisationsdata"]
+ end
+
+ api["Integrations-API / ETL
(REST · JSON)"]
+ motor["Dokumentmotor
(skabelon + data → dokument)"]
+
+ subgraph admin["Skabelonforvaltning"]
+ register["Skabelonregister
versionering · rettigheder"]
+ fraser["Frasebibliotek"]
+ editor["Web-editor
(OnlyOffice / Collabora)"]
+ end
+
+ subgraph output["Output"]
+ docx["DOCX / ODT / PDF"]
+ arkiv["Arkivering i ESDH
· download · e-mail"]
+ end
+
+ kilder --> api --> motor --> docx --> arkiv
+ admin --> motor
+```
+
+::: info Klienter og glidende overgang
+Brugerne møder løsningen via flere klienter — en **webportal**, en **Word add-in** og en **LibreOffice-extension** — så overgangen kan ske gradvist uden at tvinge alle over på ét format eller én klient på én gang.
+:::
+
+## Åbne standarder og open source
+
+Løsningen skal kunne deles via OS2 og overholde deres principper, og den skal bygge på åbne standarder. Relevante formater og kandidatkomponenter, der bør undersøges i en afklaringsfase:
+
+- **Formater:** ODF (ODT) som åbent kerneformat, med output også i DOCX og PDF for at sikre en glidende overgang.
+- **Dokumentmotor:** docxtemplater (template + JSON → DOCX), Jinja2, Open Document Mail Merge (ODMM), LibreOffice Mail Merge.
+- **PDF:** WeasyPrint (HTML + CSS → PDF) eller tilsvarende.
+- **Web-editor / samarbejde:** OnlyOffice eller Collabora Online.
+- **Lagring og versionering:** afklares — git er teknisk uegnet til binære docx/odt-filer; et DMS (fx Nextcloud) er en mulighed, men tilfører et ekstra led, der skal driftes.
+
+En løsning baseret på åbne standarder og open source kan med fordel samudvikles og genbruges via fx **OS2** eller **KOMBIT**. Tilsvarende offentlige initiativer findes allerede i bl.a. Tyskland (Bundesdruckerei, ODF), Frankrig (OpenFisca + Mako Templates) og Norge (Open eGov, XSLT/HTML-fletning).
+
+## Hensyn fra udviklingsteamet
+
+::: warning To centrale forbehold skal adresseres i designet
+**1. Glidende overgang frem for et stort spring.** Med flere tusind brugere er det risikabelt at flytte alle over på ODT, Markdown eller git på én gang. Nextcloud og git løser et lagringsproblem, men er et stort skridt for brugerne og endnu et led at vedligeholde. Designet skal muliggøre en gradvis migrering — ikke en "big bang".
+
+**2. Komplekse skabeloner, ikke kun simple placeholders.** Flere skabeloner kan ikke løses med simple `{navn}`/`{dato}`-placeholders. Der findes i dag Word-makroer, der interaktivt beder brugeren om en række input. Hvis motoren kun understøtter simpel substitution, bygger projektet sig ind i et hjørne, hvor en POC er mulig, men nye features bliver dyre. Motoren skal fra start kunne håndtere **betingede felter, gentagelige sektioner og brugerstyrede input-flows**.
+:::
+
+## Faseopdelt tilgang
+
+For at imødegå usikkerheden startes småt og udvides, efterhånden som koncept og behov afklares:
+
+- **Fase 0 — Afklaring.** Lagringsmodel, format-standard, governance, strategi for komplekse skabeloner og fagsystem-snitflader.
+- **Fase 1 — POC.** En skabelonmotor der fletter JSON-data ind i 1-2 reelle Aarhus-skabeloner og udskriver DOCX og PDF.
+- **Fase 2 — MVP.** Skabelonregister, frasebibliotek, adminmodul-UI, web-editor og første fagsystem-integration.
+- **Fase 3 — Fuld løsning.** Integrations-API til fagsystemerne, Word add-in og LibreOffice-extension, migreringsværktøj og OS2-udgivelse.
+
+Se [Estimeringsnotat](./estimeringsnotat) for timeestimat, tidshorisont og forbehold.
+
+## Hvad prototypen viser
+
+Den interaktive prototype visualiserer **administrationsgrænsefladen** — den del fagredaktører og administratorer arbejder i. Den er klientside-only (ingen backend) og et visuelt diskussionsgrundlag, ikke en færdig løsning. Den viser:
+
+- **Skabelonregister** — liste over skabeloner med version, ejer, afdeling og status (kladde / publiceret / udløbet), med søgning og filtre. Indholdet er fiktivt (eksempelafdelinger og generiske dokumenttyper), kun til illustration.
+- **Frasebibliotek** — centrale tekstblokke med fagligt ejerskab, version og adgang.
+- **Skabelon-detalje og redigering** — placeholders, kolofon-data (afsender, sagsbehandler, DokID fra ESDH) og et eksempel på et **komplekst input-flow**, der adresserer makro-behovet.
+- **Dokumentmotor-preview** — udfyld med testdata og generér DOCX/PDF (simuleret).
+
+## Spørgsmål der skal afklares
+
+1. **Lagring og versionering.** Git er uegnet til binære docx/odt-filer. Skal der bruges et DMS (Nextcloud/Alfresco), og hvilke ulemper (ekstra drift, brugervenlighed) accepteres?
+2. **Brugerparathed til åbne formater.** Er brugerne klar til ODT/Markdown, eller skal DOCX forblive det primære arbejdsformat i en overgangsperiode?
+3. **Komplekse skabeloner.** Hvordan erstattes Word-makro-baserede input-flows — betingede felter, gentagelige sektioner, guidede formularer?
+4. **Fagsystem-integration vs. indbyggede løsninger.** Skal Cura, GetOrganized og Modulus Social integrere med den fælles løsning, eller bruge deres egne indbyggede skabelonløsninger? Hvordan håndteres "skjulte" integrationer, hvor brugere åbner Word-dokumenter i fagsystemet?
+5. **Migrering.** Hvordan udtrækkes, analyseres og konverteres 2.464 skabeloner og 10.000+ fraser? Hvor meget kan automatiseres?
+6. **Hosting og ejerskab.** Hvem driver og betaler for platformen — et OS2-fællesskab, en værtskommune eller en central aktør?
+7. **Governance.** Hvordan sikres kvalitet, fagligt ejerskab og rettigheder til delte skabeloner og fraser på tværs af organisationer?
+
+## Succeskriterie
+
+En fungerende **POC**, der fletter JSON-data ind i 1-2 reelle Aarhus-skabeloner og udskriver korrekt formateret DOCX og PDF — sammen med en demonstrerbar **administrationsgrænseflade**. POC'en skal samtidig afklare, om motoren kan håndtere kravet om komplekse skabeloner, så projektet ikke bygger sig ind i et hjørne.
+
+---
+
+## Interaktiv prototype
+
+Åbn administrationsgrænsefladen ↗
diff --git a/docs/projects/skabelonloesning/mocks.md b/docs/projects/skabelonloesning/mocks.md
new file mode 100644
index 0000000..16f9c6d
--- /dev/null
+++ b/docs/projects/skabelonloesning/mocks.md
@@ -0,0 +1,8 @@
+**Project:** Fælles Skabelonløsning
+
+# Interaktive Mocks
+
+---
+
+**Administrationsgrænseflade — prototype ↗**
+Visualisering af administrationsgrænsefladen til en åben skabelonløsning. Viser skabelonregister med version, ejer, afdeling og status, frasebibliotek med fagligt ejerskab, en skabelon-detalje med kolofon-data og et komplekst input-flow (makro-erstatning), samt en simuleret dokumentmotor-preview (udfyld testdata → generér DOCX/PDF). Klientside-only, fiktivt illustrativt indhold.
diff --git a/docs/public/design-system/v1/components.css b/docs/public/design-system/v1/components.css
index 91b6a47..cce769b 100644
--- a/docs/public/design-system/v1/components.css
+++ b/docs/public/design-system/v1/components.css
@@ -27,8 +27,8 @@
white-space: nowrap;
}
-.ds .btn:hover { background: var(--ds-bg-subtle); }
-.ds .btn:active { background: var(--ds-bg-muted); }
+.ds .btn:hover { background: var(--ds-bg-muted); }
+.ds .btn:active { background: var(--ds-gray-200); }
.ds .btn:disabled,
.ds .btn[aria-disabled="true"] {
@@ -62,7 +62,7 @@
background: transparent;
border-color: transparent;
}
-.ds .btn-ghost:hover { background: var(--ds-bg-subtle); }
+.ds .btn-ghost:hover { background: var(--ds-bg-muted); }
.ds .btn-danger {
color: var(--ds-text-inverse);
@@ -173,7 +173,7 @@
.ds .input:disabled,
.ds .select:disabled,
.ds .textarea:disabled {
- background: var(--ds-bg-subtle);
+ background: var(--ds-bg-muted);
color: var(--ds-text-muted);
cursor: not-allowed;
}
@@ -202,10 +202,13 @@
border-bottom: 1px solid var(--ds-border-subtle);
}
+/* Flat tables: no fills, horizontal rules only. The header is defined by a
+ slightly stronger bottom border rather than a background. */
.ds .table th {
font-weight: var(--ds-fw-semibold);
color: var(--ds-text-secondary);
- background: var(--ds-bg-subtle);
+ background: transparent;
+ border-bottom: 1px solid var(--ds-border-default);
position: sticky;
top: 0;
z-index: 1;
@@ -213,9 +216,9 @@
.ds .table tbody tr:last-child td { border-bottom: 0; }
-.ds .table-zebra tbody tr:nth-child(even) { background: var(--ds-bg-subtle); }
+.ds .table-zebra tbody tr:nth-child(even) { background: transparent; }
-.ds .table-hover tbody tr:hover { background: var(--ds-color-primary-soft); }
+.ds .table-hover tbody tr:hover { background: var(--ds-bg-muted); }
/* -------------------------------------------------------------------------- */
/* Modal */
@@ -376,7 +379,7 @@
padding: var(--ds-space-3) var(--ds-space-4);
border-radius: var(--ds-radius-md);
border-left: 4px solid var(--ds-border-default);
- background: var(--ds-bg-subtle);
+ background: var(--ds-bg-muted);
font-size: var(--ds-fs-sm);
}
diff --git a/docs/public/design-system/v1/tokens.css b/docs/public/design-system/v1/tokens.css
index 42f1c01..56322eb 100644
--- a/docs/public/design-system/v1/tokens.css
+++ b/docs/public/design-system/v1/tokens.css
@@ -75,16 +75,16 @@
--ds-text-link: var(--ds-teal-600);
--ds-text-link-hover: var(--ds-teal-700);
- /* Semantic — surfaces */
- --ds-bg-page: #f5f4f2;
+ /* Semantic — surfaces (flat, white-first) */
+ --ds-bg-page: #ffffff;
--ds-bg-surface: var(--ds-white);
- --ds-bg-subtle: var(--ds-gray-100);
- --ds-bg-muted: var(--ds-gray-200);
+ --ds-bg-subtle: #ffffff;
+ --ds-bg-muted: #f4f6f6;
--ds-bg-inverse: var(--ds-gray-900);
- /* Semantic — borders */
- --ds-border-default: var(--ds-gray-300);
- --ds-border-subtle: var(--ds-gray-200);
+ /* Semantic — borders (subtle hairlines) */
+ --ds-border-default: #e3e8e8;
+ --ds-border-subtle: #edf0f0;
--ds-border-strong: var(--ds-gray-500);
--ds-border-focus: var(--ds-teal-500);
@@ -144,12 +144,12 @@
--ds-space-7: 3rem; /* 48 */
--ds-space-8: 4rem; /* 64 */
- /* Radii */
+ /* Radii (tightened for a flatter, more modern look) */
--ds-radius-sm: 2px;
- --ds-radius-md: 4px;
- --ds-radius-lg: 6px;
- --ds-radius-xl: 10px;
- --ds-radius-2xl: 14px;
+ --ds-radius-md: 3px;
+ --ds-radius-lg: 4px;
+ --ds-radius-xl: 5px;
+ --ds-radius-2xl: 6px;
--ds-radius-pill: 9999px;
--ds-radius-full: 9999px;
diff --git a/docs/public/projects/skabelonloesning/mocks/index.html b/docs/public/projects/skabelonloesning/mocks/index.html
new file mode 100644
index 0000000..c29911e
--- /dev/null
+++ b/docs/public/projects/skabelonloesning/mocks/index.html
@@ -0,0 +1,348 @@
+
+
+