51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
# 41 — Release evidence contract
|
|
|
|
## Purpose
|
|
|
|
A release decision must be independently reviewable. Codex must not replace evidence with a narrative claim that the application is complete.
|
|
|
|
## Canonical artifact
|
|
|
|
The final implementation creates `release-evidence.json` from `templates/release-evidence.template.json` and validates it against `schemas/release-evidence.schema.json`.
|
|
|
|
The template contains every requirement ID from document 33 exactly once. During implementation, Codex updates status and evidence rather than deleting inconvenient requirements.
|
|
|
|
## Status rules
|
|
|
|
- `passed` — implementation exists and the referenced evidence actually passed;
|
|
- `failed` — required behavior or gate was run and failed;
|
|
- `blocked` — evidence cannot currently be completed because of a genuine dependency or environment blocker;
|
|
- `not-applicable` — the requirement truly does not apply, with explanation;
|
|
- `accepted-exception` — an explicit exception record identifies owner, rationale, impact and review/expiry date.
|
|
|
|
A required item with no evidence remains `blocked`; it is never silently treated as passed.
|
|
|
|
## Evidence rules
|
|
|
|
- `commit` identifies the implementing or verifying revision when available;
|
|
- `testEvidence` references exact commands, test reports, traces or report paths;
|
|
- `browserEvidence` references browser flows, screenshots or traces where relevant;
|
|
- `notes` explains limitations and causal context;
|
|
- `exceptionId` is mandatory in practice for `accepted-exception` and null otherwise;
|
|
- release artifacts include SHA-256 digests.
|
|
|
|
## Summary consistency
|
|
|
|
The summary counts must equal the requirement statuses. Overall status can be `passed` only when no requirement or mandatory gate is failed or blocked and every accepted exception is explicitly approved.
|
|
|
|
## Required gates
|
|
|
|
At minimum the final matrix records:
|
|
|
|
- build-pack validation;
|
|
- formatting, lint and typecheck;
|
|
- unit, integration, contract, security and browser suites;
|
|
- production build and container health;
|
|
- migration from a fresh database;
|
|
- 28 golden prompt conformance;
|
|
- clean-room installation;
|
|
- backup and restore drill;
|
|
- performance target report;
|
|
- dependency, license and secret scans;
|
|
- final documentation and handoff review.
|