[bong-water-water-bong]

The docs on 1bit.gg come from 1bit-MONSTER/engine; the site only learns of a merge there on its schedule. Today the owner read the onnx-pack page three hours stale (#684 had merged in the engine). This moves the schedule from every 3 hours to hourly. A build takes about a minute, the repository is public, so Actions minutes are free.

A push-triggered rebuild from the engine would need a token with write access to this repository's workflows stored as an engine secret; that is the owner's call and is not part of this change.

🤖 Generated with Claude Code

[bong-water-water-bong]

VERDICT: READY (tprs-ready applied). Exactly the one-line change it says: cron: "17 */3 * * *" → "17 * * * *", with the comment above it updated to match — and nothing else in the workflow touched.

Checked on the head 65b0414a6:

• The cron is valid and keeps the offset: '17 * * * *', five fields, hourly at :17 — so it will not collide with the other hourly fleet jobs.
• Nothing else changed: the diff is +2/−2, one comment line and one cron line. The triggers are still push, pull_request, workflow_dispatch, schedule; jobs: [build, deploy] unchanged; deploy is still github.event_name != 'pull_request' && github.ref == 'refs/heads/main', so a schedule run on main deploys and a PR does not.
• No pile-up risk: concurrency: group: pages-${{ github.ref }} with cancel-in-progress: true, and a build is ~a minute per the body, so runs cannot stack.
• Nothing else in the repo still assumes the 3-hour cadence: grep -rn "3 hours\|\*/3" over the tree → nothing.
• CI build: SUCCESS on this head (the PR-triggered build), deploy: SKIPPED as designed for a PR.

One thing this triples, worth knowing rather than blocking: the deploy job pings IndexNow with every URL in the sitemap on each run (pages.yml:84-90), and that now happens 24×/day instead of 8×. It is continue-on-error: true, so it can never fail the build, but IndexNow's own guidance is to submit changed URLs only, and repeating a full-site submission three times as often is the kind of thing that gets a key quietly rate-limited. If you care, the cheap fixes are to gate the ping to github.event_name == 'push' (schedule runs then only rebuild) or to submit only the URLs whose files changed — both are separate one-liners, and neither belongs in this PR.

Also worth saying in the body if it is not obvious to the next reader: GitHub's scheduled workflows are best-effort (they can be delayed at times of load), so the promise is "within the hour" in the normal case, not a guarantee.