diff --git a/docs/dhbw-fundament.md b/docs/dhbw-fundament.md
new file mode 100644
index 0000000..5104bf1
--- /dev/null
+++ b/docs/dhbw-fundament.md
@@ -0,0 +1,44 @@
+# DHBW Technik I — Fundament (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
+**Format-Vorbild:** wie das HdM-Fundament in `CLAUDE.md`, aber DHBW-spezifisch zugeschnitten.
+
+## Drei Meta-Lernziele für DHBW Technik I
+
+DHBW-Studierende sind Dualstudierende — sie pendeln zwischen Theorie-Phase (an der DHBW) und Praxis-Phase (im Unternehmen). Das verändert die didaktische Aufgabe gegenüber HdM:
+
+### 1. Industrie-Anschluss-Fähigkeit
+
+Studis sollen am Ende **mit aktuellen Industrie-Tools, -Konzepten und -Konventionen vertraut sein** — nicht nur konzeptionell, sondern handwerklich. Ziel: in der Praxis-Phase im Unternehmen können sie auf 70 % des dort verwendeten Stacks zeigen und sagen „kenne ich, kann ich".
+
+*Konsequenz:* keine veralteten Tools (kein jQuery, kein PHP-Heritage). Aktuelle Stack-Wahl: Node 24 LTS, ESM, TypeScript, Docker, Git/GitHub. CLI-First.
+
+### 2. Selbstständig-Lernen-Lernen
+
+DHBW-Studis kommen oft direkt aus dem Abi und in eine erste fachliche Auseinandersetzung mit IT. **Werkzeugkompetenz zum eigenen Lernen** ist wichtiger als enzyklopädisches Wissen.
+
+*Konsequenz:* explizite Anleitung wie man Doku liest (MDN, ARIA-Spec, RFC), wie man Errors googelt, wie man eine Issue formuliert. „Ich kenne die Doku" > „ich kenne die Antwort auswendig".
+
+### 3. Verbindung Theorie ↔ Praxis-Phase
+
+Was in der DHBW gelernt wird, wird sofort in der Praxis-Phase eingesetzt (oder eben nicht — dann hat die Veranstaltung versagt). **Jedes Thema braucht einen erkennbaren Anwendungsfall im typischen Praxis-Setting** des dualen Studiums.
+
+*Konsequenz:* Bezüge zu konkreten Unternehmens-Szenarien (z.B. „intern README schreiben", „CI-Pipeline reparieren", „Konvention im Repo lesen") sind nicht Bonus, sondern Pflicht.
+
+## Didaktische Werkzeuge (vom HdM-Fundament übernommen)
+
+Die HdM-Werkzeuge (Constructive Alignment, Advance Organizer, Mayer-12, Informatikdidaktik) gelten unverändert. Nur die *Lernziel-Inhalte* sind DHBW-spezifisch (siehe oben).
+
+## Validierungs-Kriterien (zusätzlich zur HdM-Checkliste)
+
+- [ ] Bedient die Folie mindestens eines der drei DHBW-Meta-Lernziele?
+- [ ] Gibt es einen *erkennbaren Praxis-Bezug* (Tool / Konvention / Stack-Komponente, die im Unternehmen real verwendet wird)?
+- [ ] Hilft das Material den Studis, das Thema *selbstständig zu vertiefen* (Verweis auf Doku, Beispiel-Repo, Übung)?
+
+## Offene Fragen für dich
+
+1. **Tool-Stack-Fokus:** Node + Docker + Git ist meine Lese-Annahme aus dem aktuellen Kurs. Stimmt das mit der Praxis-Verteilung an der DHBW Karlsruhe überein, oder gibt es einen anderen Industrie-Anschluss-Fokus (z.B. Java/Spring, .NET, Python)?
+2. **Praxis-Phase-Realität:** wie sehen die DHBW-Praxis-Phasen typischerweise aus? Welche Konventionen begegnen den Studis dort am häufigsten?
+3. **Soft-Skills-Block (Kapitel 8 best-practices):** soll der bleiben in dieser Tiefe oder fokussieren wir auf Hard-Skills?
+
+**Bitte beantworte → ich lock das Fundament → leite daraus die kapitelweisen Lernziele ab.**
diff --git a/docs/dhbw-pruefungsleistung.md b/docs/dhbw-pruefungsleistung.md
new file mode 100644
index 0000000..06541af
--- /dev/null
+++ b/docs/dhbw-pruefungsleistung.md
@@ -0,0 +1,77 @@
+# DHBW Technik I — Prüfungsleistung-Kompetenzen (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
+**Kontext:** DHBW Technik I hat keine Klausur, sondern eine **Projekt-Prüfungsleistung** (75 Pkt + 10 Bonus, Code-Abgabe + Präsentation).
+
+## Was die Prüfungsleistung zeigen soll
+
+Die Projekt-Abgabe sollte demonstrieren, dass Studis die **drei DHBW-Meta-Lernziele** verkörpern (siehe `dhbw-fundament.md`):
+
+1. **Industrie-Anschluss-Fähigkeit** — Stack ist aktuell, Konventionen werden eingehalten.
+2. **Selbstständig-Lernen** — Lösung ist nicht 1:1 aus dem Kurs, sondern eigener Pfad mit Doku/Beispielen.
+3. **Theorie-Praxis-Verbindung** — das Projekt löst ein realistisches (kleines) Industrie-Problem.
+
+## Vorschlag: 8 Kompetenz-Felder
+
+Pro Feld 5–15 Punkte (insgesamt 75 + 10 Bonus möglich).
+
+### 1. Projekt-Strukturierung & README (10 Pkt)
+- Klare Verzeichnisstruktur, sinnvolle Namen
+- README erklärt: was tut das Projekt, wie installieren, wie starten, wie testen
+- LICENSE-Datei
+
+### 2. Code-Qualität (15 Pkt)
+- Lesbar (sinnvolle Variablen-/Funktions-Namen, kurze Funktionen)
+- Konsistente Formatierung (Prettier/ESLint oder gleichwertig)
+- Keine ungenutzten Imports / Variablen
+- Sinnvolle Aufteilung in Module
+
+### 3. Git-Hygiene (10 Pkt)
+- Mindestens 5 sinnvolle Commits, keine `wip` / `fix` ohne Kontext
+- Conventional Commits Format (feat:, fix:, docs: …)
+- `.gitignore` für `node_modules`, `.env`, build-outputs
+- Optionale Bonus: GitHub-Workflow / CI
+
+### 4. Tests (10 Pkt)
+- Mindestens 3 Unit-Tests für nicht-triviale Funktionen
+- Tests laufen lokal durch (`npm test`)
+- Test-Coverage-Bericht (optional)
+
+### 5. Docker-Containerisierung (10 Pkt)
+- `Dockerfile` baut sauber
+- `docker compose up` startet das Projekt
+- Multi-stage-build (Bonus, falls sinnvoll)
+
+### 6. HTTP / API-Design (10 Pkt)
+- Mindestens 3 REST-Endpunkte (z.B. GET/POST/DELETE)
+- Sinnvolle Statuscodes (200, 400, 404, 500)
+- JSON-Antworten mit Schema
+
+### 7. Frontend (10 Pkt) *— wenn das Projekt eine UI hat*
+- Funktioniert auf Smartphone + Desktop
+- Mindestens 3 a11y-Kriterien erfüllt (semantisches HTML, alt-Text, Kontrast)
+- Build mit Vite oder gleichwertig
+
+### 8. Präsentation (5 Pkt + 10 Bonus)
+- 5 Min Live-Demo des Projekts
+- Erklärung: was war die größte Herausforderung, wie wurde sie gelöst
+- Bonus: kurze Reflexion über Design-Entscheidungen
+
+## Punkte-Skalierung
+
+| Bewertung | Punkte | Bedeutung |
+|-----------|-------:|-----------|
+| Sehr gut | 80–85 | über den Erwartungen, mit Bonus-Punkten |
+| Gut | 67–79 | alle Kompetenzen mit kleinen Lücken |
+| Befriedigend | 50–66 | alle Kompetenzen wenigstens angeschnitten |
+| Ausreichend | 33–49 | mind. 5 Felder ordentlich, 3 ggf. lückenhaft |
+| Nicht bestanden | < 33 | mehrere zentrale Felder fehlen |
+
+## Offene Fragen für dich
+
+1. **Frontend-Pflicht oder optional?** Kompetenz 7 ist nur sinnvoll wenn UI-Bestandteil — vielleicht macht es Sinn, das Projekt-Thema so zu wählen, dass UI Pflicht ist (z.B. „kleine Web-App mit Backend + Frontend").
+2. **Punkte-Verteilung 10/15/10/10/10/10/10/5:** stimmt das mit deinem Gewichts-Gefühl überein?
+3. **Bonus-Punkte:** wofür konkret? Vorschläge: Conventional Commits + CI-Workflow + Test-Coverage + Multi-stage-Docker + a11y-Audit. Welche zählst du als Bonus?
+4. **Plagiat-Erkennung:** wie gehst du mit AI-generierten Code-Anteilen um? KI-Hilfe ist Realität — sinnvoll Reglement?
+
+**Bitte beantworte → ich finalisiere die Prüfungsleistung-Kompetenzen → leite daraus die Lehrinhalte pro Kapitel ab.**