Production Test and Verification Plan Prompt

Build a risk-based test and verification plan for the following software change or release.

Inputs
- Change or release under test: [Change or release under test]
- Repository and relevant files: [Repository and relevant files]
- System and runtime context: [System and runtime context]
- Acceptance criteria: [Acceptance criteria]
- Test and deployment constraints: [Test and deployment constraints]
- Available evidence: [Available evidence]
- Authorized actions and environment: [Authorized actions and environment]
- CI/CD and rollback context: [CI/CD and rollback context]

Codex operating boundaries
- Use Codex to inspect supplied repository content, diffs, configuration, test suites, CI definitions, logs, and command output that are actually available in the session.
- Run tests or read additional files only when the environment provides that capability and the authorized-actions input permits it. Prefer targeted, read-only inspection before expensive or state-changing commands.
- Do not deploy, merge, approve a release, alter production, access undeclared systems, expose secrets, create real customer data, disable safeguards, or run destructive commands. Treat migrations, load tests, security probes, external API calls, and commands that write or delete data as approval-gated.
- Stop before an action if its target, blast radius, data handling, cost, reversibility, or authorization is unclear. Record the blocked action, required approval, and a safe alternative.
- Never imply that a command ran merely because it was proposed. Never claim that code is fixed, tests passed, coverage improved, a release was approved, a rollback works, or a deployment completed without corresponding execution evidence.

Input and evidence rules
1. Treat the change target, acceptance criteria, repository or equivalent technical artifacts, runtime context, and authority scope as prerequisites for an execution-backed assessment. If one is missing, ask only the questions necessary to unblock it.
2. If execution is blocked but supplied artifacts are sufficient, produce a bounded plan and mark execution-dependent conclusions unverified. If the change boundary or acceptance criteria cannot be established, do not issue a release-confidence recommendation.
3. Maintain an evidence ledger that distinguishes supplied facts, direct Codex observations, command execution evidence, assumptions, hypotheses, conflicts, and unknowns. Cite file paths, symbols, diff locations, log excerpts, CI job names, test identifiers, commands, exit codes, or artifact locations where available.
4. Do not resolve conflicting documentation, code behavior, logs, or requirements by guessing. Describe the conflict, its verification impact, and who must resolve it.
5. Do not infer test success from the existence of test files, infer production behavior solely from mocks, or equate code coverage with behavioral correctness.

Assessment workflow
1. Establish scope and baseline
   - Identify changed components, interfaces, dependencies, data stores, feature flags, configuration, infrastructure, schemas, jobs, and user journeys.
   - Determine the comparison baseline and whether generated files, lockfiles, migrations, API contracts, or deployment manifests changed.
   - Record exclusions and distinguish intentional scope limits from unavailable evidence.

2. Perform change-impact and risk analysis
   - Trace affected call paths, consumers, upstream and downstream integrations, shared libraries, background work, cache behavior, concurrency boundaries, and compatibility requirements.
   - Rate each material risk by likelihood and impact. Include regression, data integrity, authorization, privacy, availability, performance, observability, backward compatibility, migration, retry or idempotency, and rollback risks when relevant.
   - Prioritize tests by risk reduction rather than test count.

3. Build acceptance traceability
   - Decompose each acceptance criterion into observable behavior.
   - Map it to one or more unit, component, integration, contract, end-to-end, migration, security, performance, resilience, or manual checks as appropriate.
   - Define setup, fixtures or test data, action, expected result, required evidence, cleanup, and ownership for every check.
   - Include negative paths and boundaries such as empty, null, malformed, duplicate, maximum-size, timeout, partial-failure, retry, race, permission-denied, stale-cache, and dependency-unavailable conditions where applicable.

4. Evaluate existing verification assets
   - Identify relevant tests and assess whether their assertions prove the required behavior rather than merely execute code.
   - Detect missing assertions, over-mocking, nondeterministic time or randomness, shared-state leakage, order dependence, brittle snapshots, unsafe fixtures, hidden network access, and flaky retries.
   - Review CI triggers, path filters, matrices, service dependencies, caches, artifacts, timeouts, required checks, branch protections, and failure propagation for gaps that could produce false confidence.

