br1anchen/pstack-pair

Lies den Laufzeitadapter, bevor du diesen Workflow befolgst. Seine Laufzeit-Zuordnungen gelten für alle referenzierten Playbooks und Skripte.

Pstack-Paar

Zwei Agenten, eine Herdr- oder Rex-Sitzung, ein Repository. Der Meister besitzt das Urteilsvermögen und der Sidekick besitzt den Arbeitsbaum. Jede Nachricht zwischen ihnen ist eine Datei im Paarspeicher plus eine einzeilige Aufforderung, die die Datei benennt. Das Terminal ist niemals die Aufzeichnung, da Agenten auf dem alternativen Bildschirm keinen Scrollback hinterlassen.

Voraussetzungen

1. Innerhalb von Herdr (test "${HERDR_ENV:-}" = 1) oder Rex (REX_BLOCK gesetzt). Außerhalb beider: sag es und stoppe.
2. Lade die Fertigkeit des Multiplexers für Fenster- und Agentensteuerung: Herdrs ~/.agents/skills/herdr/SKILL.md (oder herdr --skill, wenn diese Datei fehlt), oder Rex' rex skill show. Seine Sicherheitsregeln gelten durchgängig. In Rex lies Ausführung in Rex.
3. herdr oder rex, sowie Python 3.11 oder höher (python3), im PATH. scripts/pair.sh help listet alle Speicher- und Kanaloperationen auf; verwende es anstelle von selbstgebauten herdr- oder rex-Aufrufen für das Paar.
4. Starte den Meister im Auto-Modus. Devin standardmäßig umgeht Berechtigungen mit --permission-mode dangerous. Andere Arten erben den Modus des Meisters. pair.sh permission gibt den erkannten Meistermodus aus. Verwende --permission <mode> oder native Berechtigungsflags nach --, um den Standard zu überschreiben; --permission auto wählt den Devin-Smart-Modus. Arten ohne Übersetzung akzeptieren native Flags nach --. spawn überspringt auch die Ordnervertrauensaufforderung jeder Art, die einen unbeaufsichtigten Agenten in einem ihm unbekannten Ordner aufhängen würde: pi erhält --approve, Devin --respect-workspace-trust false. Ein Vertrauensflag nach -- überschreibt dies. Claude und Codex hingegen fragen, ob sie einem Ordner vertrauen sollen, den sie noch nicht gesehen haben; diese Entscheidung liegt beim Menschen, daher lehnt spawn den Dialog ab und stoppt mit der Anweisung, was zu tun ist: öffne diesen Agenten einmal im Repo und vertraue ihm.

Rollen

	Meister	Sidekick
Besitzt	Plan, Aufträge, Überprüfung, Entscheidungen, den Menschen	den Arbeitsbaum, Tests, Diagnose, Evidenz
Führt pstack aus als	Poteto-Mode-Rahmung, how, architect, Überprüfungsfertigkeiten	das Playbook, das jeder Auftrag benennt, mit seiner Aufgabenliste
Schreibt	nur den Paarspeicher	Dateien innerhalb des Arbeitsauftrags-Umfangs, plus sein Fortschrittsprotokoll und seinen Bericht
Spricht durch	Aufträge, Lenkungsbefehle, Überprüfungen, ständige Anweisungen, Tore	Fortschrittszeilen, Berichte

Tritt deine Rolle ein. Meister: references/master.md. Sidekick: references/sidekick.md.

Paarspeicher

${XDG_STATE_HOME:-$HOME/.local/state}/pstack/pair/<slug>/, erstellt durch pair.sh init. Ein Schreiber pro Datei.

