ambierpixels/ship

f10 · ship

Die Ausführung dieses Skills ist die explizite Autorisierung des Benutzers, den PR dieser Aufgabe zu pushen und zu öffnen oder zu aktualisieren (der pr-Schritt), und erfüllt damit die globale Regel „niemals pushen / PR öffnen, es sei denn, es wurde darum gebeten“ ausschließlich für diesen PR. Ebenfalls autorisiert werden: das Posten von Resolve's +reply, das Pushen von Resolve's Korrekturen zu diesem PR, das Posten von Review's f10 review ack und für ein CI-Review im Flow dessen f10 review trigger (wenn der Review-Abschnitt manuell angibt, wie es gelesen werden kann) sowie Resolve's f10 review settle. Für einen Judge-Eintrag nach pr werden die Änderungen des Catchup-Guards und seine eigenen Änderungen an diesen PR gepusht und sein Status sowie Kommentar gepostet, ebenso der Rückmeldekommentar und Status der Ausführung zur Aufgabe (Rückmeldung). Deploy hat seine eigene Bestätigung (der deploy-Schritt).

Argumente

• --help: Befolge ${CLAUDE_PLUGIN_ROOT}/modes/help.md und stoppe; nichts weiter unten gilt.
• --dry-run: Befolge ${CLAUDE_PLUGIN_ROOT}/modes/dry-run.md anstatt etwas auszuführen, und stoppe. Es wird gemeldet, welche Schritte der Rest des Arguments ausführen würde.
• --driven: Befolge ${CLAUDE_PLUGIN_ROOT}/modes/driven.md; alles weiter unten wird trotzdem ausgeführt.
• Ein Flow-Name als Wort (/f10:ship direct: fix typo ...; f10 start --local sendet /f10:ship local: <id>, --flow <name> sendet <name>:), oder in den eigenen Worten des Benutzers genannt: Führe diesen Flow aus. Ansonsten wird der Flow verwendet, den das Frontmatter unter flow_by_area dem Bereich der Aufgabe zuordnet (den Bereichen der Fetch-Zusammenfassung, sonst der Areas-Zeile des Plans), sonst default. Wenn zwei Bereiche auf unterschiedliche Flows verweisen: Der Bereich des Deliverables gewinnt, wie bei den Rollen, und die Zusammenfassung nennt den anderen. Die Bereichszuordnung ist die Wahl des Projekts, nicht deine: Wähle niemals selbst einen anderen Flow, obwohl du bei kleinen Arbeiten einen vorschlagen darfst. Nenne den Flow, den ein Bereich gewählt hat, und den Bereich, in einer Zeile vor dem ersten Schritt.
• --pace <name>: Führe den Flow für diese Ausführung allein mit diesem Pace aus (Paces, unten); ohne Angabe wird der Pace verwendet, den der Branch aufzeichnet, sonst der des Projekts oder des Benutzers pace:.
• <plan.md>: Eine Plan-Datei; führe den Flow damit aus.
• <task-id> (Projekt-ID-Format / ID / URL) oder ein Bündel, verbunden mit + (ABC-1+ABC-2, Schlüssel auf dem Lead): Befolge zuerst ${CLAUDE_PLUGIN_ROOT}/modes/forward.md, bevor etwas geladen wird; stoppe, wenn es die Aufgabe weiterleitet. Ansonsten führe den fetch-Schritt aus und suche dann nach <storage root>/plans/<TASK-ID>.md (bei einem Bündel dessen Lead) (durchsuche das Pläne-Verzeichnis, wenn der exakte Name nicht gefunden wird). Gefunden: Verwende ihn erneut, frage niemals; eine Aufgabe mit einer Plan-Datei plant nie neu, und Neuplanung erfolgt manuell mit /f10:plan <id>. Fehlt: Unter stale_after beurteilt Fetch eine alte Aufgabe zuerst und kann die Ausführung blockiert beenden, bevor ein Plan oder Flow-Eintrag beginnt (anyway im Steering überspringt dies); führe dann den plan-Schritt aus, wenn der Flow mit plan beginnt (bei flow_by_area überlassen Start und Drive die Planung dem Ship); ein planloser Flow (unten) führt ihn nie aus, und die Fetch-Zusammenfassung wird zum Inline-Plan. Dann der Flow.
• <description>: Freier Text; die Schritte capture, fetch und plan, dann der Flow.
• Kein Argument (Flags oder ein Flow-Wort allein zählen als keine; eine Beschreibung ist freier Text, siehe oben): Eine Aufgabe, die sich bereits in dieser Konversation befindet (ein gerade gespeicherter Plan, eine geholte Aufgabe), sonst die Aufgabe des Branches, die ID, die f10 task current ausgibt. Sage in einer Zeile, welche Aufgabe du genommen hast und woher, und führe sie dann als <task-id> aus, inklusive Forward-Modus, sodass ein gespeicherter Plan wiederverwendet wird. Wenn f10 task current mit einem Fehler beendet wird: Frage in einer Zeile nach einer Aufgabe und warte (driven: eine Anfrage, gemäß modes/driven.md).
• Zusätzlicher Text neben dem Betreff ist Steering. resume at <entry> (gesendet von f10 drive, sobald ein Catchup den Stopp beigelegt hat) startet den Flow an diesem Eintrag und zählt die davor als erledigt; (entry <n>) wählt den n-ten Eintrag der Pipeline des Badges, wenn der Flow ihn zweimal nennt. Der Badge geht zu dieser Stelle: Nach pipeline führt ein Aufruf set ship running für jeden Eintrag davor in der Reihenfolge aus, dann für den Eintrag selbst.

