Four-agent CV screening pipeline
Upload a résumé. It is parsed, its skills resolved against a controlled vocabulary of 679 canonical terms, and scored against all 800 roles in the corpus in a single pass — with five weighted components returned separately, so any total can be reconstructed from its parts rather than taken on trust.
The live API runs on a development machine behind a tunnel, so the demo is only up while that machine is. If it does not respond, the walkthrough is a full capture of the same app running.
What this proves
Each was found here, reproduced, and fixed with a test that failed first. Every card names the file, so the claim can be checked.
A race that only exists above one worker.
Choosing a provider per request meant writing to a module-level
singleton and restoring it outside a finally. The fix
was not a lock — the provider is injected once at construction, so
there is no mutable state to contend for.
The same input scored two different numbers.
Keyword extraction sliced [:20] from a set,
and Python randomises string hashing per process. Terms now rank by
frequency, tied alphabetically.
Seeding that cannot overwrite your data.
The corpus became writable through POST /jobs, and on an
ephemeral filesystem the obvious implementation reseeds every deploy.
seed_jobs writes nothing into a populated table.
Rate limits charged to the right client.
Per-IP limits read the socket address, which behind a proxy is the
proxy's — so every visitor shares one bucket.
X-Forwarded-For is client-supplied, so it is believed
only when TRUST_PROXY_HEADERS says something is in front.
Target leakage found in my own model. A perfect ROC-AUC. Removing the feature I suspected changed nothing. The label turned out to be a threshold on a column already excluded from training, and two ordinary columns rebuild it anyway.
A degraded run must not look like a healthy one. A rule-based explanation and a model-written one are both fluent paragraphs, so a dead key produces a broken demo that reads as a working one.
explanation_source, scoring_mode, and the provider named at /health.Built with
Versions as pinned in requirements.txt and frontend/package.json.
3.10+
FastAPI 0.104.1
Pydantic 2.12.5
scikit-learn 1.3+
SQLite WAL
slowapi rate limits
Next.js 16.3.0
React 18.3.1
TypeScript 5.4.2
Tailwind CSS 3.4.1
pytest 8.4.1
mypy 1.19.0
ruff 0.16.2
black 25.11.0
The lint toolchain is pinned exactly, not by lower bound.
A range makes "correctly formatted" a function of the install date
rather than of the code: an open black>=24.0.0 had CI
resolve a major version ahead of a developer's machine, and the two
disagreed about seven files nobody had touched.
How a score is built
| Component | Weight | What it measures |
|---|---|---|
| Skill match | 50% | CV skills against required and preferred, both resolved to the vocabulary |
| Experience | 20% | Years against the stated range, penalising both directions |
| Title similarity | 17% | The candidate's role against the job title |
| Education | 8% | Highest degree against the stated requirement |
| Keyword overlap | 5% | Terms from the description present in the CV |
Enforced, not documented. The weights live in
config/agents.yaml and nowhere else. A set that does not
sum to 1.0 fails at import with the offending values named, and a
contract test asserts the five components add up to the reported
rule-based total — because a stacked bar built on drifting weights does
not look wrong, it looks right.