Replace workflows and scheduled prompts with project-bound routines #576

New issue

Closed

opened 2026-08-28 17:40:51 +02:00 by dries · 0 comments

dries commented

2026-08-28 17:40:51 +02:00

Owner

Problem Statement

Ocman currently exposes two overlapping automation concepts: heavyweight DAG-based Workflows and project-level Scheduled Prompts. The intended product model is simpler: users need named, project-bound prompts that execute from a schedule and can also be invoked explicitly by a user or another coding agent. Workflows are no longer wanted, while Scheduled Prompts are hidden inside Project Detail, unnamed, lack durable per-invocation history, and cannot be discovered or triggered through MCP.

Users need one clear automation concept—Routine—with a dedicated main-menu experience, durable scheduling, local and remote project ownership, explicit invocation, and an additive trigger model that can support webhooks later without implementing them now.

Solution

Replace Workflows and Scheduled Prompts with Routines.

A Routine is a named prompt bound to exactly one project on one machine. It has exactly one configured trigger (once, interval, or cron), a timezone where relevant, an enabled flag, and a session mode (fresh or reuse). Automatic scheduling, UI Run now, and MCP invocation all execute the same Routine through one backend service and record a durable Routine Run.

Add Routines as a main-menu destination showing local and connected-remote projects together. Users can filter, create, edit, delete, enable or disable, run immediately, inspect the next run and last result, open linked sessions, and inspect run history. Agents can list, inspect, trigger, and inspect runs through MCP, but cannot author or mutate Routine definitions.

Migrate every existing Scheduled Prompt into an equivalent Routine. Remove all active Workflow/Dagu runtime, API, MCP, UI, examples, installed skill, documentation, and command surfaces. Preserve historical Workflow database tables and migrations as inert data; do not convert Workflow definitions or runs into Routines.

User Stories

