Resume Builder — in development

Resume Builder — in development

Product spec v0.9.5 · accepted 2026-09-02 · canonical copy: BrainDrive Library / foundation / app-platform-product-specs / apps / resume-builder

What it is: Resume Builder should feel like talking to an expert career coach. It helps a BrainDrive owner understand their experience, draw out what matters, and craft a resume they feel confident using. The owner can start from their BrainDrive context, from a pasted resume or LinkedIn profile, or from scratch. The model writes an editable Resume Profile; the app turns it into a formatted Resume and exports a PDF.

Status: build started 2026-08-10 · first candidate in evaluation, fixes in progress · formal evaluation pending
Where it will live: a standalone app, one-click install from the Apps page; it shows up alongside the Careers page.

This is the public build thread. Progress updates land as replies. Questions welcome.

How it works

Experience

The owner enters Resume Builder and uses normal BrainDrive chat. The host supplies relevant, owner-authorized BrainDrive context, including Career context when available. The app remains fully usable when Career data or companion apps are absent. The model confirms what it knows and asks only for corrections or resume-specific gaps. It handles follow-up questions, uncertainty, corrections, and digressions as a conversation, not a checklist.

When the owner asks to create a resume, the model writes or updates the Resume Profile. The Profile is the editable source of truth. The owner can edit it directly or ask for changes in chat. Create Resume formats the Profile into a separate Resume. Export PDF produces a downloadable PDF from that Resume.

The standard workspace has Conversation, Your Resume Profile, and Your Resume. Advanced exposes Agent Instructions and Interview Guide for owners who want to inspect or adjust how the app works. Document pages keep the established BrainDrive controls: Back to chat, applicable edit controls, and the native composer.

Primary Flow

  1. Start and interview: The model uses relevant, authorized BrainDrive context when available, including Career context. Otherwise, it asks first for a resume, LinkedIn profile, or other career material to paste. A from-scratch interview starts only when the owner has no material.
  2. Create the source: Owner clearly asks to create a resume; model writes or updates the Resume Profile; owner reviews and edits it.
  3. Create and export: Owner chooses Create Resume; app formats the current Profile; owner reviews the Resume and chooses Export PDF.
User stories (16, all confirmed)

US-1: Create A Strong, Accurate Resume — Confirmed

As a BrainDrive owner, I want a strong, accurate resume that reflects my real experience and positions me clearly for the kind of role I want next, without errors, exaggeration, or made-up facts.

Acceptance criteria

Given an owner has created and reviewed a Resume Profile, when they create a Resume, then:

  • AC-1.1 — the Resume accurately reflects the owner’s real experience. Pass bar: a calibrated reviewer rates groundedness at least 4 of 5 on every required persona run, and no unsupported material claim survives into the Profile, Resume, or PDF.
  • AC-1.2 — the Resume uses clear, role-directed language. Pass bar: calibrated reviewer ratings for outcome quality average at least 4 of 5 across the persona pack.
  • AC-1.3 — the Resume contains no invented employment, education, credentials, metrics, or contact information. Pass bar: none.

The product helps the owner position their experience; it does not promise a hiring outcome.

US-2: Natural Resume Conversation — Confirmed

As a BrainDrive owner, I want to discuss my career in normal chat, so that I can create a resume without translating my experience into an unfamiliar form.

Acceptance criteria
  • AC-2.1Migrated to the App-Workspace Contract as APP-1.1/APP-1.2 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability; the canonical requirement lives in the contract.

US-3: Start From Existing Material — Confirmed

As a BrainDrive owner, I want Resume Builder to start with career information, resume text, LinkedIn text, or other material I already have, so that I build from useful context rather than repeating work.

Acceptance criteria
  • AC-3.1 — Given an owner opens Resume Builder without authorized Career context, the model first asks whether the owner has a resume, LinkedIn profile, or other career material to share.
  • AC-3.2 — Given an owner pastes existing material into Resume Builder chat, the model treats it as starting context and continues conversationally. The owner does not need to upload or import a file or repeat the material through a blank-slate interview.

US-4: Start From My Career Page — Confirmed

As a BrainDrive owner, I want Resume Builder to start from relevant information I have already established in BrainDrive, so that I do not repeat work or get asked questions BrainDrive can already answer.

Acceptance criteria
  • AC-4.1 — Given an owner has authorized relevant Career context, the host supplies it when the owner opens Resume Builder. The model confirms what it knows and asks only for corrections or resume-specific gaps. If Career context is unavailable, the owner can use pasted material or start from scratch.
  • AC-4.2 — The host must not silently scan unrelated material.

The long-term contract is not Career-only. The host should make relevant, owner-authorized context from any BrainDrive workspace available through the same purpose-limited interface. The Resume Profile remains the private, editable source for this resume.

US-5: Start From Scratch — Confirmed

As a BrainDrive owner, I want to start a resume conversation without an existing resume or LinkedIn profile, so that I can build a strong resume from my experience rather than being blocked by missing material.

Acceptance criteria
  • AC-5.1 — Given an owner has no existing resume or LinkedIn material, the model helps them tell their story naturally, and the owner can create a Resume Profile without supplying an existing document. Pass bar: a Profile is created from conversation alone, and calibrated reviewer ratings for conversation quality and career-coach usefulness are each at least 4 of 5 on every from-scratch persona run.

US-6: Resume My Work Later — Confirmed

As a BrainDrive owner, I want to return to my resume conversation later and pick up where I left off, so that I can add remembered details or continue my work without starting over.

Acceptance criteria
  • AC-6.1Migrated to the Host Chat Contract as CHAT-1.1/CHAT-1.2 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability; the canonical continuity requirement lives in the contract.
  • AC-6.2 — The owner can correct or add information, and the next Resume render uses the current saved Profile.

US-7: Review An Editable Resume Profile — Confirmed

