chameleon-explainlisted

# /chameleon-explain Two drill-downs share this command, dispatched on the argument shape: - `/chameleon-explain <rule>` — explain one enforcement rule: why it's active or demoted, how often it would have blocked real edits, how often the team overrode it. The drill-down behind the `/chameleon-status` enforcement summary. - `/chameleon-explain <file>` — replay what chameleon knew and did the last time that file was edited, and classify why the gate stayed silent. The recovery loop for a postmortem. Dispatch: if the argument names an existing file (or looks like a path — has a `/`, a known source extension, or matches a file in the repo), run the **file** flow. Otherwise treat it as a rule name and run the **rule** flow. With no argument, explain every rule that has activity (rule flow). --- # Rule flow: `/chameleon-explain <rule>` Explain a single enforcement rule for the active repo: why it's active or demoted, how often it would have blocked real edits, and how often the team overrode it with inline `chameleon-ignore`. Usage: `/chameleon-explain <rule>` (e.g. `/chameleon-explain import-preference-violation`). With no rule, explain every rule that has activity. ## The two axes — keep them separate A rule's health is two independent measurements. Do not collapse them into one number. 1. **Bootstrap calibration (`fp_rate`)** — a one-shot measurement taken when the profile was built, running the rule against the repo's own committed files. A demoted rule carries the `