RIPDPI: Skill for Claude Code

Diagnostics System

1. Overview

The diagnostics system is a two-tier pipeline:

• Rust engine (native/rust/crates/ripdpi-monitor-engine/ plus the ripdpi-diagnostics-* crates) -- executes network probes in a background thread, producing a ScanReport with structured ProbeResult and ProbeObservation values.
• Kotlin orchestration (core/diagnostics/) -- manages lifecycle, catalog loading, JNI bridge, report enrichment, persistence, and policy application.

The Rust engine is stateless per scan; the Kotlin layer owns state, scheduling, and cross-scan coordination (remembered network policies, resolver overrides).

Telemetry primitives live in native/rust/crates/ripdpi-telemetry/ and provide LatencyHistogram and LatencyDistributions for in-process latency recording.

2. Scan Types

Two ScanKind variants exist:

Kind	Purpose	Typical profile
Connectivity	Tests reachability of domains, DNS, TCP, QUIC, services, circumvention tools, Telegram, and throughput targets. Results are bucketed into healthy/attention/failed/inconclusive.	default, dpi-detector-full, ru-* profiles
StrategyProbe	Evaluates path optimization strategy candidates (TCP and QUIC) against a target set, then recommends the best configuration. Requires RAW_PATH mode (outside the VPN tunnel).	automatic-probing (quick_v1), automatic-audit (full_matrix_v1)

Connectivity scans are general-purpose. Strategy probe scans are the automatic calibration mechanism -- they test multiple bypass configurations and select the most effective one for the current network.

3. Rust Engine Pipeline

Entry point

MonitorSession::start_scan() in lib.rs validates the wire request, spawns a worker thread, and calls run_engine_scan() (in engine.rs).

Stage-based execution model

The engine uses a plan-then-execute architecture:

1. Plan (engine/plan.rs): build_execution_plan() creates an ExecutionPlan with an ordered Vec<ExecutionStageId>. For connectivity scans the order is derived from probe_tasks families (or a default sequence). For strategy probes, strategy_stage_order() builds: Environment -> (Web, only when in-path mode with a route and domain targets) -> StrategyDnsBaseline -> StrategyTcpCandidates/StrategyQuicCandidates (QUIC first when confirm_good_dpi_evidence is set, TCP first otherwise) -> StrategyConnectionConcurrency -> StrategyRecommendation. Read strategy_stage_order() directly before restating this order; it is a stale-prone list, not a fixed constant.