Structurer les règles agent (.cursor/rules entreprise/projet/ops).

Playbook Git/deploy et paramètres Reader pour référence automatique à chaque session.

Co-authored-by: Cursor <cursoragent@cursor.com>

.cursor/rules/entreprise/00-checklist-nouveau-projet.mdc

@@ -0,0 +1,21 @@
+---
+description: Checklist agent — monter un nouveau projet sur le modèle Progiweb
+alwaysApply: true
+---
+
+# Checklist nouveau projet (agent)
+
+Quand l'utilisateur demande de reproduire le modèle Reader / Inscription / CRM :
+
+1. Créer la structure `.cursor/rules/{entreprise,projet,ops}/` (copier `entreprise/` depuis un projet déjà aligné).
+2. Remplir `ops/20-parametres.mdc` (URLs Gitea, Bitbucket, chemins serveur, webhook, SSH).
+3. Remplir `ops/20-git-deploy-playbook.mdc` (layout git root : `$HOME` vs `public_html`).
+4. Remplir `projet/` (stack, conventions, préfixe JIRA).
+5. Windows : remote Gitea, branche `dev`, `.gitignore` secrets / runtime.
+6. Versionner `deploy_dev.php` au bon endroit (docroot) **avant** d'activer le webhook.
+7. Serveur : `~/deploy/deploy_dev.sh` (chemins absolus), git init/fetch sur le bon root, tester `curl` webhook.
+8. Gitea : webhook push → URL `deploy_dev.php` ; miroir Bitbucket avec sync **à chaque soumission** + intervalle filet (ex. `1h`).
+9. Test bout en bout : push `dev` → commit visible sur Gitea, serveur, Bitbucket.
+10. Secrets uniquement dans 1Password (référencer le titre de l'item dans `ops/20-parametres.mdc`).
+
+Ne pas inventer Bitbucket SSH sur le serveur : le serveur tire depuis Gitea local (`127.0.0.1:3000`) en général.

.cursor/rules/entreprise/00-git-modele.mdc

@@ -0,0 +1,43 @@
+---
+description: Progiweb — modèle Git / Gitea / Bitbucket / serveur (entreprise)
+alwaysApply: true
+---
+
+# Modèle Git entreprise (Progiweb)
+
+Référentiel agent. Détails par projet → `ops/20-parametres.mdc` et `ops/20-git-deploy-playbook.mdc`.
+
+## Rôles
+
+| Système | Rôle |
+|---|---|
+| **Gitea** (`git.progiweb.ca`) | Source de vérité — push depuis Windows |
+| **Bitbucket** | Miroir / backup opérationnel hors serveurs |
+| **Serveur (cPanel)** | Déploiement uniquement — **jamais** de commits sur le serveur |
+
+## Branches
+
+- Travail quotidien : **`dev`**
+- Prod : **`master`** (quand le projet l'utilise ; ne pas inventer le flux prod)
+- Ne pas pousser `master` sans demande explicite
+
+## Flux nominal
+
+```
+Windows  --push-->  Gitea(dev)  --webhook-->  serveur (deploy_dev)
+                         |
+                         +--miroir push-->  Bitbucket(dev)
+```
+
+## Déploiement (règles absolues)
+
+- Script shell hors webroot : typiquement `~/deploy/deploy_dev.sh`
+- Déclencheur versionné dans le **docroot** : `deploy_dev.php` (sinon `git clean -fd` le détruit)
+- Le script fait : `git fetch` → `git reset --hard FETCH_HEAD` → `git clean` **ciblé** (jamais un clean aveugle sur tout le home cPanel)
+- Via PHP/Apache, **`HOME` est souvent absent** → chemins **absolus** dans le `.sh`
+- Auth Gitea Windows : token (éviter OAuth HTTP « Bad Request »)
+- Auth miroir Bitbucket : user `x-token-auth` + Repository Access Token (1Password) — pas le mot de passe web
+
+## Nouveau projet
+
+Suivre `entreprise/00-checklist-nouveau-projet.mdc` et recopier `entreprise/` + remplir `ops/` + `projet/`.

.cursor/rules/entreprise/00-workflow.mdc

@@ -0,0 +1,30 @@
+---
+description: Progiweb — workflow agent (entreprise). Toujours s'y référer.
+alwaysApply: true
+---
+
+# Workflow entreprise (Progiweb)
+
+Référentiel agent — pas une doc humaine. S'appliquer à tous les projets Progiweb montés sur ce modèle.
+
+## Avant de modifier du code
+
+- Demander le **numéro JIRA** si l'utilisateur ne l'a pas fourni (préfixe selon le projet, voir `projet/`).
+- Ne pas bloquer une simple question ou une lecture seule.
+
+## Portée
+
+- **Changement minimal** : uniquement ce qui est demandé.
+- Pas de refactor large, renommage massif ou nettoyage opportuniste sans accord explicite.
+- Cohérence locale (fichier / module) plutôt que modernisation globale.
+
+## Incohérences voisines
+
+1. Signaler brièvement.
+2. Proposer une correction ciblée.
+3. Attendre confirmation avant de sortir du périmètre.
+
+## Fin de tâche
+
+- Résumer : quoi, où, déploiement / SQL / étapes manuelles restantes.
+- Ne pas créer de README ou docs hors demande explicite (les règles agent vivent dans `.cursor/rules/`).

.cursor/rules/ms1reader-documentation.mdc

@@ -1,35 +0,0 @@
----
-description: Documentation du code et des changements MS1 Reader
-alwaysApply: true
----
-
-# Documentation MS1 Reader
-
-## Commentaires dans le code
-
-- Documenter la **logique métier non évidente**.
-- Pour une nouvelle fonction ou un bloc important : courte description du **pourquoi**, pas seulement du quoi.
-- Référencer le ticket : `// MSREAD-xxxx` ou bloc PHPDoc.
-- Langue : **français** pour les commentaires métier, sauf si le fichier est entièrement en anglais.
-
-## Scripts SQL
-
-En-tête obligatoire en tête de fichier :
-
-```sql
--- MSREAD-xxxx — Titre court
--- Contexte / prérequis
--- Notes (idempotent, safe, etc.)
-```
-
-- Préférer les scripts **idempotents** quand c'est possible.
-
-## Résumé des changements (agent)
-
-À la fin d'une implémentation, fournir :
-
-1. **Quoi** — comportement ajouté ou corrigé.
-2. **Où** — fichiers principaux touchés.
-3. **Déploiement** — SQL, config, étapes manuelles.
-
-Ne pas créer de fichiers README ou docs hors demande explicite.

.cursor/rules/ms1reader-php-conventions.mdc

@@ -1,27 +0,0 @@
----
-description: Conventions PHP / CodeIgniter 4 — MS1 Reader
-globs: **/*.php,ci4app/app/**/*.php,www/**/*.php,public_html/**/*.php
-alwaysApply: false
----
-
-# Conventions PHP MS1 Reader
-
-Code applicatif dans `ci4app/app/`, points d'entrée `www/` / `public_html/`.  
-Ne pas imposer ces règles à `ci4app/system/`, vendors ou librairies tierces.
-
-## Style à respecter
-
-- **Suivre le fichier ouvert** : indentation, guillemets, style des `if` — ne pas « moderniser » PHP dans un diff parallèle.
-- Préférer les patterns CodeIgniter 4 déjà présents (Controllers, Models, Config, Filters).
-- Réutiliser helpers / libraries existants avant d'en créer.
-
-## Qualité
-
-- Code **propre et lisible** dans la zone modifiée ; pas de code mort ni de `var_dump` / `dd()` laissé en prod.
-- **Pas de sur-ingénierie** : pas d'abstraction pour un seul appel.
-- Sécurité : échapper les sorties HTML, Query Builder / requêtes préparées — pas de concat SQL brute.
-
-## Config sensible
-
-- Secrets et DB → `ci4app/.env` (gitignored). Ne jamais committer de mots de passe.
-- Exemple versionné : `ci4app/.env.example`.

.cursor/rules/ms1reader-workflow.mdc

@@ -1,39 +0,0 @@
----
-description: Workflow MS1 Reader — JIRA, validation avant gros changements
-alwaysApply: true
----
-
-# Workflow MS1 Reader
-
-## Numéro JIRA
-
-- Au début d'une tâche de développement (nouvelle feature, correctif, refactor), **demander le numéro JIRA** si l'utilisateur ne l'a pas fourni.
-- Ne pas bloquer une simple question ou une lecture du code — seulement quand on s'apprête à modifier des fichiers.
-- Référencer le ticket dans le code et les scripts SQL : `// MSREAD-xxxx` ou `-- MSREAD-xxxx — description` (ajuster le préfixe projet si différent).
-
-## Portée des changements
-
-- **Changement minimal** : corriger uniquement ce qui est demandé.
-- Pas de refactor large, renommage massif ou « nettoyage » opportuniste sans accord explicite.
-- Pour le code existant, privilégier la cohérence locale (fichier / module touché) plutôt qu'une modernisation globale.
-
-## Git / déploiement (philosophie MS1)
-
-- Développement sur branche **`dev`** ; **`master`** = référence prod.
-- Le serveur = **déploiement uniquement** (pas de commits sur le serveur).
-- Sur le serveur Reader, le dépôt Git est à **`$HOME`** (`/home/ms1reader`) : `ci4app/` et `public_html/` sont frères ; `www` → symlink vers `public_html`.
-- Flux : push Windows → Gitea → webhook → `public_html/deploy_dev.php` → `~/deploy/deploy_dev.sh` (`fetch` + `reset --hard` + `clean -fd` **limité** à `ci4app` et `public_html`).
-- Tout fichier nécessaire après un deploy (ex. `public_html/deploy_dev.php`) **doit être versionné**.
-
-## Incohérences repérées
-
-Quand du code voisin contredit le pattern du fichier ou du module :
-
-1. **Signaler** brièvement l'incohérence à l'utilisateur.
-2. **Proposer** une correction ciblée ou l'alignement sur le pattern dominant.
-3. **Attendre confirmation** avant de corriger hors périmètre.
-
-## Fin de tâche
-
-- Résumer ce qui a changé (fichiers, comportement, SQL à exécuter).
-- Mentionner les étapes manuelles restantes (déploiement, import SQL, cache).

.cursor/rules/ops/20-git-deploy-playbook.mdc

@@ -0,0 +1,36 @@
+---
+description: MS1 Reader — playbook Git/deploy + subtilités (ops)
+alwaysApply: true
+---
+
+# Playbook Git / deploy — MS1 Reader
+
+## Layout critique (≠ CRM)
+
+- Sur le serveur, le dépôt Git est à **`/home/ms1reader`**, pas dans `public_html` seul.
+- `ci4app/` et `public_html/` sont **frères** ; `index.php` charge `../ci4app/...`.
+- `www` est un **symlink** vers `public_html` — ne jamais versionner un dossier `www/` réel (casse le symlink).
+
+## Fichiers deploy (obligatoires)
+
+1. **`/home/ms1reader/deploy/deploy_dev.sh`** (hors git applicatif ou non tracké OK)  
+   - `REPO_DIR="/home/ms1reader"` (absolu — PHP n'a pas `HOME`)  
+   - `git fetch origin dev` → `reset --hard` → `git clean -fd -- ci4app public_html`  
+   - Réparer symlink `www` si besoin  
+2. **`public_html/deploy_dev.php`** (versionné) appelle le `.sh`  
+3. Exemple dans le repo : `deploy/deploy_dev.sh.example`
+
+## Subtilités apprises
+
+- Terminal cPanel ≠ PowerShell Windows (`[ms1reader@serveur-prod ~]$`).
+- Premier `git checkout` sur fichiers existants : souvent besoin de `-f`.
+- `git clean` sur `public_html` peut enlever `.well-known` / favicon non versionnés.
+- Auth Gitea : Credential Manager ; éviter OAuth HTTP (`login/oauth/grant` Bad Request) → provider generic + token.
+- Ne pas tester `git@bitbucket.org` **depuis le serveur** (pas de clé) — Bitbucket = miroir depuis Gitea seulement.
+- Bitbucket créé avec `main` vide : aligner avec `git push --force … dev:dev` puis default branch `dev`, supprimer `main`.
+
+## Test bout en bout
+
+1. Push `dev` → Gitea  
+2. `git -C ~ log -1 --oneline` sur serveur = même SHA  
+3. `git ls-remote --heads git@bitbucket.org:progiwebinc/ms1readerv4.git` (depuis Windows) = même SHA  

.cursor/rules/ops/20-parametres.mdc

@@ -0,0 +1,46 @@
+---
+description: MS1 Reader — paramètres figés (ops). Toujours s'y référer.
+alwaysApply: true
+---
+
+# Paramètres — MS1 Reader
+
+Ne pas réinventer. Secrets → 1Password uniquement.
+
+## Git / remotes
+
+| Clé | Valeur |
+|---|---|
+| Gitea (Windows) | `http://git.progiweb.ca/stephan/ms1readerv4.git` |
+| Gitea (serveur) | `http://127.0.0.1:3000/stephan/ms1readerv4.git` |
+| Bitbucket miroir | `https://bitbucket.org/progiwebinc/ms1readerv4.git` |
+| Branche travail | `dev` |
+| Branche prod | `master` (pas encore le flux actif) |
+
+## Miroir Gitea → Bitbucket
+
+| Clé | Valeur |
+|---|---|
+| Auth user | `x-token-auth` |
+| Auth secret | Repository Access Token (1Password : `Bitbucket mirror — ms1readerv4`) |
+| Sync | **À chaque soumission** + intervalle filet **`1h0m0s`** |
+
+## Webhook
+
+| Clé | Valeur |
+|---|---|
+| URL | `https://ms1reader.info/deploy_dev.php` |
+| Événement | Événements de soumissions (Push) |
+| Méthode | POST, `application/json` |
+
+## Serveur
+
+| Clé | Valeur |
+|---|---|
+| Host / cPanel | `ms1reader.info` / `serveur-prod.progiweb.net` |
+| User / home | `ms1reader` / `/home/ms1reader` |
+| Git root | `/home/ms1reader` (`ci4app` + `public_html` frères) |
+| `www` | symlink → `public_html` |
+| Script deploy | `/home/ms1reader/deploy/deploy_dev.sh` |
+| Webhook PHP | `/home/ms1reader/public_html/deploy_dev.php` |
+| SSH / SQLTools | port **7822**, host `ms1reader.info` |

.cursor/rules/projet/10-documentation.mdc

@@ -0,0 +1,11 @@
+---
+description: MS1 Reader — documentation agent des changements
+alwaysApply: true
+---
+
+# Documentation agent — MS1 Reader
+
+- Documenter la logique métier non évidente ; le **pourquoi**.
+- Référencer le ticket : `// MSREAD-xxxx`.
+- Scripts SQL : en-tête `-- MSREAD-xxxx — Titre` ; préférer idempotent.
+- Fin d'implémentation : quoi / où / déploiement.

.cursor/rules/projet/10-php-conventions.mdc

@@ -0,0 +1,15 @@
+---
+description: Conventions PHP / CI4 — MS1 Reader
+globs: **/*.php,ci4app/app/**/*.php,www/**/*.php,public_html/**/*.php
+alwaysApply: false
+---
+
+# Conventions PHP MS1 Reader
+
+Code applicatif : `ci4app/app/`, entrées `public_html/` / `www/`.  
+Pas ces règles sur `ci4app/system/` ni vendors.
+
+- Suivre le fichier ouvert (style local).
+- Patterns CI4 déjà présents (Controllers, Models, Config, Filters).
+- Pas de sur-ingénierie ; pas de `var_dump` / `dd()` laissé en prod.
+- Sorties HTML échappées ; Query Builder / requêtes préparées.

.cursor/rules/projet/10-stack.mdc

@@ -0,0 +1,12 @@
+---
+description: MS1 Reader — stack et préfixe JIRA (projet)
+alwaysApply: true
+---
+
+# Projet MS1 Reader — stack
+
+- Stack : **CodeIgniter 4** (`ci4app/`) + docroot `public_html/` (`www` → symlink serveur).
+- Préfixe JIRA : **`MSREAD-xxxx`** (confirmer avec l'utilisateur si doute).
+- Commentaires métier : français.
+- Secrets : `ci4app/.env` et/ou `~/.env` serveur — jamais committer.
+- Exemple local : `ci4app/.env.example` ; SQLTools : `.vscode/settings.json.example` (SSH port **7822**).