Méthodologie Ezkey

Valeurs méthodologiques

Les valeurs canoniques vivent dans le corpus méthodologique Ezkey. Cette vue garde les tests opératoires visibles : assez de rigueur pour préserver le jugement et la traçabilité, sans assez de cérémonie pour ralentir le travail simple.

Flux de travail de bout en bout Couloir A

Neuf phases explicites avec sorties d’artefacts et critères de sortie. Passez à l’implémentation dès que la direction, la premier découpage, les critères de validation et les questions ouvertes non bloquantes sont établis — en évitant autant le code prématuré que la préparation perpétuelle.

Types d’artefacts

Tous les artefacts canoniques utilisent des identifiants date+slug. Aucun compteur global n’est requis. Les identifiants sont stables — jamais renommés après création, jamais réutilisés.

Couloirs parallèles

Quatre couloirs s’exécutent en parallèle du flux principal d’idéation à livraison. Une session peut combiner le couloir A avec un ou plusieurs de ces couloirs selon le besoin.

Contexte de collaboration

Pas un couloir — un modificateur transversal. Ces règles s’appliquent en plus des couloirs A, B, C et D quand la collaboration se fait sur des branches Git parallèles ou des worktrees. Le couloir E reste généralement géré en branche unique puisqu’il modifie la méthodologie elle-même.

Conventions de nommage

Identifiants stables et résistants aux collisions sur toutes les branches et worktrees. Les artefacts hérités NNNN ne sont jamais renommés.

Traçabilité bidirectionnelle

Le flux n’est pas seulement un pipeline vers l’avant. La clôture et l’audit doivent aussi prouver d’où vient un artefact, quel canon l’a absorbé et si des décisions ultérieures ont changé son sens.

Contrats de frontières des compétences

Chaque compétence répond aux quatre mêmes questions : entrer quand, sortir quand, appeler ensuite et inutile quand. Le texte canonique des compétences vit sous .cursor/skills/; ce tableau est la surface de navigation rapide.

Vues enrichies

Compagnons HTML aux documents Markdown sources, créés lorsque la richesse visuelle améliore matériellement la clarté et l’alignement conceptuel entre collaborateurs humains et IA. La base méthodologique reste Markdown d’abord — les vues enrichies sont des suppléments délibérés, pas des remplacements.

Quand créer une vue enrichie

• Relations d’entités complexes — plusieurs types d’entités interdépendants avec interactions de cycle de vie difficiles à suivre seulement en prose ou tableaux.
• Machines d’état et gouvernance de cycle de vie — transitions d’état, règles d’activation/désactivation, propagation en chaîne parent entre types d’entités.
• Flux cryptographiques ou protocolaires — flux multi-acteurs avec transit de matériel de clé, fenêtres de synchronisation et contraintes de séquençage où un diagramme ancre la compréhension.
• Décisions architecturales à fort impact — décisions transversales avec complexité visuelle qui bénéficient d’un ancrage graphique durable.
• La méthodologie elle-même — le processus et le système d’artefacts bénéficient d’une référence visuelle accessible aux humains et aux agents IA au début d’une session.

Convention de dossier et de lien

Principes de conception

• Autonome — aucune dépendance CDN externe. Intégrer tous les styles et tous les SVG.
• Palette sobre — l’information d’abord. La couleur sert la distinction, pas la décoration.
• Lié depuis le parent Markdown — le document source porte une référence claire vers la vue enrichie.
• Mis à jour dans le même ensemble de changements — lorsque le document parent change, la vue enrichie est mise à jour avec lui.
• Un seul index.html par dossier de vue; fichiers additionnels seulement si la navigation ajoute vraiment de la valeur pour le sujet.