* docs(add-portal): specify credential handling for portals needing an API token /add-portal can already scaffold a skill for a portal that returns usable content only through a paid fetching service, but the spec says nothing about the credential such a skill needs: no guidance on where it lives, no requirement to document it, no defined failure mode when it is unset, and no point at which the user learns the portal costs money per query. Three additions, all to the generator spec: - Step 2 gains a reconnaissance point for whether the portal needs a credential at all, to be raised with the user before scaffolding. A portal that bills per query is a different proposition from a free one and the user should get to decline it. - The portal-skill contract gains a Credentials rule: environment variable only, named <SERVICE>_API_TOKEN, never a CLI flag (flags leak into shell history and process listings), never in url-reference.md or a fixture, and a MISSING_CREDENTIALS exit rather than a fallthrough to an unauthenticated request that fails confusingly. - SKILL.md for such a skill must carry a Setup section naming the service, the variable, and the per-call billing. Spec only. All six shipped portals are free and unauthenticated, so no existing skill changes and the zero-dependency default is untouched. Evidence this is not speculative: running /add-portal against portals that sit behind bot-detection produced four token-requiring skills in my own fork (Bright Data Web Unlocker), each of which had to invent its own convention for reading, documenting, and failing on the token, because the spec defines none. Verified: lint_skills, check_framework_version, security_guards all OK; python3 -m unittest discover -s tests 196 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(add-portal): subordinate the credential check to the robots.txt decision Review catch: as written, Step 2.5 could be read as "robots.txt or the terms said no, but a paid unlocker gets through, so here is the convention for that" - which would let a paid fetcher launder a robots refusal. That is not the intent and it contradicts the posture settled in #277/#286 (09-web-research.md, tools/robots_check.py): robots.txt is decided first and honestly, and is never overridden by better fetching machinery. State the subordination explicitly in 2.5 rather than leaving it implied by step order, and record it in the changelog entry so the constraint survives later edits to the step. The credential path is for portals whose robots.txt permits access but whose bot protection blocks ordinary fetches - paying for access a site allows, never paying past a site's no. Wording follows the reviewer's suggestion. Verified: lint_skills, check_framework_version, security_guards all OK; python3 -m unittest discover -s tests 219 passed. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
31 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
security_guards.pynow holds.claude/settings.jsonhooks to an allowlist - the guard readpermissions.allowand nothing else, so ahooksblock in the same file passed silently. A hook is strictly more dangerous than a pre-approved permission: a permission pre-approves something Claude may choose to do, while a hook runs unconditionally when its event fires, with no prompt and no model decision in between. This is not hypothetical - it is the vector the Shai-Hulud worm used in its August 2026 wave, planting aSessionStarthook in.claude/settings.jsonthat executed on session start (JFrog research). For a template thousands of people are invited to fork, that is the riskiest key in the file the guard already parses.ALLOWED_HOOKSships empty (the template has no hooks), the check runs before the permissions shape guards so a malformed permissions block cannot return early and skip it, and unrecognised hook layouts fail closed rather than being skipped. Eight newHookGuardTestscases; 14 of the suite's 26 tests fail against the unpatched guard.
Changed
- CI discovers portal CLIs instead of hardcoding them (#310). The
cli-checksmatrix is now emitted by adiscover-clisjob that finds every.agents/skills/*/cli/package.json, so a portal skill added with/add-portalgets itstypecheckandtestscripts run by CI automatically - on this repo and on any fork - without editing the workflow. Upstream coverage is unchanged (the discovered list onmasteris exactly the six shipped portals)./add-portal's Register step now says so. Thanks @ayobamiseun.
Fixed
-
/applyarchives the job posting while it still holds it (#306)./applydrafted two documents and a tracker row from the full posting, then let the text die with the session;/outcomeStep 3.2 tried to recover it by re-fetching asourceURL the spec itself expects to be dead, and a posting pasted from an email or a PDF had nosourceto re-fetch at all. Step 6b item 7 now writes the posting verbatim todocuments/applications/<company>_<role>/job_posting.md, never a re-fetch or a reconstruction from memory; an existing file is left alone (a re-application to the same company and role keeps the earlier posting) and named in the report. Step 0 and the/scrapepath (job-application-assistantSKILL.md Step 1) retain the full posting text, not a summary. Pinned bytests/test_apply_records_application.py. -
Tracker status enum defined once;
offer declined/no responsenow reach the correct/html-reportbucket and/gmail-synccorrectly marks them final (#298). The tracker CSVstatuscolumn had no single authoritative definition. Six command files restated it independently with inconsistent spellings, producing two concrete bugs:/outcomeStep 4 wroteno responseandoffer declined(with spaces)./html-reportStep 1 normalised onlyno_response/offer_declined(underscores), so any row written with spaces matched no bucket and was silently dropped from the rejection-rate denominator./gmail-syncStep 2 defined the "final" set with the space forms, so a row written with underscores was never recognised as final and the sync kept chasing closed applications./html-reportincludedinterview_onlyin the tracker bucket map; that value belongs to the archiveoutcome.mdStatus:field, not the CSVstatuscolumn.
Fix: a
## Tracker status vocabularyblock in/outcome(the only writer of the CSV) now defines the canonical set once with underscore spellings and the Final set by explicit list — everything else,draftedincluded, is Open. The legacy space spellings are the same values, not separate statuses: equally Final, and every rule that names one form applies to the other — readers must accept them on read, and never write them. Every reader that makes final/open decisions references that block (/applyStep 6b,/interviewStep 0,/gmail-syncStep 2,/html-reportStep 1,/notion-syncSteps 3-4)./outcomeStep 4 writesno_response/offer_declined;/notion-syncnormalises both forms to the canonical spellings before setting the Status property;/html-report's bucket map losesinterview_only, keeps both spellings, and gains a case-insensitive catch-all that maps unrecognised values to Rejected/Closed and names them once in the status breakdown. Pinned bytests/test_tracker_status_vocab.py.Fork heads-up: if your personalized
/outcomeaddsno responseoroffer declined(space forms) to the tracker write path, swap them for the underscore forms. Existing rows keep working because every reader now accepts both spellings on read. If your Notion database already carries space-form Status options, they simply go unused — Notion never auto-removes select options.
1.4.0 - 2026-08-07
Added
-
--jobage-minuteson linkedin-search for sub-day freshness windows (#302) - LinkedIn filters itsf_TPRparameter server-side at second granularity, so the CLI can now ask for postings from the last N minutes instead of whole-day windows only. Conflicts with--jobageare rejected explicitly (CONFLICTING_AGE_FLAGS). Useful for early-applicant freshness on high-volume searches; URL construction only, no parsing change. -
README: video walkthrough link in Quick start - The Next New Thing's hands-on walkthrough of the workflow (recorded August 2026), for newcomers who want to see the setup-to-application flow before reading. Docs only.
-
Spec-pinning tests for the Language Gate's
/rankcontract (#278) - four regression guards intests/test_rank_command.pypinning thelanguage_gate/language_notefields through Steps 2-5 of/rank, including the Step 4 persistence rule that was live-debugged during #275 (vetoes reported in console output butlanguage_gate: nullon every persisted entry). Mirrors the existinggaps/strengthspinning pattern. No behavior change. -
The jobnet and jobdanmark CLIs identify themselves on every API request (#283) - their
apiFetch/apiPostwrappers now send an explicitUser-Agent(jobnet-cli/1.0,jobdanmark-cli/1.0) instead of Bun's anonymous default token, matching the honest self-identification jobindex already uses onhtmlFetch. The newuser-agent.test.tssuites assert the header on every request wrapper. No response behavior observed to change.
Changed
-
/add-portalnow specifies how a generated skill handles an API token - the command could already scaffold a skill for a portal reachable only through a paid fetching service, but said nothing about the credential such a skill needs. It now checks for that case during reconnaissance and raises the per-call cost with the user before scaffolding. That check is explicitly subordinate to therobots.txt/terms decision in Step 2.4 - a paid fetching service never launders a refusal, and the credential path exists only for portals whoserobots.txtpermits access but whose bot protection blocks ordinary fetches. The portal-skill contract requires the token to come from a<SERVICE>_API_TOKENenvironment variable (never a CLI flag, never a fixture) and to fail withMISSING_CREDENTIALSwhen unset; and such a skill'sSKILL.mdmust carry a Setup section naming the service, the variable, and the billing. Spec only - no shipped portal needs a credential, so no existing skill changes. -
The four Danish demo portals now ship disabled (#288) -
jobindex-search,jobbank-search,jobdanmark-search, andjobnet-searchdefault toenabled: false, and/setup's job-portals question now acts on the answer: it flips them toenabled: truewhen your market is Denmark, and leaves them off otherwise. Previously a non-Danish user's/scraperan all four Danish boards by default, spending tokens fetching and filtering irrelevant listings. Fork heads-up: if you search the Danish market, setenabled: truein those fourSKILL.mdfiles after updating (or re-run/setup --section search); forks that already curated their portal set are unaffected.
Fixed
-
The linkedin-search CLI identifies honestly - its
User-Agentwas a full Chrome browser string, the last portal CLI still spoofing after #283 and the jobbank/jobdanmark fix. It now sendsMozilla/5.0 (compatible; linkedin-search-cli/1.0), the same token format as every other portal. Verified live on both the search and detail endpoints: identical 200 responses with full content under the honest token. -
A
.envwas committable (.gitignore,tools/security_guards.py)./add-portalcan generate a skill for a portal that only returns usable content through a paid fetching service, and such a skill reads an API token from the environment - but nothing stopped the.envholding that token from being committed. No shipped portal needs a credential, so upstream never hit this; a fork whose generated portals do hit it immediately..envand.env.*are now ignored and pinned inREQUIRED_IGNORE_RULES, so the guard fails if the rule is ever dropped. -
The robots gate did not fail closed (
tools/robots_check.py, #277). Found by an adversarial review run over the merged file, not by inspection. Both cases are pinned intests/test_robots_check.pyas FAIL-OPEN REGRESSIONs:- A soft
200granted permission. A host answering/robots.txtwith an HTML error page at status 200 produces a body that parses to zero rules, and zero rules read as "allowed" - so the browser-header retry ran on permission that was never given. A non-empty body carrying no recognised directive is now treated as unreadable. A genuinely empty file stays allow-all, per RFC 9309. Disallowpatterns were never percent-decoded while the request path was, soDisallow: /foo%20barnever matched/foo barand the rule was silently skipped - a fail-open on any site that encodes its own rules.
- A soft
-
curlargument hardening (tools/robots_check.py). The curl argv had no--terminator before the URL.gate()rebuilds the target asscheme://host/robots.txtbefore calling_fetch, so the gate path was never exposed; this is hardening for direct callers, with a test pinning the terminator, that a dash-leading argument fails closed end to end, and thatgate()never passes a caller-supplied URL through to curl.--max-redirs 5is set explicitly rather than left to curl's default. -
Negative and fractional filter flags are rejected in the Danish portal CLIs (#281) -
--jobage(jobindex),--radius(jobnet),--category/--jobtitle-id(jobdanmark), and--company(jobbank) now validate as positive integers, completing thepage/limit/per-pagetightening from #191. Some portals silently ignore invalid filter values and return unfiltered results, so a mistyped ID produced wrong results instead of an error. -
The upstream checker reports files missing from the upstream ref instead of a silent
[OK](#282) - if upstream renames or deletes a tracked framework file, a fork'scheck_upstream_updates.pynow lists it under a[WARNING]summary instead of skipping it and printing a false all-clear. -
09-web-research.mdis now tracked by the upstream checker - the file shipped in #277 but was never added toFRAMEWORK_FILES, so forks got no signal when it changed. -
jobbank and jobdanmark CLIs identify honestly - jobbank's
User-Agentwas a full Chrome browser string and jobdanmark's detail command sent a bareMozilla/5.0; both now use theMozilla/5.0 (compatible; <portal>-cli/1.0)token the other portal CLIs use, matching the identification posture settled in #277. Verified live: both portals serve identical responses to the honest token. -
A
WebFetch403 is no longer treated as a dead posting -WebFetchsends a bot user agent, and many bank and corporate sites answer it with HTTP 403 while serving the same page to a browser normally. Every command read that as "page unavailable" and degraded silently instead of failing loudly:/rankmarked live postingsexpired,/applyfell back to search-result snippets or to vague cover-letter prose, and/scrapestored listing-page#fragmentURLs that fetch fine but return unrelated jobs, breaking every later run on that entry. New09-web-research.md(framework_version1.0.0) is the single reference: the trust boundary, a curl browser-header retry with a tag-stripping extractor, a four-step escalation order, the login-wall case, why the employer's own careers posting beats an aggregator listing (the requisition ID and the grade survive there), and the rule that a search snippet is a lead rather than a source. Wired into/apply,/rank,/interview,/outcome,/notion-sync, the job-scraper skill, and writing-style rule 5 (03-writing-style.md1.1.0 to 1.2.0).The retry is gated on
robots.txt.WebFetchidentifies itself asClaude-Userand honorsrobots.txt, so a 403 means either a WAF default on a site whose published policy allows access, or a site that has actually declined. Newtools/robots_check.pytells them apart and the escalation runs it before retrying: a disallow for*orClaude-Userskips the retry entirely and goes straight to finding the employer's own posting. The rule is stated in the file so later edits do not erode it - the retry exists to get past bot-filtering firewalls on sites whose robots.txt permits access; it is never used to override a site that has said no. Two findings are pinned bytests/test_robots_check.py(15 offline cases): the WAF usually blocksrobots.txtitself, so the policy is read as a browser when the honest request is refused and then obeyed strictly; andurllib.robotparsercannot be used, because it ends a record at a blank line and matches in file order, which reads a real-world policy as "everything allowed". -
/applynow records the application in the tracker - the flagship command wrote a CV and a cover letter to disk and then wrote nothing tojob_search_tracker.csv, so a drafted and submitted application was invisible to/gmail-sync,/html-report,/notion-sync,/interview,/upskillaggregate mode, and to/rank's dedup exclusion - and the safety net that would have caught it (/gmail-sync) refuses to create missing rows, so nothing detected the loss. A new Step 6b appends adraftedrow carrying the two document paths, the fit rating and the posting URL, reusing/outcome's exact header so the two commands cannot diverge; re-running/applyupdates that row rather than duplicating it, unless every matching row holds a final status, in which case a second application to the same role gets its own row. The same step is mirrored intojob-application-assistantbecause/scrapeStep 5 routes straight into the skill (framework_version1.2.0 -> 1.3.0), and/scrapeStep 6 now defers to it instead of adding a row of its own.seen_jobs.jsonis deliberately left alone. Forks: the bump meanscheck_upstream_updates.pywill flag the skill - reconcile the new Step 3b (and Step 6b inapply.md) into your personalized copies rather than skipping the flag.draftedis introduced into the tracker status vocabulary, and every reader that meant submitted now says so. These readers define "open" by exclusion from the final statuses, so a new non-final value would otherwise have joined all of them silently:/outcome's follow-up branch no longer drafts a chase email for an application that was never sent,/gmail-syncno longer reports unsent drafts as stale,/notion-syncleaves "Applied on" empty for them and says "not yet submitted" in the page body rather than calling drafts submitted documents, and/html-reportgains a sixth Drafted bucket kept out of the funnel, the rejection rate and the headline count./outcomeStep 4 overwritesdatewith the submission date when a row leavesdrafted, so the column keeps meaning "applied on"./gmail-syncdeliberately keeps searching for drafted rows./applydrafts but the user submits, and forgetting to run/outcomeafterwards is the failure this issue is about. An employer reply arriving against a row still markeddraftedis how that gets caught, so those rows stay in the search set, the application acknowledgement is promoted from noise to adrafted->appliedsignal (it is the one email that proves a hand submission, and it arrives within a day of it), and an approved match corrects thedateas well as the status. Only the staleness check skips them, since nothing was sent. (#269)
1.3.0 - 2026-08-03
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.
Fixed
-
CV date fields now use ASCII hyphens, so the PDF text layer extracts cleanly - the stock template wrote date ranges as
[YYYY--YYYY], and on the repo's mandatedlualatextoolchain the--en-dash ligature extracts from the PDF as U+FFFD (�). The stock template therefore failed the ATS checklist's own "no�replacement characters" item on every date field, and did so silently: the rendered page looks correct, and no existing check inspected the extracted text.cv/main_example.texnow uses[YYYY-YYYY]and[YYYY-Present], and05-cv-templates.mddocuments the failure mode and the check that catches it (framework_version1.3.0 to 1.4.0). The two-page layout budget is unaffected.Fork reconciliation note. The five changed lines in
cv/main_example.texare the\cventrydate fields - three under Professional Experience, two under Education - precisely the lines every fork personalizes. Rebasing forks should expect conflicts there, resolve them in favour of their own dates, and then apply the same--to-change by hand. To find remaining instances across your own CV variants:grep -rn '\\cventry{[^}]*--' cv/Verify afterwards by extracting the text layer and checking the date lines specifically:
pdftotext -layout <file>.pdf - | grep '�'- none of the hits may be a date field. (On the stock template two benign hits remain either way: the decorative separators on the contact and award lines, which are unrelated to dates and predate this fix.) -
tools/convert_salary_excel.pynow parses localized numeric string cells - Excel exports that store numbers as text (a Danish"108,5","1.234,5", or space-separated thousands) previously hitfloat()'sValueErrorand were silently dropped fromsalary_data.json. The ambiguous single-comma-plus-three-digits pattern ("1,234", thousands in one locale and a decimal in another) is deliberately skipped rather than guessed, preserving the old safe behaviour for the one case that cannot be disambiguated. (#272) -
tools/check_upstream_updates.pycompares the template-repo slug case-insensitively - GitHub serves repository paths case-insensitively, so a clone made from a lowercased URL was a legitimate direct clone that nonetheless triggered #265's fork-vs-self warning. (#273)
Changed
- SETUP.md section 8 now shows the first-time
git remote add upstream ...command before telling you togit fetch upstream, which previously failed on any clone of a personal fork with no explanation of the missing remote. (#274)
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.