---
description: Doctrine de travail du projet Circuy. Contexte produit, autorité ponytail, interdiction du sur-engineering, progression par étapes validées. S'applique à toute intervention sur ce dépôt.
alwaysApply: true
---

# Circuy — doctrine de travail

Circuy est une plateforme d'adoption numérique souveraine : un SDK JavaScript exécute des parcours de guidage sur le site du client, une extension de navigateur les crée sans code, un backend Hono/PostgreSQL les stocke, les cible et les distribue. Le contrat JSON de parcours est le pivot : les trois briques ne servent qu'à le produire, le distribuer ou l'exécuter.

## Autorité

Les règles `ponytail` (`.cursor/rules/ponytail/`) sont l'autorité philosophique absolue de ce dépôt. Si ce dossier disparaît du dépôt, les principes ci-dessous restent en vigueur et tiennent lieu de doctrine.

- Le sur-engineering est un défaut sévère, pas une préférence de style.
- YAGNI à toutes les altitudes. Si le besoin n'est pas écrit aujourd'hui, il n'existe pas.
- Jamais d'abstraction, de couche ou d'option spéculative : deux usages concrets existants minimum.
- Ennuyeux et éprouvé bat état de l'art. La charge de la preuve pèse sur la nouveauté.
- Toute nouvelle pièce mobile doit payer son loyer en valeur mesurée, et coûte un ADR.
- « Pour la montée en charge » exige un chiffre. Pas de chiffre, pas de composant.
- Supprimer est une fonctionnalité. Retirer un composant vaut mieux qu'en ajouter un.
- Jamais laxiste sur : sécurité, intégrité des données, validation aux frontières de confiance, gestion des erreurs, accessibilité, et compréhension du problème de bout en bout.

## Méthode de travail imposée

- **Une étape à la fois.** Un livrable est rédigé, présenté, amendé puis validé avant d'entamer le suivant. Aucun livrable n'anticipe sur une décision non encore validée.
- **Questionner avant de construire.** Devant plusieurs implémentations valables, poser la question à l'utilisateur avec les options et une recommandation argumentée, plutôt que de choisir seul. Demander coûte moins cher que construire.
- **Contester la demande quand elle importe de la complexité.** « Avez-vous vraiment besoin de X, ou Y le couvre-t-il déjà ? » vaut pour les spécifications comme pour le code.
- **Honnêteté sur l'état réel.** Rapporter ce qui est fait, testé et vérifié. Ne jamais présenter un échafaudage comme une solution.

## Langue

Toute communication et toute documentation sont en français. Seuls le code, les identifiants et les messages de commit sont en anglais.