# Risk Pre-Mortem

A forward-looking method for surfacing what could go wrong before a project starts, ranking each risk, and turning the serious ones into either a recorded issue or a mitigation task. Investigation mode handles problems after they happen; this is the opposite — it finds problems while they are still cheap to prevent. The Challenge Premise phase of a Full sprint asks whether the work is right but names no method for the risks; this supplies it.

## Method: imagine it already failed

The pre-mortem inverts the usual question. Instead of "what might go wrong?", assume the project has already failed and ask: "it is six months from now and this went badly — what happened?" Working backwards from an assumed failure surfaces risks that forward optimism hides, because the team is now explaining a failure rather than defending a plan.

Generate the list of failure causes, then rank each one on two axes:

- **Likelihood** — how probable is this, given what you know? Low / Medium / High.
- **Impact** — if it happens, how much does it hurt the project? Low / Medium / High.

The product of the two sets priority. A High × High risk is addressed before execution starts. A Low × Low risk is noted and left. The middle band is where judgement applies — a low-likelihood, high-impact risk (a key supplier folding) often deserves a mitigation even though it probably will not happen.

## Graph termination

Every risk worth surfacing terminates in the graph — never as chat-only text.

- **Serious risks become a recorded issue.** For each High-impact risk, append a note to the project with `project-update` in the issue format: `[PROJECT:ISSUE] {risk description} — Impact: {likelihood × impact assessment}`. This lands it in the project's searchable lifecycle history.
- **Risks you will act on become a mitigation Task.** Where a risk warrants concrete preventive work, create it with `work-create` and attach it to the project via `work-relate` (`PART_OF`, passing the project `taskId`). The mitigation then flows through the normal `work-ready` / execution path like any other task.

A pre-mortem that produces only a verbal warning has failed its own method. The test: after running it, `project-get` shows `[PROJECT:ISSUE]` notes or related mitigation Tasks. If it shows neither, nothing was actually captured.

## Wiring

This method runs inside the Challenge Premise phase of `sprint.md` (Full tier), before Lock Execution. Load it via `plugin-read` once the scope is agreed but execution has not begun — mitigations identified here change the locked task list. It can also run standalone before any significant project when the operator asks what could go wrong.

## When to Use

- A Full sprint Challenge Premise phase, before the plan is locked.
- "What could go wrong with this?"
- "Before we commit, what are the risks?"
- A high-stakes project where a preventable failure would be expensive.