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
2.1 KiB
Plaintext
36 lines
2.1 KiB
Plaintext
---
|
|
title: スケジュールタスク
|
|
description: プロンプトをスケジュールに従って自動実行します。
|
|
---
|
|
|
|
# スケジュールタスク
|
|
|
|
スケジュールタスクは、たとえば毎日の「昨日の変更を要約」や毎週の整理のように、指定したスケジュールでプロンプトを実行します。実行時には OpenChamber が新しいセッションを開始し、自動でプロンプトを送信します。セッションサイドバー上部のボタンからスケジューラーを開きます。
|
|
|
|
## タスクを作成する
|
|
|
|
1. セッションサイドバーからスケジュールタスクダイアログを開きます。
|
|
2. タスクを追加し、名前を付けます。
|
|
3. 実行タイミングを選びます。
|
|
- **daily** — 毎日 1 つ以上の時刻
|
|
- **weekly** — 選んだ曜日と時刻
|
|
- **once** — 1 回だけの日時
|
|
4. 実行内容を設定します。送信するプロンプト、使用するプロバイダー、モデル、エージェントです。プロンプトには `/review` のようなスラッシュコマンドも使えます。
|
|
5. 保存し、タスクが有効になっていることを確認します。
|
|
|
|
任意のタスクは **run now** ですぐ実行でき、期待通り動くか確認できます。
|
|
|
|
**ゴールとして実行**にチェックすると、実行は1回の返信で止まらず、プロンプトを完了まで追求します — [セッションゴール](/session-goals/)を参照してください。
|
|
|
|
## 成功時の見え方
|
|
|
|
実行後、タスクには最後に実行された時刻、成功したかどうか、作成されたセッションへのリンクが表示されます。実行に失敗した場合は、エラーもそこに表示されます。
|
|
|
|
## 注意点
|
|
|
|
タスクは OpenChamber サーバーが実行中の間だけ発火します。閉じると、サーバーが戻るまでスケジュール実行は一時停止します。
|
|
|
|
## 関連
|
|
|
|
- [コマンドとスニペット](/commands-snippets/) — スラッシュコマンドをプロンプトとして再利用する
|