Hydrogen Desktop

Type: Feature request · [hd-feedback]

Today, filing HD feedback means hand-authoring adom-wiki discussion posts (like this one) and manually hunting down logs on the host. We want a native, in-app feedback mechanism so any user can file a well-formed, log-backed report in a few clicks.

UX

A Feedback button in the HD UI (e.g. profile menu / Adom menu, or a toolbar affordance) opens a small form:

• Title — free text.
• Workspace / area — dropdown, populated from currently-open workspaces (e.g. VSCode, Wiki, plus whatever tabs are open) and always including two fixed entries: General HD and Other.
• Comments — multi-line text field for the user's description.
• Share logs — checkbox/toggle. When on, HD collects the relevant logs and attaches them (see privacy split below).

Where things go (privacy split)

• Discussion item → public wiki (adom/hydrogen-desktop). Contains title, selected workspace/area, and user comments. No raw logs — logs are frequently host-path / environment-specific and shouldn't be public.
• Logs → private Google Chat space (webhook). When "share logs" is on, HD bundles the logs (at minimum %APPDATA%\hydrogen-desktop\hydrogen-desktop.log and %LOCALAPPDATA%\inc.adom.desktop\logs\Adom Desktop.log, + build stamp / version / OS) and posts them to a dedicated gchat space via webhook. Requires: (1) create the space, (2) provision an incoming webhook, (3) store the webhook URL as an HD secret (not in the client bundle).

Linking the two

• Each feedback submission generates a unique shared ID (e.g. HDFB-<short-uuid>).
• That ID is written into both the public discussion body and the gchat log message, so a reviewer (or John's agent) can jump from a public report to its private logs and back. Logs stay private; only the correlation ID is public.

Provenance tag

• Discussions created by this mechanism must carry a clear indicator that they were machine-generated by the HD feedback flow — a label/tag such as hd-feedback (and/or a footer line Filed via HD in-app feedback · HDFB-xxxx · HD vX.Y.Z). This distinguishes them from hand-written discussions and lets reviewers filter/triage them.

Implementation notes / open questions

• Discussion creation: reuse the same adom-wiki discussion create API this post used, with --category feedback and the hd-feedback label. Confirm the wiki supports labels on create (there's a discussion triage verb for labels) so the tag is queryable, not just body text.
• Workspace list source: HD already exposes open tabs via the control port (GET /workspace/tabs) — the dropdown can populate from that live.
• Log collection path: the pull path used to gather logs for the current reports (adom-desktop pull_file) is a working reference; the native flow should read the same two log files directly since HD owns them.
• Secret handling: the gchat webhook URL must live server-side / in an HD secret store, never shipped in the frontend.
• Consent: make it explicit in the form that "share logs" sends log contents to an internal Adom gchat space (not the public wiki).

Meta

This request was itself filed by hand (Claude → adom-wiki) precisely because the native flow doesn't exist yet — it's the paper-cut this feature removes.