test: three timing-sensitive tests still fail on a loaded runner, with no landed fix

[ivndev001]

Steps

Open any PR whose branch is a few days behind main, or re-run test + coverage (latest ruby/rails) on a loaded runner.

Expected

A PR whose diff touches no lib/ file, and in two cases no test/ file at all, gets a green suite.

Actual

Four of the five PRs open on 2026-09-03 went red on test + coverage, and none of the failures was caused by the PR's diff. Six distinct timing-sensitive methods across five files failed on a loaded runner:

Test	File	Landed fix on main
SwarmSupervisionTest#test_crash_loop_backoff_grows_and_term_drains_while_pending	test/integration/swarm_supervision_test.rb	yes — #518
TimeoutHangTest#test_a_genuinely_sleeping_job_past_its_deadline_is_abandoned_and_booked_expired	test/integration/timeout_hang_test.rb	yes — #518, reinforced by #519
ApiMutationsTest#test_bulk_deduplicates_repeated_keys	test/engine/api_mutations_test.rb	yes — #520
WebSearchTest#test_search_bounds_round_trips_on_a_huge_no_match_queue	test/unit/web_search_test.rb	no
LimiterStressTest#test_1000_concurrent_acquires_never_exceed_the_limit	test/integration/limiter_stress_test.rb	no
WebExtensionsTest#test_search_kinds_filter	test/engine/web_extensions_test.rb	no

Three fixes landed on main on 2026-09-03/04. The bottom three have no landed fix, and they are the subject of this issue.

Observed failure text, for identification:

• WebSearchTest — Expected 104 to be <= 102 (a bounds assertion that hard-codes ONE queue; see the corrected diagnosis below)
• LimiterStressTest — 17 acquires timed out with a 15s wait
• WebExtensionsTest — expected ["retry"], got []

Version

Filed against main at b29d659010e56f6b5cf0605cd306a3ad421b308c.

Why this is worth its own issue

The three open CI issues do not cover this class, and each was checked:

• ci: a rubocop release can redden required lint on main with no PR at fault #471 (a rubocop release can redden required lint) — lint (rubocop) passed on all five PRs. Not firing.
• ci: the dependabot lockfile fix leaves the PR red, so the queued merge never fires #470 (the dependabot lockfile fix leaves the PR red) — none of the five is a Dependabot PR. Does not apply.
• ci: parity and lint are required checks that a docs-only PR satisfies by skipping #469 (required checks a docs-only PR satisfies by skipping) — the inverse mechanism, and it is live in this set in the permissive direction. It explains how a docs PR reaches green without gating, never why one went red.

So the failures are a real, uncovered class: timing-sensitive integration tests that fail on a loaded runner. The cost is not theoretical — it is why four PRs sat red for days while their diffs were fine, and why a rebase is currently the standard remedy for a test result that had nothing to do with the change.

The three root causes are DIFFERENT — do not apply one remedy to all three

An earlier version of this issue folded all three under "make the assertion follow the clock or the
schedule rather than a fixed wall-clock margin". That fits two of them and actively misleads on the
third, which has no clock at all.

1. WebSearchTest — the bound hard-codes one queue; the driver is how many queues EXIST. The
   original gloss ("assumes the queue did not grow under load") is wrong and the cited code says so:
   queue_scan_stop caps at [SCAN_LIMIT_PER_QUEUE, SCAN_BUDGET - @scanned].min
   (lib/wurk/web/search.rb), so the seeded queue's SIZE cannot move the counter — the test's own
   comment already notes the count is "never proportional to the queue's real size". What moves it is
   search_queues iterating Queue.all, which is SMEMBERS of the shared Keys::QUEUES_SET
   (lib/wurk/queue.rb:33-36): one SMEMBERS + one LLEN + 100 LRANGE = exactly 102 for a single 10k
   queue, which is max_round_trips with ZERO margin. Every additional member of that set adds at
   least one more round trip.

   WHO adds the extra members is NOT established — do not invent an answer. An earlier revision
   of this issue blamed concurrent sibling methods under parallelize_me!. That is false:
   Wurk::Test::UnitCase overrides def self.parallelize_me! with an EMPTY body
   (test/test_helper.rb:199-201), minitest-parallel_fork re-extends any genuinely parallel suite
   with Minitest::Unparallelize anyway, and test/integration/swarm_boot_test.rb:92-97 states both
   in prose. Two hypotheses remain consistent with the repo and neither is confirmed: a leaked
   scheduled poller re-enqueuing due entries and SADDing their queues (the mechanism test: seed the API mutation sorted-set fixtures not-yet-due #520's own
   comment records at test/engine/api_mutations_test.rb:297-309), or two suite runs sharing one
   Redis instance on a loaded runner.

   Remedy: because the writer is unidentified, the fix must hold when the set changes during the
   measured window, not merely when it is larger at the start. Either derive the bound from the
   queues present in a way that tolerates concurrent mutation, or give this test its own Redis
   logical DB / capsule (as DemoWorkloadTest does with Wurk::Test::DEDICATED_DB) so Queue.all
   can only ever see its own queue. Do NOT "isolate Keys::QUEUES_SET" by editing
   lib/wurk/keys.rb — that is a lib/ change, which the diff-scope criterion forbids and which
   would make this slice runtime-affecting. Do NOT widen SCAN_LIMIT_PER_QUEUE or QUEUE_PAGE —
   they are a real DoS guard ("a keystroke must never full-walk a multi-million-entry queue") and
   this test is the only thing pinning them.

