@johpaz/hive-sdk 0.1.6 → 0.3.0

package/CHANGELOG.md

@@ -2,16 +2,457 @@
 
 ## Sin publicar
 
+### Corregido
+
+- **`browser_scrape` extraía con una tool que no ve lo que el navegador
+  renderizó.** La skill existe para sitios dinámicos, y su paso de extracción
+  usaba `web_fetch`, que vuelve a pedir la URL al servidor y recibe el HTML sin
+  JavaScript ejecutado: en un SPA, una cáscara vacía. Pasa a usar
+  `browser_extract`, que lee el DOM ya renderizado, con un `browser_wait` previo.
+  (Uno de sus ejemplos citaba además `browser_fetch`, que no existe.)
+
+- **`browser_automate` no esperaba a los elementos.** Sus pasos iban de navegar a
+  hacer clic sin `browser_wait` en el medio, que es la falla más común de la
+  automatización web y falla en silencio. Se agregó el paso y el orden de
+  escalada: selector → `browser_script` → `computer_use_task`.
+
+- **La tabla de campos de `cron_manager` omitía la mitad de lo que acepta la
+  tool**: `max_runs`, `payload`, `agent_id` y `tool_name`. También documentaba
+  expresiones de 5 campos cuando el motor acepta 6, y no aclaraba que la zona
+  horaria sale del perfil del usuario y no se pasa en la llamada.
+
+- **Los contadores del scheduler perdían actualizaciones.** `run_count` y
+  `error_count` se calculaban desde una lectura hecha antes del bucle de
+  reintento de `updateJob`, así que al reintentar por conflicto de versión se
+  reescribía el valor viejo. Con dos corridas solapadas del mismo job —normal en
+  uno que tarda más que su intervalo y no declara `protect`, y garantizado en la
+  puesta al día por misfire, que llama a `execute()` en paralelo con el job ya
+  activado— ambas leían `error_count: 4` y ambas escribían 5. La consecuencia no
+  era el número: es que el umbral de auto-pausa (5 errores seguidos) no se
+  alcanzaba nunca y un job que fallaba siempre se quedaba reintentando para
+  siempre. `updateJob` ahora acepta un parche en forma de función, que se evalúa
+  contra la lectura fresca de cada intento. Es el mismo error que ya se corrigió
+  en `touchThread`. Cubierto por `packages/core/src/scheduler/scheduler.test.ts`.
+
+### Agregado
+
+- **El seed inicial de especialistas es una elección.** `ensureHiveDb()` y
+  `seedAllData()` aceptan `specialists: "all" | "none" | string[]`. Con `"none"`
+  la colmena arranca sin ningún especialista y con sólo las `MINIMAL_TOOLS`
+  activas —la competencia del coordinador—, y son los enjambres los que traen
+  consigo a los suyos. `"all"` sigue siendo el default, así que nada cambia para
+  quien no lo pida.
+
+  La elección alcanza también a las **capacidades**, no sólo a los agentes: una
+  fila de tool o skill que nace en un arranque `"none"` nace inactiva. Antes
+  `active` defaulteaba a `true` para toda fila nueva, así que un arranque sin
+  especialistas dejaba igual las 62 tools encendidas — el usuario terminaba
+  apagando a mano lo que nunca pidió.
+
+  **Nunca borra.** La elección gobierna qué se crea, no qué se conserva: una
+  base que ya tiene sus ocho agentes no pierde ninguno por arrancar con
+  `"none"`, y se siguen reconciliando en cada arranque.
+
+  `createSwarm` acepta ahora miembros del catálogo que todavía no tienen fila:
+  con el seed en `"none"` un enjambre es el **pedido de instalación**, no una
+  referencia a algo que ya debería existir. Un id que no es del catálogo y no
+  existe sigue siendo un error.
+
+- **Crear un enjambre ahora siembra sus especialistas.** El seed selectivo
+  (`applySeedPlan`) dejaba elegir qué personas del catálogo instalar, pero
+  `createSwarm` no lo miraba: guardaba el enjambre **sin una queja** con
+  miembros apagados y sus tools inactivas. La validación de "el agente existe"
+  pasaba igual, porque el seed crea las 8 filas siempre y sólo cambia `enabled`
+  — el enjambre quedaba definido y sin poder trabajar.
+
+  `createSwarm` y `updateSwarm` aceptan `activateMembers`, **`false` por
+  defecto**: crear un enjambre no debería cambiar en silencio qué capacidades
+  tiene la instalación entera, así que sin él el enjambre se crea igual y el
+  faltante vuelve en `pendingActivation` para que la UI lo muestre y el usuario
+  decida. Con `true` se activa la unión con lo que ya estaba, de modo que
+  encender los especialistas de un enjambre nunca apaga los de otro.
+
+  Se agregó `planActivationFor(agentIds)`, que devuelve el faltante **sin
+  encender nada** —para el "esto se va a activar" antes de confirmar— y
+  `enableCatalogAgents(ids)` en plural, porque activarlos de a uno reescribía el
+  catálogo entero una vez por agente. Cubierto por `test/swarm-seed.test.ts`.
+
+- **Skills para las capacidades que no tenían ninguna.** `image_editor`
+  (`image_metadata`, `image_transform`, `artifact_inspect`) y `artifact_reader`
+  (`artifact_read`, `artifact_inspect`). Las tools existían pero ninguna skill
+  las enseñaba, así que el modelo sólo podía dar con ellas de casualidad vía
+  `search_knowledge` — y en el caso de los artefactos eso deja inerte todo el
+  mecanismo de `artifact_ref`, que existe justamente para que los archivos
+  grandes no entren en la ventana de contexto.
+
+
+- **`sessionStart` y `sessionEnd` ya se disparan.** Eran registrables desde que
+  se implementaron los hooks, pero nada los invocaba. Van enganchados a las
+  cuatro transiciones del ciclo de vida del hilo (crear, reabrir, archivar,
+  borrar), todas en `agent/thread-store.ts`. `sessionStart` cuelga del `put` que
+  crea la fila y no de `createSession`, que es idempotente y se llama en cada
+  turno: enganchado ahí habría contado mensajes en vez de conversaciones.
+  `closeSession`/`reopenSession` pasan a delegar en los nuevos `archiveThread`
+  y `unarchiveThread` para que las cuatro transiciones vivan en un solo archivo.
+  Cubierto por `test/hooks.test.ts`.
+
+### Quitado
+
+- **Cero dependencias para el cron: fuera `croner` y `cron-parser`.** El motor
+  ahora es propio (`scheduler/cron/`) y usa sólo `setTimeout` e `Intl` del
+  runtime. `cron-parser` además ni siquiera se importaba: estaba declarada en
+  los dos `package.json` y se la bajaba todo el que instalara el SDK.
+
+  `Bun.cron()` **no** sirve como reemplazo —evaluado contra el runtime 1.4.0—:
+  acepta sólo 5 campos, rechaza una fecha ISO como patrón (que es como se
+  agendan los jobs `one_shot`), ignora la zona horaria en `parse()`, y su handle
+  no expone la próxima corrida, de donde sale `next_run_at` y con lo que se
+  detectan las corridas perdidas al arrancar. Tampoco tiene equivalente de
+  `protect`, `maxRuns`, `interval`, `startAt`/`stopAt` ni `domAndDow`, todos
+  campos persistidos de `CronJobDoc`.
+
+  El motor propio conserva la superficie entera, así que `CronScheduler` no
+  cambió de comportamiento, e implementa además los dos casos de horario de
+  verano que se rompen callados: la hora que **no existe** al adelantar el
+  reloj (se saltea ese día en vez de correr a una hora inventada) y la que
+  **ocurre dos veces** al atrasarlo (corre en la primera, una sola vez). El
+  motor se exporta suelto desde `./scheduler` —`Cron`, `parseCronExpression`,
+  `isValidCronExpression`, `nextOccurrence`— para validar o previsualizar sin
+  montar un scheduler. Documentado en `docs/API-CRON.md`. Cubierto por
+  `packages/core/src/scheduler/cron/cron-engine.test.ts` (28 tests).
+
+- **`CronerOptions` (tipo público).** Estaba declarado dos veces —en
+  `scheduler/types.ts` y en `swarm/types.ts`— y no tipaba nada en ninguna parte:
+  un tipo muerto con el nombre de una librería que ya no se usa. Su forma es la
+  de `CronOptions`, que ahora exporta el motor desde `./scheduler`.
+
+- **Menciones a Croner en lo que lee el modelo.** Las descripciones de
+  `cron.create` (`start_at`, `stop_at`, `dom_and_dow`) y la skill `cron_manager`
+  citaban opciones "de Croner". Eso entra en el prompt: nombrarle al modelo una
+  librería que el código ya no usa lo manda a buscar documentación que no
+  aplica. Quedan sólo las referencias históricas que explican por qué el motor
+  es propio.
+
 ### Seguridad
 
