Learn preferences

This is the feedback loop that makes ScoutJobs get better the longer it is used. It is conservative: it proposes, the user confirms, and nothing stated by the user is ever overwritten by inference.

Input

scoutjobs decision summary --json
scoutjobs pref list --json

The summary holds: counts per decision kind, signals_by_kind (how often each key=value appeared in skip vs apply vs withdraw decisions), recent_reasons in the user's words, interview_outcomes, and score_overrides (jobs where the fit score and the user's choice disagreed).

Infer

For each signal key, compare its distribution across kinds. A candidate preference exists when:

• the same value appears in at least 3 decisions of one kind and rarely in the opposite kind (for example remote=onsite in 4 skips, 0 applies → remote: not onsite), or
• the user's reasons repeat a theme (read recent_reasons; cluster by meaning, not exact words), or
• score_overrides show a consistent direction (user skips high-scoring jobs with a shared trait → that trait is a negative the scorer misses; user applies to low-scoring ones → a positive it misses).

Confidence: 0.5 for 3 supporting decisions, 0.7 for 5, 0.9 for 8 or more, minus 0.2 if there is contradicting evidence. Never above 0.95 for learned items.

Do not infer protected or irrelevant attributes (anything about people at the company, nationality, age, gender). Preferences are about the job: stack, remote, location, seniority, company size, industry, salary, on-call, process, role family, language.

Propose

Queue every candidate for review, with the numbers behind it. Skip a key the user stated (pref list shows stated); the CLI refuses it anyway.

scoutjobs pref propose stack_avoid "java, spring" --support 5 --against 0 --confidence 0.7 --evidence "5 skips mention Java; 0 applies"
scoutjobs pref propose company_size "50-500" --support 3 --confidence 0.5 --evidence "3 withdrawals from 1000+ companies: 'too much process'"

--evidence holds the counts and at most two short quotes from the user's reasons. A value the user rejected before is refused unless --support is higher than it was then; check scoutjobs pref review --all --json first.

Confirm

Present a short table: key, proposed value, current value if any, confidence, evidence. Ask the user to accept, edit, or reject each. Full sentences here; this is a question. The user can also answer later on the dashboard's Preferences page, under "Awaiting your review".

Apply only what the user said:

scoutjobs pref confirm stack_avoid                          # accept: stored as learned
scoutjobs pref confirm company_size --value "under 300"      # their own words: stored as stated, confidence 1
scoutjobs pref reject stack_avoid --reason "skipped those for salary"

Unanswered proposals stay pending. Every confirm, edit and reject is in the Activity log, and the CLI re-renders preferences.md. Finish with scoutjobs session log --kind review --topic "learn-preferences" --notes "<n> accepted, <m> rejected, <k> pending".

Also tune the scorer

If score_overrides is non-empty, tell the user which dimension of the job-fit weighting seems off for them and propose a one-line note to add to preferences.md under a scoring key, for example scoutjobs pref set scoring "weight stated remote preference as a hard rule; ignore company size" --source stated. job-fit reads that key.