@roopesh.yadava/qa-pack 1.5.0 → 1.5.1

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,14 @@ 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. |
 
 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
@@ -148,12 +150,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 +252,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,6 +289,7 @@ 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) |
@@ -292,3 +302,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/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
 ```

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

@@ -0,0 +1,200 @@
+# Test Design Guide — Requirement Analysis, Coverage Dimensions, Scenario Framework
+
+Loaded once by the manual-testing skill at Phase 1 (Requirement Analysis). Reference sections
+by number afterward (e.g. "per §2 trigger table") — never re-quote this file in chat or in
+saved reports.
+
+Purpose: manual testing should verify a feature is functionally correct, usable, reliable,
+secure, compatible, and aligned with business expectations — not just that the happy path
+works. This guide operationalizes that without inflating every card into the same fixed
+checklist: coverage is scoped by what the card actually touches (§2) and by risk (§4), so a
+copy-change card and a payment card get proportionally different depth.
+
+---
+
+## §1 — Requirement Gap Checklist
+
+Run once per card, right after Phase 1 fetch, before the test plan is drafted. For each row
+whose signal is present, fold the question into the **one** consolidated gap-question message
+(same message as any Phase 0 gaps — never a second round of questions). Skip a row entirely
+if the AC already answers it — do not manufacture questions on a precise, complete AC.
+
+| Gap type | Signal to look for | Question to ask if missing |
+|---|---|---|
+| No AC at all | Card has no AC/COS section | "No Acceptance Criteria found — what should be tested?" (most severe — if this fires, skip the rest of this table and just ask this) |
+| Ambiguous requirement | Vague terms in AC ("appropriate", "as needed", "similar to", "etc.") | Quote the exact phrase, ask for the precise rule |
+| Missing validation rule | A field/form is named with no stated format or limit | "What's the valid format/limit for {field}?" |
+| Missing negative/error case | AC describes only the happy path, no failure behavior | "What should happen on {plausible failure mode}?" |
+| Missing permission rule | Roles/access mentioned but AC doesn't say who can do what | "Which roles can perform this action?" |
+| Missing boundary condition | A numeric/length limit is implied ("a short code", "a few items") but not exact | "What's the exact min/max for {field}?" |
+| Missing state/workflow rule | A status/workflow field exists but transitions aren't listed | "What are the valid status transitions?" |
+| Missing data relationship | AC needs a specific paired entity (parent+child, account+card) without naming which | Already covered by the skill's Test Data & Entity Selection Rules — ask once or mark `🔒 BLOCKED`, don't duplicate the question here |
+
+---
+
+## §2 — Feature Signal → Coverage Dimension Trigger Table
+
+Scan the card title + AC (already read in Phase 1 — no extra fetching, no grepping `src/`)
+for these signals. A matched signal turns its dimension(s) ON for test-plan generation in
+Phase 3a. Untriggered dimensions are not drafted — this is what keeps test count proportional
+to the card instead of forcing all 19 dimensions onto every run.
+
+| Signal in title/AC | Dimensions turned ON |
+|---|---|
+| login, auth, OTP, session, token, password, logout | Authentication, Security-oriented, State/Workflow (session) |
+| role, permission, admin, restricted, access level | Authorization / Permissions |
+| payment, price, amount, invoice, refund, subscription, billing, calculation | Boundary/Equivalence, Business Rules, Database, Security-oriented |
+| delete, remove, deactivate, cancel, archive | Negative, State/Workflow, Database (soft vs hard delete) |
+| upload, download, attachment, file, import, export | File Upload/Download |
+| search, filter, sort, paginate, list, table, grid | Search/Filter/Sort/Pagination |
+| API, endpoint, integration, webhook, third-party, external service, sync | API, Integration |
+| status, state, workflow, transition, approve, submit, draft, review | State/Workflow |
+| any form or input field named in the AC | Validation, Boundary/Equivalence |
+| notification, email, SMS, push, alert, toast, reminder | Notifications |
+| multi-step flow, wizard, redirect, navigation between screens | End-to-End |
+| *(always on, every card)* | Functional Positive, Functional Negative, UI/UX States |
+
+No specific signal matched → draft Functional (positive + one negative) + UI/UX States + one
+Boundary check only. Do not force File Upload tests on a card with no file field, API tests on
+a pure front-end copy change, etc.
+
+---
+
+## §3 — Coverage Dimension Catalog
+
+What each dimension actually means when drafting a test idea:
+
+- **Functional Positive** — valid input/action produces the documented expected result.
+- **Functional Negative** — invalid input, missing mandatory field, unauthorized action, wrong
+  state transition, or a dependency failure (API/network) is handled without a crash and with
+  a correct, user-facing message.
+- **Boundary/Equivalence** — see §6 templates. Values at/around a stated limit, and one
+  representative value per valid/invalid partition — not exhaustive enumeration.
+- **UI/UX States** — see §8. Initial, loading, empty, success, error, disabled states of the
+  components the card actually touches.
+- **Validation** — mandatory/optional fields, character/numeric limits, special characters,
+  whitespace, duplicate values, invalid format, field interdependencies.
+- **Business Rules** — role-based/status-based/date-based behavior, calculations, eligibility
+  and workflow-transition rules stated in the AC.
+- **Authentication** — valid/invalid credentials, empty credentials, OTP flow, session
+  expiry, logout, token expiration.
+- **Authorization / Permissions** — each distinct role named in the AC gets one test for
+  allowed and one for denied behavior; direct-URL/API access with an unauthorized session
+  should not succeed just because the UI hid the button.
+- **API** (only when the card's flow visibly depends on a request) — correct status code for
+  the scenario (200/201/204 success; 400 invalid; 401 unauthenticated; 403 unauthorized; 404
+  not found; 409 conflict/duplicate; 500 server failure), response shape sanity, not full
+  contract testing.
+- **Database** (only when the UI exposes persisted state) — does the value shown after a
+  reload match what was submitted; does a delete actually remove/soft-remove the record;
+  spot-check only, not a DB audit.
+- **Integration** — cross-system handoff visible from the UI (payment gateway redirect,
+  auth-provider callback, file-storage upload) — verify the round trip completes and failures
+  are surfaced, not the integration's internals.
+- **End-to-End** — the full journey named in the card (e.g. Login → create entity → submit →
+  see it reflected downstream), not just the single screen in the AC.
+- **File Upload/Download** — supported/unsupported type, size limit, empty/corrupted file,
+  duplicate filename, correct downloaded filename/contents.
+- **Search/Filter/Sort/Pagination** — exact match, no-match, empty query, filter
+  combination, clear filters, sort direction, first/last page, empty result page.
+- **Notifications** — correct message, correct recipient/trigger, not duplicated, and (if
+  observable within the run) sent after both success and retry-after-failure.
+- **State/Workflow** — every transition named in the AC, one attempt at an invalid transition,
+  and what the UI shows on reopening/refreshing after a transition.
+- **Security-oriented** (only for high-risk signals in §4) — direct URL access while logged
+  out or as the wrong role, sensitive data not exposed in the URL or in error text, password
+  masked, session actually ends on logout.
+- **Accessibility spot-check** — one keyboard-only pass through the card's critical path
+  (tab order reaches every control, focus is visible, no dead-end). This is a lightweight
+  spot-check, not the full WCAG audit — hand off to the `accessibility-testing` skill if the
+  card needs that level of coverage.
+- **Compatibility** — only when the card explicitly calls out a browser/viewport; otherwise
+  out of scope for a single-card manual run (covered separately, not by default here).
+
+---
+
+## §4 — Risk-Based Depth
+
+| Risk tier | Signals (from §2, or explicit in AC) | Depth |
+|---|---|---|
+| **High** | payment, auth/authz, delete, financial calculation, subscription/billing, critical third-party integration, sensitive data | Each triggered dimension gets 2–3 tests; also add Security-oriented and Database checks even if not explicitly triggered by §2 |
+| **Medium** | ordinary business feature, none of the High signals | Each triggered dimension gets 1–2 tests |
+| **Low** | copy/label/minor UI-only change | Functional (positive + one negative) plus one regression spot-check — nothing else |
+
+This tier decides **how many tests to draft per dimension**. It's separate from the
+`risk-score` toolkit call, which orders the **execution sequence** of whatever was drafted, by
+git churn + known-bug density. Run both — they answer different questions.
+
+---
+
+## §5 — Test Scenario Identification Framework
+
+While turning triggered dimensions into numbered T-01, T-02... ideas, walk these 10 questions
+once — they map straight onto §3's dimensions and stop scenario drafting from stalling out at
+"just the AC's happy path":
+
+1. What can the user do? → Functional Positive
+2. What can the user enter? → Validation, Boundary/Equivalence
+3. What can go wrong? → Functional Negative
+4. What are the limits? → Boundary
+5. Who can perform the action? → Authorization/Permissions
+6. What happens to the data? → Database/API
+7. What happens after the action? → End-to-End, Notifications
+8. What happens when the system fails? → Functional Negative (dependency failure)
+9. What existing functionality could break? → flag for qa-agent's post-phase regression
+   suggestion (Covered Flows overlap) — don't draft duplicate regression tests here
+10. What unusual behavior could a real user perform? → at most one exploratory idea, tagged
+    clearly (`[exploratory]`) so it doesn't inflate the planned-test count
+
+---
+
+## §6 — Boundary & Equivalence Quick Templates
+
+If the AC (or the answer to a §1 gap question) states a numeric/length range `[MIN, MAX]`:
+
+- Full set (High-risk fields — payments, quotas, security limits): `MIN-1` (invalid), `MIN`
+  (valid), `MIN+1` (valid), `MAX-1` (valid), `MAX` (valid), `MAX+1` (invalid) — 6 tests.
+- Collapsed set (Medium/Low-risk, wide range): `MIN` (valid), one mid-range value (valid),
+  `MAX` (valid), one just-out-of-range value (invalid) — 4 tests.
+
+Equivalence partitioning (no exact boundary stated, just a described valid category): one
+representative value below the valid range, one within it, one above it — 3 tests, not an
+enumeration of every possible value.
+
+---
+
+## §7 — Defect Record Fields (Phase 4 payload)
+
+Every bug filed from this skill should carry: Title, Environment, Preconditions, Steps to
+Reproduce, Expected Result, Actual Result, Severity, Priority, Screenshot, Test data used, and
+Build/version (the card ID + run date stands in when the product has no separate build
+number). Severity/Priority derivation stays as defined in the skill's Phase 4 table — this
+section only adds the two fields (Preconditions, Test data used) that weren't previously
+captured.
+
+---
+
+## §8 — State Validation Checklist
+
+For each key screen/component the card's test plan actually reaches, note which of these
+states were observed and their result — skip states that are genuinely unreachable within the
+test rather than forcing them:
+
+Initial · Loading · Empty · Success · Error · Disabled
+
+---
+
+## §9 — Exit Criteria Quick Check
+
+Before handing off to Phase 5 (test charter), confirm:
+
+- Every planned test executed — `🔒 BLOCKED` is an acceptable outcome, a silently skipped test
+  is not.
+- No open Critical/Blocker-severity bug among those just filed goes unmentioned — flag it
+  prominently in the final summary. This pack does not gate the pipeline on it (no release
+  authority here), it only makes sure the flag isn't buried.
+- If the product context's `Known Bugs` table (already loaded in Phase 1) lists a bug on this
+  same flow with a status other than Closed/Done, one retest of that specific bug was included
+  in the plan.
+- The regression suggestion in qa-agent Step 5 runs after this skill returns — nothing to do
+  here, just don't skip past it.