jobtrackingapp/docs/cv-builder-product-teardown.md

# CV Builder Product Teardown — Jobbjakt Internal Review

**Date:** 2026-07-12
**Scope:** Critical product, UX, and technical teardown of the current CV builder and related career features, ahead of the Career Workspace redesign.
**Companions:** `docs/cv-builder-competitor-deep-research.md` (market context) and the CV Builder Architecture Proposal artifact (target design). This document is the honest "as-is" audit both of those build on.
**Stance:** Written as a senior PM + UX designer + architect reviewing before a major redesign. Existing code is treated as evidence, not as precedent. Where something is wrong, it is called wrong.

---

## 1. Current Product Overview

### What the application is today

Jobbjakt is a self-hosted, single-tenant-ish (multi-user with admin) **job application tracker** with strong email intelligence, to which a CV builder has been progressively bolted on. Live at `https://jobs.cesnimda.uk`. Stack: ASP.NET Core 9 + EF Core (SQLite dev / MariaDB prod), Next.js 16 static-export frontend (MUI), FastAPI AI sidecar (Ollama/Gemini/Groq router), Playwright PDF rendering.

**Feature inventory (career-relevant):**

| Area | What exists | Where |
|---|---|---|
| Job tracking | CRUD, kanban pipeline, drag-drop, statuses, reminders, analytics/funnel | `JobApplicationsController` (~2,900 lines), `KanbanBoard`, `DashboardView` |
| Email intelligence | Gmail sync, thread↔job linking, review queue, suggested jobs, status suggestions | `GmailController`, `GmailReviewPage`, `CorrespondenceInboxPage` |
| Master CV | Upload (PDF/text) → parse → normalize → structured profile; rebuild/improve/reprocess; section rewrite | `ProfileCvController` (2,265 lines), `ProfilePage.tsx` |
| Tailored CV | Per-job draft: generate from master + job, edit, preview, PDF export | `JobApplicationsController:2465–2614`, `JobDetailsDialog.tsx` |
| Templates | 6 hardcoded templates (ats-minimal, harvard, auckland, edinburgh, monarch, fjord), curated accent palette, section order, page mode, bullet density | `CvTemplateRenderer` (448 lines), `TailoredCvRenderOptions` |
| Match scoring | CV↔JD keyword match with curated skill-tag synonyms | `JobCvMatchService`, `SkillTagger`, `match-score` endpoint |
| Per-job AI | Interview prep, candidate fit, focus plan, follow-up drafts, application package, readiness | `JobDetailsDialog.tsx` (all crammed into one dialog) |
| AI service | `/summarize`, `/cv/normalize`, `/cv/classify-block`, `/cv/rewrite` with prompt-injection hardening + provider router | `tools/summarizer/app.py` |

### Target user

Implicitly: **the developer himself** — a technically fluent, self-hosting job seeker running an active search. Nothing in the product contradicts this: no onboarding for novices, AI knobs exposed raw (tone/language/target-role fields), extraction "runs" and "reprocess" surfaced in end-user UI, admin pages in the same nav. The recent additions (onboarding checklist, empty states, OAuth signup) are the first genuine gestures toward a second user.

**This is the central product tension:** the backend is built like a multi-user SaaS (Identity, roles, registration, OAuth, per-owner scoping), but the UX is built like a personal tool. The redesign must pick: the Career Workspace vision implies real second users, which means the "developer-as-user" assumptions have to go.

### Current user journey

1. Land → sign in (email/Google/Microsoft) → dashboard.
2. Add jobs manually, via bookmarklet, or via Gmail suggested-jobs.
3. Track through kanban; Gmail sync auto-links correspondence; reminders fire.
4. Separately, on Profile page: upload a CV → extraction pipeline produces structured profile.
5. Inside a job's details dialog (a modal!): generate tailored CV draft → edit in text fields → preview → export PDF.
6. AI extras (interview prep, fit, follow-ups) live as tabs/sections in that same modal.

### Current relationships (the actual object model in practice)

