lessan/jobs

Was macht jobs?

Verwende runjob, um begrenzte Arbeit an ein installiertes, kopfloses Modell-CLI zu übergeben und ein maschinenweites Ausführungs-Ledger zu führen. Stelle sicher, dass runjob im PATH ist; falls nicht, verweise den Benutzer auf die Installationsschritte des Repositorys, anstatt eine maschinenweite Installation zu improvisieren.

Das Starten eines Jobs kann Kontingente verbrauchen oder Kosten beim Anbieter verursachen. Behandle eine explizite Anfrage zum Versenden oder Übergeben von Arbeit als Autorisierung für diesen Start. Eine Anfrage zum Erklären, Inspizieren, Entwerfen oder Planen ist keine Startgenehmigung.

Wähle die Ausführungsform

• Verwende runjob run für einen einzelnen, begrenzten Job. Er wird im ausgewählten Arbeitsverzeichnis ausgeführt und erstellt keinen Branch oder Worktree. Für Arbeiten, die Änderungen vornehmen oder Commits durchführen können, verwende einen einmaligen Git-Worktree oder den Fleet-Modus.
• Verwende runjob fleet run für mehrere Jobs, Abhängigkeiten, automatische isolierte Worktrees, fortsetzbare Sitzungen oder gleichzeitige Limits pro Engine. Lese references/fleet.md, bevor du Fleet-Dateien erstellst.
• Verwende runjob log, runjob report und runjob dash, um bereits laufende Arbeiten zu überprüfen. Diese sind schreibgeschützt; runjob repair ist eine explizite Ledger-Mutation.

Ersetze diese Fähigkeit nicht durch einen In-Session-Subagenten, wenn der Benutzer eine Delegation innerhalb der aktuellen Konversation gewünscht hat.

Einmalige Jobs

Verwende eine Prompt-Datei für umfangreiche Anweisungen, sodass der Versand überprüfbar ist:

runjob run --engine codex --effort high \
  --cwd /absoluter/pfad/zum/worktree --file /absoluter/pfad/zur/prompt.md

Lasse --model oder --effort weg, wenn der Benutzer sie nicht ausgewählt hat und die Engine eine sinnvolle CLI-Voreinstellung hat. Erfinde keine aktuellen Modellnamen. Lese references/engines.md, wenn engine-spezifische Flags, Authentifizierung oder Sandbox-Verhalten relevant sind.

runjob run kehrt nach dem Start zurück, es sei denn, --wait wird angegeben. Behalte die ausgegebene UID. Überprüfe sie mit:

runjob log --uid UID
runjob log --active
runjob report UID --json
runjob dash

Logs und Prompts können Quellcode oder vertrauliche Anweisungen enthalten. Sie liegen unter ${DEV_JOBS_HOME:-~/.config/dev-jobs}; veröffentliche oder hänge sie nicht ohne separate Überprüfung an.

Abschluss und Übergabe

Melde die UID, die tatsächlich angeforderte Engine/das Modell, das Arbeitsverzeichnis und ob der Job nur gestartet oder bereits abgeschlossen wurde. Beschreibe einen Prozessstart nicht als erfolgreiches Ergebnis. Überprüfe beim Warten den Terminal-Ledger-Zustand und fasse die tatsächliche Ausgabe des Jobs zusammen, einschließlich Fehlern oder verbleibender Arbeit.

Für maschinenlesbare Job-Endungen verwende das exakte Protokoll in references/report-trailer.md. Behandle seine Felder als die Behauptungen des Jobs; überprüfe Commits, Tests und geänderte Pfade unabhängig, bevor du etwas mergst oder veröffentlichst.