jumiBot/Flujo de Tareas (Aufgabenablauf)

Aufgabenablauf (Flujo de tareas)

Die Regel für jede Statusänderung findet sich in references/estados.md: eine Karte pro Änderung mit Angaben zu Wann, Wer, Welche Autorisierung erforderlich, Was im Repository passiert und Reihenfolge. Diese Datei beschreibt die Anwendung.

So wird die Warteschlange geändert

Jeder Schreibzugriff auf die Warteschlange erfolgt über das CLI, niemals von Hand:

python -I -X utf8 "$HOME/.claude/sf/cola.py" [--raiz RUTA] [--quien propietario|principal] [--via cli|panel] [--json] <Befehl> …

• Immer dieser Befehl, gleich in bash, zsh und PowerShell, in jedem Projekt; auch für Unteragenten. Wenn der Mod zu Beginn der Sitzung mitteilt, dass Python auf diesem Rechner mit einem anderen Namen gestartet wird (unter macOS: python3), wird dieser Name statt python verwendet – hier und in jedem SF-Python-Befehl („Der Python-Befehl verwendet den erkannten Interpreter“, 236); der Auftrag von cola.py encargo sagt dies ebenfalls. Niemals das tools/cola.py eines Ordners (in der SF ändert sich plugins/sf/tools/cola.py mit dem aktiven Branch): maßgeblich ist das des geladenen Plugins. Beim Laden kopiert das Panel sein cola.py nach ~/.claude/sf/cola-<Sitzung>.py und führt es aus („Das Panel führt eine beim Laden erstellte Kopie von cola.py aus“, 136); ~/.claude/sf/cola.py ist ein Starter, der den Befehl an diese Kopie weiterleitet, über CLAUDE_CODE_SESSION_ID: Claude und das Panel verwenden dieselbe (Aufgabe 252). Ohne die Kopie wird mit 2 beendet und eine Meldung ausgegeben; /reload-plugins erstellt sie neu.
• --raiz: das Projektverzeichnis, standardmäßig das aktuelle. Zum Testen der Pfad einer Kopie der Warteschlange.
• --quien: standardmäßig principal; propietario, wenn die Änderung eine Entscheidung des Eigentümers ist (seine Zustimmung zum Schließen).
• Rückgabewerte: 0 bei erfolgreicher Änderung, 1 wenn keine Änderung vorgenommen wird (Grund wird genannt, nichts wird berührt) und 2 bei fehlerhaftem Befehl; choques (nur Abfrage) gibt 3 bei Konflikten zurück. cola.py <Befehl> -h zeigt die Verwendung jedes Befehls.

Was das CLI bei jedem Schreibzugriff tut: Sperren der Warteschlange (.sf/peticiones.lock), vorherige Sicherung einer Kopie in .sf/copias/ (die letzten 50), Eintragen der Änderung in das historial der Aufgabe und, wenn die Aufgabe die Warteschlange verlässt, Übertragen mit Historie nach .sf/historial.jsonl. Die Nummern werden nicht wiederverwendet.

Vom CLI nicht erzwungene Regeln

Das CLI wendet die Bedingungen jeder Änderung an (Ausgangszustand, Branch, Schritte, Git). Wann und wie es im Gespräch verwendet wird (das Menü beim Notieren, In-Bearbeitung-setzen, Starten und Einsammeln von Unteragenten, Vorschlagen von Tests und Schließen, Vorschlagen von Zusammenführungen und Neubeschreibungen, Dokumentationsaufgaben, was in freier Zeit zu tun ist) ist in der Fähigkeit sf:orquestacion beschrieben. Hier folgt, was die Warteschlange selbst betrifft:

