fs
545bcc789b
Most German docs were written with `ue`/`ae`/`oe`/`ss` ASCII fallbacks (`fuer`, `aenderung`, `koennen`, `gemaess`) — relic from older toolchain constraints. Replaced 237 occurrences across 38 .md files with proper umlauts and ß so the docs read naturally. Substitutions are constrained to plain prose: fenced code blocks (```...```), inline code spans (`...`), markdown link targets `[..](..)`, and HTML comments are preserved verbatim. Path references like `docs/howto-erste-aenderung.md` keep their original (umlaut-replaced) filenames — only the surrounding prose is normalised. Tool: bin/fix-md-umlauts.py (idempotent — no-op on already-clean files). Re-runnable if ASCII fallbacks creep back in via copy-paste. Doc-link-check + doc-drift-check stay green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
---
|
|
name: core-guardrails
|
|
description: Verbindliche Guardrails für Architektur-, Refactor-, Zentralisierungs-, Standardisierungs- und Implementierungsaufgaben in diesem Starterkit. Verwenden, wenn Code geändert, neu strukturiert oder gegen bestehende Layer-/UI-/Security-Standards geprüft 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 über `ApiResponse::validationFromFormErrors(...)`, kein `ApiResponse::readJsonBody(...)` in `pages/api/v1/**`, keine direkten Superglobals in `pages/**`).
|
|
3. MUST AuthZ/RBAC serverseitig durchsetzen und im UI nur über `$viewAuth` steuern.
|
|
4. MUST Security-Guards einhalten (CSRF auf POST-Endpunkten, keine unredacted PII/Secrets in Logs/Audit-Meta, SQL nur vorbereitet über Repository).
|
|
5. MUST UI-Standards und Data-Contracts für Listen/Detailseiten nutzen (Wrapper, Partials, globaler Confirm-Dialog statt `window.confirm`, inklusive globaler Grid-Standards für rowInteraction/pageSize).
|
|
6. MUST Frontend-Hardcuts einhalten (keine inline ESM-Module in Templates/Pages, JS-`src` mit `assetVersion(...)`, zentrale Telemetrie für relevante Frontend-Warnings/Fetch-Fehler).
|
|
7. MUST Quality-Gates ausführen und Ergebnis transparent berichten.
|
|
8. MUST bei Konflikten den regelkonformen Weg wählen 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. Änderung minimal halten, keine Seiteneffekte ohne Grund.
|
|
4. Nach Änderung die relevanten Gates ausführen.
|
|
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`
|