feat: Project Manual + CM-/RM-Plan + Landing-Page

3 neue Plaene:
- Project Manual: Master-Wegweiser fuer neue Projektmitglieder,
  Lese-Reihenfolge, Rollen, Lebenszyklus, Dokumenten-Landschaft
- Configuration Management Plan: CIs, Baselines, Change Control,
  Release-Prozess, Aufbewahrungsfristen (ASPICE SUP.8)
- Risk Management Plan: Projekt-Risiken (abgegrenzt von HARA),
  Klassifikations-Skala, Risiko-Register, Eskalations-Pfad

Landing-Page (Startseite):
- tools/generate_landing_page.py erzeugt build/index.html
- Standalone-HTML, oeffnet im Browser ohne Server
- KPI-Cards: SG/SYS/SWE/Arch/Komponenten/Tests-Counts
- Sektionen mit Links: Plaene, Safety, Manuals, Audit, Reports,
  Diagramme, Source-Code, externe Links
- Existenz-Check: nicht-generierte Reports werden grau markiert
- Im Release-Bundle als index.html ganz oben

CI-Integration:
- validate.yml: neuer Step "Landing-Page" + Upload als Artefakt
- release.yml: Landing-Page generieren + ins Bundle einbauen,
  zusaetzlich Source-Code im Bundle (war vorher nur als tar.gz)

Makefile: neues Target `make landing-page`

docs/plans-md/CM-Plan.md

