[idea] Detect Pi's ask_user / approval dialogs as "blocked" (instead "working")

[davidvv]

idea / problem

When a Pi agent blocks on user input via ctx.ui.select (the ask_user tool, or the
security-gate approval prompt) or ctx.ui.input (the ask_user "Other…" box), Herdr
shows the pane as working the whole time, even though the agent is genuinely blocked
waiting for an answer.

Pi still renders "Working..." beside the dialog, and the pi detection manifest only
has a working_literal rule — there's no blocked rule like Claude's live_blocked_form
/ *_permission_prompt. So the "blocked" state the phone bridge (pi-webui) already
reports never shows up in Herdr's pane status.

Expected: the pane shows blocked while one of these dialogs is open, like Claude does.

The dialogs render a distinctive hint line ("↑↓ navigate enter select escape/ctrl+c
cancel" for ctx.ui.select; "enter submit escape/ctrl+c cancel" for ctx.ui.input), so a
blocked rule in the pi manifest could match it. I'm running a local override
(~/.config/herdr/agent-detection/pi.toml) that does this — herdr agent explain reports
blocked while ask_user is open, working when only the spinner shows. Happy to share it
or open a PR if there's interest.

One limitation: phone-side approvals (where the prompt goes to the iOS app and the
desktop only shows the spinner) have no on-screen selector to scrape — only the
on-device dialogs are detectable this way.

requested change

The change: add blocked rules to the pi agent-detection manifest (mirroring Claude's
live_blocked_form / *_permission_prompt) so that when a Pi agent is blocked on a
ctx.ui.select or ctx.ui.input dialog — the ask_user tool, the security-gate approval
prompt, or the ask_user "Other…" text box — Herdr shows the pane as blocked instead of
working.

why you want this

I run Pi with Herdr plus an iOS remote app, and I'm often away from
the desk. When the agent is waiting on me to answer a question, the pane still shows
working the entire time (Pi renders "Working..." beside the dialog and the pi manifest
only has a working_literal rule), so I can't tell from Herdr which pane actually needs
my attention. Claude already behaves correctly here; Pi doesn't.

[demetere]

Question about where this should live rather than a concrete feature request.

RPIV @juicesharp/rpiv-ask-user-question@2.1.0 now emits a stable package-owned event while it is waiting for user input:

rpiv:ask-user:blocked

Herdr's Pi integration currently listens for herdr:blocked and maps that into Herdr's semantic blocked state. That makes sense as an integration-owned convention, but it leaves a question for extension-specific blocker events like this one.

Would Herdr want to support a configurable allow/list of Pi events that should map to semantic blocked? For example, something conceptually like:

[integrations.pi]
blocked_events = ["rpiv:ask-user:blocked"]

Or is your intended architecture that each Pi extension / extension ecosystem should provide its own tiny bridge to herdr:blocked or pane.report_agent, instead of Herdr accepting arbitrary event mappings?

I am trying to understand the right ownership boundary before asking either side to add glue. I don't think RPIV core should emit herdr:* directly, but I also don't want to assume Herdr should hardcode every third-party Pi extension event.

Related RPIV issue/release context: juicesharp/rpiv-mono#128

[zhcsyncer]

Following up with concrete validation of the integration boundary discussed above.

RPIV PR #129 shipped rpiv:ask-user:blocked in v2.1.0 for both TUI and RPC waits. Its final contract is deliberately package-owned ({ active: boolean }), with consumer-side mapping left out of scope.

For Pi panes using Herdr's official integration, a screen-manifest rule is not sufficient: once the integration reports state, Herdr treats it as full lifecycle authority and skips screen detection. I verified that behavior on current master (Pi integration v7, protocol 18).

I prototyped optional mappings in the managed Pi integration while preserving the existing public herdr:blocked event:

{
  "blockedAdapters": [
    { "kind": "event", "event": "rpiv:ask-user:blocked", "label": "question" },
    { "kind": "tool", "toolName": "submit_plan", "label": "plan review" }
  ]
}

Event adapters pair by depth; tool adapters pair by toolCallId and are documented as approximate because they cover the full tool execution interval. Real protocol-18 validation produced:

ask:  idle -> working -> blocked -> working -> idle
plan: idle -> working -> blocked -> working -> idle

The branch passes the full just check, includes integration-asset coverage for pairing, errors, settlement cleanup, invalid configuration, and v7 runtime replacement, and leaves exit ownership with the v7 process tracker. Branch: https://github.com/zhcsyncer/herdr/tree/feat/pi-blocked-adapters

Would this configurable adapter boundary fit Herdr's intended ownership model, or should each Pi extension ecosystem provide its own bridge to herdr:blocked?

[JensMoeslund]

A small alternative to per-extension adapters: Pi core exposes ui_prompt_start and ui_prompt_end around its blocking UI dialogs. We are using those events to bridge into the existing herdr:blocked convention:

export default function (pi) {
  pi.on("ui_prompt_start", (event) => {
    pi.events.emit("herdr:blocked", {
      active: true,
      label: event.title ?? "Waiting for input",
    });
  });
  pi.on("ui_prompt_end", () => {
    pi.events.emit("herdr:blocked", { active: false });
  });
}

Herdr's managed Pi integration v9 already counts active herdr:blocked events and gives blocked state priority over working. Listening to these Pi core events in the managed integration could therefore cover ordinary Pi UI questions without hardcoding each question extension's event name or adding configuration. Existing herdr:blocked producers could remain supported.

Scope: this covers dialogs that go through Pi's instrumented UI APIs. It does not establish coverage for a remote-only approval flow that never emits these events. Nested/custom dialogs can produce multiple balanced events, and untitled dialogs use the generic label above; native editor dialogs can also emit a more specific title, so preserving useful labels would deserve a check in an upstream implementation.

Would you accept a small PR to add support for these core Pi UI events to the managed integration? The useful regression cases would be prompt open/close, cancellation, nested prompts, and coexistence with existing herdr:blocked producers.