v6.0.0 — Chartes de format et de frontières

✨ Fonctionnel

• BREAKING — Une charte de format commune aux 8 documents de story — nouvelle référence partagée references/document-format.md, chargée par les 8 skills producteurs (feature-interview, feature-pitch, les 3 *-plan, review, report, estimate). Elle fixe ce que chaque template appliquait jusqu'ici à sa façon : une matrice des buts (un document = un registre, une question, un consommateur), un en-tête normalisé (but / registre / story / amont — conservé après commit, contrairement aux blocs guides), un vocabulaire canonique des sections, un squelette commun aux trois plans, des formats de table normatifs, un catalogue fermé de tags et des verdicts en français. En cas de doute sur un titre ou un format, la charte fait foi.
• BREAKING — Les trois plans partagent un squelette unique — feature-plan, refactor-plan et tech-plan produisaient trois dialectes du même document (jusqu'à 3 formats pour lister les fichiers touchés, 2 pour les risques, 3 noms pour la séquence d'exécution). Ils suivent désormais le même ordre de sections ; les spécificités de track deviennent des sections additionnelles explicites (Forme cible et Tests de caractérisation pour un refacto, Rollback et kill switch et Métriques (baseline → cible) pour une évolution technique).
• BREAKING — Verdicts de review en français — READY TO COMMIT / CHANGES REQUESTED / NEEDS FIXES sont remplacés par PRÊT À COMMITER / PRÊT À COMMITER SOUS RÉSERVE / CORRECTIONS REQUISES. La review.md ouvre désormais sur sa ## Synthèse (verdict en tête, plus en pied) — comme report.md et estimate.md : un document de décision se lit par sa conclusion.
• La chaîne plan → report fonctionne enfin pour les refactos et les évolutions techniques — le report.md confrontait le livré à l'intention avec les tables de feature-plan ; un -r- (table fichier/lignes/action) ou un -t- (liste à puces) ne pouvait pas se confronter ligne à ligne. Les tables de ## Périmètre sont désormais normatives et identiques dans les 3 plans, le report les reprend + une colonne « Prévu dans le plan ». Idem pour les critères : ## Critères de sortie est la section unique de critères d'un plan, quel que soit le track (un tech-plan en avait deux).
• Étanchéité fonctionnel / technique renforcée — chaque document déclare son registre dans son en-tête et s'y tient. Le pitch.md perd les noms de classes et de mécanismes qui fuyaient dans ses Impacts transverses (redevenus des questions métier : « des libellés à traduire ? », « qui a le droit de voir ça ? ») ; ses « Notes pour le plan technique » deviennent une ## Annexe — Pistes pour le plan explicitement non contractuelle — seule zone d'un document fonctionnel où un nom technique peut apparaître, et que /forge:sync ne réaligne jamais.
• Le tech-plan gagne une ## Stratégie de test — elle manquait : une cible chiffrée n'est pas un test. Ce qui ne se vérifie qu'en environnement réel (bascule DNS, certificat, tiers) est désormais explicitement distingué et rattaché aux étapes de bascule.
• BREAKING — Un contrat de frontières entre skills — nouvelle référence references/skill-boundaries.md : trois invariants (un artifact, un écrivain ; on juge le livrable, pas le moyen ; aucune invocation automatique), la matrice de propriété d'écriture artifact par artifact, les deux seules exceptions de co-écriture admises (metadata.json, append-only par construction ; les documents projet, que sync co-écrit via les modes de leurs propriétaires, sur validation), et une revue qui porte sur le document produit — est-ce le bon fichier, est-il dans son rôle, est-il pertinent — plutôt que sur le frontmatter du skill.
• Les outillages projet ne sont pas restreints — borner les binaires d'un skill (composer, cargo, pytest, npm…) contrôle le chemin, pas le livrable : un feature-pitch privé de cargo produit exactement le même pitch.md, avec une demande d'autorisation en plus. Les skills d'implémentation pré-autorisent une liste large et multi-stack (PHP/JS, Rust, Go, Python, Ruby, JVM, .NET, conteneurs) — un confort contre les demandes d'autorisation, pas une frontière. La seule capacité qui soit une frontière est l'écriture git : elle seule permet de produire l'artifact d'un autre.
• Aucun skill ne se déclenche plus automatiquement — report, sync, report-and-sync et claude-md étaient invocables par le modèle, contrairement aux vingt autres. Les trois premiers décrivent trois découpages du même moment du cycle : leur triage automatique était intrinsèquement ambigu, donc faux tôt ou tard. Tous portent désormais disable-model-invocation: true.

