hearting

Hearting (anteriormente agent_setting) es una capa de flujo de trabajo local-first para agentes de codificación. En lugar de configurar un único runtime, define contratos compartidos una vez y los proyecta sobre las superficies nativas de habilidad, agente, hook, modo y comando que Claude Code, Codex y OpenCode descubren. El objetivo declarado es llevar investigación, planificación, implementación y verificación a través de un ciclo consistente en los tres. Los mecanismos clave descritos en el README: - Capacidades enrutadas: 12 routers de entrada sobre 26 capacidades. Antes de trabajo sustancial, el agente propone una tarjeta de ruta de cinco campos (tarea, razón, ruta, alcance, finalización) para aprobación. - Escalera de intensidad: niveles directo, rápido, estándar, fuerte, exhaustivo y adversarial que seleccionan el gráfico de etapa y la profundidad de despacho; la rigor de verificación se deriva de la intensidad. - Despacho sellado cross-harness: en estándar y superior, cada etapa se ejecuta como una sesión lanzada por separado con rol sellado, perfil de modelo y alcance de escritura disjunto. Grupos paralelos de 2-4 piernas comienzan en una transacción, y las piernas se expanden por familias de harness por defecto. La profundidad de despacho 3 está prohibida. - Niveles de modelo por nodo: deep, balanced-deep, light y mini están sellados por nodo en tiempo de compilación; los adaptadores los mapean a modelos concretos sin nombrar vendors en contratos compartidos. - Fleet: un panel en vivo sobre el registro de intentos que muestra sesiones interactivas y trabajadores despachados de los tres runtimes en un solo árbol, con estado, harness, perfil sellado, gauge de contexto y contabilidad de tokens. `fleet --once` y `fleet --json` funcionan sin curses. - Guards: 39 hooks, 5 de ellos bloqueos duros, denegando violaciones de alcance de escritura, lectura de especificación, raíz de artifacts, estado git y ruta de memoria antes de la llamada a la herramienta. - Sistema de artifacts: investigación/analizar-proyecto a especificación a planes para código, e investigación a borrador a refinar para documentos, bajo una raíz .agent_reports/ a nivel de proyecto. - Memoria: SQLite con FTS5 entre sesiones, proyectos y runtimes; las decisiones cambiadas son suplantadas en lugar de eliminadas. La instalación es mediante un script de lanzamiento de una línea que instala un archivo verificado por integridad y registra una verificación diaria de actualización a nivel de usuario donde sea compatible. El instalador no toca credenciales de runtime, sesiones, logs ni bases de datos. Cuando Codex está presente, también instala un ingress protegido reversible para que los comandos interactivos de codex entren al servidor App gestionado por harness, mientras que los comandos no interactivos pasan al CLI real. `hearting update` etapa y verifica un nuevo lanzamiento antes de cambiar el puntero activo y hace rollback en caso de fallo. Un operador `compute-hosts` lee un archivo YAML de configuración propiedad del usuario semillado una vez como plantilla comentada. El soporte de runtime cubre Claude Code, Codex y OpenCode en modos de proyección linked (live-debug) y packaged (bundle inmutable). Las superficies no soportadas se marcan SKIP con una razón. Los flujos de desarrollo incluyen un único punto de entrada generate/check, pruebas de deriva de proyección generada, y Git hooks del repositorio que ejecutan las mismas comprobaciones que CI. La documentación cubre uso, layout de instalación, política de lanzamientos, capacidades, roles, enrutamiento, operaciones, memoria y hooks. Licenciado bajo MIT.