fix broken doc links

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.