Automatiseringer

Automatiseringer kører en instruktion efter en tidsplan og leverer resultatet som en almindelig chatsession. En daglig nyhedsoversigt, ugentlig gennemgang eller månedsrapport kører uden brugerflade på serveren, vises i chatlisten og kan åbnes og fortsættes som enhver anden samtale.

Opbygning

En automatisering har et navn, fritekstinstruktioner, en eller flere udløsere, en valgfri model (tomt betyder Auto: din standardmodel på kørselstidspunktet), et kørselsmål og en notifikationsindstilling. Målet bestemmer resultatet: Chat session (standard) sætter instruktionen i kø som en samtale, mens Work task starter en isoleret Work-sandbox med instruktionen som første besked og eventuelt en navngiven Work-policy. Med notifikationer aktiveret vises mislykkede kørsler også i notifikationsindbakken. Separat vil det at slå Automatiseringsresultater til under Indstillinger → Notifikationer → E-mailnotifikationer sende dig resultatet af hver kørsel via e-mail, når en administrator har konfigureret en udgående mailserver (se Notifikationer). Navne og instruktioner krypteres i hvile. Hver automatisering tilhører den bruger, der oprettede den.

Udløsere genbruger kalenderens model – once, hourly, daily, weekly, monthly, yearly – og en automatisering kan have op til fem. Næste kørsel er den tidligste kommende forekomst blandt alle udløsere, beregnet i serverens lokale tidszone.

Event-udløsere

En syvende slags, event, har slet intet ur: den udløses, når en af dine notifikationer ankommer.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event kan være enhver notifikationstype undtagen automation-failed — en rutine må ikke kunne genstarte sig selv fra sin egen fejlbesked. Det valgfrie match er en versalufølsom delstrengstest mod notifikationens titel; uden det udløser enhver notifikation af den type rutinen.

En event-udløser bidrager aldrig med et næste-kørsel-tidspunkt. En automatisering, hvis udløsere alle er events, viser derfor ingen næste kørsel: listen og redigeringsdialogen siger i stedet Runs when …. At blande en event-udløser med en tidsplan er fint — de planlagte udløsere driver stadig uret.

To spærringer begrænser rækkevidden. En rutine udløses højst én gang i minuttet fra events, uanset hvor travl strømmen er, og en kørsels egen fejlnotifikation udløser aldrig den rutine, der producerede den.

Kørslen modtager det, der udløste den, tilføjet dens instruktioner:

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Udførelse

En scheduler-tick kører hvert minut bag en koordineringslease, så præcis én replika flytter tidsplanerne. Når en automatisering forfalder, registrerer tick'et en kørsel, sætter et vedvarende automation.run.v1-job i kø og flytter next_run_at med compare-and-set, så hver forekomst udløses højst én gang. Jobbet opretter en chatsession med automatiseringens navn og køer instruktionen gennem samme vedvarende chatpipeline som andre samtaler, inklusive udbyderrute, personastandarder og lagring.

Hvis serveren var nede, kører næste tick den seneste forfaldne forekomst én gang og springer ældre tider over. Pause rydder tidsplanen; genoptagelse eller redigering beregner den igen fra nu. Sletning fjerner kørselsloggen gennem en foreign-key cascade.

Kørsler afgøres fra den vedvarende joblog: succes når chatgenereringen er afsluttet, fejl når et job dead-lettered, og fejl som stalled hvis en køet kørsel ikke starter inden for 30 minutter.

Work-kørsler bruger Work-livscyklussen i stedet for chatjobbet. Kørslen registrerer opgaven og linker til den, lykkes når agenten afslutter eller stopper for at bede om input og mislykkes ved fejl eller annullering. En resultat-e-mail for en Work-målrettet kørsel bærer det resumé, selve Work-kørslen gemte — det, agenten endte på, samme tekst som opgavens kørselshistorik viser — og falder tilbage til opgavens enkeltlinjestatus, når en kørsel går forud for gemte resumeer. Work-adgang håndhæves, når tidsplanen udløses; tilbagekaldt adgang giver work-access-denied. En valgt policy valideres ved lagring, og dens netværks- og ressourcegrænser gælder alle opgaver. Kun direkte modeludbydere kører i Work, og modellen skal understøtte værktøjer.

