# Interactive Tailoring Workflow

Use this when the user provides a job description, target company, target role,
or asks for a tailored resume.

## Contents

1. Operating mode
2. Strategy checkpoint
3. Evidence checkpoint
4. Bullet checkpoint
5. Assembly checkpoint
6. Finalization checkpoint
7. One-shot and multi-job modes

## 1. Operating mode

Default to collaborative tailoring. The common request `Here is a JD; make me a
resume` does not authorize skipping directly to a polished final document.

Use:

```text
JD -> strategy -> evidence map -> locked bullets -> assembled draft -> final
```

Pause at each checkpoint so the user can correct the story before formatting
makes weak choices feel settled.

Only enter one-shot mode when the user explicitly asks for it. Label the output
as a draft, identify missing evidence, and do not mark it final without approval.

## 2. Strategy checkpoint

Read the JD as evidence of the business problem behind the hire. If given a URL,
open the current posting. Prefer the JD and primary company sources.

Determine:

- what the hire must make true in the first 6-18 months
- company stage, product, customer, business model, and functional maturity
- role altitude, autonomy, pace, ambiguity, and likely comparison set
- hard screens, daily work, and cultural signals
- what a recruiter, hiring manager, and executive each need to believe

Present a concise strategy readout:

```text
They need:
Candidate story:
Proof pillars:
Main screening risks:
What to emphasize:
What to de-emphasize:
Tone:
```

Explain non-obvious inferences. Ask for corrections and stop before choosing the
final bullet set.

## 3. Evidence checkpoint

After the story is accepted:

1. Search `resume_vault.json` first for explicitly approved achievements.
2. Search `resume_library_db.json`, the target draft, master resume, source
   library, and nearby tailored variants for additional candidates.
3. Treat broad-library bullets as leads, not verified canonical facts.
4. Compare evidence against the accepted proof hierarchy.

Present:

- proposed experience order
- bullet budget by role
- strongest evidence for each proof pillar
- bullets to reuse, rewrite, cut, or excavate
- unresolved accuracy or narrative gaps

Do not assemble the full resume until the user has had a chance to redirect the
portfolio.

## 4. Bullet checkpoint

Work one bullet at a time unless the user explicitly approves batch review.

For each bullet:

1. State what the bullet must prove in the target story.
2. Show the current evidence or source wording.
3. Diagnose ownership, result, scale, maturity, restraint, specificity,
   industry recognition, and truth.
4. Read `impact-excavation.md` and ask one hypothesis-led question when evidence
   is missing.
5. Propose the strongest interview-defensible wording.
6. Obtain explicit approval.
7. Persist the locked bullet immediately using `persistence-and-state.md`.

Do not bank alternatives, speculative metrics, or merely generated candidates.

After each role, recommend bullet order and confirm that the role proves
distinct capabilities rather than repeating one message.

## 5. Assembly checkpoint

Assemble only locked bullets into the editable Markdown source. Preserve the
canonical format unless an accepted strategy decision requires a departure.

Show the complete draft and run:

- 20-second scan: which three messages remain?
- proof coverage: does the first half prove the central mandate?
- narrative continuity: does each section advance one story?
- screening-risk check: is the main concern resolved without defensiveness?
- portfolio check: does every bullet earn its space?
- truth check: are metrics, titles, causality, and ownership supported?

Any edit to a locked bullet reopens it. Explain the reason and obtain a new
approval before updating its canonical vault entry.

## 6. Finalization checkpoint

Do not render or mark the resume final until the user explicitly approves the
assembled content.

Then:

1. Mark all current bullets content-approved through the workflow tool.
2. Render DOCX and PDF using the repository renderer.
3. Verify one-page fit, two-line targets, orphan tails, and page fill.
4. Visually inspect the rendered page.
5. Update the completion log.
6. Rebuild the broad library.
7. Record the exact source and export hashes as `rendered-final`.

Any later source edit invalidates `rendered-final` and returns the resume to
`draft`.

## 7. One-shot and multi-job modes

For explicit one-shot mode, perform strategy and evidence selection internally,
but return a draft with assumptions and gaps. Do not persist generated bullets
until approved.

For multiple JDs:

1. Build a shared evidence-gap map.
2. Reuse discovery only where the underlying achievement is the same.
3. Run a separate strategy checkpoint for each materially different role.
4. Keep approved achievement facts shared while allowing target-specific
   wording variants.