Add a release-drift check to the health sweep

[cshuttle]

Part of #25

Question

Teach the health sweep to notice unreleased work.

The release-cut decision chose a workflow_dispatch button, whose honest weakness is that nothing presses it. That failure is already evidenced: VirtualWindow sat 46 commits past its only release and nothing surfaced it until this map went looking, three weeks later.

The sweep in cshuttle/Monitoring already walks the estate periodically, applies trend judgment and files deduplicated GitHub issues. This adds one more check beside the Netdata/Komodo/ArgoCD/backup ones: for each repo that has releases, commits on the default branch since the last release tag.

To decide while building:

• The threshold. A count, an age, or both — one commit a week old is not drift; thirty are. Whatever it is, it should not page for a repo that is simply quiet.
• Which repos are in scope. Every repo with a release tag, or an explicit list? An explicit list avoids nagging about repos that deliberately never release; a tag-presence rule needs no maintenance.
• chrome-exporter is a component, not a repo — its tags are chrome-exporter/vX.Y.Z inside Monitoring, so "commits since the last release" must be scoped to that subdirectory or the number is meaningless.
• Dedupe and close behaviour: the issue should update rather than multiply, and close when a release lands.

Sequenced after the first real releases exist — there is nothing to measure drift against until then.

[cshuttle]

Resolution

The sweep now reports release drift, which is the half of the release-cut decision that keeps the rest from decaying. Landed as Monitoring#396.

Answers to the questions the ticket left open

Threshold — both, not one. Reported at 20 unreleased commits or any commit left unreleased for 30 days. A single commit merged this morning is not drift; thirty are, and so is one that has waited a month. A check that pages on quiet repos is one you learn to ignore.

Scope — self-maintaining. Any repo whose newest release is version-shaped is in scope. A repo that never releases never nags; one that starts releasing is picked up with no list to edit.

That filter turned out to be load-bearing rather than tidy. The first live run reported .password-store with 54 commits of drift — its newest "release" is tagged latest, a moving tag. Requiring vX.Y.Z states the actual rule (is this repo participating in the version model?) instead of special-casing a repo name.

Components count their own directory. chrome-exporter/v1.0.0 names a component inside Monitoring, whose config side is reconciled at HEAD and deliberately unversioned — whole-repo counting against it would be meaningless. The compare API cannot filter by path, so that branch uses the commits list scoped to the directory.

Dedupe follows the sweep convention: one fingerprint per repo (monitoring/release-drift/<repo>), so each drifting repo dedupes independently and closing one does not close another.

It earned its place before merging

First live run, one true positive and no noise:

RELEASE DRIFT (1 of 7 releasing repos) — fingerprint monitoring/release-drift/<repo>:
  cshuttle/blinkstick-mqtt  11 unreleased commit(s) since v1.0.1, oldest 36d old

That is exactly the repo the map's fog had flagged as a stalled cadence — now surfaced by machinery rather than by someone remembering.

Two things worth knowing for next time

Local hooks and CI do not check the same things. Lefthook runs shellcheck, gitleaks and yamllint here — not the formatter — so a shellcheck-clean script can still fail trunk fmt in CI. Green locally is not green.

trunk fmt silently claims core.hooksPath. Running it took the git hooks away from Lefthook, which this repo deliberately owns so the two do not fight. Reverted; worth knowing before it is discovered as hooks quietly not running.