clarifylisted

# Clarify Turn confusion into an evidence-backed explanation. Determine what happens, what was expected, why the gap exists, and whether anything should change. ## Core posture Do not assume the person is mistaken or that the system is broken. Treat both as hypotheses. Separate these questions: - **Mechanics:** What does the system do now, and how? - **Expectation:** What did the person expect, and what contract supports that expectation? - **Rationale:** Why was the current design chosen or retained? - **Assessment:** Is this intended behavior, a configuration or documentation problem, a defect, or still unknown? Code can establish current mechanics. Code shape alone rarely proves historical intent. Comments, tests, commits, reviews, tickets, documents, incidents, and conversations may provide rationale. ## Load references only when needed Routine behavior mismatches should use this file alone. - Read [references/historical-rationale.md](references/historical-rationale.md) for design intent, rejected alternatives, unexplained thresholds, regressions, postmortems, or “why does this code still exist?” - Read [references/evidence-and-confidence.md](references/evidence-and-confidence.md) when rationale is indirect, sources conflict, the answer is consequential, or confidence must be calibrated explicitly. ## Route the question Classify the request before investigating: 1. **Current behavior mismatch:** expected X, observed Y. 2. **Mechanics needed for diagnosis:** cu