clean-codelisted

# Clean Code Clean code is code whose meaning is truthful, visible, and efficient enough for its job. This skill answers: > Is this code honest about what states are valid, clear about what it does, and free of needless local complexity? Use `clean-architecture` for responsibility placement, dependency direction, structural stage, startup wiring, adapters, and core boundaries. Use `clean-code` to evaluate the code inside those boundaries. ## Priority Order Apply checks in this order: 1. Semantic integrity 2. Reader clarity 3. Local efficiency Do not polish unclear code before deciding whether the behavior should exist. Do not optimize code whose meaning is wrong. Do not rename or compress code in ways that hide invariants. ## Semantic Integrity Semantic integrity is the hard gate. Fail code that makes invalid, obsolete, missing, or unknown state look acceptable. Look for: - `Option<T>` where absence is invalid - `Result<Option<T>>` where missing should be an error - nullable fields that are required in real usage - defaults hiding bad config or bad data - silent fallbacks - legacy aliases - permissive parsing of old formats - multiple schemas accepted in normal runtime paths - null, zero, empty, or infinity sentinels standing in for real meaning - invalid state converted to `None`, `0`, empty list, default object, or best-effort skip - swallowed errors around required behavior - broad enums with unused variants - boolean flags that hide real states - stringly typ