Mission has one authoritative backend runtime: open-missiond. Open Mission surfaces are daemon clients; they do not own Mission truth, workflow truth, repository truth, Agent execution truth, or command semantics.
Mission has one Open Mission app model. packages/app owns Open Mission-facing application models, view contracts, and state shaping over daemon truth. It is not a Svelte package, a Tauri plugin layer, a browser state store, or a host compatibility package.
Mission exposes these Open Mission native hosts over that one application model:
apps/webfor the SvelteKit web host and web-specific backend facadeapps/nativefor the Tauri native host
The web and native hosts are not separate products. They must share the Open Mission app route model, component model, application state model, query semantics, command semantics, and subscription semantics unless a feature is inherently host-specific. Host-specific APIs sit behind adapters.
The SvelteKit backend is a backend-for-frontend for browser delivery. It may own remote functions, request-scoped web orchestration, web subscription endpoints, and optional web session concerns. It is not the canonical system boundary and must not replace daemon or Open Mission contracts.
For ordinary browser request-response application behavior, the preferred and default SvelteKit boundary is remote functions. New query and command surfaces must be introduced as .remote.ts functions rather than traditional +server.ts JSON endpoints. +server.ts routes are reserved for cases where remote functions are not the right transport shape, such as SSE subscriptions, WebSocket upgrade companions, auth callbacks and redirects, binary or streaming proxy responses, or similarly explicit transport seams. If a new +server.ts route is proposed for routine application data exchange, the design is presumptively wrong unless an ADR or task-specific doctrine records the exception.
The native host owns native packaging, windowing, permissions, native capability wiring, and native daemon launch or supervision when needed. It should prefer direct daemon RPC or a thin Tauri bridge for core application data and commands when practical. It must not redefine business actions, Open Mission app pane view rules, or Open Mission semantics.
The shared UI must depend on an abstract Open Mission app client with query, command, and subscription capabilities. It must not depend directly on fetch, SvelteKit remote functions, Tauri APIs, or terminal substrate APIs for domain behavior.
Inside a client process, Open Mission host code must materialize shared client-side Entity instances inside one Open Mission application context. That application context is the single source of truth for client-local Entity state, selection inputs, derived pane state, and other shared view data built from daemon-backed reads, commands, and subscriptions. Components may read from that context and request mutations through it, but they must not create parallel Entity caches, run competing reconciliation logic, or own duplicate business state for the same Entity.
.svelte components are view surfaces over the Open Mission application context Entities. They may render, collect operator input, and call model-layer methods or host adapters, but they must not own query orchestration, domain reconciliation, canonical Entity mutation rules, or cross-component truth for Entity-backed state. Shared behavior belongs in the Open Mission app model layer and its client-side Entity classes, not in renderer files.
Component script blocks must stay minimal. When Entity or application-context instances already expose reactive $state, components should render and bind those properties directly in markup instead of creating loose $derived mirrors for the same values. .svelte.ts modules are the place for reusable reactive behavior and view-model helpers. $effect, $effect.pre, $derived, and $derived.by should be used sparingly and only when they express a real side effect or calculation that is not already represented by the application context Entity graph. Components must not use effects to continually write back into Entity-backed state, because that creates duplicate reconciliation paths and can produce update loops.
This does not make the client the cross-surface authority. The daemon remains the authoritative domain runtime and source of shared Mission truth across clients. The Open Mission application context is the single source of truth only within one client host process, so that all components in that process observe one coherent Entity graph instead of maintaining parallel local copies.
Repository package boundaries follow from this decision:
packages/coremust not absorb UI framework code.packages/appmust not absorb renderer-specific framework code.apps/webmust not become the daemon authority.apps/nativemust not become a second frontend implementation.
New Open Mission work must converge on one shared Open Mission app model with host adapters rather than preserving host-specific application forks.