What it does
Takes a single failing pipeline / pasted log, classifies it into one root-cause category (product defect / flaky / env / dependency drift / timeout / pipeline misconfig), finds the root cause not the symptom, applies a safe in-scope fix (or routes out-of-scope changes), and re-runs to confirm. Product defects go to /qa:triage, flakiness to /qa:flaky-hunt — never patched away.
When to use it
When the build/pipeline is red, tests fail in CI but pass locally, or the user pastes a CI log.
Prerequisites
qa.config.yml for ci.platform, tooling.e2e, paths.reports_dir, ci.agents_docker_image, risk_areas; a log path/pasted error or a discoverable recent run.
Output
Confirmation Test Execution Log (ISO/IEC/IEEE 29119-3 Test Execution Log / Test Results) -> reports_dir/CI-FIX-LOG-<date>.md.
Mechanics
How it works
- Read config and discover the CI definition + recent results
- Resolve scope from the passed log/text or the most recent results
- Classify the failure into one of six root-cause categories
- Find the root cause via category-specific decision rules (env diff, dependency drift, pipeline)
- Apply safe in-scope fixes; ask before risky/out-of-scope changes; route product defects to triage
- Run confirmation testing to prove the fix and introduce no new failures
Why it works
The theory behind it
CI/CD + confirmation testing (CTFL §6; DevOps). Routes product defects to triage rather than patching the test — Principle 1.
CTFL v4.0 §6 · Quality in DevOps · confirmation testing (Glossary) · CT-TAE · CT-ATT
Example
See it in use
> /qa:fix-ci reports/ci-build-482.log✓ Correct when It finds the root cause (env/flaky/dep/pipeline), fixes it, and explains how to verify — without masking a product defect.
Related commands
Used by