As a BrainDrive owner, I want to review and edit the model’s understanding of my experience before formatting, so that I remain in control of the source content.

Acceptance criteria
  • AC-7.1 — Given an owner has discussed their experience and clearly asks to create a resume, the model creates or updates an editable Resume Profile.
  • AC-7.2 — The Profile honestly omits missing information or marks it for later input.

US-8: Keep My Resume And Coach In Sync — Confirmed

As a BrainDrive owner, I want changes I make to my Resume Profile to be reflected in my Resume and in the model’s current understanding of me, so that I have one accurate source of truth.

Acceptance criteria
  • AC-8.1 — Given an owner edits the Resume Profile directly, the host supplies the current Profile as the owner’s resume context when they return to chat or choose Create Resume. Create Resume uses that current Profile rather than a stale copy.
  • AC-8.2 — The app clearly tells the owner when Profile edits require a new render. It does not silently overwrite the Profile from older chat context.

US-9: Use A Standard Professional Format — Confirmed

As a BrainDrive owner, I want my Resume to use a conventional, professional format by default, so that I can use it confidently without having to choose a design.

Acceptance criteria
  • AC-9.1 — Given an owner chooses Create Resume, the app uses one conservative, single-column, reverse-chronological format with standard resume headings, as defined by the Resume Template Standard.
  • AC-9.2 — The format remains readable, professional, and suitable for ordinary applicant-tracking systems. Pass bar: a calibrated reviewer passes every item of the Resume Template Standard §6 acceptance checklist on the rendered Resume and PDF for every required persona run.

Template selection is a later capability. V1 does not ask the owner to choose a design.

US-10: Create A Predictable Resume — Confirmed

As a BrainDrive owner, I want Create Resume to format my reviewed Profile predictably, so that the formatted result does not change the meaning I approved.

Acceptance criteria
  • AC-10.1 — Given an editable Resume Profile exists, when the owner chooses Create Resume, the app creates a distinct formatted Resume from the current Profile.
  • AC-10.2 — No additional model call occurs, and the Profile remains unchanged.

US-11: Export What I Reviewed — Confirmed

As a BrainDrive owner, I want a PDF of my formatted Resume, so that I can use the same resume outside BrainDrive.

Acceptance criteria
  • AC-11.1 — Given a formatted Resume exists, when the owner chooses Export PDF, the app creates a selectable, text-based PDF from that Resume in the one V1 format and downloads it directly to the owner’s Downloads folder (deterministic code, no model call — D374). The owner sees an unmistakable downloaded signal (a model line naming the Downloads folder, or a control-state change). No PDF artifact, receipt, or sidebar entry is created in the app.
  • AC-11.2 — The PDF preserves the Resume’s logical content and order.
  • AC-11.3 — The exported PDF opens in a standard PDF reader outside BrainDrive, on a standard page size (US Letter or A4), with fonts embedded, and shows the same layout as the formatted Resume. Pass bar: opens without error in one named standard reader; page size and embedded fonts verified; a calibrated reviewer confirms the layout matches on a screenshot taken in that reader, for every required persona run.
  • AC-11.4 — It is obvious how to download the PDF. Given a formatted Resume exists, the owner can find Export PDF from the Resume page without asking, and if they do ask in chat, the model points them to the actual control and, after an export, to the Downloads folder — never to a sidebar location that does not exist. Pass bar: the Export PDF control is visible on the Resume page with a text label; a calibrated reviewer rates owner clarity and control at least 4 of 5 on a “how do I get my PDF?” turn for every required persona run.
  • AC-11.5 — Whenever the model describes where the Profile, Resume, or PDF is, or what state it is in, the description matches the actual interface. The model never names a location, control, or artifact that does not exist. Pass bar: none — any false statement about app or artifact state is a hard failure.

US-12: Recover Without Losing Work — Confirmed

As a BrainDrive owner, I want failures to leave my conversation and documents visible, so that I can continue rather than start over.

Acceptance criteria
  • AC-12.1Migrated to the Host Chat Contract as CHAT-3.1 (v0.9.3), pass bar included; binds by reference through the Inherits line. The ID is retained for traceability; the canonical requirement lives in the contract.

US-13: Understand And Adjust The App — Confirmed

As a BrainDrive owner, I want to inspect the app’s working documents and instructions when I choose, so that I can understand and influence how it works.

Acceptance criteria
  • AC-13.1Migrated to the App-Workspace Contract as APP-4.1–4.3 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability. Resume Builder’s declared edit matrix (the app-declared input APP-4.1 tests, ruled D25 2026-09-01): Resume Profile, Agent Instructions, and Interview Guide are directly editable on their pages via the native composer; the formatted Resume is read-only (deterministically generated from the Profile — editing it would break the Profile-as-source-of-truth invariant). Read-only standards documents are presented as read-only per APP-4.3.

US-14: Get Help In The Conversation — Confirmed

As a BrainDrive owner, I want to ask Resume Builder how the process works or what is happening, so that I can understand and make decisions without leaving my resume work to find separate help.

Acceptance criteria
  • AC-14.1 — Given an owner asks about the interview, Resume Profile, formatting, or export during resume work, the model gives a plain-language, context-aware answer in the same conversation. Pass bar: a calibrated reviewer rates owner clarity and control at least 4 of 5 on every required persona run.
  • AC-14.2 — After answering a process question, the model can smoothly return to the owner’s resume work without losing the current conversation, Profile, or next useful step.

The product does not require a front-loaded tutorial.

US-15: Use It Without A Manual — Confirmed

As a BrainDrive owner, I want Resume Builder to be self-guiding, so that I can understand what to do next without reading a separate user manual.

Acceptance criteria
  • AC-15.1 — Given an owner opens or returns to Resume Builder, the ordinary chat and workspace make the next action understandable through familiar BrainDrive patterns, clear labels, and context-appropriate guidance. Pass bar: a calibrated reviewer rates owner clarity and control at least 4 of 5 on the opening turn of every required persona run.

