create-go-plate 0.0.0-stage → 0.1.0

package/template/docs/RULES.md

@@ -0,0 +1,31 @@
+# RULES — Interdits stricts
+
+<!--
+Ce ne sont PAS des préférences de style (ça va dans AGENTS.md) : ce sont des interdits que l'agent
+ne doit JAMAIS enfreindre, quelle que soit la demande. Les règles déjà imposées techniquement
+(permissions et hooks dans .claude/settings.json) sont marquées [bloqué].
+Complète avec les règles propres au projet pendant /cadrage.
+-->
+
+## Code et dépendances
+- Ne jamais ajouter une dépendance sans vérifier qu'elle existe, qu'elle est maintenue et qu'elle est
+  bien celle attendue (nom exact : attention aux paquets aux noms proches).
+- Ne jamais désactiver un test, une règle de lint ou une vérification de type pour « faire passer ».
+- Ne jamais laisser de code mort, de `console.log` de debug ou de TODO sans entrée dans `TASKS.md`.
+
+## Secrets
+- Jamais de secret, clé ou mot de passe en dur dans le code, les tests ou les docs.
+- Ne jamais lire ni modifier les fichiers `.env` réels. [bloqué]
+- Toute nouvelle variable d'environnement est ajoutée (sans valeur) à `.env.example`.
+
+## Données
+- Ne jamais exécuter de migration destructive (suppression de table, de colonne, de données)
+  sans confirmation explicite de l'utilisateur.
+- Ne jamais se connecter à la base de production depuis l'environnement de développement.
+
+## Git
+- Ne jamais réécrire l'historique partagé (`push --force`, `reset --hard` sur une branche poussée). [bloqué]
+- Ne jamais committer directement sur la branche principale une fois le projet en production.
+
+## Spécifiques au projet
+<!-- Ex : "Toute requête à la base passe par le contrôle d'accès défini dans ARCHITECTURE.md" -->

package/template/docs/SECURITY.md

