reviewing-test-coveragelisted

# Reviewing Test Coverage Present the set, apply feedback surgically, record approval, and capture what the corrections taught. ## 1. Present in chat Summary table first: | Test Case ID | Objective | Test Type | Priority | Tier | |---|---|---|---|---| Then full details per case: ID, Objective, Covers, Type, Priority, Execution Tier, Preconditions, Test Data, Test Steps, Expected Result. Then the complexity assessment, AC → TC matrix, dependency matrix, QA Questions, assumptions, charter, and notes to development. Never hide cases in a file. Never require a download to review. Generate Excel or CSV only if explicitly asked, and never regenerate the set to do it. If the checklist failed on any item, name the failures at the top rather than presenting a clean-looking set. ## 2. Apply feedback surgically QA may change priorities, remove cases, rewrite steps or expected results, add missing scenarios, or regenerate one case. - Change **only** what was named. - Preserve every unmentioned case byte-for-byte — objective, type, steps, expected result, priority, tier. - **Never renumber.** A removed TC-012 leaves a gap; that is correct. - New cases continue the sequence from the highest ID ever used. - Never regenerate the whole set unless explicitly asked. Re-run `../references/coverage-checklist.md` after edits and report any item the changes broke — for example, removing the only case covering AC-3. ## 3. Record approval Ask which IDs are approved. Accept ranges (`TC-0