@roopesh.yadava/qa-pack 1.5.0 → 1.6.0

package/README.md

@@ -107,6 +107,28 @@ token beyond the one line of output. This is also why `qa-insights` (dashboard/d
 across every product you've ever tested) costs about the same whether you have 2 products or
 200 — the script does the aggregation, not the model.
 
+### Team dashboard (optional, off by default)
+
+`qa-insights`' dashboard is local and per-repo — it only sees runs on your own machine.
+To see the whole team's runs across every product, set `QA_DASHBOARD_REPO` and
+`QA_DASHBOARD_TOKEN` in `.env` (see `.env.example`). Once set, **every skill** reports its
+own execution as its last step — one small JSON file pushed to that shared GitHub repo via
+the GitHub Contents API. No local `git commit`/`git push`, so it never touches this repo's
+`.git` or shows up in `git status`. Leave the variables unset and nothing changes; the
+call is a silent no-op, same as the optional `QA_TRACKING_DIR` token tracking.
+
+One record is one *skill execution*, not one card: a single card taken through `qa-agent` →
+`manual-testing` → `bug-reporting` reports three. The dashboard counts both ("skill runs"
+and "cards covered") so neither number is misleading.
+
+What each record contains: product, card (when the skill has one), skill name, outcome, bug
+IDs, reuse %, date, calling repo name, and an author label taken from `git config user.name`
+— never `user.email`, since the dashboard repo is typically public and its history is
+permanent. Set `QA_DASHBOARD_AUTHOR` in `.env` to override the label. A push that fails
+(expired PAT, wrong repo, no network) stays silent and is appended to
+`outputs/report-run-errors.log`; add `--verbose` to a manual `report-run` call to see the
+result directly, which is the way to verify a freshly issued token.
+
 ## What postinstall does
 
 | File | Behaviour |

package/claude/skills/SKILLS_CONTEXT.md

@@ -50,6 +50,8 @@ A 10-test run with `browser_snapshot()` per test = ~100k wasted tokens.
 | `BDD_TEMPLATES.md` | Once at Phase 1 start | Never reload in the same run |
 | `LOCATOR_PATTERNS.md` | Once at Phase 1 start | Never reload in Phase 2 or 3 |
 | `WCAG_CHECKS.md` | Once at skill start | Never reload |
+| `manual-testing/TEST_DESIGN_GUIDE.md` | Once at Phase 1c (manual-testing) | Never reload — reference sections by number (§1–§9) |
+| `mobile-automation/MOBILE_MCP_REFERENCE.md`, `BDD_TEMPLATES.md`, `LOCATOR_PATTERNS.md` | Once at Phase 2 start (mobile-automation) | Never reload in Phase 3 or 4 |
 | `test-charter.md` | Once when charter starts | Never reload |
 | `context.md` | Once at qa-agent Step 0 | Never reload |
 
@@ -86,14 +88,15 @@ node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs <command> [--flags]
 | Command | Used by | Purpose |
 |---------|---------|---------|
 | `get-bugs` / `get-runs` / `get-selectors` --product P | any skill | Cheap reads of one context.md table, pipe-delimited rows |
-| `fingerprint` --product P --url U --testids "a,b" | manual-testing, automation, roam-testing | DOM fingerprint cache — `UNCHANGED` means skip re-discovery |
+| `fingerprint` --product P --url U --testids "a,b" | manual-testing, automation, mobile-automation, roam-testing | DOM/screen fingerprint cache — `UNCHANGED` means skip re-discovery. Mobile uses a synthetic `mobile:{bundleId}/{Screen}` string as `--url` and resource-id/accessibility-id values as `--testids` — the command itself is platform-agnostic |
 | `pii-scan` (stdin or `--file`) | bug-reporting, manual-testing, roam-testing | Flags emails/keys/tokens before anything is posted to Jira |
 | `dup-bug` --product P --summary S | bug-reporting, manual-testing, roam-testing | Fuzzy-matches a new bug against Known Bugs, no LLM comparison needed |
 | `cost-estimate` --product P [--phase N] | qa-agent | One-line run-cost estimate from Runs Log history |
 | `risk-score` --product P --modules "a,b" | manual-testing | Orders tests by git churn + past bug density, not AC order |
-| `trust-record` / `trust-status` --product P | automation (record), qa-agent (status) | Trust ratchet on Gate 1/Gate 2 approvals |
-| `locator-record` / `locator-query` --product P --page U | automation | Self-improving locator memory across self-heal fixes |
-| `dashboard` / `digest [--days N]` / `roi` | qa-insights | Cross-product reports — 100% script-generated, zero synthesis |
+| `trust-record` / `trust-status` --product P [--namespace N] | automation, mobile-automation (`--namespace mobile` — routes to a separate `trust.mobile.json` so its gate streaks never enter qa-agent's web-only eligibility computation), qa-agent (status) | Trust ratchet on Gate 1/Gate 2 approvals. `--namespace` is optional and additive — omitted, behavior is unchanged (`trust.json`); `trust-status` takes `min(streak)` across every gate in whichever file it reads, so gates from two automation surfaces must never share one file |
+| `locator-record` / `locator-query` --product P --page U | automation, mobile-automation (page keys prefixed `mobile:` to avoid colliding with web page URLs) | Self-improving locator memory across self-heal fixes |
+| `dashboard` / `digest [--days N]` / `roi` | qa-insights | Cross-product reports — 100% script-generated, zero synthesis. Add `--json` to any of the three for a structured payload (same data, machine-readable) instead of the one-line summary — for anything scripting against this (e.g. an external dashboard app) rather than chatting with it. |
+| `report-run` --skill S --outcome Y [--product P] [--card C] [--bugs "a,b"] [--reuse N] [--phase X] [--verbose] | **every skill, as its own last step** — `qa-agent`, `automation`, `manual-testing`, `mobile-automation`, `accessibility-testing`, `ui-test-figma`, `roam-testing`, `bug-reporting`, `impacted-tests`, `test-charter`, `k6-framework-scaffold` | Optional team dashboard: pushes one JSON file per **skill execution** to a shared GitHub repo (Contents API — no local git commit/push). Only `--skill`/`--outcome` are required: `--product` defaults to the calling repo's name and `--card` is omitted entirely by the skills that have no Jira card. Silent no-op unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env`, same convention as `QA_TRACKING_DIR`. A failed push never prints or fails the run — it is appended to `outputs/report-run-errors.log`; `--verbose` prints the result, which is how you verify a new PAT once. No `--notes` flag — only short, structurally-constrained values are safe to inline. |
 
 This file is versioned logic (always overwritten on `npm update`, like every other skill
 file) — never store product data inside it. Its outputs live under
@@ -101,6 +104,11 @@ file) — never store product data inside it. Its outputs live under
 `locator-learnings.md` — all new, all gitignored the same way `context.md` already is) or
 `outputs/` (`dashboard.html`, `qa-weekly-digest-*.md`, `roi-report.md`).
 
