Apra-fleet

---

Este repositorio está construido por el producto que estás viendo. Un flujo de trabajo autónomo de apra-fleet planifica, codifica, revisa, prueba y publica este código base en sprints de varias horas — reportando errores contra sí mismo y corrigiéndolos. La grabación anterior es una ejecución real, no una maqueta.

---

¿Por qué una flota?

Ejecutar un solo agente de IA es una demo. Ejecutar cincuenta — en una MacBook en la oficina, una caja con GPU en el laboratorio, tres VMs en la nube y tu CI — es un problema de operaciones que nadie más ha resuelto:

• ¿Qué máquina ejecuta qué agente? Dispositivos reales, no sandboxes desechables: miembros registrados, con credenciales y verificación de salud que ya posees.
• ¿Qué modelo hace qué trabajo? Claude para revisión, un nivel económico para ediciones mecánicas, un modelo local vLLM para datos privados — todo en una sola flota, enrutado por nivel de costo, cambiable por tarea.
• ¿Quién vigila a los agentes? Flujos de trabajo duraderos con supervisores, perros guardianes, reservas y paneles en vivo. Los agentes que mueren se detectan. El trabajo que se estanca se reanuda. Nada se ejecuta en silencio.
• ¿Quién tiene las llaves? Secretos ingresados fuera de banda, nunca visibles para ningún modelo. Composición de permisos por proveedor. Política de egreso de red por credencial.

Un plano de control. Cualquier dispositivo. Cualquier modelo. Cualquier flujo de trabajo. Cualquier dominio.

Lo que obtienes

Pilar	Concretamente
Cualquier dispositivo	Registra cualquier máquina Windows / macOS / Linux (local o por SSH) como miembro de la flota con un solo comando. Los miembros en la nube se inician automáticamente bajo demanda. Los miembros Windows son totalmente compatibles para despacho, ejecución de comandos y tareas de larga duración en segundo plano (lanzadas de forma desacoplada vía WMI).
Cualquier modelo	Claude, Codex, Copilot, Antigravity, modelos locales (cualquier endpoint compatible con OpenAI vía OpenCode) — mezclados libremente. El enrutamiento por niveles (económico / estándar / premium) mantiene la gobernanza de costos integrada. La revisión entre proveedores es un mecanismo de calidad: un modelo diferente, con diferentes puntos ciegos, verifica cada cambio.
Cualquier flujo de trabajo	Los flujos de trabajo son programas duraderos, no cadenas de prompts: de varias horas, reanudables, observables, con reservas de miembros y estado atómico. Escribe el tuyo; envíalo a la flota.
Cualquier dominio	No solo desarrollo de software. El patrón encaja dondequiera que el trabajo se descomponga en piezas de tamaño agéntico que necesiten orquestación y un rastro de auditoría: reposición minorista nocturna (conciliar deltas de inventario, redactar órdenes de compra para aprobación), manejo de excepciones logísticas (triar un envío retrasado, re-reservar, notificar), admisión de salud (resumir referencias, verificar integridad, enrutar), ejecuciones de back-office (conciliación de facturas, recolección de evidencia de cumplimiento). La ingeniería de software es el vertical que se ejecuta hoy — tu dominio está a un flujo de trabajo de distancia.

Observa una flota trabajar

Nuestro flujo de trabajo insignia, fleet-sprint, desarrolla software de forma autónoma: planificar -> desarrollar -> revisar -> desplegar -> prueba de integración -> cosechar, en ciclos, hasta que se cumpla el objetivo o la evidencia diga detenerse.

No es un juguete. Construye apra-fleet en sí mismo:

• Sprints de múltiples ciclos que se ejecutan durante horas, sin supervisión
• Más de 2,300 pruebas unitarias y una suite de integración de 81 archivos contra backends reales
• Reporta errores contra sí mismo, los descompone, los corrige y bloquea su propio lanzamiento hasta que las puertas de calidad pasen
• Cada despacho, veredicto y dólar visible en vivo en el panel
• El stdout/stderr crudo de cada hijo de sprint se captura en un registro por sprint y se enlaza desde el panel, para que la salida de una ejecución sea rastreable incluso si se bloquea antes de reportar algo

