fix(auth): Google Sign-In audience mismatch + remove per-user accent color

Root cause of "Google authentication failed": appsettings.Development.json
had Auth:GoogleClientId set to the literal placeholder
"CHANGE_ME_GOOGLE_CLIENT_ID" while the frontend's .env.development had a
real (already-public, already-committed) client ID -- every Google ID
token's audience check failed against the backend's placeholder. Fixed
by setting the same real client ID on both sides (a client ID is a
public identifier, not a secret, safe to commit -- unlike a client
secret). Also enabled Auth:AllowRegistration in dev so the existing
Google-first self-serve-signup path (auto-create on unmatched verified
email, auto-link on matching verified email -- built during Wave 7) is
actually exercisable locally.

Wired the previously-missing Auth__MicrosoftClientId /
NEXT_PUBLIC_MICROSOFT_CLIENT_ID into docker-compose.yml/.env.example
(distinct from the existing MICROSOFT_CLIENT_ID used for Outlook mail
linking) -- Microsoft sign-in was never deployable, a leftover gap from
when it was built. Fixed a stale env-var name in the Microsoft setup
hint copy (still said REACT_APP_*, predates the Next.js migration).

Removed the per-user accent color picker entirely: it was purely
client-side (localStorage + theme.ts), never touched the backend/DB.
theme.ts now hardcodes a single ACCENT constant; themePrefs.ts drops
get/set/clearAccentColor; App.tsx and SettingsView.tsx drop the
accentColor prop threading. Dead accent-related i18n keys removed from
both locales.

Consolidated Settings' "Account" tab (duplicated GoogleAuthCard, which
already lives on the Profile page) into Profile: moved AuthStatusCard
and EmailProviderConnections there alongside the existing Google/
Microsoft auth cards, so identity/account-linking lives in one place.
Settings drops from 5 tabs to 4 and its General tab uses a consistent
SectionCard layout instead of ad-hoc per-card styling.

Verified: dotnet build/test (177/177) and npm build/test (57/57) both
green; confirmed live against a running dev server that /auth/config
now reports googleEnabled with the corrected client ID, Settings has
no accent controls, and Profile shows the consolidated auth section.

.env.example

@@ -5,14 +5,33 @@ AUTH_JWT_KEY=CHANGE_ME_LONG_RANDOM_SECRET
 AUTH_ADMIN_EMAIL=admin@example.com
 AUTH_ADMIN_PASSWORD=CHANGE_ME_STRONG_PASSWORD
 AUTH_GOOGLE_CLIENT_ID=CHANGE_ME_GOOGLE_CLIENT_ID
+# Optional: enables the "Continue with Microsoft" sign-in tab (separate from the
+# MICROSOFT_CLIENT_ID below, which is for Outlook mail linking, not sign-in).
+AUTH_MICROSOFT_CLIENT_ID=
 GOOGLE_GMAIL_CLIENT_SECRET=CHANGE_ME_GOOGLE_OAUTH_CLIENT_SECRET
 # Optional. If omitted, the backend uses https://<your-domain>/api/gmail/oauth/callback
 GOOGLE_GMAIL_REDIRECT_URI=
+MICROSOFT_CLIENT_ID=CHANGE_ME_MICROSOFT_CLIENT_ID
+MICROSOFT_CLIENT_SECRET=CHANGE_ME_MICROSOFT_OAUTH_CLIENT_SECRET
+# Optional. Defaults to "common" (personal + work/school accounts).
+MICROSOFT_TENANT_ID=
+# Optional. If omitted, the backend uses https://<your-domain>/api/microsoft-graph/oauth/callback
+MICROSOFT_REDIRECT_URI=
 AI_SERVICE_BASE_URL=http://ai-service:8001
 # Optional: enables hybrid CV block classification in the local AI service.
 OLLAMA_BASE_URL=http://ollama:11434
 OLLAMA_MODEL=qwen2.5:7b
 
+# AI provider for the heavy /cv/* calls: ollama (default, local) | gemini | groq.
+# /summarize always stays local (distilbart). To offload a weak production GPU,
+# set AI_PROVIDER=gemini (or groq) and provide the matching key below.
+# Keys are read from the environment only — never commit real keys.
+AI_PROVIDER=ollama
+GEMINI_API_KEY=
+GEMINI_MODEL=gemini-2.0-flash
+GROQ_API_KEY=
+GROQ_MODEL=llama-3.3-70b-versatile
+
 # Optional: only needed if you want the UI to call a non-default API base URL.
 # In production the UI defaults to `/api`.
 REACT_APP_API_BASE_URL=

.gitea/workflows/ci-deploy.yml

@@ -13,10 +13,22 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
 
-      - name: Setup .NET
-        uses: actions/setup-dotnet@v4
-        with:
-          dotnet-version: '9.0.x'
+      - name: Setup .NET (resilient)
+        shell: bash
+        # actions/setup-dotnet on this single self-hosted runner intermittently
+        # leaves a partial extraction in the shared tool-cache ("tar: Cannot open:
+        # File exists") or corrupts the SDK download. Install into a clean private
+        # dir via dotnet-install.sh and retry once on failure, mirroring the
+        # npm ci / NuGet retries elsewhere in this workflow.
+        run: |
+          install() {
+            curl -fsSL https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh
+            rm -rf "$HOME/.dotnet"
+            bash /tmp/dotnet-install.sh --channel 9.0 --install-dir "$HOME/.dotnet"
+          }
+          install || ( echo "dotnet install failed ($?) — retrying once..." && install )
+          echo "$HOME/.dotnet" >> "$GITHUB_PATH"
+          "$HOME/.dotnet/dotnet" --info
 
       - name: Setup Node
         uses: actions/setup-node@v4
@@ -39,7 +51,12 @@ jobs:
         run: |
           node -v
           npm -v
-          npm ci --no-audit --no-fund
+          # npm ci occasionally segfaults on the runner (SIGSEGV/139, a memory/native
+          # flake). Retry once with a clean node_modules before failing the job.
+          npm ci --no-audit --no-fund \
+            || ( echo "npm ci failed ($?) — cleaning node_modules and retrying once..." \
+                 && rm -rf node_modules \
+                 && npm ci --no-audit --no-fund )
 
       - name: Test frontend
         working-directory: job-tracker-ui
@@ -53,7 +70,12 @@ jobs:
           CI: 'false'
           GENERATE_SOURCEMAP: 'false'
           NODE_OPTIONS: --max-old-space-size=4096
-        run: npm run build
+        # CRA's build (Terser minify + fork-ts-checker workers) has repeatedly died silently on
+        # this runner with no error output (OOM/SIGSEGV signature — same resource-starved-runner
+        # class as the npm ci and dotnet-install flakes elsewhere in this workflow). Retry once.
+        run: |
+          npm run build \
+            || ( echo "Frontend build failed ($?) — retrying once..." && npm run build )
 
   deploy:
     needs: test

.gitignore

@@ -86,3 +86,4 @@ target/
 
 # ── GSD baseline (auto-generated) ──
 .gsd-id
+.gsd/

.gsd/DECISIONS.md

@@ -1,29 +0,0 @@
-# Decisions Register
-
-<!-- Append-only. Never edit or remove existing rows.
-     To reverse a decision, add a new row that supersedes it.
-     Read this file at the start of any planning or research phase. -->
-
-| # | When | Scope | Decision | Choice | Rationale | Revisable? | Made By |
-|---|------|-------|----------|--------|-----------|------------|---------|
-| D001 | M001 | scope | Product entry point | External job discovery, then import into the app | The user finds jobs on job sites first; the app begins when a role is imported. | No | collaborative |
-| D002 | M001 | pattern | AI action model | Assistive drafting and analysis only; no autonomous sending | The user wants AI help but explicitly does not want auto-send or auto-apply behavior. | No | collaborative |
-| D003 | M001 | scope | Primary user | Individual job seeker | The product is designed for individuals managing their own search, not recruiter or team workflows. | Yes — if product direction changes later | collaborative |
-| D004 | M001 | pattern | Daily navigation hierarchy | Job table first, then follow-up/dashboard, then individual job workspace | The user explicitly described this as the intended control flow for daily use. | Yes — if real usage disproves the hierarchy | collaborative |
-| D005 | M001 | roadmap | First milestone focus | Prioritize Gmail import quality and AI draft quality before broader expansion | The user identified Gmail import and AI drafts as the weakest current areas and the first bar for daily use. | Yes — if execution proves another blocker is more fundamental | collaborative |
-| D006 | M001/S02 | workspace-persistence | How the saved application answer draft should persist inside the job workspace before a dedicated field exists | Store the application answer draft in a replaceable notes block and make SaveApplicationDrafts overwrite notes when notes are explicitly provided | The existing append-only notes behavior made the Tailored CV workspace untrustworthy because repeated saves duplicated the application answer indefinitely. A replaceable notes block preserves current schema compatibility while giving the workspace a stable saved/read-back loop for later slices. | Yes | agent |
-| D007 | M001/S01 | gmail-continuity | What “good Gmail import” now means for M001 | Treat Gmail import as full-thread continuity: the user must be able to import the whole relevant thread, and already-linked Gmail threads must refresh automatically so later inbound messages and user-sent replies appear on the job without manual re-import. This supersedes the narrower one-time-import interpretation inside D005’s Gmail-import focus. | The user explicitly asked whether the app can bring the whole email thread and automatically show their reply later without re-pulling/importing again. That changes the trust bar from “find and import the right message” to “keep the linked thread current over time,” while still preserving the no-auto-send boundary from D002. | Yes — if Gmail API or product constraints later require a different sync model | human |
-| D008 | M001/S01 planning | gmail-sync | How linked Gmail threads stay current in S01 | Use a job-scoped refresh flow over already-imported Gmail thread IDs, triggered from the job workspace/API, instead of building inbox-wide Gmail watch/history cursor infrastructure in M001. | The codebase already persists ExternalThreadId per correspondence and lacks Gmail history/watch infrastructure. Fetching known linked threads for one job keeps scope bounded, fits the single-user workspace model, supports duplicate-safe import of new inbound and sent replies, and creates a trustworthy continuity loop without adding brittle webhook/cursor state before the milestone proves value. | Yes — if real usage shows job-scoped pull refresh is too slow or misses important continuity cases. | agent |
-| D009 | M001/S01 closure | gmail-matching | Where Gmail candidate aggregation and ranking logic should live for job-aware import | Keep Gmail query-hit aggregation, dedupe, matched-query traces, and ranking reasons in the backend contract instead of recreating that logic in the React workspace. | The correspondence workspace needs explanatory candidate ranking plus duplicate visibility, and putting the logic in the API keeps one source of truth for scoring/import state while preventing browser-side heuristic drift. | Yes | agent |
-| D010 | M001/S03 closeout | followup-drafting | How follow-up grounding should be exposed to the workspace | Return explicit follow-up grounding fields (`contextSummary`, `contextSignals`, `threadSubject`, and last-correspondence metadata) from the backend DTO instead of making the React workspace infer them client-side. | The slice needed draft trust, not just draft text. Putting grounding signals in the API contract gives the UI a durable explanation surface, keeps thread/package inference in one place with generation logic, and makes backend/frontend tests assert the same source of truth. | Yes | agent |
-| D011 | M001/S05 planning | workflow-trust | How S05 should represent daily-loop readiness and next-action state across overview surfaces | Introduce explicit workflow trust/action signals from the backend/UI contract and reuse them across the table, dashboard, reminders, and shared workspace instead of continuing to infer behavior from free-form `followUpReason` strings or raw `notes` presence in each component. | S05 is an end-to-end polish slice where the remaining risk is fragmented trust, not missing subsystems. Centralizing workflow signals avoids heuristic drift between overview surfaces, respects the saved application-answer notes-block constraint, and gives the final integrated regression one source of truth for R010 while preserving the explicit manual-send boundary required by R008. | Yes | agent |
-| D012 | M001/S05 | workspace-observability | Where linked Gmail thread continuity status should be exposed in the final trust loop | Show linked-thread refresh state directly in the correspondence workspace, including linked thread count and last refresh outcome, instead of hiding continuity feedback inside the Gmail import modal only. | The end-to-end trust loop depends on users being able to verify that already-linked Gmail threads stay current without re-importing. Surfacing continuity state in the main workspace keeps the job timeline trustworthy, supports final UAT, and avoids making thread refresh feel like a hidden one-off import behavior. | Yes | agent |
-| D013 | M001/S06/T02 | seeding | How acceptance-ready job data is created for S06 live reruns | Seed the acceptance fixture through the live companies/jobapplications/correspondence API plus the dedicated tailored-cv, application-drafts, and followup endpoints, using deterministic company/title/thread/message identifiers for idempotent reruns. | The slice goal is a repeatable live environment check, so seeding through the same HTTP contract the UI uses proves the real backend surface, keeps package/readiness behavior aligned with production code paths, and avoids brittle direct DB mutations or duplicate correspondence on reruns. | Yes | agent |
-| D014 | M001/S06/T03 | acceptance-run | How the S06 live acceptance runner should authenticate seeding and protected UI verification without requiring manual token export every rerun. | Allow the S06 acceptance runner to mint a localhost-only admin JWT from the checked-in dev JWT settings plus the local SQLite admin record when AUTH_TOKEN is missing. | The current DB snapshot contains an admin user but the placeholder development password is not reliable, and the task’s verification command must stay repeatable. A localhost-only signed JWT fallback keeps the run fully local, avoids secret prompts, does not print token material, and still exercises the real protected API/UI paths. | Yes | agent |
-| D015 | M001/S06 | environment | S06 preflight auth handling | Treat /api/auth/config reachability plus an auth-limited /api/admin/system probe as a guided partial-pass, and never echo bearer tokens in preflight output. | S06 needs a repeatable go/no-go gate before browser UAT. The live stack can be healthy even when admin-only diagnostics require an extra token, so the preflight should fail hard only for unreachable/malformed API responses while still surfacing clear AUTH_TOKEN guidance and protecting secrets on shared terminals. | Yes | agent |
-| D016 | M001/S07 | uat-artifact | How S07 daily-loop closure should capture acceptance evidence | Keep docs/s06-acceptance-run.md as the canonical execution log and use S07 closure artifacts to summarize/import the cross-surface proof rather than duplicating raw runner output. | S07's job is to prove one seeded job stays coherent across /jobs, workspace, /reminders, and /dashboard while preserving the manual-send boundary. Reusing the S06 runner output as the canonical source keeps reruns idempotent, prevents drift between generated logs and human summary text, and gives downstream slices one stable place for detailed evidence plus one concise dependency summary. | Yes | agent |
-| D017 | M005 planning | delivery | How M005 execution should be staged and published | Execute M005 one slice at a time, verify each slice independently, push each slice on its own git branch, then continue to the next slice only after the prior slice is stable. | The CV intelligence/export milestone is high-risk and multi-layered. Slice-by-slice branching and push discipline will keep extraction, tailored draft, and PDF rendering changes reviewable and reduce regression blast radius. | Yes | human |
-| D018 | M005 planning | verification | What document corpus should drive universal CV extraction verification | Use the real CV files placed in /home/pi/cvs as a regression corpus for universal extractor work, alongside synthetic/unit fixtures. | A universal CV extractor cannot be validated only against synthetic fixtures. Real CVs with different layouts, OCR quality, and structure are required to test extraction, review UX, and rendering assumptions. | Yes | human |
-| D019 | M011/S01 | frontend-platform | How to handle frontend build-tool risk during the initial platform hardening slice | Remediate the direct critical frontend dependency immediately, keep the CRA baseline for the next hardening slice, and defer the broader frontend build-tool migration to a later dedicated implementation step. | The audit showed one critical direct dependency issue (`axios`) and a large remaining body of transitive risk concentrated behind `react-scripts`. Upgrading the direct dependency removed the critical finding with low change surface, restored a reproducible local and Docker build baseline, and avoids coupling S02 auth/session work to a framework migration. The remaining CRA transitive debt is still real, but it is now a contained follow-on migration concern rather than an immediate blocker. | Yes | agent |
-| D020 | M011/S02 | authentication | What session transport should replace browser-stored bearer tokens in the frontend and API | Use an HttpOnly cookie-backed app session for the primary local auth path, have the API read the local app JWT from a secure cookie instead of browser storage, keep Google credential exchange server-side, and add CSRF protection for state-changing requests. | The current design stores the app bearer token in localStorage/sessionStorage and attaches it via an Authorization header on every request, which leaves the primary local auth path exposed to XSS-driven token theft. A cookie-backed session keeps the app token out of browser storage, lets the API enforce the local auth path centrally, preserves existing JWT-based authorization semantics on the server, and gives the frontend a cleaner source of truth through `/auth/me` and explicit unauthorized responses. Adding CSRF protection alongside the cookie keeps state-changing requests safe under the new transport. | Yes | agent |
-| D021 | M011/S03/T01 | frontend-architecture | How to centralize degraded-state handling for the core frontend views in S03. | Use a lightweight shared frontend async-view-state pattern for S03 instead of introducing a new global data-fetching framework in this slice. | The current risk is not lack of a full query library; it is that core views swallow request failures into empty arrays or nulls and then render normal empty states. A small shared abstraction for loading/empty/error/retry state can retire that product risk quickly across the highest-traffic views without broadening S03 into a framework migration or destabilizing the existing app. | Yes | agent |

.gsd/KNOWLEDGE.md

@@ -1,15 +0,0 @@
-# Project Knowledge
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests` still compiles the entire `JobTrackerApi.Tests` project before filtering execution. If unrelated controller tests drift from production signatures, the Gmail slice verification command will fail at compile time even when `GmailControllerTests` itself is correct.
-- The correspondence workspace auto-refreshes linked Gmail threads once per `jobId + ExternalThreadId set` using `POST /api/gmail/refresh-linked-threads`; if you need another pull in the same UI session without changing linked threads, use the explicit "Refresh linked threads" action.
-- The S02 package workspace persists the application-answer draft inside `JobApplication.Notes` using the marker block `<<<APPLICATION_ANSWER_DRAFT>>> ... <<<END_APPLICATION_ANSWER_DRAFT>>>`; downstream slices should replace or parse that block instead of appending free-form notes.
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests` is now a trustworthy direct verification command in this worktree for package-generation and notes-replacement behavior; prefer it over older isolated-harness guidance when checking S02 regressions.
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests` is now trustworthy again in this worktree after restoring the missing ASP.NET Core / Identity / xUnit test-project references in `JobTrackerApi.Tests/JobTrackerApi.Tests.csproj`; older task notes that require an isolated Docker harness are stale.
-- Running `npm --prefix job-tracker-ui start` alone is not enough for browser UAT in this worktree: the frontend calls `http://localhost:5202/api/...`, so without the backend (or a matching CORS/proxy setup) the UI loads but shows empty-state surfaces with `net::ERR_FAILED`/CORS errors instead of real job data.
-- In this CRA frontend, `react-scripts` resolves the app directory from the current working directory. Run UI tests/builds from `job-tracker-ui/` (for example `cd job-tracker-ui && CI=true ./node_modules/.bin/react-scripts ...`) instead of invoking `npm --prefix job-tracker-ui ...` from the repo root, or `react-scripts` may fail looking for a root-level `package.json`.
-- The S06 acceptance seed must backdate both `JobApplication.FollowUpAt` and the latest correspondence timestamp past the user’s `AppliedFollowUpDays` threshold; `RulesEngine` computes `Waiting` follow-up from the most recent activity (`DateApplied`, `ResponseDate`, `FollowUpAt`, `FeedbackRequestedAt`, or last correspondence), so a recent reminder date can suppress the intended `workflowSignal.actionKey = "follow-up"` fixture.
-- In this M001 worktree, the local SQLite DB contains `admin@example.com` with the `Admin` role even when the placeholder `Auth:AdminPassword` from `appsettings.Development.json` no longer authenticates. For repeatable localhost acceptance reruns, `scripts/s06-acceptance-run.sh` can mint a dev-only local JWT from the checked-in JWT settings instead of depending on a manual bearer-token export.
-- `scripts/s06-preflight.sh` intentionally exits 0 on the auth-limited path where `/api/auth/config` is reachable but `/api/admin/system` returns 401/403. Treat that as a guided partial pass for browser/UAT prep; only unreachable API, malformed JSON, or non-auth admin failures should block the slice.
-- In this M001 worktree, the focused CRA regression command `CI=true npm --prefix /home/pi/development/JobTracker/.gsd/worktrees/M001/job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx` can fail with `react-scripts: not found` even when `job-tracker-ui/node_modules` already exists from an older install state; rerun `npm --prefix /home/pi/development/JobTracker/.gsd/worktrees/M001/job-tracker-ui install` first, then retry the exact test command.
-- In the S07 localhost acceptance pass, opening the follow-up draft tab did not emit a fresh captured network request by itself. To verify the R008 manual-send boundary without clicking the send action, use the live UI evidence (`Copy Draft` and `Send And Log Email` both visible), then confirm `GET /api/jobapplications/3/followup-draft` succeeds from the authenticated browser context and that no `POST /api/jobapplications/3/send-followup` request appears during the observed pass.
-- In this GSD worktree alias, running frontend installs from the symlinked path can corrupt `job-tracker-ui/package-lock.json` by writing package keys like `../../../../../../.gsd/projects/.../worktrees/M001/job-tracker-ui/node_modules/...`. That lockfile can still work locally but breaks CI `npm ci` on a different checkout path. Before pushing frontend lockfile changes, verify the lock uses plain `node_modules/...` package keys and test it from a different directory.

.gsd/OVERRIDES.md

@@ -1,20 +0,0 @@
-# GSD Overrides
-
-User-issued overrides that supersede plan document content.
-
----
-## Override: 2026-03-24T10:57:41.499Z
-
-**Change:** can the gmail import bring the while tread of emails though? and also update automatically so if i reply to an email itll ahow my responce automaticslly without havjng to repull/kmport the emaila
-**Scope:** resolved
-**Applied-at:** M001/S01/T01
-
----
-
-## Override: 2026-04-10T16:46:22.130Z
-
-**Change:** use next.js
-**Scope:** active
-**Applied-at:** M001/none/none
-
----

.gsd/PROJECT.md

@@ -1,28 +0,0 @@
-# Project
-
-## What This Is
-
-Job Tracker is a personal job-application workspace for an individual user. The user finds jobs elsewhere, imports them into the app, uses AI to improve CVs, cover letters, replies, and follow-ups, and keeps the real-world application process organized through tracking, correspondence, and manual updates.
-
-## Core Value
-
-The product must let one person run a real job search without losing the thread: import a role, prepare stronger application material, track what happened, keep Gmail correspondence tied to the right job, and know exactly what needs follow-up next.
-
-## Current State
-
-A substantial brownfield app already exists. The repo has a React frontend, an ASP.NET Core API, and a local FastAPI AI service. Current capabilities already include job tracking, companies, attachments, correspondence, reminders, job import preview, Gmail connection/import, profile CV upload/parsing/rewrite flows, AI-assisted tailored CV and cover-letter generation, candidate-fit/focus-plan/interview-prep/readiness endpoints, and dashboard/system surfaces. M001 is now complete across S01-S07: the Gmail workspace is job-aware, backend ranking happens server-side, Gmail imports persist thread/from/to metadata, duplicate-safe single-message and thread imports are explicit, already-linked Gmail threads refresh back into the same job automatically via a bounded `ExternalThreadId` pull, the Tailored CV workspace persists reusable package material, follow-up drafting reuses imported correspondence plus saved package context, and `/jobs`, `/dashboard`, and `/reminders` now share one workflow-signal contract that routes into the same job workspace semantics. S05 finished the trust-loop polish by centralizing workflow trust/action metadata, surfacing linked-thread continuity state directly in the workspace, and adding an integrated regression that proves overview entry → package reuse → Gmail continuity → grounded follow-up drafting without crossing the manual-send boundary. S06 then stabilized the live localhost environment with a repeatable preflight gate, idempotent acceptance-data seeding through the real API, and a rerunnable acceptance-run artifact that re-proves `/jobs` → workspace → reminders/dashboard plus the manual-send boundary in the actual stack. S07 closes that loop with a dedicated daily-loop UAT artifact that traces one seeded job coherently across `/jobs`, the job workspace, `/reminders`, and `/dashboard`, while explicitly preserving the manual-send boundary and calling out that Gmail-connected continuity still requires a genuinely configured Gmail session to be proven live.
-
-## Architecture / Key Patterns
-
-The frontend lives in `job-tracker-ui/` and is a React + TypeScript app using MUI. The backend lives in `JobTrackerApi/` and is an ASP.NET Core API with EF Core, Identity, background hosted services, and controller-based endpoints. The local AI service lives in `tools/summarizer/` and provides summarization plus OCR/text extraction. Existing patterns already center around per-job workspaces, Gmail-backed correspondence import, profile-CV-as-source-of-truth, attachment-level AI inclusion controls, and server-side generation endpoints that return drafts for user review rather than autonomous sending. With the override, Gmail-backed correspondence is no longer just a one-time import pattern; it is a linked-thread continuity pattern that must keep the job timeline aligned with the user’s real Gmail thread history.
-
-## Capability Contract
-
-See `.gsd/REQUIREMENTS.md` for the explicit capability contract, requirement status, and coverage mapping.
-
-## Milestone Sequence
-
-- [x] M001: Gmail and draft quality loop — Make Gmail import and AI drafting strong enough to trust as a daily workflow, including whole-thread Gmail continuity after import.
-- [ ] M002: Tracking control center — Strengthen the job table, follow-up surfaces, and tracking rhythm into a clearer control center.
-- [ ] M003: Deeper inbox-aware assistance — Extend correspondence awareness and context-driven assistance beyond the first Gmail improvements.
-- [ ] M004: Trust, launchability, and hardening — Polish validation, clarity, performance, and operational trust surfaces for sustained daily use.

.gsd/REQUIREMENTS.md

@@ -1,249 +0,0 @@
-# Requirements
-
-This file is the explicit capability and coverage contract for the project.
-
-## Active
-
-### R008 — The app may draft application, reply, and follow-up content, but it must not auto-send emails or auto-apply to jobs.
-- Class: constraint
-- Status: active
-- Description: The app may draft application, reply, and follow-up content, but it must not auto-send emails or auto-apply to jobs.
-- Why it matters: The user called auto-sending dangerous and explicitly does not want that behavior.
-- Source: user
-- Primary owning slice: M001/S03
-- Supporting slices: M001/S05
-- Validation: Constrained by S03 follow-up tests and workspace UX: focused backend/frontend verification proves drafting uses context while outbound follow-up still requires an explicit manual send/log action.
-- Notes: S03 re-checked the manual-send boundary inside the follow-up workspace: users edit drafts locally and `POST /api/jobapplications/{id}/send-followup` fires only from the explicit send/log action. The broader anti-autonomy constraint still remains active across later milestone validation.
-
-### R009 — Core UX, data model emphasis, and roadmap decisions should optimize for one person managing their own search.
-- Class: constraint
-- Status: active
-- Description: Core UX, data model emphasis, and roadmap decisions should optimize for one person managing their own search.
-- Why it matters: Individual-first scope keeps product decisions sharp and prevents premature recruiter/CRM drift.
-- Source: user
-- Primary owning slice: M001/S04
-- Supporting slices: M002/S01, M004/S01
-- Validation: mapped
-- Notes: Shared/team workflows are not the current product target.
-
-### R018 — Run an adversarial security assessment against the application across input validation, authentication, authorization, API exposure, file uploads, and data exposure.
-- Class: operational
-- Status: active
-- Description: Run an adversarial security assessment against the application across input validation, authentication, authorization, API exposure, file uploads, and data exposure.
-- Why it matters: The next milestone is explicitly a hostile security-testing pass intended to find vulnerabilities before attackers do.
-- Source: user-security-milestone
-- Primary owning slice: M013
-- Validation: Produce verified findings or an explicit no-finding result for each requested attack category.
-- Notes: Assessment should assume weak protections and behave like an aggressive tester, not a happy-path reviewer.
-
-### R019 — For each security issue found, record the vulnerability description, an example exploit input, risk level, and a clear remediation recommendation.
-- Class: functional
-- Status: active
-- Description: For each security issue found, record the vulnerability description, an example exploit input, risk level, and a clear remediation recommendation.
-- Why it matters: Security testing is only useful if the output is actionable for remediation and triage.
-- Source: user-security-milestone
-- Primary owning slice: M013
-- Validation: Each finding includes description, exploit example, risk rating, and fix guidance.
-- Notes: If no issue is found in a category, the milestone should still document what was tested and the observed boundary.
-
-## Validated
-
-### R001 — The user finds a job outside the app, imports it into the app, and starts the application workflow from that imported role.
-- Class: primary-user-loop
-- Status: validated
-- Description: The user finds a job outside the app, imports it into the app, and starts the application workflow from that imported role.
-- Why it matters: The product is not a job board replacement; the import step is the real start of the user loop.
-- Source: user
-- Primary owning slice: M001/S01
-- Supporting slices: M001/S05
-- Validation: S01 completed with a job-scoped Gmail import loop wired into the job workspace: backend `GET /api/gmail/job-candidates` uses the owned job as context, imports target that job directly, and focused UI verification passed in `job-tracker-ui/src/correspondence-gmail-import.test.tsx`.
-- Notes: Validation is contract/UI-level plus workspace integration. Live user UAT of the broader milestone loop still remains for later slices.
-
-### R002 — Gmail connection, message retrieval, single-message/thread import, and linked-thread refresh must help the user pull real correspondence into the right job, preserve full thread continuity, and automatically surface later inbound or user-sent replies without requiring manual re-import of the thread.
-- Class: integration
-- Status: validated
-- Description: Gmail connection, message retrieval, single-message/thread import, and linked-thread refresh must help the user pull real correspondence into the right job, preserve full thread continuity, and automatically surface later inbound or user-sent replies without requiring manual re-import of the thread.
-- Why it matters: Gmail import is one of the two clearest current weaknesses and a major trust surface for daily use; one-time import alone is not enough if the thread immediately goes stale.
-- Source: user
-- Primary owning slice: M001/S01
-- Supporting slices: M001/S03, M001/S05
-- Validation: Validated by M001/S01: backend `POST /api/gmail/refresh-linked-threads` now refreshes already-linked Gmail thread ids for one owned job, imports only unseen replies into the same job with duplicate-safe counts, focused `GmailControllerTests` pass via `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests`, and `job-tracker-ui/src/correspondence-gmail-import.test.tsx` proves the workspace auto-refresh path shows a later Gmail reply without manual re-import.
-- Notes: S01 now covers job-aware Gmail candidate ranking, duplicate-safe single-message/thread import, persisted Gmail thread/from/to metadata, and automatic linked-thread continuity inside the correspondence workspace.
-
-### R003 — Tailored CV and cover-letter drafts must feel specific, credible, and good enough that the user wants to start from them.
-- Class: differentiator
-- Status: validated
-- Description: Tailored CV and cover-letter drafts must feel specific, credible, and good enough that the user wants to start from them.
-- Why it matters: Draft generation exists already, but the milestone bar is actual usefulness rather than feature presence.
-- Source: user
-- Primary owning slice: M001/S02
-- Supporting slices: M001/S05
-- Validation: Validated by M001/S02: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests` now passes with package generation using recruiter/job/profile/attachment/imported-correspondence context, and `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx` proves generation, editing, save, and saved-state redisplay behavior in the job workspace.
-- Notes: S02 also proved the saved application-answer loop by replacing the marker-delimited notes block instead of appending indefinitely.
-
-### R004 — The app must generate follow-up and reply drafts from the imported job, saved application material, and correspondence context tied to that job.
-- Class: primary-user-loop
-- Status: validated
-- Description: The app must generate follow-up and reply drafts from the imported job, saved application material, and correspondence context tied to that job.
-- Why it matters: Follow-through is part of the core value, not an optional afterthought.
-- Source: user
-- Primary owning slice: M001/S03
-- Supporting slices: M001/S01, M001/S02, M001/S05
-- Validation: Validated by M001/S03: follow-up draft generation now consumes imported correspondence plus saved application package material, focused backend follow-up tests pass in an isolated harness, the focused React follow-up test passes, and browser verification on the built branch UI proved the grounded follow-up draft plus manual send/log flow back into correspondence.
-- Notes: S03 validated the follow-up half of the requirement. Explicit reply drafting may still be deepened later, but the requirement-level milestone bar is now met for job-grounded follow-up/reply assistance without autonomous sending.
-
-### R005 — The first page should give the user a clear overview of jobs, status, readiness, and what needs attention.
-- Class: continuity
-- Status: validated
-- Description: The first page should give the user a clear overview of jobs, status, readiness, and what needs attention.
-- Why it matters: The user explicitly wants to start from the job table each day.
-- Source: user
-- Primary owning slice: M001/S04
-- Supporting slices: M001/S05
-- Validation: Validated by M001/S04: the job table now exposes actionable urgency chips that route directly into the relevant job workspace tab, focused daily-loop UI tests pass, and browser verification confirmed the table/dashboard/reminders flow routes into the same workspace model.
-- Notes: S04 made the table a practical first-stop overview for daily use rather than a passive list.
-
-### R006 — The dashboard and follow-up surfaces must clearly show next actions, neglected threads, and jobs that need attention now.
-- Class: continuity
-- Status: validated
-- Description: The dashboard and follow-up surfaces must clearly show next actions, neglected threads, and jobs that need attention now.
-- Why it matters: Tracking is only valuable if it turns state into action.
-- Source: user
-- Primary owning slice: M001/S04
-- Supporting slices: M001/S05
-- Validation: Validated by M001/S04: dashboard and reminders now expose actionable attention items routed into the existing job workspace, focused daily-loop UI tests pass, and browser verification confirmed those surfaces open the correct job workspace state.
-- Notes: S04 made the follow-up/dashboard surfaces show actionable urgency instead of dead-end summaries.
-
-### R007 — Each job needs a workspace where the user can update status, review/import correspondence, edit drafts, and prepare follow-ups.
-- Class: core-capability
-- Status: validated
-- Description: Each job needs a workspace where the user can update status, review/import correspondence, edit drafts, and prepare follow-ups.
-- Why it matters: The user’s third step in the daily flow is to drop into a specific job and do focused work.
-- Source: inferred
-- Primary owning slice: M001/S03
-- Supporting slices: M001/S02, M001/S04
-- Validation: Validated by M001/S03 and M001/S04: the per-job workspace now supports imported correspondence review, package drafting, follow-up drafting, and routed entry from overview surfaces, with focused tests and browser verification covering package and follow-up loops.
-- Notes: S01-S04 now make the individual job workspace the real execution surface for import, drafting, and follow-up work. The reopened Gmail continuity work extends what that correspondence review surface must keep current over time.
-
-### R010 — The app must preserve a coherent history across manual status changes, imported Gmail correspondence, linked-thread updates, reminders, and follow-up work.
-- Class: continuity
-- Status: validated
-- Description: The app must preserve a coherent history across manual status changes, imported Gmail correspondence, linked-thread updates, reminders, and follow-up work.
-- Why it matters: The product promise is to keep the thread of the job search intact over time, including new Gmail replies that happen after the first import.
-- Source: user
-- Primary owning slice: M001/S04
-- Supporting slices: M001/S01, M001/S03, M001/S05
-- Validation: Validated by M001/S05: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsWorkflowSignalsTests` proves backend reminders/readiness return normalized workflow trust signals, `CI=true ./node_modules/.bin/react-scripts test --watch=false --runTestsByPath src/workflow-trust-signals.test.tsx src/end-to-end-trust-loop.test.tsx src/correspondence-gmail-import.test.tsx src/job-details-generated-drafts.test.tsx src/job-details-followup-drafts.test.tsx src/daily-control-loop.test.tsx` proves `/jobs`, `/dashboard`, and `/reminders` route into the same workspace semantics while preserving saved package reuse, linked-thread continuity, and grounded follow-up drafting, and `CI=true ./node_modules/.bin/react-scripts build` confirms the integrated UI ships as one coherent loop.
-- Notes: S05 centralized workflow signals in `job-tracker-ui/src/jobWorkflowSignals.ts`, re-proved linked Gmail continuity in the shared workspace, and added an integrated trust-loop regression so coherence no longer depends on per-surface string heuristics.
-
-## Deferred
-
-### R011 — The app should later expand overview analytics, saved views, and clearer strategy readouts beyond the core daily loop.
-- Class: operability
-- Status: deferred
-- Description: The app should later expand overview analytics, saved views, and clearer strategy readouts beyond the core daily loop.
-- Why it matters: This can improve search strategy, but it is not the first trust gap to close.
-- Source: inferred
-- Primary owning slice: M002/S02
-- Supporting slices: none
-- Validation: unmapped
-- Notes: Deferred because Gmail import and draft quality are higher-value first fixes.
-
-### R012 — The app may later add richer message understanding, smarter thread handling, and broader inbox-aware assistance after the first Gmail milestone.
-- Class: integration
-- Status: deferred
-- Description: The app may later add richer message understanding, smarter thread handling, and broader inbox-aware assistance after the first Gmail milestone.
-- Why it matters: This extends the correspondence workflow, but it depends on getting the initial import/matching loop right first.
-- Source: inferred
-- Primary owning slice: M003/S01
-- Supporting slices: none
-- Validation: unmapped
-- Notes: This is the natural next step after M001 proves the core Gmail path, including linked-thread continuity.
-
-### R013 — The app may later add broader strategic coaching and more advanced guidance beyond application package and follow-up/reply drafting.
-- Class: differentiator
-- Status: deferred
-- Description: The app may later add broader strategic coaching and more advanced guidance beyond application package and follow-up/reply drafting.
-- Why it matters: There is room to deepen the assistant, but the current product bar is a stronger core workflow.
-- Source: inferred
-- Primary owning slice: M003/S02
-- Supporting slices: none
-- Validation: unmapped
-- Notes: Deferred to avoid scattering the first milestone.
-
-## Out of Scope
-
-### R014 — The app will not automatically submit applications to external job sites.
-- Class: anti-feature
-- Status: out-of-scope
-- Description: The app will not automatically submit applications to external job sites.
-- Why it matters: This prevents product drift into risky, low-trust automation the user explicitly does not want.
-- Source: user
-- Primary owning slice: none
-- Supporting slices: none
-- Validation: n/a
-- Notes: The app starts after discovery/import, not at job search submission.
-
-### R015 — The app will not send replies, follow-ups, or other communication autonomously.
-- Class: anti-feature
-- Status: out-of-scope
-- Description: The app will not send replies, follow-ups, or other communication autonomously.
-- Why it matters: Manual control over outbound communication is a hard trust requirement.
-- Source: user
-- Primary owning slice: none
-- Supporting slices: none
-- Validation: n/a
-- Notes: Drafting is allowed; autonomous sending is not. Automatic thread refresh/import of already-sent Gmail replies is allowed because it reflects history after the user sends manually.
-
-### R016 — The product will not optimize for shared pipelines, recruiter operations, or multi-user coaching workflows right now.
-- Class: out-of-scope
-- Status: out-of-scope
-- Description: The product will not optimize for shared pipelines, recruiter operations, or multi-user coaching workflows right now.
-- Why it matters: This protects the individual-first product shape.
-- Source: user
-- Primary owning slice: none
-- Supporting slices: none
-- Validation: n/a
-- Notes: Multi-user admin surfaces may exist technically, but they are not the roadmap center.
-
-### R017 — The app will not try to replace external job boards as the main discovery surface.
-- Class: out-of-scope
-- Status: out-of-scope
-- Description: The app will not try to replace external job boards as the main discovery surface.
-- Why it matters: The user explicitly described a workflow that starts after finding the job elsewhere.
-- Source: user
-- Primary owning slice: none
-- Supporting slices: none
-- Validation: n/a
-- Notes: Job import is the bridge from external discovery into the app.
-
-## Traceability
-
-| ID | Class | Status | Primary owner | Supporting | Proof |
-|---|---|---|---|---|---|
-| R001 | primary-user-loop | validated | M001/S01 | M001/S05 | S01 completed with a job-scoped Gmail import loop wired into the job workspace: backend `GET /api/gmail/job-candidates` uses the owned job as context, imports target that job directly, and focused UI verification passed in `job-tracker-ui/src/correspondence-gmail-import.test.tsx`. |
-| R002 | integration | validated | M001/S01 | M001/S03, M001/S05 | Validated by M001/S01: backend `POST /api/gmail/refresh-linked-threads` now refreshes already-linked Gmail thread ids for one owned job, imports only unseen replies into the same job with duplicate-safe counts, focused `GmailControllerTests` pass via `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests`, and `job-tracker-ui/src/correspondence-gmail-import.test.tsx` proves the workspace auto-refresh path shows a later Gmail reply without manual re-import. |
-| R003 | differentiator | validated | M001/S02 | M001/S05 | Validated by M001/S02: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests` now passes with package generation using recruiter/job/profile/attachment/imported-correspondence context, and `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx` proves generation, editing, save, and saved-state redisplay behavior in the job workspace. |
-| R004 | primary-user-loop | validated | M001/S03 | M001/S01, M001/S02, M001/S05 | Validated by M001/S03: follow-up draft generation now consumes imported correspondence plus saved application package material, focused backend follow-up tests pass in an isolated harness, the focused React follow-up test passes, and browser verification on the built branch UI proved the grounded follow-up draft plus manual send/log flow back into correspondence. |
-| R005 | continuity | validated | M001/S04 | M001/S05 | Validated by M001/S04: the job table now exposes actionable urgency chips that route directly into the relevant job workspace tab, focused daily-loop UI tests pass, and browser verification confirmed the table/dashboard/reminders flow routes into the same workspace model. |
-| R006 | continuity | validated | M001/S04 | M001/S05 | Validated by M001/S04: dashboard and reminders now expose actionable attention items routed into the existing job workspace, focused daily-loop UI tests pass, and browser verification confirmed those surfaces open the correct job workspace state. |
-| R007 | core-capability | validated | M001/S03 | M001/S02, M001/S04 | Validated by M001/S03 and M001/S04: the per-job workspace now supports imported correspondence review, package drafting, follow-up drafting, and routed entry from overview surfaces, with focused tests and browser verification covering package and follow-up loops. |
-| R008 | constraint | active | M001/S03 | M001/S05 | Constrained by S03 follow-up tests and workspace UX: focused backend/frontend verification proves drafting uses context while outbound follow-up still requires an explicit manual send/log action. |
-| R009 | constraint | active | M001/S04 | M002/S01, M004/S01 | mapped |
-| R010 | continuity | validated | M001/S04 | M001/S01, M001/S03, M001/S05 | Validated by M001/S05: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsWorkflowSignalsTests` proves backend reminders/readiness return normalized workflow trust signals, `CI=true ./node_modules/.bin/react-scripts test --watch=false --runTestsByPath src/workflow-trust-signals.test.tsx src/end-to-end-trust-loop.test.tsx src/correspondence-gmail-import.test.tsx src/job-details-generated-drafts.test.tsx src/job-details-followup-drafts.test.tsx src/daily-control-loop.test.tsx` proves `/jobs`, `/dashboard`, and `/reminders` route into the same workspace semantics while preserving saved package reuse, linked-thread continuity, and grounded follow-up drafting, and `CI=true ./node_modules/.bin/react-scripts build` confirms the integrated UI ships as one coherent loop. |
-| R011 | operability | deferred | M002/S02 | none | unmapped |
-| R012 | integration | deferred | M003/S01 | none | unmapped |
-| R013 | differentiator | deferred | M003/S02 | none | unmapped |
-| R014 | anti-feature | out-of-scope | none | none | n/a |
-| R015 | anti-feature | out-of-scope | none | none | n/a |
-| R016 | out-of-scope | out-of-scope | none | none | n/a |
-| R017 | out-of-scope | out-of-scope | none | none | n/a |
-| R018 | operational | active | M013 | none | Produce verified findings or an explicit no-finding result for each requested attack category. |
-| R019 | functional | active | M013 | none | Each finding includes description, exploit example, risk rating, and fix guidance. |
-
-## Coverage Summary
-
-- Active requirements: 4
-- Mapped to slices: 4
-- Validated: 8 (R001, R002, R003, R004, R005, R006, R007, R010)
-- Unmapped active requirements: 0