2. WebExtensionsTest — a due-NOW seed that a scheduled poller drains first. :189-192 seeds
   ZADD <name> Time.now.to_f, which is exactly the pattern test: seed the API mutation sorted-set fixtures not-yet-due #520 fixed in
   api_mutations_test.rb:296-310 by seeding a future score (+ 3600). That landed comment names
   the mechanism: "a due entry in the worker's shared Redis DB is exactly what a scheduled poller
   still running from an earlier class pops before the request lands." This is the clock/schedule
   remedy, and it is a direct mirror of merged precedent.

3. LimiterStressTest — genuinely wall-clock dependent. 1000 acquires against limit 5 across 50
   threads under a fixed wait_timeout: 15. This is the hard one; pick and state an approach in the
   PR rather than tuning the number, and show how the replacement is demonstrated red.

Do not simply widen a constant, and do not delete an assertion that is testing something real.

Acceptance criteria

All three tests PASS on a quiet runner today, so bin/check green proves nothing on its own. These
criteria are what go red against current main:

• WebSearchTest: a case that mutates Keys::QUEUES_SET concurrently with the measured
  window — a thread SADDing sibling queues while the search runs — still satisfies the bound
  (red today, and unlike a population fixed before the counter is installed, this is the shape
  that actually flakes; a Queue.all.size snapshot taken at assert time passes the static
  version and still flakes)
• WebExtensionsTest: a case where a due-now-seeded retry entry is drained before the request is
  made still returns ["retry"] from the kinds filter (red today)
• LimiterStressTest: the test asserts the ATOMICITY invariant it exists for — max_seen <= limit and limiter.size == 0 — without asserting over_limit == 0, and a case that
  deliberately starves the limiter is added showing that new assertion red
