Add an in-app AI Help Agent for general operating support

[k9mq]

Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

What

Add a conversational AI help panel inside AetherSDR that users can ask general "how do I..." and troubleshooting questions during a live session — e.g. "why is my TX audio distorted," "how do I set up DAX for WSJT-X," "what does the TNF button do" — and get an answer without leaving the app or hunting through the wiki.

This is distinct from the existing 💡 AI-Assisted Issue Reporter (Help → Submit your idea…), which only helps draft a GitHub bug report or feature request for submission upstream. This request is for real-time operating/support help, not issue authoring.

Why

New users (and experienced users on unfamiliar features) currently have three options when something isn't obvious: dig through the GitHub wiki, ask in Discussions, or file an issue. All three take the user out of their operating session and require a round trip to someone else. A built-in help agent would let users get unstuck immediately, using context AetherSDR already has on hand (current radio model, connected mode, active applets, recent log entries) to give more relevant answers than a generic web search would.

How Other Clients Do It

• SmartSDR has no in-app AI assistant; support is via FlexRadio's community forum and PDF manuals.
• GQRX and SDR++ likewise rely on external wikis/Discord/forums with no in-app help surface.
• Outside the SDR space, apps like JetBrains IDEs (AI Assistant chat) and Notion (Q&A panel) embed a chat pane that can answer product questions using the product's own docs as grounding — a reasonable model for what this could look like.

Suggested Behavior

• New menu item: Help → Ask AetherSDR… (or a persistent chat icon in the title bar, alongside the existing 💡 lightbulb) opens a dockable chat panel, similar in spirit to AppletPanel.
• The panel is a simple scrollable message list + text input, styled to match the existing dark theme.
• On send, the app assembles a context block similar to what the existing "File an Issue" support bundle already gathers (Aether version, connected radio model, active DSP/NR engine, current mode, redacted settings) and sends it along with the user's question and the contents of the built-in help docs (resources/help/*.md) to an AI backend.
• Response streams into the chat panel as plain text; no automatic actions are taken on the user's behalf (read-only assistant, not an agent that changes settings).
• A "Copy conversation" button lets the user paste the exchange into a bug report if it turns out to be a real bug — bridging to the existing 💡 reporter rather than duplicating it.
• Should work whether or not a radio is connected (e.g. Demo Mode), since much of the value is answering "how do I configure X" questions independent of a live session.
• Needs a clear opt-in/setting (e.g. in Radio Setup → General) since this implies network calls to a third-party AI API, and a way to disable it entirely for privacy-conscious or offline users.

Protocol Hints

