|
- ---
- 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.
|
