ci: release ten minutes after upstream instead of an hour

[jooyoungseo]

The weekly schedule added in #306 ran at 16:00 UTC, an hour after
upstream's 15:00 UTC release, to give the maidr npm publish time to
land before the bundle step pulls it.

Move to 15:10 UTC. Also correct the comment: the old wording claimed the
gap guaranteed the bundle step saw the release upstream had just
published, which no gap of this size can promise. GitHub queues
scheduled workflows rather than starting them on the requested minute --
upstream's own 15:00 job has started between 35 and 115 minutes late over
the last fourteen runs, drawn independently per workflow -- so the
ordering is a tendency, not an invariant, and the comment now says which
existing checks catch the case where it does not hold.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01SPUYj6bH372HzEnoKaZ8JV

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Review: ci: release ten minutes after upstream instead of an hour (#332)

Nice cleanup of the comment's overclaim — "guaranteed" was wrong given the delay data, and calling it a "tendency" is more honest. But the numbers cited in this very PR argue against the change it makes.

The 10-minute gap looks like a regression, not an improvement

Using the delay distribution quoted in the commit message (upstream's 15:00 job starting 35–115 minutes late, delays "drawn independently per workflow"), and assuming release.yml's own scheduled runs are subject to the same queueing distribution:

• Old (60-min gap, target 16:00): modeling both delays as i.i.d. Uniform(35, 115) minutes, the release job's actual start time beats upstream's actual publish time in ~97% of runs. Only ~3% of releases would have bundled the previous week's assets.
• New (10-min gap, target 15:10): with the same distribution, the release job now beats upstream's publish in only ~62% of runs — ~38% of releases would bundle the previous week's assets, up from ~3%.

(Derivation: for D = U - R with U, R ~ Uniform(0, L) i.i.d., L = 80, P(D > d) = (L-d)²/(2L²) for 0<=d<=L. Old: d=60 → 3.1%. New: d=10 → 38.3%.)

So shrinking the buffer doesn't just make the comment more honest about an existing edge case — it makes the "ships the release upstream just published" outcome roughly 12x less reliable in the common case. If minimizing wall-clock latency to upstream's target time is the actual goal here (e.g. for maintainer scheduling reasons), that's a reasonable tradeoff to make explicitly, but as written the PR frames 15:10 as still achieving "ordinarily" the fresh bundle, which the same delay data contradicts. Worth either:

• keeping (or increasing) the buffer if the ~97% freshness-catch rate is something you want to preserve, or
• being explicit in the comment that this is a deliberate trade of freshness-catch rate for an earlier run, and why that trade is worth it.

The safety net is weaker than the comment implies

The new comment says drift is caught by check-bundle-freshness.yml and fixed by update-maidr-js.yml. Worth noting for readers:

• check-bundle-freshness.yml only fails (red run / maintainer email) when the bundle is STALE_MINOR_GAP = 5 minor versions behind (maidr/util/dependencies.py:980, :1098-1101). A single week of drift — the exact case this PR makes ~12x more likely — only produces an informational ::notice::, not a failure. So in practice nothing pages anyone for a one-release staleness; it would need to persist for several releases before the freshness check turns red.
• update-maidr-js.yml is workflow_dispatch-only with no schedule, so "refreshes it on demand" is accurate but means the fix requires a human to notice the notice and manually run it — it won't self-correct.

Neither of these is wrong per se, but combined with the higher staleness rate above, the practical effect is "stale-by-one-week bundles become much more common and mostly silent," which seems worth calling out explicitly rather than leaving implicit in "degrades gracefully."

Minor / nits

• Cron syntax (10 15 * * 1) and the UTC→CST/CDT conversion in the comment are both correct.
• Off-the-hour minute (:10) is good practice and consistent with the existing convention in check-bundle-freshness.yml (:23).
• Commit type (ci) is an allowed conventional-commit tag per CLAUDE.md.

No test coverage concerns (YAML/comment-only change, nothing executable to unit test) and no security concerns.