If the owner is unsure, they can ask naturally in chat and receive help under US-14.

US-16: Keep My BrainDrive Memory Current — Confirmed

As a BrainDrive owner, I want meaningful information established while using Resume Builder to update the right part of my BrainDrive memory automatically, so that I do not have to repeat the same work in future BrainDrive conversations or apps.

Acceptance criteria
  • AC-16.1 — Within Resume Builder, the conversing model is Your Agent doing the app’s job. App code remains a separate actor and has no direct owner-memory access.
  • AC-16.2 — Given the model and owner establish grounded, reusable understanding, Your Agent writes it through the host to the appropriate owner-controlled memory home without a routine confirmation prompt. The model announces the update in the same turn.
  • AC-16.3 — Stable cross-cutting facts belong in the owner profile. Career-specific facts belong in Career memory. Another workspace receives a fact only when it is the appropriate home.
  • AC-16.4 — The owner can inspect, edit, or remove the update. Guesses, unresolved conflicts, transient details, and unrelated material do not become settled memory.
Acceptance and trust

The rc6 Resume Builder Evaluation Plan owns scenarios, personas, scoring, evidence bundles, and qualification decisions. This specification owns the product outcomes that plan must prove.

Critical Failure Behavior

Scenario Expected behavior
Model unavailable Inherited — CHAT-4.1 binds by reference (was the CF-1 row).
Uncertain material Ask naturally, omit the claim, or mark a visible gap.
Invalid or incomplete Profile Name the missing item. Let the owner edit the Profile, return to chat, or knowingly create an honest partial render.
Rendering failure Keep the Profile and prior Resume unchanged; give a next action.
PDF export failure Keep the Profile and Resume available; allow a later retry without a model call.
Authorized context unavailable Do not imply it was read. Continue with useful questions.
Uncertain memory update Do not save it as settled shared memory. Resolve it in conversation or keep it resume-specific.

Required Evidence

  • A live supported-host from-scratch journey reaches an editable Profile, Resume, and downloadable PDF.
  • A live pasted-text journey reaches the same outcome without file import.
  • A direct Profile correction produces a newly rendered Resume without source drift.
  • PDF parse-back confirms expected text and logical order.
  • Model, render, and export failures preserve saved work and show understandable recovery.
  • Owner-memory evidence identifies Your Agent as the actor, records the host-mediated destination and same-turn announcement, and proves inspection, correction, and removal.
  • Calibrated model-judge and independent-verifier evidence support grounded, useful output and acceptable visual quality.

Logical text and order parity are the automated hard gate. A passing lower layer does not prove the live product. Each acceptance claim must identify whether it comes from code, a built branch or container, or a live install.

Non-Negotiable Trust Boundaries

  • The app never adds a competing chat lifecycle, hidden interview intelligence, or form-like confirmation workflow. (The chat-lifecycle half is inherited — APP-1.1 binds by reference; hidden interview intelligence stays RB-owned.)
  • The system never turns uncertain information into a confident career claim.
  • The workspace remains private and owner-scoped. The app never exposes provider credentials, unrestricted storage, or unrelated personal context.
  • App code never reads or writes owner memory directly. Your Agent performs memory work through host mediation and announces each settled update in the same turn.
  • The owner can review and edit the Profile before formatting. (The lifecycle half — deleting private app documents does not delete chat; uninstall defaults to keep — is inherited: APP-5.1 binds by reference; was the TB-5 row.)
  • Companion apps may use the current Resume Profile only through declared, owner-authorized context. They cannot silently overwrite it, and Resume Builder does not take ownership of their downstream workflows.
  • Do not claim full portable-app conformance until accepted ground-truth evidence exists.
Full product spec (v0.9.5)

Spec: Resume Builder — Base Resume V1

Purpose: Product and engineering contract for Resume Builder, a standalone app and the base-resume workspace in the Job Search Pack. This is for product owners, builders, QA, and maintainers. It is not an owner-facing artifact.

Status: Accepted v0.9.5 — 2 September 2026. Dave W accepted this revision as the Resume Builder product authority. v0.9.5 retains the decisions from unpublished v0.9.4/D374, pins Host Chat v0.5 and APP v0.3, and records the four narrow inherited-criterion exclusions approved by Dave W. v0.9.4 is superseded. The separate unpublished evaluation-plan rc5 and RB-KIT-1.0-rc5 drafts were also superseded and never canonical. Formal evaluation remains blocked only on the plan and execution-kit prerequisites recorded downstream.

Overview

What We’re Building

Resume Builder should feel like talking to an expert career coach. It helps a BrainDrive owner understand their experience, draw out what matters, and craft a resume they feel confident using.

The owner can start from authorized BrainDrive context, pasted resume or LinkedIn text, or a blank slate. Career context is useful when available, but Resume Builder does not require completed Career data or another Job Search Pack app. Over time, relevant information from any BrainDrive workspace should be available without making the owner repeat it.

The model conducts the conversation and writes a resume-ready Resume Profile when the owner asks. The owner reviews or edits the Profile. The app then creates a formatted Resume deterministically and exports a PDF from it.

Outcome And V1 Success

Resume Builder serves anyone preparing for work, from a first-time job seeker to someone with a long or changing career. It succeeds when the owner feels they have an expert career coach on their side and can produce a strong, accurate resume they feel confident using.

V1 is done when an owner can:

  1. start with available authorized BrainDrive context, pasted material, or a blank slate;
  2. use normal chat to create and edit a clear Resume Profile;
  3. create a distinct formatted Resume and a selectable, text-based PDF from that Profile; and
  4. recover from ordinary model, render, or export failures without losing work.

V1 does not include DOCX export, file upload or direct LinkedIn integration, tailoring, job-search workflows, template choice, version history, export receipts, visual-diff release gates, or full portable-app conformance.