As an ocman user, I want Routines in the main menu, so that automation is a first-class feature rather than buried in a project page.
As an ocman user, I want one automation concept, so that I do not have to choose between Workflows and Scheduled Prompts.
As an ocman user, I want every Routine bound to one project, so that its prompt executes in the correct repository context.
As a multi-remote user, I want each Routine bound to a machine as well as a project, so that execution occurs on the project-owning host.
As an ocman user, I want to see local and connected-remote Routines together, so that I can manage automation from the hub.
As an ocman user, I want to filter Routines by project and machine, so that a global list remains manageable.
As an ocman user, I want every Routine to have a required name, so that I can recognize and reference it.
As an ocman user, I want Routine names unique within a project, so that similarly named automation is unambiguous.
As an ocman user, I want a stable Routine ID, so that renaming does not break external references.
As an ocman user, I want to create a Routine with a prompt, trigger, timezone, and session mode, so that its execution is fully defined.
As an ocman user, I want one-time triggers, so that I can schedule a prompt for a specific future time.
As an ocman user, I want interval triggers, so that I can run a prompt repeatedly at a simple cadence.
As an ocman user, I want five-field cron triggers, so that I can express calendar schedules.
As an ocman user, I want cron evaluated in an explicit IANA timezone, so that schedules retain their wall-clock meaning across hosts and daylight-saving changes.
As an ocman user, I want invalid trigger configuration rejected before saving, so that a Routine cannot silently become unschedulable.
As an ocman user, I want to edit a Routine, so that future invocations use an updated prompt or schedule.
As an ocman user, I want to disable automatic firing without deleting a Routine, so that I can pause automation temporarily.
As an ocman user, I want Run now to work even while a Routine is disabled, so that disabling a schedule does not prevent deliberate invocation.
As a coding agent, I want to invoke an existing Routine through MCP, so that one agent can initiate predefined project automation.
As a coding agent, I want to list and inspect Routines through MCP, so that I can discover valid targets before invoking one.
As a coding agent, I want to inspect Routine Runs through MCP, so that I can determine whether dispatch succeeded and find the resulting session.
As an operator, I want agents prevented from creating or editing Routines through MCP, so that persistent automation remains user-authored.
As an ocman user, I want fresh-session mode, so that every invocation receives an isolated coding-agent session.
As an ocman user, I want reuse-session mode, so that repeated invocations can retain one Routine-owned conversation.
As an ocman user, I want prompts queued durably when a reused session is busy, so that concurrent firing does not lose work or race the active turn.
As an ocman user, I want each fresh-mode firing to create an independent session, so that one active run does not block another.
As an ocman user, I want each invocation recorded as a Routine Run, so that I can audit what was dispatched.
As an ocman user, I want a Routine Run to record its source (schedule, ui, or mcp), so that I know why it happened.
As an ocman user, I want a Routine Run to link to its created or reused session, so that I can inspect the agent's work.
As an ocman user, I want dispatch failures recorded with an error, so that failed automation is visible.
As an ocman user, I want a run considered dispatched when the platform accepts its prompt, so that ocman does not pretend to track the full agent-turn lifecycle.
As an ocman user, I want recurring Routines to remain enabled after one dispatch failure, so that transient failures do not permanently stop automation.
As an ocman user, I want failed one-time Routines to remain inspectable and manually runnable, so that I can retry deliberately.
As an ocman user, I want at most one catch-up firing after downtime, so that missed schedules do not flood agents.
As an ocman user, I want the scheduler to advance to the next future occurrence after catch-up, so that normal cadence resumes.
As an ocman user, I want archived projects and archived reused sessions skipped as they are today, so that automation does not unexpectedly revive archived work.
As an ocman user, I want to delete a Routine after confirmation, so that obsolete automation and its history can be removed.
As an ocman user, I want deleting a Routine to leave coding-agent sessions untouched, so that execution evidence is not destroyed indirectly.
As an existing Scheduled Prompts user, I want all records migrated automatically, so that upgrading does not lose automation.
As an existing Scheduled Prompts user, I want prompt, project owner, timing, timezone, enabled state, session mode, linked reusable session, and operational state preserved, so that migrated behavior remains equivalent.
As an existing Scheduled Prompts user, I want a deterministic generated name, so that unnamed records become valid Routines without manual repair.
As an existing Scheduled Prompts user, I want generated-name collisions resolved deterministically, so that migration succeeds for similar prompts.
As an operator, I want migration to be idempotent, so that retries and repeated startup cannot duplicate Routines.
As an operator, I want interrupted dispatches recovered without automatic duplicate prompt delivery, so that restart safety favors auditability over repeated side effects.
As an operator, I want historical Workflow tables left intact, so that upgrading does not destructively erase old data.
As an ocman user, I want Workflow UI and navigation removed, so that the retired concept is no longer presented.
As an operator, I want Workflow APIs, MCP tools, runner integration, and installed skills removed, so that retired code cannot continue executing.
As a maintainer, I want Dagu-specific dependencies and the workflow-step command removed when no longer referenced, so that the binary and maintenance surface shrink.
As a maintainer, I want Workflow examples and product documentation removed or rewritten, so that documentation matches the product.
As a maintainer, I want architecture documentation updated, so that diagrams and prose show Routines rather than the retired Workflow subsystem.
As a future implementer, I want trigger representation to be typed and validated, so that a webhook trigger can be added additively later.
As an ocman user, I want webhook behavior clearly marked unavailable, so that the UI and API do not imply support that does not exist.

Implementation Decisions

