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 supports several layers of customisation so that each workshop can tailor the checklist content, visual branding, and language to their exact requirements — without forking the codebase or modifying core application logic. Most configuration happens through environment variables and dedicated config files rather than scattered inline edits.

Custom inspection sections

Inspection sections are defined in the section configuration module. Each section is a typed SectionConfig object that declares its checklist items, display label, icon, and whether it is mandatory for a completed inspection. A section definition looks like this:
export const customSection: SectionConfig = {
  id: 'air-conditioning',
  label: 'Aire Acondicionado',
  icon: 'snowflake',
  mandatory: false,
  items: [
    { id: 'ac-cooling',     label: 'Refrigeración',    mandatory: true  },
    { id: 'ac-filter',      label: 'Filtro de cabina', mandatory: false },
    { id: 'ac-compressor',  label: 'Compresor',        mandatory: true  },
  ],
};
To add your section to the inspection form, import it and append it to the default sections array exported from the section configuration module:
import { defaultSections } from './defaultSections';

export const sections: SectionConfig[] = [
  ...defaultSections,
  customSection,
];
The SectionConfig and ItemConfig interfaces are defined in the inspection types module:
interface ItemConfig {
  id: string;
  label: string;
  mandatory: boolean;
  /** Optional free-text note shown below the checklist item in the form */
  hint?: string;
}

interface SectionConfig {
  id: string;
  label: string;
  /** Icon name from the Lucide icon set (https://lucide.dev/icons/) */
  icon: string;
  mandatory: boolean;
  items: ItemConfig[];
}
Section and item id values must be unique across the entire inspection. They are used as keys in the stored inspection record and in generated PDF reports. Changing an id after inspections have been saved locally will break the display of those historical records.
The mandatory flag on a section means the section must be fully completed before the inspection can be submitted. The mandatory flag on an item means that specific checklist item must be answered (pass, fail, or N/A) before the section is considered complete.

Branding

Workshop branding is controlled entirely through environment variables — no source code changes are required. Set the following variables in your .env (or .env.production) file:
VITE_WORKSHOP_NAME="Euroautos Madrid"
VITE_PRIMARY_COLOR=#1A3A5C
These values propagate throughout the application:
VariableWhere it appears
VITE_WORKSHOP_NAMEApp header, PDF report footer, browser title
VITE_PRIMARY_COLORButtons, active nav items, report header stripe, progress bars

Language / locale

The application ships with full Spanish (es) translations. All user-visible strings are managed through i18n key files in the locale configuration directory. Current locale support:
LocaleStatus
Spanish (es)✅ Fully supported
English (en)🔧 Community — see below
To add English (or any other language), duplicate the Spanish locale file and translate the values. For example, using the Bash shell:
cp src/locales/es.json src/locales/en.json
Open the new locale file and translate each string value, leaving keys unchanged:
{
  "app.header.title": "Vehicle Inspection",
  "inspection.status.pass": "Pass",
  "inspection.status.fail": "Fail",
  "inspection.status.na": "N/A",
  "inspection.submit.button": "Submit Inspection",
  "inspection.submit.confirm": "Are you sure you want to submit this inspection? This action cannot be undone.",
  "report.generatedBy": "Generated by {{workshopName}}",
  "report.date": "Inspection date"
}
Then register the new locale in the i18n configuration module:
import en from './locales/en.json';
import es from './locales/es.json';

export const resources = {
  es: { translation: es },
  en: { translation: en },
};
The active language is determined at runtime by the browser’s navigator.language value, falling back to Spanish if no matching locale is found. You can override this default in the i18n configuration module by changing the fallbackLng option.

Report template

The PDF inspection report layout is defined in the report template module. It is a React component rendered in the browser via @react-pdf/renderer and compiled into a PDF when the technician finalises an inspection. The template supports the following customisation points:
  • Header — workshop name and inspection date. Controlled by the branding env variables.
  • Footer — page numbering, workshop contact details, and a legal disclaimer. Edit the <ReportFooter /> component in the report template module.
  • Section ordering — sections appear in the PDF in the same order they are defined in the section configuration module. Re-order the array to change the PDF layout.
  • Custom fields — add workshop-specific metadata (e.g. assigned technician, service bay number) by extending the InspectionMeta type in the inspection types module and adding the corresponding field to the <ReportHeader /> component.
// Extending the metadata type in the inspection types module
interface InspectionMeta {
  vehiclePlate: string;
  vehicleMake: string;
  vehicleModel: string;
  vehicleYear: number;
  mileage: number;
  // Custom fields:
  technicianName: string;
  serviceBay: string;
}

Theming

The application’s colour scheme is driven by CSS custom properties (variables) defined in the theme stylesheet. You can override any of these to adjust the visual appearance beyond what VITE_PRIMARY_COLOR provides.
:root {
  /* Primary brand colour — also set via VITE_PRIMARY_COLOR */
  --color-primary:  #1A3A5C;

  /* Lighter accent used for hover states and highlights */
  --color-accent:   #2E6DA4;

  /* Background colour for cards and panels */
  --color-surface:  #F5F7FA;

  /* Text colours */
  --color-text:         #1C1C1E;
  --color-text-muted:   #6B7280;

  /* Status colours for pass / fail / N/A indicators */
  --color-pass:   #16A34A;
  --color-fail:   #DC2626;
  --color-na:     #9CA3AF;

  /* Border radius applied to cards and buttons */
  --radius-md: 8px;
  --radius-lg: 12px;
}
If you update --color-primary directly in the theme stylesheet, you can remove the VITE_PRIMARY_COLOR variable from your .env file. The CSS variable takes precedence over the dynamically injected style when both are present.
Dark mode support is planned for a future release. The current theme stylesheet contains a commented-out @media (prefers-color-scheme: dark) block that you can uncomment and customise to enable an experimental dark theme for your deployment.

Build docs developers (and LLMs) love