Pipeline (39 steps)

Le pipeline ATOOX est une séquence orchestrée de 39 steps qui transforme une intention en code production-ready.

Vue d'ensemble

┌─────────────────────────────────────────────────────────────────┐
│                      PIPELINE ATOOX                              │
├─────────────────────────────────────────────────────────────────┤
│  PHASE 0: PRÉPARATION (00c → 00b)                               │
│  ────────────────────────────────────────────────────────────── │
│  00c-centuple → 00-clarify → 00-init → 00b-context              │
├─────────────────────────────────────────────────────────────────┤
│  PHASE 1: CORE (01 → 09)                                        │
│  ────────────────────────────────────────────────────────────── │
│  01-analyze → 02-plan → 03-execute → 04-validate                │
│  05-examine → 06-resolve → 07-tests → 08-run-tests → 09-finish  │
├─────────────────────────────────────────────────────────────────┤
│  PHASE 2: AUDITS (10 → 22)                                      │
│  ────────────────────────────────────────────────────────────── │
│  10-security → 11-ui → 12-perf → 13-docs → 14-ideas → 15-learn  │
│  16-api → 17-migrate → 18-monitoring → 19-i18n → 20-deps        │
│  21-seo → 22-cicd                                                │
├─────────────────────────────────────────────────────────────────┤
│  PHASE 3: AVANCÉ (23 → 39)                                      │
│  ────────────────────────────────────────────────────────────── │
│  23-compliance → 24-iac → 25-ai → 26-copywriting → 27-launch    │
│  28-user-docs → 29-community → 30-analytics → 31-legal          │
│  32-green → 33-psychology → 34-ethics → 35-biases               │
│  36-geopolitics → 37-augmentation → 38-metrics → 39-gaps        │
└─────────────────────────────────────────────────────────────────┘

Phase 0 : Préparation

Step 00c — Centupling Engine

Expert : Prompt Analyst

Action : Analyse cognitive et sélection du framework optimal.

┌─────────────────────────────────────────────────────────────┐
│  CENTUPLING ENGINE                                          │
├─────────────────────────────────────────────────────────────┤
│  1. DIAGNOSTIQUER la complexité                             │
│     ├── Simple   → RTF + Zero-Shot-CoT                     │
│     ├── Medium   → CRAFT + Chain of Thought                │
│     ├── Complex  → RCTFTC + Tree of Thoughts               │
│     └── Expert   → Mega-Prompt + ReAct/Reflexion           │
│                                                             │
│  2. ASSEMBLER l'équipe adaptative selon le scope            │
│     ├── Micro-tâche (1 domaine)   → 1-2 experts (LEAD)    │
│     ├── Feature (1-3 domaines)    → 2-4 experts (LEAD+SUP)│
│     ├── Module (3-5 domaines)     → 4-6 experts (multi-L) │
│     └── Projet (5+ domaines)      → TOUS (phasé)          │
│                                                             │
│  3. ACTIVER le système de récompense interne                │
│                                                             │
│  4. REFACTORER selon le template du framework               │
└─────────────────────────────────────────────────────────────┘

Step 00 — Clarify

Action : Transformer la description floue en Feature Spec précise.

Input : « ajouter validation email » Output :

Feature: Email Validation
Description: Valider le format email dans le formulaire d'inscription
Acceptance Criteria:
  - Format RFC 5322 validé
  - Message d'erreur clair
  - Validation temps réel (onBlur)
  - Tests unitaires
Scope: src/components/SignupForm.tsx
Out of Scope: Vérification SMTP, blacklist domaines

Step 00-init

Action : Créer la branche feature, vérifier working tree clean.

git checkout -b feature/email-validation

Step 00b — Context

Action : Détecter stack, framework, conventions du projet.

Output : Context Map

Stack:
  Language: TypeScript 5.3
  Framework: Next.js 14 (App Router)
  UI: Tailwind CSS + shadcn/ui
  Testing: Vitest + React Testing Library
  Linting: ESLint + Prettier

