jobtrackingapp/docs/s06-acceptance-run.md

# S06 Acceptance Run

This document captures the live S06 acceptance rerun for the "/jobs → workspace → reminders/dashboard → follow-up/manual-send boundary" loop.

<!-- acceptance-run:generated:start -->
## Run Metadata

- Run id: "20260327T085659Z"
- Generated at (UTC): "2026-03-27T08:56:59Z"
- API base: "http://localhost:5202/api"
- Auth token source: minted-local-dev-admin
- Overall runner result: **pass**

## Shell Verification Summary

| Step | Status | Exit | Duration | Notes | Log |
|---|---|---:|---:|---|---|
| Preflight | pass | 0 | 479ms | Backend reachable. Preflight passed or reached the expected auth-limited partial-pass state. | "docs/artifacts/s06-acceptance/logs/20260327T085659Z-preflight.log" |
| Seed acceptance data | pass | 0 | 2596ms | Acceptance fixture seeded or updated successfully. | "docs/artifacts/s06-acceptance/logs/20260327T085659Z-acceptance-data.log" |
| UI trust-loop test | pass | 0 | 3083ms | Relevant trust-loop regression passed. | "docs/artifacts/s06-acceptance/logs/20260327T085659Z-end-to-end-trust-loop.log" |

## Runner Observations

- Preflight is the only hard-stop gate. If the backend is unreachable, this runner exits non-zero after recording the failure.
- Seeding failures and UI regression failures are still written into this artifact so auth/test blockers are visible instead of disappearing behind a shell exit.
- Secrets are redacted by design: the runner never prints bearer tokens and only records the token source category.

## Auth / Blocker Guidance

- If the environment already exported "AUTH_TOKEN", the runner reuses it.
- If "AUTH_TOKEN" is missing and the API base is the default localhost dev target, the runner attempts a **local dev JWT fallback** using the checked-in dev JWT settings plus the local SQLite admin user so acceptance seeding can proceed without printing a token.
- If the fallback cannot mint or validate a token, treat the seed/browser run as **auth blocked**. In that case, log in via "POST /api/auth/login" with the real local account (or reuse an already-authenticated browser session), export only the access token, and rerun the runner.
- Gmail continuity may legitimately remain blocked when Gmail is not connected/configured for the local user; that is expected to be called out explicitly below instead of triggering auto-send behavior.
<!-- acceptance-run:generated:end -->

## Guided Browser Observations

<!-- acceptance-run:browser:start -->
- **/jobs:** In the rerun session opened after the fresh `20260327T084839Z` acceptance shell pass, the live jobs table rendered the seeded row `S06 Acceptance Labs • S06 Acceptance Backend Engineer` with `Follow up`, `CV ready`, and `Waiting` badges. Current jobs/workspace debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-46-41-172Z-s07-jobs-workspace`.
- **Workspace / Tailored CV:** Opening the seeded job from `/jobs` loaded the real workspace dialog for the same row and showed the saved tailored-CV content already attached to the acceptance fixture. The tailored CV textarea still contained the seeded text beginning `Saved acceptance tailored CV highlighting ASP.NET Core delivery, workflow trust signals...`.
- **Workspace / Correspondence:** The correspondence tab showed the seeded recruiter-thread message (`Backend Engineer follow-up`) inside the real workspace. The live UI still did **not** visibly surface the `Linked Gmail thread continuity` banner text during this pass. No linked-thread refresh activity was observed, so Gmail continuity remains **not configured / not refreshed in this local run**, not a proven live Gmail-sync success.
- **Workspace / Follow-up draft / manual-send boundary:** The follow-up draft tab rendered the real draft flow with separate `Copy Draft` and `Send And Log Email` actions visible in the workspace. In this run, switching to the tab did not emit a fresh captured network request on its own, so the draft endpoint was rechecked directly from the authenticated browser context: `GET /api/jobapplications/3/followup-draft -> 200` returned a subject/body payload and the expected reason text. During the entire browser observation pass, **no** `POST /api/jobapplications/3/send-followup` request was triggered, so the manual-send boundary held: draft viewing stayed preparatory and did not auto-send mail. Follow-up draft debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-44-29-745Z-s07-followup-draft`.
- **/reminders:** The reminders page showed the seeded acceptance job under `Needs Follow-up` with the expected badges `Follow up`, `Waiting 14d`, and `Follow-up: 10/03/2026`. Those values were explicitly asserted in-browser. Reminders debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-44-55-926Z-s07-reminders`.
- **/dashboard:** The dashboard route reflected the integrated seeded state: `Active applications = 2`, `Applied (30 days) = 2`, `Responses logged = 1`, and `Top companies by activity` included `S06 Acceptance Labs`. After clearing diagnostics and reloading `/dashboard`, browser assertions confirmed **no console errors** and **no failed requests** for the clean dashboard pass. Dashboard debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-46-10-205Z-s07-dashboard`.
- **Trace / timeline evidence:** Browser trace zip: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-38-51-567Z-session/s07-acceptance.trace.zip`. Browser timeline JSON: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-38-51-567Z-session/s07-acceptance-timeline.json`.
- **Known live gap called out for handoff:** This rerun proves the individual-first `/jobs -> workspace -> reminders/dashboard` loop and the manual-send boundary, but it still does **not** prove a Gmail-connected continuity refresh because the local browser session did not expose connected Gmail state or run a linked-thread refresh request.
<!-- acceptance-run:browser:end -->