---
name: your-cadence-can-be-the-blocker
description: "On a one-runner box, your own doc/register push cadence can be what gates the peer experiment you are supporting."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: bfeaecfe-d441-4294-9e1c-05349f38de7b
  modified: 2026-08-03T05:48:24.166Z
---

When supporting a peer's lane on a shared single-runner box, count your own pushes as
part of their queue. hfenduleam runs ONE self-hosted runner, and `ci.yml`'s docs-only
classifier early-returns `code=true` on every non-`pull_request` event — so each
docs-only push to main spins the full unit matrix including the Windows leg.

**Why:** 2026-08-03, filing IR-18/IR-19 as findings arrived, each landing as its own
push. Every one queued a Windows unit leg ahead of hertz's positive control — the single
experiment gating both the lane and the entry's evidence rating. Neither of us could see
it from our own side; hertz had to name it. The register work was worth doing, but
landing it incrementally made the supporting work the blocker for the supported work.

**How to apply:** batch routed text into one landing when a peer is waiting on the box;
ask who is queued before pushing docs. Centralizing writes through one owner (doyle now
holds register writes) fixes the crossing class, not just the instance. Related:
[[serial-legs-share-runner-workdir]], [[two-runs-per-sha-notification-trap]].