Una flota que ha estado en producción:

pm-1      Opus (premium)      orchestrator
doer-1    Sonnet (standard)   feature work
doer-2    Antigravity         large-context tasks
reviewer  Opus (premium)      final review

El motor no sabe qué es un "sprint"; sabe cómo ejecutar tu flujo de trabajo de manera confiable en tu flota (ver Cualquier dominio arriba).

Inicio rápido (5 minutos)

1. Instala — un solo comando vía npm (Node.js 22+), o toma el binario instalador independiente para tu plataforma desde Releases y haz doble clic en él (la instalación es la acción predeterminada):

npm install -g @apralabs/apra-fleet
apra-fleet install           # installs for Claude Code (default)
apra-fleet install --llm agy # or --llm opencode / codex / copilot
cd ~/.apra-fleet/bin && apra-fleet start             # start the apra-fleet

La instalación predeterminada incluye fleet-se (fleet-sprint, supervisor, bd), que requiere un Node.js 22.16+ del sistema y npm en PATH; el instalador falla de inmediato si faltan. Usa apra-fleet install --workflows none para instalar solo el núcleo.

2. Conecta tu agente. Carga el servidor de flota en Claude Code con /mcp (o reinicia el CLI de tu proveedor). Tu agente ahora tiene una flota.

3. Registra miembros — en lenguaje natural. apra-fleet se maneja conversacionalmente a través de cualquier agente compatible con MCP:

"Registra un miembro local llamado doer. Registra otro llamado reviewer. Emparejalos."

"Registra 192.168.1.10 como build-server. Usuario akhil, carpeta de trabajo /home/akhil/projects/myapp."

Las contraseñas remotas se recopilan fuera de banda — escritas en una terminal separada, nunca en el chat — se usan una vez para configurar claves SSH y luego se olvidan.

4. Ejecuta tu primer flujo de trabajo:

apra-fleet workflow hello-world

Luego apunta la flota al trabajo real:

apra-fleet workflow fleet-sprint \
  --issue my-project-epic --members doer \
  --branch fleet-sprint/first-run --base main

Abre el panel, observa tu flota PLANIFICAR->CONSTRUIR->REVISAR->PROBAR->PUBLICAR en un bucle hasta el cierre

¿Nuevo en fleet-sprint? Lee la Guía de inicio de fleet-sprint (Markdown si estás leyendo esto en GitHub — PDF) — un recorrido en lenguaje sencillo de lo que hace, lo que necesitas preparar (backlog de beads, deploy.md, playbooks de prueba, registro de miembros), cómo lanzar y monitorear un sprint, y qué está automatizado versus qué sigue siendo tu decisión.

Ejecutar fleet-sprint después de npm install: el comando apra-fleet workflow fleet-sprint ... anterior es el mismo comando para todos — ya sea que hayas instalado vía npm install -g @apralabs/apra-fleet, el binario independiente o un checkout de desarrollo desde git clone. No hay un comando fleet-sprint separado para instalar o recordar. Consulta la referencia completa de banderas para cada opción.

Cómo funciona

Arquitectura en capas

Documentación de componentes: fleet-sprint | auto-sprint.js | apra-fleet-client | apra-pm | apra-fleet-mcp | Roles de agente

Topología de despacho de flota

flowchart LR
    CP["Control Plane<br/>(Server, Engine, Supervisor)"] -->|Dispatch & Sync| M1["MacBook<br/>(Claude)"] & M2["Linux GPU<br/>(vLLM)"] & M3["Cloud VM<br/>(AGY)"] & M4["Windows<br/>(OpenCode)"]

