supercode-harness 0.4.8

The optional native Supercode agent and tool harness
Documentation
//! 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 crate::mcp::ElicitationResponse;
use crate::permissions::ApprovalOutcome;

/// 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).
#[derive(Debug)]
pub struct PendingApprovalRequest {
    /// The tool being called (`"bash"`, `"write_file"`, …).
    pub tool: String,
    /// The canonicalized command/path subject, if any.
    pub subject: Option<String>,
    /// The raw, model-supplied arguments.
    pub raw_args: serde_json::Value,
    /// Where to send the user's decision.
    pub reply_tx: std::sync::mpsc::Sender<ApprovalOutcome>,
}

/// 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.
#[derive(Debug)]
pub struct PendingChildApproval {
    /// Which child raised this request.
    pub child_agent_id: String,
    /// The tool it tried to call.
    pub tool: String,
    /// The canonicalized command/path subject, if any.
    pub subject: Option<String>,
    /// The raw, model-supplied arguments.
    pub raw_args: serde_json::Value,
    /// Where to send the parent's decision.
    pub reply_tx: std::sync::mpsc::Sender<ApprovalOutcome>,
}

/// 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.
#[derive(Debug)]
pub struct PendingElicitation {
    /// The server's human-readable prompt.
    pub message: String,
    /// JSON Schema for the requested input shape.
    pub requested_schema: serde_json::Value,
    /// Where to send the user's answer.
    pub reply_tx: tokio::sync::oneshot::Sender<ElicitationResponse>,
}

/// 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.
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct PendingOAuthDisplay {
    /// The server name this login is for (so a multi-server login session
    /// is unambiguous in the modal).
    pub server_name: String,
    /// Short code the user enters at `verification_uri`.
    pub user_code: String,
    /// The URL the user visits.
    pub verification_uri: String,
    /// A URL that already embeds `user_code`, if the server provided one.
    pub verification_uri_complete: Option<String>,
    /// How long (seconds) the code remains valid.
    pub expires_in_secs: u64,
}