# 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.