```
ApplicationUser
 ├─ ProfileCvText          (raw CV text — a column on the Identity user row)
 ├─ ProfileCvStructureJson (StructuredCvProfile serialized — also a user column)
 ├─ CvUploadArtifact ──< CvExtractionRun (parser/normalizer/prompt versions, run history)
 └─ JobApplication ──1:1── TailoredCvDraft
                             ├─ TemplateId + RenderOptionsJson  (presentation welded to content)
                             ├─ SummaryJson / SelectedSkillsJson / ExperienceJson / ... (per-section JSON blobs)
                             ├─ CanonicalProfileVersion (staleness pointer to master)
                             └─ Status ("generated" / edited)
Cover letters: DO NOT EXIST as entities. Interview prep etc.: transient AI responses, not persisted as documents.
```

### Current product philosophy (inferred, since none is written down)

- **Tracker-first:** the CV is an attachment to a job application, not a first-class product. The tailored CV lives *inside the job details modal* — the clearest possible statement of the current hierarchy.
- **One master CV, ephemeral derivatives:** exactly one profile per user; tailored drafts are per-job satellites; nothing else is durable.
- **AI as pipeline, not as assistant:** AI does batch transforms (parse this, rewrite that) with exposed machinery, rather than conversational or inline assistance.
- **Provenance-conscious:** field-level confidence/review-state metadata shows real care about "where did this claim come from" — unusually mature for this product stage.

The Career Workspace vision inverts the first two tenets. The last two are worth keeping.

---

## 2. User Experience Review

### New user

**How does a user create their first CV?** They can't, in any meaningful sense — they can only *import* one. `ProfilePage` offers "Upload CV" (parse an existing document). There is no from-scratch path: no guided form, no "add your first job" flow for the profile. A user without an existing CV document is stuck. Every competitor in the research offers from-scratch creation; we are import-only.

**Is onboarding clear?** The new onboarding checklist (add CV / import job / check match) is a good spine, but step one drops the user on a Profile page where the CV feature is a card among password/avatar/email-connection cards. CV building is presented as an *account setting*. That framing is wrong for what is supposed to become the product's centerpiece.

**Critical bug, found during this audit:** [`ProfilePage.tsx:356`](../job-tracker-ui/src/views/ProfilePage.tsx) computes `isLocal = me?.provider === "local"` and disables CV upload/rebuild/improve (among other controls) for OAuth users. The gate was presumably meant for identity fields (can't change password on a Google account) and was blanket-applied to the CV card. **Google/Microsoft users — the exact accounts we just built auto-signup for — get a disabled CV builder.** A Google-first new user's journey dead-ends at step one of the checklist. Must-fix regardless of redesign timing.

**Where do new users get confused?**
- "Reprocess," "Rebuild," "Improve," "Runs" — four adjacent buttons whose distinction (re-run extraction vs. regenerate structure vs. AI-rewrite text vs. view pipeline history) is developer vocabulary. No user knows which to press.
- The structured profile (the actual output of extraction) has no real editing UI — the raw text and the structure are shown, but correcting a mis-parsed date means fighting JSON or re-uploading.
- Nothing explains that the master CV feeds match scores and tailored drafts; the causal chain that makes the product coherent is invisible.

### Existing user

**Editing the CV:** the master CV is edited as *raw text* (`ProfileCvText` in a textarea) with AI rewrite assistance per-section. The structured profile is a *derived artifact* the user can't directly maintain. This is backwards relative to both competitors (structured forms are the primary surface everywhere) and our own architecture proposal. Consequence: every text edit desynchronizes text from structure until a rebuild; the "which is the truth?" question has no good answer today (see §4).

**Creating tailored CVs:** open a job → details modal → tailored CV section → "Generate" → edit. Real problems:
- It's in a **modal**. A document editor competing for space with interview prep, fit analysis, follow-ups, readiness, notes — inside a dialog over the jobs table. No room for the side-by-side JD↔CV tailoring view that the competitor research identified as the killer screen (Teal's core loop).
- Bullets are edited as newline-joined blobs (`splitLines`/`joinLines` in `tailoredCvDraft.ts`) — plain textareas, no per-bullet operations, no drag-reorder, no AI-improve-this-bullet affordance at the point of editing.
- **One draft per job, no variants, no history.** Regenerate overwrites; a good manual edit lost to a regenerate is unrecoverable. `Status` ("generated"/edited) and `GenerationContextHash` exist precisely because overwrite-anxiety is real — they mitigate instead of solving.

