design-rationale

Investigate why code is shaped this way. Git and PRs first, then every evidence category that actually exists (tickets, docs, chat, observability, errors, analytics). Every claim is labeled Direct / Supported / Inferred / Speculative / Unknown. Never treat code as its own intent. Apply when the user asks why a design exists, why a flag is off, or why a threshold is what it is. Use subsystem-walkthrough for runtime behavior. Use dissect to audit entities. Use proving-change-safety before merge.