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>
config/config.php was gitignored and devs had to copy it from
config/config.php.example on every fresh clone. Since the bootstrap
config reads everything from .env via $envString() / $envInt() /
$envBool() defaults, there is nothing developer-specific in the file —
the cp step was dead ceremony.
- Remove config/config.php from .gitignore and track it directly
- Delete config/config.php.example
- Drop the example-existence + per-doc reference checks from
bin/docs-drift-check.sh; add a legacy-pattern check that flags
any new mention of the removed example file
- Update ConfigContractsTest to require config.php and forbid the
example
- Clean stale references in CLAUDE.md, README.md, six docs files,
and the core-guardrails skill
Same commit slims README down from 294 to 47 lines: one setup
checklist (now 3 commands instead of 4), the seeded login table,
the three quality-gate commands, and pointers to CLAUDE.md and
docs/index.md for everything else.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