+- **El playbook ACE no distinguía de quién era lo aprendido.** `PlaybookDoc` y
+  `ReflectionDoc` no tenían `user_id`, así que la cadena entera —trazas →
+  reflexión → regla → inyección en el system prompt— era global: lo que el
+  agente aprendía interactuando con una persona se le aplicaba a todas las demás
+  del mismo proceso. Es el mismo supuesto de "un solo usuario" que ya se había
+  cerrado en `memory`. Ahora el reflector agrupa las trazas por usuario
+  (derivado del `thread_id`), el curador propaga el dueño a la regla y deduplica
+  dentro del usuario, y las tres puertas de lectura filtran a global + propio:
+  `selectPlaybookRules(texto, userId)`, `EthicsGuard.getRules(rol, userId)` y la
+  tool `search_knowledge`. Las reglas sembradas siguen siendo globales a
+  propósito (`user_id: ""`): son conocimiento del producto, no de nadie.
+  `ensureHiveDb()` migra las filas anteriores asignándolas al primer usuario de
+  la base — dejarlas sin dueño las volvería globales, que es justo lo que se
+  viene a cerrar. Cubierto por `test/playbook-isolation.test.ts`.
+
+- **La lista blanca de tools no se aplicaba al descubrimiento dinámico.**
+  `compileContext` sólo recortaba `allTools` cuando el agente era de catálogo
+  (`source === "catalog"`). Un agente creado por el usuario veía su loadout
+  inicial restringido, pero `search_knowledge` busca contra el índice completo y
+  el agent loop inyecta lo que encuentre resolviéndolo contra `allTools`: la
+  tool excluida terminaba siendo llamable igual. Ahora la restricción depende de
+  que el agente declare una lista, no de su origen. Cubierto por
+  `test/tool-allowlist-discovery.test.ts`.
+
+- **Aislamiento de credenciales entre inquilinos.** `AgentLoopOptions` no tenía
+  forma de recibir la key del proveedor, así que la única fuente era el secret
+  store de HiveDB o `process.env[PROVIDER_API_KEY]`, ambos globales al proceso.
+  Un host multi-tenant que corriera dos workspaces en el mismo proceso les daba
+  la misma credencial. Se agregó `credentials` en `AgentLoopOptions`,
+  `IsolatedAgentOptions` y `resolveProviderConfig`; la credencial de la llamada
+  gana y corta ahí, sin consultar las fuentes globales ni mutar `process.env`.
+  Retrocompatible: sin `credentials` el comportamiento es el de siempre.
+  Cubierto por `test/tenant-isolation.test.ts`.
+
+
 - **`sanitizeDiagnostic` dejaba el token en claro detrás del esquema de auth.**
   La regex consumía sólo la palabra `Bearer`, así que un diagnóstico con
   `authorization: Bearer <token>` quedaba como `authorization: [REDACTED] <token>`
   y la credencial viajaba al prompt del coordinador. Afecta a **0.1.5 y
   anteriores**: el archivo viaja en el tarball publicado.
 
