Ajouter les règles agent entreprise/projet/ops pour le CRM.

Documente le layout public_html et le playbook de déploiement Gitea.

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/ops/20-git-deploy-playbook.mdc

@@ -0,0 +1,29 @@
+---
+description: CRM MS1 — playbook Git/deploy + état connu (ops)
+alwaysApply: true
+---
+
+# Playbook Git / deploy — CRM MS1
+
+## Layout (≠ Reader)
+
+- Dépôt Git serveur = **`~/public_html`** (comme un site entier dans le docroot).
+- `deploy_dev.php` doit être **versionné** à la racine du dépôt — sinon chaque `git clean -fd` l'efface.
+
+## Philosophie
+
+- Serveur = déploiement only (pas de `user.name` / commits serveur).
+- Windows → Gitea → webhook → `deploy_dev.php` → `~/deploy/deploy_dev.sh`.
+
+## Subtilités / état à surveiller
+
+- `git clean -fd` est agressif : tout fichier non versionné dans `public_html` disparaît.
+- Si le push Windows échoue : auth Gitea (token), pas OAuth HTTP cassé.
+- Miroir Bitbucket : sync à chaque soumission + intervalle filet `1h` (aligner sur Reader).
+- Tunnel SQL / Cursor : SSH **7822**.
+
+## Checklist locale agent
+
+1. `deploy_dev.php` présent et tracké avant d'activer le webhook.
+2. Tester `curl` / hit sur `deploy_dev.php` après correction des chemins absolus dans le `.sh`.
+3. Vérifier Gitea + serveur sur le même SHA `dev`.

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

@@ -0,0 +1,38 @@
+---
+description: CRM MS1 — paramètres figés (ops)
+alwaysApply: true
+---
+
+# Paramètres — CRM MS1
+
+Secrets → 1Password uniquement.
+
+## Git / remotes
+
+| Clé | Valeur |
+|---|---|
+| Gitea (Windows) | `http://git.progiweb.ca/stephan/crm-ms1.git` |
+| Gitea (serveur, typique) | `http://127.0.0.1:3000/stephan/crm-ms1.git` |
+| Branche travail | `dev` |
+| Autre branche remote vue | `main` (historique) — travail sur **`dev`** |
+| Bitbucket | Ancien ; source de vérité = **Gitea** |
+
+## Webhook / deploy (dev)
+
+| Clé | Valeur |
+|---|---|
+| URL webhook prévue | `https://ms1crmdev.progiweb.net/deploy_dev.php` |
+| Script | `~/deploy/deploy_dev.sh` |
+| Git root serveur | **`~/public_html`** (tout le CRM = docroot) |
+| Comportement script | fetch → reset --hard → `git clean -fd` |
+
+## SSH / SQLTools
+
+| Clé | Valeur |
+|---|---|
+| Port SSH | **7822** (pas 3306 pour le tunnel) |
+| Hosts connus | `ms1crmdev.progiweb.net`, etc. |
+
+## 1Password / auth
+
+- Même modèle Reader : token Gitea pour push Windows ; miroir Bitbucket si activé = `x-token-auth` + access token.

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

@@ -0,0 +1,10 @@
+---
+description: CRM MS1 — documentation agent
+alwaysApply: true
+---
+
+# Documentation agent — CRM MS1
+
+- Documenter la logique métier non évidente.
+- Référencer le ticket JIRA dans le code / SQL quand fourni.
+- Fin de tâche : quoi / où / déploiement.

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

@@ -0,0 +1,11 @@
+---
+description: Conventions PHP CRM MS1
+globs: **/*.php,application/**/*.php,v4/**/*.php,v4_ci4/**/*.php
+alwaysApply: false
+---
+
+# Conventions PHP — CRM MS1
+
+- Suivre le fichier ouvert (style local).
+- Changement minimal ; pas de modernisation globale sans accord.
+- Pas de secrets dans le code ; pas de `var_dump` laissé en prod.

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

@@ -0,0 +1,11 @@
+---
+description: CRM MS1 — stack et préfixe JIRA (projet)
+alwaysApply: true
+---
+
+# Projet CRM MS1 — stack
+
+- Stack : PHP applicatif CRM (`application/`, `v4/`, `v4_ci4/`, etc.).
+- Préfixe JIRA : confirmer avec l'utilisateur (souvent ticket CRM / MS1 selon le contexte).
+- Workspace local typique : `C:\dev_v4\crm-ms1`.
+- Ne pas committer `credentials.json` ni secrets.