Cada issue tracker que has usado sigue el mismo patrón. Hay un servicio cloud. Tiene una interfaz web. Alguien construye un CLI que habla con la API del cloud. El CLI es un ciudadano de segunda clase: más lento, menos capaz, siempre una versión de API por detrás.

Ahora invierte esa arquitectura. Empieza con el CLI. Haz que escriba en una base de datos local. Haz que la base tenga control de versiones, con la misma semántica de branching y merging que usas en el código fuente. Luego pon una app de escritorio nativa encima que lea los mismos archivos de base de datos directamente, sin API de por medio.

Eso es lo que hacen beads y Beadbox. Y la razón por la que esta arquitectura existe son los agentes IA.

El problema: los agentes no pueden hacer clic en botones

Si coordinas una flota de agentes IA (generadores de código, revisores, testers, deployers), necesitas que creen issues, actualicen estados y lean colas de trabajo. No pueden autenticarse en Jira. No pueden navegar la UI de Linear. Necesitan un CLI que escriba en una base de datos local, rápido, con cero dependencias de red.

beads es ese CLI. Es un issue tracker open-source, Git-native, diseñado exactamente para este workflow. El comando bd crea, actualiza, lista y cierra issues. Cada escritura aterriza en una base de datos local Dolt dentro del directorio .beads/ de tu repositorio.

Los números importan aquí. bd create toma aproximadamente 15 ms. bd list a través de 10.000 issues retorna en unos 200 ms. Estos benchmarks vienen de la suite de tests de beads. Cuando los agentes procesan items de trabajo en bucles cerrados, los milisegundos por operación determinan si tu issue tracker mantiene el ritmo o se convierte en el cuello de botella.

¿Por qué Dolt, no SQLite?

Dolt es una base de datos SQL que implementa semántica Git. Cada escritura es un commit. Obtienes dolt diff para ver qué cambió entre dos puntos. Obtienes dolt log para historial de auditoría completo. Obtienes dolt branch y dolt merge con el mismo modelo mental que ya usas en el código.

Para issue tracking, esto significa que el historial de tu proyecto tiene dos rastros de auditoría paralelos: git log para cambios de código, dolt log para cambios de issues. Puedes responder preguntas como "¿cómo era la base de issues cuando tagueamos v2.1.0?" haciendo checkout de ese punto en la historia de Dolt. Puedes hacer branch en tu base de issues para experimentar con una reorganización, luego mergearla o descartarla.

beads eliminó el soporte de SQLite en v0.9.0 y apostó todo por Dolt. La semántica de control de versiones no es un nice-to-have; es el fundamento. Cuando veinte agentes escriben en la misma base de issues, quieres la capacidad de hacer diff, branch y merge de esos datos con la misma confianza que tienes en tu control de código fuente.

La colaboración opcional funciona a través de DoltHub. Haz push de tu base de issues a un remoto, y tus compañeros hacen pull. El mismo workflow push/pull de Git, aplicado a datos estructurados.

La capa visual: Beadbox

Los agentes prosperan con CLIs. Los humanos no, al menos no cuando necesitan la visión general. Grafos de dependencias, árboles de progreso de épicas, cadenas de issues bloqueados: son problemas espaciales que un terminal no puede renderizar bien.

Beadbox es una aplicación de escritorio nativa construida con Tauri (no Electron) que lee el mismo directorio .beads/ al que el CLI escribe. Sin paso de importación, sin proceso de sincronización, sin capa de API. La GUI vigila el sistema de archivos vía fs.watch(), detecta cambios en la base Dolt y transmite actualizaciones por un WebSocket local. Cuando un agente ejecuta bd update BEAD-42 --status in_progress, el badge de estado cambia en Beadbox en milisegundos.

Así se ve el workflow en la práctica:

# Un agente crea un issue
bd create --title "Migrate auth to OIDC" --type task --priority 1

# Otro agente lo reclama
bd update BEAD-42 --claim --actor agent-3

# Un humano abre Beadbox y ve el tablero completo:
# grafos de dependencias, árboles épicos, filtros por status/prioridad/asignado
# Sin comandos. Solo mirar.

# El agente termina y lo marca para revisión
bd update BEAD-42 --status ready_for_qa

# Beadbox se actualiza en tiempo real. El agente de QA lo toma.

Los agentes escriben a través del CLI. Los humanos leen a través de la GUI. Ambos operan sobre la misma base Dolt local. Sin reconciliación, sin cachés desactualizados, sin "déjame refrescar."

Beadbox funciona en macOS, Linux y Windows. Soporta múltiples workspaces, así que puedes cambiar entre proyectos sin reiniciar.

Lo que "local-first" realmente significa

El término se usa demasiado. Esto es lo que significa concretamente para beads y Beadbox:

Sin cuenta. No te registras en nada. Instala el CLI, instala la app, apúntala a un directorio. Listo.

Sin dependencia de la nube. Todo corre en tu sistema de archivos. Tus datos nunca salen de tu máquina a menos que explícitamente hagas dolt push a un remoto. ¿Se cae internet? Nada cambia. Sigues trabajando.

Sin servidor. No hay demonio que gestionar, no hay contenedor Docker que correr. La base Dolt es un directorio de archivos. El CLI lee y escribe esos archivos. Beadbox vigila esos archivos.

Colaboración opcional. Cuando sí quieres compartir, haz push a DoltHub. Tus compañeros hacen pull. Los conflictos de merge en datos de issues se resuelven igual que en código. Pero es opt-in, no obligatorio.

Compara esto con las alternativas. Jira necesita un servidor (o Atlassian Cloud). Linear necesita cuenta y conexión a internet. GitHub Issues necesita un repositorio en los servidores de GitHub. Incluso las opciones self-hosted como Gitea requieren correr un servicio web.

beads necesita un directorio. Beadbox necesita ese mismo directorio y un doble clic.

Para quién es esto

Si corres agentes IA que necesitan coordinarse a través de una cola de trabajo compartida, y quieres que los humanos monitoreen y dirijan ese trabajo visualmente, este stack fue construido para tu workflow.

Si gestionas proyectos en solitario y quieres issue tracking con control de versiones que viva junto a tu código, sin cuenta cloud, este stack también funciona para eso.

Si necesitas el modelo de permisos enterprise de Jira o la edición colaborativa en tiempo real de Linear a través de un equipo distribuido, esta no es la herramienta correcta. beads es local-first por diseño. Es un tradeoff, no un descuido.

Empezar

Instala el CLI de beads desde github.com/steveyegge/beads, luego instala Beadbox:

brew tap beadbox/cask && brew install --cask beadbox

Inicializa una base beads en cualquier proyecto:

cd your-project
bd init

Abre Beadbox, apúntalo al directorio, y estás viendo tu tablero de issues. Sin registro. Sin wizard de configuración. Sin modal de "conecta tu cuenta de GitHub."

Beadbox es gratuito durante la beta.