Product Behavior

Experience

The owner enters Resume Builder and uses normal BrainDrive chat. The host supplies relevant, owner-authorized BrainDrive context, including Career context when available. The app remains fully usable when Career data or companion apps are absent. The model confirms what it knows and asks only for corrections or resume-specific gaps. It handles follow-up questions, uncertainty, corrections, and digressions as a conversation, not a checklist.

When the owner asks to create a resume, the model writes or updates the Resume Profile. The Profile is the editable source of truth. The owner can edit it directly or ask for changes in chat. Create Resume formats the Profile into a separate Resume. Export PDF produces a downloadable PDF from that Resume.

The standard workspace has Conversation, Your Resume Profile, and Your Resume. Advanced exposes Agent Instructions and Interview Guide for owners who want to inspect or adjust how the app works. Document pages keep the established BrainDrive controls: Back to chat, applicable edit controls, and the native composer.

Primary Flow

  1. Start and interview: The model uses relevant, authorized BrainDrive context when available, including Career context. Otherwise, it asks first for a resume, LinkedIn profile, or other career material to paste. A from-scratch interview starts only when the owner has no material.
  2. Create the source: Owner clearly asks to create a resume; model writes or updates the Resume Profile; owner reviews and edits it.
  3. Create and export: Owner chooses Create Resume; app formats the current Profile; owner reviews the Resume and chooses Export PDF.

User Stories

US-1: Create A Strong, Accurate Resume — Confirmed

As a BrainDrive owner, I want a strong, accurate resume that reflects my real experience and positions me clearly for the kind of role I want next, without errors, exaggeration, or made-up facts.

Acceptance criteria

Given an owner has created and reviewed a Resume Profile, when they create a Resume, then:

  • AC-1.1 — the Resume accurately reflects the owner’s real experience. Pass bar: a calibrated reviewer rates groundedness at least 4 of 5 on every required persona run, and no unsupported material claim survives into the Profile, Resume, or PDF.
  • AC-1.2 — the Resume uses clear, role-directed language. Pass bar: calibrated reviewer ratings for outcome quality average at least 4 of 5 across the persona pack.
  • AC-1.3 — the Resume contains no invented employment, education, credentials, metrics, or contact information. Pass bar: none.

The product helps the owner position their experience; it does not promise a hiring outcome.

US-2: Natural Resume Conversation — Confirmed

As a BrainDrive owner, I want to discuss my career in normal chat, so that I can create a resume without translating my experience into an unfamiliar form.

Acceptance criteria
  • AC-2.1Migrated to the App-Workspace Contract as APP-1.1/APP-1.2 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability; the canonical requirement lives in the contract.

US-3: Start From Existing Material — Confirmed

As a BrainDrive owner, I want Resume Builder to start with career information, resume text, LinkedIn text, or other material I already have, so that I build from useful context rather than repeating work.

Acceptance criteria
  • AC-3.1 — Given an owner opens Resume Builder without authorized Career context, the model first asks whether the owner has a resume, LinkedIn profile, or other career material to share.
  • AC-3.2 — Given an owner pastes existing material into Resume Builder chat, the model treats it as starting context and continues conversationally. The owner does not need to upload or import a file or repeat the material through a blank-slate interview.

US-4: Start From My Career Page — Confirmed

As a BrainDrive owner, I want Resume Builder to start from relevant information I have already established in BrainDrive, so that I do not repeat work or get asked questions BrainDrive can already answer.

Acceptance criteria
  • AC-4.1 — Given an owner has authorized relevant Career context, the host supplies it when the owner opens Resume Builder. The model confirms what it knows and asks only for corrections or resume-specific gaps. If Career context is unavailable, the owner can use pasted material or start from scratch.
  • AC-4.2 — The host must not silently scan unrelated material.

The long-term contract is not Career-only. The host should make relevant, owner-authorized context from any BrainDrive workspace available through the same purpose-limited interface. The Resume Profile remains the private, editable source for this resume.

US-5: Start From Scratch — Confirmed

As a BrainDrive owner, I want to start a resume conversation without an existing resume or LinkedIn profile, so that I can build a strong resume from my experience rather than being blocked by missing material.

Acceptance criteria
  • AC-5.1 — Given an owner has no existing resume or LinkedIn material, the model helps them tell their story naturally, and the owner can create a Resume Profile without supplying an existing document. Pass bar: a Profile is created from conversation alone, and calibrated reviewer ratings for conversation quality and career-coach usefulness are each at least 4 of 5 on every from-scratch persona run.

US-6: Resume My Work Later — Confirmed

As a BrainDrive owner, I want to return to my resume conversation later and pick up where I left off, so that I can add remembered details or continue my work without starting over.

Acceptance criteria
  • AC-6.1Migrated to the Host Chat Contract as CHAT-1.1/CHAT-1.2 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability; the canonical continuity requirement lives in the contract.
  • AC-6.2 — The owner can correct or add information, and the next Resume render uses the current saved Profile.

US-7: Review An Editable Resume Profile — Confirmed

As a BrainDrive owner, I want to review and edit the model’s understanding of my experience before formatting, so that I remain in control of the source content.

Acceptance criteria
  • AC-7.1 — Given an owner has discussed their experience and clearly asks to create a resume, the model creates or updates an editable Resume Profile.
  • AC-7.2 — The Profile honestly omits missing information or marks it for later input.

US-8: Keep My Resume And Coach In Sync — Confirmed

As a BrainDrive owner, I want changes I make to my Resume Profile to be reflected in my Resume and in the model’s current understanding of me, so that I have one accurate source of truth.

Acceptance criteria
  • AC-8.1 — Given an owner edits the Resume Profile directly, the host supplies the current Profile as the owner’s resume context when they return to chat or choose Create Resume. Create Resume uses that current Profile rather than a stale copy.
  • AC-8.2 — The app clearly tells the owner when Profile edits require a new render. It does not silently overwrite the Profile from older chat context.

