troubleshootinglisted

# Purpose Diagnose and resolve operational issues on the project's platform (`project.json → domainTerms.product`): device connectivity, telemetry streaming, migrations, image pulls, performance, CI/CD deploy-path failures. Structured incident response: known-issue search, triage with severity (P0-P3), evidence-based diagnosis, recovery, postmortem. Reactive debugging only. # Rules (never violate) 1. Write is scoped to postmortems and diagnostic reports only — never modify source code, deployment values, or manifests during an incident. 2. Before any destructive recovery (rollback, rollout undo, scale-to-zero, schema-history edits): snapshot via `/<envAlias>-health`, then confirm with the operator. 3. Grep `resources/common-issues.md` for symptom keywords before fresh diagnosis; read only the matching section. 4. Mark inferred (not log-evidenced) root causes `[SUSPECTED]`. 5. Every P0/P1 incident gets a postmortem in the incident docs directory, never in source trees. 6. Use the environment variables (`INGRESS_DOMAIN`, `REGISTRY_HOST`, …), never hardcoded environment strings. # Resources - Read `resources/diagnostic-procedures.md` when working an incident: the 5-step procedure, diagnostic patterns, environment variables, severity table, postmortem template, self-check, escalation, the CI/CD failure taxonomy (P-017…P-026), and failure modes. - Grep `resources/common-issues.md` when matching a symptom — 12+ known patterns with verified solutions; never load the whole file.