ki-engineeering/34-anhang-e-lesepfade-und-checklisten.md

Anhang E: Lesepfade und Checklisten

Dieser Anhang ist der handlungsorientierte Index zum Buch: welche Kapitel in welcher Reihenfolge, welche Checklisten und Templates parallel, und wie ein Team in 1–30 Tagen von „wir haben eine Demo“ zu „wir können betreiben“ kommt. Abschnitt 2 führt ein Feature end-to-end durch Spec, Adaptation, Eval, Security, Ops und Incident — als roter Faden gegen „Kapitel gelesen, System nie zusammengedacht“.

Die lebenden Quellen liegen unter checklists/ und templates/. Was hier steht, ist ein Snapshot zum Mitlesen (PDF) und zum schnellen Einstieg — bei Abweichung gilt die Datei im Repo.

Kurzverweis auf die Lesepfade in der Einführung: dort A–D nach Engpass. Hier nach Rolle und Ziel, mit Skip-Hinweisen und parallelem Handlungspfad.

---

1. Lesepfade (nach Rolle / Ziel)

Gemeinsame Regel für alle Pfade:

1. Ein Feature im Kopf behalten — Spekulation ohne Use Case verpufft.
2. Templates parallel ausfüllen, nicht „erst alles lesen“.
3. Skip ist ok, wenn du den Engpass kennst; zurückspringen, wenn die Spec unscharf wird.

Kapitelnummern verweisen auf die Dateien 03-… bis 29-….

1.1 Schnelleinstieg SE (2–3 Tage Lesen)

Ziel: Mental Model, Ampel, Spec, Adaptation, Eval-Minimum, Security-Grundlagen — genug, um ein Feature nicht naiv zu bauen.

Tag	Kapitel (Reihenfolge)	Parallel
1	02 → 03 → 04 → 05	wann-llm
2	06 → 08 → 11	ai-feature-spec, adr-adaptation
3	17 → 19 → skimmen 16, 22	eval-plan, security-review-ai

Skip ok: 07–10 tief (nur Landkarte skimmen); 12–15 außer du brauchst RAG/Agent/FT sofort; 18, 20–28 für später.

Danach: Pfad 1.5 (Demo → Production) oder gezielt Teil III für deinen Adaptation-Schritt.

1.2 Tech-Lead / Architektur

Ziel: Control Flow vs. LLM Flow, Adaptation Ladder, Context, Routing, Hosting — Entscheidungen, die teuer zurückzunehmen sind.

Block	Kapitel	Parallel
Mental Model	03–06	Spec + Ampel
Architektur	07 → 08 → 09 → 10	adr-adaptation, adr-model-hosting
Bausteine (selektiv)	11, 12 oder 13–14, 16	tool-contract, agent-readiness / rag-production-ready
Qualität & Security als Architektur	17, 19	Eval-Plan, Security Review
Lifecycle	21, 24	model-change-checklist

Skip ok: 15, wenn FT nicht in 90 Tagen auf dem Tisch liegt; 25–28 nach dem ersten Go-Live nachziehen; Detailtiefe in 12 vs. 14 nur für den gewählten Zweig.

Deliverable: Adaptation-ADR + Hosting-ADR + Ownership-Skizze (wer Prompt/Eval/Model/On-Call).

1.3 Platform / SRE / Ops

Ziel: Serving, Observability, Kosten/SLOs, Model-Lifecycle, Incidents, Online-Qualität.

Block	Kapitel	Parallel
Was bricht anders	04, 09 (Tiers, Fallbacks)	—
Qualität online	17 → 18	eval-plan
Betriebskern	21 → 22 → 23	observability-minimum
Evolution & Störung	24 → 25	model-change-checklist, incident-runbook-ai
Go-Live Gate	templates/production-ready-checklist.md	Abschnitt 6 unten

Skip ok: Prompt-Handwerk tief (11 nur Contracts/Versionierung); RAG/Agent-Mechanik außer du betreibst die Pipeline; 26–28 für Platform-Rollout später.