US-9: Use A Standard Professional Format — Confirmed

As a BrainDrive owner, I want my Resume to use a conventional, professional format by default, so that I can use it confidently without having to choose a design.

Acceptance criteria
  • AC-9.1 — Given an owner chooses Create Resume, the app uses one conservative, single-column, reverse-chronological format with standard resume headings, as defined by the Resume Template Standard.
  • AC-9.2 — The format remains readable, professional, and suitable for ordinary applicant-tracking systems. Pass bar: a calibrated reviewer passes every item of the Resume Template Standard §6 acceptance checklist on the rendered Resume and PDF for every required persona run.

Template selection is a later capability. V1 does not ask the owner to choose a design.

US-10: Create A Predictable Resume — Confirmed

As a BrainDrive owner, I want Create Resume to format my reviewed Profile predictably, so that the formatted result does not change the meaning I approved.

Acceptance criteria
  • AC-10.1 — Given an editable Resume Profile exists, when the owner chooses Create Resume, the app creates a distinct formatted Resume from the current Profile.
  • AC-10.2 — No additional model call occurs, and the Profile remains unchanged.

US-11: Export What I Reviewed — Confirmed

As a BrainDrive owner, I want a PDF of my formatted Resume, so that I can use the same resume outside BrainDrive.

Acceptance criteria
  • AC-11.1 — Given a formatted Resume exists, when the owner chooses Export PDF, the app creates a selectable, text-based PDF from that Resume in the one V1 format and downloads it directly to the owner’s Downloads folder (deterministic code, no model call — D374). The owner sees an unmistakable downloaded signal (a model line naming the Downloads folder, or a control-state change). No PDF artifact, receipt, or sidebar entry is created in the app.
  • AC-11.2 — The PDF preserves the Resume’s logical content and order.
  • AC-11.3 — The exported PDF opens in a standard PDF reader outside BrainDrive, on a standard page size (US Letter or A4), with fonts embedded, and shows the same layout as the formatted Resume. Pass bar: opens without error in one named standard reader; page size and embedded fonts verified; a calibrated reviewer confirms the layout matches on a screenshot taken in that reader, for every required persona run.
  • AC-11.4 — It is obvious how to download the PDF. Given a formatted Resume exists, the owner can find Export PDF from the Resume page without asking, and if they do ask in chat, the model points them to the actual control and, after an export, to the Downloads folder — never to a sidebar location that does not exist. Pass bar: the Export PDF control is visible on the Resume page with a text label; a calibrated reviewer rates owner clarity and control at least 4 of 5 on a “how do I get my PDF?” turn for every required persona run.
  • AC-11.5 — Whenever the model describes where the Profile, Resume, or PDF is, or what state it is in, the description matches the actual interface. The model never names a location, control, or artifact that does not exist. Pass bar: none — any false statement about app or artifact state is a hard failure.

US-12: Recover Without Losing Work — Confirmed

As a BrainDrive owner, I want failures to leave my conversation and documents visible, so that I can continue rather than start over.

Acceptance criteria
  • AC-12.1Migrated to the Host Chat Contract as CHAT-3.1 (v0.9.3), pass bar included; binds by reference through the Inherits line. The ID is retained for traceability; the canonical requirement lives in the contract.

US-13: Understand And Adjust The App — Confirmed

As a BrainDrive owner, I want to inspect the app’s working documents and instructions when I choose, so that I can understand and influence how it works.

Acceptance criteria
  • AC-13.1Migrated to the App-Workspace Contract as APP-4.1–4.3 (v0.9.3); binds by reference through the Inherits line. The ID is retained for traceability. Resume Builder’s declared edit matrix (the app-declared input APP-4.1 tests, ruled D25 2026-09-01): Resume Profile, Agent Instructions, and Interview Guide are directly editable on their pages via the native composer; the formatted Resume is read-only (deterministically generated from the Profile — editing it would break the Profile-as-source-of-truth invariant). Read-only standards documents are presented as read-only per APP-4.3.

US-14: Get Help In The Conversation — Confirmed

As a BrainDrive owner, I want to ask Resume Builder how the process works or what is happening, so that I can understand and make decisions without leaving my resume work to find separate help.

Acceptance criteria
  • AC-14.1 — Given an owner asks about the interview, Resume Profile, formatting, or export during resume work, the model gives a plain-language, context-aware answer in the same conversation. Pass bar: a calibrated reviewer rates owner clarity and control at least 4 of 5 on every required persona run.
  • AC-14.2 — After answering a process question, the model can smoothly return to the owner’s resume work without losing the current conversation, Profile, or next useful step.

The product does not require a front-loaded tutorial.

US-15: Use It Without A Manual — Confirmed

As a BrainDrive owner, I want Resume Builder to be self-guiding, so that I can understand what to do next without reading a separate user manual.

Acceptance criteria
  • AC-15.1 — Given an owner opens or returns to Resume Builder, the ordinary chat and workspace make the next action understandable through familiar BrainDrive patterns, clear labels, and context-appropriate guidance. Pass bar: a calibrated reviewer rates owner clarity and control at least 4 of 5 on the opening turn of every required persona run.

If the owner is unsure, they can ask naturally in chat and receive help under US-14.

US-16: Keep My BrainDrive Memory Current — Confirmed

As a BrainDrive owner, I want meaningful information established while using Resume Builder to update the right part of my BrainDrive memory automatically, so that I do not have to repeat the same work in future BrainDrive conversations or apps.

