Registros de artefactos

Registro canónico de las cohortes de artefactos. Este documento contiene las enumeraciones completas de comandos, reglas, trabajadores delegados, hooks, skills, output-styles, 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. ComandosCopy Anchor Link

Se registran cuarenta y cinco comandos desde src/apothem/commands/*.md (no recursivo) — la referencia completa y siempre actualizada por comando es la Referencia de comandos generada, y la canalización /research de trece etapas (de /research-ideate a /research-disseminate) más los orquestadores de flujos de trabajo envueltos /audit y /fortress se enumeran allí por completo. 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.

Treinta y cinco comandos son invocables por el modelo (disable-model-invocation: false): el modelo puede ejecutar uno cuando una solicitud coincide con su descripción. Diez solo los invoca el operador: /freshify, /github-deploy-fresh, /github-deploy-next, /release-readiness, /elevate, /fortress, /workflow, /plan-execute, /research-experiment y /research-publish. La bandera de cada comando se registra en src/apothem/commands/README.md.

Los comandos de auditoría y elevación que no son de plan ni de investigación:

Comandos de la canalización de planCopy Anchor Link

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ónCopy Anchor Link

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 skill hermana del mismo nombre) más el orquestador delgado de la canalización de plan.

2. ReglasCopy Anchor Link

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 delegadosCopy Anchor Link

El ecosistema se entrega con catorce 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
------------------- ------------------------------------------ --------------- -------------
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

Las entradas de hook de Claude Code instaladas usan la forma exec: command es ${PYTHON_BIN}, y args contiene una ruta de script bajo ${HARNESS_ROOT}/.apothem/support/ (por ejemplo, hooks/dispatch.py y conformity/gate.py). La forma -m apothem.hooks.dispatch es para desarrollar desde un checkout del código fuente con PYTHONPATH=src. 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 están junto a él, en el propio src/apothem/hooks/: src/apothem/hooks/emit_hook_context.py da formato a 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 le delega cuando enruta ese evento. Los mensajes de hook que se presentan al asistente cuando se disparan los eventos admitidos viven como archivos de contexto Markdown bajo src/apothem/hooks/messages/, uno por variante de evento: 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 y stop.md. El despachador carga cada archivo de contexto enrutado cuando se dispara su evento y su argumento de contexto está registrado en settings.json. pretooluse-conformity.md se distribuye como variante disponible sin una entrada de enrutamiento actual en settings.json. skill-index.md se genera a partir del catálogo de skills y comandos y lo lee el bootstrap de inicio de sesión, sin enrutarse a través de settings.json. pretooluse-dependency-guard.md se enruta en los matchers Write y Edit, y pretooluse-eval-guard.md en los matchers Write, Edit y 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

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ónCopy Anchor Link

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. SkillsCopy Anchor Link

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

Una skill con disable-model-invocation: true solo se ejecuta cuando el operador la invoca por su nombre. Veinte skills son invocables por el modelo. Cuatro son manuales porque cambian el estado fuera del árbol de trabajo o dependen de que el operador elija el momento: Dependency Upgrade, Secret Rotation, Workflow e Issue Lifecycle. Las dos skills de suite son plantillas solo de referencia que se leen por ruta. El índice de skills del inicio de sesión enumera los nombres invocables por el modelo y los manuales por dominio.

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 skill de carpeta-con-SKILL.md declarada en el esquema de la fuente del proyecto.

6. Output-stylesCopy Anchor Link

Cuatro output-styles viven bajo src/apothem/output-styles/.

7. Evolución de artefactosCopy Anchor Link

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 skills, 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íasCopy Anchor Link

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.