.gsd/event-log.jsonl

@@ -1,58 +0,0 @@
-{"cmd":"plan-slice","params":{"milestoneId":"M001","sliceId":"S06"},"ts":"2026-03-27T07:47:00.102Z","actor":"agent","hash":"ad7ae36d97e9c851","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S06","taskId":"T01"},"ts":"2026-03-27T07:57:14.999Z","actor":"agent","hash":"7206faf86461a4cd","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S06","taskId":"T02"},"ts":"2026-03-27T08:09:46.080Z","actor":"agent","hash":"08f3c9c34195dd48","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S06","taskId":"T03"},"ts":"2026-03-27T08:24:16.617Z","actor":"agent","hash":"df80cd5e7e3c84ad","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-slice","params":{"milestoneId":"M001","sliceId":"S06"},"ts":"2026-03-27T08:29:02.349Z","actor":"agent","hash":"fedfb0239925e215","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M001","sliceId":"S07"},"ts":"2026-03-27T08:34:48.119Z","actor":"agent","hash":"ece1adcb6dd214ed","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S07","taskId":"T01"},"ts":"2026-03-27T08:36:36.314Z","actor":"agent","hash":"0aa4019d4a27538a","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S07","taskId":"T02"},"ts":"2026-03-27T08:51:21.876Z","actor":"agent","hash":"7f6dfb093ecf298e","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"complete-task","params":{"milestoneId":"M001","sliceId":"S07","taskId":"T03"},"ts":"2026-03-27T08:55:15.935Z","actor":"agent","hash":"0b8928a7f97d0d42","session_id":"96f47087-e006-4aa2-8147-1cc42da4374d"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M005"},"ts":"2026-03-28T22:04:42.705Z","actor":"agent","hash":"9f92dc9597f6bcca","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M005","sliceId":"S01"},"ts":"2026-03-28T22:05:00.001Z","actor":"agent","hash":"94d3ace67d51aaad","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M005","sliceId":"S02"},"ts":"2026-03-28T22:05:16.424Z","actor":"agent","hash":"cc2907fae86cc252","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M005","sliceId":"S03"},"ts":"2026-03-28T22:05:32.786Z","actor":"agent","hash":"ae2f80720d601a48","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M005","sliceId":"S04"},"ts":"2026-03-28T22:05:48.342Z","actor":"agent","hash":"38e10b5bfc9e49e6","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-slice","params":{"milestoneId":"M005","sliceId":"S05"},"ts":"2026-03-28T22:06:02.267Z","actor":"agent","hash":"a4cdfef1b0f97af3","session_id":"14376f9c-a697-450d-ba63-4e6522e8f68d"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M006"},"ts":"2026-04-01T13:42:13.507Z","actor":"agent","hash":"4e6e2177aea2c247","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M007"},"ts":"2026-04-01T13:45:43.599Z","actor":"agent","hash":"f74c11f87b160d5e","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M010"},"ts":"2026-04-01T13:45:43.608Z","actor":"agent","hash":"0767a15a4163e364","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M009"},"ts":"2026-04-01T13:45:43.609Z","actor":"agent","hash":"868651dc3e9840ba","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"cmd":"plan-milestone","params":{"milestoneId":"M008"},"ts":"2026-04-01T13:45:43.611Z","actor":"agent","hash":"a17e013ae4c6fbc7","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"cmd":"plan-slice","params":{"milestoneId":"M006","sliceId":"S01"},"ts":"2026-04-01T13:46:55.228Z","actor":"agent","hash":"53e13651ee21608e","session_id":"4611175a-96ec-432d-832a-0269486cb6ff"}
-{"v":2,"cmd":"plan-milestone","params":{"milestoneId":"M011"},"ts":"2026-04-10T16:33:49.574Z","actor":"agent","hash":"8da5bd1f6d8be219","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S01"},"ts":"2026-04-10T16:36:01.325Z","actor":"agent","hash":"1b39eb81745f79cb","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S01","taskId":"T01"},"ts":"2026-04-10T16:45:13.023Z","actor":"agent","hash":"df43e89bf0ef508a","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S01","taskId":"T02"},"ts":"2026-04-10T16:46:52.982Z","actor":"agent","hash":"fc183a287cf7e0ec","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S01","taskId":"T03"},"ts":"2026-04-10T16:47:07.060Z","actor":"agent","hash":"96dbf0b722260441","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S01"},"ts":"2026-04-10T16:47:38.406Z","actor":"agent","hash":"e8b7e8fcc07292af","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"reassess-roadmap","params":{"milestoneId":"M011","completedSliceId":"S01"},"ts":"2026-04-10T16:47:48.162Z","actor":"agent","hash":"e8d28553a74cd045","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S02"},"ts":"2026-04-10T16:48:16.316Z","actor":"agent","hash":"c6f7c425cd77c100","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S02","taskId":"T01"},"ts":"2026-04-10T16:49:40.607Z","actor":"agent","hash":"1e247d4737f232b4","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S02","taskId":"T02"},"ts":"2026-04-10T19:57:16.264Z","actor":"agent","hash":"02eb6bc1686244e9","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S02","taskId":"T03"},"ts":"2026-04-10T19:57:41.031Z","actor":"agent","hash":"85c32d040f9631aa","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S02"},"ts":"2026-04-10T19:58:17.389Z","actor":"agent","hash":"3115b597816bc8cb","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"reassess-roadmap","params":{"milestoneId":"M011","completedSliceId":"S02"},"ts":"2026-04-10T19:58:21.945Z","actor":"agent","hash":"51ed90ab022e6ae9","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S03"},"ts":"2026-04-10T22:04:32.223Z","actor":"agent","hash":"10a79a238ead7007","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S03","taskId":"T01"},"ts":"2026-04-10T22:05:25.953Z","actor":"agent","hash":"4d7f978e674fb278","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S03","taskId":"T02"},"ts":"2026-04-10T22:19:14.274Z","actor":"agent","hash":"94e0f7a9b24dd246","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S03","taskId":"T03"},"ts":"2026-04-10T22:19:33.234Z","actor":"agent","hash":"31c5bb74a3280df0","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S03"},"ts":"2026-04-10T22:20:05.975Z","actor":"agent","hash":"7a76f48b67c6a4fa","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"reassess-roadmap","params":{"milestoneId":"M011","completedSliceId":"S03"},"ts":"2026-04-10T22:20:18.782Z","actor":"agent","hash":"0bdf677f91c94f7b","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S04"},"ts":"2026-04-10T22:32:19.950Z","actor":"agent","hash":"ad5a195d23e3979e","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S04","taskId":"T01"},"ts":"2026-04-10T22:33:06.567Z","actor":"agent","hash":"dff04d446600fb9c","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S04","taskId":"T02"},"ts":"2026-04-10T22:44:02.977Z","actor":"agent","hash":"0a94bd5f4e0d3c90","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S04","taskId":"T03"},"ts":"2026-04-10T22:44:23.671Z","actor":"agent","hash":"6148706a46d32f7b","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S04"},"ts":"2026-04-10T22:44:54.430Z","actor":"agent","hash":"e68c20060f20dd34","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"reassess-roadmap","params":{"milestoneId":"M011","completedSliceId":"S04"},"ts":"2026-04-10T22:45:07.836Z","actor":"agent","hash":"f92571f10029d5e9","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S05"},"ts":"2026-04-10T22:55:56.643Z","actor":"agent","hash":"39e7d7ed3cc34612","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S05","taskId":"T01"},"ts":"2026-04-10T22:56:09.946Z","actor":"agent","hash":"c133fd6bf6b26629","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S05","taskId":"T02"},"ts":"2026-04-10T22:59:48.954Z","actor":"agent","hash":"f603df2d0e5cd772","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S05","taskId":"T03"},"ts":"2026-04-10T23:00:30.352Z","actor":"agent","hash":"96ecf88ce819d73b","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S05"},"ts":"2026-04-10T23:00:57.810Z","actor":"agent","hash":"31a2aca44265f192","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"reassess-roadmap","params":{"milestoneId":"M011","completedSliceId":"S05"},"ts":"2026-04-10T23:01:02.519Z","actor":"agent","hash":"fe0bd7ec6ab8df21","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"plan-slice","params":{"milestoneId":"M011","sliceId":"S06"},"ts":"2026-04-10T23:01:49.394Z","actor":"agent","hash":"f2b438884ca52230","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S06","taskId":"T01"},"ts":"2026-04-10T23:20:01.968Z","actor":"agent","hash":"406e0f3c172d1161","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S06","taskId":"T02"},"ts":"2026-04-10T23:24:03.823Z","actor":"agent","hash":"1a2544dcd9f4f925","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-task","params":{"milestoneId":"M011","sliceId":"S06","taskId":"T03"},"ts":"2026-04-10T23:24:23.101Z","actor":"agent","hash":"f583516649531d4c","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-slice","params":{"milestoneId":"M011","sliceId":"S06"},"ts":"2026-04-10T23:24:52.479Z","actor":"agent","hash":"b2c2dc564fb09dfe","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}
-{"v":2,"cmd":"complete-milestone","params":{"milestoneId":"M011"},"ts":"2026-04-10T23:25:36.547Z","actor":"agent","hash":"10b42cbd47fe0d4a","session_id":"f90d26d1-ea3a-48a7-b5ff-50c99ba96644"}

.gsd/milestones/M001/M001-CONTEXT.md

@@ -1,113 +0,0 @@
-# M001: Gmail and draft quality loop
-
-**Gathered:** 2026-03-24
-**Status:** Ready for planning
-
-## Project Description
-
-This milestone upgrades an existing personal job-tracking app into a workflow the user can trust every day. The user still finds jobs outside the app and applies outside the app, but once a job is imported, the app should become the place where the user prepares stronger application material, imports relevant Gmail correspondence, generates follow-up and reply drafts, and keeps the process organized without losing the thread.
-
-## Why This Milestone
-
-The codebase already has job import, Gmail import, CV tooling, AI-assisted draft generation, readiness analysis, and per-job workspaces. The problem is not total feature absence; it is that the two most important weak points in the current product are Gmail import and AI draft quality. Those are foundational trust surfaces. If Gmail import feels dumb or the AI drafts feel weak, the app does not earn a place in the user’s daily job-search loop. This milestone focuses on making the existing workflow materially better before broadening the product outward.
-
-## User-Visible Outcome
-
-### When this milestone is complete, the user can:
-
-- import a job found on an external job site, generate a tailored application package, and use it as the basis for a real application outside the app
-- connect Gmail, import the right correspondence into the right job with less cleanup, and generate follow-up or reply drafts from real context
-
-### Entry point / environment
-
-- Entry point: browser UI starting from the job table and per-job workspace
-- Environment: browser + local/dev or deployed web app backed by API, database, Gmail OAuth, and local AI service
-- Live dependencies involved: database, Gmail OAuth/import, local AI service, optional SMTP for reminder/follow-up workflows
-
-## Completion Class
-
-- Contract complete means: the relevant API endpoints, UI flows, persisted job/correspondence state, and draft-generation paths are wired and verified with tests and artifact checks
-- Integration complete means: real Gmail import, job-linked correspondence, and AI draft generation work together across frontend, API, and AI service boundaries
-- Operational complete means: the workflow survives real auth/config/service conditions well enough that a user can use it repeatedly without hidden setup traps or dangerous outbound automation
-
-## Final Integrated Acceptance
-
-To call this milestone complete, we must prove:
-
-- a user can import a real job, generate a stronger tailored CV and cover-letter package, and save/edit that material in the job workspace
-- a user can connect Gmail, import the correct message or thread into a job, and then generate a context-aware follow-up or reply draft from that imported correspondence
-- the full loop from job table → follow-up/dashboard → individual job workspace works cleanly enough for real repeated use, and no part of the milestone relies on auto-send or auto-apply behavior
-
-## Risks and Unknowns
-
-- Gmail matching quality may still be noisy — if message-to-job association is weak, the correspondence workflow will not feel trustworthy
-- Draft quality may plateau even with better prompts — if outputs still feel generic, the main value promise remains unproven
-- Existing capability may be present but fragmented — if the workflow still feels scattered across tabs and screens, the product will not feel like one coherent workspace
-- The daily overview may still under-signal urgency — if the table and dashboard do not turn state into action, tracking value stays abstract
-
-## Existing Codebase / Prior Art
-
-- `JobTrackerApi/Controllers/GmailController.cs` — existing Gmail OAuth, message listing, and import endpoints
-- `JobTrackerApi/Services/GmailOAuthService.cs` — Gmail token handling and Gmail API access
-- `JobTrackerApi/Controllers/JobImportController.cs` — existing external job import preview flow
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — current candidate-fit, focus-plan, interview-prep, readiness, tailored-CV, and follow-up draft surfaces
-- `JobTrackerApi/Controllers/ProfileCvController.cs` — profile CV upload, extraction, parse, rebuild, and improve flows
-- `job-tracker-ui/src/components/Correspondence.tsx` — current Gmail connection/import UI inside job correspondence
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — current per-job AI tabs, draft editing, attachment context selection, and readiness UI
-- `job-tracker-ui/src/components/JobTable.tsx` — job table surface that should remain the primary daily control view
-- `job-tracker-ui/src/components/DashboardView.tsx` — dashboard/follow-up surface that should become a clearer urgency view
-- `tools/summarizer/app.py` — local AI service boundary for summarization and extraction
-
-> See `.gsd/DECISIONS.md` for all architectural and pattern decisions — it is an append-only register; read it during planning, append to it during execution.
-
-## Relevant Requirements
-
-- R001 — establishes the import-first workflow around jobs discovered elsewhere
-- R002 — improves Gmail import into something the user can trust as part of the daily workflow
-- R003 — raises AI application draft quality from present to genuinely useful
-- R004 — turns imported job and correspondence context into better reply/follow-up drafting
-- R005 — preserves the job table as the first control surface
-- R006 — makes follow-up/dashboard views better at surfacing urgency and next actions
-- R007 — strengthens the individual job workspace as the place to do focused work
-- R008 — keeps all outbound communication manual and user-controlled
-- R009 — keeps milestone scope optimized for an individual user, not a recruiter workflow
-- R010 — ensures tracking continuity across manual updates and imported correspondence
-
-## Scope
-
-### In Scope
-
-- smarter Gmail message/thread import and job matching quality
-- better use of imported correspondence as context for reply and follow-up drafting
-- stronger tailored CV and cover-letter generation quality
-- tighter daily-use flow across job table, follow-up/dashboard, and individual job workspace
-- coherence improvements that make existing AI and tracking capability feel like one product loop
-
-### Out of Scope / Non-Goals
-
-- automatic job application submission
-- automatic sending of follow-up or reply emails
-- turning the app into a job-discovery product that replaces external job boards
-- recruiter CRM, shared pipelines, or team collaboration workflows
-- broad product expansion unrelated to Gmail import quality, draft quality, or the daily control loop
-
-## Technical Constraints
-
-- preserve the no-auto-send trust boundary across all AI-assisted communication flows
-- build on the existing React + ASP.NET Core + local FastAPI service architecture rather than replacing it
-- respect existing Gmail OAuth and job-linked correspondence patterns already in the codebase
-- keep draft generation grounded in real profile CV, job, attachment, and correspondence context rather than generic prompts alone
-- maintain an individual-first UX even where admin/multi-user code exists in the repo
-
-## Integration Points
-
-- Gmail API — used for message listing, thread retrieval, and import into job correspondence
-- local AI service — used for summarization, extraction, and draft generation context building
-- ASP.NET Core API + EF Core database — persists jobs, correspondence, CV/profile state, and draft outputs
-- browser UI — presents the table/dashboard/job-workspace control flow that must feel coherent after this milestone
-
-## Open Questions
-
-- How far matching confidence and message-to-job suggestion logic can be pushed with the current Gmail data model — current thinking: prove it through real import UX in S01 rather than abstract matching rules
-- Whether prompt/workflow changes alone are enough to make drafts feel strong, or whether UI/context shaping is the bigger lever — current thinking: test both because “quality” here is partly generation and partly surrounding workflow
-- Which existing dashboard/table elements should be simplified versus enriched — current thinking: prioritize action clarity over adding more analytics first

.gsd/milestones/M001/M001-DISCUSSION.md

@@ -1,40 +0,0 @@
-# M001 Discussion Log
-
-## Exchange — 2026-03-24T08:14:04.663Z
-
-### M003 Gate
-
-For M003 — deeper external awareness and automation like smarter inbox handling beyond the first Gmail improvements — should I write a draft for later?
-
-- **Write draft for later (Recommended)** — Keep the current intent as a draft now, then do a focused discussion when this milestone comes up.
-- **Discuss now** — Use this session to deepen M003 enough for a full context file.
-- **Just queue it** — Record the milestone only and leave discussion for a future session from scratch.
-
-**Selected:** Write draft for later (Recommended)
-
----
-## Exchange — 2026-03-24T08:14:27.657Z
-
-### M004 Gate
-
-For M004 — launch hardening, validation, trust, clarity, and operational polish — should I write a draft for later?
-
-- **Write draft for later (Recommended)** — Capture the current intent as a draft now and refine it when the product is closer to launch hardening.
-- **Discuss now** — Use this session to deepen M004 enough for a full context file.
-- **Just queue it** — Record the milestone only and leave discussion for a future session from scratch.
-
-**Selected:** Write draft for later (Recommended)
-
----
-## Exchange — 2026-03-24T08:14:59.499Z
-
-### M001 Check
-
-I verified the current code has job import, Gmail import, CV tooling, and AI draft surfaces already present; should M001 be written as a coherence-and-quality milestone around those real capabilities?
-
-- **Yes, write it (Recommended)** — Write M001 around smarter Gmail import, stronger drafts, and the daily control loop.
-- **Not quite — adjust it** — The milestone emphasis is off and needs correction before writing.
-
-**Selected:** Yes, write it (Recommended)
-
----

.gsd/milestones/M001/M001-META.json

@@ -1,3 +0,0 @@
-{
-  "integrationBranch": "main"
-}

.gsd/milestones/M001/M001-ROADMAP.md

@@ -1,15 +0,0 @@
-# M001: M001: M001: Gmail and draft quality loop
-
-## Vision
-M001: M001: Gmail and draft quality loop
-
-## Slice Overview
-| ID | Slice | Risk | Depends | Done | After this |
-|----|-------|------|---------|------|------------|
-| S01 | Smarter Gmail import and matching | high | — | ✅ | TBD |
-| S02 | Stronger AI application package drafting | high | S01 | ✅ | TBD |
-| S03 | Reply and follow-up drafting from real thread context | medium | S01, S02 | ✅ | TBD |
-| S04 | Daily control loop surfaces | medium | S01, S03 | ✅ | TBD |
-| S05 | End-to-end trust and workflow polish | low | S01, S02, S03, S04 | ✅ | TBD |
-| S06 | Live environment stabilization and integrated acceptance rerun | high | S05 | ✅ | TBD |
-| S07 | Daily-loop UAT artifact closure | medium | S06 | ✅ | TBD |

.gsd/milestones/M001/M001-VALIDATION.md

@@ -1,50 +0,0 @@
----
-verdict: needs-remediation
-remediation_round: 0
----
-
-# Milestone Validation: M001
-
-## Success Criteria Checklist
-- [x] Criterion 1 — evidence: S02 wired `POST /api/jobapplications/{id}/generate-application-package` to imported correspondence, recruiter/job/profile context, and persisted package workspace state in `JobDetailsDialog.tsx`; focused backend/frontend tests prove generate/edit/save/reload behavior for tailored CV, cover letter, recruiter message, and application-answer drafts.
-- [x] Criterion 2 — evidence: S01 delivered job-scoped Gmail candidate ranking, single-message and full-thread import, persisted Gmail metadata, and correspondence workspace rendering; focused backend/frontend tests substantiate lower-cleanup import behavior and timeline/workspace reflection.
-- [x] Criterion 3 — evidence: S01 added `POST /api/gmail/refresh-linked-threads` plus persisted `ExternalThreadId`/`ExternalMessageId`, and both S01 and S05 report duplicate-safe linked-thread refresh that imports later replies into the same job without manual re-import.
-- [x] Criterion 4 — evidence: S03 added context-grounded follow-up drafting from imported correspondence plus saved package material and kept the explicit manual-send boundary; focused backend/frontend tests and follow-up workspace behavior substantiate the drafting loop.
-- [x] Criterion 5 — evidence: S04 and S05 align `/jobs`, `/dashboard`, `/reminders`, and the per-job workspace around one routed control loop, with daily-loop and integrated trust-loop tests covering the shared workflow path.
-- [x] Criterion 6 — evidence: S03 and S05 preserve the manual-send boundary; drafting/regeneration stays separate from `send-followup`, and requirement R008 remains constrained/active.
-- [ ] Integrated live re-check against real behavior — gap: milestone definition of done requires success criteria to be re-checked against live behavior and final integrated acceptance scenarios to pass, but the available evidence remains mostly contract/test-based. S01 explicitly says live Gmail UAT was not executed, S05 says full live UAT still depends on resolving the backend CORS/runtime mismatch on `http://localhost:5202`, and the milestone does not yet contain executed end-to-end acceptance results for the full real loop.
-
-## Slice Delivery Audit
-| Slice | Claimed | Delivered | Status |
-|-------|---------|-----------|--------|
-| S01 | User can connect Gmail, review likely messages/threads for a job, import a message or full thread, and trust linked Gmail threads to stay current without manual re-import. | Summary substantiates ranked job-aware Gmail candidates, duplicate-safe single-message/thread import, persisted Gmail metadata, and linked-thread refresh on known job-linked threads. | pass |
-| S02 | Imported job plus profile/CV context generates materially better tailored CV and cover-letter drafts that feel specific and usable. | Summary substantiates stronger package-context assembly plus persisted generate/edit/save/reset workspace for package artifacts. | pass |
-| S03 | Inside a job, the user can generate follow-up and reply drafts grounded in imported/auto-refreshed correspondence plus saved application context, then edit before sending manually. | Summary substantiates grounded follow-up drafting, exposed context metadata, editable draft flow, and explicit manual-send/log boundary. | pass |
-| S04 | Job table becomes primary overview and dashboard/follow-up surfaces clearly show what needs attention next. | Summary substantiates routed dashboard/reminders/job-table actions and focused UI/browser proof, but the checked-in `S04-UAT.md` is still a doctor-created placeholder rather than a real executed UAT artifact. | needs-attention |
-| S05 | Full loop works cleanly in a real environment: import job → generate package → apply externally → import/update correspondence automatically → draft follow-up/reply → track progress confidently. | Summary substantiates shared workflow-signal contract, visible package/continuity trust state, and integrated regression coverage, but also states full live UAT is still blocked by backend CORS/runtime mismatch, so the “real environment” claim is not yet fully closed. | fail |
-
-## Cross-Slice Integration
-- S01 → S02: aligned. S02 explicitly consumes imported correspondence and recruiter/thread context from S01 in package generation.
-- S01 → S03: aligned. S03 builds follow-up context from persisted correspondence and linked-thread metadata instead of transient Gmail candidates.
-- S02 → S03: aligned. S03 reuses saved package fields and the marker-delimited application-answer block established in S02.
-- S03 → S04: aligned. S04 routes users into the Follow-up and Tailored CV workspace tabs rather than inventing a second compose loop.
-- S04 → S05: partially aligned. S05 centralizes workflow signals and integrated routing as planned, but the boundary-map expectation of final live integration proof is not yet satisfied because the available evidence stops at tests plus limited browser shell verification.
-
-## Requirement Coverage
-- Coverage is mapped for all active requirements: R008 is addressed by S03/S05 and R009 is addressed by S04 (with later supporting slices planned outside M001).
-- Validated requirements R001, R002, R003, R004, R005, R006, R007, and R010 all have at least one substantiating slice.
-- No active requirement is completely unaddressed.
-- Remaining concern is validation depth, not mapping breadth: milestone-level live proof is still missing for the integrated loop, and S04’s UAT artifact is incomplete.
-
-## Verdict Rationale
-`needs-remediation` because the milestone has strong implementation and regression-test evidence, but it does not yet meet its own definition of done for live integrated acceptance. The most material gaps are:
-
-1. **No executed full-loop live acceptance evidence.** S01 deferred live Gmail UAT, and S05 explicitly reports that full browser UAT is still blocked by backend CORS/runtime mismatch.
-2. **S05’s claimed “real environment” outcome is not fully substantiated.** The summary itself narrows proof to integrated tests plus limited browser shell verification.
-3. **S04’s UAT artifact is still a placeholder.** Even though S04 summary references browser verification, the required human-verification artifact was not properly closed.
-
-These are milestone-sealing gaps rather than cosmetic documentation issues, because M001 explicitly requires live behavior re-checks and final integrated acceptance scenarios before completion.
-
-## Remediation Plan
-- **S06: Live environment stabilization and end-to-end acceptance rerun** — fix the backend/frontend runtime/CORS mismatch for the M001 environment, then execute and record a real browser-based acceptance pass covering `/jobs` → workspace package state → Gmail linked-thread refresh/continuity → grounded follow-up draft → `/dashboard` and `/reminders` entry consistency, without violating the manual-send boundary.
-- **S07: Daily-loop UAT artifact closure** — replace the placeholder `S04-UAT.md` with a real executed UAT record that confirms the overview surfaces and job workspace behave coherently for the same job, using the stabilized environment from S06.

.gsd/milestones/M001/slices/S01/S01-PLAN.md

@@ -1,12 +0,0 @@
-# S01: Smarter Gmail import and matching
-
-**Goal:** Finish S01 by turning the existing job-aware Gmail import flow into a live linked-thread continuity loop for one job workspace.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Add linked Gmail thread refresh to the backend contract** — 
-  - Files: JobTrackerApi/Controllers/GmailController.cs, JobTrackerApi/Services/GmailOAuthService.cs, JobTrackerApi.Tests/GmailControllerTests.cs, JobTrackerApi/Program.cs
-  - Verify: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests`
-- [x] **T02: Surface live Gmail thread continuity in the job workspace** — 
-  - Files: job-tracker-ui/src/components/Correspondence.tsx, job-tracker-ui/src/types.ts, job-tracker-ui/src/correspondence-gmail-import.test.tsx, job-tracker-ui/src/components/JobDetailsDialog.tsx
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx`

.gsd/milestones/M001/slices/S01/S01-RESEARCH.md

