Implementation brief

Recurring scheduled threads for T3 Code

A recurring task creates a fresh thread, sends its first workflow prompt, records the run, and keeps existing approval safeguards in place.

What was added

Recurrence rules

Weekly, fortnightly, and monthly schedules with timezone and daylight-saving handling.

SQLite persistence

Schedules, claimed occurrences, run status, thread IDs, and errors are stored durably.

Duplicate protection

A unique task/occurrence key makes claims atomic across retries and restarts.

Background scheduler

Due tasks are claimed, dispatched through existing orchestration, and marked successful or failed.

Authenticated API

Owners can list, create, update, disable, and inspect scheduled tasks and run history.

Settings surface

A minimal UI creates schedules, toggles them, and shows recent approval-gated runs.

How one run works

The scheduler finds an enabled task whose nextRunAt is due.
It coalesces any missed interval into one occurrence rather than replaying every missed run.
SQLite atomically claims that occurrence and advances the next run time.
The existing orchestration engine receives a thread.turn.start command with bootstrap metadata.
A new thread is created with the task prompt as its first user message.
The run history records the resulting thread ID, or records a failure if dispatch fails.

Safety default: scheduled tasks use approval-required unless explicitly configured otherwise. The scheduler does not grant broader permissions than the saved task configuration.

API surface

GET /api/scheduled-tasks — list the current owner’s tasks
POST /api/scheduled-tasks — create a validated task
PATCH /api/scheduled-tasks/:taskId — update or disable a task
DELETE /api/scheduled-tasks/:taskId — stop future runs
GET /api/scheduled-tasks/:taskId/runs — inspect run history

Read operations require the orchestration read scope. Mutations require the orchestration operate scope. Created threads are not deleted when a schedule is disabled.

Verification status

The feature is committed on the feat/scheduled-threads branch of the fork. The implementation includes focused tests for recurrence, persistence claims, and scheduler behavior. Full typechecking and Vitest execution still need to run in the repository’s required Node 24.13.1 environment; dependency installation was blocked in the available Node 22 environment.