Connor
2.2 KiB
2.2 KiB
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/S01 planning | architecture | How S01 will improve Gmail import matching | Add a job-scoped backend Gmail matching contract and persist Gmail thread/message metadata on correspondence instead of relying on client-only scoring | Backend ranking can use owned job, company, recruiter, and prior correspondence context consistently, gives the UI explicit match reasons and duplicate state, and preserves thread continuity for later reply/follow-up slices without changing the no-auto-send boundary. | Yes — if real Gmail usage shows the ranking contract or stored metadata is insufficient | agent |