jb/pi-ask
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: support ask flow in RPC clients
CI / validate (push) Failing after 13s
Details

Browse Source
This commit is contained in:
jb
2026-08-22 21:55:08 -04:00
parent 49482b7e5d
commit 80da307828
5 changed files with 346 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/contract.md
+4 -2
View File
@@ -268,7 +268,9 @@ Dirty dismiss:
## Non-TUI and non-interactive modes
The rich ask flow uses `ctx.ui.custom()` and opens only in TUI mode. In print, JSON, RPC, or any other non-TUI mode, the tool returns a `Needs user input: ask_user requires interactive TUI mode.` message in `content` and a cancelled result in `details` instead of opening custom UI.
The rich ask flow uses `ctx.ui.custom()` and opens only in TUI mode. RPC mode falls back to Pi's standard `select` and `input` dialogs so RPC clients can bridge questions into their own interface. Questions are presented sequentially; multi-select questions use repeated toggle dialogs followed by `Done`. The RPC fallback collects option selections and custom text, but does not expose preview panes, notes, or elaboration actions.
Print, JSON, and other non-interactive modes return a `Needs user input: ask_user requires interactive TUI mode.` message in `content` and a cancelled result in `details` instead of opening UI.
The public tool schema requires question `id` and `prompt` plus option `value` and `label`, and it restricts question `type` to `single`, `multi`, or `preview`, so malformed structural fields fail before execution. The tool still validates trimmed text, uniqueness, option counts, and preview requirements during execution and returns structured issues for those failures. Result rendering falls back to Pi's raw tool-error text when schema validation prevents execution.
@@ -280,7 +282,7 @@ When enabled, pi-ask emits one best-effort external notification per ask session
## Remote inter-extension events
pi-ask exposes a local `pi.events` contract for trusted Pi extensions. It does not expose a network API and does not automate terminal keystrokes. RPC or headless integrations should use a trusted in-process bridge extension that consumes these events rather than expecting the TUI-only custom surface to open.
pi-ask exposes a local `pi.events` contract for trusted Pi extensions. It does not expose a network API and does not automate terminal keystrokes. Integrations that need the complete rich-flow semantics should use a trusted in-process bridge extension that consumes these events; the built-in RPC fallback intentionally exposes only standard dialog semantics.
Channels: