fix(ci): the decoupling ratchet was timing out before it ran

[Weegy]

core decoupling ratchet (#470) reported cancelled on two PRs in a row. That reads like a transient — a push cancelling an in-flight run. It was not: when a push cancels a run, every job is cancelled, and here the siblings all succeeded on the same SHA while only this one died.

What actually happened

From the job's own step timings:

step	window	result
Set up job → setup-node	15:35:41 → 15:35:47	success
Ensure ripgrep	15:35:47 → 15:40:54	cancelled (5:07)
Check core is not re-coupling	—	skipped

The job's timeout-minutes: 5 fired inside the install step, so the step that does the actual checking never executed.

And the run that passed was not comfortable either — the same install took 3:28 there. The job routinely had about ninety seconds of headroom, which is why this surfaces as an intermittent rather than a permanent failure.

A timed-out job reports as cancelled and skips its remaining steps. So a required check was silently not running: not red, not passing, just absent. That is the same failure family as a permanently-green guard-skip — the gate is gone and nothing about the PR page says so.

The fix

apt-get update is the expensive half. It refetches every package index in order to install one small binary. The step now tries the cached indices first and only refreshes when that actually fails; worst case costs a few seconds more than today, best case skips minutes.

rg is genuinely required and the step cannot just be deleted — scripts/check-core-decoupling.mjs shells out to it (execFileSync('rg', args, …) at line 119).

Timeout 5 → 10, so a slow package mirror cannot take out a required check. The install is the only unbounded thing in the job; the check itself is a single rg over the repo.

One deliberate detail

The guard is an explicit if:

if ! command -v rg >/dev/null; then
  sudo apt-get install -y ripgrep \
    || (sudo apt-get update && sudo apt-get install -y ripgrep)
fi

not command -v rg >/dev/null && exit 0. Whether set -e aborts on the first half of an && list is precisely the kind of shell subtlety that has produced a silent CI failure in this repo before (the printf | grep -q EPIPE inversion that left the release pipeline dead for a month). Both branches were verified under bash -e.

Verification

The real verification is this PR's own run: if the ratchet check comes back success rather than cancelled, the step completed and the check executed. Worth glancing at its duration too — the point is headroom, not just a pass.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[Weegy]

Verified on this PR's own run — which was the stated test.

	before	after
Ensure ripgrep	3:28 on a passing run, 5:07 on the one that timed out	43s
whole job	hit the 5:00 cap → cancelled	51s
Check core is not re-coupling	skipped (never ran)	runs, <1s

Skipping apt-get update is what did it on its own; the 5 → 10 timeout is belt-and-braces for a slow mirror rather than the actual fix. The check step itself is instant, so essentially the entire job was package-index fetching.

Worth noting the shape of this one, because it is the third time this pattern has cost time in this repo: the gate was not red and not green — it was absent. cancelled reads as infrastructure noise, and the PR page gives no hint that the step which does the checking was skipped. The tell was that only one job died while its siblings on the same SHA passed; a push-cancellation kills them all.

#750 and #751 both still carry a cancelled ratchet on their heads. Once this merges they need that job re-run (or a rebase) before their required checks go green.