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.
Table of contents
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 |
Content-console 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.