Changelog

The "Add Project" flow previously required the user to manually type

their GitHub username and click "Load Projects" — even though they're

already authenticated. Now it auto-fetches the viewer's login via

GraphQL and loads their projects immediately on open.

The UI is restructured: project list appears first as the primary

content, with a "Load from a different account" section below for

switching to an org or different user.

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.

The "Add GitHub Project" picker and the source list were both visible

simultaneously because State 1 (source list) only checked !IsAddingSource,

not !IsAddingProject or !IsConfiguringFilters. Added a computed

IsShowingSourceList property that correctly hides the source list and

footer buttons whenever any sub-state (repo picker, project picker,

filter config) is active.

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).