Save /rank's gaps into seen_jobs.json, let /upskill use them

[NotAbdelrahmanelsayed]

/rank already fetches every job posting and writes a gaps list for each one (Step 2). But Step 4 only saves rank_score, rank_verdict, and rank_date to seen_jobs.json. The gaps list is shown once in the terminal and then lost.

Real example from my own seen_jobs.json:

sangoma-3 / Analytics Engineer, Enterprise Data
status: ranked, rank_score: 60.2
(no gaps field, even though /rank computed one)

At the same time, /upskill (aggregate mode) only reads job_search_tracker.csv. That file is usually a small subset of the jobs you actually scraped and ranked. So /upskill ends up guessing skill gaps from job titles/notes, when /rank already has better data sitting right there, just not saved.

Idea: small change, two parts:

1. /rank Step 4 also saves gaps (and maybe strengths) to the entry.
2. /upskill also reads seen_jobs.json entries with status: ranked and uses their gaps, weighted by (100 - rank_score), same idea as how tracker rows are weighted today.

No new fetches, no schema break — just stop throwing away data that's already computed. Would split this into two PRs (save first, then consume) since that seems to be the preferred style here.

Posting this here first to check if it makes sense before I build it, or if there's a reason gaps was left out on purpose.

[MadsLorentzen]

Verified against the files before answering, and you're right on all three counts: the agents do compute gaps, Step 4 drops them, and /upskill's aggregate mode re-guesses from tracker titles what /rank already knew. There's no deliberate reason gaps was left out - Step 4 simply saved the minimum needed for the shortlist, and nobody connected the two commands until now.

So yes, build it - and the two-PR split is exactly the right shape. Two design notes for PR 1: save both gaps and strengths (same cost, and /interview could plausibly use strengths later), and keep them as the agent returned them (1-3 bullets, no reformatting) so the field stays cheap. For PR 2: your (100 - rank_score) weighting mirrors how tracker rows work today, which is right; just make sure entries re-ranked after a profile change replace their old gaps rather than accumulating (the --all re-rank path). Looking forward to both.