systemic-issue-triagelisted

# Systemic Issue Triage Treat each issue's stated mechanism as a hypothesis, not evidence. The purpose is to eliminate a causal class with the smallest safe change, rather than grow one-off guards, flags, and states around its symptoms. ## Before triaging 1. Read every issue body and relevant comments, not just titles or labels. 2. Fetch `origin/main` and record the commit being evaluated. A report against an older release may already be fixed, but it is not proof until the reported scenario succeeds on the current target. 3. Read the affected OpenSpec contract in `openspec/specs/`. For a change that would alter behaviour, add an MCP tool, or affect a load-bearing invariant, open an OpenSpec change before implementation. 4. Build and run the narrowest real reproduction. Pair it with a passing control; a green probe that did not reach the boundary proves nothing. Use `diagnose` for the reproduction loop. If the affected surface is HTTP, MCP, or migrations, read `rembric-smoke-tests` and probe the actual mounted stack. ## Classification Place every report in one bucket and record its evidence: | Bucket | Meaning | Required evidence | | ----------------- | ------------------------------------------------------ | --------------------------------------------------- | | A — in flight | An approved, unmerged change addresses it | Change/PR plus the test