Pfad	Schreiber	Inhalt
pair.json	Meister via pair.sh	Agentennamen, Fenster-IDs, aktuelles Arbeitsverzeichnis, Git-Root, Fallback und Failover des Sidekicks, Fensterplatzierung (geteilt oder Tab)
standing-orders.md	Meister	nummerierte Einschränkungen, die per Pfad in jeden Auftrag eingefügt werden
plans/NNN-<slug>.md	Meister	eine Planrunde, aus der Planvorlage
briefs/NNN-<slug>.md	Meister	eine Einheit, aus der Auftragsvorlage
progress/NNN-<slug>.md	Sidekick via pair.sh progress	eine mit Zeitstempel versehene Zeile pro abgeschlossenem Schritt oder Richtungswechsel; ein Check-in zeigt nur die Zeilen an, die der Meister noch nicht gesehen hat
steers/NNN-<slug>-s<k>.md	Meister	mid-Auftrag-Lenkung k für Einheit NNN, aus der Lenkungsvorlage; supersedes: benennt den beanstandeten Lenkungsbefehl, auf den es antwortet
reports/NNN-<slug>-s<k>.md	Sidekick	Einwand gegen Lenkungsbefehl k, aus der Lenkungsantwortvorlage
reports/NNN-<slug>.md	Sidekick	Evidenz für Auftrag NNN, aus der Berichtsvorlage, oder die Zustimmungs-/Einwand-Antwort auf Plan NNN, aus der Planantwortvorlage
reviews/NNN-<slug>.md	Meister	Urteil über Bericht NNN, aus der Überprüfungsvorlage; agreed bei einem Plan gibt seine Aufträge frei
scratch/<id>	Meister via pair.sh scratch	Link zu einem Wegwerf-Arbeitsbaum bei einem Commit einer Einheit zum erneuten Ausführen ihrer Prüfungen, außerhalb des Repos unter ${XDG_STATE_HOME:-~/.local/state}/pstack/scratch/ aufbewahrt (PSTACK_SCRATCH_ROOT verschiebt ihn), dem Claude und Codex einmal pro Host vertrauen müssen (kitchen.py doctor prüft); nach der Überprüfung entfernt
gates.md	Meister	offene Fragen an den Menschen
decisions.tsv	Meister via pair.sh log	die Zeig-mir-deine-Arbeit-Spur
status.md	pair.sh status	abgeleitete Tabelle; niemals von Hand bearbeitet
queue	Meister via pair.sh queue und dispatch	der Pfad des nächsten Auftrags, ein Platz
steps/NNN-<slug>.tsv	Sidekick via pair.sh step	eine Zeile pro festgeschriebenem Schritt: Nummer, Commit, Zeit, Notizen, die er auflöst, Zusammenfassung
notes/NNN-<slug>-n<k>.md	Meister via pair.sh new-note und note	Überprüfung der Schritte der Einheit bis Schritt k, aus der Notizvorlage: blockierende Punkte und Folgemaßnahmen
followups.md	Meister via pair.sh note	Folgemaßnahmen aus jeder Notiz, für einen späteren Auftrag oder ein Issue
session-handoff.md	Meister	kompakte Wiederherstellungs- und Nächste-Aufgabe-Kontext, beim Bootstrap gelesen
sessions/	pair.sh spawn / rotate	vorherige fertige Berichte; aufbewahrte Sitzungsexporte und Zeitsteuerungs-Evidenz
events.tsv	jeder pair.sh-Befehl	eine Zeile pro Nachricht, Bericht, Aufwecken und Protokolleintrag, gelesen von pair.sh metrics

NNN ist eine nullgepolsterte Sequenz, die von Plan oder Auftrag, Bericht und Überprüfung gemeinsam genutzt wird, sodass die Dateien für eine Einheit zusammen sortieren.

Nachrichten

Aufforderungstext	Richtung	Helfer des Senders	Zug des Empfängers
bootstrap (nennt die Fertigkeit und den Speicher)	Meister an Sidekick	pair.sh spawn	Bootstrap-Schritte, reports/000-ready.md, Antwort READY
pstack-pair PLAN <plan-path>	Meister an Sidekick	pair.sh discuss	den Plan im Code verankern, eine Zustimmungs- oder Einwand-Antwort schreiben, die Runde beenden
pstack-pair BRIEF <brief-path>	Meister an Sidekick	pair.sh dispatch	den Auftrag ausführen, seinen Bericht schreiben, pair.sh finish ausführen, dann die Runde mit der REPORT-Zeile beenden
pstack-pair BRIEF <brief-path>, in die Warteschlange gestellt	Meister an einen arbeitenden Sidekick	pair.sh queue	der Meister sendet ihn nach einer frischen Sitzung; pair.sh next lehnt ab
pstack-pair STEER <steer-path>	Meister an einen arbeitenden Sidekick oder an einen, der bei einem Einwand pausiert	pair.sh steer	bei Ankunft lesen, zwischen Werkzeugaufrufen; zustimmen und fortfahren, oder mit Evidenz Einwände erheben und die Runde beenden
pstack-pair REPORT <report-path>	Sidekick an Meister	pair.sh finish (oder notify)	den Bericht lesen, überprüfen
pstack-pair STOP <store>	Meister an Sidekick	pair.sh stop	sicher pausieren, einen Stopp-Bericht schreiben

