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

.agents/skills/make-resume/SKILL.md

@@ -3,88 +3,8 @@ name: make-resume
 description: Generate a tailored evidence-first resume from a real job description. Use for new applications to assess hard qualifications and role fit before writing, select International Tech or Swiss/DACH format, plan canonical achievements, generate LaTeX, validate claims, compile, and record the application decision.
 ---
 
-# Generate a Resume
+# Shared project workflow
 
-## Input
+Read and follow [the make-resume workflow](../../../resume_builder/reference/workflows/make-resume.md) before doing this task. Resolve project paths from the repository root.
 
-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;
-- the selected cohort category is already full;
-- 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:
-
-```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`.
+This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.