FlightPlan

Ваши агенты сталкиваются. Подайте FlightPlan.

Перед началом работы каждый из ваших агентов объявляет, куда направляется, и видит, что уже находится в полете. Они координируют действия при конфликтах, затем оставляют запись о том, что изменилось и почему.

Рекомендательный, не блокирующий.

Побочный продукт работы агентов, а не еще один процесс для поддержки.

FlightPlan координирует действия агентов до того, как их работа столкнется. Этот репозиторий содержит CLI, MCP-сервер и установщик для хостингового сервиса на getflightplan.com.

Быстрый старт

Из корня вашего репозитория:

uvx getflightplan install

Это устанавливает FlightPlan для Claude Code. Для Codex добавьте --agent codex (или --agent both). Команду можно безопасно повторять. При первом запуске на машине выполните uvx getflightplan login — она подключает вашу учетную запись и завершает настройку MCP.

Хостинговый сервис находится в бета-версии; войдите через учетную запись GitHub на getflightplan.com. Пакет находится на PyPI, поэтому указанной выше команды достаточно. Чтобы зафиксировать ветку или коммит, установите из исходного кода: uvx --from git+https://github.com/sledmonkey/getflightplan getflightplan install.

Политика версий и совместимости: docs/versioning.md.

Related MCP server: asynkor

Как это работает

1. Оформите работу. Перед редактированием агент объявляет свою задачу и файлы, которые планирует затронуть.

2. Узнайте, что в работе. FlightPlan возвращает пересекающуюся активную работу, включая незафиксированные изменения, которые Git не видит, решения, принятые во время кодирования, а также соответствующие недавние результаты.

3. Координируйте. Пересечения носят рекомендательный характер: сузьте работу, выстройте последовательность или продолжайте с учетом контекста.

4. Подведите итоги. Агент записывает, что изменилось, что его удивило и что он попробовал, чтобы следующий сеанс не начинался с нуля.

Что добавляет установщик

• .flightplan.toml — фиксирует имя репозитория, под которым публикует каждый агент, а также URL реестра. Преднамеренно добавляется в коммит; никаких секретов.

• Управляемый фрагмент для агента в CLAUDE.md и/или AGENTS.md.

• /registry-digest — команда "что произошло в последнее время" по запросу.

• Хук остановки сеанса (.claude/hooks/flightplan_stop_hook.py плюс его настройки), который напоминает агенту закрыть открытые намерения.

Он также проверяет регистрацию MCP и доступность сервиса и исправляет регистрацию, если на машине есть учетные данные — без запросов. Проверка носит рекомендательный характер и никогда не прерывает выполнение.

Чтобы удалить все, что записал установщик, выполните getflightplan uninstall из корня репозитория (--dry-run для предварительного просмотра, --purge-key для удаления сохраненного API-ключа).

Вход в систему

getflightplan login получает учетные данные без копирования API-ключа. Он открывает ваш браузер, вы подтверждаете там, и учетные данные сохраняются в ~/.config/flightplan/env с правами 600. Учетные данные никогда не выводятся на экран. После сохранения учетных данных вход также регистрирует MCP-сервер для двоичных файлов агента на вашей машине — шаг, который установщик пропускает, пока на машине нет учетных данных.

На машине без браузера выполните getflightplan login --headless. Команда показывает короткий код и адрес. Откройте этот адрес на другом устройстве и введите код.

getflightplan logout удаляет сохраненные учетные данные с этой машины. Чтобы отозвать их в сервисе, используйте страницу /devices.

Поиск вашего репозитория

После входа клиент спрашивает у реестра, какой репозиторий соответствует этой копии. Он отправляет адрес вашего удаленного репозитория origin и до 1000 идентификаторов коммитов, которые доказывают, что у вас есть клон. Если ваша учетная запись имеет доступ, идентификатор и имя сохраняются в .flightplan.toml. Если реестр не знает репозиторий, клиент предлагает зарегистрировать его в вашем браузере. Если ваша учетная запись не имеет доступа, клиент предлагает запросить его.

getflightplan login --no-register пропускает проверку. getflightplan register запускает ее отдельно, позже. Неудачная проверка никогда не приводит к сбою входа.

Сообщение о завершении работы

Намерение, завершенное с uncommitted: true, означает, что работа находится в рабочем дереве кого-то и нигде больше. Реестр не видит ваше дерево, поэтому он продолжает предупреждать всех, кто затрагивает эти пути, пока ему не сообщат, что работа завершена.

Агенты делают это с помощью инструмента mark_intent_landed. Вы можете сделать это вручную:

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

Коммиты необязательны; временная метка является корректировкой. Передавайте SHA только если вы их знаете — клиент никогда не угадывает, к какому намерению относятся коммиты. Завершение можно повторять безопасно и никогда не перезаписывает запись о выполненной работе.

Конфигурация

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

• FLIGHTPLAN_API_KEY — ваш ключ (переменная окружения MCP-сервера; хук остановки также читает ~/.config/flightplan/env).

• .flightplan.toml — привязка к репозиторию: имя repo и url, или target_id с читаемым name, когда у репозитория есть закрепленный идентификатор.

Что сообщается вашему агенту

Установщик добавляет следующий управляемый контракт с закрепленным именем вашего репозитория.

Реестр намерений