Das dispatch und wait des Meisters kehren zurück, wenn die Antwort des Sidekicks eintrifft: der seit der Nachricht geschriebene Bericht oder ein blocked-Sidekick. Ein Beruhigen (settle) vom Multiplexer allein wird nicht getraut: Ein Devin-Sidekick zeigt Leerlauf an, wenn eine Aufforderung eintrifft und zwischen Schritten, und kann in einem schmalen Fenster für einen ganzen Durchlauf fertig anzeigen, daher wird ein Beruhigen an der "esc to interrupt"-Zeile des Fensters geprüft; ein Beruhigen ohne Bericht, das eine Minute anhält, beendet die Wartezeit mit report: missing. Sie kehren auch zurück, wenn das Check-in-Intervall vergeht, während der Sidekick noch arbeitet, und drucken eine Check-in-Zusammenfassung anstelle eines Berichtspfads. wait gibt auch in dem Moment zurück, in dem ein versendeter Auftragsbericht eintrifft, selbst wenn der Sidekick bereits den in die Warteschlange gestellten Auftrag übernommen hat; running: benennt dann den Auftrag, an dem er arbeitet. notify fordert den Meister nur auf, wenn der Meister im Leerlauf ist, sodass ein wartender Meister niemals unterbrochen wird. Eine Nachricht, die du nach einer Kompaktierung erhältst, benennt immer noch diese Fertigkeit und die zu lesende Datei, also lade die Fertigkeit neu und fahre mit dieser Datei fort.

Zuerst planen

Die Implementierung beginnt nur aus einem Plan, dem beide Agenten zugestimmt haben. Der Meister treibt die Implementierung, Architektur und das Systemdesign voran: Er entwirft plans/NNN-<slug>.md mit dem gewählten Design, den Alternativen, die er abgewogen hat, und deren Vor- und Nachteilen, sendet ihn dann mit pair.sh discuss. Der Sidekick denkt über diese Abwägungen nach, prüft jeden Schritt gegen den Code und antwortet mit Zustimmung oder Einwand und Evidenz. Der Meister überarbeitet in einer neuen Planrunde oder antwortet auf die Einwände, bis eine Antwort Zustimmung sagt und der Meister eine Überprüfung mit dem Urteil agreed schreibt. pair.sh dispatch lehnt einen Auftrag für Funktion, Fehlerbehebung, Refactoring, Leistungsproblem oder pstack-tdd ab, dessen plan:-Zeile keinen vereinbarten Plan benennt. Schreibgeschützte und forensische Aufträge benötigen keinen Plan; ein Diagnose-Auftrag für einen Fehler läuft vor seinem Plan, sodass der Plan auf Laufzeit-Evidenz basiert. Drei Runden ohne Einigung werden zu einer Hürde für den Menschen, mit beiden Positionen in gates.md.

Check-ins und Lenkungsbefehle

Der Meister treibt an, wie ein Fahrer beim Pair Programming: Er schaut in einem Rhythmus nach, nicht kontinuierlich, und korrigiert die Richtung, nicht die Tastenanschläge.

• Der Sidekick hängt eine Zeile pro abgeschlossenem Aufgabenlisten-Schritt und pro Richtungswechsel an progress/NNN-<slug>.md an, über pair.sh progress. Bevor er außerhalb des Umfangs schreibt oder vom Plan abweicht, schreibt er zuerst die Zeile, sodass ein Check-in es abfangen kann.
• dispatch und wait kehren im Check-in-Intervall (--every MIN, standardmäßig neun Minuten) zurück, wenn der Sidekick noch arbeitet, mit einer Zusammenfassung: verstrichene Zeit gegen das Zeitlimit, die noch nicht gesehenen Fortschrittszeilen, berührte Dateien und welche außerhalb des Umfangs liegen, Commits seit dem Versand und Lenkungszählungen. Wenn der Sidekick den Branch gewechselt oder rebased hat, sodass HEAD nicht mehr vom Versand-HEAD abstammt, zählen nur die seit dem Versand gemachten Commits als berührt. Diese Zusammenfassung ist alles, was der Meister zwischen den Berichten liest; er liest das Fenster nur, wenn die Zusammenfassung das Protokoll als STALE markiert.
• Ein Lenkungsbefehl ist eine mid-Auftrag-Korrektur vom Meister: pair.sh new-steer, dann pair.sh steer. Er landet in der Eingabewarteschlange des Sidekicks, während dieser arbeitet; das Geschirr übergibt ihn zwischen Werkzeugaufrufen und der Sidekick handelt daraufhin, nicht am Ende des Schritts. Ein Devin-Sidekick erhält ihn stattdessen als STEER:-Zeile von seinem nächsten pair.sh step, notes oder progress, da die Eingabe, die eine in die Warteschlange gestellte Nachricht an Devin liefert, seinen laufenden Befehl abbricht. --interrupt bricht zuerst den laufenden Werkzeugaufruf ab, für eine Richtung, die nicht darauf warten kann. Lenkungsbefehle tragen eine Richtung: einen Ansatz, den der vereinbarte Plan nicht gewählt hat, Umfangsdrift, einen zu überspringenden Schritt, eine Verbotene Zeile, die kurz vor dem Überschreiten steht, oder Neuigkeiten vom Menschen. Alles, was die Überprüfung am Ende abfangen kann, wartet auf die Überprüfung.
• Der Sidekick stimmt zu oder erhebt Einwände, wie bei einem Plan. Zustimmen: anwenden, im Fortschrittsprotokoll bestätigen, fortfahren. Einwände erheben: die Lenkungsantwort mit Evidenz und einer Alternative schreiben, benachrichtigen, die Runde beenden. Der Meister antwortet mit einem Lenkungsbefehl, der den beanstandeten ersetzt, überarbeitet oder zurückgezogen, und pair.sh steer setzt den Sidekick fort. Zwei Runden pro Lenkungsbefehl; die Entscheidung bleibt beim Meister, und eine anhaltende Meinungsverschiedenheit geht in eine Planrunde.
• Zwei frische Lenkungsbefehle pro Auftrag. Ein dritter bedeutet, dass der Auftrag falsch war: die Einheit stoppen und neu beauftragen.

