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>
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
# 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`
|