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: "20260327T082247Z"
- Generated at (UTC): "2026-03-27T08:22:47Z"
- 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 | 372ms | Backend reachable. Preflight passed or reached the expected auth-limited partial-pass state. | "docs/artifacts/s06-acceptance/logs/20260327T082247Z-preflight.log" |
| Seed acceptance data | pass | 0 | 2048ms | Acceptance fixture seeded or updated successfully. | "docs/artifacts/s06-acceptance/logs/20260327T082247Z-acceptance-data.log" |
| UI trust-loop test | pass | 0 | 2950ms | Relevant trust-loop regression passed. | "docs/artifacts/s06-acceptance/logs/20260327T082247Z-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:** The live job table rendered the seeded row `S06 Acceptance Labs • S06 Acceptance Backend Engineer` with `Follow up`, `CV ready`, and `Waiting` badges. Jobs-page screenshot/debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-17-55-372Z-s06-jobs-workspace`.
- **Workspace / Tailored CV:** Opening the seeded job from `/jobs` loaded the real workspace dialog and showed the saved tailored-CV/application-package content for the acceptance fixture. The tailored CV textarea contained the seeded text beginning `Saved acceptance tailored CV highlighting ASP.NET Core delivery...`.
- **Workspace / Correspondence:** The correspondence tab showed the seeded recruiter-thread message (`Backend Engineer follow-up`) inside the real workspace. The live UI did **not** visibly surface the newer `Linked Gmail thread continuity` banner text during this pass even though the seeded correspondence was present. No `POST /api/gmail/refresh-linked-threads` request fired in the captured browser network log, so Gmail continuity should be treated as **not configured / not refreshed in this local run**, not as a proven live Gmail sync success.
- **Workspace / Follow-up draft / manual-send boundary:** The follow-up draft tab rendered the real draft flow with a generated subject/body plus separate `Copy Draft` and `Send And Log Email` actions. Network evidence showed `GET /api/jobapplications/3/followup-draft -> 200` and **no** `POST /api/jobapplications/3/send-followup` request during observation, so the manual-send boundary held: opening/regenerating the draft did not auto-send mail. Follow-up draft debug artifact: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-19-39-323Z-s06-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`. This was explicitly asserted in-browser.
- **/dashboard:** The dashboard route loaded cleanly and 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 earlier navigation noise and reloading `/dashboard`, browser assertions confirmed **no console errors** and **no failed requests**. Dashboard debug artifacts: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-20-06-098Z-s06-dashboard` and `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-20-47-319Z-s06-reminders-and-dashboard`.
- **Trace / timeline evidence:** Browser trace zip: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-17-13-689Z-session/s06-acceptance.trace.zip`. Browser timeline JSON: `/home/pi/development/JobTracker/.artifacts/browser/2026-03-27T08-17-13-689Z-session/s06-acceptance-timeline.json`.
- **Known live gap called out for handoff:** This run proves the individual-first `/jobs -> workspace -> reminders/dashboard` loop and the manual-send boundary, but it 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 -->