fa/breadcrumb-the-shire
1
0
Fork 1
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
545bcc789bc4797ec69d51d1d8f5a6b4fbcb647f
breadcrumb-the-shire/.agents/skills/core-guardrails/SKILL.md
fs 545bcc789b docs: replace ASCII umlaut fallbacks with proper äöüß across all .md 
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>
2026-04-29 09:57:22 +02:00

2.3 KiB
Raw Blame History

name, description
name description
core-guardrails 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
Reference in New Issue View Git Blame Copy Permalink