Step 12 — Verify a change with five perspectives and deployment smoke

This verification step is not about adding another technology. It proves that a change is actually finished, from source content through Admin, DB, Docker, Fly, and production. The next step checks whether the same evidence survives partial failure and recovery across services.

From five perspectives to public smoke

1Product

choose completion conditions for normal, empty, and partial failure.

2Design

expose the next action on mobile, keyboard, and error states.

3Engineering

make API, DB, cache, and tests point to one contract.

4User

distinguish success, progress, and failure, with a safe retry path.

5Operations

connect readiness, DB smoke, public URLs, and rollback evidence.

Warragon release order

1. Check a clean worktree and exclude the developer folder.
2. Run Admin/Codingstairs content checks and builds.
3. Deploy Codingstairs SSR to PROD with a Git-SHA image and a real public-read smoke.
4. Use the authenticated Admin screen to upsert courses/ and notes/ into the Codingstairs database.
5. Verify the export contains the new bilingual content, then run fly deploy --no-cache for the static mirror.
6. Check /, /en, course and note routes, search, sitemap, and healthcheck on both targets.

Payments, gRPC, WebSocket, WebRTC, media, conversational voice, and GitHub Actions have no current Warragon product/operations contract or conflict with repository policy. Record their adoption conditions and defer them instead of pretending that a larger scope is safer.

Only the execution log and release tag make this complete.

Read next

• Release, smoke, and rollback evidence
• Next step