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: "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.

Guided Browser Observations

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