---
description: Exécuter une implémentation par phases avec portes de validation
argument-hint: "<feature-slug> [--phase N] [--validate-only]"
---

## Entrée utilisateur

```text
$ARGUMENTS
```

Tu **DOIS** parser l'entrée utilisateur pour extraire le slug de fonctionnalité (le nom du dossier dans `rpi/`).

## Objectif

Cette commande exécute l'implémentation par phases de fonctionnalités à partir de la documentation de planification. Elle orchestre des agents spécialisés, impose des portes de validation et garantit la conformité constitutionnelle pendant toute l'implémentation.

**Prérequis** :
- Le dossier de fonctionnalité existe dans `rpi/{feature-slug}/`
- La planification est terminée (`rpi/{feature-slug}/plan/PLAN.md` existe)

**Emplacement de sortie** : `rpi/{feature-slug}/implement/`

**C'est l'étape 4 du workflow RPI** (étape finale - implémentation réelle).

## Flags

- `--phase N` : exécute une phase spécifique (1-8), sinon démarre à la phase 1
- `--validate-only` : valide seulement la phase courante, sans implémenter
- `--skip-validation` : saute la porte de validation et continue (à utiliser avec prudence)

## Agents disponibles

Tous les agents utilisent le **modèle Opus** pour une qualité maximale.

### Agent d'implémentation

| Agent | Type | Quand l'utiliser |
|-------|------|------------------|
| `senior-software-engineer` | Custom | Toutes les tâches d'implémentation |

### Agents de support

| Agent | Type | Objectif |
|-------|------|----------|
| `Explore` | Built-in | Exploration de code pré-implémentation |
| `code-reviewer` | Custom | Revue de code et validation qualité |
| `constitutional-validator` | Custom | Validation contre la constitution projet |
| `documentation-analyst-writer` | Built-in | Génération de documentation |

### Routage des agents

Toutes les tâches d'implémentation sont prises en charge par l'agent `senior-software-engineer`.

---

## Phase 0 : charger le contexte et les règles

**Prérequis** : slug extrait de l'entrée utilisateur

**Processus** :

### 0.1 Charger la constitution projet

1. Chercher un document de constitution ou de principes dans le dépôt
2. S'il existe, extraire :
   - Contraintes techniques (type safety, tests, isolation composant)
   - Principes business (standards qualité, workflow)
   - Frontières architecturales
3. Stocker les contraintes pour les appliquer pendant l'implémentation

### 0.2 Charger les consignes propres au domaine

Selon les fichiers à modifier, charger les consignes projet pertinentes :
- Vérifier les README propres aux composants
- Vérifier les guides de style de code
- Vérifier la documentation d'exigences de test

### 0.3 Analyser le périmètre d'implémentation

1. Lire `rpi/{feature-slug}/plan/PLAN.md`
2. Identifier tous les fichiers à modifier
3. Mapper les fichiers vers l'agent d'implémentation

**Sorties** :
- Résumé du contexte constitutionnel
- Règles de domaine chargées
- Mapping fichiers-agent
- Plan d'exécution des phases

**Validation** :
- [ ] Constitution chargée (si elle existe)
- [ ] Règles de domaine chargées pour les fichiers affectés
- [ ] Tous les fichiers mappés aux agents
- [ ] Plan d'exécution compris

---

## Workflow d'implémentation par phases

### Boucle d'implémentation de phase

Pour chaque phase dans PLAN.md :

```
┌─────────────────────────────────────────────────────────────────┐
│ Phase N: [Phase Name]                                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Code Discovery (Explore Agent)                              │
│     └─→ Comprendre le code existant avant de le changer          │
│                                                                  │
│  2. Implementation (senior-software-engineer)                   │
│     └─→ Implémenter les livrables de la phase                    │
│                                                                  │
│  3. Self-Validation                                             │
│     └─→ L'ingénieur valide contre la checklist de phase          │
│                                                                  │
│  4. Code Review (code-reviewer Agent)                           │
│     └─→ Sécurité, correction, maintenabilité                     │
│                                                                  │
│  5. User Validation Gate                                        │
│     └─→ STOP et demander l'approbation utilisateur               │
│         ├─→ PASS: passer à la phase suivante                     │
│         ├─→ CONDITIONAL PASS: noter les problèmes, continuer     │
│         └─→ FAIL: corriger les problèmes, revalider              │
│                                                                  │
│  6. Documentation Update                                        │
│     └─→ Mettre à jour le statut de phase dans PLAN.md            │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
```

