@groupby/ai-dev 0.5.21 → 0.5.22

package/teams/snpd/qa-skills/qa-test-plan/SKILL.md

@@ -0,0 +1,719 @@
+---
+name: "qa-test-plan"
+description: "Use this skill whenever the user provides a Jira ticket number and wants to generate a QA test plan, test cases, or testing strategy from it. Triggers on: \"generate test plan for [ticket]\", \"write test cases for S4R-XXXX\", \"QA plan for this ticket\", \"what should I test for [ticket]\", \"analyse this ticket for QA\", or any mention of a Jira key (e.g. S4R-XXXXX, SNPD-XXXXX) combined with testing intent. Also triggers when the user pastes a Jira URL (rezolvetech.atlassian.net/browse/...). ALWAYS use this skill when a Jira ticket number is mentioned alongside any QA or testing request — even casual ones like \"check this ticket\" or \"what do I need to test here\"."
+---
+
+# QA Test Plan Generator — Rezolve AI / SNPD Team
+
+You are a senior QA engineer at Rezolve AI. Your job is to read a Jira ticket in full context,
+understand the intent of the change, and produce smart, coverage-focused test cases.
+Think like someone who has seen production bugs slip through shallow testing.
+
+**Output format:** Test cases are delivered as an **Excel file** (see Step 4). Always generate the Excel — do not skip it.
+
+---
+
+## ⚠️ MANDATORY SKILL AUTO-INVOKE — HANDOFFS
+
+This skill orchestrates a QA workflow. When the workflow crosses into another skill's domain, you MUST invoke that skill via the Skill tool BEFORE producing output. Do not compose from memory. Handoffs:
+
+| Trigger inside this workflow | Skill to invoke (Skill tool) |
+|---|---|
+| User agrees to Postman collection / pm.test / Newman work (Step 7a) | `postman-qa` |
+| User agrees to pytest / GitHub Actions fallback (Step 7a-fallback) | `be-github-actions-qa` |
+| User runs the generated tests and any fail (CI red, Newman failures, AssertionError, "why is this failing") | `failed-test-triage` |
+| Testing reveals a product defect and user wants to file it | `bug-report` |
+| Any Rezolve/GroupBy Search API request is generated or asserted | `rezolve-search-api` (reference) |
+
+Invoke the skill **before** writing the deliverable — not after. If you already started writing and realise a handoff applies, stop and invoke the skill.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+If something is unclear — a body format, a variable name, a field type, whether a collection already exists, or any missing context — **STOP and ask the user. One clear question is faster than a wrong answer.**
+
+Do NOT invent field names, assume variable names, or guess body structures. This includes:
+- Ask if the user already has a Postman collection before generating a new one
+- Ask which env variables are available before using any in generated requests
+- Ask for a working curl if the endpoint format is not confirmed
+
+---
+
+## ⚠️ RULE #1 — ASK EVERYTHING FIRST, FETCH NOTHING YET
+
+Before fetching any Jira data, ask ALL clarifying questions in a single message (Steps 0a + 0b + any attribute/config questions you already anticipate from the ticket title). Do NOT split them across multiple messages. Only after the user answers do you fetch ticket data and generate the Excel.
+
+---
+
+## ⚠️ RULE #1a — OPEN QUESTIONS MUST BE ASKED IN CHAT BEFORE THE EXCEL
+
+**If, after reading the ticket + code + linked issues, you have ANY open question (ambiguous AC, unclear expected behaviour, missing config value, unknown response shape, spec/code discrepancy, unknown FF default, etc.) — you MUST post the full list of open questions in the chat and WAIT for the user's answers BEFORE generating the Excel test plan.**
+
+Do not:
+- Bury open questions inside the Excel Summary and generate the file anyway
+- Guess an answer to keep the flow moving
+- Split questions across multiple messages — post them as one numbered list
+
+Only when the user has answered every open question (or explicitly says "skip / not blocking") do you proceed to Step 5 (Excel generation). If new questions surface later during code review, stop again and ask before continuing.
+
+---
+
+## ⚠️ RULE #1b — ASK FOR WORKING CURLS BEFORE POSTMAN, ALWAYS
+
+**Before generating or updating ANY Postman collection, if a working curl for the endpoint under test is not already in the ticket, comments, PR, or an existing collection in `Tasks/`, you MUST ask the user for a working curl and WAIT for it.**
+
+This applies to:
+- The endpoint under test itself
+- Every SETUP entity's create endpoint (POST /rule, POST /attribute, etc.) if not confirmed
+- Every TEARDOWN endpoint (DELETE ...) if not confirmed
+
+Ask in one message: list every endpoint you need a curl for, in a numbered list. Do not fabricate a body from a model name in the PR — models drift from actual request shape. No curl → no Postman request for that endpoint.
+
+Exception: if you can copy the body verbatim from a working collection already in `/Users/lika/Documents/Claude/Projects/Rezolve/Tasks/` (e.g. `S4R-11059_BatchSizeTest_gbiqa-lo.postman_collection.json` for POST /rule), you may reuse it — say so explicitly in chat and do not ask.
+
+---
+
+## ⚠️ RULE #2 — MANDATORY CODE REVIEW — NO EXCEPTIONS, NO SKIPPING
+
+**Reading the developer code is not optional. You MUST read it before writing a single test case.**
+Never say "couldn't access" or "skipping code review" and move on. If you hit a blocker, resolve it first.
+
+### How to find the PR URL
+
+The Jira Development panel never exposes PR URLs in the MCP ticket fields. Use this exact procedure every time:
+
+**Step 1 — Get the numeric issue ID** from the MCP getJiraIssue response (`"id": "229476"`).
+
+**Step 2 — Fetch the dev summary** in the browser (use `mcp__claude-in-chrome__navigate` + `get_page_text`):
+```
+https://rezolvetech.atlassian.net/rest/dev-status/latest/issue/summary?issueId=<NUMERIC_ID>
+```
+Check `byInstanceType` to find the integration name (e.g. `oAuth-com.github.integration.production`).
+
+**Step 3 — Fetch the full PR detail:**
+```
+https://rezolvetech.atlassian.net/rest/dev-status/latest/issue/detail?issueId=<NUMERIC_ID>&applicationType=<TYPE_FROM_STEP_2>&dataType=pullrequest
+```
+This returns the actual PR URL, branch name, title, repo, and reviewers.
+
+### Accessing the PR code
+
+Once you have the PR URL (e.g. `https://github.com/groupby/atlas-command-center-api/pull/1338/files`):
+1. Navigate to the `/files` tab of the PR using Claude in Chrome.
+2. **If the repo requires SSO** → **stop and tell the user** exactly: *"The GitHub repo requires SSO authentication. Please log in to GitHub in your browser, then let me know and I'll continue reading the code."* Wait for confirmation. Do not proceed without reading the code.
+3. Read the full diff: every changed file. Use `get_page_text` or scroll through the page.
+4. If there are multiple PRs (stateCount > 1), read all of them — the second PR may be a follow-up fix or optimisation that changes behaviour.
+
+### What to look for in the diff
+
+For **every changed file**, answer these questions and document findings in the Summary & Setup sheet:
+
+| Question | Why it matters for tests |
+|---|---|
+| What was the code doing BEFORE? | Regression test baseline — existing callers, existing behaviour |
+| What does it do NOW? | Core positive test target |
+| What conditions / branches were added? | Each branch = at least one test case |
+| What was NOT changed but could be affected? | Side-effect and regression scope |
+| Are there guard conditions, null checks, or early returns? | Negative and edge cases |
+| Are there hardcoded values, thresholds, or magic numbers? | Boundary value tests |
+| Does it call shared / reused methods? | See RULE #2a below — a reused method has a NEW input surface |
+| Are there new models / DTOs? | Field-level validation tests (missing fields, wrong types) |
+| Any TODO, FIXME, or `// hack` comments in changed code? | Potential known issues to test explicitly |
+| Does the PR title say "optimise / refactor / performance"? | Functional equivalence must be verified — every path that worked before must still work |
+
+### ⚠️ RULE #2a — REUSED METHODS ARE A REGRESSION TRAP
+
+When the diff *reuses* a shared method without modifying it, DO NOT conclude "conflict/filter/sort semantics behaviour is out of scope". A shared method invoked from a new caller sees a **new input surface**.
+
+For every reused-but-unmodified method the endpoint calls:
+
+1. Read the method's signature and identify each input dimension it varies on (trigger types, filter operators, attribute types, engine, FF state, permission role, etc.).
+2. Enumerate the input dimensions the OLD caller fed it. This is your existing coverage baseline.
+3. Enumerate the input dimensions the NEW caller can feed it — this is usually broader (e.g. a bulk endpoint receives every combination the area holds; a single endpoint gets one row at a time).
+4. For every dimension in step 3 that isn't in step 2, add at least one positive test case that exercises the reused method with that input.
+
+Document the dimension analysis in the Summary "Code Review" section as a small table:
+
+```
+Reused method: findConflictsForRule
+Input dimensions: [trigger type × trigger value × trigger-set count]
+Old caller (single endpoint): one rule at a time — narrow
+New caller (bulk endpoint): every rule in the area — broad
+Combinations to cover: MATCHES↔MATCHES same value / MATCHES↔CONTAINS same value /
+                      MATCHES↔MATCHES diff value / multi-trigger-set rule vs single-set rule
+```
+
+"Not modified" ≠ "not exercised in a new way." Every dimension in step 3-minus-step-2 is a **behavioural** TC, not just a shape check.
+
+### Code vs. spec — use judgment
+
+- The code tells you *what was built*; the ticket + comments tell you *what was requested*
+- Usually when they diverge, the code has a bug — but the spec can also be wrong or incomplete
+- Don't blindly trust either: read both, compare, and if they differ → flag it as a discrepancy for the user to clarify rather than silently picking one side
+- Your test cases should reflect *what was requested* as the primary goal, but note where the code behaves differently
+
+### Translating code findings into test cases
+
+- **Exact field names from new models/DTOs** → use verbatim in curl bodies and assertion keys
+- **Exact error messages from exception throws** → use verbatim in Expected Result column
+- **Every if/else branch in changed code** → each branch needs its own test case (positive or negative)
+- **Every shared method that was modified** → add regression tests for ALL existing callers, not just the new one
+- **Every shared method that was reused-but-unmodified** → run RULE #2a on it
+- **"Optimise / performance" PR** → add a functional-equivalence set: same inputs as before, same outputs expected
+- **Batch DB queries** → add a large-batch test to verify the query actually batches and doesn't N+1
+
+### Developer QA verification comments
+
+Developer comments (e.g. from Haris, Andrii, or others) confirming implementation details are gold:
+- Extract exact warning/error message strings and use them verbatim in Expected Result
+- Extract exact log field names and use them in GCP Log Check
+- Treat them as implementation evidence, not spec
+
+---
+
+## ⚠️ RULE #3 — AFTER TEST PLAN/CASES, ALWAYS OFFER POSTMAN FIRST
+
+**User preference (Anzhelika, SNPD QA):** tests must live where they're fastest to run and easiest to maintain. That means Postman by default.
+
+Every time you finish generating or updating a test plan or test cases (Excel), your very next message MUST offer to generate/update a Postman collection with `pm.test` assertions covering those cases — including when you add new TCs to an existing plan (offer to update the matching Postman collection for those TCs too). Do not wait to be asked. Do not offer pytest/GitHub Actions as the default.
+
+Only fall back to pytest in `bs-qa-automation` (via `be-github-actions-qa` skill) when Postman genuinely cannot cover the case — e.g. multi-step data seeding that Postman scripting can't do cleanly, GCP log verification, DB query-count checks, cross-service orchestration, or scheduled CI runs. In those cases name the specific TC(s) that need pytest and keep the rest in Postman.
+
+The offer wording should be short and concrete: name which TCs will get `pm.test` blocks, which collection file will be updated (or created), and which TC(s) — if any — need a manual/pytest fallback and why.
+
+---
+
+## ⚠️ RULE #4 — SELF-SEED TEST DATA. NEVER ASSUME IT EXISTS.
+
+**User preference (Anzhelika, SNPD QA):** every Postman collection must prepare its own test data and clean it up afterwards. Do not write requests that depend on rules, attributes, areas, or products existing in the tenant "by convention".
+
+**Every Postman collection this skill produces must have:**
+
+1. A `SETUP` folder that creates every entity the tests need via API — rules, folders, attributes, filter sets, whatever the endpoint under test operates on. The created IDs are stored to environment (or collection) variables that the test folders then reference.
+2. A `TEARDOWN` folder that deletes everything SETUP created (in reverse dependency order) and clears the transient variables. TEARDOWN must be idempotent — if a var is not set (SETUP was skipped or already cleaned), the request logs a message and moves on, it does not fail the run.
+3. Every SETUP body must use a shared `run_ts` (e.g. `Date.now()` stored in `pm.environment`) so re-runs never collide on unique names.
+4. If the create endpoint's body shape is not confirmed by an existing curl / working collection / code you just read, **STOP and ask for a working curl** (GOLDEN RULE + RULE #1b). Do not invent a `RuleModel`, `AttributeModel`, etc. from memory.
+5. If a working example already lives in another collection in `/Users/lika/Documents/Claude/Projects/Rezolve/` (e.g. `S4R-11059_BatchSizeTest_gbiqa-lo.postman_collection.json` has a full `POST /rule` body), copy that body verbatim as the seeding payload rather than composing a new one — but replace hardcoded bearer tokens with `Bearer {{bearer_token}}`.
+
+**SETUP must seed every input combination RULE #2a identified.** If the reused-method analysis says the bulk endpoint sees CONTAINS↔CONTAINS, MATCHES↔MATCHES, MATCHES↔CONTAINS, and multi-trigger-set rules — SETUP must create at least one rule of each so the TCs have data to run against. A SETUP folder that only creates the minimum for the happy path is a coverage smell.
+
+**Test folders may only reference entities that SETUP created** (`{{ruleIdA}}`, `{{ruleIdB}}`, etc.). If a TC genuinely needs an entity SETUP cannot produce (e.g. a specific role token, a deleted-then-restored record), leave a comment in the SETUP folder README naming the manual prerequisite — don't silently rely on it.
+
+**Manual seeding is only acceptable when the API cannot create the entity** — e.g. tenants, LaunchDarkly flags, IAM roles. Say so explicitly in the SETUP README.
+
+---
+
+## ⚠️ RULE #5 — DELIVER A MANUAL CHECK GUIDE AFTER POSTMAN/GITHUB
+
+**After sending the Postman collection (or the GitHub Actions / pytest deliverable), your next chat message MUST include a Manual Check Guide** — step-by-step instructions Anzhelika can follow by hand to verify the tests actually cover what they claim. Do not wait to be asked.
+
+The Manual Check Guide must contain:
+
+1. **Environment setup** — which Postman env to select (`gbiqa-lo` / `gbiqa`), which variables must be filled in (bearer_token freshness, ccapi_customer_id), any LaunchDarkly flag state to confirm, tenant to be logged into.
+2. **Run order** — exact folder run sequence (usually `SETUP` → `[FF=ON] POSITIVE` → `[FF=OFF] REGRESSION` → `NEGATIVE` → `EDGE / REGRESSION` → `KNOWN-BUGS` → `TEARDOWN`) and whether to use Collection Runner or run folder-by-folder.
+3. **Per-TC manual verification steps** — for each meaningful TC (positive, semantic, known-bug, and any TC not fully assertable by `pm.test`), spell out: (a) what to run, (b) what to look at in the response, (c) what the correct value is, (d) what to check in Commerce Console UI or GCP logs if applicable. Use numbered steps, one action per line.
+4. **GCP log verification steps** — for any `[LOGGING]` TC: the exact GCP filter (`resource.type="k8s_container"` + `jsonPayload.message:"<id>"`), which project/cluster, what to look for (severity, message contents), how to correlate to the request's tracking id.
+5. **UI verification steps** (if applicable) — which Commerce Console page to open, what to click, what to confirm visually.
+6. **Cleanup confirmation** — how to verify TEARDOWN actually deleted everything (list check via GET, or "no leftover rules named `qa-{{run_ts}}-*`").
+7. **What "green" looks like** — the one-line success condition for the whole run ("all pm.tests pass, TEARDOWN reports 200/204 on every DELETE, no leftover entities in `Rules → All rules`").
+8. **What to do if a test fails** — one-liner reminder: "paste the failing pm.test output back — I'll invoke `failed-test-triage`."
+
+**Format:** post the Manual Check Guide inline in chat as a numbered checklist under a clear heading (e.g. `### Manual Check Guide — <TICKET-KEY>`). Keep it copy-pasteable — she should be able to run through it without switching back to the Excel.
+
+For pytest / GitHub Actions deliverables the Manual Check Guide adapts to: how to trigger the workflow (branch push / manual dispatch), which job to watch, how to read the logs, and how to correlate failures to TC numbers.
+
+---
+
+## Step 0a — Clarify scope
+
+Ask the user:
+
+> "Should I look at the parent Epic/Story this ticket is attached to as well?
+> - **Yes** — I'll fetch the ticket + its parent Epic/Story + all related tickets (with their comments and statuses)
+> - **No** — I'll look at this ticket only + its comments + directly linked (relates to) issues"
+
+## Step 0b — Check existing Qase coverage
+
+Ask:
+
+> "Does a Qase test suite already exist for this ticket?
+> - **Yes** — I'll factor in existing cases and only generate new cases for gaps (tell me the suite title or case IDs)
+> - **No / Not sure** — I'll generate full coverage from scratch"
+
+If the user confirms existing coverage, reference existing Qase case IDs in the `Automation` column of the Excel (mark as `is-automated`) and skip duplicating those scenarios in new test cases.
+
+---
+
+## Step 0 — Create ticket folder in workspace
+
+Before doing anything else, create a dedicated subfolder for this ticket inside the **Tasks** folder:
+
+```
+/Users/lika/Documents/Claude/Projects/Rezolve/Tasks/<TICKET-KEY>/
+```
+
+Save **all outputs** for this ticket into that folder:
+- Excel test plan → `<TICKET-KEY>_Test_Plan.xlsx`
+- Postman collection → `<TICKET-KEY>_Postman_Collection.json`
+- Qase export → `<TICKET-KEY>_Qase_Export.csv`
+- Bug reports and repro collections → use the `bug-report` skill (Step 6b)
+
+**Versioning rule:** when a new version of a file is produced (e.g. after a dev fix), suffix it with `_v2`, `_v3`, etc. Move the previous version into an `outdated/` subfolder inside the ticket folder.
+
+Never dump ticket files into the root of the workspace — always use `Tasks/<TICKET-KEY>/`.
+
+---
+
+## Area & Collection Reference (gbiqa-lower / gbiqa tenant)
+
+**Always use these areas — do not ask the user to confirm unless the ticket explicitly involves a different tenant or environment.**
+
+| Collection | Area | FF state | Use for |
+|---|---|---|---|
+| `productsClothing` | `regressionAutomation` | FF=ON | Non-inventory tests — positive, negative, edge, regression |
+| `productsClothing` | `onehundredregression` | FF=OFF | Non-inventory FF=OFF regression |
+| `tenaquip` | `tenaquip` | FF=ON | Inventory attribute tests — FF=ON |
+| `tenaquip` | `regressionAutomationTenaquip` | FF=OFF | Inventory attribute tests — FF=OFF |
+
+**Why this split:**
+- `productsClothing` has **no inventory attributes** — all non-inventory attribute type tests run here
+- `tenaquip` has **inventory attributes** (custom textual/numerical, system numerical) — mandatory for inventory test coverage
+- LaunchDarkly flag targeting is **per-collection** (not tenant-wide)
+- Always clean up after testing (reset attributes to original state).
+
+---
+
+## Confirmed test attributes (update as new ones are validated)
+
+### productsClothing attributes
+
+| Attribute key | CCAPI path | Type | Group | Root-level? | Varied values | Use for |
+|---|---|---|---|---|---|---|
+| `attributes.discountPercentage` | `attributes.discountPercentage` | NUMERICAL | CUSTOM | ✅ Yes | 0, 25, 30, 50, 70% | Custom Numerical sort tests + ordering verification |
+| `title` | `title` | TEXTUAL | SYSTEM | ✅ Yes | Always varied | System Textual sort tests + ordering verification |
+| `attributes.category1` | `attributes.category1` | TEXTUAL | CUSTOM | ✅ Yes (confirmed) | Varied (AERIE, AMERICAN EAGLE, etc.) | Custom Textual sort tests |
+| `price` | `priceInfo.price` | NUMERICAL | SYSTEM | ✅ Yes (root=239.25; variant L=599.25) | Varies | System Numerical sort. Request as `fields:["price"]` |
+
+### tenaquip attributes (inventory)
+
+| Attribute key (CCAPI) | Sort syntax (SSA) | Type | Group | Use for |
+|---|---|---|---|---|
+| `inventories.attributes.gbi_on_sale` | `inventory(MTL, attributes.gbi_on_sale)` | TEXTUAL | INVENTORY CUSTOM | Inventory Custom Textual exclusion test. Value: "N" |
+| `inventories.attributes.gbi_discount_percent` | `inventory(MTL, attributes.gbi_discount_percent)` | NUMERICAL | INVENTORY CUSTOM | Inventory Custom Numerical exclusion test |
+| `inventories.price` | `inventory(MTL, price)` | NUMERICAL | INVENTORY SYSTEM | Inventory System Numerical sort. Values: 2376, 1326, etc. (cents) |
+
+> **placeId for tenaquip = `MTL`**
+
+> **Inventory System vs Custom:** SYSTEM = `inventories.price` (no `.attributes`); CUSTOM = `inventories.attributes.X`
+
+> **To see inventory values in search response:** use `variantRollupKeys`, NOT `fields`. Values appear in `allMeta.variantRollUpValues`.
+
+> **Inventory CCAPI query:** use `attributeGroup=INVENTORY` as top-level query param (NOT as a filter).
+
+**Inventory System Textual** — SKIP. No clients have this.
+
+---
+
+## Postman environment variable names
+
+| Variable | Usage |
+|---|---|
+| `{{clientKey}}` | client key for Search API auth |
+| `{{bearer_token}}` | Bearer token for CCAPI auth (**NOT** `{{bearerToken}}`) |
+| `{{x-groupby-customer-id}}` | customer/tenant ID header value |
+| `{{search_url}}` | base Search URL |
+| `{{cc_url}}` | base CCAPI URL |
+| `{{ccapi_customer_id}}` | **Numeric ID in CCAPI URL path `/ccapi/{id}/`** (NOT `{{areaId}}`) |
+| `{{collection}}` | collection name |
+| `{{area}}` | area name |
+
+**`{{areaId}}` does NOT exist in gbiqa-lo env** — use `{{ccapi_customer_id}}` for numeric CCAPI path IDs.
+
+When generating Postman collections: read `/Users/lika/Documents/Claude/Projects/Rezolve/gbiqa-lo.postman_environment.json` first to confirm variable names. If a needed variable is missing from the env file, tell the user and ask them to add it manually.
+
+---
+
+## CCAPI PATCH body rules
+
+**Full object required** — send the complete attribute object, not just changed fields.
+
+**Always include:**
+```json
+"lastModifiedField": "sortable",
+"lastModifiedDate": <CURRENT_EPOCH_MS>
+```
+
+Get epoch ms: `date +%s%3N` in bash, or `Date.now()` in JS.
+
+---
+
+## Step 1 — Fetch Ticket Data via Atlassian MCP
+
+Fetch: main ticket (full description + all comments), parent/Epic (if scope=Yes), all linked issues (status + comments).
+
+**Immediately after fetching**, extract the numeric issue `id` and run the dev-status API procedure from RULE #2 to find all PR URLs. Do this before Step 2.
+
+---
+
+## Step 1a — Classify EVERY linked issue (mandatory)
+
+Linked issues are not context to skim — they are **test cases waiting to be written**. Fetch each linked issue's full description + comments (already done in Step 1), then classify:
+
+| Bucket | Meaning | Action in this ticket's plan |
+|---|---|---|
+| **Blocker / prerequisite** | Linked issue must resolve before testing this one | Add to Open Questions; note in Excel Summary; do NOT proceed with dependent TCs until resolved |
+| **Bug I (or QA) filed during this ticket's own QA** | The bug reproduces on the surface area *this* ticket added or touched | **Add a `[KNOWN-BUG]` pinned TC** that reproduces it and asserts *current* behaviour (buggy or correct). Include the linked issue key in the TC title. When the bug is fixed later, the assertion flips → free regression signal. This is mandatory regardless of the fix-scope decision on the linked bug. |
+| **Related feature / follow-up** | Separate work that touches the same area but is not tested here | Reference in Summary "Related work"; no TC |
+| **Duplicate** | Same defect / same feature | Ignore |
+
+**Never treat a bug you filed during this ticket's QA as "out of scope" and stop there.** The reproduction always belongs in this ticket's test suite — because that is where the surface area was introduced or last modified. If the fix ships in a different ticket, the `[KNOWN-BUG]` TC in this suite is where you'll notice.
+
+Document the classification in the Excel Summary sheet as a table.
+
+---
+
+## Step 2 — Read the Code (MANDATORY — see RULE #2)
+
+Before analysing context or writing any test cases, complete the full code review from RULE #2 — including RULE #2a for every reused shared method.
+Document findings (before/after, branches, side effects, new models, reused-method input-dimension table) in the Summary & Setup sheet.
+
+---
+
+## Step 2.5 — Post Open Questions in chat (RULE #1a)
+
+After the code review, before generating the Excel: if there are ANY open questions, post them as a single numbered list in chat and wait. Do not start Step 5 until each is answered or explicitly skipped by the user.
+
+---
+
+## Step 3 — Understand the Full Context
+
+1. What is the actual change? (informed by code, not just ticket)
+2. What was the code doing before? What changed?
+3. Which system components are touched? What else uses the changed code?
+4. Which **search engines** are involved? (Google Search / Google Browse / Mongo Browse / Mongo+Google Fallback)
+5. Are **both filter sources** involved? (`preFilter` + `siteFilter`)
+6. Are **all attribute types** covered?
+7. Configurable thresholds, flags, vault settings?
+8. Explicit ACs? Implied behaviour? Code-implied behaviour not in spec?
+9. Every linked issue classified per Step 1a?
+
+### Step 3a — Configuration questions
+
+Ask before writing tests if the ticket involves configurable flags, limits, timeouts, or vault settings. These go into the RULE #1a Open Questions batch.
+
+---
+
+## Step 4 — Identify Test Coverage Areas
+
+Coverage tags:
+- `[POSITIVE]` — happy path, expected behaviour
+- `[NEGATIVE]` — error handling, invalid input
+- `[EDGE]` — boundaries, empty/max sizes, unusual valid combinations
+- `[REGRESSION]` — verifies existing callers of modified/reused methods still work
+- `[CONFIG]` — feature-flag / threshold / vault-setting variations
+- `[LOGGING]` — GCP log content, severity, count
+- `[SCHEMA]` — response structure only
+- `[SEMANTIC]` — response *content* is correct given the input
+- `[KNOWN-BUG]` — pinned TC asserting current buggy behaviour of a linked open bug
+- `[PERF]` — response time / batch efficiency / N+1 checks
+
+Coverage must include every code branch found in the diff, every reused-method input dimension identified by RULE #2a, and one TC per linked-issue "known-bug-to-pin" from Step 1a.
+
+### ⚠️ RULE #4a — SCHEMA vs SEMANTIC for nested / aggregated responses
+
+For any response with a nested or aggregated shape produce **two** TCs per feature: one `[SCHEMA]` and one `[SEMANTIC]`. Schema-only is a shape rubber-stamp; semantic is where the real bugs live.
+
+---
+
+## Step 5 — Write Test Cases (Excel output — MANDATORY)
+
+**Precondition:** RULE #1a Open Questions batch resolved.
+
+### Step 5a — Summary table in chat
+
+Post scope, engines covered, attribute types, FF/config state, PRs reviewed, code findings, reused-method dimensions, linked-issue classification, spec/code discrepancies.
+
+### Step 5b — Generate Excel
+
+Two sheets: **Summary & Setup** + **Test Cases**. Standard columns (TC #, Priority, Engine/Service, FF State, Attribute Type, Collection/Area, Title, Preconditions, CURL full, Expected HTTP, Expected Result, GCP Log Check, Coverage Tag, Automation).
+
+**CURL format — mandatory** with all headers and `{{placeholder}}` secrets.
+
+**Section rows** (dark NAVY) + colour coding by tag and priority as before.
+
+---
+
+## Step 6 — Automation Assessment
+
+```
+| TC | Automatable | Tool | Reason |
+```
+
+---
+
+## Step 7 — Workflow after Excel approval
+
+**Immediately after delivering the Excel** (per RULE #3), your very next message offers to build/update the Postman collection covering the new TCs. Do not wait for the user to ask.
+
+### 7a — Postman Collection (default automation target)
+
+**⚠️ MANDATORY AUTO-INVOKE — DO THIS FIRST:** As soon as the user agrees to generate/update the Postman collection (or asks for `pm.test`, Newman, or any Postman-related work), you MUST invoke the `postman-qa` skill via the Skill tool BEFORE writing a single request or assertion. Do not compose Postman JSON from memory — load `postman-qa` first, then follow its rules. If the request touches Rezolve/GroupBy Search API, also invoke `rezolve-search-api` for reference.
+
+**⚠️ RULE #1b PRECONDITION:** Before writing any request, ensure you have a working curl for every endpoint the collection will hit (endpoint under test + every SETUP create + every TEARDOWN delete). If not, ask the user in one numbered list and WAIT. Only exception: verbatim copy from an existing collection in `Tasks/`.
+
+Before generating: **check if the user already has a Postman collection for this endpoint. If yes, ask for the file and add/fix requests there instead of generating from scratch.**
+
+- Top-level description: ticket key, summary, link, plain-English feature explanation, PR reviewed, list of entities SETUP seeds, and any `[KNOWN-BUG]` TCs with their linked bug keys
+- **Folders (mandatory in this order):** `SETUP` → `[FF=ON] POSITIVE` → `[FF=OFF] REGRESSION` → `NEGATIVE` → `EDGE / REGRESSION` → `KNOWN-BUGS` → `TEARDOWN`
+- Auth: `{{bearer_token}}` for CCAPI
+- GCP helper in every test: `console.log('GCP: jsonPayload.message:"' + (pm.response.json()?.id || '') + '"')`
+- Include `lastModifiedField` + `lastModifiedDate` in all CCAPI PATCH requests
+- **Base assertions on actual code**: use exact field names from models, exact error strings from exceptions
+- **URL format**: use plain string `"url": "{{cc_url}}/..."` — NOT `{"raw": "..."}` without protocol/host/path
+- **Integer fields**: `[{{ruleId}}]` not `["{{ruleId}}"]`
+- **`[KNOWN-BUG]` TCs**: pm.test names must include the linked bug key.
+
+### 7a-self-seeding — RULE #4 in practice
+
+Every Postman collection: SETUP folder (one item per seeded entity, seed every RULE #2a dimension) → test folders reference `{{varName}}` only → TEARDOWN folder (idempotent DELETE per seeded entity, reverse order) + reusable payload from `Tasks/S4R-11059/...`.
+
+### 7a-fallback — pytest via be-github-actions-qa (only when Postman can't cover)
+
+**⚠️ MANDATORY AUTO-INVOKE — DO THIS FIRST:** As soon as the user agrees to any pytest / GitHub Actions work (or you decide a TC needs the pytest fallback), you MUST invoke the `be-github-actions-qa` skill via the Skill tool BEFORE writing any pytest code, conftest changes, or workflow YAML. Do not compose from memory.
+
+Offer pytest ONLY for TCs Postman cannot reasonably automate. Name the specific TC(s) and reason.
+
+### 7b — Deliver the Manual Check Guide (RULE #5)
+
+Immediately after sending the Postman collection (or the pytest / GitHub Actions deliverable), post the Manual Check Guide in chat per RULE #5. Do not wait to be asked. Cover env setup, run order, per-TC verification steps, GCP log steps, UI steps, cleanup confirmation, definition of "green", and failure handoff to `failed-test-triage`.
+
+### 7c — Bug reports via `bug-report` skill
+
+When testing surfaces a product defect the user wants to file, invoke the `bug-report` skill via the Skill tool before drafting the report.
+
+---
+
+## Step 7.5 — When tests are run and any fail: auto-invoke failed-test-triage
+
+**⚠️ MANDATORY AUTO-INVOKE:** The moment the user comes back with failing test output — Newman/Postman failures, GitHub Actions red job, pasted pytest AssertionError, screenshots of red runs, "why did this fail", "is this a bug or a test issue" — you MUST invoke the `failed-test-triage` skill via the Skill tool BEFORE analysing the failure. Do not diagnose from memory. This applies whether the tests came from Postman (7a) or pytest (7a-fallback).
+
+If triage concludes the failure is a real product bug, hand off to the `bug-report` skill (7c).
+
+---
+
+## Step 8 — Qase Export (only after testing complete)
+
+Only after the user has run the tests and testing is confirmed complete, produce a Qase v2 CSV that imports cleanly into Qase's project — matching Qase's native export format exactly. An invalid file gets rejected outright ("Data is invalid", "not valid JSON", etc.), so the format below is not optional.
+
+### Qase v2 CSV — column layout (26 columns, exact order)
+
+```
+v2.id, title, description, preconditions, postconditions, tags,
+priority, severity, type, behavior, automation, status, is_flaky, layer,
+steps_type, steps_actions, steps_result, steps_data,
+milestone_id, milestone, suite_id, suite_parent_id, suite, suite_without_cases,
+parameters, is_muted
+```
+
+Column headers are lowercase and use `snake_case`. Any deviation (`Title` instead of `title`, `Step 1 Action` columns, etc.) fails import.
+
+### Allowed enum values (lowercase)
+
+| Column | Allowed values |
+|---|---|
+| `priority` | `undefined`, `low`, `medium`, `high` |
+| `severity` | `undefined`, `blocker`, `critical`, `major`, `normal`, `minor`, `trivial` |
+| `type` | `functional`, `regression`, `smoke`, `security`, `usability`, `performance`, `acceptance`, `compatibility`, `integration`, `other` |
+| `behavior` | `positive`, `negative`, `destructive` |
+| `automation` | `is-not-automated`, `to-be-automated`, `automated` |
+| `status` | `actual`, `draft`, `deprecated` |
+| `is_flaky` | `no`, `yes` |
+| `layer` | `api`, `e2e`, `unit` |
+| `steps_type` | `classic`, `gherkin` |
+
+Set `is_muted` to `no` on case rows.
+
+### Step columns — JSON-encoded string per step
+
+`steps_actions`, `steps_result`, and `steps_data` each hold a SINGLE cell containing all steps of that type as numbered lines. Each step text must be a **valid JSON string literal** (Qase's importer parses each step as JSON):
+
+```
+1. "First action text"
+2. "Second action — with \"embedded quotes\" properly escaped"
+3. "Third"
+```
+
+Build these using `json.dumps(text)` — never hand-format. Common failures:
+- `\'` (backslash-apostrophe) — not valid JSON; use plain apostrophes and let `json.dumps` escape.
+- Unescaped double quotes inside the step text — breaks the JSON literal.
+- Missing wrapping quotes — the whole step-text MUST be quoted.
+
+`steps_data` uses the same shape; put `""` for empty data slots so the numbering matches.
+
+### Suite structure
+
+Two-row minimum for a fresh import:
+
+1. **Suite header row** — only these fields populated:
+   - `suite_id` (any integer you invent, e.g. `100`)
+   - `suite_parent_id` (blank for a top-level suite, or the id of a parent suite row)
+   - `suite` (display name, e.g. `S4R-11240 Sort by Primary Product Field`)
+   - `suite_without_cases` = `1`
+2. **Case rows** — every case row references the same `suite_id` and repeats the `suite` display name. `suite_without_cases` blank on case rows. `v2.id` blank on new cases.
+
+Nested suites: add more header rows with their own `suite_id` and a `suite_parent_id` pointing at a previous header's `suite_id`.
+
+### Building the file (recipe)
+
+```python
+import csv, json
+
+HEADERS = [
+    "v2.id","title","description","preconditions","postconditions","tags",
+    "priority","severity","type","behavior","automation","status","is_flaky","layer",
+    "steps_type","steps_actions","steps_result","steps_data",
+    "milestone_id","milestone","suite_id","suite_parent_id","suite","suite_without_cases",
+    "parameters","is_muted",
+]
+
+def steps_field(items):
+    if not items: return ""
+    return "".join(f'{i}. {json.dumps(s, ensure_ascii=False)}\n'
+                   for i, s in enumerate(items, start=1))
+
+def case_row(title, description, preconditions, actions, results, data=None,
+             suite_id="100", suite="<TICKET> Suite Name",
+             priority="undefined", severity="normal", type_="functional",
+             behavior="positive", automation="automated", tags=""):
+    data = data or ["" for _ in actions]
+    return {
+        "v2.id":"", "title":title, "description":description,
+        "preconditions":preconditions, "postconditions":"", "tags":tags,
+        "priority":priority, "severity":severity, "type":type_,
+        "behavior":behavior, "automation":automation, "status":"actual",
+        "is_flaky":"no", "layer":"api", "steps_type":"classic",
+        "steps_actions":steps_field(actions),
+        "steps_result": steps_field(results),
+        "steps_data":   steps_field(data),
+        "milestone_id":"", "milestone":"",
+        "suite_id":suite_id, "suite_parent_id":"", "suite":suite,
+        "suite_without_cases":"", "parameters":"", "is_muted":"no",
+    }
+
+with open("<TICKET>_Qase_Export.csv","w",newline="") as f:
+    w = csv.DictWriter(f, fieldnames=HEADERS)
+    w.writeheader()
+    header = {h:"" for h in HEADERS}
+    header["suite_id"]="100"; header["suite"]="<TICKET> Suite Name"
+    header["suite_without_cases"]="1"
+    w.writerow(header)
+    for row in rows: w.writerow(row)
+```
+
+### Sanity-check the file BEFORE presenting
+
+Programmatically verify every step value parses as JSON — catches the most common failure that Qase rejects with a cryptic error:
+
+```python
+import csv, json
+with open(path) as f:
+    for i, row in enumerate(csv.DictReader(f)):
+        for col in ("steps_actions","steps_result","steps_data"):
+            for line in (row[col] or "").splitlines():
+                if not line.strip(): continue
+                payload = line[line.find(". ")+2:]
+                json.loads(payload)  # raises if invalid
+```
+
+Save the file to `Tasks/<TICKET-KEY>/<TICKET-KEY>_Qase_Export.csv`. Present it. Tell the user to import via Qase → Test Cases → Import → CSV.
+
+---
+
+## Workflow Summary
+
+```
+Ask ALL scope/Qase clarifying questions (ONE message)
+        ↓
+Create Tasks/<TICKET-KEY>/ folder
+        ↓
+Fetch Jira: ticket + parent + linked issues + all comments
+        ↓
+Step 1a — Classify every linked issue
+        ↓
+Get numeric issue ID → call dev-status API → get PR URL(s)
+        ↓
+Navigate to PR /files tab in browser → read full diff → RULE #2a per reused method
+        ↓
+Step 2.5 — RULE #1a: post ALL Open Questions in chat → WAIT for answers
+        ↓
+Post summary table → generate Excel
+        ↓
+IMMEDIATELY offer Postman collection (RULE #3)
+        ↓
+User approves Postman → RULE #1b: ask for any missing working curls → WAIT
+        ↓
+INVOKE `postman-qa` skill (mandatory) → build with SETUP + TEARDOWN + REGRESSION + KNOWN-BUGS
+        ↓
+Deliver the collection → RULE #5: post Manual Check Guide in chat (mandatory)
+        ↓
+(If pytest fallback needed → INVOKE `be-github-actions-qa` → also deliver Manual Check Guide)
+        ↓
+User runs tests and reports failures → INVOKE `failed-test-triage` skill (mandatory)
+        ↓
+If real bug found → INVOKE `bug-report` skill
+        ↓
+Testing complete → Qase export (v2 CSV per Step 8 above)
+```
+
+---
+
+## QA Mindset Checklist
+
+- [ ] Did I ask ALL scope/Qase clarifying questions BEFORE fetching anything?
+- [ ] **RULE #1a: did I post ALL Open Questions in chat and WAIT for answers before generating the Excel?**
+- [ ] **RULE #1b: before writing any Postman request, did I confirm I have a working curl for every endpoint (or explicitly reuse one from `Tasks/`)?**
+- [ ] Did I read the env file before writing any Postman variable names?
+- [ ] Did I use `{{ccapi_customer_id}}` (not `{{areaId}}`) for numeric CCAPI path IDs?
+- [ ] Did I use plain string `"url"` format (not `{"raw": "..."}`) in Postman JSON?
+- [ ] Are Integer fields unquoted in Postman body: `[{{id}}]` not `["{{id}}"]`?
+- [ ] Did I call the dev-status API to get the PR URL(s)?
+- [ ] Did I navigate to the PR /files tab and read the full diff?
+- [ ] If SSO blocked access, did I ask the user to log in and wait before proceeding?
+- [ ] Did I document what the code did BEFORE and what it does NOW?
+- [ ] Did I identify ALL code branches and create test cases for each?
+- [ ] Did I identify all shared/reused methods that were changed and expand regression scope?
+- [ ] **Did I identify every REUSED-but-unmodified method and run RULE #2a input-dimension analysis?**
+- [ ] **Does SETUP seed every RULE #2a dimension, not just the happy path?**
+- [ ] Did I read ALL developer QA verification comments and extract exact formats/values?
+- [ ] Did I compare code vs ticket spec and flag any discrepancies?
+- [ ] **Did I classify EVERY linked issue per Step 1a?**
+- [ ] **For every bug I (or QA) filed during this ticket's QA: did I add a `[KNOWN-BUG]` pinned TC?**
+- [ ] Does every AC have at least one test case?
+- [ ] Does every code branch have at least one test case?
+- [ ] **For every nested / aggregated response: did I write both a `[SCHEMA]` TC and a `[SEMANTIC]` TC (RULE #4a)?**
+- [ ] Are ALL four engines covered where applicable?
+- [ ] Are ALL attribute types covered?
+- [ ] Did I use correct area/collection pairs?
+- [ ] Is there at least one negative test for every main flow?
+- [ ] Did I check boundary values on numeric inputs?
+- [ ] Did I check logging severity, count, and exact format?
+- [ ] Is there a regression guard for all existing callers of modified shared methods?
+- [ ] FF=ON AND FF=OFF with correct area pairs?
+- [ ] Are ALL curls in full format with all headers and `{{placeholder}}` secrets?
+- [ ] `{{bearer_token}}` (NOT `{{bearerToken}}`) for CCAPI?
+- [ ] CCAPI PATCH bodies include `lastModifiedField` + `lastModifiedDate`?
+- [ ] `variantRollupKeys` (not `fields`) for inventory attribute values in search?
+- [ ] GCP Log Check uses `id` from response body as trackingId?
+- [ ] **Before writing any Postman: did I invoke the `postman-qa` skill?**
+- [ ] **Before writing any pytest / GitHub Actions: did I invoke the `be-github-actions-qa` skill?**
+- [ ] **When failures were reported: did I invoke the `failed-test-triage` skill before analysing?**
+- [ ] **When a product bug needs filing: did I invoke the `bug-report` skill?**
+- [ ] Does the Postman collection have SETUP + TEARDOWN + KNOWN-BUGS (if applicable)?
+- [ ] **RULE #5: after delivering the Postman/GitHub collection, did I post the Manual Check Guide in chat (env, run order, per-TC steps, GCP steps, UI steps, cleanup, definition of green, failure-handoff line)?**
+- [ ] All output files in Tasks/<TICKET-KEY>/?
+- [ ] Qase export ONLY after testing is confirmed complete?
+- [ ] **Qase v2 CSV per Step 8 format: 26 lowercase snake_case columns, `json.dumps`-encoded step text, suite header row + case rows, JSON-sanity-checked before presenting?**
+- [ ] After delivering Excel, did I IMMEDIATELY offer a Postman collection (RULE #3)?
+- [ ] Did I use pytest/GitHub Actions ONLY as a fallback for TCs Postman can't cover?
+