Todos los issue trackers que has usado siguen el mismo patron. Hay un servicio en la nube. Tiene una interfaz web. Alguien construye un CLI que habla con la API de la nube. El CLI es un ciudadano de segunda clase: mas lento, menos capaz, siempre una version de API atras.

Ahora invierte esa arquitectura. Empieza con el CLI. Haz que escriba en una base de datos local. Haz que la base de datos tenga control de versiones, con las mismas semanticas de branching y merging que usas en tu codigo 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 razon por la que esta arquitectura existe son los agentes de IA.

El problema: los agentes no pueden hacer clic en botones

Si estas coordinando una flota de agentes de IA (generadores de codigo, 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, rapido, con cero dependencias de red.

beads es ese CLI. Es un issue tracker open-source, Git-native, disenado exactamente para este flujo de trabajo. 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 numeros importan aqui. bd create toma aproximadamente 15ms. bd list a traves de 10,000 issues retorna en unos 200ms. Estos benchmarks provienen de la suite de tests de beads. Cuando los agentes estan procesando items de trabajo en loops cerrados, los milisegundos por operacion determinan si tu issue tracker aguanta el ritmo o se convierte en el cuello de botella.

Por que Dolt y no SQLite?

Dolt es una base de datos SQL que implementa semanticas de Git. Cada escritura es un commit. Obtienes dolt diff para ver que cambio entre dos puntos. Obtienes dolt log para el historial de auditoria completo. Obtienes dolt branch y dolt merge con el mismo modelo mental que ya usas en tu codigo.

Para issue tracking, esto significa que tu historial de proyecto tiene dos pistas de auditoria paralelas: git log para cambios de codigo, dolt log para cambios de issues. Puedes responder preguntas como "como se veia la base de datos de issues cuando taggeamos v2.1.0?" revisando ese punto en el historial de Dolt. Puedes hacer branch de tu base de datos de issues para experimentar con una reorganizacion, y luego hacer merge de vuelta o descartarlo.

beads elimino el soporte de SQLite en v0.9.0 y aposto todo a Dolt. Las semanticas de control de versiones no son un nice-to-have; son la base. Cuando veinte agentes estan escribiendo en la misma base de datos de issues, quieres la capacidad de hacer diff, branch y merge de esos datos con la misma confianza que tienes en tu control de versiones.

La colaboracion opcional funciona a traves de DoltHub. Haz push de tu base de datos de issues a un remoto, haz pull de los cambios de tus companeros. El mismo flujo 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 vision general. Grafos de dependencias, arboles de progreso de epics, cadenas de issues bloqueados: son problemas espaciales que una terminal no puede renderizar bien.

Beadbox es una aplicacion de escritorio nativa construida con Tauri (no Electron) que lee el mismo directorio .beads/ al que el CLI escribe. No hay paso de importacion, no hay proceso de sincronizacion, no hay capa de API. La GUI observa el filesystem via fs.watch(), detecta cambios en la base de datos Dolt, y transmite las 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.

Asi se ve el flujo de trabajo en la practica:

# 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, arboles de epics, filtro por estado/prioridad/asignado
# No se necesitan comandos. Solo mira.

# El agente termina y lo marca para revision
bd update BEAD-42 --status ready_for_qa

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

Los agentes escriben a traves del CLI. Los humanos leen a traves de la GUI. Ambos operan sobre la misma base de datos Dolt local. Sin reconciliacion, sin caches obsoletas, sin "dejame refrescar."

Beadbox funciona en macOS, Linux y Windows. Soporta multiples workspaces, asi que puedes cambiar entre proyectos sin reiniciar.

Lo que "local-first" realmente significa

El termino 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, apuntala a un directorio. Listo.

Sin dependencia de la nube. Todo corre en tu filesystem. Tus datos nunca salen de tu maquina a menos que explicitamente hagas dolt push a un remoto. Se cae internet? Nada cambia. Sigues trabajando.

Sin servidor. No hay daemon que administrar, no hay contenedor Docker que ejecutar. La base de datos Dolt es un directorio de archivos. El CLI lee y escribe esos archivos. Beadbox observa esos archivos.

Colaboracion opcional. Cuando quieras compartir, haz push a DoltHub. Tus companeros hacen pull. Los conflictos de merge en datos de issues se resuelven de la misma forma que en codigo. Pero esto es opt-in, no obligatorio.

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

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

Para quien es esto

Si ejecutas agentes de IA que necesitan coordinarse a traves de una cola de trabajo compartida, y quieres que los humanos monitoreen y dirijan ese trabajo visualmente, este stack fue construido para tu flujo de trabajo.

Si gestionas proyectos en solitario y quieres issue tracking con control de versiones que viva junto a tu codigo, sin una cuenta en la nube, este stack tambien funciona para eso.

Si necesitas el modelo de permisos enterprise de Jira o la edicion colaborativa en tiempo real de Linear a traves de un equipo distribuido, esta no es la herramienta correcta. beads es local-first por diseno. Eso es un tradeoff, no un descuido.

Para 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 de datos beads en cualquier proyecto:

cd your-project
bd init

Abre Beadbox, apuntalo al directorio, y estaras viendo tu tablero de issues. Sin registro. Sin wizard de configuracion. Sin modal de "conecta tu cuenta de GitHub".

Beadbox es gratis durante la beta.