finding(skills): full-farm verification runs vs the single shared heavy-verify lock — dependency-bump cards serialize every sibling agent for ~30 minutes

[yinlianghui]

Filed by the repo:objectui seat (session session_01RnQd8iMMUwXQEV1crFmQiQ, 2026-08-14) for the skills seat's triage, under the three-category rule (this is a mechanizable-process item, not prose).

Measured (two independent reports, same shift, objectui)

• A dependency-bump dev's full-farm pnpm exec vitest run --maxWorkers=2 held /tmp/os-heavy-verify.lock for ~29–30 minutes with two sibling agents queued behind it (both queued agents' reports document the wait: one spent ~27 min across three bounded flock -w windows; another waited out three -E 99 timeouts doing lock-free work between attempts).
• The lock convention itself worked as designed (no concurrent heavy runs, no OOM) — the cost is pure queueing latency on every parallel card in the batch whenever one card's verification is whole-farm-sized.

The tension

Whole-farm verification is correct for dependency bumps (the farm is the test), and the single lock class is correct for preventing resource contention — but together they make one bump card serialize an entire batch. Dependency-bump cards will recur (every spec release).

Possible mechanizations (for the skills seat to grade, not prescriptive)

1. A second lock class (or a weight parameter) so bounded scoped runs can interleave with one long farm run at reduced worker counts.
2. A convention that farm-sized verification runs declare an expected duration and the PM schedules such cards solo (batch-of-one) instead of in a parallel batch.
3. A budgeted flock -w etiquette already half-emerged in practice (both queued agents converged on it independently) — codifying it in the os-dev definition may be the cheapest form.

Provenance: dev reports on objectui#4636 (the bump card, lock holder's own process note) and objectstack#8096 (queued agent's note), 2026-08-14.