Files
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

55 lines
2.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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`