0004 — Credo ruleset pinned to the FluxVale fleet config

Context

mix ci ran credo --strict with no .credo.exs — credo's implicit default ruleset (ADR 0003: nothing in the code failed it, so no file shipped). That means the rule set silently changes with every credo upgrade, and it diverges from the rest of the FluxVale fleet, where the reference config at ~/Work/FluxVale/fluxvale/apps/platform/.credo.exs (generated against credo 1.7.19, exact-pinned in both repos) settles the posture: fully enumerated checks (immune to credo drift), UnusedVariableNames [force: :meaningful], TagTODO [exit_status: 2] (TODOs fail the gate), MaxLineLength at 120 with low priority, Readability.Specs on, and a fixed disabled list.

Decision

Ship a .credo.exs derived from the fleet reference. Same enabled set, same disabled list, same per-check parameters, strict: true — identical modulo single-app adaptations:

Adopting the ruleset surfaced ~150 findings in the TUI code (missing @specs, bare _ names, single/multi-pipe style, variable rebinding, @impl true, grouped aliases, String.to_atom in tests). All were fixed in the same change with behavior-preserving edits; no check was relaxed to make that easier.

The config carries a header crediting its derivation and source path: future readers diff the two files to sync fleet-wide changes, and a check added by a future credo stays off until it is enumerated in both.

Alternatives considered

Consequences