+### Cambiado
+
+- **Los tests que manejan un navegador real son opt-in (`BROWSER_TESTS=1`).**
+  Su guarda era `isWebViewSupported()`, que sólo comprueba que exista un binario
+  de Chromium — no que arranque. En un runner de CI (contenedor, a menudo root)
+  el binario está y Chromium muere igual sin `--no-sandbox`, así que ~90 tests
+  de integración fallaban por el entorno. Como los tests son condición para
+  publicar, eso bloqueaba el release. Los describe unitarios de esos mismos
+  archivos —`resolveBackendKind`, detección de motor, `normalizeCookies`,
+  `sessionPersistenceEnabled`— siguen corriendo siempre: son los que cubren el
+  contrato del backend.
+
+- **Se quitó un `mock.module` que se filtraba entre archivos de test.** El test
+  de aislamiento multi-tenant sustituía el módulo `storage/crypto` para no
+  escribir en el keychain del SO. `mock.module` es global al proceso, no al
+  archivo: mientras estuviera activo, cualquier otro test que importara ese
+  módulo recibía el doble, y `loadProviderApiKey` devolvía la key del mock. Que
+  mordiera dependía del orden de ejecución — pasaba en local y fallaba en CI.
+  Ahora el test usa un id de proveedor propio (`test-tenant-isolation`) y limpia
+  sus secretos, sin tocar el módulo ni la credencial de nadie.
+
+- **El caché de disponibilidad del keychain se envenenaba para todo el proceso.**
+  `_keychainOk` recuerda si `Bun.secrets` respondió, para no reintentar en cada
+  lectura en un servidor sin libsecret. El problema es que ese resultado valía
+  para siempre: una vez marcado como no disponible, sustituir `Bun.secrets` por
+  otro backend —o por un doble de test— no servía de nada, porque la lectura
+  cortaba antes de tocarlo. Ahora se detecta que el objeto cambió de identidad y
+  el sondeo se invalida solo. Era la causa de que el test de compatibilidad con
+  keychain fallara en CI headless (y sólo ahí).
+
+- **`resetKeychainProbe()`** en `storage/crypto.ts`. Si el keychain del SO no
+  responde, el resultado se cachea a nivel de módulo para no reintentar en cada
+  lectura — correcto en producción, pero significa que el primer sondeo vale
+  para todo el proceso. Un test que sustituya `Bun.secrets` por un doble queda
+  cortocircuitado si algo ya sondeó y falló antes, que es lo que pasa en CI
+  headless.
+
+
+- **Automatización web: un solo backend, `Bun.WebView`.** Se retiró
+  `AgentBrowserBackend`, que hablaba con el CLI de agent-browser por
+  subproceso. El motivo no es de estilo: medido en Bun 1.4 el WebView **sí**
+  corre headless (Bun lanza Chromium con `--headless`), que era la única razón
+  por la que agent-browser seguía siendo el default. Lo que quedaba era su
+  costo — ~40 ms de `Bun.spawn` por operación contra ~0,3 ms, y ~88 MB con su
+  propia copia de Chrome.
+
+  Lo importante para quien consume el paquete: el backend viejo ejecutaba
+  **`bun add agent-browser@latest` en el entorno del consumidor**, al primer uso
+  de una browser tool. Una versión flotante bajada de npm en runtime, en
+  producción. Eso ya no existe.
+
+  Requisitos ahora: un Chromium instalado (o `BUN_CHROME_PATH`) y **Bun ≥ 1.4**,
+  declarado en `engines`. La clave de config `tools.browser.backend` sobrevive:
+  `"agent-browser"` se acepta, avisa una vez y usa el WebView, así que las
+  configuraciones viejas no se rompen.
+
+- **Sesión de navegador persistente** (`tools/web/browser-session.ts`). El
+  perfil de Chrome que abre Bun es efímero —su ruta lleva un hash que cambia
+  entre procesos— así que las cookies se guardan y restauran a mano. Sin esto
+  cada reinicio empezaba sin logins. Se controla con `tools.browser.persistSession`
+  (activo por defecto).
+
+- **Nueva tool `computer_use_task`**: operar el navegador mirando la pantalla
+  —clic por coordenadas, escribir, navegar— cuando no hay un selector CSS
+  estable (canvas, UIs generadas, visores embebidos).
+
+- CI actualizado a **Bun 1.4.0**, alineado con `hive`.
+
+### Quitado
+
+- **`AgentRunner`** (`agent/providers/index.ts`). Era una capa de compatibilidad
+  con la firma de LangGraph anterior a que el runtime pasara a `agent-loop.ts`, y
+  **nunca llegó a instanciarse**: los cuatro puntos de entrada reales —el
+  gateway, `createAgent`, el worker y los ejecutores del harness— llaman
+  `runAgent()` directo. 158 líneas de código muerto. El subpath
+  `@johpaz/hive-sdk/agent/providers` sigue existiendo con sus tipos (`Provider`,
+  `ModelResponse`), que sí son parte del contrato público.
+
+### Añadido
+
+- **Streaming por token en la API pública.** `chat(mensaje, { stream: true })`
+  emite eventos `token` con los deltas del proveedor a medida que llegan. El
+  mecanismo ya existía —los proveedores llamaban `onToken` por cada delta— pero
+  **ningún punto de entrada lo pasaba**, así que nunca llegaba a nadie: la
+  respuesta aparecía de golpe al terminar el turno.
+
+- **`@johpaz/hive-sdk/services/images`** — imágenes como servicio para el usuario
+  final, no para el agente: entra y sale por bytes, se persiste por id. Incluye
+  galería (`listImages`), presets y control de retención.
+
+- **`@johpaz/hive-sdk/services` — la superficie que maneja una interfaz.** El SDK
+  estaba construido para que lo condujera el modelo: casi todo el CRUD vivía
+  dentro de las tools (`cronCreateTool`, `memoryWriteTool`, `agentCreateTool`),
+  con argumentos con forma de LLM y respuestas escritas para un prompt. Montar
+  una UI encima obligaba a llamar `tool.execute({...})` y parsear prosa, o a
+  escribir consultas crudas contra HiveDB conociendo un esquema privado.
+
+  Ahora la implementación vive en `services/` y las tools la envuelven — una
+  implementación, dos consumidores. Diez dominios: `agents`, `swarms`, `skills`,
+  `tools`, `providers`, `models`, `mcp`, `cron`, `memory`, `ethics`. Es
+  deliberadamente agnóstico del framework (funciones, no rutas HTTP): una app
+  móvil o de escritorio que embeba el runtime no quiere un servidor.
+
+  Añade tres cosas que hive no hace: **valida que las referencias existan** al
+  asignar tools/skills/MCP a un agente (hive las guarda sin comprobar, y el
+  error aparece cuando el agente intenta usarlas); **`testMcpServer()`**, que
+  allí es "guardá y esperá a que el hot-reload conecte"; y el **rename de modelo
+  transaccional**, que re-apunta a cada agente en el mismo `batch()`.
+
+- **`SwarmDoc` — los enjambres se pueden guardar.** Hasta acá un enjambre existía
+  sólo mientras corría: `runRoleSwarm()` recibe los agentes en la llamada y no
+  persiste nada, así que quien armara uno desde una interfaz lo perdía al cerrar
+  la ventana. Era el bloqueador real para poner una UI encima del SDK, y explica
+  por qué hive-cloud creó sus propias tablas en Postgres.
+
+  La validación ocurre **al guardar, no al correr**: un enjambre jerárquico sin
+  orquestador, o con un agente que ya no existe, es un error de configuración —
+  descubrirlo semanas después, cuando alguien lo ejecuta, es descubrirlo tarde.
+
+- **El harness trae ejecutores listos** (`initHarnessExecutors()`). La cola
+  durable sabía encolar, reintentar y recuperar tras un crash, pero no ejecutar:
+  registrar los ejecutores quedaba en manos de quien usara el SDK, y eso son
+  ~420 líneas de cableado —epoch, proof packets, criterios de aceptación,
+  fan-in de delegaciones— antes de correr un solo enjambre durable. Ahora vienen
+  `worker_task` (worker delegado en contexto aislado, con verificación de sus
+  criterios) y `goal_run` (varios turnos contra un objetivo hasta verificarlo o
+  agotar el presupuesto).
+
+  `chat_turn` no está a propósito: qué es un canal y cómo se transmite un token
+  lo define la aplicación. Se registra desde fuera con `registerExecutor()`.
+  Registrar sigue siendo opt-in — `initHarnessExecutors()` no se llama sola.
+
+- **`getRegisteredExecutorTypes()`** — el registro era privado, así que no había
+  forma de comprobar si un tipo quedó cableado. Un job encolado sin ejecutor no
+  falla al encolarse sino al tomarse, lejos de donde está el error.
+
+- **Superficie pública completa**: 33 subpaths (antes 28). `events/` y
+  `resilience/` no tenían barril, `canvas/` no exportaba su emitter, `artifacts/`
+  no existía como módulo, y `./events` apuntaba a un solo archivo — el
+  **agent-bus**, que es la mensajería entre workers de un enjambre, era
+  inalcanzable desde fuera. También se exponen `./tool-runtime`, `./channels`,
+  `./voice`, y `initializeBrowserService`/`activateBrowserTools`, sin los cuales
+  las browser tools estaban en el catálogo pero nadie podía arrancarlas.
+
+- **`@johpaz/hive-sdk/sessions`** — la conversación de un usuario como una sola
+  cosa. Hasta acá "sesión" estaba repartida entre `thread-store` (identidad),
+  `conversation-store` (mensajes), `run-store` (ejecución) y un `Map` en memoria
+  que moría con el proceso; no existía la consulta "qué sesiones tiene este
+  usuario". `Session` es una vista compuesta sobre las colecciones que ya
+  existían — no agrega una tercera persistencia — y `Session.id` ES el
+  `threadId`. Incluye `createSession`, `listSessions`, `appendMessage`,
+  `resumeSession`, `closeSession`/`reopenSession` y `deleteSession`.
+
+- **`@johpaz/hive-sdk/models`** — el seed de modelos con nombre propio. El
+  catálogo (18 proveedores, 110 modelos), las claves de modelo y el cálculo de
+  costo seguían viviendo bajo `storage/`; esto les da un punto de entrada sin
+  mover la implementación.
+
+- **Enjambre por roles** (`runRoleSwarm` en `@johpaz/hive-sdk/swarm`) —
+  orquestador/trabajadores con estrategias `sequential`, `parallel` y
+  `hierarchical`. Es la tercera forma de armar un enjambre, junto a la
+  delegación por catálogo y al DAG de tareas, y la única que expresa un enjambre
+  como *configuración persistida* en vez de un grafo conocido de antemano. No
+  persiste nada: `onMessage` es el punto de enganche del consumidor.
+
+- **`bun run drift`** (`scripts/check-drift.ts`) — compara los módulos del
+  cerebro contra `hive` y reporta qué falta y qué difiere, indicando de qué lado
+  está el avance. El SDK es la fuente de verdad pero nada lo garantizaba
+  estructuralmente: la última vez la divergencia llegó a compartir sólo 87 de
+  224 nombres de archivo.
+
+- **`test/exports-contract.test.ts`** — importa de verdad cada subpath declarado
+  en `exports`. Los deep-imports se han roto entre versiones sin aviso, y el
+  consumidor se defendía pineando la versión exacta.
+
 ### Corregido
 
