dicklesworthstone/vibe_cockpit

Purpose and entry points

Vibe Cockpit (vc) is a Rust fleet console for AI coding-agent telemetry across local and SSH-reachable machines. Its primary executable entry point is src/main.rs; command orchestration and machine-readable output live in crates/vc_cli/src/lib.rs and crates/vc_cli/src/robot.rs. Operators use CLI, daemon, TUI, web API, or MCP; all non-collection surfaces read persisted state.

Configuration and runtime boundary

vc_config defines the shared runtime configuration, including database location, enabled collectors, schedules, and machine definitions: crates/vc_config/src/lib.rs. Collection is explicitly the external-I/O boundary: it invokes installed tools, reads local files/databases, and opens SSH sessions. Cancellation-aware execution, remote access, and machine registration are separated in crates/vc_collect/src/executor.rs, crates/vc_collect/src/ssh.rs, and crates/vc_collect/src/machine.rs.

Collection pipeline

vc_collect runs a pluggable set of source adapters, normalizes their results, redacts sensitive values, and writes observations to storage. Collector implementations cover agent tools, GitHub, system probes, SQLite/JSONL sources, and HTTP benchmarking under crates/vc_collect/src/collectors/mod.rs, crates/vc_collect/src/collectors/github.rs, and crates/vc_collect/src/collectors/sysmoni.rs. Scheduling, adaptive polling, and per-collector execution are centered in crates/vc_collect/src/scheduler.rs, crates/vc_collect/src/probe.rs, and crates/vc_collect/src/redact.rs.

Durable data plane

vc_store is the system-of-record layer backed by DuckDB. It owns schema access and ordered migrations in crates/vc_store/src/lib.rs, crates/vc_store/src/schema.rs, and crates/vc_store/src/migrations/001_initial_schema.sql. Migrations establish tables for telemetry, machines, health, alerts, knowledge, experiments, commands, and retention. The documented DuckDB-to-FrankenSQLite export is one-way; DuckDB remains the read/write source for the application.

Analysis, scoring, and operational decisions

vc_query transforms stored telemetry into fleet views: health scores/factors, freshness, cost attribution, digests, guardrails, and natural-language query handling. Its architectural core is crates/vc_query/src/health.rs, crates/vc_query/src/nl.rs, and crates/vc_query/src/cost.rs. vc_alert evaluates and records alert rules/routes (crates/vc_alert/src/lib.rs, crates/vc_alert/src/routing.rs); threshold evaluation is the implemented alert condition. Higher-level automation and intelligence are isolated in crates/vc_guardian/src/autopilot.rs, crates/vc_knowledge/src/mining.rs, and crates/vc_oracle/src/evolution.rs.

Read and integration surfaces

The interactive terminal console is vc_tui, with store-backed data access and screen composition in crates/vc_tui/src/data.rs, crates/vc_tui/src/lib.rs, and crates/vc_tui/src/screens/overview.rs. The read-only HTTP/WebSocket and metrics-facing service is vc_web (crates/vc_web/src/lib.rs, crates/vc_web/src/auth.rs), with a separate Next.js frontend under web/src/app/page.tsx and web/src/lib/api.ts. Agent integration is provided by a stdio JSON-RPC MCP server in crates/vc_mcp/src/lib.rs; versioned robot envelopes and TOON output are handled by crates/vc_cli/src/robot.rs and crates/vc_cli/src/toon.rs.

Primary control flow

vc daemon repeatedly executes: load config → schedule local/remote collectors → normalize/redact → persist to DuckDB → derive health/freshness → evaluate threshold alerts. TUI, web, MCP, JSON CLI, and robot commands query the resulting store rather than querying external tools directly. JSON robot contracts are published in docs/schemas/robot-envelope.json, docs/schemas/robot-health.json, and docs/schemas/robot-triage.json.