+The toolkit reads `.env` from the repo root itself (real environment variables win), so
+every `QA_*` value documented for `.env` reaches it without the calling skill exporting
+anything. Before this, `QA_DASHBOARD_*` and `QA_TRACKING_DIR` were read straight off
+`process.env` and were therefore permanently unset in normal skill use.
+
 **Never inline arbitrary text into a toolkit shell call.** Bug descriptions, locator
 strings, and anything else that isn't a short agent-controlled token (a card ID, a product
 folder name, a URL) can contain quotes, `` ` ``, `$(...)`, or `|` — inlined into a bash
@@ -148,12 +156,18 @@ test-charter   │
 this diagram — they don't take a Jira card, and qa-insights doesn't touch Playwright at all.
 Both are driven by the toolkit rather than by each other.
 
+`mobile-automation` also sits outside this diagram — it's a standalone, directly-triggered
+skill (same status as `roam-testing`/`k6-framework-scaffold`), not wired into qa-agent's
+Phase 2 dispatch, which remains web/Playwright-only via `automation`. Trigger it by name
+("automate mobile PROJ-123", "mobile test PROJ-123") rather than through the qa-agent phase menu.
+
 ## Skills — One-Line Summary
 
 | Skill | Input | Output | MCP Needed |
 |-------|-------|--------|------------|
 | `qa-agent` | Jira card ID or menu choice | Dispatches to correct skill | Atlassian |
 | `automation` | Jira card ID | Reuse audit + Gherkin + Step Defs + POM + real run (reuse % reported) | Atlassian, Playwright |
+| `mobile-automation` | Jira card ID | Reuse audit + mobile Gherkin + Step Defs + Screen POM + real device run (reuse % reported) | Atlassian, Mobile MCP, MobileWright/mobilecli |
 | `manual-testing` | Jira card ID + app URL | Execution report + bugs + charter | Atlassian, Playwright |
 | `ui-test-figma` | Figma URL + app URL | UI mismatch report, Jira comment | Playwright (CLI+MCP), Figma (optional) |
 | `accessibility-testing` | Full page URL + Jira card (optional) | WCAG 2.1 A/AA report + Jira bugs | Playwright (CLI+MCP), Atlassian |
@@ -244,6 +258,7 @@ python3 $PROJECT/track_tokens.py session
 
 **Phase names by skill:**
 - automation: `start` → `jira_fetch` → `reuse_audit` → `gherkin_generation` → `step_definitions` → `pom_generation` → `test_run` → `end`
+- mobile-automation: `start` → `jira_fetch` → `reuse_audit` → `gherkin_generation` → `step_definitions` → `pom_generation` → `test_run` → `end`
 - manual-testing: `start` → `jira_fetch` → `ui_testing` → `test_execution` → `end`
 - ui-test-figma: `start` → `login` → `comparison` → `end`
 - accessibility-testing: `start` → `login` → `a11y_checks` → `end`
@@ -280,10 +295,13 @@ First run will always be 0% (cold cache). Second and subsequent runs should cach
 | Auth session | `.playwright-session.json` (gitignored) |
 | Secrets / environment | `.env` at repo root (gitignored) |
 | Step catalog (reuse audit) | `.claude/skills/qa-agent/product_context/[PRODUCT]/step-catalog.md` |
+| Mobile step catalog (reuse audit) | `.claude/skills/qa-agent/product_context/[PRODUCT]/mobile-step-catalog.md` |
 | Automation hints | `outputs/automation-hints-[CARD]-[date].md` |
 | Token analytics | `~/.claude/token_analytics.png` |
 | Knowledge graph | `graphify-out/graph.html` (open in browser) |
 | Product QA context | `.claude/skills/qa-agent/product_context/[PRODUCT]/context.md` |
+| Team QA dashboard data (shared, cross-repo, not in this repo) | `runs/[PRODUCT]/[date]-[card]-[skill]-[id].json` inside the repo named by `QA_DASHBOARD_REPO` — see `report-run` |
+| Team dashboard push failures (local, gitignored) | `outputs/report-run-errors.log` — the only place a failed `report-run` is visible |
 | DOM fingerprint cache | `.claude/skills/qa-agent/product_context/[PRODUCT]/dom-fingerprints.json` |
 | Trust ratchet state | `.claude/skills/qa-agent/product_context/[PRODUCT]/trust.json` |
 | Locator learnings | `.claude/skills/qa-agent/product_context/[PRODUCT]/locator-learnings.md` |
@@ -292,3 +310,4 @@ First run will always be 0% (cold cache). Second and subsequent runs should cach
 | QA weekly digest | `outputs/qa-weekly-digest-[date].md` |
 | Token-spend / ROI view | `outputs/roi-report.md` |
 | Shared toolkit CLI | `.claude/skills/qa-agent/toolkit/qa-toolkit.cjs` |
+| Manual-testing coverage/scenario reference | `.claude/skills/manual-testing/TEST_DESIGN_GUIDE.md` |

package/claude/skills/accessibility-testing/SKILL.md

@@ -315,3 +315,19 @@ Accessibility Testing Complete
 | Jira bug creation fails | Note failure, continue remaining bugs, report failures at end |
 | OTP screen appears unexpectedly | Type the `QA_OTP_CODE` value from `.env`, proceed |
 | Page requires further navigation after login | Follow redirect, confirm TARGET_URL loads |
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill accessibility-testing --card {JIRA_CARD_ID, omit if none} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}"
+```
+This skill has no `PRODUCT_FOLDER`; omit `--product` and the record is filed under the
+calling repo's name automatically. Omit `--card` too when the run had no Jira card.

