====== Car management ======

*//Car management//// holds your programme’s ////clients//// (owners), ////cars////, paperwork, ////lifing////, and ////financial lines//* tied to each project.

===== Clients =====

A *//client//* is the commercial counterparty — owner, entrant, or sponsor entity. Store contact details and notes here so car records stay linked to the right person.

===== Cars =====

Each *//car//* has a stable identity in the system (used for logistics, scrutineering QR, and history). For each car you typically maintain:

- Identity (chassis, number, model lines for display)
- *//Documents//* (uploads and expiry where you track compliance)
- *//Lifing//* on components (hours, cycles, dates)
- *//Money in / out//* lines when you use the built-in project accounting
- *//Race bookings//* linking the car to events in logistics

===== Car QR codes =====

Cars can carry a *//QR code//* used by:

- *//Scrutineering//* handsets (officials scan at the lane)
- *//Workshop tablets//* (crew scan to open the car context)
- *//Public scan flows//* where your programme enables tokenised views

Print or display the QR from the car record when the event requires physical labels on the car or paperwork folder.

===== Scrutineering history =====

When scrutineering is enabled, *//reports and setup baselines//// accumulate on the car file. Open the car in admin and review the ////scrutineering//* section for a season-long thread — useful for protests, insurance, and handover between events.

===== Showroom and sales =====

Cars marked for *//showroom//// use additional sales fields (photos, spec bullets, slug). See ////Showroom listings//// in this manual. Lifecycle moves such as ////Sold//* archive the public listing while keeping the operational record.

===== Who can edit what =====

Team admins edit cars for their programme. Super-admins can see all teams. Restricted logins only see car management if that module is enabled for their account.