site-profile-universal.json is what the released Windows installer is built from, so a bundled plugin missing from it is invisible to the install wizard. Worse, `flask plugin prune-schema` drops the tables owned by plugins the site did not install (ADR-014), so backuprevisions would have been dropped at provisioning on every new site - a table that shipped in the build, removed because the profile never named it. The same omission explains why `flask plugin upgrade-all` skipped backups: upgrade_all_plugins iterates the REGISTRY, not the plugins directory, on purpose - a plugin folder merely sitting on disk unadopted must not have its DDL run as a side effect of a deploy. instance/ is gitignored, so any machine that never ran `flask plugin install backups` has it on disk but unadopted. Nothing in the suite caught the stale profile, so this adds two guards: every bundled plugin carrying a manifest must appear in the universal profile, and the profile must not name a plugin that does not exist. Verified the first one fails with the profile as it was.
4.1 KiB
4.1 KiB