Roadmap: deliver a polished provider, MCP, settings, and native experience center

[qwen-code-dev-bot]

Source

• Source type: source:user
• Source evidence: user request for a complete, best-in-class CLI plus Desktop product.
• Public inspiration reviewed on 2026-07-31: Gemini CLI, Goose, OpenCode, VS Code, and GitHub Desktop.

Problem statement

Providers, models, MCP servers, permissions, themes, accessibility, updates, and diagnostics determine whether the product feels dependable. These controls need a coherent, secret-safe experience rather than scattered config knowledge.

User value

Users can understand capabilities, switch or diagnose integrations, personalize the interface, and keep the app healthy without exposing secrets or editing fragile configuration blindly.

Scope

• Provider/model capability, health, quota, latency, cost, and selection views.
• MCP inventory, permissions, lifecycle, logs, and trust posture.
• Searchable effective settings with provenance, safe editing proposals, validation, and rollback.
• Shared themes, density, reduced motion, screen-reader semantics, notifications, diagnostics, and native update readiness.

Non-goals

• Displaying raw credentials.
• Installing or enabling extensions without consent.
• Replacing the provider/extension backends Roadmap: secure extensibility and automation ecosystem #34/Roadmap: offline-first local models and resilient provider routing #287.

Acceptance criteria

• Effective provider/model/MCP state is visible, redacted, and attributable to configuration provenance.
• Changes preview impact, validate before write, and remain recoverable.
• Permission and trust boundaries are consistent across TUI and Desktop.
• Core journeys work with keyboard navigation, reduced color, reduced motion, and assistive labels.
• Native packaging, diagnostics, and update states are testable once the Desktop gate is satisfied.

Test plan

Redaction/provenance fixtures, capability and health tests, settings validation/rollback tests, accessibility checks, theme snapshots, and native packaging E2E.

Dogfood plan

Diagnose a provider failure, switch to a compatible model, inspect one MCP server's permissions, adjust density/theme, and export a secret-safe support bundle.

Risk and security notes

Configuration UI can accidentally expose or overwrite secrets. Show references and provenance, not secret values; mutations remain policy-governed and atomic.

Duplicate search evidence

Consumes #34/#92/#110/#287 and completed extension-health children. It unifies their user-facing control and native polish instead of creating parallel backends.

Parent/child relationship

This is a roadmap parent. Decompose read-only health, safe settings proposals, MCP lifecycle, accessibility, theming, diagnostics, and native update readiness.

Dependency order

Read-only redacted health first, safe proposal/validation next, TUI settings experience next, Desktop/native polish after #106/#133 and #142 where applicable.

Product and governance guardrails

• Treat the linked projects as behavior-level inspiration only. Do not copy third-party source code, assets, screenshots, branding, or visual identity.
• Preserve one underlying run/session model across TUI and Desktop; do not create demo-only state or simulated execution evidence.
• Any native Desktop acceptance remains gated by Desktop: launch a secure macOS session shell #106 and the maintainer-authored macOS evidence required by Governance: add head-bound macOS Electron screenshot check #133. A TUI or shared-core child may proceed independently only when its acceptance does not depend on that gate.
• Keep approval, sandbox, redaction, lease, and append-only evidence guarantees intact.