CC Window Aligner: Implementation Guide

| Decision Type | Required Signals | Authority | |---------------|------------------|-----------| | **Type/Schema changes** | Charter + Invariants + Downstream impact | Lock requires review | | **Algorithm changes** | Invariants preserved + Tests pass | Implementation owner | | **Configuration defaults** | Performance + Safety tradeoff | Implementation owner | | **New device support** | DIR-003 compatibility + No breaking changes | Requires integration test | | Conflict Type | Resolution | |---------------|------------| | **Invariants vs. Performance** | Invariants always win. Find alternative optimization. | | **Strict vs. Low-Latency** | Mode selection by caller. Both must work. | | **Simplicity vs. Completeness** | Completeness for invariant-related code. Simplicity elsewhere. | | **Determinism vs. Floating-point efficiency** | Determinism wins. Use reproducible operations. | A component is "done" when: 1. Implementation matches specification in this guide 2. All relevant invariants are enforced (see INVARIANTS.md) 3. Unit tests cover happy path + edge cases + failure modes 4. Integration test with at least one downstream consumer passes 5. Documentation is complete (inline + docs/) 6. No TODOs remain in implementation A component is "blocked" when: 1. Required upstream dependency does not exist 2. Invariant cannot be satisfied with current design 3. Clarification needed from charter (ambiguous requirement) 4. Performance target cannot be met Each implementation task (checklist item) must: - Touch at most ONE stage or ONE module - Produce at most ONE new public type - Be completable in one session - Have clear validation criteria