Framework Integration

OpenStation App Framework integration

Fleet 0.9.0-rc.1 was audited against OpenStation commit 9bac9176b26a6228e3e57c9a7c8f11f586063afd. The current 0.10.0 release was also tested against OpenStation PR #763, exact commit a48d37b8bfdc6453056eb9345ff610c396a71e15, based on released OpenStation 1.1.6. Fleet's saved-instance regression passed with that commit on September 4, 2026.

PR #763 is still open and is not part of a released OpenStation build. These are exact compatibility references, not a guarantee that another package carrying the same version string includes identical framework code.

Framework feature	Fleet use
App discovery and .os.php manifests	Native hub and per-site apps; no classic fallback
State schemas, mount parameters, capabilities	Independent site/window identity and guarded actions
Tabs and title/menu actions	Site workspaces, refresh, hub navigation, repair/disconnect
Shared server transport, morphing and loading	Remote forms and actions; no custom AJAX controller
Native os-table, property binding and row events	Post/page lists with stable keys and accessible selection
Os::page()	Bounded remote collection pagination
Native forms/selects/buttons/save status	Editor, filters, setup, and unsaved-state feedback
Public loadComponents()	Preloads the shared control kit before server-rendered controls arrive; no bundled copy
Declarative confirmation, notices, toast effects	Destructive actions and results
Watch/announce	Fleet-scoped changes refresh the hub; remote post IDs are not announced as hub post IDs
Window lifecycle/confirmation API	Unsaved-content close guards and separate named instances
Theme tokens and bounded sizes	Shell-consistent surfaces without full-width windows

Deliberate non-uses

• In-process WordPress REST helpers target the hub. Fleet keeps its authenticated remote client so a managed-site save cannot accidentally write to the hub.
• Client .os.ts views, local state slicing, createPagedList(), and preserved-table synchronizers suit browser-owned datasets. Fleet's remote pagination needs a server request; its server view uses Os::page() instead of adding a redundant client store/build system.
• Presence, AI tools, games, wallpapers, and desktop layout ownership do not serve Fleet's current management workflow. Using every API indiscriminately would add weight rather than integration quality.
• No polling loop is added to open windows. WP-Cron handles summaries, with explicit user refreshes and framework change notifications.

The experimental dependency remains a launch gate. Cold component-import warnings appeared under load; Fleet now requests its controls through the public loader before markup arrives. Browser tests wait for the framework's actual content-ready/action-complete state, not merely an existing window header. Final candidate verification is recorded in Load testing.

Fleet CI pins the exact PR #763 commit while the fix is unreleased, then runs a mandatory saved multi-window identity regression. Replace that pin with the released containing commit after upstream merges and publishes the change. Fleet's pass does not replace the OpenStation project's own review, required checks, or release process.

Fleet's own Composer and npm audits were clean. The separate trunk build reported dependency advisories during installation; these were not triaged or changed as part of Fleet work. They are not findings against Fleet's PHP ZIP, but the dependency owner should assess them when choosing a supported public OpenStation build.

Sources: App Framework contract, JavaScript API.

Core health compatibility

Fleet deliberately excludes Core's authorization-header health probe: it compares the request against the literal user:pwd header supplied by Core's cookie-authenticated admin test. A real Application Password therefore produces an invalid-header warning even while authenticating correctly. Fleet relies on actual credential introspection and authenticated API results, not that incompatible probe. Other health tests remain visible. WordPress source.

Status refreshes verify /wp/v2/users/me?context=edit&_fields=id,capabilities, including manage_options. A successful public API index alone is not proof that a credential still works. Core does not enable batch access to /users/me, so this is one small separate request; content summaries remain batched. Requesting a nested capability through _fields does not reliably return the dynamically keyed capability map, so Fleet requests the complete capability field and inspects it server-side.