analyze-problemlisted

# Analyze Problem ## Purpose Perform structured problem analysis before proposing or implementing any changes. Focus on: - verified facts - multiple hypotheses - root cause identification - validation strategy --- ## Constraints - Apply `@rules/php/core-standards.mdc` **only once it is established that the project is a PHP project (PHP stack in `composer.json`) and the analyzed change touches PHP code** — skip it for a non-PHP problem (docs, tooling, infra, markdown, config); do not load the PHP standards for an analysis that does not touch PHP. - Apply @rules/compound-engineering/general.mdc — the pre-implementation research and the plan artifact below exist so the analysis compounds: it grounds the work in what already exists and leaves a reusable plan behind. - Never modify code - Output Markdown only - Use one language only - Do not jump directly to solutions - Do not assume a single cause - Be explicit about uncertainty --- ## Execution ### Issue-tracker context (mandatory pre-flight) Whenever the problem references an issue-tracker source (a GitHub issue / PR, a JIRA key, or a Bugsnag error — identifiable from a link, an ID, or the surrounding task context), you **must** load **all** available tracker information **before** starting the analysis. This is not optional: an analysis built on a partially-read issue is the most common source of a wrong root cause. - Run the deterministic context gatherer for the detected tracker — never call `gh`, `acli`, or REST en