readiness

Release readiness

Judge the proposed use and consequence, not the polish of the preview. This is a scoped readiness review, not a security certification or authorization to launch.

Work

• Identify the artifact, intended audience, data sensitivity, exposure, and claimed readiness. Recover intent from the brief, code, or user context; missing documentation does not prevent inspecting obvious risks.
• Verify the primary task and its critical failure paths. Distinguish real behavior, mocks, and unverified integration.
• Assess data persistence and recovery, server authorization and tenant isolation, input validation, secrets, async writes, accessibility, deployment, observability, and rollback as applicable.
• Use pass, fail, unverified, or not applicable with reasons and evidence.
• Name must-fix items for the intended use. A real-data pilot still requires access enforcement and a data recovery decision.
• Record accepted risk only when an actual authorized person accepted it. Otherwise label it a proposed deferral with owner and revisit condition to resolve.

Deliver

Lead with the supported use or blocking conclusion. Follow with area → evidence/status → impact → required action, then checks performed and unknowns. Keep the review focused on the existing product promise.

## Readiness review

Artifact: Stated use: demo | pilot | production Supported use: Promise still true? yes / no — [one line]

Score

Area	Demo	Pilot	Production	Notes
Data & persistence
Auth & permissions
Gap states
Security (UI-owned)
Tests & preview
Observability & rollback

Must fix before treating this as [level]

• [item]

Accept explicitly

• [risk] — accepted by [who] — revisit when [signal]

Next artifact

Do not publish, message stakeholders, alter permissions, or claim compliance as a side effect of review. Use `$states` for targeted recovery work and `$craft` when visible quality also needs evaluation.

## Worked example

```markdown
## Readiness review

**Artifact:** `https://preview.example.com/dashboard`
**Stated use:** production (client asked to "just launch")
**Supported use:** demo only; pilot after the must-fix items below
**Promise still true?** Partially: the primary job works; billing and invites are stubs

### Score
| Area | Demo | Pilot | Production | Notes |
|---|---|---|---|---|
| Data & persistence | Pass | Fail | Fail | Real DB; no backup or recovery decision yet |
| Auth & permissions | Pass | Fail | Fail | Login works; admin delete has no server check |
| Gap states | Pass | Fail | Fail | Empty dashboard renders blank |
| Security (UI-owned) | Pass | Fail | Fail | Delete fires from hidden UI without server enforcement |
| Tests & preview | Pass | Fail | Fail | Preview exists; no CI checks on the delete path |
| Observability & rollback | Unverified | Unverified | Unverified | No error tracking; rollback leaves stored deletes in place |

### Must fix before treating this as pilot
- Enforce server-side permission on delete and admin routes; hidden UI is not enforcement
- Decide data recovery for the pilot: backups, or a named person accepting the risk
- Add empty and error states to the project list with retry that preserves input
- Name the use to the client: pilot, not launch

### Accept explicitly
- English only: accepted by the PM; revisit at the first EU customer

### Next artifact
`$states` on dashboard and project list; then a written client note on pilot limits.

Gotchas

• A score table invites averaging: five passes and one fail reads as mostly ready, but the fail decides the level.
• Login proves identity, not permission; verify server enforcement on every consequential action.
• Hidden UI is not enforcement; probe the endpoint directly as an unauthorized identity.
• Risk is accepted only by a named authorized person with a revisit signal; otherwise it is a proposed deferral with an owner.
• A rollback leaves stored changes and external effects in place; name the recovery decision.

Boundaries

• Do not use to build or harden the workflow; use $slice instead. With nothing runnable, report that no use is supported yet and name the smallest path to make it runnable.
• Do not use when the question is only visual drift or token and component divergence; use $system instead.
• Do not use when the question is only missing states; use $states instead.