formal-you/agent-skills-suite — Dev

Dev — Implémentation de tâche

Implémente un lot de tâches et le remet à QA. Cette compétence définit le processus et porte ses propres limites de rôle dans references/role-boundaries.md. Si le dépôt adoptant définit des règles d’agent (AGENTS.md, un répertoire de règles de rôle ou équivalent), lisez-les et suivez-les lorsqu’elles sont présentes ; la compétence n’accorde jamais d’accès supplémentaire.

À utiliser lorsque

• Une tâche sous tasks/<task-id>/ a un 01-contract.md terminé et vous êtes le rôle Dev.
• Vous devez implémenter une tranche verticale, exécuter ses commandes DoD, enregistrer les preuves et passer le relais.
• Vous retravaillez une tâche après que QA a émis REWORK_REQUIRED.

Ne pas utiliser lorsque

• Le contrat est manquant, incomplet ou contesté — retournez-le au Planner.
• On vous demande de planifier, découper ou revoir des tâches, ou de vérifier le travail d’un autre agent.
• La modification demandée est en dehors de touch_files du contrat — escaladez ou fractionnez la tâche.

Entrées

• tasks/<task-id>/01-contract.md — frontmatter YAML faisant autorité, touch_files, dod, scénarios BDD section 4 (invariants Given-When-Then) et ADR hérités.
• Points d’ancrage spec référencés par le contrat.
• Commandes du projet pour la vérification de type et le lint, la suite de tests existante et la cible d’acceptation appartenant à QA déclarée dans dod.test_file.
• tasks/<task-id>/02-dev-workspace.md — le formulaire vierge que vous remplissez.

Sorties