+- **Las notificaciones no llegaban a ningún lado.** `notifyChannel` era un stub
+  que sólo hacía `console.log`, y está en el camino real: la tool `notify`, los
+  reportes de progreso, el aviso de que una tarea programada terminó, el de un
+  turno interrumpido por un crash. Un agente sobre el SDK **no podía hablarle al
+  usuario por ningún canal**, mientras `channels/manager.ts` tenía adaptadores
+  funcionales de Slack, Discord, Telegram y WhatsApp sin nada que los conectara.
+  Ahora la app registra el suyo con `setChannelManager()`; sin registro se
+  conserva el comportamiento anterior, pero avisando.
+
+- **Las imágenes se reenviaban al modelo en cada turno.** `content_multimodal`
+  guardaba el base64 completo y `toAPIMessages` lo restauraba una y otra vez:
+  cinco fotos en una conversación eran cinco fotos viajando en cada turno
+  siguiente. Ahora se guardan como artefacto y en el historial queda una
+  referencia; las de los últimos mensajes se vuelven a poner en línea, porque un
+  modelo de visión no ve una foto desde un id. Mismo criterio que
+  `clearOldToolResults`.
+
+- **`token_count` no contaba las imágenes**, así que la compactación creía que un
+  hilo lleno de fotos ocupaba lo que ocupa su texto y no se disparaba hasta que
+  el proveedor rechazaba el turno. Ahora se estiman por área, como cobran los
+  proveedores.
+
+- **`agent.context.compactionThreshold` no lo leía nadie.** Estaba en el esquema
+  de configuración y ajustarlo no hacía nada. Una opción que no hace nada es
+  peor que no tenerla, porque el usuario cree que cambió algo.
+
+- **`search_knowledge` filtraba en el lugar equivocado.** Mostraba tools fuera de
+  la lista blanca del agente. La ejecución sí estaba protegida, pero además de
+  contarle qué existe fuera de su alcance, ofrecerle algo que no puede ejecutar
+  es hacerle perder un turno.
+
+- **El seed selectivo no habría sobrevivido a un reinicio.** `reseedToolsAndSkills()`
+  escribía `active: true` para todas las tools y skills en cada arranque, así que
+  la elección del usuario sobre qué capacidades quiere en su colmena duraba hasta
+  el próximo reinicio: apagaba lo que no usaba y volvía todo. Ahora el reseed
+  preserva `active` —la descripción y la categoría siguen viniendo del código,
+  que es su fuente de verdad—, igual que ya hacía con los modelos.
+
+- **La memoria era global al proceso.** El id de `MemoryDoc` era sólo el título y
+  no había `user_id`: dos usuarios no podían tener una memoria con el mismo
+  nombre —la segunda pisaba la primera— y cualquiera veía la del otro. Coherente
+  con hive, que es mono-usuario; inservible para un runtime donde cada quien arma
+  su colmena. El id pasa a ser `${userId}:${title}` y toda lectura filtra por
+  dueño. Las filas anteriores se migran al arrancar.
+
+- **Los ids no manejaban acentos.** "Efímero" quedaba como `ef_mero` y "Diseño"
+  como `dise_o`, porque la í y la ñ no son `[a-z0-9]`. Para un producto en
+  español eso no es cosmético. `slugify()` normaliza los diacríticos antes de
+  filtrar, y se aplica también a skills y servidores MCP.
+
+- **Documentación que describía un backend retirado.** `API-TOOLS-SKILLS-CHANNELS.md`
+  seguía explicando cómo `agent-browser` se instalaba solo en `~/.hive/` al
+  primer uso — un backend que ya no existe. Reescrita para `Bun.WebView`, con la
+  nota de por qué se retiró. También se corrigieron los conteos (58→60 tools,
+  106→110 modelos) y los pies de página congelados en `v0.0.17`.
+
+
+- **Un job que moría por expiración de lease no disparaba su terminal hook.** La
+  ruta normal de fallo sí lo hacía; la de recuperación tras un crash, no. El
+  aviso al usuario y el fan-in de delegaciones se perdían en silencio justo
+  cuando más importaban.
+
+- **Los artefactos de imagen no llegaban al consumidor.** El agent loop ya los
+  emitía (`chunk.artifacts.images`, vía mcp-result-normalizer), pero el wrapper
+  `AgentRunner` no los propagaba, así que una imagen producida por una tool MCP
+  se perdía antes de salir del SDK.
+
+- **NVIDIA no emitía razonamiento.** NIM lo mantiene apagado por defecto y el
+  interruptor no es `reasoning_effort` sino `chat_template_kwargs`, con una
+  clave distinta por familia de modelo. Se añade el reintento sin esos extras
+  cuando el proveedor responde 400/422: perder el razonamiento es mejor que
+  perder el turno.
+
+- **Un turno con más de una tool call podía morir por un hueco de empaquetado.**
+  `resolveWorkerEntry()` lanzaba si no encontraba el worker; ahora devuelve null
+  y degrada a hilo principal.
+
+- **`touchThread` perdía mensajes en el contador.** El incremento se calculaba
+  fuera del reintento de `updateDoc`, así que ante un conflicto de versión el
+  reintento volvía a escribir el valor viejo. Como `addMessage` la llama sin
+  esperarla, dos mensajes seguidos del mismo hilo bastaban para que el conteo se
+  quedara corto de forma permanente. Ahora el valor se recalcula dentro del
+  bucle.
+
+- **El paquete publicaba su propia suite de tests.** Sin campo `files`, el
+  tarball llevaba 329 archivos y 2.3 MB, incluidos `test/`, `docs/`, `scripts/`
+  y los `*.test.ts` que conviven con el código. Ahora son 260 archivos y 448 kB.
+
+- **`prepublish` no verificaba nada** (era un `echo`), y además es el hook
+  deprecado. Se reemplazó por `prepublishOnly` con typecheck + tests.
+
+- **Sintaxis TypeScript que ningún runtime salvo Bun puede procesar.** Las 5
+  *parameter properties* (`constructor(private x)`) rompían incluso el
+  type-stripping nativo de Node, y como las clases se re-exportan desde el barrel
+  raíz tumbaban cualquier import del paquete. Se reescribieron a mano, sin
+  cambiar la API, y se normalizaron 355 imports relativos a extensión `.ts`
+  explícita. El paquete sigue requiriendo Bun por el uso de `Bun.*` en 18
+  archivos del core — ahora documentado en el README.
+
+
 - Se fijaron las 8 dependencias que estaban en `latest` (`zod`, `discord.js`,
   `grammy`, `@slack/bolt`, `@whiskeysockets/baileys`, `@modelcontextprotocol/sdk`,
   `qrcode-terminal`, `@sapphire/snowflake`). Como `bun.lock` no se publica, cada

