# Spec-to-Release Evidence Desk

Local-first worksheet for software developers and teams using AI coding assistants. Adapt it to the project's actual repository rules, architecture, security model, privacy obligations, accessibility target, release process, and incident procedures. Never paste secrets, credentials, tokens, private customer data, proprietary code, or access-controlled material into an unapproved AI service.

## 1. Job and permission card

- Change/request ID: ____________________
- User problem and expected outcome: ____________________
- Repository/service and owner: ____________________
- In-scope paths/components: ____________________
- Out-of-scope paths/systems: ____________________
- Approved AI tools and data/code permissions: ____________________
- Forbidden commands/actions: ____________________
- Human reviewer: ____________________
- Merge authority: ____________________
- Deploy authority: ____________________
- Risk level: low / medium / high / security-sensitive / data-sensitive

## 2. Requirement and source ledger

| Req ID | Requirement/acceptance criterion | Authoritative source | User-visible? | Risk if wrong | Human confirmed? |
|---|---|---|---|---|---|
| R-01 |  |  | Yes / No |  | Yes / No |
| R-02 |  |  | Yes / No |  | Yes / No |

Include failure behavior, permissions, privacy, security, accessibility, performance, observability, migration, rollback, and compatibility requirements where applicable.

## 3. Architecture and change plan

| Decision | Options considered | Chosen approach | Evidence/tradeoff | Reviewer |
|---|---|---|---|---|
|  |  |  |  |  |

- Files/components expected to change: ____________________
- Existing patterns to reuse: ____________________
- Data/schema/API impact: ____________________
- Dependency change and provenance review: ____________________
- Threat/abuse cases: ____________________
- Accessibility impact: ____________________
- Rollback or feature-disable route: ____________________

AI may propose. A responsible developer approves the plan before broad or high-risk edits.

## 4. Implementation evidence log

| Change unit | Files changed | Why | AI role | Human inspection | Unexpected effects |
|---|---|---|---|---|---|
| C-01 |  |  | drafted / edited / none | pending / passed / revised |  |

Do not hide copied code, generated dependencies, assumptions, warnings, test failures, or manual steps.

## 5. Verification matrix

| Acceptance criterion/risk | Test type | Exact environment/command | Expected | Actual evidence | Status |
|---|---|---|---|---|---|
|  | unit / integration / browser / accessibility / security / performance / manual |  |  |  | pass / fail / blocked |

Required questions:

- [ ] Happy path and realistic failure paths were tested.
- [ ] Authorization and data-boundary checks were tested where relevant.
- [ ] No secret, credential, private data, or unsafe debug output was introduced.
- [ ] Dependencies and generated code received provenance/security review.
- [ ] Accessibility was tested with applicable automated and human checks.
- [ ] Tests prove the requested behavior, not merely that the build runs.
- [ ] Known failures and untested areas remain visible.

## 6. Review and merge packet

- Requirement links: ____________________
- Scoped diff reviewed: Yes / No
- Test evidence attached: Yes / No
- Security/privacy review required/completed: ____________________
- Accessibility review required/completed: ____________________
- Migration/backfill evidence: ____________________
- Known limitations: ____________________
- Reviewer decision: approve / request changes / reject
- Reviewer and date: ____________________
- Merge performed by authorized human/process: ____________________

No AI confidence statement counts as review evidence.

## 7. Release, rollback, and monitoring card

- Release target/environment: ____________________
- Exact artifact/commit/version: ____________________
- Deployment owner and approval: ____________________
- Staging/canary evidence: ____________________
- Rollback/disable trigger: ____________________
- Rollback steps tested: Yes / No / Not applicable, why: __________
- Health, error, latency, security, and business signals: ____________________
- Observation window and owner: ____________________
- Incident/escalation route: ____________________
- Release result and evidence: ____________________

AI may prepare this card. It does not merge, deploy, rotate secrets, change production data, or close an incident without the authorized human/process.

## Safe prompt

> Act as a software engineering preparation assistant, not a product owner, security approver, reviewer, merger, deployer, or incident commander. Using the supplied repository rules and requirement ledger, produce: (1) unanswered requirement questions, (2) a scoped change plan, (3) candidate tests mapped to acceptance criteria and failure modes, (4) security/privacy/accessibility review flags, and (5) a release/rollback evidence checklist. Do not invent requirements, claim tests ran, hide failures, expose secrets, add unreviewed dependencies, execute destructive commands, merge, deploy, or change production data. Mark assumptions and unverified areas explicitly.