42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
# 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.
|