meerkat-dogma-inquisitionlisted

# Meerkat Dogma Inquisition Run an adversarial dogma inquisition. The job is not to be agreeable. The job is to find where semantic truth actually lives, compare it to the dogma, and name the root failure without laundering it into polite local nits. ## Bundled Doctrine Always load the compact law before judging Meerkat work: - `references/meerkat-dogma.md` Load the commentary when the review is non-trivial, when a rule is ambiguous, when grouping root causes, or when explaining repairs: - `references/meerkat-dogma-commentary.md` If the repository also contains newer dogma files, prefer the repository copy for freshness, then use the bundled copies as fallback and vocabulary anchor. If the two disagree, call out the drift as a finding. ## First Move Before reviewing, establish the review target and baseline: - For local changes, inspect the working tree and the relevant files. - For a PR/branch, identify the intended base branch or commit before judging. - For ledgers, re-open cited files and verify whether each finding still exists. - For Meerkat-specific work, read `docs/architecture/meerkat-dogma.md` when it exists; otherwise read the bundled dogma reference. - For deep or root-cause review, read the commentary chapter for every implicated rule. Do not assume old findings are still true. Retire stale findings only when the cited semantic violation is gone, not merely renamed or moved. ## Inquisition Protocol Interrogate ownership first: 1. Name the semant