Conventions:
  Naming: camelCase (files), PascalCase (components)
  Imports: Absolute (@/)
  Commits: Conventional Commits

Patterns Détectés:
  - Composants fonctionnels avec hooks
  - Validation avec Zod
  - Form handling avec react-hook-form

Phase 1 : Core

Step 01 — Analyze

Expert : Martin Fowler

Action : Analyser l'architecture, patterns existants, dette technique.

Output :

Fichiers à modifier
Dépendances impactées
Risques identifiés
Patterns à respecter

Step 02 — Plan

Expert : Robert C. Martin

Action : Créer un plan d'implémentation SOLID.

Plan:
  1. Créer le schéma de validation Zod
     File: src/lib/validations/email.ts

  2. Ajouter le hook useEmailValidation
     File: src/hooks/useEmailValidation.ts

  3. Intégrer dans SignupForm
     File: src/components/SignupForm.tsx

  4. Ajouter les tests
     File: src/hooks/useEmailValidation.test.ts

Approbation : En mode interactif, demande confirmation avant de continuer.

Step 03 — Execute

Experts : Martin + Osmani

Action : Écrire le code (Clean Code, Guard Clauses, expressif).

Principes appliqués :

Fonctions courtes et focalisées
Nommage expressif
Early returns (Guard Clauses)
Pas de commentaires inutiles
DRY mais pas prématurément

Step 04 — Validate

Action : Lint + typage + complexité cyclomatique.

npm run lint        # 0 errors, 0 warnings
npm run typecheck   # OK

Métriques :

Complexité cyclomatique < 10
Lignes par fonction < 30
Couverture de types : 100%

Step 05 — Examine

Experts : Kent Beck + Fowler

Action : Revue critique avec Devil's Advocate.

Checklist des 18 code smells :

[ ] Long Method
[ ] Large Class
[ ] Primitive Obsession
[ ] Long Parameter List
[ ] Data Clumps
[ ] Switch Statements
[ ] Parallel Inheritance
[ ] Lazy Class
[ ] Speculative Generality
[ ] Temporary Field
[ ] Message Chains
[ ] Middle Man
[ ] Inappropriate Intimacy
[ ] Alternative Classes
[ ] Incomplete Library
[ ] Data Class
[ ] Refused Bequest
[ ] Comments (explaining bad code)

Step 06 — Resolve

Expert : Fowler

Action : Corriger chaque problème identifié par sévérité.

Ordre : Critical → High → Medium → Low

Step 07 — Tests

Expert : Kent Beck

Action : Écrire les tests (happy path + edge cases + régression).

describe('useEmailValidation', () => {
  // Happy path
  it('should validate correct email format', () => {
    expect(validateEmail('user@example.com')).toBe(true);
  });

  // Edge cases
  it('should reject email without @', () => {
    expect(validateEmail('userexample.com')).toBe(false);
  });

  it('should reject email with spaces', () => {
    expect(validateEmail('user @example.com')).toBe(false);
  });

  // Regression
  it('should handle international domains', () => {
    expect(validateEmail('user@example.co.uk')).toBe(true);
  });
});

Step 08 — Run Tests

Action : Exécuter les tests, corriger si échec (max 3 cycles).

npm test
# ✓ 12 tests passed
# Coverage: 94%

Règle : 0 régression tolérée.

Step 09 — Finish

Action : Commit conventionnel + push + PR.

git add -A
git commit -m "feat(auth): add email validation with Zod schema

- Add RFC 5322 compliant email validation
- Integrate with SignupForm component
- Add real-time validation on blur
- Include comprehensive test coverage

Closes #123"

git push -u origin feature/email-validation
gh pr create --title "feat(auth): add email validation"

Phase 2 : Audits

Step 10 — Security

Expert : Troy Hunt

Audit OWASP Top 10 :

[ ] Injection
[ ] Broken Authentication
[ ] Sensitive Data Exposure
[ ] XML External Entities
[ ] Broken Access Control
[ ] Security Misconfiguration
[ ] XSS
[ ] Insecure Deserialization
[ ] Vulnerable Components
[ ] Insufficient Logging

