ludo

Use the initial mode, which starts from the car's verified range record and current game version before proposing any slider value. It labels everything as doctrine or assumption and includes the test runs that would turn those assumptions into evidence.

It calls the strategy optimiser's build_inputs and recommend functions rather than hand-rolling stint arithmetic, and requires measured per-lap targets for lap time, fuel burn, and compound wear. Every plan includes a playbook of bounded adaptations and states which constraint actually binds.

Yes, but it reads the 60 Hz telemetry archive first and asks at most four questions the data cannot answer, starting with whether the symptom happens on or off throttle. That throttle-state fork decides which symptom table applies, so it is resolved before any slider is named.

No. Application work such as tests, UI bugs, telemetry capture, packet parsing, haptics, and audio is explicitly out of scope. When a request is app work rather than race engineering, the skill says so and stands down.

Fuel map changes are a standing refusal of the driver, who uses short-shifting and lift-and-coast instead. Corner names are refused because corner models are auto-segmented from telemetry, so names like turn three cannot be honestly identified.

It uses the Pit Crew SQLite database containing 60 Hz lap frames with per-wheel slip, suspension height, surface type, steering, and pedal channels, plus session, event, and measurement tables. It runs a data health check per car and circuit before making any claims.