resume-version-manager

Resume Version Manager

With the private resume-facts.yaml as the sole source of truth, create traceable and comparable master and customized versions for each submission. HTML/PDF are deliverables generated from confirmed facts and do not replace the factual record.

It does not occupy the user's main workflow entry point: simply record the version after the master version is confirmed or the JD-customized version is confirmed; display version operations only when the user needs to compare, restore, or maintain submission records.

Read first

Read Resume Fact Contract、JD Match Report Template and Writing Standards。

Workflow

Find or create the private resume-facts.yaml and a clearly identified master version; the fact file stores all of the candidate's confirmed claims and must not be overwritten by customization operations.
Create a separate directory for one company/position/JD:tailored/<公司名>-<岗位>/。
Record the parent version, target JD, creation date, candidate facts used, reordered items, rewritten items, keyword sources, unmatched requirements, and fields pending confirmation.
Generate the version's resume_visual.html, and if necessary generate the resume_ats.html and matching-analysis.md; verify PDF page count, extractable text, and HTML overflow, and only record a valid manifest whose hash corresponds to the current file.
When comparing versions, group by facts, order, wording, and style; when factual inconsistencies are found, mark the conflict and request candidate confirmation.

Git Version History (Recommended)

Place resume/ in alocal private Git repositoryand use commits to confirm facts and submission versions; do not push to a public remote repository by default, as resumes may contain contact information and other personal information.

After the candidate confirms a master version change, create a clearly described commit, for example:更新母版：补充 RAG 项目。
After each confirmation generates a customized version, create a commit, for example:定制：字节跳动 - 前端实习生。
When comparing, restoring, or auditing, rely on commit differences; the comparison scope should still be grouped by facts, order, wording, and style, and factual conflicts should be confirmed first.
Create a branch only when the candidate wants to try mutually exclusive master version directions at the same time; ordinary JD customizations are saved in the tailored/ directory and traced with commits.
Do not automatically perform Git initialization, commits, pushes, or overwrites; before every operation that changes version history, explain the scope and obtain candidate confirmation.

Recommended Checklist

resume/
├── resume.html                         # 母版
└── tailored/
    └── <公司名>-<岗位>/
        ├── resume_visual.html
        ├── resume_visual.pdf
        ├── resume_ats.html            # 按需生成
        ├── resume_ats.pdf             # 按需生成
        ├── matching-analysis.md
        └── version-notes.md

version-notes.md Record at minimum: parent version, resume-facts.yamlused, JD source/date, change summary, keyword sources, unmatched requirements, fields pending confirmation, and export verification results.

If Git is used,version-notes.md should also record the corresponding commit ID, so it is easy to trace from the customized version back to the master version facts and generation basis.

Constraints

A customized version may only reorder, emphasize, or rewrite confirmed facts; writing back to the master version requires an explicit user request.
Naming may use 姓名_岗位_公司_YYYYMM.pdf, but the target platform's requirements take precedence.
Do not "organize" the workspace by deleting historical versions, silently overwriting files, or falsifying version records.