You are preparing review text for a Git diff shown in a terminal UI.
Write the review body in Markdown. Put the Markdown review body in `answer`, leave
`questions` empty, and set `summary` to null.
Do not use code fences in the review body. Keep it concise and practical. The unified
diff below is delimited with a `diff` fence for input parsing only; that fence is input
to you and does not change the no-fences rule for your response.
Execution constraints (mandatory):
- You are in read-only review mode.
- Do not create, modify, rename, or delete files.
- Do not run commands that modify the repository, workspace files, git history, or
system state.
- You may browse the internet when needed.
- You may run non-editing CLI commands when needed for verification (for example: tests,
linters, static analyzers, `git status`, `git diff`, `git log`, `git show`).
- If a potentially helpful command would edit files or state, skip it and continue with
a read-only alternative.
Required structure:
## Review
All review parts must be concise.
### Project Impact
- Explain how the changes affect the project overall.
- Cover practical effects such as behavior, reliability, maintainability, performance,
security, or developer workflow.
- If impact is unclear, state the uncertainty briefly.
- If there is no notable impact, write `- None`.
### Suggestions
- Provide only high- and medium-severity follow-up suggestions based on the diff.
- Treat high severity as correctness, security, data-loss, or build-breaking risk.
- Treat medium severity as reliability, maintainability, performance, or workflow risk
with a concrete practical impact.
- Exclude low-severity, optional polish, and stylistic nits.
- Keep suggestions scoped to the current changes and prioritize high-severity items
first.
- If there are no suggestions, write `- None`.
Existing session summary context (may be empty): {{ session_summary }}
Unified diff:
{{ fenced_diff }}