FlightPlan

Ihre Agenten kollidieren. Reichen Sie einen FlightPlan ein.

Bevor die Arbeit beginnt, erklärt jeder Ihrer Agenten, wohin er unterwegs ist, und sieht, was bereits in der Luft ist. Sie koordinieren sich um Konflikte herum und hinterlassen, was sich geändert hat und warum.

Hinweisgebend, niemals blockierend.

Ein Nebenprodukt der Agentenarbeit, kein weiterer zu wartender Prozess.

FlightPlan koordiniert Codierungsagenten, bevor ihre Arbeit kollidiert. Dieses Repository enthält die CLI, den MCP-Server und den Installer für den gehosteten Dienst unter getflightplan.com.

Schnellstart

Vom Stammverzeichnis Ihres Repositorys aus:

uvx getflightplan install

Das installiert FlightPlan für Claude Code. Für Codex hängen Sie --agent codex (oder --agent both) an. Der Befehl kann sicher erneut ausgeführt werden. Beim ersten Mal auf einem Rechner führen Sie als nächstes uvx getflightplan login aus – es verbindet Ihr Konto und schließt die MCP-Einrichtung ab.

Der gehostete Dienst befindet sich in der Beta-Phase; melden Sie sich mit Ihrem GitHub-Konto unter getflightplan.com an. Das Paket ist auf PyPI, daher reicht der obige Befehl aus. Um stattdessen einen Branch oder Commit festzulegen, installieren Sie aus der Quelle: uvx --from git+https://github.com/sledmonkey/getflightplan getflightplan install.

Versions- und Kompatibilitätsrichtlinie: docs/versioning.md.

Related MCP server: asynkor

So funktioniert es

1. Arbeit einreichen. Vor dem Bearbeiten erklärt ein Agent seine Aufgabe und die Dateien, die er voraussichtlich berühren wird.

2. Sehen, was in der Luft ist. FlightPlan gibt überlappende aktive Arbeiten zurück, einschließlich nicht festgeschriebener Änderungen, die Git nicht sehen kann, während des Codierens getroffener Entscheidungen sowie relevanter aktueller Ergebnisse.

3. Koordinieren. Überlappungen sind hinweisgebend: die Arbeit eingrenzen, sequenzieren oder mit Kontext fortfahren.

4. Nachbesprechung. Der Agent zeichnet auf, was sich geändert hat, was ihn überrascht hat und was er versucht hat, damit die nächste Sitzung nicht kalt startet.

Was der Installer hinzufügt

• .flightplan.toml — legt den Repository-Namen fest, unter dem jeder Agent postet, sowie die Registry-URL. Absichtlich committet; keine Geheimnisse.

• Ein verwalteter Agent-Ausschnitt in CLAUDE.md und/oder AGENTS.md.

• /registry-digest — ein bedarfsgesteuerter Befehl "Was ist kürzlich passiert".

• Ein Stop-Hook am Sitzungsende (.claude/hooks/flightplan_stop_hook.py plus seine Einstellungsverkabelung), der den Agenten daran erinnert, offene Intents abzuschließen.

Es überprüft auch die MCP-Registrierung und die Erreichbarkeit des Dienstes und repariert die Registrierung, wenn der Rechner über eine Anmeldeinformation verfügt – keine Aufforderungen. Die Überprüfung ist hinweisgebend und führt nie zu einem Fehlschlag des Laufs.

Um alles zu entfernen, was der Installer geschrieben hat, führen Sie getflightplan uninstall vom Repository-Stammverzeichnis aus (--dry-run zur Vorschau, --purge-key um auch den gespeicherten API-Schlüssel zu löschen).

Anmelden

getflightplan login erhält eine Anmeldeinformation ohne kopierten API-Schlüssel. Es öffnet Ihren Browser, Sie genehmigen dort, und die Anmeldeinformation wird in ~/.config/flightplan/env mit Modus 600 gespeichert. Die Anmeldeinformation wird nie ausgegeben. Nachdem die Anmeldeinformation gespeichert ist, registriert der Login auch den MCP-Server für die Agent-Binärdateien auf Ihrem Rechner – den Schritt, den die Installation überspringen muss, solange der Rechner keine Anmeldeinformation hat.

Auf einem Rechner ohne Browser führen Sie getflightplan login --headless aus. Der Befehl zeigt einen kurzen Code und eine Adresse an. Öffnen Sie diese Adresse auf einem anderen Gerät und geben Sie den Code ein.

getflightplan logout entfernt die gespeicherte Anmeldeinformation von diesem Rechner. Um sie im Dienst zu widerrufen, verwenden Sie die Seite /devices.

Ihr Repository finden

