backward-compatibility-policy

Internal code in an integrated monorepo like KHI requires no backward compatibility. Delete old functions, update all call sites in the same change, and never retain deprecated wrappers, aliases, or defensive fallbacks for hypothetical legacy callers.

Backward compatibility matters only for data formats that persist across versions, such as KHI's exported .khi inspection dump files serialized with Protocol Buffers. Even then, raise the compatibility strategy explicitly with the user during planning before implementing migration logic.

No. Adding variadic parameters solely to keep existing zero-argument callers compiling is an anti-pattern. Make the new parameter explicit and required, then update all call sites across the repository in the same change.

No. Retaining a deprecated function that delegates to the new implementation is an anti-pattern in a monorepo. Rename the function cleanly, delete the old one, and update every call site; version control preserves the history.

Update the interface directly and adjust all its implementations in the codebase. Do not create an InterfaceV2 or use runtime type assertions to conditionally call new methods, since all implementations live in the same monorepo.

First identify whether the change affects exported file structures or import/export serializers. Then propose the plan explicitly with an open question about whether previously exported .khi files must remain loadable, and wait for user approval before implementing any migration or fallback decoders.