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, styles de sortie, 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. Commandes

Trente commandes sont enregistrées depuis src/apothem/commands/*.md (non récursif). 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. Les commandes qui ne sont ni de plan ni de workflow :

Commandes de la chaîne de plan

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'orchestration

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ègles

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és

L'écosystème est livré avec douze 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
------------------- ------------------------------------------ --------------- -------------
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
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. Hooks

Chaque commande de hook enregistrée utilise la forme exec de commande de Claude Code (command: "python" plus un tableau args) et invoque soit -m apothem.hooks.dispatch soit -m apothem.conformity.gate. 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 assistants qui se trouvent à ses côtés sous src/apothem/hooks/ : src/apothem/hooks/emit_hook_context.py formate les charges utiles d'événements pour l'assistant, et src/apothem/hooks/session_start_bootstrap.py porte le travail de préparation du SessionStart que le répartiteur transmet lorsqu'il achemine cet événement. Les messages de hook présentés à l'assistant lorsque les événements supportés se déclenchent vivent sous forme de fichiers de contexte Markdown sous src/apothem/hooks/messages/ — un par variante d'événement : postcompact.md, precompact.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, stop.md. Chaque fichier de contexte acheminé est chargé par le répartiteur lorsque son événement se déclenche et que son argument de contexte est enregistré dans settings.json ; trois fichiers de contexte (pretooluse-conformity.md, pretooluse-dependency-guard.md, pretooluse-eval-guard.md) sont livrés comme variantes disponibles sans entrée d'acheminement actuelle dans settings.json.

Event             Automates                Timeout  Purpose
----------------- ------------------------ -------- --------------------------------------------------
SessionStart      CM-14                    30s      Read memory, check plan state, report readiness
PreCompact        CM-24 §2.3               30s      Verify state externalized before compaction
PostCompact       CM-24 §6.2               30s      Restore working state after compaction
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       —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event
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 configuration

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étences

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

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. Styles de sortie

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

7. Évolution des artefacts

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 vides

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.