Initial commit: demo-epb v1.0 — Elektrische Parkbremse Demo

Vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet-
Software. Zeigt ASPICE 4.0 / ISO 26262-konforme Entwicklung im Monorepo.

Inhalte:
- 5 Plaene (PID, PM-, QA-, SWE-, Test-Plan) in Word, ausgefuellt mit
  EPB-spezifischen Inhalten
- 10 System-Anforderungen + 25 Software-Anforderungen (Doorstop-MD)
- 5 System-Architektur-Elemente + 10 Software-Architektur-Elemente
  mit PlantUML-Diagrammen und vollstaendigem Mapping
- 3 implementierte Komponenten (Apply Controller D, Actuator Driver B,
  Switch Debouncer QM) plus 7 Header-Stubs
- 28 Unit-Tests, alle gruen, mit Coverage- und MISRA-Build-Targets
- Audit-Artefakte: 1 Review-Protokoll, 1 Non-Conformity, 1 MISRA-Record
- Gitea-Actions-CI-Pipeline (validate.yml)
- Doorstop-Konfiguration fuer bidirektionale Traceability
- Generator-Skript fuer alle 50 Reqs/Arch-Elemente aus Strukturdaten
- README mit gefuehrter Tour fuer Prospects

docs/non-conformities-md/NC-001.md

@@ -0,0 +1,60 @@
+---
+nc-id: NC-001
+projekt: demo-epb
+datum-festgestellt: 2026-05-11
+schwere: Critical
+status: Closed
+---
+
+# Non-Conformity NC-001: Step-Counter-Ueberlauf nicht dokumentiert
+
+| Feld                | Wert                              |
+|---------------------|-----------------------------------|
+| NC-ID               | NC-001                            |
+| Projekt             | demo-epb                          |
+| Datum festgestellt  | 2026-05-11                        |
+| Festgestellt durch  | Review REV-001                    |
+| Betroffenes Artefakt| `src/apply_controller.c`          |
+| Anforderung         | SWE-002 (Watchdog)                |
+| Schwere             | Critical                          |
+| Status              | Closed                            |
+
+---
+
+## 1. Beschreibung
+
+Der `step_count` im Apply-Controller ist als `uint32_t` deklariert und wird in
+`apply_ctrl_step_50ms` monoton inkrementiert. Bei 50 ms/Tick ueberlaeuft der
+Zaehler nach 2^32 * 50 ms ~= 6.8 Jahren. Der Watchdog in SWA-002 vergleicht
+zwar nur das Delta zwischen zwei Lese-Zugriffen (Wrap-Around unkritisch), aber
+das Verhalten ist nicht im Header dokumentiert und kann bei nachfolgender
+Code-Pflege Fehler erzeugen.
+
+## 2. Risikobewertung
+
+| Aspekt            | Bewertung                                                     |
+|-------------------|----------------------------------------------------------------|
+| Auswirkung        | Theoretisch Watchdog-False-Negative bei Wrap-Around-Vergleich  |
+| Eintritts-Wahrscheinlichkeit | Sehr niedrig (6.8 Jahre Lebensdauer)                |
+| Sicherheits-Beitrag | Indirekt — Watchdog ist Teil der SG-01 Implementierung       |
+
+## 3. Sofortmassnahme
+
+Header-Kommentar in `apply_controller.h` ergaenzt: explizite Beschreibung des
+Wrap-Around-Verhaltens. Watchdog-Implementierung (in SWA-001) muss Delta-
+Vergleich mit `uint32_t` Subtraktion verwenden (Wrap-safe).
+
+## 4. Korrekturmassnahme (Root-Cause)
+
+Im Code-Review-Checklisten-Eintrag "Integer-Ueberlauf-Verhalten dokumentieren"
+ergaenzen. Pruefung in folgenden Reviews.
+
+## 5. Verifikation
+
+- Kommentar in `apply_controller.h` v1.1 (Commit `<hash>`)
+- Watchdog in SWA-001 verwendet `uint32_t`-Subtraktion (siehe SWA-001 §4)
+- Review-Checkliste aktualisiert
+
+## 6. Abschluss
+
+Geschlossen am 2026-05-11 durch S. Lohmaier nach Verifikation.