Positionnement

Public : évaluateurs qui décident d'adopter ou non apothem pour du travail de production piloté par un assistant. Durée : ~12 minutes de lecture de bout en bout. Se parcourt section par section. Objet : cadrer ce qu'apothem EST réellement, ce qu'il N'EST PAS, et pourquoi la réponse à « que distribue ce projet ? » diffère structurellement de celle que donnent la plupart des projets d'outillage de gouvernance.

§1. ThèseCopy Anchor Link

apothem est une gouvernance de ratification d'artefacts, empaquetée sous forme de binaire.

Le cadrage conventionnel de l'outillage pour assistants est le réglage de prompts : un prompt système, un choix de modèle, une stratégie de fenêtre de contexte, une petite bibliothèque de slash-commands et un tas de folklore d'ingénierie de prompts. Dans ce cadrage, le point de levier de l'opérateur est la prose qu'il remet au modèle. Quand le modèle se comporte mal, la réparation consiste à modifier cette prose. L'artefact que le projet distribue est le jeu de prompts.

apothem rejette ce cadrage.

Le point de levier d'un assistant qui travaille sur un vrai projet n'est pas la prose que l'opérateur remet au modèle — c'est l'artefact que le modèle s'apprête à émettre. Cet artefact va atterrir dans un espace de travail, être commité, relu, fusionné, déployé, cité par des artefacts en aval, hérité par de futurs contributeurs. Sa qualité est une propriété irréversible en aval, que le prompt ne peut pas réparer après coup. Modifier le prompt après l'arrivée d'un commit malformé est une taxe imposée à l'opérateur, et non une récupération de l'artefact.

La discipline que ce projet encode est l'inversion : chaque émission passe par un portail structuré, convenu et vérifié mécaniquement avant de quitter les mains de l'assistant. Le portail applique quinze mandats qui couvrent la découverte de l'hôte, la divulgation, dix dimensions de qualité, l'auto-application, l'hygiène d'autorité, l'incorporation d'expertise, l'annotation des options, le caractère définitif, le levier visuel, la liaison bidirectionnelle, l'appareillage de sprint agile, l'agencement canonique, le métier du code, la participation systémique et la préparation à la production. Chaque mandat est une règle, dotée d'une portée filtrée par chemin et d'un corps qui opérationnalise une classe d'échec précise. Chaque échec du portail est un constat structurel que l'assistant fait remonter — jamais une dégradation silencieuse.

Le corpus de règles EST le produit. Le binaire apothem en est l'empaquetage — une surface de distribution qui achemine le corpus jusqu'à la racine de configuration utilisateur de chaque opérateur et l'enregistre comme posture opérationnelle de l'assistant. L'empaquetage est remplaçable ; le corpus est l'actif de longue traîne.

Un projet qui adopte apothem n'adopte pas un prompt. Il adopte un régime de gouvernance. Chaque artefact que l'assistant émet dans le dépôt hôte — code, tests, configuration, schémas, documentation, runbooks, messages de commit, noms de branche — respecte le même plancher de quinze barres. Le point de levier de l'opérateur passe de « que dois-je dire à l'assistant ? » à « quels mandats contraignent cette émission, et quelle preuve le portail exige-t-il ? ». Ce déplacement est structurel, non stylistique.

Ce document explique pourquoi le corpus est l'actif porteur, parcourt les quinze mandats avec leurs ancres de fichier de règle, et met en avant les deux disciplines transversales (le traitement des entrées par canal canonique et l'architecture créative d'identité cognitive) qui lient le corpus en un tout cohérent.

§2. Architecture à trois piliersCopy Anchor Link

Le corpus repose sur trois piliers. Chaque pilier est une surface séparable dotée de sa propre spécification canonique ; chaque pilier renforce les deux autres.

Pilier A — Le registre des mandats (M1–M15 + CM-1..CM-28)Copy Anchor Link

Le registre des mandats est la surface de gouvernance de l'axe externe. M1–M15 gouvernent chaque artefact que l'assistant produit dans un projet hôte : découverte de l'hôte, divulgation, dix dimensions de qualité, auto-application, autorité, expertise, annotation des options, caractère définitif, levier visuel, liaison bidirectionnelle, sprints agiles, agencement canonique, métier du code, participation systémique et préparation à la production. Le registre est canonisé sous la forme du registre de quinze mandats et opérationnalisé par les fichiers de règles énumérés au §3 ci-dessous.

CM-1..CM-28 sont les contreparties de l'axe interne — des mandats opérationnels qui gouvernent la discipline d'interaction de l'assistant (évaluation critique, zéro hypothèse, chercher avant d'implémenter, évaluation de la meilleure solution, honnêteté brutale, vélocité de décision, priorité au goulot d'étranglement, produit cohérent, et vingt autres entrées couvrant la localité des plans, la gérance du contexte, l'orchestration du travail délégué, la génération de fichiers volumineux et le cycle de vie de la mémoire). L'axe interne est canonisé dans la règle des mandats opérationnels et dans site/content/docs/governance/cross-cutting-mandates.mdx.

Chaque émission passe par les deux axes. Le portail situé à src/apothem/rules/pre-emission-gate.md exécute à chaque émission les quinze barres, mécaniques et raisonnées, et consigne un bloc de vérification dans la trace de travail de l'artefact.

Pilier B — La discipline du canal canoniqueCopy Anchor Link