• Servidor de flota: el plano de control. Registra miembros, despacha comandos y prompts, mueve archivos, media credenciales. Habla MCP, por lo que cualquier agente compatible con MCP puede manejar una flota. execute_prompt admite bifurcación de sesiones (fork) en proveedores con capacidad de bifurcación — ramifica una sesión nueva e independiente desde el contexto de una existente (por ejemplo, una sesión preparada reutilizada en despachos por tarea) sin continuar escribiendo en la sesión fuente. Consulta docs/mcp-tools.md para el contrato de parámetros.
• Miembros: máquinas reales que ejecutan CLIs de proveedores. Componen permisos nativos del proveedor antes de cada despacho; los modos sin supervisión están limitados, nunca generales.
• Motor de flujos de trabajo: ejecuta programas de flujo de trabajo con fases, reintentos, presupuestos de turnos, sesiones reanudables, estado persistente por actividad y una puerta cooperativa de pausa/reanudación a la que cualquier flujo de trabajo puede conectarse.
• Supervisor: capa siempre activa — lanzar, pausar/reanudar y detener sprints por HTTP, libro de reservas de miembros, perro guardián de bloqueos (incluyendo un estado "pausado" en vivo e indicador de desviación de la rama base), historial de ejecuciones.

Capa de conocimiento

Cada sesión de agente comienza llamando a kb_session_prime. La KB verifica qué archivos han cambiado desde la última lectura y devuelve exactamente esos. Los archivos sin cambios se sirven desde resúmenes en caché — sin relectura, sin tokens desperdiciados.

Cold session:  kb_session_prime returns stale_files=[a.ts, b.ts, c.ts]
               Agent reads all three, calls kb_capture for each.
Warm session:  kb_session_prime returns stale_files=[], session_warm=true
               Agent works from KB summaries. Zero file reads.

Herramientas MCP que se incluyen con la KB:

Herramienta	Qué hace
kb_session_prime	Prepara una sesión: archivos obsoletos, resúmenes frescos, lista de llamadas de GitNexus
kb_capture	Almacena un aprendizaje, caché de contexto, runbook o entrada de conocimiento
kb_query	Recuperación FTS de dos niveles (L1: título+resumen, L2: contenido completo)
kb_list	Lista entradas de auditoría por confianza/tipo/módulo/símbolo (solo lectura, sin incremento de use_count)
kb_context	Verificación de frescura de archivos por lotes (una sola llamada git para N archivos)
kb_invalidate	Marca archivos como obsoletos de inmediato (también llamado por el hook de git)
kb_promote	Avanza la confianza: UNVERIFIED -> INFERRED -> CONFIRMED
kb_harvest	Extrae aprendizajes de una transcripción de sesión (se dispara automáticamente después de execute_prompt)
kb_export	Escribe entradas CONFIRMED en vivo en .fleet/kb-canonical.json — la biblia del equipo compartible por git
kb_setup	Instala el hook de git, escribe la configuración del proveedor, almacena el token remoto cifrado

kb_setup --remote <url> --token <key> surte efecto de inmediato: la siguiente llamada a una herramienta de KB resuelve su proveedor de proyecto desde esta configuración, por lo que una compilación estándar apunta a un servidor KB remoto solo por configuración, sin cambio de código y sin una compilación separada de "modo servidor". Una configuración sin remoto, o cualquier configuración que el lector no pueda analizar, siempre recurre al proveedor SQLite local — consulta Selección de proveedor del lado del cliente para la regla de selección exacta y su invariante de construcción de respaldo.

La configuración del proveedor es a nivel de instalación, no por repositorio. Hay un knowledge/config.json por instalación de flota, por lo que apuntarlo a una KB remota apunta CADA repositorio que sirve la instalación — cada miembro, cada proyecto — a ese servidor. El repo_path de kb_setup solo elige qué repositorio recibe el hook post-commit de git; no limita la configuración. En un servidor de flota compartido, trata kb_setup --remote como un cambio para todos sus usuarios.

Cada llamada a una herramienta de KB está limitada al repositorio al que se refiere — un servidor de flota que maneja muchos miembros en muchos repositorios nunca permite que los aprendizajes de un repositorio aterricen en la KB de otro repositorio. El alcance normalmente se deriva de la ruta del repositorio del llamador; las herramientas también aceptan un repo_remote_url explícito para que un miembro remoto (cuya carpeta de trabajo es una ruta en otro host, inalcanzable desde el sistema de archivos del servidor de flota) resuelva a la misma KB de proyecto que un clon local de ese repositorio en lugar de una base de datos de respaldo compartida. La cosecha automática posterior al prompt y la ruta de enriquecimiento de KB code_context también reenvían esta URL, y una ruta de carpeta de trabajo inalcanzable nunca se intercambia silenciosamente por el directorio de trabajo del propio servidor de flota — consulta Aislamiento de KB por repositorio para las reglas completas de anclaje y clave de caché.

