---
title: "What nudge_top1_count Tells You That a Status Field Can't"
canonical: https://dxdev.com/blog/blocked-request-surface-every-session/
datePublished: 2026-08-08
---
On August 8th we ran a RICE pass over 310 Highest and High priority tickets, looking for lane heads to promote into the Working queue we actually work from. Six went in, and the queue went from 4 items to 10. Three more looked ready and got left out after a second check. One had an audit that had already come back clean. One was gated on a release that hadn't shipped yet (3.362, due 8/11).

That was normal triage. The mechanic underneath it is what stuck with us: the Working queue filter excludes anything with Dev-Spec `Waiting` or `Parked`. Promoting a ticket in that state doesn't land it. It sits there, invisible, until a human stumbles on it again.

"Blocked on someone else" and "forgotten" render identically. The filter itself is correct, because a queue full of things nobody can act on is useless. But a ticket waiting on a partner to flip a DNS record looks exactly like a ticket nobody has touched in six weeks. Both are absent from the list.

## The first fix, and what it cost

Our first pass was the obvious one. We dropped the `Waiting`/`Parked` exclusion from the Working queue query and let blocked tickets sit in the list with a status badge. We shipped it and ran it against the live board. The queue jumped past 40 items.

The 10 we could pick up right now were buried under two dozen tickets we had no ability to move. It took a full session to notice the queue was useless again, this time for a different reason. Then we reverted the query and pulled apart the two concerns we had conflated. Blocked-but-owned-by-someone-else is not the same list as ready-to-work, and putting them in one feed moved the noise from "invisible" to "unfilterable."

## What shipped instead

The fix that stuck leaves the Working queue alone. It's a separate surface, a blocked-ask detector. It scans session manifests and ticket state for anything parked on an external actor. Then it stamps what it finds into the dev board at every session start, not only the sessions where someone happens to reopen the ticket.

Each session's frontmatter now carries `nudge_top1_id` and `nudge_top1_count`. They hold the highest-priority blocked candidate and how many sessions in a row it has been surfaced without resolving. A ticket no longer gets rediscovered as new on session five. It shows up with count: 5. That number is the part a plain status field can't give you.

The detector caught a real case the same day. We had traced an unknown Google Cloud project owner to a partner's side while ruling out a sign-in gate. Instead of fixing only that one project, we pushed updated accounts-of-record to the partner's agents with the specific ask attached. We also adopted a standing rule, dual-admin on every service, so neither of us can get locked out again. The rule only stuck because the ask stayed visible past the session that raised it.

The domain migration follows the same pattern. Its ticket shows 65 of 253 client-managed domains still resolving through the old server address, down from 96 the week before and 79 before that. The fix is spec'd and ready to build, but it's parked behind a personalized final-notice email round that only we can send. Without the detector, that ticket reads as someone else's problem. A new session finds it fresh every time, does the same investigation, reaches the same conclusion and parks it again.

With the detector, the session manifest's `pulse` field says `blocked-ask detector shipped; verifier running; my partner has the ask`. That line tells the next session not to redo the diagnosis.

The `close` skill got the other half of this. If a session's `tasks` list is empty but `nudge_top1_id` is set, that's a candidate bind that never landed. Closing without surfacing it first is exactly the silent-loss failure the detector exists to catch.

## Keep two lists

Keep the list of work you can act on separate from the list of work waiting on someone else. Give the second list a count of how many sessions in a row each item has resurfaced. Then check whether any tracker you rely on can tell "blocked on someone else" from "forgotten." If it can't, the same diagnosis gets repeated every time a parked item turns up again.