Files

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.9 KiB

Raw Blame History

RBAC Permission Playbook

Letzte Aktualisierung: 2026-03-06

Ziel: Neue Rechte konsistent und ohne Legacy-Pfade ergänzen.

Entscheidungshilfe

Nur UI an bestehende Ability hängen: 3 Schritte.
Neue Ability auf bestehende Permission: 4 Schritte.
Ganz neue Permission (inkl. DB): 7 Schritte.

Fall A: Ganz neue Permission

Permission-Key in PermissionService ergänzen. Datei: core/Service/Access/PermissionService.php
DB-Update für Bestandsinstanzen anlegen (idempotent). Datei: db/updates/YYYY-MM-DD-*.sql
db/init/init.sql für Neuinstallationen synchron ergänzen.
Ability in passender Policy ergänzen: ABILITY_*, supports(), Mapping in authorize().
Action/API auf Ability umstellen: Web: Guard::requireAbility(...) oder AuthorizationService. API: ApiResponse::requireAbility(...).
Falls UI betroffen: UiCapabilityMap ergänzen und in Action nach $viewAuth auflösen.
Tests + Doku aktualisieren.

Beispiel (Core): system_audit.view + system_audit.purge mit Abilities ops.admin.system_audit.view und ops.admin.system_audit.purge.

Fall B: Neue Ability auf bestehende Permission

Ability in passender Policy ergänzen und auf vorhandenen Permission-Key mappen.
Action/API auf neue Ability ziehen.
Optional UI-Mapping in UiCapabilityMap + $viewAuth.
Tests/Doku nachziehen.

Fall C: Nur UI-Freigabe erweitern (ohne neue Permission)

Capability-Key in UiCapabilityMap ergänzen.
In Action mit UiAccessService::pageCapabilities(...) oder layoutCapabilities() auflösen.
Template nur über $viewAuth['page'] bzw. $viewAuth['layout'] steuern.

Fall D: API-only Endpoint

Ability festlegen (Policy/OperationsPolicy).
Endpoint mit ApiResponse::requireAbility(...) schützen.
OpenAPI aktualisieren.
API-Tests ergänzen.

Fall E: Scope-sensitive Ability (Ressourcenbezug)

Immer Kontext übergeben, z. B.: actor_user_id, target_user_id, target_tenant_id, input.
Wenn Capabilities benötigt werden: AuthorizationDecision::attribute('capabilities', []) nutzen.
Für reine Bool-Checks AuthorizationService::allow(...) verwenden.

Verbindliche Regeln

Keine Permission-Checks in Templates (can(...) verboten).
Keine alten Wrapper (Guard::requirePermission*, ApiResponse::requirePermission).
UI nur über $viewAuth.
Policy-/Ability-Namen sind der technische Vertrag, nicht der Permission-Key im Template.

Minimal-Checkliste vor Merge

rg -n "(?<!::)\\bcan\\(" templates pages -g '*.phtml' -P
rg -n "Guard::requirePermission\\(|Guard::requirePermissionOrForbidden\\(|ApiResponse::requirePermission\\(" pages lib tests web templates -g '*.php'
docker compose exec php vendor/bin/phpunit
docker compose exec php vendor/bin/phpstan analyse -c phpstan.neon --no-progress

Erwartung:

Die beiden rg-Checks liefern 0 Treffer.
phpunit und phpstan sind grün.

2.9 KiB Raw Blame History