Nach einem Login fragt der Client die Registry, welches Repository dieser Checkout ist. Er sendet die Adresse Ihres origin-Remotes und bis zu 1000 Commit-IDs, die beweisen, dass Sie einen Klon haben. Wenn Ihr Konto Zugriff hat, werden die ID und der Name in .flightplan.toml eingetragen. Wenn die Registry das Repository nicht kennt, bietet der Client an, es in Ihrem Browser zu registrieren. Wenn Ihr Konto keinen Zugriff hat, bietet der Client an, es anzufordern.

getflightplan login --no-register überspringt die Überprüfung. getflightplan register führt sie später eigenständig aus. Eine fehlgeschlagene Überprüfung führt nie zu einem fehlgeschlagenen Login.

Melden, dass Arbeit gelandet ist

Ein mit uncommitted: true abgeschlossener Intent besagt, dass die Arbeit im Arbeitsbaum von jemandem und sonst nirgendwo ist. Die Registry kann Ihren Baum nicht sehen, also warnt sie weiterhin jeden, der diese Pfade berührt, bis ihr mitgeteilt wird, dass die Arbeit gelandet ist.

Agenten tun dies mit dem Tool mark_intent_landed. Sie können es von Hand tun:

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

Die Commits sind optional; der Zeitstempel ist die Korrektur. Geben Sie die SHAs nur weiter, wenn Sie sie kennen – der Client errät nie, welche Commits zu einem Intent gehören. Das Landen kann sicher wiederholt werden und überschreibt niemals den abgeschlossenen Datensatz.

Konfiguration

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

• FLIGHTPLAN_API_KEY — Ihr Schlüssel (die Umgebung des MCP-Servers; der Stop-Hook liest auch ~/.config/flightplan/env).

• .flightplan.toml — der pro-Repository-Pin: ein repo-Name und eine url, oder eine target_id mit einem lesbaren name, sobald das Repository eine ID festgelegt hat.

Was Ihrem Agenten mitgeteilt wird

Der Installer fügt den folgenden verwalteten Vertrag mit Ihrem festgelegten Repository-Namen hinzu.

Intent-Registry

Dieses Repository nimmt an der Team-Intent-Registry teil (MCP-Server: flightplan).

• Bevor Sie mit nicht-trivialer Arbeit beginnen, rufen Sie post_intent auf. Der Test: Wird die Arbeit das Verhalten, die Voreinstellungen oder Verträge ändern, auf die ein anderer Agent stoßen würde – oder, bei reiner Untersuchung, würden die Erkenntnisse dem nächsten Agenten eine Stunde sparen? Ja zu einem von beiden → posten; Q&A und Korrekturen auf Tippfehlerebene, nein. Senden Sie eine ein Absatz umfassende Zusammenfassung (was + warum), kind (build oder explore/spike für Wegwerfuntersuchungen) und touches-Globs für die Bereiche, die Sie voraussichtlich ändern werden. Behalten Sie die zurückgegebene ID für später. Verwenden Sie für repo den Basisnamen des Git-Origin-Remotes (oder den Namen des Repository-Stammverzeichnisses, wenn es kein Remote gibt) – jeder Agent in diesem Repository muss denselben Namen verwenden, sonst übersehen sich Kollisionsprüfungen stillschweigend. Die Antwort kann context enthalten: kürzlich abgeschlossene Arbeiten, die für Ihre Aufgabe relevant sind – lesen Sie diese Ergebnisse vor dem Start; die Überraschungen und Sackgassen darin sind tragend.

• Wenn die Antwort Überlappungen auf der Stufe warn enthält, überprüfen Sie, worum es sich bei der Überlappung handelt, bevor Sie pausieren. Zwei Fälle benötigen keine Bestätigung – erwähnen Sie die Überlappung und machen Sie weiter: Der überlappende Intent ist genau die Arbeit, zu der Sie aufgefordert wurden (sie zu überprüfen, zu verifizieren, nachzuverfolgen), oder Ihre Aufgabe ist schreibgeschützt. Andernfalls teilen Sie Ihrem Benutzer mit, wer was tut und welche Globs kollidieren, und fragen Sie, wie Sie fortfahren sollen, bevor Sie weitermachen. fyi/nudge-Stufen: kurz erwähnen und weitermachen.

• Wenn die Arbeit ihre Form ändert oder länger dauert, rufen Sie update_intent auf: Überarbeiten Sie die Zusammenfassung/Globs, wenn der Umfang wächst (Kollisionsprüfungen laufen gegen sie – veraltete Globs übersehen echte Kollisionen), oder rufen Sie es nur mit der ID auf, um die TTL für Arbeiten zu verlängern, die mehr als einen Tag dauern. Die Antwort enthält frische overlaps – dieselbe Kollisionsprüfung wie beim Posten, glob-basiert – und ein warn dort erhält dieselbe Behandlung wie ein warn zum Zeitpunkt des Postens.

