1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
//! P5-4: the data shapes carried across the thread boundary between an
//! interactive-handler call (blocked on a background/agent thread) and the
//! render/event-loop's main thread — deliberately just data + a reply
//! channel, no trait impls, so [`crate::tui::state`] (the pure view-model)
//! and [`crate::tui::handlers`] (the actual `PermissionsApprovalHandler`/
//! `McpElicitationHandler` implementations) can both depend on this module
//! without a circular dependency between them.
use crateElicitationResponse;
use crateApprovalOutcome;
/// One `Ask`-tier request from the TOP-LEVEL agent's own permissions gate
/// (P5-1's [`crate::permissions::PermissionsApprovalHandler::ask`]),
/// waiting on [`Self::reply_tx`] for the TUI's decision. `ask` blocks the
/// calling thread on the paired `Receiver` until a reply arrives (or the
/// sending end is dropped — see [`crate::tui::handlers::TuiApprovalHandler`]'s
/// doc comment for why that's still fail-closed).
/// The child-spawn analog of [`PendingApprovalRequest`] (P5-3 §2.2 C6,
/// closed by [`crate::tui::handlers::TuiChildApprovalHandler`]): additionally
/// carries which BACKGROUND CHILD raised the request, since a parent may
/// have several background children in flight at once.
/// One server→client `elicitation/create` request
/// ([`crate::mcp::ElicitationRequest`]), waiting on [`Self::reply_tx`] for
/// the user's answer. Uses a `tokio::sync::oneshot` (not `std::sync::mpsc`
/// like the two structs above) because
/// [`crate::mcp::McpElicitationHandler::handle`] is an ASYNC trait method —
/// it `.await`s the reply rather than blocking a thread.
/// The OAuth device-code flow's ONE-TIME display push (P5-2's
/// `run_device_flow`'s `on_prompt` callback) — informational only, no
/// reply: the device flow polls the token endpoint regardless of whether
/// the user has acknowledged seeing this, so there is nothing to block on.