**Reusing information:** the master→tailored generation is the only reuse mechanism. No way to reuse a great tailored summary across jobs, no library of alternative bullets, no second master for a different career track. `CanonicalProfileVersion` at least detects when a draft is stale relative to the master — good instinct, minimal payoff without a refresh/diff flow.

**Maintaining career information over time:** effectively unsupported. Adding a new job to your history = edit raw text + rebuild, or re-upload a new document. For a product whose vision is "the structured career profile is the single source of truth," today's truth is a text blob on the user table.

**Friction inventory (ranked):**
1. OAuth users locked out of CV features (bug).
2. No from-scratch creation path.
3. No structured-profile editor — raw text is the editing surface.
4. Tailored CV editor trapped in a modal.
5. Single draft, overwrite-on-regenerate, no history.
6. Pipeline vocabulary (runs/reprocess/rebuild) in end-user UI.
7. Preview is HTML-in-a-box, not a paginated document preview; template switching is a dropdown with no visual gallery.
8. CV features split across two distant locations (Profile page ↔ job modal) with no navigational thread connecting them.

---

## 3. CV Builder Analysis (vs. competitor research)

### Editing model

Current: **raw-text-primary with derived structure** (master) and **form-ish JSON blob editing** (tailored). The market-winning model per the research: **structured forms + instant themed preview + drag-drop sections** (FlowCV, Reactive Resume, Teal). We have the *data model* for that (StructuredCvProfile is section-granular) but not the UI. Verdict: the editing surface must be rebuilt around structure; the raw text demotes to an import artifact and export view.

### Preview experience

Rendered HTML returned by the server per-request, displayed inline. No client-side re-render on keystroke, no pagination fidelity, no zoom, no "what the ATS sees" view (which our structured pipeline could produce almost for free — competitive claim identified in research §7.4). Against FlowCV's lag-free live preview this is a clear generation behind.

### Template switching & customization

Genuinely decent bones: `TemplateId` swaps freely over the same content (content/presentation separation *within* the draft works); render options offer curated accent palette, section order, page mode, bullet density, photo toggle. This matches the curated-token pattern Novoresume uses (research §4.7) — the right instinct. Falls short on: no visual template gallery, no font choice, no spacing control, six templates whose design quality is mid-tier vs. the design-led cluster, and per-CV theme settings can't be saved/reused as a named style.

### What we already do well (protect these in the redesign)

1. **Extraction pipeline with provenance** — versioned runs (parser/normalizer/prompt versions), field-level confidence + review-state + source snippet. No competitor surfaces provenance at all. This is a differentiating asset the moment a review UI exposes it ("we're 60% sure about this date — confirm?").
2. **Match scoring with curated skill synonyms** in the same system as tracking — Teal's premium feature, already ours.
3. **Prompt-injection-hardened AI pipeline** with delimiter fencing and instruction-ignoring rules; provider router with local fallback. More mature than the market's bolt-on AI.
4. **Server-side Playwright rendering** — full CSS typography control; matches the print quality of the design-led cluster.
5. **Staleness detection** (`CanonicalProfileVersion`, `GenerationContextHash`) — the primitive that version-aware tailoring needs.

### Where we fall behind

| Dimension | Market bar | Us |
|---|---|---|
| From-scratch creation | Universal | Absent |
| Structured editing UI | FlowCV/RR/Teal forms + preview | Raw text + JSON blobs |
| Live preview | Instant, paginated | Server round-trip HTML |
| Variants | Unlimited (RR) / paid tiers | One per job, zero free-standing |
| Version history | Rare in market (opportunity) | None (also our gap) |
| Template count/quality | 30–50 good | 6 mid |
| DOCX export | ~60% of market | None |
| Public share link | RR, FlowCV | None |
| Onboarding to first PDF | <10 min (FlowCV) | Not achievable without an existing CV document |

