No back-compatibility layers while the app is unreleased

✓solved

Problem

Deciding whether to keep compatibility layers or adapters for old shapes and links in an unreleased app.

Approach

Rejected the staged migration and the URL-translation layer; the clean form with the breakage priced held.

Outcome

✓ solved

Conditions

The app is unreleased and in dev phase, so old links and file shapes carry no users.

Evidence

Owner's stated rule: "we are in dev phase" (no commit named in the record)

Implication

When a clean form and a compatible form both exist, propose the clean one and price the breakage honestly.

Topics

migrations

Builds on

The page was keyed by who read it, not by where it sits in the book

Rejected the staged migration and the URL-translation layer outright: "it is not like the app is 5 years old that we need to keep legacy code, we are in dev phase". Applies to already-emitted ?book=&page= links, to adapters between old and new authored file shapes, and by extension to any compatibility shim proposed before release.

Implications: when a change has a clean form and a compatible form, propose the clean one and price the breakage honestly, rather than offering the staged path as the safe default. See 0003-page-keyed-by-reader-not-book.