---

## Étape 1 : découverte du code (par phase)

**Agent** : Explore (Built-in, via Task tool)

**Objectif** : ancrer l'implémentation dans la réalité du code avant tout changement.

**Processus** :
1. Lancer l'agent Explore via Task tool avec `subagent_type="Explore"`
2. Demander l'analyse des fichiers affectés par la phase courante
3. Comprendre patterns existants, points d'intégration et contraintes

**Prompt de l'agent Explore** :
```
Analyze the codebase to prepare for implementing Phase N of [feature-name].

Files to be modified in this phase:
[List files from PLAN.md]

Investigate and document:

1. **Current Implementation**
   - How do these files currently work?
   - What patterns are used?
   - What functions/classes will be affected?

2. **Integration Points**
   - What other files import or use these modules?
   - What APIs or interfaces will change?
   - What tests cover this code?

3. **Dependencies**
   - What libraries are used?
   - What internal utilities are available?
   - What constraints exist from current code?

4. **Patterns to Follow**
   - What coding style is used in these files?
   - What naming conventions are followed?
   - What error handling patterns exist?

5. **Risks and Considerations**
   - What could break if we change this?
   - What edge cases exist?
   - What backward compatibility concerns?

Provide a discovery summary to inform implementation.
```

**Sortie** : résumé de découverte pour l'agent d'implémentation

---

## Étape 2 : implémentation (par phase)

**Agent** : senior-software-engineer

**Processus** :
1. Utiliser l'agent senior-software-engineer
2. Fournir le contexte de découverte de l'étape 1
3. Implémenter tous les livrables de la phase
4. Respecter les contraintes constitutionnelles et règles projet

**Template de prompt de l'agent d'implémentation** :
```
Acting as the [agent-name] agent, implement Phase N deliverables for [feature-name].

## Context
- Constitutional Constraints: [from Phase 0]
- Domain Rules: [from Phase 0]
- Discovery Summary: [from Step 1]

## Phase N Deliverables
[List from PLAN.md]

## Files to Modify
[List files with specific changes from PLAN.md]

## Implementation Requirements
1. Follow existing code patterns identified in discovery
2. Honor constitutional constraints (type safety, testing, etc.)
3. Follow project-specific rules (if applicable)
4. Write tests for new functionality
5. Include appropriate logging
6. Handle errors gracefully

## Quality Checklist
- [ ] Code follows existing patterns
- [ ] Type annotations present where applicable
- [ ] Tests written and passing
- [ ] No breaking changes to existing functionality
- [ ] Logging added for observability
- [ ] Error handling comprehensive

Implement all deliverables and report what was done.
```

---

## Étape 3 : auto-validation