Canonical model: A Routine is project + name + prompt + one trigger + enabled state + session mode. It is not a DAG, does not contain nodes or dependencies, and does not invoke another Routine as an internal graph operation.
Project ownership: Store both canonical project directory and owner remote ID. Resolve and execute through the existing owner-routing and managed OpenCode seams; explicit unknown/disconnected remote owners fail closed.
Identity: Use an immutable opaque Routine ID. Require a non-empty display name unique within one (remote, project) scope.
Trigger model: Represent the configured trigger as a validated typed value with type-specific configuration. Implement only once, interval, and five-field cron; preserve explicit IANA timezone handling. The representation must permit a later additive webhook type, but no webhook placeholder UI, endpoint, secret, or receiver is built now.
Invocation channels: The configured trigger governs automatic execution. UI Run now and MCP invocation are explicit channels, not additional configured triggers, and may invoke a disabled Routine.
Single execution service: Scheduler, REST handlers, and MCP tools must call one Routine service for validation, invocation, state transitions, and run recording. Do not duplicate dispatch logic in adapters.
Session modes: Fresh mode creates a new session for each invocation. Reuse mode creates and remembers a Routine-owned session on first execution, then uses the existing durable follow-up queue when that session is busy.
Run semantics: Create one durable Routine Run per invocation attempt. Record Routine ID, source (schedule, ui, mcp), timestamps, dispatch status, platform/session link when known, and error text. dispatched means the platform accepted the prompt; the run does not follow the later agent turn to completion.
Definition snapshots: A run should retain enough prompt/trigger identity to explain what was dispatched even if the Routine is edited later; keep this minimal and avoid a general immutable-version subsystem.
Atomicity: Claim automatic firings and create run records atomically enough that concurrent scheduler ticks cannot dispatch the same due occurrence twice. Explicit invocations each represent one intentional run.
Restart recovery: A run left in dispatching state after restart is marked failed/interrupted and is not automatically redelivered, because duplicate agent side effects are worse than a visible missed dispatch.
Scheduling: Reuse the current durable scheduler behavior and cron library. After downtime, fire no more than once for an overdue recurring Routine and calculate its following time strictly in the future. Do not replay every missed interval.
Failures: Record all failures. Recurring Routines remain enabled and advance to the next occurrence after a dispatch failure. A failed one-time Routine remains available for explicit Run now/MCP retry but has no future automatic occurrence.
Archived work: Preserve current behavior that does not automatically dispatch into archived projects or archived reused sessions. Explicit invocation must return a clear error rather than silently doing nothing where the current ownership/archive policy disallows execution.
CRUD API: Add localhost-protected REST operations for global/project-filtered listing, creation, retrieval, update, deletion, enablement, explicit invocation, and paginated run history. Responses expose next run, last dispatch result, and linked session details needed by the UI. Validate all project, trigger, name, and session-mode inputs at the trust boundary.
MCP API: Add tools to list Routines, inspect one Routine, invoke one Routine, and list its runs. Do not expose create, update, enable/disable, or delete tools. MCP invocation records source mcp; no verified caller-agent identity is claimed because the transport does not provide one.
Main-menu UI: Replace the Workflows navigation destination with Routines. The page combines local and connected-remote records and supports project/machine filters, create/edit/delete, enable/disable, Run now, next-run display, last result/error, linked session navigation, and per-Routine history. Use existing accessible controls and stable test locators.
Project UI: Remove the Scheduled Prompts editor/list from Project Detail; the global Routines page is the authoring surface. Project-filtered deep links are acceptable when they reuse that page rather than recreate the component.
Deletion: Confirm destructive deletion, then delete the Routine and its Routine Run records. Never archive or delete coding-agent sessions created or reused by it.
Scheduled Prompt migration: Introduce an idempotent state migration that converts every existing Scheduled Prompt. Preserve its ID, owner/project, prompt, timing configuration, timezone, enabled state, session mode, linked platform/session, timestamps, and meaningful operational state. Generate a short name from the prompt's first non-empty line and append a deterministic suffix for collisions. Preserve enough previous completion/failure information as migrated run/history state where available.
Workflow retirement: Remove active Workflow service/runtime, scheduler, dispatcher/compiler integrations, REST endpoints, MCP tools, frontend pages/stores/types/routes, installed workflow skill, examples, Dagu integration, workflow-step command, user documentation, marketing references, and now-unused dependencies. Remove tests that only assert retired behavior.
Historical Workflow data: Keep existing Workflow schema migrations and tables untouched and inert. New runtime code must not read or execute them. Do not migrate Workflow definitions, versions, runs, attempts, artifacts, or migrated legacy loops into Routines.
Legacy loop data: Existing historical loop-to-workflow migration remains valid upgrade history. Do not revive loop tables or runtime behavior.
Documentation: Update feature docs, MCP tool documentation, repository guidance, architecture diagrams/prose, and user-facing navigation/marketing copy. Avoid changing unrelated CI files whose paths happen to contain the word “workflow.”
Events and polling: Reuse the simplest existing frontend refresh mechanism unless an existing generic change event already fits. Do not add a Routine-specific streaming subsystem solely for this feature.

