feat(profile): guide candidates through a resumable career-facts interview

[akoita]

Problem to solve

On first use, most candidates will understandably seed DraftLoop with their richest existing CV. A CV is still a selective, compressed artifact: it often omits older experiences, project context, decisions, constraints, collaboration, outcomes, and evidence that could become strong arguments for a future application.

DraftLoop should help candidates invest in a more complete, reusable career record without making initial onboarding burdensome. It also needs a safe way to handle cases where a new recollection conflicts with an imported CV or another candidate-provided source.

Proposed approach

Add an optional, resumable career-facts interview after initial Candidate Knowledge Base (CKB) intake. The interview uses the candidate's reviewed material to walk chronologically from their earliest experience to their latest, asking focused follow-up questions that can uncover useful, source-traceable facts.

The interview should:

• Invite the candidate after their first substantive source import, while preserving a clear “not now” path.
• Build an agenda from known experiences and visible gaps, then move from earliest to latest experience.
• Adapt follow-up questions to what is already known rather than use one fixed questionnaire.
• Explore application-relevant facts such as role scope, responsibilities, projects, decisions, constraints, collaborators, customers, tools, skills, promotions, recognition, outcomes, and available qualitative or quantitative evidence.
• Avoid leading questions that pressure the candidate to invent metrics or overstate impact.
• Let the candidate skip a question, say they do not remember, pause, and resume later.
• Show progress by experience and make it worthwhile to complete the corpus incrementally rather than in one long session.

Each accepted answer becomes explicitly identified candidate-authored source material in the selected CKB. It does not silently become an independently verified fact. The canonical profile workflow in #66 remains responsible for normalization and candidate review.

Contradiction reconciliation

When an answer conflicts with existing material—for example on dates, title, scope, technology, team size, or a metric—the app must not choose or overwrite a value silently. It should show the competing statements with their source/version provenance and ask the candidate to:

• confirm one statement and supersede the other;
• edit the new answer;
• keep both because they describe different periods, projects, or contexts; or
• leave the conflict unresolved and continue.

The reconciliation decision and rationale should be concise, user-visible, and versioned. Unresolved conflicts must remain visible to profile review and must not be flattened into a single drafting fact.

User stories

• As a new candidate, I want to start with my existing CV and enrich it later so that I can reach first value without completing a lengthy questionnaire.
• As a candidate, I want relevant follow-up questions for each experience so that I can recover useful facts my CV omitted.
• As a returning candidate, I want to pause and resume the interview so that I can build my career corpus over time.
• As a candidate, I want contradictory statements shown with their origins so that I can reconcile them without losing evidence.
• As a candidate who does not remember an answer, I want to skip or mark it unknown so that the app never pressures me to fabricate detail.

Scope boundaries

• The interview enriches reusable candidate knowledge; it is not tied to one opportunity and does not submit applications.
• The first slice should support candidate-controlled text answers and structured reconciliation. Voice capture, document generation, public research, and automatic employer/contact verification are out of scope.
• The interview does not claim independent factual verification, infer unsupported achievements, or invent dates, employers, titles, technologies, or metrics.
• This is not a required first-run gate. Candidates can obtain value from imported sources before choosing to enrich their corpus.

Privacy and provider considerations

• Answers, progress, reconciliation decisions, and history remain local by default and follow CKB retention, deletion, export, and backup boundaries.
• Before any provider receives candidate material to generate or adapt questions, the app must show the exact scope and require the existing visible transmission approval boundary.
• The app must expose provider/model identity and must not retain hidden chain-of-thought; store only candidate answers, structured interview state, concise question rationale where useful, and reconciliation decisions.
• Declining provider transmission must not corrupt or discard already accepted answers. A deterministic/local question path should be evaluated during design so core review and reconciliation are not coupled to a live provider.
• No background web research, employer contact, publishing, or external side effect is authorized by participating in the interview.

Acceptance criteria

• After first substantive CKB intake, the candidate is offered the interview with clear start, defer, and dismiss choices; drafting is not blocked by deferral.
• The interview derives a chronological agenda from the selected CKB and covers every known experience without merging distinct roles silently.
• Questions use known context, avoid asking for facts already answered, and allow follow-up depth without an unbounded session.
• The candidate can skip, mark unknown, pause, resume after restart, review accepted answers, and correct or withdraw an answer.
• Accepted answers are stored as versioned candidate-authored evidence with stable provenance and remain distinguishable from imported sources and independent verification.
• Potential contradictions across interview answers and existing sources are detected for at least dates, titles, employers, scope, technologies, and quantitative claims.
• Reconciliation shows both statements and source/version origins, supports supersede/edit/contextualize/defer outcomes, and records the candidate's explicit decision without deleting source history.
• Unresolved conflicts remain visible to feat(profile): build a persistent canonical candidate career profile #66 profile review and cannot silently produce one canonical drafting fact.
• Provider transmission is explicit, scoped, and recorded; local data is not sent merely because the user opened or resumed the interview.
• Retention, deletion, backup/restore, and CKB isolation cover interview state and accepted answers without cross-CKB leakage.
• Sanitized tests cover sparse and rich CVs, overlapping roles, career gaps, promotions, changed recollections, unknown answers, restart recovery, provider refusal/failure, and contradiction reconciliation.
• Representative user evaluation measures time spent, completion/resumption, useful new facts recovered, unresolved conflicts, and unsupported-claim regressions before setting product targets.
• Shared application contracts support CLI/desktop parity; the desktop remains a UI shell over those contracts.
• Affected README, architecture/privacy/threat-model guidance, CLI help, and roadmap references are synchronized when implementation is scheduled.
• pnpm validate passes.

Roadmap and dependencies

Treat this as Later / controlled expansion until the current evidence-backed drafting vertical is complete and representative validation shows where profile gaps remain. Do not add it to the dependency-closed v0.8 milestone.

The feature builds on the portable CKB and application selection boundaries in #78 and #111, and on the canonical profile/conflict contract in #66. Implementation should be split into independently closable slices for interview state, question planning, candidate-authored evidence intake, contradiction reconciliation, and shared CLI/desktop integration.

Related: #4, #66, #78, #80, #111