Acceptance criteria
  • AC-16.1 — Within Resume Builder, the conversing model is Your Agent doing the app’s job. App code remains a separate actor and has no direct owner-memory access.
  • AC-16.2 — Given the model and owner establish grounded, reusable understanding, Your Agent writes it through the host to the appropriate owner-controlled memory home without a routine confirmation prompt. The model announces the update in the same turn.
  • AC-16.3 — Stable cross-cutting facts belong in the owner profile. Career-specific facts belong in Career memory. Another workspace receives a fact only when it is the appropriate home.
  • AC-16.4 — The owner can inspect, edit, or remove the update. Guesses, unresolved conflicts, transient details, and unrelated material do not become settled memory.

Requirements

Functional Requirements

  • Use native BrainDrive chat for all ordinary interview turns.
  • Accept available authorized context, pasted resume or LinkedIn text, or a from-scratch conversation.
  • Ask only for corrections and resume-specific gaps when relevant context already exists.
  • Keep the saved Resume Profile as the sole editable source of resume content.
  • Create or update the Profile only on clear owner intent; never rewrite it silently.
  • Route grounded reusable understanding through Your Agent and the host to the appropriate owner-memory home, announce the update in the same turn, and keep uncertain material unsettled. App code never accesses owner memory directly.
  • Let companion apps read the current Profile only through purpose-limited authorization; they cannot modify it silently.
  • Persist the Profile and distinct formatted Resume in private owner-scoped app storage.
  • Let the owner delete app documents without deleting normal chat. On uninstall, offer keep or permanently delete and default to keep.
  • Before rendering marked gaps or missing essentials, name them and let the owner continue with an honest partial resume or return to editing. Essentials are contact information and at least one experience entry; the check uses gap markers and required-section presence, not a readiness score.
  • Render the current Profile deterministically into one professional, single-column, reverse-chronological Resume.
  • Export a selectable, text-based PDF from the formatted Resume.
  • Keep Conversation, Resume Profile, Resume, and Advanced documents discoverable through native workspace patterns.
  • Preserve durable work after restart or recoverable failure and provide a clear next action.

Model, Tool, Or Automation Behavior

  • Use the owner’s configured BrainDrive model through normal chat; do not expose a separate provider, credential, or model-selection interface.
  • Model owns interviewing, clarifying, interpreting nuance, identifying useful gaps, and writing Profile language.
  • Recognize an owner’s natural intent to create or update the Resume Profile; no required phrase exists.
  • When the interview feels complete, offer to draft the Profile: “I think I have what I need — want me to write up your Resume Profile?”
  • When intent is ambiguous, ask one natural confirmation. Never create or rewrite the Profile silently.
  • Model must not invent employment, education, credentials, metrics, or contact information.
  • Model may improve organization and phrasing without changing owner meaning.
  • When material is uncertain, model clarifies, omits it, or marks it visibly open.
  • App code must not add hidden interview state, readiness scores, or per-message fact-confirmation engines.
  • Create Resume and Export PDF make no model call.

Data, Memory, And Artifact Contract

Data / Artifact Source Owner Read / Write Rules Retention
Conversation Native BrainDrive chat Owner and host Normal host lifecycle; app does not re-project turns Host-managed
Relevant BrainDrive context Current Resume Profile plus any available owner-authorized workspace context, including Career Owner Host provides only resume-relevant context to model, with source provenance; app does not silently browse unrelated material Source document lifecycle
Shared BrainDrive memory Meaningful, grounded, reusable understanding established through Resume Builder Owner Your Agent writes through the host to the appropriate owner-controlled home and announces the update in the same turn: owner profile for cross-cutting facts, Career memory for career facts, or another relevant workspace. App code has no direct memory access; the owner can inspect, edit, or remove the update. Shared owner-memory lifecycle; unaffected by app uninstall
Agent Instructions App package / owner edits Owner Advanced, editable instructions Private workspace; lifecycle evidence pending
Interview Guide App package / owner edits Owner Advanced, editable guide Private workspace; lifecycle evidence pending
Resume Profile Model from owner conversation / owner edits Owner Editable source of truth; owner can delete it independently of normal chat Durable private workspace until owner deletion or an explicit uninstall choice
Companion-app context Current Resume Profile supplied through the host context contract Owner Purpose-limited, owner-authorized read; no implicit access or silent write-back by Job Discovery, Application Preparation, or another app Follows the Resume Profile lifecycle
Resume Deterministic renderer Owner Read-only derivative of Profile; owner can delete it independently of normal chat Durable private workspace until owner deletion or an explicit uninstall choice
PDF Deterministic exporter Owner Derived from formatted Resume; written straight to the owner’s Downloads folder on Export PDF (D374) No separate app copy, receipt, sidebar entry, or history in V1

Interface And Accessibility Requirements

  • Use one app workspace sidebar rather than a nested second sidebar.
  • Keep the native composer available on Conversation and document pages.
  • Provide Back to chat and edit controls consistent with established BrainDrive project pages.
  • Mark Profile as content-editing source and Resume as derivative.
  • Make error and loading states understandable without technical vocabulary.
  • Make navigation keyboard accessible and use text labels in addition to color or icons.

Acceptance And Trust

The rc6 Resume Builder Evaluation Plan owns scenarios, personas, scoring, evidence bundles, and qualification decisions. This specification owns the product outcomes that plan must prove.

Critical Failure Behavior

Scenario Expected behavior
Model unavailable Inherited — CHAT-4.1 binds by reference (was the CF-1 row).
Uncertain material Ask naturally, omit the claim, or mark a visible gap.
Invalid or incomplete Profile Name the missing item. Let the owner edit the Profile, return to chat, or knowingly create an honest partial render.
Rendering failure Keep the Profile and prior Resume unchanged; give a next action.
PDF export failure Keep the Profile and Resume available; allow a later retry without a model call.
Authorized context unavailable Do not imply it was read. Continue with useful questions.
Uncertain memory update Do not save it as settled shared memory. Resolve it in conversation or keep it resume-specific.

