dennisthiessenandClaude Opus 5
afdef7eb94
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
80 lines
2.7 KiB
Markdown
80 lines
2.7 KiB
Markdown
<!-- Shared workflow version: 2026-09-11 -->
|
|
|
|
# Build or Update the Knowledge Base
|
|
|
|
## Authority Model
|
|
|
|
The pipeline is:
|
|
|
|
`source documents -> extractions -> canonical claims -> experience records/bundles -> generated applications`
|
|
|
|
Generated applications never flow backward into the KB.
|
|
|
|
Read `resume_builder/canonical/claims.json`, `config.md`, and all relevant extractions before changing normalized sources. Preserve raw source documents. A verified correction must update canonical claims first and then every dependent normalized file.
|
|
|
|
## Canonical Claim Record
|
|
|
|
For each employment item or achievement, record:
|
|
|
|
- stable ID;
|
|
- employer, title, dates and location;
|
|
- factual scope;
|
|
- individual vs shared ownership;
|
|
- allowed verbs;
|
|
- forbidden overstatements;
|
|
- metric/result and verification status;
|
|
- evidence source;
|
|
- last verified date.
|
|
|
|
When ownership is ambiguous, use contributing/shared scope and ask the user. Do not default to full ownership.
|
|
|
|
## Experience Files
|
|
|
|
Experience files explain facts and context. They may contain example phrasings, but those examples cannot override canonical scope and should not be optimized to fixed line counts.
|
|
|
|
Every achievement section must include canonical ID, source, ownership scope, status, verified result/metric state, relevant skills and role relevance.
|
|
|
|
## Skills Taxonomy
|
|
|
|
Use only these evidence levels:
|
|
|
|
- Production — current.
|
|
- Production — historical.
|
|
- Hands-on — current.
|
|
- Project / proof of concept.
|
|
- Certification / coursework.
|
|
- Unverified / never used.
|
|
|
|
Do not assign Expert/Proficient/Familiar labels. Add a skill to canonical claims before it can appear in a generated document.
|
|
|
|
## Role Bundles
|
|
|
|
Each bundle must contain:
|
|
|
|
1. Defensible positioning.
|
|
2. Good-fit roles and hard-gate cautions.
|
|
3. Achievement priorities.
|
|
4. Safe reframing rules.
|
|
5. Evidence-backed skills guidance.
|
|
6. Conditional cover-letter guidance.
|
|
|
|
Bundles may rank evidence; they may not broaden it. Title-defining gaps must be stated explicitly.
|
|
|
|
## Significance Context
|
|
|
|
Keep company/industry context separate from candidate impact. Mark external claims for re-verification at application time. Never attach generic scale, economics, customers or market trends to the candidate.
|
|
|
|
## Correction Propagation
|
|
|
|
After any correction, search canonical claims, config, extractions, experience files, bundles, support files, templates and active drafts. Historical submitted outputs remain unchanged but update `historical_outputs.json` when they become unsafe for reuse.
|
|
|
|
## Validation
|
|
|
|
Run:
|
|
|
|
```powershell
|
|
python resume_builder/helpers/validate_resume_system.py
|
|
```
|
|
|
|
Then review the diff for dates, titles, ownership, metrics and skill evidence. Present the changed claim records and affected downstream files to the user for confirmation.
|