feat(work): scheduled tasks under Work mode

[charlescook-ph]

Summary

Adds a Scheduled section to PostHog Work, on top of the existing TaskAutomation backend. Wires the sidebar's previously-static Automations entry into a real list + editor, with a non-engineer-friendly UX.

• Natural-language schedule field: type "every Tuesday at 5pm", "daily at 9am", "weekdays at 9am", "15th of the month at 8am", or raw cron. Live parse preview shows what you typed → "Tuesdays at 5pm". Save disabled when unparseable. Quick-fill chips below for common patterns.
• Data sources picker: chip multi-select pulling from the user's connected MCP servers via useMcpServers(), with brand icons. Selected sources are persisted as a [Sources: github, slack] prefix on the prompt (stopgap until the backend grows a first-class field).
• Curated examples in the empty state — Weekly competitive analysis, Daily meeting briefing, Customer feedback digest, Monthly metric review, Weekly product update — each prefills name + prompt.
• Last-run inline panel in the editor with "Open task" deep link that flips to Code mode and opens the spawned TaskRun.
• Status badge covers Paused / Healthy / Failed / Running / Cancelled / Active.

Plugs into the existing workView state in navigationStore (adds scheduled-list and scheduled-edit, plus matching nav actions). Pure additions to WorkSidebarMenu (renames "Automations" → "Scheduled", wires its click) and WorkView (new routing branches).

Known stopgaps

• repository: "posthog-work" sentinel is sent because the current TaskAutomation.repository field is required + non-blank. Backend ticket needed to make it nullable for Work-mode tasks.
• MCP source choice is stuffed into the prompt as a [Sources: …] header. Works today (agent treats it as advisory). Backend ticket needed for a first-class mcp_sources: string[] field.

Test plan

• In Work mode, click Scheduled in the sidebar — lands on an empty state with 5 clickable examples.
• Click an example — editor opens with name + prompt prefilled.
• Type "every Tuesday at 5pm" → see green "→ Tuesdays at 5pm". Type "blue chickens" → amber "couldn't understand" hint. Save disabled until parseable.
• Quick-fill chips fill the field with valid NL.
• Pick a couple of data sources — chips toggle, get persisted in the prompt header on save.
• Save → row appears in the list with the right schedule label + next-run time.
• Click row → editor reopens with everything (including selected sources) repopulated.
• Run now → toast, new TaskRun spawned; Open task swaps to Code mode and opens it.
• Delete → row gone after refetch.
• Toggle back to Home in the sidebar — sample-projects splash still works.
• Click any Skills sidebar item — skills flow still works (untouched).

[greptile-apps]

Comments Outside Diff (1)

1. apps/code/src/renderer/features/work/components/ScheduledTaskEditor.tsx, line 475-479 (link)

   User edits lost on every polling cycle

   existing is in the dependency array alongside existing?.id. Because useScheduledTasks refetches every 30 seconds, polling updates (e.g. last_run_at or last_run_status changing) produce a new object reference with the same id, causing the effect to fire and reset the draft — clobbering whatever the user has typed. The comment on the next line explicitly states only the id should trigger a reset, but the deps don't reflect that intent. Fix: use only [existing?.id] (or [editingId]).

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/features/work/components/ScheduledTaskEditor.tsx
   Line: 475-479
   
   Comment:
   **User edits lost on every polling cycle**
   
   `existing` is in the dependency array alongside `existing?.id`. Because `useScheduledTasks` refetches every 30 seconds, polling updates (e.g. `last_run_at` or `last_run_status` changing) produce a new object reference with the same `id`, causing the effect to fire and reset the draft — clobbering whatever the user has typed. The comment on the next line explicitly states only the `id` should trigger a reset, but the deps don't reflect that intent. Fix: use only `[existing?.id]` (or `[editingId]`).
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/work/components/ScheduledTaskEditor.tsx:475-479
**User edits lost on every polling cycle**

`existing` is in the dependency array alongside `existing?.id`. Because `useScheduledTasks` refetches every 30 seconds, polling updates (e.g. `last_run_at` or `last_run_status` changing) produce a new object reference with the same `id`, causing the effect to fire and reset the draft — clobbering whatever the user has typed. The comment on the next line explicitly states only the `id` should trigger a reset, but the deps don't reflect that intent. Fix: use only `[existing?.id]` (or `[editingId]`).

```suggestion
  // Sync the draft when the editor is pointed at a different existing automation.
  useEffect(() => {
    if (existing) setDraft(toDraft(existing));
    // The id is what should trigger a reset — other field changes from polling
    // shouldn't clobber user edits.
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [existing?.id]);
```

### Issue 2 of 3
apps/code/src/renderer/api/posthogClient.ts:183-190
**Type-unsafe double cast on the run endpoint body**

`{} as unknown as Schemas.TaskAutomation` is a double cast that bypasses TypeScript entirely. The `/run/` endpoint almost certainly does not require a `TaskAutomation` body; if it takes no body at all the `body` key can be omitted, or if the generated client requires some body shape it should match the actual schema type.

```suggestion
    const data = await this.api.post(
      `/api/projects/{project_id}/task_automations/{id}/run/`,
      {
        path: { project_id: teamId.toString(), id: automationId },
      },
    );
```

### Issue 3 of 3
apps/code/src/renderer/features/work/components/WorkHome.tsx:1-54
**Dead-code file — never rendered**

`WorkHome.tsx` is a new file added in this PR, but `WorkView.tsx` still imports `beachHog`, `WorkHomePrompt`, and `WorkSampleProjects` directly and renders the home content inline — its default branch is unchanged and never mounts `<WorkHome />`. This violates simplicity rule 4 ("has no superfluous parts"). Either update `WorkView`'s default branch to `return <WorkHome />;` and remove the duplicated inline JSX, or delete this file until the refactor is intentional.

_{Reviews (1): Last reviewed commit: "feat(work): add scheduled tasks UI to Wo..." | Re-trigger Greptile}

[greptile-apps]

Dead-code file — never rendered

WorkHome.tsx is a new file added in this PR, but WorkView.tsx still imports beachHog, WorkHomePrompt, and WorkSampleProjects directly and renders the home content inline — its default branch is unchanged and never mounts <WorkHome />. This violates simplicity rule 4 ("has no superfluous parts"). Either update WorkView's default branch to return <WorkHome />; and remove the duplicated inline JSX, or delete this file until the refactor is intentional.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/work/components/WorkHome.tsx
Line: 1-54

Comment:
**Dead-code file — never rendered**

`WorkHome.tsx` is a new file added in this PR, but `WorkView.tsx` still imports `beachHog`, `WorkHomePrompt`, and `WorkSampleProjects` directly and renders the home content inline — its default branch is unchanged and never mounts `<WorkHome />`. This violates simplicity rule 4 ("has no superfluous parts"). Either update `WorkView`'s default branch to `return <WorkHome />;` and remove the duplicated inline JSX, or delete this file until the refactor is intentional.

How can I resolve this? If you propose a fix, please make it concise.