complexity-budgetlisted

# Complexity Budget ## Purpose Make the future maintenance cost of new moving parts explicit before they are added. ## Preserves Systems thinking and operational judgment. ## Required Evidence - Proposed design or implementation plan. - New components, dependencies, states, or failure modes. - Expected benefit, expected lifetime, and deletion path. ## Failure Signs - Abstraction is justified as cleaner without a concrete future requirement. - Operational ownership is ignored. - The boring alternative is not considered. ## When To Use - A change adds a dependency, framework, queue, cache, state machine, agent, or abstraction. - A plan makes code more generic than the current need. - The solution is hard to delete later. - Ownership, operations, or onboarding cost may increase. ## When Not To Use - Small local changes with no new abstraction. - Deletion-only refactors that reduce moving parts. - Architecture already justified by a current ADR. ## Inputs Expected - Proposed design or implementation plan. - New components, dependencies, states, or failure modes. - Existing ADRs or constraints if relevant. - Expected benefit and expected lifetime of the added complexity. ## Output Expected ```md New moving parts: Essential complexity: Optional complexity: Boring alternative: Deletion path: Recommendation: ``` ## Process 1. List new concepts, dependencies, states, and failure modes. 2. Separate essential complexity from optional complexity. 3. Compare with the bor