scheduling

name

scheduling

description

Work on the scheduling system — sch_* tables, /schedules user UI, /administration/scheduling admin UI, the matrx-scheduler Python package, and the aidream /scheduling/* router. Triggers on any of: editing files under `features/scheduling/**`, `app/(authenticated)/schedules/**`, `app/(authenticated)/(admin-auth)/administration/scheduling/**`, `lib/services/scheduling-admin-service.ts`, `migrations/sch_*.sql`; or, in the aidream repo, files under `packages/matrx-scheduler/**`, `aidream/api/routers/scheduling.py`, `aidream/services/scheduling/**`; or any task mentioning sch_task, sch_trigger, sch_run, cron parser, scheduled agent, lease, claim, heartbeat task, scanner.

Scheduling

Cross-repo scheduling spine. Three live systems share four Supabase tables (sch_task, sch_agent_task, sch_trigger, sch_run):

• matrx-frontend — control plane (this repo). Users create/observe.
• aidream + matrx-scheduler — server-side executor.
• matrx-extend (Chrome extension) — browser-context executor for context-match triggers.

Spec: docs/SCHEDULING.md. FEATURE doc: features/scheduling/FEATURE.md.

---

30-second mental model

sch_task           kind='agent' (today). Spine: title, surfaces[], next_due_at.
  ↳ sch_agent_task   1:1 extension: agent_id, prompt, variables, conversation_id.
sch_trigger        when it fires. v1 = one trigger per task.
sch_run            each execution attempt. Lease via claim_token + claim_expires_at.

RLS: owner-or-is_super_admin() on all four tables. Service_role is NEVER used for user-initiated writes; admin pages use the regular browser client and rely on RLS for cross-user reads.