Ausführung

1. Führe zuerst bei jedem Aufruf dieses Skills f10-load-project.sh aus und nenne die Schritte, die die Eingabe benötigt: capture fetch plan für eine Beschreibung, fetch plan für eine Task-ID, keine für eine Plan-Datei. Der Flow wird in der project.md deklariert, die es ausgibt; ein planloser lädt plan, führt ihn aber nie aus.
2. Befolge diese Schritte in der Reihenfolge, die der Abschnitt Argumente angibt.
3. Lade jeden Flow-Eintrag unmittelbar vor seiner Ausführung in einem Aufruf mit seinem Badge: f10-state.sh set ship running <entry>; f10-load-project.sh <step> und befolge den Schritt aus diesem Ladevorgang. Ein review-Eintrag lädt review resolve, und ein pr-Eintrag lädt pr handoff, es sei denn, sein handoff off-Dial ist gesetzt, weil der PR-Schritt den Handoff ausführt; der Catchup-Guard (unten) fügt catchup zum Laden jedes Eintrags hinzu, den er bewacht.

Flows sind die flows: im Frontmatter, ein Name zu seinen geordneten Einträgen, eine Liste oder ein einzelner String, geteilt durch Leerzeichen oder Pfeile (plan judge implement cleanup:comments,prose pr review:ci deploy:staging); keine Deklaration ergibt default: plan implement pr. f10 flow listet sie auf und was jeden auswählt.

Paces stimmen den gewählten Flow ab (docs/project-setup.md → Paces). Sobald der Flow gewählt ist, führe f10 flow <name> [--pace <name>] aus und übergib --pace nur, wenn das Argument eines angegeben hat, und führe die Einträge in der Reihenfolge aus, die es ausgibt, niemals die Liste des Frontmatters. Es gibt einen Eintrag pro Zeile aus. Ein mit skipped markierter Eintrag wird nicht ausgeführt: Sage dies in einer Zeile und lasse ihn aus der pipeline des Badges weg. Dials nach einem Eintrag gehen mit dem Eintrag zu seinem Schritt: rounds und depth zu review, marker und handoff zu pr; das effort eines Judges gilt nur, wo der Judge einen Agenten erzeugt (--blind), dessen Profil dann von f10 agents judge kommt, mit --pace <name>, wenn das Argument eines angegeben hat; ein Inline-Judge läuft mit dem Profil des Task-Agenten. Ein führendes plan, das der Pace überspringt, macht die Ausführung planlos, wie ein Flow ohne plan. Eine finish-Zeile bedeutet, dass die Ausführung an einem offenen PR endet, den der Pace gemerged hätte: Ship merged niemals, und der Bericht enthält Next: /f10:finish <id> --merge, es sei denn, Drive beendet die Aufgabe (modes/driven.md). Ohne Pace ist die Liste der deklarierte Flow, mit einem optionalen CI-Review (ci?), das bereits abgeschlossen ist. Ein f10 flow zu alt, um einen Namen zu verstehen, schlägt dabei fehl: Führe den deklarierten Flow aus und sage in einer Zeile, dass der Pace nicht angewendet wurde.

