Déclencheurs
- phase de fondation
- scaffolding
- configuration du projet
- pipeline CI/CD
- configuration de l'infrastructure
- implémentation du système de design
- configuration de la base de données
- scaffold API
- configuration de l'environnement
- configuration du monitoring
- environnement de développement
- scaffolding du projet
- bibliothèque de composants
- système de thème
- pipeline de déploiement
Instructions
La phase 2 construit la fondation technique et opérationnelle sur laquelle tous les travaux subséquents reposent. Mettez le squelette debout avant d'ajouter de la substance. Après cette phase, chaque développeur dispose d'un environnement fonctionnel, d'un pipeline déployable et d'un système de design pour construire. Durée : 3-5 jours.
Pré-conditions
Vérifiez avant de commencer :
- Quality Gate de la phase 1 passée (Architecture Package approuvée)
- Handoff Package de la phase 1 reçu
- Tous les documents d'architecture finalisés
Flux de travail A : Infrastructure (Jour 1-3, Parallèle)
Utilisez organization_spawn ou swarm_spawn pour activer en parallèle :
DevOps Automator — Pipeline CI/CD + Infrastructure :
- Entrée : Architecture système Backend Architect + exigences de déploiement
goal_create: Pipeline CI/CD (scanning de sécurité, tests, build/conteneurisation, déploiement, rollback)goal_create: Infrastructure as Code (provisionnement d'environnement, orchestration de conteneurs, config réseau/sécurité)goal_create: Configuration d'environnement (gestion des secrets, variables d'env, parité multi-environnement)- Fichiers à créer : .github/workflows/ci-cd.yml, templates infrastructure/, docker-compose.yml, Dockerfiles
- Délai : 3 jours.
Infrastructure Maintainer — Infrastructure Cloud + Monitoring :
- Entrée : Infrastructure DevOps Automator + architecture Backend Architect
goal_create: Provisionnement des ressources cloud (calcul, stockage, réseau, auto-scaling, load balancer)goal_create: Stack de monitoring (Prometheus/DataDog, dashboards Grafana)goal_create: Logging et Alerting (logs centralisés, règles d'alerte, notifications on-call)goal_create: Renforcement de la sécurité (règles firewall, SSL/TLS, politiques de contrôle d'accès)- Délai : 3 jours.
Studio Operations — Configuration des processus :
- Entrée : plan Sprint Prioritizer + besoins de coordination
goal_create: Git Workflow (stratégie de branches, processus de révision PR, politiques de merge)goal_create: Canaux de communication (canaux d'équipe, routage des notifications, cadence de statut)goal_create: Templates de documentation (template PR, template issue, log de décisions)goal_create: Outils de collaboration (project board, configuration du suivi de sprint)- Délai : 2 jours.
Flux de travail B : Fondation applicative (Jour 1-4, Parallèle)
Frontend Developer — Scaffolding du projet + Bibliothèque de composants :
- Entrée : Système de design CSS UX Architect + identité Brand Guardian
goal_create: Scaffolding du projet (configuration du framework, TypeScript, build tooling, framework de test)goal_create: Implémentation du système de design (tokens CSS, composants de base, système de thème, utilitaires responsifs)goal_create: Application Shell (routage, composants de layout, error boundary, états de chargement)- Délai : 3 jours.
Backend Architect — Base de données + Fondation API :
- Entrée : Spécification d'architecture système + Conception du schéma de base de données
goal_create: Configuration de la base de données (déploiement du schéma/migrations, indexes, seed data, connection pooling)goal_create: Scaffold API (configuration du framework, structure des routes, stack middleware, health checks)goal_create: Système d'authentification (auth provider, gestion JWT/session, scaffold RBAC)goal_create: Communication entre services (versioning API, sérialisation, standardisation des erreurs)- Délai : 4 jours.
UX Architect — Implémentation du système CSS :
- Entrée : Identité Brand Guardian + spécification du système de design CSS Phase 1
goal_create: Implémentation des tokens de design (custom properties CSS, palette de marque, échelle typographique)goal_create: Système de layout (système de conteneurs, patterns de grille, utilitaires flexbox)goal_create: Système de thème (variables light/dark, détection des préférences système, toggle de thème, transitions fluides)- Délai : 2 jours.
Checkpoint de vérification (Jour 4-5)
Utilisez organization_delegate vers un Evidence Collector pour vérification avec preuves screenshot :
- Pipeline CI/CD s'exécute avec succès
- Squelette applicatif se charge dans le navigateur (desktop + mobile)
- Toggle de thème fonctionne (light + dark)
- API health check répond
- Base de données est accessible (statut des migrations)
- Dashboards de monitoring sont actifs
- Bibliothèque de composants est renderée
Gate Decision
Double approbation : DevOps Automator (infrastructure) + Evidence Collector (visuel)
- PASS : Squelette fonctionnel avec pipeline DevOps complet -> Phase 3
- FAIL : Problèmes spécifiques d'infrastructure ou d'application -> Corriger et re-vérifier
Utilisez knowledge_write pour persister tous les artefacts de fondation et preuves de vérification.
Livrables
- [ ] Pipeline CI/CD fonctionnel (builds, tests, déploiements)
- [ ] Schéma de base de données déployé avec toutes les tables/indexes
- [ ] Scaffold API répondant sur health check
- [ ] Squelette frontend renderisé dans le navigateur
- [ ] Dashboards de monitoring affichant les métriques
- [ ] Tokens du système de design implémentés
- [ ] Toggle de thème fonctionnel (light/dark/system)
- [ ] Workflow Git et processus documentés
- [ ] Screenshots de vérification Evidence Collector
Métriques de succès
- Pipeline CI/CD build, teste et déploie sans erreurs
- Schéma de base de données déployé avec toutes les tables et indexes
- Scaffold API répondant sur l'endpoint health check
- Squelette frontend renderisé dans le navigateur (desktop + mobile)
- Dashboards de monitoring affichant les métriques
- Tokens du système de design implémentés et bibliothèque de composants renderisée
- Toggle de thème fonctionnel (light/dark/system)
- Workflow Git et processus documentés
Vérifier
- Le livrable de cette phase existe en tant qu'artefact concret (doc, ticket, board, repo) et son emplacement est partagé, pas décrit
- Chaque engagement a un propriétaire nommé, une date limite et une definition-of-done que quelqu'un d'autre que l'auteur pourrait vérifier
- Les risques sont listés avec probabilité/impact et une mitigation nommée, pas comme un bullet générique 'risks: TBD'
- Les dépendances sur d'autres équipes/vendeurs/agents sont explicites ; une approbation de chaque dépendance est enregistrée ou marquée 'en attente'
- Les critères de succès pour la phase suivante sont numériques ou autrement objectivement testables
- Un critère de rollback / kill-switch / 'on arrêtera si X' est écrit avant que le travail ne commence