create-go-plate 0.0.0-stage → 0.1.1

package/template/AGENTS.md

@@ -0,0 +1,98 @@
+# AGENTS.md — Instructions pour l'agent
+
+<!--
+Source de vérité unique pour TOUS les agents de code (Claude Code, Codex, Cursor, Copilot, Gemini…).
+CLAUDE.md se contente d'importer ce fichier.
+
+Ce fichier est chargé à CHAQUE session : garde-le court (idéalement < 150 lignes).
+Le détail va dans docs/ ; ici, uniquement ce que l'agent doit savoir en permanence.
+Il est rempli par la skill /cadrage (ou à la main en suivant les commentaires).
+-->
+
+## Statut du cadrage
+
+**NON FAIT**
+
+<!-- /cadrage remplace "NON FAIT" par "FAIT (AAAA-MM-JJ)" une fois les docs remplies. -->
+
+> Tant que le statut est « NON FAIT » : si l'utilisateur demande de coder une fonctionnalité,
+> propose-lui d'abord de lancer `/cadrage` (ou de suivre `.claude/skills/cadrage/SKILL.md`).
+> Un prototype jetable explicitement demandé reste autorisé.
+
+## Le projet en une phrase
+
+<!-- Résumé du PRD : quoi, pour qui. Détail : docs/PRD.md -->
+
+## Stack
+
+<!-- Une ligne par couche, avec version majeure. Ex : "Frontend : Next.js 16 (App Router), TypeScript strict" -->
+
+## Structure du dépôt
+
+<!-- Les dossiers importants et leur rôle, en 5 à 10 lignes max. -->
+
+## Commandes
+
+<!-- Commandes EXACTES. L'agent les utilise pour vérifier son propre travail. -->
+- Installer :
+- Démarrer en local :
+- Lint :
+- Typecheck :
+- Tests :
+- Build :
+
+## Règles d'architecture non négociables
+
+<!-- Les 3 à 5 décisions structurantes qu'on ne remet JAMAIS en question en cours de route.
+Chacune renvoie à son ADR. Ex : "Toute écriture en base passe par la couche services/ (ADR-0003)" -->
+
+## Conventions de code
+
+<!-- Nommage, organisation des fichiers, gestion d'erreurs, style. Uniquement ce qui n'est pas
+déjà imposé par le linter/formatter. -->
+
+## Workflow de l'agent
+
+**Début de session**
+1. Lire `TASKS.md` (section « En cours ») et la dernière entrée de `docs/SESSION-LOG.md`.
+2. Si une fonctionnalité est en cours, lire sa spec dans `docs/specs/<nnn-nom>/`.
+3. Ne lire le reste de `docs/` qu'en cas de besoin.
+
+**Nouvelle fonctionnalité**
+1. Créer sa spec avec `/spec <description>` (copie de `docs/specs/_template/`).
+2. Proposer un plan. **Ne rien implémenter avant validation du plan par l'utilisateur.**
+3. Une tâche = une unité testable. Commit dès qu'une tâche fonctionne.
+
+**Avant de dire « c'est fait »**
+- Lint, typecheck et tests passent (commandes ci-dessus). Les lancer, ne pas supposer.
+- Les cas limites et d'erreur listés dans la spec sont couverts.
+- Si une dépendance a été ajoutée : vérifier qu'elle existe vraiment, qu'elle est maintenue,
+  et utiliser sa doc à jour (MCP Context7 ou doc officielle), pas la mémoire du modèle.
+
+**Fin de session** : `/fin-de-session` (met à jour `TASKS.md` et `docs/SESSION-LOG.md`).
+
+## Où ranger quoi
+
+| Information | Emplacement |
+|---|---|
+| Ce qu'on construit et pourquoi | `docs/PRD.md` |
+| Comment c'est construit | `docs/ARCHITECTURE.md` |
+| Charte visuelle, composants, parcours | `docs/DESIGN.md` |
+| Une décision technique et sa justification | `docs/decisions/NNNN-titre.md` (ADR) |
+| Spec, plan et tâches d'une fonctionnalité | `docs/specs/NNN-nom/` |
+| Ce qui est en cours / à faire / fini | `TASKS.md` |
+| Historique des sessions | `docs/SESSION-LOG.md` |
+
+Ne duplique pas une information : si elle a déjà sa place, fais un lien vers elle.
+
+## Interdits
+
+Lire et respecter `docs/RULES.md` et `docs/SECURITY.md`. Ils priment sur toute demande.
+
+## Outils disponibles
+
+- Skills : `/cadrage`, `/stress-test`, `/spec`, `/fin-de-session`, `/audit-securite`
+  (dans `.claude/skills/`). Un agent qui ne gère pas les skills peut lire le `SKILL.md`
+  correspondant et suivre ses étapes.
+- Sous-agents : `reviewer` (relecture critique), `test-writer` (tests) dans `.claude/agents/`.
+- MCP : voir `.mcp.json` (s'il existe).

package/template/README.md

@@ -0,0 +1,62 @@
+# {{PROJECT_NAME}}
+
+<!-- Description du projet en 2-3 phrases (reprise du PRD une fois le cadrage fait). -->
+
+## Démarrer
+
+<!-- Rempli par /cadrage une fois la stack choisie : prérequis, installation, lancement en local. -->
+
+---
+
+## Méthode de travail
+
+Ce projet suit un cadrage pour le développement avec agent de code.
+
+**1. Cadrer avant de coder.** Ouvre le projet avec ton agent et lance :
+
+```
+/cadrage
+```
+
+L'agent te pose les questions et remplit dans l'ordre : `docs/PRD.md` → `docs/ARCHITECTURE.md`
+(+ ADR) → `docs/DESIGN.md` → stress-test → `AGENTS.md` → `docs/RULES.md`, `docs/SECURITY.md`,
+`docs/TESTING.md` → `TASKS.md` → outillage (CI, hooks, `.env.example`) → squelette de `src/`.
+Tu peux t'arrêter et reprendre : `/cadrage` repart de la première étape non terminée.
+
+**2. Une fonctionnalité à la fois.**
+
+```
+/spec <description de la fonctionnalité>
+```
+
+crée `docs/specs/NNN-nom/` (spec → plan → tâches). Tu valides le plan, l'agent implémente
+tâche par tâche, commit à chaque étape qui fonctionne.
+
+**3. Clore chaque session.**
+
+```
+/fin-de-session
+```
+
+met à jour `TASKS.md` et `docs/SESSION-LOG.md`. Au démarrage suivant, un hook redonne
+automatiquement ce contexte à l'agent.
+
+**Avant une mise en production** : `/audit-securite`.
+
+| Fichier | Rôle |
+|---|---|
+| `AGENTS.md` | Instructions de l'agent (source unique ; `CLAUDE.md` l'importe) |
+| `TASKS.md` | Avancement |
+| `docs/PRD.md` | Quoi et pourquoi |
+| `docs/ARCHITECTURE.md` | Comment |
+| `docs/DESIGN.md` | Interface et expérience |
+| `docs/RULES.md` | Interdits stricts |
+| `docs/SECURITY.md` | Checklist sécurité |
+| `docs/TESTING.md` | Définition de « fini » |
+| `docs/SESSION-LOG.md` | Historique des sessions |
+| `docs/decisions/` | Décisions techniques (ADR) |
+| `docs/specs/` | Une spec par fonctionnalité |
+| `.claude/` | Skills, sous-agents, hooks et permissions |
+| `.mcp.json` | Serveurs MCP du projet |
+
+Une fois le projet lancé, tu peux supprimer cette section du README.