5. Specify the verification sequence
   - Order checks from fast and isolated to broad and operational: static checks, targeted unit tests, component or integration tests, contracts, migrations, end-to-end paths, non-functional checks, and manual exploration.
   - Provide exact commands only when supported by repository evidence. Otherwise label commands as proposed and identify what must be confirmed.
   - Separate blocking release gates from advisory checks. Define retry policy, flaky-test handling, artifact retention, test-data cleanup, and ownership of failures.

6. Execute only authorized checks
   - Before each command, state its purpose, environment, expected side effects, and why it is within authority.
   - Capture the exact command, working directory, relevant environment details with secrets redacted, start and finish state, exit code, actual observation, and artifact reference.
   - Do not silently rewrite code or tests to make checks pass. If modification is expressly authorized, present the proposed patch and its rationale separately, then verify it with fresh evidence.
   - Classify each check as passed, failed, blocked, not run, or inconclusive. A zero exit code is not sufficient when assertions, logs, skipped-test counts, or produced artifacts contradict success.

7. Assess deployment and recovery readiness
   - Verify pre-deployment prerequisites, configuration compatibility, secret references without revealing values, migration ordering, backward and forward compatibility, feature-flag behavior, health checks, and capacity assumptions where relevant.
   - Define post-deployment smoke tests and observability signals with query or dashboard source, baseline, threshold, observation window, and owner. Cover errors, latency, saturation, queue lag, data reconciliation, and key business behavior as applicable.
   - Specify rollback or roll-forward triggers, decision owner, procedure reference, data consequences, compatibility limits, recovery verification, and cases where rollback is unsafe, such as irreversible schema or data transformations.

8. Reconcile evidence and determine confidence
   - Reconcile every acceptance criterion, risk, test result, defect, skipped check, and conflicting observation.
   - Recommend exactly one state: Ready, Conditionally ready, Not ready, or Unassessed. This is a technical recommendation, not release approval.
   - Ready requires all blocking criteria to have passing evidence and no unresolved release-blocking defect or unknown. Conditionally ready requires explicit conditions, owners, and deadlines. Not ready requires named blockers. Unassessed applies when evidence is insufficient to support a conclusion.

Required deliverable
A. Scope and evidence ledger
- Change boundary, baseline, affected systems, exclusions, authority scope, and environment.
- Evidence table with ID, classification, source or artifact, observation, reliability limitation, and related conclusion.
- Assumptions, unknowns, and conflicts, each with impact and resolution owner.

B. Change-impact and risk register
- Component or behavior, change mechanism, dependent systems, failure mode, likelihood, impact, detectability, risk priority, proposed control, and residual risk.

C. Acceptance-to-test matrix
- Criterion ID, observable behavior, risk covered, test level, setup and data, procedure or command, expected observation, required evidence, cleanup, owner, priority, and status.

D. Existing test and CI assessment
- Relevant test or job, what it proves, identified gap, flakiness or isolation concern, CI gate status, and recommended correction.

E. Execution record
- Check ID, proposed or executed state, exact command or manual procedure, environment, expected observation, actual observation, exit code when applicable, duration when known, evidence reference, and result classification.

F. Defect and unresolved-work register
- Defect or gap ID, reproduction evidence, affected criterion, severity, release impact, workaround, owner, and retest requirement. Keep proposed fixes separate from applied changes.

G. Deployment, observability, and recovery checks
- Pre-deployment gates, smoke tests, monitored signals, baselines and thresholds, observation windows, rollback or roll-forward triggers, recovery procedure references, data reconciliation, and responsible approvers.

H. Verification verdict
- Recommended state, evidence-backed rationale, passed blocking gates, failed or missing gates, residual risks, approval still required, and the smallest safe next action.

Use concise technical language. Preserve unresolved states and make every consequential conclusion traceable to evidence.