Wiederkehrende Aufgaben

Wiederkehrende Aufgaben ermöglichen es, einen Workflow nach einem wiederholenden Zeitplan automatisch auszuführen. Statt jeden Morgen manuell einen Run für eine nächtliche Code-Qualitätsprüfung oder jeden Montag für ein Abhängigkeits-Update auszulösen, definieren Sie eine wiederkehrende Aufgabe einmal, und CodeCourier löst sie automatisch in der konfigurierten Frequenz aus. Jede Auslösung erzeugt einen Standard-Workflow-Run mit Quelle scheduled, der wie jeder andere Run in der Run-Historie Ihres Projekts erscheint.

Datenmodell wiederkehrender Aufgaben

Ein Datensatz für eine wiederkehrende Aufgabe enthält alle Informationen, die nötig sind, um jeden Run, den sie auslöst, zu planen und zu konfigurieren:

{
  title: string,                        // Human-readable name for the task
  description: string,                  // Optional longer description
  prompt: string,                       // The prompt sent to the workflow each firing
  frequency: "daily"                    // How often the task fires
            | "every_other_day"
            | "weekly"
            | "biweekly"
            | "monthly",
  targetWorkflowId: string,             // Workflow blueprint to execute
  projectId: string,                    // Owning project
  createdBy: string,                    // User who created the task
  isActive: boolean,                    // Whether the task is currently enabled
  timezone: string,                     // IANA timezone (e.g., "America/New_York")
  scheduledHour: number,               // Hour to fire (0-23, in the given timezone)
  scheduledMinute: number,             // Minute to fire (0-59)
  nextRunAt: number,                    // Unix timestamp of next scheduled execution
}

Frequenz-Optionen

CodeCourier unterstützt fünf Wiederholungsfrequenzen:

• daily - Wird einmal pro Kalendertag zur konfigurierten Stunde und Minute ausgelöst. Verwenden Sie dies für nächtliche Qualitätsprüfungen, tägliche Testläufe oder kontinuierliches Abhängigkeits-Scanning.
• every_other_day - Wird alle zwei Tage ausgelöst. Ein leichterer Rhythmus als täglich - nützlich für Aufgaben, die wichtig sind, aber nicht jeden einzelnen Tag laufen müssen.
• weekly - Wird einmal pro Woche am gleichen Wochentag und zur gleichen Zeit wie bei der ursprünglichen Erstellung ausgelöst. Verwenden Sie dies für wöchentliche Abhängigkeits-Updates, wöchentliche Refactoring-Durchläufe oder wöchentliche Abdeckungsberichte.
• biweekly - Wird alle zwei Wochen ausgelöst. Geeignet für Aufgaben mit Sprint-Rhythmus, etwa Sicherheits-Audits oder Dokumentations-Updates, die an Entwicklungszyklen ausgerichtet sind.
• monthly - Wird einmal pro Kalender- monat ausgelöst. Am besten für seltene, hoch-impact Automation wie große Abhängigkeits-Upgrades oder Compliance-Prüfungen.

Eine wiederkehrende Aufgabe erstellen

Wiederkehrende Aufgaben werden im Bereich für wiederkehrende Aufgaben des Projekts erstellt, erreichbar unter /p/[id]/recurring. Jede Aufgabe kann zudem einzeln eingesehen und bearbeitet werden unter /p/[id]/recurring/[taskId].

Wie geplante Runs funktionieren

Wenn eine wiederkehrende Aufgabe ausgelöst wird, erzeugt der CodeCourier-Scheduler einen Workflow-Run mit zusätzlichen Scheduling-Metadaten:

{
  source: "scheduled",                  // Identifies the run as scheduler-originated
  workflowId: task.targetWorkflowId,
  prompt: task.prompt,
  scheduledFor: timestamp,              // When the task was scheduled to fire
  timezone: task.timezone,              // Timezone from the recurring task
  recurrencePattern: task.frequency,    // e.g., "daily", "weekly"
  recurringTaskId: task._id,            // Reference back to the recurring task
  // ... standard run configuration
}

Diese Felder erscheinen in der Run-Detailansicht und verknüpfen jede Ausführung mit der wiederkehrenden Aufgabe, die sie ausgelöst hat. Der Zeitstempel scheduledFor spiegelt die beabsichtigte Auslösezeit wider, die aufgrund der Scheduler-Queue- Latenz geringfügig von der tatsächlichen startedAt-Zeit abweichen kann.

Integration in die Runs-Liste

Geplante Runs erscheinen in der Runs-Liste des Projekts mit:

• Quellen-Badge, das scheduled anzeigt (verschieden vonworkflow, sprint oder sandbox).
• Dem Titel der wiederkehrenden Aufgabe als Teil des Run-Namens, was geplante Runs auf einen Blick erkennbar macht.
• Standard-Statusverfolgung - geplante Runs durchlaufen denselben Lebenszyklus pending → running → completed/failed wie alle anderen Runs.

