diagnose-project-rebuildlisted

# Diagnose Project Rebuild Diagnose first; intervene second. Rebuild is one possible treatment, not the default. ## Restore the real job Accept rough conversation, old files, surviving versions, code, screenshots, and partial memories as evidence. Restore the user's actual decision question before organizing the project. Separate: - the product's purpose; - current user decisions; - AI proposals; - observed behavior and validation; - implementation that may still be useful; - process experience that may travel; - old strategy that has no current authority; - missing or destroyed evidence. Do not treat document volume, code volume, test count, or effort already spent as proof that the direction is right. ## Diagnose by condition, not stage Inspect only enough live evidence to classify the limiting condition. Read [diagnostic-lenses.md](references/diagnostic-lenses.md) when the project has multiple histories, missing sources, contradictory truth files, or unclear authority. Choose one primary route: - **Recover** — important source evidence is missing or damaged; preserve and reconstruct before redesign. - **Clarify** — artifacts exist, but the product purpose, user, or promised change is not stable enough to govern work. - **Repair** — the direction is still valid, while documents, architecture, workflow, or implementation contradict it. - **Rebuild** — the direction was replaced or active context is too contaminated to repair safely in place. - **Continue** — purpos