Spark — sarcini recurente și declanșate de evenimente

Ce face

Spark înregistrează joburi care rulează în fundal prin gateway-ul Hermes: o sarcină, un declanșator și o regulă de aprobare. Rezultatele sunt livrate prin canalul operatorului, iar pașii externi, distructivi sau financiari rămân propose-only dacă operatorul nu autorizează explicit altceva.

Când îmi folosește

  • pentru o verificare zilnică sau săptămânală;
  • pentru un job one-shot programat;
  • pentru o reacție la un tip de eveniment deja publicat pe event bus;
  • pentru muncă de fundal care trebuie reluată fără un nou prompt.

Cum îl invoc / declanșez

Spune-i lui Wednesday ce trebuie să se întâmple, când și ce acțiuni necesită aprobare. Pentru control direct, folosește CLI-ul din rădăcina vault-ului:

/opt/homebrew/bin/python3 $VAULT_ROOT/_infra/scripts/spark-task.py add \
  "Recap săptămânal" --weekly 09:00 --days mon \
  --task "Transformă notele furnizate într-un brief și propune follow-up-uri"
 
/opt/homebrew/bin/python3 $VAULT_ROOT/_infra/scripts/spark-task.py list

Declanșatoarele disponibile sunt --daily, --weekly, --every, --once și --on-event. Un trigger de eveniment se înregistrează numai după ce este confirmat un publisher curent pentru acel tip; Spark nu presupune existența unui emitter.

Exemplu practic

„În fiecare luni la 09:00, transformă notele săptămânii într-un brief de decizii și propune taskurile următoare în Apple Reminders.” Wednesday înregistrează jobul, confirmă programul și păstrează mutațiile la poarta de aprobare.

Pentru date personale, sursele canonice sunt Apple Reminders pentru taskuri, Beaver pentru obiceiuri și iCloud pentru calendar și mail. Alți conectori sunt folosiți doar dacă jobul îi cere explicit.

Output / unde aterizează

Fiecare run are un rezultat livrat operatorului și o înregistrare tehnică în ledgerul Spark. Taskurile pot fi listate, rulate imediat, dezactivate, reactivate sau șterse prin CLI.

Limite / gotchas

  • Execuția de fundal folosește modelul configurat în Hermes, fără model pin în skill.
  • --no-approval este potrivit numai pentru acțiuni strict read-only care trec allowlist-ul runnerului.
  • Prezența unui task în registry nu dovedește că publisherul unui eveniment există.
  • Starea autonomă se confirmă prin sănătatea grupului de daemoni și a publisherului Spark, nu printr-un label standalone.