Registros de artefactos

Registro canónico de las cohortes de artefactos. Este documento contiene las enumeraciones completas de comandos, reglas, trabajadores delegados, hooks, habilidades, estilos de salida, disciplina de evolución de artefactos y declaraciones de clases de artefacto vacías; las tablas sustantivas viven aquí. El esquema de la fuente del proyecto proporciona la vista condensada y siempre activa.

1. Comandos

Se registran treinta comandos desde src/apothem/commands/*.md (no recursivo). Cada comando es un archivo registrado de primera clase; el orquestador /plan solo encadena las etapas de plan que ya son de primera clase y no lleva lógica de etapa propia, por lo que sigue sin haber un despachador monolítico ni agrupación de subcomandos. Los comandos que no son de plan ni de workflow:

Comandos de la canalización de plan

La canalización de plan se entrega como ocho comandos de primera clase — uno por etapa, cada uno invocable directamente como /plan-<stage> desde su propio archivo registrado en src/apothem/commands/plan-<stage>.md.

Comandos de flujo de trabajo del operador y de orquestación

Tres comandos entran en un procedimiento profundo en lugar de llevar lógica de etapa propia: dos puntos de entrada de flujo de trabajo del operador (cada uno respaldado por una habilidad hermana del mismo nombre) más el orquestador delgado de la canalización de plan.

2. Reglas

Las reglas de comportamiento viven bajo src/apothem/rules/ — un pequeño núcleo siempre activo más un conjunto mayor filtrado por ruta (cargado bajo demanda al tocar artefactos coincidentes). La enumeración completa por regla — con las columnas Scope (siempre activa / filtrada por ruta) e Implements — es el reference/rules.mdx generado a partir de la fuente, refrescado desde src/apothem/rules/*.md por el generador del inventario de referencia; consúltalo para obtener la lista autoritativa actual.

Delineación de facetas de CM-21 (tres reglas coimplementan CM-21 con facetas distintas y no superpuestas): filtros creativos e identidad cognitiva → cognitive-identity.md; metodología de generación (protocolos de escritura y reescritura) → clean-room-generation.md; técnicas de planificación/revisión → planning-techniques.md. Cada regla posee su faceta; las demás remiten hacia afuera.

Puntero al esquema de preguntas interactivas. El esquema canónico de invocación de consulta estructurada — campos requeridos, tabla de resumen de campos, dos ejemplos ejecutables (selección única en §2.1 y selección múltiple en §2.2) — vive en src/apothem/rules/interactive-questions.md §2 "Structured-Inquiry Shape". Los artefactos descendentes pueden copiar §2.1 o §2.2 como plantillas de invocación; el esquema de anotación de opciones de tres segmentos que lleva el cuerpo description de cada opción se especifica en el §3 del mismo archivo.

3. Trabajadores delegados

El ecosistema se entrega con doce definiciones de trabajadores persistentes; los patrones de equipo de la regla de orquestación despachan hacia ellos. Cada definición vive en la ruta de archivo indicada a continuación.

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

Cada comando de hook registrado usa la forma exec del comando de Claude Code (command: "python" más un array args) e invoca ya sea -m apothem.hooks.dispatch o -m apothem.conformity.gate. El despachador importa src/apothem/hooks/lib/resolve_root.py para la resolución de la raíz del ecosistema y delega en dos auxiliares que se sitúan junto a él bajo src/apothem/hooks/: src/apothem/hooks/emit_hook_context.py formatea las cargas útiles de eventos para el asistente, y src/apothem/hooks/session_start_bootstrap.py lleva el trabajo de preparación de SessionStart que el despachador delega cuando enruta ese evento. Los mensajes de hook presentados al asistente cuando se disparan los eventos soportados viven como archivos de contexto Markdown bajo src/apothem/hooks/messages/ — uno por variante de evento: 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. Cada archivo de contexto enrutado es cargado por el despachador cuando se dispara su evento y su argumento de contexto está registrado en settings.json; tres archivos de contexto (pretooluse-conformity.md, pretooluse-dependency-guard.md, pretooluse-eval-guard.md) se entregan como variantes disponibles sin una entrada de enrutamiento actual en 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

Convención. Las filas donde Automates es — son aceptadas por dispatch.py pero no están cableadas en settings.json; la columna Timeout muestra el valor por defecto a nivel de despacho que se aplica si y cuando el evento se cablea más adelante.

Bloque canónico de valores de timeout. La columna Timeout de esta tabla es la única fuente de verdad para los valores de timeout de hooks en todo el ecosistema. Los campos timeout por hook en settings.json, las tablas espejo en site/content/docs/reference/settings-reference.mdx § Hook Events y site/content/docs/reference/artifact-schema.mdx § Hooks Pipeline, y la guía de reglas en src/apothem/rules/persistent-conventions-vigilance.md § Convention Awareness, todas derivan de esta columna. Las futuras revisiones de timeout aterrizan aquí y los consumidores vuelven a derivar en la siguiente referencia.

Cadencia de revisión de la plantilla de configuración

settings.json es la única plantilla de Claude Code. Cada comando de hook usa la forma exec en lugar de un envoltorio específico de shell, por lo que el comportamiento entre SO se revisa dentro de un único archivo en lugar de diferenciando plantillas pareadas. Las nuevas entradas de permisos, eventos de hook, timeouts y mensajes de estado aterrizan en ese archivo de forma atómica.

5. Habilidades

Las habilidades reutilizables viven bajo src/apothem/skills/, una carpeta por habilidad.

Convención. La Ruta de cada fila es una carpeta; el punto de entrada es el archivo SKILL.md dentro de ella — p. ej. src/apothem/skills/plan-suite/SKILL.md — según la convención de habilidad de carpeta-con-SKILL.md declarada en el esquema de la fuente del proyecto.

6. Estilos de salida

Cuatro estilos de salida viven bajo src/apothem/output-styles/.

7. Evolución de artefactos

Obligatorio. Cuando un patrón, corrección o técnica reutilizable recurre (2+ instancias en una sesión, o anotado en memoria como recurrente), el ecosistema debe evolucionar. El ciclo tiene cuatro pasos: Detect el patrón durante cualquier interacción; Search las habilidades, reglas, comandos, hooks y memoria existentes en busca de solapamiento; Act evolucionando el artefacto coincidente en su lugar (actualizar procedimiento, antipatrones, alcance) o creando uno nuevo cuando la preocupación es genuinamente ortogonal; Validate que las referencias cruzadas aún se resuelven y los artefactos dependientes permanecen consistentes. Prefiere el refinamiento sobre la creación — los artefactos nuevos acumulan superficie de mantenimiento. Consulta src/apothem/rules/persistent-conventions-vigilance.md §2+§4 para el protocolo completo, incluido el catálogo cerrado de disparadores de detección de brechas en cada clase de artefacto.

8. Clases de artefacto vacías

Superficies declaradas en el registro del ecosistema pero intencionalmente vacías hasta que se dispara un disparador de activación. Cada fila registra la superficie reservada, el archivo o directorio que andamia la clase, y el disparador que promueve la fila de declaración-vacía a poblada.

La declaración-vacía es una declaración positiva, no una brecha. El andamio de la clase (cuando existe) es el artefacto canónico sin operación que rastrea el momento de activación. Las promociones de declaración-vacía a poblada aterrizan en la sección de registro relevante de forma atómica con el primer valor no vacío del andamio.