|
| 1 | +# Functional Requirements (RequestTracker UI) |
| 2 | + |
| 3 | +This document combines: |
| 4 | + |
| 5 | +- Projected UI requirements derived from the `McpServer` workspace requirements and the UI.Core migration directives. |
| 6 | +- Newly captured requirements discovered during the as-built audit of `McpServerManager.Android` and `McpServerManager.Desktop`. |
| 7 | + |
| 8 | +## Group Hierarchy (Up To 3 Levels) |
| 9 | + |
| 10 | +1. Projected requirements from McpServer workspace |
| 11 | + 1.1 Shared UI.Core command/handler parity contract |
| 12 | + 1.2 Cross-host architecture and migration scope |
| 13 | +2. As-built uncaptured requirements (Android + Desktop) |
| 14 | + 2.1 Connection and workspace bootstrap |
| 15 | + 2.2 Shell surfaces and status affordances |
| 16 | + 2.3 Todo workflows |
| 17 | + 2.4 Workspace workflows |
| 18 | + 2.5 Session-log workflows |
| 19 | + 2.6 Voice workflows |
| 20 | + 2.7 Cross-cutting runtime UX |
| 21 | + 2.8 Agent event notifications |
| 22 | + |
| 23 | +## FR-RTUI-001 1.1.1 Shared UI.Core ViewModel and RelayCommand contract |
| 24 | + |
| 25 | +All user-facing actions across Phone, Tablet, Desktop, TUI, and Web shall execute through `McpServer.UI.Core` ViewModels and `RelayCommand`/`IAsyncRelayCommand` contracts, with host-specific behavior layered on top. |
| 26 | + |
| 27 | +**Projected from:** `FR-MCP-029`, `FR-MCP-030`, `FR-MCP-031`, `FR-MCP-037` |
| 28 | + |
| 29 | +## FR-RTUI-002 1.1.2 Complete command-to-mutation path per use case |
| 30 | + |
| 31 | +Each documented user use case shall have a complete `RelayCommand -> Handler -> ViewModel mutation` path with no method-only bypasses for active UI operations. |
| 32 | + |
| 33 | +**Projected from:** `FR-MCP-029` |
| 34 | + |
| 35 | +## FR-RTUI-003 1.1.3 Endpoint and handler parity for shared UI domains |
| 36 | + |
| 37 | +For TODO, Workspace, Session Log, Health, Tunnel, and Template domains, each supported UI endpoint path shall be represented by at least one handler and corresponding UI command path. |
| 38 | + |
| 39 | +**Projected from:** `FR-MCP-029`, `FR-MCP-049` |
| 40 | + |
| 41 | +## FR-RTUI-004 1.2.1 Cross-surface behavior parity with explicit divergence notes |
| 42 | + |
| 43 | +Common use cases shall have equivalent behavior across Phone, Tablet, Desktop, TUI, and Web. Any intentional divergence shall be documented and traceable. |
| 44 | + |
| 45 | +**Projected from:** `FR-MCP-030`, `FR-MCP-031` |
| 46 | + |
| 47 | +## FR-RTUI-005 1.2.2 Extension-only host customization |
| 48 | + |
| 49 | +Host-specific UX behavior shall be implemented as extensions around shared UI logic rather than forks of endpoint logic in host-local ViewModels. |
| 50 | + |
| 51 | +**Projected from:** `FR-MCP-030`, `FR-MCP-031` |
| 52 | + |
| 53 | +## FR-RTUI-006 1.2.3 Director and Web host migration to RequestTracker baseline |
| 54 | + |
| 55 | +Director (TUI) and Web UI hosts shall converge on the same shared command/runtime baseline used by the Android and Desktop apps in this workspace. |
| 56 | + |
| 57 | +**Projected from:** `FR-MCP-030`, `FR-MCP-031` |
| 58 | + |
| 59 | +## FR-RTUI-101 2.1.1 Connection bootstrap and authenticated session entry |
| 60 | + |
| 61 | +The UI shall provide host/port connection, optional QR-assisted host capture (Android), OIDC device flow sign-in, and automatic reconnect from saved connection preferences. |
| 62 | + |
| 63 | +**Covered by:** `ConnectionViewModel`, `ConnectionWindow`, `ConnectionDialogView`, `App` (Desktop/Android), `AndroidQrScannerService` |
| 64 | + |
| 65 | +## FR-RTUI-102 2.1.2 Workspace selection with health-gated switching and rollback |
| 66 | + |
| 67 | +The shell shall allow workspace selection, persist the selected workspace key, run preflight health checks during switch, and roll back to the previous workspace when switch validation fails. |
| 68 | + |
| 69 | +**Covered by:** `MainWindowViewModel`, `WorkspaceConnectionOption`, `AndroidConnectionPreferencesService` |
| 70 | + |
| 71 | +## FR-RTUI-103 2.2.1 Adaptive shell by form factor |
| 72 | + |
| 73 | +Android shall switch between phone and tablet shells at runtime based on display width, while Desktop provides a multi-tab shell with Request Tracker, Todos, Voice, Workspaces, Logs, AGENTS, and Settings. |
| 74 | + |
| 75 | +**Covered by:** `AdaptiveMainView`, `DeviceFormFactor`, `PhoneMainView`, `TabletMainView`, `MainWindow.axaml` |
| 76 | + |
| 77 | +## FR-RTUI-113 2.2.2 Global status and shell quick actions |
| 78 | + |
| 79 | +The shell shall expose live status text, workspace health indicator, app version, and logout. Android status text supports tap-to-dialog and long-press-to-copy affordances. |
| 80 | + |
| 81 | +**Covered by:** `MainWindowViewModel`, `PhoneMainView`, `TabletMainView`, `MainWindow.axaml` |
| 82 | + |
| 83 | +## FR-RTUI-115 2.2.3 AGENTS marker visibility in shell |
| 84 | + |
| 85 | +Desktop shall expose an AGENTS tab that loads and refreshes `AGENTS-README-FIRST.yaml` metadata/content for the selected workspace. |
| 86 | + |
| 87 | +**Covered by:** `MainWindowViewModel`, `AgentsReadmeView`, `MainWindow.axaml` |
| 88 | + |
| 89 | +## FR-RTUI-104 2.3.1 TODO lifecycle management |
| 90 | + |
| 91 | +Users shall be able to list, filter, group, create, open, edit, save, toggle done, copy ID, and delete TODO items from UI surfaces. |
| 92 | + |
| 93 | +**Covered by:** `TodoListViewModel`, `TodoListView` (Desktop/Android), `PhoneTodoView` |
| 94 | + |
| 95 | +## FR-RTUI-105 2.3.2 TODO AI-assisted workflows |
| 96 | + |
| 97 | +Users shall be able to run requirements analysis and status/plan/implement prompt workflows from TODO context with streaming output and explicit cancellation/stop controls. |
| 98 | + |
| 99 | +**Covered by:** `TodoListViewModel`, `PhoneTodoView`, `TodoListView.axaml` (Desktop/Android) |
| 100 | + |
| 101 | +## FR-RTUI-106 2.3.3 Phone TODO drill-in navigation and back behavior |
| 102 | + |
| 103 | +Android phone TODO UX shall support list, formatted detail, and markdown edit states with back navigation that unwinds the current screen stack before exiting the tab. |
| 104 | + |
| 105 | +**Covered by:** `PhoneTodoView`, `AndroidBackNavigationService`, `MainActivity` |
| 106 | + |
| 107 | +## FR-RTUI-107 2.4.1 Workspace lifecycle and prompt editing operations |
| 108 | + |
| 109 | +Users shall be able to create/edit/delete workspaces, inspect status/health, and invoke init/start/stop operations. Workspace-level prompt templates are editable on Desktop and Android; global prompt template editing is provided on Desktop. |
| 110 | + |
| 111 | +**Covered by:** `WorkspaceViewModel`, `WorkspaceView` (Desktop/Android), `WorkspaceView.axaml` (Desktop) |
| 112 | + |
| 113 | +## FR-RTUI-108 2.5.1 Session-log explorer and request-detail inspection |
| 114 | + |
| 115 | +Users shall be able to browse session logs, search/filter indexed request rows, open request details, navigate previous/next request details, and copy request payloads. |
| 116 | + |
| 117 | +**Covered by:** `MainWindowViewModel`, `McpServerManagerView`, `PhoneSessionLogView` |
| 118 | + |
| 119 | +## FR-RTUI-109 2.6.1 Voice conversation session lifecycle |
| 120 | + |
| 121 | +Users shall be able to create/resume a voice session, submit turns (sync and stream), inspect transcript/tool calls, interrupt generation, send ESC, and end sessions. |
| 122 | + |
| 123 | +**Covered by:** `VoiceConversationViewModel`, `SimplifiedVoiceView`, `VoiceConversationView` |
| 124 | + |
| 125 | +## FR-RTUI-110 2.6.2 Android continuous voice loop and background resilience |
| 126 | + |
| 127 | +Android voice UX shall support continuous listen/send/speak operation with spoken command detection (`send now`, `start over`, `clear chat`, `pause`, `resume`, `end chat`) and background session survivability. |
| 128 | + |
| 129 | +**Covered by:** `SimplifiedVoiceView`, `AndroidVoiceAudioServices`, `VoiceSessionForegroundService` |
| 130 | + |
| 131 | +## FR-RTUI-111 2.7.1 User-managed speech filter phrases |
| 132 | + |
| 133 | +Users shall be able to manage speech filter phrases in Settings and apply them to TTS output filtering, including import from text, JSON, and YAML content. |
| 134 | + |
| 135 | +**Covered by:** `SettingsViewModel`, `SpeechFilterService`, `SimplifiedVoiceView` |
| 136 | + |
| 137 | +## FR-RTUI-112 2.7.2 Operational log inspection |
| 138 | + |
| 139 | +Users shall be able to view runtime logs with level filtering, pause/resume, copy selected/all entries, and clear logs. |
| 140 | + |
| 141 | +**Covered by:** `LogViewModel`, `LogView` (Desktop/Android) |
| 142 | + |
| 143 | +## FR-RTUI-114 2.7.3 Layout and view-state persistence |
| 144 | + |
| 145 | +Desktop shall persist window geometry/state, selected tab, chat window state, and splitter positions. Shared layout DTOs shall support orientation-aware splitter restoration. |
| 146 | + |
| 147 | +**Covered by:** `LayoutSettings`, `LayoutSettingsIo`, `SplitterLayoutPersistence`, `MainWindow`, `McpServerManagerView`, `TodoListView`, `WorkspaceView` |
| 148 | + |
| 149 | +## FR-RTUI-116 2.8.1 Agent-event surfaced status notifications |
| 150 | + |
| 151 | +The shell shall listen for actionable agent lifecycle events and surface status updates and system notifications to users. |
| 152 | + |
| 153 | +**Covered by:** `MainWindowViewModel`, `McpAgentEventStreamService`, `ISystemNotificationService` |
| 154 | + |
| 155 | +## FR-RTUI-117 2.7.4 Android crash evidence recovery and operator collection workflow |
| 156 | + |
| 157 | +Android operators shall be able to recover prior-launch crash evidence from app-managed diagnostics and collect a reproducible artifact bundle from an attached device using the documented adb workflow. |
| 158 | + |
| 159 | +**Covered by:** `AndroidCrashDiagnostics`, `MainApplication`, `App`, `collect-android-crash-artifacts.ps1`, `android-crash-diagnostics-workflow.md` |
0 commit comments