Skip to main content
codingstairs

Step 7

Turn completion criteria into verifiable evidence

4 views

Table of contents

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 a content console

Content lives as Korean/English file pairs under the monorepo notes/ and courses/ roots. If a console 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:

  1. Course steps start at 1, remain contiguous, and correspond across languages.
  2. Published, category, and keyword queries apply both language and content_kind.
  3. Invalid lesson steps are rejected by both the Admin API and the database CHECK.
  4. 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