Skip to content

[Feat] Enable structured task suggestions beyond automations - #2325

Draft
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/structured-suggestions-all-tasks-379fzou34lfsa
Draft

[Feat] Enable structured task suggestions beyond automations#2325
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/structured-suggestions-all-tasks-379fzou34lfsa

Conversation

@roomote-roomote

Copy link
Copy Markdown
Contributor

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

No linked issue. This is an independently requested expansion of the existing structured suggestion capability, based on develop without incorporating or depending on #2309.

Why this PR exists

  • A maintainer explicitly invited this PR in the linked issue or discussion
  • I am a maintainer / this is internal Roomote work

Structured suggestions were restricted to automation turns, and ordinary Fast reply adapters did not publish their cards. Task origin should not determine whether useful follow-up work can be offered through the existing acceptance flow.

What changed

  • Make structured suggestions optional across ordinary user turns, automation turns, delegated-task reports, and other task types, while retaining supported chat surfaces and closeout rules.
  • Publish existing suggestion cards through ordinary Slack/Discord adapters, reactions, SDK surface replies, and nonautomation parent events across Slack, Discord, Teams, and Telegram.
  • Preserve authorization, destination checks, workspace validation, origin Session/thread lookup, existing card acceptance/start behavior, and Scan's scheduled/onboarding and pinned launch contracts.
  • Deliver cards after streamed replies or retry-notice replacement without repeating the narrative. Report partial card-delivery failure explicitly and prevent narrative replay.
  • Align prompts and tool descriptions without requiring suggestions on every reply. No new UI, migration, or replacement with prose.

The impact is broader availability of the same launchable cards, not broader launch authority. Unsupported surfaces still cannot promise card launching, and delegated workers continue reporting privately through their parent Session.

How it was tested

  • Targeted Fast service, native-tool, prompt, and streaming tests passed; the final service suite passed 261 tests.
  • Worker MCP descriptions, replies, and Session propagation: 90 tests passed.
  • API submission eligibility and safety: 72 tests passed; ordinary/reaction adapter suites: 62 tests passed.
  • SDK surface delivery, parent-event, publisher, and queue suites: 133 tests passed, with the final parent-event suite rerun passing 70 tests.
  • Existing acceptance and workspace-routing regression suites: 72 tests passed.
  • API, worker, SDK, and cloud-agents package typechecks passed. Pre-push repository-wide oxlint, residual ESLint, fast typechecks, and knip all passed.
  • No live external-provider end-to-end run. Visual proof capture timed out; no screenshots or recordings are claimed. Scan's separate architecture and unsupported browser/source-control card surfaces remain unchanged.

Checklist

  • The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
  • This PR is small and scoped to one change
  • pnpm lint and pnpm check-types pass locally
  • I added tests or included a clear manual validation note above
  • I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
  • If this change should appear in the changelog, I ran pnpm changeset

The exact full lint/typecheck commands above were not run; package typechecks, scoped formatting, and the complete pre-push static gates passed. No changeset was added.

@roomote-community

roomote-community Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

1 issue outstanding. See task

  • Keep partial card-delivery failures from replaying an already-visible Fast reply.

Reviewed babb206

conversation,
messageId: posted.messageId,
});
if (suggestions.length > 0) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reply has already reached Discord when this awaited card publish can fail. That rejection bubbles through postReply, so the closeout is neither persisted nor marked delivered; a model retry or durable resume can resend the narrative even though users already saw it. Treat card posting as a non-fatal second phase here (as the stream/retry path does) and return a delivery warning instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant