Capacités du produit

Cette compétence permet de traduire l'intention du produit en contraintes techniques explicites.

Utilisez-la lorsque la question n’est pas « que devons-nous construire ? », mais « quelles conditions doivent être remplies avant de commencer la mise en œuvre ? ».

Quand l'utiliser

• Un PRD, un élément de la feuille de route, une discussion ou une note du fondateur existe, mais les contraintes de mise en œuvre restent implicites
• Une fonctionnalité concerne plusieurs services, dépôts ou équipes et nécessite un contrat de capacités avant le codage
• L’intention produit est claire, mais les implications en matière d’architecture, de données, de cycle de vie ou de politique restent floues
• Les ingénieurs seniors ne cessent de réitérer les mêmes hypothèses sous-jacentes lors des revues
• Vous avez besoin d’un artefact réutilisable capable de perdurer d’un test à l’autre et d’une session à l’autre

Artefact canonique

Si le dépôt dispose d’un fichier de contexte produit durable, tel que PRODUCT.md, docs/product/ ou un répertoire program-spec, mettez-le à jour à cet endroit.

Si aucun manifeste de capacités n’existe encore, créez-en un à l’aide du modèle disponible à l’adresse :

• docs/examples/product-capability-template.md

L’objectif n’est pas de créer une nouvelle pile de planification. L’objectif est de rendre les contraintes de capacités cachées durables et réutilisables.

Règles non négociables

• N’inventez pas la vérité du produit. Signalez explicitement les questions en suspens.
• Séparez les promesses visibles par l’utilisateur des détails de mise en œuvre.
• Précisez clairement ce qui relève d’une politique fixe, ce qui relève d’une préférence architecturale et ce qui reste encore en suspens.
• Si la demande entre en conflit avec les contraintes existantes du dépôt, signalez-le clairement au lieu de passer cela sous silence.
• Privilégiez un artefact de fonctionnalité réutilisable plutôt que des notes ad hoc éparpillées.

Données d'entrée

Ne lisez que ce qui est nécessaire :

1. Objectif du produit
   • tique, discussion, PRD, note de feuille de route, message du fondateur
2. Architecture actuelle
   • documentation pertinente du dépôt, contrats, schémas, routes, workflows existants
3. Contexte des capacités existantes
   • PRODUCT.md, documents de conception, RFC, notes de migration, documents relatifs au modèle opérationnel
4. Contraintes de mise en œuvre
   • authentification, facturation, conformité, déploiement, rétrocompatibilité, performances, politique de révision

Workflow principal

1. Reformuler la fonctionnalité

Résumer la demande en une seule phrase précise :

• qui est l’utilisateur ou l’opérateur
• quelle nouvelle fonctionnalité sera disponible une fois le produit lancé
• quels résultats en découlent

Si cette formulation n'est pas suffisamment claire, la mise en œuvre risque de s'écarter de l'objectif initial.

2. Résoudre les contraintes liées aux fonctionnalités

Identifier les contraintes qui doivent être respectées avant la mise en œuvre :

• règles métier
• limites de portée
• invariants
• limites de confiance
• propriété des données
• transitions du cycle de vie
• exigences de déploiement / de migration
• scénarios de défaillance et de reprise

Ce sont là des éléments qui ne figurent souvent que dans la mémoire des ingénieurs seniors.

3. Définir le contrat relatif à la mise en œuvre

Élaborer un plan des capacités de type SRS comprenant :

• un résumé des capacités
• les non-objectifs explicites
• les acteurs et les interfaces
• les états et transitions requis
• des interfaces / entrées / sorties
• Implications sur le modèle de données
• contraintes de sécurité / de facturation / de politique
• exigences en matière d’observabilité et d’exploitation
• questions en suspens bloquant la mise en œuvre

4. Passer à la mise en œuvre

Terminer par le transfert précis :

• prêt pour une mise en œuvre immédiate
• nécessite d’abord une révision de l’architecture
• nécessite au préalable une clarification du produit

Si utile, indiquez la prochaine voie native ECC :

• project-flow-ops
• workspace-surface-audit
• générateur-de-connecteurs-API
• dashboard-builder
• tdd-workflow
• boucle-de-vérification

Format de sortie

Renvoyer le résultat dans cet ordre :

CAPACITÉ
- reformulation en un paragraphe

CONTRAINTES
- règles fixes, invariants et limites

CONTRAT DE MISE EN ŒUVRE
- acteurs
- surfaces
- états et transitions
- implications en matière d’interface et de données

NON-OBJECTIFS
- ce dont cette piste ne s'occupe explicitement pas

QUESTIONS EN SUSPENS
- obstacles ou décisions relatives au produit encore à prendre

TRANSFERT
- ce qui doit se passer ensuite et quelle piste ECC doit prendre le relais

Résultats positifs

• L’intention du produit est désormais suffisamment concrète pour être mise en œuvre sans redécouvrir de contraintes cachées en cours de PR.
• La revue d’ingénierie dispose d’un artefact durable au lieu de s’appuyer sur la mémoire ou le contexte Slack.
• Le plan qui en résulte est réutilisable sur les surfaces de planification de Claude Code, Codex, Cursor, OpenCode et ECC 2.0.