asepharyana
be0a9582bb
Transform the single binary crate into a 9-crate workspace monorepo: - Root Cargo.toml as [workspace] manager with resolver = "2" - zesdex-entities: Domain entity types (session, settings, store, message, etc.) - zesdex-utils: Pure utility functions (error, logger, pagination, slug, clipboard) - zesdex-dto: Data Transfer Objects for LLM provider API communication - zesdex-ipc: Unix-socket IPC layer (client/server/framing/protocol) - zesdex-iam: Identity & Access Management (Clean Architecture: domain/application/infrastructure) - zesdex-cms: Content Management (Clean Architecture: domain/application/infrastructure) - zesdex-middleware: HTTP middleware (Auth, CORS, Rate Limiting) - zesdex-libs: Composition root (AppContext, DB init, JWT, Argon2) - zesdex-backend: Main binary entry point + seed/migrate binaries - DevOps: Dockerfile, docker-compose, Nix (flake/shell/default), CI/CD updates - Remove dead root src/ and src-misc/ directories All crate re-exports maintain backward compatibility with original crate::model::*, crate::dto::*, crate::ipc::* module paths. Feature crates enforce strict layer separation: domain -> application -> infrastructure with generic trait-based dependency injection.
41 lines
1.3 KiB
Rust
41 lines
1.3 KiB
Rust
//! Event variants that a running subagent can emit to its parent via the
|
|
//! shared mpsc channel.
|
|
use serde_json::Value;
|
|
|
|
/// Progress and outcome events emitted by `run_subagent` as it processes
|
|
/// LLM responses and tool calls.
|
|
#[derive(Debug, Clone)]
|
|
pub enum SubagentEvent {
|
|
StepCompleted {
|
|
output: String,
|
|
},
|
|
StepFailed {
|
|
step: usize,
|
|
error: String,
|
|
},
|
|
Completed,
|
|
ToolCall {
|
|
tool: String,
|
|
args: Value,
|
|
},
|
|
ToolResult {
|
|
tool: String,
|
|
args: Value,
|
|
},
|
|
Progress(String),
|
|
/// Token usage reported by the LLM after one streaming call inside the
|
|
/// subagent. The drain thread accumulates these across all steps and
|
|
/// forwards the total to the parent's `TurnEvent::ReviewUsage` handler
|
|
/// so the Usage panel can split "main" tokens from "self-learning"
|
|
/// tokens (review, test-gen, arch-review, security-review, etc.).
|
|
///
|
|
/// Why a separate variant instead of folding into `Completed`: usage
|
|
/// is reported per-step, so the parent can update the running total
|
|
/// incrementally rather than waiting for the whole subagent run to
|
|
/// finish. The drain thread still aggregates before forwarding.
|
|
Usage {
|
|
tokens_in: u64,
|
|
tokens_out: u64,
|
|
},
|
|
}
|