Appropriate use
Use when engineering marks a defect ready for QA, a candidate build contains a fix, or a previously intermittent issue needs confirmation.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use when the original expected behaviour is unresolved, the fixed build cannot be identified, or the environment cannot reproduce the relevant conditions.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 6
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Defect and fix preflight Gate 1 · approve fix target
Resolve the original defect revision, approved expectation, original evidence, affected versions, proposed fix PR, candidate deployment, and known workaround.
defect revision · fix commits · candidate artifact · affected baseline
Phase 2: Original-path reconstruction
Rebuild the shortest faithful reproduction using original role, data, platform, timing, configuration, and network conditions.
original preconditions · exact action · original failure signature
Phase 3: Baseline confirmation
When safe and available, confirm the test detects the problem on an affected build. If unavailable, record the reason and use approved original evidence.
red proof · historical evidence · unavailable rationale
Phase 4: Candidate environment validation
Verify the deployed artifact includes the intended fix and no unrelated environment change invalidates the comparison.
deployment manifest · config diff · feature flags · data state
Phase 5: Fix execution
Execute the original scenario on the candidate build, record all attempts, and compare against the exact expected result and original failure signature.
attempt ledger · direct evidence · no retry-until-green
Phase 6: Related regression checks
Test nearby states, negative paths, roles, platforms, recovery, and data persistence based on the fix blast radius.
direct regression · indirect regression · excluded coverage
Phase 7: Fix assessment Gate 2 · confirm result
Classify the result as fully fixed, partially fixed, not fixed, blocked, inconclusive, or regressed elsewhere. Separate symptom removal from root-cause confidence.
original symptom · remaining impact · new regressions · confidence
Phase 8: Publish and regression recommendation Gate 3 · publish verification
Update the defect, attach evidence, recommend the proper automated test layer, and record any remaining risk or follow-up ticket.
verification comment · test recommendation · follow-up issue
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve fix target | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · confirm result | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish verification | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
FIXED
The original failure no longer occurs and required related regression checks pass.
PARTIALLY FIXED
The main symptom improved but some approved behaviour or affected scope remains incorrect.
NOT FIXED
The original controlled failure still occurs in the candidate build.
REGRESSION FOUND
The fix resolves the original issue but introduces another release-relevant failure.
BLOCKED
The fix cannot be verified because the candidate, prerequisite, data, or environment is unavailable.
INCONCLUSIVE
Evidence cannot distinguish a real fix from timing, environment, or intermittent behaviour.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Original defect | Issue revision and original evidence | The verification targets the same approved expectation. |
| Baseline | Affected-build result or approved historical evidence | Why red proof is available or unavailable is recorded. |
| Candidate identity | Deployment manifest | The intended fix commits are present. |
| Original path | Assertion-specific evidence | The previous failure signature is explicitly checked. |
| Regression scope | Impact-based scenario results | Included and excluded related coverage is visible. |
| Intermittency | Attempt sequence and timing | A pass after an assertion failure is not treated as FIXED. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
Version integrity
Verification stops when the deployed candidate does not contain the approved fix.
Runtime control
Expectation integrity
The expected result cannot be changed merely to match the implementation.
Runtime control
Attempt transparency
All attempts remain visible, including environment and automation errors.
Runtime control
Partial-fix honesty
A reduced frequency or changed symptom does not automatically become FIXED.
Runtime control
Regression independence
A new failure is tracked separately while remaining part of the release decision.
Runtime control
Publication binding
The verification comment records build, context hash, evidence, and approver.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
BLOCKED
The fix target or required verification conditions cannot be established.
NOT FIXED
The original defect remains or the expected behaviour is still unmet.
PARTIALLY FIXED
Material residual behaviour or scope remains.
FIXED WITH FOLLOW-UP
The original issue is fixed, but optional risk or separate non-blocking work remains.
FIXED
The original defect and required regression scope pass in the verified candidate.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Some historical builds cannot be recreated safely.
- Limit 2. A symptom can disappear because of configuration changes rather than the code fix.
- Limit 3. Intermittent defects need enough controlled attempts to support confidence.
- Limit 4. A root cause may remain uncertain even when the observable defect is fixed.
- Limit 5. Platform-specific fixes require platform-specific verification.
- Limit 6. A fix verification is not a full release regression unless explicitly scoped that way.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
verification-context.jsonVersioned output produced by the workflow.
baseline-result.mdVersioned output produced by the workflow.
candidate-attestation.jsonVersioned output produced by the workflow.
verification-plan.mdVersioned output produced by the workflow.
attempt-ledger.jsonlVersioned output produced by the workflow.
evidence-manifest.jsonVersioned output produced by the workflow.
regression-results.yamlVersioned output produced by the workflow.
verification-comment.mdVersioned output produced by the workflow.
verification-report.htmlVersioned output produced by the workflow.
artifacts/qa/verify-fix/<run-id>/ ├── verification-context.json ├── baseline-result.md ├── candidate-attestation.json ├── verification-plan.md ├── attempt-ledger.jsonl ├── evidence-manifest.json ├── regression-results.yaml ├── verification-comment.md └── verification-report.html
Example
Example request and controlled output
Input
Verify fix QA-5520 in player 4.11.5. Reproduce the original offline reboot issue and check reconnect, cached playback, and a second reboot.
Output excerpt
Verification: PARTIALLY FIXED Original issue: The reboot loop no longer occurs. Remaining problem: After reconnection, the player displays the latest playlist but reports the previous playlist version for approximately three minutes. Regression checks: - Cached playback: PASS - First reboot: PASS - Reconnect metadata: FAIL - Second reboot: PASS Next action: Keep QA-5520 open or split the remaining metadata issue after Product confirms impact.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/verify-fix
Determines whether a reported defect is fully fixed in the intended build and whether related behaviour remains safe across the agreed regression scope.