breadcrumb-the-shire/docs/reference-extension-readiness.md

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.