jobtrackingapp/.gsd/DECISIONS.md

Decisions Register

#	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