Liste de contrôle de déploiement

Étapes de vérification préalables au déploiement de l'écosystème Apothem sur une nouvelle machine, à son partage avec d'autres ou à son traitement comme prêt pour la production.

1. Validité du YAMLCopy Anchor Link

• Tous les fichiers de règles s'analysent sans erreur YAML — le bloc frontmatter ouvre par ---, ferme par --- et ne contient aucun contenu orphelin en dehors du bloc
• Tous les fichiers de travailleurs délégués s'analysent sans erreur YAML
• Tous les fichiers de commande s'analysent sans erreur YAML
• Tous les fichiers SKILL.md de compétences s'analysent sans erreur YAML

Vérification : python scripts/dev/validate_ecosystem.py analyse le frontmatter de chaque artefact et signale les erreurs YAML et les champs requis manquants. Pour une détection ad hoc des éléments de liste orphelins : rg -n "^- " src/apothem/rules/*.md.

2. Complétude du frontmatterCopy Anchor Link

Pour chaque type d'artefact, vérifiez que les champs requis sont présents :

Règles (src/apothem/rules/*.md)Copy Anchor Link

• name — identifiant en kebab-case correspondant au nom du fichier
• description — résumé d'une seule phrase
• alwaysApply — true pour les règles toujours actives, false pour les règles filtrées par chemin
• pathFilter — présent sur chaque règle : "" pour les règles toujours actives (alwaysApply: true), une liste de globs séparés par des virgules pour les règles filtrées par chemin (alwaysApply: false)

Les règles ne comportent aucune clé version, updated, scope ni portability.

Commandes (src/apothem/commands/*.md)Copy Anchor Link

• name — nom de commande en kebab-case
• version, updated, description, argument-hint, portability, allowed-tools présents
• disable-model-invocation présent et intentionnel (false pour les commandes en lecture seule ou consultatives ; true uniquement lorsque l'exécution de la commande modifie l'état en dehors de l'arbre de travail ou dépend du moment choisi par l'opérateur)
• Aucune clé effort : command.schema.json fixe additionalProperties: false et ne l'admet pas

Travailleurs déléguésCopy Anchor Link

Chemin :

src/apothem/agents/*.md

• name, version, updated, description présents
• tools — liste séparée par des virgules des outils autorisés
• disallowedTools — liste explicitement les outils interdits
• maxTurns — défini (avec un commentaire de justification si > 10)
• permissionMode — ne doit PAS être "bypassPermissions" ; laissez la clé non définie, car la posture agnostique ne préconfigure aucun mode de permission
• memory omis sauf si la mémoire persistante est intentionnelle ; lorsqu'il est défini, l'une des valeurs user, project, local (pas de forme booléenne)

Compétences (src/apothem/skills/*/SKILL.md)Copy Anchor Link

