Ir al contenido
emet

Arquitectura

Un mapa del código de emet/src y cómo lo dirigen los prompts de /emet. Los términos siguen GLOSSARY.md; las decisiones detrás de esta forma viven en docs/adr. Para los problemas, consulta la solución de problemas.

Forma

Hay dos mitades. Los prompts (commands/run.md, agents/*.md, emet/reference/*.md) le dicen a Claude qué hacer en cada fase. La CLI emet (emet/bin/emet.ts y emet/src/) hace todo lo que debe ser determinista: comprobaciones, reclamaciones, slots, compuertas, escrituras en el tracker y aterrizaje. Los prompts nunca reimplementan una comprobación que la CLI ya realiza.

emet/bin/emet.ts es un despachador delgado: lee el primer argumento y delega en un módulo de subcomando, que lee por sí mismo el resto de process.argv. Los códigos de salida tienen significado en todos los subcomandos.

Cómo los prompts dirigen la CLI

commands/run.md es un enrutador corto. Carga un archivo de fase de emet/reference/ a la vez, de modo que una compactación nunca pierde las reglas de la fase actual.

Fase Prompt Llamadas a la CLI
1-5 entrevista, spec, tickets, aprobación phases-1-5.md init, doctor, validate, surfaces, approve, tracker
6-7 despacho y workers phases-6-7-dispatch.md, worker-prompt.md preflight, claims, slots, launch, lock-reason, handoff, results
8 revisión, compuerta, aterrizaje, cierre phases-8-closeout.md, reviewer-prompt.md verify, review-package, review, assess, gate, land, cleanup
9 handoff y encadenamiento phases-9-handoff.md status, metrics, usage, spec-merge

El coordinador es el único que escribe en el tracker (ADR-0005): los workers informan mediante una nota de handoff y emet results, y el coordinador las publica. emet guard se ejecuta como un hook PreToolUse y bloquea los desencadenantes conocidos de fallos en ejecuciones sin supervisión.

Mapa de módulos

Cada módulo tiene un *.test.ts a su lado.

Área Módulos
Configuración y auditoría init.ts (configuración y esqueleto de documentos), config.ts (emet.config.json, el forge.config.json heredado todavía se lee), doctor.ts (barrido de flota), preflight.ts (higiene del despacho), dependencies.ts, skills.ts (contrato con mattpocock-skills), map.ts (resumen del código)
Estado de ejecución claims.ts (reservas de tickets), slots.ts (pool de slots de workers), resources.ts (datos del host), runs.ts (actividad), locks.ts, lockreason.ts, proctree.ts, worktrees.ts, cleanup.ts, status.ts, launch.ts
Tracker tracker.ts, tracker-files.ts (tracker local .scratch/), validate.ts (cobertura de la spec), specmerge.ts, approve.ts, surfaces.ts (solapamiento de superficies de edición)
Handoff del worker handoff.ts, results.ts, materializelog.ts
Revisión y aterrizaje verify.ts, reviewpackage.ts, review.ts (libro de hallazgos), assess.ts (clasificador de riesgo), gate.ts, land.ts
Informes metrics.ts, usage.ts
Seguridad guard.ts, guard-destructive.ts
Utilidades compartidas narrow.ts, optional.ts, assets.ts (archivos incrustados en los binarios compilados)

Estructura de los prompts

commands/run.md (unas 130 líneas) es el enrutador de /emet. Cada archivo de emet/reference/ es un grupo de fases (phases-1-5.md, phases-6-7-dispatch.md, phases-8-closeout.md, phases-9-handoff.md), que se carga solo cuando el modo de la ejecución actual lo necesita. Una prueba falla si alguno crece por encima de 20 000 bytes, de modo que un solo archivo no pueda apoderarse del contexto tras una compactación. Las fases le indican al coordinador que vuelva a leer la sección pertinente antes de cada ronda de corrección o revisión. install.sh aparta un antiguo phases-6-9.md único como phases-6-9.md.retired cuando lo editaste o es anterior al manifiesto de instalación, y lo elimina en caso contrario. install.sh también conecta emet guard en ~/.claude/settings.json como el hook PreToolUse.

Distribución

install.sh copia emet/ a ~/.claude/emet y reescribe los prompts. La vía del plugin incluye un shim que descarga un binario independiente con suma de verificación, construido por tools/build-binaries.ts. Consulta el ADR-0008.

Véase también