package/README.md

@@ -1,3 +1,7 @@
+<p align="center">
+  <img src="docs/assets/logoblack.png" alt="Hive SDK" width="180" />
+</p>
+
 # @johpaz/hive-sdk
 
 > **Hive Agent Harness SDK** — construí, desplegá y escalá aplicaciones de agentes de IA, con soporte multi-canal, Bun Workers y orquestación en swarm.
@@ -13,19 +17,33 @@ bun add @johpaz/hive-sdk
 **Hive SDK es un Agent Harness**: un marco de trabajo completo para construir, desplegar y escalar aplicaciones de agentes de IA. A diferencia de un simple wrapper de LLM, un *harness* provee todo lo necesario para que un agente opere en producción:
 
 - **Agentes**: ciclo ReAct nativo con checkpoint durable, 16 providers LLM y descubrimiento de tools/skills por búsqueda BM25.
-- **Catálogo**: 18 providers y 106 modelos sembrados, cada uno con su precio por millón de tokens — una sola fuente de verdad para el costo.
-- **Tools**: 58 tools incluidas — filesystem, web search, browser automation (`agent-browser`), APIs (`api_request`), a2ui, office, cron, delegación.
+- **Catálogo**: 18 providers y 110 modelos sembrados, cada uno con su precio por millón de tokens — una sola fuente de verdad para el costo.
+- **Tools**: 60 tools incluidas — filesystem, web search, browser automation (`Bun.WebView`), APIs (`api_request`), a2ui, office, cron, delegación.
 - **Skills**: 23 workflows bundled, más los tuyos con `defineSkill` y `SkillLoader`.
 - **Canales**: Telegram, Discord, WhatsApp, Slack y WebChat con `ChannelManager`.
 - **Swarm**: orquestación multi-agente con `DAGScheduler`, `TaskGraph` y `WorkerPool`.
 - **Runtime**: ejecución paralela de tools vía Bun Workers.
 - **Gateway**: servidor HTTP/WebSocket para exponer agentes como API.
 - **Memoria y estado**: HiveDB (colecciones + índice BM25), scratchpad, context compiler con compactación.