🔧 Technique

• Outillage des skills d'implémentation ouvert aux stacks non-PHP — leurs allowed-tools ne pré-autorisaient que PHP et JS (php, composer, symfony, bin/console, npm…), ce qui contredisait la promesse stack-agnostique : sur un projet Rust, Go ou Python, chaque commande déclenchait une demande d'autorisation. La liste couvre désormais les outillages courants. Un projet dont l'outillage n'y figure pas fonctionne pareil, et peut le pré-autoriser dans son propre .claude/settings.json. test-scenario perd un Bash(curl:*) qu'il n'utilisait jamais (capacité morte, pas frontière).
• Capacités des skills resserrées sur leur périmètre — les trois *-implem détenaient Bash(git:*), soit commit, push, reset et rebase, alors que leur prose délègue le commit à /forge:commit ; ils passent à git en lecture seule. report-and-sync n'avait aucun allowed-tools — donc des capacités illimitées, la plus grande surface ouverte du plugin sur son skill le moins exigeant — et déclare maintenant l'union exacte de report et sync. backfill-metadata avait Bash(git tag:*) (création de tags) pour un usage en lecture seule → Bash(git tag --contains:*). refactor-implem commitait lui-même le verrou de caractérisation : il passe par /forge:commit.
• Sept frontmatter de skills n'étaient pas du YAML valide — les descriptions de commit, estimate, feature-plan, product-backlog, refactor-implem, stack et vision contenaient un : dans un scalaire nu, ce qu'aucun parseur YAML strict n'accepte. Corrigé par mise entre guillemets.
• Templates dé-symfonisés — > Stack : symfony en dur disparaît des en-têtes (la stack vient de la détection, pas d'un littéral), et les exemples des templates (entité Doctrine, Foundry, EasyAdmin, PHPStan level 5, make test) sont rendus génériques. Les mécanismes, commandes QA et seuils viennent des references/stacks/ et du CLAUDE.md du projet, conformément à la promesse stack-agnostique du plugin.
• Métadonnées dupliquées retirées des en-têtes — Date, Commits liés et les tables ## Changelog en pied de pitch.md/plan.md disparaissent des templates : leur source de vérité est metadata.json depuis la 4.4.0, mais les templates n'avaient pas suivi (les SKILL.md, eux, l'interdisaient déjà). vision.md, stack.md et product-backlog.md gardent leur changelog — ils n'ont pas de metadata.json.
• Collision de vocabulaire levée — « Périmètre » désignait à la fois les fichiers qu'un plan prévoit de toucher et le diff qu'une review examine. Ce dernier devient Diff examiné ; « Référence d'intention » devient Amont, comme dans tous les autres documents.
• Renommages canoniques propagés aux skills — Problème adressé → Motivation, Brique retenue/Cible → Approche retenue, Mécanismes framework mobilisés/Pattern de refacto → Mécanismes mobilisés, Ordre d'implémentation/Stratégie d'exécution incrémentale → Ordre d'exécution, Critères de réussite/Critères de succès → Critères de sortie, Résumé → Synthèse. Les axes de challenge des SKILL.md et les consignes de sync, report, review et tech-implem sont alignés.
• Stories 001 → 009 rétro-migrées — les 9 stories du Forge Board sont reformatées sur le nouveau contrat (en-têtes, titres de sections, changelogs redondants retirés). Contenu inchangé : c'est de la doc d'intention livrée, on la reformate, on ne la réécrit pas. La story 007, seule sans metadata.json, en reçoit un reconstruit depuis ses tables de changelog et l'historique git.
• Fuites techniques purgées des 9 pitchs livrés — les pitchs laissaient passer des noms de classes, mécanismes et configuration dans leurs sections fonctionnelles (ROLE_USER dans une règle métier, firewall et voters dans les impacts transverses, TokenCipher et StoryStageMapper dans des critères d'acceptation, tokens CSS dans des questions ouvertes). Chaque fuite est traduite en capacité vécue, jamais supprimée — sens, contraintes et vérifiabilité des critères préservés à l'identique. Les questions purement techniques rejoignent l'annexe non contractuelle.