The Debian 13 readiness work has crossed another important boundary.

MB684 proved that Mediabot could exercise its fresh-install configuration path on Debian 13.

MB685 went further and proved that a fresh MariaDB database could be created with the real installation tooling and then validated against Mediabot’s expected schema.

MB686 now proves the other side of the lifecycle: upgrading an existing stable installation.

Instead of constructing an artificial database fixture, the Debian 13 CI gate starts from the real database schema shipped by the Git 3.3 stable tag.

The test deliberately proves that the current repository first sees that stable database as outdated, applies the released upgrade path through the real migration helper, and finally verifies that the resulting database matches the current expected schema.

real Git 3.3 database baseline
        ↓
strict schema drift detected
        ↓
released migrations verified
        ↓
post-3.3 migrations discovered
        ↓
real db_migrate.sh executed
        ↓
strict post-migration validation
        ↓
clean current database

🧭 A real upgrade baseline, not a CI-only approximation

The stable baseline is derived from the real Git 3.3 tag.

This matters because an upgrade test should prove compatibility with something that was actually released, not with a fixture silently maintained beside the test.

Before migration, the CI contract requires the current strict schema checker to detect drift. If there is no drift, the test fails: that would mean the scenario is no longer proving a genuine stable-to-current upgrade.

After migration, the same strict validation must be clean.

📜 Released migrations are treated as immutable history

MB686 does not merely check that migration files happen to exist.

Released migrations used by the upgrade path are checked for:

• presence;
• expected ordering;
• SHA-256 immutability.

The post-3.3 migration inventory is discovered from Git history and ordered according to the documented migration contract.

This protects an important property of database evolution: a migration that has already been released must not silently change underneath installations that may already have applied it.

🔐 Database credentials stay off the command line

The real install/db_migrate.sh path is exercised by CI.

To make that possible without leaking the database password through process arguments, MB686 adds support for a private MySQL --defaults-extra-file.

The credential file is required to be private. A deliberately insecure option file must be rejected.

This means the following output seen during the test is intentional:

ERROR: --defaults-extra-file must not be readable/writable/executable by group or others

That is a negative security test succeeding, not a migration failure.

The historical interactive password mode remains available, preserving the existing standalone workflow.

🧪 Validation

MB686 passed every validation layer:

Targeted : 556 / 556
Fast     : 5992 / 5992
Full     : 15561 / 15561

The full suite was rerun explicitly as the normal mediabot runtime/development user.

Final repository checks were also clean:

git diff --check : PASS
working tree     : clean
HEAD             : synchronized with origin/master

The resulting commit is:

4932613 🪄 Make Debian 13 Prove the Stable Upgrade Path

Version:

3.4dev-20260822_093627

🏰 What Debian 13 CI can now prove

The readiness chain now covers substantially more of the installation lifecycle:

fresh OS/configuration     ✅
fresh database             ✅
stable database upgrade    ✅
strict post-upgrade schema ✅

MB686 does not modify the Mediabot runtime bot code and does not change the database schema definition itself.

No runtime restart was required for this round.

⚠️ CI is still not the final Debian 13 acceptance test

The project deliberately keeps one boundary outside CI.

Before the future Mediabot 3.5 stable release receives final acceptance, a dedicated Debian 13 machine still needs to exercise the complete end-to-end lifecycle, including:

fresh Debian 13 machine
        ↓
public clone
        ↓
system prerequisites
        ↓
configure / CPAN
        ↓
MariaDB / database install
        ↓
systemd installation
        ↓
first startup
        ↓
logs
        ↓
IRC connection
        ↓
runtime smoke commands
        ↓
Doctor / schema / security checks

That manual validation remains intentionally separate from the CI contracts.

The next readiness work will therefore focus on the remaining operating-system/runtime boundaries rather than pretending that database CI alone proves a complete production installation.

A good migration spell is not one that merely finishes. It is one that can prove where it started, exactly what it changed, and that the database emerged on the other side intact. 🧙‍♂️