Registres d'artefacts

Registre canonique des cohortes d'artefacts. Ce document porte les énumérations complètes des commandes, règles, travailleurs délégués, hooks, compétences, output-styles, discipline d'évolution des artefacts et déclarations de classes d'artefact vides ; les tableaux substantiels vivent ici. L'agencement des sources du projet fournit la vue condensée et toujours active.

1. CommandesCopy Anchor Link

Quarante-cinq commandes sont enregistrées depuis src/apothem/commands/*.md (non récursif) — la référence complète et toujours à jour par commande est la référence des commandes générée, et la chaîne /research en treize étapes (de /research-ideate à /research-disseminate) ainsi que les orchestrateurs de flux de travail encapsulés /audit et /fortress y sont énumérés en entier. Chaque commande est un fichier enregistré de première classe ; l'orchestrateur /plan ne fait qu'enchaîner les étapes de plan déjà de première classe et ne porte aucune logique d'étape propre, de sorte qu'il n'y a toujours pas de répartiteur monolithique ni de regroupement de sous-commandes.

Trente-cinq commandes sont invocables par le modèle (disable-model-invocation: false) : le modèle peut en exécuter une lorsqu'une demande correspond à sa description. Dix ne sont invoquées que par l'opérateur : /freshify, /github-deploy-fresh, /github-deploy-next, /release-readiness, /elevate, /fortress, /workflow, /plan-execute, /research-experiment et /research-publish. L'indicateur par commande est consigné dans src/apothem/commands/README.md.

Les commandes d'audit et d'élévation qui ne relèvent ni du plan ni de la recherche :

Commandes de la chaîne de planCopy Anchor Link

La chaîne de plan est livrée sous forme de huit commandes de première classe — une par étape, chacune invocable directement comme /plan-<stage> depuis son propre fichier enregistré à src/apothem/commands/plan-<stage>.md.

Commandes de flux de travail de l'opérateur et d'orchestrationCopy Anchor Link

Trois commandes entrent dans une procédure approfondie plutôt que de porter une logique d'étape propre : deux points d'entrée de flux de travail de l'opérateur (chacun soutenu par une compétence sœur du même nom) plus l'orchestrateur fin de la chaîne de plan.

2. RèglesCopy Anchor Link

Les règles comportementales vivent sous src/apothem/rules/ — un petit noyau toujours actif plus un ensemble plus large filtré par chemin (chargé à la demande lors des touches d'artefacts correspondants). L'énumération complète par règle — avec les colonnes Scope (toujours active / filtrée par chemin) et Implements — est le reference/rules.mdx généré depuis la source, rafraîchi depuis src/apothem/rules/*.md par le générateur d'inventaire de référence ; consultez-le pour la liste autoritative actuelle.

Délimitation des facettes de CM-21 (trois règles co-implémentent CM-21 avec des facettes distinctes et non chevauchantes) : filtres créatifs et identité cognitive → cognitive-identity.md ; méthodologie de génération (protocoles d'écriture et de réécriture) → clean-room-generation.md ; techniques de planification/revue → planning-techniques.md. Chaque règle possède sa facette ; les autres renvoient vers l'extérieur.

Pointeur du schéma de questions interactives. Le schéma canonique d'invocation d'interrogation structurée — champs requis, tableau récapitulatif des champs, deux exemples exécutables (sélection unique en §2.1 et sélection multiple en §2.2) — vit dans src/apothem/rules/interactive-questions.md §2 « Structured-Inquiry Shape ». Les artefacts en aval peuvent copier §2.1 ou §2.2 comme modèles d'invocation ; le schéma d'annotation d'options à trois segments que porte le corps description de chaque option est spécifié au §3 du même fichier.

3. Travailleurs déléguésCopy Anchor Link

L'écosystème est livré avec quatorze définitions de travailleurs persistants ; les motifs d'équipe de la règle d'orchestration répartissent vers eux. Chaque définition vit au chemin de fichier listé ci-dessous.

Worker              File                                       Pattern         Model Policy
------------------- ------------------------------------------ --------------- -------------
Citation Auditor    src/apothem/agents/citation-auditor.md    Audit           host-selected
Codebase Explorer   src/apothem/agents/codebase-explorer.md   Research        host-selected
Convention Auditor  src/apothem/agents/convention-auditor.md  Audit           host-selected
Dependency Auditor  src/apothem/agents/dependency-auditor.md  Audit           host-selected
Design Critic       src/apothem/agents/design-critic.md       Audit           host-selected
Fact Checker        src/apothem/agents/fact-checker.md        Audit           host-selected
MCP Builder         src/apothem/agents/mcp-builder.md         Generation      host-selected
Memory Auditor      src/apothem/agents/memory-auditor.md      Audit           host-selected
Prompt Evaluator    src/apothem/agents/prompt-evaluator.md    Quality         host-selected
Quality Gate        src/apothem/agents/quality-gate.md        Quality         host-selected
Refactor Surgeon    src/apothem/agents/refactor-surgeon.md    Implementation  host-selected
Research Scout      src/apothem/agents/research-scout.md      Research        host-selected
Security Scanner    src/apothem/agents/security-scanner.md    Audit           host-selected
Test Runner         src/apothem/agents/test-runner.md         Quality         host-selected

4. HooksCopy Anchor Link

Les entrées de hook de Claude Code installées utilisent la forme exec : command vaut ${PYTHON_BIN}, et args contient un chemin de script sous ${HARNESS_ROOT}/.apothem/support/ (par exemple hooks/dispatch.py et conformity/gate.py). La forme -m apothem.hooks.dispatch ne sert qu'au développement depuis un checkout des sources avec PYTHONPATH=src. Le répartiteur importe src/apothem/hooks/lib/resolve_root.py pour la résolution de la racine de l'écosystème et délègue à deux modules voisins, situés directement sous src/apothem/hooks/ lui-même : src/apothem/hooks/emit_hook_context.py met en forme les charges utiles d'événements pour l'assistant, et src/apothem/hooks/session_start_bootstrap.py porte le travail de préparation de SessionStart que le répartiteur lui transmet lorsqu'il achemine cet événement. Les messages de hook remontés à l'assistant lorsque les événements pris en charge se déclenchent sont des fichiers de contexte Markdown sous src/apothem/hooks/messages/, un par variante d'événement : postcompact.md, precompact.md, posttooluse-proactive-compaction.md, pretooluse-askuserquestion-recommended.md, pretooluse-bash.md, pretooluse-bash-plan-guard.md, pretooluse-conformity.md, pretooluse-dependency-guard.md, pretooluse-edit.md, pretooluse-edit-header-guard.md, pretooluse-eval-guard.md, pretooluse-notebookedit.md, pretooluse-write.md, pretooluse-write-header-guard.md, pretooluse-write-plan-guard.md, sessionstart.md, skill-index.md, stop.md. Chaque fichier de contexte acheminé est chargé par le répartiteur lorsque son événement se déclenche, et son argument de contexte est enregistré dans settings.json. pretooluse-conformity.md est livré comme variante disponible, sans entrée d'acheminement actuelle dans settings.json. skill-index.md est généré à partir du catalogue des compétences et des commandes et lu par l'amorce de démarrage de session, sans être acheminé par settings.json. pretooluse-dependency-guard.md est acheminé sur les matchers Write et Edit, et pretooluse-eval-guard.md sur les matchers Write, Edit et Bash|PowerShell.

Event             Automates                Timeout  Purpose
----------------- ------------------------ -------- --------------------------------------------------
SessionStart      CM-14                    30s      Read memory, check plan state, report readiness
PreCompact        CM-24                    30s      Verify state externalized before compaction. Codex and Qwen Code register it; the Claude Code settings.json template does not
PostCompact       CM-24                    30s      Restore working state after compaction. Codex and Qwen Code register it; the Claude Code settings.json template does not
Stop              CM-14/CM-22/CM-24/CM-26  60s      Session-end externalization
PreToolUse        CM-7/CM-22               10s      Write/Edit/NotebookEdit validation — codebase-isolation, frontmatter, license-header, and plans-locality checks plus the conformity gate. Bash validation — git artifact isolation and plans-locality
PostToolUse       Proactive compaction     10s      Proactive-compaction advisory on every tool call; the Claude Code settings.json template routes it on the all-tools matcher
UserPromptSubmit  —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event
Notification      —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event

Convention. Les lignes où Automates est — sont acceptées par dispatch.py mais non câblées dans settings.json ; la colonne Timeout montre la valeur par défaut au niveau de la répartition qui s'applique si et quand l'événement est câblé plus tard.

Bloc canonique des valeurs de timeout. La colonne Timeout de ce tableau est l'unique source de vérité pour les valeurs de timeout des hooks dans tout l'écosystème. Les champs timeout par hook dans settings.json, les tableaux miroirs dans site/content/docs/reference/settings-reference.mdx § Hook Events et site/content/docs/reference/artifact-schema.mdx § Hooks Pipeline, et les indications de règles dans src/apothem/rules/persistent-conventions-vigilance.md § Convention Awareness, dérivent toutes de cette colonne. Les futures révisions de timeout atterrissent ici et les consommateurs re-dérivent à la référence suivante.

Cadence de revue du modèle de configurationCopy Anchor Link

settings.json est l'unique modèle Claude Code. Chaque commande de hook utilise la forme exec plutôt qu'un wrapper spécifique au shell, de sorte que le comportement inter-OS est revu à l'intérieur d'un seul fichier plutôt qu'en comparant des modèles appariés. Les nouvelles entrées de permissions, événements de hook, timeouts et messages de statut atterrissent dans ce fichier de manière atomique.

5. CompétencesCopy Anchor Link

Les compétences réutilisables vivent sous src/apothem/skills/, un dossier par compétence.

Une compétence avec disable-model-invocation: true ne s'exécute que lorsque l'opérateur l'invoque par son nom. Vingt compétences sont invocables par le modèle. Quatre sont manuelles parce qu'elles modifient un état en dehors de l'arbre de travail ou dépendent du moment choisi par l'opérateur : Dependency Upgrade, Secret Rotation, Workflow et Issue Lifecycle. Les deux compétences de suite sont des modèles de référence uniquement, lus par chemin. L'index des compétences du démarrage de session liste les noms invocables par le modèle et les noms manuels par domaine.

Convention. Le Chemin de chaque ligne est un dossier ; le point d'entrée est le fichier SKILL.md qu'il contient — p. ex. src/apothem/skills/plan-suite/SKILL.md — selon la convention de compétence dossier-avec-SKILL.md déclarée dans l'agencement des sources du projet.

6. Output-stylesCopy Anchor Link

Quatre output-styles vivent sous src/apothem/output-styles/.

7. Évolution des artefactsCopy Anchor Link

Obligatoire. Lorsqu'un motif, une correction ou une technique réutilisable se reproduit (2+ instances dans une session, ou noté en mémoire comme récurrent), l'écosystème doit évoluer. Le cycle a quatre étapes : Detect le motif lors de toute interaction ; Search les compétences, règles, commandes, hooks et la mémoire existants pour les chevauchements ; Act en faisant évoluer l'artefact correspondant sur place (mettre à jour la procédure, les anti-motifs, la portée) ou en en créant un nouveau lorsque la préoccupation est véritablement orthogonale ; Validate que les références croisées se résolvent encore et que les artefacts dépendants restent cohérents. Préférez le raffinement à la création — les nouveaux artefacts accumulent de la surface de maintenance. Consultez src/apothem/rules/persistent-conventions-vigilance.md §2+§4 pour le protocole complet, y compris le catalogue fermé des déclencheurs de détection de lacunes pour chaque classe d'artefact.

8. Classes d'artefact videsCopy Anchor Link

Surfaces déclarées dans le registre de l'écosystème mais intentionnellement vides jusqu'à ce qu'un déclencheur d'activation se déclenche. Chaque ligne enregistre la surface réservée, le fichier ou répertoire qui échafaude la classe, et le déclencheur qui promeut la ligne de déclaration-vide à peuplée.

La déclaration-vide est une déclaration positive, non une lacune. L'échafaudage de la classe (lorsqu'il existe) est l'artefact canonique sans opération qui suit le moment d'activation. Les promotions de déclaration-vide à peuplée atterrissent dans la section de registre pertinente de manière atomique avec la première valeur non vide de l'échafaudage.