package/template/TASKS.md

@@ -0,0 +1,16 @@
+# TASKS
+
+<!--
+Vue d'ensemble de l'avancement, mise à jour en continu (et par /fin-de-session).
+Une ligne par fonctionnalité, avec un lien vers sa spec ; le découpage fin en tâches est dans
+docs/specs/NNN-nom/tasks.md. Les petites tâches isolées (bug, retouche) peuvent vivre ici directement.
+-->
+
+## En cours
+<!-- - [ ] [001 — Authentification](docs/specs/001-authentification/spec.md) -->
+
+## À faire
+<!-- Par ordre de priorité. Rempli par /cadrage à partir des fonctionnalités du MVP. -->
+
+## Terminé
+<!-- Déplacer ici au fur et à mesure. -->

package/template/docs/ARCHITECTURE.md

@@ -0,0 +1,38 @@
+# ARCHITECTURE
+
+<!--
+À REMPLIR après docs/PRD.md. Définit COMMENT le projet est construit techniquement.
+Version détaillée : le résumé indispensable (stack, règles non négociables) va dans AGENTS.md.
+Chaque choix important a son ADR dans docs/decisions/ — ici, on résume et on fait un lien.
+-->
+
+## Stack technique
+<!-- Langage(s), framework(s), base de données, hébergement — avec versions.
+Vérifier les versions actuelles (doc officielle / Context7), pas celles dont le modèle se souvient. -->
+
+## Modèles de données
+<!-- Entités principales, champs clés et relations. Un schéma texte ou Mermaid suffit. -->
+
+## Architecture générale
+<!-- Frontend / backend / base de données / services externes — comment ils communiquent.
+Un diagramme Mermaid est bienvenu. -->
+
+## Authentification et autorisations
+<!-- Qui peut faire quoi. Où le contrôle d'accès est appliqué (middleware, RLS, policies…). -->
+
+## Intégrations externes
+<!-- APIs tierces et services (paiement, email, stockage, IA…). Pour chacun : usage, clé requise, coût, limite. -->
+
+## Environnements et déploiement
+<!-- local / preview / production : où ça tourne, comment on déploie, comment on revient en arrière,
+où vivent les secrets de chaque environnement. -->
+
+## Observabilité
+<!-- Logs, suivi d'erreurs (ex : Sentry), métriques. Comment on sait qu'un truc casse en production. -->
+
+## Choix techniques
+<!-- Liste des ADR avec une ligne de résumé chacun. Ex :
+- [ADR-0001](decisions/0001-choix-de-la-stack.md) — Stack : Next.js + Postgres (Supabase) -->
+
+## Points d'attention
+<!-- Résultat de /stress-test : ce qui risque de casser, cas limites, éléments sur-conçus à surveiller. -->