---

## 4. Current Data Model Review

### Entities and storage

- **`ApplicationUser.ProfileCvText` + `ProfileCvStructureJson`** — the master CV as two nullable string columns *on the Identity user row*. Sins: (a) fat blobs on the most-fetched row in the system (auth reads drag CV bytes along unless carefully projected); (b) exactly-one-profile hard-coded into the schema — the CvVariant/second-career-track future requires a migration by definition; (c) no versioning — every rebuild silently destroys the previous structure (extraction *runs* are versioned; the *applied profile* is not); (d) dual representation with no single source of truth — text and structure coexist, edits touch one, rebuilds overwrite the other, and different features read different ones (match scoring builds a corpus from raw text; tailoring generates from structure).
- **`StructuredCvProfile`** (JSON shape) — good: section-granular, extensible (`OtherSections`, generic `Sections`), already covers certifications/projects/languages/interests, and `Metadata.Fields` carries per-field provenance. Weak: date fields are free-strings (`Start`/`End`) so no reliable timeline math (career-timeline feature will choke); `Skills` is `List<string>` with no proficiency/category/years; no stable IDs on items, so "this bullet in the tailored draft came from job #2 bullet #3" is unexpressible — lineage between master and tailored content is lost at generation time.
- **`TailoredCvDraft`** — one row per job (`JobApplicationId` FK, effectively 1:1), section JSON blobs, `TemplateId` + `RenderOptionsJson` inline. Good: `CanonicalProfileVersion` + `GenerationContextHash` staleness primitives; JSON-blob sections are pragmatic for a document-shaped payload. Bad: **presentation welded to content** (can't render one draft in two themes without mutating it — the architecture proposal's core criticism, confirmed); no variant concept; no history; `Status` is a two-state string doing lifecycle work.
- **`CvUploadArtifact` / `CvExtractionRun`** — the best-designed corner: artifacts retained, runs versioned by parser/normalizer/prompt versions, `StructuredProfileJson` snapshot per run. This IS a version history — but only for imports, and nothing lets a user diff or restore from it.
- **Cover letters, interview prep, portfolios, public profiles** — no entities. Interview prep/fit/focus outputs are transient API responses; a user's best interview-prep notes evaporate.

### Verdict against the Career Workspace target

The proposal's target model (CareerProfile → CvVariant → CvVersion, Theme as sibling reference, TailoredCvVersion, output entities) is confirmed necessary by this audit, and the migration is *tractable*: `ProfileCvStructureJson` lifts into a `CareerProfile` table nearly verbatim; each `TailoredCvDraft` becomes a job-linked CvVariant with its render options extracted to a theme reference. Two additions this audit forces onto the proposal:
1. **Stable item IDs** in the profile schema (jobs, bullets, skills) — without them, variant/tailoring lineage, "update everywhere," and inheritance-with-overrides are all unimplementable.
2. **Normalize dates** (`YYYY-MM` + `isCurrent`) at migration time — timeline, tenure math, and skills-recency all depend on it; migrating free-strings later means re-parsing every profile again.

Also settle the source-of-truth rule explicitly: **structure is canonical; text is derived** (an export format and search corpus, regenerated on change) — and make match scoring read from structure so the two consumers stop diverging.

---

## 5. AI Workflow Review

### What exists

| Feature | Flow | Persistence |
|---|---|---|
| CV parse/normalize | upload → PDF text → `/cv/normalize` + `/cv/classify-block` (delimiter-fenced) → StructuredCvProfile | Run snapshots ✓ |
| Section rewrite / improve | section text + tone/language/target-role knobs → `/cv/rewrite` → replace text | Overwrites |
| Tailored generation | master profile + job context → draft sections | Overwrites draft |
| Match score | curated skill tags (synonym regex) + keyword corpus | Computed |
| Job-ad summary | local distilbart `/summarize` | Stored on job |
| Interview prep / fit / focus / follow-ups / package / readiness | per-job LLM calls from modal | **Transient** |

