The version says 0.2.0, and the migrations since 0.1.0 are one

[kisielewski]

The preparation commit for 0.2.0: the version, the copies of it in README.md, the six unreleased migrations squashed into version_0_2_0, and the runbook's dated readings refreshed.

The squash is an assembly, not a regeneration

The 0.2.0 range holds 23 migrationBuilder.Sql calls across three migrations and two renames. A model differ emits DDL from a comparison of two models: it produces no UPDATE at all, and it renders RenameTable and RenameColumn as a drop and a create. Regenerating version_0_2_0 the way 0.1.0 was collapsed would therefore have produced a schema-identical, data-destroying migration — an installation upgrading from 0.1.0 would keep template: permission keys that now match nothing, lose every row of PermissionTemplates, and find AnonymizeAfter and SourceAnonymizedAt empty.

So version_0_2_0 is the six migrations' own statements in their own order: Up is their Up bodies concatenated chronologically, Down their Down bodies in reverse. Nothing was rewritten, so nothing could be dropped in rewriting.

How that is checked

dotnet ef migrations script version_0_1_0 --context ApplicationDbContext, run before the assembly and after it — this is what a database standing at 0.1.0 actually receives:

statements, history stripped	95 before, 95 after, byte-identical
raw difference	five INSERT INTO "__EFMigrationsHistory" blocks with their COMMIT; START TRANSACTION; pairs, and the last row's MigrationId

A schema comparison cannot see this difference, which is why it is not the proof. It was run anyway: 2972 lines from an empty database either side, differing only in pg_dump's own \restrict session token, with no column reordering. Two history rows and one, as expected — LtiDbContext gained nothing because nothing in the range touched it.

20260920180000_version_0_2_0.Designer.cs's model compared line by line with ApplicationDbContextModelSnapshot.cs: 2776 lines each, zero differing lines. The snapshot itself is untouched.

RoleMigrationTests is what caught the squash

Three tests failed with The migration '20260912215309_printoutClaim' was not found. They are the only thing in the repository that checks a data migration — they migrate to a named earlier migration, seed an installation's rows, migrate forward and assert what the UPDATEs did — and a squash deletes the id they target.

Previous now names 20260907183332_version_0_1_0, the previous release's own migration. That is the state the class summary already said they start from ("an installation as 0.1.0 left it"), it is the real upgrade path, and it is the only id a squash leaves standing. The seeds touch only tables that exist at 0.1.0.

Sabotaged afterwards to prove they still bite: breaking the grant-linking UPDATE turns An_untouched_grant_is_linked_and_every_other_kind_is_left_alone red; breaking the key the manager UPDATE adds turns A_manager_grant_from_before_roles_is_linked red.

Gates

989 passed, 0 failed, 0 skipped, 3 m 9 s. Build clean under -warnaserror. No vulnerable package, transitive included. openapi.json identical to what the development container serves, sha256 793eb42a… — which is the value AlgoJudge-Docs/content-sources.json will need to pin. .env.example matches the compose substitutions both ways, and no .env exists in tree or index.

Two things this does not settle

Tagging the Server without the Client. DECISIONS_AND_OPEN_QUESTIONS.md of 2026-09-18 says Server and Client 0.2 are tagged together, because Ops defaults both images to the moving 0 and a 0.2 Server beside a 0.1.1 Client answers self-enrollment with 404. That was verified rather than assumed and remains true. Releasing the Server alone is a deliberate choice made with it in view; it belongs at the top of the release note, and the decision record needs amending to match.

Dependabot #121 raises dotnet-ef to 10.0.12, and the tool version is written into the new migration's ProductVersion annotation and its history row. Merging it between this commit and the tag means assembling and re-verifying the migration again. Before this branch, or after the tag.