Summary
Tracking issue for the 26 actionable findings from a recent multi-axis architecture/security/code-quality/UX/extensibility/AI-ergonomics/duplication review of the Windows companion suite. Each finding has its own issue with full context, source citations (file_path:line_number), and a proposed fix.
The review was conducted by seven parallel senior-engineer sub-agents, each assigned one axis, each given the same shared context document with framework lineage (MFC → WinForms → WPF → UWP → WinUI 3) and comparables (Adaptive Cards, MCP reference, Discord/Slack tray-app pattern, AppLocker, iOS App Intents, Avalonia).
Issues by category
Critical / High-priority bugs (12)
Architectural / Structural (10)
Code duplication / "AI slop" (8 — two further duplication items consolidated into C2 and A5)
Suggested order of attack
The deep review proposed a 3-phase plan:
Phase 1 — Stop the bleeds (1-2 weeks): C1, C2, C3, C4, C5, C6, C7, C8, C9, C11, C12. Concrete bugs, small/medium changes.
Phase 2 — Hygiene and discoverability (1 month): A2, A3, A4, A5, A6, A8, A9, A10, C10, D1-D8.
Phase 3 — Keystone refactor (1+ quarter): A1 (introduce GatewayDataStore between ConnectionManager and UI). Once A1 is done, the single-instance pipe (C6 long-term fix), A7 RTL plumbing, and the App.xaml.cs split all become tractable.
Methodology
- Seven sub-agents reviewed in parallel: architecture, UX, extensibility, AI ergonomics, code quality, security (STRIDE), duplication.
- Each was told to verify against code, not slice docs, and to cite
file_path:line_number for every finding.
- Each was given a shared context document with framework lineage and comparables to avoid duplicate research.
- Output: seven slice docs in
docs/architecture/deep-review/ plus a synthesized root summary.
- No code changes were made as part of the review.
Open questions for the maintainer
The review couldn't decide these from code alone:
- Is the V2 exec coordinator on a near-term roadmap? Several findings (D3 wrapper duplication, parts of A5) dissolve once V2 ships.
- Was a per-role Ed25519 keypair (operator vs node) considered and rejected, or just not implemented?
- Why named-mutex + pipe rather than
AppInstance.FindOrRegisterForKey (which the codebase already uses for protocol activation)?
- Does Updatum verify Authenticode internally (C4)? Tray-side handlers don't.
- Does anything depend on
_useV2Signature persisting across reconnects (C10 unblocker)?
Summary
Tracking issue for the 26 actionable findings from a recent multi-axis architecture/security/code-quality/UX/extensibility/AI-ergonomics/duplication review of the Windows companion suite. Each finding has its own issue with full context, source citations (
file_path:line_number), and a proposed fix.The review was conducted by seven parallel senior-engineer sub-agents, each assigned one axis, each given the same shared context document with framework lineage (MFC → WinForms → WPF → UWP → WinUI 3) and comparables (Adaptive Cards, MCP reference, Discord/Slack tray-app pattern, AppLocker, iOS App Intents, Avalonia).
Issues by category
Critical / High-priority bugs (12)
WindowsNodeClientleaksex.Messageto gateway, defeats Stt privacy invariantNodeService.ShowToastbypasses user sound preferences for capture/recordCardBackgroundtheme override parsed but never appliedopenclaw://agent?message=…sends chat with no UI confirmationPipeSecurity/PipeOptions.CurrentUserOnlysystem.execApprovals.setvalidator accepts arbitrary path Allow rulesapp.settings.setover MCP accepts arbitrary keys without validationws://gateway URLs accepted with no TLS warningtools/listRecordingConsentDialogis aWindowEx, notContentDialog— fails assistive techArchitectural / Structural (10)
App.xaml.cs(4617 lines) has become the gateway data storetools/listships permissiveinputSchemafor every toolComponentRendererRegistryctor isinternal— no 3rd-party renderersCancellationTokencontract exists butWindowsNodeClientnever passes oneTryGetPropertywalksAutomationIdtest hooks but only 3AutomationProperties.Nameinitializehas noinstructions;skill.mdinvisible to MCP clientsdotnet format, noDebug.AssertWindowsNodeClientsingle-threaded receive loop has no back-pressureCode duplication / "AI slop" (8 — two further duplication items consolidated into C2 and A5)
CopyTextToClipboardduplicated across 17 sitestry/catchblocks across 41 files_useV2Signaturestate machine duplicated across both WS clientsModels.cs(1972 lines) contains ~700 lines of non-DTO helpersDeepLinkActions+AppCapabilityare same delegate-per-verb pattern twiceJsonSerializerOptionssingletons with drifted defaultsSuggested order of attack
The deep review proposed a 3-phase plan:
Phase 1 — Stop the bleeds (1-2 weeks): C1, C2, C3, C4, C5, C6, C7, C8, C9, C11, C12. Concrete bugs, small/medium changes.
Phase 2 — Hygiene and discoverability (1 month): A2, A3, A4, A5, A6, A8, A9, A10, C10, D1-D8.
Phase 3 — Keystone refactor (1+ quarter): A1 (introduce GatewayDataStore between ConnectionManager and UI). Once A1 is done, the single-instance pipe (C6 long-term fix), A7 RTL plumbing, and the
App.xaml.cssplit all become tractable.Methodology
file_path:line_numberfor every finding.docs/architecture/deep-review/plus a synthesized root summary.Open questions for the maintainer
The review couldn't decide these from code alone:
AppInstance.FindOrRegisterForKey(which the codebase already uses for protocol activation)?_useV2Signaturepersisting across reconnects (C10 unblocker)?