@jetrabbits/agentic 0.0.1

package/areas/software/platform/workflows/provision-env.md

@@ -0,0 +1,77 @@
+---
+name: provision-env
+type: workflow
+trigger: /provision-env
+description: Spin up a complete, isolated environment for a branch or initialize a standing environment using Terraform.
+inputs:
+  - target_environment
+  - branch
+outputs:
+  - provisioned_environment
+  - environment_url
+roles:
+  - team-lead
+  - developer
+  - qa
+execution:
+  initiator: team-lead
+related-rules:
+  - immutability.md
+  - cost-governance.md
+  - reliability.md
+uses-skills:
+  - terraform-patterns
+  - k8s-manifests
+  - networking
+quality-gates:
+  - no unexpected destroy operations in plan for non-preview envs
+  - cost delta within budget before apply
+  - smoke tests pass against new environment
+---
+
+## Steps
+
+### 1. Validate Prerequisites — `@team-lead`
+- **Input:** environment type, branch
+- **Actions:** check cloud credentials active; verify Terraform state backend accessible; confirm no active locks on target environment state
+- **Output:** prerequisites confirmed
+- **Done when:** no locks; credentials valid
+
+### 2. Plan Infrastructure — `@developer`
+- **Input:** validated prerequisites
+- **Actions:** `terraform init -reconfigure`; `terraform plan -out=tfplan`; if destroyed resources > 0 in non-preview env → HALT, request manual approval
+- **Output:** `tfplan` artifact; destroy count confirmed
+- **Done when:** plan reviewed; no unexpected destroys
+
+### 3. Estimate Cost — `@developer`
+- **Input:** tfplan
+- **Actions:** `infracost breakdown --path tfplan`; HALT if delta > $500/month for preview environments
+- **Output:** cost estimate; approval if within budget
+- **Done when:** cost within budget; `@team-lead` approves
+
+### 4. Apply Infrastructure — `@developer`
+- **Input:** approved plan + cost estimate
+- **Actions:** `terraform apply tfplan`; capture all outputs (endpoints, ARNs)
+- **Output:** infrastructure provisioned; outputs captured
+- **Done when:** apply exits 0; all resources created
+
+### 5. Configure DNS & Ingress — `@developer`
+- **Input:** infrastructure outputs
+- **Actions:** register subdomain: `<branch>.staging.mycompany.com`; wait for SSL certificate validation; verify HTTPS endpoint responds
+- **Output:** DNS and SSL active; HTTPS confirmed
+- **Done when:** HTTPS endpoint reachable
+
+### 6. Seed & Smoke Test — `@qa`
+- **Input:** running environment
+- **Actions:** run database migrations; run smoke test suite against new environment
+- **Output:** smoke test results; environment validated
+- **Done when:** smoke tests pass; environment confirmed functional
+
+### 7. Report — `@pm`
+- **Input:** validated environment
+- **Actions:** post environment URL to PR comment; include: all endpoints, credentials location, teardown command
+- **Output:** environment URL published in PR
+- **Done when:** team has access and teardown instructions
+
+## Exit
+Smoke tests green + URL published = environment ready for use.

package/areas/software/qa/AGENTS.md