Deliverable: Observability-Minimum live, Cost/Latency-Alerts, Model-Change im Release-Prozess, Incident-Runbook verlinkt.

1.4 Security-fokussiert

Ziel: Trust Boundaries, Injection, Tool Abuse, Leakage, Privacy/Compliance-Praxis, Red-Team-Stichprobe — als Architektur, nicht als Prompt-Appell.

Block	Kapitel	Parallel
Kontext	04, 05 (Rot-Ampel)	—
Angriffsfläche Bausteine	11 (Contracts), 12 (ACL/PII im Index), 13–14	tool-contract, agent-readiness
Kern	19 → 20	security-review-ai
Betrieb	22 (Logs ohne Secrets), 25 (Safety/Leak)	Incident-Runbook

Skip ok: Fine-Tuning (15); detaillierte Unit Economics (23) außer Budget-Missbrauch; Org-Kapitel außer Ownership von Security-Findings.

Deliverable: ausgefüllte Security-Review-Checkliste + Trust-Boundary-Skizze für ein kritisches Feature.

1.5 Von Demo zu Production (Handlungspfad parallel zum Lesen)

Ziel: nicht „Buch zu, dann bauen“, sondern Slice im Staging mit Spec, Eval, Guardrails, Obs.

Phase	Lesen (knapp)	Tun
0 — Stopp oder Go	05	wann-llm pro Teilproblem
1 — Spec	06	ai-feature-spec
2 — Adaptation	08, ggf. 12/14	adr-adaptation; RAG/Agent-Checkliste
3 — Schnitt	11, 16	Structured Output, Validate/Repair/Fallback
4 — Eval	17	eval-plan, Golden Set v0
5 — Security	19	security-review-ai
6 — Ops	21–23	observability-minimum
7 — Gate	18, 24	production-ready-checklist, Model-Change

Skip ok: Kapitel außerhalb des gewählten Adaptation-Zweigs; Org-Reife (27–28) bis der Slice stabil ist.

1.6 Optional: „Ich habe nur 1 Tag“

Morgens (Mental Model + Entscheidung)
03 skimmen → 05 + wann-llm → 06 halb ausfüllen (Success/Failure/Cost/Privacy).

Mittags (Adaptation + Schnitt)
08 → eine Stufe wählen → 11 (Contract + Structured Output) oder 16 (Loop-Muster).

Nachmittags (Qualität + Risiko)
17 (Golden Set Idee, 20–50 Cases) → 19 skimmen → security-review-ai stichprobenartig → production-ready-checklist als Lückenliste (nicht als Go-Live-Lüge).

Skip alles andere. Am nächsten Tag: Pfad 1.1 oder 1.5 fortsetzen.

Lesepfade — Übersicht

Pfad	Fokus	Kernkapitel	Typische Outputs
SE 2–3 Tage	Mental Model + Spec + Eval/Security light	03–06, 08, 11, 17, 19	Spec-Entwurf, Ampel, Eval-Skizze
Tech-Lead	Architektur & ADRs	07–11, 16–17, 19, 21, 24	2 ADRs, Ownership
Platform/SRE	Betrieb	04, 09, 17–18, 21–25	Obs, Alerts, Runbook
Security	Threat Model	11–14, 19–20, 22, 25	Security Review, Boundaries
Demo→Prod	Handlung	05–08, 11/12/14, 16–19, 21–24	Staging-Slice + Gate
1 Tag	Triage	03, 05–06, 08, 11/16, 17, 19	Lückenliste, nächster Engpass
E2E Walkthrough	Ein Feature, alle Schichten	Abschnitt 2 unten	Artefakt-Kette Spec→Gate→Incident

---

2. End-to-End-Walkthrough: Support-Antwort-Entwurf

Zweck: die Produktionsreife-Säule greifbar machen. Ein Feature, alle Schichten des Buchs — nicht als Tutorial eines Vendors, sondern als Entscheidungspfad mit Artefakten. Zahlen und Schwellen sind Beispiele (Stand August 2026); du ersetzt sie durch eure Spec.

