Preguntas frecuentes

¿Puedo usar Takuto libremente?

Sí. Autoalojar Takuto Core para tu propio uso — en tu máquina o dentro de tu empresa — es gratis: sin pagos al proyecto, sin límites de asientos, sin topes de uso que te imponga. El motor es source-available bajo la FSL-1.1-ALv2 y la Takuto CLI es MIT, así que eres libre de ejecutarlo, modificarlo y autoalojarlo para cualquier fin no competidor. No hay telemetría y nada hace phone-home.

El único límite que conviene conocer: la FSL prohíbe el uso competidor — no puedes usar Takuto Core para ofrecer un producto o servicio alojado que compita. El uso interno, la evaluación y el trabajo para clientes vía servicios profesionales están permitidos, y cada versión se convierte en Apache-2.0 dos años después de su lanzamiento. Si esos términos no encajan, ponte en contacto.

¿Cuánto cuesta ejecutarlo?

Takuto Core en sí no te factura — lo hace tu proveedor de IA. El agente ejecuta Claude Code, Cursor Agent, Codex o un modelo autoalojado contra tu cuenta, y cada ticket consume tokens en proporción al tamaño del código, al contexto del prompt y al número de pasos de tu workflow.

Lo que cuesta depende por completo del proveedor y el modelo que elijas — consulta sus tarifas actuales y vigila tus primeras ejecuciones para hacerte una idea de tu propia carga.

Palancas para ahorrar costes:

  • Usa pasos de comando para el trabajo determinista (lint, test) — no consumen tokens de IA.
  • Limita el contexto con [jira] ticket_context_max_description_bytes.
  • Ensaya con [general] dry_mode = true antes de apuntar a un backlog real.
  • Un modelo autoalojado vía OpenCode elimina por completo la facturación por token (solo pagas el hardware) — consulta Modelos autoalojados.

¿Está listo para producción?

Takuto Core está en beta. Es usable hoy, y hay gente ejecutando workflows reales con él — pero espera asperezas, y todo el feedback es bienvenido. El estado de beta es también la razón de que el mensaje en todo este sitio se incline hacia “pruébalo, dinos qué se rompe” en lugar de “listo para empresa”. Cada reporte ayuda a dar forma al rumbo del proyecto.

¿Puedo contribuir? ¿Por qué no se aceptan pull requests?

Takuto Core es source-available, pero el autor no acepta pull requests por ahora. Es una postura deliberada y temporal por motivos legales: el proyecto necesita tiempo para ser observado y estructurado como es debido — el licenciamiento de contribuidores, la gobernanza y las marcas tienen que estar en su sitio antes de que el código externo pueda mergearse de forma responsable.

Eso no significa que el feedback no sea bienvenido — al contrario. Los reportes de bugs, las peticiones de funcionalidades y el feedback general se desean mucho. Abre un issue o escribe a morphet.contact@gmail.com. La restricción es específicamente sobre mergear código externo, no sobre la conversación en torno al proyecto.

¿Cuáles son las licencias?

Dos componentes, dos licencias:

  • Takuto Core (el motor que autoalojas) es source-available bajo la Functional Source License 1.1 (FSL-1.1-ALv2): gratis para cualquier uso no competidor, y cada versión se convierte en Apache-2.0 dos años después de su lanzamiento. No puedes usarlo para ofrecer un producto o servicio alojado que compita. Si esos términos no encajan, escribe a morphet.contact@gmail.com — encantado de hablarlo.
  • La Takuto CLI (la herramienta complementaria de setup) está licenciada bajo MIT.

El código fuente de Takuto Core está en https://github.com/takuto-team/takuto-core; la CLI está en https://github.com/takuto-team/takuto-cli.

¿Recopiláis algún dato o telemetría?

No. Takuto Core no recopila ni transmite ninguna telemetría — sin analíticas de uso, sin reporte de crashes, sin phone-home. Puedes verificarlo tú mismo en el código fuente.

Todo el tráfico saliente pasa por un egress firewall que bloquea todo por defecto y solo habilita lo que una ejecución necesita — tu(s) proveedor(es) de IA, GitHub/Jira y los registros de paquetes (añade más con [network] extra_egress_hosts). El contenido de tus tickets, tu código fuente y tus prompts se envían solo al proveedor de IA que elegiste — Takuto Core en sí nunca los ve — y con un modelo autoalojado, nada sale de tu infraestructura.

¿Cómo se aísla? ¿Es seguro ejecutar agentes de forma autónoma?

El aislamiento es un objetivo de diseño central:

  • Cada agente corre en su propio container, así que el radio de impacto de un ataque de prompt injection se limita a ese container.
  • El egress firewall restringe lo que cualquier agente puede alcanzar por la red. La allowlist por defecto bloquea todo salvo los hosts que una ejecución necesita — el ajuste más estricto, aunque enumerar cada host se vuelve engorroso con servicios tras un CDN como GitHub. Cuando eso no es práctico, [network] allow_all_https permite todo el HTTPS saliente en su lugar; combinado con el aislamiento por container de arriba, sigue siendo una postura sólida.
  • La protección de ramas es obligatoria — los agentes empujan ramas y abren PRs, nunca hacen commit a main. Combinado con tokens acotados (un PAT de GitHub de grano fino, una cuenta de servicio limitada en Jira), esto acota lo que una sesión secuestrada puede hacer realmente.

Takuto Core añade un encuadre explícito de contenido no confiable en torno al texto de los tickets y topes de bytes opcionales, lo que reduce el riesgo de prompt injection pero no lo elimina — la revisión humana de código en los PRs sigue siendo tu red de seguridad.

¿Qué agentes de IA son compatibles?

  • Claude Code
  • Cursor Agent
  • Codex
  • OpenCode (solo para modelos autoalojados)

