Support scheduled tasks end to end

[boycez]

Summary

Support scheduled tasks as a complete end-to-end MicroClaw experience. Users should be able to create, review, edit, enable or pause, run, and delete scheduled agent tasks without editing OpenClaw configuration outside the app.

This feature requires both experience design and technical implementation. The workflow should make common schedules approachable while retaining enough detail and control for advanced users.

Current experience

MicroClaw already has a read-only Scheduled Tasks view. It calls cron.list and displays the task name, schedule expression, target agent, enabled state, and last run. The empty state tells users to configure tasks in OpenClaw, but there is no in-app creation or management flow.

The current integration is list-only across the full stack:

• desktop/renderer/src/views/TasksView.vue renders the list and refresh state.
• desktop/renderer/src/stores/tasks.ts maps cron, at, and every schedules into display rows.
• desktop/renderer/env.d.ts, desktop/src/preload.ts, desktop/src/main.ts, and desktop/src/gateway-client.ts expose only cron.list.

End-to-end experience design

Design the complete task lifecycle, including:

• A clear entry point and useful empty state with a primary Create task action.
• A create/edit flow for task name, agent, instructions or prompt, schedule, and enabled state.
• Human-friendly options for one-time and recurring schedules, with an advanced cron option where appropriate.
• Localized schedule summaries, time zone visibility, validation, and the next expected run time before saving.
• List or detail actions to run now, pause or resume, edit, and delete with appropriate confirmation.
• Execution feedback: last run, next run, status, errors, and access to useful run history or resulting conversation/output.
• Clear offline, gateway-disconnected, loading, empty, permission, and failure states.
• Consistent behavior in English and Chinese, light and dark themes, and supported desktop window sizes.

The design should define whether task results appear in an existing agent conversation, a dedicated task history, notifications, or a combination of these.

Technical implementation

• Confirm the OpenClaw cron API contracts and supported schedule kinds for create, update, enable/disable, run, delete, status, and history operations.
• Add typed GatewayClient methods and corresponding main-process IPC, preload APIs, and renderer type declarations.
• Extend the Pinia task store with normalized task models, mutations, per-action loading/error states, refresh behavior, and stale-data handling.
• Implement the creation, editing, lifecycle actions, schedule validation, and execution details in the renderer.
• Preserve IDs and server-owned fields correctly; avoid reconstructing jobs from display-only values.
• Handle gateway reconnects and externally modified jobs without duplicating or losing task state.
• Add localization, accessibility, telemetry/logging as appropriate, and automated coverage at the store, IPC/client, and UI boundaries.

Acceptance criteria

• A user can create a valid one-time or recurring scheduled task entirely within MicroClaw.
• A user can inspect, edit, enable or pause, run now, and delete an existing task.
• The UI shows an understandable schedule, time zone, next run, last result/status, and actionable errors.
• Changes remain consistent after app restart, gateway restart, and refresh.
• Invalid schedules and incomplete task definitions cannot be saved and provide clear corrective guidance.
• Gateway-disconnected and partial-failure scenarios do not leave the UI in a misleading state.
• Existing externally configured OpenClaw jobs remain visible and manageable when supported by the API.
• Core create/update/delete/run flows have automated coverage, including failure paths.
• The experience is localized in English and Chinese and reviewed in light and dark themes.

Open design and product questions

• Which schedule presets and recurrence patterns are required for the first release?
• Which time zone owns execution, and how should daylight-saving transitions be communicated?
• Where should task output and run history live, and how should users be notified of completion or failure?
• Should task creation be available only from Scheduled Tasks, or also from chats and agent quick tasks?
• What confirmation or permission model is required for tasks that can access files, external apps, or message channels while unattended?