Run a lessons-learned review after a project

Project: {{project_summary}}
Planned versus actual (dates, budget, scope delivered): {{planned_vs_actual}}
Who will read the review: {{audience}}

Input from the team (retrospective notes, survey answers, comments, emails):
"""
{{team_input}}
"""

Task:
Write a lessons-learned review of this project from the team's input, for the readers named above. The goal is to change how the next project runs, so every lesson should lead to something specific we will do differently. The review should be blameless: it looks at decisions, processes and conditions, not at who was at fault.

Format:
1. Summary: three or four sentences on how the project went against its plan, and the two most important lessons.
2. Timeline: up to eight key events or decisions, in date order, that shaped the outcome.
3. What went well and should be repeated: up to five points, each with its evidence from the input.
4. What did not go well: up to five points. For each, the effect it had and the underlying cause, asking "why" until you reach something a process or decision could change, and stopping where the input stops.
5. Lessons and actions: five to seven, each written as "Next time we will..." with a suggested owner (a role) and where it will be recorded so it gets used, such as a project template, a checklist or an onboarding guide.
6. Open points: questions the input raises but does not answer.

Requirements:
- Under 900 words.
- Blameless wording: describe what happened and why it made sense at the time. Do not name individuals in anything that went wrong; name people only in what went well, and only if the input names them.
- Show how widely a view was held, for example "raised by four of seven people", and do not present one person's view as the team's.
- Use only the input. Do not add causes, events or figures it does not contain.
- Lessons must be specific actions, not general advice such as "communicate better".

If the input comes from only a few people, or from only one team, say so at the top, because the review may be missing other views. If the input is too thin for a section, write what is missing and suggest two questions to ask the team.