@@ -0,0 +1,43 @@
+# SECURITY — Sécurité de l'application
+
+<!--
+Les applications vibecodées tombent souvent dans les mêmes pièges. Ce fichier liste les points à
+vérifier ; /audit-securite les passe en revue. Coche ce qui est en place, adapte à la stack choisie,
+supprime ce qui ne s'applique pas (en notant pourquoi).
+-->
+
+## Secrets et configuration
+- [ ] Aucun secret dans le code ni dans l'historique git (scan : gitleaks ou équivalent).
+- [ ] Aucun secret exposé au navigateur (variables `NEXT_PUBLIC_*`, `VITE_*`… ne contiennent que du public).
+- [ ] Clés différentes entre développement et production.
+
+## Authentification et accès
+- [ ] Le contrôle d'accès est appliqué côté serveur, jamais seulement dans l'interface.
+- [ ] Chaque requête vérifie que l'utilisateur a le droit d'accéder à CETTE ressource (pas seulement qu'il est connecté).
+- [ ] Si la base est accessible depuis le client (Supabase, Firebase…) : règles RLS / security rules activées sur toutes les tables.
+- [ ] Sessions / jetons : expiration, révocation, cookies `HttpOnly` + `Secure` + `SameSite`.
+
+## Entrées et sorties
+- [ ] Toutes les entrées sont validées côté serveur (schéma : Zod, Pydantic…).
+- [ ] Requêtes paramétrées / ORM, jamais de concaténation SQL.
+- [ ] Pas de HTML non échappé (XSS).
+- [ ] Upload de fichiers : type, taille et emplacement contrôlés.
+
+## Abus
+- [ ] Limitation de débit (rate limiting) sur l'authentification, les formulaires publics et les endpoints coûteux.
+- [ ] Protection CSRF si l'authentification passe par cookies.
+- [ ] Les messages d'erreur ne révèlent pas d'information interne.
+
+## Dépendances
+- [ ] Audit des dépendances dans la CI (`npm audit`, `pip-audit`…).
+- [ ] Mises à jour de sécurité automatisées (Dependabot / Renovate).
+- [ ] Fichier de lock commité.
+
+## Fonctionnalités IA (si applicable)
+- [ ] Le contenu fourni par l'utilisateur ou par des sources externes n'est jamais traité comme des instructions (injection de prompt).
+- [ ] Le modèle n'a accès qu'aux outils et données strictement nécessaires.
+- [ ] Coût maîtrisé : limites par utilisateur et alertes de dépense.
+
+## Données personnelles
+- [ ] Données collectées limitées au nécessaire, durée de conservation définie (RGPD).
+- [ ] Suppression de compte et export des données possibles si requis.

package/template/docs/SESSION-LOG.md

@@ -0,0 +1,15 @@
+# SESSION-LOG
+
+<!--
+Une entrée par session de travail, la plus récente EN HAUT. Rempli par /fin-de-session.
+Objectif : que la session suivante reparte avec le contexte, sans deviner.
+Reste bref : les décisions vont dans un ADR (docs/decisions/), on se contente d'y faire un lien.
+
+Format :
+
+### AAAA-MM-JJ — titre court
+- Fait :
+- Pièges rencontrés :
+- Décisions : (liens vers les ADR)
+- Prochaine étape :
+-->

package/template/docs/TESTING.md

@@ -0,0 +1,34 @@
+# TESTING — Stratégie de validation
+
+<!--
+À REMPLIR avant de développer les fonctionnalités.
+Répond à une question : comment sait-on qu'une fonctionnalité est « faite » ?
+Plus les vérifications sont automatiques, plus l'agent peut se corriger seul.
+-->
+
+## Boucle de retour automatique
+<!-- Ce que l'agent lance lui-même après chaque modification. Les commandes exactes sont dans AGENTS.md. -->
+- Formatage automatique : hook `PostToolUse` de Claude Code (`.claude/hooks/format.mjs`), ou formatage à l'enregistrement dans l'éditeur
+- Lint :
+- Typecheck :
+- Tests unitaires :
+- Tests end-to-end : <!-- ex : Playwright ; l'agent peut aussi piloter le navigateur via le MCP Playwright -->
+
+## Intégration continue
+<!-- Ce que la CI (.github/workflows/ci.yml) vérifie à chaque push / pull request. Aucun merge si elle échoue. -->
+
+## Ce qui doit être testé pour chaque fonctionnalité
+- Cas nominal
+- Cas limites (vide, très long, caractères spéciaux, doublons, concurrence)
+- Cas d'erreur (réseau, permissions, données invalides)
+<!-- Les cas précis de chaque fonctionnalité sont listés dans sa spec (docs/specs/NNN-nom/spec.md). -->
+
+## Fonctionnalités critiques : test écrit AVANT le code
+<!-- Les parties où l'exactitude est critique (paiement, auth, droits d'accès, calculs). Pour elles,
+l'agent écrit d'abord le test (sous-agent test-writer), vérifie qu'il échoue, puis implémente. -->
+
+## Checklist manuelle avant un commit important
+- [ ] Parcours complet testé, pas seulement le chemin heureux
+- [ ] Entrées invalides / vides
+- [ ] Mobile (si applicable)
+- [ ] Mode sombre / accessibilité clavier (si applicable)

package/template/docs/decisions/0000-template.md

@@ -0,0 +1,16 @@
+# NNNN — Titre de la décision
+
+- **Statut** : Proposé | Accepté | Remplacé par NNNN
+- **Date** : AAAA-MM-JJ
+
+## Contexte
+<!-- Le problème à résoudre et les contraintes. -->
+
+## Options envisagées
+<!-- 2 ou 3 options, avec avantages et inconvénients. -->
+
+## Décision
+<!-- L'option retenue, en une phrase. -->
+
+## Conséquences
+<!-- Ce que ça implique, y compris les inconvénients acceptés. -->

package/template/docs/decisions/README.md

@@ -0,0 +1,8 @@
+# Décisions techniques (ADR)
+
+Une décision structurante = un fichier `NNNN-titre-court.md`, copié depuis `0000-template.md`.
+Un ADR n'est jamais modifié après acceptation : si la décision change, on en écrit un nouveau
+qui « remplace » l'ancien, et on passe l'ancien au statut « Remplacé par NNNN ».
+
+Pourquoi : l'agent (et toi dans 6 mois) sait pourquoi les choses sont ainsi, et ne remet pas
+une décision en cause sans raison nouvelle.

package/template/docs/specs/README.md

