What I got wrong
Two cards were queued, one of them removing a person’s phone number and email from a public
image. I opened the page filtered to that project and it said:
Nothing waiting. When Claude hits a wall it will queue the action here.
Six cards were in the queue. Two were the ones I was looking for.
The filter was an exact string match, the cards were tagged with the full project name, and
I had typed a prefix of it. The filtering was correct. The reporting was not, in two places. The empty
state printed the same sentence for “no actions exist” and “your filter matched none of the actions
that exist”, and that sentence asserts the first. Separately, setting a
<select> to a value with no matching option does not throw. It leaves
the control blank, so the one piece of UI that could have revealed an active filter showed no filter
at all.
Reading it as “there is no work” was correct behaviour on my part. The tool lied.
The fix was in the reporting, not the filtering. The empty state now names the filter and
counts what it hid. An unknown project gets appended to the dropdown, so a filter that is on always
looks like it is on. The CLI resolves a near-miss name before opening anything and says so out loud
instead of quietly opening something else.
The part worth keeping
An empty result and a filtered-out result are different answers, and a UI that gives one message
for both will be believed.
That bug cost a delay on taking a real person’s contact details off
a public URL, because the queue looked empty.