Wiederkehrende Aufgaben verwalten

Aktivieren und Deaktivieren

Jede wiederkehrende Aufgabe hat einen isActive-Toggle. Das Deaktivieren einer Aufgabe pausiert alle künftigen Auslösungen, ohne die Aufgabe zu löschen. Das Feld nextRunAt wird beim Deaktivieren gelöscht. Das Reaktivieren der Aufgabe berechnet nextRunAt neu, ausgehend von der aktuellen Zeit basierend auf Frequenz und Zeitplan.

Wiederkehrende Aufgabe bearbeiten

Alle Felder einer wiederkehrenden Aufgabe können auf ihrer Detailseite bearbeitet werden. Änderungen wirken sich auf die nächste Auslösung aus - jeder laufende Run verwendet die Konfiguration vom Zeitpunkt seiner Auslösung, nicht die aktualisierten Werte. Das Bearbeiten des Zeitplans (Frequenz, Zeitzone, Stunde oder Minute) führt dazu, dass CodeCourier nextRunAt sofort neu berechnet.

Sie können ändern:

• Titel und Beschreibung.
• Prompt - der aktualisierte Prompt wird ab der nächsten Auslösung verwendet.
• Ziel-Workflow - tauschen Sie für künftige Runs eine andere Pipeline ein.
• Frequenz, Zeitzone, Stunde und Minute.

Eine wiederkehrende Aufgabe löschen

Das Löschen einer wiederkehrenden Aufgabe entfernt sie endgültig und stoppt alle künftigen Auslösungen. Runs, die von der Aufgabe erstellt wurden, bleiben in der Run-Historie und sind nicht betroffen. Um die Aufgabenkonfiguration für eine mögliche spätere Nutzung zu erhalten, sollten Sie eher deaktivieren als löschen.

Zeitzonen-Behandlung

Wiederkehrende Aufgaben speichern eine explizite IANA-Zeitzone, damit sich Zeitpläne unabhängig vom Standort der Teammitglieder oder der Server-Zeitzone, in der CodeCourier läuft, intuitiv verhalten. Die Zeitzone wird sowohl bei der initialen Berechnung von nextRunAt als auch bei jeder folgenden Wiederholungsberechnung nach einer Auslösung verwendet.

Sommerzeit-Übergänge werden automatisch behandelt. Eine Aufgabe, die auf 09:00 America/New_York konfiguriert ist, läuft das ganze Jahr über um 9:00 Uhr Eastern Time, mit automatischer Anpassung an EST/EDT-Übergänge ohne manuellen Eingriff.

Run-Historie einer Aufgabe einsehen

Die Detailseite der wiederkehrenden Aufgabe (/p/[id]/recurring/[taskId]) zeigt die Run-Historie dieser spezifischen Aufgabe - alle Runs mit einer passenden recurringTaskId. Das gibt Ihnen eine fokussierte Sicht darauf, wie der geplante Workflow im Laufe der Zeit performt hat: wie viele Runs erfolgreich waren, wie viele fehlgeschlagen sind, und ob es Muster in Ausführungsdauer oder Qualitäts-Scores gibt.

Von jedem Run-Eintrag in der Aufgaben-Historie können Sie zur vollständigen Run-Detailseite navigieren, um Sandbox-Ausgaben, Schritt-Urteile, PR-URLs und Qualitäts-Scores zu inspizieren.

Anwendungsfälle

• Nächtliche Code-Qualitätsprüfungen - Eine tägliche Aufgabe führt jede Nacht um 2:00 Uhr einen Qualitäts-Workflow aus und fängt Typ-Fehler, Lint-Verstöße und Testfehler ab, die tagsüber eingeführt wurden.
• Wöchentliche Abhängigkeits-Updates - Eine wöchentliche Aufgabe wird jeden Montag ausgelöst und führt einen Workflow aus, der npm-Abhängigkeiten auditiert, veraltete Pakete aktualisiert und einen PR mit den Änderungen öffnet.
• Tägliche Testläufe - Eine tägliche Aufgabe führt einen Workflow aus, der das Projekt kompiliert und die vollständige Test-Suite ausführt, und Fehler über das Run-Benachrichtigungssystem meldet.
• Zweiwöchentliche Sicherheits-Audits - Eine zweiwöchentliche Aufgabe löst einen Deep-Dive-Workflow aus, der nach häufigen Schwachstellen in Abhängigkeiten, Konfiguration und Code-Mustern sucht.
• Monatliche Dokumentations-Synchronisation - Eine monatliche Aufgabe führt einen Designer-Workflow aus, der die Codebasis liest und die API- Dokumentation an die Änderungen des vergangenen Monats anpasst.
• Kontinuierliche Performance-Baseline - Eine alle-zwei-Tage- Aufgabe führt einen Workflow aus, der Performance-Benchmarks ausführt und die Ergebnisse committet, und so eine Langzeit-Baseline für Regressionserkennung aufbaut.