+- **Servicios**: CRUD tipado de agentes, enjambres, skills, modelos, MCP y cron para montarle **la interfaz que quieras** — móvil, web o escritorio. Ver [API-SERVICES.md](./docs/API-SERVICES.md).
+- **Sesiones**: un hilo por canal y por contacto, con historial, resumen y reanudación tras un corte.
+- **Imágenes**: redimensionar y convertir con `Bun.Image`, sin dependencias nativas. Las imágenes entrantes se normalizan antes de llegar al modelo — una foto de cámara pasa de 217 KB a 4 KB.
+- **Harness**: cola durable con leases y recuperación tras crash, y ejecutores listos (`initHarnessExecutors`).
 
 Con Hive SDK no montas un agente desde cero: **enganchas tu lógica de negocio en un harness ya armado**.
 
+Y si además querés ponerle interfaz, no tenés que hablarle a la base de datos ni
+imitar el formato que espera el modelo: `@johpaz/hive-sdk/services` expone el
+mismo CRUD que usan las tools, en funciones tipadas.
+
 ## Instalación
 
+> **Requiere Bun.** El paquete se publica como TypeScript y usa APIs de Bun
+> (`Bun.secrets`, `Bun.spawn`, Workers) en 18 archivos del core, así que no
+> corre sobre Node aunque se le apliquen los flags de type-stripping. Si tu
+> backend es Node, hoy la vía es un proceso Bun aparte; el build a JS que
+> levantaría esa restricción todavía no existe.
+
 ```bash
 # Instalar globalmente para el CLI
 bun install -g @johpaz/hive-sdk
@@ -212,4 +230,4 @@ npm view @johpaz/hive-sdk dist-tags   # verificar después del release
 
 ---
 
-*Hive SDK v0.1.6 — MIT*
+*Hive SDK v0.3.0 — MIT*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@johpaz/hive-sdk",
-  "version": "0.1.6",
+  "version": "0.3.0",
   "private": false,
   "description": "Hive SDK — The Agent Harness SDK. Build, deploy, and scale AI agent applications with multi-channel support, context engineering, and swarm orchestration.",
   "license": "MIT",
@@ -35,12 +35,22 @@
     "./tools": "./packages/core/src/tools/index.ts",
     "./skills": "./packages/core/src/skills/index.ts",
     "./storage": "./packages/core/src/storage/index.ts",
+    "./services": "./packages/core/src/services/index.ts",
+    "./hooks": "./packages/core/src/hooks/index.ts",
+    "./images": "./packages/core/src/images/index.ts",
+    "./sessions": "./packages/core/src/sessions/index.ts",
+    "./models": "./packages/core/src/models/index.ts",
     "./swarm": "./packages/core/src/swarm/index.ts",
     "./swarm/strategies": "./packages/core/src/swarm/strategies/index.ts",
     "./swarm/presets": "./packages/core/src/swarm/presets/index.ts",
     "./scheduler": "./packages/core/src/scheduler/index.ts",
     "./workers": "./packages/core/src/workers/index.ts",
-    "./events": "./packages/core/src/events/event-bus.ts",
+    "./events": "./packages/core/src/events/index.ts",
+    "./resilience": "./packages/core/src/resilience/index.ts",
+    "./tool-runtime": "./packages/core/src/tool-runtime/index.ts",
+    "./channels": "./packages/core/src/channels/index.ts",
+    "./voice": "./packages/core/src/voice/index.ts",
+    "./artifacts": "./packages/core/src/artifacts/index.ts",
     "./ethics": "./packages/core/src/ethics/index.ts",
     "./canvas": "./packages/core/src/canvas/index.ts",
     "./config": "./packages/core/src/config/index.ts",
@@ -59,6 +69,19 @@
   "bin": {
     "hives": "./packages/cli/bin/hives"
   },
+  "files": [
+    "packages/core/src",
+    "packages/cli/bin",
+    "packages/cli/src",
+    "packages/cli/templates",
+    "!packages/**/*.test.ts",
+    "README.md",
+    "CHANGELOG.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "bun": ">=1.4.0"
+  },
   "workspaces": [
     "packages/core",
     "packages/cli"
@@ -70,7 +93,8 @@
     "skills:bundle": "bun scripts/generate-skill-bundle.ts",
     "version:set": "bun scripts/bump-version.ts",
     "release": "bun scripts/bump-version.ts --push",
-    "prepublish": "echo 'No build needed - Bun runs TypeScript directly'"
+    "prepublishOnly": "bun run typecheck && bun test",
+    "drift": "bun scripts/check-drift.ts"
   },
   "dependencies": {
     "@johpaz/hive-db": "^0.4.0",
@@ -81,8 +105,6 @@
     "@slack/bolt": "^4.7.2",
     "@whiskeysockets/baileys": "7.0.0-rc11",
     "async-mutex": "^0.5.0",
-    "cron-parser": "^5.5.0",
-    "croner": "^10.0.1",
     "discord.js": "^14.26.4",
     "docx": "^9.6.1",
     "grammy": "^1.42.0",

package/packages/core/src/agent/acceptance-checks.ts

@@ -13,13 +13,13 @@
  * to judge using this checks result plus the raw evidence.
  */
 
-import { col } from "../storage/hive";
-import type { AgentDoc } from "../storage/collections";
-import type { AcceptanceCriterion } from "./run-store";
-import { interpretCheckResult } from "./goal-runner";
-import { inspectArtifact } from "../artifacts/store";
-import { loadConfig } from "../config/loader";
-import { logger } from "../utils/logger";
+import { col } from "../storage/hive.ts";
+import type { AgentDoc } from "../storage/collections.ts";
+import type { AcceptanceCriterion } from "./run-store.ts";
+import { interpretCheckResult } from "./goal-runner.ts";
+import { inspectArtifact } from "../artifacts/store.ts";
+import { loadConfig } from "../config/loader.ts";
+import { logger } from "../utils/logger.ts";
 
 const log = logger.child("acceptance-checks");
 
@@ -55,8 +55,8 @@ export function sanitizeDiagnostic(value: string, limit = 1000): string {
 async function runCheckTool(criterion: AcceptanceCriterion, objective: string): Promise<AcceptanceCheckResult | null> {
   if (!criterion.checkTool) return null;
   try {
-    const { executeToolBatch } = await import("../tool-runtime");
-    const { createAllTools } = await import("../tools/index");
+    const { executeToolBatch } = await import("../tool-runtime/index.ts");
+    const { createAllTools } = await import("../tools/index.ts");
     const allTools = createAllTools(loadConfig());
     const toolDef = allTools.find((t) => t.name === criterion.checkTool);
     if (!toolDef) {