felipevale23/sddkit

/sdd-stack

Entrée : $ARGUMENTS. Vous menez un entretien sur la stack et n'écrivez des fichiers qu'à la fin, après confirmation de l'utilisateur.

0. Avant de demander : découvrez les faits

Les faits de l'environnement sont votre travail, ne les demandez jamais à l'utilisateur. Regardez (ou déléguez à un sous-agent) :

• les manifestes et le code existant (package.json, pyproject.toml, go.mod, Dockerfile, .github/workflows/, dossiers racine) ;
• .agents/specs/stack.md et architecture.md (s'ils sont déjà remplis et qu'il n'y a pas --revisar, affichez le résumé et ne demandez que ce qui manque) ;
• .specify/memory/constitution.md (contraintes déjà décidées, ex. : RGPD, base de données unique) ;
• sddkit suggest --json (stacks détectées).

Ce qui est déjà décidé dans le code est considéré comme une décision prise, pas comme une question.

1. Méthode

• Skill grilling installé dans .agents/skills/ → suivez sa méthode (tours par la frontière de l'arbre de décision, chaque question avec réponse recommandée, jusqu'à ce que la frontière soit vide).
• Non installé → même format : à chaque tour, toutes les questions dont les pré-conditions sont déjà satisfaites, numérotées, chacune ainsi :

❓ **Q1 — <titre>** : <question, avec 2–4 options et le trade-off de chacune en 1 ligne>

➡️ <votre recommandation et pourquoi, en 1–2 lignes>

Écrivez chaque question de sorte que "oui" accepte la recommandation. Préférez une technologie ennuyeuse et mature, que l'équipe connaît déjà, à l'état de l'art ; un langage pour tout le projet, sauf motif fort ; le minimum de pièces qui couvre le périmètre (chaque service supplémentaire est un coût d'exploitation). Si la réponse contredit une précédente ou la constitution, signalez-le et demandez laquelle prévaut.

2. Arbre de décision de la stack

Parcourez dans cet ordre de dépendance ; sautez les branches qui ne s'appliquent pas (ex. : sans interface utilisateur → pas de questions frontend).

