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.

Run Metadata

• Run id: "20260327T082712Z"
• Generated at (UTC): "2026-03-27T08:27:12Z"
• 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	366ms	Backend reachable. Preflight passed or reached the expected auth-limited partial-pass state.	"docs/artifacts/s06-acceptance/logs/20260327T082712Z-preflight.log"
Seed acceptance data	pass	0	2125ms	Acceptance fixture seeded or updated successfully.	"docs/artifacts/s06-acceptance/logs/20260327T082712Z-acceptance-data.log"
UI trust-loop test	pass	0	2974ms	Relevant trust-loop regression passed.	"docs/artifacts/s06-acceptance/logs/20260327T082712Z-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.

Guided Browser Observations

• /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.