trusty-memory 0.15.1

MCP server (stdio + HTTP/SSE) for trusty-memory
Documentation 
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

//! Per-subcommand handlers for the `trusty-memory` binary.
//!
//! Why: Keep CLI handlers out of `lib.rs` so the library surface stays focused
//! on MCP server code while the binary stays a thin clap-to-handler shim.
//! What: One submodule per subcommand. `serve --stdio` is handled by
//! `serve_stdio` (direct MCP, PR1 #919 of the #914 cutover epic); `serve`
//! (HTTP) is wired to `crate::run_http` / `crate::run_http_dynamic` in
//! `main.rs`; `migrate` rewrites Claude settings to point at trusty-memory;
//! `service` manages the macOS launchd LaunchAgent; `setup` orchestrates
//! first-time install (data dir + launchd + Claude settings patch). The
//! former `trusty-memory-mcp-bridge` binary and UDS transport were removed
//! in PR3 of the #914 epic.
//! Test: Each submodule carries its own unit tests.

pub mod daemon_guard;
pub mod daemon_lock;
pub mod doctor;
pub mod inbox_check;
pub mod kg_rebuild;
pub mod kuzu_migrate;
pub mod link;
pub mod migrate;
pub mod migrations;
pub mod monitor;
pub mod note;
pub mod port;
pub mod prompt_context;
pub mod send_message;
pub mod serve_stdio;
pub mod service;
pub mod setup;
pub mod single_instance;
pub mod start;
pub mod stop;
pub mod upgrade;

/// Process-wide lock for tests that mutate `TRUSTY_DATA_DIR_OVERRIDE` and
/// related env vars.
///
/// Why: Rust's default test runner executes tests in the same process with
/// thread parallelism, but `std::env::set_var` / `remove_var` mutate
/// process-wide state. Tests that pin the data dir override to a tempdir
/// can otherwise observe each other's writes mid-run, with the symptom that
/// the handler resolves the *real* user data dir and the test asserts the
/// wrong directory. Acquiring this lock at the top of each env-touching
/// test forces them to run one-at-a-time without pulling in `serial_test`.
/// What: a `tokio::sync::Mutex<()>` (chosen over `std::sync::Mutex` so the
/// guard can be held across `.await` points without tripping clippy's
/// `await_holding_lock` lint). Tests hold the guard for the duration of
/// the env-sensitive section.
/// Test: indirectly via the integration tests in `prompt_context` and
/// `inbox_check`.
#[cfg(test)]
pub(crate) fn env_test_lock() -> &'static tokio::sync::Mutex<()> {
    use std::sync::OnceLock;
    static LOCK: OnceLock<tokio::sync::Mutex<()>> = OnceLock::new();
    LOCK.get_or_init(|| tokio::sync::Mutex::new(()))
}