Feature (fiktiv, realistisch): Support-Antwort-Entwurf — Agent:innen sehen Ticket-Text + vorgeschlagene Antwort mit Quellenangaben aus interner Doku. Senden bleibt menschlich (Wirkungsebene: vorschlagen, nicht ausführen).

Warum dieses Beispiel: Ampel oft gelb/grün hybrid; Ladder typisch RAG + Structured Output (kein Agent-Loop nötig); Security (indirekte Injection in Doku), Eval (Richtigkeit + Ton), Kosten/Latenz und Model-Change greifbar — ohne FT-Theater.

2.1 Phase für Phase

Phase	Entscheidung / Ergebnis (Beispiel)	Kapitel	Artefakt
0 — Ampel	Teilproblem A: Antwort formulieren → Gelb/Grün mit Review. Teilproblem B: Routing/Priorität aus Policy → oft Rot (Regeln). Hybrid: LLM nur für Entwurf + Citations; Status-Codes deterministisch.	05	wann-llm pro Teilproblem
1 — Spec	Success: ≥X % Task-Success im Golden Set; p95 < N s; €/Erfolg unter Cap; keine PII im Provider-Log. Failure Modes: Halluzination ohne Quelle, falsche Policy, Cost Spike.	06	ai-feature-spec v0
2 — Adaptation	Lowest competent: Structured + RAG, fester Workflow (retrieve → generate → validate). Kein Agent-Loop (ein Pfad reicht). FT: nein, solange Format/Eval mit Prompt+Schema hält.	08, 12	adr-adaptation; rag-production-ready
3 — Modelle	Primary: Balanced-Tier; Fallback Fast bei Last; Strong nur für Eskalation/Stichprobe. Pin der Model-ID. Hosting: API zuerst, Self-Host nur mit ADR.	09	adr-model-hosting
4 — Schnitt	Prompt = Contract (Rolle, Schema, „ohne Quelle → refuse“). Structured Output + Validate → begrenzter Repair → Fallback „Mensch schreibt selbst“.	11, 16	prompt_version, Schema, Orchestrierungs-Outcomes
5 — Eval	Golden Set: 40–80 Tickets (anonymisiert) mit erwarteter Quelle/Label + „Fail“-Definition. Offline-Gate vor Merge; Online: Thumbs, Edit-Rate, Citation-Click.	17, 18	eval-plan + Golden Set v0
6 — Security / Privacy	Threat: indirekte Injection in Wissensartikeln; Leakage von internen Links/PII; kein ungeprüftes HTML. Guardrails: Content-as-data, Redaction, ACL am Index.	19, 20	security-review-ai
7 — Deploy / Obs / Cost	Timeouts, Streaming optional (UX), Rate limits pro Tenant. Traces: retrieve / model / validate / tokens. Alerts: error rate, €-Spike, p95, quality drop.	21–23	observability-minimum
8 — Gate	Production-Ready ehrlich; Kill-Switch; Canary %. No-Go ist Erfolg, wenn Lücken benannt sind.	templates/production-ready-checklist.md	Go/No-Go + Backlog
9 — Lifecycle	Model-/Prompt-Change = Breaking Change: Eval-Gate, Canary, Rollback.	24	model-change-checklist
10 — Incident	Szenarien: Cost Spike (Loop/Traffic), Quality Drop nach Pin-Wechsel, Safety (Leak/Injection).	25	incident-runbook-ai v0
11 — Ownership	Namen für Prompt, Eval, Model-Pin, On-Call — nicht „das Team“.	26	Ownership-Matrix

2.2 Mini-Spec (ausgefüllt, gekürzt)

