Déclencheurs

eng plan review
review the architecture
review architecture
engineering review
lock in the plan
tech review
technical review
plan engineering review
arch review
review implementation plan

Plan Review — Mode engineering

Vue d'ensemble

Le plan a passé les revues CEO et design. Le périmètre est verrouillé, la forme est verrouillée. Le rôle de cette revue : détecter les problèmes d'architecture qui rendraient le plan douloureux à construire, effrayant à déployer, ou coûteux à maintenir.

C'est la troisième revue du pipeline autoplan (CEO → design → eng). À exécuter après que le périmètre et la forme soient arrêtés, pas avant — une revue eng d'un plan sur le point d'être re-scopé est du temps perdu.

Ne remettez pas en cause le périmètre. Si vous trouvez un problème fondamental de périmètre à ce stade, signalez-le à l'utilisateur comme un bloquant plutôt que de le réécrire silencieusement.

Six dimensions à noter (0–10)

Pour chacune, une phrase « ce qui ferait un 10 », puis la note.

Clarté architecturale — le plan nomme-t-il chaque composant et la limite entre eux ? Un étranger pourrait-il dessiner le diagramme à partir du plan seul ?
Flux de données — pour chaque action visible par l'utilisateur, le chemin est-il tracé à travers chaque couche (requête → auth → logique métier → stockage → réponse) ? Les transitions d'état sont-elles explicites ?
Cas limites — que se passe-t-il en cas d'échec partiel, timeout réseau, requête dupliquée, auth expirée, condition de course, entrée vide, entrée surdimensionnée ? Au moins 5 cas limites nommés par composant non trivial.
Couverture de tests — y a-t-il des critères d'acceptation testables pour chaque comportement livré ? Quel est le plus petit cas de reproduction pour le bug qui nous convaincrait que c'est cassé ?
Réversibilité — les changements peuvent-ils être annulés sans perte de données ? Le schéma est-il rétro-compatible ? Les déploiements sont-ils échelonnés ?
Opérabilité — de quoi la personne en astreinte aurait-elle besoin pour diagnostiquer cela à 3h du matin ? Logs, métriques, runbook, erreurs structurées avec codes ?

En dessous de 7 sur une dimension ➜ patcher le plan avant approbation.

Ce que vous devez ajouter au plan

Si absent, remplissez directement (ne signalez pas juste) :

Carte des modules — liste des fichiers / nouveaux packages et ce que chacun possède. Référencez les fichiers existants du repo par chemin pour pouvoir localiser les appelants.
Diff de schéma — changements au niveau des tables, indexes, contraintes, ordre de migration, plan de backfill.
Modes d'échec — liste à puces des échecs nommés + la réponse prévue de l'agent (retry / fail-loud / silent-skip / escalate).
Critères d'acceptation — énoncés testables qui correspondent à la « demande de réalité » de la couche CEO/design. Pas « la fonction retourne », mais « l'utilisateur voit X dans Y secondes ».
Rollback — étapes exactes pour revenir. Si « on pousse juste un autre commit », dites-le explicitement.

Comment utiliser

Lire le plan (chemin, texte, ou goal_status du goal actif).
Récupérer knowledge_search(scope="system") pour les docs d'architecture/conventions du projet et toute leçon scope="learned" apprise précédemment (on ne veut pas répéter les erreurs connues).
Parcourir les six dimensions.
Soit (a) patcher le plan sur place, soit (b) retourner un diff structuré + liste d'escalades.

Quand appelé depuis plan_autoplan, retourner du JSON correspondant au schéma attendu par l'outil. Quand appelé interactivement, du narratif convient.

Règles strictes

N'ajouter une nouvelle dépendance que si vous nommez l'alternative qu'on a considérée et rejetée.
Ne pas changer une API publique sans un chemin de dépréciation.
Ne pas proposer un changement de schéma sans un plan de backfill / rollback.
Ne pas masquer un problème de périmètre connu avec la rigueur de l'engineering — escalader vers l'utilisateur.

Ce que cette skill ne fait PAS

Remettre en cause le périmètre (rôle de la revue CEO — escalader à la place).
Critiquer l'UI/UX (rôle de la revue design).
Écrire ou implémenter du code.

Vérifier

Le livrable pour cette phase existe comme un 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 définition de fait vérifiable par quelqu'un d'autre que l'auteur
Les risques sont listés avec probabilité/impact et une mitigation nommée, pas une puace générique 'risques : TBD'
Les dépendances sur d'autres équipes/vendors/agents sont explicites ; un accusé de réception de chaque dépendance est enregistré ou marqué 'pending'
Les critères de succès pour la phase suivante sont numériques ou autrement objectivement testables
Un criterion de rollback / kill-switch / 'on arrêtera si X' est écrit avant le début du travail

plan-review-eng