93 lines
5.1 KiB
Markdown
93 lines
5.1 KiB
Markdown
# 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`
|