• no wait/timeout literal in test/integration/limiter_stress_test.rb increases relative to
  origin/main — wait_timeout: 15 at :36 lives inside test/**, so the diff-scope criterion
  below does not reach it, and raising it is the exact "buy green by widening a constant" this
  issue forbids
• the diff touches only test/** — git diff --name-only origin/main...HEAD lists no path
  outside test/. This is what stops "buy green by widening SCAN_LIMIT_PER_QUEUE"
• the PR body states, per test, what the old assertion depended on and what the new one depends
  on instead
• no test is deleted or skipped to reach green
• gates green: bin/check (lint + suite + parity)

Affected paths

test/unit/web_search_test.rb, test/engine/web_extensions_test.rb, test/integration/limiter_stress_test.rb

AFK / HITL

AFK.

Verified against

42cc4e4

[ivndev001]

spec-gate verdict: NEEDS-SPEC

Verification complete; advisor incorporated. Final verdict:

issue: 522
repo: developerz-ai/wurk
bodyRevision: live
verdict: NEEDS-SPEC
checklist:
  - id: C1
    name: No-op against its own stated problem
    status: pass
    evidence: |
      git diff b29d659..origin/main -- test/unit/web_search_test.rb
      test/integration/limiter_stress_test.rb test/engine/web_extensions_test.rb
      returns EMPTY. All three target files are byte-identical from the cited
      commit to today's tip (42cc4e4, 2026-09-17), so the draft's central claim
      ("the bottom three have no landed fix") still holds and the prescribed work
      is not inert. #518 touched swarm_supervision_test.rb + timeout_hang_test.rb,
      #519 touched timeout_hang_test.rb, #520 touched api_mutations_test.rb —
      none of the three targets.
  - id: C2
    name: Standing ruling reversal
    status: pass
    evidence: |
      wurk CLAUDE.md's "Never" list does not bar editing tests (it bars Redis
      key/JSON schema changes, MessagePack, mocking Redis, license checks,
      compat shims, --no-verify, shared fork sockets, force-push main). Its
      "Parity tests are oracles" rule is scoped to test/parity/; none of the
      three targets lives there. The workspace rule "never modify tests to make
      them pass" carries an "unless the test itself is wrong" carve-out, and
      #518/#519/#520 are merged precedent for exactly this edit class. The draft
      does not reverse the posture — AC#4 ("no test is deleted or skipped to
      reach green") restates it.
  - id: C3
    name: Repo-wide lockout
    status: pass
    evidence: |
      .dz/pipeline/agent-pipeline.json declares merge.reviewGate "ci-only" and
      NO policy.module, so isPolicyRepo is false and decideMerge's
      review-gate-conflict branch is unreachable. Change is test-only; no new
      required check, no ruleset review count, no fail-closed branch added.
  - id: C4
    name: Live-test provenance
    status: pass
    evidence: |
      As written the slice is non-deploying (test/ only). The repo declares
      policy.defaultTier "GREEN" and no policy.module, so effectiveTier yields
      {fallbackTier} and a fenceless governing issue short-circuits to
      NOT_REQUIRED. The draft carries no `## Live test` fence, which is correct
      here — inventing one would buy the C4-bullet-2 signalling hazard and arm
      revert.ts for nothing. NOTE: this pass depends on the diff staying out of
      lib/, which the draft does not require — see blocker 3.
  - id: C5
    name: Checkable acceptance
    status: fail
    evidence: |
      No criterion is mutation-sensitive. All three target tests PASS today on a
      quiet runner — they are flaky under load, not deterministically red — so
      AC#1 `bin/check` green cannot distinguish "fixed the flake" from "changed
      nothing" from "widened a constant", and C5 names suite-green as explicitly
      not the mutation-sensitive criterion. AC#2 "made robust on a loaded runner
      without weakening what it asserts" uses the exact unfalsifiable word C5
      lists ("make it robust"); no load harness exists anywhere in the repo
      (git ls-tree finds only limiter_stress_test.rb itself), no command is
      given, and "weakening" is an author-context judgement. AC#3 is a PR-body
      prose requirement. AC#4 is an absence check. Nothing here goes red today.
  - id: C6
    name: Draft's own evidence
    status: fail
    evidence: |
      test/unit/web_search_test.rb:183 — `max_round_trips = 2 +
      (SCAN_LIMIT_PER_QUEUE / QUEUE_PAGE)` = 2 + 5000/50 = 102, matching the
      quoted "Expected 104 to be <= 102". But the draft's causal gloss "(a bounds
      assertion that assumes the queue did not grow under load)" is contradicted
      by the code it cites: lib/wurk/web/search.rb `queue_scan_stop` caps at
      `[SCAN_LIMIT_PER_QUEUE, SCAN_BUDGET - @scanned].min`, so the seeded queue's
      size cannot move the counter — the test's own comment says so ("never
      proportional to the queue's real size (10k would need ~200 LRANGE calls to
      full-walk instead of the capped ~100)"). The real driver is the NUMBER of
      queues: `search_queues` iterates `Queue.all`, which is SMEMBERS of the
      shared `queues` SET (lib/wurk/queue.rb:33-36), and WebSearchTest is
      `parallelize_me!` so concurrent sibling methods each SADD their own
      `@queue` (+1 LLEN each; 104 - 102 = 2 siblings in flight).
      Consequence: the draft's prescription "make the assertion follow the clock
      or the schedule rather than a fixed wall-clock margin" is inapplicable to a
      test with no clock and no wall-clock margin, steering an executor toward
      the one remedy the draft prohibits ("do not simply widen a constant").
      Scope note: this is ONE sentence. Every other citation verified — see notes.
  - id: C7
    name: Fail-open
    status: pass
    evidence: |
      The prescribed direction is not fail-open: re-anchoring an assertion to the
      invariant it means to test removes no blocker, widens no accept condition,
      relaxes no fail-closed default, shortens no named wait, and makes no absent
      signal count as permission. Hard class does not apply by FUNCTION — these
      test/ files are graded BY the gate, they do not decide whether a PR may
      merge, what review it carries, how a diff is classified, whether a live
      test is required, or whether a revert arms; reading them as hard-class on a
      ci-only repo would park every test change. NOTE (risk, not a FAIL): a
      fail-open SHORTCUT exists and produces green CI — widening
      `max_round_trips`, or raising `wait_timeout: 15` in limiter_stress_test.rb
      — and `SCAN_LIMIT_PER_QUEUE` is a real DoS guard ("a keystroke must never
      full-walk a multi-million-entry queue") that this test alone pins. The
      draft forbids that path in prose only; blockers 1 and 3 are what convert
      the prohibition into checks.
  - id: C8
    name: Blast radius and reversibility
    status: pass
    evidence: |
      One concern (one flake class), three files, size/2h — one PR's worth under
      the concerns-not-directories test. No mutation a revert cannot reach: no
      issue/label edits, no repo settings, no rulesets, no secrets, no deletions.
      Reversible by reverting the merge commit; revert.ts does not arm (no fence,
      NOT_REQUIRED via fallbackTier). NOTE: the three items have three distinct
      root causes (due-now zset score / concurrent-queue count / wall-clock
      wait), so "one concern" is thematic rather than mechanical — defensible,
      but it is why blocker 1 asks for a per-test criterion rather than one.
  - id: C9
    name: Work is real
    status: pass
    evidence: |
      (a) Abundant resolvable evidence: six file paths and six test method names
      all present on origin/main; commit b29d659 exists and is an ancestor of
      origin/main; PRs #518/#519/#520 exist, MERGED, with titles and touched-file
      lists matching the credit the draft gives them. (b) No `## Parent` section,
      so limb (b) is not engaged.
blockers:
  - criterion: C5
    defect: >
      No acceptance criterion is red against today's code; all three tests pass
      on a quiet runner, so bin/check green proves nothing about the flake.
    fix: >
      Add a per-test mutation-sensitive criterion that fails today. Two are
      mechanical: for WebSearchTest, a case that SADDs K sibling queues into the
      `queues` SET before installing RoundTripCounter and asserts the bound still
      holds (red today, since the bound hard-codes one queue); for
      WebExtensionsTest, a case where a due-now-seeded retry entry is drained
      before the request and the kinds filter still returns ["retry"] — or, at
      minimum, a presence-grep that web_extensions_test.rb's push_to_zset seeds a
      future score, mirroring the `+ 3600` #520 landed in
      api_mutations_test.rb:305. The third is genuinely hard and the draft must
      pick an approach rather than leave it to the executor: state what replaces
      LimiterStressTest's dependence on the fixed `wait_timeout: 15`, and how
      that replacement is demonstrated red.
  - criterion: C6
    defect: >
      The WebSearchTest diagnosis names queue growth, which the cited code makes
      impossible, and the shared "follow the clock or the schedule" prescription
      does not fit a test that has no clock.
    fix: >
      Replace "(a bounds assertion that assumes the queue did not grow under
      load)" with the real driver — round trips scale with the number of queues
      in the shared `queues` SET that `Queue.all` SMEMBERS-iterates, while
      `queue_scan_stop` caps per-queue scanning so the seeded queue's size cannot
      move the count — and give WebSearchTest its own prescription (derive the
      bound from the queues actually present, or isolate the `queues` SET for
      that test) instead of folding it under the clock/schedule rule that fits
      only the other two.
  - criterion: C5
    defect: >
      The draft never scopes the fix's diff. An executor may edit
      SCAN_LIMIT_PER_QUEUE / QUEUE_PAGE in lib/wurk/web/search.rb, which both
      makes the slice runtime-affecting (C4 bullet 1 then bites a fenceless
      draft) and is the exact "widen a constant" the draft prohibits.
    fix: >
      Add an acceptance criterion that the diff touches only `test/**` — e.g.
      "`git diff --name-only origin/main...HEAD` lists no path outside test/".
      One grep-able line; it closes the C4 exposure and turns the fail-open
      prohibition into an enforceable check.
notes: >
  Audited the LIVE body (no caller-pinned revision; `gh issue view 522 --comments`
  returns zero comments, so nothing amends it). Author ivndev001, created
  2026-09-07T12:05:20Z.

  CITATION QUALITY — the C6 fail is one sentence, not a pattern, and should not
  be read as a blanket evidence failure. Everything else verified: issues
  #469/#470/#471 all resolve via `gh api repos/developerz-ai/wurk/issues/N` with
  no `pull_request` key (all genuine ISSUES, all open) and their titles match the
  draft's characterisations verbatim; #518/#519/#520 are MERGED PRs whose touched
  files match the fixes credited to them; "Expected 104 to be <= 102" is
  arithmetically exact against web_search_test.rb:183.

  NO DRIFT, NO STALE-ON-ARRIVAL — unusually, this draft's version stamp is
  correct. b29d659 was main's tip from 2026-09-04T06:38Z until a80034b on
  2026-09-07T15:30Z; the issue was filed 12:05Z that day, inside that window.
  The only LimiterStress nit is a paraphrase, not a misquote: the draft renders
  "17 acquires timed out with a 15s wait" where the assertion message is "no
  acquire should time out with a 15s wait (17 did)". NOTE only.

  NOT VERIFIED, AND NOT LOAD-BEARING — "four of the five PRs open on 2026-09-03
  went red" is corroborated circumstantially (#502/#508/#509/#511/#512 were all
  created 2026-09-03 and all merged 2026-09-07, matching "sat red for days") but
  I did not read check-run conclusions per PR. The two claims the verdict rests
  on — load-sensitivity, and no-landed-fix — were both verified directly at the
  code instead.

  MECHANISM CONFIRMED FOR TWO OF THREE. WebExtensionsTest is the strongest item
  in the draft: web_extensions_test.rb:189-192 still seeds `ZADD name
  Time.now.to_f` (due NOW), the precise pattern #520 fixed in
  api_mutations_test.rb, whose landed comment names the failure mode — "a due
  entry in the worker's shared Redis DB is exactly what a scheduled poller still
  running from an earlier class pops before the request lands". That fully
  explains `expected ["retry"], got []`. LimiterStressTest's `wait_timeout: 15`
  over 1000 acquires against limit 5 across 50 threads is genuinely wall-clock
  dependent. Only the WebSearchTest gloss is wrong.

  PRECHECK — MATERIAL TO THE CALLER. This body carries no `## Verified against`
  stamp and no `## Affected paths` section (it predates the prd-to-issue
  convention), so it would not clear `precheckBody` / `offload-gate.ts`
  regardless of this C1-C9 verdict. Its `## Version` section carries the SHA but
  under the wrong heading.

  LABELS — `afk` present, `hitl` absent: no label-hygiene contradiction, and the
  C7 attended-draft waiver is neither invoked nor needed.

  REVERT POSTURE — worth stating because it is subtle: no fence +
  policy.defaultTier "GREEN" + no policy.module means runLiveTest returns
  NOT_REQUIRED via the fallbackTier path, so revert.ts does not arm on this
  issue. That is the correct outcome for a test-only slice; it also means the
  post-merge net here is a manual revert of the merge commit and nothing else,
  which is why blocker 3 (test/**-only scope) matters more than it looks.

  C2 ATTENDANCE — not load-bearing here. No fail-open leg is being cleared, so
  the unrestorable attendance property (recorder shipped in
  unattended-selection.ts, zero production callers, wiring tracked by #872) does
  not bear on this verdict.

  WHY THIS IS NEEDS-SPEC AND NOT A NITPICK. The draft is well-researched and its
  problem is real. But on this repo `merge.reviewGate` is "ci-only" with
  `merge.standingAuthorization: true`, so CI green IS the entire gate and an
  unattended executor merges on it with no human reading the diff. The subject of
  this issue is three assertions that are green today and red only under load —
  the one situation where "the suite is green" is actively misleading — and the
  draft's only defence against an executor buying green by widening a bound is
  prose. The three blockers are small, concrete draft edits: two red-today
  criteria that are already mechanical, one sentence corrected, one grep-able
  scope line.

Files read (all at origin/main, commit 42cc4e42d20ca4ddfb2dfb8d7d02cc481735e986, via git show origin/main:<path> in /home/ivann/ws/developerz.ai/Projects/wurk):

• /home/ivann/ws/developerz.ai/Projects/wurk/.dz/pipeline/agent-pipeline.json — the gate config that makes this verdict repo-specific
• /home/ivann/ws/developerz.ai/Projects/wurk/test/unit/web_search_test.rb (:170-190, :258-282)
• /home/ivann/ws/developerz.ai/Projects/wurk/lib/wurk/web/search.rb (search_queues, scan_queue_list, queue_scan_stop)
• /home/ivann/ws/developerz.ai/Projects/wurk/lib/wurk/queue.rb (:33-36)
• /home/ivann/ws/developerz.ai/Projects/wurk/test/engine/web_extensions_test.rb (:60-70, :187-192)
• /home/ivann/ws/developerz.ai/Projects/wurk/test/engine/api_mutations_test.rb (:296-310 — the test: seed the API mutation sorted-set fixtures not-yet-due #520 fix this draft should mirror)
• /home/ivann/ws/developerz.ai/Projects/wurk/test/integration/limiter_stress_test.rb (:34-68)
• /home/ivann/ws/developerz.ai/Projects/wurk/test/test_helper.rb, /home/ivann/ws/developerz.ai/Projects/wurk/bin/check

The single load-bearing contradiction, for the caller's convenience — draft says the WebSearchTest bound "assumes the queue did not grow under load", but lib/wurk/web/search.rb caps it independently of queue size:

def queue_scan_stop(size)
  cap = [SCAN_LIMIT_PER_QUEUE, SCAN_BUDGET - @scanned].min
  @truncated = true if size > cap
  [size, cap].min
end

run: a99ca6470c9c40758
provider: anthropic
model: claude-opus-5

[ivndev001]

spec-gate verdict: NEEDS-SPEC

Verification complete. Writing the verdict.

issue: 522
repo: developerz-ai/wurk
bodyRevision: live
verdict: NEEDS-SPEC
checklist:
  - id: C1
    name: No-op against its own stated problem
    status: pass
    evidence: |
      `git diff --stat b29d659 origin/main -- test/unit/web_search_test.rb
      test/engine/web_extensions_test.rb test/integration/limiter_stress_test.rb`
      returns EMPTY: all three targets are byte-identical from the filed-against
      commit to tip (42cc4e4), so "the bottom three have no landed fix" holds.
      The prescriptions are not inert: deriving the WebSearch bound from the
      queues present changes the assertion in the failure case (see C6 for the
      proof that queue COUNT is the only thing that can move the counter), and
      seeding a future score changes what a poller can drain. NOTE: the
      LimiterStress prescription is "pick and state an approach in the PR" —
      no prescription to test for inertness. See blocker 3.
  - id: C2
    name: Standing ruling reversal
    status: pass
    evidence: |
      Scope is the TARGET repo. wurk's CLAUDE.md "Never" list bars Redis key /
      job-JSON changes, MessagePack, mocking Redis in integration/parity tests,
      license checks, compat shims, --no-verify, shared fork sockets and
      force-push to main — not test edits. "Parity tests are oracles" is scoped
      to test/parity/; none of the three targets lives there. The workspace-level
      "never modify tests to make them pass" rule is in the developerz.ai
      workspace AGENTS.md, NOT in wurk, and carries an "unless the test itself is
      wrong" carve-out; PRs #518/#519/#520 (all MERGED, titles read back via
      `gh api repos/developerz-ai/wurk/issues/N`) are in-repo precedent for this
      exact edit class. AC "no test is deleted or skipped to reach green"
      restates the posture rather than reversing it.
  - id: C3
    name: Repo-wide lockout
    status: pass
    evidence: |
      .dz/pipeline/agent-pipeline.json declares merge.reviewGate "ci-only",
      standingAuthorization true, policy.defaultTier "GREEN" and NO policy.module
      — so isPolicyRepo is false and decideMerge's review-gate-conflict branch is
      unreachable. Change adds no required check, no ruleset review count, no
      fail-closed branch. Legacy root .agent-pipeline.json is not on origin/main.
  - id: C4
    name: Live-test provenance
    status: pass
    evidence: |
      Non-deploying as scoped (test/** only), repo declares policy.defaultTier
      "GREEN" with no policy.module, so a fenceless governing issue resolves
      NOT_REQUIRED and no fence is wanted (inventing one would buy the signalling
      hazard and arm revert.ts for nothing). CONTINGENT: this pass holds only
      because AC4 keeps the diff out of lib/. The draft's own WebSearch remedy
      option 2 ("isolate the `queues` SET for this test") points at
      `Keys::QUEUES_SET` = 'queues' (lib/wurk/keys.rb:18) — an executor taking it
      literally makes the slice runtime-affecting and C4 bullet 1 then bites.
      See blocker 4.
  - id: C5
    name: Checkable acceptance
    status: fail
    evidence: |
      AC1 and AC2 are genuinely red-today, which the previous body lacked — but
      two defects remain.
      (a) AC1 models the queue population as STATIC: it SADDs K sibling queues
      "before installing the round-trip counter", fixed for the measured window.
      The CI failure is a LOAD failure, i.e. the population changes DURING the
      window. A fix that snapshots `Queue.all.size` at assert time passes AC1 and
      still flakes, because the snapshot and the search's own SMEMBERS are two
      reads. The draft's only red-today WebSearch criterion therefore cannot
      detect the failure that filed the issue.
      (b) AC3 is satisfiable by the exact move the draft prohibits.
      "the assertion no longer depends on the fixed `wait_timeout: 15`" is
      literally satisfied by `wait_timeout: 60`
      (test/integration/limiter_stress_test.rb:36), and AC4's `test/**` scope
      does not reach it because wait_timeout lives in the TEST file. It is the
      only criterion covering one of the three subjects, and the rest of it ("the
      PR shows the replacement failing") is a PR-body prose requirement, not a
      command, file state or API response a stranger can check. The prior verdict
      asked the draft to STATE the LimiterStress approach; the rewrite converted
      that demand into a criterion that restates the demand.
      Brittleness rules themselves are clean: no bare absolute counts, symbol-
      anchored references, and AC4 is a grep-able diff-scope check.
  - id: C6
    name: Draft's own evidence
    status: fail
    evidence: |
      The corrected WebSearchTest mechanism is half proven and half contradicted.
      PROVEN HALF (verified at the code, not taken): `queue_scan_stop` caps at
      `[SCAN_LIMIT_PER_QUEUE, SCAN_BUDGET - @scanned].min`
      (lib/wurk/web/search.rb:124-128), so queue SIZE cannot move the counter;
      round trips on the counting thread are 1 SMEMBERS + 1 LLEN + 100 LRANGE =
      exactly 102 for one 10k queue, matching `max_round_trips` at
      test/unit/web_search_test.rb:183 with ZERO margin, and each additional
      queue in `Keys::QUEUES_SET` adds >= 1. `Queue.all` is SMEMBERS of that set
      at lib/wurk/queue.rb:33-36, cited accurately. Nothing else on the counting
      thread can add a trip (growth cannot add pages; the capsule is
      thread-local, lib/wurk.rb:146-148). So "the driver is the NUMBER of queues"
      is forced by the code.
      CONTRADICTED HALF — the attribution, which is what the rewrite was asked to
      establish: "while the class is `parallelize_me!` and every concurrent
      sibling method SADDs its own queue ... 104 - 102 = 2 is two siblings in
      flight". There are no concurrent sibling methods, on three independent
      legs. (1) test/test_helper.rb:199-201 — `Wurk::Test::UnitCase` overrides
      `def self.parallelize_me!` with an EMPTY body, shadowing Minitest's, and
      WebSearchTest is a UnitCase subclass. Demonstrated empirically under
      minitest 6.0.6: with that stub in the base class,
      `Child.ancestors.include?(Minitest::Parallel::Test)` => false,
      `Child.method(:parallelize_me!).owner` => the stubbing base (an unstubbed
      control class gives true). (2) minitest-parallel_fork 2.1.1
      `parallel_fork_run_test_suite` re-extends any genuinely parallel suite with
      `Minitest::Unparallelize`, so even a working parallelize_me! runs serially
      inside the fork. (3) The repo states both in prose at
      test/integration/swarm_boot_test.rb:92-97: "`Wurk::Test::UnitCase`
      overrides `parallelize_me!` with a no-op ... and parallel_fork re-extends
      any genuinely parallel suite with Minitest::Unparallelize anyway. Across
      classes: parallel_fork deals whole suites round-robin to NCPU forked
      workers that each run their slice sequentially on their own Redis logical
      DB." test/support/redis_namespace.rb:3-7 says the same and FLUSHDBs after
      every test. The rewrite replaced one wrong diagnosis with another; the
      identity of the concurrent writer is still unestablished, and AC1 inherits
      the wrong model (see C5).
  - id: C7
    name: Fail-open
    status: pass
    evidence: |
      Not hard class by FUNCTION: these test/ files are graded BY the gate; they
      do not decide whether a PR may merge, what review it carries, how a diff is
      classified, whether a live test is required, or whether a revert arms.
      Reading them as hard-class on a ci-only repo would park every test change.
      None of the five triggers fires on the prescribed direction — re-anchoring
      an assertion to the invariant it means to test removes no blocker, widens
      no accept condition, relaxes no fail-closed default, shortens no NAMED
      check or blocker, and makes no absent signal count as permission.
      NOTE (exposure, not a FAIL): on this repo CI green IS the merge gate
      (reviewGate "ci-only", standingAuthorization true,
      required_approving_review_count 0), so a weakened assertion is a quietly
      widened accept condition. Two fail-open shortcuts produce green CI:
      widening `max_round_trips` (or a generous derived bound), and raising
      `wait_timeout` in limiter_stress_test.rb. AC4 converts the first
      prohibition into a check only for lib/ constants — `SCAN_LIMIT_PER_QUEUE`
      (lib/wurk/web/search.rb:34, a real DoS guard this test alone pins) is
      protected; the in-test constants are not. That is scored as the C5 defect.
      No `## Blocked by` ordering dependency is claimed or needed.
  - id: C8
    name: Blast radius and reversibility
    status: pass
    evidence: |
      One concern (one flake class), three files, size/2h — one PR's worth under
      the concerns-not-directories test. No mutation a revert cannot reach: no
      issue/label edits, no repo settings, no rulesets, no secrets, no deletions,
      no credential minting or plaintext secret read. Reversible by reverting the
      merge commit; revert.ts does not arm (fenceless + fallbackTier GREEN =>
      NOT_REQUIRED). NOTE: three distinct root causes under one heading, so "one
      concern" is thematic — defensible, and the draft now carries per-test
      remedies rather than one.
  - id: C9
    name: Work is real
    status: pass
    evidence: |
      (a) Every cited artifact resolves: six test files and six method names
      present on origin/main; b29d659 exists and `git merge-base --is-ancestor`
      confirms it is an ancestor of origin/main; #518/#519/#520 resolve with a
      `pull_request` key (MERGED PRs, titles match the fixes credited);
      #469/#470/#471 resolve with NO `pull_request` key (genuine OPEN issues,
      titles match the draft's characterisations). (b) No `## Parent` section, so
      limb (b) is not engaged.
blockers:
  - criterion: C6
    defect: >
      The rewrite's WebSearchTest attribution — concurrent sibling methods under
      `parallelize_me!` — is contradicted by the repo: UnitCase stubs
      `parallelize_me!` to a no-op (test/test_helper.rb:199-201), parallel_fork
      un-parallelizes any real parallel suite anyway, and
      swarm_boot_test.rb:92-97 documents both. The driver (queue COUNT) is right;
      the account of who adds the queues is wrong and remains unidentified.
    fix: >
      Strike the `parallelize_me!` / "two siblings in flight" sentence and keep
      only the half the code proves: round trips scale with the cardinality of
      `Keys::QUEUES_SET` that `Queue.all` SMEMBERS-iterates, while
      `queue_scan_stop` caps per-queue scanning so the seeded queue's size cannot
      move the count. Then either name and cite the concurrent writer, or state
      that it is unidentified and require the remedy to hold when the set changes
      DURING the measured window.
  - criterion: C5
    defect: >
      AC1 SADDs K sibling queues "before installing the round-trip counter" — a
      population fixed for the whole measured window. The CI failure is a
      concurrent-population failure, so a `Queue.all.size` snapshot taken at
      assert time passes AC1 and still flakes. The draft's only red-today
      WebSearch criterion cannot detect the failure that filed the issue.
    fix: >
      Require the criterion to mutate `Keys::QUEUES_SET` CONCURRENTLY with the
      measured window (e.g. a thread SADDing sibling queues while the search
      runs) and assert the bound still holds — or require the remedy to be
      independent of the set's cardinality at any instant (give the test its own
      Redis DB / capsule so `Queue.all` can only ever see its own queue).
  - criterion: C5
    defect: >
      AC3 is satisfied by `wait_timeout: 60` — the exact "widen a constant" the
      draft prohibits in prose — because `wait_timeout: 15` lives at
      test/integration/limiter_stress_test.rb:36, inside the `test/**` scope AC4
      allows. It is the only criterion covering LimiterStressTest, and its second
      half is a PR-body prose requirement rather than anything a stranger can
      run. It restates the prior verdict's demand instead of answering it.
    fix: >
      State the LimiterStress approach in the DRAFT, not "in the PR", and make it
      checkable — e.g. "the test asserts the atomicity invariant
      (`max_seen <= limit`, `limiter.size == 0`) without asserting
      `over_limit == 0`, and a case that deliberately starves the limiter is
      added showing the new assertion red", plus a grep-able criterion that no
      wait/timeout literal in the file increases relative to origin/main.
  - criterion: C4
    defect: >
      The draft's own WebSearch remedy option 2, "isolate the `queues` SET for
      this test", points at `Keys::QUEUES_SET` (lib/wurk/keys.rb:18) — a lib/
      constant. Following it literally violates the draft's own AC4 and makes a
      fenceless slice runtime-affecting, which parks it.
    fix: >
      Re-word option 2 to a test-only form: "run this test against its own Redis
      logical DB / capsule (as DemoWorkloadTest does with
      `Wurk::Test::DEDICATED_DB`) so `Queue.all` can only see its own queue", or
      drop option 2 and keep only "derive the bound from the queues present".
notes: >
  RE-GATE, LIVE BODY. Audited the current body as returned by `gh issue view 522
  --json body` (no caller-pinned revision). One comment exists — a prior
  spec-gate NEEDS-SPEC verdict by ivndev001 at 2026-09-17T18:48:39Z. I scored
  every criterion from the code afresh and did not carry any prior finding
  forward. The rewrite genuinely fixed two of the three prior blockers (the
  diff-scope criterion, and two red-today criteria replacing "made robust"), and
  genuinely re-diagnosed the WebSearch mechanism — but the replacement diagnosis
  is itself contradicted, which is why C6 fails again on different evidence.

  ROOT CAUSE IS NOT ESTABLISHED, AND I AM NOT SUPPLYING ONE. What the code
  forces is only that extra members in `Keys::QUEUES_SET` are the sole way to
  exceed 102 on the counting thread. Who adds them under load is NOT established
  read-only. Two hypotheses are consistent with the repo (a leaked scheduled
  poller re-enqueuing due entries and SADDing their queues — the exact mechanism
  #520's own comment at test/engine/api_mutations_test.rb:297-309 records; or two
  suite runs sharing one Redis instance on a loaded runner) and I could verify
  NEITHER. Writing either into the draft would repeat the defect this verdict
  fails.

  NO DRIFT, NO STALE-ON-ARRIVAL. `## Verified against` is 42cc4e4, which IS
  origin/main's tip (`chore(mise): pin bun and node alongside ruby (#531)`).
  b29d659 is an ancestor, and the three target files are byte-identical from it
  to tip.

  NOTES, NOT FAILS: (1) `web_extensions_test.rb:189-192` — `push_to_zset` spans
  187-191 with the ZADD at 189; symbol and mechanism hold. (2) The LimiterStress
  failure text is paraphrased ("17 acquires timed out with a 15s wait"); the
  assertion message at :65 is "no acquire should time out with a 15s wait (17
  did)". (3) "one extra `LLEN` each" is incomplete even granting the (wrong)
  concurrency premise — a non-empty sibling queue adds LLEN + at least one
  LRANGE, so "104 - 102 = 2" admits more than one reading. (4) Item 2's
  quotation of #520's landed comment is verbatim and correct, and item 2's
  mechanism is the strongest part of the draft.

  CALLER PREMISE, CORRECTED PATH. `.maintainer.yml` is NOT on origin/main — it
  exists only in the local working tree. The committed posture is
  `.dz/maintainer/maintainer.yml:126` `auto_merge: true`, with the file's own
  read-back note recording `required_approving_review_count` 0 and
  "Merges are gated by MACHINES — CI green plus the ruleset — not by a human
  review". `.dz/pipeline/agent-pipeline.json` adds `standingAuthorization: true`.
  So the caller's weighting is right in substance: a READY here authorises a
  build-and-merge no human reads, on a subject whose whole remedy space includes
  making three assertions weaker. That is why C5(b) is scored a FAIL rather than
  a note — the LimiterStress third of this slice currently has no check that an
  unattended executor cannot satisfy by raising a number.

  VERIFICATION METHOD. All code read via `git show origin/main:<path>` against a
  freshly fetched origin/main (42cc4e4); never the working tree, which is on
  branch docs/474-bin-check-exit-contract. The parallelize_me! shadowing was
  additionally demonstrated by executing a self-contained `ruby -e` snippet
  against the installed minitest 6.0.6 — no repo files read or written by it.

Verdict: NEEDS-SPEC.

Headline: the rewrite's corrected WebSearchTest diagnosis is itself wrong. The half that says "queue SIZE cannot move the count, queue COUNT can" is provably right — I re-derived the exact 102 round trips and confirmed nothing else on the counting thread can add one. The half that says the extra queues come from concurrent sibling methods under parallelize_me! is contradicted three ways, including by a comment in the repo that states it in plain prose:

• /home/ivann/ws/developerz.ai/Projects/wurk/test/test_helper.rb:199-201 — Wurk::Test::UnitCase overrides def self.parallelize_me! with an empty body
• minitest-parallel_fork re-extends any genuinely parallel suite with Minitest::Unparallelize anyway
• /home/ivann/ws/developerz.ai/Projects/wurk/test/integration/swarm_boot_test.rb:92-97 says both, verbatim

The downstream consequence is the more serious finding: AC1 SADDs its sibling queues before installing the counter, so it models a static population — and the CI failure is by definition a concurrent one. A Queue.all.size snapshot passes AC1 and still flakes. The draft's only red-today WebSearch criterion cannot catch the bug that filed the issue.

Separately, LimiterStressTest is still unspecified in substance: AC3 is satisfied literally by wait_timeout: 60, and the test/** diff-scope criterion does not reach it because that constant lives in the test file.

I did not write a root cause into the verdict — the writer that adds the extra queues is not establishable read-only, and asserting one would be the same defect one level up.

run: aee933da433642082
provider: anthropic
model: claude-opus-5