@@ -0,0 +1,148 @@
+---
+doc-id: SLM-EPB-CM-001
+version: 1.0
+status: Freigegeben
+datum: 2026-05-12
+---
+
+# Configuration Management Plan (CM-Plan)
+
+| Feld         | Wert                                  |
+|--------------|----------------------------------------|
+| Projekt      | demo-epb                               |
+| Dokument-ID  | SLM-EPB-CM-001                         |
+| Version      | 1.0                                    |
+| Status       | Freigegeben                            |
+| Datum        | 2026-05-12                             |
+| Norm         | ASPICE SUP.8 + ISO 26262-8 §7          |
+
+---
+
+## 1. Zweck
+
+Beschreibt, wie Konfigurations-Items identifiziert, versioniert, freigegeben
+und kontrolliert geaendert werden.
+
+## 2. Configuration Items (CIs)
+
+Folgende Artefakte stehen unter Konfigurationskontrolle:
+
+| Typ                     | Pfad                                   | Versionierung                |
+|-------------------------|----------------------------------------|------------------------------|
+| Source-Code             | `src/**/*.{c,h}`                       | Git                          |
+| Tests                   | `tests/**`                              | Git                          |
+| Anforderungen           | `reqs/{sys,swe}/*.md`                   | Git + Doorstop-Item-Hash     |
+| Architektur             | `arch/{sys,swe}/*.md`                   | Git + Doorstop-Item-Hash     |
+| Safety Goals            | `safety/sg/*.md`                        | Git                          |
+| Plaene (Word)           | `docs/plaene/*.docx`                    | Git + Dokument-Versionsblock |
+| Safety-Doku (Word)      | `docs/safety/*.docx`                    | Git                          |
+| Manuals (Word)          | `docs/manuals/*.docx`                   | Git                          |
+| Reviews + NCs           | `docs/reviews/`, `docs/non-conformities/` | Git                       |
+| MISRA-Records           | `misra/records/*.docx`                  | Git                          |
+| CI-Konfiguration        | `.gitea/workflows/*.yml`                | Git                          |
+| Build-Definition        | `Makefile`, `Doxyfile`                  | Git                          |
+| Tools                   | `tools/*.py`                            | Git                          |
+
+## 3. Repository-Struktur
+
+- **Remote:** https://gitea.slohmaier.com/slohmaier/demo-epb
+- **Branch `main`:** stabil, immer freigegebener Stand
+- **Branch `develop`:** aktueller Entwicklungsstand
+- **Feature-Branches:** `feature/SWE-XXX-...`
+- **Bugfix-Branches:** `bugfix/<issue>-...`
+- **Release-Branches:** `release/vX.Y` (nur bei Real-Projekt; Demo: direkt von main)
+
+## 4. Baselines
+
+Eine Baseline ist ein eingefrorener, freigegebener Stand. Baselines werden durch
+Git-Tags gesetzt.
+
+| Baseline-Typ              | Tag-Schema       | Wann                                  |
+|---------------------------|-------------------|----------------------------------------|
+| Requirements Baseline     | `req-vX.Y`        | Nach Anforderungs-Freigabe            |
+| Architecture Baseline     | `arch-vX.Y`       | Nach Architektur-Review               |
+| Release Baseline          | `vX.Y.Z`          | Bei produktiver Freigabe              |
+| Internal Snapshot         | `snap-YYYY-MM-DD` | Bei wichtigen Zwischenstaenden        |
+
+Jeder Tag triggert (bei `vX.Y.Z`) den Release-Workflow, der ein Bundle erzeugt.
+
+## 5. Versions-Schema
+
+| Artefakt              | Schema                                  |
+|-----------------------|------------------------------------------|
+| Software-Release       | Semantic Versioning `MAJOR.MINOR.PATCH` |
+| Anforderungen          | Doorstop-Level `X.Y` + Datum            |
+| Architektur            | Doorstop-Level `X.Y` + Datum            |
+| Word-Dokumente         | `MAJOR.MINOR` im Dokument-Header        |
+
+## 6. Change Control
+
+Aenderungen an Configuration Items erfolgen ueber:
+
+1. **Trivial-Aenderung** (Tippfehler, Kommentare): direkt im Branch, PR mit 1 Approval
+2. **Normal-Aenderung** (Feature, Bugfix): Feature-Branch, PR mit Reviews je nach ASIL
+3. **Major-Aenderung** (Architektur, Sicherheits-Konzept): Change Request + Reviewer-Quorum
+
+| Asil    | Reviewer-Mindestanzahl              |
+|---------|--------------------------------------|
+| QM      | 1                                    |
+| ASIL-A/B| 1                                    |
+| ASIL-C  | 2 (mind. 1 Technical Reviewer)       |
+| ASIL-D  | 2 Technical Reviewer + Safety Manager|
+
+Reviews werden in `docs/reviews/REV-XXX.docx` dokumentiert.
+
+## 7. Release-Prozess
+
+```
+1. Alle PRs in main gemerged
+2. Branch protected, alle CI-Checks gruen
+3. Release-Notes-Entwurf im PR vorbereitet
+4. Tag setzen: git tag -a vX.Y.Z -m "..."
+5. Push: git push origin vX.Y.Z
+6. Release-Workflow laeuft (.gitea/workflows/release.yml):
+   - Build + Tests + Coverage
+   - Traceability + Diagrams + API-Doc
+   - Word-Dokumente bundlen
+   - Source + Artefakt-Archive packen
+   - Gitea-Release anlegen
+7. Release manuell pruefen (Bundle herunterladen, sichten)
+8. Release als "stable" markieren
+```
+
+## 8. Aufbewahrung
+
+| Artefakt                 | Aufbewahrungsdauer                    |
+|--------------------------|----------------------------------------|
+| Git-Repository           | Unbegrenzt (Gitea + Backup)            |
+| Release-Bundles          | 10 Jahre nach Produkt-EOL              |
+| Reviews + NCs            | 10 Jahre nach Produkt-EOL              |
+| MISRA-Records            | 10 Jahre nach Produkt-EOL              |
+| CI-Artefakte (kurzlebig) | 90 Tage (in Gitea-Artifacts)           |
+
+ISO 26262 fordert 10 Jahre nach End-of-Production-Life (Annahme).
+
+## 9. Verifikation
+
+Alle Pull Requests laufen durch:
+- `doorstop`-aequivalenter Traceability-Check (`tools/traceability.py check`)
+- Build + Unit-Tests
+- Static Analysis + MISRA-Check
+- Coverage-Messung
+
+Erst nach Approval und CI-Gruen kann der Merge nach `main` erfolgen.
+
+## 10. Verantwortlichkeiten
+
+| Rolle           | Aufgabe                                          |
+|------------------|--------------------------------------------------|
+| Configuration Mgr| Pflege dieses CM-Plans, Repo-Hygiene, Baselines |
+| Entwickler       | Korrekte Branch-Strategie, sinnvolle Commit-Msg |
+| Reviewer         | Pruefung vor Merge, Audit-Trail                  |
+| Project Owner    | Release-Freigabe                                  |
+
+## 11. Aenderungshistorie
+
+| Version | Datum       | Aenderung           | Autor       |
+|---------|-------------|---------------------|-------------|
+| 1.0     | 2026-05-12  | Erstfreigabe        | S. Lohmaier |