miketropi/nextora-ecosystem

Écosystème Nextora — routeur

Coordonne cinq compétences qui partagent une source de vérité unique et un ensemble commun de portes de qualité de production. Ce point d'entrée résout le thème cible, détermine quels spécialistes sont nécessaires pour la demande, et passe la main. Il ne contient pas les règles d'implémentation : celles-ci vivent dans les compétences spécialisées et dans les deux références de cette compétence.

Compétences de cette suite

Compétence	Possède
../nextora-child-themes/SKILL.md	Création ou amorçage d'un thème enfant Nextora : en-têtes, bootstrap, pipeline d'assets, registre de blocs.
../nextora-gutenberg-blocks/SKILL.md	Métadonnées de bloc, UI de l'éditeur, rendu dynamique, répéteurs, panneaux de paramètres, scripts de vue.
../nextora-design-system/SKILL.md	Préréglages de palette/typographie, variations de style, le sélecteur optionnel de couleurs/polices pour le visiteur, surfaces token et CSS.
../nextora-site-composition/SKILL.md	Modèles, parties de modèles, motifs, composition de requêtes/archives.

Preuves et portes partagées pour chaque spécialiste :

• references/source-map.md — d'où viennent les règles, avec provenance.
• references/quality-gates.md — ce qui doit être vrai avant que le travail ne soit accepté.

Flux de travail ordonné

1. Résoudre le thème cible et son parent

Travaillez à partir de l'installation active, ou du référentiel qui vous a été donné. N'inventez jamais un chemin et ne codez jamais en dur un chemin machine dans la sortie ou les notes.

À l'intérieur d'une installation WordPress, les deux racines sont le répertoire de modèles (le parent) et le répertoire de feuilles de style (le thème activé, parent ou enfant) :

get_template_directory();      // racine du thème parent
get_stylesheet_directory();    // racine du thème actif (enfant lorsqu'un est actif)
get_stylesheet_directory_uri();

En dehors d'une installation, localisez le thème par un style.css portant un en-tête Theme Name et, pour un enfant, un en-tête Template: nommant son parent. Si un chemin fourni est manquant, redécouvrez le vrai ; ne fabriquez jamais de preuve source, ne choisissez jamais silencieusement un thème différent, et ne revendiquez jamais la compatibilité Nextora tant que la source Nextora est indisponible — dites que le prérequis est manquant et terminez le travail qui n'en dépend pas.

2. Lire les preuves locales avant de proposer du code

Lisez ces fichiers depuis le thème cible, dans cet ordre, et préférez leurs valeurs actives à tout ce qui est cité dans une compétence :

Fichier	Ce qu'il détermine
style.css	Nom du thème, Version, Template: (parent pour un enfant), Requires at least, Requires PHP, Tested up to, Text Domain, Licence.
functions.php	Ordre de chargement, ce que le thème nécessite en portée de fichier, quels fichiers de fonctionnalités il inclut.
theme.json	Slug de palette, dégradés, famille de polices, taille de police, espacement ; modèles et parties de modèles personnalisés ; version.
package.json	Quelles commandes de construction/vérification existent réellement, et quelles bibliothèques sont déjà des dépendances.
theme.js/.nvmrc, scripts de build	Version de Node et les véritables points d'entrée de construction.
AGENTS.md, README.md, docs/, .opencode/	Instructions du projet. Traitez-les comme des affirmations à vérifier, pas comme une autorité.

Ensuite, trouvez ce qui existe déjà avant de proposer quoi que ce soit de nouveau :

• blocks/*/block.json — blocs enregistrés, leurs noms, catégories, supports.
• parts/*.html, templates/*.html — surfaces de composition et leur hiérarchie.
• patterns/*.php — balisage de section réutilisable.
• resources/css/ + assets/css/ — quelle feuille de style est réellement livrée et comment elle est construite.
• resources/ts/editor/ ou équivalent — outils d'édition partagés à réutiliser plutôt qu'à réécrire (shell de prévisualisation, texte enrichi, média, répéteur).
• inc/ — aides pour les requêtes, la navigation, les modèles.

La réutilisation bat l'invention : un bloc, motif, aide ou token existant qui fait déjà le travail est la réponse correcte, et un nouveau bloc n'est correct que lorsque le comportement demandé ou la structure d'édition ne peut pas être exprimé autrement.

3. Répartir par intention

Demande	Spécialistes à charger
Créer, échafauder ou amorcer un thème enfant ; pipeline d'assets enfant ; enregistrement de bloc enfant	nextora-child-themes
Ajouter/modifier un bloc : block.json, attributs, UI de l'éditeur, render.php, script de vue, répéteur, panneau de paramètres	nextora-gutenberg-blocks
Couleurs, polices, tokens d'espacement, variations de style, le sélecteur visiteur, « doit suivre la palette »	nextora-design-system
Modèles, parties de modèles, motifs, mises en page de page, archives, requêtes de publication	nextora-site-composition

Les demandes combinées chargent tous les spécialistes applicables. Deux combinaisons sont obligatoires :

• Nouvel enfant + toute exigence d'apparence → nextora-child-themes et nextora-design-system. Un enfant qui doit suivre les commutateurs de préréglage ou de visiteur ne peut pas être terminé par la seule compétence enfant.
• Bloc nouveau ou restylisé → nextora-gutenberg-blocks et nextora-design-system. L'apparence du bloc est détenue par le système de conception.

Parce que les spécialistes doivent être d'accord, chargez-les dans la même session et laissez la compétence du système de conception gagner sur toute question d'apparence qu'elle couvre.

4. Charger les références progressivement

Chaque spécialiste est directement invocable ; exécuter ce routeur n'est pas un prérequis. Lorsque vous chargez un spécialiste, ouvrez son SKILL.md, puis lisez uniquement les fichiers de référence que son flux de travail nomme, par chemin relatif. Les deux références partagées ci-dessus sont liées depuis chaque spécialiste, donc les liens relatifs interspécialistes (../nextora-ecosystem/references/...) doivent continuer à résoudre — ne les déplacez pas et ne les renommez pas.

5. Passer la main

Chargez le(s) spécialiste(s), suivez leur flux de travail ordonné, et appliquez references/quality-gates.md avant de déclarer quoi que ce soit comme terminé. Si la demande est purement une question sur l'origine d'une règle, répondez depuis references/source-map.md et arrêtez-vous.

Vérifications d'achèvement

• Thème cible et parent identifiés depuis leur propre style.css/theme.json, non supposés.
• Seuls des fichiers réels et existants sont cités ; tout ce qui est cité comme source a été lu dans cette session.
• Chaque spécialiste applicable a été chargé, y compris les paires obligatoires ci-dessus.
• Le nouveau code réutilise les blocs, motifs, aides et tokens existants là où ils existent.
• references/quality-gates.md appliqué au résultat.
• Rien dans le travail ne dépend de la disposition des fichiers de ce routeur au-delà des liens relatifs ci-dessus.

Limites

Cette suite est une instruction Markdown et une référence basée sur les sources. Elle ne livre aucun script d'exécution, générateur, arbre de thème de démarrage, gestionnaire de paquets ou installateur. Les commandes de construction en aval et de vérification du navigateur appartiennent au thème cible et sont listées dans references/quality-gates.md.