Mission code changes are clean-sheet by default. When Mission renames a concept, changes a schema, replaces an interface, or removes an old domain model, the old shape must be removed in the same change. Callers must move to the new canonical shape instead of being allowed to keep using old names, old payloads, or old behavior.

Aliases, backward-compatibility paths, compatibility method names, fallback parsers, tolerant readers, hidden normalization layers, and transitional duplicate exports are forbidden by default. They create opaque future errors by allowing two names or shapes to appear valid after the domain has chosen one. This rule applies to all Mission code: Entity schemas, Entity classes, Entity contracts, daemon protocols, runtime data, state store modules, Open Mission surfaces, adapters, tests, documentation, and generated artifacts.

Conservative coding is not allowed when it means preserving old behavior, silently accepting obsolete shapes, or hedging between two domain models. Defensive coding is allowed only to catch errors that are unrelated to backward compatibility, fallbacks, aliases, or obsolete inputs. Valid defensive coding includes clear validation failures, explicit invariant checks, permission checks, filesystem safety checks, network error handling, and typed error reporting. It must fail loudly instead of repairing, guessing, or accepting deprecated forms.

Backward compatibility may exist only when a human maintainer explicitly asks for it for a bounded case. That exception must be recorded in an ADR or migration decision with its scope, removal criteria, validation requirements, and owner. In the absence of that explicit request and recorded decision, clean-sheet replacement is mandatory.