cron-tuner — selbstjustierende Takt-Regelschleife
Eine selbstjustierende Regelschleife für wiederkehrende, zeitplangetriebene
Arbeit (Cron-Jobs, geplante Aufgaben, Timer). Statt eines festen Intervalls
passt der Job seinen eigenen Takt an: er schärft bei Arbeit und kühlt bei
Stille ab. Host- und plattformneutral; das Muster funktioniert mit jedem
Scheduler.
Wann nutzen
- Ein wiederkehrender Scan (Mailbox-Watch, Sync-Yard-Scan, Queue-Poll) soll
während eines aktiven "Match" schnell reagieren und in Leerlaufphasen
günstig bleiben.
- Die Anpassung soll auditierbar sein (eine State-Datei) statt implizit
in einer Konversation oder im Kopf einer Person.
Konzepte
- Regelschleife: messen → entscheiden → handeln → persistieren. Jeder
Lauf endet mit dem Schreiben seines States; jeder Lauf beginnt mit dessen
Lesen.
- Aktivierung: neue Arbeit gefunden → direkt auf das schnellste
Intervall springen.
- Cooldown-Leiter: leere Läufe rücken eine Leiter herab; jede Stufe
gilt nur, wenn sich das Intervall tatsächlich ändert.
- Deckel: niemals über ein definiertes Maximalintervall hinaus
entspannen.
Referenzschema
| Bedingung |
Neues Intervall |
| neue Arbeit gefunden |
schnellstes (z. B. 15 min) |
| 4 aufeinanderfolgende leere Läufe |
30 min |
| 6 aufeinanderfolgende leere Läufe |
1 h |
| jeder weitere leere Lauf |
verdoppeln (2 h, 4 h, 8 h) |
| Deckel |
24 h (niemals höher) |
Die Schwellen auf die Arbeitslast abstimmen; die Verdopplung einfach und den
Deckel explizit halten.
State-Datei (Pflicht)
Eine kleine JSON-Datei je Worker, z. B. cron-tuner-state.json:
{
"empty_runs": 0,
"interval_minutes": 15,
"note": "cron-tuner state"
}
Regeln:
- Datei, nicht Gedächtnis. Der Zähler muss Kontext-Kompaktierung,
Session-Neustarts und Operator-Wechsel überleben und für Menschen und
andere Agenten einsehbar sein. Den Takt nicht in der Konversationshistorie
verfolgen.
- Nur bei Änderung neu schreiben. Den State bei jedem Lauf persistieren,
aber den geplanten Job nur ersetzen, wenn sich das Intervall tatsächlich
ändert.
- Neuer Job = neuer Zeitplan, gleicher State. Ein Taktwechsel bedeutet,
den alten Job zu löschen und einen neuen mit dem neuen Intervall
anzulegen; der Zähler läuft weiter.
Betriebsregeln
- Arbeit entscheidet, nicht Stimmung. Nur beobachtete Ankünfte ändern
den Takt — niemals Erwartungen oder Näherungen.
- Anti-Herden-Offsets. Volle-Stunde- und Halbe-Stunde-Marken für das
schnellste Intervall meiden (z. B. Minuten 7/22/37/52), damit Flotten
nicht im Gleichschritt feuern.
- Fail-Safe: Verstummt ein Partnersystem, gilt die normale
Vakanz-/Abwesenheitsregel — der Tuner eskaliert nie in Poll-Fluten.
- Belege: Jeder Taktwechsel wird mit Grund, altem und neuem Intervall
protokolliert.
Erweiterbarkeit (Registry der Loop-Typen)
Der Skill ist die Heimat für weitere selbstjustierende Loop-Typen über die
Zeit:
- cooldown (dieses Schema: Stille → langsamer)
- backoff (Fehler → langsamer, Erfolg → schneller)
- burst (Ankunfts-Spitze → temporärer Schnellmodus mit explizitem Ende)
- wake-assist (externe Wake-Nachricht → sofortiger Lauf außerhalb des
Zyklus)
Neue Loop-Typen bekommen hier ein Unterkapitel plus ihr eigenes
State-Datei-Schema.
1---2name: cron-tuner3description: Selbstjustierende Takt-Regelschleife für wiederkehrende Agenten-Scans. Nutzen, wenn ein geplanter Scan sein Intervall bei Aktivität schärfen und bei Stille abkühlen soll, ohne Operator-Eingriff.4---56<img src="banner.png" width="100%" alt="cron-tuner banner">78# cron-tuner — selbstjustierende Takt-Regelschleife910Eine **selbstjustierende** Regelschleife für wiederkehrende, zeitplangetriebene11Arbeit (Cron-Jobs, geplante Aufgaben, Timer). Statt eines festen Intervalls12passt der Job seinen eigenen Takt an: er schärft bei Arbeit und kühlt bei13Stille ab. Host- und plattformneutral; das Muster funktioniert mit jedem14Scheduler.1516## Wann nutzen1718- Ein wiederkehrender Scan (Mailbox-Watch, Sync-Yard-Scan, Queue-Poll) soll19 während eines aktiven "Match" schnell reagieren und in Leerlaufphasen20 günstig bleiben.21- Die Anpassung soll **auditierbar** sein (eine State-Datei) statt implizit22 in einer Konversation oder im Kopf einer Person.2324## Konzepte2526- **Regelschleife**: messen → entscheiden → handeln → persistieren. Jeder27 Lauf endet mit dem Schreiben seines States; jeder Lauf beginnt mit dessen28 Lesen.29- **Aktivierung**: neue Arbeit gefunden → direkt auf das schnellste30 Intervall springen.31- **Cooldown-Leiter**: leere Läufe rücken eine Leiter herab; jede Stufe32 gilt nur, wenn sich das Intervall tatsächlich ändert.33- **Deckel**: niemals über ein definiertes Maximalintervall hinaus34 entspannen.3536## Referenzschema3738| Bedingung | Neues Intervall |39|---|---|40| neue Arbeit gefunden | schnellstes (z. B. 15 min) |41| 4 aufeinanderfolgende leere Läufe | 30 min |42| 6 aufeinanderfolgende leere Läufe | 1 h |43| jeder weitere leere Lauf | verdoppeln (2 h, 4 h, 8 h) |44| Deckel | 24 h (niemals höher) |4546Die Schwellen auf die Arbeitslast abstimmen; die Verdopplung einfach und den47Deckel explizit halten.4849## State-Datei (Pflicht)5051Eine kleine JSON-Datei je Worker, z. B. `cron-tuner-state.json`:5253```json54{55 "empty_runs": 0,56 "interval_minutes": 15,57 "note": "cron-tuner state"58}59```6061Regeln:62631. **Datei, nicht Gedächtnis.** Der Zähler muss Kontext-Kompaktierung,64 Session-Neustarts und Operator-Wechsel überleben und für Menschen und65 andere Agenten einsehbar sein. Den Takt nicht in der Konversationshistorie66 verfolgen.672. **Nur bei Änderung neu schreiben.** Den State bei jedem Lauf persistieren,68 aber den geplanten Job nur ersetzen, wenn sich das Intervall tatsächlich69 ändert.703. **Neuer Job = neuer Zeitplan, gleicher State.** Ein Taktwechsel bedeutet,71 den alten Job zu löschen und einen neuen mit dem neuen Intervall72 anzulegen; der Zähler läuft weiter.7374## Betriebsregeln7576- **Arbeit entscheidet, nicht Stimmung.** Nur beobachtete Ankünfte ändern77 den Takt — niemals Erwartungen oder Näherungen.78- **Anti-Herden-Offsets.** Volle-Stunde- und Halbe-Stunde-Marken für das79 schnellste Intervall meiden (z. B. Minuten 7/22/37/52), damit Flotten80 nicht im Gleichschritt feuern.81- **Fail-Safe:** Verstummt ein Partnersystem, gilt die normale82 Vakanz-/Abwesenheitsregel — der Tuner eskaliert nie in Poll-Fluten.83- **Belege:** Jeder Taktwechsel wird mit Grund, altem und neuem Intervall84 protokolliert.8586## Erweiterbarkeit (Registry der Loop-Typen)8788Der Skill ist die Heimat für weitere selbstjustierende Loop-Typen über die89Zeit:9091- **cooldown** (dieses Schema: Stille → langsamer)92- **backoff** (Fehler → langsamer, Erfolg → schneller)93- **burst** (Ankunfts-Spitze → temporärer Schnellmodus mit explizitem Ende)94- **wake-assist** (externe Wake-Nachricht → sofortiger Lauf außerhalb des95 Zyklus)9697Neue Loop-Typen bekommen hier ein Unterkapitel plus ihr eigenes98State-Datei-Schema.