Feld	Beispielwert
Job-to-be-done	Wenn ich ein Support-Ticket bearbeite, will ich einen belegten Antwortentwurf, damit ich schneller und konsistenter antworte.
Wirkungsebene	Vorschlagen — Senden/Refund/Account-Änderung nur durch Mensch.
Hybrid-Schnitt	LLM: Entwurf + Citations. Deterministisch: Ticket-Status, SLA-Timer, Berechtigungen.
Qualität	Task Success ≥ 80 % im Golden Set (menschlich gelabelt); „ohne Quelle antworten“ = Fail.
Latency	p95 Gesamt < 8 s interaktiv (Retrieve + Generate); sonst async-Queue.
Kosten	Cap €/Ticket und €/Tag; bei Überschreitung Fallback ohne Modell.
Privacy	Keine Klartext-PII an Provider, wenn vermeidbar; Retention Logs N Tage; Residenz laut Vertrag.
Ladder	Structured + RAG; Agent: nein; FT: nein (Review in 90 Tagen).

2.3 Orchestrierungs-Skizze (logisch)

Ticket (redacted)
    → Retrieve (Index + ACL) → chunks + source_ids
    → Generate (pinned model, prompt_version) → structured draft
    → Validate (schema, source_ids ⊆ retrieved, policy deny-list)
         ├ ok → UI: Entwurf + Citations
         ├ repair (≤1–2×) → Validate
         └ fallback → leeres Template + „kein Entwurf“ + Grund
    → Telemetry (trace, tokens, outcome, cost)

Das ist Thin Orchestration (16): Kontrolle im Code, Eloquenz im Modell, Wahrheit an Quellen und Validierung gebunden.

2.4 Was „fertig“ hier heißt — und was nicht

Fertig (Slice)	Nicht fertig (und ok)
Spec + ADR + Golden Set v0 + Security-Durchlauf	Alle Edge-Cases der Wissensbasis
Staging mit Flag und Kill-Switch	Multi-Provider Active-Active
Obs-Minimum und Cost-Cap	Eigenes Fine-Tune
Benannte Owner und Runbook-Skizze	Org-weites Reifegrad-Level 4

Anti-Pattern in diesem Walkthrough: „Wir bauen erst den Agenten mit zehn Tools, Eval kommt nach dem Launch.“ Hier: messen und absichern im selben Slice wie der Happy Path.

2.5 Lesen parallel zum Nachbauen

Wenn du …	Dann Lesepfad
den Walkthrough nachbauen willst	Pfad 1.5 (Demo→Prod) + diese Tabelle
nur entscheiden willst	08, 33
Team-Ramp brauchst	Abschnitt 5 (30-Tage) und 26–28

Ersetze „Support-Antwort“ durch euer Feature — die Phasen und Artefakte bleiben; die Ladder-Stufe wechselt.

---

3. Workshop-Agenda (1 Tag / optional 2 Tage)

Zweck: ein reales (oder realistisch geplantes) Feature gemeinsam spezifizieren und absichern — nicht Folien-Theater.

Teilnehmer: 1 Feature-Owner, 1–2 Devs, ideal 1 Person mit Security-/Ops-Blick. Max. ~8 Personen.

Vorbereitung (1 Woche vorher): Pilot-Kandidat benennen; Zugang zu Repo/Staging klären; Templates und Checklisten kopierbar bereitlegen.

3.1 Ein-Tages-Agenda

Zeit	Block	Inhalt	Output
09:00–09:30	Kickoff	Ziel, Non-Goals, „ein Feature“ festnageln	Scope-Satz
09:30–10:30	Mental Model	AI Eng ≠ ML Eng; Non-Determinismus; Thesen light (T2, T3, T4, T10)	gemeinsame Sprache
10:30–10:45	Pause
10:45–12:00	Spec-Übung	Job-to-be-done, Success/Failure, Cost Envelope, Privacy	ai-feature-spec v0
12:00–12:30	Ampel	wann-llm pro Teilproblem	Grün/Gelb/Rot + Hybrid-Schnitt
12:30–13:15	Mittag
13:15–14:15	Adaptation-ADR	Ladder: Prompt → Structured → RAG → Tools/Workflow → Agent → FT → Train	adr-adaptation Entwurf
14:15–15:15	Mini-Eval	15–30 Golden Cases skizzieren; Metrik, Gate-Idee	eval-plan v0
15:15–15:30	Pause
15:30–16:30	Security Threat Model light	Trust Boundaries, Injection, Tools, Egress	security-review-ai
16:30–17:00	Ownership-Matrix	Prompt / Eval / Model / On-Call	Namen, nicht Rollen-Abstracta
17:00–17:30	Retro	Demo-Theater vs. belastbar; nächste 2 Wochen	Action-Board

