# Repository Guidelines

## Project Structure & Module Organization
This repository is a legacy PHP web application served from the repo root. Feature areas are grouped by directory, including `admin/`, `customer/`, `courier/`, `invoice/`, `jobs/`, `jobs2/`, `import/`, `service/`, and `sysadmin/`. Shared includes, auth, database helpers, and AJAX endpoints live in `include/`. Assets are in `js/`, `css/`, `images/`, and `lib/`.

Treat `lib/`, `locating/`, and `include/barcode*` as vendor-style code unless a task explicitly targets them. Runtime files and exports appear under `temp/` and `log/`; avoid committing generated content there.

## Build, Test, and Development Commands
There is no top-level build pipeline; PHP files are executed directly.

- `php -S 127.0.0.1:8000 -t .` — run the application locally from the repository root.
- `php -l path/to/file.php` — syntax-check a changed PHP file before submitting.
- `find admin include jobs tools -name '*.php' -print0 | xargs -0 -n1 php -l` — optional batch lint for touched areas.

Open `http://127.0.0.1:8000/index.php` to verify redirects and login flow.

## Coding Style & Naming Conventions
Follow the style already present in the file you touch; do not reformat large legacy files. Use full `<?php ?>` tags, keep shared includes in `*.inc.php`, and prefer snake_case for PHP variables and helpers. Existing code commonly uses `if (...): ... endif;` and uppercase SQL keywords.

Preserve existing indentation and file encoding. Some files still use `latin1` or legacy HTML charsets, so avoid bulk UTF-8 conversion.

## Testing Guidelines
There is no centralized PHPUnit or Jest suite for the main app. Use targeted syntax checks, then browser or CLI smoke tests for the feature you changed. Existing verification scripts usually follow the `*.test.php` naming pattern and sit near the related feature.

Run any test scripts only against a safe local database; several scripts trigger real queries, cron-like loops, or exports.

## Commit & Pull Request Guidelines
This checkout does not include `.git` history, so follow concise, imperative commit messages such as `jobs: fix courier price lookup`. Keep commits focused by feature area.

For pull requests, include: purpose, affected paths, config prerequisites, manual validation steps, and screenshots for UI changes. Call out changes to `include/`, auth flow, imports, exports, or scheduled scripts explicitly.

## Security & Configuration Tips
Database and environment-specific settings are loaded from include files such as `include/dbconnect.inc.php`. Never commit real credentials, production URLs, or customer data. Sanitize exports, logs, and files under `temp/` before sharing.