dennisthiessenandClaude Opus 5
34299bce54
Second-pass review of this session's work by another agent. It corrected several
real mistakes of mine and finished F06 gaps I had left open. Reviewed, verified
and committed as-is.
THE MISS THAT MATTERS
`job_scout/state/applications.json` — the authoritative application registry
introduced by F02 — was never actually tracked. `job_scout/state/*` in
.gitignore silently excluded it, so my checkpoint commit afdef7e claimed to add
it and did not. Only `application_cohort.json`, the GENERATED projection, was
version-controlled; the source of truth and the migration history backup were
not. .gitignore now carries explicit negations for both.
MY ERRORS, CORRECTED
- "kastellaun" was in CH_LOCATION_KEYWORDS. Kastellaun is in Rhineland-Palatinate.
I took it from a Bundeswehr reserve listing and filed it under Switzerland -
precisely the class of bug F12 existed to fix.
- The F12 fix only widened the keyword list; SmartRecruiters still discarded the
structured country, which was the concrete case the review named
(city=Baar, country=CH). The adapter now preserves it, and a COUNTRY_NAMES
mapping gives country precedence over a bare town name.
- F15 was applied to Taleo and Prospective only. Greenhouse still wrote
`updated_at` into `posted`; it now uses `published_at` and carries provenance.
- My negation guard `\b(no|not|...)\b[^.;]{0,60}$` was too loose - an unrelated
"not" within 60 characters could mask a real claim. Tightened to require the
negation to govern the term.
- F18's retirement of the macro-count rule missed "Four to six compact skills
lines" in the workflow; removed now.
F06 GAPS I LEFT OPEN, NOW CLOSED
Date-format validation on education/employment periods (the 2035-99 case named
in the review), evidence-structure validation, referential integrity on evidence
source files, and the missing-identity KeyError.
F10 TAKEN FURTHER, AND RIGHTLY
I demoted the US-GPA fields to *_orientation_only. They are now removed
entirely, with grade_output_rule saying what to do instead: use the German grade
and scale, and if a recipient requires a US GPA, use THEIR method and record it.
Keeping a number derived by a non-recognised method invites its use.
Also: the Capgemini omit-preference now sits in experience_capgemini.md itself,
alongside the instruction not to fill or explain the intentional gap.
BIS BASEL - REJECTED 2026-09-11
jr100429, applied 2026-07-10, no interview, no reason given. Recorded in the
registry with a dated event and in the decision log; the "prep interview brief
when screening lands" next action is cleared. This also settles the 2026-09-04
observation that the req had vanished from the BIS board - it was a real
rejection, not just a closed posting.
VERIFICATION I RAN MYSELF BEFORE COMMITTING
49/49 tests. Validator PASS with 0 advisory warnings. Package manifest and
registry views current. All 12 F12 location cases still correct, including
Kastellaun now rejecting. The F05 counter-proof still catches all 9 violations.
SBB, NVIDIA, RUAG and Kdo Cy resumes still scan clean. Diffs are net-additive
across every reference file - the deletions are replacements, not losses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
<!-- Shared workflow version: 2026-09-11 -->
|
||
|
||
# Generate a Resume
|
||
|
||
## Input
|
||
|
||
Accept a JD file, pasted JD, or URL. Obtain the real posting text before analysis. If it cannot be retrieved, ask the user to paste it; never reconstruct it.
|
||
|
||
## Phase 0 — Canonical and JD Preflight
|
||
|
||
1. Read `resume_builder/reference/shared_ops.md`.
|
||
2. Read `resume_builder/canonical/claims.json` completely.
|
||
3. Read `config.md`, `AGENTS.md`, `application_strategy.md`, `resume_reference.md`, and `critique_framework.md`.
|
||
4. Run `python resume_builder/helpers/validate_resume_system.py`.
|
||
5. Verify and save the verbatim JD; record source/date/status.
|
||
6. Create the output folder and session from `session_file_template.md`.
|
||
|
||
## Phase 1 — Fit Gate Before Writing
|
||
|
||
Build a requirement table with Required/Preferred and Direct/Adjacent/Gap/Constraint classifications. Cite canonical claim IDs for every Direct or Adjacent match.
|
||
|
||
Compute Evidence Fit and identify hard gates using `critique_framework.md`. Then assign:
|
||
|
||
- Core.
|
||
- Adjacent.
|
||
- Stretch.
|
||
- No-go.
|
||
|
||
Record Channel Strength and a warm-channel action for Core roles.
|
||
|
||
Stop and present the fit decision before resume planning when:
|
||
|
||
- a hard gate fails;
|
||
- the role is Stretch;
|
||
- a practical constraint is unresolved.
|
||
|
||
Proceed on a no-go only after the user explicitly overrides the stated reason. An override does not change the fit classification.
|
||
|
||
## Phase 2 — Audience and Content Plan
|
||
|
||
Select the audience profile from `resume_reference.md`: International Tech, Swiss/DACH, Denmark, Norway or Employer-specific. Employer requirements take precedence.
|
||
|
||
Read the matching role bundle, `skills_taxonomy.md`, `achievement_reframing_guide.md`, and only the experience files needed for selected claims.
|
||
|
||
Plan:
|
||
|
||
- Optional summary sized to the selected audience profile.
|
||
- Compact evidence-backed skills block, normally 4–8 rendered lines, verified in the PDF.
|
||
- Swisscom 4--5 bullets.
|
||
- Bosch 3--4 bullets.
|
||
- Zero or one bullet for each older role.
|
||
- Normally 11--14 bullets total, with no page-fill quota.
|
||
|
||
For each proposed bullet show canonical ID, evidence type, scope, and why it belongs. Identify any impact metric that still needs user confirmation.
|
||
|
||
Apply `cl_reference.md` and propose `Cover Letter Decision: YES/NO` with one reason.
|
||
|
||
Present the plan and wait for explicit user confirmation before generation.
|
||
|
||
## Phase 3 — Generate
|
||
|
||
Copy `resume.cls` and `resume_template.tex` into the output folder. For a Swiss/DACH audience, also read `resume_template_dach.tex` as an audience-policy overlay; it is not a standalone document. Write fresh content from canonical claims and experience records; never copy a historical output.
|
||
|
||
Rules:
|
||
|
||
- Employer, formal/transparent title, dates and location come first.
|
||
- Do not use tailored themes as job titles.
|
||
- Mix natural bullet lengths.
|
||
- Use only verified metrics and outcomes.
|
||
- Preserve allowed verbs and ownership scope.
|
||
- Never add a skill to mirror the JD.
|
||
- Certifications appear once.
|
||
|
||
## Phase 4 — Validate and Inspect
|
||
|
||
Run:
|
||
|
||
```powershell
|
||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
|
||
```
|
||
|
||
Fix every failure. Compile the LaTeX, inspect both pages, and run `pdftotext` to verify parsing and information order. Do not add filler to reduce whitespace.
|
||
|
||
Update the session with the as-built content, validation results, page count, cover-letter decision, and next action.
|
||
|
||
Present the finished resume and the original Evidence Fit classification. Wait for approval. If the cover-letter decision is YES, point to `/make-cl`; otherwise point directly to `/critique`.
|