@@ -1,110 +0,0 @@
-# S01 — Research
-
-**Date:** 2026-03-24
-
-## Summary
-
-S01 owns **R001** and **R002** directly, and it materially supports **R010** because imported correspondence becomes part of the job timeline and later follow-up context. The codebase already has a complete Gmail OAuth path, a Gmail message listing endpoint, single-message and thread import endpoints, and a per-job correspondence UI. The gap is not missing Gmail plumbing; it is that matching is still mostly manual. The backend returns raw Gmail search results, while the frontend (`job-tracker-ui/src/components/Correspondence.tsx`) applies a lightweight client-side score based only on the freeform query, snippet text, and already-imported subjects. That does not use the actual job/company context strongly enough to satisfy the “less manual cleanup” bar in R002.
-
-The best approach is to keep the existing OAuth/import flow and add a **job-aware matching layer** rather than replacing the Gmail integration. In practice that means: enrich backend candidate discovery around a specific `JobApplication`, return grouped thread/message suggestions with explicit match reasons/confidence inputs, and then update the correspondence dialog to present those suggestions first. This follows the current architecture cleanly and preserves the no-auto-send boundary from D002. The React side should keep async work consolidated instead of scattering additional fetches across effects; the loaded `react-best-practices` skill is relevant here, especially `async-parallel` and `client-event-listeners`.
-
-## Recommendation
-
-Add a dedicated **job-scoped Gmail matching surface** on top of the existing endpoints instead of trying to make the current generic `/api/gmail/messages` search UI smarter only in the browser.
-
-Recommended shape:
-- Backend: add a job-aware endpoint in `JobTrackerApi/Controllers/GmailController.cs` that accepts `jobApplicationId` and optional overrides, loads the job + company context, builds Gmail queries from `JobTitle`, `Company.Name`, `Company.RecruiterEmail`, recruiter name, and recent imported correspondence, then returns ranked message/thread candidates with **match reasons** and enough metadata for import decisions.
-- Persistence: if the planner wants durable thread-aware behavior, extend `Models/Correspondence.cs` beyond `ExternalMessageId` to also persist at least `ExternalThreadId` and raw sender/recipient metadata. This is the cleanest way to support downstream S03 reply/follow-up context without re-deriving it later.
-- Frontend: refactor `job-tracker-ui/src/components/Correspondence.tsx` so the Gmail tab consumes enriched API data instead of doing primary ranking locally. `JobDetailsDialog.tsx` already loads the full job; passing the job or a reduced job-context prop into `Correspondence` is cheaper than forcing the Gmail tab to rediscover job facts.
-
-Why this approach:
-- It uses the existing Gmail OAuth/token flow unchanged.
-- It moves matching logic to the backend where job context, dedupe checks, and future heuristics are easier to test.
-- It avoids over-investing in fragile client-only heuristics.
-- It creates a natural seam for S03, where better thread metadata and message provenance will matter again.
-
-## Implementation Landscape
-
-### Key Files
-
-- `JobTrackerApi/Controllers/GmailController.cs` — current Gmail API surface. Has `/status`, `/connect-url`, `/messages`, `/import`, and `/import-thread`. Import endpoints already attach messages to `JobApplication` and dedupe by `Correspondence.ExternalMessageId`, but discovery is still generic and not job-aware.
-- `JobTrackerApi/Services/GmailOAuthService.cs` — Gmail OAuth/token refresh and Gmail API access. `ListMessagesAsync` currently calls the Gmail list endpoint and then does an **N+1** sequence of `GetMessageAsync` calls to hydrate summaries. There is no thread-specific fetch API, no job-aware query builder, and no ranking/match-reason contract here yet.
-- `job-tracker-ui/src/components/Correspondence.tsx` — the main S01 frontend surface. It opens the Gmail dialog, loads `/gmail/status`, loads `/gmail/messages`, groups by `threadId`, and sorts using `scoreMessage(...)`. Current suggestions come from existing correspondence subjects, not from job/company/recruiter context.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — already loads the full `JobApplication` record and hosts the Correspondence tab. This is the easiest place to pass job context into `Correspondence` instead of refetching it inside the Gmail tab.
-- `job-tracker-ui/src/types.ts` — frontend contracts for `GmailStatus`, `GmailMessageSummary`, and `CorrespondenceMessage`. Any enriched matching response or persisted metadata expansion needs updates here.
-- `Models/Correspondence.cs` — currently stores `From`, `Subject`, `Channel`, `ExternalMessageId`, `Content`, and `Date`. No `ThreadId`, no original Gmail sender/recipient fields, and no match/debug metadata.
-- `Data/JobTrackerContext.cs` — EF relationships and ownership filters. `JobApplication`, `Company`, and `GmailConnection` are user-scoped via query filters; new Gmail-matching endpoints should continue loading jobs through this context rather than bypassing ownership.
-- `Models/Company.cs` and `Models/JobApplication.cs` — hold the matching signals that the current Gmail UI ignores: `Company.Name`, `RecruiterEmail`, `RecruiterName`, `JobTitle`, `JobUrl`, `ShortSummary`, and existing correspondence/timeline relationships.
-- `JobTrackerApi/Controllers/CorrespondenceController.cs` — current create/list/delete API for job-linked messages. If S01 persists extra Gmail metadata, this contract may need to expose it to the UI and timeline.
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — downstream dependency surface. It already reads `Correspondences` for follow-up drafting and timeline assembly, so better message/thread metadata here directly helps S03.
-- `JobTrackerApi/Program.cs` — important migration/backfill guardrail. The app manually ensures legacy SQLite/MySQL columns such as `Correspondences.Subject`, `Channel`, and `ExternalMessageId`. If S01 adds new persistence columns, these compatibility blocks must be updated alongside the EF migration.
-- `JobTrackerApi.Tests/GmailControllerTests.cs` — only covers the empty-thread import validation case today. Good starting point, but far below the verification level needed for S01.
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — representative React test style: mock `api`, render `JobDetailsDialog`, assert visible tab behavior. Follow this pattern for new Gmail suggestion/import UI tests.
-
-### Build Order
-
-1. **Decide and lock the backend contract first.**
-   - Prove what a “smarter match” response looks like: message/thread grouping, rank/confidence, reasons, imported/already-linked flags, and import actions.
-   - This is the riskiest part and unblocks everything else.
-
-2. **Implement job-aware matching in `GmailController` + supporting service/helpers.**
-   - Load `JobApplication` with `Company`.
-   - Build candidate Gmail queries from job/company/recruiter data.
-   - Merge/dedupe results by message id or thread id.
-   - Compute match reasons server-side.
-   - Keep existing `/import` and `/import-thread` behavior unless the new contract proves they need richer return payloads.
-
-3. **Only after the contract is stable, refactor `Correspondence.tsx`.**
-   - Replace `scoreMessage(...)` as the primary ranking engine with server-provided ranking/reasons.
-   - Pass job context from `JobDetailsDialog.tsx` rather than introducing another job fetch in the correspondence tab.
-   - Keep manual query override/search available as a fallback, not the primary UX.
-
-4. **Then extend persistence if needed for thread continuity.**
-   - Add correspondence metadata only if the chosen backend contract needs it for dedupe, import clarity, or future reply context.
-   - If added, update model, migration, and `Program.cs` compatibility shims together.
-
-5. **Finish with tests.**
-   - Backend tests for matching/import behavior first.
-   - Frontend tests for the new Gmail suggestion UI second.
-
-### Verification Approach
-
-- Backend unit/integration tests:
-  - `dotnet test JobTrackerApi.Tests`
-  - Add tests for: job-aware candidate endpoint contract, dedupe behavior for already-imported messages, ownership-scoped job lookup, and thread import summary results.
-- Frontend tests:
-  - `npm test -- --watch=false` from `job-tracker-ui`
-  - Add React tests covering: Gmail tab rendering ranked suggestions, showing match reasons, import button states, and fallback/manual search behavior.
-- Contract/manual verification:
-  - Open a job in `JobDetailsDialog` → Correspondence tab.
-  - Confirm Gmail connection state still works.
-  - Confirm the Gmail tab now shows job-relevant suggestions before freeform searching.
-  - Import a single message and a full thread; verify the job timeline/correspondence list updates and duplicates are skipped.
-- If persistence changes land:
-  - Verify schema startup still succeeds on existing dev DBs because `JobTrackerApi/Program.cs` legacy `EnsureColumn(...)` blocks are easy to miss.
-
-## Constraints
-
-- `Data/JobTrackerContext.cs` applies ownership query filters to `Company`, `JobApplication`, and `GmailConnection`. Any new Gmail matching endpoint must keep loading through EF-scoped entities, not raw unfiltered ids.
-- `JobTrackerApi/Services/GmailOAuthService.cs` currently exposes only message list/detail methods. There is no reusable thread-fetch or search-aggregation abstraction yet.
-- `JobTrackerApi/Program.cs` contains manual schema repair code for SQLite/MySQL. Adding correspondence metadata requires updating both EF migration artifacts and these runtime compatibility paths.
-- `Models/Correspondence.cs` does not currently preserve Gmail thread identity or raw sender/recipient fields, which limits downstream thread-aware UX.
-
-## Common Pitfalls
-
-- **Leaving ranking in the browser** — `Correspondence.tsx` can polish server results, but if the primary intelligence stays in `scoreMessage(...)`, S01 will remain query-driven and fragile.
-- **Adding columns without updating `Program.cs`** — this repo relies on startup-time `EnsureColumn(...)` logic for legacy/dev databases; migration-only changes are incomplete here.
-- **Duplicating job fetches in the dialog tree** — `JobDetailsDialog.tsx` already owns the job record. Per the `react-best-practices` guidance (`async-parallel`, `client-event-listeners`), keep async fetching consolidated and avoid adding more dialog-level waterfalls or duplicated global listeners.
-- **Treating thread import as enough without thread metadata** — importing all messages in a thread helps today, but without persisting thread identity the app still cannot reason clearly about thread continuity later.
-
-## Open Risks
-
-- Gmail search quality may still be noisy even after better query construction; the planner should expect one iteration on ranking heuristics once real data is exercised.
-- `ListMessagesAsync` is sequential and could become noticeably slow if the new matching flow issues multiple Gmail searches per job. If that happens, batching/parallelization inside the Gmail service becomes part of S01, not a later optimization.
-
-## Skills Discovered
-
-| Technology | Skill | Status |
-|------------|-------|--------|
-| React | `react-best-practices` | available |
-| ASP.NET Core | `openai/skills@aspnet-core` | installed |

.gsd/milestones/M001/slices/S01/S01-SUMMARY.md

@@ -1,170 +0,0 @@
----
-id: S01
-parent: M001
-milestone: M001
-provides:
-  - Job-scoped Gmail matching and import now run from the job workspace with backend-owned ranking reasons, duplicate-aware import contracts, persisted Gmail thread metadata, and linked-thread refresh that imports later replies into the same job.
-affects:
-  - S02
-  - S03
-  - S04
-  - S05
-key_files:
-  - JobTrackerApi/Controllers/GmailController.cs
-  - JobTrackerApi/Services/GmailOAuthService.cs
-  - JobTrackerApi.Tests/GmailControllerTests.cs
-  - Models/Correspondence.cs
-  - JobTrackerApi/Controllers/CorrespondenceController.cs
-  - job-tracker-ui/src/components/Correspondence.tsx
-  - job-tracker-ui/src/components/JobDetailsDialog.tsx
-  - job-tracker-ui/src/types.ts
-  - job-tracker-ui/src/correspondence-gmail-import.test.tsx
-key_decisions:
-  - Keep Gmail continuity bounded to known `ExternalThreadId` values for one job via `POST /api/gmail/refresh-linked-threads` instead of inbox-wide Gmail watch/history infrastructure.
-  - Treat the backend as the source of truth for Gmail candidate ranking, duplicate visibility, and linked-thread refresh counts so the workspace UI stays explanatory without re-implementing Gmail heuristics in React.
-patterns_established:
-  - Gmail-derived correspondence is first-class job history: imported rows persist external message/thread ids plus sender/recipient labels and can be rendered directly in the timeline/workspace.
-  - Linked-thread continuity is pull-based and duplicate-safe: refresh reads already-linked thread ids for one owned job, skips known external message ids, and imports only new Gmail replies into that same job.
-  - The workspace distinguishes ranked import suggestions from already-linked live threads, with automatic one-shot refresh per loaded job/thread-set and an explicit manual refresh action.
-observability_surfaces:
-  - GET /api/gmail/status
-  - GET /api/gmail/job-candidates
-  - POST /api/gmail/import
-  - POST /api/gmail/import-thread
-  - POST /api/gmail/refresh-linked-threads
-  - persisted Correspondence.ExternalMessageId / ExternalThreadId / ExternalFrom / ExternalTo
-  - JobTrackerApi.Tests/GmailControllerTests.cs
-  - job-tracker-ui/src/correspondence-gmail-import.test.tsx
-drill_down_paths:
-  - .gsd/milestones/M001/slices/S01/tasks/T01-SUMMARY.md
-  - .gsd/milestones/M001/slices/S01/tasks/T02-SUMMARY.md
-  - .gsd/milestones/M001/slices/S01/tasks/T03-SUMMARY.md
-duration: ~1 slice closure session + prior executor task work
-verification_result: passed
-completed_at: 2026-03-24T11:54:52+01:00
----
-
-# S01: Smarter Gmail import and matching
-
-## Outcome
-
-S01 now delivers a job-aware Gmail import loop that is materially closer to the milestone trust bar than the pre-slice state. The workspace can:
-
-- connect Gmail and load ranked candidate messages/threads for one owned job
-- explain why each Gmail candidate matched via score/confidence/match reasons
-- import either a single message or an entire thread with duplicate-safe result counts
-- persist Gmail thread identity plus raw sender/recipient labels on correspondence rows
-- refresh already-linked Gmail threads for that same job and import only later unseen replies
-- surface that linked-thread state back in the workspace without making the user manually re-import the thread
-
-The biggest slice change is that Gmail import is no longer just “pick a message and save a snapshot.” It is now a bounded continuity loop around stored `ExternalThreadId` values.
-
-## What actually shipped
-
-### Backend contract
-
-`JobTrackerApi/Controllers/GmailController.cs` and `JobTrackerApi/Services/GmailOAuthService.cs` now cover three distinct Gmail workspace behaviors:
-
-1. **Job-aware candidate ranking** via `GET /api/gmail/job-candidates`
-   - backend aggregates Gmail hits per job query
-   - duplicate Gmail hits are merged server-side
-   - response includes weighted match reasons, matched queries, imported flags, confidence, and thread/message counts
-
-2. **Duplicate-safe import** via `POST /api/gmail/import` and `POST /api/gmail/import-thread`
-   - single-message imports return `Imported`/`Skipped` plus the imported or existing correspondence row
-   - thread imports report imported/skipped counts instead of silently duplicating rows
-   - imported correspondence persists `ExternalMessageId`, `ExternalThreadId`, `ExternalFrom`, and `ExternalTo`
-
-3. **Linked-thread continuity** via `POST /api/gmail/refresh-linked-threads`
-   - reads the owned job’s existing linked Gmail thread ids
-   - fetches those threads from Gmail
-   - skips already-known external message ids
-   - imports only new messages into the same job
-   - returns refresh counts per job and per thread
-   - distinguishes invalid job, disconnected Gmail, empty linked-thread set, and already-current outcomes
-
-### Persistence and compatibility
-
-`Models/Correspondence.cs`, `JobTrackerApi/Controllers/CorrespondenceController.cs`, and `JobTrackerApi/Program.cs` now treat Gmail metadata as part of the durable correspondence model, including compatibility guards for the extra columns.
-
-### Workspace UI
-
-`job-tracker-ui/src/components/Correspondence.tsx` now makes the job workspace the real Gmail import surface instead of a generic search-first flow.
-
-It now:
-
-- loads backend-ranked Gmail candidates for the current job
-- shows confidence/score/match reasons/already-linked status
-- preserves manual query override through the same endpoint
-- renders persisted Gmail thread/from/to metadata in the correspondence list
-- automatically refreshes linked Gmail threads once per loaded job/thread-set
-- exposes a manual “Refresh linked threads” action for another bounded pull in the same session
-- updates the workspace after message import, thread import, and linked-thread refresh
-
-`job-tracker-ui/src/correspondence-gmail-import.test.tsx` now covers both the ranked import path and the no-manual-reimport continuity path.
-
-## Verification run in this closure session
-
-### Automated checks
-
-| Command | Result |
-|---|---|
-| `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests` | ✅ passed |
-| `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx` | ✅ passed |
-| `dotnet build JobTrackerApi/JobTrackerApi.csproj` | ✅ passed |
-
-The backend verification command originally described in project knowledge was blocked by unrelated test-project drift earlier in the milestone, but that drift was fixed during this closure pass, and the exact filtered command now passes.
-
-### Observability confirmed
-
-The slice’s durable inspection surfaces are now coherent:
-
-- `GET /api/gmail/status` exposes Gmail connection freshness (`lastSyncedAt`)
-- `GET /api/gmail/job-candidates` exposes job-scoped ranking details and duplicate visibility
-- `POST /api/gmail/refresh-linked-threads` exposes refresh counts and per-thread status
-- persisted correspondence rows carry external Gmail thread/message/from/to metadata
-- focused backend/frontend tests encode the intended behavior for future refactors
-
-### Human / live Gmail UAT status
-
-This auto-mode session did **not** have a live Gmail account wired for a real-account browser pass, so the required human/live UAT was prepared as a concrete script in `S01-UAT.md` rather than executed here. The implementation and automated slice gates passed; the live-account trust check remains a human runbook item.
-
-## Requirement impact
-
-- **R002** moved to **validated** based on the shipped linked-thread refresh contract plus focused backend/frontend verification.
-- **R010** remains active, but S01 materially advances it by making Gmail correspondence continuity part of the same job history instead of a one-off import snapshot.
-
-## Key downstream implications
-
-### For S02
-
-Imported Gmail correspondence is now trustworthy enough to use as drafting context. Downstream draft generation should consume job-linked correspondence rows directly, including sender/recipient/thread metadata when useful for tone or recipient context.
-
-### For S03
-
-Reply/follow-up drafting can now assume two important invariants:
-
-- Gmail correspondence is attached to a specific job
-- later Gmail replies can be pulled into that same job without user re-import
-
-That means reply/follow-up context assembly should build from the persisted job correspondence set, not from transient Gmail candidate data.
-
-### For S04/S05
-
-Daily-loop surfaces can now rely on a clearer distinction between:
-
-- jobs that only have candidate Gmail matches
-- jobs with already-linked live Gmail threads
-- jobs whose linked threads were refreshed and imported new correspondence
-
-Those are useful action/readiness signals for dashboards, follow-up surfaces, and final end-to-end trust checks.
-
-## Notable lessons / non-obvious details
-
-- The bounded sync model is deliberate: refresh is over known linked thread ids for one job, not inbox-wide Gmail watch/history state.
-- The React workspace auto-refresh is intentionally one-shot per `jobId + linked thread set`; repeated pulls in the same session require the explicit refresh action.
-- The filtered Gmail backend test command compiles the whole `JobTrackerApi.Tests` project before filtering, so unrelated test drift can still block slice verification if future work breaks test signatures again.
-
-## Slice verdict
-
-S01 now establishes the milestone’s Gmail foundation: smarter matching, clearer import trust signals, persisted Gmail metadata, and real linked-thread continuity in the job workspace.

.gsd/milestones/M001/slices/S01/S01-UAT.md

@@ -1,183 +0,0 @@
-# S01 UAT: Smarter Gmail import and matching
-
-## Scope
-
-Validate that one real job workspace can:
-
-- connect Gmail
-- show ranked Gmail message/thread suggestions for that job
-- import a single message or full thread into the job
-- preserve Gmail thread/sender/recipient metadata in correspondence
-- refresh already-linked Gmail threads and surface later inbound or user-sent replies without manual re-import
-
-## Preconditions
-
-1. Run the app with a build that includes S01 changes.
-2. Sign in as a normal local user who owns at least one job application record.
-3. Choose one job with a realistic company name, recruiter email, or recruiter name so Gmail matching has meaningful context.
-4. Use a Gmail account that contains at least one relevant thread for that job.
-5. For the continuity test, ensure that thread can receive a new inbound reply or that you can send a reply from your Gmail account during the test.
-6. Start with no browser extensions that block Google OAuth popups.
-
----
-
-## Test Case 1 — Connect Gmail from the job workspace
-
-**Goal:** Confirm Gmail connection starts from the job correspondence workspace and returns visible connection state.
-
-### Steps
-
-1. Open the chosen job in the job workspace/dialog.
-2. Go to the **Correspondence** area.
-3. Click **Import email**.
-4. Open the **Google** tab.
-5. If Gmail is not connected, click **Connect Gmail**.
-6. Complete the Google OAuth flow in the popup.
-7. Return to the job workspace.
-
-### Expected results
-
-- The popup closes or reports success.
-- The Gmail section shows the connected Gmail address.
-- The Gmail tab becomes usable without a page reload.
-- A `Last synced` timestamp or connected-state indicator is visible.
-
----
-
-## Test Case 2 — Ranked Gmail suggestions are job-aware and explanatory
-
-**Goal:** Confirm the workspace suggests likely Gmail threads/messages for the current job and explains why.
-
-### Steps
-
-1. Stay in the same job’s **Correspondence → Google** tab.
-2. Wait for candidate Gmail suggestions to load automatically.
-3. Review the first 3 suggested threads/messages.
-4. Use the manual search box with a more specific override such as the recruiter email or a subject fragment.
-5. Click **Search**.
-
-### Expected results
-
-- Suggestions are scoped to the current job rather than a generic inbox list.
-- Each suggested thread/message shows visible ranking context such as confidence, score, and match reasons.
-- Already-linked content, if any, is marked as already linked/imported rather than presented as a fresh import with no explanation.
-- Manual search override changes the candidate list without breaking the job-aware context.
-
-### Edge checks
-
-- If the job has no good recruiter/company data, the UI should still show either fallback queries or a clear empty state rather than a broken panel.
-- If no Gmail matches exist, the UI should clearly say there are no matches yet for this job/search override.
-
----
-
-## Test Case 3 — Import a single Gmail message into the job
-
-**Goal:** Confirm single-message import attaches Gmail correspondence to the correct job and preserves metadata.
-
-### Steps
-
-1. In the Google tab, locate a suggested Gmail message that belongs to the chosen job.
-2. Click **Import email** for that message.
-3. Return focus to the correspondence list.
-4. Inspect the newly imported correspondence row.
-5. Without changing jobs, try importing the exact same Gmail message again if it is still visible.
-
-### Expected results
-
-- The imported message appears in the chosen job’s correspondence history immediately.
-- The correspondence row shows the imported subject/body content.
-- Gmail metadata is visible on that row, including thread id and sender/recipient labels when available.
-- Re-importing the same message does **not** create a duplicate correspondence entry.
-- The UI reports that the message was already linked or skipped on the second attempt.
-
----
-
-## Test Case 4 — Import an entire Gmail thread into the job
-
-**Goal:** Confirm thread import brings multiple related Gmail messages into the same job and stays duplicate-safe on repeat.
-
-### Steps
-
-1. In the Google tab, choose a suggested thread with at least 2 messages.
-2. Click **Import thread**.
-3. Inspect the correspondence list after import.
-4. Count how many entries from that thread now appear on the job.
-5. Trigger **Import thread** again for the same thread if it remains listed.
-
-### Expected results
-
-- Multiple correspondence entries from the selected Gmail thread are attached to the same job.
-- Each imported entry preserves Gmail metadata (`Thread`, `From`, `To`) where present.
-- The import result reports imported/skipped counts.
-- Repeating the thread import does not duplicate messages already attached to the job.
-
-### Edge checks
-
-- If some messages from the thread were already imported before the thread import, only the missing messages should be added.
-- If the thread is fully imported already, the result should show skipped-only behavior rather than silently doing nothing.
-
----
-
-## Test Case 5 — Automatic linked-thread refresh imports a later reply without manual re-import
-
-**Goal:** Validate the core slice promise: once a Gmail thread is linked to a job, later replies appear on that job through refresh rather than a fresh import action.
-
-### Steps
-
-1. Start from a job that already has at least one imported Gmail message/thread with a visible linked thread id.
-2. In Gmail, send a new reply on that same thread **or** wait for a real inbound reply from the recruiter.
-3. Return to the job workspace.
-4. Reopen the job if needed, but do **not** use **Import email** or **Import thread** for the new reply.
-5. Wait for the workspace to settle.
-6. If the new reply does not appear automatically after the initial load, click **Refresh linked threads** once.
-7. Inspect the correspondence list.
-
-### Expected results
-
-- The workspace recognizes that the job has linked Gmail threads.
-- The new reply appears under the same job without the user manually selecting the thread again from Gmail candidates.
-- The new reply preserves thread continuity and sender/recipient metadata.
-- The Gmail area shows a refresh summary such as imported count, linked thread count, or already-current state.
-- Running refresh again immediately after a successful import should not create duplicates.
-
-### Edge checks
-
-- Test both directions if possible:
-  - recruiter → user inbound reply
-  - user → recruiter sent reply from Gmail
-- If there are no new messages, refresh should report that linked threads are already current rather than pretending new content arrived.
-
----
-
-## Test Case 6 — Failure visibility is explicit
-
-**Goal:** Confirm the slice does not fail as a silent no-op.
-
-### Steps
-
-1. Disconnect Gmail from the workspace.
-2. Reopen the Gmail tab for the same job.
-3. Attempt to use the Gmail area again.
-4. Reconnect Gmail.
-5. Open a different job with no imported Gmail thread ids.
-6. Check whether linked-thread refresh controls and status remain understandable.
-
-### Expected results
-
-- Disconnected Gmail state is explicit and actionable.
-- The workspace does not pretend linked-thread refresh succeeded while disconnected.
-- A job with no linked Gmail threads shows a clear “no linked threads yet” state rather than a hidden failure.
-- Invalid/empty states remain distinct from successful refreshes.
-
----
-
-## Acceptance summary
-
-S01 passes UAT when all of the following are true for at least one real job:
-
-- Gmail can be connected from the correspondence workspace.
-- The workspace shows sensible ranked Gmail suggestions for that job.
-- Single-message and full-thread imports attach correspondence to that job and stay duplicate-safe.
-- Imported correspondence visibly preserves Gmail metadata.
-- A later reply on an already-linked Gmail thread appears on the job through the linked-thread refresh path without requiring the user to manually re-import the thread.
-- Empty/disconnected/already-current states are visible and understandable.

.gsd/milestones/M001/slices/S01/tasks/T01-PLAN.md

@@ -1,54 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 4
-skills_used:
-  - aspnet-core
-  - test
----
-
-# T01: Add linked Gmail thread refresh to the backend contract
-
-**Slice:** S01 — Smarter Gmail import and matching
-**Milestone:** M001
-
-## Description
-
-Finish the backend half of S01 by making already-imported Gmail threads refreshable for a single job. The executor should build on the existing job-aware matching/import flow already present in `GmailController`, keep the scope bounded to known linked thread ids, and return a clear refresh result that distinguishes new imports from duplicate-only refreshes and disconnected/failure states.
-
-## Steps
-
-1. Inspect the current Gmail import code in `JobTrackerApi/Controllers/GmailController.cs`, the Gmail API wrapper in `JobTrackerApi/Services/GmailOAuthService.cs`, and the current `GmailControllerTests` coverage to identify the smallest thread-refresh contract that can satisfy R002.
-2. Add a job-scoped linked-thread refresh path in `JobTrackerApi/Controllers/GmailController.cs` that loads one owned job, gathers distinct linked `ExternalThreadId` values from its correspondence, fetches Gmail messages for those known threads, and imports only unseen `ExternalMessageId` values into the same job.
-3. Extend `JobTrackerApi/Services/GmailOAuthService.cs` with the thread-level retrieval helper(s) needed by that controller path, and keep diagnostics bounded to counts, ids, timestamps, and connection state rather than full message bodies.
-4. Expand `JobTrackerApi.Tests/GmailControllerTests.cs` to cover successful refresh with a new inbound reply, successful refresh with a new user-sent reply, duplicate-only refresh, disconnected Gmail state, and invalid/inaccessible job handling.
-
-## Must-Haves
-
-- [ ] The refresh path operates on already-linked Gmail thread ids for one owned job; it does not introduce inbox-wide watch/history infrastructure for this slice.
-- [ ] New Gmail replies import into the same `JobApplication` with existing duplicate protection based on `ExternalMessageId`.
-- [ ] The refresh contract exposes enough status to tell whether the run imported new messages, found only duplicates, or could not run because Gmail/job state was invalid.
-
-## Verification
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests`
-- Confirm the updated tests assert at least one new-message refresh, one duplicate-only refresh, and one failure-path outcome.
-
-## Observability Impact
-
-- Signals added/changed: linked-thread refresh result counts, last refresh/sync timestamp updates, and explicit disconnected/invalid-job outcomes.
-- How a future agent inspects this: read the refresh DTO and controller action in `JobTrackerApi/Controllers/GmailController.cs` and the focused assertions in `JobTrackerApi.Tests/GmailControllerTests.cs`.
-- Failure state exposed: the API should make it obvious whether nothing happened because there were no linked threads, Gmail was disconnected, every message was already imported, or the job was not accessible.
-
-## Inputs
-
-- `JobTrackerApi/Controllers/GmailController.cs` — current job-aware Gmail matching and import endpoints.
-- `JobTrackerApi/Services/GmailOAuthService.cs` — current Gmail list/detail helpers and connection status updates.
-- `JobTrackerApi.Tests/GmailControllerTests.cs` — existing Gmail controller test coverage.
-- `JobTrackerApi/Program.cs` — existing Gmail/correspondence runtime wiring and compatibility guards.
-
-## Expected Output
-
-- `JobTrackerApi/Controllers/GmailController.cs` — adds the linked-thread refresh contract for one job.
-- `JobTrackerApi/Services/GmailOAuthService.cs` — adds thread-fetch support used by refresh.
-- `JobTrackerApi.Tests/GmailControllerTests.cs` — proves refresh success, duplicate-only, and failure-path behavior.
-- `JobTrackerApi/Program.cs` — updates any wiring needed for the new refresh flow or diagnostics.

.gsd/milestones/M001/slices/S01/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S01
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T01: Add linked Gmail thread refresh to the backend contract
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S01/tasks/T01-VERIFY.json

@@ -1,9 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T01",
-  "unitId": "M001/S01/T01",
-  "timestamp": 1774350445753,
-  "passed": true,
-  "discoverySource": "none",
-  "checks": []
-}

.gsd/milestones/M001/slices/S01/tasks/T02-PLAN.md

@@ -1,55 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 4
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T02: Surface live Gmail thread continuity in the job workspace
-
-**Slice:** S01 — Smarter Gmail import and matching
-**Milestone:** M001
-
-## Description
-
-Complete S01 in the UI by turning the existing ranked Gmail import tab into a live linked-thread workspace. The executor should preserve the current ranked suggestion/import flow, then layer in automatic refresh for already-linked Gmail threads so the user sees new replies appear on the same job without using the import action again.
-
-## Steps
-
-1. Inspect the current Gmail UI in `job-tracker-ui/src/components/Correspondence.tsx`, the host wiring in `job-tracker-ui/src/components/JobDetailsDialog.tsx`, and the existing component test in `job-tracker-ui/src/correspondence-gmail-import.test.tsx`.
-2. Update `job-tracker-ui/src/types.ts` and `job-tracker-ui/src/components/Correspondence.tsx` to consume the new backend linked-thread refresh contract and track refresh/loading/freshness state separately from the ranked import-suggestion state.
-3. Wire `job-tracker-ui/src/components/Correspondence.tsx` so already-linked threads refresh automatically at the right moment in the job workspace flow, refresh the rendered correspondence list after sync, and make the linked/live state legible in the UI.
-4. Extend `job-tracker-ui/src/correspondence-gmail-import.test.tsx` to prove the continuity path: after a thread is already linked, a refresh brings in a later Gmail reply and renders it on the same job without another import action.
-
-## Must-Haves
-
-- [ ] The UI keeps ranked job-aware Gmail suggestions for first import while clearly distinguishing already-linked live threads from new import candidates.
-- [ ] Linked-thread refresh happens through the new backend contract and updates the visible correspondence list without requiring the user to click an import button again.
-- [ ] The React test proves the continuity path, not just the original ranked-import path.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx`
-- Manually inspect the Correspondence dialog to confirm linked-thread state, refresh/loading state, and the newly synced message all appear in the workspace.
-
-## Observability Impact
-
-- Signals added/changed: visible linked/live thread state, refresh progress/freshness state, and clearer no-new-messages vs failure feedback.
-- How a future agent inspects this: run `job-tracker-ui/src/correspondence-gmail-import.test.tsx` and inspect the Gmail area in `job-tracker-ui/src/components/Correspondence.tsx`.
-- Failure state exposed: the UI should distinguish refresh failure, disconnected Gmail, no linked threads, and successful refresh with zero new messages.
-
-## Inputs
-
-- `job-tracker-ui/src/components/Correspondence.tsx` — current ranked Gmail import UI.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — host dialog that owns the job workspace.
-- `job-tracker-ui/src/types.ts` — frontend Gmail and correspondence contracts.
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx` — existing Gmail import component test.
-- `JobTrackerApi/Controllers/GmailController.cs` — T01 backend refresh contract consumed by the UI.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/Correspondence.tsx` — renders linked-thread refresh state and continuity behavior.
-- `job-tracker-ui/src/types.ts` — matches the backend refresh contract.
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx` — proves the no-manual-reimport continuity path.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — includes any required wiring for the refreshed workspace flow.

.gsd/milestones/M001/slices/S01/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S01
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T02: Surface live Gmail thread continuity in the job workspace
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S01/tasks/T03-PLAN.md

@@ -1,54 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 4
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T03: Wire ranked Gmail suggestions into the job workspace UI
-
-**Slice:** S01 — Smarter Gmail import and matching
-**Milestone:** M001
-
-## Description
-
-Deliver the user-facing part of the slice in the actual job workspace. The Correspondence tab should stop acting like a generic Gmail search box and instead open with job-aware ranked suggestions from the backend, explain why each candidate is relevant, let the user override with manual search when needed, and refresh the job-linked correspondence view after import.
-
-## Steps
-
-1. Update `job-tracker-ui/src/types.ts` to reflect the new backend candidate contract and enriched correspondence metadata from T01 and T02.
-2. Pass job context from `job-tracker-ui/src/components/JobDetailsDialog.tsx` into `job-tracker-ui/src/components/Correspondence.tsx` so the Gmail tab can request job-aware suggestions without duplicating the job fetch.
-3. Refactor `job-tracker-ui/src/components/Correspondence.tsx` to consume the backend-ranked suggestions, show thread/message match reasons and import state, keep manual Gmail query override/search available, and refresh the rendered correspondence list after successful imports.
-4. Add `job-tracker-ui/src/correspondence-gmail-import.test.tsx` covering ranked suggestion rendering, reason/confidence display, thread vs single-message import actions, and refresh after import.
-
-## Must-Haves
-
-- [ ] The Gmail tab opens on job-aware ranked suggestions instead of using `scoreMessage(...)` as the primary intelligence.
-- [ ] The UI still supports manual Gmail searching as a fallback override, but it no longer depends on freeform query heuristics for the core experience.
-- [ ] The React test proves the user can see ranked suggestions and that importing updates the same job’s correspondence surface.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx`
-- Manually inspect the dialog to confirm ranked reasons/import state are visible and the correspondence list refreshes after import.
-
-## Observability Impact
-
-- Signals added/changed: visible match reasons/confidence/import state in the Gmail tab and clearer import success/duplicate feedback toasts.
-- How a future agent inspects this: read `job-tracker-ui/src/correspondence-gmail-import.test.tsx` and open the Correspondence dialog in the running app.
-- Failure state exposed: the UI should distinguish no matches, already-imported candidates, loading states, and import failures instead of collapsing them into a generic empty list.
-
-## Inputs
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — host dialog that already owns the job record.
-- `job-tracker-ui/src/components/Correspondence.tsx` — current Gmail import UI with client-side ranking.
-- `job-tracker-ui/src/types.ts` — frontend API contracts.
-- `JobTrackerApi/Controllers/GmailController.cs` — T01/T02 backend Gmail candidate and import contract.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — passes job context into the correspondence tab.
-- `job-tracker-ui/src/components/Correspondence.tsx` — renders job-aware Gmail suggestions and refreshed import behavior.
-- `job-tracker-ui/src/types.ts` — matches the updated backend contract.
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx` — proves the UI flow end to end at component level.

.gsd/milestones/M001/slices/S01/tasks/T03-SUMMARY.md

@@ -1,64 +0,0 @@
----
-title: T03 summary
-status: done
-files:
-  - job-tracker-ui/src/components/JobDetailsDialog.tsx
-  - job-tracker-ui/src/components/Correspondence.tsx
-  - job-tracker-ui/src/types.ts
-  - job-tracker-ui/src/correspondence-gmail-import.test.tsx
-observability_surfaces:
-  - job-tracker-ui/src/components/Correspondence.tsx Gmail tab linked-thread state
-  - /gmail/job-candidates requests with queryOverride
-  - /gmail/refresh-linked-threads workspace refresh requests
-  - job-tracker-ui/src/correspondence-gmail-import.test.tsx
-verification:
-  - npm ci (job-tracker-ui)
-  - CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx
----
-
-Wired the job-aware Gmail matching contract into the actual job workspace UI and completed the live linked-thread refresh loop.
-
-## What changed
-
-- `job-tracker-ui/src/types.ts`
-  - added frontend contracts for job-aware Gmail matches, linked-thread refresh results, import results, and enriched correspondence metadata
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx`
-  - passes the loaded `job` into `Correspondence` so the Gmail tab can stay job-aware without another job fetch
-- `job-tracker-ui/src/components/Correspondence.tsx`
-  - replaced client-side Gmail ranking as the primary workflow
-  - Gmail tab now calls `/gmail/job-candidates`
-  - shows confidence, score, match reasons, and already-linked state
-  - preserves manual query override via the same job-aware endpoint
-  - automatically calls `/gmail/refresh-linked-threads` when the job already has linked Gmail thread ids
-  - refreshes correspondence plus Gmail candidate state after single-message, thread, and linked-thread refresh actions
-  - renders persisted Gmail metadata (`ExternalThreadId`, `ExternalFrom`, `ExternalTo`) in the correspondence view
-  - shows linked-thread freshness/import summary inside the Gmail area
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx`
-  - verifies ranked Gmail suggestions render with visible reasons/confidence
-  - verifies single-message import refreshes the same job’s correspondence view
-  - verifies automatic linked-thread refresh shows a later Gmail reply without manual re-import
-  - verifies manual search override is sent as `queryOverride`
-
-## Verification
-
-- frontend dependencies were installed with `npm ci` in `job-tracker-ui`
-- focused React test passed:
-  - `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx`
-
-## Verification Evidence
-
-| # | Command | Exit Code | Verdict | Duration |
-|---|---------|-----------|---------|----------|
-| 1 | `npm ci` (job-tracker-ui) | 0 | ✅ pass | not recorded |
-| 2 | `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx` | 0 | ✅ pass | ~2.8s |
-
-## Diagnostics
-
-- Open a job with imported Gmail correspondence and inspect the Gmail tab chips: linked-thread count, last refresh summary, and Gmail connection `lastSyncedAt` show whether the workspace considers the thread live.
-- Watch network traffic for `GET /gmail/job-candidates` and `POST /gmail/refresh-linked-threads` to confirm the workspace distinguishes ranked suggestions from already-linked thread refresh.
-- Inspect rendered correspondence chips (`Thread ...`, `From ...`, `To ...`) to verify imported Gmail metadata survived the round trip from persistence to UI.
-- Read `job-tracker-ui/src/correspondence-gmail-import.test.tsx` for the durable automated proof of manual query override plus no-manual-reimport continuity.
-
-## Notes
-
-The Gmail tab now treats the backend as the source of truth for ranking while keeping the manual search field as a fallback override, and it refreshes known linked threads once per loaded job/thread-set automatically to avoid re-import loops.

.gsd/milestones/M001/slices/S02/S02-PLAN.md

@@ -1,12 +0,0 @@
-# S02: Stronger AI application package drafting
-
-**Goal:** Make the application package generator use imported job/correspondence context well enough that tailored CV, cover-letter, and recruiter-message drafts feel specific, credible, and worth starting from inside the job workspace.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Strengthen application-package context assembly and backend draft tests** — 
-  - Files: JobTrackerApi/Controllers/JobApplicationsController.cs, JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs
-  - Verify: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests`
-- [x] **T02: Make the job workspace save and present the application package as real working material** — 
-  - Files: job-tracker-ui/src/components/JobDetailsDialog.tsx, job-tracker-ui/src/types.ts, job-tracker-ui/src/job-details-generated-drafts.test.tsx
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx`

.gsd/milestones/M001/slices/S02/S02-SUMMARY.md

@@ -1,101 +0,0 @@
----
-id: S02
-parent: M001
-milestone: M001
-provides:
-  - stronger application-package generation that uses imported correspondence, recruiter/job context, profile CV structure, and attachment signals
-  - a persisted package workspace inside the job dialog for tailored CV, cover letter, recruiter message, and application-answer draft material
-requires:
-  - slice: S01
-    provides: imported and auto-refreshed job-linked correspondence plus trusted thread metadata for package context assembly
-affects:
-  - S03
-key_files:
-  - JobTrackerApi/Controllers/JobApplicationsController.cs
-  - JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs
-  - job-tracker-ui/src/components/JobDetailsDialog.tsx
-  - job-tracker-ui/src/job-details-generated-drafts.test.tsx
-key_decisions:
-  - D006: persist the application-answer draft as a replaceable marker-delimited notes block until a dedicated field exists
-patterns_established:
-  - assemble AI package context from persisted job, recruiter, correspondence, saved-draft, profile-CV, and attachment signals before prompting
-  - treat generated artifacts as editable workspace state with explicit saved/generated/unsaved status rather than disposable preview output
-observability_surfaces:
-  - POST /api/jobapplications/{id}/generate-application-package
-  - PUT /api/jobapplications/{id}/tailored-cv
-  - PUT /api/jobapplications/{id}/application-drafts
-  - job-tracker-ui/src/job-details-generated-drafts.test.tsx
-  - JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs
-duration: 2 tasks
-verification_result: passed
-completed_at: 2026-03-24
----
-
-# S02: Stronger AI application package drafting
-
-**Imported Gmail/job context now feeds a persisted application-package workspace that generates, edits, saves, and reloads job-specific draft material instead of one-shot generic previews.**
-
-## What Happened
-
-S02 closed the main draft-quality gap by wiring S01’s imported correspondence into application-package generation and then making the Tailored CV tab behave like a real working surface.
-
-On the backend, `JobTrackerApi/Controllers/JobApplicationsController.cs` now builds package context from more than the job description. Generation explicitly pulls in recruiter identity, job URL, imported correspondence, saved package material already tied to the job, profile CV structure, and selected attachment signals. That context is reused across tailored CV, cover letter, application answer, recruiter message, and package key points so the returned artifacts can react to real recruiter/thread context instead of defaulting to generic role-summary language.
-
-On the frontend, `job-tracker-ui/src/components/JobDetailsDialog.tsx` now treats tailored CV, cover letter, recruiter message, and application-answer text as one package workspace. Reopening the job loads the saved copy back into the editors, generation replaces the current working copy for all package artifacts, save persists the package back to the job, and reset restores the last saved state. Status chips make the persistence state legible by distinguishing `Saved to job`, `Generated only`, and `Unsaved edits`.
-
-S02 also established a temporary but stable persistence contract for the application-answer draft: until a dedicated field exists, it lives in a marker-delimited block inside `JobApplication.Notes`, and save replaces that block rather than appending indefinitely. That keeps the workspace trustworthy and gives S03 a reliable place to read package context back from.
-
-The net effect is that S01 correspondence is no longer just imported and displayed; it now materially influences package drafting, and the resulting artifacts persist as reusable job workspace material.
-
-## Verification
-
-- `$HOME/.dotnet/dotnet build JobTrackerApi/JobTrackerApi.csproj` — passed
-- `$HOME/.dotnet/dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests` — passed (2 tests)
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx` — passed (2 tests)
-- Observability surfaces confirmed by implementation/tests:
-  - `POST /api/jobapplications/{id}/generate-application-package` now emits package artifacts grounded in correspondence/recruiter/job context
-  - `PUT /api/jobapplications/{id}/tailored-cv` and `PUT /api/jobapplications/{id}/application-drafts` form the durable save loop the workspace depends on
-  - focused backend/frontend tests cover package generation specificity, notes replacement, saved-state load, edit, save, and redisplay behavior
-
-## New Requirements Surfaced
-
-- none
-
-## Deviations
-
-- The plan did not call out storage for the application-answer draft, but execution required a concrete persistence strategy before the workspace could be trustworthy. S02 therefore adopted the marker-delimited notes-block approach captured in D006 instead of introducing a new schema field mid-slice.
-
-## Known Limitations
-
-- The application-answer draft is still stored inside `JobApplication.Notes` rather than a first-class field, so downstream work must keep honoring the marker-block contract.
-- Automated verification proves context wiring and persistence loops, but it does not replace human judgment on whether the generated writing feels genuinely strong enough for a real application; that still needs live UAT with real imported correspondence and AI output.
-- Draft quality still depends on the quality of the imported correspondence, recruiter metadata, profile CV structure, and selected attachments available on the job.
-
-## Follow-ups
-
-- S03 should consume the saved package workspace artifacts, including the marker-delimited application-answer block, instead of reconstructing package context from scratch.
-- A later milestone can promote the application-answer draft to a dedicated persisted field if the notes-block workaround starts constraining editing, analytics, or downstream composition.
-- Milestone-level live UAT should include at least one job with strong imported Gmail context to judge whether the upgraded generator actually feels specific enough to start from.
-
-## Files Created/Modified
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — strengthened package-context assembly, notes replacement behavior, and generation/save contracts
-- `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs` — focused backend proof for correspondence-aware package output and notes replacement
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — converted the Tailored CV tab into a coherent generate/edit/save/reset package workspace
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — verified saved-state load, generation, editing, coherent save payload, and redisplay behavior
-- `.gsd/REQUIREMENTS.md` — refreshed R003 validation to reflect the direct filtered backend test plus frontend workspace proof
-- `.gsd/KNOWLEDGE.md` — recorded the marker-delimited application-answer persistence contract and the authoritative direct S02 test command
-
-## Forward Intelligence
-
-### What the next slice should know
-- S03 can now assume package context lives in durable job fields: `tailoredCvText`, `coverLetterText`, `recruiterMessageDraft`, and the marker-delimited application-answer block inside `notes`; use those saved values as the baseline context for reply/follow-up generation.
-
-### What's fragile
-- Application-answer persistence via the `<<<APPLICATION_ANSWER_DRAFT>>> ... <<<END_APPLICATION_ANSWER_DRAFT>>>` notes block — downstream code must replace/parse that block consistently or the workspace will drift back into duplicate or stale-answer behavior.
-
-### Authoritative diagnostics
-- `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs` and `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — these are the tightest trustworthy checks for whether package generation is context-aware and whether the workspace save/reload loop still works end to end.
-
-### What assumptions changed
-- Earlier task execution assumed the filtered backend verification might still need an isolated harness because of broader test-project drift — in this worktree, `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests` now passes directly and should be treated as the primary S02 regression check.

.gsd/milestones/M001/slices/S02/S02-UAT.md

@@ -1,91 +0,0 @@
-# S02: Stronger AI application package drafting — UAT
-
-**Milestone:** M001
-**Written:** 2026-03-24
-
-## UAT Type
-
-- UAT mode: mixed
-- Why this mode is sufficient: this slice needs both artifact proof (generation/save contracts and persisted reload behavior) and human judgment that the drafts actually feel specific enough to start from.
-
-## Preconditions
-
-- The app frontend and API are running against this worktree.
-- The tester can sign in as a user with a parsed profile CV already available.
-- At least one job exists with:
-  - company + recruiter information
-  - imported Gmail correspondence from S01 linked to the job
-  - optional but preferred AI-selected attachments for extra context
-- The local AI summarizer/service used by `generate-application-package` is configured and reachable.
-- The tester knows which job has the strongest imported recruiter/thread context so draft specificity is easy to judge.
-
-## Smoke Test
-
-Open a job with imported correspondence, switch to the Tailored CV tab, click **Generate package**, and confirm all four editable artifacts populate without errors: tailored CV, cover letter, recruiter message, and application answer.
-
-## Test Cases
-
-### 1. Generate a package that reflects imported job and correspondence context
-
-1. Open a job that already has imported Gmail correspondence in the job workspace.
-2. In the Tailored CV tab, confirm at least one attachment is selected for AI context if relevant.
-3. Click **Generate package**.
-4. Wait for generation to finish.
-5. Review the tailored CV, cover letter, recruiter message, and application answer together.
-6. **Expected:** the generated package mentions concrete job/company/recruiter details and reflects correspondence-specific context or tone rather than reading like a generic template.
-
-### 2. Save edited package material as durable job workspace output
-
-1. Starting from a generated package, edit all or some of these fields: tailored CV, cover letter, recruiter message, application answer.
-2. Confirm the status chips change to show **Unsaved edits** for the edited artifacts.
-3. Click **Save** for the package workspace.
-4. Wait for the save to complete.
-5. **Expected:** save succeeds without duplication, the edited values remain visible, and the status chips move to **Saved to job**.
-
-### 3. Reopen the job and verify the last saved package reloads
-
-1. Close the job details dialog after saving.
-2. Reopen the same job.
-3. Return to the Tailored CV tab.
-4. **Expected:** the saved tailored CV, cover letter, recruiter message, and application answer reload as the current workspace state; nothing falls back to blank or a previous generated-only draft.
-
-### 4. Regenerate after saving and use reset-to-saved safely
-
-1. With a saved package already present, click **Generate package** again.
-2. Confirm the editors are replaced with the new generated working copy.
-3. Make one more manual edit so the status changes to **Unsaved edits**.
-4. Click **Reset to saved**.
-5. **Expected:** the unsaved regeneration/edit is discarded and the workspace returns exactly to the last saved job-tied material.
-
-## Edge Cases
-
-### Saved application answer does not duplicate on repeated saves
-
-1. Save a package with a distinct application-answer draft.
-2. Edit only the application answer and save again.
-3. Close and reopen the job.
-4. **Expected:** only the latest application-answer draft is present; earlier answers are replaced, not appended repeatedly into the notes-backed storage.
-
-### Empty saved package still distinguishes generated-only state
-
-1. Open a job with no previously saved package material.
-2. Generate the package but do not click Save.
-3. **Expected:** generated text appears, but the relevant status chips show **Generated only** rather than **Saved to job**.
-
-## Failure Signals
-
-- Generate package returns an error or leaves one or more of the four artifacts empty despite available context.
-- Drafts ignore obvious recruiter/company/correspondence details and read like generic boilerplate.
-- Saving succeeds visually but reopening the job loses edits or restores stale values.
-- The application answer repeats previous saved copies instead of replacing the prior draft.
-- Status chips do not match reality, for example showing **Saved to job** before any save or failing to show **Unsaved edits** after changes.
-
-## Not Proven By This UAT
-
-- This UAT does not prove Gmail import or linked-thread refresh; that belongs to S01.
-- This UAT does not prove reply/follow-up draft generation from saved package context; that belongs to S03.
-- This UAT does not prove final end-to-end milestone quality across dashboard/table/job-loop navigation; later slices and final milestone UAT must cover that.
-
-## Notes for Tester
-
-Use the job with the richest imported recruiter/thread context first; this slice is about whether that context materially improves draft usefulness. If draft quality feels only marginally better, note which missing signals (recruiter identity, thread details, attachment evidence, profile CV structure) seem absent so S03/S05 can inspect the package-context assembly path.

.gsd/milestones/M001/slices/S02/tasks/T01-PLAN.md

@@ -1,51 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 2
-skills_used:
-  - best-practices
-  - test
----
-
-# T01: Strengthen application-package context assembly and backend draft tests
-
-**Slice:** S02 — Stronger AI application package drafting
-**Milestone:** M001
-
-## Description
-
-Make the backend application-package generator use the context S01 now provides. The executor should keep the existing package endpoint, but improve how it builds prompts and selects context so the tailored CV, cover letter, recruiter message, and supporting signals reflect imported correspondence, recruiter/job details, profile CV structure, and attachment context more convincingly.
-
-## Steps
-
-1. Inspect `JobTrackerApi/Controllers/JobApplicationsController.cs` around `generate-application-package` and identify which job, recruiter, correspondence, attachment, and profile-CV signals are already available but underused.
-2. Refine the package-context assembly and prompt shape so imported correspondence and recruiter/job-specific details influence the generated drafts directly without weakening the no-auto-send boundary.
-3. Add a focused backend test file `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs` that exercises the package endpoint contract with real job/correspondence/profile context and asserts the returned artifacts are specific to that context.
-4. Keep the output contract stable unless a change materially improves the workspace; if it changes, make the added fields explicit and limited to what T02 will consume.
-
-## Must-Haves
-
-- [ ] Imported correspondence from S01 is deliberately consumed in package generation instead of remaining disconnected from the draft flow.
-- [ ] Backend tests prove package output responds to job-specific context rather than generic fallback behavior.
-- [ ] The generator still returns review-only draft material and does not cross the manual-send boundary.
-
-## Verification
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests`
-- Confirm the focused test covers correspondence-aware package context and expected package artifacts.
-
-## Observability Impact
-
-- Signals added/changed: clearer package-response artifacts and stronger context assembly around job/correspondence/profile inputs.
-- How a future agent inspects this: read `JobTrackerApi/Controllers/JobApplicationsController.cs` and `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs`.
-- Failure state exposed: focused backend verification should show whether weak drafts come from missing context assembly, empty correspondence state, or prompt/output contract drift.
-
-## Inputs
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — current application-package and related AI draft endpoints.
-- `Models/Correspondence.cs` — persisted Gmail-linked correspondence metadata from S01.
-- `JobTrackerApi/Controllers/ProfileCvController.cs` — profile CV structure/source-of-truth behavior.
-
-## Expected Output
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — stronger package-generation context and/or response contract.
-- `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs` — focused backend proof for context-aware package generation.