Testing Decisions

Tests assert externally visible behavior and durable state transitions, not private helper structure.
The primary seam is a Routine service integration test using fake time, a fake store or real temporary state database as appropriate, and fake session dispatch. Cover validation, each trigger, next-run calculation, timezone behavior, disabled explicit invocation, fresh/reuse dispatch, queue delegation, atomic claiming, one-run catch-up, failure advancement, restart recovery, deletion, and run provenance.
Migration tests start from a database containing representative Scheduled Prompts in once/interval/cron, enabled/disabled, fresh/reuse, completed/failed/canceled, local/remote, and collision cases. Verify equivalent Routines, deterministic names, preserved links/state, idempotency, and no mutation of historical Workflow tables.
HTTP integration tests cover CRUD, filtering, owner resolution/fail-closed remote behavior, enablement, Run now, validation errors, deletion, and run-history responses through the existing server test seam.
MCP tests cover list, inspect, invoke, and history operations and prove authoring/mutation tools are absent. Verify MCP and REST invocation produce the same service behavior with different provenance.
Frontend page tests exercise the Routines page as a user: navigation, global/project/machine filtering, create/edit/delete confirmation, enable/disable, Run now while disabled, status/error presentation, history, and session links.
A navigation smoke test proves Routines is present and Workflow/Scheduled Prompt product surfaces are absent.
Removal verification includes compilation/guard tests proving no active Workflow/Dagu runtime, route, MCP registration, installed skill, or product navigation remains, while historical database migration tests still pass.
Maintain or increase Go and frontend line coverage under the repository coverage ratchet. New branches and migration paths require corresponding tests.

Out of Scope

Receiving, authenticating, configuring, or delivering webhook triggers.
Any trigger type beyond once, interval, and cron.
Converting Workflow definitions or run history into Routines.
Multi-step DAGs, dependencies, nodes, maps, joins, approvals, command execution, subworkflows, resource pools, leases, or artifacts.
Agents creating, editing, enabling, disabling, or deleting Routine definitions through MCP.
Tracking an agent turn through completion or interpreting its final response as the Routine Run result.
Verifying or persisting the identity of the specific agent that called MCP.
Replaying every schedule occurrence missed during downtime.
Deleting sessions when a Routine is deleted.
Adding a new event-streaming subsystem for Routine UI refresh.

Further Notes

This is intentionally a replacement, not a third automation system. The completed repository should present only Routines to users.
The existing Scheduled Prompt scheduler, remote-owner routing, managed session launch, reusable-session queue, cron/timezone handling, and archive checks are the closest reusable behavior.
The old Agent Loops implementation and Workflow subsystem are historical context only; do not revive their tables or broad orchestration model.
The implementation should prefer deletion and renaming over parallel compatibility layers. Keep compatibility only where required for database upgrades and preservation of existing Scheduled Prompts.