@@ -0,0 +1,58 @@
+# QA — guidance index
+
+## What this area covers
+
+Test strategy, risk-based verification, and release confidence: test pyramid design, flakiness management, performance auditing, regression suite maintenance, test data management, and accessibility testing.
+
+## Guidance chain
+
+1. Project `.agent/` baseline (`AGENTS.md` + `.agent/*`)
+2. `software/general/rules/*` — always active
+3. `qa/rules/*` — load all for this spec
+4. `qa/skills/*/SKILL.md` — load only the skill matching the current task
+5. `qa/workflows/*` — load the workflow matching the triggered command
+
+## Inherited from general
+
+- SDLC role responsibilities and handoffs
+- Git / CI / lint / format quality baseline
+- Shared development and review workflows
+
+## QA-specific constraints
+
+- Flaky tests must be quarantined within one business day; they are never silently skipped.
+- Go / no-go recommendation must be written with evidence — "looks good" is not a QA output.
+- Every test data set must be deterministic and resettable; no dependency on production data.
+
+## Spec map
+
+```text
+qa/
+├── rules/
+│   ├── test-strategy.md       ← pyramid ratios, coverage targets, risk classification
+│   ├── quality-gates.md       ← blocking vs advisory criteria, merge conditions
+│   ├── flakiness-policy.md    ← quarantine SLA, fix-or-delete policy, flakiness budget
+│   └── test-data.md           ← data isolation, factory patterns, PII handling in tests
+├── skills/
+│   ├── test-pyramid/SKILL.md             ← unit/integration/e2e ratios, boundary decisions
+│   ├── e2e-patterns/SKILL.md             ← Playwright/Cypress patterns, page objects
+│   ├── api-testing/SKILL.md              ← contract tests, mutation testing, schema validation
+│   ├── performance-testing/SKILL.md      ← k6, Lighthouse, load profiles, threshold design
+│   ├── accessibility-testing/SKILL.md    ← axe-core, manual checks, WCAG AA criteria
+│   └── test-data-management/SKILL.md     ← factories, seeds, snapshot isolation
+├── workflows/
+│   ├── smoke-test.md                  ← /smoke-test
+│   ├── regression-suite.md            ← /regression-suite
+│   ├── flakiness-investigation.md     ← /flakiness-investigation
+│   ├── performance-audit.md           ← /performance-audit
+│   └── test-coverage-report.md        ← /test-coverage-report
+└── prompts/
+    └── *.md
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`
+- `prompts/*.md`

package/areas/software/qa/PROMPTS.md

@@ -0,0 +1,32 @@
+# PROMPTS: qa
+
+Use these prompts with `AGENTS.md` from the same directory.
+
+## 1) Initialize agent behavior
+
+```text
+Read `qa/AGENTS.md` and adopt its rules, skills loading strategy, and workflows as hard constraints.
+List the active rules and the selected workflow before implementation.
+```
+
+## 2) Implement a feature
+
+```text
+Using `qa/AGENTS.md`, implement: <feature description>.
+Before coding: provide architecture notes, risk list, and test plan.
+After coding: run checks and report exact commands and results.
+```
+
+## 3) Incident / debug mode
+
+```text
+Using `qa/AGENTS.md`, run incident triage for: <incident summary>.
+Return root cause hypotheses, validation steps, fix plan, and rollback plan.
+```
+
+## 4) Release readiness
+
+```text
+Using `qa/AGENTS.md`, prepare release checklist for: <release scope>.
+Include quality gates, security gates, performance gates, and deployment validation.
+```

package/areas/software/qa/prompts/flakiness-investigation.md

@@ -0,0 +1,61 @@
+---
+workflow: flakiness-investigation
+---
+
+# Prompt: `/flakiness-investigation`
+
+Use when: a test fails intermittently in CI without a deterministic cause.
+
+---
+
+## Example 1 — Timeout-pattern flake
+
+**EN:**
+```
+/flakiness-investigation
+
+Flaky test: tests/e2e/checkout.spec.ts → "should complete payment flow"
+Failure rate: 15% over last 20 CI runs (3/20 failed)
+Pattern: only fails in CI, not locally; always on the payment confirmation step
+Error: Timeout waiting for "Order confirmed" text (30s timeout exceeded)
+Suspected cause: CI payment mock slower than local; or race condition in status polling
+Last stable: 2 weeks ago before adding retry logic to payment service
+```
+
+**RU:**
+```
+/flakiness-investigation
+
+Нестабильный тест: tests/e2e/checkout.spec.ts → "should complete payment flow"
+Частота сбоев: 15% за последние 20 CI запусков (3/20 упали)
+Паттерн: падает только в CI, не локально; всегда на шаге подтверждения платежа
+Ошибка: Timeout ожидания текста "Order confirmed" (превышен таймаут 30с)
+Предполагаемая причина: CI платёжный mock медленнее локального; или race condition в polling статуса
+Последняя стабильная версия: 2 недели назад до добавления retry логики в payment service
+```
+
+---
+
+## Example 2 — Test pollution flake
+
+**EN:**
+```
+/flakiness-investigation
+
+Flaky test: test_user_order_count_is_zero
+Failure rate: 20% (always fails when test_create_bulk_orders runs before it)
+Pattern: order-dependent failure — shared DB state between tests
+Root cause suspected: test_create_bulk_orders commits data that isn't cleaned up
+Fix direction: switch from truncation-based to transaction-rollback isolation
+```
+
+**RU:**
+```
+/flakiness-investigation
+
+Нестабильный тест: test_user_order_count_is_zero
+Частота сбоев: 20% (всегда падает когда test_create_bulk_orders запускается перед ним)
+Паттерн: зависимость от порядка — общее состояние БД между тестами
+Предполагаемая причина: test_create_bulk_orders коммитит данные которые не очищаются
+Направление исправления: переключиться с truncation-based на transaction-rollback изоляцию
+```

