---
description: Require deploy/release notes with test plan and expected results for commits and PRs
alwaysApply: true
---

# Deploy notes: what changed + how to test

When the user asks to **commit**, **open a PR**, **prepare a deploy**, or **summarize changes for the team**, also produce a short **Deploy / QA note** (Markdown) with test steps and expected results.

## Required sections

```markdown
## Summary
- (1–3 bullets: what changed and why; user-facing impact)

## Scope
- Backend: …
- Frontend: … (if any)
- DB / Liquibase: … (none if N/A)
- Config / ops: … (none if N/A)

## Commits
- `abc1234` — short title

## Test plan
| # | Steps (who / where / data) | Expected result |
|---|----------------------------|-----------------|
| 1 | … | … |
| 2 | … | … |

## Out of scope / not tested
- …

## Rollback
- How to revert or disable if broken (branch, flag, or previous build)
```

## Rules

- Prefer **concrete UI labels** in 「」 and real routes (e.g. `/doworkbench`) when UI is involved.
- Prefer **concrete sample data** when known (item codes, dates, shop codes) from local DB or the change itself.
- Cover **happy path + one failure / edge** when the change adds validation or a fix.
- If only backend API changed, still give **how to verify** (API call, UI screen that uses it, or SQL check).
- Do **not** invent test steps for files you did not inspect; if unclear, say what to confirm with the author.
- Save durable notes under `docs/deploy/` when the user asks to keep them (filename: `YYYYMMDD_short-topic.md`).
- To auto-generate **one Word file per commit** into a folder, run:
  `python scripts/generate_commit_test_plans_docx.py <range>` → `docs/deploy/commit-plans/`.
- Commit messages should still be clear; “no message” is not acceptable when we author the commit.