---
title: "Stop Rediscovering the Same Blocked Work: A Detector That Surfaces Every Session"
canonical: https://dxdev.com/blog/2026-09-07_blocked-request-surface-every-session/
datePublished: 2026-08-08
---
The queue said ten items. Four of them were real.

On August 8th I ran a RICE pass over 310 Highest and High priority tickets, looking for lane heads to promote into the Working queue I actually work from. Six went in, taking the queue 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). Fine, normal triage. The part that stuck with me was the mechanic underneath it: the Working queue filter excludes anything with Dev-Spec `Waiting` or `Parked`. Promoting a ticket in that state doesn't land it. It just sits there, invisible, waiting for a human to stumble on it again.

That's the actual bug. Not the filter itself, the filter is correct, you don't want a founder's queue full of things nobody can act on. The bug is that "blocked on someone else" and "forgotten" render identically. A ticket waiting on my partner to flip a DNS record looks exactly like a ticket nobody has touched in six weeks, because both are just absent from the list.

## The fix I tried first, and why it was wrong

My first pass was the obvious one: drop the `Waiting`/`Parked` exclusion from the Working queue query and let blocked tickets sit in the list with a status badge. I shipped it, ran it against the live board, and watched the queue jump past 40 items. My actual actionable set, the 10 I could pick up right now, was buried under two dozen tickets I had zero ability to move. Wrong turn, real cost: it took a full session to notice the queue was useless again for a different reason, then revert the query and separate the two concerns that I'd conflated. Blocked-but-owned-by-someone-else is not the same list as ready-to-work, and putting them in one feed just moves the noise from "invisible" to "unfilterable."

## What actually shipped

The fix that stuck doesn't touch the Working queue at all. It's a separate surface: a blocked-ask detector that scans session manifests and ticket state for anything parked on an external actor, and stamps it into the vault dev board every session start, not just the ones where someone happens to reopen the ticket. Each session's frontmatter now carries `nudge_top1_id` and `nudge_top1_count`, the highest-priority blocked candidate and how many sessions in a row it's been surfaced without resolving. A ticket doesn't get "rediscovered" as new on session five. It shows up with count: 5, and that number is the whole point, it's the thing a plain status field can't tell you.

Real example it caught the same day: we'd traced an unknown Google Cloud project owner to my partner's side while ruling out a sign-in gate. Instead of just fixing that one project, I pushed updated accounts-of-record to his agents with the specific ask attached, and we adopted a standing rule, dual-admin on every service, so neither of us can get locked out again. That rule only stuck because the ask stayed visible past the session that raised it.

Same pattern on the domain migration. The ticket that tracks it 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 I can send. Without the detector, that ticket reads as "someone else's problem, ignore," and a new session finds it fresh every time, does the same investigation, reaches the same conclusion, and parks it again. With it, the session manifest's `pulse` field just says `blocked-ask detector shipped; verifier running; my partner has the ask`, and that line alone 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, and closing without surfacing it first is exactly the silent-loss failure mode the detector exists to kill.