jobtrackingapp/.gsd/milestones/M001/slices/S03/S03-UAT.md

S03: Reply and follow-up drafting from real thread context — UAT

Milestone: M001 Written: 2026-03-24

UAT Type

• UAT mode: mixed
• Why this mode is sufficient: S03 changes both backend draft assembly and the per-job Follow-up workspace, so the right acceptance script combines artifact-backed checks (focused backend/frontend tests and build) with a human review of draft specificity, editability, and the manual-send boundary.

Preconditions

• The API and UI for this worktree are running from /home/pi/development/JobTracker/.gsd/worktrees/M001.
• A job exists with all of the following:
  • imported Gmail correspondence tied to the job
  • recruiter email populated on the company/job
  • saved tailored CV, cover letter, recruiter message, and/or saved application-answer draft material
• The tester can open that job in the job workspace.
• No autonomous outbound-email automation is enabled anywhere in the environment.

Smoke Test

Open one seeded job, switch to the Follow-up tab, and confirm the tab shows a generated draft plus a visible context panel that names the thread/package grounding rather than only a blank email form.

Test Cases

1. Generate a thread-grounded follow-up draft

1. Open a job that already has imported correspondence and saved application package material.
2. Open the Follow-up tab.
3. Wait for the draft to load.
4. Review the context panel above/alongside the draft.
5. Expected:
   • a draft subject and body are generated
   • the UI shows why the draft was generated now (for example, waiting-update timing)
   • the UI shows thread/package grounding such as thread subject, latest sender, context summary, or context signals
   • the draft content feels tied to the actual thread stage and saved package context instead of reading like a generic template

2. Edit the draft before sending and verify manual-send behavior

1. In the Follow-up tab, edit the generated subject and/or body.
2. Confirm the recipient field is editable or clearly visible before any send action.
3. Verify the helper text/button copy makes the manual-send boundary explicit.
4. Click Send and log email.
5. Expected:
   • nothing is sent before the explicit button click
   • the edited draft text, not the original generated text, is what gets submitted
   • the workflow behaves like a manual send/log action rather than background automation
   • there is a clear success state or logged result after submission

3. Confirm the sent follow-up reappears in job history/correspondence

1. After sending/logging the follow-up, switch to the job’s correspondence/history surface.
2. Refresh the job workspace if needed.
3. Find the newly logged outbound follow-up entry.
4. Expected:
   • the sent/logged follow-up appears back in the same job timeline/correspondence record
   • the entry is attached to the correct job and thread context
   • the app reflects history continuity instead of treating the send as an isolated compose event

Edge Cases

Missing package or thin thread context still preserves user control

1. Open a job that has weaker context than the happy path (for example, imported correspondence but little/no saved package material, or saved package material but only a thin thread).
2. Generate a follow-up draft.
3. Expected:
   • the app still returns an editable draft or a clearly explained degraded draft state
   • the UI reflects missing/limited grounding rather than pretending the draft is strongly informed
   • the manual-send boundary remains unchanged: no autonomous send occurs, and the user still must explicitly send/log

Failure Signals

• The Follow-up tab loads only a blank compose form with no visible context grounding.
• The generated draft ignores obvious thread details (subject, recruiter, recent message content) and reads like a generic reminder.
• Editing the draft does not persist into the send/log request.
• A follow-up appears to be sent or logged without an explicit user action.
• The sent follow-up does not return to the job’s correspondence/history surface.
• The tab crashes, build/test regressions appear, or the follow-up endpoint no longer returns the grounding fields expected by the UI.

Not Proven By This UAT

• This UAT does not prove Gmail OAuth/import itself; that was covered by S01 and is only consumed here as prerequisite context.
• This UAT does not prove end-to-end milestone coherence across table/dashboard/control-loop surfaces; S04 and S05 still own that broader workflow validation.

Notes for Tester

Use a job with real-looking imported thread content and saved package material; otherwise the quality signal will be too weak to judge whether S03 actually improved grounding. If the environment cannot support live send/log execution, fall back to the focused checks that already passed for this slice:

• $HOME/.dotnet/dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests
• CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-followup-drafts.test.tsx
• CI=true npm --prefix job-tracker-ui run build