Registre des mandats transversaux (CM-1–CM-28)

Registre canonique des mandats transversaux. Ce document porte le corps complet du registre CM-N ; les énumérations de fond vivent ici et sont rendues opérationnelles par les fichiers de règles sous src/apothem/rules/. Chaque session qui a besoin du corps détaillé de CM-N charge ce document à la demande.

Exemption d'autoréférence du registreCopy Anchor Link

Ce document EST le registre canonique CM-N — c'est la source où les jetons CM-1 à CM-28 sont définis. Réénoncer ces jetons à l'intérieur du corps même du registre est canonique, et non une fuite de terminologie interne aux plans. L'invariant d'isolation de la base de code continue de s'appliquer pleinement à tous les autres artefacts qui ne relèvent pas de la documentation publiée (règles, auxiliaires, commandes, hooks, schémas, scripts, outils, tests, README, CONTRIBUTING, journaux de modifications, sujets/corps de commits, noms de branches, titres/descriptions de PR) : aucun jeton CM-N / TM-N / CP-N, uniquement du langage de domaine naturel.

Les pages de documentation publiées sous site/content/docs/ peuvent citer un mandat par son identifiant CM-N, car ce registre et la page de référence des règles définissent ces identifiants pour les lecteurs. Une page qui cite un identifiant DEVRAIT nommer le mandat en termes simples à côté de celui-ci, et NE DOIT PAS citer les numéros de section internes aux plans d'un mandat. Les jetons TM-N et CP-N restent hors de la documentation publiée, tout comme les autres termes interdits du bloc CM-7 ci-dessous.

Espaces de nomsCopy Anchor Link

