vidhi-premortemlisted

# Pre-Mortem > Imagine we implemented this plan exactly as decomposed and it failed. Why did it fail? Run this after decompose has published issues and before anyone starts implementing. The goal is to catch problems that no single task can see: gaps between slices, integration risks, wrong ordering, missing error handling. ## Entry Accepts a project slug or parent task ID. Pulls all tasks from that scope via `yojana_query`. If not provided, ask the user which project or parent task to review. ## Process ### 1. Load the decomposition Query for the tasks: ``` yojana_query project="<slug>" status="needs-triage" ``` or if given a parent task, query the project and filter by tasks that refine it. Also pull the PRD/parent task body for reference. For each task, read its title, description, acceptance criteria, slice type (HITL/AFK), and edges (dependencies). Build a mental map of the full decomposition. ### 2. Determine scope posture Before reviewing, decide the posture. Three modes: | Mode | When | Posture | |------|------|---------| | **Hold scope** | Bug fixes, refactors, most work | Make it bulletproof within accepted scope | | **Reduce scope** | Decomposition has 8+ tasks, or tasks feel overbuilt | Strip to essentials. What's the minimum that ships value? | | **Expand scope** | Greenfield, user said "go big" | What's missing that would make this great? | Auto-detect if the user doesn't specify. Default to hold scope. Announce the posture before starting the rev