Finding simplifications

Find changes that remove maintained obligations: APIs, representations, lifecycle states, configuration paths, dependencies, tests, or documentation. It is guidance, not a checklist: prefer a few well-proven candidates over a count of deletions, and distinguish a survey from permission to implement its proposals.

Start with repo context

• Read the root AGENTS.md — the pre-release stance when present, and conventions such as tests-are-not-golden-truth and Agent Notes-are-not-golden-truth doctrines — plus the repository's defensive-patterns and testing docs when they exist.
• Skim the architecture doc before judging core code; simplifications that fight the service map or event taxonomy need extra evidence.
• Use the Agent Note tree and its rules to understand intentional architecture; a recorded decision needs new evidence to overturn, not a "looks complex" flag. Start with high-signal implemented examples — capability seams, twin adapters, and persistence notes — when the tree has them.
• Treat the repository's recorded adapter, persistence, and extension boundaries as intentional. Removing unused members within one can be valid when it preserves the recorded obligation; changing that obligation needs explicit scope and evidence.

What counts as a strong candidate

A strong simplification removes, folds, or demotes something real and has clear evidence that the current design costs more than it buys: