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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
//! # trusty-mpm
//!
//! Why: the original eight sub-crates (`trusty-mpm-{core,client,mcp,daemon,
//! cli,tui,telegram,gui}`) were published separately, which required a complex
//! `[patch.crates-io]` dance for cross-crate development and meant that a
//! simple `cargo install trusty-mpm` did not exist. Consolidating them into
//! one crate with feature-gated `[[bin]]` targets gives users a single install
//! target and eliminates the inter-crate publish coordination overhead.
//!
//! What: re-exports the two library surfaces — `core` (domain types + traits)
//! and `client` (daemon HTTP client + command model) — as top-level modules.
//! The heavier components (`mcp`, `daemon`, `tui`, `telegram`) are declared as
//! conditional modules gated behind their respective features; they are only
//! compiled when the feature is enabled.
//!
//! Test: `cargo test -p trusty-mpm` exercises the core serde round-trips,
//! client URL construction, MCP dispatch, and the daemon's in-process API.
//! Run `cargo test -p trusty-mpm --features daemon,mcp,tui,telegram` for the
//! full suite.
// ── Always-on library modules ────────────────────────────────────────────────
/// Service manifest schema, discovery engine, and status types for `tm services`.
///
/// Why: agents need a canonical, scriptable interface for service discovery that
/// replaces ad-hoc `lsof`/`curl`/`pgrep` patterns hardcoded in prompts. This
/// module provides the stable contract (`ServicesManifest`) and the runtime
/// probe engine (`Discoverer`).
/// What: re-exports `ServicesManifest`, `Discoverer`, `ServiceStatus`,
/// `HealthState`, and the manifest validation / tilde-expansion helpers.
/// Test: `cargo test -p trusty-mpm` exercises the manifest and discoverer unit
/// test suites; the integration smoke test requires a live trusty-search daemon.
/// Domain types, artifact model, and IPC protocol.
///
/// Why: shared types used by every trusty-mpm component. Centralizing them
/// prevents protocol drift between the daemon and its clients.
/// What: agents, skills, hooks, session state, and the IPC envelope exchanged
/// over the daemon's local socket / HTTP API.
/// Test: serde round-trips and frontmatter parser covered by `cargo test -p trusty-mpm`.
/// Shared daemon HTTP client, command model, and executor.
///
/// Why: the Telegram bot, the TUI, and the CLI all spoke to the daemon through
/// three independent HTTP layers. This module is the single shared seam.
/// What: [`client::DaemonClient`] is the one HTTP transport, [`client::TrustyCommand`]
/// the one command model, [`client::CommandExecutor`] the one dispatcher.
/// Test: URL construction and the command model are covered by the unit suite.
/// Managed session subsystem: records, persistence, lifecycle manager.
///
/// Why: the session-manager MVP tracks every agent session the daemon spawns so
/// operators can inspect, control, and recover sessions across daemon restarts.
/// What: re-exports `SessionManager`, `SessionRecord`, `ManagedSessionId`,
/// `ManagedSessionState`, and the tmux/store seams from its submodules.
/// Test: each submodule carries unit tests; `tests/session_manager_mvp.rs`
/// exercises the integration path.
/// Runtime adapters that launch an agent runtime inside a tmux session.
///
/// Why: the session manager must swap runtime backends (Claude Code CLI today,
/// trusty-code tomorrow) without changing its own code.
/// What: defines the `RuntimeAdapter` trait and the `ClaudeCodeAdapter`.
/// Test: `runtime::claude_code::tests`.
/// Activity monitoring for managed sessions (content-hash cached classification).
///
/// Why: the dashboard and circuit-breaker logic need a real-time, token-cheap
/// view of what each session is doing.
/// What: re-exports the cache and monitor types.
/// Test: `activity::*::tests`.
/// Workspace provisioner: clones a repo into an isolated session workspace.
///
/// Why: agent sessions must never collide with an operator's live checkout; each
/// session gets a clean, isolated workspace under `~/.trusty-mpm/workspaces/`.
/// What: re-exports `WorkspaceProvisioner`, `GitBackend`, `PreparedWorkspace`.
/// Test: `provisioner::workspace::tests`.
/// Agent/skill catalog synchronization from the claude-mpm repository.
///
/// Why: syncing the agent/skill catalog from the authoritative claude-mpm repo
/// keeps the local catalog current without manual re-porting.
/// What: re-exports `CatalogSync`, `CatalogError`, `CatalogSyncResult`.
/// Test: `content::catalog_sync::tests`.
/// Driver autonomy subsystem: T1–T4 tier policy + session↔artifact correlation.
///
/// Why: the calling agentic process that drives trusty-mpm must decide, for every
/// `pending_decision` a managed session surfaces, whether to auto-accept the
/// proposed default or escalate to a human. This module provides the structured,
/// non-LLM policy (T1–T4 tiers, hard guardrails) and the session↔artifact
/// correlation that defines a session's scope boundary.
/// What: re-exports `evaluate_autonomy_tier`, `AutonomyTier`, `AutonomyDecision`,
/// `GuardrailSignals`, `SessionCorrelation`, and `ScopeCheck`.
/// Test: pure unit tests in `driver::policy::tests` and `driver::correlation::tests`.
/// Unattended supervisor: 24/7 fleet observer + auto-resumer (#1206).
///
/// Why: the session manager normally needs a live calling agentic process to keep
/// a fleet moving. For overnight / unattended operation an always-on supervisor
/// auto-resumes enduring (`stopped`) sessions, observes session health without a
/// caller, surfaces `pending_decision`s for a human, and survives reboots under
/// launchd/systemd. It is a PASSIVE observer — it never makes autonomy decisions.
/// What: re-exports `Supervisor`, `SupervisorConfig`, `FleetMetrics`, and the
/// per-tick `run_tick` sweep; the `/metrics` + `/health` HTTP server is gated
/// behind the `daemon` feature (axum lives there).
/// Test: `supervisor::tests` covers config parsing, metrics derivation, the
/// N-session fleet sweep, and the HTTP handlers.
// ── Feature-gated modules ────────────────────────────────────────────────────
/// MCP server: six orchestration tools exposed to Claude Code sessions.
///
/// Why: Claude Code sessions need to list sibling sessions, request agent
/// delegations, protect their context window, and inspect circuit-breaker state.
/// MCP is the protocol Claude Code already speaks.
/// What: defines the `OrchestratorBackend` trait, the tool catalog, and
/// the `dispatch` entry point.
/// Test: mock-backend dispatch tests in `mcp` module, enabled by the `mcp` feature.
/// Daemon library: HTTP API, hook relay, session registry, watcher.
///
/// Why: the daemon's HTTP API and shared state need to be reachable from
/// integration tests (e.g. the Telegram test suite) without a live daemon
/// process.
/// What: re-exports `api::router`, `state::DaemonState`, and the `run_http` /
/// `run_mcp` entry points.
/// Test: in-process e2e suite in `tests/e2e/`; enabled by the `daemon` feature.
/// ratatui coordinator dashboard.
///
/// Why: operators need one conversational surface with visibility into every
/// active Claude Code session.
/// What: a ratatui app that polls the daemon and renders the coordinator chat
/// and health panels.
/// Test: rendering and client are unit-tested; enabled by the `tui` feature.
/// Telegram remote-management bot.
///
/// Why: remote management lets an operator drive the daemon from a phone.
/// What: teloxide adapter that wires `TelegramCommand` to `CommandExecutor`,
/// renders results via `TelegramFormatter`, and runs the push-alert loop.
/// Test: command conversion, formatting, and authorization are unit-tested;
/// enabled by the `telegram` feature.