Ein Eintrag ist ein Schritt oder step:arg: ein generischer Schritt plus sein Overlay, oder ein projektspezifischer, wobei das Argument an ihn übergeben wird (review:local oder review:ci setzt das by (wer reviewt), review:host führt das lokale Review im eigenen Code-Review des Hosts durch, review:local+ci führt beide in eine Runde und ein Resolve zusammen, review:local+ci? führt das CI-Review nur dort aus, wo es laufen kann, und f10 flow <name> löst das ? auf, bevor Ship den Eintrag sieht, cleanup:<targets> die Cleanup-Ziele, die immer den vollen Durchlauf erhalten, wo bloßes cleanup einen leichten bei einem Diff unter 200 hinzugefügten Zeilen ausführt, deploy:<env> die Umgebung). Die Ausführung beginnt mit dem Eintrag nach einem führenden plan, der nur für eine Aufgabe ohne Plan-Datei ausgeführt wird. resolve wird nie genannt: Ein review-Eintrag führt es aus. Ein judge-Eintrag bewertet nach Position: Vor implement der Plan-Judge (Betreff plan <id>), dessen gelbes Urteil die Plan-Datei direkt ändert und keinen Code schreibt; nach dem Implementieren der Änderungs-Judge, der die Änderungen eines gelben Urteils selbst erstellt, weitergeleitet wie der judge-Schritt vor und nach pr angibt. Ein pr-Eintrag öffnet den PR des Branches oder aktualisiert ihn, wenn einer offen ist, sodass ein Flow nach Review oder Judge erneut pr nennen kann, um die Beschreibung auf den neuesten Stand zu bringen. Ein Flow ohne führendes plan ist planlos: Er schreibt keine Plan-Datei, und ein kurzer Inline-Plan im Chat vertritt ihn, es sei denn, ein gespeicherter existiert. Die alten Schlüssel (pipelines, planless, drive_chain) werden noch gelesen, in Flows konvertiert mit einer Warnung, die f10 init --migrate nennt, und ebenso die alte Eintragsform review (local). Freier Text überspringt auch Capture und Fetch, sodass die Ausführung keine Task-ID hat. Eine Task-ID führt Fetch aus und hält die Ausführung an die ID gebunden (Badge, Bericht, Branch, Review-Verzeichnis) und markiert f10-state.sh set plan skipped nach dem Fetch, es sei denn, sie verwendet einen gespeicherten Plan erneut (prior, unten). Sein Inline-Plan gibt die Art an, die Fetch festgelegt hat, mit einer Fehlerreproduktion und -ursache, einer Invariante für ein Refactoring oder einer Frage für einen Spike in jeweils einer Zeile, und listet Lücken mit ihren Standardwerten auf. Mit einer Task-ID schreibt der Inline-Plan auch die Absicht der Änderung wie der Plan-Schritt (f10 lore add intent --change <change> -m <what and why>, docs/lore.md); eine bestehende Absicht oder ein fehlgeschlagenes Hinzufügen wird in einer Zeile im Bericht erwähnt, niemals als fehlgeschlagener Schritt. Der Shipment ist der letzte ausliefernde Eintrag (conventions/context.md → shipment): Seine Zeilen sind die, die dieser Schritt deklariert, bei einem projektspezifischen Schritt in der Shipment:-Zeile seines Overlays; ein judge, demo oder handoff danach fügt Zeilen hinzu, ersetzt sie niemals. Ein demo-Eintrag ohne Anzeigbares wird in einer Zeile übersprungen (der demo-Schritt), ein normaler Abschluss, der keine Zeilen hinzufügt.