El backend es intercambiable: comienza con SQLite local, agrega un servidor HTTP central para un equipo, o conecta Postgres más tarde — todo mediante un cambio de configuración de una línea.

Consulta docs/knowledge-layer.md para la guía completa.

Explora con agentes. Opera con programas.

Hay dos formas de orquestar agentes, y apra-fleet se basa en la observación de que necesitas ambas — en diferentes etapas de la vida de un flujo de trabajo:

• Modo exploración. Mientras un flujo de trabajo aún se está descubriendo, deja que un LLM lo orqueste: flexible, adaptable y hambriento de tokens -- cada paso es una decisión, y cada decisión cuesta pensamiento.
• Modo operación. Una vez que sabes lo que debe suceder, el flujo de control se convierte en un programa de flujo de trabajo determinista. Los pasos de shell, git y archivos se ejecutan a través de execute_command -- cero tokens. El modelo se invoca solo en las esquinas que realmente requieren juicio (execute_prompt): revisa este diff, planifica este backlog, decide esta excepción.

Eso no es una proyección -- es el propio paso de configuración y desmontaje e2e de este repositorio, antes y después de que lo endureciéramos. Los tokens de desarrollo no son tokens de operación: paga una vez para descubrir el flujo de trabajo, luego ejecútalo gratis.

	Orquestado por LLM (explorar)	Orquestado por flujo de trabajo (operar)
Flujo de control	el modelo decide cada paso (tokens)	programa determinista (gratis)
Pasos de shell / git / archivos	narrados a través del modelo	execute_command, cero tokens
Dónde se ejecuta el modelo	en todas partes	solo nodos de juicio (execute_prompt)
Curva de costos	escala con cada paso	escala solo con el pensamiento
Modo de fallo	deriva y reintentos silenciosos	errores tipados, estado reanudable

El colapso es bidimensional. A medida que un flujo de trabajo se endurece, el flujo de control se mueve del modelo al programa -- y los nodos de juicio que permanecen se mueven de modelos de frontera a otros más baratos, porque una tarea bien especificada ya no necesita razonamiento de nivel descubrimiento. Desarrolla un flujo de trabajo con Claude; operacionalízalo en OpenCode contra un modelo local o de OpenRouter. Misma flota, mismo flujo de trabajo -- intercambia los miembros. El enrutamiento por niveles lo convierte en un cambio de registro, no en una reescritura.

Solo una flota hace posible ese intercambio. Las herramientas de un solo proveedor no pueden dejar a su proveedor; los frameworks en proceso no pueden mover la orquestación fuera de la ruta de tokens. Debido a que la unidad de ejecución de apra-fleet es el miembro -- una máquina más un proveedor, intercambiable en el registro -- el mismo flujo de trabajo endurecido se ejecuta en modelos de frontera el día que lo diseñas y en modelos de bajo costo todos los días después.

fleet-sprint es este principio, vivido: comenzó como exploración orquestada por LLM; cada patrón descubierto se endureció en el motor determinista; hoy el motor impulsa ejecuciones autónomas de una hora en las que los modelos se consultan solo como planificador, ejecutor, revisor, probador y recolector.

Comparación con alternativas

Herramienta	Superposición	Dónde difiere apra-fleet
Asistentes de codificación de agente único	La IA escribe código	Una flota añade agentes que revisan, prueban y despliegan el trabajo de los demás -- entre proveedores.
Runners autoalojados de CI	Ejecuta trabajo en otras máquinas	Conversacional y con estado, no activado por pipeline; los agentes llevan contexto entre fases.
SkyPilot / dstack	Cómputo multimáquina	Coordina agentes y su contexto, credenciales y permisos -- no solo trabajos.
Google A2A	Mensajería agente a agente	Una capa de orquestación y operaciones con opinión, no solo un transporte.
Frameworks de agentes (LangGraph, CrewAI, ...)	Lógica multiagente	Esos componen agentes dentro de un proceso; apra-fleet opera agentes a través de máquinas reales, proveedores y flujos de trabajo de días de duración.