Required Evidence

  • A live supported-host from-scratch journey reaches an editable Profile, Resume, and downloadable PDF.
  • A live pasted-text journey reaches the same outcome without file import.
  • A direct Profile correction produces a newly rendered Resume without source drift.
  • PDF parse-back confirms expected text and logical order.
  • Model, render, and export failures preserve saved work and show understandable recovery.
  • Owner-memory evidence identifies Your Agent as the actor, records the host-mediated destination and same-turn announcement, and proves inspection, correction, and removal.
  • Calibrated model-judge and independent-verifier evidence support grounded, useful output and acceptable visual quality.

Logical text and order parity are the automated hard gate. A passing lower layer does not prove the live product. Each acceptance claim must identify whether it comes from code, a built branch or container, or a live install.

Non-Negotiable Trust Boundaries

  • The app never adds a competing chat lifecycle, hidden interview intelligence, or form-like confirmation workflow. (The chat-lifecycle half is inherited — APP-1.1 binds by reference; hidden interview intelligence stays RB-owned.)
  • The system never turns uncertain information into a confident career claim.
  • The workspace remains private and owner-scoped. The app never exposes provider credentials, unrestricted storage, or unrelated personal context.
  • App code never reads or writes owner memory directly. Your Agent performs memory work through host mediation and announces each settled update in the same turn.
  • The owner can review and edit the Profile before formatting. (The lifecycle half — deleting private app documents does not delete chat; uninstall defaults to keep — is inherited: APP-5.1 binds by reference; was the TB-5 row.)
  • Companion apps may use the current Resume Profile only through declared, owner-authorized context. They cannot silently overwrite it, and Resume Builder does not take ownership of their downstream workflows.
  • Do not claim full portable-app conformance until accepted ground-truth evidence exists.

Companion Documents

  • Inherits: Host Chat v0.5 · App-Workspace Contract (APP-n) v0.3. Host Chat is canonical; APP v0.3 remains at its confirmed temporary drafting location pending the App Host §14B move. APP requires Host Chat, so this list is transitively complete.
  • Approved exclusions (Dave W, 2026-09-02): Host Chat US-9 criteria 1, 2, and 3, plus Host Chat US-11 criterion 2. Their exact operands are page spec.md/plan.md artifacts and page spec/plan generation states, which Resume Builder does not create. Do not reinterpret them as Resume Profile or formatted Resume requirements. All other Host Chat v0.5 criteria apply universally or remain conditional according to their own Given clauses.
  • Inherited requirements bind by reference and are never restated here. A Host Chat or APP version change invalidates open evaluation plans pinned here.
  • Job Search Pack Product Overview — combined promise, four-stage journey, standalone value, and composition boundaries.
  • Career workspace specification — career direction, planning, and Career-memory ownership used when available and authorized.
  • Resume Builder Evaluation Plan — v1.0-rc6 consistency/executability candidate: Host Chat v0.5/APP v0.3 mapping, approved exclusions, E-1–E-14 state machine, AI qualification gate, and execution kit. The accepted v0.9 plan remains historical context. The unpublished rc5 plan and kit drafts were never canonical and are superseded by rc6.
  • Build Plan Overview — implementation sequencing and reconciliation work.
  • App Platform Overview — platform scope, host responsibilities, and portability work.
  • Candidate Resume Builder Decisions — rationale and decision history not needed to build or evaluate V1.

Changelog

