diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 0000000..824b8f2
Binary files /dev/null and b/.DS_Store differ
diff --git a/03_Karten/artefaktkarten_gamma.md b/03_Karten/artefaktkarten_gamma.md
new file mode 100644
index 0000000..9ceba33
--- /dev/null
+++ b/03_Karten/artefaktkarten_gamma.md
@@ -0,0 +1,336 @@
+# Artefaktkarten — Gamma-Vorlage
+
+Material, um aus den 15 konsolidierten Artefakten (A1–A15, siehe
+`README_karten.md` Abschnitt 3) eine **Gamma-Präsentation im Kartenformat** zu
+erzeugen — je Artefakt eine Karte mit der gleichen Struktur:
+**Was umfasst es? · Warum brauchen wir es? · Konkretes Beispiel · Wo wird es gebraucht?**
+
+---
+
+## Teil 1 — Prompt für das Gamma-Eingabefeld
+
+> Erstelle eine Präsentation im **Karten-/Kartendeck-Stil**: **eine Karte pro
+> Artefakt**, insgesamt 15 Karten plus Titel- und Übersichtskarte. Zielgruppe:
+> Mitarbeitende der Stadt Freiburg / DIGIT, die den Service-Lifecycle kennenlernen.
+> Sprache: Deutsch, sachlich-verständlich, „for dummies"-tauglich.
+> Design: klares Freiburg-Layout (Rot/Weiß), je Karte oben ein Phasen-Tag
+> (Design = blau, Transition = orange, Operation = grün, Support = teal,
+> Review = lila). Jede Artefaktkarte hat **genau diese vier Abschnitte** mit
+> fettem Label und kurzem Text/Bullets:
+> **Was umfasst es? · Warum brauchen wir es? · Konkretes Beispiel · Wo wird es gebraucht?**
+> Halte den Text knapp (max. ~4 Bullets pro Abschnitt), eine Karte = ein Artefakt.
+> Verwende die unten gelieferten Inhalte 1:1 als Grundlage und erfinde keine
+> zusätzlichen Fakten. Füge je Karte ein passendes Icon hinzu.
+
+*Tipp: In Gamma „Aus Text einfügen / Paste in text" wählen und Teil 2 komplett
+hineinkopieren. Die `---`-Trenner erzeugen die einzelnen Karten.*
+
+---
+
+## Teil 2 — Karteninhalte (zum Einfügen in Gamma)
+
+# Die 15 Artefakte des Service-Lifecycle
+
+Jedes Artefakt ist ein greifbares Ergebnis im Lebenszyklus eines Services —
+von der ersten Idee (Design) bis zur Ablösung (Review). Diese Karten erklären,
+**was** es ist, **warum** es gebraucht wird, ein **Beispiel** und **wo** es im
+Lifecycle entsteht.
+
+---
+
+## A1 · Projektauftrag
+
+**Was umfasst es?**
+Der freigegebene Auftrag aus dem Demand-Lifecycle: Ziel, Rahmen, benannte
+Projektleitung sowie zugesagtes Budget und Ressourcen (nach DSR/MB-Freigabe).
+
+**Warum brauchen wir es?**
+Er ist das Startsignal und Mandat für die Design-Phase — ohne ihn gibt es weder
+einen legitimierten Start noch zugewiesene Ressourcen.
+
+**Konkretes Beispiel**
+Ein neues Landesgesetz verpflichtet zur Online-Bürgerbeteiligung. Der
+Demand-Lifecycle gibt das Projekt „Beteiligungs-Module fürs Bürgerportal" mit
+benannter Projektleitung frei.
+
+**Wo wird es gebraucht?**
+Eingang in die Design-Phase → Aktivität **ds_01**.
+
+---
+
+## A2 · Service-Definition
+
+**Was umfasst es?**
+Zweck, Nutzen und Zielgruppen des Services, Utility & Warranty, die
+SLA-/SLO-Anforderungen sowie Abhängigkeiten zu anderen Services.
+
+**Warum brauchen wir es?**
+Sie legt fachlich fest, **was** der Service leisten soll — der Bezugspunkt für
+Design, Betrieb und das spätere Review.
+
+**Konkretes Beispiel**
+„Beteiligungs-Modul: Bürger:innen kommentieren Bauvorhaben fristgebunden online;
+Zielverfügbarkeit 99,5 %."
+
+**Wo wird es gebraucht?**
+Erstellt in **ds_01**; im Review (rv_02/rv_04) fortgeschrieben.
+
+---
+
+## A3 · Service Design Document (SDD)
+
+**Was umfasst es?**
+Servicearchitektur (Komponenten, Schnittstellen), Design der Betriebs- und
+Supportprozesse, Security/Datenschutz/Compliance, Monitoring/Reporting und das
+Rollenmodell.
+
+**Warum brauchen wir es?**
+Es übersetzt das „Was" der Service-Definition in das **Wie** — der technische und
+organisatorische Bauplan und Voraussetzung für Gate 1.
+
+**Konkretes Beispiel**
+Architektur der Beteiligungs-Module inkl. Schnittstellen zu Portal und DMS,
+Barrierefreiheit und Lastdesign für das Ende von Beteiligungsfristen.
+
+**Wo wird es gebraucht?**
+Entsteht in **ds_02**; an **Gate 1 (tr_01)** auf Vollständigkeit geprüft.
+
+---
+
+## A4 · Implementation Blueprint
+
+**Was umfasst es?**
+Plan zur organisatorischen Einführung: Integration, Rollenübergaben, Anpassung
+von Prozessen/Tools, Trainings & Kommunikation, Bewertung der Time-to-Operate.
+
+**Warum brauchen wir es?**
+Er stellt sicher, dass der Service nicht nur gebaut, sondern auch wirklich in die
+Organisation **eingeführt und übernommen** werden kann.
+
+**Konkretes Beispiel**
+Schulungsplan für die Sachbearbeiter:innen im Planungsamt plus Übergabeplan an
+Betrieb und Support.
+
+**Wo wird es gebraucht?**
+Entsteht in **ds_03**; Input für **Gate 1**.
+
+---
+
+## A5 · Gate-/SOR-Vorlage
+
+**Was umfasst es?**
+Die Entscheidungsvorlage für ein Gate: Aufwand/Risiken/Budget, Empfehlung und die
+zu prüfenden Dimensionen. An Gate 2 als „Transition-Steckbrief".
+
+**Warum brauchen wir es?**
+Sie macht Gate-Entscheidungen nachvollziehbar und legitimiert — ohne Vorlage
+keine SOR-/SO-Freigabe.
+
+**Konkretes Beispiel**
+SOR-Vorlage an Gate 1: „Entwicklung statt Konfiguration, geschätzt X Personentage,
+Budget vorhanden, Betrieb grundsätzlich bereit."
+
+**Wo wird es gebraucht?**
+**tr_01** (Gate 1), **tr_09** (Gate 2, Steckbrief), **tr_11** (Gate-3-Antrag).
+
+---
+
+## A6 · Betriebsdokumentation
+
+**Was umfasst es?**
+Service Operation Manual, Betriebshandbuch, Arbeitsanweisungen, Eskalationswege,
+Standard Changes, Known Errors und Konfigurations-/Betriebsrichtlinien.
+
+**Warum brauchen wir es?**
+Sie macht den Service **betreib- und supportbar** — ohne sie kein stabiler
+Regelbetrieb und keine schnelle, einheitliche Störungsbehebung.
+
+**Konkretes Beispiel**
+Runbook „Beteiligungsverfahren anlegen und archivieren", Eskalationspfad bei
+Speicherfehlern, Standard-Change „neues Verfahren freischalten".
+
+**Wo wird es gebraucht?**
+Erstellt in **tr_06**; bereitgestellt und gepflegt in **op_02**.
+
+---
+
+## A7 · Test-Report
+
+**Was umfasst es?**
+Ergebnisse von Funktions-, Integrations- und Abnahmetests, der Nachweis der
+Betriebsreife sowie Testprotokolle und Freigaben.
+
+**Warum brauchen wir es?**
+Er belegt, dass der Service **funktioniert, bevor er live geht** — Grundlage für
+die Freigabe an Gate 2.
+
+**Konkretes Beispiel**
+Abnahmetest: Eine Online-Konsultation startet und endet fristgerecht, Eingaben
+werden korrekt und vollständig gespeichert.
+
+**Wo wird es gebraucht?**
+Entsteht in **tr_07**; Input für **Gate 2 (tr_09)**.
+
+---
+
+## A8 · Aktivierter Service
+
+**Was umfasst es?**
+Der freigegebene, produktive Service inklusive Aufnahme ins Portfolio und
+aktiviertem Katalog-Eintrag (ggf. mit Support-Dokumentation).
+
+**Warum brauchen wir es?**
+Es markiert den offiziellen **Go-Live** — ab hier ist der Service in Betrieb und
+im Portfolio sichtbar und steuerbar.
+
+**Konkretes Beispiel**
+Das Beteiligungs-Modul ist live, im Service-Katalog gelistet und für Bürger:innen
+nutzbar.
+
+**Wo wird es gebraucht?**
+Ergebnis von **Gate 3 (tr_12)**; Übergang in Operation und Support.
+
+---
+
+## A9 · Service-Qualitätsbericht
+
+**Was umfasst es?**
+SLA-/SLO-Auswertung, technische KPIs (Verfügbarkeit, Response Time), Abgleich
+gegen Qualitätsziele und Verbesserungspotenziale — inkl. Monitoring-/Betriebsdaten.
+
+**Warum brauchen wir es?**
+Er zeigt **objektiv**, ob der Service seine Versprechen hält, und ist die Zuarbeit
+fürs Review.
+
+**Konkretes Beispiel**
+Quartalsbericht: 99,7 % Verfügbarkeit, aber Lastspitzen zum Fristende und ein
+Formular mit auffällig hoher Abbruchquote.
+
+**Wo wird es gebraucht?**
+Erstellt in **op_06** (Daten aus op_05); Input für das Review (rv_01/rv_02).
+
+---
+
+## A10 · Incident Record
+
+**Was umfasst es?**
+Aufnahme, Bearbeitung, Lösung und Abschluss einer Störung oder eines Service
+Requests — inklusive Klassifizierung für Auswertungen. (Trägt auch den
+Request Record.)
+
+**Warum brauchen wir es?**
+Es dokumentiert Störungen/Anfragen nachvollziehbar, sichert SLA-Konformität und
+liefert Daten für Trendanalysen.
+
+**Konkretes Beispiel**
+„Kommentar-Speichern schlägt unter Last fehl" — aufgenommen, an den 2nd Level
+eskaliert, gelöst und sauber geschlossen.
+
+**Wo wird es gebraucht?**
+**sp_04–sp_08** (Service Requests: sp_04/sp_07).
+
+---
+
+## A11 · Problem Record
+
+**Was umfasst es?**
+Beschreibung, Symptome und Diagnosewege, bekannte Workarounds, die Ursache
+(Root Cause, wenn gefunden), Change-Bedarf sowie Status und Priorität.
+
+**Warum brauchen wir es?**
+Es bündelt die **strukturelle Ursachenarbeit** hinter wiederkehrenden oder
+ungelösten Incidents — das einzige im Blueprint formal definierte Artefakt.
+
+**Konkretes Beispiel**
+Problem Record „Timeout beim Speichern unter Last" mit dokumentiertem Workaround
+und einer Change-Empfehlung.
+
+**Wo wird es gebraucht?**
+Erzeugt in **sp_09/sp_10**, aktualisiert in **sp_11**; ausgewertet im Review (rv_01).
+
+---
+
+## A12 · Workaround
+
+**Was umfasst es?**
+Eine vorläufige Umgehungslösung, die den Betrieb stabil hält, bis die eigentliche
+Ursache behoben ist — mit Eintrag in die Wissensdatenbank.
+
+**Warum brauchen wir es?**
+Es hält den Service **nutzbar**, obwohl die Ursache noch offen ist, und reduziert
+den Druck auf den Support.
+
+**Konkretes Beispiel**
+„Kommentare in kleineren Blöcken speichern", bis der Timeout-Fix ausgerollt ist.
+
+**Wo wird es gebraucht?**
+Entsteht in **sp_11** aus der operativen Root-Cause-Analyse.
+
+---
+
+## A13 · Wissensdatenbank-Eintrag
+
+**Was umfasst es?**
+Standardlösungen, Known Errors, Workarounds, FAQ und Anleitungen — das zentrale
+Arbeitsmittel für 1st und 2nd Level Support.
+
+**Warum brauchen wir es?**
+Es **beschleunigt den Support**, sichert konsistente Antworten und entlastet die
+höheren Support-Level.
+
+**Konkretes Beispiel**
+FAQ „Wie kommentiere ich ein Bauvorhaben?" plus Known-Error-Eintrag zum
+Speicher-Timeout.
+
+**Wo wird es gebraucht?**
+Gepflegt in **sp_02**, genutzt in **sp_05/sp_06**, gespeist aus **sp_11**.
+
+---
+
+## A14 · Service-Review-Bericht
+
+**Was umfasst es?**
+Das „Service Performance & Improvement Review": Bewertung über 4 Dimensionen
+(Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit) per Ampel und eine
+Handlungsempfehlung (CONTINUE / IMPROVEMENT / REDESIGN / RETIRE).
+
+**Warum brauchen wir es?**
+Es liefert die strukturierte Grundlage für die SOR-Entscheidung über die **Zukunft
+des Service**.
+
+**Konkretes Beispiel**
+Review nach zwei Quartalen: Dimension Stabilität „gelb" wegen des Lastproblems →
+Empfehlung IMPROVEMENT.
+
+**Wo wird es gebraucht?**
+Erstellt in **rv_02**; Grundlage für die SOR-Entscheidung in **rv_03**.
+
+---
+
+## A15 · DPM-Rücklauf
+
+**Was umfasst es?**
+Die Übergabe an den Demand-Lifecycle — **Variante A: Neuer Demand** (Redesign/
+Erweiterung) oder **Variante B: Retirement-Plan / Decommissioning-Auftrag**
+(Stilllegung).
+
+**Warum brauchen wir es?**
+Es **schließt den Lebenszyklus**: größere Änderungen oder das Ende eines Service
+laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei".
+
+**Konkretes Beispiel**
+Variante A: eine komplett neue Beteiligungsplattform → neuer Demand.
+Variante B: das Modul wird durch eine Landeslösung ersetzt → Retirement-Plan.
+
+**Wo wird es gebraucht?**
+**rv_05** (Neuer Demand) bzw. **rv_06** (Retirement) → Demand-Lifecycle (DPM).
+
+---
+
+## Übersicht — Artefakte nach Phase
+
+- **Design:** A2 Service-Definition · A3 Service Design Document · A4 Implementation Blueprint *(Eingang: A1 Projektauftrag)*
+- **Transition:** A5 Gate-/SOR-Vorlage · A6 Betriebsdokumentation · A7 Test-Report · A8 Aktivierter Service
+- **Operation:** A9 Service-Qualitätsbericht *(+ A6 wird hier gepflegt)*
+- **Support:** A10 Incident Record · A11 Problem Record · A12 Workaround · A13 Wissensdatenbank-Eintrag
+- **Review:** A14 Service-Review-Bericht · A15 DPM-Rücklauf