Changelog

The incremental skip logic only checked if the plugin DLL existed,

not whether all NuGet dependencies were present. If a previous

publish was interrupted or the output directory was manually

modified, subsequent --with-plugins runs would skip the plugin

thinking it was up-to-date, leaving it deployed without transitive

dependencies (e.g. Avalonia.HtmlRenderer for the Email plugin).

Add a DLL count check: if the output directory has only the plugin

DLL itself (no transitive dependencies), force a republish.

Server SDK passthrough logs were all at Debug level, but the minimum log

level is Information — making them completely invisible. Changed all 16

SDK log calls from Debug to Information so server activity is visible.

Also fixed RegistryUpdateService using stale static readonly ILogger

(same ForContext pattern that killed PluginRegistry logging after

workspace switch).

Server side (LocalApiServer):

• /sdk/execute: logs action, entity_type, response size, and timing
• /sdk/register-entity-type: logs entity type at Information level
• /sdk/search: logs response size and timing
• Vault/blob operations: logs operation and vault/blob IDs
• DB maintenance: logs operation and timing
• Fixed stale logger (static readonly → property)

Client side (HttpSdkTransport):

• All POST/GET requests: logs timing via Stopwatch
• Slow requests (>500ms): logged at Warning level
• Failed requests: includes elapsed time for diagnosing timeouts

Log format uses [SDK] prefix on server and [Client→Server] on client

so both sides are easily grepable in the shared log file.

In client mode, every SDK call is an HTTP roundtrip (~100-300ms each).

Sequential execution of 30-45 calls during startup and 20-30 calls for

Dashboard metrics caused 5-10 second load times.

Two parallelization changes:

1. Plugin initialization: Split DiscoverAndInitialize into two phases.

Phase 1 (serial): vault unlock, host creation, schema registration

— these are fast and may touch shared state. Phase 2 (parallel):

InitializeAsync on all plugins concurrently via Task.WhenAll — each

plugin is independent and the SdkHost's ReaderWriterLockSlim allows

concurrent reads.

2. Dashboard metrics: SystemMetricsService.GetDataMetricsAsync now

fetches all IDataMetricsProvider results via Task.WhenAll instead of

sequential foreach+await. This turns 11 sequential plugin queries

into parallel HTTP calls.

Both changes are safe for standalone mode (FFI calls are fast, so the

parallelism just adds minor thread pool overhead with no UX impact).

CommunityToolkit's AsyncRelayCommand disables the command while it's

executing, preventing concurrent calls. In client mode, SelectTab awaits

plugin.OnNavigatedToAsync() which makes HTTP SDK calls to the server —

these are much slower than local FFI calls. While the first SelectTab

is waiting on the HTTP response, all sidebar buttons bound to the same

SelectTabCommand are disabled (greyed out) because CanExecute returns

false during execution.

Fix: AllowConcurrentExecutions = true on SelectTab, matching the

expected behavior where rapid tab switching should always work.

Also fix HttpSdkTransport stale logger (same pattern as PluginRegistry:

static readonly ForContext becomes dead after ReconfigureForWorkspace).