Cuándo NO usarlo: un cambio único de un solo archivo no necesita una flota.

Modelo de seguridad, en un párrafo

Los secretos se ingresan fuera de banda en un almacén de credenciales y se referencian como {{secret.NAME}} -- resueltos en el lado del servidor en la ejecución, nunca visibles para ningún LLM o registro; consulta docs/secret-variables.md. Las credenciales se limitan a los miembros, expiran con TTL y pueden llevar una política de egreso de red (permitir / denegar / confirmar). Cada miembro se ejecuta con archivos de permisos compuestos y nativos del proveedor -- herramientas en lista blanca, no modo dios. El acceso a VCS se aprovisiona y es revocable por miembro, en GitHub, Bitbucket y Azure DevOps -- las diferencias de host (forma de URL, dialecto REST de PR, patrón de autenticación, vocabulario de errores) se ocultan detrás de un descriptor por proveedor en lugar de filtrarse en código compartido; consulta docs/design-azure-devops-vcs-auth.md para los detalles de ensamblaje de credenciales y vida útil de PAT del proveedor de Azure DevOps. Un comando de VCS que requiere credenciales puede entregarse al servidor para su ejecución (vcs_credential_exec) en lugar de que el orquestador aprenda el token en texto plano: el servidor sustituye la credencial en el comando, lo ejecuta en el miembro, y redacta el token de cada campo del resultado -- el texto plano nunca transita por una salida legible por el orquestador. La composición de permisos verifica su propia entrega: una concesión se lee de vuelta del miembro objetivo y se compara estructuralmente con lo que se pretendía antes de que se informe como aplicada, por lo que una escritura fallida o parcial se muestra como un fallo explícito en lugar de un éxito falso.

Configuración de correo electrónico

La herramienta send_email de la flota envía correo electrónico a través de SendGrid o SMTP. Los secretos se almacenan en el almacén de credenciales de la flota. La configuración no secreta (proveedor, host, puerto, dirección de origen) se pasa por el flujo de trabajo en cada llamada.

Almacenamiento de secretos (configuración única)

Almacena los secretos de correo electrónico a través de la CLI:

# SendGrid API key
apra-fleet secret --set sendgrid_api_key --persist

# SMTP password
apra-fleet secret --set smtp_password --persist

O a través de la herramienta MCP (la ruta que usa un agente LLM):

{ "name": "sendgrid_api_key", "prompt": "Enter your SendGrid API key", "persist": true }

Los secretos se cifran en el almacén de credenciales de la flota. Nunca aparecen en el código del flujo de trabajo, archivos de configuración o variables de entorno.

Envío de correo electrónico desde un flujo de trabajo

El flujo de trabajo pasa la configuración no secreta en línea y llama a send_email. Carga tu configuración como prefieras (archivo JSON, codificado, etc.):

import { parseToolJson } from '@apralabs/apra-fleet-client';
import { connectFleet } from '@apralabs/apra-fleet-client/server-resolution';

const { fleetApi } = await connectFleet({ env: process.env });

// fleetApi wrappers return the raw MCP tool result ({ content: [...] });
// parseToolJson extracts the JSON payload.
const result = parseToolJson(await fleetApi.sendEmail({
  provider: 'smtp',
  host: 'smtp.example.com',
  port: 587,
  user: 'notifications@example.com',
  from: 'noreply@example.com',
  to: 'team@example.com',
  subject: 'Sprint Report',
  body: 'All tasks completed.'
}));
console.log(`Sent: ${result.messageId}`);

La contraseña SMTP se resuelve automáticamente desde el almacén de credenciales. Nunca aparece en el flujo de trabajo. Consulta examples/workflows/email-notify/ para un ejemplo ejecutable completo y docs/email-workflow-guide.md para el tutorial completo.

Referencia de la herramienta send_email

