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
//! The interactive approval seam at the engine's dispatch step (ADR-0017).
//!
//! The engine consults an injected [`Approver`] before every tool call, at the
//! gate **in front of** the one dispatch door — the tools crate stays
//! interaction-free (`Registry` is a first-class library surface whose
//! consumers must not inherit an approval dependency). The core stays headless
//! (ADR-0001): nothing here renders or waits on a terminal — the engine awaits
//! a trait method that headless callers resolve instantly ([`AllowAll`]).
//!
//! An interactive frontend implements [`Approver`] with a oneshot + FIFO queue
//! (the pattern all four studied harnesses share); prompt queueing and
//! stickiness ("always allow") are the approver implementation's job,
//! client-side — not core vocabulary.
use async_trait;
use ToolKind;
use Value;
/// Decides whether one tool call may run. Consulted by the engine per call,
/// serially, before dispatch; the await suspends **only this call**.
/// The pre-dispatch view of one tool call — what the studied UIs render their
/// permission prompts from (request args, not host-resolved detail).
///
/// `#[non_exhaustive]` so richer context can be added without breaking
/// downstream constructors — only the engine builds one.
/// The approval vocabulary — deliberately minimal (ADR-0017 Option V1):
/// stickiness and richer choices live in approver implementations.
///
/// `#[non_exhaustive]` so variants (e.g. `AllowModified`) are additive.
/// The default approver: allows everything, instantly — headless consumers
/// (`locode-exec`, evals) are byte-for-byte unchanged in behavior.
;