Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/juanmatz/inspection-form-euroautos/llms.txt

Use this file to discover all available pages before exploring further.

The Euroautos Inspection Form is built around a set of strongly-typed data structures that represent every aspect of a vehicle inspection — from top-level record metadata down to individual checklist item findings and photographic evidence. All data is persisted locally in the browser’s IndexedDB store so that inspections can be created and completed without a network connection, and optionally synced to the backend API when connectivity is restored.

​
Inspection

The Inspection interface is the root record for a single vehicle inspection job. It ties together the vehicle being inspected, the inspector and workshop responsible, the current workflow status, and the ordered list of completed sections. 
interface Inspection {
  id: string;                    // UUID v4, generated client-side on record creation
  vehicleId: string;             // References a Vehicle record
  workshopId: string;            // Identifies the Euroautos workshop location
  inspectorId: string;           // User ID of the assigned inspector
  status: 'draft' | 'pending_review' | 'approved' | 'completed';
  createdAt: string;             // ISO 8601 datetime string, e.g. "2024-11-14T09:32:00Z"
  updatedAt: string;             // ISO 8601 datetime, updated on every save
  completedAt: string | null;    // ISO 8601 datetime when status became 'completed'; null otherwise
  sections: InspectionSection[]; // Ordered array of all inspection sections
  signature: string | null;      // Base64-encoded SVG from the inspector's signature pad
  notes: string;                 // Top-level inspector notes, visible on the final report
}
The id is always generated client-side using crypto.randomUUID() at the moment the inspector creates a new record. This means the record can be written to IndexedDB immediately — without waiting for a server response — and the same ID is used when the record is eventually synced to the backend. Collisions are statistically negligible with UUID v4.

​
Vehicle

The Vehicle interface captures the identifying details of the car or light commercial vehicle being inspected. A vehicle record may be reused across multiple inspections over time. 
interface Vehicle {
  id: string;               // UUID v4
  licensePlate: string;     // Registration number as displayed, e.g. "AB12 CDE"
  make: string;             // Manufacturer name, e.g. "Volkswagen"
  model: string;            // Model name, e.g. "Golf GTI"
  year: number;             // Four-digit year of first registration, e.g. 2021
  mileage: number;          // Odometer reading in kilometres at time of inspection
  colour: string;           // Primary body colour, e.g. "Midnight Blue"
  vin: string;              // 17-character Vehicle Identification Number
}
The vin field is validated against the standard 17-character alphanumeric format (excluding the letters I, O, and Q) before the Vehicle Information section can be marked complete. The licensePlate value is stored exactly as entered and is used as the primary human-readable identifier throughout the form UI and on the generated PDF report.

​
InspectionSection

Each Inspection contains an ordered array of InspectionSection records — one per section type. Sections are created automatically when a new Inspection record is initialised, with all items in a default unassessed state. 
type SectionType =
  | 'vehicle_information'
  | 'exterior_condition'
  | 'interior_condition'
  | 'engine_mechanical'
  | 'electrical_systems'
  | 'tyres_wheels'
  | 'brakes'
  | 'final_checklist';

interface InspectionSection {
  id: string;                  // UUID v4
  inspectionId: string;        // References the parent Inspection
  type: SectionType;           // Determines which checklist template is loaded
  inspectorId: string;         // May differ from Inspection.inspectorId on multi-tech jobs
  items: ChecklistItem[];      // All checklist items belonging to this section
  completedAt: string | null;  // ISO 8601 datetime when the section was marked complete
}

​
ChecklistItem

ChecklistItem is the atomic unit of the inspection. Each item represents a single inspection point within a section — for example, “Front left tyre tread depth” within the tyres_wheels section. All findings, notes, and photographic evidence are stored at this level. 
type ChecklistItemStatus = 'ok' | 'attention' | 'critical' | null;

interface ChecklistItem {
  id: string;                        // UUID v4
  sectionId: string;                 // References the parent InspectionSection
  label: string;                     // Human-readable description, e.g. "Front left tyre tread"
  status: ChecklistItemStatus;       // null = not yet assessed
  notes: string;                     // Free-text finding notes; required when status is not 'ok'
  photos: string[];                  // Array of Base64-encoded image strings (JPEG or PNG)
  mandatory: boolean;                // If true, must be assessed before section can be submitted
  branchFields: BranchField[] | null; // Expanded detail fields revealed when status is 'critical'
}

interface BranchField {
  id: string;
  label: string;
  type: 'text' | 'number' | 'boolean' | 'select';
  options: string[] | null;   // Populated when type is 'select'
  value: string | null;       // Stores the inspector's response
  mandatory: boolean;
}

​
Local storage

All inspection data is persisted in the browser’s IndexedDB database under the store name euroautos_inspections. The database contains three object stores: inspections (keyed by Inspection.id), vehicles (keyed by Vehicle.id), and sync_queue (an ordered log of mutations that have not yet been confirmed by the backend).When the application is offline or the backend is unreachable, every create, update, and delete operation is written to sync_queue as a serialised mutation object containing the operation type (create | update | delete), the target store name, the affected record ID, and the full record payload. When connectivity is restored, the application processes the queue in order, replaying mutations against the API and removing entries from the queue as each one is acknowledged. If a sync conflict is detected — for example, the same record was modified on another device — the backend returns a 409 Conflict response and the application surfaces a manual merge prompt to the user.
Photos stored as Base64 strings can significantly increase the size of an inspection record — a single high-resolution JPEG can be 1–3 MB encoded. Inspectors should be aware that a heavily-photographed inspection may approach or exceed the default IndexedDB quota on some mobile browsers. The application will warn the inspector if the estimated storage usage for the current inspection exceeds 25 MB, and will prompt them to compress photos before attaching further images.

Build docs developers (and LLMs) love

Get started for freeTalk to us