cesnimda
b176a44627
Active docs/ was stub scaffolding while the real docs sat in docs/_archive/. Restore and correct them, and record the Phase 0 work. - docs/architecture/current.md: verified system map (from archived SYSTEM_OVERVIEW, 9 corrections against code). - docs/research/competitors.md: sourced competitor analysis (from archived PRODUCT_RESEARCH, feature matrix corrected). - docs/decisions/ADR-002-job-application-model.md: the Job/JobApplication split. - docs/application-discovery-report.md, docs/implementation-roadmap.md, docs/phase-0-foundation-report.md, docs/career-workspace-branch-assessment.md. - Remove 10 zero-byte placeholder files that advertised content that never existed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
# Jobbjakt Architecture Evolution
|
|
|
|
## Guiding constraints
|
|
|
|
- Preserve the existing single-master-profile model.
|
|
- Keep job applications and their workflow at the centre of the domain.
|
|
- Make AI providers replaceable and optional.
|
|
- Add SaaS foundations without prematurely building a billing platform or team product.
|
|
- Keep feature slices small while reducing the current controller concentration.
|
|
|
|
## Target boundaries
|
|
|
|
```text
|
|
Web UI
|
|
-> Application APIs
|
|
-> Application workflow domain
|
|
-> Career profile and document domain
|
|
-> Discovery provider adapters
|
|
-> Connected-account adapters
|
|
-> AI provider boundary
|
|
-> Entitlements and usage policy
|
|
```
|
|
|
|
### Career profile and documents
|
|
|
|
`ApplicationUser.ProfileCvStructureJson` remains the canonical master profile during the transition. A later migration may normalize high-change sections (projects and portfolio items) into user-owned tables, but generated CVs and application-specific drafts must remain immutable copies with a profile-version reference.
|
|
|
|
### Discovery
|
|
|
|
Create an `IJobDiscoveryProvider` contract with normalized query and result types. Providers own authentication, source-specific filters, terms-aware attribution, and mapping. The UI and import flow must not know provider payload shapes. Cache public results briefly, do not persist an external job until the user imports it.
|
|
|
|
### AI
|
|
|
|
Extract AI prompts and model transport from controllers behind task-focused interfaces: CV extraction, CV tailoring, draft generation, interview preparation, and summarization. Each request records provider, model, input profile version, job context, and user review state. Local and online providers implement the same boundary.
|
|
|
|
### Entitlements
|
|
|
|
Introduce account-level plan, entitlement, and usage-ledger records before payment integration. Product code checks named capabilities (for example `ai.tailor_cv`, `cv.premium_theme`, `storage.attachments`) rather than payment-provider state. This supports trials, manual access, subscriptions, and future organisation plans.
|
|
|
|
## Incremental engineering work
|
|
|
|
1. Add targeted feature services beside the existing controllers for every touched feature; do not attempt a big-bang controller rewrite.
|
|
2. Replace local-only preferences that affect behaviour with user-owned persisted settings.
|
|
3. Replace the in-memory CV queue with a database-backed work item before horizontal hosting.
|
|
4. Use PostgreSQL for hosted multi-tenant deployment; retain SQLite for self-hosted/single-user deployments.
|
|
5. Add provider health, job processing, AI usage, and entitlement audit telemetry before paid hosting.
|
|
|
|
## Explicit non-goals for the first SaaS release
|
|
|
|
- Teams/organisations and shared candidate data.
|
|
- Auto-apply automation or scraping-proxy infrastructure.
|
|
- A browser-extension marketplace release.
|
|
- A billing-provider integration before commercial policy is decided.
|