❤️ (VCS/VTC) Refactor: Implement Semantic Triage & Adaptive "Lean" Mapping for Vitals Telemetry

[OppaAI]

⚠️ Issue: Telemetry Bloat & Energy Hemorrhage

The Problem: Currently, the Pump is a "dumb" firehose. It harvests every single vitals conduit defined in the YAML at the same frequency, regardless of whether the robot is navigating a minefield or sitting in a garage charging. This causes unnecessary CPU/GPU overhead, drains battery life, and contributes to the "Log Pollution" mentioned in our previous architectural critique.

🎯 Location:

robot/vtc/pump.py
robot/vcs/robot_spec.yaml

🦠 Symptoms:

• High Idle Drain: The Jetson pulls 15W just "monitoring" fan speeds and disk space that haven't changed in hours.
• Buffer Overrun: The lifestream deques are filled with 90% diagnostic "garbage" (DIAG) and 10% operational "gold" (OP).
• Thermal Jitter: High-frequency polling of non-essential sensors adds micro-stutter to time-critical motor control loops.

🩺 Diagnosis:

The ConduitMapBlueprint lacks Semantic Intent. We treat a cpu_usage (Operational) the same as a disk_available_space (Diagnostic). Without a classification flag, we cannot implement "Lean Mode" execution to save the world's energy resources.

💡 Proposal:

The "Telemetry Triage" Protocol Update the YAML schema and the Pump construction logic to support a two-tier vitals system.

1. YAML Contract Update
Add a fourth parameter to the conduit tuple: [Module, Path, Frequency, Triage_Level].
OP (Operational): Essential for real-time survival. Always active.
DIAG (Diagnostic): Non-essential. Only active in "Full Map" or "Service" modes.

2. The "Lean" Filter
Modify _extract_conduit_specs to accept a lean_mode=True flag:
If True, the Pump only builds conduits marked OP.
Reduces jtop lookup overhead by ~60% during active missions.

3. Execution Tiers
Lean Mode: Focused, fast, and energy-efficient. Used for deployment.
Full Mode: Verbose and power-heavy. Used for debugging and admin diagnosis.