@@ -0,0 +1,12 @@
+# Specs
+
+Un dossier par fonctionnalité : `NNN-nom-court/` (ex : `001-authentification/`), créé par `/spec`
+à partir de `_template/`.
+
+| Fichier | Contenu | Validé par l'utilisateur avant… |
+|---|---|---|
+| `spec.md` | Le QUOI : comportement attendu, critères d'acceptation | le plan |
+| `plan.md` | Le COMMENT : fichiers, données, API, dépendances | le découpage |
+| `tasks.md` | Les tâches ordonnées, cochées au fil de l'eau | le code |
+
+Une spec terminée reste dans le dépôt : elle documente pourquoi le code est comme il est.

package/template/docs/specs/_template/plan.md

@@ -0,0 +1,27 @@
+# NNN — Plan technique
+
+<!-- Le COMMENT. Validé par l'utilisateur avant de découper en tâches. -->
+
+## Approche
+<!-- En quelques phrases, et pourquoi celle-ci plutôt qu'une autre. -->
+
+## Fichiers touchés
+<!-- Créés / modifiés / supprimés, avec leur rôle. -->
+
+## Données
+<!-- Modifications du schéma, migrations (destructives ? → confirmation obligatoire). -->
+
+## API / interfaces
+<!-- Routes, actions serveur, événements, composants exposés. -->
+
+## Dépendances
+<!-- Nouvelle bibliothèque ? Nom exact, version, pourquoi, vérifiée (existe, maintenue, doc à jour). -->
+
+## Sécurité
+<!-- Contrôle d'accès, validation, données sensibles — points de docs/SECURITY.md concernés. -->
+
+## Tests
+<!-- Ce qui sera testé et comment. Parties critiques en TDD ? -->
+
+## Risques
+<!-- Résultat éventuel de /stress-test. -->

package/template/docs/specs/_template/spec.md

@@ -0,0 +1,23 @@
+# NNN — Nom de la fonctionnalité
+
+<!-- Le QUOI, pas le COMMENT. Lisible par quelqu'un qui ne code pas. -->
+
+## Objectif
+<!-- Quel besoin du PRD cette fonctionnalité couvre, pour quel utilisateur. -->
+
+## Comportement attendu
+<!-- Parcours pas à pas du point de vue de l'utilisateur. -->
+
+## Critères d'acceptation
+<!-- Chacun doit être vérifiable par un test. Format conseillé : Étant donné… quand… alors… -->
+- [ ]
+- [ ]
+
+## Cas limites et erreurs
+<!-- Vide, invalide, doublon, droits insuffisants, réseau coupé, concurrence… et le comportement attendu pour chacun. -->
+
+## Hors périmètre
+<!-- Ce que cette fonctionnalité ne fait volontairement pas. -->
+
+## Questions ouvertes
+<!-- À trancher avant le plan. Vide = prêt pour le plan. -->

package/template/docs/specs/_template/tasks.md

@@ -0,0 +1,8 @@
+# NNN — Tâches
+
+<!-- Ordonnées. Chaque tâche est petite, testable et committable seule. Cochée dès qu'elle est faite et commitée. -->
+
+- [ ] 1.
+- [ ] 2.
+- [ ] Vérifier tous les critères d'acceptation de spec.md
+- [ ] Relecture par le sous-agent reviewer

package/template/gitignore

@@ -0,0 +1,30 @@
+# Dépendances et builds
+node_modules/
+dist/
+build/
+.next/
+out/
+coverage/
+__pycache__/
+*.pyc
+.venv/
+
+# Secrets — garder uniquement .env.example
+.env
+.env.*
+!.env.example
+*.pem
+*.key
+
+# Claude Code (réglages personnels)
+.claude/settings.local.json
+
+# Éditeurs et système
+.idea/
+.vscode/*
+!.vscode/extensions.json
+.DS_Store
+Thumbs.db
+
+# Logs
+*.log

package/template/src/README.md

@@ -0,0 +1,9 @@
+# src/
+
+<!--
+Vide au démarrage. La dernière étape de /cadrage y crée la structure de dossiers et de fichiers
+quasi vides correspondant à docs/ARCHITECTURE.md : l'objectif est de poser le périmètre, pas
+d'implémenter. Selon la stack, le code peut vivre ailleurs (app/, packages/…) : dans ce cas,
+supprime ce dossier.
+Ce README peut être supprimé une fois la vraie structure en place.
+-->