• Nur der Hauptnutzer schreibt in die Warteschlange. Ein Unteragent führt keine schreibenden Befehle aus; dies wird in seinem Bericht erwähnt, und der Hauptnutzer führt sie aus.
• Jede Anfrage wird unter einer laufenden Aufgabe bearbeitet; ohne diese wird nicht mit der Arbeit begonnen. Das Umorganisieren der Warteschlange (Zusammenführen, Aufteilen, Neubeschreiben, Schritte hinzufügen, Typen ändern) erfordert keine laufende Aufgabe („Orchestrierung mit einem lebenden Unteragenten pro Aufgabe“, 149).
• Die Zustimmung des Eigentümers: cerrar, a-observacion, reobservar und descartar erwarten sie; en-cola von einer laufenden Aufgabe ebenfalls, jedoch nur ohne Arbeit: mit eigenen Commits in ihrem Branch (oder im Hilfsbranch ihres Unteragenten) kehrt sie nicht in die Warteschlange zurück; sie wird geschlossen, in Beobachtung genommen oder verworfen („Eine laufende Aufgabe mit Branch kehrt nicht in die Warteschlange zurück“, 170). Bei leerem oder bereits gelöschtem Branch entfernt en-cola den Branch und sammelt den Unteragenten leer ein (275).
• Typ bei Erstellung (crear --tipo): deliberar (beraten), documentar (dokumentieren), diseñar (entwerfen), implementar (implementieren), especificar (spezifizieren), corregir (korrigieren) oder investigar (untersuchen); bei Änderung: tipo N T.
• Konflikte vor en-curso: choques N, mit --archivos und den voraussichtlichen, basierend auf der Beschreibung, wenn noch kein Branch vorhanden ist. Nicht beim Starten von Unteragenten bereits laufender Aufgaben („Konflikte vorhersehen, wenn eine Aufgabe in Bearbeitung genommen wird“, 130).
• Branch vor dem ersten aktiven (rama), mit Hinweis. Für einen Unteragenten erstellt der Hauptnutzer den Branch ohne Aktivierung und notiert ihn vor dem Start (rama --sin-activar, subagente); der Unteragent arbeitet auf einem Hilfsbranch davon, und der Hauptnutzer führt ihn mit git merge --ff-only zusammen. Der Unteragent aktiviert niemals den Aufgabenbranch in seinem Worktree: so funktionieren T und C mit dem eingestellten Worktree („Orchestrierung mit einem lebenden Unteragenten pro Aufgabe“, 149).
• Einsammeln des Unteragenten: erfolgt durch das CLI, mit den in subagente notierten Worktrees und Branches (--worktree akzeptiert relative Pfade zum Projekt), bei jedem Befehl, der die Aufgabe ohne ihn zurücklässt: cerrar, a-observacion, descartar, eliminar, a-propuesta, revertir, limpiar, reabrir und, bei absorbierten Aufgaben, fusionar (nur wenn sein Hilfsbranch bereits in dem verbleibenden Branch ist; der verbleibende behält seinen). Ohne Erzwingung: Ein Worktree mit uncommitteten Änderungen, ein Hilfsbranch mit Commits, die nicht in develop eingeflossen sind, oder ein nicht integrierter Hilfsbranch bei einer Zusammenführung bleiben erhalten, und es wird gewarnt. descartar und limpiar hingegen entfernen alles, auch den Hilfsbranch mit nicht eingeflossenen Commits und den Worktree mit uncommitteten Änderungen: Das Verwerfen verwirft alles (189). cerrar und a-observacion verweigern vorher, wenn ein Hilfsbranch Commits enthält, die nicht in den Aufgabenbranch eingebracht wurden, und geben an, wie sie einzubringen sind. reabrir hingegen bereinigt alles, auch mit uncommitteten Änderungen und ohne Warnung: Ein alter Worktree wird niemals wiederverwendet. Historie: recogida oder recogida-con-avisos. Der Hauptnutzer stoppt lediglich den Unteragenten und kümmert sich um die Warnungen („cola.py sammelt den Unteragenten ein, wenn die Aufgabe ohne ihn zurückgelassen wird“, 169).
• Die Signatur der Commits („Die Signatur des Abschluss-Commits ist konfigurierbar; ohne Konfiguration keine Zeile“, 238): Der Squash von cerrar und a-observacion, der Commit von decision und der der RELEASE-Version enthalten die coautor-Zeile aus .sf/proyecto.json (in der SF selbst, die diese Datei nicht hat, ihre eigene: Co-Authored-By: Claude Opus 5.5 <[email protected]>). cerrar, a-observacion, decision und encargo akzeptieren --coautor "…", das die konfigurierte Zeile überschreibt. Ohne eine solche gehen die Commits ohne Co-Autor-Zeile, und der Auftrag teilt dies dem Unteragenten mit.
• Entscheidungen des Eigentümers: decision "Titel" --archivo RUTA|--texto T [--numero NNN] [--coautor "Co-Authored-By: …"] [--push] berührt die Warteschlange nicht. Es liefert die nächste Nummer von docs/decisiones/ in develop und den Dateinamen NNN-AAAA-MM-DD-titel.md (mit --numero wird diese überschrieben, ohne den Namen zu ändern); schreibt die Datei (den Text, mit # Titel davor, falls nicht vorhanden; falls vorhanden, muss er übereinstimmen), erstellt README.md neu und führt den Commit „Decisión NNN: Título“ in develop durch, auch bei einem anderen aktiven Branch, ohne diesen zu wechseln oder seine Arbeitskopie zu berühren, wie a-propuesta (Aufgabe 273). Führt dies nicht aus, wenn develop in einem anderen Worktree ist oder, falls es der aktive ist, docs/decisiones/ uncommittete Änderungen enthält. Mit aktivem develop wird auch README.html neu erstellt. --push lädt develop hoch; gibt die Nummer und den Hash aus. Ohne Git oder ohne develop werden nur die Dateien geschrieben, und es wird eine Meldung ausgegeben (Aufgabe 283).
• Zusammenführen und Aufteilen werden vom Eigentümer geschrieben (/sf_fusionar, /sf_split im Panel); der Hauptnutzer führt mit fusionar nur zwei Aufgaben zusammen, die dasselbe Dokument aktualisieren („Eine Aufgabe pro zu aktualisierendem Dokument“, 142).

Befehle nach Moment

Moment	Befehle
Anlage und Start	crear, choques, en-curso, en-cola, rama
Während der Arbeit	paso añadir, paso marcar, paso quitar, renombrar, tipo, subagente, informe
Test	listo, comprobado, probar
Abschluss	cerrar, a-observacion
In Beobachtung	observando, seguir, cerrar, reobservar und, falls nötig, revertir
Rückgängig machen	descartar, limpiar, revertir, reabrir, eliminar, restaurar, a-propuesta
Zusammenführen und Aufteilen	fusionar, split
Abfrage und Kopien	lista, ver, copias, recuperar
Außerhalb der Warteschlange	decision

Jeder Abschluss (cerrar, a-observacion), mit oder ohne Branch, auch ein Vorschlag, erfordert den Schritt „Aufgabe schließen“ und keinen anderen offenen Schritt außer „Branch aktivieren, um testen zu können“. Die beiden Abschlussschritte werden von cola.py gesetzt, sobald die Aufgabe in Bearbeitung geht (crear --en-curso, en-curso, reabrir, probar aus der Warteschlange, restaurar, fusionar), einmal und am Ende, und werden weder entfernt noch im Text geändert; eine laufende Aufgabe ohne diese Schritte erhält sie beim Laden der Warteschlange. Ein neuer Arbeitsschritt setzt „Branch aktivieren, um testen zu können“ wieder auf offen, falls es bereits erledigt war: Es muss erneut getestet werden. Die Testhilfen (paso añadir N "text" --prueba) werden zwischen den beiden Abschlussschritten eingefügt, werden von keinem Abschluss gefordert, bleiben wie sie sind, und ihr Hinzufügen setzt „Branch aktivieren“ nicht auf offen zurück („Testhilfen: nach Aktivierung des Branches und nicht obligatorisch für den Abschluss“, 184). listo speichert nur, was zu testen ist („Die Abschlussschritte, seit die Aufgabe in Bearbeitung ist“, 174). probar integriert develop in den Branch (Merge; bei Konflikten wird dies rückgängig gemacht und nicht aktiviert; bei Commits von sub-NN, die nicht eingebracht wurden, wird weder integriert noch aktiviert), aktiviert ihn oder belässt ihn, falls bereits aktiv, und markiert „Branch aktivieren, um testen zu können“ als erledigt, ebenso cerrar: Die Zustimmung des Eigentümers ist das Schließen (172, 121). Die Schritte werden ab 1 nummeriert, wie das n jedes Schrittes in ver. Was die Warteschlange verlässt, trägt in .sf/historial.jsonl den Status, mit dem es verlassen hat (cerrada, eliminada, absorbida, descartada und, aus der Zeit vor der Revision, die gelöscht oder offen gelassen hat (134), revertida), und ver zeigt dies an.

Revertir (Rückgängig machen) erfordert die Angabe des Ziels: revertir N --eliminar entfernt die Aufgabe spurlos aus der Warteschlange, wie die E; revertir N --pendiente gibt sie als offene, wiedereröffnete Aufgabe ohne Branch in die Warteschlange zurück. Sie verbleibt nie in Geschlossen mit R („Revertir entfernt die Aufgabe oder belässt sie offen“, 134). Wenn der Eigentümer dies nicht angibt, ihn fragen, welches.

Wenn ein Befehl aufgrund von Git-Problemen fehlschlägt (Konflikte beim Squash oder beim Revert, uncommittete Änderungen, der Branch in einem anderen Worktree), macht das CLI dies rückgängig und gibt an, was passiert ist; der Hauptnutzer löst das Problem und wiederholt den Befehl. Ein fehlgeschlagener Push verhindert den Abschluss nicht: Es verbleibt in der Historie (push-fallido), und der Push wird manuell wiederholt.