3.2 Optionaler Tag 2 (Vertiefung)

Zeit	Block	Inhalt	Output
Vormittag	Baustein-Tiefgang	RAG oder Tools/Agent (nicht beides halb)	rag-production-ready / agent-readiness; ggf. tool-contract
Nachmittag	Ops light	Serving-Grenzen, observability-minimum, Cost/Latency grob	Trace-Plan, Alert-Liste
Spätnachmittag	Gate & Lifecycle	production-ready-checklist; Model-Change	Lücken-Backlog; model-change-checklist im Prozess

3.3 Workshop-Outputs (Checkliste)

• Feature-Spec v0 mit messbaren Success/Failure Criteria
• Ampel-Entscheidung inkl. Hybrid-Schnitt
• Adaptation-ADR (auch wenn „nur Prompt + Validate“)
• Eval-Plan v0 + Liste Golden Cases (auch unvollständig)
• Security Review einmal durchlaufen
• Ownership-Matrix mit Namen
• Max. 5 Actions für die nächsten 10 Arbeitstage

Anti-Pattern: Workshop endet mit „wir brauchen eine Platform“ und ohne Spec. Platform kommt nach dem ersten belastbaren Slice (27).

---

4. Checklisten-Überblick

Lebende Dateien unter checklists/. Kurzform hier; Details und Meta-Felder in den Dateien.

Datei	Zweck	Kapitel / Kontext
wann-llm.md	Ampel Grün/Gelb/Rot pro Teilproblem	05, Spec 06
rag-production-ready.md	RAG über „Vektor-DB steht“ hinaus	12, Gate 17–22
agent-readiness.md	Agent vs. Pipeline; Go-Live-Voraussetzungen	13–14
security-review-ai.md	Security Review vor Seitenwirkungen	19, 20
observability-minimum.md	Mindest-Telemetrie und Alerts	22, 23
team-onboarding-30-tage.md	Team-Ramp in 4 Wochen	26–28; Abschnitt 5

Verwandte Templates (nicht Checklisten, aber oft am selben Gate):
production-ready-checklist, eval-plan, model-change-checklist, incident-runbook-ai.

4.1 Snapshot: Wann LLM

Quelle: checklists/wann-llm.md — pro Teilproblem, nicht nur pro Epic.

Grün (oft sinnvoll)

• Unstrukturierte Eingaben (Freitext, Dokumente, variable Formulierungen)
• Hohe Varianz in der Form, aber prüfbares Ziel (Labels, Schema, Review)
• Generierung mit menschlicher oder automatischer Prüfung vor Wirkung
• Klassifikation / Extraktion mit Eval-Set in greifbarer Zeit
• Nutzen klar größer als Runtime-Komplexität (Varianz, Kosten, Latency)

Gelb (nur mit Guardrails)

• Semi-strukturierte Workflows mit Tools / Seitenwirkungen
• Nutzer-sichtbare Fakten (Citations, Ablehnung ohne Evidenz)
• Kosten- oder latenzsensitiv bei erwartetem Volumen
• Produkt-Agent / Mehrschritt-Loop (Stopps, Permissions, Eval)
• Personenbezogene oder interne Daten im Context (Privacy-Grenzen klar)

Rot (besser ohne LLM)

• Deterministische Business Rules (if/else, Policy-as-Code)
• Harte Korrektheit ohne Toleranz (z. B. Geld allein durchs Modell)
• Reine Lookups / stabile Schemas / Katalog-APIs
• AuthZ, Krypto, Signaturen, Berechtigungsentscheidungen
• Kein Weg zu Eval, Review oder Incident-Ownership
• Asymmetrisches Risiko: ein Fehler wiegt viele Erfolge auf

Realitätscheck: Job-to-be-done in einem Satz · Orakel-Test (5 % überzeugend falsch) · Eval in ~2 Wochen definierbar · Budget (€, p95) grob bekannt · Ownership Prompt/Model/On-Call benannt.