CM-N = mandat de configuration (défini ici, ou dans src/apothem/rules/*.md selon la table des règles de site/content/docs/reference/rules.mdx) ; TM-N = mandat de template (défini dans src/apothem/skills/plan-suite/master-template.md §4 « General Mandates », TM-1–28) ; CP-N = principe fondamental (défini dans le même template, §6 « Core Principles », CP-1–27). Le template de la suite de planification est le registre canonique des TM/CP — les commandes /plan résolvent les références croisées via ce fichier. Les artefacts auxiliaires (règles, auxiliaires, commandes, hooks) citent ce registre par référence.

ActivationCopy Anchor Link

CM-1–10 + l'identité cognitive régissent toutes les interactions. CM-11, CM-13 (sous-règles A à C), CM-15, CM-16, CM-20 ne s'appliquent qu'au sein du pipeline /plan. La sous-règle D de CM-13 s'applique à chaque écriture git, et la sous-règle E aux cibles de git mv / git rm et aux chemins du corps des commits, à l'intérieur comme à l'extérieur de ce pipeline. CM-12, CM-14, CM-17–19, CM-21–22, CM-24–26 s'appliquent universellement. CM-23, CM-27, CM-28 s'appliquent universellement dans la portée de filtre de chemin qu'ils déclarent. Niveau de sérieux par défaut en mode ad hoc : PERSONAL_USE. Un mandat s'applique, que sa règle soit chargée ou non au lancement : quatre règles se chargent dans chaque session (agnostic-posture, authority-inquiry, session-closure, context-management), et les autres se chargent sur un chemin correspondant, via l'index des règles, ou via une règle, une skill ou une commande qui les cite.

CM-1–10 (Opérationnels)Copy Anchor Link

(1) Évaluation critique (→TM-10), (2) Zéro hypothèse (→TM-1), (3) Piloté par la configuration (→TM-2), (4) Chercher avant d'implémenter (→TM-4), (5) Meilleure solution (→TM-7), (6) Auto-amélioration (→CP-20), (7) Produit cohérent (→TM-11), (8) Priorité au goulot d'étranglement, (9) Vélocité de décision, (10) Honnêteté brutale. Définitions complètes avec indicateurs de violation : src/apothem/rules/operational-mandates.md.

CM-7 (Isolation interne aux plans)Copy Anchor Link

Il s'agit de la facette de CM-7 tournée vers la base de code ; la facette de complétude du produit est documentée sous le nom Produit cohérent (→TM-11) dans src/apothem/rules/operational-mandates.md §CM-7. Les deux libellés désignent le même mandat.

Les artefacts de la base de code ne doivent JAMAIS contenir de références internes aux plans. Termes interdits (bloc canonique — les consommateurs apparentés renvoient à cette énumération) : TM-N, CM-N, CP-N, « Resumption Contract », « Phase Output Registry », « convention anchors », noms de dossiers de phase, noms de fichiers de la suite de planification (PROGRESS.md, PLAN-NOTES.md, PREAMBLE, MASTER-PLAN), noms de niveaux de sérieux (EXPLORING, PERSONAL_USE, SHARED, PUBLIC_LAUNCH). Artefacts protégés : code source, tests, configurations, schémas, scripts de build, données, ressources, messages de commit, noms de branches, titres/descriptions de PR, README, CONTRIBUTING, documentation d'API, journaux de modifications — tout artefact visible en dehors de l'arborescence des sources d'Apothem (les destinations d'installation par environnement, telles que ~/.claude/ pour Claude Code). Uniquement du langage de domaine naturel. La seule exception est la documentation publiée sous site/content/docs/, qui peut citer des identifiants CM-N comme décrit dans l'exemption d'autoréférence du registre ci-dessus. Consommateurs apparentés (chacun cite ce bloc par référence plutôt que de le réénumérer) : src/apothem/hooks/messages/pretooluse-bash.md, src/apothem/hooks/messages/pretooluse-write.md, src/apothem/hooks/messages/pretooluse-edit.md, src/apothem/hooks/messages/pretooluse-notebookedit.md, src/apothem/rules/operational-mandates.md §CM-7 indicateurs de violation.

CM-11 (Intégrité du plan)Copy Anchor Link

A — Fidélité à la prose : Chaque exigence est traçable prose↔plan. Grille d'évaluation : PASS ≥90% STRONG/0 ABSENT. B — Cohérence interne : Cohérence entre documents au sein de la suite de planification. Grille d'évaluation : PASS 100%. C — Portails : FAIL bloque l'exécution à SHARED+ (dérogation du Product Owner autorisée à SHARED avec justification consignée ; blocage strict à PUBLIC_LAUNCH). Consultatif à PERSONAL_USE.

CM-12 (Gérance du contexte)Copy Anchor Link

Gestion allégée du contexte en permanence — voir la règle CM-24. Quatre sous-paliers sont énumérés dans la section Convention de sous-référence ci-dessous. La discipline de compactage (CM-19) régit l'acte de compacter ; CM-12 régit la discipline en régime permanent.

CM-13 (Commits)Copy Anchor Link

• A — Cadence par tâche : Par tâche à SHARED+. Par phase à PERSONAL_USE. Optionnelle à EXPLORING.
• B — Commits de qualité/remédiation : Les corrections des portails de qualité et les changements de remédiation sont commités immédiatement, séparément du travail de fonctionnalité.
• C — Portail de fin de phase : Aucune modification non commitée ne franchit les limites de phase. L'isolation CM-7 s'applique à tous les artefacts git. À PUBLIC_LAUNCH : commits signés GPG (git commit -S) requis.
• D — Paternité exclusivement humaine : Chaque surface de paternité de chaque artefact git (sujet du commit, corps du commit, Author:, trailer Co-Authored-By:, trailer Signed-off-by:, nom de branche, nom d'étiquette, annotation d'étiquette, nom de stash, corps de git-notes, titre de PR, description de PR) ne nomme que des contributeurs humains. L'assistant ne s'attribue jamais lui-même, ni le modèle de langage sous-jacent, ni le runtime / l'environnement / l'IDE / l'extension / l'éditeur, ni aucun autre outil automatisé, à aucune de ces surfaces. Les motifs interdits sont énumérés et appliqués mécaniquement dans src/apothem/rules/production-ready-prs.md §6 (Commit-Message Discipline → Human-only authorship), avec le détecteur de src/apothem/hooks/messages/pretooluse-bash.md Scan 3 qui se déclenche à chaque invocation Bash qui écrit dans git.
• E — Discipline des préfixes numériques sur les cibles de git-mv / git-rm : Les préfixes numériques (NN-) sur les chemins du système de fichiers expriment un ordre et ne s'appliquent que lorsque l'ordre est intrinsèque — séquences de dossiers de phase, séquences de sous-phases, schémas de nommage ordinal découverts par l'hôte. Les singletons de niveau racine qui n'ont aucune séquence sœur ne portent aucun préfixe numérique ; en ajouter un est une décoration dénuée de sens qui signale à tort une relation d'ordre inexistante. Spécification complète dans src/apothem/rules/canonical-layout.md §2.1. Appliqué mécaniquement dans src/apothem/hooks/messages/pretooluse-bash.md Scan 2 sur git mv / git rm et sur les références de chemin dans le corps du commit.

CM-14 (Protocoles de session)Copy Anchor Link

Début : Exécuter le Blind Bootstrap (CM-24 §6). Fin : Exécuter le Phase Exit (CM-24 §2.5) + l'évaluation de la mémoire (CM-26) + l'évolution des artefacts (CM-22 §2+§4).

CM-15–21 (Pipeline)Copy Anchor Link

CM-15 et CM-16 sont définis en ligne ici (sans règle séparée) ; CM-17–21 délèguent à des règles selon la table des règles de site/content/docs/reference/rules.mdx. Le titre regroupe ces mandats par thème ; leur portée suit le paragraphe Activation : CM-15, CM-16 et CM-20 ne s'appliquent qu'au sein du pipeline /plan, et CM-17–19 et CM-21 s'appliquent universellement.

• CM-15 Cohérence collective : Vérifier que les artefacts du plan restent cohérents après une modification.
• CM-16 Exécution autonome : À SHARED+, ne jamais s'arrêter entre les phases. Compactage obligatoire aux transitions de phase (PERSONAL_USE+).
• CM-17 Équipes de travailleurs : Déployer des équipes de travailleurs délégués pour le travail parallélisable — voir la règle CM-25.
• CM-18 Récupération d'erreurs : Six classes générales (CM-24 §8) ; les classes propres à l'exécution du plan sont dans TM-18. Escalader après 3 échecs.
• CM-19 Discipline de compactage : Déclencheurs de compactage proactif — voir CM-24 §3.
• CM-20 Orchestration du pipeline : prose→[approval]→generate→[approval]→review→[approval]→execute(01→NN). Techniques de revue : src/apothem/rules/planning-techniques.md.
• CM-21 Qualité créative : Les filtres cognitifs sont des portails de qualité, pas une décoration. Mise à l'échelle selon la règle d'identité cognitive, §2.

CM-22–28 (Délégués à des règles)Copy Anchor Link

Ancres d'une ligne pour les mandats délégués à des règles (les spécifications complètes vivent dans les fichiers cités) :

• CM-22 Vigilance des conventions — conventions de l'écosystème et évolution proactive des artefacts. Voir src/apothem/rules/persistent-conventions-vigilance.md.
• CM-23 Génération de fichiers volumineux — protocole d'ajout incrémental pour les fichiers au-delà du seuil d'écriture unique. Voir src/apothem/rules/large-file-generation.md.
• CM-24 Protocole de gérance du contexte — externalisation, compactage, blind bootstrap et discipline budgétaire. Voir src/apothem/rules/context-management.md.
• CM-25 Orchestration des travailleurs — modèles de déploiement, contrats de retour, isolation du contexte. Spécification complète dans la règle d'orchestration des travailleurs.
• CM-26 Cycle de vie de la mémoire automatique — discipline de la mémoire, organisation des fichiers par sujet, évaluation de fin de session. Voir src/apothem/rules/auto-memory.md.
• CM-27 Couches d'architecture propre — séparation Domain / Application / Infrastructure / Presentation. Voir src/apothem/rules/clean-architecture-layers.md.
• CM-28 Architecte senior Python — garde-fous SOLID, de style, de tests et de sécurité pour les artefacts Python. Voir src/apothem/rules/code-craft-python.md.

Mandats délégués à des règles vs. mandats définis en ligneCopy Anchor Link

• Délégués à des règles (spécification complète dans src/apothem/rules/) : voir la colonne « Implements » de la table des règles de site/content/docs/reference/rules.mdx. Couvre CM-1–10, CM-12, CM-14, CM-17–28.
• Définis en ligne (spécification complète ici, sans règle séparée) : CM-11 (Intégrité du plan), CM-13 (Commits ; les sous-règles D et E renvoient à des fichiers de règles pour leur spécification détaillée), CM-15 (Cohérence collective), CM-16 (Exécution autonome).

Convention de sous-référenceCopy Anchor Link

Les commandes utilisent des suffixes alphabétiques pour référencer des sous-sections précises au sein des mandats. Schéma : CM-N + lettre de suffixe = section de règle. Convention de casse : Les suffixes en majuscule désignent des sous-sections structurelles au sein d'un mandat ; les suffixes en minuscule désignent des directives plus fines au sein d'un palier de gérance. La table canonique de correspondance des clés de sous-référence (définitions internes au registre) figure dans le bloc délimité ci-dessous :

CM-11A = Prose Fidelity
CM-11B = Internal Consistency
CM-11C = Gates

CM-12a = lean ingestion / demand loading (context-management §7.2)
CM-12b = budget awareness (§7.1)
CM-12c = budget pressure response (§7.3)
CM-12d = per-task effort calibration (context-management §7.4 — D3 stratified taxonomy; PHASE.md frontmatter is the per-phase override surface)

CM-13A = per-task commits
CM-13B = quality / remediation commits
CM-13C = end-of-phase commit gate
CM-13D = human-only authorship
CM-13E = numeric-prefix discipline on git mv / git rm targets

CM-23A = pre-generation size assessment (§1)
CM-23B = incremental generation protocol (§2)

CM-24B = proactive externalization (§2)

CM-25A = worker-team patterns (§1)
CM-25C = return-contract enforcement (§4)
CM-25E = isolation / non-duplication (§5)