[deep-review][duplication] D6: DeepLinkActions and AppCapability are the same delegate-per-verb pattern open-coded twice

[codemonkeychris]

Summary

Two places in the codebase implement the same "delegate-per-verb registry" pattern with no shared abstraction:

1. DeepLinkActions — a struct in src/OpenClaw.Tray.WinUI/Services/DeepLinkHandler.cs:269-301 with 28 delegate fields (OpenSettings, OpenChat, RunHealthCheck, CopyDebugBundle, ...). Wired in App.xaml.cs:4286-4324 with a ~200-line new DeepLinkActions { ... } initializer block. Dispatched via switch in DeepLinkHandler.Handle (DeepLinkHandler.cs:54-266).

2. AppCapability — at src/OpenClaw.Shared/Capabilities/AppCapability.cs, with 10 public mutable Func<...>? fields. Wired in App.xaml.cs:WireAppCapabilityHandlers with a similar bulk assignment. Dispatched via 13-arm switch inside AppCapability.ExecuteAsync.

Why it matters

Three problems:

1. Open-coded ten ten times — adding a new deep-link verb is: add a field to DeepLinkActions, add a case to the switch in DeepLinkHandler, add a => ... in the wiring block in App.xaml.cs. Three sites for one verb. Same for AppCapability.
2. Public mutable fields — AppCapability's ten public Func<...>? fields can be reassigned anywhere in the AppDomain. Testable but not safe.
3. No discoverability for callers — the deep-link dispatch table lives in DeepLinkHandler.Handle, but the contract (what each action does) lives in App.xaml.cs. Splitting the action from its implementation makes the surface harder to read.

Proposed fix

A small IDispatchRegistry<TVerb, TArgs, TResult> abstraction:

public interface IDispatchRegistry<TArgs, TResult>
{
    void Register(string verb, Func<TArgs, TResult> handler);
    TResult Dispatch(string verb, TArgs args);
    bool IsRegistered(string verb);
}

Migrate DeepLinkActions and AppCapability to use it. Side benefit: the dispatch site becomes table-driven, so adding a verb is one Register call instead of three edits.

For AppCapability: this also addresses the public-mutable-field smell. Handlers are registered through Register, not assigned to fields.

Lower-priority alternative: introduce a [DeepLinkAction("settings")] attribute and source-generate the dispatch table.

Severity

Low — code-shape smell, not a bug. Becomes Medium next time someone adds a deep-link verb.

[github-actions]

---

Note

The pull request was not created — a fallback review issue was created instead due to protected file changes: #431

🤖 This is an automated response from Repo Assist.

The IDispatchRegistry abstraction is sound, but it's worth flagging one practical concern before committing to it: the two patterns have different type shapes.

• DeepLinkActions has 28 mostly-distinct delegate signatures (some take string, some CancellationToken, some are Func<string, Task>, some Action, etc).
• AppCapability has 10 fields, but they're similarly heterogeneous.

A generic IDispatchRegistry<TArgs, TResult> would only help if you constrain handlers to a single signature (e.g. everything becomes Func<JsonElement, CancellationToken, Task<JsonElement>>). If you try to preserve the distinct signatures, you end up boxing through object delegates and losing type safety.

Two lower-risk alternatives worth considering:

1. Source-generated dispatch — a [DeepLinkAction("settings")] attribute on a method, with a Roslyn source generator that emits the switch at compile time. The wiring block in App.xaml.cs becomes zero LOC. The switch in DeepLinkHandler becomes a generated partial method. This keeps distinct signatures, adds discoverability, and removes the three-site requirement. Complexity cost: writing the generator (or using System.CommandLine as a model).

2. Staged cleanup — don't unify the two patterns yet. First, replace AppCapability's public mutable fields with a Register(string verb, Func<JsonElement, CancellationToken, Task<JsonElement?>> handler) API (internal to the assembly), keeping the existing dispatch switch intact. This fixes the mutable-field smell without requiring a shared abstraction. Then revisit unification after you've seen whether the two registration sites actually share a natural common shape.

The three-edit problem for DeepLinkActions is real, but a [DeepLinkAction] attribute-based approach would solve it more ergonomically than a runtime registry.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[shanselman]

Closing during the post-refactor deep-review cleanup. Delegate-pattern duplication is consolidated into #372 as architecture debt. This keeps the signal while reducing stale one-off issue noise.