MGS1009: target never replays from cache

magus noticed that a target you just waited on has executed repeatedly and never replayed from cache. Not a cold cache - a cache that cannot work.

[MGS1009] docs render:rw has run 8 times without ever replaying from cache
(11m spent). Its declared footprint is probably wider than it reads, so
unrelated edits keep changing its key; run 'magus doctor' for the full list

magus doctor reports every affected target at once, worst wall-clock first:

[fail] cache yield: 2 target(s) executed repeatedly and never replayed from cache
    docs generate:rw: 74 runs, 0 cached, 5226s spent (71s avg)
    docs render:rw: 8 runs, 0 cached, 574s spent (72s avg)

Why

This is the most expensive kind of misconfiguration precisely because nothing looks wrong. Every run passes. The cache reports no error. The only symptom is that the build is slower than it should be - and since it has always been that slow, there is nothing to compare against. It is invisible per-run and obvious only in aggregate, which is why magus reads it back out of the invocation journals rather than trying to detect it live.

A target's cache key is derived from its footprint: the union of the globs a bound spell contributes, the project-wide sources/outputs, and any per-target magus\inputs/magus\outputs. If that footprint includes files the target never reads, then editing one of those files changes the key without changing anything the target cares about. Do that routinely - edit a Markdown file in a project whose sources include **/*.md, when the target compiles TypeScript - and the key changes on every commit. The cache is working exactly as designed; it has simply been told that everything matters.

The threshold is deliberately conservative. A handful of misses proves nothing, because a target legitimately misses while you edit its real inputs, and a target that misses in milliseconds costs nothing to rerun. magus stays quiet until a target has executed at least 8 times, averaged at least 2 seconds, and replayed zero times. A single replay clears it: one hit proves the cache works for that target, and the rest are ordinary edit-rebuild cycles.

Fix

Narrow the footprint, or move the work.

Check what the target actually reads. If a target compiles Go and its project declares **/*.md in sources, every docs commit rebuilds it. Split the glob, or move the target into a project whose sources describe its real inputs.

Per-target magus\inputs cannot rescue you here. It is additive: it adds to the footprint and cannot narrow below the project-wide baseline (see MGS1005 for the same asymmetry from the other direction). If the project declares too much, the fix belongs in the project, not the target.

Consider whether the work is in the right project at all. A step whose inputs have nothing to do with its neighbors - protobuf codegen inside a docs project, say - will keep busting its key on every unrelated edit no matter how you declare it. Two sets of work with disjoint inputs sharing one project means the union invalidates both. That is a project-boundary problem, and no footprint declaration solves it.

Confirm the target declares outputs. A target that produces files but declares no magus\outputs has nothing for magus to snapshot, so there is nothing to replay even when the key matches.

Not a bug when

• The target is genuinely non-deterministic or exists to always run (a deploy, a smoke test against a live service). Those should be short; if one is slow and intentionally uncached, the finding is noise you can ignore.
• You have been editing its real inputs every time. Eight consecutive real changes to the files a target reads is a legitimate zero hit rate. The wall-clock figure is the tell: if it looks like time you meant to spend, it was.