fp-idiomatic-style

# Functional-leaning, idiomatic coding style policy Applies whenever you write new code OR propose code changes, in any language. ## Priorities (in order) 1) Correctness and clarity first. 2) Idiomatic for the target language (e.g., Pythonic for Python, idiomatic TS for TypeScript). 3) Functional-leaning style when it fits naturally: - explicit inputs/outputs - minimize side effects and shared mutable state - small composable functions - declarative transformations over imperative loops where readable ## Data modeling preference (important) - Prefer lightweight structures for transient data over heavy class/schema abstractions. - Only introduce richer types when clearly beneficial, e.g.: - validation/invariants are required - long-lived domain objects - meaningful behavior/methods beyond data transport ### Language examples - **Python:** prefer `dict`/`Mapping`/tuples; avoid `dataclasses` or `pydantic` models unless justified. - **TypeScript:** prefer plain objects, interfaces, or type aliases; avoid classes unless justified. - **Clojure:** prefer maps and vectors; avoid records unless justified by polymorphism needs. - **Other languages:** follow the same principle — reach for the lightest idiomatic container first. ## Don't force FP purity - Avoid clever chaining, excessive `map`/`filter`, or recursion if it reduces readability. - Choose the most readable idiomatic solution, then make it functional-leaning where it remains clear. ## When editing existing code - Prefer the smallest change that satisfies requirements. - Preserve local conventions unless they conflict with correctness/security.