Draft: Automate work with Routines

Today, automating work in the Duo Agent Platform means creating a trigger. Routines make the automation itself the thing you create: work that runs on a schedule, or when something happens in your project, as an identity whose permissions you can see at a glance, with a history of what it ran, what it skipped, and what it cost. Triggers become something a routine has, so one routine can run every Sunday evening and whenever a merge request is marked ready. It also settles the confusion of "triggers" meaning one thing on this page and another inside a flow. Everything here is clickable on mock data, so the experience can be judged before it is built. The open question it raises is how a routine knows when its work is done.

Steps to validate locally

Everything is frontend only, so there is no migration to run and nothing to seed. The Routines pages never call GraphQL, and the existing Flows and Triggers pages fall back to fixtures only when the project has no real data of its own.

1. Use a project where Duo features are enabled and your user can reach the Automate section. If the Agent sessions item is visible in that project's Automate menu, the Routines route will load, since it falls through to the same general Duo Workflow gate rather than the narrower one the Triggers page uses.
2. Ideally use a project at the path gitlab-duo/test. The fixtures hardcode that path for the "View full session" links on each run report, so they resolve to real agent session pages instead of dead ends.
3. Go to Automate > Routines in the sidebar, or visit /-/automate/routines directly. Triggers stays exactly where it was, so the two can be compared side by side in one tab.

What to look at, roughly in the order the story is told:

• The index: eight seeded routines, the stat cards above them, and the list and calendar toggle. In the calendar, past days show runs that actually happened while future days can only show scheduled occurrences, which is inherent to putting event-driven work on a calendar.
• Weekly feature request pass, which is the one routine that is not a single-shot bot. Open it and read the run reports: it opens a digest issue, implements the top request, waits on its own pipeline, and reviews its own diff until another pass would not be worth it. One run stops on a pass limit while still finding real problems, and another declines to open a merge request at all because the work needed a schema change. Its durations are hours rather than minutes, which is the fastest way to see it is a different kind of work.
• New routine: the three configuration sources (agent, flow, or a YAML file), the instructions field and how its label and requiredness change with the target, the permissions summary that spells out what the routine can do at the chosen role and which capabilities deserve a second look, and the triggers builder, where a trigger is added as either a schedule or an event and validated before it joins the list.
• The Triggers page for contrast, now populated with fixtures. Note the Owner column: it renders the service account the trigger runs as, which is the same concept Routines calls "Runs as" alongside an explicit role.

One thing to expect: the store is in memory, so anything you create, edit, pause, or delete resets on reload. That is deliberate.