FlightPlan

Tus agentes colisionan. Presenta un FlightPlan.

Antes de que comience el trabajo, cada uno de tus agentes declara hacia dónde se dirige y ve lo que ya está en vuelo. Se coordinan en torno a los conflictos y luego dejan constancia de qué cambió y por qué.

Consultivo, nunca bloqueante.

Un subproducto del trabajo de los agentes, no otro proceso que mantener.

FlightPlan coordina a los agentes de codificación antes de que su trabajo colisione. Este repositorio contiene la CLI, el servidor MCP y el instalador para el servicio alojado en getflightplan.com.

Inicio rápido

Desde la raíz de tu repositorio:

uvx getflightplan install

Eso instala FlightPlan para Claude Code. Para Codex, añade --agent codex (o --agent both). El comando se puede volver a ejecutar sin riesgo. La primera vez en una máquina, ejecuta a continuación uvx getflightplan login — conecta tu cuenta y completa la configuración de MCP.

El servicio alojado está en beta; inicia sesión con tu cuenta de GitHub en getflightplan.com. El paquete está en PyPI, así que con el comando anterior es suficiente. Para fijar una rama o un commit en su lugar, instala desde el código fuente: uvx --from git+https://github.com/sledmonkey/getflightplan getflightplan install.

Política de versiones y compatibilidad: docs/versioning.md.

Related MCP server: asynkor

Cómo funciona

1. Registra el trabajo. Antes de editar, un agente declara su tarea y los archivos que espera tocar.

2. Mira lo que está en vuelo. FlightPlan devuelve el trabajo activo solapado, incluidos los cambios sin confirmar que Git no puede ver, las decisiones tomadas durante la codificación y los resultados recientes relevantes.

3. Coordina. Los solapamientos son consultivos: acota el trabajo, secuéncialo o continúa con contexto.

4. Informa. El agente registra qué cambió, qué lo sorprendió y qué intentó para que la próxima sesión no comience en frío.

Lo que añade el instalador

• .flightplan.toml — fija el nombre del repositorio bajo el que publica cada agente, además de la URL del registro. Se incluye en el repositorio a propósito; no contiene secretos.

• Un fragmento de agente gestionado en CLAUDE.md y/o AGENTS.md.

• /registry-digest — un comando bajo demanda de "lo que ha pasado últimamente".

• Un hook de parada al final de la sesión (.claude/hooks/flightplan_stop_hook.py más su configuración asociada) que recuerda al agente cerrar las intenciones abiertas.

También comprueba el registro de MCP y la accesibilidad del servicio, y repara el registro cuando la máquina tiene una credencial, sin preguntar. La verificación es consultiva y nunca hace fallar la ejecución.

Para eliminar todo lo que escribió el instalador, ejecuta getflightplan uninstall desde la raíz del repositorio (--dry-run para previsualizarlo, --purge-key para eliminar también la clave API guardada).

Iniciar sesión

getflightplan login obtiene una credencial sin tener que copiar una clave API. Abre tu navegador, apruebas allí y la credencial se guarda en ~/.config/flightplan/env con modo 600. La credencial nunca se imprime. Después de guardar la credencial, el inicio de sesión también registra el servidor MCP para los binarios de agente de tu máquina — el paso que install tiene que omitir mientras la máquina no tenga credencial.

En una máquina sin navegador, ejecuta getflightplan login --headless. El comando muestra un código corto y una dirección. Abre esa dirección en otro dispositivo e introduce el código.

getflightplan logout elimina la credencial almacenada de esta máquina. Para revocarla en el servicio, usa la página /devices.

Encontrar tu repositorio

Después de un inicio de sesión, el cliente pregunta al registro a qué repositorio corresponde este checkout. Envía la dirección de tu remoto origin y hasta 1000 IDs de commit, que demuestran que tienes un clon. Si tu cuenta tiene acceso, el id y el nombre se guardan en .flightplan.toml. Si el registro no conoce el repositorio, el cliente ofrece registrarlo en tu navegador. Si tu cuenta no tiene acceso, el cliente ofrece solicitarlo.

getflightplan login --no-register omite la comprobación. getflightplan register la ejecuta por sí solo, más tarde. Una comprobación fallida nunca hace que falle un inicio de sesión.

Indicar que el trabajo ha aterrizado

Una intención completada con uncommitted: true indica que el trabajo está en el árbol de trabajo de alguien y en ningún otro sitio. El registro no puede ver tu árbol, así que sigue avisando a cualquiera que toque esas rutas hasta que se le diga que el trabajo ha aterrizado.

Los agentes hacen esto con la herramienta mark_intent_landed. Puedes hacerlo manualmente:

getflightplan landed <intent-id> --commit <sha> --commit <sha>

Los commits son opcionales; la marca de tiempo es la corrección. Pasa los SHAs solo si los conoces: el cliente nunca adivina qué commits pertenecen a una intención. El aterrizaje se puede repetir de forma segura y nunca reescribe el registro completado.

Configuración

• FLIGHTPLAN_URL — https://api.getflightplan.com

• FLIGHTPLAN_API_KEY — tu clave (el entorno del servidor MCP; el hook de parada también lee ~/.config/flightplan/env).

• .flightplan.toml — la fijación por repositorio: un nombre repo y una url, o un target_id con un name legible una vez que el repositorio tiene un id fijado.

Lo que se le dice a tu agente

El instalador añade el siguiente contrato gestionado con el nombre de tu repositorio fijado.

Registro de intenciones

Este repositorio participa en el registro de intenciones del equipo (servidor MCP: flightplan).

• Antes de empezar un trabajo no trivial, llama a post_intent. La prueba: ¿el trabajo cambiará el comportamiento, los valores predeterminados o los contratos que otro agente encontraría — o, para una investigación pura, los hallazgos le ahorrarían una hora al siguiente agente? Si la respuesta es sí a cualquiera de las dos → publica; las Q&A y las correcciones tipográficas, no. Envía un resumen de un párrafo (qué + por qué), kind (build, o explore/spike para una investigación desechable), y globs touches para las áreas que esperas cambiar. Guarda el id devuelto para más tarde. Para repo, usa el nombre base del remoto git origin (o el nombre del directorio raíz del repositorio si no hay remoto) — todos los agentes de este repositorio deben usar el mismo nombre; de lo contrario, las comprobaciones de colisión pasarán por alto unas a otras en silencio. La respuesta puede incluir context: trabajo completado reciente relevante para tu tarea — lee esos resultados antes de empezar; las sorpresas y los callejones sin salida que contienen son esenciales.

• Si la respuesta incluye solapamientos en el nivel warn, comprueba en qué consiste el solapamiento antes de pausar. Dos casos no necesitan confirmación — menciona el solapamiento y continúa: la intención solapada es exactamente el trabajo sobre el que te pidieron actuar (revisarlo, verificarlo, darle seguimiento), o tu tarea es de solo lectura. En caso contrario, informa a tu usuario de quién está haciendo qué y qué globs colisionan, y pregunta cómo proceder antes de continuar. Niveles fyi/nudge: menciónalos brevemente y continúa.

• Si el trabajo cambia de forma o se alarga, llama a update_intent: revisa el resumen/touches cuando el alcance crezca (las comprobaciones de colisión se ejecutan contra