Bohdan Triapitsyn
bb45164ae8
Arm the target button in the composer and the next prompt becomes a goal: the server keeps the session working toward it (idle tick -> small-model audit -> continuation) until the objective is verifiably complete, blocked, or out of budget — even with the UI closed. Server (packages/web/server/lib/session-goal): - event-driven loop on the global SSE hub; goal state lives in session.metadata.openchamber.goal (merge-safe patches, stale-write guard by goal id), so it survives restarts and syncs to every client for free - the small-model audit (objective + last assistant turn only, language pinned to the objective) is the sole termination authority; blocked needs 3 consecutive verdicts, audit outages tolerate one unaudited continuation then stop the goal as resumable-blocked - hard stops: optional token budget, auto-continuation cap (Resume grants a fresh allowance), turn errors; user abort pauses the goal instead of blocking it, and resuming over an aborted tail nudges immediately - token accounting as a snapshot of the latest turn (input + cache.read + output), goal-relative via a creation baseline and segmented across compactions; a compaction summary skips the audit and continues - continuations reuse the session's own provider/model/agent/variant UI: - three-mode target button (arm / disarm / manage dialog), informational goal strip with inline pause/resume and an Evaluating indicator, sidebar state glyph, objective length counter (2000-char server clamp), read-only completed goals - goal entry points: composer (sessions and drafts), start-new-session- from-answer dialog, plan implement dialog (plan content becomes the objective), scheduled tasks (Run as goal + budget) - Settings -> Chat -> Goal: feature toggle + default token budget with three-layer parity (web server, client persistence, VS Code bridge); VS Code renders goal state but hides the entry points (the loop runs in the web server only) Notifications: per-turn "ready" notifications are suppressed while a goal is active; settling sends one final notification (desktop, web-push, APNs generic titles with the session name as body) honoring the completion toggle. Error/question/permission notifications are untouched. Docs: user guide (session-goals) in all 9 locales + sidebar entry, scheduled-tasks cross-reference, server module DOCUMENTATION.md.
36 lines
1.9 KiB
Plaintext
36 lines
1.9 KiB
Plaintext
---
|
||
title: Tâches planifiées
|
||
description: Lancez automatiquement un prompt selon un planning.
|
||
---
|
||
|
||
# Tâches planifiées
|
||
|
||
Une tâche planifiée lance un prompt pour vous selon un planning — par exemple un « résume les changements d’hier » quotidien ou un nettoyage hebdomadaire. Quand elle s’exécute, OpenChamber démarre une nouvelle session et envoie le prompt tout seul. Ouvrez le planificateur depuis le bouton en haut de la barre latérale des sessions.
|
||
|
||
## Créer une tâche
|
||
|
||
1. Ouvrez la boîte de dialogue des tâches planifiées depuis la barre latérale des sessions.
|
||
2. Ajoutez une tâche et donnez-lui un nom.
|
||
3. Choisissez quand elle s’exécute :
|
||
- **daily** — à une ou plusieurs heures chaque jour
|
||
- **weekly** — certains jours de la semaine et à certaines heures
|
||
- **once** — une seule date et heure
|
||
4. Définissez ce qu’elle fait : le prompt à envoyer, ainsi que le fournisseur, le modèle et l’agent à utiliser. Le prompt peut être une commande slash, comme `/review`.
|
||
5. Enregistrez, puis vérifiez que la tâche est activée.
|
||
|
||
Vous pouvez lancer n’importe quelle tâche immédiatement avec **run now** pour vérifier qu’elle fait ce que vous attendez.
|
||
|
||
Cochez **Exécuter comme objectif** pour que l'exécution poursuive son prompt jusqu'au bout au lieu de s'arrêter après une réponse — voir [Objectifs de session](/session-goals/).
|
||
|
||
## À quoi ressemble une réussite
|
||
|
||
Après une exécution, la tâche indique quand elle a tourné pour la dernière fois, si elle a réussi et un lien vers la session créée. Si une exécution échoue, l’erreur s’affiche aussi à cet endroit.
|
||
|
||
## À garder en tête
|
||
|
||
Les tâches ne se déclenchent que lorsque le serveur OpenChamber tourne. Si vous le fermez, les exécutions planifiées sont en pause jusqu’à son retour.
|
||
|
||
## Pages liées
|
||
|
||
- [Commandes et snippets](/commands-snippets/) — réutiliser une commande slash comme prompt
|