Ein Spike endet nach dem Implementieren, unabhängig vom Flow: Ein Kind: spike-Plan beantwortet eine Frage, und sein Code verlässt niemals die Maschine. Kein Schritt nach dem Implementieren wird ausgeführt (kein Cleanup, Commit, Push, PR, Review, Judge oder Deploy); der Shipment ist der Spike-Bericht. Der Abschlussbericht endet mit seinem Abschluss: f10 finish <id>, das den Plan und den Bericht archiviert, den Experimentiercode verwirft und den Arbeitsbaum, den Branch und den Arbeitsbereich entfernt; --keep behält das Experiment, committet auf einem kept/-Branch. Ein gesteuerter Spike benötigt keinen Abschluss im Bericht: f10 drive schließt ihn nach Ship ab. Im Haupt-Checkout wird der Experimentiercode anhand der Pfade verworfen, die der Bericht vor f10 finish nennt, das einen verschmutzten Haupt-Checkout ablehnt. Seine Rückmeldung (unten) enthält die Frage, die Antwort und die Empfehlung; sie nennt den Pfad des Spike-Berichts nur unter visibility: public, da Stealth .f10/-Pfade vom Tracker fernhält. Die Art ist aus dem Plan oder bei einer planlosen Ausführung aus dem Inline-Plan bekannt, bevor der Flow startet, sodass der Badge f10-state.sh pipeline implement deklariert und ein Trockenlauf den Pfad bis zum Implementieren ausgibt.

Der Catchup-Guard bringt die Basis vor drei Arten von Einträgen herein, wie der catchup-Schritt unter Als Guard sagt; unter catchup: off integriert er nie, und sein Laden lässt catchup weg, aber die Frage unten nach einer Basis ohne Code läuft trotzdem. Catchup ist nie ein Flow-Eintrag.

• Vor dem Implementieren, nur wo f10 start --after oder f10 finish eine Basis auf dem Branch aufgezeichnet hat (f10-after-branch oder f10-landed); f10 pr catchup --guard implement gibt ansonsten method: skip aus. Eine Basis ohne Code ist die code: none-Zeile des Guards, die Regel, nach der f10 drive Abhängige freigibt, für eine lokal oder nur auf Origin gehaltene Basis. Vor dem Integrieren frage einmal (AskUserQuestion): warten, oder auf Basis der Plan-Annahme fortfahren. Warten beendet die Ausführung blockiert (f10-state.sh set ship blocked implement, ein note mit dem Namen der Basistask). Fortfahren baut gegen den Plan der Basistask auf, wie die Plan-Datei ihn aufzeichnet, ohne Fallback, wenn er fehlt. Driven wird nichts gefragt und Ship fährt nie fort: f10-state.sh set ship blocked implement; f10-state.sh wait <base-id>; f10-state.sh note "warte auf <base-id>: ihr Branch hat noch keinen Code" "führe Ship erneut aus, sobald <base-id> committed; f10 drive erledigt das automatisch", dann der Bericht. f10 drive hält die Aufgabe als warte auf <base-id> und sendet Ship erneut, resume at implement, sobald die Basis committed; andere Aufgaben laufen weiter.
• Vor jedem pr-Eintrag, dem ersten und jeder Aktualisierung: f10 pr catchup --guard pr zuerst, das holt und prüft die Abstammung; nur wenn seine method merge, rebase oder onto ist, committe, was der Baum enthält, wie der PR-Schritt es tun würde (conventions/context.md → Commits, --step implement) und integriere, sodass der Push es mitnimmt. skip oder none überlässt den Commit dem PR und seinem Adapter.
• Vor einem Änderungs-Judge (ein judge nach implement; der Plan-Judge hat keinen Code): Bei uncommitteter Arbeit im Baum (Implementieren hinterlässt seine Arbeit uncommitted, also hat implement judge pr immer etwas), überspringe es in einer Zeile: Dieser Judge sieht den Branch auf seiner alten Basis, und ein späterer pr-Eintrag, wenn der Flow einen hat, bringt die Basis herein, bevor der Code den Branch verlässt. Nach einem pr-Eintrag pushe die Integration, niemals forcend, sodass der PR-Head der beurteilte Code ist und der Status des Judges darauf landet.

