## Summary Nothing checks who wrote a note before rendering its payload as a Duo question card. `parseDuoQuestion` reads the note body and the component renders whatever parses, so any user can post a comment carrying a `json:duo-question` block and get a real interactive card: options that look system-generated, and clicking one posts a reply and resolves the thread. There is no exposure today, which is why this is tracked in the open. Card rendering is gated on `duo_workplan_async_flow`, and that flag is off by default, so a fabricated payload renders nothing on a production instance right now. This needs settling before either flag is enabled anywhere. ## Current state `ee/app/assets/javascripts/work_items/components/notes/duo_question_note.vue` decides whether to render from two things only: the `duoWorkplanAsyncFlow` flag, and whether the payload parses as a `closed` question. The author never enters into it. `canReply` is not a substitute. It is the viewer's permission to reply (`app/assets/javascripts/work_items/components/notes/work_item_note.vue`, `work_item_discussion.vue`), not a statement about who authored the note. Worth noting what a fabricated payload can and cannot do. A note body is already user-authored markdown rendered through Banzai, so a bullet list, a bold label, or a link are all things a user can write directly. Two things are genuinely new: - An interactive control that posts a reply and resolves a thread on the reader's behalf. - Divergence between surfaces. `pre[data-lang-params='duo-question']` in `app/assets/stylesheets/page_bundles/work_items.scss` hides the block for everyone and is not flag-gated, so a comment can read one way on the page and another way elsewhere. The same predicate is needed on the backend for notification emails, proposed in https://gitlab.com/gitlab-org/gitlab/-/issues/627212. Both surfaces should decide this the same way rather than growing two rules. ## Implementation notes - `bot` already exists on the GraphQL user interface (`app/graphql/types/user_interface.rb`), declared `null: false` with `method: :bot?`. That is the same `User#bot?` the email side uses, so the two agree by construction instead of by two parallel definitions. It is derived from `user_type` on an already-loaded record, so there is no extra query. - It is not requested anywhere in the work item note queries today. The note fragments select the author through the shared spread in `app/assets/javascripts/graphql_shared/fragments/user.fragment.graphql`, which carries only identity and avatar fields. - Prefer adding `bot` alongside the spread in `work_items/graphql/notes/work_item_note.fragment.graphql` rather than to the shared fragment, which is imported by roughly 70 files. Check whether `work_item_discussion_note.fragment.graphql` needs it too, since the replies path nests `WorkItemNote`. - `bot?` rather than a specific username: the workplan flow posts as a service account (`user_type: service_account`), Duo Code Review posts as `duo_code_review_bot`, and both report `bot?`. The epic expects more than one flow to ask questions, so a username would date immediately. - There is backend precedent for gating on Duo authorship in `EE::Note#authored_by_duo_bot?`, which is narrower (`duo_code_review_bot?` only) and would not match the workplan service account. - Most of the diff will be fixture churn: every mock note in the work items Jest mock data and the question card specs needs an author carrying `bot`. ## Open questions - **What should a human-authored payload render?** Failing closed is not obviously right here. The block is hidden by CSS regardless of the flag, so suppressing the card alone leaves the reader with prose and no options at all, which is worse than either showing the card or showing the raw block. Options: gate the CSS rule on the same condition, render the block as an ordinary code block when the author is not trusted, or strip the payload. - Does anything else need the same predicate, for example the Decision Log work, once it starts reading answers back? - Should the prompt-side contract say anything, or is this purely a rendering decision? ## Related - The email side, which needs the same predicate: https://gitlab.com/gitlab-org/gitlab/-/issues/627212 - The flow's prompt instructs the agent not to rely on note authorship when recognising its own earlier questions: https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6711. That is a different problem from a renderer deciding whether to trust a payload, and the two should not be conflated: a false negative there means a duplicate comment, a false positive here means rendering someone else's content as if the system produced it. - Rendering states for a settled question: https://gitlab.com/gitlab-org/gitlab/-/issues/617978 ## Acceptance criteria - [ ] A payload in a bot-authored note renders exactly as it does today - [ ] A payload in a human-authored note does not render an interactive card - [ ] A reader of a human-authored payload is never left with prose whose options are invisible, whichever resolution the open question above takes - [ ] The condition matches what the email side uses, so one surface cannot trust a note the other rejects - [ ] Jest specs cover a bot author, a human author, and the untrusted rendering path