Step 7
Turn completion criteria into verifiable evidence
0 views
Table of contents
Turn completion criteria into verifiable evidence
Define “done” as evidence another person can reproduce, not as a feeling. This lets product, design, engineering, users, and operations share the same finish line.
1. Five perspectives
| Perspective | Question | Example evidence |
|---|---|---|
| Product | Are the requested states and exceptions defined? | State transition table, allow/deny cases |
| Design | Are keyboard, mobile, and error states designed? | Focus order, empty state, failure copy |
| Engineering | Do API, DB, and cache contracts agree? | Typecheck, unit tests, SQL constraints |
| User | Can people understand success, progress, and failure? | role=status, retry guidance, smoke test |
| Operations | Can the change be deployed, observed, and recovered? | Health/readiness, logs, rollback record |
2. Apply it to Codingstairs/Admin
Codingstairs content lives as Korean/English file pairs under the monorepo notes/ and courses/ roots. If an Admin seed file fails, the API must return HTTP 409 with the error list, and the screen must show the count and retry reason. Checking only a success response is not completion evidence.
Verify the public paths as well:
- Course steps start at 1, remain contiguous, and correspond across languages.
- Published, category, and keyword queries apply both
languageandcontent_kind. - Invalid lesson steps are rejected by both the Admin API and the database CHECK.
- Error details can be opened on mobile and the action is keyboard accessible.
3. Verification matrix
requirement → state/error definition → API/DB contract → UI feedback → automated test → deploy smoke
An empty cell means “awaiting verification,” not “implemented.” Record a command or log location in every cell so the next person can reproduce the result.
4. Start with small gates
Do not turn every screen into E2E at once. Put fast, deterministic checks such as the content inventory, typecheck, Admin seed errors, and Compose health contracts in the PR gate first. Run browser and restore rehearsals in their appropriate environments and retain the result as evidence.
Checklist
- Success and partial-failure responses and UI were checked.
- Keyboard, narrow viewport, empty data, and error states were checked.
- API validation and the DB constraint reject the same invalid range.
- Command, result, and environment were recorded.
Next
- 08-partial-failure-recovery
- /notes/data/16-idempotent-migration-recovery