43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
|
---
|
||
|
|
name: core-guardrails
|
||
|
|
description: Verbindliche Guardrails fuer Architektur-, Refactor-, Zentralisierungs-, Standardisierungs- und Implementierungsaufgaben in diesem Starterkit. Verwenden, wenn Code geaendert, neu strukturiert oder gegen bestehende Layer-/UI-/Security-Standards geprueft werden soll.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Core Guardrails
|
||
|
|
|
||
|
|
## Ziel
|
||
|
|
|
||
|
|
Durchgaengig dieselben technischen Grenzen durchsetzen, damit Core robust, wartbar und vorhersagbar bleibt.
|
||
|
|
|
||
|
|
## Verbindliche Regeln
|
||
|
|
|
||
|
|
1. MUST Layering einhalten (`pages` -> `Service` -> `Repository`, Templates nur Rendering).
|
||
|
|
2. MUST Request/Input/Validation-Contract einhalten (`requestInput()`, `FormErrors`, API-Validation ueber `ApiResponse::validationFromFormErrors(...)`, kein `ApiResponse::readJsonBody(...)` in `pages/api/v1/**`, keine direkten Superglobals in `pages/**`).
|
||
|
|
3. MUST AuthZ/RBAC serverseitig durchsetzen und im UI nur ueber `$viewAuth` steuern.
|
||
|
|
4. MUST Security-Guards einhalten (CSRF auf POST-Endpunkten, keine unredacted PII/Secrets in Logs/Audit-Meta, SQL nur vorbereitet ueber Repository).
|
||
|
|
5. MUST UI-Standards und Data-Contracts fuer Listen/Detailseiten nutzen (Wrapper, Partials, globaler Confirm-Dialog statt `window.confirm`, inklusive globaler Grid-Standards fuer rowInteraction/pageSize).
|
||
|
|
6. MUST Frontend-Hardcuts einhalten (keine inline ESM-Module in Templates/Pages, JS-`src` mit `assetVersion(...)`, zentrale Telemetrie fuer relevante Frontend-Warnings/Fetch-Fehler).
|
||
|
|
7. MUST Quality-Gates ausfuehren und Ergebnis transparent berichten.
|
||
|
|
8. MUST bei Konflikten den regelkonformen Weg waehlen oder den Konflikt als Blocker markieren.
|
||
|
|
9. MUST NOT Extension-Architektur erfinden; dieses Thema ist aktuell Out of Scope.
|
||
|
|
|
||
|
|
## Vorgehen je Aufgabe
|
||
|
|
|
||
|
|
1. Scope bestimmen (`core`, `ui`, `api`, `mixed`).
|
||
|
|
2. Vorhandene Contracts zuerst suchen, dann wiederverwenden.
|
||
|
|
3. Aenderung minimal halten, keine Seiteneffekte ohne Grund.
|
||
|
|
4. Nach Aenderung die relevanten Gates ausfuehren.
|
||
|
|
5. Rest-Risiken explizit benennen.
|
||
|
|
|
||
|
|
## Out of Scope
|
||
|
|
|
||
|
|
- Extension-Mechanik (Ablageorte, Hooks, Lifecycle) wird hier nicht standardisiert.
|
||
|
|
- Fuer Extensions nur den Status "nicht definiert" dokumentieren, keine impliziten Regeln erfinden.
|
||
|
|
|
||
|
|
## Referenzen
|
||
|
|
|
||
|
|
- Core-Boundaries: `references/boundaries-core.md`
|
||
|
|
- UI-Boundaries: `references/boundaries-ui.md`
|
||
|
|
- Quality-Gates: `references/quality-gates.md`
|
||
|
|
- Source-Map zu Projekt-Doku: `references/source-map.md`
|