4.2 Snapshot: RAG Production Ready

Quelle: checklists/rag-production-ready.md

• Chunking-Strategie dokumentiert und evaluiert
• Hybrid Search oder begründetes reines Dense/Sparse
• Freshness / Re-Index-Prozess
• Citation / Source-IDs in der Antwort
• Retrieval-Metriken (Recall@k, MRR, …) im Eval
• End-to-End Task-Success, nicht nur Retrieval
• Handling: leere Treffer, widersprüchliche Quellen
• PII / ACL beim Indexieren berücksichtigt
• Latency- und Cost-Budget für Retrieve + Generate

4.3 Snapshot: Agent Readiness

Quelle: checklists/agent-readiness.md

Agent lohnt eher, wenn

• Schritte nicht a priori festlegbar
• Tool-Auswahl kontextabhängig
• Human-in-the-loop akzeptabel oder nötig
• Eval für Trajectories existiert

Pipeline ist besser, wenn

• Fester Workflow, bekannte Verzweigungen
• Strenge Kosten-/Latency-SLOs
• Auditierbarkeit jedes Schritts kritisch
• Team noch ohne Agent-Ops-Reife

Vor Agent-Go-Live

• Tool-Contracts + Allowlist
• Step- und Cost-Budgets
• Abbruchbedingungen
• Observability pro Step
• Kill-Switch / Feature-Flag

4.4 Snapshot: Security Review (AI App)

Quelle: checklists/security-review-ai.md

• Trust Boundaries skizziert (User, Retrieval, Prompt, Tools, Downstream)
• Direct + Indirect Prompt Injection bedacht
• Tool-Permissions Least Privilege
• Output nicht ungeprüft an Shell/SQL/HTML
• Data Egress: was darf zum Model-Provider?
• Logs ohne Secrets / PII-Klartext
• Rate limits / Abuse
• Red-Team-Stichprobe für kritische Flows

4.5 Snapshot: Observability Minimum

Quelle: checklists/observability-minimum.md

• Request-ID / Trace über Orchestration
• Model-ID, Prompt-Version, Routing-Entscheidung
• Token In/Out + geschätzte Kosten
• Latency Breakdown (retrieve / model / tools)
• Error classes (validation, timeout, provider, tool)
• Quality proxy (User-Feedback, Judge-Sample, Task Success)
• Alerts: Error Rate, Cost Spike, Latency, Quality Drop

4.6 Snapshot: 30-Tage Team-Onboarding (Kurzform)

Quelle: checklists/team-onboarding-30-tage.md — ausführlich in Abschnitt 5.

Woche	Haken (Kurz)
1	Thesen/Ampel · Pilot spezifiziert · Eval-Baseline
2–3	Adaptation-ADR · dünner Slice Staging · Obs Minimum · Security Review
4	Production-Ready-Check · Model-Change-Prozess · Ownership-Matrix · Retro

---

5. 30-Tage Onboarding (angereichert)

Zielbild nach 30 Tagen: ein Pilot-Feature im Staging (oder eng begrenzter Prod-Canary) mit Spec, Eval-Baseline, Security-Durchlauf, Observability-Minimum und benannten Ownern — nicht „AI-Platform fertig“.

Angelehnt an checklists/team-onboarding-30-tage.md und die Kapitel 26–28.

Woche 1 — Sprache, Ampel, Spec, Eval-Rohbau

Tag-Fokus	Aktivität	Artefakt
Gemeinsame Basis	Thesen T1–T10 und Abgrenzung AI Eng vs. ML Eng / Coding-Agent (03, 02)	1 Seite „so reden wir“
Ampel	Teilprobleme des Pilots durch wann-llm	Ampel-Tabelle
Spec	ai-feature-spec: Success Metrics, Failure Modes, Cost Envelope, Privacy	Spec v0 im Repo
Eval	20–50 Golden Cases skizzieren; Metrik und „was zählt als Fail“	eval-plan v0 + Roh-Set

