jobtrackingapp/docs/deployment/manual-smoke-test.md

Manual smoke test — post-deployment

Run this after every production deploy, in a real browser, signed in as a real user.

Authentication requires the owner. No step here is automated and no password is handled by any tool or script — signing in is the owner's job. The automated suite verifies the authorization boundary exists (every user endpoint returns 401 unauthenticated); only a human with credentials can verify what is behind it.

Each item names what wrong looks like, because "it loaded" is not a check. Stop and consider rollback on any ✗.

Authentication

• Login succeeds with an existing account. ✗ = password rejected, or a 5xx on submit.
• Existing session works — reload the page after login and stay signed in. ✗ = session drops on refresh, which means AUTH_JWT_KEY changed between deploys.
• Logout works and returns to the signed-out state. ✗ = still authenticated after logout.

Applications

• Existing applications load. ✗ = empty list for a user who had applications.
• Counts are correct — the number matches what you saw before the deploy. ✗ = any drop. This is the single most important check.
• Workspace opens for one application — Overview, Checklist, Timeline, Analysis, Match render. ✗ = a section erroring. Empty new sections on old applications are correct, not a fault.

Career profile

• Profile loads with real experience, education and skills.
• Languages are present. ✗ = languages missing, or reduced to English only. That is the 9681618 / fba858e ICU-dependence class of bug; if it reappears the container's ICU differs from what was tested. Check a profile that lists Norwegian specifically.
• Structured career data is intact — experiences, education, projects, certifications all show their fields, not blanks.
• No data loss from the relational migration — spot-check a profile edited before the deploy against what you remember. ✗ = fields silently emptied.

CV builder

• Existing CV variants load in the builder list; open one.
• Editing works — change a field, confirm autosave persists after reload.
• Preview works — the themed preview renders the variant.
• PDF export works — export produces a valid PDF (this exercises the in-container Chromium). ✗ = export hangs or errors, usually a Chromium/CV_PDF_BROWSER_PATH problem.
• Public CV loads directly after refresh — open /cv/<slug> for an already-public variant, then hard-refresh. ✗ = 404 on refresh, which is SPA deep-link routing, not the CV itself.

AI features

• AI generation works — run one generation (interview prep or cover letter). ✗ = 5xx or an indefinite hang. If ai-service is down the deploy still succeeds (AI is not a deploy gate), so this must be checked by hand.
• Suggestions are generated and shown for review.
• No unwanted writes occur — the generation does not modify the Career Profile, a CV variant, or application fields until you explicitly save. Confirm the source records are unchanged after generating but before saving. ✗ = anything written without your action.

Files

• Attachment upload — upload a file to an application; it appears in the list.
• Attachment download — download an existing attachment from an old application. ✗ = 404, which means the jobtracker_data volume did not survive the deploy.
• Permissions — confirm you cannot reach another user's attachment. Signed in as user A, requesting user B's attachment id must return 404/403, never the file. (The automated suite already asserts tenant scoping; this is the human confirmation.)

After the checklist

• /health reports the version you deployed, not 1.0.0.0 (the assembly fallback means APP_VERSION did not reach the container).
• Row counts for applications and companies still match the pre-deploy numbers.