feat(workflows): schedule workflows and inspect each occurrence's run

[Igloczek]

Closes #29 · Parent spec #3 · Stack layer 5/5 (base: #35 workflows/28-parallel-attention)

Problem

Scheduled workflow occurrences passed input straight to start and left no record linking an occurrence to its run. The existing Scheduled tasks controls couldn't select a workflow, and users couldn't see what each occurrence actually started.

What this adds

• Generic schedule-target contribution: WebPlugin.scheduleTargets adds a "Runs" choice (a prompt, or a plugin target) to Settings → Scheduled tasks. A target is offered only when the environment's catalog publishes it, and core scheduling imports no workflow code. Prompt schedules are unchanged.
• Workflow target:
  • Project, saved workflow ("Currently saved: revision N" plus runnable status and reasons), workspace, and a bounded task.
  • The editor states the truth about revisions: "Each occurrence starts the workflow as it is saved when that occurrence runs, not necessarily revision N."
  • No required-input contract is invented.
• Same start path as a manual start: each occurrence calls the shared saved-workflow start (startCatalog), keyed by its durable occurrence identity. It checks the stored result first, including legacy IDs, so redelivery or a lost ack gives one run and distinct occurrences give distinct runs. Permission ceilings and the pending-occurrence pipeline are unchanged. The host scheduler remains the only timing owner.
• Occurrence history (Run history):
  • Bounded (20 entries plus a "more" flag, never a fake total) and redacted like every other workflow read.
  • Each receipt is linked to its exact run under the project it was recorded in, so history survives project edits.
  • Dispatch status (pending, dispatched, failed) is shown separately from workflow status (running, needs your decision, completed, …).
  • Revisions come from each run's own snapshot. A recreated schedule ID does not inherit old receipts.
  • Open run is withheld when that project no longer exists.
• Plugin removal: the row stays saved and shows an actionable "unavailable" state. Timing, pause, and delete still work, and history returns when the plugin returns. Host edits no longer echo dispatchTarget; the server keeps the stored one.
• Docs: "Schedule a workflow" in docs/user/workflows.md, plus docs/user/project-settings.md.

Validation

• Server (Bun):
  • WorkflowsScheduling.integration.test.ts covers:
    • two authenticated environments
    • create, edit, pause, run-now
    • redelivery, and a dispatch cut off after commit
    • revision changes between occurrences, and restart
    • project relocation keeping run links; delete and recreate starting with empty history
    • plugin removed → edit timing → reinstall → run-now
    • prompt schedules alongside workflow schedules
    • a scheduled run following the same thread, report, gate, and completion path as a manual start
    • a scheduled parallel review forking reviewer threads
  • WorkflowsCatalogRedaction covers schedule history with a known secret.
  • The Schedule, ScheduleCatalog, PluginScheduleReceipt, PluginScheduledCeiling, PluginDiscoveryAndSchedule, PluginHost, OrchestratorMcpToolkit, and ScheduledTaskService suites pass.
• Web:
  • WorkflowSchedule.integration.test.tsx covers the editor, history, Open run, the removed-project state, and the read-only and disconnected states.
  • PluginClientPermissions passes.
  • The unit tests in scheduleTargetLogic.test.ts use no mocks.
• Static checks: typecheck, lint, and fmt are clean for touched packages. The only exception is the pre-existing binCli.ts TS2345.

Independent review

Three rounds by a separate Claude Opus 5.5 reviewer. Fixed:

• history losing run links after a project edit
• unredacted history titles and reasons
• extra history re-reads
• a mock-heavy dialog test, replaced with pure logic plus a real-server check
• recreated IDs inheriting old receipts

Final verdict: APPROVED 5e8694119056373dd49a50c7cd562b14fddce3c2.

UI evidence

Real-browser verification is pending; the T3 Browser panel was unavailable.

Limitations

• Plugin targets support "At a time" and "Every interval" only; webhook triggers stay prompt-only.
• Runs left behind in a project the schedule moved away from refresh only when the schedule row changes, the dialog reopens, or the user presses Refresh.
• The occurrence history read filters receipts by task_id without a dedicated index (capped, dialog-only). A migration was deliberately avoided.
• Pre-existing, not changed here: the core scheduledTasks.upsert RPC accepts dispatchTarget (including dispatchLimits) from operate-scoped callers. This predates the stack and is worth a separate issue.

Implemented by Claude Opus 5.5 implementation agents and reviewed by an independent Claude Opus 5.5 agent (gilfoyle), orchestrated in Claude Code running in T3 Code.

🤖 Generated with Claude Code