# Repository Guidelines

## Project Structure & Module Organization
This repository is a PrestaShop-based store with customizations across core-like folders and modules.
- `controllers/`, `classes/`, `src/`: main PHP application logic (legacy + Symfony-style code).
- `modules/`: feature modules (custom and vendor-like). Most front-end build/test tooling lives here.
- `themes/` and `themes/leo_gstore/`: storefront templates, assets, and theme behavior.
- `override/`: PrestaShop overrides; keep changes minimal and well-justified.
- `app/config/`, `config/`: environment and platform configuration.
- `changelog/`: dated change notes (for example `changelog/2026-03-19.md`).

## Build, Test, and Development Commands
There is no single root build command; use module-scoped workflows.
- `php -l path\to\file.php`: quick PHP syntax check before commit.
- `cd modules\ps_facetedsearch && npm install && npm run dev`: install deps and run watch build.
- `cd modules\ps_facetedsearch && npm run build`: production JS/CSS bundle.
- `cd modules\ps_facetedsearch && npm test`: run Mocha tests (`tests/**/*.spec.js`).
- `cd modules\gsitemap && composer install`: install PHP dev dependencies for that module.

## Coding Style & Naming Conventions
- Follow existing PrestaShop conventions: PHP classes in `PascalCase`, methods in `camelCase`, constants in `UPPER_SNAKE_CASE`.
- Keep indentation/style consistent with surrounding file (legacy files vary; do not reformat unrelated code).
- Use descriptive module/template names (example: `AdminSearchController.php`, `search-results.tpl`).
- Prefer changes in `modules/` or `themes/` over editing vendor code in `vendor/` or `phpmailer/`.

## Testing Guidelines
- Test at the smallest valid scope: module-level first, then manual store/admin verification.
- JS tests use `*.spec.js` (see `modules/ps_facetedsearch/tests`).
- Run syntax checks for edited PHP files and exercise affected BO/FO pages (cart, product page, checkout, admin config).
- No global coverage gate is enforced; add/update tests when touching tested modules.

## Commit & Pull Request Guidelines
- Prefer clear, typed commits: `feat: ...`, `fix: ...`, `chore: ...`.
- Avoid vague messages like `update` or `Save`.
- Keep commits focused to one concern and include touched paths in PR description.
- PRs should include: purpose, risk/rollback notes, manual test steps, and screenshots for UI/theme changes.
- For user-visible behavior changes, add/update a dated file in `changelog/`.