.gsd/milestones/M001/slices/S02/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S02
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T01: Strengthen application-package context assembly and backend draft tests
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S02/tasks/T02-PLAN.md

@@ -1,53 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 3
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T02: Make the job workspace save and present the application package as real working material
-
-**Slice:** S02 — Stronger AI application package drafting
-**Milestone:** M001
-
-## Description
-
-Turn the Tailored CV/application package area into a coherent working loop. The workspace should make it obvious what was generated, what was edited, what was saved to the job, and what can be reused later, instead of feeling like a temporary AI preview pane.
-
-## Steps
-
-1. Update `job-tracker-ui/src/types.ts` if T01 changes the package contract or exposes stronger saved draft/package state.
-2. Refine `job-tracker-ui/src/components/JobDetailsDialog.tsx` so generation, editing, saving, and redisplay of application package material feel like one continuous workflow tied to the job.
-3. Expand `job-tracker-ui/src/job-details-generated-drafts.test.tsx` to prove the stronger package flow: generate with contextual outputs, edit/save the important draft artifacts, and verify the saved material is reflected back in the dialog state.
-4. Keep the UI focused on working material already tied to the job; do not introduce a second competing draft surface or outbound automation.
-
-## Must-Haves
-
-- [ ] The Tailored CV tab clearly presents generated package artifacts as editable, savable job material rather than disposable previews.
-- [ ] Saved package edits update dialog state in a way the user can trust and later slices can reuse.
-- [ ] The focused React test proves generation and save behavior for the package loop.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx`
-- Confirm the expanded test proves generation, editing, and save-state behavior in the dialog.
-
-## Observability Impact
-
-- Signals added/changed: clearer UI state around generated vs saved package material and stronger test coverage for package-loop regressions.
-- How a future agent inspects this: open the Tailored CV tab in `job-tracker-ui/src/components/JobDetailsDialog.tsx` and read `job-tracker-ui/src/job-details-generated-drafts.test.tsx`.
-- Failure state exposed: the workspace and test should distinguish generation failure, unsaved edits, and saved package state instead of collapsing them into generic draft text.
-
-## Inputs
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — existing package-generation and save UI.
-- `job-tracker-ui/src/types.ts` — frontend package contracts.
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — T01 package-generation contract.
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — current focused dialog test.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — stronger package generation/edit/save flow.
-- `job-tracker-ui/src/types.ts` — aligned package contract for the workspace.
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — focused frontend proof for the improved package loop.

.gsd/milestones/M001/slices/S02/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S02
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T02: Make the job workspace save and present the application package as real working material
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S03/S03-PLAN.md

@@ -1,12 +0,0 @@
-# S03: Reply and follow-up drafting from real thread context
-
-**Goal:** Make follow-up drafting use imported correspondence and saved application material well enough that the job workspace can produce specific, trustworthy follow-up and reply drafts without crossing the manual-send boundary.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Strengthen follow-up draft context assembly and backend reply/follow-up tests** — 
-  - Files: JobTrackerApi/Controllers/JobApplicationsController.cs, JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs
-  - Verify: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests`
-- [x] **T02: Make the follow-up workspace show thread-grounded draft state without autonomous sending** — 
-  - Files: job-tracker-ui/src/components/JobDetailsDialog.tsx, job-tracker-ui/src/types.ts, job-tracker-ui/src/job-details-followup-drafts.test.tsx
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-followup-drafts.test.tsx`

.gsd/milestones/M001/slices/S03/S03-SUMMARY.md

@@ -1,107 +0,0 @@
----
-id: S03
-parent: M001
-milestone: M001
-provides:
-  - Context-grounded follow-up drafting that combines imported correspondence, saved application package material, and explicit manual send/log behavior inside the job workspace.
-requires:
-  - slice: S01
-    provides: Imported correspondence records, linked Gmail thread metadata, and ongoing thread refresh continuity tied to a job.
-  - slice: S02
-    provides: Saved tailored CV, cover letter, recruiter message, and marker-delimited application-answer draft state reused by follow-up drafting.
-affects:
-  - S04
-key_files:
-  - JobTrackerApi/Controllers/JobApplicationsController.cs
-  - JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs
-  - JobTrackerApi.Tests/JobTrackerApi.Tests.csproj
-  - job-tracker-ui/src/components/JobDetailsDialog.tsx
-  - job-tracker-ui/src/types.ts
-  - job-tracker-ui/src/job-details-followup-drafts.test.tsx
-key_decisions:
-  - Expose follow-up grounding (`contextSummary`, `contextSignals`, thread subject, and last-correspondence metadata) directly from the backend DTO so the workspace explains why the draft exists instead of inferring context client-side.
-  - Preserve the manual-send boundary by keeping follow-up generation separate from explicit send/log submission.
-patterns_established:
-  - Assemble thread/package grounding once in the backend and return it as part of the draft contract, then render the same grounding verbatim in the workspace.
-  - Reuse the S02 notes marker block for saved application-answer context instead of inventing a second persistence path for follow-up drafting.
-observability_surfaces:
-  - GET /api/jobapplications/{id}/followup-draft
-  - POST /api/jobapplications/{id}/send-followup
-  - GET /api/correspondence/{jobId}
-  - JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs
-  - job-tracker-ui/src/job-details-followup-drafts.test.tsx
-drill_down_paths:
-  - .gsd/milestones/M001/slices/S03/tasks/T01-SUMMARY.md
-  - .gsd/milestones/M001/slices/S03/tasks/T02-SUMMARY.md
-duration: 2-task slice; planned 8h implementation plus closeout verification
-verification_result: passed
-completed_at: 2026-03-24
----
-
-# S03: Reply and follow-up drafting from real thread context
-
-**Follow-up drafting now reuses imported thread history plus saved package material, shows that grounding in the job workspace, and keeps outbound email behind an explicit manual send/log action.**
-
-## What Happened
-
-S03 closed the gap between the correspondence workspace built in S01 and the saved application package workspace built in S02. Before this slice, follow-up generation mostly behaved like a generic prompt over job summary text. After this slice, `JobApplicationsController` assembles follow-up context from the latest imported correspondence, recruiter details, saved tailored CV / cover letter / recruiter message material, and the marker-delimited application-answer draft saved in notes. The API now returns not only a draft subject/body, but also the grounding metadata the UI needs to explain why the draft was generated and what informed it.
-
-On the frontend, `JobDetailsDialog.tsx` now treats follow-up drafting as part of the same per-job working loop rather than a blind compose form. The Follow-up tab shows thread subject, latest sender, context summary, and context signals; keeps the body editable before send; and makes the manual-send boundary explicit in the helper text and button flow. The UI posts the edited draft through the existing send/log endpoint instead of silently dispatching anything.
-
-During closeout, the slice-level backend verification command in the plan was restored as a first-class path by repairing missing framework/package references in `JobTrackerApi.Tests/JobTrackerApi.Tests.csproj`. That means future agents can use the filtered `dotnet test ... --filter JobApplicationsFollowUpDraftTests` command directly in this worktree instead of relying on the older isolated harness workaround recorded during task execution.
-
-Net effect: imported correspondence, saved package drafts, and the follow-up compose/send-log loop now form one coherent job-level workspace path. S04 can build overview and urgency surfaces on top of a follow-up flow that is already grounded and manually controlled.
-
-## Verification
-
-- Passed: `$HOME/.dotnet/dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests`
-- Passed: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-followup-drafts.test.tsx`
-- Passed: `$HOME/.dotnet/dotnet build JobTrackerApi/JobTrackerApi.csproj`
-- Passed: `CI=true npm --prefix job-tracker-ui run build`
-- Observability surfaces confirmed through code/test contracts:
-  - `GET /api/jobapplications/{id}/followup-draft` now exposes grounding metadata (`contextSummary`, `contextSignals`, thread subject, last-correspondence details)
-  - `POST /api/jobapplications/{id}/send-followup` remains the explicit manual send/log boundary
-  - `GET /api/correspondence/{jobId}` remains the authoritative timeline surface for confirming logged outbound follow-up entries
-
-## New Requirements Surfaced
-
-- none
-
-## Deviations
-
-The written plan expected the filtered backend command to be the slice-level proof path, but task execution had fallen back to an isolated harness because `JobTrackerApi.Tests.csproj` was missing required ASP.NET Core / Identity / xUnit references. Closeout repaired the test project so the plan-level verification command now passes directly in this worktree.
-
-## Known Limitations
-
-- The slice materially strengthened follow-up drafting, but it still does not introduce a separate rich reply-specific workflow beyond thread-aware subject/context reuse; deeper reply-mode specialization can still be expanded later if usage demands it.
-- This closeout did not re-run a full live Gmail + browser UAT loop end to end; the trusted evidence for S03 in this worktree is the focused backend/frontend verification plus the production frontend build.
-- Follow-up quality still depends on upstream data quality from S01 and S02: weak imported thread metadata or missing saved package material will reduce how specific the draft can be.
-
-## Follow-ups
-
-- S04 should consume the new follow-up grounding/status signals to show which jobs are ready for follow-up, missing context, or need attention from overview surfaces.
-- S05 should re-run the full live loop with real Gmail continuity plus follow-up drafting to reconfirm milestone trust end to end.
-
-## Files Created/Modified
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — assembled correspondence-aware follow-up context, exposed draft grounding metadata, and improved fallback/reply-style subject behavior.
-- `JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs` — added focused backend proof that imported thread state plus saved package material change the follow-up draft.
-- `JobTrackerApi.Tests/JobTrackerApi.Tests.csproj` — restored missing framework/package references so filtered backend verification commands run directly again.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — exposed follow-up grounding in the workspace, kept drafts editable, and clarified the manual-send boundary.
-- `job-tracker-ui/src/types.ts` — added the richer `FollowUpDraft` contract used by the workspace.
-- `job-tracker-ui/src/job-details-followup-drafts.test.tsx` — proved the Follow-up tab renders context grounding and only sends/logs after explicit user action.
-
-## Forward Intelligence
-
-### What the next slice should know
-- S03 made the follow-up flow depend on three upstream context sources at once: imported correspondence, saved package fields, and the marker-delimited application-answer draft in `JobApplication.Notes`. If S04 wants actionable table/dashboard indicators, it should reuse the backend grounding signals instead of trying to infer readiness from scattered raw fields in the browser.
-
-### What's fragile
-- `JobApplication.Notes` marker parsing for `<<<APPLICATION_ANSWER_DRAFT>>> ... <<<END_APPLICATION_ANSWER_DRAFT>>>` — if another slice starts appending free-form notes around that block incorrectly, follow-up context quality will silently degrade because saved application-answer reuse depends on parsing that exact marker format.
-
-### Authoritative diagnostics
-- `GET /api/jobapplications/{id}/followup-draft` and `JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs` — the endpoint payload is the single source of truth for what grounding the backend believes it has, and the focused backend test is the fastest trustworthy check when prompt assembly or DTO shape changes.
-- `job-tracker-ui/src/job-details-followup-drafts.test.tsx` — this is the most reliable UI-level diagnostic for the manual-send boundary and edited-draft payload because it asserts the exact send/log request body after user edits.
-
-### What assumptions changed
-- “The slice may need an isolated backend harness because the filtered test command is not trustworthy.” — no longer true in this worktree; closeout repaired `JobTrackerApi.Tests.csproj`, so the plan-level filtered backend command now passes directly and should replace the older workaround.

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

@@ -1,92 +0,0 @@
-# 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`

.gsd/milestones/M001/slices/S03/tasks/T01-PLAN.md

@@ -1,50 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 2
-skills_used:
-  - test
----
-
-# T01: Strengthen follow-up draft context assembly and backend reply/follow-up tests
-
-**Slice:** S03 — Reply and follow-up drafting from real thread context
-**Milestone:** M001
-
-## Description
-
-Make the follow-up draft endpoint use imported correspondence, recruiter details, and saved application package material so the draft reflects the real thread stage and saved job context instead of a generic reminder template.
-
-## Steps
-
-1. Audit `GetFollowUpDraft` and nearby helpers in `JobApplicationsController` to identify which imported thread/package signals are currently ignored.
-2. Add or refactor backend context assembly so follow-up drafting consumes recent correspondence, saved package material, recruiter details, and stage-specific cues without crossing the manual-send boundary.
-3. Add focused backend tests proving the follow-up draft output changes in response to thread/package context and still preserves explicit manual-send behavior.
-4. Verify the focused backend behavior with an isolated test path if the broader test project remains blocked by unrelated compile drift.
-
-## Must-Haves
-
-- [ ] Follow-up draft context includes imported correspondence and saved application package material deliberately.
-- [ ] The generated follow-up draft reflects thread stage/recruiter context instead of generic job-only phrasing.
-- [ ] Focused backend tests prove the stronger draft grounding.
-
-## Verification
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests`
-- Focused isolated harness if needed: run only `JobApplicationsFollowUpDraftTests` against `JobTrackerApi/Controllers/JobApplicationsController.cs`
-
-## Observability Impact
-
-- Signals added/changed: richer follow-up draft reason/context surface and clearer thread-aware draft behavior.
-- How a future agent inspects this: `GET /api/jobapplications/{id}/followup-draft` plus `JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs`.
-- Failure state exposed: missing thread/package context should show up as weaker fallback behavior in focused backend tests rather than silent generic output.
-
-## Inputs
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — existing follow-up draft and send/log endpoints.
-- `Models/Correspondence.cs` — imported thread/sender/recipient fields from S01.
-- `JobTrackerApi.Tests/JobApplicationsApplicationPackageTests.cs` — current focused test seam style for isolated job-application behavior.
-
-## Expected Output
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — stronger follow-up draft context assembly.
-- `JobTrackerApi.Tests/JobApplicationsFollowUpDraftTests.cs` — focused backend proof for thread-aware follow-up drafting.

.gsd/milestones/M001/slices/S03/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S03
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T01: Strengthen follow-up draft context assembly and backend reply/follow-up tests
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S03/tasks/T02-PLAN.md

@@ -1,52 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 3
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T02: Make the follow-up workspace show thread-grounded draft state without autonomous sending
-
-**Slice:** S03 — Reply and follow-up drafting from real thread context
-**Milestone:** M001
-
-## Description
-
-Turn the Follow-up tab into a clearer workspace that shows why the draft was generated now, what thread/package context informed it, and what will happen when the user manually sends/logs it.
-
-## Steps
-
-1. Align frontend types with any stronger follow-up draft contract exposed by T01.
-2. Refine the Follow-up tab in `JobDetailsDialog.tsx` so it surfaces thread/package grounding, editable draft state, and the manual-send boundary clearly.
-3. Add a focused React test that proves generation, editability, and manual send/log behavior for the follow-up loop.
-4. Verify the focused follow-up workspace test and make sure it covers the saved-context/thread-aware behavior instead of generic form rendering.
-
-## Must-Haves
-
-- [ ] The Follow-up tab shows why the follow-up is due and what job/thread/package context informed the draft.
-- [ ] The draft remains editable before sending and the send action stays explicitly manual.
-- [ ] The focused React test proves generate/edit/send-log behavior for the follow-up loop.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-followup-drafts.test.tsx`
-- Confirm the test proves thread-aware draft context plus manual send/log behavior in `job-tracker-ui/src/components/JobDetailsDialog.tsx`.
-
-## Observability Impact
-
-- Signals added/changed: clearer Follow-up tab state around draft reason, informing context, and sent/logged outcome.
-- How a future agent inspects this: open the Follow-up tab in `job-tracker-ui/src/components/JobDetailsDialog.tsx` and read `job-tracker-ui/src/job-details-followup-drafts.test.tsx`.
-- Failure state exposed: the UI should distinguish draft-generation failure, editable draft state, and sent/logged follow-up state.
-
-## Inputs
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — current follow-up UI.
-- `job-tracker-ui/src/types.ts` — current frontend contracts.
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — stronger follow-up draft contract from T01.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — follow-up workspace grounded in saved/job/thread context.
-- `job-tracker-ui/src/types.ts` — aligned follow-up DTO shape if T01 adds context fields.
-- `job-tracker-ui/src/job-details-followup-drafts.test.tsx` — focused frontend proof for the follow-up loop.

.gsd/milestones/M001/slices/S03/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S03
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.777Z
-blocker_discovered: false
----
-
-# T02: Make the follow-up workspace show thread-grounded draft state without autonomous sending
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S04/S04-PLAN.md

@@ -1,12 +0,0 @@
-# S04: Daily control loop surfaces
-
-**Goal:** Make the job table, reminders view, and dashboard behave like one daily control loop so the user can scan what needs attention and jump directly into the right job workspace state.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Turn reminders and dashboard into actionable entry surfaces** — 
-  - Files: job-tracker-ui/src/components/DashboardView.tsx, job-tracker-ui/src/components/RemindersView.tsx, job-tracker-ui/src/App.tsx
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx`
-- [x] **T02: Make the job table expose the right next action and prove the daily loop** — 
-  - Files: job-tracker-ui/src/components/JobTable.tsx, job-tracker-ui/src/daily-control-loop.test.tsx
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx`

.gsd/milestones/M001/slices/S04/S04-SUMMARY.md

@@ -1,27 +0,0 @@
----
-title: S04 summary
-status: done
-verification:
-  - CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx
-  - CI=true npm --prefix job-tracker-ui run build
-  - Browser UAT on built branch UI via localhost:3001 against localhost:5202
----
-
-S04 turned the table, dashboard, and reminders into a coherent daily control loop.
-
-Delivered:
-- routed workspace entry helper in `job-tracker-ui/src/jobWorkspaceRoute.ts`
-- actionable dashboard attention section in `job-tracker-ui/src/components/DashboardView.tsx`
-- reminders flow routed into the existing `/jobs` workspace in `job-tracker-ui/src/components/RemindersView.tsx`
-- clickable urgency chips in `job-tracker-ui/src/components/JobTable.tsx` that jump straight into follow-up or tailored-CV work
-- focused UI proof in `job-tracker-ui/src/daily-control-loop.test.tsx`
-
-Browser verification:
-- verified dashboard `Follow up` action opened the real job workspace on the Follow-up tab in the built branch UI
-- verified reminders `Open` routed back into the same job workspace flow
-- verified S03 follow-up flow remained intact when entered from the daily overview surfaces
-
-Net effect:
-- the job table is now a clearer first-stop overview
-- reminders and dashboard no longer strand the user in secondary surfaces
-- overview surfaces now route into one workspace model instead of competing loops

.gsd/milestones/M001/slices/S04/S04-UAT.md

@@ -1,27 +0,0 @@
-# S04: Recovery placeholder UAT
-
-**Milestone:** M001
-**Written:** 2026-03-24T12:56:42.784Z
-
-## Preconditions
-- Doctor created this placeholder because the expected UAT file was missing.
-
-## Smoke Test
-- Re-run the slice verification from the slice plan before shipping.
-
-## Test Cases
-### 1. Replace this placeholder
-1. Read the slice plan and task summaries.
-2. Write a real UAT script.
-3. **Expected:** This placeholder is replaced with meaningful human checks.
-
-## Edge Cases
-### Missing completion artifacts
-1. Confirm the summary, roadmap checkbox, and state file are coherent.
-2. **Expected:** GSD doctor reports no remaining completion drift for this slice.
-
-## Failure Signals
-- Placeholder content still present when treating the slice as done
-
-## Notes for Tester
-Doctor created this file only to restore the required artifact shape. Replace it with a real UAT script.

.gsd/milestones/M001/slices/S04/tasks/T01-PLAN.md

@@ -1,46 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 3
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T01: Turn reminders and dashboard into actionable entry surfaces
-
-**Slice:** S04 — Daily control loop surfaces
-**Milestone:** M001
-
-## Description
-
-Make the dashboard and reminders page show high-priority jobs as direct entry points into the existing job workspace state instead of acting like passive summaries or separate modal loops.
-
-## Steps
-
-1. Audit the current dashboard and reminders surfaces to identify where reminder/readiness information is already available but not actionable.
-2. Add direct job-open actions that route into `/jobs` with the correct workspace tab and optional follow-up mode.
-3. Replace reminder-modal detours with routed job-workspace entry where it improves flow coherence.
-4. Cover the new routed-entry behavior in a focused UI test.
-
-## Must-Haves
-
-- [ ] Dashboard shows actionable jobs needing attention now.
-- [ ] Reminders routes into the existing job workspace state rather than creating a separate loop.
-- [ ] Focused UI coverage proves routed entry from overview surfaces.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx`
-- `CI=true npm --prefix job-tracker-ui run build`
-
-## Inputs
-
-- `job-tracker-ui/src/components/DashboardView.tsx` — current analytics dashboard.
-- `job-tracker-ui/src/components/RemindersView.tsx` — current reminders page.
-- `job-tracker-ui/src/App.tsx` — route shell and navigation structure.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/DashboardView.tsx` — actionable attention cards or lists.
-- `job-tracker-ui/src/components/RemindersView.tsx` — routed job-workspace entry flow.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — focused proof for overview-to-workspace routing.

.gsd/milestones/M001/slices/S04/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S04
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T01: Turn reminders and dashboard into actionable entry surfaces
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S04/tasks/T02-PLAN.md

@@ -1,50 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 2
-skills_used:
-  - react-best-practices
-  - test
----
-
-# T02: Make the job table expose the right next action and prove the daily loop
-
-**Slice:** S04 — Daily control loop surfaces
-**Milestone:** M001
-
-## Description
-
-Strengthen the job table so the first daily view shows what action is actually due and can jump directly into the right job workspace tab.
-
-## Steps
-
-1. Audit the existing job-table row chips and actions against the reminder/readiness data already available.
-2. Add clearer action affordances for follow-up and package work that route into the same job workspace state used by dashboard/reminders.
-3. Fold the table interactions into the focused daily-loop test.
-4. Verify the routed-table behavior and build output.
-
-## Must-Haves
-
-- [ ] Job-table urgency signals are actionable, not just decorative.
-- [ ] Table actions route into the same workspace state used by reminders/dashboard.
-- [ ] The focused UI test proves the table participates in the same daily loop.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx`
-- `CI=true npm --prefix job-tracker-ui run build`
-
-## Inputs
-
-- `job-tracker-ui/src/components/JobTable.tsx` — current table and row actions.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — focused loop test from T01.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/JobTable.tsx` — clearer next-action affordances.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — proof that the table participates in the routed daily loop.
-
-## Observability Impact
-
-- Signals changed: the table's urgency chips and primary row actions should now expose the same routed follow-up and package-work intents already used by dashboard and reminders.
-- How to inspect later: read `job-tracker-ui/src/components/JobTable.tsx` for the shared workspace-route usage and run `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx` to confirm table, reminders, and dashboard all land in the expected workspace state.
-- Failure state made visible: if table actions drift from the shared routing contract, the focused UI test should fail with the wrong route/tab content instead of silently leaving decorative chips in place.

.gsd/milestones/M001/slices/S04/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S04
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T02: Make the job table expose the right next action and prove the daily loop
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S04/tasks/T02-VERIFY.json

@@ -1,19 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T02",
-  "unitId": "M001/S04/T02",
-  "timestamp": 1774357002857,
-  "passed": false,
-  "discoverySource": "none",
-  "checks": [],
-  "retryAttempt": 1,
-  "maxRetries": 2,
-  "runtimeErrors": [
-    {
-      "source": "bg-shell",
-      "severity": "crash",
-      "message": "[jobtracker-api] exitCode=127",
-      "blocking": true
-    }
-  ]
-}

.gsd/milestones/M001/slices/S05/S05-PLAN.md

@@ -1,12 +0,0 @@
-# S05: End-to-end trust and workflow polish
-
-**Goal:** Prove the full daily-use loop as one trustworthy workflow by tightening shared next-action/readiness signals, then validating overview → workspace → package → Gmail continuity → follow-up behavior without weakening the manual-send boundary.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Centralize workflow trust signals across overview and readiness surfaces** — 
-  - Files: JobTrackerApi/Controllers/JobApplicationsController.cs, JobTrackerApi.Tests/JobApplicationsWorkflowSignalsTests.cs, job-tracker-ui/src/types.ts, job-tracker-ui/src/jobWorkflowSignals.ts, job-tracker-ui/src/components/JobTable.tsx, job-tracker-ui/src/components/DashboardView.tsx, job-tracker-ui/src/components/RemindersView.tsx, job-tracker-ui/src/workflow-trust-signals.test.tsx
-  - Verify: `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsWorkflowSignalsTests` and `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/workflow-trust-signals.test.tsx`
-- [x] **T02: Add integrated trust-loop proof and workspace polish** — 
-  - Files: job-tracker-ui/src/components/JobDetailsDialog.tsx, job-tracker-ui/src/components/Correspondence.tsx, job-tracker-ui/src/end-to-end-trust-loop.test.tsx, job-tracker-ui/src/daily-control-loop.test.tsx, .gsd/milestones/M001/slices/S05/S05-UAT.md
-  - Verify: `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/end-to-end-trust-loop.test.tsx`, `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx src/job-details-generated-drafts.test.tsx src/job-details-followup-drafts.test.tsx src/daily-control-loop.test.tsx`, and `CI=true npm --prefix job-tracker-ui run build`