Parámetro	Tipo	Requerido	Descripción
provider	"sendgrid" o "smtp"	no (predeterminado: "sendgrid")	Proveedor de correo electrónico
from	string	sí	Dirección de correo del remitente
host	string	solo SMTP	Nombre de host del servidor SMTP
port	number	no (predeterminado: 587, o 465 cuando secure es verdadero)	Puerto del servidor SMTP
user	string	solo SMTP	Nombre de usuario SMTP
secure	boolean	no (predeterminado: falso)	TLS implícito (puerto 465). Cuando es falso, se requiere STARTTLS.
to	string o string[]	sí	Dirección(es) de correo del destinatario
subject	string	sí	Línea de asunto del correo electrónico
body	string	sí	Cuerpo del correo en texto plano
html	string	no	Cuerpo del correo en HTML
cc	string[]	no	Direcciones de destinatarios en CC
bcc	string[]	no	Direcciones de destinatarios en CCO
attachments	attachment[]	no	Archivos adjuntos (codificados en base64)

Cada adjunto: filename (string), content (string, base64), contentType (string, opcional).

Los secretos se resuelven desde el almacén de credenciales por nombre:

• SendGrid: sendgrid_api_key
• SMTP: smtp_password

Devuelve: { ok: true, messageId } en éxito, { ok: false, error } en fallo.

Los paquetes

Paquete	Qué es
apra-fleet	La plataforma de la flota: servidor, CLI, gestión de miembros, credenciales, tiempo de ejecución de flujos de trabajo
packages/apra-fleet-se	La vertical de ingeniería de software: motor de fleet-sprint, contratos de agentes, suites de integración
packages/apra-fleet-workflow	Tiempo de ejecución de autoría de flujos de trabajo: estado, visor, checkpointing
packages/fleet-api-contract	Contrato de API tipado compartido por servidor y clientes

Estado y hoja de ruta

apra-fleet está en desarrollo activo -- por su propia flota. Enfoque actual: endurecer la ejecución autónoma de sprints (el flujo de trabajo más difícil que conocemos), operación multi-sprint orquestada por supervisores, y el SDK de flujos de trabajo para verticales de terceros.

Documentación