La discipline du canal canonique régit la façon dont l'assistant sollicite l'entrée de l'opérateur. Les prompts en format libre sont retirés dans tout l'écosystème ; chaque choix passe par le canal d'interrogation structurée, avec un schéma structuré d'annotation des options (justification + recommandation + pointeur par défaut pour chaque option), une taxonomie fermée des recommandations, un plancher de confirmation par fichier pour les opérations destructrices, et un balayage heuristique qui détecte la dérive vers les prompts conversationnels sur chaque surface gouvernée. La spécification complète se trouve à src/apothem/rules/interactive-questions.md, la profondeur étant portée par les compagnons filtrés par chemin src/apothem/rules/interactive-questions-canonical-shapes.md et src/apothem/rules/interactive-questions-sweep-matchers.md.

Le levier de cette discipline est l'auditabilité de la décision. Chaque choix volontaire de l'opérateur porte les éléments que l'assistant a examinés, la recommandation que l'assistant a émise et la justification fondée sur des facteurs concrets. Six mois après le choix, un auditeur qui lit le grand livre de divulgation peut reconstituer la frontière de la décision sans faire appel à la mémoire de l'opérateur.

Pilier C — La taxonomie d'identité cognitiveCopy Anchor Link

La taxonomie d'identité cognitive régit la façon dont l'assistant pense. Cinq filtres cognitifs séquentiels (Purge de l'Évident, Exil de Domaine, Presse d'Inversion, Explosion Combinatoire, Exigence Esthétique) composent une cadence créative. Le premier et le dernier filtre s'appliquent à chaque sortie substantielle ; les trois filtres intermédiaires s'appliquent aux décisions non triviales. Six techniques d'idéation (Saboteur Historique, Paradoxe de la Contrainte, Lentille des Systèmes Vivants, Récit de Second Ordre, Cadrage du Méchant, Zoom à 100 Ans) se déclenchent sur des signaux de détection lorsque l'approche standard a donné un résultat insatisfaisant. Sept axes d'ampleur (Architecture, Concurrence, Performance, Sécurité, Tests, Outillage, Observabilité) constituent la surface de profondeur au regard de laquelle chaque décision non triviale est attestée. La spécification complète se trouve à src/apothem/rules/cognitive-identity.md, la profondeur étant portée par le compagnon filtré par chemin src/apothem/rules/cognitive-identity-techniques.md.

Le levier de la taxonomie est la nouveauté structurelle. Le filtre de Purge de l'Évident écarte la réponse de première idée vers laquelle tout le monde se tourne ; la Presse d'Inversion exige qu'au moins une hypothèse inversée survive dans la sortie finale ; l'Exigence Esthétique rejette les formes fonctionnelles mais oubliables. Le résultat est un assistant qui produit des sorties que les opérateurs s'arrêtent pour relire — non parce que la prose est décorée, mais parce que le choix structurel n'a rien d'évident, d'une manière qui, une fois perçue, paraît inévitable.

Comment les piliers se renforcent mutuellementCopy Anchor Link

Les trois piliers sont mutuellement porteurs. Le registre des mandats (pilier A) définit ce que l'artefact doit satisfaire. La discipline du canal canonique (pilier B) définit comment l'entrée de l'opérateur pénètre la surface de décision qui produit l'artefact. La taxonomie d'identité cognitive (pilier C) définit la cadence créative qui donne sa forme à l'artefact. Retirer un seul pilier fait s'effondrer les deux autres : un registre sans canal canonique produit des artefacts dont les valeurs par défaut ont été retenues en silence, qui paraissent conformes mais dissimulent des décisions structurelles ; un canal canonique sans profondeur cognitive produit des sorties correctement acheminées mais de forme générique ; une cadence cognitive sans registre produit des artefacts esthétiquement élégants qui échouent à s'intégrer au projet hôte.

§3. Parcours du registre des mandatsCopy Anchor Link

Le registre de quinze mandats est la surface canonique de gouvernance de l'axe externe. Chaque sous-section ci-dessous nomme le mandat, sa portée opérationnelle et le fichier de règle qui porte la spécification canonique. Chaque fichier de règle est filtré par chemin sur les classes d'artefacts qu'il gouverne et chargé à la demande dans le contexte opérationnel de l'assistant lorsque ces classes sont touchées.

M1 — Agnosticisme vis-à-vis du projet hôte et découverte des conventionsCopy Anchor Link

Portée. Tout ce que l'assistant produit dans un projet hôte est façonné par ce que le projet hôte est déjà — sa pile technique, son langage, son framework, sa toolchain, son outil de formatage, son linter, son framework de tests, son générateur de documentation, sa stratégie de branches, sa convention de messages de commit, son agencement, sa nomenclature, sa politique d'épinglage des dépendances. Chacun est découvert à partir de la source de vérité faisant autorité de l'hôte (manifestes, fichiers de verrouillage, fichiers frères de nature comparable, documents de convention au niveau du dépôt) et respecté. Lorsque l'hôte est muet sur une convention que l'assistant doit adopter, ce silence remonte sous forme de demande faisant autorité, au titre de M5 — il n'est jamais résolu en choisissant en silence une valeur par défaut interne.

Spécification canonique. src/apothem/rules/host-discovery.md (avec le catalogue de manifestes par langage à src/apothem/rules/host-discovery-manifests.md).