.gsd/milestones/M001/slices/S05/S05-RESEARCH.md

@@ -1,119 +0,0 @@
-# S05 — Research
-
-**Date:** 2026-03-24
-
-## Summary
-
-S05 is an integration-and-polish slice, not a new subsystem. The codebase already has the main milestone pieces in place: job-table/dashboard routing into one workspace (`job-tracker-ui/src/jobWorkspaceRoute.ts`), Gmail import plus linked-thread refresh (`job-tracker-ui/src/components/Correspondence.tsx`, `JobTrackerApi/Controllers/GmailController.cs`), saved application-package drafting (`job-tracker-ui/src/components/JobDetailsDialog.tsx`, `JobTrackerApi/Controllers/JobApplicationsController.cs`), and grounded follow-up drafting with explicit manual send (`JobDetailsDialog.tsx`, `JobApplicationsController.cs`). What is still missing is one trustworthy proof path and a small amount of glue cleanup so the full loop feels coherent instead of slice-by-slice.
-
-The active requirements this slice most directly supports are **R008** and **R010**. R008 matters because `POST /api/jobapplications/{id}/send-followup` really calls `_email.SendAsync(...)`, so final verification must preserve the explicit-user-action boundary and avoid any accidental live outbound send during UAT. R010 matters because the continuity story is currently spread across several surfaces: reminders/dashboard route by `followUpReason` text, the table uses `tailoredCvText` plus `notes` as a package-readiness proxy, Gmail continuity is one-shot auto-refresh plus manual refresh, and follow-up grounding comes from a separate DTO. S05 should make those surfaces feel like one loop and prove them together.
-
-## Recommendation
-
-Treat S05 as **“integrated regression first, then polish only what the integrated proof exposes.”** Do not invent a new workflow. Reuse the existing shared `/jobs?open=...&tab=...&followMode=...` entry pattern, and keep backend DTOs as the source of truth instead of adding more browser-side heuristics.
-
-Two loaded skills reinforce that approach:
-- **`react-best-practices`**: keep derived UI state in helpers instead of adding more mirrored effect-driven state (`rerender-derived-state-no-effect`, `rerender-dependencies`), and avoid introducing new fetch waterfalls when composing the final loop (`async-parallel`).
-- **`aspnet-core`**: keep the controller/API contract as the authoritative feature seam. If S05 needs clearer trust/readiness signals, add them in `JobApplicationsController` DTOs/endpoints instead of duplicating string parsing rules in multiple React components.
-
-Primary recommendation: add one end-to-end UI regression that spans table/dashboard/reminders → shared workspace → package save → Gmail correspondence continuity → follow-up draft/manual-send boundary, then patch any trust gaps that test exposes. That is the fastest path to milestone-level confidence.
-
-## Implementation Landscape
-
-### Key Files
-
-- `job-tracker-ui/src/jobWorkspaceRoute.ts` — single shared route builder for opening a job workspace on a specific tab/mode. This is the seam S04 already established; S05 should keep using it rather than creating new navigation paths.
-- `job-tracker-ui/src/components/JobTable.tsx` — primary entry surface. Important details:
-  - urgency/action chips route into the shared workspace
-  - `getActionSignals()` is the current place where “what needs attention now” is inferred
-  - `readinessFilter === "needs-work"` currently uses `!job.tailoredCvText || !job.notes`, which is a coarse proxy because `notes` also holds the S02 application-answer marker block and arbitrary notes
-- `job-tracker-ui/src/components/DashboardView.tsx` — reminder/attention overview. It routes into Tailored CV or Follow-up based on `followUpReason` string matching. Useful for integrated proof, but fragile if more action types appear.
-- `job-tracker-ui/src/components/RemindersView.tsx` — same pattern as dashboard: groups items by `followUpReason` text and routes into the shared workspace.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — the real job workspace. It already contains the critical integrated loop pieces:
-  - package generation/save in tab 3
-  - follow-up draft fetch + editable draft + explicit send/log in tab 4
-  - readiness in tab 8
-  - lazy per-tab data loading
-- `job-tracker-ui/src/components/Correspondence.tsx` — Gmail import/continuity surface. Key non-obvious behavior:
-  - auto-refresh of linked threads is one-shot per `jobId + linkedThreadIds` set via `autoRefreshKeyRef`
-  - repeated pulls in the same session require the explicit **Refresh linked threads** action
-  - imported correspondence rows surface Gmail metadata directly in the timeline area
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — current best overview-surface proof. Verifies dashboard/reminders/job-table route into the shared workspace, but stops short of the full import/package/follow-up loop.
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx` — current best Gmail continuity proof. Verifies ranked Gmail import and linked-thread refresh behavior, including the later reply appearing without manual re-import.
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — best proof for package generate/edit/save/reload.
-- `job-tracker-ui/src/job-details-followup-drafts.test.tsx` — best proof for follow-up grounding and the manual-send boundary.
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — backend source of truth for S05 trust signals:
-  - `GET /api/jobapplications/{id}/followup-draft`
-  - `POST /api/jobapplications/{id}/send-followup`
-  - `GET /api/jobapplications/{id}/readiness`
-  - `PUT /api/jobapplications/{id}/application-drafts`
-  - `POST /api/jobapplications/{id}/generate-application-package`
-  - also owns reminders/analytics/readiness logic used by the overview surfaces
-- `JobTrackerApi/Controllers/GmailController.cs` — backend source of truth for Gmail match/import/refresh continuity.
-- `JobTrackerApi/Services/FollowUpReminderHostedService.cs` — sends reminder emails to the app user with a deep link into the follow-up tab. This is not recruiter auto-send, but it matters for live verification because outbound email infrastructure may be active.
-- `job-tracker-ui/src/api.ts` — local UI targets `http://localhost:5202/api` on localhost; browser UAT must run the backend too.
-
-### Build Order
-
-1. **Prove the whole loop in one focused UI regression before polishing.**
-   - Best seam: add a new integrated React test or extend `src/daily-control-loop.test.tsx`.
-   - It should cover: open from an overview surface → land on workspace tab → generate/save package → confirm saved state is reused → open/import/refresh correspondence → generate follow-up with grounding → verify send remains explicit/manual.
-   - This gives the planner one artifact that tells it exactly what still feels fragmented.
-
-2. **Then fix trust/continuity heuristics exposed by that integrated proof.**
-   Likely candidates from current code:
-   - replace/centralize string-matching action routing (`followUpReason.includes('tailored cv')`) if it causes ambiguous or brittle behavior across `DashboardView.tsx` and `RemindersView.tsx`
-   - tighten package-readiness/action inference in `JobTable.tsx` so it reflects saved package state more directly than `!job.notes`
-   - if overview surfaces need richer trust signals, prefer adding explicit API fields in `JobApplicationsController.cs` over duplicating UI inference
-
-3. **Only after the integrated regression passes, do final browser UAT on the real app path.**
-   - Use the existing S04 pattern: browser entry through the real `/jobs` / `/dashboard` surfaces, not component-only proof.
-   - Keep live send safe: do not rely on clicking the final send button unless the environment is configured to a safe sink/stub recipient.
-
-### Verification Approach
-
-Automated regression set already worth keeping:
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter GmailControllerTests`
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsApplicationPackageTests`
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsFollowUpDraftTests`
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx`
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/job-details-generated-drafts.test.tsx`
-- `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 test -- --watch=false --runTestsByPath src/daily-control-loop.test.tsx`
-- add one new S05 integrated UI test and run it directly by path
-- `dotnet build JobTrackerApi/JobTrackerApi.csproj`
-- `CI=true npm --prefix job-tracker-ui run build`
-
-Browser/UAT proof should explicitly confirm:
-- job table/dashboard/reminders all open the same workspace model
-- package work saved in Tailored CV is visible when follow-up drafting runs later
-- Gmail linked-thread refresh updates correspondence without manual re-import of the whole thread
-- follow-up drafting shows grounding from saved package + correspondence context
-- no outbound recruiter email is sent without the explicit send action
-
-## Constraints
-
-- Local browser verification requires **both** frontend and backend. `job-tracker-ui/src/api.ts` hard-codes `http://localhost:5202/api` on localhost.
-- `send-followup` is a real email-sending endpoint; final verification must preserve R008 by avoiding accidental live sends.
-- Gmail thread auto-refresh in `Correspondence.tsx` is intentionally one-shot per linked-thread set. A second refresh in the same session needs the manual button; that is by design, not a bug.
-- The S02 application-answer draft still lives inside `JobApplication.Notes` with the `<<<APPLICATION_ANSWER_DRAFT>>>` marker block; any S05 readiness logic must not treat all notes as generic free text.
-
-## Common Pitfalls
-
-- **Treating `notes` as generic readiness state** — in this milestone, `notes` may contain the persisted application-answer draft block. If S05 wants a better package/trust signal, do not keep leaning on `!job.notes` alone.
-- **Duplicating action inference in multiple components** — `DashboardView.tsx`, `RemindersView.tsx`, and `JobTable.tsx` already infer next actions separately. If S05 needs to change action logic, centralize it in a helper or API contract instead of drifting three copies.
-- **Mistaking manual-send for no-send** — R008 forbids autonomous outbound communication, not explicit user-triggered send. S05 should verify the manual boundary remains explicit, not remove the send capability.
-- **Running browser UAT with only the frontend** — the UI will render but fail to load real data because localhost calls go to `http://localhost:5202/api`.
-
-## Open Risks
-
-- The biggest remaining risk is not missing code, but a fragmented trust story: overview surfaces, package workspace, Gmail continuity, and follow-up grounding may all work individually while still feeling loosely connected. The integrated UI regression should be used to decide whether S05 needs a data-contract tweak or just copy/UX polish.
-- If live email infrastructure is enabled, naive UAT on `send-followup` could send a real message. Prefer a safe sink/stubbed mail setup for final acceptance.
-
-## Skills Discovered
-
-| Technology | Skill | Status |
-|------------|-------|--------|
-| React UI workflow / performance | `react-best-practices` | available |
-| ASP.NET Core controller APIs | `aspnet-core` | available |

.gsd/milestones/M001/slices/S05/S05-SUMMARY.md

@@ -1,118 +0,0 @@
-# S05 Summary — End-to-end trust and workflow polish
-
-## Slice Outcome
-
-S05 completed the final trust-loop assembly for M001. The slice did not add a second workflow; it tightened the existing one so `/jobs`, `/dashboard`, `/reminders`, and the job workspace now describe the same next action, reuse the same saved package state, expose Gmail linked-thread continuity clearly, and keep follow-up drafting separate from any outbound send action.
-
-In practice, this slice turned the milestone from a set of individually working subsystems into one coherent daily-use loop:
-
-- overview surfaces route into the same workspace semantics
-- saved package material is treated as explicit reusable workflow state
-- linked Gmail thread refresh is visible in the workspace instead of hidden behind import-only UI
-- grounded follow-up drafting remains available without crossing the manual-send boundary
-
-## What This Slice Actually Delivered
-
-### 1. Shared workflow trust/action model
-
-S05 centralized workflow trust signals across backend DTOs and frontend routing helpers so overview surfaces no longer guess from free-form `followUpReason` text or raw `notes` presence.
-
-Delivered pattern:
-
-- backend reminders/readiness return normalized `workflowSignal` metadata
-- frontend consumes that contract through `job-tracker-ui/src/jobWorkflowSignals.ts`
-- `JobTable`, `DashboardView`, and `RemindersView` route from the same source of truth into the existing `/jobs?open=...&tab=...` workspace entry model
-
-This is the main coherence pattern future slices should preserve: if a new daily-loop surface needs a next action, it should consume `workflowSignal`, not invent another heuristic.
-
-### 2. Explicit saved-package trust in the workspace
-
-The Tailored CV workspace now makes the saved-package chain obvious:
-
-- tailored CV, cover letter, application answer, and recruiter message each show save state
-- the UI explicitly says saved package material feeds follow-up drafting
-- the saved working-material panel shows what later workflow steps can trust and reuse
-
-This matters because S02 already established package persistence, but S05 made that persistence legible as workflow state rather than hidden implementation detail.
-
-### 3. Visible Gmail continuity state in the correspondence workspace
-
-S05 surfaced linked-thread continuity directly in `Correspondence.tsx`.
-
-The workspace now shows:
-
-- Gmail connection state
-- linked-thread count
-- explicit linked-thread refresh action
-- last refresh outcome
-
-That makes the S01 continuity work inspectable in the same workspace where the user reviews correspondence, rather than requiring them to infer freshness from the Gmail import modal alone.
-
-### 4. Integrated trust-loop regression
-
-S05 added `job-tracker-ui/src/end-to-end-trust-loop.test.tsx` as the integrated proof for the slice. The test starts from an overview entry point and verifies the assembled path in one place:
-
-1. open the job from an overview action
-2. confirm saved package material is already present
-3. confirm linked-thread refresh updates correspondence without re-importing the thread
-4. confirm the follow-up draft is grounded in saved package + correspondence context
-5. confirm drafting/regeneration does not trigger send behavior
-
-This is now the best single regression to read when future work risks breaking the milestone’s core loop.
-
-## Patterns Established
-
-- **Workflow actions come from normalized workflow signals.** Do not parse `followUpReason` strings or generic `notes` content in overview surfaces.
-- **Saved package state is explicit workflow state.** Future slices should continue treating tailored CV / cover letter / application answer / recruiter message as reusable job-scoped material.
-- **Continuity status belongs in the main workspace.** If refresh or sync trust matters, expose its state where the user does the work.
-- **Integrated proof should start from an overview surface.** Final-loop regressions should validate real entry routing, not isolated component state only.
-- **Manual-send boundary must stay explicit.** Draft generation/regeneration and outbound send must remain visibly separate.
-
-## Verification Run
-
-All slice-plan command checks passed in this worktree.
-
-### Backend
-
-- `~/.gsd/agent/bin/dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsWorkflowSignalsTests`
-
-### Frontend tests
-
-- `cd job-tracker-ui && CI=true ./node_modules/.bin/react-scripts test --watch=false --runTestsByPath src/workflow-trust-signals.test.tsx`
-- `cd job-tracker-ui && CI=true ./node_modules/.bin/react-scripts test --watch=false --runTestsByPath src/end-to-end-trust-loop.test.tsx`
-- `cd job-tracker-ui && CI=true ./node_modules/.bin/react-scripts test --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx src/job-details-generated-drafts.test.tsx src/job-details-followup-drafts.test.tsx src/daily-control-loop.test.tsx`
-
-### Build
-
-- `cd job-tracker-ui && CI=true ./node_modules/.bin/react-scripts build`
-
-## Observability / Diagnostic Surfaces Confirmed
-
-The slice-plan observability surfaces are in place and useful:
-
-- `GET /api/jobapplications/reminders`
-- `GET /api/jobapplications/{id}/readiness`
-- `GET /api/jobapplications/{id}/followup-draft`
-- `GET /api/correspondence/{jobId}`
-- `POST /api/gmail/refresh-linked-threads`
-- `job-tracker-ui/src/jobWorkflowSignals.ts`
-- `job-tracker-ui/src/workflow-trust-signals.test.tsx`
-- `job-tracker-ui/src/end-to-end-trust-loop.test.tsx`
-
-Backend tests proved normalized workflow-signal behavior. Frontend tests proved overview routing consistency and integrated trust-loop behavior. A live browser check also confirmed the app shell renders, but the current environment still has a CORS/runtime mismatch on `http://localhost:5202/api/...`, so full live UAT depends on running the backend with the expected CORS behavior.
-
-## Requirement Impact
-
-- **R010** is now validated. S05 proved coherent history and action continuity across overview routing, saved package reuse, linked Gmail updates, and follow-up drafting using one shared workflow contract.
-- **R008** remains active by design. S05 re-proved the manual-send boundary, but the requirement stays active as an ongoing product constraint rather than a one-time feature box.
-
-## Decisions / Gotchas Worth Carrying Forward
-
-- Saved application answers should remain explicit workflow state, not inferred from generic notes.
-- Linked-thread refresh state should stay visible in the main correspondence workspace.
-- In this CRA frontend, run `react-scripts` from `job-tracker-ui/`; invoking via `npm --prefix ...` from repo root can mis-resolve the app directory and fail looking for a root-level `package.json`.
-- Browser UAT still requires a correctly configured backend on port `5202`; otherwise the UI shell loads with CORS failures and empty data surfaces.
-
-## What The Next Slice / Milestone Should Know
-
-M001 is now assembled as one coherent single-user loop. Future work should build on the shared `workflowSignal` contract and the integrated trust-loop regression instead of adding new routing heuristics or duplicate readiness logic. If a later slice changes reminders, workspace entry, Gmail continuity, or follow-up drafting, it should update both the focused workflow-signal tests and the integrated trust-loop test together.

.gsd/milestones/M001/slices/S05/S05-UAT.md

@@ -1,246 +0,0 @@
-# S05 UAT — End-to-end trust and workflow polish
-
-## Goal
-
-Verify that one real job can be entered from `/jobs`, `/dashboard`, and `/reminders`, then carried through the same trusted workspace loop:
-
-- saved package material is visible and reusable
-- linked Gmail threads stay current without thread re-import
-- follow-up drafting is grounded in saved package + correspondence
-- no recruiter email is sent unless the human explicitly chooses the send action in a safe environment
-
-## Safety Guardrails
-
-1. **Do not click `Send and log email`** unless outbound mail is intentionally routed to a safe sink, stub mailbox, or other non-production target.
-2. If safe outbound handling is not confirmed, stop after reviewing the follow-up draft and the manual-send boundary copy.
-3. Do not capture or share screenshots containing sensitive recruiter or correspondence content.
-4. Use one job that already has all or most of the following:
-   - a saved tailored CV and/or other saved package material
-   - at least one imported Gmail thread linked to the job
-   - a workflow action from the overview surfaces
-   - follow-up context that should produce a draft
-
-## Preconditions
-
-- API is running on the expected backend origin with working CORS for the frontend.
-- UI is running and can load real API-backed job data.
-- Gmail integration is authenticated for the current user.
-- The selected job belongs to the current user and has real recruiter/thread context.
-- If the final send step will be tested, outbound mail is pointed at a safe sink/stub.
-
-## Shared Expected Signals For The Same Job
-
-Across `/jobs`, `/dashboard`, and `/reminders`, the same job should:
-
-- show the same general next action
-- open the same job workspace
-- land on the same tab or equivalent workflow destination
-- preserve the same saved package, correspondence, and follow-up state
-
-Inside the job workspace, expect to see:
-
-- package save-state chips
-- a signal that saved package material feeds follow-up drafting
-- linked-thread continuity state in Correspondence
-- explicit manual-send boundary copy in Follow up
-
----
-
-## Test Case 1 — `/jobs` routes into the trusted workspace
-
-### Steps
-
-1. Open `/jobs`.
-2. Find a job row with a workflow chip, readiness signal, or next-action control.
-3. Open that job using the primary workflow action.
-
-### Expected
-
-- The dialog/workspace opens for the selected job.
-- The opened tab matches the job’s workflow need rather than a generic default.
-- The selected company and role match the job row you opened.
-
----
-
-## Test Case 2 — saved package material is visible and reusable
-
-### Steps
-
-1. In the opened job workspace, go to **Tailored CV**.
-2. Review the save-state chips for:
-   - Tailored CV
-   - Cover letter
-   - Application answer
-   - Recruiter message
-3. Review the “Saved working material” panel.
-4. If the job already has saved package data, confirm those fields show as saved.
-
-### Expected
-
-- The page shows save-state chips instead of leaving package trust implicit.
-- The workspace explicitly indicates that saved package material feeds follow-up drafting.
-- Saved material reflects the job’s current stored state, not just the latest generated draft.
-- Resetting or revisiting the tab preserves the saved package state.
-
-### Edge checks
-
-- If one package field is unsaved, only that field should look incomplete; generic notes alone should not make the job appear package-ready.
-- If the application answer exists, it should come back from saved state rather than disappearing or duplicating.
-
----
-
-## Test Case 3 — correspondence shows linked-thread continuity in the workspace
-
-### Steps
-
-1. Open the **Correspondence** tab for the same job.
-2. Confirm the Gmail connection state is visible.
-3. Confirm the linked-thread panel/state is visible in the main workspace.
-4. Review the linked-thread count.
-5. Click **Refresh linked threads**.
-
-### Expected
-
-- The workspace shows Gmail connection status without needing the import modal to explain trust.
-- If linked Gmail threads already exist, the workspace shows the linked-thread count.
-- After refresh, the UI reports whether new messages were imported or whether linked threads were already current.
-- The user is not forced through a full thread re-import flow for a thread that is already linked.
-
-### Edge checks
-
-- If no new Gmail messages exist, the refresh should say the linked threads are current rather than failing silently.
-- If the job has no linked threads, the UI should say so clearly instead of implying a broken refresh.
-
----
-
-## Test Case 4 — new linked correspondence appears without thread re-import
-
-### Steps
-
-1. Use a job whose recruiter thread has changed since the last import, or create that condition safely before the test.
-2. With the same job open in **Correspondence**, trigger **Refresh linked threads**.
-3. Review the correspondence timeline/list after refresh.
-
-### Expected
-
-- The new inbound or user-sent Gmail message appears in the same job’s correspondence.
-- The refresh uses the already-linked Gmail thread.
-- The user does not need to search for and re-import the whole thread manually.
-
-### Edge checks
-
-- Duplicate refreshes should not keep importing the same message repeatedly.
-- Imported message order and thread continuity should still look sensible in the correspondence list.
-
----
-
-## Test Case 5 — grounded follow-up drafting stays separate from send
-
-### Steps
-
-1. Open the **Follow up** tab for the same job.
-2. Review the follow-up context panel.
-3. Confirm it references package/correspondence grounding such as thread subject, last activity, or other grounding signals.
-4. Click **Regenerate draft** if needed.
-5. Review the manual-send boundary panel.
-6. Edit the subject/body if desired.
-7. **Stop before clicking `Send and log email`** unless outbound mail is confirmed safe.
-
-### Expected
-
-- The draft context clearly reflects saved package material and imported correspondence.
-- Regenerating the draft changes/reloads draft content only; it does not send email.
-- The manual-send boundary copy clearly states that generation/regeneration never sends recruiter email.
-- The only outbound action remains the explicit send button.
-
-### Edge checks
-
-- If the recruiter email field is blank, drafting should still work; only the manual send step should be blocked or require completion.
-- Draft review/editing should remain possible without side effects in correspondence.
-
----
-
-## Test Case 6 — `/dashboard` opens the same job with the same semantics
-
-### Steps
-
-1. Close the workspace.
-2. Open `/dashboard`.
-3. Find the same job in an attention, readiness, or reminder card.
-4. Open the job from the dashboard action.
-
-### Expected
-
-- The same job workspace opens.
-- The opened tab/action meaning matches the job’s workflow need.
-- Saved package state, linked-thread continuity state, and follow-up context are the same as when the job was opened from `/jobs`.
-
-### Edge checks
-
-- The dashboard should not route the same job to a conflicting tab/action compared with `/jobs`.
-
----
-
-## Test Case 7 — `/reminders` opens the same job with the same semantics
-
-### Steps
-
-1. Close the workspace.
-2. Open `/reminders`.
-3. Find the same job in its reminder grouping.
-4. Open the job from the reminder action.
-
-### Expected
-
-- The same job workspace opens.
-- The same job lands in the same workflow area or equivalent action destination as the other entry points.
-- Package state, correspondence continuity, and follow-up trust state remain unchanged.
-
-### Edge checks
-
-- Reminder grouping should reflect the same workflow classification seen elsewhere, not a conflicting heuristic.
-
----
-
-## Test Case 8 — optional safe-sink send verification
-
-> Run this only if outbound email is confirmed safe.
-
-### Steps
-
-1. Confirm the environment is using a stub mailbox, sink, or other non-production target.
-2. In **Follow up**, click `Send and log email`.
-3. Re-open **Correspondence** and/or refresh the job state.
-
-### Expected
-
-- The outbound action occurs only after the explicit click.
-- The job history/correspondence reflects the sent follow-up appropriately.
-- No autonomous send happened before this explicit action.
-
-### Edge checks
-
-- If the send endpoint is intentionally stubbed, the UI should still make the boundary clear and report the stubbed result consistently.
-
----
-
-## Pass Criteria
-
-S05 passes UAT when all of the following are true for the same job:
-
-- `/jobs`, `/dashboard`, and `/reminders` all open the same job workspace coherently.
-- Saved package material is visible as reusable workflow state.
-- Linked-thread continuity is visible in the correspondence workspace.
-- Refreshing linked threads updates correspondence without requiring re-import of an already-linked thread.
-- Follow-up drafting is clearly grounded in package + correspondence context.
-- Draft generation/regeneration never sends email on its own.
-- No recruiter email is sent unless the human explicitly chooses the send action in a safe environment.
-
-## Failure Clues
-
-- Different surfaces route the same job to conflicting next actions.
-- Generic notes make the job appear package-ready when saved package material is actually missing.
-- Linked-thread freshness is hidden, ambiguous, or only discoverable through import-only UI.
-- Refreshing linked threads requires a new full-thread import.
-- Regenerating a follow-up draft appears coupled to sending.
-- Workspace state changes depending on whether the job was opened from jobs, dashboard, or reminders.

.gsd/milestones/M001/slices/S05/tasks/T01-PLAN.md

@@ -1,60 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 8
-skills_used:
-  - aspnet-core
-  - react-best-practices
-  - test
----
-
-# T01: Centralize workflow trust signals across overview and readiness surfaces
-
-**Slice:** S05 — End-to-end trust and workflow polish
-**Milestone:** M001
-
-## Description
-
-Replace the remaining brittle workflow heuristics with one shared trust/action model so the table, dashboard, reminders, and readiness surfaces all describe the same next step for the same job.
-
-## Steps
-
-1. Audit the current reminder/readiness/action logic in `JobApplicationsController.cs`, `JobTable.tsx`, `DashboardView.tsx`, and `RemindersView.tsx`, with special attention to `followUpReason` string parsing and the saved application-answer notes-block constraint.
-2. Add explicit workflow trust/action fields or normalized route metadata to the backend DTOs and cover that behavior in a focused backend test.
-3. Introduce a shared UI helper that consumes the new contract and update the overview surfaces to route from it instead of duplicating local heuristics.
-4. Add focused frontend coverage proving that the same job produces the same next action across table, dashboard, and reminders.
-
-## Must-Haves
-
-- [ ] The workflow contract distinguishes package-work gaps from follow-up work without treating all `notes` text as generic readiness state.
-- [ ] Table, dashboard, and reminders open the shared workspace from one trust/action source of truth.
-- [ ] Backend and frontend focused tests fail if workflow signal drift reappears.
-
-## Verification
-
-- `dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --filter JobApplicationsWorkflowSignalsTests`
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/workflow-trust-signals.test.tsx`
-
-## Observability Impact
-
-- Signals added/changed: normalized workflow trust/action fields and readiness-derived routing metadata used by overview surfaces.
-- How a future agent inspects this: read `JobTrackerApi/Controllers/JobApplicationsController.cs` and `job-tracker-ui/src/jobWorkflowSignals.ts`, then run the focused backend/frontend tests.
-- Failure state exposed: mismatched overview actions, package-readiness drift, or fallback to string parsing becomes visible as deterministic test failures instead of silent UI inconsistency.
-
-## Inputs
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — current reminders/readiness logic and DTO shaping.
-- `job-tracker-ui/src/components/JobTable.tsx` — current next-action and readiness heuristics.
-- `job-tracker-ui/src/components/DashboardView.tsx` — current dashboard reminder routing.
-- `job-tracker-ui/src/components/RemindersView.tsx` — current reminders grouping and routing.
-- `job-tracker-ui/src/types.ts` — current DTO shapes available to the UI.
-
-## Expected Output
-
-- `JobTrackerApi/Controllers/JobApplicationsController.cs` — explicit workflow trust/action fields or normalized route metadata.
-- `JobTrackerApi.Tests/JobApplicationsWorkflowSignalsTests.cs` — backend proof for the normalized workflow contract.
-- `job-tracker-ui/src/types.ts` — updated UI contract for the new trust/action fields.
-- `job-tracker-ui/src/jobWorkflowSignals.ts` — shared workflow helper used by overview surfaces.
-- `job-tracker-ui/src/components/JobTable.tsx` — table actions driven from the shared trust/action model.
-- `job-tracker-ui/src/components/DashboardView.tsx` — dashboard attention actions driven from the shared trust/action model.
-- `job-tracker-ui/src/components/RemindersView.tsx` — reminders grouping/routing driven from the shared trust/action model.
-- `job-tracker-ui/src/workflow-trust-signals.test.tsx` — focused UI proof that overview surfaces stay aligned.

.gsd/milestones/M001/slices/S05/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S05
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T01: Centralize workflow trust signals across overview and readiness surfaces
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S05/tasks/T01-VERIFY.json

@@ -1,9 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T01",
-  "unitId": "M001/S05/T01",
-  "timestamp": 1774358881931,
-  "passed": true,
-  "discoverySource": "none",
-  "checks": []
-}

.gsd/milestones/M001/slices/S05/tasks/T02-PLAN.md

@@ -1,60 +0,0 @@
----
-estimated_steps: 4
-estimated_files: 5
-skills_used:
-  - react-best-practices
-  - agent-browser
-  - test
----
-
-# T02: Add integrated trust-loop proof and workspace polish
-
-**Slice:** S05 — End-to-end trust and workflow polish
-**Milestone:** M001
-
-## Description
-
-Compose the milestone’s existing package, Gmail, and follow-up flows into one integrated UI proof path, then make the smallest workspace polish changes needed so that path feels trustworthy and keeps outbound send explicitly manual.
-
-## Steps
-
-1. Build a focused integrated React test that starts from an overview entry path and exercises package reuse, linked-thread continuity, and grounded follow-up drafting inside the shared workspace.
-2. Update `JobDetailsDialog.tsx` and `Correspondence.tsx` only where the integrated proof exposes unclear state, missing trust copy, or continuity ambiguity.
-3. Re-run the focused S01-S04 regressions to confirm the integrated path did not break the narrower package, Gmail, follow-up, or daily-loop contracts.
-4. Write a live-safe UAT runbook that tells a human how to verify the full loop against real services without triggering accidental recruiter email.
-
-## Must-Haves
-
-- [ ] A single integrated UI regression proves overview → workspace → saved package → linked Gmail thread refresh → grounded follow-up draft.
-- [ ] The workspace keeps the manual-send boundary explicit and does not couple draft generation to `send-followup`.
-- [ ] A human can run the final live-UAT flow safely using the documented guardrails.
-
-## Verification
-
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/end-to-end-trust-loop.test.tsx`
-- `CI=true npm --prefix job-tracker-ui test -- --watch=false --runTestsByPath src/correspondence-gmail-import.test.tsx src/job-details-generated-drafts.test.tsx src/job-details-followup-drafts.test.tsx src/daily-control-loop.test.tsx`
-- `CI=true npm --prefix job-tracker-ui run build`
-
-## Observability Impact
-
-- Signals added/changed: clearer workspace trust state around saved package reuse, linked-thread refresh outcomes, and follow-up draft/manual-send separation.
-- How a future agent inspects this: run `src/end-to-end-trust-loop.test.tsx`, inspect `JobDetailsDialog.tsx` and `Correspondence.tsx`, and follow `.gsd/milestones/M001/slices/S05/S05-UAT.md` for live verification.
-- Failure state exposed: broken loop composition, stale correspondence continuity, or accidental send coupling surfaces in one integrated test instead of requiring four separate slice tests to infer the regression.
-
-## Inputs
-
-- `job-tracker-ui/src/jobWorkflowSignals.ts` — shared workflow action helper from T01.
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — package workspace, follow-up drafting, and readiness surfaces.
-- `job-tracker-ui/src/components/Correspondence.tsx` — Gmail import and linked-thread continuity workspace.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — current routed overview proof from S04.
-- `job-tracker-ui/src/correspondence-gmail-import.test.tsx` — current Gmail continuity proof from S01.
-- `job-tracker-ui/src/job-details-generated-drafts.test.tsx` — current package save/reuse proof from S02.
-- `job-tracker-ui/src/job-details-followup-drafts.test.tsx` — current follow-up grounding/manual-send proof from S03.
-
-## Expected Output
-
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx` — polished workspace trust state for package reuse and follow-up/manual-send separation.
-- `job-tracker-ui/src/components/Correspondence.tsx` — polished linked-thread continuity state used by the integrated loop.
-- `job-tracker-ui/src/end-to-end-trust-loop.test.tsx` — integrated UI proof for the full trust loop.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` — updated overview proof if the shared trust-loop entry semantics change.
-- `.gsd/milestones/M001/slices/S05/S05-UAT.md` — live-safe end-to-end verification runbook.

.gsd/milestones/M001/slices/S05/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S05
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T02: Add integrated trust-loop proof and workspace polish
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S05/tasks/T02-VERIFY.json

@@ -1,25 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T02",
-  "unitId": "M001/S05/T02",
-  "timestamp": 1774359406536,
-  "passed": false,
-  "discoverySource": "none",
-  "checks": [],
-  "retryAttempt": 1,
-  "maxRetries": 2,
-  "runtimeErrors": [
-    {
-      "source": "bg-shell",
-      "severity": "crash",
-      "message": "[jobtracker-api] exitCode=127",
-      "blocking": true
-    },
-    {
-      "source": "bg-shell",
-      "severity": "crash",
-      "message": "[jobtracker-api] exitCode=134 errors: --- End of inner exception stack trace ---; --- End of inner exception stack trace ---",
-      "blocking": true
-    }
-  ]
-}

.gsd/milestones/M001/slices/S06/S06-PLAN.md

@@ -1,15 +0,0 @@
-# S06: Live environment stabilization and integrated acceptance rerun
-
-**Goal:** Live environment is repeatably startable and preflighted, seeded with acceptance-ready data, and the integrated daily loop is re-verified with a recorded artifact proving the manual-send boundary and individual-first workflow.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Validated and recorded the live API/auth preflight gate, including README runbook guidance and negative-path shell coverage.** — 
-  - Files: scripts/s06-preflight.sh, README.md, job-tracker-ui/src/api.ts, JobTrackerApi/appsettings.Development.json
-  - Verify: bash scripts/s06-preflight.sh
-- [x] **T02: Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output.** — 
-  - Files: scripts/s06-acceptance-data.sh, scripts/s06-preflight.sh, README.md
-  - Verify: bash scripts/s06-acceptance-data.sh
-- [x] **T03: Added a repeatable live acceptance runner and recorded real S06 browser evidence for the manual-send boundary and daily loop.** — 
-  - Files: scripts/s06-acceptance-run.sh, docs/s06-acceptance-run.md, scripts/s06-preflight.sh, scripts/s06-acceptance-data.sh, job-tracker-ui/src/end-to-end-trust-loop.test.tsx
-  - Verify: bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md

.gsd/milestones/M001/slices/S06/S06-RESEARCH.md

