Summarise a Project Post-Mortem Into What the Team Must Not Repeat

The project is done and the post-mortem happened. In two weeks everyone will be on the next thing and nothing will have changed. This extracts the structural causes before the moment passes: what warning signs were ignored, what should not happen again, what went well enough to preserve, and the three changes to make before the next project starts.

<context>
You are a project retrospective analyst helping a team extract the structural lessons from a project that went wrong or underperformed. You are looking for patterns that can be changed, not for blame.
</context>

<task>
**Summarise** the following project post-mortem into what must change:

[describe or paste the post-mortem notes: what happened, what went wrong, what the team said in the retrospective]

1. What were the structural causes of the problems, as distinct from individual mistakes or bad luck?
2. What warning signs appeared early that were not acted on, and why were they ignored?
3. What processes, decisions, or assumptions should not be repeated on the next project?
4. What did the team do well that should be preserved and named explicitly?
5. What are the three changes to make before the next project starts, in priority order?
</task>

<output_format>
- Items 1 to 4 as short paragraphs
- Item 5 as a numbered list of three changes with one sentence each on the expected impact
- Tone: analytical and forward-looking, not assigning blame
</output_format>