rescan

name	rescan
description	Re-run an existing prior-art scan against today's ecosystem and append a dated revision, without rewriting the original. Use when the user says "is that still true", "re-check that scan", "has anything appeared since", "refresh the prior art on X", or is about to act on a scan that is months old. Also used to sweep every stale `build` verdict at once.

rescan

A prior-art scan is a claim about a date. This re-tests one against today and records the difference.

Revisions append. Nothing above the Revisions heading is ever rewritten. The value of an old scan is partly the record of what was true then — "nothing existed in August, something did by January" tells you the space is filling up, which neither snapshot says on its own. Overwrite it and you have a mediocre new scan instead of a trend.

Inputs

• target (required): a scan slug, a filename, or --stale to sweep everything past its shelf life.

Procedure

1. Pick the targets

Named target: read the file, take the original spec verbatim. Do not re-derive the acceptance criteria — the whole point is testing the same spec against a new date. If the requirement itself has genuinely changed, that is a new scan with a new slug, and the old one gets a revision noting the supersession.

--stale, using the shelf lives in docs/verdicts.md:

Priority	What
1	build verdicts older than ~6 months where nothing was built
2	contribute verdicts of any age — the PR either landed or died
3	adopt / fork verdicts whose dependency has gone quiet

Skip already-have-it and native unless asked; they don't decay.

Report the list before working it, and cap a sweep at what can be done properly. Six shallow re-scans are worth less than two real ones.

2. Re-run the surfaces

Work docs/method.md again. Two shortcuts that are legitimate and one that isn't:

• Legitimate: date-bound the queries where the surface supports it — the MCP registry takes updated_since; gh search repos can filter on pushed:>YYYY-MM-DD.
• Legitimate: re-check named candidates from the original directly before searching broadly. A candidate that has since died changes the verdict on its own.
• Not legitimate: skipping a surface because it was empty last time. Empty surfaces are exactly where new things appear.

Re-check the original candidates for liveness in both directions. A fork verdict reverts to contribute if the upstream came back to life.

3. Decide what changed

Three outcomes, all worth writing:

Outcome	Record
Verdict holds	Say so, with today's date and what you re-ran. This is the common case and it is not a wasted revision — it extends the claim's validity
Verdict changes	New verdict, what appeared or died, and what the user should now do
Spec has drifted	The requirement is no longer the one that was written down. Note it, open a new scan, mark this one superseded

4. Write the revision

Append under ## Revisions:

### 2026-11-03 — adopt (was: build)

`someone/some-plugin` appeared 2026-09; first release 2026-10-14, meets criteria 1–3,
misses NICE 4. Re-ran: substrate, GitHub topic + code search, MCP registry, web.
The original `build` verdict is superseded — nothing was built in the interim, so
nothing to migrate.

**Install:** `/plugin install some-plugin@someone`

Then update the frontmatter: verdict: to the current one, and append today's date to revised: []. Leave date: at the original — it is when the question was first asked.

Finally run reindex, since the table reads verdict:.

Guardrails

• Never edit above ## Revisions.
• Never re-derive the criteria for a rescan.
• A revision that says "still nothing" is a real deliverable. Write it.
• If a surface is unavailable today, say which, and drop confidence accordingly rather than quietly claiming the same coverage as last time.