@groupby/ai-dev 0.5.21 → 0.5.22

package/teams/snpd/qa-skills/qa-test-plan/references/qase-schema.md

@@ -0,0 +1,55 @@
+# Qase Export Schema Reference
+
+Based on actual SRTM export from Rezolve AI QA team.
+
+## Field value enums
+
+### priority
+`critical` | `high` | `medium` | `low`
+
+### severity
+`critical` | `major` | `normal` | `minor` | `trivial`
+
+### type
+`functional` | `regression` | `performance` | `smoke` | `security` | `usability`
+
+### behavior
+`positive` | `negative` | `destructive`
+
+### automation
+`is-not-automated` | `is-automated` | `to-be-automated`
+
+### layer
+`api` | `ui` | `e2e` | `unit`
+
+### status
+`actual` | `deprecated` | `draft`
+
+## Title convention
+`[SERVICE-NAME][TC-NN] Short imperative title`
+
+Examples:
+- `[SITE-SEARCH][TC-01] Bulkhead overflow logs HTTP 429 as ERROR`
+- `[SEARCH-API][TC-03] Regression guard: 429 must never be WARNING`
+
+## Suite title convention
+`[TICKET-KEY] Short description — service-name`
+
+Example: `[S4R-11081] 429 should show as errors not warnings - site-search-api`
+
+## Suite description
+Always the Jira URL: `https://rezolvetech.atlassian.net/browse/TICKET-KEY`
+
+## Steps — data field
+Use the `data` field for:
+- Full URL of the endpoint being called
+- Request payload (JSON or key params)
+- GCP Logs Explorer query URL (for log-checking steps)
+- Any env-specific value needed to execute the step
+
+## Tags
+Use lowercase, hyphen-separated. Include:
+- Service name (e.g. `site-search-api`)
+- Feature area (e.g. `bulkhead`, `429`, `logging`)
+- Test type (e.g. `regression`, `negative-control`)
+- Ticket key is NOT needed in tags (it's in suite description)

package/teams/snpd/qa-skills/qa-test-plan/references/rezolve-stack.md

@@ -0,0 +1,52 @@
+# Rezolve AI — Stack & Testing Patterns Reference
+
+## Team
+SNPD team, QA engineer stack:
+- Kotlin/Java backend services
+- React frontend
+- Node.js microservices  
+- Python ML services
+- Postman API testing
+- GitHub Actions CI/CD
+- GCP (Google Cloud Platform) — logs via GCP Logs Explorer
+
+## Known services / components (update as needed)
+- `site-search-api` — search service (Kotlin/Java)
+- GroupBy search cloud (`groupbycloud.com`) — external search provider
+- Command Center (CC) — internal admin/config UI (React)
+
+## Common test endpoints (QA/staging)
+- Search: `https://search.gbiqa-lo.groupbycloud.com/api/search`
+- Auth: `Authorization: client-key <uuid>`
+- Tenant header: `X-Groupby-Customer-Id`
+
+## Areas (for API requests)
+- `regressionAutomation` — MONGO, GOOGLE, MONGO_GOOGLE engines
+- `regressionAutomationBrowse` — GOOGLE BROWSE engine
+- Wrong area → 401 response
+
+## Logging
+- GCP Logs Explorer is used to verify log severity
+- Relevant filter pattern: `resource.labels.namespace_name="<service-name>"` + keyword
+- Severity levels to watch: ERROR vs WARNING (common regression point)
+
+## Feature flags
+- Controlled in Command Center or Vault
+- Always ask which env has which flag state before writing flag-dependent tests
+
+## Vault settings
+- Timeout values, bulkhead/concurrency limits, thresholds — ask user for actual values per env
+- Do not hardcode — use variable placeholders like `<bulkhead_limit>` and note the question
+
+## Automation tools
+- **Postman** — API testing, collections, environment variables
+- **GitHub Actions** — CI regression, can run k6 or curl-based load tests
+- **Manual** — GCP log severity checks, visual UI validation
+
+## Bulkhead / concurrency pattern (resilience4j or similar)
+When a ticket involves bulkhead/semaphore limits:
+- Positive: send N requests where N < limit → all succeed
+- Boundary: send exactly N = limit requests → edge (some may queue)  
+- Overflow: send N > limit → expect 429 Too Many Requests
+- Log check: 429 events must be ERROR not WARNING
+- Negative control: low concurrency (e.g. 5 requests) → no 429, no error logs