rpi_tools/tools/
tool_context.rs

1//! Mirrors `packages/agent/src/harness/tools/tool-context.ts` — the context the
2//! built-in tools execute against.
3//!
4//! TS: `interface ExecutionToolContext { env: ExecutionEnv }`. The Rust port
5//! keeps the same single-field shape but splits `env` into the read-only
6//! `ExecutionEnv` view and (for the write/edit tools) the `MutatingEnv` view
7//! that carries the file-mutation-queue registry.
8
9use std::sync::Arc;
10
11use crate::env::ExecutionEnv;
12use crate::file_mutation_queue::MutatingEnv;
13
14/// The context handed to a built-in tool's `execute`. Mirrors TS
15/// `ExecutionToolContext`.
16///
17/// `env` is the read-only view for read/bash; `mutating_env` is `Some` when the
18/// context was built with a mutation-capable env (write/edit use it to reach
19/// the per-canonical-path queue). Callers conventionally wrap an
20/// `OsExecutionEnv` or `InMemoryExecutionEnv` (which implement both traits)
21/// via [`ExecutionToolContext::new`].
22pub struct ExecutionToolContext {
23    env: Arc<dyn ExecutionEnv>,
24    mutating_env: Option<Arc<dyn MutatingEnv>>,
25}
26
27impl ExecutionToolContext {
28    /// Build a context from a mutation-capable env. The env is stored both as
29    /// `Arc<dyn ExecutionEnv>` (for read/bash) and `Arc<dyn MutatingEnv>` (for
30    /// write/edit). The two arcs point at the same allocation when the caller
31    /// passes a single concrete env.
32    pub fn new(env: Arc<dyn ExecutionEnv>, mutating_env: Option<Arc<dyn MutatingEnv>>) -> Self {
33        Self { env, mutating_env }
34    }
35
36    pub fn env(&self) -> &Arc<dyn ExecutionEnv> {
37        &self.env
38    }
39
40    pub fn mutating_env(&self) -> Option<&Arc<dyn MutatingEnv>> {
41        self.mutating_env.as_ref()
42    }
43}
rpi_tools/tools/tool_context.rs

rpi_tools/tools/
tool_context.rs
