v6.3.0 — Pipeline en quatre phases

✨ Fonctionnel

• Nomenclature en quatre phases — le pipeline s'articule explicitement en phases 0 (poser le décor), 1 (cadrer), 2 (implémenter) et 3 (clôturer) ; les trois tracks (feature, refacto, tech) deviennent un second axe qui décide des skills appelées en phases 1 et 2.
• Clôture réordonnée, commit en dernier — la phase de clôture suit review → report → sync → commit. Le commit embarque d'un coup le code, le report.md et les documents réalignés, au lieu de committer avant de documenter.
• Vitrine enrichie — le hero du site gagne une identité terminal (une ligne de commande qui se tape toute seule, un curseur clignotant, une entrée en cascade) et un footer harmonisé sur toute la largeur, à l'image du header.

🔧 Technique

• Skills de clôture alignées sur le working tree — report, sync, review et commit lisent les fichiers en cours de livraison (staged + unstaged + untracked) plutôt que l'historique git, cohérent avec le commit qui passe en dernier.
• Ordres de skills unifiés — la clôture et les utilitaires sont dans le même ordre entre l'inventaire du plugin, la page de documentation et llms.txt.

v6.2.1 — Site public & documentation en ligne

✨ Fonctionnel

• Site public forge.mustiere.fr — une vitrine qui présente le pipeline, les trois tracks et l'inventaire des skills, avec une carte de partage social. Servi en HTTPS, indexable par les moteurs, et lisible par les assistants via un llms.txt qui décrit le pipeline en entier.
• Documentation en ligne — prérequis, installation pas à pas, concepts (la règle d'or de la validation explicite, les artefacts de docs/story/, comment choisir son track, le track fast), référence des skills track par track, configuration des permissions et dépannage. Sommaire navigable, contenu tiré du plugin lui-même — aucune commande inventée.
• Le plugin est inchangé — cette version ne touche à aucune skill : rien de nouveau à apprendre, /plugin marketplace update forge ne fait que suivre le numéro.

🔧 Technique

• Déploiement GitHub Pages — un workflow unique vérifie puis publie le site, sur domaine personnalisé avec certificat automatique.
• Garde-fou de version — le déploiement échoue si le site annonce une version différente de plugin.json, désormais seule source de vérité. La dérive n'était pas théorique : le site a déjà affiché une version périmée sans que rien ne le signale.
• Intégration continue réduite au site — les jobs PHP (CS-Fixer, PHPStan, PHPUnit, Playwright) sont retirés : rouges depuis le 4 juillet et Actions désactivées, ils ne garantissaient plus rien. La QA de l'application tourne en local via le Makefile.
• README recentré — la documentation vit sur le site ; l'inventaire des skills n'y est plus dupliqué (il avait déjà deux skills de retard). Bannière refaite à la charte du site.
• Documentation projet réalignée — CLAUDE.md et docs/stack.md décrivent le site comme troisième brique du dépôt, et corrigent deux affirmations fausses de longue date : la direction artistique du Board (« Nova · Midnight », pas « Paper ») et le niveau PHPStan (10, pas 9).

v6.2.0 — Rules de projet

✨ Fonctionnel

• Nouveau skill /forge:rules — écrit et entretient les règles projet dans .claude/rules/, un mécanisme natif de Claude Code : des instructions paths-scopées, que le harness ne charge que lorsque Claude ouvre un fichier de la zone concernée. Le gain est là et nulle part ailleurs — une règle sans paths est chargée au lancement avec la même priorité que .claude/CLAUDE.md, donc n'apporte rien qu'une section du CLAUDE.md n'apporterait déjà. Trois modes (Création / Enrichir / Éditer, le retrait faisant partie d'Éditer, parce qu'une règle périmée continue d'être obéie).
• Deux tests appliqués à chaque règle candidate, et c'est tout le skill. Le test du paths : quels fichiers Claude doit-il être en train de lire pour que cette règle serve ? Pas de glob honnête → ce n'est pas une règle de zone. C'est le cas de toutes les règles d'outillage (« toujours le binaire symfony », « passer par le Makefile ») : lancer une commande n'est pas lire un fichier, donc aucun paths ne les déclencherait au bon moment — elles restent dans le CLAUDE.md, ou deviennent un hook PreToolUse si l'utilisateur veut une garantie plutôt qu'un conseil. La règle de preuve : une règle ne s'écrit qu'attestée par un fichier, un diff ou un finding — comptée, jamais récitée, et jamais prescrite plus large que ce qui a été mesuré.
• /forge:rules retire du CLAUDE.md ce qu'il en emporte — troisième exception assumée du contrat de frontières (§3), en soustraction seule : ce qui part en règle en est retiré (le doublon se cherche par le sens, pas par les mots — les règles sont écrites depuis le code et ne reprennent jamais la formulation d'origine), un renvoi de deux lignes le remplace. Un déplacement laissé à moitié produirait exactement le mal que l'invariant I1 veut éviter : deux énoncés de la même convention, qui divergeront. Ajouter, restructurer ou réécrire reste à /forge:claude-md.
• Pas de changelog dans les fichiers de règles, contrairement à vision.md/stack.md/product-backlog.md : une règle est injectée en contexte à chaque session où son paths matche — un historique dedans serait payé en tokens à chaque fois pour un contenu qui n'aide personne à écrire du code. git log fait le travail.
• Préséance posée dans _detection.md : .claude/rules/ scopées > CLAUDE.md > références stack. Les skills n'ont rien à faire pour obtenir les règles — le harness les charge ; les lire à la main les payerait deux fois.

