Propose, never silently activate
Chat and the form create a disabled draft. Neither may approve authority, widen access, or enable execution.
Draft proposal · complete experience
Scheduled work that stays reviewable, bounded, and honest.
First-class Scheduled Tasks let a user describe recurring agent work, review the exact task and authority, test it in a fresh session, enable it, inspect durable results, repair denied access, and pause it—without turning OpenWork into a general workflow platform.
◷ Scheduled tasks run while OpenWork is running.
22 / 22visual evidence frames passed
7 / 7end-to-end journey steps passed
319e15bd3exact captured revision
Draftnot manually confirmed by requester
The product promise
OpenWork owns scheduling, authority, persistence, claims, receipts, and user experience. The agent engine is a replaceable execution adapter that receives only the reviewed request.
Review definition and authority separately
One immutable task revision and one immutable grant revision are bound to every unattended run.
Deliver normal OpenWork results
Every attempt creates a fresh session, durable receipt, timeline, bounded usage, and verified artifact references.
→
Ownership and execution path
Describe or edit
Exact prompt, workspace, schedule, timezone, model, timeout.
Persist revision
Disabled draft with five-occurrence preview.
Review grant
Roots, capabilities, filesystem, ceiling, fixed denials.
Claim once
Atomic occurrence identity, no overlap, bounded retry.
Fresh session
Normalized status, cancellation, artifacts, honest terminal outcome.
Deliberate boundary: no cloud scheduler, OS background daemon, or closed-app execution is claimed.
The running-app limitation appears in creation, detail, and every list card.
The complete journey
Every frame below came from the real Hub-isolated Electron app against the exact revision above. Select any image to inspect it at full resolution.
1
Discover and create
First-class workspace destination
Honest empty state, creation entry, and running-app limitation.
Workspace and exact definition
Name, description, self-contained prompt, frequency, timezone, and disabled-save semantics.
Schedule and execution preview
Five server-calculated occurrences plus provider, model, agent, timeout, overlap, missed-run, retry, and safety policy.
Natural language stays disabled
The visible receipt is disabled, review-required, and cannot carry an authority grant.
2
Review and authorize
Exact task before execution
Prompt, daily wall-clock schedule, timezone, next five, workspace defaults, timeout, and edit/duplicate/delete controls.
Every save is a new revision
Editing explicitly warns that the new draft must be reviewed again before unattended work.
Creation is not permission
Workspace roots, capability IDs, action classes, read/write scope, reviewer, and fixed denials are independently visible.
Reviewed does not mean enabled
The exact read/write grant is durable and revocable; communication, destructive action, and self-modification remain denied.
3
Test, inspect, and receive results
Run once with cancellation
Manual trigger, live status, revision binding, claimed timeline, bounded usage, and Cancel run.
Immutable, linked outcome
Terminal status, duration, attempts, task/grant revisions, session link, artifact, and claimed/started/completed times.
The normal transcript is the record
The receipt opens the exact fresh session; there is no separate automation transcript system.
Activation stays separate
After review, Enable produces a precise next run while Run once and Pause remain available.
Exactly one occurrence
The due boundary creates one scheduled run in a fresh session; repeating the same tick creates no duplicate.
Completion reaches the user
The persistent notification center offers a direct View action back to the task.
Durable across relaunch
Definition, grant, receipts, next occurrence, and idempotency state survive restart without replay.
Upcoming at a glance
Cards summarize state, schedule, next run, latest outcome, Open action, and the running-app limitation.
4
Fail closed, repair, resume, and pause
Denied unattended work stops
A write attempted under read-only authority becomes repairable needs-attention instead of borrowing interactive approval.
Repair signal is persistent
The owner receives an attention notification with a direct View path.
Review a new grant revision
The owner restores exact write capability and filesystem scope before Resume becomes available.
Resume clears attention
The task returns to Enabled and receives a newly calculated next occurrence.
Pause blocks real due work
After pause, advancing to a genuinely due occurrence does not claim a run; Run once and Resume remain explicit.
Paused and still auditable
The overview moves it to Drafts and recent while preserving schedule, latest run, and limitation.
Every state and control
The primary journey proves the critical transitions. The complete product contract also defines the non-happy-path states and recovery behavior below.
| State | What the user sees | Allowed recovery / action | Evidence |
|---|---|---|---|
| Loading | Dedicated loading copy while capabilities, list, or detail resolve. | Wait; no unsafe optimistic controls. | UI contract |
| Unavailable | Server upgrade/restart or connection guidance when Scheduled Tasks are unsupported. | Reconnect, upgrade, or restart the owning server. | UI contract |
| Inaccessible workspace | Honest workspace access error; no execution. | Restore workspace/connection access. | Server + UI contract |
| Empty | Natural creation entry and running-app limitation. | New Scheduled Task or chat proposal. | Frame 01 |
| Draft / disabled | Exact definition, five occurrences, Run once/Enable disabled until grant review. | Edit, duplicate, delete, review authority. | Frames 04–07 |
| Stale / review required | An edit made elsewhere or a new revision invalidates prior review. | Refresh, inspect latest revision, review again. | Revision contract |
| Reviewed / ready | Reviewed grant badge; task remains disabled. | Run once, enable, revoke authority. | Frame 08 |
| Enabled / upcoming | Precise next run, schedule preview, Pause and Run once. | Wait, test manually, edit, pause, revoke. | Frames 12, 16 |
| Queued / running / retrying | Trigger, live status, attempt count, bounded usage, revision binding, timeline, Cancel run. | Cancel; scheduler prevents overlap. | Frame 09 |
| Needs attention | Task-level alert, run receipt error, notification, no inherited approval. | Repair workspace/capability/grant, review, Resume—or Pause. | Frames 17–20 |
| Paused | No next run is claimed; Run once and Resume remain explicit. | Resume after review or keep paused. | Frames 21–22 |
| Completed | Duration, attempts, bounded usage, revision and idempotency binding, session, artifact, timeline. | Open session/artifact; run again. | Frames 10, 13–15 |
| Failed / cancelled / ambiguous | Typed, bounded terminal error; ambiguous outcomes remain honest. | Inspect receipt/session, repair if required, rerun intentionally. | Service + receipt contract |
| Deleted | Task leaves active UI; server history remains auditable. | Deletion requires explicit confirmation. | Control contract |
⌁
Control semantics
| Control | Contract | Safety consequence |
|---|---|---|
| New / chat proposal | Creates one workspace-scoped disabled draft. | Never approves or enables. |
| Preview next five | Uses the same server scheduler as real runs. | Timezone and DST behavior cannot drift from execution. |
| Edit | Saves a new immutable task revision. | Prior review cannot silently cover changed work. |
| Duplicate | Creates a separate disabled task identity. | No grant or enabled state is silently inherited. |
| Delete | Requires confirmation; removes the active task. | Run history remains auditable on the server. |
| Approve / revoke authority | Creates or revokes an immutable grant revision. | Execution rechecks the grant server-side. |
| Run once | Creates one manual occurrence and fresh session. | Uses the same reviewed revision/grant boundary as scheduled work. |
| Enable | Activates a reviewed non-manual schedule. | Separate from review; computes the next occurrence. |
| Pause / Resume | Stops or restarts future claims. | A due tick while paused creates no run. |
| Cancel run | Requests cancellation through the execution adapter. | Outcome is retained honestly if engine termination is ambiguous. |
| Open session / artifact | Resolves the exact receipt-bound result. | Artifacts are run-scoped and canonical-path contained. |
Authority, scheduling, and threat boundaries
The feature is intentionally narrower than a workflow engine. Its useful power comes from explicit, durable boundaries rather than broad unattended permission.
Reviewed grant contains
- Workspace identity and authorized workspace roots.
- Capability IDs and allowed action classes.
- Filesystem read/write scope.
- Maximum runtime and model/agent selection.
- Grantor, review time, expiry, and revocation state.
Always denied in this proposal
- External communication and destructive operations.
- Changing its own task, schedule, grant, or enabled state.
- Path escape, unverified artifact access, or secret persistence.
- Borrowing another session’s approval for unattended work.
- Running after sign-out, workspace loss, capability loss, or revoked grant.
Exact scheduling behavior
- Manual, daily, and weekly schedules; no advanced cron.
- IANA timezone with DST-aware wall-clock calculation.
- Five-occurrence preview from the real scheduler.
- Default no-overlap behavior and maximum runtime.
- One bounded retry: at most two attempts.
- No catch-up storm; at most one missed occurrence is manually recoverable.
Claim and restart guarantees
- Atomic identity across task revision and scheduled occurrence.
- Repeated deterministic ticks do not duplicate an occurrence.
- Restart replay does not duplicate an occurrence.
- Definitions, grants, occurrences, attempts, receipts, sessions, errors, and artifacts are durable.
- Pause prevents a genuinely due claim.
Receipt and result delivery
OpenWork does not create a parallel transcript system. The receipt is an audit index into normal OpenWork sessions and artifacts.
Identity
Task revision, grant revision, scheduled occurrence, claimed time, attempt ID, idempotency key, and fresh session ID.
Outcome
Final status, duration, bounded usage, attempt count, retry state, cancellation, attention, typed error, or honest ambiguity.
Delivery
Exact session link, downloadable receipt-verified file references, live timeline, and persistent completion/failure/attention notifications.
Verification and readiness
The complete coded journey passed on the final revision. This remains a draft because the requester has not manually confirmed the behavior.
Exact final evidence
✓22/22 Fraimz frames passed.
✓7/7 end-to-end journey steps passed.
✓Natural-language proposal, real manual run, fresh transcript, and real artifact verified.
✓Deterministic due tick, repeated tick, Electron relaunch, denial/repair, notification, resume, and pause verified.
✓Captured commit:
319e15bd394a3d2fea4d548ecd4f1f951d703df5.Prior level-3 evidence retained
✓56 scheduled server contract, migration, schedule/DST, persistence, claim, retry, cancellation, grant, loss, and adapter tests.
✓26 post-hardening adapter and affordance regression tests / 136 assertions.
✓484 app tests, app/server/eval typechecks, production builds, syntax checks, diff check, and clean merge-tree check.
!Manual requester confirmation has not happened; the PR intentionally remains draft.
Migration, rollback, and non-goals
The change is additive and deliberately avoids irreversible ownership or platform promises.
Migration and rollback
Feature-local openwork_scheduled_task_* tables are added to the existing runtime SQLite database. Existing workspace/session data is not rewritten.
Reverting removes route/scheduler/UI registration while leaving records intact for a future compatible build. No destructive down migration runs automatically; operational rollback should preserve runtime.sqlite.
Explicit non-goals
No general workflow graph, arbitrary code DSL, webhook/event/file/email triggers, multi-agent DAG, template marketplace, cloud scheduler, OS background service, closed-app execution, organization-wide automation administration, or automatically authorized external communication.
Strings use a complete English fallback across locale bundles; native translations are follow-up work.