## Problem Statement Ocman currently exposes two overlapping automation concepts: heavyweight DAG-based Workflows and project-level Scheduled Prompts. The intended product model is simpler: users need named, project-bound prompts that execute from a schedule and can also be invoked explicitly by a user or another coding agent. Workflows are no longer wanted, while Scheduled Prompts are hidden inside Project Detail, unnamed, lack durable per-invocation history, and cannot be discovered or triggered through MCP. Users need one clear automation concept—**Routine**—with a dedicated main-menu experience, durable scheduling, local and remote project ownership, explicit invocation, and an additive trigger model that can support webhooks later without implementing them now. ## Solution Replace Workflows and Scheduled Prompts with Routines. A Routine is a named prompt bound to exactly one project on one machine. It has exactly one configured trigger (`once`, `interval`, or `cron`), a timezone where relevant, an enabled flag, and a session mode (`fresh` or `reuse`). Automatic scheduling, UI Run now, and MCP invocation all execute the same Routine through one backend service and record a durable Routine Run. Add Routines as a main-menu destination showing local and connected-remote projects together. Users can filter, create, edit, delete, enable or disable, run immediately, inspect the next run and last result, open linked sessions, and inspect run history. Agents can list, inspect, trigger, and inspect runs through MCP, but cannot author or mutate Routine definitions. Migrate every existing Scheduled Prompt into an equivalent Routine. Remove all active Workflow/Dagu runtime, API, MCP, UI, examples, installed skill, documentation, and command surfaces. Preserve historical Workflow database tables and migrations as inert data; do not convert Workflow definitions or runs into Routines. ## User Stories 1. As an ocman user, I want Routines in the main menu, so that automation is a first-class feature rather than buried in a project page. 2. As an ocman user, I want one automation concept, so that I do not have to choose between Workflows and Scheduled Prompts. 3. As an ocman user, I want every Routine bound to one project, so that its prompt executes in the correct repository context. 4. As a multi-remote user, I want each Routine bound to a machine as well as a project, so that execution occurs on the project-owning host. 5. As an ocman user, I want to see local and connected-remote Routines together, so that I can manage automation from the hub. 6. As an ocman user, I want to filter Routines by project and machine, so that a global list remains manageable. 7. As an ocman user, I want every Routine to have a required name, so that I can recognize and reference it. 8. As an ocman user, I want Routine names unique within a project, so that similarly named automation is unambiguous. 9. As an ocman user, I want a stable Routine ID, so that renaming does not break external references. 10. As an ocman user, I want to create a Routine with a prompt, trigger, timezone, and session mode, so that its execution is fully defined. 11. As an ocman user, I want one-time triggers, so that I can schedule a prompt for a specific future time. 12. As an ocman user, I want interval triggers, so that I can run a prompt repeatedly at a simple cadence. 13. As an ocman user, I want five-field cron triggers, so that I can express calendar schedules. 14. As an ocman user, I want cron evaluated in an explicit IANA timezone, so that schedules retain their wall-clock meaning across hosts and daylight-saving changes. 15. As an ocman user, I want invalid trigger configuration rejected before saving, so that a Routine cannot silently become unschedulable. 16. As an ocman user, I want to edit a Routine, so that future invocations use an updated prompt or schedule. 17. As an ocman user, I want to disable automatic firing without deleting a Routine, so that I can pause automation temporarily. 18. As an ocman user, I want Run now to work even while a Routine is disabled, so that disabling a schedule does not prevent deliberate invocation. 19. As a coding agent, I want to invoke an existing Routine through MCP, so that one agent can initiate predefined project automation. 20. As a coding agent, I want to list and inspect Routines through MCP, so that I can discover valid targets before invoking one. 21. As a coding agent, I want to inspect Routine Runs through MCP, so that I can determine whether dispatch succeeded and find the resulting session. 22. As an operator, I want agents prevented from creating or editing Routines through MCP, so that persistent automation remains user-authored. 23. As an ocman user, I want fresh-session mode, so that every invocation receives an isolated coding-agent session. 24. As an ocman user, I want reuse-session mode, so that repeated invocations can retain one Routine-owned conversation. 25. As an ocman user, I want prompts queued durably when a reused session is busy, so that concurrent firing does not lose work or race the active turn. 26. As an ocman user, I want each fresh-mode firing to create an independent session, so that one active run does not block another. 27. As an ocman user, I want each invocation recorded as a Routine Run, so that I can audit what was dispatched. 28. As an ocman user, I want a Routine Run to record its source (`schedule`, `ui`, or `mcp`), so that I know why it happened. 29. As an ocman user, I want a Routine Run to link to its created or reused session, so that I can inspect the agent's work. 30. As an ocman user, I want dispatch failures recorded with an error, so that failed automation is visible. 31. As an ocman user, I want a run considered dispatched when the platform accepts its prompt, so that ocman does not pretend to track the full agent-turn lifecycle. 32. As an ocman user, I want recurring Routines to remain enabled after one dispatch failure, so that transient failures do not permanently stop automation. 33. As an ocman user, I want failed one-time Routines to remain inspectable and manually runnable, so that I can retry deliberately. 34. As an ocman user, I want at most one catch-up firing after downtime, so that missed schedules do not flood agents. 35. As an ocman user, I want the scheduler to advance to the next future occurrence after catch-up, so that normal cadence resumes. 36. As an ocman user, I want archived projects and archived reused sessions skipped as they are today, so that automation does not unexpectedly revive archived work. 37. As an ocman user, I want to delete a Routine after confirmation, so that obsolete automation and its history can be removed. 38. As an ocman user, I want deleting a Routine to leave coding-agent sessions untouched, so that execution evidence is not destroyed indirectly. 39. As an existing Scheduled Prompts user, I want all records migrated automatically, so that upgrading does not lose automation. 40. As an existing Scheduled Prompts user, I want prompt, project owner, timing, timezone, enabled state, session mode, linked reusable session, and operational state preserved, so that migrated behavior remains equivalent. 41. As an existing Scheduled Prompts user, I want a deterministic generated name, so that unnamed records become valid Routines without manual repair. 42. As an existing Scheduled Prompts user, I want generated-name collisions resolved deterministically, so that migration succeeds for similar prompts. 43. As an operator, I want migration to be idempotent, so that retries and repeated startup cannot duplicate Routines. 44. As an operator, I want interrupted dispatches recovered without automatic duplicate prompt delivery, so that restart safety favors auditability over repeated side effects. 45. As an operator, I want historical Workflow tables left intact, so that upgrading does not destructively erase old data. 46. As an ocman user, I want Workflow UI and navigation removed, so that the retired concept is no longer presented. 47. As an operator, I want Workflow APIs, MCP tools, runner integration, and installed skills removed, so that retired code cannot continue executing. 48. As a maintainer, I want Dagu-specific dependencies and the workflow-step command removed when no longer referenced, so that the binary and maintenance surface shrink. 49. As a maintainer, I want Workflow examples and product documentation removed or rewritten, so that documentation matches the product. 50. As a maintainer, I want architecture documentation updated, so that diagrams and prose show Routines rather than the retired Workflow subsystem. 51. As a future implementer, I want trigger representation to be typed and validated, so that a webhook trigger can be added additively later. 52. As an ocman user, I want webhook behavior clearly marked unavailable, so that the UI and API do not imply support that does not exist. ## Implementation Decisions - **Canonical model:** A Routine is `project + name + prompt + one trigger + enabled state + session mode`. It is not a DAG, does not contain nodes or dependencies, and does not invoke another Routine as an internal graph operation. - **Project ownership:** Store both canonical project directory and owner remote ID. Resolve and execute through the existing owner-routing and managed OpenCode seams; explicit unknown/disconnected remote owners fail closed. - **Identity:** Use an immutable opaque Routine ID. Require a non-empty display name unique within one `(remote, project)` scope. - **Trigger model:** Represent the configured trigger as a validated typed value with type-specific configuration. Implement only `once`, `interval`, and five-field `cron`; preserve explicit IANA timezone handling. The representation must permit a later additive `webhook` type, but no webhook placeholder UI, endpoint, secret, or receiver is built now. - **Invocation channels:** The configured trigger governs automatic execution. UI Run now and MCP invocation are explicit channels, not additional configured triggers, and may invoke a disabled Routine. - **Single execution service:** Scheduler, REST handlers, and MCP tools must call one Routine service for validation, invocation, state transitions, and run recording. Do not duplicate dispatch logic in adapters. - **Session modes:** Fresh mode creates a new session for each invocation. Reuse mode creates and remembers a Routine-owned session on first execution, then uses the existing durable follow-up queue when that session is busy. - **Run semantics:** Create one durable Routine Run per invocation attempt. Record Routine ID, source (`schedule`, `ui`, `mcp`), timestamps, dispatch status, platform/session link when known, and error text. `dispatched` means the platform accepted the prompt; the run does not follow the later agent turn to completion. - **Definition snapshots:** A run should retain enough prompt/trigger identity to explain what was dispatched even if the Routine is edited later; keep this minimal and avoid a general immutable-version subsystem. - **Atomicity:** Claim automatic firings and create run records atomically enough that concurrent scheduler ticks cannot dispatch the same due occurrence twice. Explicit invocations each represent one intentional run. - **Restart recovery:** A run left in dispatching state after restart is marked failed/interrupted and is not automatically redelivered, because duplicate agent side effects are worse than a visible missed dispatch. - **Scheduling:** Reuse the current durable scheduler behavior and cron library. After downtime, fire no more than once for an overdue recurring Routine and calculate its following time strictly in the future. Do not replay every missed interval. - **Failures:** Record all failures. Recurring Routines remain enabled and advance to the next occurrence after a dispatch failure. A failed one-time Routine remains available for explicit Run now/MCP retry but has no future automatic occurrence. - **Archived work:** Preserve current behavior that does not automatically dispatch into archived projects or archived reused sessions. Explicit invocation must return a clear error rather than silently doing nothing where the current ownership/archive policy disallows execution. - **CRUD API:** Add localhost-protected REST operations for global/project-filtered listing, creation, retrieval, update, deletion, enablement, explicit invocation, and paginated run history. Responses expose next run, last dispatch result, and linked session details needed by the UI. Validate all project, trigger, name, and session-mode inputs at the trust boundary. - **MCP API:** Add tools to list Routines, inspect one Routine, invoke one Routine, and list its runs. Do not expose create, update, enable/disable, or delete tools. MCP invocation records source `mcp`; no verified caller-agent identity is claimed because the transport does not provide one. - **Main-menu UI:** Replace the Workflows navigation destination with Routines. The page combines local and connected-remote records and supports project/machine filters, create/edit/delete, enable/disable, Run now, next-run display, last result/error, linked session navigation, and per-Routine history. Use existing accessible controls and stable test locators. - **Project UI:** Remove the Scheduled Prompts editor/list from Project Detail; the global Routines page is the authoring surface. Project-filtered deep links are acceptable when they reuse that page rather than recreate the component. - **Deletion:** Confirm destructive deletion, then delete the Routine and its Routine Run records. Never archive or delete coding-agent sessions created or reused by it. - **Scheduled Prompt migration:** Introduce an idempotent state migration that converts every existing Scheduled Prompt. Preserve its ID, owner/project, prompt, timing configuration, timezone, enabled state, session mode, linked platform/session, timestamps, and meaningful operational state. Generate a short name from the prompt's first non-empty line and append a deterministic suffix for collisions. Preserve enough previous completion/failure information as migrated run/history state where available. - **Workflow retirement:** Remove active Workflow service/runtime, scheduler, dispatcher/compiler integrations, REST endpoints, MCP tools, frontend pages/stores/types/routes, installed workflow skill, examples, Dagu integration, workflow-step command, user documentation, marketing references, and now-unused dependencies. Remove tests that only assert retired behavior. - **Historical Workflow data:** Keep existing Workflow schema migrations and tables untouched and inert. New runtime code must not read or execute them. Do not migrate Workflow definitions, versions, runs, attempts, artifacts, or migrated legacy loops into Routines. - **Legacy loop data:** Existing historical loop-to-workflow migration remains valid upgrade history. Do not revive loop tables or runtime behavior. - **Documentation:** Update feature docs, MCP tool documentation, repository guidance, architecture diagrams/prose, and user-facing navigation/marketing copy. Avoid changing unrelated CI files whose paths happen to contain the word “workflow.” - **Events and polling:** Reuse the simplest existing frontend refresh mechanism unless an existing generic change event already fits. Do not add a Routine-specific streaming subsystem solely for this feature. ## Testing Decisions - Tests assert externally visible behavior and durable state transitions, not private helper structure. - The primary seam is a Routine service integration test using fake time, a fake store or real temporary state database as appropriate, and fake session dispatch. Cover validation, each trigger, next-run calculation, timezone behavior, disabled explicit invocation, fresh/reuse dispatch, queue delegation, atomic claiming, one-run catch-up, failure advancement, restart recovery, deletion, and run provenance. - Migration tests start from a database containing representative Scheduled Prompts in once/interval/cron, enabled/disabled, fresh/reuse, completed/failed/canceled, local/remote, and collision cases. Verify equivalent Routines, deterministic names, preserved links/state, idempotency, and no mutation of historical Workflow tables. - HTTP integration tests cover CRUD, filtering, owner resolution/fail-closed remote behavior, enablement, Run now, validation errors, deletion, and run-history responses through the existing server test seam. - MCP tests cover list, inspect, invoke, and history operations and prove authoring/mutation tools are absent. Verify MCP and REST invocation produce the same service behavior with different provenance. - Frontend page tests exercise the Routines page as a user: navigation, global/project/machine filtering, create/edit/delete confirmation, enable/disable, Run now while disabled, status/error presentation, history, and session links. - A navigation smoke test proves Routines is present and Workflow/Scheduled Prompt product surfaces are absent. - Removal verification includes compilation/guard tests proving no active Workflow/Dagu runtime, route, MCP registration, installed skill, or product navigation remains, while historical database migration tests still pass. - Maintain or increase Go and frontend line coverage under the repository coverage ratchet. New branches and migration paths require corresponding tests. ## Out of Scope - Receiving, authenticating, configuring, or delivering webhook triggers. - Any trigger type beyond once, interval, and cron. - Converting Workflow definitions or run history into Routines. - Multi-step DAGs, dependencies, nodes, maps, joins, approvals, command execution, subworkflows, resource pools, leases, or artifacts. - Agents creating, editing, enabling, disabling, or deleting Routine definitions through MCP. - Tracking an agent turn through completion or interpreting its final response as the Routine Run result. - Verifying or persisting the identity of the specific agent that called MCP. - Replaying every schedule occurrence missed during downtime. - Deleting sessions when a Routine is deleted. - Adding a new event-streaming subsystem for Routine UI refresh. ## Further Notes - This is intentionally a replacement, not a third automation system. The completed repository should present only Routines to users. - The existing Scheduled Prompt scheduler, remote-owner routing, managed session launch, reusable-session queue, cron/timezone handling, and archive checks are the closest reusable behavior. - The old Agent Loops implementation and Workflow subsystem are historical context only; do not revive their tables or broad orchestration model. - The implementation should prefer deletion and renaming over parallel compatibility layers. Keep compatibility only where required for database upgrades and preservation of existing Scheduled Prompts.