Pourquoi c'est important. L'émission de l'assistant est indiscernable de celle qu'aurait écrite un contributeur de longue date du projet hôte. La dérive de convention est un échec structurel, et non une préférence stylistique.

M2 — Discipline éditoriale et amendements divulguésCopy Anchor Link

Portée. Toute modification d'une portée significative porte un grand livre de divulgation explicite — ce qui a été demandé, ce qui a été amendé, ce qui a été étendu, ce qui a été affiné, ce qui a été différé. La sur-conformité silencieuse (« a fait exactement ce qui était demandé, même si c'était faux ») et le débordement silencieux (« a élargi la portée de la modification sans le dire ») sont tous deux des échecs. Chaque amendement porte une justification au niveau d'exigence académique / technique (référence citée, RFC, documentation de l'éditeur, précédent d'un fichier frère, motif nommé issu de la littérature).

Spécification canonique. src/apothem/rules/disclosure-ledger.md (avec le catalogue des classes de marqueurs à src/apothem/rules/disclosure-ledger-markers.md).

Pourquoi c'est important. Un diff qui corrige discrètement un bug voisin tout en implémentant la modification demandée est un amendement non divulgué. Six mois plus tard, un relecteur ne peut pas distinguer la correction délibérée de la dérive. Le grand livre est la surface d'audit et de récupération.

M3 — Les dix dimensions de qualitéCopy Anchor Link

Portée. Chaque artefact est évalué selon dix dimensions de qualité avant l'émission : rigueur scientifique, consistance / cohérence / intégration / validité, configurabilité / non-redondance / consolidation, lisibilité / intuition / propreté, orphelinat / obsolescence, structuralité / systémicité / uniformité / exhaustivité, architecture, uniformité de nomenclature, référencement académique / technique, et exemples / tests / docstrings / documentation. L'échec d'un même artefact sur plusieurs dimensions est multiplicatif, et non additif — un artefact à la fois obsolète ET orphelin ET nommé de façon incohérente ET non documenté est candidat au retrait, non à la réparation.

Spécification canonique. src/apothem/rules/ten-dimension-check.md (avec le corps de chaque dimension à src/apothem/rules/ten-dimension-check-dimensions.md).

Pourquoi c'est important. La qualité est décomposable. Nommer les dix dimensions rend chacune auditable et signalable isolément ; les constats ambigus du type « ça paraît faible » deviennent des constats précis du type « dimension 5, obsolescence : la référence à la ligne 42 pointe vers un fichier déplacé ».

M4 — Auto-application — portail de pré-émissionCopy Anchor Link