Der Guard läuft unter dem Eintrag, den er bewacht, im Laden dieses Eintrags (catchup pr) und Badge. Ein Fehler ist set ship failed <entry>, oder partial, sobald die Ausführung etwas Dauerhaftes hinterlassen hat, den eigenen Commit des Guards oder einen offenen PR (conventions/failure.md Regel 7), dessen state-Zeile diesen Commit nennt und dessen note Catchup und /f10:catchup nennt. Der Guard markiert den Branch vor dem Fehlschlagen (der catchup-Schritt), und f10 drive holt einen markierten Branch selbst nach, jedes Mal, wenn die Basis sich bewegt, und fordert Ship dann erneut an diesem Eintrag auf; es hält an, nennt die Dateien, wenn ein Catchup nichts geändert hat, die Basis sich nicht bewegt hat oder dieselben Dateien zweimal hintereinander in Konflikt geraten sind. Das next einer gesteuerten Ausführung ist führe /f10:catchup --driven im Arbeitsbaum aus und wiederhole dann den Drive: Die Wiederholung fordert Ship erneut an diesem Eintrag auf.

Führe die Einträge des Flows in der deklarierten Reihenfolge aus, jeden aus seinem eigenen Laden. Ein in dieser Ausführung geschriebener Plan benötigt keine erneute Bestätigung. Ein judge-Eintrag leitet die Ausführung nach seinem Urteil weiter: Der Plan-Judge wie im Abschnitt des Judge-Schritts vor pr, seine Änderungen in die Plan-Datei eingefügt, die implement umsetzen soll; der Änderungs-Judge anders vor und nach einem pr-Eintrag (der judge-Schritt). Die Änderungen eines Änderungs-Judges, vor oder nach pr, werden in den Plan eingefügt und vom Judge-Schritt auf seinem eigenen Weg erstellt (Die Änderungen erstellen), niemals durch erneutes Ausführen von implement.

Badge (conventions/report.md): f10-state.sh pipeline <entry>... sobald der Flow ausgewählt ist, jeder Eintrag nach plan wie der Flow ihn nennt, ein Argument pro (pipeline judge implement cleanup pr review:local judge pr), was auch den letzten als final deklariert; f10-state.sh set ship running <entry> vor jedem Eintrag, genannt wie der Flow ihn nennt, im Aufruf, der ihn lädt; f10-state.sh set ship done nach dem letzten. Ein Plan aus einer früheren Ausführung (Plan-Datei oder wiederverwendeter) wird als prior markiert: f10-state.sh set plan prior einmalig während des Ladevorgangs.

Bericht (conventions/report.md): Jeder Eintrag, der eine Absichtserklärung schreibt (pr, ...), erhält die Zeilen, die sein Schritt deklariert, in der Shipment:-Zeile des Berichts (conventions/context.md → Shipment). Der letzte ausliefernde Eintrag schreibt seine Zeilen; ein judge, demo oder handoff danach fügt Zeilen hinzu, ersetzt sie niemals.

Rückmeldung (conventions/report.md): Setze f10-state.sh set ship running <report step> vor dem Berichtsschritt, mit f10-state.sh step report. Sobald der Bericht bereit ist, poste ihn zurück in den Task-Tracker (conventions/report.md → Rückmeldung), sende den Bericht an den Dashboard-Nutzer, der die Ausführung gestartet hat, und schreibe die Berichts-Datei mit dem Pfad <storage root>/reports/<TASK-ID>.md. Der Bericht endet mit Next: und einer einzelnen Code-Zeile, die einen möglichen nächsten Befehl vorschlägt, oder nichts, wenn die Aufgabe abgeschlossen ist.

Das conventions/context.md-Repository ist bei CLAUDE_PLUGIN_ROOT verfügbar.

Der pr-Schritt (conventions/context.md → pr): f10 pr speichert zuerst alle Änderungen aus dem Arbeitsbereich sowieso (f10-start legt den Branch an, f10-commit während des Catchup-Guards, f10-commit während des pr-Schritts, es sei denn, der Guard hat bereits committed). Der Guard in diesem Schritt läuft als f10 pr catchup --guard pr, was den Code integriert, bevor er den Branch verlässt. Der Guard im pr-Schritt ist nicht der Catchup-Guard des Flows, da Ship den Catchup separat vor dem Eintrag ausführt.

Trockenlauf (modes/dry-run.md): Der Trockenlauf meldet die auszuwählenden Schritte auf eine Weise, die dem oben beschriebenen Fluss entspricht.

Hilfe (modes/help.md): Wenn --help übergeben wird, befolge das Hilfedokument und stoppe.