### What's genuinely valuable
- The **hardened pipeline** (fencing, ignore-embedded-instructions, provider router with graceful local fallback) — infrastructure competitors lack.
- **Match scoring** — the research's verdict was that JD-gap analysis is the one universally-praised AI feature; ours is real (curated synonyms beat naive keyword matching) and already wired to job data.
- **Structured extraction with confidence** — the input side of every future feature.

### What's limited
- **Rewrite is fire-and-forget:** no diff view, no accept/reject, no before/after. The research flagged "generic rewrite" as the gimmick tier and "improvement with visible diff/scoring" as the useful tier (BeamJobs pattern). We're on the wrong side of that line purely for lack of UI.
- **Tailoring is disconnected from scoring:** generation doesn't take the match-score gaps as input, and the score doesn't update live as the user edits the draft. The two halves of the killer loop exist and don't talk.
- **AI knobs are raw:** tone/language/target-role as form fields instead of intent-level actions ("make this more senior," "address this missing keyword").
- **Transient outputs:** interview prep and fit analyses regenerate (cost + latency + inconsistency) instead of persisting as reviewable documents.

### Hallucination / factual-accuracy risk — currently the biggest unmanaged AI risk
Rewrites and tailored generation can fabricate: a rewrite that upgrades "assisted with migration" to "led migration" is a *career integrity* failure, invisible today because nothing constrains generation to source facts or shows the user a diff. The provenance metadata (source snippets, confidence) exists on extraction but is **not enforced on generation**. Recommendation, in priority order:
1. Every AI mutation renders as a **diff with accept/reject** (also solves the limited-rewrite problem).
2. Generation prompts constrained to *select/rephrase* profile content, never invent quantities, employers, titles, or dates; validator pass flags novel named entities/numbers that don't appear in the source profile.
3. Tailored content carries source-item references (needs the stable IDs from §4) so "where did this claim come from" is answerable per bullet.

### Missing AI opportunities (ranked by leverage of existing assets)
1. **Tailoring loop screen:** match gaps ↔ draft side-by-side, one-click "address this gap" → constrained rewrite → live rescore. Wires three existing services into the screen no competitor has with our rendering quality.
2. **Extraction review queue:** low-confidence fields surfaced as confirm/fix cards — turns existing provenance metadata into visible trust.
3. **Email-aware prep:** interview prep that reads the actual recruiter thread (unique data no competitor holds).
4. **Skills-gap analytics across tracked JDs:** "your last 15 rejections wanted X" — pure aggregation over data already stored.

---

## 6. Template & Rendering Review

### Pipeline
`TailoredCvDocument` → `CvTemplateRenderer.Render(templateId, …)` → C# switch over 6 template methods building HTML strings (~450 lines total) → `PlaywrightCvPdfExporter` (headless Chromium print) → PDF. Accent resolved via `ResolveAccent` (slate/blue/emerald/plum/brick → hex). Same renderer drives HTML preview and PDF (single source of visual truth — good).

### Evaluation
- **Add a new template:** write a new C# method, recompile, redeploy. Designer-inaccessible, review-heavy, untestable in isolation. Cost is why there are six.
- **User customization:** limited to the curated render options; anything more means more C# branches.
- **Premium/marketplace templates:** impossible — templates are compiled code; third-party code in the renderer is a non-starter (research §6 confirmed themes-as-declarative-data is how RR solves this: "Structured Style Rules").
- **Career Workspace outputs:** each new output type (public profile page, portfolio, DOCX) would today mean another hardcoded renderer. The proposal's `IOutputAdapter` + Scriban theme manifests directly answers this; this audit adds one guardrail from RR's history (they abandoned server-Chromium for cost): **keep the PDF backend swappable behind the adapter interface** — Playwright is right for us now (already built, small scale, full CSS), but the boundary must let a lighter renderer replace it without touching themes.
- **Print fidelity risks present today:** page-break control is CSS-implicit (no explicit widow/orphan handling per section); "one-page" mode is a squeeze heuristic rather than a layout contract. Fine at 6 templates; codify break rules in the theme manifest schema when porting.

---

