fifteen additive steps, then one deliberate break

Every roadmap wants to ship the interesting thing first. Ours could not, because the interesting thing was a cryptographic upgrade that invalidates every existing message shape at once: new key material, a new handshake, new frame variants. Landing it early would have meant shipping a break with nothing underneath it — no server-side stores to hold the new material, no credential types to say what kind of identity a peer is claiming, no replay defence to make the new flow safe to retry.

The tension is that each of those pieces is unglamorous, and none of them changes a security property on its own. A sequence of fifteen steps in which the first eight are scaffolding looks, from outside, like a project avoiding its own hard problem.

The decision was to split the release into two phases and be explicit about the boundary. The first phase is additive by construction: every step only adds message variants, stores, configuration and backup encoding, and every step must leave the old flows working unchanged. That gives a run of releases that can ship independently and roll back one at a time. The second phase forks from the last additive version and is allowed to break, once, in a single place where the break is the point.

Each step is one change set behind one test gate, so a step that fails does not ship, rather than a milestone that slips. The cost is that the security property arrives last and the schedule looks padded until you read what the padding is for. What it proves is that the plan is a compatibility strategy, not a feature list.