Date Change Reason Source
2026-09-02 Accepted v0.9.5: Dave W accepted this revision as the Resume Builder product authority. It retains every v0.9.4/D374 PDF decision; pins canonical Host Chat v0.5 plus APP v0.3; excludes only Host Chat US-9 criteria 1–3 and US-11 criterion 2 because their exact page spec.md/plan.md operands do not exist in Resume Builder; prohibits reinterpretation as Profile/Resume criteria; and supersedes the two unpublished rc5 reconciliation drafts. Dave W accepted the complete v0.9.5 authority, including the four narrow exclusions. The Host Chat US-18 authority advanced to v0.5 after the calibration audit. Dave W + Codex, 2026-09-02
2026-09-02 v0.9.4 (unpublished; superseded by v0.9.5): AC-11.1 / AC-11.4 and the PDF data row state the export path — Create PDF is deterministic code that writes the one V1 format straight to the owner’s Downloads folder with a visible downloaded signal; no PDF artifact, receipt, or sidebar entry in the app. AC-13.1’s owner-editable Advanced docs were reaffirmed by D375. DW + DJ ruling on the 9/2 dev call (D374, D375). DW + Claude, 2026-09-02
2026-09-01 v0.9.3: Added the Inherits line (Host Chat Contract CHAT-n v0.3 + App-Workspace Contract APP-n v0.3, both Confirmed, no exclusions) and migrated the inherited requirements out by reference: AC-2.1 → APP-1.1/1.2, AC-6.1 → CHAT-1.1/1.2, AC-12.1 → CHAT-3.1, AC-13.1 → APP-4.1–4.3 (with RB’s declared edit matrix retained in-spec per D25), CF “model unavailable” → CHAT-4.1, delete/uninstall lifecycle → APP-5.1. IDs retained for traceability; no requirement changed meaning or weakened — each moved to its canonical scope so every hosted app inherits it. Inherited requirements need one canonical authority an app spec points at; RB-001’s escapes proved restating them per-app hides them from evaluation. DW + Claude, 2026-09-01 (harness D26/D27; eval-system plan v0.7 Phase D)
2026-08-29 v0.9.2: Pass-bar corrections after Codex pre-flight review: AC-1.2 uses outcome quality only (coach usefulness measures questions, not resume language); AC-5.1 scores the from-scratch runs, not a pack average it cannot compute; AC-11.3 names one standard reader. No behavior change. Bars must be computable by the method that proves them. DW + Claude, 2026-08-29
2026-08-29 v0.9.1: Added AC-11.3 (PDF works outside BrainDrive: standard reader, page size, embedded fonts, same layout), AC-11.4 (Export PDF is obvious to find; the model points to the real control), and AC-11.5 (the model never misdescribes where a document or the PDF is — prompted by Dave J’s finding that the model claimed the PDF was in the sidebar). US-11’s purpose is using the resume outside BrainDrive; the plan could not test that, or the false-location behavior, without the spec owning them. DW + DJ + Claude, 2026-08-29
2026-08-28 v0.9: Gave every acceptance criterion a stable AC-<story>.<n> ID and stated the pass bar for each qualitative criterion (AC-1.1, 1.2, 5.1, 9.2, 12.1, 14.1, 15.1) by promoting the thresholds the evaluation plan v0.9 §6 already applied. Every bar is AI-provable: AC-9.2’s Template Standard §6 checklist is run by the calibrated reviewer, not only at the owner run-through. AC-9.1 now names the Resume Template Standard (D352) as the definition of the standard format. Otherwise no product behavior changed. Pass bars are product authority; the evaluation plan measures them but may not set them. At that revision, a separate owner run-through was described as acceptance rather than proof; EP-1.1 supersedes that process rule with terminal AI qualification. Surfaced as O-1/O-2/O-4 by the /test-plan v2 dry run. DW + Claude, 2026-08-28
2026-08-26 v0.8: Propagated the ratified one-memory/one-actor rule into the Resume Builder contract: Your Agent performs host-mediated memory writes, announces them in the same turn, and app code never accesses owner memory directly. Aligns the product authority with the accepted D348 rule already enforced by the evaluation judge. ../../../../decisions.md D348
2026-08-21 Formalized standalone use and automatic grounded memory continuity as D357–D358, superseding the earlier required-Career-context rule and reconciling the shared Memory Architecture. Makes the two policy changes explicit and reviewable rather than hiding them inside a writing pass. ../../decisions.md D357–D358
2026-08-21 Applied the current concise specification template: reduced duplicated requirements, routed detailed evidence to the evaluation plan, and preserved all accepted story IDs. Keeps the product and acceptance contract buildable without repeating downstream documents. Job Search Pack concise-suite pass
2026-08-21 v0.7: Made standalone value explicit. Career context is used when available and authorized but is no longer described as a required Resume Builder dependency; added the Job Search Pack overview as composition authority. Aligns Resume Builder with the accepted four-workspace journey and optional composition model. Job Search Pack overview reconciliation
2026-08-20 Added the downstream composition boundary for Job Discovery and future Application Preparation. The current Resume Profile can be reused through authorized host context, but companion apps cannot silently modify it and Resume Builder does not own their workflows. Makes the Resume Profile reusable across the Job Search Pack without expanding Resume Builder V1 or creating hidden app coupling. DW direction
2026-08-17 v0.6: Reframed Resume Builder around holistic, owner-controlled BrainDrive memory. Career is the required V1 source; broader workspace context and automatic writes to the appropriate memory home are the target host contract. Prevents the Career page from becoming an accidental architectural boundary while keeping V1 implementation claims honest. DW direction
2026-08-17 v0.5: Resolved the five former open questions: Profile trigger, incomplete Profile handling, renderer boundary, visual-parity release bar, and timing for history and receipts. The governing sections contain the current decisions. DW walked the questions one at a time and ruled on each. DW review session
2026-08-17 Applied a preservation-first readability pass, then reduced the document to the product-and-acceptance contract. Build sequencing, detailed eval mechanics, platform architecture, and decision rationale now live in companion documents. Keeps the V1 contract readable without changing scope, user stories, requirements, or acceptance criteria. DW direction
2026-08-17 Profile shape confirmed: the two-layer model stands (resume-private Resume Profile as the editable render source + automatic grounded Career-memory writes, US-4/US-16); the name stays “Resume Profile.” Eval ownership recorded: this spec and its story-derived eval suite are one DW-owned unit ([[braindrive-repo]] D346). Resolves the Mon dev call’s “career profile” framing against this spec’s deliberate design; one durable career-wide app document was considered and declined. DW review session (D344/D346)
2026-08-16 Reframed as template-based product and engineering spec. Separates product outcome and acceptance contract from retrospective architecture discussion. DW direction
2026-08-16 Added paste-in-chat start; PDF-only V1; deferred tailoring and Job Search Pack work. Bounds V1 around intended owner outcome. DW direction
2026-07-31 Original Job Search Pack Phase 1 spec created. Defined Interview to Resume as initial pack phase. Historical baseline

Approval

  • Reviewed by: Dave W — 2026-08-17
  • Technical reconciliation by: Dave J
  • Ready for Planning:

Next: Review and accept the product contract. Downstream build, current-state, and platform-evidence artifacts carry implementation sequencing and conformance work.

:paperclip: resume-builder-spec-v0.9.5.md — product spec only; the evaluation plan and build plan are not published.

@djjones — Candidate-05 spot check findings, routed by owner (two are yours).

Pre-gate spot check on Candidate-05 (frozen source 4930fcde, app 4.2.21). Verdict: Findings — no trust/safety breaks, no data loss. This was a spot check, not a formal qualification.

For Dave J (code):

  1. En-dash → hyphen in the exported PDF — AC-11.3 exact-character-preservation fails. Root cause: builds/resume_builder/src/chat-workspace.ts:1027normalizePdfText maps the U+2012–U+2015 en/em-dashes to ASCII - (and folds curly quotes), so the two date-range en-dashes render as plain hyphens.
  2. Sparse page-2 pagination — Certifications + Skills land on page 2 with large unused space.

For Dave W (instruction):

  1. Grounding over-claim — the model invented a “Survey design” skill unsupported by the persona’s ground truth (caught and corrected in-run).
  2. Imprecise export-control wording — the model described the Export PDF control’s location loosely.

Harness (eval-infra): the pre-export judge timed out at 120s (no score produced) — under investigation.