package/claude/skills/automation/SKILL.md

@@ -531,3 +531,21 @@ Print one line only (omit entirely if file not found):
 ```
 Selectors written to product context ({N} elements, {N} flows).
 ```
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill automation --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --outcome {Pass|Fail|Partial} --reuse {reuse % number} --phase Automation
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/bug-reporting/SKILL.md

@@ -293,4 +293,21 @@ Show a summary:
 - Notified: [Confirmed person's name]
 - Screenshots attached: [list of filenames, or "none" / "credentials not set"]
 
----
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill bug-reporting --product {PRODUCT_FOLDER} --card {the card just filed/updated} \
+  --outcome {Pass if the bug posted, Fail if it did not} \
+  --bugs "{the bug key(s) filed}"
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/impacted-tests/SKILL.md

@@ -108,4 +108,19 @@ Rules for each entry:
 
 ## Step 5 — Stop
 
-The report is the deliverable. Do NOT run any test, do NOT ask whether to run them — the QA reviews the report and runs files manually using the footer command. End the turn after printing the report.
+The report is the deliverable. Do NOT run any test, do NOT ask whether to run them — the QA reviews the report and runs files manually using the footer command. End the turn after printing the report (the dashboard report below is the one exception — it prints nothing).
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Run this after the report is printed and before ending the turn. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill impacted-tests --outcome Pass
+```
+No product folder and no card in this skill — omit both flags; the record is filed under
+the calling repo's name.

package/claude/skills/k6-framework-scaffold/SKILL.md

@@ -56,3 +56,17 @@ After it runs, tell the tester the next steps:
 - Keep real tokens out of version control (the scaffold's `.gitignore` covers `secrets.local.*`).
 - If the user wants the structure tailored (their user types, real endpoints from a Postman
   collection), scaffold first, then edit the generated templates to match.
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill k6-framework-scaffold --outcome {Pass|Fail}
+```
+No product folder and no card — omit both flags.

package/claude/skills/manual-testing/SKILL.md

@@ -2,8 +2,12 @@
 name: manual-testing
 description: >
   Manual Testing branch orchestrator. Follows the flowchart:
-  Jira Card Input → UI Testing (Figma MCP, optional) → Manual Testing (Playwright MCP)
-  → Bug Reporting (Atlassian MCP) → Test Charter → Automation Agent (optional handoff).
+  Jira Card Input → Requirement Gap Analysis → UI Testing (Figma MCP, optional) →
+  Manual Testing (Playwright MCP) → Bug Reporting (Atlassian MCP) → Test Charter →
+  Automation Agent (optional handoff).
+  Test planning is risk-scoped and coverage-dimension-driven (see TEST_DESIGN_GUIDE.md) —
+  not just "1-3 tests per AC line" — so a payment/auth card gets materially deeper coverage
+  than a copy-change card.
   Captures element selectors and interaction data during execution and saves them to an
   automation-hints file for the automation skill to reuse — skipping DOM re-discovery.
   Uses Playwright CLI for zero-token screenshots. Token tracking enabled.
@@ -99,6 +103,13 @@ Derive `PRODUCT_FOLDER` now (uppercase `PROJECT_KEY`'s product name, spaces →
 normalisation qa-agent Step 6a uses) so Phases 3 and 4 below can call the toolkit without
 re-deriving it. If the qa-agent parameter block already named a product folder, use that instead.
 
+If a product folder was resolved, pull known bugs cheaply for the retest check used in 3a/§9
+— one script call, not a `context.md` read:
+```bash
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs get-bugs --product {PRODUCT_FOLDER}
+```
+Store non-`Closed`/`Done` rows as `OPEN_KNOWN_BUGS`. `NO_CONTEXT_FILE`/`NO_BUGS` → `OPEN_KNOWN_BUGS = []`, first run for this product.
+
 Run token tracking `jira_fetch` checkpoint.
 
 ### 1b — Truncate Jira data if card is verbose
@@ -112,14 +123,33 @@ After fetching, check `CARD_DESCRIPTION` length:
 
 Do NOT tell the user the description was truncated. This prevents verbose cards from consuming 5k+ tokens before testing even starts.
 
-If no AC found (and qa-agent didn't already resolve this):
-> "No Acceptance Criteria found on this card. What should be tested?"
-Wait for user response before continuing.
-
 Set from Phase 0 values (all input was collected there — do not re-ask):
 - `RUN_UI_TEST` — true when a Figma URL is available (from parameter block, card, or user)
 - `FIGMA_URL`, `APP_URL`, `USERNAME`, `PASSWORD`, `OTP_CODE`
 
+### 1c — Load Test Design Guide (once)
+
+Read `.claude/skills/manual-testing/TEST_DESIGN_GUIDE.md` now. Per the Static File Load
+Rules in `SKILLS_CONTEXT.md`, load it once here and never reload it later in this run —
+reference its sections by number (e.g. "per §4 High risk") for the rest of the pipeline.
+
+### 1d — Requirement Gap Analysis
+
+Run the checklist in `TEST_DESIGN_GUIDE.md` §1 against `CARD_TITLE` + `ACCEPTANCE_CRITERIA`.
+This **replaces** the old bare "no AC found" check — the missing-AC row is §1's first row and
+is the most severe: if it fires, skip evaluating the rest of the table and ask only that.
+
+Fold every gap that actually applies into **one** consolidated question — the same message as
+any unresolved Phase 0 gaps, not a second round:
+> "No Acceptance Criteria found on this card. What should be tested?" (only if AC is entirely
+> missing), or, when AC exists but has gaps: one line per applicable §1 row, e.g. "AC mentions
+> a 'reference code' but doesn't state its length/format — what's the exact rule?"
+
+Skip this step's question entirely if the AC is already precise and complete on every §1
+row — do not manufacture questions to fill the message.
+
+Wait for the response before proceeding to Phase 2.
+
 ---
 
 ## Phase 2 — UI Testing (optional)
@@ -162,20 +192,44 @@ HINTS = {
 }
 ```
 
-### 3a — Generate Test Plan
+### 3a — Generate Test Plan (risk-scoped, coverage-dimension-driven)
 
 Before drafting test ideas, check each AC item for a stated entry point (menu path, URL,
 button/link name). Per the **Test Data & Entity Selection Rules** above, do not scan `src/`
 to infer a missing one — collect a single navigation question per missing entry point and
 fold it into the confirmation prompt below instead of guessing.
 
-From the AC, generate numbered test ideas:
-- 1–3 tests per AC item
-- 2+ negative/edge case tests
-- 1+ error state test
-
-**Risk-based ordering** — pull 2–5 module/page keywords straight out of the AC/card title
-you already read (e.g. "login", "checkout"; no extra fetching), then run one script call:
+**Step 1 — Classify risk tier and select dimensions.** Using `TEST_DESIGN_GUIDE.md` §2 (Feature
+Signal → Coverage Dimension Trigger Table), scan `CARD_TITLE` + `ACCEPTANCE_CRITERIA` for
+signal keywords and turn on the matched dimensions. No signal matched → default set only
+(Functional Positive/Negative + UI/UX States + one Boundary check). Then classify the card's
+risk tier per §4 (High/Medium/Low) from the same signals — this sets how many tests each
+triggered dimension gets, not just which dimensions run.
+
+**Step 2 — Draft numbered test ideas per dimension.** Walk the §5 Test Scenario Identification
+Framework (the 10 "what can/can't/who/what happens" questions) once, and for each dimension
+turned on in Step 1, draft the number of tests §4's tier calls for. Concretely, for a Medium-risk
+card this typically looks like: 1–2 Functional Positive, 1–2 Functional Negative, one Boundary
+or Equivalence set per §6 if the AC states or implies a limit, one UI/UX States pass (§8) on the
+card's key screen, plus one test per other triggered dimension (Permissions, API, Database,
+State/Workflow, etc.). High-risk cards double the per-dimension count and add Security-oriented
++ Database checks unconditionally per §4. Low-risk cards (copy/label-only) skip straight to
+Functional (positive + one negative) plus one regression spot-check — do not force the other
+dimensions onto a low-risk card.
+
+Cap exploratory ideas (§5 Q10) at one per plan, clearly tagged `[exploratory]`, so they don't
+inflate the "planned" test count used for the Exit Criteria check later (§9).
+
+If `OPEN_KNOWN_BUGS` (from Phase 1) contains a row whose Title overlaps this card's module/page
+keywords, add one retest test tagged `[retest: {BUG-ID}]` — this is what §9's retest check
+verifies actually happened.
+
+Do not draft dedicated regression tests here — that's qa-agent Step 5's job (Covered Flows
+overlap), triggered automatically after this skill returns. §5 Q9 exists only to flag *that*
+regression may apply, not to author it now.
+
+**Risk-based execution ordering** — pull 2–5 module/page keywords straight out of the AC/card
+title you already read (e.g. "login", "checkout"; no extra fetching), then run one script call:
 
 ```bash
 node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs risk-score --product {PRODUCT_FOLDER} --modules "kw1,kw2,kw3"
@@ -183,11 +237,13 @@ node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs risk-score --product {PRODUC
 
 Order the T-01, T-02... list so tests touching the highest-risk module come first. On a
 product's first run (no git history / no known bugs yet) every module scores 0 — keep the
-natural AC order in that case, no need to mention it.
+natural drafting order in that case, no need to mention it. (This reorders the tests drafted in
+Step 2 — it doesn't decide how many exist; that's §4's job, run once, not repeated per module.)
 
-Show as a compact table (T-01, T-02 ... with name and expected outcome), risk-ordered.
-Ask: `"Ready to run these tests? (yes / no or edit)"` — include any missing navigation
-questions in this same message.
+Show as a compact table (T-01, T-02 ... with name, dimension tag, and expected outcome),
+risk-ordered. Ask: `"Ready to run these tests? (yes / no or edit)"` — include any missing
+navigation questions from above in this same message (§1 gap questions were already asked
+and resolved in Phase 1d — don't re-ask them here).
 Proceed on confirmation.
 
 ### 3b — Setup Browser + Capture Login Selectors
@@ -305,10 +361,13 @@ For each test T-01, T-02, ...:
      outputs/screenshots/T-[N]-[pass|fail|observation].png
    ```
 
-5. Assert expected result via targeted `browser_evaluate` on specific selectors
+5. Assert expected result via targeted `browser_evaluate` on specific selectors. If this
+   test's dimension tag (from 3a) is UI/UX States, note which of the `TEST_DESIGN_GUIDE.md`
+   §8 states (Initial/Loading/Empty/Success/Error/Disabled) were actually observed and their
+   result — skip states genuinely unreachable in this test, don't force them.
 
 6. Log test result (to file only, not chat):
-   `T-N | title | status | expected | actual | screenshot path`
+   `T-N | title | dimension | status | expected | actual | screenshot path`
 
 7. Append to `HINTS.testCases`:
    ```
@@ -407,13 +466,19 @@ this keeps context contiguous and avoids a second skill invocation.
 
 **Step 4a — Build bug payload for each ❌ FAIL and ⚠️ OBSERVATION**
 
-Derive all fields from test execution data — no user input needed:
+Derive all fields from test execution data — no user input needed. Fields follow
+`TEST_DESIGN_GUIDE.md` §7:
 
 | Field | Source |
 |-------|--------|
 | Summary | `"T-{N}: {test name} — {actual outcome in one line}"` |
-| Description | Steps from test case + expected vs actual from execution log |
+| Environment | `APP_URL` + environment name from product context (staging/dev/prod) |
+| Preconditions | Login state + any setup steps from the test case (e.g. role, prior state) |
+| Description (Steps/Expected/Actual) | Steps from test case + expected vs actual from execution log |
 | Severity | AC explicitly failed → High · Assertion failed → Medium · Observation → Low |
+| Priority | High-risk dimension (§4) failing → High · otherwise matches Severity |
+| Test data used | The specific values/entities used for this test (never credentials) |
+| Build/version | `CARD_ID` + run date (stands in for a separate build number) |
 | Screenshot | Match `outputs/screenshots/T-{N}-*.png` by test ID — use exact filename |
 
 **Step 4a.1 — Duplicate check (one script call per failure, no user input needed)**
@@ -496,14 +561,22 @@ Run token tracking `end + report + session` close-out after charter publishes.
 
 ## Phase 6 — Automation Handoff
 
-After charter completes, show the final summary:
+After charter completes, run the `TEST_DESIGN_GUIDE.md` §9 Exit Criteria Quick Check:
+confirm every planned test executed (BLOCKED is fine, silently-skipped is not), check whether
+any bug just filed is High severity on a High-risk dimension (§4) and if so flag it as the
+first line of the summary below, and — only if `OPEN_KNOWN_BUGS` (Phase 1) was non-empty and
+overlapped this card — confirm the `[retest: {BUG-ID}]` test from 3a actually ran and note its
+outcome. This does not block or gate anything — it only makes sure nothing gets buried in the
+summary.
+
+Show the final summary:
 
 ```
 Manual Testing Complete — [CARD_ID]
 
   UI Testing (Figma)  : [completed / skipped]
   Manual Testing      : X Pass | X Fail | X Observation | X Blocked
-  Bug Reporting       : [N] bug(s) filed — [keys]
+  Bug Reporting       : [N] bug(s) filed — [keys] [+ "⚠ High-severity on {dimension}" if applicable]
   Test Charter        : [published URL or "saved locally"]
   Automation hints    : outputs/automation-hints-[CARD_ID]-[YYYYMMDD].md
 ```
@@ -554,3 +627,22 @@ Do NOT stream: full charter text, all test results (save to file), full bug repo
 | Figma URL missing / user says no | Skip UI Testing, note in final summary |
 | `browser_evaluate` returns null for element | Log "element not captured" in hints, continue |
 | Bug creation fails | Note failure, continue with remaining bugs, report at end |
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill manual-testing --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}" \
+  --phase Manual
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).