Frontera kit ↔ engine
claude-kit (la herramienta del flujo de trabajo) y @tedos/engine (el motor de ejecución de última
milla del producto) nunca deben llevar dos implementaciones de la misma operación. Cada operación
del flujo de trabajo tiene exactamente un hogar canónico, y ambas superficies — Claude Code interactivo
y el motor — consumen ese único hogar. Consistente por construcción, no por disciplina.
Dos familias, un dueño cada una
| Familia | Qué | Hogar canónico |
|---|---|---|
| 1. Git-mechanics del repo | crear / recuperar / podar worktree, ramas, commits, el flujo kit-task en nuestro repo | el bundle bash scripts/lib/ — los skills del kit son envolturas delgadas; el motor invoca el mismo bundle |
| 2. Grafo de plan / tarea | el árbol de plan-node, los links (issue / PR / deploy), el estado, "crear issue / iniciar / enlazar PR" | el grafo Postgres del Plan Engine — ver Plan Engine |
Reglas duras
- Sin segunda implementación. Antes de escribir una operación git/GitHub/tarea en cualquier superficie, comprueba si su familia ya tiene un hogar canónico; si lo tiene, llámalo — nunca re-implementes. Una operación repetida → extráela al hogar de la familia.
- La Familia 1 es bash, propiedad del kit. Los git-mechanics de nuestro repo viven en
scripts/lib/. El motor los invoca vía un proceso hijo; no los reimplementa en TypeScript. - La fuente de verdad de la Familia 2 es el grafo (el conductor diario); los issues de GitHub se mantienen sincronizados con él (un espejo, no eliminado — la eliminación está diferida). Nunca reintroduzcas un segundo almacén de tickets.
Los conectores de tenant son producto, nunca flujo de trabajo
Los conectores de tenant del motor (GitHub, Google, HubSpot, …) son conscientes del tenant, con alcance OAuth, y operan sobre los sistemas del cliente. No tienen nada que ver con nuestros git-mechanics del flujo de trabajo. Las operaciones de Familia-1/2 nunca se enrutan a través de un conector de tenant, y un conector de tenant nunca se enruta a través de la herramienta del flujo de trabajo. Esta es la frontera producto / flujo de trabajo — ver Engine.
kit ⇄ proyecto — mantenerse sincronizados
claude-kit y el .claude/ + scripts/lib/ de un proyecto son un cuerpo en dos checkouts; nunca deben
divergir. Una actualización trae nuevas versiones del kit a un proyecto; cuando un esfuerzo mejora un
archivo gestionado por el kit, esa mejora pertenece upstream en el kit — de lo contrario la próxima
actualización la revierte.
El CLI del kit
Un dispatcher bash (scripts/kit) fronta ambas familias sin añadir una tercera implementación:
despacha al bash de la Familia 1 y proxea la Familia 2 al motor a través de un adaptador
enchufable. El adaptador está apagado por defecto, para que el kit permanezca portable como
producto (sin motor = comportamiento respaldado por GitHub); un proyecto opta por activarlo configurando
la costura del motor.
Dónde encaja claude-kit
claude-kit está documentado en detalle en su propia sección — ver claude-kit. Esta página es la frontera entre esa herramienta de desarrollo y el motor del producto: dos familias, un dueño cada una, sin duplicación.