Agentrutiner

En Work-automatisering kan bindes til en eksisterende Work-opgave via workTaskId, som bruges af Routines på agentens detaljepanel. Hver forekomst starter en kørsel i opgavens eksisterende arbejdsområde og samtale med dens model, udbyder og runtime-policy; automatiseringens model- og policyfelter gælder ikke. Bindingen valideres ved lagring. En slettet opgave giver work-task-missing; en opgave, der allerede kører eller har en aktiv preview, giver work-task-busy i stedet for at blive køet.

Webhook-udløsere

Ud over tidsplanen kan en automatisering udløses af et eksternt system — en CI-pipeline, en cron-tjeneste, husautomation. I automatiseringens redigeringsdialog genererer Webhook trigger → Enable en hemmelighed pr. automatisering; kun dens SHA-256 gemmes, så klarteksten vises præcis én gang. Rotation af hemmeligheden ugyldiggør den forrige med det samme, og deaktivering af webhooken lukker endpointet igen.

Det eksterne system udløser automatiseringen med:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..."

(X-Libre-Webhook-Secret: lwh_... fungerer som alternativ header.) Svaret er 202 med id'et på den køede kørsel — den samme manuelle kørselssti som Run now, så kørsler afgøres, notificerer og vises i historikken på nøjagtig samme måde. Sammenligningen af hemmeligheden er konstant tid, en manglende automatisering og en forkert hemmelighed svarer ens (intet orakel for automatiserings-id), og en automatisering på pause svarer 409: i modsætning til ejerens Run now kan en ekstern kalder ikke udløse hen over en pause.

Et JSON-objekt i anmodningens krop følger med ind i kørslen som dens trigger-payload, så rutinen kan se, hvad den reagerer på:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..." \
  -H "Content-Type: application/json" \
  -d '{"commit":"abc123","branch":"main"}'

Payloaden tilføjes til de instruktioner, kørslen udfører, under en Trigger payload (JSON):-overskrift — for chatkørsler, nye Work-opgaver og opgavebundne rutiner alle tre. Kun JSON-objekter overføres (arrays og skalarer ignoreres), og en payload, hvis serialiserede form overstiger 4000 tegn, kasseres i stedet for at blive afkortet, med en advarsel i serverloggen. En udløsning uden krop opfører sig præcis som før.

API

Alle endpoints undtagen webhook-udløsningen kræver autentificering og virker kun på kalderens egne automatiseringer; webhook-udløsningen autentificerer i stedet med hemmeligheden pr. automatisering.

Metode	Sti	Formål
GET	/api/automations	Vis automatiseringer
POST	/api/automations	Opret en automatisering
GET	/api/automations/occurrences?from=&to=	Beregnede kommende forekomster
GET	/api/automations/runs	Kørselslog (kan filtreres)
GET	/api/automations/runs/summary	Usynligt antal + 30-dages grupper
POST	/api/automations/runs/seen	Markér afsluttede kørsler som set
GET	/api/automations/:automationId	Læs én automatisering
PUT	/api/automations/:automationId	Opdater en automatisering
DELETE	/api/automations/:automationId	Slet en automatisering
POST	/api/automations/:automationId/pause	Sæt tidsplanen på pause
POST	/api/automations/:automationId/resume	Genoptag tidsplanen
POST	/api/automations/:automationId/run	Kør nu (202 med kørsels-id)
POST	/api/automations/:automationId/webhook	Udløs via hemmelighed (202)
POST	/api/automations/:automationId/webhook-secret	Opret/rotér hemmeligheden
DELETE	/api/automations/:automationId/webhook-secret	Deaktivér webhooken

En bruger kan have op til 50 automatiseringer. Navne er begrænset til 200 tegn og instruktioner til 20.000.