Files

fs 2e73cb98b4 feat(console): add db:migrate CLI for idempotent core schema updates

Existing systems used to have no automatic mechanism for the
db/updates/*.sql idempotent updates after `git pull` — devs had to
remember which files were already applied and run new ones manually
with `mariadb < ...`. Mirror module:migrate to fix this:

- New `bin/console db:migrate` walks db/updates/*.sql in alphabetical
  order, skipping anything already recorded in the new core_migrations
  tracking table. Each file runs in its own transaction; failure
  rolls back so the file is retried on the next run.
- New `db:migrate --status` lists applied vs. pending files without
  running anything. Useful for ops debugging "schema seems stale"
  symptoms.
- module:sync now runs db:migrate as its first step, so the standard
  post-pull command stays a single invocation. README's 3-step setup
  is unchanged — module:sync now also covers core schema updates.

CoreMigrationRepository owns its own mysqli connection (using the
same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()`
instead of going through DB::query's prepared statement path —
MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK)
in the prepared protocol, which the existing 18 db/updates files
trip on. ModuleMigrationRepository is left untouched (no module
migration uses such DDL today and changing the vendor pattern is
out of scope).

End-to-end verified: against an existing DB the first run applies
all 19 idempotent files as no-ops and records them, second run
reports "all updates already applied". Against a freshly init'd
DB the same thing happens — no double work, no surprises. All
encrypted seed secrets keep decrypting because APP_CRYPTO_KEY
is unchanged.

Tests: tests/Console/CoreCommandsTest covers success/failure/status
output shapes against a FakeModuleRunner (mirror of the existing
ModuleCommandsTest pattern). 5 stale baseline entries in
phpstan-baseline removed (covered by the new @api annotation on
the test fixture class).

Docs: CLAUDE.md and docs/reference-cli-commands.md document the
new command + --status flag; docs/howto-fehlerbehebung.md gains
a "schema seems stale after git pull" section pointing at
db:migrate --status.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-29 08:59:57 +02:00

App

fix(routing): prevent login redirect loops on alias targets

2026-04-26 10:20:28 +02:00

Architecture

chore(setup): track config.php directly, slim README to setup checklist

2026-04-29 08:37:45 +02:00

Console

feat(console): add db:migrate CLI for idempotent core schema updates

2026-04-29 08:59:57 +02:00

Domain/Taxonomy

refactor(audit): extract audit domain into self-contained module

2026-03-25 21:12:49 +01:00

Http

fix(routing): prevent login redirect loops on alias targets

2026-04-26 10:20:28 +02:00

I18n

feat: module-owned i18n with merge-at-boot translation loading

2026-03-19 22:08:34 +01:00

Repository

refactor(tests): remove redundant tests and fix assertion style

2026-03-25 18:46:49 +01:00

Service

fix(user-lifecycle): track last-run state in core, not in audit log

2026-04-26 21:07:57 +02:00

Support

refactor(action-context): remove unused fragment aggregator + building block

2026-04-26 17:34:53 +02:00

Unit

fix(flash): make flash messages one-shot per request

2026-04-15 18:45:45 +02:00

bootstrap.php

refactor: rename lib/ to core/ for clearer core-module separation

2026-04-13 23:20:42 +02:00

README.md

Clarify test suite taxonomy

2026-03-19 20:22:10 +01:00

README.md

Tests

Ziel

Die Tests sind nach Schutzwirkung organisiert, nicht nur nach technischer Ebene. Wichtige Architektur- und Security-Invarianten sollen schnell gezielt laufen koennen, ohne dass jede Aenderung immer die komplette Suite im Kopf behalten muss.

PHPUnit-Suiten

CoreCore: gesamte Test-Suite.
Unit: kleine verhaltensorientierte Unit-Tests ohne breites Orchestrierungs-Setup.
Service: Business-Logik, Policies, Gateways und Orchestrierungs-Tests unter tests/Service/.
Repository: Query- und Repository-Tests unter tests/Repository/.
Domain: fachliche Taxonomie- und Domain-Tests unter tests/Domain/.
Architecture: alle Architektur-Contracts unter tests/Architecture/.
ArchitectureCore: Core-Boundaries, Module-/Repository-Contracts, Taxonomie- und Sync-Contracts.
ArchitectureSecurity: CSRF, PRG, File-Storage, Crypto, Logging sowie AuthZ-nahe Contracts.
ArchitectureUI: UI-Contracts fuer Listen, Detailseiten, Runtime-Komponenten und A11y.
ArchitectureModules: modulbezogene Struktur- und Isolations-Contracts.
ArchitectureMeta: Agent-/Skill-/Meta-Contracts fuer das Repository-Setup.

Regeln fuer neue Architecture-Tests

Nur stabile Invarianten testen, keine einmaligen Migrationsdetails.
Guards oder Risiken explizit abdecken, zum Beispiel GR-CORE-*, GR-SEC-*, GR-TEST-*.
Keine Duplikate neben bereits breiten Contracts anlegen.
String-Assertions nur verwenden, wenn kein robusterer Contract moeglich ist.
Monolithische Sammeltests vermeiden; lieber kleine thematische Contracts.

Delete vs. Refactor vs. Keep

keep: testet einen echten plattformweiten Contract oder Security-Guard.
refactor: Schutz ist wichtig, aber der Test ist zu datei-, markup- oder implementation-detailnah.
delete: dupliziert bestehende Schutzwirkung oder prueft nur historische Altlasten.

Regeln fuer neue Service-Tests

Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
Keine eigenen Tests fuer reine find/list/get/set-Delegation ohne zusaetzliche Regel.
Thin Wrapper auf gemeinsame Primitive zentral testen, nicht pro Gateway erneut.
Mockability-, Reflection- und Interface-Existenz-Tests ohne Risiko-Schutz vermeiden.
Kleine Normalisierungs-Matrizen mit DataProvidern oder zusammengezogenen Contract-Dateien verdichten.

Typische Low-Value-Muster

Gateway-Test prueft nur encrypt/decrypt erneut, obwohl das Basisverhalten schon zentral abgesichert ist.
Test bestaetigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
Test prueft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.

Naechste Audit-Kandidaten

methodenweiser Low-value-Pass in tests/Service/User/UserAccountServiceTest.php
methodenweiser Low-value-Pass in tests/Service/Org/DepartmentServiceTest.php
methodenweiser Low-value-Pass in tests/Service/Access/RoleServiceTest.php
verbleibende kleine Settings-Gateway-Tests auf weitere Verdichtung pruefen