fix broken doc links

docs/howto-erste-aenderung.md

@@ -1,6 +1,6 @@
 # Leitfaden für die erste Änderung
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 ## Ziel
 
@@ -37,7 +37,7 @@ Ein neuer Entwickler soll den ersten Change strukturiert und reproduzierbar umse
 2. Permission- und Tenant-Scope-Prüfungen beibehalten
 3. Optional Service/Repository ergänzen, Instanziierung über `app(...)`/Factory-Standards
 4. `docs/openapi.yaml` aktualisieren
-5. `docs/api.md` mit Beispiel aktualisieren
+5. `/docs/reference-api.md` mit Beispiel aktualisieren
 6. Bei neuen Berechtigungen: `PermissionService` + `init.sql` synchron halten, für Bestandsumgebungen idempotentes SQL-Update in `db/updates/*.sql` bereitstellen
 
 ### Done-Kriterien

docs/howto-lokale-entwicklung.md

@@ -1,6 +1,6 @@
 # Lokale Entwicklung
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 ## Ziel
 
@@ -55,8 +55,8 @@ Bei JS-Änderungen zusätzlich Browser-Smoke mit DevTools-Console (keine JS-Erro
 ## API-spezifisch
 
 - `docs/openapi.yaml` aktualisieren
-- bei Bedarf `docs/api.md` ergänzen
-- bei Security-Änderungen `docs/sicherheitsmodell.md` aktualisieren
+- bei Bedarf `/docs/reference-api.md` ergänzen
+- bei Security-Änderungen `/docs/explanation-sicherheitsmodell.md` aktualisieren
 
 ## Vertiefung
 

docs/index.md

@@ -1,6 +1,6 @@
 # Dokumentation
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 Diese Dokumentation ist nach dem Diataxis-Modell in vier Quadranten gegliedert: Tutorials zum Lernen, How-to Guides zum Nachschlagen von Aufgaben, Explanation zum Verstehen und Reference zum Nachschlagen von Fakten.
 
@@ -93,6 +93,8 @@ Diese Dokumentation ist nach dem Diataxis-Modell in vier Quadranten gegliedert:
   - Definition of Done vor Merge.
 - `/docs/reference-codex-prompts.md`
   - Standard-Prompts fuer Skill-basierte Planung und Implementierung.
+- `/docs/reference-extension-readiness.md`
+  - Verbindliche Vorbedingungen fuer spaetere Module ohne Hook-/Lifecycle-Festlegung.
 - `/docs/reference-agents-overview.md`
   - Einstieg in das Rollenmodell und die Artefakte.
 - `/docs/reference-agents-roles.md`

docs/reference-agents-overview.md

@@ -1,6 +1,6 @@
 # Agent Workflow Overview
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 This project uses a multi-role workflow for issue and feature delivery.
 
@@ -24,6 +24,6 @@ Source of truth:
 - quality gates: `agent-system/checks/quality-gates.json`
 
 Entry points:
-- roles: `docs/agents/roles.md`
-- workflow: `docs/agents/flow.md`
+- roles: `/docs/reference-agents-roles.md`
+- workflow: `/docs/reference-agents-flow.md`
 - schemas and prompts: `agent-system/`

docs/reference-codex-prompts.md

@@ -1,6 +1,6 @@
 # Codex Prompt-Standards
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 ## Ziel
 
@@ -63,3 +63,4 @@ Regel:
 1. Keine impliziten Extension-Standards erfinden.
 2. Erweiterungen explizit als Out-of-Scope kennzeichnen.
 3. Nur dokumentieren, was bereits verbindlich im Repo festgelegt ist.
+4. Vor Implementierungsstart die Vorbedingungen aus `/docs/reference-extension-readiness.md` prüfen.

docs/reference-extension-readiness.md

@@ -0,0 +1,41 @@
+# Extension-Readiness (ohne Architektur-Festlegung)
+
+Letzte Aktualisierung: 2026-03-09
+
+## Ziel
+
+Verbindliche Vorbedingungen fuer spaetere eigenstaendige Module festhalten, ohne jetzt eine konkrete Extension-Mechanik (Hooks/Lifecycle/Loader) zu standardisieren.
+
+## Readiness-Checkliste vor neuem Modul
+
+1. **Modulgrenzen klarziehen**
+   - Betroffene Schichten benoennen (`pages -> Service -> Repository`).
+   - Keine SQL-/Business-Logik in Templates oder `pages/*.phtml`.
+2. **Contracts definieren**
+   - Oeffentliche API-/UI-Contracts dokumentieren (Inputs, Outputs, Fehlerfaelle).
+   - Bei API-Aenderungen `docs/openapi.yaml` im selben Merge pflegen.
+3. **Security + Scope absichern**
+   - AuthZ/RBAC serverseitig pruefen.
+   - Tenant-Scope serverseitig pruefen.
+   - POST-Mutationen mit CSRF absichern.
+4. **Testbarkeit und Gates**
+   - Architektur- und Domain-Tests fuer neue Logik ergaenzen.
+   - Relevante Quality Gates (`QG-*`) im Merge reporten.
+5. **Daten- und Betriebsfaehigkeit**
+   - Schema-/Datenaenderungen fuer Bestandsinstallationen idempotent in `db/updates/*.sql`.
+   - Logs/Audit ohne unredacted PII/Secrets.
+
+## Bewusst Out of Scope in diesem Stand
+
+- Kein standardisierter Extension-Loader.
+- Kein Hook-/Plugin-Lifecycle.
+- Keine verbindlichen Modul-Ablageorte ausserhalb bestehender Schichten.
+
+## Entscheidungslog fuer spaetere Standardisierung
+
+Wenn die Extension-Mechanik spaeter konkretisiert wird, muss die Entscheidung mindestens diese Punkte mitliefern:
+
+1. Aktivierung/Deaktivierung und Reihenfolge von Modulen.
+2. Versionierung und Migrationsstrategie pro Modul.
+3. Sicherheits- und Tenant-Isolation pro Erweiterung.
+4. Test- und Rollback-Strategie fuer Modul-Deployments.

docs/reference-konventionen.md

@@ -1,6 +1,6 @@
 # Konventionen (kurz und verbindlich)
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
 ## 1) Code
 
@@ -44,7 +44,7 @@ Letzte Aktualisierung: 2026-03-06
 
 - Templates nur für Rendering.
 - UI-Texte über `t('...')`.
-- Strukturregeln in `docs/frontend-css.md` und `docs/frontend-javascript.md`.
+- Strukturregeln in `/docs/reference-frontend-css.md` und `/docs/reference-frontend-javascript.md`.
 
 ## 6) Mindestchecks vor Merge
 

docs/reference-lib-standards.md

@@ -1,8 +1,8 @@
 # lib-Standards
 
-Letzte Aktualisierung: 2026-03-06
+Letzte Aktualisierung: 2026-03-09
 
-Praktische Regeln nur für `lib/**`. Ergänzt `docs/architektur.md`.
+Praktische Regeln nur für `lib/**`. Ergänzt `/docs/explanation-architektur.md`.
 
 ## 1) Repository-Regeln