Eliges el proveedor en Configuración → AI Settings; cada uno tiene sus propios ajustes [agent.providers.<name>]. Consulta la referencia de configuración.

¿Qué hardware necesito?

Estas cifras son estimaciones aproximadas, no requisitos estrictos — tus necesidades reales dependen del proyecto, de tu proveedor y de tu concurrencia. Como referencia, el autor desarrolla y ejecuta Takuto Core en un Apple M1 Pro con 16 GiB de RAM.

  • RAM: ≥ 8 GiB para un solo workflow; ≥ 12 GiB en macOS con Podman (la VM necesita su propia parte). Escala con [general] max_concurrent_workflows.
  • Disco: ≥ 30 GiB libres — los worktrees, las cachés de npm/cargo, los toolchains de mise y la capa opcional de Docker-in-Docker viven todos en volúmenes de Docker.
  • SO: se recomienda un host Linux para despliegues en servidor; macOS funciona bien para uso local.
  • Los modelos autoalojados necesitan considerablemente más — dimensiona la GPU/VRAM al modelo que pretendas servir.

¿Por qué falla mi conexión a la base de datos cuando uso localhost?

Takuto corre dentro de un container, así que una cadena de conexión a localhost apunta de vuelta a Takuto mismo, no a tu base de datos. Usa el nombre de servicio del container de la base de datos y su puerto interno en una red de Docker compartida (p. ej. postgres://…@postgres:5432/…) — no localhost ni el puerto publicado en el host. Con la CLI, elige «una base de datos en un container que corre en esta máquina» en takuto setup y te lo cablea por ti. Consulta Base de datos externa.

Guardar mi PAT de GitHub o mi clave de IA falla con un error de conexión — ¿está mal mi token?

Normalmente no. Validar un token solo alcanza un endpoint del proveedor, así que un fallo casi siempre apunta a un problema de red/egress más que a una credencial incorrecta — a menudo un host respaldado por CDN como api.github.com, cuyas IPs rotan. Comprueba que la allowlist de egress resuelva los hosts actuales del proveedor, y añade los que falten con [network] extra_egress_hosts. Consulta Configuración → red.

Mi modelo autoalojado devuelve «Model not found» o errores de contexto.

Dos causas habituales: (1) carga el modelo en tu servidor con el ancho de contexto que Takuto espera — ajusta [agent.providers.opencode] context_limit para que coincida con lo que tu servidor sirve realmente (LM Studio, por ejemplo, usa 4096 por defecto, no 32768); y (2) el id del modelo debe coincidir con el identificador exacto de la API del proveedor. Consulta Modelos autoalojados.

Mis claves de API guardadas dejaron de funcionar tras resetear un volumen de Docker.

Las credenciales se cifran con una clave maestra (secret.key) almacenada en el volumen takuto-data. Si borras o recreas ese volumen, las claves selladas con la clave maestra anterior ya no pueden descifrarse — el síntoma es un confuso error de «autenticación» o «not found» en lugar de un fallo criptográfico evidente. Vuelve a abrir los ajustes del proveedor y reintroduce cada clave. Para mantener estable la clave maestra entre reseteos, provisiona TAKUTO_SECRET_KEY tú mismo en lugar de depender de la autogeneración.

La instalación de la CLI de agente falla o se rompe en el arranque — ¿qué puedo hacer?

Las CLIs de agente (claude / codex / opencode / cursor) no vienen horneadas en la imagen — Takuto las instala en el volumen de herramientas compartido en el primer arranque del container y las refresca a la latest en cada arranque. Así que una versión de CLI recién publicada puede romper una configuración que antes funcionaba: fallos de instalación, una CLI que ya no arranca o cambios de comportamiento en tiempo de ejecución.

Si te topas con esto, fija la CLI a una versión que sepas buena con version en la sub-tabla de ese proveedor, para que deje de seguir la latest:

[agent.providers.claude]
version = "2.1.178"

Esto funciona para los cuatro proveedores (claude, codex, opencode, cursor). Reinicia para que se instale la versión fijada, y luego sube la fijación de forma deliberada una vez que hayas verificado una versión más reciente. Consulta Configuración → instalación de las CLIs de agente y fijación de versión.

¿A quién se atribuyen los commits y los PRs — a mí o a un bot?

La atribución sigue tus credenciales, del mismo modo para los commits y los pull requests: con un GitHub PAT, ambos se atribuyen a ti; con una GitHub App sola (sin PAT), ambos se atribuyen al bot. No hay un interruptor por ejecución. Consulta GitHub App.

¿Por qué «Mark as Done» no mueve mi ticket de Jira?

Mark as Done transiciona el ticket a tu [jira] done_status. Falla cuando el workflow de tu proyecto de Jira no tiene ninguna transición desde el estado actual del ticket a ese estado, o cuando tu token carece de permiso de transición. Ajusta done_status a un estado que sea realmente alcanzable en el workflow de tu tablero. (El nombre del estado en sí se compara de forma independiente del idioma, así que nombres localizados como «Terminé(e)» siguen resolviéndose a «Done».)

¿Puedo alojar Takuto tras un dominio público?

Sí. Ponlo detrás de un reverse proxy con TLS (consulta Instalar Takuto Core) y apóyate en la autenticación multiusuario integrada. Como ese login es la puerta de entrada y Takuto aún no admite 2FA/OTP ni llaves de seguridad (passkeys/WebAuthn), usa una contraseña fuerte y única para cada cuenta. Las protecciones integradas ayudan — hash de contraseñas con argon2, bloqueo de cuenta tras intentos fallidos repetidos y limitación de tasa por IP en el login — pero la contraseña es tu principal línea de defensa por ahora. Mantén la protección de ramas y los tokens acotados como red de seguridad.

¿A dónde voy ahora?