feat(compile): recompile when a prompt modifier changes, and record which ran

[ethanj]

Closes the first two items of #186. Items 3 and 4 are not included — they need files from #182 and #184, which are unmerged.

What was wrong

llmwiki compile --lang Japanese over an already-compiled project reported "Nothing to compile" and left every page in the previous language. Change detection classifies a source purely by the SHA-256 of its bytes, and a prompt modifier is not part of the source, so the pipeline short-circuited before any prompt was built. Setting LLMWIKI_OUTPUT_LANG behaved the same way.

The fix

The selected modifiers now travel in state.json as a digest, and flipping one invalidates the pages it would have changed. Pages also carry a promptModifiers frontmatter entry, surfaced per page in the JSON export: promptVersion names the prompt implementation and is identical whether or not a modifier was active, so it could never separate two such pages.

promptModifierPairs is the single canonical rendering that both the digest and the frontmatter stamp consume, so a page's recorded modifiers and the state digest cannot drift into disagreeing about what "the same selection" means.

The migration edge

An absent digest reads as "none selected", not as its own third state.

I tried the other reading first — absence means "no difference", so upgrading never costs a recompile — and it is wrong in a way worth recording. The no-op compile path never flushes state, so a project with nothing to compile would never record a first digest, and flipping a modifier on exactly the settled project this feature exists for would stay silent forever.

Reading absence as "none" costs an untouched project nothing: its first compile records the empty selection and finds no difference. It costs one recompile to a project already running under --lang when it upgrades, which is the same trade the embedding store already makes for an index predating fingerprints.

The digest is recorded at the single durable flush rather than at load, so a compile that dies mid-run leaves the previous digest on disk and the re-run still sees the difference.

Scoped runs must not record the selection

The digest is one global fact, so anything that narrows what a run recompiles can advance it past work that never happened, leaving a page current and permanently stale. Two such paths exist and both are handled.

refresh --stale supplies a changeFilter and recompiles a subset by design. It now flushes source state but leaves the digest alone, so the sources it filtered out keep the only signal that says they are stale. The pages it did refresh pay a second regeneration on the next full compile, which is the safe direction to be wrong in.

markUnchangedPendingSources demotes a promoted source back to unchanged when a pending review candidate carries the same source hash — and it ran on the line right after the promotion, so with any candidate present the feature was undone entirely and a modifier flip made zero model calls. Each candidate now records the digest it was generated under, and deduplication demotes only when the hash and the selection both match.

Comparing against the project's digest instead is not sufficient, and it fails in only one direction. Review mode never flushes state, so a project whose only compiles were --review has no recorded digest — and an absent digest means "none selected", which is exactly what clearing a modifier requests. Japanese → Spanish passes either way; Japanese → default does not.

Tests

11 unit cases for the set, digest and change test, plus four CLI integration cases: two that compile twice over byte-identical sources, and three covering the narrowing paths above (a pending candidate under a changed selection, the same transition in reverse, and a scoped refresh --stale).

Only the integration cases can detect any of this — every mutant is killed by them and by no unit test: neutering the promotion, never recording the digest, always recording it on a scoped run, and dedupe ignoring the selection.

Notes

src/compiler/index.ts was already past the 400-line guideline before this change, so the promotion lives in prompt-modifiers.ts and index.ts grows by 12 lines — the call site and the flush.

When #183 lands, --no-sources-section becomes one more entry in activePromptModifiers and inherits the invalidation with no further work.