[DTP-Worker] Sprint 1 · CI/CD Gitea Actions (gate qualité 4Big · DevOps)

Débloque le dernier livrable DevOps Sprint 1 authorable en-repo (GAP §7).

- .gitea/workflows/ci.yml : pipeline Gitea Actions (Gitea ONLY, jamais GitHub)
  4 jobs : constraints-guard · validate-json · check-docs · gate agrégat.
- ci/guard_constraints.sh : enforce contraintes NON-NÉGOCIABLES CLAUDE.md
  (GitHub/GitLab/Bitbucket #2 · EspoCRM/HubSpot #3 · Stripe #10 ·
  /var/www/html/static · git clean · remote non-Gitea).
  Heuristique zéro faux positif (ignore lignes de prohibition) + escape ci-allow.
- ci/validate_json.sh : parse strict schémas Faisabilité↔Publiciste.
- ci/check_docs.sh : liens Markdown internes [HARD] + auto-score 4Big [SOFT].
- ci/README.md : doc pipeline + procédure enregistrement act_runner (VPS/DevOps).
- GAP_ANALYSIS §7 : critère CI/CD Gitea Actions -> done (runner VPS restant).

Validé localement : 3 scripts verts (exit 0) sans faux positif ;
test négatif (hubspot+github.com) -> guard exit 1 correct.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ci/README.md

@@ -0,0 +1,95 @@
+# CI/CD · OTO Enterprise OS DTP · Gitea Actions
+
+> **Livrable Sprint 1** (roadmap `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` §Sprint 1 · DevOps)
+> _« CI/CD Gitea Actions »_ — gate qualité qui conditionne tous les sprints suivants.
+>
+> **Plateforme : Gitea Actions UNIQUEMENT** (CLAUDE.md contrainte #2 · JAMAIS GitHub).
+
+---
+
+## 1. Ce que fait le pipeline
+
+Workflow : `.gitea/workflows/ci.yml`. Déclenché sur `push` / `pull_request` vers `main`
+et manuellement (`workflow_dispatch`). Quatre jobs :
+
+| Job | Script | Rôle | Blocant |
+|---|---|---|---|
+| `constraints-guard` | `ci/guard_constraints.sh` | Enforce les contraintes NON-NÉGOCIABLES de CLAUDE.md | ✅ oui |
+| `validate-json` | `ci/validate_json.sh` | Parse strict de tous les `*.json` (schémas Faisabilité↔Publiciste) | ✅ oui |
+| `check-docs` | `ci/check_docs.sh` | Liens Markdown internes + présence auto-score 4Big | ✅ oui (liens) |
+| `gate` | — | Agrégat vert = gate qualité 4Big franchi | ✅ oui |
+
+Aucune dépendance réseau/marketplace hors `actions/checkout`. Tout tourne avec
+`bash` + `git` + `python3` (déjà présents sur un runner standard).
+
+## 2. Détail des contrôles
+
+### `guard_constraints.sh` — contraintes NON-NÉGOCIABLES
+Détecte l'**usage** (pas la simple mention) de :
+- Plateformes git interdites : `github.com`, `gitlab.com`, `bitbucket.org` (#2).
+- CRM interdits : `EspoCRM`, `HubSpot` (#3).
+- Paiement interdit : `Stripe` (#10 · Cardnet only).
+- Écriture directe dans `/var/www/html/static/` (Interdit absolu).
+- Commande `git clean` (Interdit absolu).
+- Remote git pointant ailleurs que Gitea/interne.
+
+**Zéro faux positif** : une ligne contenant un marqueur de prohibition
+(`jamais`, `❌`, `only`, `pas de`, `interdit`…) est un rappel de règle → ignorée.
+Escape hatch documenté : ajouter `ci-allow` sur une ligne pour l'exclure.
+
+### `validate_json.sh`
+Parse chaque `*.json` suivi (dont `version.schema.json` et
+`projets_master.schema.json`, contrat de données Faisabilité → Publiciste).
+Un JSON cassé casse le pipeline aval → attrapé ici.
+
+### `check_docs.sh`
+- **[HARD]** liens Markdown relatifs internes : la cible doit exister.
+- **[SOFT]** livrables `05_deliverables_mvp/*.md` : mention d'auto-score 4Big
+  attendue (≥95/100, CLAUDE.md #5). Avertissement seul, non blocant.
+
+## 3. Exécution locale (avant push)
+
+```bash
+bash ci/guard_constraints.sh   # contraintes CLAUDE.md
+bash ci/validate_json.sh       # schémas JSON
+bash ci/check_docs.sh          # liens + score
+```
+
+Chaque script retourne `0` si conforme, `1` sinon. Reproduit exactement ce que
+fait la CI (mêmes scripts, aucune logique cachée côté YAML).
+
+## 4. Enregistrement du runner Gitea (ops · à faire sur le VPS)
+
+> ⚠ Étape **hors périmètre de ce worker** (touche au VPS). À réaliser par
+> l'agent DevOps. Documenté ici pour traçabilité.
+
+Le workflow cible un runner avec le label `ubuntu-latest`. Sur le VPS Gitea
+(`:3015`), enregistrer un `act_runner` :
+
+```bash
+# Sur le VPS, récupérer le token runner :
+#   Gitea → Site Administration → Actions → Runners → Create new Runner
+act_runner register \
+  --instance http://153.75.250.214:3015 \
+  --token <RUNNER_TOKEN> \
+  --labels ubuntu-latest:docker://node:20-bookworm \
+  --name oto-dtp-runner
+act_runner daemon    # ou service systemd dédié
+```
+
+Vérifier ensuite : Gitea → repo `michel/oto-enterprise-os-dtp` → **Settings →
+Actions** doit être activé, et le runner doit apparaître « Idle ».
+
+## 5. Checklist de vérification (DevOps, sur VPS)
+
+- `[ ]` Gitea Actions activé au niveau instance ET repo.
+- `[ ]` `act_runner` enregistré, label `ubuntu-latest`, statut Idle.
+- `[ ]` Push de test → les 4 jobs apparaissent et passent au vert.
+- `[ ]` PR de test avec violation volontaire → `constraints-guard` bloque (rouge).
+
+---
+
+**Auto-score 4Big du livrable : 96/100.** _Réserve −4_ : l'enregistrement du
+runner (§4) est hors périmètre repo et reste à confirmer sur le VPS par DevOps ;
+tant que le runner n'est pas Idle, la CI ne s'exécute pas côté serveur bien que
+les scripts soient validés localement.