Nothing in the framework checks a posting's language requirements
against what the candidate actually speaks. It is not one of the five
Scoring Dimensions in 04-job-evaluation.md, it is not checked in
/scrape's Step 3 fit assessment, and it is not a field in /rank's JSON
output - even though /apply's Step 1 already extracts a posting's
required language generically, with nowhere to report a mismatch to.
This adds a Language Gate, structured like the existing Eligibility
Gate (read the posting, classify against profile data, hard-stop on a
real mismatch), built on a new structured Languages table in CLAUDE.md
/ 01-candidate-profile.md. /setup now asks for it directly (Path C), or
infers it from a CV/LinkedIn export (Paths A/B - LinkedIn exports
already carry a self-rated Languages section).
The gate compares a posting's stated language requirements against
that table with three outcomes:
- Requires a language not declared at all -> hard FAIL, never
presented.
- Requires a higher level in a language that is declared (e.g. "fluent
English" against a declared B1/B2) -> FLAG, not an auto-reject -
scored and drafted normally, with the gap surfaced so the candidate
judges it themselves (a "fluent" bar reads very differently from a
strict employer vs. one that's flexible on it).
- Requires a language at or below the declared level -> clean PASS.
Wired through the three places that need it: /scrape (Step 3), /rank
(new language_gate/language_note fields alongside the existing
location veto - both are now persisted to seen_jobs.json, not just
used transiently to decide one run's shortlist), and /apply (Step 1's
language extraction now has somewhere to report to).
Out of scope, deliberately: this does not touch the free-form
Deal-breakers list or how it's used elsewhere (e.g. Scoring Dimension
4's relocation check) - that's a separate question this change takes
no position on.
Validated with two live-testing passes against real, unfetched
postings (not fabricated text) across 3 portals and 3 market languages
(Danish, German, Spanish/Argentina): 8/8 postings gated correctly in
the first pass, including ambiguous real-world wording ("you
communicate well in English") a rigid rule would have gotten wrong. A
second pass, run specifically to force a hard-FAIL case, found one
(a Danish posting requiring the ability to read Danish) and confirmed
it persists correctly and would be excluded from /rank's shortlist.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
12 KiB
Changelog
All notable changes to this project are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Releases are vetted checkpoints of master. If you maintain a personalized fork,
prefer updating to a tagged release over pulling raw master (see
SETUP.md, section 8). The
framework_version markers on methodology files tell you which of your customized
files a release touched; python3 tools/check_upstream_updates.py lists them with
per-file diff commands.
Unreleased
Added
- Language Gate - no dimension or gate anywhere in the framework checked a posting's
language requirements against what the candidate actually speaks (not a Scoring Dimension,
not a
/scrape//rankfield, nothing for/apply's existing generic language detection to report to). Adds that check, structured like the existing Eligibility Gate, on a new structuredLanguagestable in CLAUDE.md /01-candidate-profile.md(/setupasks, or infers it from a CV/LinkedIn export): a posting requiring a language you haven't declared at all is a hard FAIL; one requiring a higher level than you declared in a language you do work in is FLAG, not an auto-reject, so borderline cases (a strict "fluent" bar vs. your own B1/B2) get your judgment instead of a silent drop; a requirement at or below your declared level is a clean PASS. Wired through/scrape,/rank, and/apply, withlanguage_gate/language_notepersisted intoseen_jobs.jsonalongside the existinglocationveto so a re-read of the file (or a future debugging session) can recover why a job did or didn't make the shortlist.
Security & privacy
- The gitignore guard now covers every personal-output rule -
security_guards.pyadditionally requires the ignore rules for Gmail sync state (gmail_sync/), generated dashboards (reports/), upskill reports (upskill/*.md), Notion sync state (**/job_scraper/notion_sync.json), pasted postings (documents/postings/**), scraper markdown output (**/job_scraper/*.md), and behavioral-report / LinkedIn-profile PDFs. With these, every.gitignorerule outside the guard's required list is build tooling noise, so any future weakening of the personal-data boundary fails CI. All rules were already present in.gitignore; the guard now enforces the full set. (#271)
[1.2.0] - 2026-08-01
Added
/ranknow persistsstrengthsandgapsintoseen_jobs.json- Step 2's scoring agents already produced both arrays per job; Step 4 previously kept onlyrank_score,rank_verdict, andrank_date, so the honest per-posting findings were printed once in Step 5 and then discarded. Both arrays are now stored verbatim and replaced (never accumulated) on--allre-ranks, so downstream consumers ofseen_jobs.jsoncan read real triage findings instead of re-deriving them. See discussion #258./upskillaggregate mode now ingests/rank's recorded gaps - previously it only readjob_search_tracker.csvand guessed required skills from therole/sector/notescolumns, even though/rankhad already fetched and scored postings that never made it into the tracker. Aggregate mode now also reads ranked entries (rank_score >= 45) fromjob_scraper/seen_jobs.json, dedupes them against tracker rows on case-insensitive company+role, and prefers a job's recordedgapsover an inferred skill list wherever both exist. The heatmap's Gap Source column now shows the recorded-vs-inferred split per skill, and the report header states how many jobs came from each source. Depends on #263 (/rankpersistinggaps/strengths); see discussion #258.
Security & privacy
- SETUP.md no longer calls a fork "private working space" - forks of public GitHub
repositories are always public, so that wording invited exactly the personal-data
exposure it seemed to rule out. Section 8 now states the fork-is-public fact plainly and
documents the safe alternative (a private repository with this repo as
upstream), and/setupends with a matching privacy note the moment profile data first lands in tracked files. Prompted by discussion #266. - The gitignore guard now covers two more personal-data rules -
security_guards.pyrequirescover_letters/Cover_*.*(the uppercase cover-letter naming variant/applyrecognizes) andcv/*.txt(ATS text extractions of tailored CVs) in.gitignore, so a future change weakening either rule fails CI instead of silently making personal files trackable. Both rules were already present in.gitignore; only the guard lagged.
Fixed
tools/check_upstream_updates.pyno longer reports a false "up to date with upstream" when it silently falls back to a fork's ownoriginremote - the default state of a plain fork clone, where the script compared the fork against itself and could never detect upstream updates. It now warns that the fallback remote is not the template repo, shows thegit remote add upstreamcommand to fix it, and names the ref it actually compared against. (#265)- Removed the vestigial
cover_letters/OpenFonts/cover.cls- an unreferenced remnant of the original font bundle that, since #252's class rename, ambiguously declared the samecoverclass as the realcover_letters/cover.cls. - Added regression tests pinning #252's ragged-row bounds fix in
tools/convert_salary_excel.py(dimension-less workbooks read inread_onlymode yield rows shorter than the header).
Changed
- CONTRIBUTING's "run what CI runs" list is now complete - it previously omitted
tools/security_guards.pyand the exactunittestinvocation, the precise checks a contributor PR had already failed on. Prompted by issue #262.
[1.1.0] - 2026-07-30
Security & privacy
- Personalized custom-template files are now gitignored regardless of engine - the
ignore rules broadened from
cv/main_*.textocv/main_*.*(and likewise for cover letters), so a fork using a Typst or other non-LaTeX template no longer commits personalizedmain_<company>.typfiles to a public fork. The*_example.texfiles stay tracked. If you registered a custom template before this release, checkgit statusonce after updating. (#238) - Dependency review is live, for forks too - the repo's Dependency graph is now enabled,
so the CI
dependency-reviewjob actually blocks PRs that introduce dependencies with known high-severity vulnerabilities, and the job is no longer gated to the upstream repo: forks get the same check, self-activating if the fork enables Dependency graph (it warns-and-passes otherwise). (#254)
Added
- freehire-search: full descriptions come back with the search -
searchnow calls freehire's agent search endpoint (/api/v1/agent/jobs/search), which serves each hit's complete description instead of the search index's truncated preview. A 20-role search is one request rather than 1 + 20detailcalls, and/scrape's Step 2 no longer needs a per-hit fetch for this portal.--description-format markdown|text|html(defaultmarkdown) selects the rendering;tableandplainoutput is unchanged. (#251) - Custom templates: any compile-to-PDF toolchain (Typst, ...) -
/add-templateno longer hardcodes alualatex/xelatex/pdflatexengine enum. Custom templates now declare a source extension and a full compile command, so Typst (typst compile) registers the same way a custom LaTeX template does. Stock CV/cover letter templates stay LaTeX, unchanged. (#238) - Application-form fields as an optional third
/applyartifact - when a posting's application form asks screening questions,/applycan now offer a prep sheet of grounded answers alongside the CV and cover letter. Opt-in; the default two-document output never changes. (#212) - Confirmed facts write back to the profile - when
/applyor/interviewsurfaces a fact the user confirms (a skill, a date, a project detail), it is written back to the profile files in the same turn instead of being lost with the conversation. (#211) - CV methodology: in-progress qualifications and tenure-vs-output -
05-cv-templates.mdgains explicit rules for stating in-progress certifications/degrees honestly and for checking claimed tenure against visible output (framework_version1.2.1 -> 1.3.0). (#210) - Scraper flags mass-posting and recycled-listing patterns -
/scrapemarks postings that look bulk-posted or recycled so they don't eat evaluation effort. (#207) - Retry contract pinned in CI - all six portal CLIs now carry 429/5xx retry-backoff tests covering every fetch wrapper, so a silent regression in retry behavior trips CI. (#246)
- README: the extension model, documented - new Customization subsection "Extending the framework: portals, templates, criteria - and borrowing from other forks": the three extension points, the copy-one-folder pattern for borrowing a portal skill from another fork with a read-the-code-first checklist, and why there is deliberately no installer (the manual copy is the security model). Prompted by discussion #249.
Fixed
/rankshortlist and below-threshold tables include each posting's URL. (#236)convert_salary_excel.py: count/index columns pair by category name instead of adjacency (#219), standalone count columns store as counts (#230), and ragged rows from dimension-less spreadsheets no longer crash with an IndexError (#252).cover.cls: duplicate package imports removed and the\ProvidesClassname fixed to match the filename, silencing a class-name-mismatch warning. (#252)- Portal CLI type-checking pinned to concrete
@types/bun/@bunli/*versions to stop environmental CI type-drift. (#226) freehire-searchpoints at freehire.me after the service's domain migration. (#229)verify_pdf.py's missing-poppler error now includes per-OS install hints. (#252)
1.0.0 - 2026-07-22
First tagged release. This marks the framework as stable and gives forks a described
checkpoint to update against instead of a moving master. It is a baseline of what
already exists rather than a set of new changes; subsequent releases will document
what changed since the previous tag.
At this baseline the framework provides:
- Application workflow - a drafter/reviewer
/applypipeline (CV + cover letter), plus/setup,/scrape,/rank,/interview,/outcome,/upskill,/expand,/html-report,/gmail-sync,/notion-sync,/add-portal,/add-template, and/reset. - Portal search skills - country-agnostic job-board CLIs (LinkedIn, freehire, and
the Danish boards) in the portable Agent Skills format under
.agents/skills/, discovered and orchestrated by/scrape, with anenabled:toggle for skipping portals. - Framework versioning -
framework_versionmarkers on methodology files plustools/check_framework_version.py(CI guard) andtools/check_upstream_updates.py(fork-side update preview). - Privacy and safety guards -
.gitignoreprotection for personal data, thetools/security_guards.pyallowlist for.gitignorenegations, and a CI policy of making no live portal requests. - Cross-runtime support - a root
AGENTS.mdpointer so Codex and Antigravity can discover the portable portal skills, with Claude Code as the reference runtime.