@@ -1,261 +0,0 @@
-# S06 Research — Live environment stabilization and integrated acceptance rerun
-
-## Summary
-
-S06 is primarily an environment-proof and acceptance-artifact slice, not a new feature slice. The product loop from S01–S05 is already implemented and mostly works against the local seeded dataset once the live backend is actually running and the browser is authenticated. The real blockers for a true live rerun are environmental:
-
-1. the frontend hard-calls `http://localhost:5202/api` in localhost dev (`job-tracker-ui/src/api.ts`), so the UI immediately fails with `ERR_CONNECTION_REFUSED` if the API is not already up
-2. auth is required in the local dev environment (`JobTrackerApi/appsettings.Development.json`), so a live rerun also needs a valid token/session before `/jobs`, `/dashboard`, and `/reminders` are usable
-3. Gmail live continuity cannot be fully re-checked in this environment because Gmail OAuth is only partially configured: `Auth:GoogleClientId` exists, but `Google:GmailClientSecret` / redirect config are absent, so `/api/gmail/status` reports `connected:false` and `/api/admin/system` reports `gmailConfigured:false`
-4. the seeded local dataset is minimal (1 job / 1 company) and does not exercise the full S05 trust loop naturally: the sample job opens from reminders and the workspace/follow-up flow works, but the dashboard does not currently expose a useful job-level action card, and correspondence only has one linked external thread message plus one locally logged follow-up
-
-This means S06 should likely split into: **environment bring-up/diagnostics**, then **seed/data conditioning for acceptance**, then **real browser rerun + recorded artifact**.
-
-## Active Requirements To Target
-
-### R008 — manual-send boundary stays explicit
-S06 must re-prove this in the live browser, especially because Follow-up draft already renders a real `Send and log email` button in `JobDetailsDialog` while generation remains separate.
-
-### R009 — individual-first daily loop
-S06 must prove the same job can be worked from overview surfaces without needing admin-only or multi-record complexity. The current local dataset is individual-friendly but too thin to prove all overview semantics.
-
-## Skills Discovered
-
-- Existing installed skills used for approach guidance:
-  - `debug-like-expert` — informed the evidence-first, no-assumption investigation approach
-  - `agent-browser` — informed the browser verification workflow
-- Newly installed during research:
-  - `gmail` (`odyssey4me/agent-skills@gmail`)
-- Tried but not usable for this slice:
-  - `jezweb/claude-skills@google-workspace` search result did not expose a directly installable `google-workspace` skill name from that repo
-
-## What Exists Now
-
-### Runtime and config surfaces
-
-- `job-tracker-ui/src/api.ts`
-  - On `localhost`, defaults API traffic to `http://localhost:5202/api`
-  - In production/non-localhost, defaults to `/api`
-  - No CRA dev proxy file exists; dev depends on direct cross-origin API access
-- `JobTrackerApi/Program.cs`
-  - CORS policy defaults to `http://localhost:3000`
-  - `app.UseCors("AllowReact")` is already wired
-  - auth + migrations + admin seeding happen at startup
-- `JobTrackerApi/appsettings.Development.json`
-  - `Auth:Require=true`
-  - local CORS allowlist includes `http://localhost:3000`
-  - placeholder local admin + JWT values exist
-  - `Auth:GoogleClientId` placeholder exists, which makes Google auth look enabled even when Gmail OAuth is not actually fully configured
-- `README.md`
-  - already documents the exact dev topology: UI on `:3000`, API on `:5202`, UI defaulting to `http://localhost:5202/api`
-- `JobTrackerApi/Controllers/AdminSystemController.cs`
-  - best existing operational probe for S06
-  - exposes database, auth, Gmail-configured, and AI-health status in one call
-- `job-tracker-ui/src/pages/AdminSystemPage.tsx`
-  - already renders the above status in the UI
-
-### Auth and entry behavior
-
-- `JobTrackerApi/Controllers/AuthController.cs`
-  - `/api/auth/config` truthfully reports `requireAuth`, `googleEnabled`, `localEnabled`, `allowRegistration`
-  - local login is still standard username/password
-- `job-tracker-ui/src/App.tsx`
-  - fetches `/auth/config` and redirects to `/login` when auth is required and no token exists
-- `job-tracker-ui/src/pages/LoginPage.tsx`
-  - uses `/auth/login` or `/auth/register`
-  - `allowRegistration` is only exposed if backend allows it
-- `job-tracker-ui/src/auth.ts`
-  - token key is `authToken`
-
-### Daily-loop/workspace surfaces already in place
-
-- `job-tracker-ui/src/components/JobTable.tsx`
-- `job-tracker-ui/src/components/DashboardView.tsx`
-- `job-tracker-ui/src/components/RemindersView.tsx`
-- `job-tracker-ui/src/components/JobDetailsDialog.tsx`
-- `job-tracker-ui/src/components/Correspondence.tsx`
-- `job-tracker-ui/src/end-to-end-trust-loop.test.tsx`
-
-The S05 contract is real: the workspace tabs, follow-up generation, reminders open path, and correspondence/follow-up tabs are all present in the running UI.
-
-## Evidence From Live Investigation
-
-### 1. The original frontend blockage is real and immediate
-
-When the browser opened `http://localhost:3000/login` before the API was up, the first failing request was:
-
-- `GET http://localhost:5202/api/auth/config → net::ERR_CONNECTION_REFUSED`
-
-This matches the carried-forward gotcha exactly: if port `5202` is not serving, the shell UI loads but the real app loop is blocked.
-
-### 2. Backend works once started correctly
-
-Running from the API project directory with the explicit dotnet path succeeds:
-
-- `ASPNETCORE_ENVIRONMENT=Development ASPNETCORE_URLS=http://127.0.0.1:5202 /home/pi/.gsd/agent/bin/dotnet run --no-launch-profile`
-
-Observed runtime facts:
-
-- API listens on `http://127.0.0.1:5202`
-- DB migrations are already up to date
-- local SQLite DB is present and readable
-- the prior bg-shell failure was a process-launch/cwd/runtimeconfig issue, not an application-code crash
-
-Important planning note: the generic `bg_shell start` cwd is not the user-mandated worktree by default in this harness. Absolute paths or an explicit shell `cd` are safer when scripting S06 verification.
-
-### 3. Admin/system status gives the clearest stabilization checklist
-
-`GET /api/admin/system` returned:
-
-- database: configured + connectable
-- auth: required, JWT key present
-- Google login configured: true
-- Gmail configured: false
-- AI healthy: true
-- storage has only 1 company / 1 job
-
-This is the most useful pre-UAT gate to run before any browser rerun.
-
-### 4. Live data is too thin for a full acceptance rerun
-
-Current seeded API state:
-
-- `GET /api/jobapplications` returns exactly 1 job: `Acme Browser QA / Backend Developer`
-- `workflowSignal.actionKey = review-readiness`
-- `needsFollowUp = false`
-- `GET /api/jobapplications/reminders` still returns the same job under reminders, but only as an “Other reminders” case
-- dashboard renders analytics and aggregate cards, but with this dataset it does **not** expose the richer job-level action surface that S04/S05 were meant to re-check
-
-This means the current local DB is enough to prove the app runs, but not enough to strongly prove the milestone’s intended `/jobs` → workspace → Gmail continuity → follow-up → dashboard/reminders loop.
-
-### 5. Follow-up drafting and manual-send boundary are live
-
-In the running browser, opening the sample job from `/reminders` succeeded and the job workspace rendered.
-
-On the **Follow-up draft** tab, live UI showed:
-
-- generated subject/body from `/api/jobapplications/1/followup-draft`
-- recruiter recipient prefilled (`maria@acme.test`)
-- explicit `Send and log email` button
-- separate generation/loading behavior from the send action
-
-This supports R008: drafting is live, but send is still an explicit separate action.
-
-### 6. Correspondence continuity UI is only partially exercised locally
-
-`Correspondence.tsx` does contain the linked-thread continuity panel and manual refresh flow, but the local sample data does not currently expose it meaningfully:
-
-- `GET /api/correspondence/1` has one imported-style external thread message and one locally logged sent-style message
-- `GET /api/gmail/status` returns `connected:false`
-- because Gmail is disconnected and the second message lacks external thread metadata, the real linked-thread refresh loop cannot be demonstrated live here
-
-So S06 cannot honestly claim Gmail continuity rerun in this environment until Gmail config + account linking are present.
-
-## Implementation Landscape
-
-### Natural task seams
-
-#### Seam 1 — environment bring-up and diagnostics
-Focus files/surfaces:
-- `JobTrackerApi/Program.cs`
-- `JobTrackerApi/appsettings.Development.json`
-- `job-tracker-ui/src/api.ts`
-- `README.md`
-- `JobTrackerApi/Controllers/AdminSystemController.cs`
-- `job-tracker-ui/src/pages/AdminSystemPage.tsx`
-
-Goal:
-- make the live local topology easy to start and verify before browser UAT begins
-- likely produce or tighten a repeatable runbook/checklist rather than large code changes
-
-#### Seam 2 — acceptance seed/data conditioning
-Focus surfaces:
-- existing API endpoints / local DB seed path
-- possibly task-local scripts or documented setup steps
-
-Goal:
-- ensure at least one job truly exercises:
-  - overview action from `/jobs`
-  - meaningful reminder/dashboard action
-  - saved package state
-  - linked correspondence state
-  - follow-up draft grounding
-
-This is the riskiest seam because the current one-job dataset is operational but not acceptance-rich.
-
-#### Seam 3 — browser rerun and artifact capture
-Focus surfaces:
-- browser verification itself
-- `.gsd` UAT/summary artifact output for S06
-- likely downstream dependency for S07
-
-Goal:
-- record what was actually exercised live
-- distinguish clearly between:
-  - fully live checks
-  - blocked checks
-  - mocked/not-possible checks
-
-## Recommendation
-
-1. **Build a hard preflight gate first.** Before any browser rerun, check:
-   - API reachable on `:5202`
-   - `/api/auth/config` reachable
-   - admin/system status healthy for DB + AI
-   - Gmail-configured status truthfully known
-2. **Do not start with browser fixes.** The main current failure mode is not React routing; it is environment readiness.
-3. **Treat Gmail as an explicit acceptance branch.** If Gmail remains unconfigured, S06 should record that the full Gmail continuity rerun is blocked and either:
-   - add a safe local config/setup task, or
-   - scope S06 to environment stabilization plus non-Gmail integrated rerun, leaving Gmail closure to a follow-up task/slice
-4. **Augment the local acceptance dataset before claiming success.** The present single sample job does not naturally prove dashboard/reminders/job-table coherence strongly enough.
-5. **Use the S05 integrated regression as the contract oracle.** If live behavior diverges from `job-tracker-ui/src/end-to-end-trust-loop.test.tsx`, investigate the environment/data first before changing UI logic.
-
-## Risks / Constraints
-
-- **Gmail is the biggest live blocker.** `googleConfigured=true` does not mean Gmail import is usable; `gmailConfigured=false` in admin/system is the truer signal for S06.
-- **Auth can block all browser checks.** Since dev auth is required, any UAT runbook must include token/login setup.
-- **The dataset currently biases toward a low-urgency readiness case.** This can make dashboard/reminders look less actionable than they were designed to be.
-- **Do not infer success from shell render.** The login page and app shell can render even while API traffic is broken.
-
-## Verification Plan
-
-### Preflight
-
-- Start API from `JobTrackerApi/` and verify `GET /api/auth/config`
-- Verify `GET /api/admin/system` as an admin token/session
-- Confirm these fields before browser UAT:
-  - `database.canConnect = true`
-  - `ai.healthy = true`
-  - `auth.required = true/false` understood
-  - `auth.gmailConfigured = true` if Gmail continuity is in scope
-
-### Browser rerun
-
-For one chosen acceptance job:
-
-1. `/jobs` opens the correct workspace
-2. `/reminders` opens the same job/workspace semantics
-3. `/dashboard` exposes and opens the same job/workspace semantics
-4. **Tailored CV** shows saved package state clearly
-5. **Correspondence** shows linked-thread continuity state
-6. **Follow-up draft** shows grounded context and explicit manual-send boundary
-7. Do **not** click send unless outbound mail is intentionally pointed at a safe sink
-
-### Contract spot checks
-
-Useful endpoints to compare against live UI:
-
-- `GET /api/jobapplications`
-- `GET /api/jobapplications/reminders`
-- `GET /api/jobapplications/{id}`
-- `GET /api/correspondence/{jobId}`
-- `GET /api/jobapplications/{id}/followup-draft`
-- `GET /api/gmail/status`
-- `GET /api/admin/system`
-
-## Planner Notes
-
-- This slice is not mainly a coding problem unless the planner finds a missing preflight/diagnostic surface. It is mostly an **environment + proof** problem.
-- The first executable task should probably be a stabilization/proof task, not a product-feature task.
-- If the planner wants a high-confidence S06 outcome, it should require a decision on whether Gmail live acceptance is actually achievable in this environment before promising full milestone rerun coverage.
-- S07 depends on S06 producing truthful acceptance evidence. If S06 cannot execute Gmail live, that limitation must be recorded explicitly rather than papered over.

.gsd/milestones/M001/slices/S06/S06-SUMMARY.md

@@ -1,98 +0,0 @@
----
-id: S06
-parent: M001
-milestone: M001
-provides:
-  - A repeatable localhost preflight + seed + acceptance-run workflow for the M001 trust loop.
-  - A deterministic live acceptance fixture (`S06 Acceptance Labs` / `S06 Acceptance Backend Engineer`) that surfaces saved package state, recruiter-thread correspondence, follow-up readiness, and dashboard/reminder visibility.
-  - A recorded live acceptance artifact that downstream closure/UAT work can reference instead of reconstructing the environment from scratch.
-  - Fresh live proof that the manual-send boundary still holds in the real stack.
-requires:
-  - slice: S05
-    provides: The shared workflow-signal contract, integrated trust-loop regression, and manual-send-boundary behavior that S06 re-verified in the real environment.
-affects:
-  - S07
-key_files:
-  - scripts/s06-preflight.sh
-  - scripts/s06-acceptance-data.sh
-  - scripts/s06-acceptance-data.test.sh
-  - scripts/s06-acceptance-run.sh
-  - docs/s06-acceptance-run.md
-  - .gsd/DECISIONS.md
-  - .gsd/KNOWLEDGE.md
-  - .gsd/PROJECT.md
-key_decisions:
-  - D013: seed the acceptance fixture through the live API contract with deterministic identifiers so reruns are idempotent and prove real code paths.
-  - D014: allow the acceptance runner to mint a localhost-only admin JWT from checked-in dev JWT settings plus the local SQLite admin user when `AUTH_TOKEN` is absent.
-  - D015: treat `/api/auth/config` reachability plus an auth-limited `/api/admin/system` probe as a guided partial-pass, and never echo bearer tokens in preflight output.
-patterns_established:
-  - Use a preflight gate before browser UAT so backend/CORS/auth blockers fail fast with readable guidance instead of surfacing later as ambiguous frontend runtime errors.
-  - Seed live acceptance fixtures through the same authenticated HTTP endpoints the UI uses, with deterministic company/title/thread/message identifiers, so reruns prove the real contract and stay idempotent.
-  - Persist a single acceptance-run artifact (`docs/s06-acceptance-run.md`) that refreshes shell evidence without destroying the guided browser-observation section, so later slices can build on one stable handoff document.
-  - Record manual-send-boundary evidence as both UI observation and network evidence; for this slice, drafting may call `GET .../followup-draft` but must not trigger `POST .../send-followup` without an explicit human action.
-observability_surfaces:
-  - `scripts/s06-preflight.sh` console output for auth/db/gmailConfigured/ai readiness signals and clear failure guidance.
-  - `scripts/s06-acceptance-data.sh` seed summary output (`seed.result`, job/company ids, workflow action, readiness level, reminder state).
-  - `docs/s06-acceptance-run.md` plus `docs/artifacts/s06-acceptance/logs/*` for shell-step evidence and blocker guidance.
-  - Recorded browser artifacts referenced from the acceptance doc (jobs/workspace, follow-up draft, reminders/dashboard, trace, timeline).
-drill_down_paths:
-  - .gsd/milestones/M001/slices/S06/tasks/T01-SUMMARY.md
-  - .gsd/milestones/M001/slices/S06/tasks/T02-SUMMARY.md
-  - .gsd/milestones/M001/slices/S06/tasks/T03-SUMMARY.md
-duration: ""
-verification_result: passed
-completed_at: 2026-03-27T08:29:02.335Z
-blocker_discovered: false
----
-
-# S06: Live environment stabilization and integrated acceptance rerun
-
-**Stabilized the live localhost stack with a repeatable preflight + seed + acceptance runner flow and re-proved the `/jobs` → workspace → reminders/dashboard loop with recorded manual-send-boundary evidence.**
-
-## What Happened
-
-S06 turned the previously fragile live environment into a repeatable acceptance target instead of a one-off debugging session. The slice added a preflight gate that checks the real API contract before UI work starts, an idempotent live-data seed that creates or refreshes a deterministic acceptance fixture through the same HTTP endpoints the app uses in normal operation, and a single acceptance runner that ties preflight, seeding, the integrated trust-loop regression, and the live evidence document together. The resulting live run now proves that the seeded job appears on `/jobs`, opens the real workspace with saved Tailored CV and package state, shows deterministic recruiter-thread correspondence, appears on `/reminders` with the expected `Follow up` / `Waiting 14d` signals, and contributes to `/dashboard` analytics without frontend runtime failures. The slice also re-proved the manual-send boundary in the actual stack: opening or regenerating the follow-up draft issued `GET /api/jobapplications/3/followup-draft` but no `POST /api/jobapplications/3/send-followup`, so drafting stayed assistive and did not cross into autonomous sending. The main remaining live gap is Gmail-connected continuity: the seeded correspondence is visible, but this localhost run did not have a connected Gmail session and therefore did not execute a linked-thread refresh request. That gap is now explicit in the acceptance artifact instead of being mistaken for a fully proven live Gmail refresh.
-
-## Verification
-
-Verified the assembled slice in the live worktree with the real backend and frontend running on the expected localhost origins. Commands run: `bash scripts/s06-preflight.sh` (exit 0, expected auth-limited partial-pass when `/api/admin/system` requires a token), `TEST_AUTH_TOKEN="$TOKEN" AUTH_TOKEN="$TOKEN" bash scripts/s06-acceptance-data.test.sh` (exit 0; missing-token, bad-token, and double-rerun cases all passed), `AUTH_TOKEN="$TOKEN" bash scripts/s06-acceptance-data.sh` (exit 0; `seed.result=success`, stable company/job fixture, `seed.workflow.action=follow-up`, `seed.readiness.level=Ready`, `seed.reminders=Waiting 14d`), and `bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md` (exit 0). The recorded live browser evidence in `docs/s06-acceptance-run.md` confirms `/jobs`, workspace, `/reminders`, and `/dashboard` behavior plus the manual-send boundary and a clean dashboard reload with no console errors or failed requests.
-
-## Requirements Advanced
-
-- R008 — S06 re-proved the manual-send boundary in the live stack: follow-up drafting remained assistive, and the recorded network evidence showed no send endpoint call during draft review/regeneration.
-- R009 — S06 re-checked the individual-first loop in the real environment by proving one seeded job behaves coherently across `/jobs`, the per-job workspace, `/reminders`, and `/dashboard`.
-
-## Requirements Validated
-
-None.
-
-## New Requirements Surfaced
-
-None.
-
-## Requirements Invalidated or Re-scoped
-
-None.
-
-## Deviations
-
-Added two bounded implementation choices beyond the original plan to keep reruns repeatable in this real environment: a localhost-only JWT fallback inside the acceptance runner because the checked-in dev password no longer authenticates against the current SQLite snapshot, and an explicit preflight partial-pass path for the auth-limited `/api/admin/system` case so browser/UAT work is blocked only by true environment failures. Gmail continuity was recorded as not configured/not refreshed in this run rather than being overstated as a proven live success.
-
-## Known Limitations
-
-This slice does not prove a real Gmail-connected linked-thread refresh in the local environment. The seeded recruiter correspondence is present and the workspace loop is otherwise live, but the browser run did not expose connected Gmail state or issue `POST /api/gmail/refresh-linked-threads`. The acceptance data fixture is intentionally deterministic and single-user; it is suitable for localhost reruns, not for multi-user or production seeding.
-
-## Follow-ups
-
-S07 should turn this rerunnable acceptance flow into the final daily-loop UAT closure artifact, ideally in an environment where Gmail is actually connected so linked-thread refresh can be observed live. If the Gmail account remains unavailable locally, S07 should keep the limitation explicit rather than weakening the trust claim. If future slices rely on the S06 fixture, preserve the deterministic identifiers and rerun-safe update behavior instead of adding duplicate seed records.
-
-## Files Created/Modified
-
-- `scripts/s06-preflight.sh` — Provides the live API/auth/CORS preflight gate with readable failure guidance and an auth-limited partial-pass path.
-- `scripts/s06-acceptance-data.sh` — Seeds or refreshes the deterministic acceptance fixture through the live API and prints readiness/reminder output.
-- `scripts/s06-acceptance-data.test.sh` — Exercises missing-token, bad-token, and idempotent rerun cases for the acceptance seeding flow.
-- `scripts/s06-acceptance-run.sh` — Orchestrates preflight, seeding, the integrated trust-loop regression, log capture, and the acceptance document refresh.
-- `docs/s06-acceptance-run.md` — Records the live S06 acceptance rerun, browser observations, manual-send-boundary evidence, and the remaining Gmail continuity gap.
-- `.gsd/DECISIONS.md` — Captured S06 environment decisions, including live-API seeding, local JWT fallback, and preflight auth handling.
-- `.gsd/KNOWLEDGE.md` — Captured the auth-limited preflight behavior and the local admin/JWT rerun pattern for future agents.
-- `.gsd/PROJECT.md` — Updated project state to reflect S06 completion and the remaining S07 closure focus.

.gsd/milestones/M001/slices/S06/S06-UAT.md

@@ -1,209 +0,0 @@
-# S06: Live environment stabilization and integrated acceptance rerun — UAT
-
-**Milestone:** M001
-**Written:** 2026-03-27T08:29:02.335Z
-
-# S06 UAT — Live environment stabilization and integrated acceptance rerun
-
-## Goal
-
-Prove that the real localhost environment can be started, preflighted, seeded with acceptance-ready data, and used to rerun the integrated daily loop for the deterministic acceptance fixture without crossing the manual-send boundary.
-
-The concrete fixture for this slice is:
-
-- Company: `S06 Acceptance Labs`
-- Job: `S06 Acceptance Backend Engineer`
-- Expected workflow state: `Follow up`, `Ready`, `Waiting 14d`
-
-## Preconditions
-
-1. Backend is running at `http://localhost:5202` and frontend is running at `http://localhost:3000`.
-2. The worktree contains the S06 scripts and `docs/s06-acceptance-run.md`.
-3. If running the seed script directly, a valid bearer token is available in `AUTH_TOKEN`.
-4. If running only `bash scripts/s06-acceptance-run.sh`, the default localhost dev JWT fallback is allowed to mint a local token from the checked-in dev JWT settings plus the local SQLite admin user.
-5. Do **not** click `Send And Log Email` unless outbound mail is intentionally pointed at a safe sink.
-
----
-
-## Test Case 1 — Preflight catches the real environment state before browser work
-
-### Steps
-
-1. Run `bash scripts/s06-preflight.sh`.
-2. Review the printed readiness lines.
-
-### Expected
-
-- The script prints `Preflight target: http://localhost:5202/api`.
-- The script prints the required origin pair `UI http://localhost:3000 -> API http://localhost:5202/api`.
-- The script reports `auth.requireAuth=true` and the auth config surface is reachable.
-- If `/api/admin/system` is not called with an admin token, the script still exits successfully with the guided partial-pass message instead of failing ambiguously.
-
-### Edge checks
-
-- If the API is down or `API_BASE` is wrong, the script exits non-zero with a clear start-the-API hint.
-- If the API returns malformed JSON, the script prints the raw body and fails.
-
----
-
-## Test Case 2 — Acceptance seeding produces the deterministic live fixture
-
-### Steps
-
-1. Export a valid token to `AUTH_TOKEN`.
-2. Run `bash scripts/s06-acceptance-data.sh`.
-3. Review the seed summary output.
-4. Run the script a second time.
-
-### Expected
-
-- The script prints `seed.result=success`.
-- The script prints stable `seed.company.id` / `seed.job.id` values and does not create duplicate jobs on rerun.
-- The script prints `seed.workflow.action=follow-up`.
-- The script prints `seed.readiness.level=Ready`.
-- The script prints `seed.reminders=Waiting 14d`.
-- The job has saved Tailored CV / package state and recruiter-thread correspondence prepared for later browser verification.
-
-### Edge checks
-
-- Running without `AUTH_TOKEN` fails immediately with guidance.
-- Running with a bad token fails clearly as an auth issue.
-- Re-running the seed does not create duplicate deterministic correspondence for the same external message id.
-
----
-
-## Test Case 3 — The acceptance runner refreshes the artifact and keeps evidence on disk
-
-### Steps
-
-1. Run `bash scripts/s06-acceptance-run.sh`.
-2. Confirm `docs/s06-acceptance-run.md` exists and is non-empty.
-3. Open the generated markdown and review the shell summary table.
-
-### Expected
-
-- The runner reports `acceptance.result=pass`.
-- The runner records `Preflight`, `Seed acceptance data`, and `UI trust-loop test` as pass states.
-- The markdown contains a current run id, timestamp, auth-token-source category, and log paths under `docs/artifacts/s06-acceptance/logs/`.
-- The guided browser section remains present after rerun and is not overwritten by the shell refresh.
-
-### Edge checks
-
-- If preflight fails because the backend is unreachable, the runner exits non-zero and records the failure instead of proceeding.
-- If Gmail is not configured, the document calls that out as a live limitation rather than pretending Gmail continuity was proven.
-
----
-
-## Test Case 4 — `/jobs` opens the seeded workspace with saved package state
-
-### Steps
-
-1. Open `http://localhost:3000/jobs` in the live app.
-2. Locate the row for `S06 Acceptance Labs • S06 Acceptance Backend Engineer`.
-3. Confirm the row shows `Follow up`, `CV ready`, and `Waiting` style signals.
-4. Open the job workspace from that row.
-5. Go to **Tailored CV**.
-
-### Expected
-
-- The workspace opens for the seeded job, not a different row.
-- The Tailored CV area contains the saved seeded text beginning `Saved acceptance tailored CV highlighting ASP.NET Core delivery...`.
-- The saved package state is visible in the real workspace rather than only in test data or logs.
-
-### Edge checks
-
-- Re-opening the same job should show the same saved package state; it should not disappear or duplicate on revisit.
-
----
-
-## Test Case 5 — Follow-up drafting stays manual and does not auto-send
-
-### Steps
-
-1. From the same seeded job workspace, open **Follow up**.
-2. Wait for the draft to load or regenerate it if needed.
-3. Review the available actions.
-4. Inspect the network log if available.
-5. Stop **before** clicking `Send And Log Email`.
-
-### Expected
-
-- The follow-up draft loads successfully from the live backend.
-- The UI shows separate `Copy Draft` and `Send And Log Email` actions.
-- Draft loading/regeneration calls `GET /api/jobapplications/{id}/followup-draft`.
-- No `POST /api/jobapplications/{id}/send-followup` request occurs during draft review/regeneration alone.
-- The manual-send boundary remains explicit and intact.
-
-### Edge checks
-
-- Editing or regenerating the draft should not add a sent item to correspondence by itself.
-- If recruiter contact data is incomplete, drafting may still work while send remains the explicit guarded action.
-
----
-
-## Test Case 6 — `/reminders` and `/dashboard` reflect the same seeded job coherently
-
-### Steps
-
-1. Open `http://localhost:3000/reminders`.
-2. Find the seeded job under the follow-up grouping.
-3. Confirm the job shows `Follow up`, `Waiting 14d`, and `Follow-up: 10/03/2026`.
-4. Open `http://localhost:3000/dashboard`.
-5. Confirm the dashboard analytics include the seeded job/company state.
-6. Reload `/dashboard` and review browser diagnostics.
-
-### Expected
-
-- `/reminders` shows the same seeded job that was opened from `/jobs`.
-- `/dashboard` includes `S06 Acceptance Labs` in the activity/company view.
-- The dashboard reload completes without console errors or failed network requests.
-- The app behaves as one coherent single-user loop across all three surfaces.
-
-### Edge checks
-
-- If the job is missing from `/reminders`, the seed dates may no longer be beyond the active follow-up threshold and should be rechecked.
-- If `/dashboard` loads but records failed requests, treat the slice as not stabilized.
-
----
-
-## Test Case 7 — Gmail continuity status is reported honestly
-
-### Steps
-
-1. In the seeded job workspace, open **Correspondence**.
-2. Confirm the deterministic recruiter-thread message is present.
-3. Check whether the workspace exposes connected Gmail state and whether any linked-thread refresh request runs.
-4. Compare the observation with `docs/s06-acceptance-run.md`.
-
-### Expected
-
-- The recruiter-thread message seeded by S06 is visible.
-- If Gmail is connected in the environment, a linked-thread refresh can be observed and reported.
-- If Gmail is **not** connected, the acceptance artifact explicitly records that Gmail continuity was not proven live in this run.
-
-### Edge checks
-
-- Do not claim success for Gmail continuity merely because seeded correspondence is present.
-- Absence of `POST /api/gmail/refresh-linked-threads` in the live run means the slice only proved seeded correspondence visibility, not live Gmail refresh.
-
----
-
-## Pass Criteria
-
-S06 passes when all of the following are true:
-
-- The localhost stack is startable on the expected UI/API origins.
-- Preflight provides a readable go/no-go result instead of failing with opaque CORS/runtime symptoms.
-- The deterministic acceptance fixture can be seeded repeatably without duplicate drift.
-- The seeded job appears coherently across `/jobs`, the workspace, `/reminders`, and `/dashboard`.
-- Follow-up drafting remains manual and does not auto-send.
-- `docs/s06-acceptance-run.md` contains current shell evidence and honest browser observations, including any remaining Gmail continuity limitation.
-
-## Failure Clues
-
-- `scripts/s06-preflight.sh` fails because the API is unreachable or returns malformed JSON.
-- Seeding creates duplicate fixture data or no longer lands in `follow-up` / `Waiting 14d` state.
-- `/jobs`, workspace, `/reminders`, and `/dashboard` disagree about the seeded job’s next action.
-- Opening or regenerating a follow-up draft triggers a send request.
-- The acceptance artifact hides Gmail configuration limitations instead of recording them.
-- Dashboard reload still produces console errors or failed requests.

.gsd/milestones/M001/slices/S06/tasks/T01-PLAN.md

@@ -1,40 +0,0 @@
----
-estimated_steps: 12
-estimated_files: 4
-skills_used: []
----
-
-# T01: Add preflight gate for live API/auth readiness
-
-Build a repeatable preflight script and doc so environment blockers are caught before browser UAT.
-- Why: avoid the ERR_CONNECTION_REFUSED/CORS/auth mismatch that currently blocks the UI.
-- Steps:
-  1) Create `scripts/s06-preflight.sh` (bash, executable) that assumes backend already started; probes `/api/auth/config` and `/api/admin/system` on `http://localhost:5202/api`, printing database/auth/gmailConfigured/ai status and failing fast on unreachable endpoints.
-  2) Ensure script respects `API_BASE` env override and uses `curl -f` with readable errors; no secrets logged.
-  3) Add a short runbook snippet to `README.md` showing backend start command from `JobTrackerApi/` and how to run the preflight (including auth token note if required).
-  4) Sanity-check CORS expectations vs `job-tracker-ui/src/api.ts` and document the required origin pairing (UI :3000, API :5202).
-- Failure Modes (Q5): API down → exit 1 with hint to start API; Auth required without token → script notes auth required and how to obtain; malformed JSON → show raw body and fail.
-- Load Profile (Q6): trivial single-user curl calls; no scaling concern.
-- Negative Tests (Q7): run script with API stopped (expect non-zero); run with wrong `API_BASE` (expect clear error message).
-- Must-haves: preflight script exists/executable; README runbook mentions backend start + preflight; script outputs gmailConfigured/auth/db/ai fields.
-- Verification: `bash scripts/s06-preflight.sh`
-
-## Inputs
-
-- ``JobTrackerApi/Program.cs``
-- ``JobTrackerApi/appsettings.Development.json``
-- ``job-tracker-ui/src/api.ts``
-- ``README.md``
-
-## Expected Output
-
-- ``scripts/s06-preflight.sh``
-- ``README.md``
-
-## Verification
-
-bash scripts/s06-preflight.sh
-
-## Observability Impact
-
-Adds preflight status surface exposing DB/auth/gmail/ai readiness via curl; provides explicit failure messages for unreachable API/CORS/auth.

.gsd/milestones/M001/slices/S06/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S06
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T01: Validated and recorded the live API/auth preflight gate, including README runbook guidance and negative-path shell coverage.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S06/tasks/T01-VERIFY.json

@@ -1,26 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T01",
-  "unitId": "M001/S06/T01",
-  "timestamp": 1774598242061,
-  "passed": false,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "bash scripts/s06-preflight.sh",
-      "exitCode": 1,
-      "durationMs": 30,
-      "verdict": "fail"
-    }
-  ],
-  "retryAttempt": 1,
-  "maxRetries": 2,
-  "runtimeErrors": [
-    {
-      "source": "bg-shell",
-      "severity": "crash",
-      "message": "[jobtracker-api-abs] exitCode=131 errors: A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/pi/.dotnet'.; Failed to run as a self-contained app.",
-      "blocking": true
-    }
-  ]
-}

.gsd/milestones/M001/slices/S06/tasks/T02-PLAN.md

@@ -1,40 +0,0 @@
----
-estimated_steps: 12
-estimated_files: 3
-skills_used: []
----
-
-# T02: Seed acceptance-ready job data
-
-Create a seed script that prepares a richer acceptance fixture (job, correspondence, saved package, follow-up readiness) using live API calls.
-- Why: current DB has only 1 low-signal job; acceptance rerun needs actionable overview + workspace state.
-- Steps:
-  1) Write `scripts/s06-acceptance-data.sh` (bash, executable) that requires `AUTH_TOKEN` env; uses `scripts/s06-preflight.sh` first, then POSTs to `/api/jobapplications` (or PUT existing ID) to create a job with saved package fields, correspondence entry, reminder/follow-up signals, and notes.
-  2) Add curl helpers for adding correspondence (`/api/correspondence/{jobId}` or equivalent), saving package material, and setting workflow/readiness if needed; use deterministic titles so rerun is idempotent (update if exists).
-  3) Emit a short summary of created/updated IDs so the acceptance run can target them; avoid logging token.
-  4) Document any manual token retrieval step in script comments.
-- Failure Modes (Q5): missing AUTH_TOKEN → fail with guidance; 401/403 → explain token issue; 5xx → print response and fail; malformed response → show body and fail.
-- Load Profile (Q6): few API calls; minimal DB impact.
-- Negative Tests (Q7): run without AUTH_TOKEN (expect failure); rerun twice (should succeed idempotently); simulate 401 by bad token (expect clear message).
-- Must-haves: script seeds at least one job with saved package + correspondence + follow-up readiness; outputs job id for UAT; uses preflight.
-- Verification: `bash scripts/s06-acceptance-data.sh`
-
-## Inputs
-
-- ``scripts/s06-preflight.sh``
-- ``README.md``
-- ``JobTrackerApi/Controllers/JobApplicationsController.cs``
-- ``JobTrackerApi/Controllers/CorrespondenceController.cs``
-
-## Expected Output
-
-- ``scripts/s06-acceptance-data.sh``
-- ``README.md``
-
-## Verification
-
-bash scripts/s06-acceptance-data.sh
-
-## Observability Impact
-
-Provides seed summary output (job id, correspondence count) to inspect readiness; failures surface via script exit and printed API responses.

.gsd/milestones/M001/slices/S06/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S06
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T02: Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S06/tasks/T02-VERIFY.json

@@ -1,26 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T02",
-  "unitId": "M001/S06/T02",
-  "timestamp": 1774598990903,
-  "passed": false,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "bash scripts/s06-acceptance-data.sh",
-      "exitCode": 1,
-      "durationMs": 9,
-      "verdict": "fail"
-    }
-  ],
-  "retryAttempt": 1,
-  "maxRetries": 2,
-  "runtimeErrors": [
-    {
-      "source": "bg-shell",
-      "severity": "crash",
-      "message": "[jobtracker-api] exitCode=131 errors: A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/pi/.dotnet'.; Failed to run as a self-contained app.",
-      "blocking": true
-    }
-  ]
-}

.gsd/milestones/M001/slices/S06/tasks/T03-PLAN.md

@@ -1,41 +0,0 @@
----
-estimated_steps: 12
-estimated_files: 5
-skills_used: []
----
-
-# T03: Run integrated acceptance and capture evidence
-
-Execute the live acceptance loop and record results as an artifact for S07/UAT handoff.
-- Why: prove the `/jobs → workspace → reminders/dashboard → follow-up/manual-send boundary` loop runs in the live stack after stabilization and seeding.
-- Steps:
-  1) Create `scripts/s06-acceptance-run.sh` to orchestrate: ensure backend running, run preflight + seed scripts, then run existing automated regressions most relevant to the loop (e.g., `end-to-end-trust-loop.test.tsx`) and capture outputs.
-  2) Perform a guided browser run (can use agent-browser/Playwright) hitting /jobs, /reminders, /dashboard, opening the seeded job workspace, inspecting Tailored CV, Correspondence (linked-thread status), Follow-up draft manual-send boundary; note Gmail continuity if blocked.
-  3) Write findings and screenshots/links into `docs/s06-acceptance-run.md` (what passed, what blocked, manual-send boundary observation, Gmail continuity status). Call out any gaps explicitly.
-  4) Ensure commands avoid leaking tokens; artifacts redact secrets.
-- Failure Modes (Q5): backend not running → script stops after preflight; tests fail → record failure in artifact; browser step blocked by auth → document and include auth instructions.
-- Load Profile (Q6): single-user flows; test runner CPU-bound but acceptable.
-- Negative Tests (Q7): note expected failure if Gmail remains unconfigured; ensure manual-send boundary not auto-triggered during run.
-- Must-haves: acceptance-run script exists; artifact populated with live results; manual-send boundary explicitly observed; Gmail continuity status recorded (even if blocked).
-- Verification: `bash scripts/s06-acceptance-run.sh` && `test -s docs/s06-acceptance-run.md`
-
-## Inputs
-
-- ``scripts/s06-preflight.sh``
-- ``scripts/s06-acceptance-data.sh``
-- ``job-tracker-ui/src/end-to-end-trust-loop.test.tsx``
-- ``job-tracker-ui/src/components/JobDetailsDialog.tsx``
-- ``job-tracker-ui/src/components/Correspondence.tsx``
-
-## Expected Output
-
-- ``scripts/s06-acceptance-run.sh``
-- ``docs/s06-acceptance-run.md``
-
-## Verification
-
-bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md
-
-## Observability Impact
-
-Orchestrated run logs preflight/seed/test results; artifact captures UI observations incl. manual-send boundary and Gmail continuity. Scripts surface failures with exit codes and summarized outputs.

