Files

60 lines
2.6 KiB
Markdown

---
name: review-backend-change
description: Review, fix, and validate the complete SXCHNGE backend contribution for a task. Use before reporting completion whenever Go, protobuf, or other backend code under backend/ was added or modified, or when the user requests a backend implementation review.
---
# Review Backend Change
## Establish the review scope
1. Read the repository root `AGENTS.md` and `backend/AGENTS.md` completely.
2. Inspect repository status and the full backend diff attributable to the
current task, including uncommitted and committed changes against the task's
base.
3. Separate unrelated pre-existing work from the task contribution. Preserve
it and do not include it in review fixes.
4. Identify changed behavior, public or internal contracts, and expected test
coverage before judging individual lines.
## Review and fix the contribution
1. Apply every quality requirement in `backend/AGENTS.md` to the entire task diff,
not only the most recently edited file.
2. Search the repository for canonical protobuf messages, enums, Go types,
interfaces, and shared domain definitions before accepting new ones.
3. Check project-error usage, cause preservation, cohesion, naming, API and
module boundaries, duplication, dead code, and testability.
4. Review structured logging at meaningful operational and domain boundaries.
Check level selection, context, sensitive-data handling, and duplicate error
logging.
5. Review success, edge, and failure paths. Add or update focused tests for the
changed behavior.
6. Fix every in-scope issue found, then re-read the resulting complete backend
diff. Repeat until no task-caused finding remains.
Do not weaken checks, suppress failures, or modify unrelated user work to make
validation pass.
## Validate
After review fixes are complete, run these commands from the repository root:
```text
make test
make lint-backend
```
Then select and run every applicable security command from the change-scoped
security completion requirements in the root `AGENTS.md`.
All commands must succeed before reporting the backend task as complete. If a
command fails, determine whether the task caused it and fix in-scope failures.
Report an external or environmental blocker with the exact command and failure;
never represent blocked validation as successful.
## Report the result
Summarize the reviewed backend scope, material fixes made during review, tests
added or updated, and the outcome of each required command. Call out contract,
migration, rollout, security, or observability implications that remain relevant.