Definition of Done Woche 1: Spec reviewbar; LLM ja/nein/hybrid begründet; mindestens eine Person kann das Failure Mode des Pilots in zwei Sätzen erklären.

Woche 2 — Adaptation und dünner Slice

Fokus	Aktivität	Artefakt
Entscheidung	Adaptation Ladder (08); bewusst nicht FT, wenn Prompt/RAG/Tools reichen	adr-adaptation
Schnitt	Prompt-Contract / Structured Output (11); Orchestrierung Validate/Repair/Fallback (16)	lauffähiger Happy Path
Spezial	Bei RAG: rag-production-ready starten; bei Agent: agent-readiness + tool-contract	Checklisten-Status
Staging	Feature-Flag / Kill-Switch; kein ungefilterter Side-Effect	Slice in Staging

Definition of Done Woche 2: ADR merged; Staging-Demo am realen Datenausschnitt (anonymisiert ok), nicht nur am Happy-Path-Fixture.

Woche 3 — Messen, sehen, absichern

Fokus	Aktivität	Artefakt
Eval	Offline-Lauf Golden Set; CI-Gate zumindest „warn“ (17)	Gate-Skript / CI-Job
Observability	observability-minimum: Trace, Model/Prompt-Version, Tokens/Kosten, Errors	Dashboard light
Security	security-review-ai einmal vollständig; kritische Findings blocken Go-Live	Review-Protokoll
Privacy	Residenz, Retention, Redaction grob (20)	Abschnitt in Spec/ADR

Definition of Done Woche 3: Regression sichtbar (auch manuell); Security-Findings priorisiert; Cost pro Request schätzbar.

Woche 4 — Gate, Ownership, Retro

Fokus	Aktivität	Artefakt
Production-Ready	production-ready-checklist ehrlich abhaken	Go / No-Go + Lücken-Backlog
Lifecycle	Model-Change im Release-Prozess (24)	model-change-checklist verlinkt
Incidents	Runbook-Skizze für Cost Spike, Quality Drop, Safety (25)	incident-runbook-ai v0
Ownership	Matrix Prompt / Eval / Model / On-Call mit Namen (26)	CONTRIBUTING oder Team-Wiki
Retro	Was war Demo-Theater? Was ist belastbar? Nächste 60 Tage	Retro-Notes

Definition of Done Woche 4: Gate-Ergebnis dokumentiert (auch „noch nicht Prod“ ist Erfolg); Ownership unmissverständlich; max. 5 Follow-ups mit Owner und Datum.

Onboarding — Rollen (Minimal)

Rolle	Verantwortung in den 30 Tagen
Feature-Owner	Spec, Priorität, „was ist Fail“
Implementierer	Slice, Contracts, CI-Anbindung
Eval-Owner	Golden Set, Gate-Schwellen (darf dieselbe Person sein — dann explizit)
Security-Reviewer	Checkliste + Findings (kann rotierend sein)
On-Call-Designat	Wer bei Cost/Quality/Safety wach wird

Anti-Patterns im Onboarding

• Parallel drei Pilots und null Eval.
• „Platform first“ ohne Feature-Spec.
• Security am Tag 29.
• Ownership „das Team“.
• Go-Live trotz offener Rot-Ampel-Teilprobleme ohne deterministischen Schnitt.

---

6. Production-Ready Gate

Lebende Quelle: templates/production-ready-checklist.md.
Kapitel-Kontext: Qualität und Absicherung 17–20; Betrieb und Evolution 21–25.

Das Gate ist ein Go/No-Go mit Belegen, keine Stimmungsabfrage. Unchecked Items ohne Plan = No-Go oder bewusstes Risiko mit Owner und Ablaufdatum.

Snapshot: Production Ready (AI Feature)

Spec & Ownership

• Feature-Spec mit messbaren Success/Failure Criteria
• Named Owner für Prompt, Eval, Model, On-Call

Qualität

• Golden Set + Offline Gates
• CI blockt Regressionen (oder klar definiertes Warn→Block-Datum)
• Human-Stichprobe für kritische Flows

Architektur