• name, version, updated, description, archetype, disable-model-invocation, allowed-tools présents
• userInvocable déclaré (true/false). L'orthographe source est userInvocable ; un skill porte exactement l'une des deux clés userInvocable ou user-invocable (l'orthographe propre à Claude Code).

3. SécuritéCopy Anchor Link

• Aucun travailleur délégué n'utilise permissionMode: "bypassPermissions" — cela contourne la confirmation interactive des opérations Write/Bash
• Les listes tools du travailleur sont minimales — uniquement les outils dont le travailleur a réellement besoin
• Les travailleurs disposant d'un accès Bash sont justifiés et ont des limites maxTurns
• Aucun chemin, jeton ou secret codé en dur dans un quelconque artefact
• Les hooks dans settings.json ont des délais d'attente raisonnables (≤ 60 secondes) et n'exécutent pas de code arbitraire issu de l'entrée utilisateur

4. Intégrité des références croiséesCopy Anchor Link

• Chaque règle listée dans le tableau src/apothem/rules/ existe sur le disque au chemin indiqué
• Chaque commande listée dans le tableau src/apothem/commands/ existe sur le disque
• Chaque travailleur délégué listé dans le tableau de registre src/apothem/agents/ existe sur le disque
• Chaque compétence listée dans le tableau src/apothem/skills/ existe sur le disque
• Chaque hook du tableau src/apothem/hooks/ a une entrée correspondante dans settings.json
• Tous les fichiers src/apothem/rules/*.md existent et résolvent leurs références croisées Bindings

5. Couverture des mandatsCopy Anchor Link

• Chaque mandat CM-N a un emplacement d'application (soit un fichier de règle, soit une définition inline explicite)
• Aucun fichier de règle n'en contredit un autre (en particulier autour de la mise à l'échelle du sérieux)
• La délimitation en trois facettes de CM-21 est respectée — aucune règle ne revendique la propriété de la facette CM-21 d'une autre règle

6. Tests de fumée fonctionnelsCopy Anchor Link

Exécutez d'abord la surface de validation Python — elle est rapide, hors ligne et détecte les régressions structurelles :

• pytest tests — tests unitaires du runtime des hooks, tous au vert
• python scripts/dev/validate_hooks.py — structure des hooks + contrôle d'hygiène Python uniquement réussis
• python scripts/dev/validate_ecosystem.py — arbre complet + frontmatter + contrôles des hooks délégués réussis
• python scripts/dev/chaos_pass.py — chaque commande de hook configurée renvoie une enveloppe JSON valide sous des entrées dégradées

Ensuite, des scénarios en direct :

• /plan-spec <sample-file> — termine l'ingestion et la clarification sans erreur au niveau des commandes
• /plan-generate --dry-run — produit un aperçu de structure sans écrire de fichiers
• /plan-status sur une suite de planification complète — renvoie des décomptes de phases exacts
• Répartition vers un travailleur délégué : le travailleur codebase-explorer invoqué avec une petite portée se termine dans maxTurns et renvoie une sortie structurée

7. Actualité de la documentationCopy Anchor Link

• CHANGELOG.md (à la racine de l'écosystème) reflète chaque modification d'artefact depuis la dernière version publiée ; la section de la prochaine version est renseignée avant la pose du tag, ou chaque modification est déjà intégrée à une section publiée
• site/content/docs/developer-guide.mdx décrit précisément la structure actuelle des artefacts
• site/content/docs/reference/artifact-schema.mdx correspond aux champs frontmatter réellement présents dans les artefacts
• site/content/docs/reference/settings-reference.mdx correspond à la configuration réelle des hooks dans settings.json
• README.md est cohérent avec l'arbre sur le disque

8. Portabilité (en cas de partage avec d'autres)Copy Anchor Link

• Tous les chemins dans les commandes de hook sont indépendants de l'environnement ou utilisent l'expansion de ~
• Les commandes de hook utilisent la forme exec et évitent les chaînes de commande propres à un shell
• Aucun chemin codé en dur C:\Users\username ou /home/username dans un quelconque artefact
• settings.json utilise un seul tableau de couverture des événements de hook et le chemin canonique du module de répartition

9. Alignement des versionsCopy Anchor Link

• La version de CLAUDE.md est la plus élevée de tout artefact de l'arbre (ou égale à la version de l'artefact le plus récemment incrémenté, par convention)
• La version de chaque artefact correspond au semver indiqué (MAJOR.MINOR.PATCH)
• CHANGELOG.md contient exactement l'entrée de version pour la version cible avant le tagging
• Le champ updated de chaque artefact est à la date de sa dernière modification changeant le comportement, ou après
• Aucun artefact ne porte une version inférieure à la version à laquelle il a été touché pour la dernière fois (aucune régression)
• src/apothem/skills/plan-suite/SKILL.md et src/apothem/skills/plan-suite/master-template.md sont épinglés à la même ligne de version de modèle

ValidationCopy Anchor Link

Déploiement approuvé par : ___________________ Date : ___________________ Version de l'écosystème déployée : ___________________