Tema	Enlace
Guía de inicio rápido de fleet-sprint (empieza aquí, en inglés sencillo)	Sitio web - Markdown - PDF
Wiki del código base (arquitectura, internals, preguntas y respuestas con IA)	DeepWiki
Instalar, desinstalar, la bandera --llm	docs/install.md
Elegir un proveedor (roles, trampas, mezclar proveedores, modelos OpenCode/locales)	docs/provider-guide.md
Transporte, modo de servicio e interfaces compatibles	docs/transport-and-service-mode.md
Modelo de costos (niveles, shell-sobre-prompts, gasto medido de tokens)	docs/cost-model.md
La habilidad PM (sprints de revisor-ejecutor, comandos /pm)	docs/pm-skill-overview.md
Preguntas frecuentes	docs/FAQ.md
Solución de problemas	docs/troubleshooting.md
Mantener Fleet actualizado (apra-fleet update)	docs/features/update.md
Actividad de miembros en vivo (apra-fleet watch, logging.previewChars)	docs/features/watch.md
Variables secretas y contraseñas	docs/secret-variables.md - docs/features/oob-auth.md
Categoría y etiquetas de miembros	docs/features/member-tags.md
Habilitar SSH en una máquina remota (si aún no lo tiene)	docs/ssh-setup.md
Autenticación de Git	docs/design-git-auth.md
Configuración de GitHub App (permisos exactos por nivel de git_access)	docs/github-app-setup.md
Computación en la nube	docs/cloud-compute.md
Arquitectura	docs/architecture.md
Diseño de confiabilidad de despacho y orquestación (completado al salir en Windows, detector de estancamiento, límite de tiempo de ejecución del ejecutor de pruebas)	docs/dispatch-reliability-hardening.md - docs/stall-detector-resilience.md
Selección de shell en Windows (orden de sondeo, gitbash/pwsh7/powershell5, shell vs os)	docs/windows-shell-selection.md
Construcción de comandos entre shells para comandos vinculados a miembros	docs/cross-shell-command-construction.md
Capa de conocimiento (configuración, uso, cambio de proveedor)	docs/knowledge-layer.md
Abstracción de proveedores de inteligencia de código	docs/code-intelligence-providers.md
Plan de migración a la nube hub-spoke (histórico; ver ADR de propiedad de nivel 3)	docs/hub-spoke-master-plan.md
Decisión de propiedad de nivel 3 (fleet-dashboard vs src/hub-service/)	docs/adr-tier3-ownership.md
Paquete de contrato de API compartido hub/dashboard	packages/fleet-api-contract/README.md
Internals del motor de flujos de trabajo (agent()/parallel()/pipeline(), diario, presupuesto, pausa/reanudación)	packages/apra-fleet-workflow/docs/apra-fleet-workflow-architecture.md
Pausa/reanudación cooperativa de flujos de trabajo (motor, visor, supervisor, fleet-sprint)	docs/features/workflow-pause-resume.md
Actualización en vivo del panel del supervisor (/state + /events SSE, actualización al activar pestaña, expansión de alcance en memoria)	docs/features/supervisor-dashboard-live-refresh.md
Escribir y ejecutar scripts de flujos de trabajo	packages/apra-fleet-workflow/docs/workflow-guide.md
Crear un apra-fleet workflow integrado en SEA (manifiesto, contrato de entrada, variables de entorno del lanzador)	docs/authoring-workflows.md
Orden de resolución del servidor del lanzador de flujos de trabajo (singleton HTTP vs. stdio)	docs/adr-workflow-server-resolution.md
Ejecutar fleet-sprint (referencia completa de banderas; idéntica para instalación npm, binario independiente y checkout de desarrollo con git-clone)	packages/apra-fleet-se/fleet-sprint/docs/README.md
Resumen de auto-sprint (bucle autónomo de planificar-desarrollar-revisar-publicar)	packages/apra-fleet-se/docs/overview.md
Referencia de CLI de auto-sprint	packages/apra-fleet-se/docs/cli-reference.md
Internals de auto-sprint (bucle de ciclo, detección de estancamiento, presupuesto, topología)	packages/apra-fleet-se/docs/architecture.md
Contratos de roles de agente de auto-sprint	packages/apra-fleet-se/docs/role-contracts.md
Habilidad fleet-supervisor (iniciar/detener/reiniciar/auto-inicio al arrancar, lanzamiento de sprint vía API HTTP)	packages/apra-fleet-se/fleet-sprint/skills/fleet-supervisor/SKILL.md
Enhebrado de hallazgos de replanificación dentro del ciclo con alcance, y contrato de KB de rol de inyección de envoltorio	docs/scoped-replan-and-planner-kb-contract.md
Resumen del SDK de cliente MCP (transportes, API ApraFleet)	packages/apra-fleet-client/docs/overview.md
Referencia de API del SDK de cliente MCP	packages/apra-fleet-client/docs/api-reference.md
Primeros pasos con el SDK de cliente MCP	packages/apra-fleet-client/docs/getting-started.md
Hallazgos e invariantes del inventario del contrato de memoria v1 (superficie de herramientas kb_*/code_*)	docs/memory-contract-v1-inventory-notes.md
Diseño de generación de esquema del contrato de memoria v1 (zod -> JSON Schema 2020-12)	docs/memory-contract-v1-generator-design.md
Validación de ida y vuelta del contrato de memoria v1, guardia de deriva y diseño de traspaso T1/T2/T3/T7	docs/memory-contract-v1-roundtrip-and-handoff.md

Comunidad

• Preguntas e ideas: Debates de GitHub
• Lanzamientos: Lanzamientos de GitHub
• Problemas: Problemas de GitHub
• Qué se planea a continuación: ROADMAP.md

Si Apra Fleet te ayudó a entregar más rápido con mejor calidad, por favor dale una estrella al repositorio -- ayuda a que otros lo encuentren.

Desarrollo

Compilar desde el código fuente (también la ruta para Macs con Intel):

git clone https://github.com/Apra-Labs/apra-fleet && cd apra-fleet
npm install && npm run build && npm test

npm test ejecuta la suite local completa: la suite vitest raíz, la suite del espacio de trabajo apra-fleet-se y la suite apra-pm (que no es un espacio de trabajo npm y de otro modo solo es accesible mediante una invocación explícita de --prefix) -- así, una ejecución local en verde y una ejecución de CI en verde ven las mismas pruebas.

Consulta CONTRIBUTING.md para contribuir.

Licencia

Apache 2.0 -- consulta LICENSE.

---