[finding] Nothing gates the ref'd-timer/`await` class after five instances — and #10661's `toBeLessThanOrEqual` repair can still hide a real leak behind foreign expiries

[claude]

Two observations from #10685, both about the same class and both left undone there deliberately. Filing together because they share one remedy shape.

1. Nothing stops the sixth site

The class — "a process-global getActiveResourcesInfo() timer count scored with toBe across an await" — has now been found five times over four cards:

where	how it surfaced
kernel.test.ts (#4813)	latent
health-monitor.test.ts (#6329)	red in the merge queue — the window stretched past the runner's own non-unref'd 100 ms throttle(sendTasksUpdate, 100) timer, measured at 105 ms
timeout-guard.test.ts (#10604 / PR #10661)	red in CI — expected 2 to be 4, two foreign timers expiring mid-test
kernel.test.ts x2, hot-reload.test.ts (#10685)	latent, fixed in PR for #10685
service-automation/src/engine.test.ts (#10783)	latent, still open

Each was repaired at the site. Nothing prevents the next one, and the failure it produces is a shard-only intermittent red whose message points at a timer count rather than at the change that caused it — which blocks every lane's merge queue at once.

A gate would close the class. The rule it needs to express is roughly: a test that derives a count from process.getActiveResourcesInfo() may compare two readings only across a window that contains no await.

Why #10685's PR did not add one

Three costs it could not pay inside an S card, all worth stating so the next attempt starts informed:

• Registration. New check:* gates are registered in root package.json, which is fenced territory of the @changesets/cli v3 migration lane (Migrate the release toolchain to @changesets/cli v3 — one atomic PR carrying the bump, the pre-mode restructure, and the gates that model v2's semantics #9465) while it runs. There is a precedent for the workaround — lint.yml already invokes several gates as node scripts/... directly, for exactly this reason, and dispatch-gates.mjs derives gate families from either spelling — so this is a cost, not a blocker.
• Detection fidelity. Deciding "is there an await between these two readings" is an AST question, and a text scan that gets it approximately right is the failure mode AGENTS.md already documents for source-scanning gates: it sees only the spellings it knows, and an unrecognised one produces no flag, silently. The cheaper and more robust formulation is to ban the raw probe outside one approved helper, which is a grep-level rule with a tiny allowlist.
• Where the helper lives. That formulation needs a home reachable from every package with such a test. Three ref'd-timer pins score a process-global count across an await — green only because their windows happen not to cross a timer phase #10685's PR put one in packages/core/src/refd-timer-probe.testkit.ts; service-automation ([finding] A fifth ref'd-timer pin scores a process-global count across an await — service-automation's engine.test.ts, outside #10685's site list #10783) cannot import it without either publishing a test helper on @objectstack/core's public surface — which the api-surface ratchet would rightly notice — or a cross-package test input, which check:cross-package-test-inputs requires to be spelled so it can see it.

So: a gate is the right end state, and it is its own card rather than a rider.

2. toBeLessThanOrEqual on a process-global count can hide a real leak

PR #10661's repair for timeout-guard.test.ts was to assert non-increase:

before = refd();
await expect(
 raceWithTimeout(new Promise(() => {}), 10, () => new Error('hung')),
).rejects.toThrow('hung');
expect(refd()).toBeLessThanOrEqual(before);

The reasoning in that file is sound as far as it goes — a leak is a growth, so the direction that matters survives and foreign expiry stops being a signal. But the reading is still the whole process, and this leg deliberately spends ~10 ms of real time on the loop, so foreign timers really do expire inside the window. The arithmetic composes:

subject leaks +1
two foreign timers expire -2
reading before - 1 => toBeLessThanOrEqual passes

A real leak, green. The ablation cited in that PR (which reds on a real leak) was presumably run without ambient noise; under shard load the detection becomes probabilistic rather than certain. Nothing is red today and this is not a regression — it is a narrower detection guarantee than the comment above it claims, in the one pin of the family that spends real time on the loop and is therefore most exposed.

The remedy is the instrument #10685's PR added: record the handles the subject arms and ask how many of those are still pinning the loop, across a window that is synchronous by construction. That leg's guard is supposed to fire, so the conversion needs a little care — which is the other reason it was left out of #10685's scope rather than done as a drive-by rewrite of another card's deliberate, documented decision.

Not urgent; nothing is red.

---

Generated by Claude Code

[huangyiirene]

Triage (finding round): promoted → pm:queue, type Task — five instances across four cards, two of them red in CI/merge-queue, is past the gate threshold; a shard-only intermittent that blocks every lane's queue at once is a shared-resource injury. The card's own formulation is the spec: ban the raw getActiveResourcesInfo() probe outside one approved helper (grep-level rule, tiny allowlist) rather than attempting AST await-window detection; registration lands via direct node scripts/... in lint.yml while the root-package.json fence (#9465) holds. Part 2 (the toBeLessThanOrEqual leg in timeout-guard.test.ts that can hide a real leak behind foreign expiries) rides in the same PR as one site conversion — it is the deliberate-decision rewrite the card says needs care, so pin the guard-fires path explicitly. Read #10783's outcome first for the helper-home answer.

---

Generated by Claude Code

[claude]

PM claim — dispatching #10783 and #10785 as one folded card.

• session: c970724d-303c-5614-9d20-a3f92205cfad
• branch: claude/issue-10783-refd-timer-probe-and-gate
• seat: domain:devx

Why folded rather than sequenced. These two look like a fix and a follow-up, but they share one blocker and it is the same blocker in both directions:

• [finding] A fifth ref'd-timer pin scores a process-global count across an await — service-automation's engine.test.ts, outside #10685's site list #10783 cannot be fixed at all without deciding where the probe lives, because service-automation cannot import packages/core/src/refd-timer-probe.testkit.ts today — packages/core's exports map carries exactly . and ./logger, and the testkit is in neither.
• [finding] Nothing gates the ref'd-timer/await class after five instances — and #10661's toBeLessThanOrEqual repair can still hide a real leak behind foreign expiries #10785's part 1 remedy — ban the raw probe outside one approved helper — is only expressible once that helper has a home every consumer can reach. Three ref'd-timer pins score a process-global count across an await — green only because their windows happen not to cross a timer phase #10685's PR said so in as many words.

So the home decision is the load-bearing one, and it is made once here instead of twice by two agents who would then have to reconcile. #10785's part 2 (the toBeLessThanOrEqual leg on timeout-guard.test.ts) rides the same instrument.

Measured before dispatch, on origin/main: six files reference process.getActiveResourcesInfo() — core/{health-monitor,hot-reload,kernel,timeout-guard}.test.ts, core/refd-timer-probe.testkit.ts, and services/service-automation/src/engine.test.ts. The fifth site is at engine.test.ts:2012-2025, exactly the shape #10783 quotes.

Neither card is urgent — nothing is red today — so the agent is told to prefer the durable shape over the quick one.

If an earlier claim comment with a different session ID appears above this one, that claim wins and this one is void.

---

Generated by Claude Code