• Modifications de code uniquement pour les chemins listés dans touch_files.
• Code respectant les invariants BDD et les limites de complexité cyclomatique ($V(G) \le 10$ standard, avertissement $11-15$ justifié dans 02, critique $> 15$ interdit).
• Un 02-dev-workspace.md rempli avec les métadonnées, les modifications réelles, l’auto‑vérification et le tableau des écarts d’implémentation (lignes DEV-001, DEV-002, … ou une ligne None explicite).
• Exactement un marqueur de remise : - [x] WAITING_FOR_QA, coché uniquement lorsque chaque élément du DoD réussit.
• Aucune modification de 01-contract.md, 03-qa-verification.md, 04-process.md ou tests/acceptance/**.

Workflow

1. Confirmer le périmètre et le contrat BDD. Lire le frontmatter de 01-contract.md et les scénarios BDD de la section 4. Vérifier que task_id correspond au nom du répertoire, et que touch_files, dod, adherence_adrs et les invariants Given-When-Then sont définis. Signaler les éléments manquants ou contradictoires au Planner.
2. Préparer le travail. Noter le commit de base et respecter les conventions de branche/commit du projet. Ne pas rouvrir une tâche déjà acceptée sauf si un relecteur la rouvre.
3. Implémenter la tranche verticale sous les limites BDD et de complexité. Modifier uniquement les fichiers dans touch_files. Implémenter la logique satisfaisant les invariants Given-When-Then déclarés dans la section 4 et dod.edge_cases. Contrôler la complexité cyclomatique de chaque fonction ($V(G) \le 10$ standard). Si la complexité approche la limite d’avertissement ($11-15$), appliquer des motifs de refactoring (Extract Method, Strategy / Lookup Table, Guard Clauses). Si $V(G) > 15$, refactoriser avant de continuer. Ne pas modifier ni créer tests/acceptance/**.
4. Exécuter le DoD vérifiable automatiquement et l’auto‑vérification. Exécuter dod.type_check et dod.lint, puis lancer les tests existants du projet ; considérer chaque élément de dod.edge_cases. Auto‑auditer la complexité cyclomatique de toutes les fonctions modifiées. La cible d’acceptation (dod.test_file) appartient à QA : l’exécuter uniquement si elle existe déjà, ne jamais l’écrire ni la modifier. Si elle n’existe pas encore, le noter dans 02 et laisser QA l’exécuter lors de la vérification. Capturer les commandes/résultats.
5. Remplir 02-dev-workspace.md. Enregistrer la branche, le commit de base/de remise, les notes de conception, une ligne par fichier effectivement modifié, les comptes nets de lignes, et cocher chaque élément d’auto‑vérification vrai. Inclure une justification architecturale explicite pour toute fonction avec une complexité d’avertissement ($11 \le V(G) \le 15$). Laisser les éléments non cochés s’ils n’ont pas réussi. Compléter le tableau des écarts d’implémentation : une ligne par endroit où le code diffère du contrat ou de la spec (DEV-001, DEV-002, … ; opération add | modify | remove ; une ancre #sec-*), ou écrire None dans chaque cellule s’il n’y a aucun écart.
6. Remettre à QA. Uniquement lorsque chaque élément d’auto‑vérification réussit et que les limites de complexité sont satisfaites, passer de - [ ] WAITING_FOR_QA à - [x] WAITING_FOR_QA. Cette unique case cochée est le déclencheur de remise. Ne pas modifier 03 ou 04.
7. En cas de rework. Lire les traces d’échec de QA dans 03-qa-verification.md, corriger uniquement dans le cadre du contrat, ré‑exécuter le DoD, mettre à jour 02 pour la nouvelle tentative et remettre à nouveau. Escalader les échecs répétés au lieu de contourner le contrat.

Porte de qualité (avant de déclarer terminé)

• Chaque chemin modifié est listé dans 01-contract.md → touch_files.
• Aucun fichier en dehors du périmètre autorisé n’a été créé ou modifié.
• L’implémentation respecte tous les scénarios BDD Given-When-Then et les invariants comportementaux.
• La vérification de type et le lint se terminent avec succès ; les tests existants du projet passent.
• L’auto‑audit de complexité cyclomatique réussit : toutes les fonctions satisfont $V(G) \le 10$ (ou $11-15$ avec justification dans 02) ; aucune ne dépasse $V(G) > 15$.
• La cible d’acceptation appartenant à QA (dod.test_file) est déclarée ; si elle n’est pas encore écrite, cela est enregistré pour QA.
• Chaque élément de dod.edge_cases a une justification d’implémentation/test.
• 02-dev-workspace.md est complet pour cette tentative, y compris le tableau des écarts d’implémentation (ligne None explicite s’il n’y a aucun écart).
• Seulement WAITING_FOR_QA est coché ; 03 et 04 sont intacts.

Gestion des échecs

• Contrat manquant ou contradictoire : arrêter ; signaler le champ et demander au Planner de le corriger.
• Modification hors périmètre nécessaire : fractionner la tâche ou escalader ; ne jamais modifier en dehors de touch_files.
• Commande DoD manquante ou non exécutable : la signaler avec la commande et l’erreur ; ne pas ignorer la vérification.
• DoD échoue : corriger l’implémentation et relancer. Ne pas cocher la case de remise tant qu’une vérification échoue.
• Complexité dépasse le seuil ($V(G) > 15$) : refactoriser en utilisant Extract Method, Strategy / Lookup Table, Guard Clauses ou State patterns avant la remise ; ne jamais remettre une complexité critique.
• Outils indisponibles : utiliser les commandes manuelles du projet et enregistrer les preuves dans 02 ; le workflow ne doit pas dépendre d’outils optionnels.

04-process.md et outils

04-process.md est une sortie dérivée. Après avoir coché la case de remise, l’outillage optionnel du dépôt ajoute HANDOFF_QA_REQUESTED et met à jour macro_status/current_lock_holder. Ne jamais modifier 04 manuellement ; sans outillage, se fier à git/CI et à la case cochée.

Après QA_PASSED : propriété de la mise à jour des specs

Le tableau des écarts d’implémentation est la dernière livraison du Dev pour la tâche. Après que QA enregistre QA_PASSED, la compétence converge possède la mise à jour des specs : elle intègre les écarts confirmés dans .specs/02-tech-spec.md, archive le bundle de tâches et ferme la proposition de modification.

• Le Dev ne modifie jamais .specs/02-tech-spec.md et n’archive jamais le bundle.
• Un écart structurel (nouveau composant, changement de limite, nouvelle décision de niveau ADR) est escaladé vers le Planner/spec-generator au lieu d’être intégré silencieusement.
• Si QA demande un rework, mettre à jour le tableau des écarts pour la nouvelle tentative ; ne pas pré‑écrire le texte de spec.

Références

• references/dev-protocol.md — listes de contrôle détaillées, vérification de périmètre, limites de complexité cyclomatique de McCabe, motifs de refactoring, procédure de remise et de rework.
• Limites de rôle : references/role-boundaries.md — périmètre d’écriture, périmètre de lecture seule, invariants et modèle d’application honnête (inclus ; aucun fichier externe nécessaire).
• Règles du dépôt : lire AGENTS.md et tout fichier de règles de rôle lorsque le projet adoptant les définit ; ils peuvent ajouter des exigences mais ne sont pas nécessaires au fonctionnement de cette compétence.
• Format du bundle de tâches : compétence task-decomposition (facultative ; cette compétence ne consomme que ses artefacts).

Limites honnêtes

Cette compétence n’accorde pas d’accès en écriture et ne peut pas imposer l’isolation des rôles. Là où le dépôt dispose d’une CI (par exemple un audit de rôle basé sur git) ou d’une protection de branche, c’est la couche faisant autorité. Le contrat, et non ce document, définit le périmètre autorisé.