0 Fork 0

Files

T

dennisthiessenandClaude Opus 5 afdef7eb94 refactor: shared agent workflows (F01) and one application registry (F02)

Checkpoint for the 2026-09-11 project review remediation. Work by a previous
agent that ran out of context; committed unchanged as a rollback point before
the remaining findings land on top of it.

F01 — the two agent directories had drifted into different processes
- Six shared workflows under `resume_builder/reference/workflows/`; both
  `.agents/skills/` and `.claude/skills/` are now thin entrypoints that route
  to the same file instead of carrying full copies.
- The `.claude` copies were the stale side: fixed bullet line variants and
  character budgets that the newer process had already dropped. Removing them
  is the point of the change, not collateral.
- Parity/link regression test added; corrected the top-level file map, which
  pointed at a directory that does not exist.

F02 — application status was stored in four places and disagreed
- New registry `job_scout/state/applications.json` (26 records) with
  `application_records.py` (schema, validation, transactional write) and
  `application_tracker.py` (add/update, no quota).
- AGENTS.md and CLAUDE.md no longer keep their own status tables; both point
  at `current_applications.md`, generated from the registry.
- Interview-reached is now independent of outcome, so a withdrawal after an
  interview can record both facts. The old tables are preserved verbatim in
  `job_scout/state/history/application_status_before_2026-09-11.json`.

Verification: `python -m unittest discover -s tests -v` — 18/18 pass.
Spot-checked that the detailed SBB and Kdo Cy notes survived the migration
into the registry rather than being flattened.

Known unresolved, deliberately not invented (see FIX_PROGRESS.md):
Aker BP's application date and its Adjacent-despite-79 classification.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM

2026-09-11 19:23:13 +02:00

3.4 KiB

Raw Blame History

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

Read resume_builder/reference/shared_ops.md.
Read resume_builder/canonical/claims.json completely.
Read config.md, AGENTS.md, application_strategy.md, resume_reference.md, and critique_framework.md.
Run python resume_builder/helpers/validate_resume_system.py.
Verify and save the verbatim JD; record source/date/status.
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 International Tech by default. Use Swiss/DACH or Employer-specific format only when the employer/context supports it.

Read the matching role bundle, skills_taxonomy.md, achievement_reframing_guide.md, and only the experience files needed for selected claims.

Plan:

Optional 2--3 line summary.
Four to six evidence-backed skills lines.
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:

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.

3.4 KiB Raw Blame History