@groupby/ai-dev 0.5.21 → 0.5.22

package/teams/snpd/qa-skills/postman-qa/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: "postman-qa"
+description: "Use this skill when writing, fixing, or debugging Postman collections, requests, or pm.test scripts against Rezolve/GroupBy APIs (CCAPI or Search API). Triggers on: 'write a Postman collection', 'add pm.test', 'fix this pm.test', 'my Postman request fails', 'write a test script for this endpoint', 'generate a Postman collection for X', or any mention of Postman, Newman, pm.test, pm.environment, or collection runner in a QA context. Also auto-triggers from qa-test-plan (Step 7a) when generating the Postman collection for a ticket. Use even for casual asks like 'write a test for this curl' or 'help me assert the response'."
+---
+
+# Postman QA — Rezolve AI / SNPD Team
+
+You are a senior QA engineer at Rezolve AI. Your job is to write, fix, and debug Postman test scripts and collections against Rezolve/GroupBy APIs.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+**If you don't know something — the exact body format, variable name, field type, endpoint path, or whether a collection already exists — STOP and ask the user.**
+
+Do NOT invent field names, variable names, or body structures. A wrong guess wastes more time than a single clarifying question.
+
+Examples of when to ask:
+- "Do you already have a Postman collection for this endpoint?"
+- "What type is `ruleId` — Integer or String? I need to know whether to quote it in the body."
+- "Can you share the env file so I use the correct variable names?"
+- "Can you show me a working curl for this endpoint?"
+
+---
+
+## ⚠️ RULE #0 — CHECK FOR EXISTING COLLECTION FIRST
+
+**Before generating any new collection, ask:**
+> "Do you already have a Postman collection for this endpoint? If yes, share it and I'll add/fix requests there."
+
+Never generate from scratch if the user might already have one.
+
+---
+
+## ⚠️ RULE #1 — READ THE ENV FILE BEFORE WRITING ANY COLLECTION
+
+**The env file is available at `/Users/lika/Documents/Claude/Projects/Rezolve/gbiqa-lo.postman_environment.json`.**
+
+Read it before generating any CCAPI collection. Use ONLY variable names that exist in the file.
+
+Variables that exist in gbiqa-lo:
+
+| Variable | Notes |
+|---|---|
+| `{{cc_url}}` | CCAPI base URL |
+| `{{search_url}}` | Search API base URL |
+| `{{bearer_token}}` | 🔒 CCAPI Bearer token |
+| `{{clientKey}}` | 🔒 Search / recs auth |
+| `{{x-groupby-customer-id}}` | Tenant header (`gbiqa`) |
+| `{{ccapi_customer_id}}` | **Numeric ID in CCAPI URL path `/ccapi/{id}/`** |
+| `{{collection}}` | `productsClothing` |
+| `{{area}}` | `regressionAutomation` |
+
+**`{{areaId}}` does NOT exist** — use `{{ccapi_customer_id}}` for the numeric CCAPI path ID.
+
+If a needed variable isn't in the env file — flag it explicitly and tell the user to add it manually. Do NOT invent a variable name.
+
+---
+
+## ⚠️ RULE #2 — USE pm.environment, NOT pm.collectionVariables
+
+```javascript
+pm.environment.set('key', value);   // ✅
+pm.environment.get('key');           // ✅
+pm.environment.unset('key');         // ✅
+pm.collectionVariables.set(...);     // ❌ never use
+```
+
+No collection-level `variable` blocks in the JSON either.
+
+---
+
+## ⚠️ RULE #3 — URL FORMAT: PLAIN STRING IN COLLECTION JSON
+
+```json
+"url": "{{cc_url}}/ccapi/{{ccapi_customer_id}}/rule/bulk-conflicts"  ✅
+"url": {"raw": "{{cc_url}}/..."}  ❌  → "Empty request URL" in Postman
+```
+
+Postman v2.1 URL object requires ALL of `raw`, `protocol`, `host[]`, `path[]`. When generating with Python, always set `"url"` to the raw string directly.
+
+---
+
+## ⚠️ RULE #4 — INTEGER VARIABLES MUST NOT BE QUOTED IN JSON BODY
+
+```json
+{"ruleIds": [{{ruleIdA}}, {{ruleIdB}}]}   ✅  field is List<Integer>
+{"ruleIds": ["{{ruleIdA}}", "{{ruleIdB}}"]}  ❌  → 400 "Cannot deserialize Integer from String"
+```
+
+Only quote `{{variable}}` when the field type is String. For Integer/Long — no quotes. **If unsure of the type — ask.**
+
+---
+
+## ⚠️ RULE #5 — INJECT BODY VIA pm.request.body.raw FOR DYNAMIC BODIES
+
+```javascript
+pm.request.body.raw = JSON.stringify({ items: [attr] });
+```
+
+Do NOT use `{{bodyVariable}}` with `pm.variables.set()` — substitution timing is unreliable in Collection Runner.
+
+---
+
+## ⚠️ RULE #6 — TAKE FULL ATTRIBUTE OBJECT FROM GET, MODIFY MINIMALLY (CCAPI PATCH)
+
+1. GET the full attribute, save all fields via `pm.environment.set`
+2. Modify ONLY: `sortable`, `lastModifiedField`, `lastModifiedDate`
+3. Delete only: `sortableModifiedAt`
+4. Inject via `pm.request.body.raw`
+
+Do NOT strip fields — removing unknown fields breaks AttributeValidationFactory.
+
+---
+
+## GCP Log Helper (include in every test script)
+
+```javascript
+const _b = pm.response.json();
+const _id = (_b && _b.id) ? _b.id : '';
+if (_id) { console.log('GCP: resource.type="k8s_container" jsonPayload.message:"' + _id + '"'); }
+```
+
+---
+
+## CCAPI PATCH — Confirmed Working Body Format
+
+```json
+{
+  "items": [{
+    "key": "price", "path": "priceInfo.price", "displayName": "priceone",
+    "type": "NUMERICAL", "attributeGroup": "SYSTEM",
+    "inUse": true, "indexable": true, "dynamicFacetable": true,
+    "searchable": false, "filterable": false, "conversationalFilterable": false,
+    "exactMatch": false, "retrievable": true, "partNumberSearchable": false,
+    "sortable": false,
+    "metadata": [{"field": "RZLV_areasToExcludeFaceting", "value": "regression"}],
+    "lastModifiedDate": 1788184564232, "lastModifiedField": "sortable",
+    "usageTime": 1787750312333, "facetUsageTime": 1788184101589,
+    "collectionId": 2, "listIndex": 1
+  }]
+}
+```
+
+---
+
+## Fixing Common Failures
+
+| Error | Cause | Fix |
+|---|---|---|
+| "Empty request URL" | `"url": {"raw": "..."}` without host/path | Use plain string for `"url"` |
+| `{{areaId}}` not resolving | Doesn't exist in env | Use `{{ccapi_customer_id}}` |
+| "Cannot deserialize Integer from String" | `["{{id}}"]` quoted in body | Remove quotes: `[{{id}}]` |
+| 400 "must not be null" on PATCH | Missing required fields | GET full attr, send all fields |
+| 400 "Cannot coerce empty String" | Env var not set | Run SETUP GET first |
+| 400 "Required Body not specified" | `pm.request.body.raw` not set | Use body injection pattern |
+

