leviath_tools/platform.rs
1//! Platform capabilities and process-group management.
2
3use super::*;
4
5/// Put `cmd` in its own process group, so the whole command tree can be
6/// signalled as one. `leviath_sys::configure_detached` does this for a
7/// `std::process::Command`; the tool lane uses tokio's, which has its own
8/// (Unix-only) setter. A no-op where the platform has no process groups -
9/// there, killing the direct child is all that exists.
10pub fn own_process_group(cmd: &mut Command) {
11 #[cfg(unix)]
12 cmd.process_group(0);
13 #[cfg(not(unix))]
14 let _ = cmd;
15}
16
17/// SIGKILLs a shell's whole process group when dropped.
18///
19/// `kill_on_drop` reaps the shell itself; this reaps what the shell started.
20/// Held for the duration of one shell tool call, so it fires on every exit path -
21/// normal completion (where the group is already gone and the signal is a
22/// harmless no-op), timeout, and the future being dropped because the agent was
23/// cancelled.
24pub struct ProcessGroupReaper(pub u32);
25
26impl Drop for ProcessGroupReaper {
27 fn drop(&mut self) {
28 // The group is usually already gone; failing to signal it is expected.
29 let _ = leviath_sys::kill_process_group(self.0);
30 }
31}
32
33/// A platform feature a built-in tool depends on.
34///
35/// Each built-in declares the capabilities it requires (see
36/// [`tool_required_capabilities`]); the current platform declares what it
37/// provides (see [`PlatformCapabilities`]). A tool whose requirements aren't
38/// met by the platform simply doesn't register - it's dropped from
39/// advertisement, name-recognition, and dispatch. This lets platform-specific
40/// tools (like `shell`, which spawns OS processes) coexist without per-tool
41/// `#[cfg]` gates or one-off boolean flags.
42#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
43pub enum ToolCapability {
44 /// Can launch child processes (e.g. the `shell` tool, stdio MCP servers).
45 ProcessSpawn,
46 /// Can read and write files.
47 FileSystem,
48 /// Can make outbound network/HTTP requests.
49 Network,
50}
51
52/// The set of [`ToolCapability`]s the current platform provides.
53///
54/// Detection is compile-time: [`current`](Self::current) resolves to the
55/// capability set for the build target. Desktop targets provide everything; a
56/// future mobile or wasm host would provide a reduced set (no
57/// [`ProcessSpawn`](ToolCapability::ProcessSpawn)). This mirrors the
58/// `leviath-sys` crate's approach of centralizing platform `#[cfg]` branching
59/// in one place rather than scattering it across call sites.
60#[derive(Debug, Clone, PartialEq, Eq)]
61pub struct PlatformCapabilities {
62 capabilities: HashSet<ToolCapability>,
63}
64
65impl PlatformCapabilities {
66 /// Capabilities for a desktop host: process spawning, filesystem, network.
67 pub fn desktop() -> Self {
68 Self {
69 capabilities: HashSet::from([
70 ToolCapability::ProcessSpawn,
71 ToolCapability::FileSystem,
72 ToolCapability::Network,
73 ]),
74 }
75 }
76
77 /// Capabilities for a mobile host: filesystem and network, but no process
78 /// spawning (so the `shell` tool doesn't register).
79 pub fn mobile() -> Self {
80 Self {
81 capabilities: HashSet::from([ToolCapability::FileSystem, ToolCapability::Network]),
82 }
83 }
84
85 /// The capability set for the platform this binary was built for.
86 ///
87 /// Only desktop targets are built today, so this resolves to
88 /// [`desktop`](Self::desktop). A future mobile/wasm target adds a `cfg` arm
89 /// here returning [`mobile`](Self::mobile) - every built-in then auto-filters
90 /// against it with no other change.
91 pub fn current() -> Self {
92 Self::desktop()
93 }
94
95 /// Build a capability set from an explicit collection (tests, future hosts).
96 pub fn from_capabilities(caps: impl IntoIterator<Item = ToolCapability>) -> Self {
97 Self {
98 capabilities: caps.into_iter().collect(),
99 }
100 }
101
102 /// Whether the platform provides `cap`.
103 pub fn supports(&self, cap: ToolCapability) -> bool {
104 self.capabilities.contains(&cap)
105 }
106
107 /// Whether the platform provides *every* capability in `required`. An empty
108 /// requirement slice is always satisfied.
109 pub fn satisfies(&self, required: &[ToolCapability]) -> bool {
110 required.iter().all(|c| self.supports(*c))
111 }
112}
113
114impl Default for PlatformCapabilities {
115 fn default() -> Self {
116 Self::current()
117 }
118}
119
120/// The capabilities a built-in tool requires to function.
121///
122/// Keyed by *canonical* tool name (resolve aliases via [`canonical_tool_name`]
123/// first). An empty slice means the tool is platform-agnostic and always
124/// available - this covers the runtime-handled tools (`present_for_review`,
125/// `ask_user_*`, `edit_document`, `context_*`) which touch neither the OS
126/// process table nor the filesystem directly.
127pub fn tool_required_capabilities(canonical_name: &str) -> &'static [ToolCapability] {
128 match canonical_name {
129 "shell" => &[ToolCapability::ProcessSpawn],
130 "read_file" | "read_files" | "write_file" | "edit_file" | "list_dir" => {
131 &[ToolCapability::FileSystem]
132 }
133 _ => &[],
134 }
135}