Step 12
Step 12 — Verify a change with five perspectives and deployment smoke
1 views
This verification step is not about adding another technology. It proves that a change is actually finished, from source content through the console, DB, Docker, a static mirror, and production. The next step checks whether the same evidence survives partial failure and recovery across services.
| Perspective | Evidence |
|---|---|
| product | normal, empty, partial-failure, and recovery states are defined |
| design | mobile, keyboard, focus, error, and retry states were checked |
| engineering | bilingual content, types, SQL constraints, indexes, and tests pass |
| user | SSR and Fly have the same meaning and explain current state |
| operations | SHA image, readiness, real DB smoke, logs, and rollback exist |
From five perspectives to public smoke
choose completion conditions for normal, empty, and partial failure.
expose the next action on mobile, keyboard, and error states.
make API, DB, cache, and tests point to one contract.
distinguish success, progress, and failure, with a safe retry path.
connect readiness, DB smoke, public URLs, and rollback evidence.
Release order
- Check a clean worktree and exclude the developer folder.
- Run console/content checks and builds.
- Deploy SSR to PROD with a Git-SHA image and a real public-read smoke.
- Use the authenticated console to upsert
courses/andnotes/into the content database. - Verify the export contains the new bilingual content, then run
fly deploy --no-cachefor the static mirror. - Check
/,/en, course and note routes, search, sitemap, and healthcheck on both targets.
Payments, gRPC, WebSocket, WebRTC, media, conversational voice, and remote CI may lack a product/operations contract or conflict with repository policy. Record adoption conditions and defer them instead of pretending that a larger scope is safer.
Only the execution log and release tag make this complete.