DDR-0033: Application Code Will Not Be Modified to Support Out-of-Date Unit Tests

Status: Accepted

Context:
During Phase 2 refactoring of the E27 session receive pump and framing integration,
several unit tests were found to rely on outdated function signatures, transitional
compatibility behaviors, or incomplete protocol models.

Specifically, some tests expected application code to:
- Accept legacy or ambiguous function signatures
- Support multiple incompatible result shapes
- Include conditional logic solely to satisfy test harnesses
- Retain temporary compatibility paths after architectural decisions were finalized

This created pressure to introduce complexity and ambiguity into production code
that is not required by the protocol, architecture, or intended API contracts.

Decision:
Application code SHALL NOT be modified or extended solely to preserve compatibility
with unit tests that are out of date, incorrect, or inconsistent with current
architectural decisions.

When a conflict arises:
- The architecture and protocol interpretation take precedence
- Application code reflects the canonical design
- Unit tests must be updated to match the current contracts

Temporary compatibility code introduced for transitional testing purposes must be
removed once the corresponding tests are corrected.

Rationale:
- Prevents long-term accumulation of test-driven technical debt
- Keeps production code minimal, deterministic, and spec-aligned
- Ensures tests validate intended behavior rather than legacy assumptions
- Preserves confidence in refactoring by enforcing a single source of truth

Consequences:
- Unit tests may fail after architectural or API changes until updated
- Test maintenance is treated as a first-class responsibility
- Refactoring phases may include explicit test update steps
- Compatibility shims are time-boxed and must not become permanent

Notes:
This decision applies broadly across the E27 codebase, including but not limited to:
- framing and deframing APIs
- session receive pumps
- encryption and presentation layers
- protocol state machines

This DDR formalizes an engineering discipline choice: correctness and clarity over
backward compatibility with stale tests.
# DDR-0033: Production Code Does Not Add Compatibility Shims for Out-of-Date Unit Tests

## Status
Accepted

## Context
During Phase-2 refactoring (session receive-pump cleanup and framing integration), unit tests may temporarily diverge from current module APIs (e.g., framing.deframe_feed signature and DeframeResult shape). Adding ad-hoc compatibility branches in production code to satisfy outdated tests increases complexity and risk, and can mask real integration issues.

## Decision
We will not modify production/application code to maintain compatibility with out-of-date unit tests.
When tests break due to intentional API evolution, tests must be updated to match the canonical production interfaces.

Specifically:
- Production code will use the canonical framing API:
  - DeframeState + deframe_feed(state, chunk) -> List[DeframeResult(ok, frame_no_crc, error)]
- Unit tests must mock/patch using the same signatures and result shapes.
- Temporary “accept both signatures / both shapes” compatibility code is not permitted in production paths.

## Consequences
- Tests may fail during refactors until updated, but failures reflect real API changes.
- Production code remains simpler and more correct, reducing long-term maintenance burden.
- Mocking standards become clearer: tests must emulate real APIs, not vice versa.