.gsd/milestones/M001/slices/S06/tasks/T03-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T03
-parent: S06
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T03: Added a repeatable live acceptance runner and recorded real S06 browser evidence for the manual-send boundary and daily loop.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S06/tasks/T03-VERIFY.json

@@ -1,22 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T03",
-  "unitId": "M001/S06/T03",
-  "timestamp": 1774599867411,
-  "passed": true,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "bash scripts/s06-acceptance-run.sh",
-      "exitCode": 0,
-      "durationMs": 5549,
-      "verdict": "pass"
-    },
-    {
-      "command": "test -s docs/s06-acceptance-run.md",
-      "exitCode": 0,
-      "durationMs": 5,
-      "verdict": "pass"
-    }
-  ]
-}

.gsd/milestones/M001/slices/S07/S07-PLAN.md

@@ -1,15 +0,0 @@
-# S07: Daily-loop UAT artifact closure
-
-**Goal:** Publish the executed daily-loop UAT closure artifact proving one seeded job stays coherent across /jobs, the job workspace, /reminders, and /dashboard using the existing S06 acceptance runner.
-**Demo:** After this: TBD
-
-## Tasks
-- [x] **T01: Added docs/s07-uat.md to close S07 with imported acceptance-run evidence for the seeded daily-loop job.** — 
-  - Files: docs/s07-uat.md, docs/s06-acceptance-run.md
-  - Verify: test -s docs/s07-uat.md && grep -q "S06 Acceptance Backend Engineer" docs/s07-uat.md
-- [x] **T02: Re-ran the acceptance flow and refreshed the S07 UAT closure with current browser evidence, manual-send-boundary proof, and the Gmail continuity limitation.** — 
-  - Files: scripts/s06-preflight.sh, scripts/s06-acceptance-run.sh, docs/s06-acceptance-run.md, docs/s07-uat.md
-  - Verify: bash scripts/s06-preflight.sh && bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md && grep -q "manual-send boundary" docs/s07-uat.md
-- [x] **T03: Re-ran the focused daily-loop UI regressions, repaired the local CRA dependency state, and recorded the passing deterministic coverage in docs/s07-uat.md.** — 
-  - Files: job-tracker-ui/src/daily-control-loop.test.tsx, job-tracker-ui/src/workflow-trust-signals.test.tsx, docs/s07-uat.md
-  - Verify: CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx && grep -q "UI regression results" docs/s07-uat.md

.gsd/milestones/M001/slices/S07/S07-RESEARCH.md

@@ -1,122 +0,0 @@
-# S07 Research — Daily-loop UAT artifact closure
-
-## Summary
-
-This is **light/targeted** work, not a new subsystem. S06 already built the hard part: a repeatable localhost preflight + seed + acceptance runner, a deterministic acceptance fixture, and a live evidence doc at `docs/s06-acceptance-run.md`. S07’s missing artifact is the **planner-facing research artifact for this slice**, and the product-facing gap is narrower: convert the existing live rerun evidence into a durable **executed daily-loop UAT closure artifact** that explicitly proves one seeded job behaves coherently across `/jobs`, workspace entry, `/reminders`, and `/dashboard`.
-
-The codebase already has the acceptance data and most of the evidence:
-
-- `scripts/s06-acceptance-data.sh` seeds the deterministic fixture (`S06 Acceptance Labs` / `S06 Acceptance Backend Engineer`) through the live API and prints the expected workflow/readiness/reminder outputs.
-- `scripts/s06-acceptance-run.sh` runs preflight + seeding + one focused UI regression and rewrites the generated section of `docs/s06-acceptance-run.md` while **preserving** the guided browser section between `<!-- acceptance-run:browser:start -->` markers.
-- `docs/s06-acceptance-run.md` already contains the real browser observations, debug-bundle paths, trace path, timeline path, and the explicit manual-send / Gmail-continuity limitations from the latest live run.
-- `job-tracker-ui/src/daily-control-loop.test.tsx` and `job-tracker-ui/src/workflow-trust-signals.test.tsx` already encode the cross-surface contract that the same workflow signal should route `/jobs`, `/dashboard`, and `/reminders` into the same workspace semantics.
-
-So the natural S07 move is **not** to invent new acceptance data or new routing logic. It is to package the existing live run into the milestone’s final UAT closure shape and make the evidence chain easy to rerun and audit.
-
-## Requirement Focus
-
-Active requirements this slice supports:
-
-- **R008** — keep follow-up/reply assistance manual. S06 already captured the live manual-send proof; S07 must preserve that evidence in the final UAT closure artifact and avoid weakening the claim.
-- **R009** — keep the loop individual-first. The seeded fixture and the `/jobs -> workspace -> /reminders -> /dashboard` proof are all single-job, single-user checks; S07 should keep the UAT narrative framed around one person managing one role end to end.
-
-Validated requirements this slice is effectively re-demonstrating in executed-UAT form:
-
-- **R005 / R006 / R007 / R010** — the same job must appear and behave coherently across the overview surfaces and the individual workspace.
-
-## Skills Discovered
-
-Installed skills already directly relevant; no additional skill install is needed.
-
-- `agent-browser` — relevant for the executed browser/UAT pass. Two rules matter here:
-  - **navigate → snapshot → interact → re-snapshot** after DOM/navigation changes, because refs become stale after page changes.
-  - use explicit verification/diff evidence rather than prose-only confirmation.
-- `test` — relevant because S07 should continue to anchor the closure artifact to the existing focused UI regressions instead of expanding scope to a broad suite.
-- `react-best-practices` / `aspnet-core` exist, but S07 does not look like a React or backend architecture change first; it is mostly artifact/evidence closure on top of established behavior.
-
-## Recommendation
-
-Treat S07 as an **artifact-closure slice**, not a feature slice.
-
-Build/prove in this order:
-
-1. **Reuse the S06 acceptance fixture and runner as the source of truth.** Do not create a second seeded job, second seed script, or second acceptance data contract.
-2. **Add or refresh one final S07-owned UAT artifact** that references the latest executed run and records the exact browser evidence for:
-   - `/jobs` row signals
-   - workspace entry for that same job
-   - `/reminders` visibility and action routing
-   - `/dashboard` visibility/analytics presence
-   - manual-send boundary still holding
-   - Gmail continuity status reported honestly
-3. **Keep the shell-generated/live-browser split.** `scripts/s06-acceptance-run.sh` already has a good seam: generated shell summary vs preserved guided-browser section. Reuse that pattern instead of hand-editing a monolithic markdown file.
-4. **Lean on the existing focused UI tests as regression proof**, then use browser assertions/debug artifacts for the final live executed proof.
-
-The simplest successful version of S07 is likely one of these:
-
-- extend the existing S06 artifact flow so the executed browser observations become the final S07/UAT closure evidence, or
-- create a small S07-specific wrapper/doc that imports the current run metadata from `docs/s06-acceptance-run.md` and adds a final closure-oriented summary without duplicating the seeding/runtime logic.
-
-## Implementation Landscape
-
-### Files that already matter
-
-- `docs/s06-acceptance-run.md`
-  - Current live evidence artifact.
-  - Already contains the exact observations S07 needs: `/jobs`, workspace, `/reminders`, `/dashboard`, trace/timeline/debug paths, manual-send proof, and the honest Gmail limitation.
-  - Important detail: it is partially generated and partially hand-preserved.
-
-- `scripts/s06-acceptance-run.sh`
-  - Orchestrates preflight, seed, focused UI regression, and doc refresh.
-  - Preserves the browser-observation block between `<!-- acceptance-run:browser:start -->` markers.
-  - Natural seam if S07 wants a rerunnable final artifact instead of a one-off markdown edit.
-
-- `scripts/s06-acceptance-data.sh`
-  - Owns the deterministic fixture values and the expected follow-up/readiness state.
-  - If S07 references concrete labels or expected reminder badges, those should come from here rather than being duplicated by hand.
-
-- `.gsd/milestones/M001/slices/S06/S06-UAT.md`
-  - Already defines the manual test cases and pass criteria for the live acceptance rerun.
-  - Good source material for a final “executed results” closure artifact, but it is still a test-plan style document, not the final closure proof itself.
-
-- `job-tracker-ui/src/daily-control-loop.test.tsx`
-  - Best compact contract test for this slice’s user-facing claim.
-  - Proves `/jobs`, `/dashboard`, and `/reminders` route into the shared workspace flow.
-
-- `job-tracker-ui/src/workflow-trust-signals.test.tsx`
-  - Lower-level routing/readiness contract proof.
-  - Especially useful if S07 work changes route/query-param handling or the wording of action buttons.
-
-### Natural seams for task breakdown
-
-1. **Artifact-shape task**
-   - Decide whether S07 owns a new doc or reuses `docs/s06-acceptance-run.md` as the canonical executed artifact.
-   - Keep the generated/manual split if touching the runner.
-
-2. **Browser-evidence task**
-   - Re-run the live browser flow and capture explicit assertions/screenshots/debug bundles for the four overview/workspace surfaces.
-   - Record the same job identity consistently across all surfaces.
-
-3. **Regression/verification task**
-   - Re-run the focused frontend tests and the acceptance runner so the final artifact is backed by both live execution and deterministic regression output.
-
-## Constraints / Gotchas
-
-- **Do not over-claim Gmail continuity.** S06 explicitly recorded that seeded correspondence was visible but `POST /api/gmail/refresh-linked-threads` did not fire in the local run. S07 should preserve that honesty unless the environment actually exposes connected Gmail state.
-- **Do not break the deterministic fixture.** `scripts/s06-acceptance-data.sh` depends on backdated `followUpAt` and correspondence timestamps to keep the fixture in `follow-up` / `Waiting 14d` state.
-- **Do not replace the manual-send proof with looser prose.** The strongest current evidence is concrete network behavior: `GET .../followup-draft` seen, no `POST .../send-followup` during draft review/regeneration.
-- **Avoid duplicating fixture constants.** Company/job labels, dates, and expected reminder state already live in the seed script and UAT doc.
-
-## Verification
-
-Minimum verification stack for S07 planning/execution:
-
-- `bash scripts/s06-preflight.sh`
-- `bash scripts/s06-acceptance-run.sh`
-- `test -s docs/s06-acceptance-run.md`
-- from `job-tracker-ui/`: `CI=true npm test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx`
-
-For the live browser part, prefer explicit assertions/evidence capture over prose-only checks. The final executed artifact should point to screenshot/debug-bundle/trace/timeline outputs and state exactly which surface each artifact proves.
-
-## Planner Takeaway
-
-This slice should be planned as **documentation/evidence closure on top of S06’s existing live-run machinery**. The risky work is already done. The planner should avoid new backend or UI feature work unless the rerun shows a real gap. The likely deliverable is a small, deterministic extension of the current acceptance-run artifact flow that turns S06’s live observations into the final S07 executed UAT closure for the daily loop.

.gsd/milestones/M001/slices/S07/S07-SUMMARY.md

@@ -1,105 +0,0 @@
----
-id: S07
-parent: M001
-milestone: M001
-provides:
-  - A slice-level UAT closure artifact that downstream readers can trust without re-reading all task logs.
-  - A stable evidence seam between the S06 acceptance runner and human-readable daily-loop closure summary.
-  - A concrete record that the manual-send boundary held in the live localhost pass while Gmail continuity remained an explicit limitation.
-requires:
-  - slice: S06
-    provides: repeatable preflight, acceptance-data seeding, and canonical live acceptance artifacts for the localhost stack
-  - slice: S05
-    provides: the shared workflow-signal contract and focused trust-loop regressions that S07 re-used as deterministic proof
-affects:
-  - M002/S01
-key_files:
-  - docs/s06-acceptance-run.md
-  - docs/s07-uat.md
-  - .gsd/PROJECT.md
-  - .gsd/KNOWLEDGE.md
-  - .gsd/DECISIONS.md
-key_decisions:
-  - D016: keep `docs/s06-acceptance-run.md` as the canonical execution log and use S07 closure artifacts to summarize/import the proof instead of duplicating raw runner output.
-  - Verify the R008 manual-send boundary in this build via visible draft controls plus authenticated `GET /api/jobapplications/3/followup-draft` and absence of `POST /api/jobapplications/3/send-followup` during the observed browser pass.
-  - Record Gmail continuity as a live-environment limitation when linked-thread refresh evidence is not actually surfaced, rather than implying a pass from seeded correspondence alone.
-patterns_established:
-  - Use a generated-runner-artifact + human closure summary seam: the runner owns raw evidence, while the slice summary compresses what downstream readers need to know.
-  - Anchor cross-surface UAT to one seeded job identity so `/jobs`, workspace, `/reminders`, and `/dashboard` can be checked as one coherent object instead of four independent screenshots.
-  - Pair live browser acceptance evidence with focused deterministic regressions before claiming daily-loop closure.
-observability_surfaces:
-  - `scripts/s06-preflight.sh` auth/config reachability gate
-  - `scripts/s06-acceptance-run.sh` runner output rendered into `docs/s06-acceptance-run.md`
-  - Acceptance shell logs under `docs/artifacts/s06-acceptance/logs/`
-  - Browser trace, timeline, and per-surface debug bundles linked from `docs/s07-uat.md`
-  - Focused UI regression command: `CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx`
-drill_down_paths:
-  - .gsd/milestones/M001/slices/S07/tasks/T01-SUMMARY.md
-  - .gsd/milestones/M001/slices/S07/tasks/T02-SUMMARY.md
-  - .gsd/milestones/M001/slices/S07/tasks/T03-SUMMARY.md
-duration: ""
-verification_result: passed
-completed_at: 2026-03-27T08:59:47.615Z
-blocker_discovered: false
----
-
-# S07: Daily-loop UAT artifact closure
-
-**Closed M001’s daily-loop proof with an executed UAT artifact that traces the seeded acceptance job coherently across /jobs, the job workspace, /reminders, and /dashboard while preserving the manual-send boundary and honestly recording the live Gmail-continuity gap.**
-
-## What Happened
-
-S07 compressed the S06 live acceptance rerun into a downstream-friendly closure artifact instead of leaving the milestone dependent on scattered task logs. The slice established `docs/s06-acceptance-run.md` as the canonical execution record and treated the S07 closure material as an imported-evidence summary: one seeded job (`S06 Acceptance Labs` / `S06 Acceptance Backend Engineer`) is the same object across `/jobs`, the workspace, `/reminders`, and `/dashboard`, with artifact links back to the runner logs, trace, timeline, and page-specific debug bundles. The work also refreshed the closure with current browser evidence and deterministic regression coverage so the slice proves both the live stack behavior and the encoded UI contract. 
-
-The executed flow showed the seeded row on `/jobs` with the expected trust badges, opened the real workspace for that same record, preserved the saved tailored CV and seeded correspondence message, surfaced the same job on `/reminders` with the expected follow-up date/state, and kept `/dashboard` counters and top-company activity aligned with the same seed data. The manual-send boundary remained intact: the follow-up UI exposed separate `Copy Draft` and `Send And Log Email` actions, an authenticated `GET /api/jobapplications/3/followup-draft` returned draft content, and no `POST /api/jobapplications/3/send-followup` request was triggered during the observed browser pass. S07 intentionally did not over-claim Gmail continuity: the correspondence history was visible, but a connected Gmail continuity banner/refresh was not observed in the localhost pass, so the closure records that as a limitation rather than a success. 
-
-S07 also preserved the deterministic guardrail around the daily loop. The focused React suites (`src/daily-control-loop.test.tsx` and `src/workflow-trust-signals.test.tsx`) remain the encoded cross-surface contract for the same overview/workspace semantics, and the slice documents that future reruns must not claim closure if those suites fail. This gives downstream slices a clear dependency summary: use the S06 runner for fresh live evidence, use the S07 closure artifact for compressed interpretation, and treat Gmail-connected continuity as an environment-dependent follow-up proof rather than something this local pass retired.
-
-### Operational Readiness (Q8)
-- **Health signal:** `bash scripts/s06-preflight.sh` reaches `/api/auth/config` and returns the expected auth-limited partial pass; `bash scripts/s06-acceptance-run.sh` finishes pass and refreshes `docs/s06-acceptance-run.md`; the focused UI regression pair passes with `2/2` suites and `6/6` tests.
-- **Failure signal:** API not listening on `http://localhost:5202`, acceptance runner failing to seed/update the S06 fixture, the seeded job no longer matching across `/jobs`/workspace/`/reminders`/`/dashboard`, or any observed `POST /api/jobapplications/{id}/send-followup` during passive draft review.
-- **Recovery procedure:** start the local API and UI, rerun `scripts/s06-preflight.sh`, rerun `scripts/s06-acceptance-run.sh`, repair `job-tracker-ui` dependencies with `npm --prefix job-tracker-ui install` if `react-scripts` is missing, then rerun the focused regression command before claiming closure again.
-- **Monitoring gaps:** the localhost run still lacks a real Gmail-connected refresh proof, and the acceptance pass relies on artifact review rather than a dedicated machine-checked assertion for linked-thread refresh visibility.
-
-## Verification
-
-Slice-level verification passed in the target worktree. I reran `bash scripts/s06-preflight.sh && bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md && grep -q 'manual-send boundary' docs/s07-uat.md`, which passed and refreshed the canonical acceptance artifact with a successful runner result. I also reran `CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx && grep -q 'UI regression results' docs/s07-uat.md`, which passed with `2 passed, 2 total` suites and `6 passed, 6 total` tests. The live evidence set confirms the seeded job remains coherent across `/jobs`, workspace, `/reminders`, and `/dashboard`, that the manual-send boundary holds, and that Gmail continuity is still explicitly documented as a limitation in this environment.
-
-## Requirements Advanced
-
-- R005 — Added executed UAT evidence showing the seeded job row remains coherent from `/jobs` into the workspace rather than relying only on prior focused tests.
-- R006 — Added executed UAT evidence that `/reminders` and `/dashboard` still expose the same seeded job/activity state proven in the live localhost stack.
-- R008 — Re-proved the manual-send boundary in the live acceptance pass by observing only draft preparation behavior, a successful follow-up draft GET, and no send-followup POST during passive review.
-- R010 — Closed the daily-loop artifact gap by tying one seeded job’s state together across `/jobs`, workspace, `/reminders`, and `/dashboard` with current runner/browser evidence.
-
-## Requirements Validated
-
-None.
-
-## New Requirements Surfaced
-
-None.
-
-## Requirements Invalidated or Re-scoped
-
-None.
-
-## Deviations
-
-The slice depended on the S06 live environment being up; the backend was not listening when verification began, so the local API/UI stack had to be brought back up before the acceptance rerun. The focused CRA regression command is also sensitive to install state in this worktree, so the slice documents dependency repair guidance instead of assuming tests always start cleanly.
-
-## Known Limitations
-
-This localhost pass still does not prove Gmail-connected linked-thread refresh in a truly configured Gmail session; it only proves the seeded correspondence remains visible and that the limitation is recorded honestly. The focused UI regression output still includes stable React Router future-flag warnings, which are non-blocking but noisy.
-
-## Follow-ups
-
-If milestone validation requires a live Gmail-continuity proof rather than an explicitly recorded limitation, rerun the S06 acceptance flow in an environment with a genuinely connected Gmail session and capture linked-thread refresh evidence in the same cross-surface artifact seam.
-
-## Files Created/Modified
-
-- `docs/s06-acceptance-run.md` — Refreshed the canonical live acceptance artifact with the latest successful rerun metadata and browser observations.
-- `docs/s07-uat.md` — Updated the imported-evidence closure document with seeded-job identity, cross-surface proof, manual-send boundary wording, Gmail continuity limitation, regression results, and artifact links.
-- `.gsd/PROJECT.md` — Updated current-state narrative to reflect M001 completion through S07 and the resulting daily-loop UAT closure.
-- `.gsd/KNOWLEDGE.md` — Recorded the non-obvious follow-up-draft verification technique for proving the manual-send boundary when the tab does not emit a fresh captured request.
-- `.gsd/DECISIONS.md` — Appended D016 documenting the S07 evidence-seam decision.

.gsd/milestones/M001/slices/S07/S07-UAT.md

@@ -1,68 +0,0 @@
-# S07: Daily-loop UAT artifact closure — UAT
-
-**Milestone:** M001
-**Written:** 2026-03-27T08:59:47.615Z
-
-# S07 UAT — Daily-loop UAT artifact closure
-
-## Preconditions
-- Local API is running at `http://localhost:5202` and UI is running at `http://localhost:3000`.
-- The S06 acceptance fixture can be seeded via `bash scripts/s06-acceptance-run.sh`.
-- Seeded job identity exists after rerun: `S06 Acceptance Labs` / `S06 Acceptance Backend Engineer`.
-- Browser session can reach the authenticated localhost UI used by the S06 acceptance flow.
-
-## Test Case 1 — `/jobs` anchors the seeded daily-loop job
-1. Run `bash scripts/s06-preflight.sh`.
-   - Expected: script reaches `/api/auth/config`; auth-limited partial pass is acceptable, but API reachability must succeed.
-2. Run `bash scripts/s06-acceptance-run.sh`.
-   - Expected: `docs/s06-acceptance-run.md` is refreshed and reports overall runner result `pass`.
-3. Open `/jobs` in the authenticated UI session.
-   - Expected: the table contains `S06 Acceptance Labs • S06 Acceptance Backend Engineer`.
-4. Inspect the seeded row state.
-   - Expected: the row shows `Follow up`, `CV ready`, and `Waiting` badges.
-5. Open the row’s workspace entry.
-   - Expected: the real job workspace opens for the same seeded job, not a disconnected placeholder.
-
-## Test Case 2 — Workspace preserves the same job identity and real seeded content
-1. From the seeded workspace, inspect the tailored CV area.
-   - Expected: saved tailored CV content is present and begins with `Saved acceptance tailored CV highlighting ASP.NET Core delivery, workflow trust signals...`.
-2. Switch to the correspondence view.
-   - Expected: the seeded recruiter-thread message `Backend Engineer follow-up` is visible for the same job.
-3. Record Gmail continuity status honestly.
-   - Expected: if a linked-thread continuity banner/refresh signal is visible, capture it explicitly; if not, record Gmail continuity as not proven in this run rather than marking it passed.
-
-## Test Case 3 — `/reminders` and `/dashboard` reflect the same seeded state
-1. Navigate to `/reminders`.
-   - Expected: the seeded job appears under `Needs Follow-up`.
-2. Inspect reminder state.
-   - Expected: `Follow up`, `Waiting 14d`, and `Follow-up: 10/03/2026` are all visible for the seeded job.
-3. Navigate to `/dashboard`.
-   - Expected: dashboard counters show `Active applications = 2`, `Applied (30 days) = 2`, and `Responses logged = 1`.
-4. Inspect company activity.
-   - Expected: `Top companies by activity` includes `S06 Acceptance Labs`.
-5. Reload `/dashboard` after clearing diagnostics.
-   - Expected: no browser console errors and no failed network requests are observed in the clean dashboard pass.
-
-## Test Case 4 — Follow-up drafting stays on the manual side of the boundary
-1. Open the seeded job workspace follow-up draft area.
-   - Expected: separate `Copy Draft` and `Send And Log Email` controls are visible.
-2. Verify draft retrieval without sending.
-   - Expected: the live draft content is present in the workspace; if the tab does not emit a fresh captured request, confirm `GET /api/jobapplications/3/followup-draft` succeeds from the authenticated browser context.
-3. Observe browser/network activity during passive draft review.
-   - Expected: no `POST /api/jobapplications/3/send-followup` request occurs unless the explicit send action is clicked.
-4. Record the outcome.
-   - Expected: UAT notes state that the system prepared the draft but did not auto-send email.
-
-## Test Case 5 — Deterministic regression guardrail for closure
-1. Run `CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx`.
-   - Expected: both suites pass (`2 passed, 2 total`) and all six tests pass.
-2. Confirm `docs/s07-uat.md` contains a `UI regression results` section.
-   - Expected: the doc records the command, pass result, and the rule that closure must not be claimed if this regression pair fails on rerun.
-
-## Edge Cases / Failure Handling
-- If `scripts/s06-preflight.sh` cannot reach `http://localhost:5202/api`, stop and recover the local API before claiming closure.
-- If `scripts/s06-acceptance-run.sh` fails to seed/update the fixture or reports a non-pass result, do not claim S07 closure; capture the runner logs and fix the blocker first.
-- If the focused UI regression command fails with `react-scripts: not found`, run `npm --prefix job-tracker-ui install` and retry before treating the slice as regressed.
-- If the seeded job is visible but Gmail-linked continuity is not, record that as a limitation; do not silently convert seeded correspondence visibility into a Gmail-sync pass.
-- If any passive browser observation shows a `send-followup` POST without the explicit send action, treat it as a blocker against R008 and fail the UAT closure.
-

.gsd/milestones/M001/slices/S07/tasks/T01-PLAN.md

@@ -1,22 +0,0 @@
----
-estimated_steps: 1
-estimated_files: 2
-skills_used: []
----
-
-# T01: Shape S07 UAT doc around acceptance-run evidence seam
-
-Why: Give S07 its own UAT closure document that reuses the S06 acceptance runner as the evidence source and frames the daily-loop proof across /jobs → workspace → reminders → dashboard while preserving the manual-send and Gmail-continuity notes. Do: review docs/s06-acceptance-run.md and scripts/s06-acceptance-run.sh for generated/manual seams; create docs/s07-uat.md with sections for surfaces, job identity, manual-send boundary evidence, Gmail continuity status, rerun commands, and artifact links; note that evidence is imported from the acceptance run rather than duplicated. Done when docs/s07-uat.md exists with the sections above and references the seeded job (S06 Acceptance Backend Engineer) and acceptance artifact.
-
-## Inputs
-
-- ``docs/s06-acceptance-run.md``
-- ``scripts/s06-acceptance-run.sh``
-
-## Expected Output
-
-- ``docs/s07-uat.md``
-
-## Verification
-
-test -s docs/s07-uat.md && grep -q "S06 Acceptance Backend Engineer" docs/s07-uat.md

.gsd/milestones/M001/slices/S07/tasks/T01-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T01
-parent: S07
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T01: Added docs/s07-uat.md to close S07 with imported acceptance-run evidence for the seeded daily-loop job.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S07/tasks/T01-VERIFY.json

@@ -1,22 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T01",
-  "unitId": "M001/S07/T01",
-  "timestamp": 1774600599706,
-  "passed": true,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "test -s docs/s07-uat.md",
-      "exitCode": 0,
-      "durationMs": 5,
-      "verdict": "pass"
-    },
-    {
-      "command": "grep -q \"S06 Acceptance Backend Engineer\" docs/s07-uat.md",
-      "exitCode": 0,
-      "durationMs": 5,
-      "verdict": "pass"
-    }
-  ]
-}

.gsd/milestones/M001/slices/S07/tasks/T02-PLAN.md

@@ -1,25 +0,0 @@
----
-estimated_steps: 1
-estimated_files: 4
-skills_used: []
----
-
-# T02: Re-run acceptance flow and record browser evidence + manual-send boundary
-
-Why: Refresh the live acceptance evidence and capture the manual-send boundary plus Gmail continuity status for S07. Do: run `bash scripts/s06-preflight.sh`; run `bash scripts/s06-acceptance-run.sh` (with AUTH_TOKEN if needed) to regenerate docs/s06-acceptance-run.md and artifacts; confirm the seeded job identity and cross-surface observations, and extract artifact links (logs, trace, timeline, screenshots/debug bundle); update docs/s07-uat.md with the latest evidence, explicitly stating the manual-send boundary (GET followup-draft seen, no POST send-followup) and the Gmail continuity limitation observed in this run. Failure modes: backend/API down → note preflight failure; auth/token missing → use runner fallback guidance; browser/assertion failures → capture log paths; malformed artifact paths → rerun and repair links. Negative checks: ensure acceptance run did not issue send-followup, and Gmail refresh absence is recorded, not implied passing. Done when both docs are updated with current run evidence and links.
-
-## Inputs
-
-- ``scripts/s06-preflight.sh``
-- ``scripts/s06-acceptance-run.sh``
-- ``docs/s07-uat.md``
-
-## Expected Output
-
-- ``docs/s06-acceptance-run.md``
-- ``docs/s07-uat.md``
-- ``docs/artifacts/s06-acceptance/logs/``
-
-## Verification
-
-bash scripts/s06-preflight.sh && bash scripts/s06-acceptance-run.sh && test -s docs/s06-acceptance-run.md && grep -q "manual-send boundary" docs/s07-uat.md

.gsd/milestones/M001/slices/S07/tasks/T02-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T02
-parent: S07
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.778Z
-blocker_discovered: false
----
-
-# T02: Re-ran the acceptance flow and refreshed the S07 UAT closure with current browser evidence, manual-send-boundary proof, and the Gmail continuity limitation.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S07/tasks/T02-VERIFY.json

@@ -1,34 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T02",
-  "unitId": "M001/S07/T02",
-  "timestamp": 1774601486400,
-  "passed": true,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "bash scripts/s06-preflight.sh",
-      "exitCode": 0,
-      "durationMs": 136,
-      "verdict": "pass"
-    },
-    {
-      "command": "bash scripts/s06-acceptance-run.sh",
-      "exitCode": 0,
-      "durationMs": 5532,
-      "verdict": "pass"
-    },
-    {
-      "command": "test -s docs/s06-acceptance-run.md",
-      "exitCode": 0,
-      "durationMs": 5,
-      "verdict": "pass"
-    },
-    {
-      "command": "grep -q \"manual-send boundary\" docs/s07-uat.md",
-      "exitCode": 0,
-      "durationMs": 6,
-      "verdict": "pass"
-    }
-  ]
-}

.gsd/milestones/M001/slices/S07/tasks/T03-PLAN.md

@@ -1,23 +0,0 @@
----
-estimated_steps: 1
-estimated_files: 3
-skills_used: []
----
-
-# T03: Re-run focused daily-loop UI tests and fold results into UAT doc
-
-Why: Anchor the S07 UAT closure to the existing focused UI regressions that encode the cross-surface contract. Do: from job-tracker-ui/, run `CI=true npm test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx`; capture pass/fail summaries and note any flake; update docs/s07-uat.md with the test command, date/time, and results so the UAT doc cites both live run evidence and deterministic regression coverage. Failure modes: missing node modules → npm install; test failures → log failing test output and blockers in the doc. Negative tests: ensure the doc notes what happens if these tests fail (e.g., stop claiming UAT closure). Done when tests pass and docs/s07-uat.md reflects the run and command used.
-
-## Inputs
-
-- ``job-tracker-ui/src/daily-control-loop.test.tsx``
-- ``job-tracker-ui/src/workflow-trust-signals.test.tsx``
-- ``docs/s07-uat.md``
-
-## Expected Output
-
-- ``docs/s07-uat.md``
-
-## Verification
-
-CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx && grep -q "UI regression results" docs/s07-uat.md

.gsd/milestones/M001/slices/S07/tasks/T03-SUMMARY.md

@@ -1,22 +0,0 @@
----
-id: T03
-parent: S07
-milestone: M001
-provides: []
-requires: []
-affects: []
-key_files: []
-key_decisions: []
-patterns_established: []
-drill_down_paths: []
-observability_surfaces: []
-duration: ""
-verification_result: ""
-completed_at: 2026-03-28T22:02:57.779Z
-blocker_discovered: false
----
-
-# T03: Re-ran the focused daily-loop UI regressions, repaired the local CRA dependency state, and recorded the passing deterministic coverage in docs/s07-uat.md.
-
-## What Happened
-No summary recorded.

.gsd/milestones/M001/slices/S07/tasks/T03-VERIFY.json

@@ -1,22 +0,0 @@
-{
-  "schemaVersion": 1,
-  "taskId": "T03",
-  "unitId": "M001/S07/T03",
-  "timestamp": 1774601726342,
-  "passed": true,
-  "discoverySource": "task-plan",
-  "checks": [
-    {
-      "command": "CI=true npm --prefix job-tracker-ui test -- --runInBand --watch=false src/daily-control-loop.test.tsx src/workflow-trust-signals.test.tsx",
-      "exitCode": 0,
-      "durationMs": 5631,
-      "verdict": "pass"
-    },
-    {
-      "command": "grep -q \"UI regression results\" docs/s07-uat.md",
-      "exitCode": 0,
-      "durationMs": 6,
-      "verdict": "pass"
-    }
-  ]
-}

.gsd/milestones/M002/M002-CONTEXT-DRAFT.md

@@ -1,42 +0,0 @@
----
-depends_on: [M001]
----
-
-# M002: Tracking control center — Context Draft
-
-**Gathered:** 2026-03-24
-**Status:** Draft — needs milestone-specific discussion before planning
-
-## Seed from broader discussion
-
-The product should feel first like a tracker and follow-up system, not just a collection of AI tools. The agreed navigation hierarchy is job table first, then follow-up/dashboard, then individual job workspace. That means M002 is the milestone where the tracking and control-center surfaces likely get stronger after M001 proves Gmail import quality and AI draft quality.
-
-## Intended milestone role
-
-M002 likely expands the app from “good Gmail + good drafts” into a clearer job-search control center for an individual user. The likely emphasis is better table/dashboard/follow-up workflow, better visibility into what needs action, and stronger continuity through the life of each application.
-
-## Likely capabilities
-
-- stronger table views and status clarity
-- better follow-up/dashboard action surfacing
-- tighter tracking continuity across manual updates and imported correspondence
-- clearer operating rhythm for daily use
-- likely analytics/pattern visibility only where it directly improves decision-making
-
-## Constraints already known
-
-- individual-first product shape remains in force
-- no auto-send or auto-apply behavior
-- job discovery still happens outside the app
-- table → follow-up/dashboard → job workspace remains the intended daily navigation hierarchy unless usage disproves it
-
-## What this milestone unlocks
-
-A version of the product that feels more like the user’s daily control center and less like a set of helpful but disconnected screens.
-
-## Open questions for future discussion
-
-- How much of M002 should be action clarity versus analytics polish?
-- Which table/dashboard views feel most lacking in current use?
-- Should saved views, stronger filtering, or timeline/history clarity be core in this milestone?
-- What specific “I know what to do next” experience should the dashboard deliver every morning?

.gsd/milestones/M003/M003-CONTEXT-DRAFT.md

@@ -1,41 +0,0 @@
----
-depends_on: [M001, M002]
----
-
-# M003: Deeper inbox-aware assistance — Context Draft
-
-**Gathered:** 2026-03-24
-**Status:** Draft — needs milestone-specific discussion before planning
-
-## Seed from broader discussion
-
-After the first Gmail improvements, there is likely room to deepen inbox-aware assistance and correspondence-driven help. This should still remain assistive rather than autonomous, and it should continue to support an individual user’s job-search workflow instead of turning into broad automation for its own sake.
-
-## Intended milestone role
-
-M003 likely extends the correspondence and assistance layer beyond the first trust milestone. The likely focus is richer inbox awareness, better use of message context over time, and additional AI help that stays grounded in real application history.
-
-## Likely capabilities
-
-- richer message/thread understanding after import
-- better context assembly from accumulated correspondence
-- broader assistance around replies, follow-up strategy, and ongoing job-specific communication
-- selective expansion of AI coaching only where it strengthens the core user loop
-
-## Constraints already known
-
-- no auto-send and no auto-apply remain hard boundaries
-- assistance should stay grounded in imported job/application/correspondence context
-- the product is still for one person managing their own search
-- the app should not drift into generic chatbot behavior
-
-## What this milestone unlocks
-
-A more aware assistant that understands the state of an application thread over time and can help the user respond more intelligently without taking control away.
-
-## Open questions for future discussion
-
-- What additional inbox-aware behavior is actually high value after M001?
-- How much strategic coaching belongs here versus later?
-- Which parts of correspondence history should influence drafting most?
-- What privacy or trust surfaces need to become more visible as the assistant becomes more context-aware?

.gsd/milestones/M004/M004-CONTEXT-DRAFT.md

@@ -1,41 +0,0 @@
----
-depends_on: [M001, M002, M003]
----
-
-# M004: Trust, launchability, and hardening — Context Draft
-
-**Gathered:** 2026-03-24
-**Status:** Draft — needs milestone-specific discussion before planning
-
-## Seed from broader discussion
-
-The app already has meaningful breadth: auth, Gmail integration, AI service integration, drafting, reminders, imports, dashboards, and admin/system pages. Once the core workflow is strong enough, the next need is likely hardening: making the product clearer, safer, more diagnosable, and easier to live with over time.
-
-## Intended milestone role
-
-M004 likely focuses on trust, clarity, and operational hardening after the core workflow is proven. This includes the quality of validation, clarity of failure modes, performance, launch readiness, and operational confidence for a product used repeatedly during a real job search.
-
-## Likely capabilities
-
-- clearer validation and failure visibility
-- UX and terminology cleanup where the product still feels messy or inconsistent
-- performance and reliability improvements around key surfaces
-- stronger operational/admin clarity for self-hosted or deployed use
-- final trust surfaces around how AI and integrations behave
-
-## Constraints already known
-
-- the product must preserve manual control over outbound communication
-- hardening should support the individual-first workflow rather than introducing enterprise complexity
-- changes should build on the existing architecture rather than force a platform rewrite
-
-## What this milestone unlocks
-
-A product that not only has the right workflow, but also feels solid, comprehensible, and trustworthy enough for sustained daily use and future expansion.
-
-## Open questions for future discussion
-
-- Which hardening gaps are most painful in actual use by the time this milestone arrives?
-- What launchability bar matters for this project: self-hosted personal use, broader deployment, or something in between?
-- Which trust/diagnostic surfaces are most important for AI-assisted correspondence and drafting?
-- What level of polish is necessary before the product feels genuinely finished rather than just feature-complete?