package/areas/software/qa/prompts/performance-audit.md

@@ -0,0 +1,65 @@
+---
+workflow: performance-audit
+---
+
+# Prompt: `/performance-audit`
+
+Use when: investigating latency regressions or establishing performance baselines.
+
+---
+
+## Example 1 — Regression investigation
+
+**EN:**
+```
+/performance-audit
+
+Target: POST /api/v1/orders
+Test type: load test
+SLO baseline: p95 < 300ms, p99 < 1000ms, error rate < 0.5%
+Current p99: 2.4s (regression vs. last release 340ms)
+Suspected cause: migration added 3 new FK lookups on order creation
+Load profile: ramp to 100 VUs over 2 min, hold 5 min
+Environment: staging (isolated from other traffic)
+```
+
+**RU:**
+```
+/performance-audit
+
+Цель: POST /api/v1/orders
+Тип теста: нагрузочный тест
+SLO baseline: p95 < 300ms, p99 < 1000ms, error rate < 0.5%
+Текущий p99: 2.4s (регрессия vs. предыдущий релиз 340ms)
+Предполагаемая причина: миграция добавила 3 новых FK lookup при создании заказа
+Профиль нагрузки: rampe to 100 VU за 2 мин, держать 5 мин
+Окружение: staging (изолировано от другого трафика)
+```
+
+---
+
+## Example 2 — Baseline establishment
+
+**EN:**
+```
+/performance-audit
+
+Target: checkout flow end-to-end (browse → cart → payment → confirmation)
+Test type: load + soak
+Purpose: establish baselines before Black Friday traffic planning
+Load: 500 concurrent users (3x normal peak)
+Soak: 2 hours at 200 VUs to detect memory leaks
+Output: performance-baselines.json for CI threshold gates
+```
+
+**RU:**
+```
+/performance-audit
+
+Цель: end-to-end поток оформления заказа (просмотр → корзина → оплата → подтверждение)
+Тип теста: нагрузочный + soak
+Цель: установить baseline перед планированием трафика Black Friday
+Нагрузка: 500 одновременных пользователей (3x нормального пика)
+Soak: 2 часа при 200 VU для обнаружения утечек памяти
+Результат: performance-baselines.json для пороговых значений в CI
+```

package/areas/software/qa/prompts/regression-suite.md

@@ -0,0 +1,61 @@
+---
+workflow: regression-suite
+---
+
+# Prompt: `/regression-suite`
+
+Use when: running full regression before a significant release or after a major code change.
+
+---
+
+## Example 1 — Release regression
+
+**EN:**
+```
+/regression-suite
+
+Environment: staging (release candidate v3.0.0)
+Scope: full — all test categories
+Release context: major version; includes DB schema migration for orders table
+High-risk areas: order creation, payment processing, user authentication
+Expected duration: ~45 min
+Failure policy: any blocker in high-risk area → hold release
+```
+
+**RU:**
+```
+/regression-suite
+
+Окружение: staging (release candidate v3.0.0)
+Скоуп: полный — все категории тестов
+Контекст релиза: мажорная версия; включает миграцию схемы для таблицы orders
+Зоны высокого риска: создание заказов, обработка платежей, аутентификация
+Ожидаемое время: ~45 мин
+Политика отказов: любой blocker в зоне высокого риска → задержать релиз
+```
+
+---
+
+## Example 2 — Targeted regression after change
+
+**EN:**
+```
+/regression-suite
+
+Environment: staging
+Scope: targeted — auth module and all downstream tests
+Reason: SSO provider upgrade to SAML 2.0 — auth flow changed
+Tests to include: login, logout, token refresh, session expiry, SSO redirect
+Skip: unrelated UI tests (save time)
+```
+
+**RU:**
+```
+/regression-suite
+
+Окружение: staging
+Скоуп: целевой — модуль auth и все зависимые тесты
+Причина: обновление SSO провайдера до SAML 2.0 — изменён auth flow
+Тесты для включения: login, logout, token refresh, session expiry, SSO redirect
+Пропустить: несвязанные UI тесты (экономия времени)
+```