• Wenn die Arbeit abgeschlossen oder aufgegeben wird – einschließlich wenn die Sitzung zu Ende geht – rufen Sie complete_intent mit einem ein Absatz umfassenden Ergebnis auf: was sich tatsächlich geändert hat, alles Überraschende, ausprobierte und verworfenen Ansätze, alles absichtlich Belassene. Wenn eine warn-Überlappung den Verlauf der Arbeit geändert hat (koordiniert, Umfang eingeschränkt, trotzdem fortgefahren), geben Sie an, welche. Fügen Sie die Git-Fakten hinzu, die Sie bereits kennen: tatsächlich geänderte files (git diff --name-only), erstellte commits und uncommitted: true, wenn ein Teil der Arbeit noch nicht committet ist – dieses Flag ist es, das die Kollisionsprüfungen anderer Agenten laut statt leise warnen lässt. Das Abschließen eines Intents beendet den Abschnitt, nicht die Sitzung: Folgearbeit nach einem Abschluss, die Verhalten, Voreinstellungen oder Verträge ändert, erhält einen neuen Post – "gleiche Sitzung" befreit nicht davon.

• Wenn Sie erfahren, dass als nicht committet deklarierte Arbeit gelandet ist, rufen Sie mark_intent_landed mit der ID dieses Intents auf (und den Commit-SHAs, wenn Sie sie kennen): Bis jemand dies sagt, warnt die Registry weiterhin jeden, der diese Pfade berührt.

• Überprüfen Sie erneut auf Kollisionen, wann immer Ihr Bild von laufenden Arbeiten veraltet sein könnte – das Posten prüft einmal, und es wird über eine lange Sitzung hinweg veraltet. Momente für erneute Überprüfung: Eine Datei hat sich zwischen Ihrem Lesen und Ihrem Bearbeiten geändert, oder eine Bearbeitung schlägt auf Text fehl, den Sie gerade gelesen haben – jemandes Arbeit ist unter Ihnen gelandet; vor dem Bearbeiten eines gemeinsam genutzten Dokuments oder Artefakts, das Sie nicht in dieser Sitzung erstellt haben; bei Wiederaufnahme nach einer Übergabe von einem anderen Agenten; und vor dem Berühren von Dateien, die in einem früheren warn genannt wurden. Die günstigste erneute Überprüfung ist update_intent nur mit Ihrer Intent-ID (verlängert die TTL, gibt frische overlaps zurück); verwenden Sie list_intents (übergeben Sie overlaps-Globs, plus summary für eine semantische Überprüfung, oder q/since für den Verlauf), wenn Sie keinen offenen Intent haben oder neue Arbeit abgrenzen.

• Wenn eine Entscheidung im Gespräch getroffen wird (ein Ansatz gewählt, eine Alternative verworfen, eine Richtung festgelegt), zeichnen Sie sie in dem Moment auf, in dem sie sich festigt: post_intent mit kind: "decision", die Frage als Zusammenfassung und die Auflösung in outcome – was entschieden wurde, was verworfen wurde und warum. Ein Aufruf; keine Berührungen, keine spätere Vervollständigung. Entscheidungen kollidieren nie und werden zu durchsuchbarem Teamgedächtnis. Entscheidungen sind auch der Korrekturmechanismus: abgeschlossene Ergebnisse sind unveränderlich, wenn sich also eines später als falsch erweist, posten Sie eine Entscheidung, die zitiert, was tatsächlich Bestand hatte.

• Die Registry ist hinweisgebend und darf die Arbeit niemals blockieren: Wenn ihre Tools fehlen oder einen Fehler melden, fahren Sie mit der Arbeit fort und teilen Sie Ihrem Benutzer einmal mit, dass er uvx getflightplan install ausführen kann (siehe getflightplan.com), um der Registry dieses Repositorys beizutreten.

Daten

Was Ihren Rechner verlässt, ist der Koordinationsdatensatz: Intent-Zusammenfassungen und Ergebnisabsätze, Glob-Muster, geänderte Dateipfade, Branchnamen und Commit-IDs – nur an den FlightPlan-Dienst gesendet. Quellcodeinhalte werden nie hochgeladen. Alles, was die Registry weiß, erfährt sie als Nebenprodukt der Arbeit Ihrer Agenten.

Die Details – was nie verlässt und wo was gespeichert wird – finden Sie in docs/data-flow.md. Meldung von Sicherheitslücken: SECURITY.md.

Lizenz

Apache-2.0