**Agent** : senior-software-engineer (même que l'étape 2)

**Processus** :
1. L'agent valide l'implémentation contre la checklist de phase
2. Lancer le linting (utiliser le linter configuré du projet)
3. Lancer les tests pertinents pour les changements
4. Vérifier que le build réussit

**Commandes de validation** (à adapter à ton projet) :

```bash
# Run linter
[your-linter-command]

# Run tests
[your-test-command]

# Build/compile
[your-build-command]
```

**Checklist d'auto-validation** :
- [ ] Tous les livrables implémentés
- [ ] Linting OK
- [ ] Tests OK
- [ ] Build OK
- [ ] Aucune régression dans les tests existants
- [ ] Contraintes constitutionnelles respectées
- [ ] Règles de domaine suivies

---

## Étape 4 : revue de code

**Agent** : code-reviewer (Custom, auto-invoqué)

**Processus** :
1. Invoquer l'agent code-reviewer pour relire les changements
2. Se concentrer sur correction, sécurité, maintenabilité
3. Corriger les blockers avant de continuer

**Prompt de l'agent de revue de code** :
```
Acting as the code-reviewer agent, review the Phase N implementation for [feature-name].

## Files Changed
[List modified files]

## Changes Made
[Summary of implementation]

## Review Focus
- Correctness & tests
- Security & dependency hygiene
- Architectural boundaries
- Clarity over cleverness

## Constitutional Constraints
[From Phase 0]

Provide review using standard output format.
```

**Verdicts de revue** :
- **APPROVED** : passer à la validation utilisateur
- **APPROVED WITH SUGGESTIONS** : noter les suggestions, continuer
- **NEEDS REVISION** : corriger, relire à nouveau

---

## Étape 5 : porte de validation utilisateur

**CRITIQUE** : cette étape REQUIERT une interaction utilisateur. NE PAS continuer automatiquement.

**Processus** :
1. Présenter la checklist des livrables de phase
2. Montrer ce qui a été implémenté (fichiers modifiés, fonctionnalités ajoutées)
3. Présenter les critères de validation depuis PLAN.md
4. Montrer les résultats de revue de code
5. **STOP et attendre la décision utilisateur**

**Format de demande de validation** :
```
## Phase N Validation Request

### Deliverables Completed
- [x] [Deliverable 1] - [implementation summary]
- [x] [Deliverable 2] - [implementation summary]
- ...

### Files Changed
| File | Change Type | Lines |
|------|-------------|-------|
| [file] | [add/modify] | [±N] |

### Tests
- [x] Unit tests: PASS
- [x] Integration tests: PASS
- [x] Build: SUCCESS

### Code Review
- Verdict: [APPROVED / APPROVED WITH SUGGESTIONS]
- Issues: [None / List]

### Validation Criteria (from PLAN.md)
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- ...

---

**Please validate Phase N:**
- **PASS**: Phase complete, proceed to Phase N+1
- **CONDITIONAL PASS**: Note issues below, proceed with caution
- **FAIL**: Specify issues to fix before proceeding
```

**Décisions utilisateur** :
- **PASS** : passer à la phase suivante
- **CONDITIONAL PASS** : documenter les problèmes, passer à la phase suivante
- **FAIL** : corriger les problèmes, relancer les étapes 2-5

---

## Étape 6 : mise à jour documentaire

**Processus** :
1. Mettre à jour `rpi/{feature-slug}/plan/PLAN.md` avec le statut de phase
2. Mettre à jour `rpi/{feature-slug}/implement/IMPLEMENT.md` avec les résultats de validation
3. Ajouter la validation de chaque phase à IMPLEMENT.md

### Suivi de statut de phase

Mettre à jour les checkboxes dans PLAN.md :
```markdown
- [ ] Phase N: Not Started
- [~] Phase N: In Progress
- [x] Phase N: Validated (PASS)
- [!] Phase N: Conditional Pass (with notes)
- [-] Phase N: Failed Validation (needs rework)
```

### Template IMPLEMENT.md

```markdown
# Implementation Record

**Feature**: [feature-slug]
**Started**: [Date]
**Status**: [IN_PROGRESS / COMPLETED]

---

## Phase 1: [Phase Name]

**Date**: [Date]
**Verdict**: [PASS / CONDITIONAL PASS / FAIL]

### Deliverables
- [x] [Deliverable 1]
- [x] [Deliverable 2]

### Files Changed
[List with line counts]

### Test Results
[Test output summary]

### Code Review
[Review verdict and notes]

### Notes
[Any additional notes]

---

## Phase 2: [Phase Name]
[Same structure as Phase 1...]

---

## Summary

**Phases Completed**: [N] of [N]
**Final Status**: [COMPLETED / IN_PROGRESS]
```

---

## Gestion des erreurs

### Échecs d'implémentation

**Si l'implémentation échoue** :
1. Documenter l'échec précis
2. Analyser la cause racine
3. Essayer une approche alternative (max 2 tentatives)
4. Si ça échoue encore, STOP et demander l'avis utilisateur
5. NE PAS passer à la phase suivante avec une implémentation cassée

**Message** : "Implementation failed: [error]. Attempted [N] approaches. User guidance needed."

### Échecs de tests

**Si les tests échouent** :
1. Analyser la cause (bug code vs bug test)
2. Corriger le problème
3. Relancer les tests
4. Si persistant, documenter et demander à l'utilisateur
5. NE PAS marquer la phase terminée avec des tests en échec

**Message** : "Tests failing: [failures]. Fix attempted but unsuccessful. User review needed."

### Échecs de build

**Si le build échoue** :
1. Vérifier les erreurs de types
2. Vérifier les imports manquants
3. Vérifier les erreurs de syntaxe
4. Corriger et rebuilder
5. Si persistant, escalader à l'utilisateur

**Message** : "Build failing: [error]. Unable to resolve automatically."

### Échecs d'agent

**Si un agent échoue ou timeout** :
1. Réessayer une fois avec les mêmes entrées
2. Si ça échoue encore, continuer sans la contribution de cet agent
3. Documenter la lacune dans la demande de validation

**Message** : "Agent [name] failed. Proceeding without contribution."

---

## Rapport de fin

À la réussite de toutes les phases :

```markdown
## Implementation Complete

### Feature Summary
- **Feature**: [feature-name]
- **Phases Completed**: [N] of [N]

### Phases Executed
| Phase | Status | Notes |
|-------|--------|-------|
| Phase 1 | PASS | [summary] |
| Phase 2 | PASS | [summary] |
| ... | ... | ... |

### Files Modified
| File | Change Type | Lines |
|------|-------------|-------|
| [file] | [type] | [±N] |

### Tests Added
- [test files]

### Code Review Summary
- Blockers Fixed: [N]
- Suggestions Addressed: [N]

### Constitutional Compliance
- [ ] Type safety maintained
- [ ] Tests written
- [ ] Component isolation respected
- [ ] No breaking changes

### Artifacts Created
- `rpi/{feature-slug}/plan/PLAN.md` (updated with phase status)
- `rpi/{feature-slug}/implement/IMPLEMENT.md` (all phase validations)

### Next Steps
1. Create PR with changes
2. Request final human review
3. Deploy to staging
4. Verify in staging environment
5. Deploy to production

### PR Notes

**Title**: [{feature-slug}] [Brief description]

**Summary**:
[What was implemented]

**Changes**:
- [List key changes]

**Testing**:
- [How tested]

**Rollout**:
- [Deployment steps]

**Rollback**:
- [Rollback procedure if issues]
```

---

## Quality Gates

### Quality gate par phase

Avant de marquer une phase comme terminée :

- [ ] Tous les livrables implémentés
- [ ] Linting OK
- [ ] Tests OK
- [ ] Build OK
- [ ] Revue de code passée
- [ ] Validation utilisateur reçue
- [ ] Documentation mise à jour

### Quality gate finale

Avant de marquer l'implémentation complète :

- [ ] Toutes les phases validées
- [ ] Aucun test en échec
- [ ] Build complet OK
- [ ] Conformité constitutionnelle vérifiée
- [ ] Règles de domaine suivies
- [ ] Notes de PR générées

---

## Notes

### Quand utiliser cette commande

- Après que `/rpi:plan` a généré PLAN.md
- Quand une implémentation par phases avec portes de validation est nécessaire
- Pour les fonctionnalités qui exigent une implémentation structurée

### Quand NE PAS utiliser cette commande

- Corrections de bugs (trop lourd, corrige directement)
- Changements très simples (<30 minutes de travail)
- Prototypage exploratoire
- Changements documentation-only

### Bonnes pratiques

1. **Relire PLAN.md d'abord** : comprendre ce que tu implémentes
2. **Faire confiance à la découverte du code** : laisser l'agent Explore informer l'implémentation
3. **Suivre les patterns existants** : laisser la découverte du code informer l'implémentation
4. **Ne pas sauter la validation** : les portes existent pour détecter tôt les problèmes
5. **Documenter au fil de l'eau** : mettre à jour le statut après chaque phase
6. **Demander quand bloqué** : mieux vaut demander que continuer incorrectement

### Partie du workflow RPI

Étape 4 sur 4 (Describe → Research → Plan → **Implement**)

---

## Exemples de commandes

### Exécuter toutes les phases

```bash
/rpi:implement "my-feature"
```

### Exécuter une phase spécifique

```bash
/rpi:implement "my-feature" --phase 3
```

### Valider seulement (sans implémentation)

```bash
/rpi:implement "my-feature" --phase 2 --validate-only
```

---

## Action post-complétion

**IMPORTANT** : après avoir terminé l'implémentation (toutes les phases ou une progression significative), demande TOUJOURS à l'utilisateur de compacter la conversation :

> **Context Management** : ce workflow d'implémentation a consommé beaucoup de contexte. Pour préserver la progression et libérer de l'espace, lance :
>
> ```
> /compact
> ```
>
> Cela résumera la conversation et préservera le statut d'implémentation tout en réduisant l'usage de tokens pour le travail futur.

**Quand demander le compact** :
- Après que toutes les phases sont terminées
- Après chaque grande phase (si implémentation multi-session)
- Si le contexte devient bas pendant l'implémentation
