## Summary When GitLab Duo builds a workplan for a work item, it sometimes hits a decision it should not make alone. This epic is about asking that question in the work item's discussion, letting a human answer it there, and having the flow pick up the answer and carry on. ## What? Duo can research a work item and write a plan for it, but some gaps are not the agent's to fill. Whether something is free or paid, who can see it, whether a change breaks existing behaviour: guessing wrong on those is expensive, and a plan built on a wrong guess is worse than no plan. The original research question was where those questions should be asked. We settled on the work item's discussions, for a few reasons: - A question in a discussion is durable. A chat session is not, and it disappears with the tab. - Other people can see it and weigh in. Deciding together is usually better than one person deciding alone. - The work item already holds everything else about this piece of work, so the decision sits next to the thing it affects. - The same surface can serve any flow that needs to ask something, not just workplan generation. What is missing today is the interaction itself. The flow can already post a question as a comment, but reading it, working out what the choices were, and typing a reply is slower and vaguer than it needs to be. There is also nothing telling you a question is waiting. ## How? The flow attaches a small machine readable summary of its question to the comment it posts. The work item turns that into something you can act on, and answering feeds straight back into the flow. - The question renders as a card in the thread, showing the options Duo considered and which one it would pick. - You answer by choosing an option. Some questions accept more than one answer. - If none of the options are right, you can say so and explain why. The explanation is required, because that is what Duo acts on next. - Answering posts your choice as an ordinary reply and resolves the thread. Resolving is the signal: once every question is settled, the flow starts again by itself and reads the answers. - Because the answer is a normal comment and a normal thread resolution, everything stays visible and anyone can follow what happened. ### Proposed Designs (Iteration 1) Complete prototypes available [here](https://www.figma.com/design/uJb85wjoRaj7MMvjxAmdHf/SDD-Iteration-Path?node-id=46-27205&t=fJN4eFDLenZlY5iG-0) | |Questions waiting for User Input|Questions with accepted answer|Custom Response| |---|---|---|---| |**Light**|{width=900 height=566}|{width=900 height=166}|{width=900 height=167}| |**Dark**|{width=900 height=571}|{width=900 height=162}|{width=900 height=169}| Everything here sits behind two feature flags, both off by default. `workplan` controls whether the Workplan widget exists on a work item at all, and `duo_workplan_async_flow` controls whether generation runs as a background flow. Both have to be on before any of this shows up, so nothing reaches anyone until the workstreams it depends on are ready. The work is broken into child issues that can each ship on their own. The first few need nothing from other teams and can land now. The rest wait on the workplan flow itself, or on decisions still being made elsewhere. ## Follow-up Open questions and decisions still to make: - **Do approval requests belong here too?** A single workplan run produced three interruptions: one real question, and two requests to approve a tool call. If all three become threads, that is a lot of noise. The current thinking is that discussions carry questions only, and approvals stay where the person running the flow can see them. - **Who records the decision?** Right now the answer survives as a reply and, if we are lucky, a line the agent writes into the plan. Nothing records what was asked, what was offered, and what was chosen in a way anything can query later. This overlaps with the Decision Log work and needs a shared answer. - **What happens to the question after it is answered?** Once the thread resolves, the options and Duo's recommendation stop being visible. Whether the thread should keep showing them, or the Decision Log becomes the place you look, is undecided. - **Nobody is told a question is waiting.** No todo, no email. The flow posts its question and finishes, so the existing notification path never fires. Notifications are a hard requirement for this initiative, so this needs solving rather than deferring. - **Can a question offer a free text answer?** The flow can already signal that the listed options might not cover everything. We do not act on that yet. - **How does this behave when a question is never answered?** The flow stops and waits. There is currently nothing that chases it or cleans it up. <details> <summary>Original description</summary> ## Summary - Research UX/Engineering: Understand what are the options to bring HITL available today? - **Comment/Discussion Thread:** - Potentially wasteful option if we have to trigger the full flow with the new comments again - Notifications: Built in with the existing todos architecture - Q: Can we make it to show.interact with suggestion widget within the comment/discussion vs typing the whole thing? - Q: Can the flow resume with a given comment/discussion thread ID and continue with that input? - Q: Alternatively can a new flow start just with the workplan and th discussion thread as the context - **Duo Chat**: - Can a flow start from the chat output question(as options) to the chat and then pick up the responses from there. - Notifications: We have to build smth to direct the user to the actual chat session to respond. - **Comment + Workplan widget**: - Show the questions as an interactive widget on the workplan itself, linked from a comment where a human is pinged by the bot. - Drive human to the correct primitive to provide feedback - Highlight WIs that are waiting for human response/feedback </details>