qa

Use when a C project wants Unity, CMock and CException run by one build command, or CMock mocks need writing or reading: Ceedling project scaffolding, project.yml, test tasks, JUnit XML, gcov coverage, host vs cross builds and CI. The Unity assertion API is unity-test-framework-c.

Use whenever Python Celery tasks need unit or integration tests: pytest-celery celery_app and worker fixtures, apply() for synchronous calls, why task_always_eager misleads, and mocking task.retry to test retry behavior, for function and class-based tasks.

Use when a Chrome extension's messages reach no listener, sendResponse never fires, a port disconnects mid-test, or a web page's access must be proven. Tests runtime.sendMessage, tabs.sendMessage, long-lived ports, externally_connectable and native messaging on a running extension.

Decides what kind of failure a red CI test is before anyone starts fixing it. Extracts seven failure signals from the runner output, stack trace, run history, and environment metadata, then walks an ordered first-match-wins rule set to exactly one verdict: flaky-known, environment-drift, defect, timeout, flaky-pre-incident, or flake-of-unknown-cause. Emits the verdict together with the alternatives that were rejected and the specific condition each one failed, so the triage decision is auditable rather than asserted. Use when a test has just gone red and the next action depends on whether the cause is a product defect, a non-deterministic test, or drifted infrastructure.

Use when designing how tests run in CI on any platform (GitHub Actions, GitLab CI, Jenkins, CircleCI): how many shards, which failures are safe to retry, quarantine, artifact retention, per-PR vs nightly cadence, cancel-on-push, timeouts and secrets. CircleCI config patterns are in its references.

Use when designing or testing a command-line tool's output: a new flag, command or error message, CLI assertions, or flaky tests caused by unstable output. Sets the contract for exit codes, stdout vs stderr, --json output, ordering, color and --help, based on the Command Line Interface Guidelines.

Use when a named framework (GDPR, CCPA, SOC 2, HIPAA, PCI DSS, ISO 27001) and existing evidence need a per-criterion readiness score before an audit, assessor visit or regulator inquiry. Marks each criterion met, partial or not met, records approved exclusions and never claims ready with a gap.

Procedure for proving that a claimed defect fix actually reached the build under test and actually works. Covers the merge-base ancestry check that proves the running build contains the fix commit rather than trusting a version label, the priority order for choosing which reproduction to re-run, and the VERIFIED / NOT FIXED / BLOCKED verdict table whose governing rule is that any ambiguous, flaky, or unreproducible result resolves to BLOCKED and is never guessed. Scoped to ISTQB confirmation testing (does this specific fix work?), not regression testing (did the fix break something else?), and not triage or severity assignment. Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.

Use when a deploy should be blocked by any incompatible API contract across protocols. Combines Pact can-i-deploy, oasdiff for OpenAPI, graphql-inspector for GraphQL and buf breaking for Protobuf into one go/no-go CI step with severity thresholds and a reason per finding.

Use when cron jobs, Kubernetes CronJobs, BullMQ repeat jobs, Sidekiq schedules or any time-based job need tests: cron expression validation, DST and leap-day edge cases, catch-up after downtime, overlapping-run locks with stale-lock recovery, and time zones.

Configures Cucumber for BDD scenarios - Cucumber-JVM (Java/Kotlin via JUnit 5), Cucumber-JS (Node), Cucumber-Ruby. Authors `.feature` files in Gherkin, writes step definitions in the host language, runs via the framework's runner, integrates with JUnit XML reporting. Use when the user mentions Cucumber, Gherkin, `.feature` files, or behavior-driven (BDD) tests in Java, Kotlin, JavaScript, or Ruby, as the canonical wrapper for any of the three official implementations.

Use when scoping a new data product or formalizing checks on an existing one. Reads a data PRD, dataset README or lineage doc and writes a data contract: schema with types, nullability and PII flags, freshness SLA, volume bounds, distribution rules and owner, for dbt, Great Expectations or Soda.

Use when designing data-quality coverage for a new data product or auditing an existing one: choosing dbt tests vs Great Expectations vs Soda, column vs table-level checks, severity tiers, SLA and freshness conventions, and anti-patterns to avoid.

Use when a data pipeline needs one CI step that fails the build when data quality drops. Gathers check results from dbt, Great Expectations or Soda, applies severity-aware thresholds and returns a single go/no-go decision with a reason per check.

Use whenever a dbt project needs data tests or CI gates: generic, singular and custom-macro tests, model assertions, reading failures from run_results.json and gating dbt build on the results.

Use when a service that takes two or more locks hangs in production with no error, or before a release when lock order across code paths was never checked. Records lock order, finds cycles, uses lock timeouts to fail instead of hang, and reads jstack or gdb thread dumps.

Use when a defect has been confirmed in production and the team must name which class of gap let it through before deciding what to build. Classifies it as a test, process or tooling gap and one of thirteen sub-patterns at the earliest layer that should have caught it, with the fix, without blame.

Use when choosing how to test or automate a desktop GUI app on Windows, macOS or Linux, or reviewing a desktop UI suite. Maps each app to a driver (FlaUI, WinAppDriver, Playwright for Electron, QtTest, XCUITest, AT-SPI) and covers accessibility-first locators, waits and elevation hazards.

Use whenever an Electron desktop app needs end-to-end tests, or a Spectron suite must be migrated: Playwright's _electron.launch, renderer windows as Pages, main-process checks via electronApp.evaluate, and IPC and DOM assertions from one suite.

Use when deciding what code coverage level embedded C/C++ needs (statement, branch, MC/DC) and wiring gcov or llvm-cov into the build: host vs QEMU instrumentation, MISRA-C and DO-178C expectations by safety level, and report formats.