Этот репозиторий участвует в командном реестре намерений (MCP-сервер: flightplan).

• Перед началом нетривиальной работы вызовите post_intent. Критерий: изменит ли работа поведение, настройки по умолчанию или контракты, с которыми столкнется другой агент — или, для чистого исследования, сэкономят ли результаты следующему агенту час? Да на любой из пунктов → публикуйте; вопросы и исправления опечаток — нет. Отправьте одноабзацное резюме (что + почему), kind (build, или explore/spike для одноразового исследования) и touches glob-шаблоны для областей, которые вы планируете изменить. Сохраните возвращенный идентификатор для дальнейшего использования. Для repo используйте базовое имя удаленного репозитория git origin (или имя корневого каталога репозитория, если удаленного репозитория нет) — каждый агент в этом репозитории должен использовать одно и то же имя, иначе проверки коллизий молча пропустят друг друга. Ответ может включать context: недавно завершенную работу, относящуюся к вашей задаче — прочитайте эти результаты перед началом; сюрпризы и тупики в них важны.

• Если ответ включает пересечения на уровне warn, проверьте, в чем пересечение, прежде чем приостанавливаться. Два случая не требуют подтверждения — упомяните пересечение и продолжайте: пересекающееся намерение — это именно та работа, которую вас попросили выполнить (проверить ее, подтвердить, продолжить), или ваша задача предназначена только для чтения. В противном случае сообщите пользователю, кто что делает и какие glob-шаблоны конфликтуют, и спросите, как действовать дальше, прежде чем продолжать. Уровни fyi/nudge: кратко упомяните и продолжайте.

• Если работа меняет форму или затягивается, вызовите update_intent: пересмотрите резюме/шаблоны, когда объем растет (проверки коллизий выполняются по ним — устаревшие glob-шаблоны пропускают реальные коллизии), или вызовите только с идентификатором, чтобы продлить TTL для работы, длящейся более дня. Ответ включает свежие overlaps — ту же проверку коллизий, что и при публикации, на основе glob-шаблонов — и warn там обрабатывается так же, как warn при публикации.

• Когда работа завершена или прекращена — в том числе когда сеанс завершается — вызовите complete_intent с одноабзацным результатом: что фактически изменилось, что было неожиданным, какие подходы были опробованы и отвергнуты, что намеренно оставлено на месте. Если warn-пересечение повлияло на ход работы (скоординировались, сузили объем, продолжили в любом случае), укажите, какое. Приложите известные вам факты git: files, которые фактически изменились (git diff --name-only), созданные commits и uncommitted: true, если какая-либо часть работы еще не зафиксирована — этот флаг позволяет проверкам коллизий других агентов предупреждать громко, а не молча. Завершение намерения заканчивает срез, а не сеанс: последующая работа после завершения, которая меняет поведение, настройки по умолчанию или контракты, требует новой публикации — "тот же сеанс" не освобождает от этого.

• Когда вы узнаете, что объявленная незафиксированная работа завершена, вызовите mark_intent_landed с идентификатором этого намерения (и SHA коммитов, если вы их знаете): пока кто-то не сообщит об этом, реестр продолжает предупреждать всех, кто затрагивает эти пути.

• Повторно проверяйте коллизии всякий раз, когда ваша картина выполняемой работы может быть устаревшей — публикация проверяет один раз, и она устаревает в течение длительного сеанса. Моменты для повторной проверки: файл изменился между вашим чтением и редактированием, или редактирование не удается на только что прочитанном тексте — чья-то работа завершилась под вами; перед редактированием общего документа или артефакта, который вы не создавали в этом сеансе; при возобновлении после передачи от другого агента; и перед касанием файлов, упомянутых в более раннем warn. Самая дешевая повторная проверка — это update_intent только с вашим идентификатором намерения (продлевает TTL, возвращает свежие overlaps); используйте list_intents (передайте glob-шаблоны overlaps, плюс summary для семантической проверки, или q/since для истории), когда у вас нет открытого намерения или вы определяете объем новой работы.

• Когда решение принято в разговоре (выбран подход, отвергнута альтернатива, задано направление), запишите его в момент принятия: post_intent с kind: "decision", вопросом в качестве резюме и решением в outcome — что было решено, что было отвергнуто и почему. Один вызов; никаких касаний, никакого последующего завершения. Решения никогда не конфликтуют и становятся доступной для поиска командной памятью. Решения также являются механизмом исправления: завершенные результаты неизменны, поэтому если позже одно окажется неверным, опубликуйте решение, ссылаясь на то, что на самом деле подтвердилось.

• Реестр носит рекомендательный характер и никогда не должен блокировать работу: если его инструменты отсутствуют или выдают ошибку, продолжайте работу и один раз сообщите пользователю, что он может запустить uvx getflightplan install (см. getflightplan.com), чтобы присоединиться к реестру этого репозитория.

Данные

С вашей машины отправляется только запись координации: резюме намерений и абзацы результатов, glob-шаблоны, пути измененных файлов, имена веток и идентификаторы коммитов — отправляется только в сервис FlightPlan. Содержимое исходного кода никогда не загружается. Все, что знает реестр, он узнает как побочный продукт работы ваших агентов.

Подробности — что никогда не покидает машину и что где хранится — в docs/data-flow.md. Сообщение об уязвимостях: SECURITY.md.

Лицензия

Apache-2.0