Bei der Übergabe einer Scheduler-Änderung könnte Folgendes stehen:
Ziel: Keine neuen Aufgaben annehmen, laufende Datenimporte fertigstellen lassen.
Ergebnis: Kernpatch gespeichert; Kommandozeileneinstieg noch nicht angeschlossen.
Konflikt: Der Patch bricht laufende Aufgaben ab; Tests bestätigen dieses alte Verhalten.
Nächster Schritt: Pausensemantik korrigieren, danach weiter anschließen.
Ausführende Instanz: keine.
Kein Agent läuft, dennoch hat die Arbeit einen klaren Zustand. Die übernehmende Person erkennt schon vor dem alten Gespräch den wichtigsten Defekt: Kerncode und aktuelles Ziel widersprechen einander. Direktes Anschließen würde falsches Verhalten zu Nutzern bringen.
Das ist ein Lehrbeispiel für den Work-Entwurf im öffentlichen Flowness-Commit c9d6abe. Diese Version führt den vollständigen Fortsetzungsweg zwischen Agents noch als Entwurf. Das Beispiel ist kein abgeschlossener Lauf. Entwurf und Evidenzstatus
Hinter der Adresse müssen Grundlagen erreichbar sein
Work bietet einen stabilen Zugang zu fortlaufender Arbeit. Eine Kennung hilft beim Finden, garantiert aber keine aktuellen Tatsachen hinter dem Link.
Flowness entwirft Work als Projektion zugrunde liegender Aufzeichnungen. Code bleibt im Repository, Tests verweisen auf Versionen, Urteile und Änderungen auf Ereignisse. Die Arbeitsansicht führt diese Fakten zusammen. Wechselt der Kernpatch die Version, muss sichtbar sein, welche Fassung geprüft wurde — über ein grünes „bestanden“ hinaus.
Die Ansicht besitzt eine zeitliche Position. as_of_seq bezeichnet das zuletzt berücksichtigte Ereignis. Steht sie bei 147 und ändert die verantwortliche Person bei 148 die Pausenanforderung, kann das System erkennen, dass die neue Entscheidung noch fehlt. WorkView-Entwurf
So kann der Zugang weitere Handlungen zuverlässiger unterstützen als eine Übergabezusammenfassung. Diese erklärt damaliges Denken; die aktuelle Ansicht muss auch erkennen, welche Erklärungen später geändert wurden.
Nach einer Unterbrechung ist zuerst zu prüfen, was zurückblieb: Ist die alte Ausführung wirklich gestoppt, der Patch committet, welche Dateien sind noch temporär, welche Ergebnisse geprüft? Tatsächlicher Zustand bestimmt die Wiederaufnahme, nicht die alte Einschätzung „fast fertig“.
Danach entsteht der Kontext für die nächste Handlung. Flowness nennt ihn Context Capsule: Von einem bestimmten Faktenstand aus werden aktuelles Ziel, Versionen, gültige Bedingungen, Ergebnisse und offene Fragen ausgewählt. Beim Scheduler muss zuerst der Semantikkonflikt gelöst werden. Der gesamte Chatverlauf könnte die entscheidenden Materialien eher verdecken. Zustandsprüfung und Kontextzusammenstellung
Der neue Agent beginnt seine eigene Ausführung am selben Work. Geprüfte Ergebnisse werden Grundlage der nächsten Abfrage.
Neue Voraussetzungen verändern die Bedeutung alter Fertigmeldungen
Anfangs wurde Pause vielleicht als „alle Aufgaben stoppen“ verstanden. Später bestätigt die verantwortliche Person, laufende Importe müssen fertig werden. Das betrifft mehr als den Aufgabentext.
Alte Tests bestehen, prüfen jedoch Abbruch. Kerncode, Testassertionen und Kommandohilfe können auf derselben alten Voraussetzung beruhen. Ein davon unabhängiges Logformat muss nicht unbedingt neu erstellt werden.
Dafür braucht das System zwei Abhängigkeiten: Ausführungsreihenfolge und die Interpretationsversion, auf der ein Ergebnis beruht. Die erste sagt, dass Anschließen nach Tests kommt. Die zweite zeigt, dass deren Anforderung veraltet ist.
Flowness nennt eine die Folgearbeit verändernde Beobachtung Finding. Reflow lokalisiert betroffene Voraussetzungen und Abhängigkeiten und organisiert die Weiterarbeit. Hier genügt: „Die Kernimplementierung bricht laufende Importe entgegen der aktuellen Anforderung ab.“ Der Plan kehrt zum Kernverhalten zurück, prüft das Fertigwerden laufender Aufgaben und verbindet anschließend die Kommandozeile. Finding und Reflow
Vorhandene Ergebnisse bleiben erhalten; geändert wird, welche Urteile sie stützen. Alte Tests erklären die Geschichte, belegen aber nicht die Erfüllung neuer Anforderungen.
Ob lokale Nacharbeit spart, hängt von genauen Abhängigkeiten ab. Fehlende Beziehungen verlangen Untersuchung. Bei unklarem Umfang kann breiteres Prüfen günstiger sein als feine Klassifikation. Reale Änderungsaufgaben müssen daher zeigen, wie viele Irrwege der Entwurf vermeidet und welche Dokumentationskosten er hinzufügt.
Für dauerhafte Ausführung gibt es bereits reife Werkzeuge. Temporal stellt Workflow-Zustand aus Ereignisgeschichte wieder her und nimmt Signal, Update und andere Eingaben entgegen. LangGraph speichert Graphzustand und datenübergreifende Thread-Inhalte mit Checkpoints und persistentem Speicher. Temporal-Workflows, Nachrichten, LangGraph-Persistenz
Work fragt, wie gespeicherter Zustand auszulegen ist: Zielversion, ersetzte Urteile, betroffene Ergebnisse und jetzt benötigtes Material. Diese Regeln können auf bestehenden Engines aufbauen. Bewahren Tickets, Repository und Workflow die Beziehungen bereits vollständig, erhöht eine parallele Datenbank nur den Synchronisationsaufwand.
Auch nach „fertig“ bleibt die Adresse nützlich
Reparierte Kernlogik beseitigt nicht jede Folgearbeit. Flowness unterscheidet vier Zustände mit verschiedenen Anschlussaktionen:
| Zustand | Bedeutung beim Scheduler |
|---|---|
| Gebaut (built) | Ein prüfbares Ergebnis der Pausenfunktion liegt vor. |
| Integriert (integrated) | Kommando und tatsächlicher Aufrufpfad sind verbunden. |
| Im echten Gebrauch aktiviert (activated) | Natürliche Nutzung in der Zielumgebung ruft die Fähigkeit tatsächlich auf. |
| Abgenommen (accepted) | Die zuständige Person bestätigt, dass das Ergebnis den Bedarf erfüllt. |
Aktivierung schließt Tests, Demos, Probeläufe und bloße Bereitstellung aus. Auch Abnahme muss auf ein bestimmtes Ergebnis und dessen Version zeigen. Definitionen von Aktivierung und Abnahme
Warten wird konkret: Die Funktion ist integriert, aber eine reale Pause wurde noch nicht gebraucht. Oder sie wurde genutzt, aber noch nicht abgenommen. Dafür muss kein Agent ständig laufen. Erwartetes Ereignis, verantwortliche Person und erneute Prüfbedingung genügen.
Tritt die Bedingung ein, wird dasselbe Work geöffnet, die aktuelle Version geprüft und die nächste Handlung begonnen. Die öffentliche Übergabedemo soll genau diesen Weg prüfen: Kann nach einer Unterbrechung eine neue Instanz aus dauerhaftem Zustand fortsetzen, ohne temporäres Gedächtnis des alten Agents? Spezifikation der Übergabedemo
Für Wartende muss die Adresse schließlich praktisch beantworten: Wo fange ich heute am Scheduler wieder an? Bleibt diese Antwort möglich, kann Arbeit Sitzungsende, Personalwechsel und veränderte Anforderungen überstehen.