🔧 Technique

• Trois pièges de glob documentés dans references/template.md, tous silencieux, découverts en évaluant le skill contre un Claude sans skill : le * simple qui ne descend pas dans les sous-dossiers ; le chemin inexistant ; et surtout les dossiers en point — ** ne fabrique jamais un composant commençant par ., donc plugins/**/* rate plugins/forge/.claude-plugin/plugin.json, précisément le fichier que la règle marketplace vise. Le glob n'est pas vide, il a l'air juste, et il rate sa cible.
• Phase 5 de vérification durcie : vérifier avec l'outil Glob, jamais avec find/ls (qui rassurent à tort — sémantique divergente) ni avec bash (qui alarme à tort — le bash de macOS est en 3.2, sans globstar : ** y dégénère en * et renvoie 0 sur un motif valide). Repli documenté sur python3 -m glob ou zsh. Et trois contrôles au lieu d'un : le glob matche-t-il, couvre-t-il ce que la règle prétend couvrir, et le scope est-il honnête.
• Contrat de frontières amendé : .claude/rules/** entre dans la table §2 avec rules pour écrivain unique ; CLAUDE.md passe à claude-md (+ rules, voir §3) ; les « deux exceptions assumées » deviennent trois, la nouvelle étant encadrée par trois garde-fous calqués sur ceux de sync.
• references/zones-catalog.md — catalogue d'amorce des zones par famille de projet (PHP/Symfony, JS/TS, Python, transverses), avec les trois lignes de découpe par ordre de rendement (par sujet, par couche, par nature de fichier) et la liste de ce qui n'est pas une zone.

v6.1.0 — Skills d'implémentation libérés

✨ Fonctionnel

• Les trois skills d'implémentation (feature-implem, refactor-implem, tech-implem) ne déclarent plus d'allowed-tools. Chacune énumérait ~45 outillages de stacks (composer, cargo, poetry, gradlew, k6…) : une liste infinie par nature, fausse dès le premier projet sortant des stacks prévus, et qui coûtait du contexte à chaque invocation. C'est désormais au .claude/settings.json du projet de pré-autoriser son propre outillage — le seul endroit où une décision de stack a sa place.
• Le corps des skills d'implémentation est réellement stack-agnostique. Les commandes PHP en dur (vendor/bin/ecs, vendor/bin/phpstan, vendor/bin/phpunit, npm run build) laissent place à l'intention (style, analyse statique, build, tests du périmètre) : les commandes se lisent dans le CLAUDE.md du projet, la référence stack ou le manifeste de tâches réel — avec consigne explicite de demander plutôt que deviner une commande plausible. Idem pour les traces de debug du nettoyage et les Stack : [symfony | sylius] des bilans.
• /forge:help et le README documentent la contrepartie. Une section « Outillage et autorisations » explique que c'est désormais au .claude/settings.json du projet de pré-autoriser son outillage — sans quoi Claude Code demande confirmation à chaque commande de build ou de test : fonctionnel, mais bavard. Exemple de configuration fourni, et mention de permissions.deny comme seul moyen de poser une interdiction dure.

🔧 Technique

• Correction d'une erreur de fait dans le contrat skill-boundaries.md. Le §4 affirmait qu'un frontmatter sans allowed-tools est « illimité — donc il détient l'écriture git sans l'avoir demandée », et le §7 en faisait un point de revue. La doc Claude Code dit l'inverse : allowed-tools « does not restrict which tools are available: every tool remains callable ». C'est une pré-autorisation, pas une allowlist — un allowed-tools avare n'a donc jamais défendu l'écriture git, il ajoutait seulement une demande de confirmation. Le §4 gagne une sous-section qui pose le comportement réel et nomme les deux seuls mécanismes contraignants (permissions.deny du projet, souverain ; disallowed-tools, à portée d'un tour), le §7 cesse de vérifier la présence de la clé et renvoie au vrai contrôle : git log.
• Le contrat tranche désormais la règle de rédaction : ne rien déclarer plutôt qu'une liste de stacks pour les skills dont l'outillage dépend du projet ; déclaration permise quand l'outillage est fini et connu (commit, vision) ; Bash(git:*) toujours évité chez qui ne livre pas — non comme rempart, mais pour préserver la demande de confirmation qui est le dernier signal avant qu'un skill livre à la place de commit.
• tech-implem ne s'attribue plus les commits d'instrumentation, de baseline et de retrait du kill switch : ils passent par /forge:commit, conformément à I1. refactor-implem le faisait déjà pour son commit de verrouillage.
• Les allowed-tools des autres skills (commit, release, vision, adr, report-and-sync…) sont inchangés : courts, finis, et alignés sur de vraies responsabilités.

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.

v5.0.0 — Refonte du changelog & nettoyage du plugin

✨ Fonctionnel

• /forge:release : versions titrées et changelog scindé Fonctionnel/Technique — chaque release porte désormais un titre obligatoire (repris à l'identique dans l'en-tête du CHANGELOG.md, le message du tag annoté et le titre de la release GitHub), et ses changements sont répartis en deux chapitres ✨ Fonctionnel (perceptible à l'usage) / 🔧 Technique (interne) au lieu des sections Added/Changed/Fixed. Le CHANGELOG.md racine est restructuré dans ce format sur tout son historique, pensé pour être montré à l'utilisateur final dans l'app. references/keep-a-changelog.md et les phases 2 à 8 du skill sont réécrites en conséquence.
• /forge:sync propage les écarts aux documents de phase 0 — une nouvelle Phase 5 réaligne aussi docs/vision.md, docs/stack.md et docs/product-backlog.md sur le code livré, pas seulement le pitch.md/plan.md de la story. Propagation différenciée selon le profil de chaque doc : stack.md gagne les dépendances/services détectés dans le diff (prouvés par fichier), product-backlog.md marque la feature livrée ou ajoute une capacité émergente, vision.md évolue avec le produit — une feature qui étend le périmètre enrichit la vision, une feature qui contredit un anti-objectif le fait retirer (la vision suit les features, elle ne les bloque pas ; seule une divergence stratégique large renvoie vers un /vision en mode Pivot). Modifications toujours proposées et validées via les modes et changelogs natifs des 3 skills (aucun nouveau format). Une story conforme à son plan déclenche quand même cette phase (une livraison conforme peut introduire une dépendance absente des docs projet). La clôture /forge:report-and-sync en bénéficie automatiquement.
• BREAKING — Skills migrate-legacy et import-external retirés — le skill de migration des anciens formats workflow (<f|r|t>-NNN-<slug>/ → NNN-<f|r|t>-<slug>/, feature.md/design.md → pitch.md/plan.md) et le skill d'import depuis Spec Kit / BMAD-METHOD / GSD disparaissent du plugin. Leurs références sont nettoyées de SKILLS.md, help, README.md et de la description du plugin.
• BREAKING — Skill et agent /forge:autopilot retirés (inutilisés) — le plugin ne fournit plus aucun subagent ; la section « Agents » disparaît de SKILLS.md et du sommaire /forge:help.

🔧 Technique

• /forge:report-and-sync s'exécute désormais dans la session courante — la skill enchaîne directement les skills canoniques /forge:report puis /forge:sync au lieu de déléguer à un subagent. Les deux SKILL.md deviennent l'unique source de vérité de la procédure (fin de la triple recopie).
• /forge:sync : suppression du bloc changelog en pied de fichier — la Phase 4 ne présente plus de table ## Changelog à insérer dans pitch.md/plan.md (consigne contradictoire avec la convention metadata.json introduite en 4.4.0). La timeline vit uniquement dans metadata.json.
• Subagent report-and-sync supprimé — au profit de l'enchaînement direct des skills report et sync en session principale. Ses 235 lignes recopiaient inline report/SKILL.md + sync/SKILL.md (troisième source de vérité qui divergeait déjà).
• Écriture du report.md réparée pour la clôture documentaire — le subagent report-and-sync ne pouvait pas écrire report.md : son permissionMode: acceptEdits (interdit aux agents livrés par un plugin, pour raisons de sécurité) était silencieusement ignoré, si bien que le Write échouait faute de pouvoir demander l'autorisation en contexte délégué. En exécutant report et sync dans la session principale, l'écriture est de nouveau autorisée normalement.
• Extraction des notes de release réparée — la commande gh release create de /forge:release s'appuyait sur une plage awk '/début/,/fin/' dont le motif de début (## [X.Y.Z]) matchait aussi le motif de fin (## [) : la plage se refermait sur la seule ligne de titre et les notes ressortaient vides. Remplacée par une extraction à flag (impression des lignes après l'en-tête de version jusqu'au prochain ## [), avec les points de version échappés.

v4.7.0

Added

• Clone local du repo d'un projet (Forge Board) — depuis le kanban, un bouton clone (ou met à jour via git pull --ff-only) le dépôt d'un projet en local, en tâche de fond (job Messenger async), avec bascule d'état en direct (Live Component, sans reload). Auth git par GIT_ASKPASS (token jamais en argv ni dans .git/config). Premier maillon du pivot productif.
• Expression d'un besoin en interview de cadrage (Forge Board) — depuis un projet cloné, l'utilisateur exprime un besoin en langage libre ; le skill feature-interview tourne en headless (claude -p, ADR-0002) dans le clone local et mène l'interview tour par tour, ancrée sur le code réel. Le brief.md produit est présenté pour relecture puis, à validation, poussé sur une branche dédiée et ouvert en PR draft GitHub (jamais de merge ni d'écriture sur la branche principale). Parcours asynchrone, une interview active par projet.
• Serveur MCP symfony-ai-mate — outillage MCP pour le développement du board (config mcp.json, worker dédié).

Changed

• feature-interview : le skill signale désormais explicitement quand il est prêt à conclure (Phase 3) et respecte une demande explicite de conclusion sans relancer un tour de questions — pour que l'utilisateur, qui sinon ne sait pas quand l'interview se termine, tienne clairement la fin du dialogue.

v4.5.0

Added

• Skill backfill-metadata — reconstruit rétroactivement le metadata.json des stories écrites avant l'introduction du contrat de métadonnées. Déduit le title du H1 du document principal, created/updated de l'historique git du dossier de la story, la timeline changelog de la date d'apparition de chaque artifact (pitch/plan/review/report) avec fusion des jalons de même date, et delivery (commit/release) des commits et tags git. Les tags sont proposés puis validés par l'utilisateur ; aucune date n'est inventée (toujours issue de git) et delivery reste absent si la livraison n'est pas identifiable avec certitude. Ne réécrit jamais un metadata.json valide sauf --force, validation par story avant écriture. Écrit le même schéma v1 que les skills de cadrage (references/story-metadata.md).

v4.4.0

Added

• Métadonnées de story (metadata.json) — chaque story forge porte désormais un fichier metadata.json (schéma v1 versionné : title, created, updated, tags, changelog, delivery) produit et maintenu par les skills via une référence partagée (plugins/forge/references/story-metadata.md). Les skills de création écrivent title/created/tags/première entrée ; chaque passe rebouge updated et append au changelog ; commit/release renseignent delivery. La timeline consolidée vit dans ce fichier — les tables de changelog en pied de pitch.md/plan.md sont abandonnées.
• Cartes de board enrichies (Forge Board) — les cartes affichent le vrai titre, la date de dernière activité, les tags et un badge de livraison (release/commit), lus depuis le metadata.json des stories en un seul appel groupé (GraphQL GitHub, nombre d'appels indépendant du nombre de stories). Le drawer expose le changelog consolidé.
• Filtre par tag et tri par activité (Forge Board) — barre d'outils client-side pour isoler un thème à travers le pipeline et réordonner les cartes par date de mise à jour, sans round-trip.

Changed

• Le lecteur de dépôt (RepositoryReaderInterface) expose readStoryMetadata() (lecture groupée du metadata) ; l'implémentation GitHub devient bi-protocole REST + GraphQL. Une story sans metadata.json, ou avec un fichier invalide, dégrade gracieusement vers le slug humanisé — aucune régression. StoryStageMapper ignore metadata.json : la colonne reste déduite des seuls .md.

v4.3.0

Added

• Kanban d'un projet forge (Forge Board) — à l'ouverture d'un projet, ses stories sont scannées en direct dans le dépôt et projetées en tableau lecture seule à quatre colonnes ordonnées par étape du pipeline, triées par numéro décroissant, avec un bandeau « À vérifier ». Un drawer permet de consulter les documents markdown de chaque story (pitch, plan…), rendus sanitizés. Aucun état persisté : le tableau est recalculé à chaque affichage.
• Déduction de l'étape d'une story depuis ses fichiers (Forge Board) — l'étape de chaque story (pitch → plan → livraison → vérification) est déduite automatiquement des fichiers présents dans son dossier docs/story/, sans aucune saisie manuelle.
• Vérification d'accès et d'éligibilité d'un dépôt (Forge Board) — à la déclaration ou l'édition d'un projet, l'application teste l'accès GitHub (token valide, dépôt atteignable) et confirme que le dépôt suit le workflow forge avant de l'accepter.