brse-qa-scenariolisted

# BrSE QA Scenario ## Overview Create QA cases that prove the business requirement, not just the implementation path. **Core principle:** When the expected behavior is unconfirmed, do not write a test case — write a Japanese confirmation question for the customer. Guessing expected results poisons QA. ## When To Use - Preparing a regression checklist, demo case set, or release verification plan from a clarified requirement. - Customer review needs a JP QA sheet before sign-off. - Source impact (`brse-impact-trace`) has surfaced new paths the prior QA plan did not cover. ## When NOT To Use - Requirement is not clarified yet — run `brse-requirement-clarifier` first. - Customer asked only for a demo script, not full QA (use the demo-scoped subset). - Source behavior is unknown and untraceable — escalate before guessing. ## Workflow 1. Identify the target release, product surface, user role, and environment. 2. Start from acceptance criteria and source impact, then derive cases. 3. For each scenario, check if the expected behavior is **confirmed** or **unconfirmed**: - **Confirmed** — write a test case row. - **Unconfirmed** (spec silent, ambiguous, or contradicts source) — write a JP confirmation question instead. Do not guess the expected result. 4. Cover: - main path - permission/role differences - existing data vs new data - validation and error states - regression around adjacent flows - client/tenant-specific config 5. For customer-facing Ja