Connor
240 lines
11 KiB
Markdown
240 lines
11 KiB
Markdown
# Requirements
|
||
|
||
This file is the explicit capability and coverage contract for the project.
|
||
|
||
Use it to track what is actively in scope, what has been validated by completed work, what is intentionally deferred, and what is explicitly out of scope.
|
||
|
||
Guidelines:
|
||
- Keep requirements capability-oriented, not a giant feature wishlist.
|
||
- Requirements should be atomic, testable, and stated in plain language.
|
||
- Every **Active** requirement should be mapped to a slice, deferred, blocked with reason, or moved out of scope.
|
||
- Each requirement should have one accountable primary owner and may have supporting slices.
|
||
- Research may suggest requirements, but research does not silently make them binding.
|
||
- Validation means the requirement was actually proven by completed work and verification, not just discussed.
|
||
|
||
## Active
|
||
|
||
### R001 — External job import starts the workflow
|
||
- Class: primary-user-loop
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: This is a hard product-shape requirement, not a convenience feature.
|
||
|
||
### R002 — Gmail import feels smart enough to trust
|
||
- Class: integration
|
||
- Status: active
|
||
- Description: Gmail connection, message retrieval, and message/thread import must help the user pull real correspondence into the right job with materially less manual cleanup.
|
||
- Why it matters: Gmail import is one of the two clearest current weaknesses and a major trust surface for daily use.
|
||
- Source: user
|
||
- Primary owning slice: M001/S01
|
||
- Supporting slices: M001/S03, M001/S05
|
||
- Validation: mapped
|
||
- Notes: Matching quality and import clarity matter more than merely exposing the API surface.
|
||
|
||
### R003 — AI application drafts are materially useful
|
||
- Class: differentiator
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: “A really good AI draft” is an explicit milestone success bar from the discussion.
|
||
|
||
### R004 — Follow-up and reply drafts use real context
|
||
- Class: primary-user-loop
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: The user stays in control of sending; the app provides strong drafts only.
|
||
|
||
### R005 — Job table is the primary daily control surface
|
||
- Class: continuity
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: This should feel like “scan the field” before drilling into one job.
|
||
|
||
### R006 — Follow-up/dashboard surfaces the right urgency
|
||
- Class: continuity
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: The follow-up/dashboard view is the second navigation priority after the table.
|
||
|
||
### R007 — Individual job workspace supports focused execution
|
||
- Class: core-capability
|
||
- Status: active
|
||
- 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: mapped
|
||
- Notes: This is where the product should feel connected instead of scattered.
|
||
|
||
### R008 — Outbound actions remain manual and user-controlled
|
||
- 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: mapped
|
||
- Notes: This is a durable trust constraint across all milestones.
|
||
|
||
### R009 — Product is designed for an individual, not a team workflow
|
||
- 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.
|
||
|
||
### R010 — Tracking continuity survives manual and imported updates
|
||
- Class: continuity
|
||
- Status: active
|
||
- Description: The app must preserve a coherent history across manual status changes, imported Gmail correspondence, reminders, and follow-up work.
|
||
- Why it matters: The product promise is to keep the thread of the job search intact over time.
|
||
- Source: user
|
||
- Primary owning slice: M001/S04
|
||
- Supporting slices: M001/S01, M001/S03, M001/S05
|
||
- Validation: mapped
|
||
- Notes: This is part of what makes the app a tracker and follow-up system, not just a draft generator.
|
||
|
||
## Validated
|
||
|
||
None yet.
|
||
|
||
## Deferred
|
||
|
||
### R011 — Stronger tracking control-center analytics
|
||
- 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 — Broader inbox-aware assistance beyond initial Gmail improvements
|
||
- Class: integration
|
||
- Status: deferred
|
||
- Description: The product 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.
|
||
|
||
### R013 — Richer AI coaching beyond the application/follow-up core
|
||
- 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 — Auto-apply to jobs
|
||
- 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 — Auto-send outbound email or messages
|
||
- 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.
|
||
|
||
### R016 — Recruiter CRM or team collaboration workflows
|
||
- 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 — In-app job discovery replacing job boards
|
||
- 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 | active | M001/S01 | M001/S05 | mapped |
|
||
| R002 | integration | active | M001/S01 | M001/S03, M001/S05 | mapped |
|
||
| R003 | differentiator | active | M001/S02 | M001/S05 | mapped |
|
||
| R004 | primary-user-loop | active | M001/S03 | M001/S01, M001/S02, M001/S05 | mapped |
|
||
| R005 | continuity | active | M001/S04 | M001/S05 | mapped |
|
||
| R006 | continuity | active | M001/S04 | M001/S05 | mapped |
|
||
| R007 | core-capability | active | M001/S03 | M001/S02, M001/S04 | mapped |
|
||
| R008 | constraint | active | M001/S03 | M001/S05 | mapped |
|
||
| R009 | constraint | active | M001/S04 | M002/S01, M004/S01 | mapped |
|
||
| R010 | continuity | active | M001/S04 | M001/S01, M001/S03, M001/S05 | mapped |
|
||
| 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 |
|
||
|
||
## Coverage Summary
|
||
|
||
- Active requirements: 10
|
||
- Mapped to slices: 10
|
||
- Validated: 0
|
||
- Unmapped active requirements: 0
|