Not a FlexLib/SmartSDR protocol feature — this is purely client-side UI plus a call to an external AI API (or an optional user-supplied API key, given the project's existing multi-provider AI tooling for the issue reporter). No TCP/UDP command changes needed. Unknown — needs research on how to package/ship the local help-doc corpus for grounding, and whether to reuse the same provider-selection UI as the 💡 reporter.

Acceptance Criteria

• A help/chat entry point exists in the Help menu (and/or title bar) distinct from the existing 💡 AI-Assisted Issue Reporter
• User can type a free-text question and receive a streamed AI response without leaving AetherSDR
• The assistant is read-only — it never changes settings, sends radio commands, or takes action without explicit user confirmation
• Feature is opt-in and can be fully disabled via a setting
• No radio credentials, tokens, or unredacted serials are sent to the AI backend (reuse the existing log/settings redaction logic from the support-bundle flow)

[aethersdr-agent]

Triaged: enhancement + GUI, maintainer-review. No duplicate — this is the only issue in the tracker proposing an in-app conversational help surface.

The request is well-scoped and the distinction from the 💡 reporter is correct. Below is what the current tree actually provides versus what the issue assumes, because one of the "Protocol Hints" premises is wrong and it changes the size of the job.

The premise that needs correcting

"an optional user-supplied API key, given the project's existing multi-provider AI tooling for the issue reporter" … "whether to reuse the same provider-selection UI as the 💡 reporter"

There is no AI tooling to reuse. Both existing "AI" flows are clipboard-and-browser handoffs with zero network calls and zero key storage:

• File an Issue — src/gui/SupportDialog.cpp:346-430. Builds kPromptTemplate, calls QApplication::clipboard()->setText(prompt) (:383-384), then shows a FramelessMessageBox whose Claude/ChatGPT/Gemini/Grok/Perplexity buttons are literally QDesktopServices::openUrl() to the consumer web chat (:415-429).
• Submit your Idea 💡 — src/gui/TitleBar.cpp:~1150-1210, same pattern, same provider table at :1176.

So the "provider-selection UI" is five buttons that open a browser. Nothing behind it streams, authenticates, or handles a response. This feature needs a genuinely new API-client layer — that's the bulk of the work, not a reuse.

What is reusable (and is the right precedent)

HTTP + user-supplied key + keychain: src/asr/RemoteAsrBackend.{h,cpp} is the existing, shipped pattern for "user points us at an OpenAI-compatible endpoint with an optional Bearer key." RemoteAsrConfig (RemoteAsrBackend.h:19-21) carries url + apiKey; the backend owns a QNetworkAccessManager (:50). Config UI lives in CopyAssistSettingsDialog (CopyAssistController.cpp:1013 for the endpoint field). Copy this shape, not the browser-button dialog.

Redaction: redactPii() from AsyncLogWriter.h is already the render-boundary scrubber used by IssueReport.cpp:45,75 and SupportBundle.cpp:112,201. Field table is src/core/LogRedactionPolicy.h. Context assembly can reuse SupportBundle::collectSystemInfo() / collectRadioInfo() + recentLogTail() (SupportDialog.cpp:434-436 shows the exact call sequence), so AC #5 is mostly satisfiable by routing the assembled block through redactPii() before send.

Help corpus: already packaged and addressable — resources/resources.qrc:38-43 aliases all six docs to :/help/*.md. Total corpus is 108 KB (~27k tokens). That fits in a single prompt with room to spare, so the issue's "needs research on how to package/ship the local help-doc corpus for grounding" resolves to: no RAG, no embeddings, no shipping work — read the six qrc paths and concatenate. HelpDialog.cpp:341 already does the QFile read from the qrc.

Two things the acceptance criteria under-specify

1. The new API key must be registered in src/core/SettingsCredentialPolicy.h or it leaks into every support bundle. That header is the single source of truth for what the settings sanitizer scrubs — kFlatCredentialKeys has {"AsrRemoteApiKey", "asr_remote_api_key"} at :30 and kCredentialDocFields has the CopyAssist doc entry at :40. A new AiHelpApiKey needs both rows plus the QtKeychain write, exactly as the ASR key does. Missing this is silent: the key persists in plain settings and SupportBundle copies it out.

2. redactPii() cannot scrub the user's own question. LogRedactionPolicy.h:19-22 says so explicitly — it's a keyword table and "cannot recognise a value that carries no keyword." AC Implement XVTR band sub-menu #5 is satisfied for the machine-assembled context block, but if a user types their SmartLink password or home grid into the chat input it goes out verbatim. Recommend the panel state this plainly in its opt-in text rather than implying blanket redaction.

Proposed shape

• src/core/AiHelpClient.{h,cpp} — QNetworkAccessManager POST to a configurable OpenAI-compatible chat endpoint, SSE streaming → chunkReceived(QString) signal. Modeled on RemoteAsrBackend.
• src/core/AiHelpContext.{h,cpp} — assembles system-prompt grounding from the six :/help/*.md files + SupportBundle::collectSystemInfo()/collectRadioInfo(), passed through redactPii(). Testable without any network, which is where the AC Implement XVTR band sub-menu #5 test belongs.
• src/gui/AiHelpPanel.{h,cpp} — message list + input + "Copy conversation"; dockable per the AppletPanel precedent the issue cites.
• src/gui/MainWindow_Menus.cpp — new action near the existing Help entries (:1254 💡, :1260 File an Issue), gated on the opt-in setting so it's absent/disabled when off.
• src/core/SettingsCredentialPolicy.h — the two credential rows above.

Read-only (AC #3) is free here: nothing in this design holds a RadioModel* handle, unlike SupportDialog::fileIssue(parent, &m_radioModel). Worth keeping it that way structurally rather than by convention.

For the maintainer

The decision this needs is which backend, and it isn't a small one. A project-hosted endpoint means AetherSDR runs and pays for inference for every user; a user-supplied key means the feature is off by default for essentially everyone who'd most benefit from it (new operators), which undercuts the stated motivation. The ASR precedent chose user-supplied, which is the consistent answer, but it's worth deciding deliberately before implementation rather than defaulting into it. Everything else above is mechanical.

---

_{🤖 aethersdr-agent · cost: $1.5651 · model: claude-opus-5}

---

_{📍 Citation health check (Foundry Constitution Principle I): 2 resolved, 7 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (7)

Citation	Reason
CopyAssistController.cpp:1013	file not found in workspace
HelpDialog.cpp:341	file not found in workspace
IssueReport.cpp:45	file not found in workspace
LogRedactionPolicy.h:19-22	file not found in workspace
RemoteAsrBackend.h:19-21	file not found in workspace
SupportBundle.cpp:112	file not found in workspace
SupportDialog.cpp:434-436	file not found in workspace