Aufgabensitzungen jeder Art

Ein Sidekick jeder Art (Claude, Codex, Devin, pi, Prime, Muse) verwendet eine frische Unterhaltung für jeden abgeschlossenen Auftrag. Bevor du seinen Speicher spawnst, in die Warteschlange stellst, rotierst oder bereinigst, lies den Devin-Sitzungslebenszyklus für Devin oder Pi, oder den Prime-Adapter für Prime. Teilweise und blockierte Arbeit bleibt in seiner Sitzung; ein abgeschlossener Auftrag verlässt die Warteschlange für den Meister zum Versenden. dispatch und discuss rotieren den Sidekick selbst zuerst (rotated: in ihrer Ausgabe); pair.sh rotate bleibt für den Meister, um es von Hand auszuführen. Der pstack-Speicher bleibt über Sitzungen hinweg bestehen.

Muse Code

Verwende --kind muse für jede Rolle. Lies den Muse-Adapter für seine Berechtigungs-, Vertrauens-, Preflight- und Exit-Behandlung. Muse führt eine Unterhaltung pro Fenster, daher wird es nicht pro Auftrag rotiert.

Prime Agent

Verwende --kind prime-agent für den Sidekick. Lies den Prime-Agent-Adapter für native Modellargumente, Preflight, Lenkung, exakte Daemon-Sitzungsbereinigung und Provider-Failover. Prime verwendet das gemeinsame Speicherprotokoll und erfordert eine Rotation nach jedem abgeschlossenen Auftrag.

Pi Sidekick und Fallback

Ein Pi-Sidekick meldet seinen Zustand an Herdr (und mit der pstack-Erweiterung an Rex) über seine eigenen Ereignisse und stellt einen Lenkungsbefehl in die Warteschlange, ohne den laufenden Befehl abzubrechen. Wenn sein Modell hinter einer Route sitzt, die ausfallen kann, starte ihn mit --fallback devin: spawn prüft zuerst das Modell, und pair.sh failover tauscht den Fallback während des Laufs ein. Lies die Pi-Sidekick-Referenz, bevor du einen spawnst.

Den Sidekick beschäftigt halten

Der Sidekick ist der kritische Pfad: Der Meister wendet einen Bericht in Minuten um, während eine Einheit zig Minuten bis Stunden dauert. Drei Gewohnheiten halten den Sidekick vom Warten auf den Meister ab.

• Den nächsten Auftrag in die Warteschlange stellen. Während eine Einheit läuft, entwirft der Meister die nächste und hält sie mit pair.sh queue. Nach einem done-Bericht startet der Sidekick eine frische Sitzung und der Meister sendet diesen Auftrag; pair.sh next lehnt ab. Die Warteschlange hat einen Platz und enthält nur eine Einheit, die nicht von der Überprüfung der laufenden Einheit abhängt, sodass eine revise zu einem Folgeauftrag wird, nicht zu einer Nacharbeit des eingereihten.
• Überprüfung beim Commit. Ein Auftrag, der schreibt, sagt commit: yes, und der head: des Berichts benennt diesen Commit. Der Meister liest ihn mit git show, während der Sidekick an der nächsten Einheit arbeitet, und führt Prüfungen in pair.sh scratch <store> NNN-<slug>-review --at <head> erneut aus, niemals im gemeinsamen Baum.
• Ändern statt neu planen. Ein Einwand, den der Meister übernimmt, wird zu einer nummerierten Änderung in der agreed-Überprüfung. Eine neue Planrunde ist für ein geändertes Design gedacht.