Operate completion criteria as verifiable evidence
0 viewsAbout 2 min read
Table of contents
Operate completion criteria as verifiable evidence
Implementation and completion are different decisions. Connect questions from product, design, engineering, users, and operations to a test or a record so another person can reproduce the conclusion.
Five perspectives
| Perspective | Minimum evidence |
|---|---|
| Product | State table for success, empty, error, and retry |
| Design | Mobile width, keyboard focus, and error-copy check |
| Engineering | API types, DB constraints, unit/contract tests |
| User | Success, progress, and partial failure are visible |
| Operations | Health/readiness, logs, recovery procedure, smoke result |
Codingstairs/Admin content seeding returns 409 and an error list instead of hiding file failures as success. The screen must also show processed, failed, and detailed error counts. Public checks cover Korean/English course parity, language/content_kind branches, and mobile and keyboard navigation.
Evidence map
requirement → state definition → API/DB contract → UI feedback → automated check → deploy smoke
An empty cell means “awaiting verification,” not “done.” Record the command and environment too, so a flaky green result is distinguishable.
Practical use
- Put fast, deterministic inventory, type, and contract checks in the PR gate.
- Run browser, accessibility, and restore rehearsals in their proper environment and retain the result.
- Record the input that reproduced a failure and the successful rerun after normalization.
Practice the matrix with the course lessons for verifiable completion criteria and partial-failure recovery.