## 7. Feature Gap Analysis

### Missing entirely (vs. competitor research + vision)

| Feature | Competitor bar | Vision need | Cost given our architecture |
|---|---|---|---|
| From-scratch CV creation | Universal | Yes | Medium (structured editor is the prerequisite) |
| Multiple CV variants | RR unlimited; FlowCV's paywall seam | Core | Schema migration (planned) |
| CV version history | Market gap — differentiator | Core | Medium (CvVersion planned) |
| Structured profile editor + review UI | Universal (forms) | Core | Large — the main UI build |
| Live paginated preview | FlowCV bar | Yes | Medium |
| DOCX export | ~60% of market, loud complaints | Yes | Medium, scoped (per proposal) |
| Public profile / share link | RR, FlowCV | Core (Horizon 2) | Medium (adapter + theme) |
| Cover letter entity + generation | All paid competitors | Core | Small once profile model lands |
| Career timeline / skills matrix | Nobody good | Differentiator | Small *after* date normalization |
| Persisted interview prep | Nobody (market gap) | Differentiator | Small (persist what exists) |
| ATS-view ("what the parser sees") | Nobody shows it | Trust play | Small (we have structure) |
| JSON Resume interop / published schema | RR | Trust play | Small |

### Exists but needs improvement
1. **OAuth CV lockout bug** — fix now (one-line frontend condition).
2. Tailored editor out of the modal into a full-page workspace route.
3. Rewrite → diff/accept/reject.
4. Match score ↔ tailoring connection (the loop).
5. Template gallery with visual previews (data exists in `templates` endpoint descriptors).
6. Pipeline vocabulary → user vocabulary ("Update from new CV," not "Reprocess run").
7. Section editing: per-bullet rows with reorder + inline AI, not newline blobs.
8. Extraction confidence → visible review flow instead of buried metadata.

---

## 8. Product Recommendations

### Immediate (low effort / high impact — do before or alongside Phase 1)

| # | Recommendation | Problem | User value | Technical impact | Complexity | Priority |
|---|---|---|---|---|---|---|
| I1 | Fix OAuth `isLocal` CV lockout | Google/MS users can't use CV features | Unblocks all OAuth users | One condition split (identity-gates vs. feature-gates) | Trivial | **P0 — bug** |
| I2 | Diff + accept/reject on every AI rewrite | Silent overwrites; hallucination invisible | Trust in AI edits; recoverability | Frontend diff view; keep previous text | Small | P1 |
| I3 | Persist interview prep / fit outputs | Regeneration cost; lost work | Notes survive; consistent prep | One table or JSON column per job | Small | P1 |
| I4 | Rename pipeline vocabulary in UI | Developer jargon confuses | Comprehensible actions | i18n strings only | Trivial | P1 |
| I5 | Template gallery with thumbnails | Blind dropdown | Informed template choice | Render 6 previews once; static images | Small | P2 |
| I6 | Export JSON of profile + drafts | No data-ownership story | Trust (research: fair-exit is strategy) | One endpoint, serializers exist | Small | P2 |

### Medium-term (requires the architectural work — Phases 1–4 of proposal)

| # | Recommendation | Problem | User value | Technical impact | Complexity | Priority |
|---|---|---|---|---|---|---|
| M1 | CareerProfile + CvVariant + CvVersion migration, **with stable item IDs and normalized dates** | One profile, no variants, no history, blobs on user row | Multiple CVs, safe regeneration, update-everywhere | The Phase-1 schema migration; raw-SQL reconciler steps | Large | P0 of redesign |
| M2 | Structured profile editor + extraction review queue | Raw text is the editing surface | Maintainable career data; visible trust | New primary UI; confidence metadata already present | Large | P0 of redesign |
| M3 | Theme engine port (Scriban manifests, 6→best 3–4 templates) | Templates are compiled code | Theme switching, future marketplace | Per proposal; add explicit page-break rules to manifest schema | Large | P1 |
| M4 | Tailoring workspace route (JD gaps ↔ draft ↔ live preview + rescore) | Modal editor; disconnected scoring | The killer screen (research MVP §9.5) | New route; wires existing services | Large | P1 |
| M5 | Fact-constrained generation + novel-entity validator | Hallucinated seniority/numbers | Career integrity | Prompt + validator in FastAPI sidecar | Medium | P1 |
| M6 | From-scratch creation + paste-text import | Import-only onboarding | New-grad / no-CV users can start | Falls out of M2 + existing normalize path | Medium | P2 |
| M7 | Scoped DOCX adapter | Loudest export complaint in market | "Employer wants Word" solved | OpenXML `IOutputAdapter` (per proposal: scoped, not parity) | Medium | P2 |

