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
//! Transport-agnostic analyzer interface.
//!
//! `Analyzer` is the seam between [`crate::deep::run`] and the concrete
//! transports — HTTP today, subprocess (PR 3) tomorrow. Adding a new
//! transport means writing one `impl Analyzer` and dispatching on
//! [`crate::deep::config::DeepMode`]; the orchestrator, candidate
//! selection, prompt rendering, schema, merge, and cost tracker all stay
//! unchanged.
//!
//! The shared types ([`AnalyzeResponse`], [`TokenUsage`]) live here so
//! transports can depend on the trait module without taking a transitive
//! dep on each other (the HTTP client must not know the subprocess
//! client exists, and vice versa).
use crateDeepError;
use crateSemanticFinding;
use crateRenderedPrompt;
/// One round-trip's worth of model output: the parsed semantic findings
/// plus token-usage stats for cost tracking.
///
/// Transports that don't have a notion of token usage (subprocess hooks
/// shelling out to opaque CLIs) populate [`TokenUsage::default`], which
/// the cost tracker treats as a no-op.
/// Token counts reported by the upstream model. `0` for both fields means
/// "no usage reported" — the cost tracker short-circuits to a no-op when
/// either rate is zero, so an empty `TokenUsage` from a transport that
/// can't measure tokens (e.g. subprocess) costs nothing.
/// Send one prompt to a transport and parse the response.
///
/// Implementations are expected to be cheap to construct (one per
/// `deep::run`) and safe to call serially from the orchestrator. The
/// orchestrator currently dispatches sequentially; a future fan-out
/// would require `Sync`, which we'll add when (if) we wire that up.