[scanner] bug: meeting-recordings refresh opens churn PRs when only YouTube's per-video updated timestamp moves #565

What happens

scripts/update-meeting-recordings.ts rewrites data/meeting-recordings.json whenever the YouTube feed's per-video updated element moves, even when nothing a reader can see changed. YouTube bumps that element on its own schedule (metadata/stats refreshes), so the daily meeting-recordings-refresh workflow opens a PR, runs the full CI matrix, and lands a commit whose only payload is a timestamp.

Evidence from the last three refresh commits on main:

• docs: refresh community meeting recordings #562 (b9501d6): the only data change is recordings[0].updatedAt 11:59:21 → 12:33:33 (plus the top-level updatedAt).
• docs: refresh community meeting recordings #495 (761c2b4): same — a single per-recording updatedAt bump.
• docs: refresh community meeting recordings #548 (35a038a): a real change (new recording T9ShTNpdf3o).

So 2 of 3 refresh PRs were pure churn.

Why it matters

Nothing renders the per-recording updatedAt: grep -rn updatedAt src/ only hits useSharedConfig.ts, which is the shared-config object, not a recording. The MeetingsPage uses publishedAt, title, url, thumbnail, description. Each churn PR costs a CI run, a hive review, a merge, and a git log entry with no user-visible effect, and it masks the genuinely new-recording refreshes.

Where

scripts/update-meeting-recordings.ts, main(): the no-op check compares JSON.stringify(existing.recordings) with the merged result, and the merge { ...byId.get(id), ...recording } carries the feed's updatedAt into the comparison.

Suggested fix

Exclude the per-recording updatedAt from the change detection (compare a projection of the fields the site actually consumes), or stop persisting updatedAt for records that already exist. Either keeps a new recording, a title edit, a thumbnail or description change triggering a refresh, while a bare updated bump is a no-op. Add a test in scripts/update-meeting-recordings.inprocess.test.ts that feeds the same entry with only updated changed and asserts the file is not rewritten.

Decision taken by hive: keep the existing updatedAt key on disk for backward compatibility (additive, no schema change); only the change-detection comparison ignores it.

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88