### Long-term (Career Workspace horizons)

| # | Recommendation | Value | Complexity | Priority |
|---|---|---|---|---|
| L1 | Cover letters as profile-derived entities | Completes application package | Small post-M1 | P1 of Horizon 2 |
| L2 | Public profile / share link (theme over live profile, not doc snapshot) | RR/FlowCV parity + our live-data twist | Medium | P2 |
| L3 | Email-aware interview prep (thread context) | Unique-data moat; market's empty space | Medium | P1 of Horizon 3 |
| L4 | Skills matrix + gap analytics across tracked JDs | Nobody has it; pure aggregation for us | Small post-M1 | P2 |
| L5 | Portfolio / personal site as output adapters | Vision endgame; each ≈ adapter + theme | Medium each | P3 |
| L6 | Published profile schema + JSON Resume interop (+ MCP later) | Trust + agent-native future (RR precedent) | Small | P3 |

---

## 9. Proposed Future Architecture

Confirms the architecture proposal, with this audit's amendments folded in:

```
CareerProfile  (one per user now, N later; stable item IDs; normalized dates;
 │              provenance metadata retained; STRUCTURE canonical, text derived)
 │  sources: upload/extraction runs (kept), from-scratch editor, paste-text
 │
 ├──< CvVariant          (free-standing OR job-linked; inherits profile, holds
 │      │                 selections/overrides by item ID — lineage preserved)
 │      ├──< CvVersion   (history: every generation & manual save; diff/restore)
 │      └── ThemeRef ────→ Theme (SIBLING input, never welded into content;
 │                          declarative Scriban manifest: tokens, layout,
 │                          section styles, page-break rules; ATS rating)
 │
 ├── Tailoring loop      (JobApplication + MatchScore gaps ↔ variant edits ↔
 │                        constrained AI rewrites w/ diff ↔ live rescore)
 │
 └──> IOutputAdapter<T>  (renderer boundary; PDF backend swappable — RR lesson)
        ├─ PDF CV            (Playwright, today)
        ├─ DOCX CV           (OpenXML, scoped)
        ├─ ATS plain-text    (trust view — near-free)
        ├─ Cover letter      (profile + job + thread context)
        ├─ Public profile    (theme over live profile)
        ├─ Portfolio / site  (Horizon 3+)
        ├─ LinkedIn content  (Horizon 3)
        └─ Interview prep    (persisted; email-thread-aware — unique moat)
```

**Why this redesign is right (one paragraph):** every weakness this teardown found — single profile as user-row blobs, text/structure truth conflict, presentation welded to drafts, overwrite-anxiety mitigations, compiled templates, modal-trapped editing, transient AI outputs — is a symptom of the same root cause: *documents are the primary objects and career data is trapped inside them*. The competitor research shows the market leader in each dimension solved exactly one symptom (RR: schema; FlowCV: editor; Teal: career data; Novoresume: themes) and none solved the root. Inverting the model — profile as source of truth, every artifact a themed projection — fixes all symptoms with one architecture, reuses our real assets (extraction provenance, match scoring, email intelligence, hardened AI pipeline, Playwright rendering), and each subsequent output costs one adapter + one theme instead of one product.

**Sequencing note:** I1 (OAuth bug) ships now. M1+M2 before any visible redesign — the migration is invisible and everything depends on it. M3/M4 are the visible payoff. The proposal's phase plan stands; this audit adds stable IDs + date normalization as Phase-1 requirements and the diff-everywhere rule as a design principle from day one.