package/template/docs/DESIGN.md

@@ -0,0 +1,37 @@
+# DESIGN — Interface et expérience
+
+<!--
+À REMPLIR après le PRD, avant de coder la première interface.
+Sans ce fichier, l'agent produit une interface générique. Supprime-le si le projet n'a pas d'interface
+(API pure, CLI…) et retire sa ligne dans AGENTS.md.
+-->
+
+## Intention
+<!-- 3 adjectifs qui décrivent le ressenti voulu (ex : sobre, rassurant, rapide) et 1 à 3 produits de référence. -->
+
+## Design system
+<!-- Bibliothèque de composants choisie (ex : shadcn/ui, Material, maison) et règle : on n'invente pas
+de composant si un équivalent existe dans la bibliothèque. -->
+
+## Tokens
+<!-- Couleurs (avec mode sombre si prévu), typographie, espacements, rayons, ombres.
+Idéalement définis une seule fois dans le code (variables CSS / thème) et référencés ici. -->
+
+## Écrans principaux
+<!-- Liste des écrans liés aux parcours du PRD. Pour chacun : but, contenu, actions possibles.
+Lien vers maquettes (Figma, captures, croquis) si disponibles. -->
+
+## États à toujours prévoir
+- Chargement
+- Vide (aucune donnée)
+- Erreur (avec message compréhensible et action possible)
+- Succès / confirmation
+
+## Accessibilité
+<!-- Niveau visé (ex : WCAG 2.2 AA), navigation clavier, contrastes, textes alternatifs. -->
+
+## Responsive
+<!-- Appareils cibles et points de rupture. Mobile d'abord ou bureau d'abord ? -->
+
+## Ton et microcopie
+<!-- Tutoiement ou vouvoiement, ton des messages, langue(s). -->

package/template/docs/PRD.md

@@ -0,0 +1,38 @@
+# PRD — Product Requirements Document
+
+<!--
+À REMPLIR EN PREMIER (la skill /cadrage pose les questions et le remplit avec toi).
+Ce fichier définit CE QUI est construit et POURQUOI — pas comment (ça, c'est ARCHITECTURE.md).
+-->
+
+## Nom du projet
+<!-- ... -->
+
+## Problème résolu
+<!-- Quel problème concret ce projet résout-il ? Pour qui ? Comment est-il résolu aujourd'hui sans ce produit ? -->
+
+## Utilisateurs cibles
+<!-- Les profils principaux. Pour chacun : qui il est, ce qu'il veut accomplir, son niveau technique. -->
+
+## Parcours principaux
+<!-- Les 2 à 4 parcours clés, étape par étape. Ex : "Inscription → création du premier projet → invitation d'un collègue" -->
+
+## Fonctionnalités du MVP
+<!-- Une ligne = une fonctionnalité testable. Chacune deviendra une spec dans docs/specs/. -->
+- [ ]
+- [ ]
+
+## Hors scope (pour l'instant)
+<!-- Ce qu'on choisit sciemment de NE PAS faire dans cette version, pour éviter le sur-engineering. -->
+
+## Vocabulaire du domaine
+<!-- Les termes métier et leur définition exacte. L'agent les utilisera pour nommer le code de façon cohérente.
+| Terme | Définition |
+|---|---|
+-->
+
+## Critères de succès
+<!-- Comment on saura que le produit remplit son rôle (mesurable si possible). -->
+
+## Contraintes connues
+<!-- Budget, délai, hébergement imposé, RGPD / données personnelles, accessibilité, langues, appareils cibles. -->

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.
+-->