## Summary In https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/work_items/2613, we built a spike of `/goal` in the Duo CLI that lets a user hand off an open-ended objective instead of a single prompt: the client keeps sending follow-up turns to the backend, using local heuristics (a Haiku "is this done?" judge, prompt tuning based on live output, turn-ended signals) to decide when to continue, pause, or stop. Following exec review, we want to move this capability off the client and into duo-workflow-service as a first-class, governed workflow — a "goal-driven" flow that the backend runs, checkpoints, and decides completion for. Clients (CLI, IDE, Web) should be able to invoke it explicitly (e.g. via `/goal`), and the workflow service should also be able to select it automatically when a request's shape calls for iterative, multi-turn execution rather than a single turn. In our '\`Trigger\`/\`Action\`/\`Stopper\`' framework for loops, this epic covers the \`Action\`\<--\>\`Stopper\` interactions. ## Problem - All "is the goal done yet, and what should happen next" logic currently lives in the CLI (see `gitlab-org/editor-extensions/gitlab-lsp`, `packages/cli`): a client-side judge model, ad hoc continuation prompts, and turn-boundary heuristics. - This only exists in one client (Duo CLI). Other surfaces (IDEs, future clients) get none of it, and can't get it without reimplementing the same heuristics. - Because the loop lives client-side, it isn't governable the way a backend workflow is: no consistent approval/checkpoint model, no server-side policy over how many iterations run or what "done" means, no observability in one place. - The backend has no concept of "run until this goal is satisfied" — `duo-workflow-service` today runs flow configs one-shot or resumes at explicit approval checkpoints (see `duo run --goal`/`--flow-config` in `packages/cli/docs/cli-reference.md`), but nothing loops on the service side toward a goal. ## Goals - Define a goal-driven workflow type in `duo-workflow-service` that owns iteration/continuation decisions (completion judging, pacing, pausing) instead of the client. - Preserve today's governance primitives (plan approval checkpoints, rejection feedback) and extend them to cover iteration boundaries in the new workflow. - A user can invoke the goal in two ways: - Explicitly, via a client trigger (e.g. `/goal` in Duo CLI, and equivalent entry points in other clients over time). - Implicitly, by allowing GitLab agents to be configured to select it automatically when a user request warrants iterative multi-turn execution. - Goal driven prompting surface in all AI Clients in a natural way. For example, Duo CLI's `/goal` becomes a thin trigger for this backend workflow. ## Out of scope (for this epic) - Changing existing one-shot `duo run --goal` / `--flow-config` behavior for flows that don't need iteration. - Adding additional event triggers or trigger types (e.g. scheduled triggers) ## 19.3 For 19.3, we should have an end to end experience with UX on parity with existing CLI but with all the logic running in the workflow service. The flow should be triggerable by Web Chat in a similar manner to any other flow. This would be the first stage of the work - all work would be reusable as we built out final UX and additional features. ### In Scope * The Workflow Service has a built-in flow that encapsulates the Action-Stopper logic (e.g. a Duo Developer flow to implement -Action, and a LLM-as-Judge to implement the Stopper) * CLI provides a `/goal` command that can run this flow directly. Full interactivity with the flow (can be stopped, updated, redirected) * WebChat can trigger the flow ambiently if the prompt is of the form of an action and stopper * Web Runners can run the flow in non-interactive mode ### Out of Scope * Session interactivity/suspend/resume on runners. For flows on runners we will assume they are fully autonomous for now and will revisit the primitives we need for interactivity and resumability * No parallel sub-agents - everything runs in a linear flow ## 19.4 In 19.4, we would work on whatever new designs come from UX for triggering and managing flows that are interactive. ### In Scope * Extends to IDEs for explicit execution with \`/goal\` * Implementing any new design for web and CLI/IDE interactions ### Stretch or post-Later (needs Eng investigation and scoping) * Add resumability and interactivity for runners (possibly will take longer into 19.5 depending on complexity) * Add abiltiy for parallel sub-agents, e.g. for parallel verifiers such as code review, security review ### Out of Scope * A separate epic would cover any management layer to create/flows, attach to triggers ###