• Adaptation-ADR dokumentiert
• Structured Output / Validation wo nötig
• Fallbacks (Model, Rule-based, Human)

Security & Privacy

• Threat Model (Injection, Leakage, Tool Abuse)
• Input/Output Guardrails
• Logging redaction; keine Secrets im Prompt-Log
• Data residency / retention geklärt

Betrieb

• Tracing (Prompt/Retrieval/Tool/Token)
• Cost + Latency Dashboards und Alerts
• Rate limits / Budget Caps
• Model-Change-Checklist im Release-Prozess
• Incident-Runbook verlinkt

Gate-Praxis

1. Checkliste im PR oder Go-Live-Ticket verlinken.
2. Jeden Haken mit Link (Spec, Dashboard, ADR, Runbook) belegen.
3. Offene Punkte: Owner + Datum + ob sie Prod blocken.
4. Nach Model-Upgrade: Gate delta erneut (siehe model-change-checklist) — Model-Updates sind Breaking Changes (These 9).

RAG- und Agent-Features: zusätzlich Abschnitt 4.2 bzw. 4.3 vor dem allgemeinen Gate grün oder bewusst akzeptiert.

---

7. „Erster Arbeitstag nach dem Buch“ — 7 konkrete Actions

Nicht „die Platform bauen“. Einen Engpass schließen.

1. Ein Feature wählen — real oder nächste Quartals-Kandidat; Scope in einem Satz.
2. wann-llm ausfüllen — pro Teilproblem Ampel; Hybrid-Schnitt notieren.
3. ai-feature-spec anlegen — Success Metrics, Failure Modes, Cost Envelope, Privacy; Lücken als „unbekannt“ markieren, nicht erfinden.
4. adr-adaptation skizzieren — gewählte Sprosse der Ladder + warum nicht die teurere.
5. Eval-Baseline starten — 20 Golden Cases in eine Datei; eval-plan mit einer primären Metrik.
6. Security light — Trust Boundaries skizzieren; security-review-ai einmal durch; Top-3-Risiken.
7. Ownership + nächster Termin — Namen für Prompt/Eval/Model/On-Call; 30-Minuten-Review in 5 Arbeitstagen mit Spec+ADR+Eval-Rohbau.

Optional am selben Tag: observability-minimum als Backlog-Tickets schneiden (noch nicht implementieren müssen).

Wenn Action 2 auf Rot ohne Hybrid landet: kein Model-API-Ticket öffnen — Rules/UI/klassische Automation zuerst.

---

Key Takeaways

• Lesen folgt Rolle und Engpass; Templates und Checklisten laufen parallel, nicht danach.
• Der E2E-Walkthrough (Abschnitt 2) verbindet Spec → Adaptation → Eval → Security → Ops → Incident an einem Feature.
• Workshop und 30-Tage-Onboarding erzeugen Artefakte (Spec, ADR, Eval, Security, Ownership) — nicht nur Alignment-Gefühl.
• Checklisten unter checklists/ und das Production-Ready-Template sind die operativen Gates; dieser Anhang ist Snapshot und Wegweiser.
• Production-Ready heißt belegbare Spec, Eval, Guardrails, Obs und Lifecycle — nicht „Demo überzeugt Stakeholder“.
• Der erste Tag nach dem Buch: ein Feature, Ampel, Spec, Adaptation, Eval-Rohbau, Security light, Namen.

Praktische nächste Schritte

1. Wähle in Abschnitt 1 den Pfad zu deiner Rolle — oder gehe Abschnitt 2 (E2E) mit eurem Pilot-Feature parallel.
2. Kopiere die für dich relevanten Dateien aus checklists/ und templates/ ins Projekt-Wiki oder Repo (docs/ai/…) und fülle sie am Pilot aus.
3. Plane Workshop (Abschnitt 3) oder 30-Tage-Onboarding (Abschnitt 5) mit Datum und Feature-Owner — ohne Owner kein Start.
4. Hänge production-ready-checklist an euer Definition-of-Done für AI-Features; erste Nutzung darf „nur Lückenliste“ sein.