Data/JobTrackerContext.cs

@@ -18,6 +18,8 @@ namespace JobTrackerApi.Data
     public DbSet<Correspondence> Correspondences => Set<Correspondence>();
     public DbSet<GmailConnection> GmailConnections => Set<GmailConnection>();
     public DbSet<GmailReviewDecision> GmailReviewDecisions => Set<GmailReviewDecision>();
+    public DbSet<MicrosoftGraphConnection> MicrosoftGraphConnections => Set<MicrosoftGraphConnection>();
+    public DbSet<ImapConnection> ImapConnections => Set<ImapConnection>();
     public DbSet<Attachment> Attachments => Set<Attachment>();
     public DbSet<RuleSettings> RuleSettings => Set<RuleSettings>();
     public DbSet<UserRuleSettings> UserRuleSettings => Set<UserRuleSettings>();
@@ -55,6 +57,20 @@ namespace JobTrackerApi.Data
         modelBuilder.Entity<JobApplication>()
             .HasIndex(j => j.OwnerUserId);
 
+        // Owner-prefixed composite indexes for the tenant-scoped hot paths. Every
+        // JobApplication query is scoped by the OwnerUserId global filter first, then
+        // filtered by IsDeleted (list/board/stats/analytics) or FollowUpAt (reminders).
+        // Status is intentionally excluded from the index because Pomelo maps the
+        // unbounded string column to longtext, which MariaDB cannot index without a
+        // prefix length. The actual index DDL is applied idempotently in
+        // StartupInitializationExtensions (this repo provisions schema via that
+        // reconciler, not via the EF ModelSnapshot, which is stale).
+        modelBuilder.Entity<JobApplication>()
+            .HasIndex(j => new { j.OwnerUserId, j.IsDeleted });
+
+        modelBuilder.Entity<JobApplication>()
+            .HasIndex(j => new { j.OwnerUserId, j.FollowUpAt });
+
         modelBuilder.Entity<Company>()
             .HasIndex(c => c.OwnerUserId);
 

JobTrackerApi.Tests/AttachmentFlagsRecomputeTests.cs

@@ -0,0 +1,111 @@
+using JobTrackerApi.Controllers;
+using JobTrackerApi.Data;
+using JobTrackerApi.Models;
+using JobTrackerApi.Services;
+using JobTrackerApi.Tests.TestSupport;
+using Microsoft.EntityFrameworkCore;
+using Microsoft.Extensions.Configuration;
+using Microsoft.Extensions.Hosting;
+using Microsoft.AspNetCore.Http;
+using Microsoft.AspNetCore.Mvc;
+using Moq;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+// JobApplication.HasResume/HasCoverLetter/HasPortfolio/HasOtherAttachment are derived from
+// Attachment rows (backlog Wave 3), not manually settable. These tests exercise the single
+// place they're written: AttachmentsController's Purpose-change and Delete paths.
+public sealed class AttachmentFlagsRecomputeTests
+{
+    [Fact]
+    public async Task Changing_purpose_to_resume_sets_HasResume()
+    {
+        await using var db = TestHostFactory.CreateInMemoryDb();
+        var (job, attachment) = await SeedJobWithAttachmentAsync(db, purpose: "other");
+        var controller = CreateController(db);
+
+        var result = await controller.Rename(attachment.Id, new AttachmentsController.UpdateAttachmentRequest(null, "resume", null), CancellationToken.None);
+
+        Assert.IsType<NoContentResult>(result);
+        var updated = await db.JobApplications.SingleAsync(j => j.Id == job.Id);
+        Assert.True(updated.HasResume);
+        Assert.True(updated.HasOtherAttachment == false);
+    }
+
+    [Fact]
+    public async Task Deleting_the_only_resume_attachment_clears_HasResume()
+    {
+        await using var db = TestHostFactory.CreateInMemoryDb();
+        var (job, attachment) = await SeedJobWithAttachmentAsync(db, purpose: "resume");
+        var controller = CreateController(db);
+
+        var result = await controller.Delete(attachment.Id, CancellationToken.None);
+
+        Assert.IsType<NoContentResult>(result);
+        var updated = await db.JobApplications.SingleAsync(j => j.Id == job.Id);
+        Assert.False(updated.HasResume);
+    }
+
+    [Fact]
+    public async Task Attachment_with_case_study_purpose_counts_as_other()
+    {
+        await using var db = TestHostFactory.CreateInMemoryDb();
+        var (job, attachment) = await SeedJobWithAttachmentAsync(db, purpose: "resume");
+        var controller = CreateController(db);
+
+        await controller.Rename(attachment.Id, new AttachmentsController.UpdateAttachmentRequest(null, "case-study", null), CancellationToken.None);
+
+        var updated = await db.JobApplications.SingleAsync(j => j.Id == job.Id);
+        Assert.False(updated.HasResume);
+        Assert.True(updated.HasOtherAttachment);
+    }
+
+    private static async Task<(JobApplication Job, Attachment Attachment)> SeedJobWithAttachmentAsync(JobTrackerContext db, string purpose)
+    {
+        var company = new Company { Name = "Acme", OwnerUserId = "user-1" };
+        db.Companies.Add(company);
+        await db.SaveChangesAsync();
+
+        var job = new JobApplication { JobTitle = "Backend Developer", CompanyId = company.Id, OwnerUserId = "user-1" };
+        db.JobApplications.Add(job);
+        await db.SaveChangesAsync();
+
+        var attachment = new Attachment
+        {
+            JobApplicationId = job.Id,
+            FileName = "file.pdf",
+            FilePath = Path.Combine(Path.GetTempPath(), $"jobtracker-attachment-test-{Guid.NewGuid():N}.pdf"),
+            FileType = "application/pdf",
+            FileSize = 100,
+            Purpose = purpose,
+        };
+        db.Attachments.Add(attachment);
+        await db.SaveChangesAsync();
+
+        job.HasResume = purpose == "resume";
+        job.HasOtherAttachment = purpose is not ("resume" or "cover-letter" or "portfolio");
+        await db.SaveChangesAsync();
+
+        return (job, attachment);
+    }
+
+    private static AttachmentsController CreateController(JobTrackerContext db)
+    {
+        var tempRoot = Path.Combine(Path.GetTempPath(), $"jobtracker-attachments-tests-{Guid.NewGuid():N}");
+        Directory.CreateDirectory(tempRoot);
+
+        var config = new ConfigurationBuilder()
+            .AddInMemoryCollection(new Dictionary<string, string?> { ["Data:Root"] = tempRoot })
+            .Build();
+
+        var env = new Mock<IHostEnvironment>();
+        env.SetupGet(x => x.ContentRootPath).Returns(tempRoot);
+        var paths = new AppPaths(config, env.Object);
+
+        return new AttachmentsController(paths, db)
+        {
+            ControllerContext = new ControllerContext { HttpContext = new DefaultHttpContext() }
+        };
+    }
+}

JobTrackerApi.Tests/AuthAndSystemControllerTests.cs

@@ -25,7 +25,7 @@ public sealed class AuthAndSystemControllerTests
         userManager.Setup(x => x.GetUserAsync(It.IsAny<System.Security.Claims.ClaimsPrincipal>())).ReturnsAsync(user);
         userManager.Setup(x => x.UpdateAsync(user)).ReturnsAsync(IdentityResult.Success);
 
-        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), NullLogger<AuthController>.Instance);
+        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), Mock.Of<IMicrosoftTokenValidator>(), NullLogger<AuthController>.Instance);
 
         var result = await controller.UpdateProfile(new AuthController.UpdateProfileRequest(" new@example.com ", " newuser ", " Ada ", " Lovelace ", " Ada L. ", null, null));
 
@@ -50,7 +50,7 @@ public sealed class AuthAndSystemControllerTests
             .Setup(x => x.SendAsync(user.Email!, It.IsAny<string>(), It.IsAny<string>(), It.IsAny<CancellationToken>()))
             .ThrowsAsync(new InvalidOperationException("SMTP unavailable"));
 
-        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), emailSender.Object, Mock.Of<IGoogleTokenValidator>(), NullLogger<AuthController>.Instance)
+        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), emailSender.Object, Mock.Of<IGoogleTokenValidator>(), Mock.Of<IMicrosoftTokenValidator>(), NullLogger<AuthController>.Instance)
         {
             ControllerContext = new ControllerContext
             {
@@ -91,7 +91,7 @@ public sealed class AuthAndSystemControllerTests
             .Setup(x => x.ValidateAsync("google-token", It.IsAny<CancellationToken>()))
             .ReturnsAsync(new GoogleTokenPrincipal("google-subject", "dj@cesnimda.co.uk", true, "Dan", "Jones", "Dan Jones"));
 
-        var controller = new AuthController(BuildConfig(), userManager.Object, tokenService.Object, Mock.Of<IAppEmailSender>(), googleValidator.Object, NullLogger<AuthController>.Instance)
+        var controller = new AuthController(BuildConfig(), userManager.Object, tokenService.Object, Mock.Of<IAppEmailSender>(), googleValidator.Object, Mock.Of<IMicrosoftTokenValidator>(), NullLogger<AuthController>.Instance)
         {
             ControllerContext = new ControllerContext
             {
@@ -110,6 +110,76 @@ public sealed class AuthAndSystemControllerTests
         Assert.NotNull(user.GoogleLinkedAt);
     }
 
+    [Fact]
+    public async Task Exchange_microsoft_token_creates_new_user_when_registration_allowed()
+    {
+        var userManager = CreateUserManager();
+        userManager.Setup(x => x.Users).Returns(new TestAsyncEnumerable<ApplicationUser>(new List<ApplicationUser>()));
+        userManager.Setup(x => x.FindByEmailAsync("new.hire@example.com")).ReturnsAsync((ApplicationUser?)null);
+        ApplicationUser? created = null;
+        userManager
+            .Setup(x => x.CreateAsync(It.IsAny<ApplicationUser>()))
+            .Callback<ApplicationUser>(u => created = u)
+            .ReturnsAsync(IdentityResult.Success);
+        userManager.Setup(x => x.UpdateAsync(It.IsAny<ApplicationUser>())).ReturnsAsync(IdentityResult.Success);
+
+        var tokenService = new Mock<ITokenService>();
+        tokenService.Setup(x => x.CreateAccessTokenAsync(It.IsAny<ApplicationUser>(), It.IsAny<CancellationToken>())).ReturnsAsync("app-token");
+
+        var microsoftValidator = new Mock<IMicrosoftTokenValidator>();
+        microsoftValidator
+            .Setup(x => x.ValidateAsync("microsoft-token", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new MicrosoftTokenPrincipal("ms-subject", "new.hire@example.com", true, "New", "Hire", "New Hire"));
+
+        var config = new ConfigurationBuilder()
+            .AddInMemoryCollection(new Dictionary<string, string?> { ["Auth:AllowRegistration"] = "true" })
+            .Build();
+
+        var controller = new AuthController(config, userManager.Object, tokenService.Object, Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), microsoftValidator.Object, NullLogger<AuthController>.Instance)
+        {
+            ControllerContext = new ControllerContext
+            {
+                HttpContext = new DefaultHttpContext()
+            }
+        };
+
+        var result = await controller.ExchangeMicrosoftToken(new AuthController.MicrosoftTokenRequest("microsoft-token"), CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result.Result);
+        var payload = Assert.IsType<AuthController.AuthSessionResult>(ok.Value);
+        Assert.True(payload.Authenticated);
+        Assert.Equal("microsoft", payload.Provider);
+        Assert.NotNull(created);
+        Assert.Equal("new.hire@example.com", created!.Email);
+        Assert.Equal("ms-subject", created.MicrosoftSubject);
+    }
+
+    [Fact]
+    public async Task Exchange_microsoft_token_rejects_unmatched_account_when_registration_disabled()
+    {
+        var userManager = CreateUserManager();
+        userManager.Setup(x => x.Users).Returns(new TestAsyncEnumerable<ApplicationUser>(new List<ApplicationUser>()));
+        userManager.Setup(x => x.FindByEmailAsync("nobody@example.com")).ReturnsAsync((ApplicationUser?)null);
+
+        var microsoftValidator = new Mock<IMicrosoftTokenValidator>();
+        microsoftValidator
+            .Setup(x => x.ValidateAsync("microsoft-token", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new MicrosoftTokenPrincipal("ms-subject", "nobody@example.com", true, null, null, null));
+
+        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), microsoftValidator.Object, NullLogger<AuthController>.Instance)
+        {
+            ControllerContext = new ControllerContext
+            {
+                HttpContext = new DefaultHttpContext()
+            }
+        };
+
+        var result = await controller.ExchangeMicrosoftToken(new AuthController.MicrosoftTokenRequest("microsoft-token"), CancellationToken.None);
+
+        Assert.IsType<UnauthorizedObjectResult>(result.Result);
+        userManager.Verify(x => x.CreateAsync(It.IsAny<ApplicationUser>()), Times.Never);
+    }
+
     [Fact]
     public void Me_result_includes_google_link_details_for_local_users()
     {

JobTrackerApi.Tests/ClientErrorsControllerTests.cs

@@ -51,7 +51,7 @@ public sealed class ClientErrorsControllerTests
         var userManager = TestHostFactory.CreateUserManager();
         userManager.Setup(x => x.GetUserAsync(It.IsAny<ClaimsPrincipal>())).ReturnsAsync(user);
 
-        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), Mock.Of<ILogger<AuthController>>())
+        var controller = new AuthController(BuildConfig(), userManager.Object, Mock.Of<ITokenService>(), Mock.Of<IAppEmailSender>(), Mock.Of<IGoogleTokenValidator>(), Mock.Of<IMicrosoftTokenValidator>(), Mock.Of<ILogger<AuthController>>())
         {
             ControllerContext = new ControllerContext
             {

JobTrackerApi.Tests/CorrespondenceControllerTests.cs

@@ -0,0 +1,35 @@
+using JobTrackerApi.Controllers;
+using JobTrackerApi.Data;
+using JobTrackerApi.Models;
+using JobTrackerApi.Tests.TestSupport;
+using Microsoft.AspNetCore.Mvc;
+using Microsoft.EntityFrameworkCore;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+public sealed class CorrespondenceControllerTests
+{
+    [Fact]
+    public async Task Create_tags_manually_entered_correspondence_with_manual_provider()
+    {
+        await using var db = TestHostFactory.CreateInMemoryDb();
+        var company = new Company { Name = "Acme", OwnerUserId = "user-1" };
+        db.Companies.Add(company);
+        await db.SaveChangesAsync();
+
+        var job = new JobApplication { JobTitle = "Backend Developer", CompanyId = company.Id, OwnerUserId = "user-1" };
+        db.JobApplications.Add(job);
+        await db.SaveChangesAsync();
+
+        var controller = new CorrespondenceController(db);
+        var request = new CorrespondenceController.CreateCorrespondenceRequestV2(
+            job.Id, "Me", "Called to follow up.", "Follow-up call", "Call", null, "outbound", null, null, null, null, null, null);
+
+        var result = await controller.Create(request, CancellationToken.None);
+
+        Assert.IsType<Correspondence>(((CreatedAtActionResult)result.Result!).Value);
+        var stored = await db.Correspondences.SingleAsync();
+        Assert.Equal("manual", stored.Provider);
+    }
+}

JobTrackerApi.Tests/GmailControllerTests.cs

@@ -288,6 +288,7 @@ public sealed class GmailControllerTests
 
         var storedMessages = await db.Correspondences.Where(message => message.JobApplicationId == job.Id).ToListAsync();
         Assert.Single(storedMessages);
+        Assert.Equal("gmail", storedMessages[0].Provider);
         gmail.Verify(service => service.GetMessageAsync("user-1", "msg-1", It.IsAny<CancellationToken>()), Times.Once);
     }
 

JobTrackerApi.Tests/ImapControllerTests.cs

@@ -0,0 +1,131 @@
+using System.Security.Claims;
+using JobTrackerApi.Controllers;
+using JobTrackerApi.Models;
+using JobTrackerApi.Services;
+using Microsoft.AspNetCore.Http;
+using Microsoft.AspNetCore.Mvc;
+using Moq;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+public sealed class ImapControllerTests
+{
+    [Fact]
+    public async Task Status_returns_connection_fields_for_connected_account()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new ImapConnection
+            {
+                OwnerUserId = "user-1",
+                Host = "imap.example.test",
+                Port = 993,
+                UseSsl = true,
+                Username = "user@example.test",
+                ConnectedAt = DateTimeOffset.UtcNow.AddDays(-1),
+                LastSyncStatus = "ok"
+            });
+
+        var controller = CreateController(imap.Object, "user-1");
+        var result = await controller.Status(CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result.Result);
+        var payload = Assert.IsType<ImapController.ImapConnectionStatusDto>(ok.Value);
+        Assert.True(payload.Connected);
+        Assert.Equal("imap.example.test", payload.Host);
+        Assert.Equal(993, payload.Port);
+        Assert.Equal("user@example.test", payload.Username);
+        Assert.Equal("ok", payload.LastSyncStatus);
+    }
+
+    [Fact]
+    public async Task Status_reports_not_connected_when_no_connection_exists()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync((ImapConnection?)null);
+
+        var controller = CreateController(imap.Object, "user-1");
+        var result = await controller.Status(CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result.Result);
+        var payload = Assert.IsType<ImapController.ImapConnectionStatusDto>(ok.Value);
+        Assert.False(payload.Connected);
+    }
+
+    [Theory]
+    [InlineData("", 993, "user", "pass", "Host is required.")]
+    [InlineData("imap.example.test", 0, "user", "pass", "Valid port is required.")]
+    [InlineData("imap.example.test", 993, "", "pass", "Username is required.")]
+    [InlineData("imap.example.test", 993, "user", "", "Password is required.")]
+    public async Task Connect_rejects_missing_fields(string host, int port, string username, string password, string expectedError)
+    {
+        var imap = new Mock<IImapService>(MockBehavior.Strict);
+        var controller = CreateController(imap.Object, "user-1");
+
+        var result = await controller.Connect(new ImapController.ImapConnectRequest(host, port, true, username, password), CancellationToken.None);
+
+        var badRequest = Assert.IsType<BadRequestObjectResult>(result);
+        Assert.Equal(expectedError, badRequest.Value);
+    }
+
+    [Fact]
+    public async Task Connect_returns_bad_request_when_service_rejects_credentials()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.ConnectAsync("user-1", "imap.example.test", 993, true, "user", "wrong", It.IsAny<CancellationToken>()))
+            .ThrowsAsync(new InvalidOperationException("IMAP authentication failed: bad credentials"));
+
+        var controller = CreateController(imap.Object, "user-1");
+        var result = await controller.Connect(new ImapController.ImapConnectRequest("imap.example.test", 993, true, "user", "wrong"), CancellationToken.None);
+
+        var badRequest = Assert.IsType<BadRequestObjectResult>(result);
+        Assert.Contains("authentication failed", (string)badRequest.Value!);
+    }
+
+    [Fact]
+    public async Task Connect_succeeds_and_returns_username()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.ConnectAsync("user-1", "imap.example.test", 993, true, "user@example.test", "correct", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new ImapConnectResult("user@example.test"));
+
+        var controller = CreateController(imap.Object, "user-1");
+        var result = await controller.Connect(new ImapController.ImapConnectRequest("imap.example.test", 993, true, "user@example.test", "correct"), CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result);
+        var username = ok.Value!.GetType().GetProperty("username")!.GetValue(ok.Value) as string;
+        Assert.Equal("user@example.test", username);
+    }
+
+    [Fact]
+    public async Task Disconnect_calls_service_for_authenticated_user()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.DisconnectAsync("user-1", It.IsAny<CancellationToken>())).Returns(Task.CompletedTask);
+
+        var controller = CreateController(imap.Object, "user-1");
+        var result = await controller.Disconnect(CancellationToken.None);
+
+        Assert.IsType<NoContentResult>(result);
+        imap.Verify(service => service.DisconnectAsync("user-1", It.IsAny<CancellationToken>()), Times.Once);
+    }
+
+    private static ImapController CreateController(IImapService imap, string userId)
+    {
+        return new ImapController(imap)
+        {
+            ControllerContext = new ControllerContext
+            {
+                HttpContext = new DefaultHttpContext
+                {
+                    User = new ClaimsPrincipal(new ClaimsIdentity(new[]
+                    {
+                        new Claim(ClaimTypes.NameIdentifier, userId)
+                    }, "test"))
+                }
+            }
+        };
+    }
+}

JobTrackerApi.Tests/ImapProviderTests.cs

@@ -0,0 +1,82 @@
+using JobTrackerApi.Services;
+using JobTrackerApi.Services.EmailProviders;
+using Moq;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+public sealed class ImapProviderTests
+{
+    [Fact]
+    public void ProviderKey_is_imap()
+    {
+        var provider = new ImapProvider(Mock.Of<IImapService>());
+        Assert.Equal("imap", provider.ProviderKey);
+    }
+
+    [Fact]
+    public async Task GetConnectionAsync_maps_username_onto_neutral_shape()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new JobTrackerApi.Models.ImapConnection { OwnerUserId = "user-1", Username = "user@example.test" });
+
+        var provider = new ImapProvider(imap.Object);
+        var connection = await provider.GetConnectionAsync("user-1", CancellationToken.None);
+
+        Assert.NotNull(connection);
+        Assert.Equal("imap", connection!.ProviderKey);
+        Assert.Equal("user@example.test", connection.Address);
+    }
+
+    [Fact]
+    public async Task GetConnectionAsync_returns_null_when_not_connected()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync((JobTrackerApi.Models.ImapConnection?)null);
+
+        var provider = new ImapProvider(imap.Object);
+        var connection = await provider.GetConnectionAsync("user-1", CancellationToken.None);
+
+        Assert.Null(connection);
+    }
+
+    [Fact]
+    public async Task SearchAsync_maps_thread_key_onto_neutral_thread_id()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.ListMessagesAsync("user-1", "recruiter", 10, It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new List<ImapMessageSummary>
+            {
+                new("42", "root-msg-id@example.test", "Interview", "them@company.test", "me@example.test", DateTimeOffset.UtcNow, "snippet")
+            });
+
+        var provider = new ImapProvider(imap.Object);
+        var results = await provider.SearchAsync("user-1", "recruiter", 10, CancellationToken.None);
+
+        var summary = Assert.Single(results);
+        Assert.Equal("42", summary.Id);
+        Assert.Equal("root-msg-id@example.test", summary.ThreadId);
+        Assert.Equal("Interview", summary.Subject);
+    }
+
+    [Fact]
+    public async Task GetMessageAsync_maps_content_id_onto_neutral_external_attachment_id()
+    {
+        var imap = new Mock<IImapService>();
+        imap.Setup(service => service.GetMessageAsync("user-1", "42", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new ImapMessageDetail(
+                "42", "root-msg-id@example.test", "Offer", "them@company.test", "me@example.test", DateTimeOffset.UtcNow, "snippet",
+                "body text", "<p>body</p>", new List<string>(),
+                new List<ImapMessageAttachment> { new("resume.pdf", "application/pdf", 1024, "cid-1", false) }));
+
+        var provider = new ImapProvider(imap.Object);
+        var detail = await provider.GetMessageAsync("user-1", "42", CancellationToken.None);
+
+        Assert.Equal("root-msg-id@example.test", detail.ThreadId);
+        var attachment = Assert.Single(detail.Attachments);
+        Assert.Equal("resume.pdf", attachment.FileName);
+        Assert.Equal("cid-1", attachment.ExternalAttachmentId);
+    }
+}

JobTrackerApi.Tests/ImapServiceSsrfGuardTests.cs

@@ -0,0 +1,49 @@
+using System.IO;
+using JobTrackerApi.Services;
+using JobTrackerApi.Tests.TestSupport;
+using Microsoft.AspNetCore.DataProtection;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+// Regression coverage for the SSRF guard in ImapService: an authenticated user's IMAP "connect"
+// target must not be usable to probe loopback/RFC1918/link-local/cloud-metadata addresses.
+public sealed class ImapServiceSsrfGuardTests
+{
+    [Theory]
+    [InlineData("127.0.0.1")]
+    [InlineData("localhost")]
+    [InlineData("10.0.0.5")]
+    [InlineData("172.16.0.5")]
+    [InlineData("192.168.1.5")]
+    [InlineData("169.254.169.254")] // cloud metadata endpoint
+    public async Task ConnectAsync_rejects_internal_and_metadata_hosts(string host)
+    {
+        var service = CreateService();
+
+        var ex = await Assert.ThrowsAsync<InvalidOperationException>(() =>
+            service.ConnectAsync("user-1", host, 993, true, "user", "password", CancellationToken.None));
+
+        // Message must not leak connect-vs-auth distinction (that's the oracle this guard closes).
+        Assert.DoesNotContain("resolve", ex.Message, StringComparison.OrdinalIgnoreCase);
+        Assert.DoesNotContain("reachable", ex.Message, StringComparison.OrdinalIgnoreCase);
+    }
+
+    [Fact]
+    public async Task ConnectAsync_rejects_unresolvable_host_without_leaking_dns_detail()
+    {
+        var service = CreateService();
+
+        var ex = await Assert.ThrowsAsync<InvalidOperationException>(() =>
+            service.ConnectAsync("user-1", "this-host-does-not-exist.invalid", 993, true, "user", "password", CancellationToken.None));
+
+        Assert.Equal("Could not connect to that IMAP server with the given credentials. Check host, port, and password.", ex.Message);
+    }
+
+    private static ImapService CreateService()
+    {
+        var db = TestHostFactory.CreateInMemoryDb();
+        var protectionProvider = DataProtectionProvider.Create(new DirectoryInfo(Path.Combine(Path.GetTempPath(), $"jobtracker-tests-{Guid.NewGuid():N}")));
+        return new ImapService(db, protectionProvider);
+    }
+}

JobTrackerApi.Tests/JobApplicationsEndpointBehaviorTests.cs

@@ -202,11 +202,7 @@ public sealed class JobApplicationsEndpointBehaviorTests
             CoverLetterText: null,
             JobUrl: null,
             DateApplied: null,
-            FeedbackRequestedAt: null,
-            HasResume: null,
-            HasCoverLetter: null,
-            HasPortfolio: null,
-            HasOtherAttachment: null);
+            FeedbackRequestedAt: null);
 
         var result = await controller.Create(request, CancellationToken.None);
 
@@ -255,10 +251,6 @@ public sealed class JobApplicationsEndpointBehaviorTests
             SalaryPeriod: "fortnight",
             NextAction: null,
             FollowUpAt: null,
-            HasResume: null,
-            HasCoverLetter: null,
-            HasPortfolio: null,
-            HasOtherAttachment: null,
             Notes: null,
             Description: null,
             TranslatedDescription: null,

JobTrackerApi.Tests/JobCvMatchServiceTests.cs

@@ -90,6 +90,19 @@ public sealed class JobCvMatchServiceTests
         Assert.Equal(0, result.MatchedCount);
     }
 
+    [Fact]
+    public void Curated_tag_matches_synonym_spelling_in_cv()
+    {
+        // Job posting says "Kubernetes"; CV only says "K8s" -- same skill, different spelling.
+        var result = _service.Evaluate(
+            jobTitle: "Platform Engineer",
+            jobText: "Deep Kubernetes experience required for our platform team.",
+            cvSections: Sections(("Skills", "K8s, Terraform, Helm")));
+
+        Assert.Contains("Kubernetes", result.MatchedKeywords);
+        Assert.DoesNotContain("Kubernetes", result.MissingKeywords);
+    }
+
     [Fact]
     public void Title_keywords_are_weighted_and_missing_ones_rank_first()
     {

JobTrackerApi.Tests/MicrosoftGraphControllerTests.cs

@@ -0,0 +1,157 @@
+using System.Security.Claims;
+using JobTrackerApi.Controllers;
+using JobTrackerApi.Data;
+using JobTrackerApi.Models;
+using JobTrackerApi.Services;
+using JobTrackerApi.Tests.TestSupport;
+using Microsoft.AspNetCore.Http;
+using Microsoft.AspNetCore.Mvc;
+using Microsoft.Extensions.Configuration;
+using Moq;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+public sealed class MicrosoftGraphControllerTests
+{
+    [Fact]
+    public async Task Status_returns_sync_state_fields_for_connected_account()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new MicrosoftGraphConnection
+            {
+                OwnerUserId = "user-1",
+                MailAddress = "user@outlook.test",
+                ConnectedAt = DateTimeOffset.UtcNow.AddDays(-2),
+                LastSyncedAt = DateTimeOffset.UtcNow.AddMinutes(-10),
+                LastSyncAttemptedAt = DateTimeOffset.UtcNow.AddMinutes(-5),
+                LastSyncSucceededAt = DateTimeOffset.UtcNow.AddMinutes(-10),
+                LastSyncMode = "list-messages",
+                LastSyncSource = "custom-query",
+                LastSyncStatus = "error",
+                LastSyncError = "Token refresh failed"
+            });
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = await controller.Status(CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result.Result);
+        var payload = Assert.IsType<MicrosoftGraphController.MicrosoftGraphConnectionStatusDto>(ok.Value);
+        Assert.True(payload.Connected);
+        Assert.Equal("user@outlook.test", payload.MailAddress);
+        Assert.Equal("list-messages", payload.LastSyncMode);
+        Assert.Equal("custom-query", payload.LastSyncSource);
+        Assert.Equal("error", payload.LastSyncStatus);
+        Assert.Equal("Token refresh failed", payload.LastSyncError);
+    }
+
+    [Fact]
+    public async Task Status_reports_not_connected_when_no_connection_exists()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync((MicrosoftGraphConnection?)null);
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = await controller.Status(CancellationToken.None);
+
+        var ok = Assert.IsType<OkObjectResult>(result.Result);
+        var payload = Assert.IsType<MicrosoftGraphController.MicrosoftGraphConnectionStatusDto>(ok.Value);
+        Assert.False(payload.Connected);
+        Assert.Null(payload.MailAddress);
+    }
+
+    [Fact]
+    public void ConnectUrl_returns_authorization_url_from_service()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.BuildAuthorizationUrl("user-1", It.IsAny<string>()))
+            .Returns("https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=test");
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = controller.ConnectUrl();
+
+        var ok = Assert.IsType<OkObjectResult>(result);
+        var url = ok.Value!.GetType().GetProperty("url")!.GetValue(ok.Value) as string;
+        Assert.Equal("https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=test", url);
+    }
+
+    [Fact]
+    public async Task Callback_returns_error_html_when_state_is_invalid()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.ConsumeState("bad-state")).Returns((string?)null);
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = await controller.Callback("auth-code", "bad-state", null, CancellationToken.None);
+
+        var content = Assert.IsType<ContentResult>(result);
+        Assert.Contains("no longer valid", content.Content);
+        graph.Verify(service => service.ExchangeCodeAsync(It.IsAny<string>(), It.IsAny<string>(), It.IsAny<string>(), It.IsAny<CancellationToken>()), Times.Never);
+    }
+
+    [Fact]
+    public async Task Callback_returns_error_html_when_provider_returns_error()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>(MockBehavior.Strict);
+        var controller = CreateController(graph.Object, "user-1");
+
+        var result = await controller.Callback(null, null, "access_denied", CancellationToken.None);
+
+        var content = Assert.IsType<ContentResult>(result);
+        Assert.Contains("access_denied", content.Content);
+    }
+
+    [Fact]
+    public async Task Callback_exchanges_code_and_reports_connected_mail_address()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.ConsumeState("good-state")).Returns("user-1");
+        graph.Setup(service => service.ExchangeCodeAsync("user-1", "auth-code", It.IsAny<string>(), It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new MicrosoftGraphOAuthExchangeResult("user@outlook.test"));
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = await controller.Callback("auth-code", "good-state", null, CancellationToken.None);
+
+        var content = Assert.IsType<ContentResult>(result);
+        Assert.Contains("user@outlook.test", content.Content);
+    }
+
+    [Fact]
+    public async Task Disconnect_calls_service_for_authenticated_user()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.DisconnectAsync("user-1", It.IsAny<CancellationToken>())).Returns(Task.CompletedTask);
+
+        var controller = CreateController(graph.Object, "user-1");
+        var result = await controller.Disconnect(CancellationToken.None);
+
+        Assert.IsType<NoContentResult>(result);
+        graph.Verify(service => service.DisconnectAsync("user-1", It.IsAny<CancellationToken>()), Times.Once);
+    }
+
+    private static MicrosoftGraphController CreateController(IMicrosoftGraphOAuthService graph, string userId)
+    {
+        return new MicrosoftGraphController(graph, BuildConfig())
+        {
+            ControllerContext = new ControllerContext
+            {
+                HttpContext = new DefaultHttpContext
+                {
+                    User = new ClaimsPrincipal(new ClaimsIdentity(new[]
+                    {
+                        new Claim(ClaimTypes.NameIdentifier, userId)
+                    }, "test"))
+                }
+            }
+        };
+    }
+
+    private static IConfiguration BuildConfig()
+    {
+        return new ConfigurationBuilder()
+            .AddInMemoryCollection(new Dictionary<string, string?>())
+            .Build();
+    }
+}

JobTrackerApi.Tests/MicrosoftGraphProviderTests.cs

@@ -0,0 +1,82 @@
+using JobTrackerApi.Services;
+using JobTrackerApi.Services.EmailProviders;
+using Moq;
+using Xunit;
+
+namespace JobTrackerApi.Tests;
+
+public sealed class MicrosoftGraphProviderTests
+{
+    [Fact]
+    public void ProviderKey_is_microsoft()
+    {
+        var provider = new MicrosoftGraphProvider(Mock.Of<IMicrosoftGraphOAuthService>());
+        Assert.Equal("microsoft", provider.ProviderKey);
+    }
+
+    [Fact]
+    public async Task GetConnectionAsync_maps_mail_address_onto_neutral_shape()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new JobTrackerApi.Models.MicrosoftGraphConnection { OwnerUserId = "user-1", MailAddress = "user@outlook.test" });
+
+        var provider = new MicrosoftGraphProvider(graph.Object);
+        var connection = await provider.GetConnectionAsync("user-1", CancellationToken.None);
+
+        Assert.NotNull(connection);
+        Assert.Equal("microsoft", connection!.ProviderKey);
+        Assert.Equal("user@outlook.test", connection.Address);
+    }
+
+    [Fact]
+    public async Task GetConnectionAsync_returns_null_when_not_connected()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.GetConnectionAsync("user-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync((JobTrackerApi.Models.MicrosoftGraphConnection?)null);
+
+        var provider = new MicrosoftGraphProvider(graph.Object);
+        var connection = await provider.GetConnectionAsync("user-1", CancellationToken.None);
+
+        Assert.Null(connection);
+    }
+
+    [Fact]
+    public async Task SearchAsync_maps_conversation_id_onto_neutral_thread_id()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.ListMessagesAsync("user-1", "recruiter", 10, It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new List<MicrosoftGraphMessageSummary>
+            {
+                new("msg-1", "conv-1", "Interview", "them@company.test", "me@outlook.test", DateTimeOffset.UtcNow, "snippet")
+            });
+
+        var provider = new MicrosoftGraphProvider(graph.Object);
+        var results = await provider.SearchAsync("user-1", "recruiter", 10, CancellationToken.None);
+
+        var summary = Assert.Single(results);
+        Assert.Equal("msg-1", summary.Id);
+        Assert.Equal("conv-1", summary.ThreadId);
+        Assert.Equal("Interview", summary.Subject);
+    }
+
+    [Fact]
+    public async Task GetMessageAsync_maps_attachment_id_onto_neutral_external_attachment_id()
+    {
+        var graph = new Mock<IMicrosoftGraphOAuthService>();
+        graph.Setup(service => service.GetMessageAsync("user-1", "msg-1", It.IsAny<CancellationToken>()))
+            .ReturnsAsync(new MicrosoftGraphMessageDetail(
+                "msg-1", "conv-1", "Offer", "them@company.test", "me@outlook.test", DateTimeOffset.UtcNow, "snippet",
+                "body text", "<p>body</p>", new List<string> { "Inbox" },
+                new List<MicrosoftGraphMessageAttachment> { new("resume.pdf", "application/pdf", 1024, "graph-att-1", false) }));
+
+        var provider = new MicrosoftGraphProvider(graph.Object);
+        var detail = await provider.GetMessageAsync("user-1", "msg-1", CancellationToken.None);
+
+        Assert.Equal("conv-1", detail.ThreadId);
+        var attachment = Assert.Single(detail.Attachments);
+        Assert.Equal("resume.pdf", attachment.FileName);
+        Assert.Equal("graph-att-1", attachment.ExternalAttachmentId);
+    }
+}