package/areas/software/qa/prompts/smoke-test.md

@@ -0,0 +1,65 @@
+---
+workflow: smoke-test
+---
+
+# Prompt: `/smoke-test`
+
+Use when: validating a deployment is healthy immediately after it lands in an environment.
+
+---
+
+## Example 1 — Post-deploy validation
+
+**EN:**
+```
+/smoke-test
+
+Environment: staging
+Deployment context: v2.4.1 just deployed — adds payment retry logic
+Critical paths to verify:
+- User can log in and see dashboard
+- Product search returns results
+- Add to cart → checkout → order confirmation flow completes
+- Payment with test card 4242 4242 4242 4242 succeeds
+Stop criteria: if payment flow fails → trigger rollback immediately
+```
+
+**RU:**
+```
+/smoke-test
+
+Окружение: staging
+Контекст деплоя: только что задеплоена v2.4.1 — добавлена логика повтора платежей
+Критические пути для проверки:
+- Пользователь может войти и видит dashboard
+- Поиск продуктов возвращает результаты
+- Поток добавить в корзину → оплата → подтверждение заказа завершается
+- Оплата тестовой картой 4242 4242 4242 4242 проходит успешно
+Критерий остановки: если поток оплаты падает → немедленно инициировать откат
+```
+
+---
+
+## Example 2 — Pre-release smoke
+
+**EN:**
+```
+/smoke-test
+
+Environment: production (20% canary)
+Deployment: canary traffic split active — v2.5.0 on 20% of traffic
+Check: error rate and latency on canary pods vs. baseline pods (must be within 5%)
+Auth: admin token from CI secrets
+Timeout: 15 minutes max — block full rollout if not green
+```
+
+**RU:**
+```
+/smoke-test
+
+Окружение: production (20% canary)
+Деплой: активен canary split — v2.5.0 получает 20% трафика
+Проверить: error rate и latency на canary подах vs. baseline (должны быть в пределах 5%)
+Auth: admin токен из CI secrets
+Таймаут: максимум 15 минут — блокировать полный rollout если не green
+```

package/areas/software/qa/prompts/test-coverage-report.md

@@ -0,0 +1,61 @@
+---
+workflow: test-coverage-report
+---
+
+# Prompt: `/test-coverage-report`
+
+Use when: auditing test coverage gaps and planning targeted test investment.
+
+---
+
+## Example 1 — Sprint coverage audit
+
+**EN:**
+```
+/test-coverage-report
+
+Coverage artifacts: coverage/lcov.info (generated by make test)
+Current threshold: 70% lines
+Focus modules: src/services/payment.py (38%), src/services/order.py (55%)
+Context: payment module had 3 production bugs last sprint — priority to improve
+Target: identify top 5 uncovered critical paths in payment service
+Output: test improvement plan with estimated effort per gap
+```
+
+**RU:**
+```
+/test-coverage-report
+
+Coverage артефакты: coverage/lcov.info (сгенерирован make test)
+Текущий порог: 70% строк
+Приоритетные модули: src/services/payment.py (38%), src/services/order.py (55%)
+Контекст: в payment модуле было 3 баг в проде за прошлый спринт — приоритет на улучшение
+Цель: определить топ-5 непокрытых критических путей в payment service
+Результат: план улучшения тестов с оценкой трудозатрат на каждый gap
+```
+
+---
+
+## Example 2 — Pre-release coverage gate
+
+**EN:**
+```
+/test-coverage-report
+
+Coverage artifacts: coverage/
+Threshold: 80% for release (currently at 74%)
+Release date: in 3 days
+Find: which files are below threshold AND were changed in this release cycle
+Output: list of files that need tests to reach 80%, prioritized by change risk
+```
+
+**RU:**
+```
+/test-coverage-report
+
+Coverage артефакты: coverage/
+Порог: 80% для релиза (сейчас 74%)
+Дата релиза: через 3 дня
+Найти: какие файлы ниже порога И были изменены в текущем цикле релиза
+Результат: список файлов, которым нужны тесты для достижения 80%, приоритизированный по риску изменений
+```

