tbh/breadcrumb-the-shire
1
0
Fork 0
forked from fa/breadcrumb-the-shire
Code Pull Requests Activity
Files
cc2cf3a2543b766972dbdca1668c74aa5fc7d8a7
breadcrumb-the-shire/docs/howto-erste-aenderung.md
fs 0e86925464 refactor: rename lib/ to core/ for clearer core-module separation 
Rename the top-level lib/ directory to core/ so the project root
immediately communicates which code is core platform and which lives
in modules/. PHP namespaces (MintyPHP\*) are unchanged — only the
Composer PSR-4 path mapping moves from lib/ to core/.

Module-internal lib/ directories (modules/*/lib/) are untouched.

Updated across the full stack:
- composer.json PSR-4 mapping
- bootstrap entry points (web/index.php, bin/*, tests/bootstrap.php)
- tooling configs (phpstan.neon, phpunit.xml, php-cs-fixer)
- 26 architecture contract tests
- enforcement-policy, guard-catalog, quality-gates
- all documentation (CLAUDE.md, README, 25 docs/, .agents/skills/)
- bin/qa-extended.sh search paths
- .claude/settings.local.json permission paths

Workflow: .agents/runs/CORE-LIB-RENAME-001/ (Analyst → Planner →
Executor → Code Review (4 findings fixed) → Security Review →
Acceptance Test → Finalizer)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-13 23:20:42 +02:00

2.2 KiB
Raw Blame History

Leitfaden für die erste Änderung

Letzte Aktualisierung: 2026-03-25

Ziel

Ein neuer Entwickler soll den ersten Change strukturiert und reproduzierbar umsetzen können.

Beispiel 1: Spalte in Admin-Liste ergänzen

Schrittfolge

  1. Data-Endpoint erweitern (z. B. pages/admin/users/data().php)
  2. Falls nötig: neue Repository-Methode ergänzen – je nach Typ:
    • Listenabfrage / Filterung / Paginierung → core/Repository/User/UserListQueryRepository.php
    • Einzelnes Objekt lesen → core/Repository/User/UserReadRepository.php
    • Schreiboperation → core/Repository/User/UserWriteRepository.php
  3. Grid-Spalte in pages/admin/<modul>/index(default).phtml ergänzen (z. B. pages/admin/users/index(default).phtml)
  4. i18n-Key für Spaltennamen setzen
  5. Service-Auflösung in Action-Dateien nur über app(Foo::class) nutzen (kein new ...Factory() in pages/**)
  6. In data().php: GET-only (gridRequireGetRequest()) und Filter/Paging über gridParseFiltersFromSchemaFile(...) normalisieren
  7. php -l + manueller UI-Test

Done-Kriterien

  • Kein SQL in View-Dateien
  • Neue Werte im Endpoint dokumentiert/benannt
  • Sortierung und Mapping im Grid konsistent
  • Bei neuen Filtern: Query-Param, Repository-Filter und Grid-State konsistent
  • Instanziierungsstandard eingehalten (app(...), keine Legacy-Helper)

Beispiel 2: API-Response erweitern

Schrittfolge

  1. Endpoint in pages/api/v1/... anpassen (z. B. pages/api/v1/me/index().php oder pages/api/v1/users/show($id).php)
  2. Permission- und Tenant-Scope-Prüfungen beibehalten
  3. Optional Service/Repository ergänzen, Instanziierung über app(...)/Factory-Standards
  4. docs/openapi.yaml aktualisieren
  5. /docs/reference-api.md mit Beispiel aktualisieren
  6. Bei neuen Berechtigungen: PermissionService + init.sql synchron halten, für Bestandsumgebungen idempotentes SQL-Update in db/updates/*.sql bereitstellen

Done-Kriterien

  • Keine numerischen IDs exponieren, wenn UUID bereits Contract ist
  • Fehlercodes konsistent (ApiResponse::error(...))
  • Kein Body-Leak in Logs/Audit
  • OpenAPI und tatsächlich gelieferte Response-Felder stimmen 1:1

Finaler Check

Vor PR/Merge diese Liste gegenprüfen:

  • /docs/reference-entwickler-checkliste.md
View Git Blame Copy Permalink