Define conformance policy for convention changes #126
Description
Problem
When the project establishes a new convention or policy, there is no stated principle for how existing artifacts should be treated. The implicit behavior has been inconsistent:
- PR Define policy for internal development history #124 (ADR-0004) cleaned up origin/replaces fields immediately (zero-tech-debt approach)
- But left inline version markers and pipeline-design.md snapshots untouched (grandfather approach)
- ADR-0001's stale body is preserved by design (historical record), but the reason is ADR lifecycle convention, not a general conformance principle
This is the zero tech debt ↔ backwards compatibility spectrum. The project needs an explicit stance.
Zero tech debt end: New policy → immediate codebase-wide conformance. No grandfather clauses. The codebase always reflects current rules.
Backwards compatibility end: New policy → only new work conforms. Existing artifacts are left alone to avoid churn and risk.
Most real positions are somewhere in between, with criteria for when to clean up immediately vs. defer.
What needs figuring out
Where does this project sit on the spectrum, and what criteria determine the answer for a given policy change? Factors might include: risk of the change, cost of leaving stale artifacts, whether the artifact is machine-parsed or human-read, whether the old convention actively misleads.
Desired outcome
A stated conformance policy that contributors and agents can apply when a new convention is established. Should answer: "I just introduced a new rule — do I clean up all existing violations now, or only enforce going forward?"
Dependencies
- Blocked by Establish foundational project principles #125 (foundational principles) — the conformance stance should derive from principles, not be asserted independently