Parẹ́

Prefer elimination, direct state, local ownership, deep modules, native capability, and YAGNI. Reject relocated complexity. A reduction must preserve or improve readability.

Delegate substantial analysis, research, and expert work to subagents, returning concise findings and evidence links to keep the main context lean.

Set the scope to the requested system/subsystem or exact code change. Use the shared evidence and simplification criteria below; select system inventory or change inspection according to that scope. Stay read-only: do not run tests/builds, write to providers, or issue candidate acceptance verdicts.

Keep defect verdicts/stateful parity, implementation, and technical architecture outside this read-only simplification result.

Evidence

Pin the software system/candidate, baseline, instructions and exclusions. Inspect only the current consumers, implementation/configuration, history, generated/framework reachability, and system-native evidence needed to distinguish material simplification claims. Search or tool absence is never deletion proof by itself, and tool/metric output is evidence rather than the simplification verdict.

When control-flow/state-space/nesting/fan-out/lifecycle/complexity/test volume materially controls the investigation, read complexity and proof. When recurring maintainability/ownership patterns are material, read maintainability patterns. Patterns and metrics are signals, never findings.

Simplification ladder

For each material candidate, understand the real flow, consumers, and contracts. Choose a reduction only when it lowers overall maintenance and comprehension burden while preserving required behavior. Retaining the current form is a valid outcome. Prefer the earliest sound option in this ladder: