# 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.