QA plan — dashboard overview

This document lists scenarios, not new verification results; prior suite counts are a prior baseline only.

G1 — owner/admin, schedule org

1. One greeting/header and one session list. Order is Action Center → Today/tasks → growth/revenue/leads trends → coaching roster when applicable.
2. No Pulse strip, standalone KPI strip, or Reports snapshot on Overview.
3. Seed the full 20-rule catalog and check severity/count ordering. Empty populations yield explicit all-clear. Use the Insights QA matrix for every rule’s boundary.
4. Today shows the whole org-local day, including dimmed ended sessions after the last class. A future class without a workout shows its amber chip.
5. Pending tasks use the open queue; clicking a row opens the existing detail sheet. Long classes/tasks lists scroll inside their own panel.
6. Growth requires analytics permission; revenue additionally requires finance permission and an active provider; leads requires leads management. A missing capability does not render a false zero chart.

G2 — coach and member roles

1. Coach HTTP Insights request succeeds with only the seven operations/engagement rules; finance, members, and leads rules are not evaluated. Coach Today requests succeed; no false coach-403 expectation.
2. Coach sees permitted task/schedule work, not restricted business trends or Reports data requests.
3. In coaching mode, one roster header contains due-today, seven-day completion, and needs-attention metrics; there is no separate KPI strip.
4. Member is routed to member home and cannot access the staff Insights feed.
5. Keep tool scope separate: analytics.org_insights is currently owner/admin registered even though the HTTP Action Center feed admits coaches.

G3 — delivery modes and members context

1. Coaching-only org: no class panel; tasks remain if permitted and coaching roster appears after applicable trends.
2. Mixed org: schedule and coaching surfaces both appear; schedule-only members must not enter the active coaching-enrollment roster.
3. No active programs: retain the scheduling empty state and Programs fallback.
4. Members ribbon requires analytics permission and shows total roster with commercial donut, trained this week, new this month, churned this month, and applicable imported/at-risk callouts. No Ending soon tile.
5. Donut selection filters the roster in place. The ending bucket/filter remains separate from open cancellation request/notice cases.

G4 — destinations

1. A Reports failure does not alter the Action Center or trends.
2. The Action Center emits actual task links:
   • tab=not_completed&type=manual_refund
   • tab=not_completed&type=payment_follow_up
   • tab=not_completed&type=cancellation_review
3. Direct-load/reload/back/forward hydrates supported task filters and /dashboard/payments?tab=debt. Unknown payment tab falls back to Transactions. tab=overdue is not supported; the overdue row links to the open queue sorted by due date rather than inventing a filter.
4. Named session samples carry valid program UUID, real org-local date, and session UUID through Schedule to the real program schedule tab/week/detail. Missing/invalid program context falls back to Programs; invalid optional date/session fields are dropped. No global schedule queue is implied.
5. Null root hrefs render nonlinks; bounded named member/session samples work where supplied. Overdue-task samples stay informational.
6. Open retention-case headline and SLA metadata count cases; a person with two cases appears once in the sample but contributes two cases. The cancellation action opens Tasks, not the Members ending roster.
7. Reports KPIs appear only at /dashboard/analytics, gated by analytics:view. Direct links use tab=attendance|revenue|retention and preserve from/to/classTypeId/method/months/asOf; the seven API/CSV projections remain intact. See Reports QA.

G5 — queues and Ask Spotter

1. Check-ins row expands its existing inline review queue; review actions update through the existing workflow.
2. Missing forms expands the existing outstanding-forms queue.
3. Ask Spotter is separate from row/sample navigation and sends localized prompt plus insight ID/count and insight subject. Later unrelated messages do not inherit stale selection context.

G6 — locales and evidence boundaries

1. Check en/he/ru labels, plurals, names, all-clear, chips and URL language prefixes. Hebrew uses logical-start severity rails and appropriate arrows.
2. Record the actual viewport with browser evidence. An 800×600 browser smoke is not full desktop/mobile responsive coverage.
3. Record whether the API used a private local clone. Do not call local browser/API evidence a production smoke or imply migrations were applied.
4. Final runtime verification is recorded separately; this documentation cleanup does not run tests, builds, lint, formatters, or performance checks.