Step 11 — UI

Expert : Vitaly Friedman

Vérifications :

Accessibilité WCAG 2.1 AA
Design responsive
États UI (loading, error, success, empty)
Navigation clavier

Step 12 — Perf

Expert : Addy Osmani

Métriques :

Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1)
Bundle size
Requêtes N+1
Lazy loading

Step 13 — Docs

Expert : Daniele Procida

Génération :

JSDoc / TSDoc pour les fonctions publiques
README mis à jour
CHANGELOG entry

Step 14 — Ideas

Panel de 7 experts : Graham, Rams, Schneier, Cagan, Karpathy, Lara, Godin

Output : 3 suggestions innovantes pour améliorer la feature.

Step 15 — Learn

Expert : Santayana

Rapport d'apprentissage :

Patterns utilisés
Décisions clés
Erreurs évitées
Conseils futurs

Steps 16-22 : Audits Spécialisés

Step	Expert	Domaine
16-api	Roy Fielding	REST conventions
17-migrate	Martin Kleppmann	Database migrations
18-monitoring	Charity Majors	Observability
19-i18n	W3C I18N	Internationalization
20-deps	Russ Cox	Dependencies audit
21-seo	Danny Sullivan	SEO
22-cicd	Jez Humble	CI/CD pipeline

Phase 3 : Avancé

Steps 23-39 : Audits Étendus

Step	Domaine
23-compliance	RGPD, SOC2, HIPAA
24-iac	Infrastructure as Code
25-ai	Intégration ML/AI
26-copywriting	Messaging, CTAs
27-launch	Checklist pré-lancement
28-user-docs	Documentation utilisateur
29-community	Stratégie communauté
30-analytics	Tracking, événements
31-legal	Aspects juridiques
32-green	Éco-conception
33-psychology	Biais cognitifs
34-ethics	IA responsable
35-biases	Détection biais
36-geopolitics	Conformité internationale
37-augmentation	Collaboration humain-IA
38-metrics	KPIs, North Star
39-gaps	Analyse des lacunes

Activation des Steps

Mode	Steps Activés
`--full`	Tous (00c → 39)
`--auto`	Core (00c → 09) + 10 + 11 + 12
`--economy`	Core minimal (00 → 04, 09)
`--tdd`	Core avec 07 avant 03

Flags Individuels

--review      # 05-06
--tests       # 07-08
--security    # 10
--ui          # 11
--perf        # 12
--docs        # 13
--ideas       # 14
--learn       # 15
--api         # 16
--migrate     # 17
--monitoring  # 18
--i18n        # 19
--deps        # 20
--seo         # 21
--cicd        # 22

Context Checkpoints

Pour optimiser le contexte LLM sur les pipelines longs, des résumés sont générés automatiquement :

Après Step	Checkpoint
04-validate	Context Checkpoint #1
08-run-tests	Context Checkpoint #2
13-docs	Context Checkpoint #3

Rapport Final

╔═══════════════════════════════════════════════════════════════════╗
║  ◆ ATOOX — PIPELINE TERMINÉ                                      ║
╠═══════════════════════════════════════════════════════════════════╣
║  Feature    : Email Validation                                    ║
║  Branche    : feature/email-validation                           ║
║  Mode       : --full                                              ║
╠═══════════════════════════════════════════════════════════════════╣
║  Code       : ✅ 3 fichiers modifiés, 2 créés                    ║
║  Validation : ✅ lint + types OK                                 ║
║  Tests      : ✅ 12/12 passés (94% coverage)                     ║
║  Sécurité   : ✅ OK                                              ║
║  UI/UX      : ✅ OK                                              ║
║  Perf       : ✅ OK                                              ║
║  Docs       : ✅ générée                                         ║
╠═══════════════════════════════════════════════════════════════════╣
║  Commit     : abc1234 feat(auth): add email validation           ║
║  PR         : https://github.com/org/repo/pull/456               ║
╚═══════════════════════════════════════════════════════════════════╝

Prochaines étapes

Première feature — Tutoriel guidé
Configuration — Personnaliser le pipeline