update-profile

name	update-profile
description	Change what is stored about the user — their position, learning preferences, objectives, budget or subject — without running a search. Re-interviews only the files that changed, re-dates them, and marks the scorecard stale so the next run rebuilds it. Use when circumstances change, when a review date passes, or when the user says a stored answer is wrong.

Update the profile

The maintenance path. Changes what is on file about the user, and stops there.

Use it when something about them has changed — more time, less money, a new job, a finished course, a shifted deadline — or when a review_after date has passed, or when they read a profile file and disagreed with it. Running a search afterwards is offered, not assumed.

Separating this from the search is deliberate. Updating a profile and re-surveying a market are different jobs on different clocks: the first is a two-minute correction that should not drag an hour of research behind it, and the second should not quietly re-open questions about the user that nobody asked to reconsider.

1. Work out what actually changed

If the user named it — "I've got more time now" — go straight there. Otherwise show the five files with their captured dates and ask which is wrong, rather than proposing a full re-interview.

Also flag anything past review_after, but flag it, do not act on it. Someone who came to fix their budget does not necessarily want to redo their benchmark in the same sitting, and bundling the two is how a two-minute correction becomes an abandoned conversation.

File	Re-run when
spec.md	The subject or the topic list changed. Consider whether this is really a new search in a new directory
benchmark.md	They have built, learned or shipped something; three months have passed; the evidence has moved
learning-preferences.md	Rarely. A change in circumstances — a commute, a new device, a course that failed in an instructive way
objectives.md	The purpose, the audience, a standing position, or the deadline changed
budget.md	Money or hours changed, or who is paying

2. Re-run only those stage skills

Invoke the corresponding skill for each file that changed. Each rewrites its file and sets a fresh captured and review_after.

Two things to hold on to while doing it:

Do not silently reopen the rest. If a benchmark update surfaces something that bears on objectives, say so and ask — do not edit objectives.md because it seemed implied.

Preserve what did not change. These interviews rewrite the whole file. Read the existing content first and carry forward the parts still true, especially the open questions and the standing positions, which are easy to lose and expensive to re-elicit.

3. Mark the scorecard stale

This is the step that makes the update mean anything.

If any profile file changed, set in scorecard/methodology.md frontmatter:

stale: true
stale_since: <today, YYYY-MM-DD>
stale_reason: <which files changed, in a few words>

Leave frozen: true and frozen_at exactly as they are. The old scorecard remains the record of what was frozen before the last research ran — overwriting that would destroy the evidence that the process was followed. stale says it needs rebuilding next time; it does not say it never happened.

rerun-search reads this flag and rebuilds and re-freezes before researching. Without it, the next run scores a changed person against an unchanged specification, produces a ranking that looks fine, and is wrong in a way nothing surfaces.

Tell the user plainly: their scorecard and their last recommendation are now provisional, and the ranking may move.

4. Offer, do not assume

Ask whether they want to re-run the search now.

Yes → hand off to rerun-search, which will see stale: true and rebuild.

No → say what is now inconsistent and leave it. That is a legitimate state: the profile is current, the scorecard is stale, and both facts are on record. Do not rebuild the scorecard here as a tidying-up gesture — a scorecard frozen in one session and researched against in another, with the freeze commit in between, is exactly the audit trail the method depends on.

Correcting rather than updating

If the user is not reporting a change but saying the file is wrong — a misunderstanding in the interview, or a position recorded at the wrong strength — fix it directly rather than re-running the whole interview, and keep the original captured date if the underlying facts are unchanged. Only a genuine change of circumstances re-dates a file. Re-dating on a correction hides how old the answers really are, which is the one thing these dates exist to prevent.