# Defect, retest and release templates

> SYNTHETIC REFERENCE • SAMPLE-PENTASCOPE-MASTER • v1.0.0 • 2026-09-08 • Draft • all 96 cases Not Run. This is a proposed learning and acceptance pack, not customer source truth, test evidence or release approval. No project is created or seeded by opening it.

## Truth boundary

There are **zero observed defects** in this sample pack. DEFECT-TEMPLATE-001 below is a blank reporting template, not a bug claim. No actual failed run, build, screenshot, delivery or closure is supplied. Synthetic scenarios in the catalogue describe what to test; they are not execution evidence.

## Defect report to fill after observation

- Defect ID: assigned by the actual project system; template identity DEFECT-TEMPLATE-001 is not a runtime issue ID.
- Project / environment / build / browser / role: actual values from the execution manifest.
- Title: concise observed deviation and trigger, e.g. a description of the specific violated adopted criterion, not a speculative root cause.
- Requirement / acceptance criterion / case and version / run and attempt: actual linked IDs.
- Preconditions and independent data: exact controlled fixture needed to reproduce, with secrets removed.
- Steps to reproduce: ordered actual actions, not a copied generic plan.
- Expected result: cite the adopted criterion/version.
- Actual result: exact observed response/state/error, UTC observation time and reproducibility count.
- Evidence: authorized screenshot/API/persisted-state references that prove the mismatch; no invented filenames.
- Impact / severity / priority: proposed impact, affected scope and rationale; reviewed by the designated human.
- Workaround: only if actually verified; otherwise unset.
- Status: observed runtime status only; template remains Draft.
- Assignee / triage decision / reviewer / time / reason: actual attributable records.

## Distinguish defect, requirement gap and environment blocker

An actual deviation from an approved criterion is a defect candidate. Conflicting or missing business rules are requirement findings. Missing credentials, down fixtures or unavailable target builds block execution. A provider error may be an observed integration issue, but it does not prove every generated artifact is wrong. Keep these categories separate and preserve evidence for the classification decision.

## Fix delivery record

Record issue ID, approved fix scope, exact revision/build, delivery reference, changed behavior, developer checks, migration/config prerequisites and deployment target. A commit or deployment is not acceptance proof. The permitted transition to Awaiting Retest requires the current backend delivery/build fields. Re-read the issue after transition to verify what was persisted.

## Retest record

Record a new actual run ID, linked case version or valid lineage, the exact delivered build, executor, target, UTC times, steps, assertions, evidence and affected regression selection. Reproduce the original failure first only when safe and useful, then verify the fix. A different-build pass or unrelated case cannot prove closure. Any failure keeps the defect unresolved; record the actual permitted reopen/failed-retest transition. Closure needs the current gate's verified fully passing evidence and authorized named decision.

## Release decision template

The JSON template provides: release/build/scope, approved source/case versions, coverage denominators, actual evidence references, critical gaps, open defects, accepted risks, sign-off actor/time and rationale. All execution and approval fields are unset, counts are zero and readiness is false.

Before signing, reconcile current source obligations → requirements → criteria → case versions → actual runs → evidence → issues/fixes/retests. Review security/privacy, integrity, performance/recovery targets and supported locale/device scope separately. If a critical gap remains or evidence is absent, the honest decision is not ready; no average score overrides it.