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
//! Addon ecosystem: community extensions for lean-ctx (#858).
//!
//! An **addon** packages an external MCP server (+ metadata) behind a small
//! [`lean-ctx-addon.toml`](manifest) manifest, so a third-party tool plugs into
//! lean-ctx's MCP gateway with a single `lean-ctx addon add` — no fork, no
//! recompile. Addons are user-global and reuse the gateway trust model
//! (`[gateway]` is global-only and opt-in; see [`crate::core::gateway`]).
//!
//! Layers:
//! - [`manifest`] — the `lean-ctx-addon.toml` contract (also the registry entry shape).
//! - [`registry`] — the curated catalog (bundled, with optional user override).
//! - [`store`] — what is installed locally (`<data_dir>/addons/installed.json`).
//! - [`install`] — wires an addon into the gateway and records it in the store.
//! - [`bootstrap`] — `[install]` block executor: provisions an addon's upstream
//! package via a pinned package manager (uv/pip/cargo/npm/brew/dotnet) on `add`,
//! uninstalls it on `remove` (#1105, Phase 2). Never goes through a shell.
//! - [`scaffold`] — `addon init` starter manifest generator (DX, P4).
//!
//! Security (#863, P1):
//! - [`capabilities`] — the declared `[capabilities]` permission model that
//! drives the per-addon sandbox + env allowlist + install consent.
//! - [`trust`] — trust tier (`verified`) + static risk assessment of the wiring.
//! - [`audit`] — capability-coherence + malware heuristics + the verified/paid
//! gate (#403): does the declared `[capabilities]` match the wiring, and is the
//! wiring free of malicious patterns?
//! - [`commerce`] — sellable-addon model (`[pricing]`) + the mandatory paid
//! listing gate (Track B): no addon is sold without clearing the audit.
//! - [`binhash`] — SHA-256 binary pinning for stdio addons (refuse a swapped
//! executable at spawn).
//! - [`policy`] — the global-only `[addons]` install policy floor + the gate.
//! - [`signing`] — Ed25519 signing for the user-override registry.
//! - [`revocation`] — central kill-switch that blocks a revoked addon from
//! running (install, catalog build, every proxy call).
//! - [`integrity`] — install-time wiring hash + local re-verify (the lockfile).
//! - [`meter`] — per-addon / per-tool usage metering (analytics + billing base, P5).
//! - [`sandbox`] — per-addon OS sandbox for spawned stdio servers.
//! - [`runtime`] — redaction + audit of untrusted addon tool output.
//!
//! Grammar addons (#690) are a separate, smaller concept living alongside
//! this module rather than inside it — a long-tail tree-sitter grammar is a
//! `cdylib` `dlopen`'d directly into lean-ctx's own process, not an MCP
//! server, so none of the subprocess/gateway-shaped layers above apply:
//! - [`grammar_manifest`] — the grammar-addon manifest (language, extensions,
//! per-platform dylib + mandatory SHA-256 pin, tree-sitter ABI version).
//! - [`grammar_registry`] — its bundled/local-override catalog, reusing only
//! [`signing`] and [`binhash`] from the MCP addon machinery.
//! - `grammar_install` (internal) — zero-config fetch (#690, Phase 1d): downloads a
//! missing pinned dylib on first use, silent on any failure (offline,
//! network error, hash mismatch) so it degrades to the regex-signature
//! fallback exactly like "not installed" — no `addon add` consent step,
//! since a grammar addon is a parsing fallback, not a spawned process.
// Grammar addons only matter to a build that can dlopen a Language into a
// tree-sitter parser at all — dead weight in the no-tree-sitter slim build
// (#663), so gated the same way `core::signatures_ts` is.
pub
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ProbeReport;
pub use ;
pub use ;
pub use SandboxMode;
pub use ;
pub use ;