Server sync is a lifecycle, not a fetch

The visible failures looked unrelated:

• A model dialog opened with no models.
• The provider dialog showed only the custom OpenAI-compatible entry.
• A missing Session escaped the Session route and reached the renderer error boundary.
• A reconnect could leave model, tool, and location data stale.

They had one common cause. The app treated server state as independent HTTP results. The V2 server exposes one ordered lifecycle. The event-stream handshake, query ownership, catalog projection, reconnect, and route error boundary must agree about that lifecycle.

The contradiction that found the catalog bug

The live Electron app gave a useful contradiction.

GET /api/provider, GET /api/model, and GET /api/model/default all returned 200. The model control also rendered. That control only rendered after its direct provider queries had reached isSuccess. However, ModelsProvider and useProviders() still returned an empty catalog.

This excluded the server response and the normalizer. The loss occurred between the TanStack query observer and the child-store projection.

The relevant flow was:

server.connected
  -> enable directory query
  -> loadProvidersQuery()
  -> TanStack query result
  -> child.provider_ready / child.provider
  -> useProviders()
  -> ModelsProvider
  -> LocalProvider
  -> prompt control and dialogs

The prompt control and the model list did not use the same readiness source. The prompt control created two extra query observers. The model list read the child-store projection. One path could say “success” while the other path still said “empty.”

This PR makes the child projection the single source for both readiness and data.

The TanStack contract

The primitive choice matters here.

TanStack Solid Query documents createQuery options as reactive. Signal reads must occur inside the options accessor:

const query = createQuery(() => ({
  ...options(directory()),
  enabled: connection.status() === "connected",
}))

This is the correct primitive for server state that belongs to a mounted Solid owner. A connection-status change updates enabled, and TanStack starts or stops automatic query work from that state.

TanStack also documents two facts that are easy to combine incorrectly:

1. A disabled query with no data has status: "pending", fetchStatus: "idle", and isLoading: false.
2. data is a Solid resource. A read can activate Suspense when data is not available.

Sources:

• Reactive query options
• Disabled query states
• data as a Solid resource
• Shared queryOptions
• Imperative QueryClient methods

The old readiness check used !isLoading. That is true for a disabled query with no data. An intermediate fix used data !== undefined. That reads the resource to answer a status question.

The final projection uses status fields for status:

const ready = query.isSuccess || query.isRefetchError

It reads query.data only after that guard. isRefetchError keeps valid cached data visible when a background refresh fails.

This matches the purpose of each primitive:

Solid preserves getters on createStore. Reads inside a getter remain tracked. The previous global-provider fallback did not use a getter. It copied globalStore.provider once, usually while it was empty. The child store could never observe a later global catalog. The PR passes a live getter instead.

Source: Solid createStore getters

One query cache and one key

The old provider tree had two nested QueryClientProvider instances. Long-lived server contexts were created under one client. Route controls and dialogs could use the other client. A refetch could update a cache that ModelsProvider did not read.

The PR keeps one QueryClient at the app base. Server contexts, route controls, and dialogs now share it.

Windows exposed a second identity split. The live netlog showed both forms:

C:/Repos/sst/opencode
C:\Repos\sst\opencode

Those strings produced different query keys. A successful response under one key did not prove that the observer under the other key had data. Directory bootstrap now uses the same pathKey normalization as the child observer and prompt control.

After the fix, the cold-start netlog contains only the forward-slash key for that directory.

The event stream is the admission gate

V2 catalog and location data can change while plugins and integrations initialize. Starting queries before the event stream is connected creates a gap:

HTTP bootstrap starts
  -> server state changes
  -> event is emitted with no active consumer
  -> HTTP result becomes stale

ServerSDK now owns the stream lifecycle. It requires server.connected as the first event. Only then does connection.status() become connected.

Global and directory queries use that status in their reactive enabled option. Reconnect follows the same sequence:

stream closes
  -> status = reconnecting
  -> new stream starts
  -> first event must be server.connected
  -> status = connected
  -> pinned Sessions and active catalogs refresh

Catalog events invalidate the exact server and directory key. Location events refresh location, VCS, skills, web search, and shell data for the affected directory. Different directories remain independent.

queryClient.fetchQuery is intentional in this event path. This work is imperative. A server fact changed, so the cache must load a new snapshot. UI ownership still uses declarative createQuery.

“Available providers” is not “providers that can be connected”

The empty provider dialog had a second defect.

/api/provider returns providers that are available to the model catalog. It is not the provider-definition inventory. The connect dialog used that response as if it contained all integrations.

The correct source is /api/integration.

The new loadIntegrationsQuery() uses the same server scope and normalized directory key as the catalog query. useIntegrations() owns it with createQuery. The connect dialog and the unpaid-model dialog use that list. The selected integration still resolves its current methods through integration.get.

The live local server returned:

integration count: 185
featured integrations:
  anthropic
  google
  openai
  opencode
  opencode-go
  openrouter
  vercel

The model list continues to use /api/provider plus /api/model. This separation is important:

Integration list: what the user can connect
Provider/model catalog: what the user can run now

Integration and catalog events refresh both caches.

Session events use the same lifecycle

The stream adapter now carries current V2 events into the app projection. ServerSession applies current Session events, pending inputs, forms, messages, and transient state. Transient hydration records a revision before its HTTP load. A newer stream event changes that revision, so an older HTTP result cannot overwrite the event projection.

On reconnect, pinned Sessions refresh. Active Session status is reconciled in both directions. A Session that is absent from the active response becomes idle. A Session that is present becomes busy.

The event consumer also batches adjacent text, reasoning, tool-input, and compaction deltas. It keeps event order while it reduces render work.

Missing Sessions belong to the Session route

A target Session can fail before TargetSessionRouteContent mounts. For example, target-server providers can resolve a stale Session ID during provisioning.

The old Session error boundary was inside that provisioning subtree. A typed SessionNotFoundError could bypass it and reach the root renderer boundary.

The route now has two boundaries:

outer Session boundary
  -> target server provisioning
     -> inner Session boundary
        -> target directory and Session UI

The outer boundary catches provisioning failures. The inner boundary keeps the existing target-scoped recovery behavior. Both use the same typed Session-not-found predicate.

Local development identity

The desktop development script already set OPENCODE_CHANNEL=local. The desktop Vite config accepted local, but the shared app Vite plugin did not. It replaced the value with dev.

The shared plugin now accepts local. A cold bun dev:desktop start shows LOCAL, uses a 2.0.0-local-* server version, and keeps the local channel database.

Evidence from the real process

The investigation used the running Electron renderer and its real sidecar. It did not use mocked server state.

The cold-start renderer showed:

channel: LOCAL
model control: Big Pickle
control type: popover

The live model menu contained OpenCode, OpenAI, and Google groups. The real integration query returned 185 entries. The netlog showed normalized provider and model URLs. App type checking completed after the final upstream merge.

Earlier focused checks on this branch also covered the server SDK, Session projection, global sync reducers, catalog invalidation, and browser model-selection flow. No public Protocol or Server HttpApi changed in this PR. The generated client is only consumed through its existing integration API.

Result

The app now has one reproducible rule:

The event handshake admits server queries. TanStack query status admits payload reads. The child projection admits UI controls.

Each boundary has one owner, one key, and one reactive source. That removes the state in which HTTP says “success,” the control says “ready,” and the dialog still says “empty.”