1. Produit : ce que c'est (app web, API, app mobile, desktop, CLI, bibliothèque, worker), qui l'utilise, échelle attendue (utilisateurs, données, pics), contraintes (RGPD, hors ligne, coût, délai).
2. Équipe : langages que l'équipe maîtrise ; qui va maintenir.
3. Forme : monolithe modulaire, monorepo avec packages ou services séparés ; ce qui doit être asynchrone.
4. Langage et runtime (version majeure) : ex. : TypeScript/Node 22, Python 3.12.
5. Frontend (s'il y a une interface utilisateur) : framework (React/Next, Vue/Nuxt, Svelte, Astro…), rendu (SPA, SSR, statique), bibliothèque de composants et style (MUI, shadcn+Tailwind…), état serveur (TanStack Query…), i18n, accessibilité.
6. Mobile/desktop (s'il y a) : natif, React Native/Expo, Flutter, Tauri, Electron.
7. Backend/API : framework (Express, Fastify, NestJS, Hono, FastAPI, Django…), style (REST, GraphQL, tRPC), contrats et validation (Zod, Pydantic, OpenAPI). 7b. Paradigme du backend (uniquement s'il y a un backend ; jamais pour le frontend, qui suit l'idiome du framework) :
   • Style : POO avec SOLID (entités avec invariants, services dépendant d'interfaces), fonctionnel (fonctions pures, données immuables, effets en bordure) ou pragmatique (modules simples, abstraction seulement avec 2+ implémentations — le défaut du ponytail).
   • Architecture : couches simples (controller → service → repository), clean/hexagonale (domaine sans dépendance framework, ports et adaptateurs) ou DDD (contextes bornés, agrégats). Recommandez le plus simple que le domaine peut supporter : clean/DDD seulement avec des règles métier riches.
   • Quels dossiers sont backend (ex. : server/**, services/**, modules/**). C'est cela qui limite le paradigme au backend.
8. Données : base de données (PostgreSQL, MySQL, MongoDB, SQLite), ORM/accès (Prisma, Drizzle, SQLAlchemy…), migrations, cache.
9. Asynchrone : file d'attente/jobs (BullMQ, Celery, pg-boss…), événements, temps réel (WebSocket/SSE).
10. Authentification et autorisation : fournisseur ou propre, sessions/JWT, rôles/permissions.
11. Intégrations externes : paiements (PIX…), e-mail, IA (SDK Anthropic…), MCP.
12. Hébergement et exploitation : où ça tourne (Vercel, VPS avec Docker, cloud managé), environnements, secrets, observabilité (logs, erreurs, métriques).
13. Qualité : tests (unitaire, intégration, e2e avec Playwright), lint/format, typecheck, CI (GitHub Actions), commits (Conventional Commits/commitlint).

3. Confirmation

Une fois la frontière vide, affichez le résumé dans un tableau (couche · choix · version · pourquoi · alternative écartée) et demandez : "On verrouille comme ça ?". N'écrivez rien avant le "oui".

4. Enregistrer

1. .agents/specs/stack.md : remplacez le contenu (y compris le marqueur [PREENCHER) par :
   • ## Par composant — chaque couche avec technologie, version majeure et les bibliothèques principales par nom du package (ex. : react, @prisma/client, bullmq, fastapi) : sddkit utilise ces noms pour suggérer des rôles et compétences ;
   • ## Infrastructure — base de données, file d'attente, cache, hébergement, CI, observabilité ;
   • ## Décisions — chaque choix important avec le pourquoi et l'alternative écartée (date du jour).
2. .agents/specs/architecture.md : remplissez la section ## Vue d'ensemble (composants et comment ils communiquent ; un diagramme mermaid s'il y a plus de 2 pièces) et enlevez le [PREENCHER. S'il y a déjà du code, remplissez aussi ## Plan du code (une ligne par zone : entrée, dossiers clés, tests). Les autres sections restent pour quand il y aura du code.
3. Paradigme du backend (si décidé en 7b et différent de "pragmatique") :
   • .agents/specs/coding-standards.md : section ## Backend — paradigme avec le style, l'architecture, les dossiers backend, 3–5 règles concrètes avec un court exemple chacune, et l'outil qui impose les règles (ci-dessous). Précisez clairement que le frontend ne suit pas cette section.
   • Mémoire de sddkit, pour que l'agent connaisse le périmètre à chaque session :

     sddkit memory add "Paradigme <style>/<architecture> seulement dans le backend (<dossiers>) ; dans le frontend, suivez l'idiome du framework" -t paradigme
     sddkit memory add "Dans le backend, la section 'Backend — paradigme' de coding-standards.md prévaut sur ponytail concernant les interfaces et les couches" -t paradigme
     sddkit memory add "<règle concrète la plus importante>" -t paradigme-backend --paths "<dossiers backend>"
     

   • Compétences (optionnelles dans le catalogue, chargées seulement par les rôles backend api, data, event-module, queue-worker) : POO/SOLID → sddkit add solid ; clean/hexagonale → sddkit add clean-architecture ; DDD → sddkit add domain-driven-design. Fonctionnel : il n'y a pas de bonne compétence générale ; les règles dans coding-standards.md et le lint font le travail.
   • Imposition déterministe (lint restreint aux dossiers backend ; devient la première tâche de setup de /sdd-feature s'il n'y a pas encore de code) :
     • couches/clean/hexagonale/DDD : dependency-cruiser ou eslint-plugin-boundaries (TypeScript), import-linter (Python) — le domaine n'importe pas d'infrastructure ni de framework ;
     • fonctionnel en TypeScript : eslint-plugin-functional dans un bloc ESLint avec files: ["<dossiers backend>"] (pas de classes, pas de mutation, pas de let) ;
     • POO : il n'y a pas de linter qui exige la POO ; utilisez les règles de couches ci-dessus et la revue.
4. Constitution : si des contraintes non négociables sont apparues (ex. : "PostgreSQL est la seule source de vérité"), proposez le texte et suggérez /speckit-constitution — ne modifiez pas la constitution directement.
5. Dites à l'utilisateur d'exécuter dans le terminal :

   sddkit init        # lit la stack déclarée et propose les rôles et compétences correspondants (rien d'existant n'est effacé)
   sddkit doctor
   

Rapport final (≤ 8 lignes)

Stack décidée en 1 ligne par couche · paradigme backend et comment il est imposé · fichiers enregistrés · contraintes suggérées pour la constitution · prochaine étape (sddkit init, puis /sdd-feature).