Guide: EVCC operations and backend orchestration
================================================

The EVCC path is how you drive loopback sessions, backend adapter checks, and differential proof. The snapshot includes native EVCC reference profiles plus adapter-backed Josev and EVerest surfaces.

Backends in the snapshot
------------------------
.. list-table::
   :header-rows: 1
   :widths: 20 25 55

   * - Backend
     - Execution posture
     - Use it for
   * - native
     - in_process
     - health-check, capability-probe, native-session-launch, timeout-capture ...
   * - josev
     - external_process
     - health-check, capability-probe, external-process-start-hook, external-process-stop-hook ...
   * - everest
     - external_process_or_container
     - health-check, capability-probe, external-process-start-hook, external-process-stop-hook ...

When to stay native
--------------------
- For fast loopback bring-up and profile sanity checks.
- When you want deterministic reference coverage that is controlled entirely inside ChargeLink.
- When you need a fast debugging baseline before moving to Josev, EVerest, or hardware EVCC.

When to use external backends
-----------------------------
- When you need vendor-aware differential behavior.
- When the release question is about adapter readiness, orchestration, or partner proof.
- When MCS differential matrices or external EVCC runtime proof are part of the gate.