Labels: feature-request · community · dogfooding · Wave 3
Summary
Add four in-app actions — Bug / Feedback / Idea / Help — that are themselves agentic: instead of opening a text box, each one gathers relevant context, structures it into a well-formed report, checks for duplicates, and (in a user-chosen mode) files it directly as a repo issue or discussion.
Problem
Today, reporting a bug or requesting a feature means leaving the product, remembering the relevant context unaided, and hand-writing an issue from scratch. There is no in-product path from "something's wrong / here's an idea" to a well-formed, actionable report — and no equivalent for a quick help question. The result is that most friction and most ideas never get captured at all; only the most motivated users write anything down, and what they write is usually thinner than what actually happened. This very feedback pack — hours of manually reconstructing context, structuring it, and cross-referencing it — is the proof: it is exactly the work this feature should do automatically.
Proposed capability
Four actions, one underlying pipeline
- Bug — something broke or misbehaved.
- Feedback — general friction, praise, or a complaint that isn't quite a bug or a feature ask.
- Idea — a feature request or improvement suggestion.
- Help — "how do I do X" — routes first to a self-check against docs/known capabilities (see FR-11) before ever becoming an issue.
All four share one agentic pipeline: gather → structure → scrub → dedupe → file.
The agentic pipeline
- Gather: pull relevant context automatically — recent error/log lines, the agent/task involved, current mode/settings, and (where applicable) a screenshot or short activity trace — rather than relying on the user to describe everything from memory.
- Structure: compile it into a standard report shape (summary, repro/context, expected vs. actual, environment) instead of a raw paragraph — the same shift from "raw complaint" to "structured, actionable input" that this pack itself demonstrates by hand.
- Scrub: strip identifying details (paths, project names, personal data) before anything leaves the product — non-negotiable, not a mode.
- Dedupe: check the report against existing open issues/discussions (and the public roadmap, FR-30) first, so a common complaint strengthens an existing thread with a 👍 and a data point instead of spawning a duplicate.
- File: open the resulting issue or discussion in the repo.
Draft-for-review vs. auto-file — a selectable mode
Whether the agent files directly or shows the user a draft to approve/edit first is a selectable mode, set at onboarding (or per-action-type) — some users want zero friction, others want to see exactly what leaves the product before it does. Either way, the user always sees the final report once it's filed.
Prior-art (inspiration)
- Aider — on an uncaught error, offers to open a prefilled GitHub issue with a scrubbed traceback and environment details, asking for confirmation before it's sent: exactly the "gather + scrub + confirm" shape this feature needs.
- GitHub Desktop — its built-in "Report an issue" flow pre-populates a structured GitHub issue template from app context, so the user edits a draft rather than starting from a blank box.
- Sentry — its user-feedback widget automatically attaches session/environment context to a report rather than asking the user to reconstruct it in prose.
Why now
It closes the loop between using Fusion and improving it, at basically no cost to the user — capture happens where friction actually occurs, not hours later in a separate document. And a structured, agent-authored, deduped report (as this pack demonstrates by hand) is far more actionable for maintainers than a raw complaint or a wishlist buried in a chat log.
Labels: feature-request · community · dogfooding · Wave 3
Summary
Add four in-app actions — Bug / Feedback / Idea / Help — that are themselves agentic: instead of opening a text box, each one gathers relevant context, structures it into a well-formed report, checks for duplicates, and (in a user-chosen mode) files it directly as a repo issue or discussion.
Problem
Today, reporting a bug or requesting a feature means leaving the product, remembering the relevant context unaided, and hand-writing an issue from scratch. There is no in-product path from "something's wrong / here's an idea" to a well-formed, actionable report — and no equivalent for a quick help question. The result is that most friction and most ideas never get captured at all; only the most motivated users write anything down, and what they write is usually thinner than what actually happened. This very feedback pack — hours of manually reconstructing context, structuring it, and cross-referencing it — is the proof: it is exactly the work this feature should do automatically.
Proposed capability
Four actions, one underlying pipeline
All four share one agentic pipeline: gather → structure → scrub → dedupe → file.
The agentic pipeline
Draft-for-review vs. auto-file — a selectable mode
Whether the agent files directly or shows the user a draft to approve/edit first is a selectable mode, set at onboarding (or per-action-type) — some users want zero friction, others want to see exactly what leaves the product before it does. Either way, the user always sees the final report once it's filed.
Prior-art (inspiration)
Why now
It closes the loop between using Fusion and improving it, at basically no cost to the user — capture happens where friction actually occurs, not hours later in a separate document. And a structured, agent-authored, deduped report (as this pack demonstrates by hand) is far more actionable for maintainers than a raw complaint or a wishlist buried in a chat log.