Portée. Chaque artefact passe un portail de pré-émission à quinze barres avant son émission. Les barres mécaniques (M5, M7, M8, M10, M13) portent des matchers exécutables dans src/apothem/conformity/*-grep.py, orchestrés par src/apothem/conformity/gate.py. Les barres M3, M9, M12, M14 et M15 sont en partie mécaniques : des matchers exécutables couvrent une partie de chaque barre, et l'assistant opérant évalue le reste. Les barres raisonnées (M1, M2, M4, M6, M11) n'ont pas de matcher ; elles sont évaluées par l'assistant opérant et consignées dans le bloc de vérification. La barre M4 vérifie elle-même que le bloc de vérification est présent dans la trace de travail de l'artefact. L'échec d'une seule barre bloque l'émission ; l'itération se poursuit jusqu'à ce que chaque barre passe.

Spécification canonique. src/apothem/rules/pre-emission-gate.md (avec la table complète des barres à src/apothem/rules/pre-emission-gate-bars.md).

Pourquoi c'est important. La qualité est une préoccupation de pré-émission, et non une préoccupation en aval du type « l'utilisateur pourra réviser ». Le portail est la traduction structurelle de cette conviction en application mécanique.

M5 — Principe d'autorité (Demander, ne pas inventer)Copy Anchor Link

Portée. Noms, adresses e-mail, identifiants de compte, noms d'hôte, organisations, locataires, endpoints, identifiants d'accès, direction de la portée, choix de nomenclature que l'hôte n'a pas encore arrêtés, politiques de rétention, épinglages de version sur des surfaces modifiables par l'hôte, décisions d'infrastructure que l'utilisateur n'a pas déclarées — aucun n'est inventé. Chacun est soit découvert à partir d'une source de vérité faisant autorité dans l'hôte (moitié « découverte » de M1), soit demandé à l'utilisateur (moitié « demande » de M5) — jamais masqué par une supposition d'apparence plausible.

Spécification canonique. src/apothem/rules/authority-inquiry.md (avec le catalogue de sept catégories à src/apothem/rules/authority-inquiry-categories.md).

Pourquoi c'est important. L'identité, la sécurité, la direction de la portée et la nomenclature des surfaces publiques ont un poids juridique et d'audit. Une adresse de contact devinée, un identifiant CODEOWNERS fabriqué ou un endpoint de signature de publication inventé entraîne en aval un nettoyage qui coûte des ordres de grandeur de plus que la demande n'aurait coûté.

M6 — Incorporation d'expertiseCopy Anchor Link

Portée. Chaque artefact de portée significative lit l'intention de l'utilisateur avant le texte littéral, amende de façon proactive lorsque la demande littérale laisserait un défaut connu, étend sur les lacunes voisines, affine avec une justification citée, anticipe les conséquences de second ordre, calibre la profondeur selon la tâche et importe des leçons de domaines voisins — en divulguant chaque amendement via le grand livre de M2.

Spécification canonique. src/apothem/rules/expertise-posture.md (avec sept sous-éléments + l'échelle de calibration à src/apothem/rules/expertise-posture-elements.md).

Pourquoi c'est important. L'expertise sans divulgation est un passage en force silencieux. L'expertise avec divulgation est un levier — l'opérateur voit l'amendement, évalue la justification, puis le ratifie ou l'annule. L'assistant agit comme un contributeur senior dont le jugement est auditable, et non comme un substitut opaque à l'intention de l'opérateur.

M7 — Discipline d'annotation des optionsCopy Anchor Link

Portée. Chaque choix à plusieurs options que l'assistant fait remonter — dans les réponses en prose, les ADR, les sections de README, les descriptions de PR, les documents de conception, les étapes de runbook, les commentaires de code, les corps de messages de commit, les RFC — porte le marqueur canonique de recommandation sur l'option recommandée, assorti d'une justification liée à des principes. Les choix silencieux et les listes d'options non annotées sont interdits sur tout territoire faisant autorité.

Spécification canonique. src/apothem/rules/option-annotation.md (avec la forme pour la prose et les documents à src/apothem/rules/option-annotation-form.md).

Pourquoi c'est important. Chaque ensemble d'options rédigé est une surface d'audit. Le lecteur voit non seulement le choix, mais aussi l'espace des alternatives, la recommandation et le facteur concret qui la fonde. La même discipline régit les invocations du canal d'interrogation structurée par l'assistant et la prose rédigée dans les artefacts permanents.

M8 — Caractère définitif, étanchéité et famille des vertus des systèmes rigoureuxCopy Anchor Link

Portée. Chaque énoncé est définitif (aucune précaution oratoire là où une prescription contraignante est possible) et étanche (aucune lacune dans les domaines déclarés, aucune faille où le respect de la lettre viole l'intention, aucune hypothèse non déclarée, aucune égalité de préséance, aucun repli silencieux). La liste du vocabulaire de précaution oratoire est détectée mécaniquement par le portail ; chaque occurrence dans une prose prescriptive se résout par l'une de trois voies — promouvoir en inconditionnel en nommant les conditions, rétrograder en conditionnel explicite en énumérant les branches, ou supprimer et renvoyer le choix vers la surface de demande.

Spécification canonique. src/apothem/rules/definitiveness.md (avec le catalogue de sept vertus à src/apothem/rules/definitiveness-virtues.md).

Pourquoi c'est important. Une prose prescriptive assortie de précautions oratoires est une taxe pour chaque lecteur. Le lecteur ne peut pas savoir si la précaution concède un véritable conditionnel ou signale une incertitude de l'auteur. La discipline oblige l'auteur à nommer la condition ou à retirer la prescription — dans les deux cas, le lecteur obtient un énoncé contraignant.

M9 — Levier visuelCopy Anchor Link

Portée. Lorsque le sujet est structurel — architecture, flux de contrôle, flux de données, graphe de dépendances, machine à états, séquence, arbre de décision, hiérarchie, pile de préséance, cycle de vie, matrice de permissions — l'artefact porte un diagramme aux côtés de la prose. Mermaid est le choix par défaut recommandé pour les corpus centrés sur Markdown ; la notation existante de l'hôte est respectée selon la découverte de M1. Chaque diagramme porte une provenance, une date de vérification et une liaison de retour vers l'artefact qu'il abstrait.

Spécification canonique. src/apothem/rules/visual-leverage.md.

Pourquoi c'est important. Une description d'architecture de deux mille mots sans diagramme est une sous-utilisation systématique du médium et un échec structurel de l'artefact, et non une préférence stylistique. Les relations spatiales sont illisibles en prose linéaire ; le diagramme est une sortie de première classe à part entière, et non une décoration.

M10 — Liaison bidirectionnelle et enchaînement de l'exécution des phasesCopy Anchor Link

Portée. Chaque élément structurel substantiel porte des liaisons réciproques vers ses pairs, dans la notation canonique à cinq directions : Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. Chaque liaison déclarée dans un sens a un pointeur de retour réciproque à l'autre extrémité ; les demi-arêtes sont des échecs structurels, et non des préférences esthétiques. Un grep mécanique de réciprocité, à src/apothem/conformity/binding_reciprocity_grep.py, applique cet invariant au portail.

Spécification canonique. src/apothem/rules/bidirectional-binding.md.

Pourquoi c'est important. Les liaisons réciproques transforment le corpus en graphe navigable. La ligne Cross-bound with ↔ de toute règle pointe vers chaque pair qui la cite, et chaque pair cité pointe en retour. Refactoriser le corpus devient mécanique — renommez une règle, et le grep de réciprocité signale chaque citation périmée dans le même ensemble de modifications.

M11 — Sprints agiles et contrôle empirique des processusCopy Anchor Link

Portée. Le travail non trivial en plusieurs étapes s'exécute sous forme de sprints agiles disciplinés, avec les sept éléments canoniques : Objectif du sprint (orienté résultat, testable), Backlog du sprint (au format INVEST, priorisé), Definition of Ready (portail d'entrée du sprint), Definition of Done (portail de sortie du sprint), Revue de sprint (approuvé / rejeté / reporté pour chaque élément), Rétrospective de sprint (continuer / arrêter / commencer), Suivi de la vélocité (un signal, jamais une cible). Trois piliers du contrôle empirique des processus — transparence, inspection, adaptation — opèrent de bout en bout.

Spécification canonique. src/apothem/rules/agile-sprints.md (avec le corps des éléments à src/apothem/rules/agile-sprints-elements.md).

Pourquoi c'est important. Un diff massif étalé sur plusieurs jours, sans structure de sprint, est opaque à la relecture. L'appareillage fait remonter chaque incrément, chaque critère d'acceptation, chaque rejet au moment où il survient — et non reporté à une rétrospective tenue bien après que la décision structurelle est devenue irréversible.

M12 — Niveaux de rapport et agencement canonique des sorties généréesCopy Anchor Link

Portée. Le travail non trivial en plusieurs étapes émet des rapports à deux niveaux : un rapport par sous-phase au niveau de travail, et une consolidation au niveau de la phase, au niveau de relecture, qui agrège au lieu de concaténer — modèle uniforme entre les sous-phases, métriques agrégées, motifs mis en évidence, auto-vérification au niveau de la phase, déclarations vers l'extérieur. Les sorties générées se trouvent à des emplacements canoniques prévisibles, découverts dans l'hôte, avec provenance et références croisées réciproques. Les sorties orphelines (artefacts sans consommateur / sans entrée d'index / sans attribution de producteur) sont des échecs structurels.

Spécification canonique. src/apothem/rules/canonical-layout.md (avec le corps des niveaux de rapport à src/apothem/rules/canonical-layout-reporting-tiers.md).

Pourquoi c'est important. Une liste plate de report1.md / report2.md à des emplacements improvisés est illisible six semaines plus tard. La discipline à deux niveaux, associée à l'agencement canonique de l'hôte, fait que chaque sortie est retrouvable, que chaque consommateur est nommé et que chaque producteur est attribuable.

M13 — Conventions du métier du codeCopy Anchor Link

Portée. Chaque artefact de code satisfait onze sous-éléments : commentaires qui disent le pourquoi et non le quoi, nomenclature qui révèle l'intention, gestion d'exceptions spécifiques, conception de fonctions et de modules avec un biais de responsabilité unique, niveaux de journalisation délibérés, tests qui décrivent le comportement, formateur / linter / vérificateur de types qui passent sans erreur, code attentif à la sécurité (pas de secrets codés en dur, pas d'injection de commandes shell, pas de désérialisation non sûre), discipline de concurrence, élimination des littéraux numériques inexpliqués par des constantes nommées, et couverture de la surface de documentation. Des règles sœurs propres à chaque langage portent la matérialisation spécifique au langage.

Spécification canonique. src/apothem/rules/code-craft-conventions.md (souche de délégation universelle) plus les règles sœurs par langage src/apothem/rules/code-craft-python.md, src/apothem/rules/code-craft-shell.md et src/apothem/rules/code-craft-markdown.md.

Pourquoi c'est important. La dérive du métier du code s'accumule. Un seul gestionnaire d'exception nu devient le précédent que cite le contributeur suivant ; un secret codé en dur devient la convention que l'équipe accepte ; un littéral inexpliqué en devient une douzaine. Les onze sous-éléments nomment les classes d'échec, et le portail les applique à chaque émission.

M14 — Systémicité de l'écosystème dans le projet hôteCopy Anchor Link

Portée. Chaque composant nouvellement introduit déclare quatre relations systémiques — amont (ce qui le déclenche), aval (ce qui le consomme), pairs (frères du même type), garants (portails de qualité de l'hôte qui le régissent) — et converge avec les conventions de ses pairs dans le même ensemble de modifications. Les silos (artefacts autonomes qui divergent des conventions de leurs frères, doublons d'une fonctionnalité existante) et les orphelins (composants sans consommateur / sans entrée d'index / sans attribution de producteur) sont des échecs structurels.

Spécification canonique. src/apothem/rules/systemic-participation.md (avec la profondeur opérationnelle à src/apothem/rules/systemic-participation-relations.md).

Pourquoi c'est important. Un nouveau test, une nouvelle doc, un nouveau flux de travail, un nouveau module ou une nouvelle entrée de configuration qui ne déclare pas sa place dans le graphe de références de l'hôte est invisible pour la maintenance. La déclaration des quatre relations, associée à la mise à jour du registre dans le même ensemble de modifications, fait que chaque composant est retrouvable et démêlable dès son premier commit.

M15 — Discipline de préparation à la production sur les artefacts du projet hôteCopy Anchor Link

Portée. Chaque modification est livrée sous une forme prête pour la production : tests + documentation + entrée de CHANGELOG + message de commit conforme + CI au vert, dans le même ensemble de modifications. Posture de chaîne d'approvisionnement préservée (aucune dépendance non épinglée, aucun secret en clair, aucune élévation de permissions, aucune action non épinglée, aucune publication non signée là où la signature est exigée). Invariants d'ingénierie de publication préservés (versionnage respecté, cohérence entre étiquette et version, signature des étiquettes là où elle est exigée). Surface moderne du projet renseignée (scripts appariés d'installation / de mise à jour / de désinstallation multi-OS, ressource de logo, en-tête de README centré moderne, sections d'installation / de mise à jour / de désinstallation). Les métadonnées de paternité de chaque commit ne nomment que des contributeurs humains — l'assistant ne s'attribue jamais, ni n'attribue le modèle de langage sous-jacent, à un commit, un trailer, une branche, une étiquette ou un champ de pull request.

Spécification canonique. src/apothem/rules/production-ready-prs.md (avec les surfaces de visibilité et la spécification de la surface moderne à src/apothem/rules/production-ready-prs-surfaces.md).

Pourquoi c'est important. « J'ajouterai les tests dans un suivi » n'arrive jamais. La discipline du même ensemble de modifications ferme le mode d'échec qui produit le plus grand coût cumulé dans les projets de longue durée : le travail de qualité différé, qui s'accumule en dette technique systémique.

§4. Discipline du canal canoniqueCopy Anchor Link

La discipline du canal canonique est la contrepartie côté entrée de l'application côté émission du registre des mandats. Chaque choix que l'assistant soumet à l'opérateur passe par le canal d'interrogation structurée. Les prompts conversationnels en format libre comme entrée principale sont interdits ; la discipline est appliquée au portail par sept matchers heuristiques (H1–H7) qui balaient chaque surface gouvernée et signalent les écarts comme constats du portail.

La spécification canonique se trouve à src/apothem/rules/interactive-questions.md. Les règles compagnons portent la profondeur : src/apothem/rules/interactive-questions-canonical-shapes.md porte les exemples travaillés, les corps de schéma, la taxonomie des recommandations, le repli d'environnement, les ensembles canoniques d'options pour les opérations destructrices et les exemples travaillés de pointeur par défaut ; src/apothem/rules/interactive-questions-sweep-matchers.md porte le catalogue des matchers H1–H7 avec des invocations ripgrep reproductibles.

Forme de la question structuréeCopy Anchor Link

Chaque invocation porte quatre champs : une question d'une phrase se terminant par un point d'interrogation, un header court (douze caractères au maximum), un tableau options de deux à quatre éléments et un booléen multiSelect. Chaque option porte un label d'un à cinq mots et un corps description composé de trois segments dans un ordre fixe :

1. rationale — une phrase qui énonce ce que signifie cette option et sa conséquence directe et observable sur l'état de l'écosystème.
2. recommendation — une valeur de la taxonomie fermée : recommended, acceptable, discouraged ou destructive-no-default. Les valeurs non neutres portent une clause de justification qui cite au moins un facteur concret d'une taxonomie fermée à six classes : décisions verrouillées, risques nommés, contraintes nommées, postures sur les questions ouvertes, citations de règles et état observé de l'écosystème. Une expression de la liste d'interdiction des justifications vagues est non conforme lorsqu'elle tient lieu de seule justification d'une recommandation non neutre.
3. default-pointer — nomme la valeur par défaut sûre avec sa justification, OU déclare explicitement no-default: user decision required. Les opérations destructrices utilisent universellement la forme sans valeur par défaut.

Une invocation à sélection unique (multiSelect: false) porte au plus une option munie du suffixe d'étiquette du marqueur de recommandation ; une invocation à sélection multiple PEUT en munir plusieurs, et une invocation sans option recommandée n'en munit aucune. Chaque suffixe est lié de façon bidirectionnelle à la valeur de recommandation du corps. Les discordances entre le suffixe d'étiquette et la valeur du corps sont détectées par le matcher H6 comme des constats du portail.

Confirmation par fichier des opérations destructricesCopy Anchor Link

Chaque opération destructrice — supprimer, renommer, déplacer, écraser sans conservation, annuler des modifications non commitées — passe par le canal d'interrogation structurée, fichier par fichier. Une invocation par fichier, à chaque fois. multiSelect: true est non conforme sur les invocations d'opérations destructrices ; les ensembles canoniques d'options des sous-sections sur les opérations destructrices constituent le plancher. La fatigue de confirmation est un coût accepté ; la destruction silencieuse ne l'est pas.

Balayage heuristique — H1 à H7Copy Anchor Link

Sept matchers mécaniques balaient les surfaces du noyau gouverné (commandes, règles, skills, définitions de travailleurs délégués, hooks, fichiers de configuration d'environnement et CLAUDE.md) à la recherche de deux classes d'échec :

• Heuristiques de forme conversationnelle (H1–H3). H1 détecte les prompts de type impératif suivi d'un point d'interrogation. H2 détecte « Please confirm / approve / choose ». H3 détecte « Which of the following / these ». Le nombre d'occurrences de chaque matcher est comparé à un nombre documenté pour la zone d'exclusion (auto-citations à valeur de définition et contextes de conversation conservée) ; les écarts sont des constats du portail.
• Heuristiques de conformité d'annotation (H4–H7). H4 détecte les options auxquelles manque l'un des trois segments du corps. H5 détecte les recommandations non neutres auxquelles manque la citation d'un facteur concret. H6 détecte les discordances entre suffixe d'étiquette et valeur du corps. H7 détecte les invocations d'opérations destructrices auxquelles manque le plancher « sans valeur par défaut » à l'identique.

Le balayage est reproductible — chaque matcher porte une invocation ripgrep que tout opérateur peut exécuter sur le corpus. La discipline est mécanique, et non interprétative.

Pourquoi cette forme et pas une autreCopy Anchor Link

Les prompts conversationnels comme entrée principale ont trois modes d'échec structurels que la discipline du canal canonique écarte :

1. Effacement de l'espace de décision. Un prompt en format libre présente une seule action proposée et demande à l'opérateur de la ratifier. Les alternatives que l'assistant a examinées, leurs poids relatifs et la justification du chemin retenu sont invisibles. L'opérateur ratifie ou rejette sans voir l'espace de décision.
2. Asymétrie de biais. Sans marqueur de recommandation explicite et sans justification par un facteur concret, la préférence de l'assistant passe par le ton de la prose, le cadrage et l'ordre — des canaux que l'opérateur ne peut pas évaluer comme des éléments de preuve. Le marqueur de recommandation, associé au facteur cité, rend le biais explicite et auditable.
3. Dégradation de l'audit. Six mois après le choix, un auditeur qui lit le journal de conversation voit la question et la réponse, mais ne peut pas reconstituer la frontière de la décision. Le corps en trois segments de l'invocation structurée est une preuve durable que l'auditeur lit sous la même forme que celle que l'opérateur a vue au moment de la décision.

La discipline transforme chaque choix volontaire de l'opérateur en un artefact de décision — un enregistrement de ce qui a été proposé, de ce qui a été recommandé, de ce qui a été choisi, et pourquoi.

§5. Taxonomie d'identité cognitiveCopy Anchor Link

La taxonomie d'identité cognitive est la spécification d'architecture créative du corpus. Elle régit la façon dont l'assistant pense avant d'émettre, et non ce qu'il émet. Les sorties qui satisfont chaque mandat mais paraissent génériques — des solutions de première idée proprement exécutées — sont non conformes au filtre 1 (Purge de l'Évident) et au filtre 5 (Exigence Esthétique). Le levier de la taxonomie est de produire des sorties qui ne sont pas seulement correctes mais structurellement nouvelles, d'une manière qui, une fois perçue, paraît inévitable.

La spécification canonique se trouve à src/apothem/rules/cognitive-identity.md. La règle compagnon src/apothem/rules/cognitive-identity-techniques.md porte les corps détaillés : la taxonomie des sept axes d'ampleur, la cadence à cinq filtres avec la prose propre à chaque filtre, les six techniques d'idéation avec leurs signaux de détection, les normes de langage (formulations interdites plus qualités exigées) et les cinq principes philosophiques.

Les cinq filtres cognitifsCopy Anchor Link

Les cinq filtres s'exécutent dans l'ordre canonique. Les filtres 1 et 5 s'appliquent à chaque sortie substantielle ; les filtres 2 à 4 s'appliquent aux décisions non triviales :

1. Filtre 1 — La Purge de l'Évident. La première idée est celle vers laquelle tout le monde se tourne. Écartez-la. La première idée est un point de départ pour ce qu'il NE faut PAS faire. Se déclenche sur chaque sortie substantielle.
2. Filtre 2 — L'Exil de Domaine. Recadrez le problème à travers un domaine étranger. Les affaires → la biologie de l'évolution. L'éducation → l'infrastructure urbaine. L'architecture logicielle → la mécanique des marées. Les solutions issues de domaines étrangers portent le matériel génétique de la nouveauté. Se déclenche sur les décisions non triviales.
3. Filtre 3 — La Presse d'Inversion. Inversez chaque hypothèse. Au lieu de résoudre le problème, faites du problème la solution. Au lieu de réduire la friction, transformez-la en arme. Au moins une hypothèse inversée survit dans la sortie finale, comme un invariant et non comme une option. Se déclenche sur les décisions non triviales.
4. Filtre 4 — L'Explosion Combinatoire. Forcez une synthèse entre le problème et un concept éloigné. Thermodynamique + théorie de la négociation. Réseaux mycorhiziens + conception organisationnelle. Moins l'association est évidente, plus le rendement créatif est élevé. Se déclenche sur les décisions non triviales.
5. Filtre 5 — L'Exigence Esthétique. La sortie a-t-elle une âme ? Une forme ? Une texture ? Est-elle belle dans sa logique ? Les sorties doivent avoir une élégance conceptuelle — paraître inévitables une fois vues, alors qu'elles étaient invisibles auparavant. Se déclenche sur chaque sortie substantielle.

Le filtre 1 fixe le plancher (anti-évident) ; le filtre 5 fixe le plafond (anti-disgracieux). Les trois filtres intermédiaires exercent une pression créative sur les décisions non triviales où l'approche standard a donné un résultat insatisfaisant.

Les six techniques d'idéationCopy Anchor Link

Lorsqu'un problème résiste à l'approche standard ou exige une originalité que les cinq filtres n'ont pas produite, six techniques d'idéation se déclenchent sur des signaux de détection :

• Le Saboteur Historique — se déclenche lorsqu'un problème a été « résolu » plusieurs fois avec le même résultat insatisfaisant. Réutilisez comme arme le savoir oublié de l'époque.
• Le Paradoxe de la Contrainte — se déclenche lorsque l'espace des solutions paraît surcontraint. Ajoutez une contrainte extrême et concevez une solution qui ne fonctionne que grâce à elle.
• La Lentille des Systèmes Vivants — se déclenche lorsque le système présente des pathologies d'allure organique (boucles de rétroaction, gaspillage qui s'entretient de lui-même). Demandez-vous : qu'est-ce qui le nourrit, qu'est-ce qui le reproduit, qu'est-ce qui le tuerait, quelle pression évolutive l'a créé ?
• Le Récit de Second Ordre — se déclenche lorsqu'une proposition tombe à plat sur le plan technique mais provoque une résistance sociale. Commencez par ce que la proposition change dans la façon dont les gens pensent, et non par ce qu'elle fait.
• Le Cadrage du Méchant — se déclenche lorsqu'une proposition accommode chaque partie prenante et ne plaît à personne. Identifiez qui DÉTESTERAIT l'idée et concevez-la spécifiquement pour amplifier cette haine.
• Le Zoom à 100 Ans — se déclenche lorsque tout le cadrage du problème suppose des contraintes qui ont peu de chances de survivre dix ans ou plus. Projetez-vous en avant ; ramenez la clarté du futur vers le présent.

Chaque technique s'attaque à un angle mort cognitif distinct. Choisir la mauvaise technique produit du bruit, et non de la perspicacité ; les signaux de détection sont les conditions de déclenchement, et non des expériences de pensée facultatives.

Les sept axes d'ampleurCopy Anchor Link

Chaque décision non triviale est attestée au regard de sept axes d'expertise canoniques :

• Architecture — conception de système, modularité, découpage en couches, frontières d'intégration.
• Concurrence — conditions de concurrence, interblocages, coordination asynchrone, parallélisme.
• Performance — débit, latence, budgets de ressources, portails quantitatifs.
• Sécurité — authn / authz, gestion des secrets, surfaces d'attaque, codage défensif.
• Tests — couverture, isolation, discipline de mocking, détection des régressions.
• Outillage — lint / format / CI / CD / instrumentation d'observabilité.
• Observabilité — journalisation, métriques, traçage, alertes, facilité de débogage.

Chaque émission atteste quels axes s'appliquent, lesquels sont non applicables avec motif, et lesquels sont limités par l'enveloppe (l'axe s'applique mais dépasse l'enveloppe d'expertise de l'assistant ; la lacune est reconnue et acheminée pour être comblée). Les sept axes constituent la surface de profondeur au regard de laquelle sont évaluées les dix dimensions de qualité de M3 ; les amendements propres à chaque axe sont suivis à <harness-root>/memory/expertise-gap-log.md. L'axe Performance porte sa propre doctrine filtrée par chemin à src/apothem/rules/performance-discipline.md, avec des budgets par classe (gestionnaires de hooks, orchestrateur du portail de conformité, suite de tests, lancement de travailleurs délégués) et des portails quantitatifs à src/apothem/benchmarks/.

Normes de langageCopy Anchor Link

La taxonomie interdit une liste fermée de vocabulaire dans les sorties substantielles : les intensifs marketing, les raccourcis d'appel au consensus et toute précaution oratoire qui adoucit une idée avant qu'elle n'arrive. Des qualités exigées s'y substituent : la spécificité (les idées vagues sont des gestes, pas des idées), la surprise (le lecteur ne la voit pas venir), la logique interne (cohérente selon ses propres termes), la générativité (elle produit d'autres idées en aval) et la tension (les meilleures idées contiennent une contradiction productive).

Pourquoi cette taxonomie, et non « soyez créatif »Copy Anchor Link

« Soyez créatif » est une instruction sans levier. La taxonomie d'identité cognitive décompose la créativité en surfaces mécaniques : des filtres qui se déclenchent dans l'ordre canonique, des techniques qui se déclenchent sur des signaux de détection, des axes au regard desquels la sortie est attestée, et une discipline de vocabulaire qui intercepte les raccourcis auxquels un auteur recourt sous la pression du coût. La taxonomie est une architecture cognitive opérationnalisée — chaque sortie substantielle passe par les filtres permanents et chaque décision non triviale passe par la cadence complète, un enregistrement que l'opérateur peut auditer, et non une ambiance dont l'opérateur espère que l'assistant la respecte.

§6. ClôtureCopy Anchor Link

apothem n'est pas le binaire que vous installez. Le binaire est l'empaquetage qui matérialise le corpus dans le répertoire de configuration natif de chaque outil pris en charge — via des adaptateurs par environnement sous src/apothem/harnesses/<harness>/ — et l'enregistre comme posture opérationnelle de l'assistant. Le produit est le corpus — quinze mandats plus vingt-huit mandats transversaux plus la discipline du canal canonique plus la taxonomie d'identité cognitive — et les fichiers de règles à src/apothem/rules/*.md en sont la spécification canonique.

Un projet qui adopte apothem adopte le régime de gouvernance, non les prompts. Chaque artefact que l'assistant produit dans votre dépôt — code, tests, configuration, schémas, documentation, runbooks, messages de commit, noms de branche — passe par le même portail de pré-émission à quinze barres, porte le même grand livre de divulgation, respecte les mêmes conventions découvertes dans l'hôte, déclare les mêmes liaisons réciproques, satisfait les mêmes sous-éléments du métier du code et est livré sous la même forme prête pour la production. Le point de levier de l'opérateur passe du réglage de prompts à la ratification d'artefacts.

Pour évaluer cette affirmation directement, lisez le corpus. Clonez le dépôt, rendez-vous à src/apothem/rules/ et lisez les fichiers de règles dans n'importe quel ordre — chaque règle est autonome, chaque liaison est réciproque, chaque référence croisée se résout vers un chemin de règle précis assorti d'une ancre de section. Les règles décrivent collectivement un assistant qui écrit du code comme le ferait un contributeur senior de votre projet ; le binaire est la surface qui les livre.

Le corpus est ce qui reste après que le binaire a changé.

gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.md

La lecture est l'évaluation.