package/areas/software/qa/rules/flakiness-policy.md

@@ -0,0 +1,12 @@
+# Rule: Flakiness Policy
+
+**Priority**: P1 — Flaky tests destroy team trust in CI.
+
+1. **Flakiness SLA**: Flaky tests fixed within 5 business days or permanently removed.
+2. **Root cause classification**: Before fixing, classify:
+   - Race condition: test doesn't wait for async operation
+   - State pollution: depends on another test's side effects
+   - Environment dependency: depends on external service
+   - Time dependency: hardcodes dates or depends on `Date.now()`
+3. **No `sleep()` to fix flakiness**: Use proper await conditions. Never arbitrary `wait(2000)`.
+4. **Flakiness tracking**: GitHub issue created for every quarantined test.

package/areas/software/qa/rules/quality-gates.md

@@ -0,0 +1,28 @@
+# Rule: Quality Gates
+
+**Priority**: P0 — CI must enforce gates automatically.
+
+## Merge Gates (Block PR)
+
+| Gate | Threshold |
+|:---|:---|
+| Unit test pass rate | 100% |
+| Integration test pass rate | 100% |
+| Coverage (business logic) | ≥ 80% |
+| SAST scan | Zero Critical/High |
+| Dependency audit | Zero Critical CVEs |
+| Type check | Zero errors |
+| Lint | Zero errors |
+
+## Deploy Gates (Block Deploy)
+
+| Gate | Threshold |
+|:---|:---|
+| E2E smoke suite | 100% pass |
+| Performance regression | p99 latency +20% vs. baseline |
+| Accessibility scan | Zero WCAG Level A violations |
+| E2E regression suite | ≥ 98% pass rate |
+
+## Flakiness Gate
+
+Test failing intermittently > 2% of runs on `main` is automatically quarantined until fixed.

package/areas/software/qa/rules/test-data.md

@@ -0,0 +1,9 @@
+# Rule: Test Data Management
+
+**Priority**: P1 — Improper test data causes production incidents.
+
+1. **No production data in tests**: Use synthetic data generators or fixtures. Never real customer data.
+2. **Test data is deterministic**: Each test creates its own data and cleans up after itself.
+3. **No shared mutable state between tests**: Tests sharing state create ordering dependencies and flakiness.
+4. **Factories over fixtures**: Use factory patterns (factory_boy, @faker-js/faker). Raw SQL fixtures go stale.
+5. **Sensitive data obviously fake**: Emails must use `@example.com`, phones use `555-` prefix.

package/areas/software/qa/rules/test-strategy.md

@@ -0,0 +1,11 @@
+# Rule: Test Strategy
+
+**Priority**: P0 — Untested code cannot be promoted to production.
+
+1. **Test pyramid proportions**: For every 1 E2E test → ~5 integration tests → ~20 unit tests.
+2. **Tests ship with code**: New features and bug fixes include tests in the same PR.
+3. **Coverage baselines**: Coverage may not decrease on merge. New code meets minimum threshold (default: 80% for business logic).
+4. **No production hotfixes without tests**: Emergency fixes must include a regression test before the fix is considered complete.
+5. **Test naming convention**: `[component] [scenario] [expected outcome]`
+   - ✅ `"checkout with expired card shows error message"`
+   - ❌ `"test_checkout_2"`