# Highlift Atelier — Instructions Claude Code

> Commence toujours par lire **CONTEXT.md** avant toute action.
> Il contient l'architecture, le schéma DB, les conventions et l'état d'avancement.

---

## Projet en une phrase
Application web PHP de suivi des réparations machines pour Highlift.be,
pilotée par scan QR code (douchettes WiFi industrielles).

---

## Stack — ne pas dévier de ça
- **PHP 8.4** + **mysqli** (pas PDO, pas de framework)
- **MySQL OVH** — config dans `clientmysql.php` (jamais commité)
- **HTML + JS vanilla** (pas de React, pas de Vue)
- **PDF** : mPDF (déjà utilisé dans d'autres projets)
- **QR Code** : endroid/qr-code via Composer

---

## Environnements
| | URL | DB |
|---|---|---|
| Test | atelier.simons.eu | highlift_atelier_dev |
| Prod | atelier.highlift.be | highlift_atelier |

---

## Conventions impératives
- Config DB : toujours dans `clientmysql.php` — **jamais hardcodé, jamais commité**
- API : toujours retourner `{ "status": "ok|error", "data": ..., "message": ... }`
- Dates : stockées UTC, affichées Europe/Brussels (`date_default_timezone_set`)
- QR codes : format fixe — `MCH-XXXX` / `USR-XXXX` / `ART-XXXXX` / `ACTION-FIN`
- Encodage : UTF-8 partout (`charset=utf8mb4` en DB)
- Pas de librairie externe sans m'en parler d'abord

---

## Structure des dossiers
```
/public      → interface ouvrier (scan, session en cours)
/admin       → back-office (machines, users, rapports)
/api         → endpoints JSON (scan.php, start.php, stop.php, addpiece.php)
/sync        → CRON Odoo → MySQL
/labels      → génération PDF étiquettes QR
/lib         → librairies
/sql         → schema.sql + seeds.sql
```

---

## Priorités de développement (dans cet ordre)
1. `sql/schema.sql` — schéma complet
2. `clientmysql.php.example` — template config DB
3. `api/scan.php` — cerveau de l'appli, route tous les scans
4. `public/index.php` — interface scan ouvrier
5. `admin/machines.php` — gestion machines + QR
6. `admin/users.php` — gestion ouvriers
7. `api/rapport.php` — rapport PDF journalier
8. `sync/sync_odoo_pieces.php` — sync catalogue Odoo
9. GitHub Actions SFTP deploy

---

## Logique scan — rappel
```
Scan reçu → api/scan.php
  ├── USR-XXXX   → identifier l'ouvrier sur cette session
  ├── MCH-XXXX   → démarrer une réparation (si pas de session active)
  │               → ou afficher session en cours
  ├── ART-XXXXX  → ajouter pièce à la réparation active
  └── ACTION-FIN → clôturer la réparation active
```

---

## Intégration Odoo
- JSON-RPC (même pattern que projets CIP SA)
- Lecture seule en Phase 1 (sync pièces)
- Écriture stock = Phase 2 uniquement
- Credentials Odoo Highlift : **à fournir par le client, non stockés dans le repo**

---

## Déploiement
- GitHub Actions → SFTP vers OVH (même pattern que `checkingatwork`)
- Fichier workflow : `.github/workflows/deploy.yml`
- `clientmysql.php` créé manuellement sur chaque serveur, jamais via deploy

---

## En fin de chaque session de travail — OBLIGATOIRE
1. Mettre à jour les cases `[x]` dans **CONTEXT.md** (section État d'avancement)
2. Noter dans CONTEXT.md toute décision d'architecture prise pendant la session
3. `git add -A && git commit -m "desc courte" && git push`

---

## Contacts & accès
- **Développeur** : Dimitri Simons — ds@cip-sa.be — 0486/243319
- **GitHub** : compte Dimitri Simons, repo privé `highlift-atelier`
- **Hébergement test** : OVH simons.eu (accès SFTP Dimitri)
- **Hébergement prod** : OVH highlift.be (accès à obtenir auprès de Highlift)