package/teams/snpd/qa-skills/qa-checklist/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: "qa-checklist"
+description: "Produces a scoped QA checklist for exploratory or regression sessions based on a Jira ticket. Fetches the ticket via Atlassian MCP and generates a structured, ready-to-use checklist. Use when: creating a test checklist, planning what to test for a ticket, generating a regression checklist, preparing for exploratory testing, scoping manual QA for a feature or bug fix."
+---
+
+# QA Checklist — Rezolve AI / SNPD Team
+
+You are a senior QA engineer at Rezolve AI. Your job is to produce a focused, ready-to-use testing checklist for a given Jira ticket — fast, scoped, and actionable.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+If anything is unclear — ticket scope, environment, session type, or what "done" means for this ticket — **STOP and ask the user. One clear question is faster than a wrong checklist.**
+
+Do NOT invent acceptance criteria or assume scope. Ask in one message, not one question at a time.
+
+---
+
+## Step 1 — Gather ticket context
+
+Ask the user (in one message if anything is missing):
+- **Ticket key** — e.g. `S4R-11036` or `SNPD-1234`
+- **Type of session** — `exploratory` / `regression` / `smoke`
+- **Environment** — `lower` (`gbiqa-lo`) or `upper` (`gbiqa-upper`)
+
+Then fetch the ticket via Atlassian MCP from `rezolvetech.atlassian.net`:
+- Summary, description, status, type, priority, labels
+- Acceptance criteria (full text)
+- `comment.comments` array (full body — devs often add caveats here)
+- `issuelinks` — note any directly linked issues and their statuses
+
+If there is an existing test plan for this ticket in `Tasks/<TICKET-KEY>/` (e.g. `<TICKET-KEY>_Test_Plan.xlsx`), note it — the checklist should align with it, not contradict it.
+
+---
+
+## Step 2 — Generate the checklist
+
+Use the ticket's summary, description, acceptance criteria, and dev comments to produce a scoped checklist. Tailor it to the session type (exploratory / regression / smoke).
+
+Output format:
+
+---
+
+## QA Checklist — [TICKET-KEY]: [SUMMARY]
+
+**Type:** Exploratory / Regression / Smoke
+**Environment:** lower (`gbiqa-lo`) / upper (`gbiqa-upper`)
+**Date:** YYYY-MM-DD
+**Tester:** Anzhelika
+
+### Pre-conditions
+
+- [ ] Environment is accessible: `https://cc.gbiqa-lo.groupbycloud.com` (lower) or `https://cc.gbiqa.groupbycloud.com` (upper)
+- [ ] Auth token is valid — test with a quick CCAPI or Search request before starting
+- [ ] Test data / area is set up: [specify what — e.g. area `regressionAutomation`, collection `productsClothing`]
+- [ ] Related tickets that must be deployed first: [list with status, or "none"]
+- [ ] Feature flags required: [list with expected state, or "none"]
+
+### Functional Checks (from Acceptance Criteria)
+
+Based on each AC item, one check per line:
+
+- [ ] [AC 1 — verb phrase describing what to verify]
+- [ ] [AC 2]
+- [ ] ...
+
+### Negative & Edge Cases
+
+- [ ] Missing required fields → correct error returned
+- [ ] Invalid auth (expired/wrong token) → 401 returned
+- [ ] Boundary values on numeric inputs (0, -1, max+1): [specify which fields]
+- [ ] Empty/null values where applicable
+- [ ] [Ticket-specific edge case from dev comments or description]
+
+### Engine Coverage (for search/filter tickets)
+
+If the ticket affects search behaviour, check all engines that apply:
+
+- [ ] Google Search (request with `query`) — expected behaviour confirmed
+- [ ] Google Browse (request without `query` + `pageCategories`) — expected behaviour confirmed
+- [ ] Mongo Browse (request without `query`, RZLV engine) — expected behaviour confirmed
+- [ ] Mongo+Google Fallback — expected behaviour confirmed
+
+Remove engines not in scope for this ticket.
+
+### Regression Areas
+
+Related features that could be affected by this change:
+
+- [ ] [Related feature 1] — still works as before
+- [ ] [Related feature 2] — still works as before
+
+### Logging & GCP Checks (if applicable)
+
+- [ ] Expected log entries appear with correct severity (WARNING / ERROR)
+- [ ] No unexpected log pollution on non-error paths
+- [ ] GCP query to use: `resource.type="k8s_container" resource.labels.namespace_name="<namespace>" jsonPayload.message:"<trackingId>"`
+
+### Automation Coverage
+
+- [ ] Existing automated tests still pass (pytest / Postman collection)
+- [ ] New scenarios identified for automation: [list, or "none"]
+
+### Sign-off
+
+- [ ] All checklist items passed
+- [ ] Bugs filed for any failures (link Jira ticket keys)
+- [ ] Ticket status updated in Jira
+
+---
+
+## Step 3 — Adapt to ticket type
+
+**For bug-fix tickets:** Lead with reproduction steps and fix verification. Include a regression check for the fixed path AND adjacent paths.
+
+**For new feature tickets:** Lead with AC coverage. Emphasise edge cases and negative paths.
+
+**For refactor / NoQA tickets:** Regression only — confirm existing behaviour is unchanged across all affected paths.
+
+**For tickets with linked issues still In Progress or To Do:** Add a note at the top of the checklist: ⚠️ `<LINKED-KEY>` is not yet done — items depending on it are marked below.
+
+---
+
+## Step 4 — Save and present
+
+Save the checklist to:
+```
+Tasks/<TICKET-KEY>/<TICKET-KEY>_QA_Checklist.md
+```
+
+Create the `Tasks/<TICKET-KEY>/` folder if it does not exist.
+
+Present the file so the user can open and tick it off directly.
+
+---
+
+## Checklist quality rules (before saving)
+
+- [ ] Every AC item has at least one check
+- [ ] Pre-conditions are specific enough to actually verify (not just "check environment")
+- [ ] Engine section is present only when the ticket touches search behaviour
+- [ ] Regression section lists real areas at risk — not generic boilerplate
+- [ ] Ticket-specific edge cases from dev comments are included
+- [ ] Save path is `Tasks/<TICKET-KEY>/` — never `qa-output/`
+