feat(mobile): plan mode (legacy) toggle with cross-client sync - #6614

💭 I'm scanning the diff for Effect service convention violations, focusing on files that touch Effect services like the orchestration module, synced client preferences contract, mobile state, web hooks, and the migration files. I'm checking import patterns, starting with whether "effect" imports are properly consolidated in the preferences file. Imports look consistent across the mobile model file too. I don't see any new Effect service definitions being introduced—the PR extends an existing pre-existing shape interface rather than creating new ones, and error handling reuses the existing OrchestrationGetSnapshotError class rather than adding new error types. I'm now checking whether the mobile outbox drain hook's use of a module-global atom registry read counts as a hidden dependency issue, though it's React/atom code rather than Effect service code. I'm tracing through DateTime usage and schema predicate exports across the contracts, normalizer, and mobile/web preference files, checking whether any of the Schema.is predicate exports are wrapped redundantly instead of being exported directly as the convention requires. That decode function throws on invalid input rather than returning a result type, and similarly there's a plain throw in createSyncedClientPreferencesWrite for missing planModeEnabled — these are pure functions throwing rather than Effect service issues per se. Now I'm turning to the bigger concern: production service construction needing to acquire Effect dependencies from the environment rather than hiding them in module globals, which touches on ManagedRuntime.make and runPromise usage. I want to check use-thread-outbox-drain.ts, where readPlanModeEnabled reads from the appAtomRegistry global, to see whether that registry was already imported there before this diff added the preferences lookup. I should look at the actual files rather than speculate further. I also want to check ProjectionSnapshotQuery.ts, which adds getSyncedClientPreferences to a service whose shape is defined separately as ProjectionSnapshotQueryShape — conventions prefer inlining the interface in the Context.Service declaration rather than keeping a standalone Shape type, though this split between Services/ and Layers/ predates the PR. Since the instructions only flag unrelated repository-wide cleanup and this is just adding a method to an existing shape using the established pattern, I don't think it's worth flagging — it's consistent with how the service is already referenced elsewhere (ProjectionSnapshotQuery["Service"]["getSyncedClientPreferences"]). The new syncedClientPreferences.ts file in client-runtime looks fine — just pure helper functions with named imports. But useSettings.ts in apps/web concerns me more: it creates a module-level mutable controller (syncedPlanModeHydrationController) and a clientSettingsPersistenceQueue outside any React hook, which could run into the "don't hide dependencies in module globals" guidance even though these are hooks rather than Effect services. Similarly, apps/mobile's synced-client-preferences.ts has a module-level mutable variable used as a memoization cache inside an Atom.make call — again not an Effect service, so probably out of scope. I want to check for any Layer.succeed, ManagedRuntime, or runPromise additions elsewhere; I see OrchestrationEngine.test.ts uses runtime.runPromise, but that's just test harness usage, which is allowed. I should also check use-thread-outbox-drain.ts, which adds a readPlanModeEnabled() function reading from a global registry — I want to verify whether appAtomRegistry is already used in that file before flagging anything. Let me pull up these files directly to confirm. The appAtomRegistry pattern looks established, so that's fine. I'm now checking the server side for new service definitions, error classes, or Layer.succeed additions, but the diff doesn't show any of those. I'm also looking at which new files were created, like the pure new-task-submit module in the threads feature. I'm checking the remaining new files: the thread composer send logic, the synced client preferences model and hooks, the plan mode hooks, the client-runtime and contracts modules, and a new server migration file. None of these introduce a new Context.Service. I'm verifying the import paths used across these files—checking that effect subpath imports like DateTime, Option, Schema, and Struct are all correctly referenced, and confirming the web hooks file imports Atom from the reactivity subpath correctly. I'm also confirming the server-side projector and migration files use proper imports, and checking whether any new error types were introduced—finding none. Now I'm looking at the websocket handler code that queries synced client preferences and maps errors. The error handling wraps failures into an OrchestrationGetSnapshotError with a descriptive message, and returns a similar error if the preferences projection is missing after patching. Since this error class already exists with a message field, I want to verify this matches the established pattern elsewhere in ws.ts before moving on. This matches existing patterns, so it's not worth flagging. I'm also checking the mobile synced-client-preferences file for a module-level mutable cache used inside an atom — it's a bit smelly but since the atom itself is a singleton, it's probably fine and outside the scope of this check. I'm verifying the server.ts addition uses the same command pattern as its siblings, which checks out. I'm also scanning the diff for Effect error-handling wrappers and import conventions — checking that Effect modules are imported as namespaces from subpaths rather than consolidated named imports from "effect", and I don't see any violations there. The mobile preferences store follows the canonical service-module pattern with its error classes already established pre-existing in the codebase. Looking at a couple of return-type removals in the diff — one in the legacy plan mode hook and one in the orchestration engine's command-to-aggregate-ref function — neither seems to violate any Effect service convention, just simplified type inference. I'm now double-checking dependency acquisition boundaries, looking at module-level singleton controllers in the web and mobile preference hooks, but these aren't Effect-related either. I'm also examining whether the PR's change to the projection snapshot query service — adding a method to its standalone shape interface — counts as "refactoring" an Effect service under the conventions, which would require inlining that shape into the Context.Service declaration. But enforcing that broadly could amount to unrelated repository-wide cleanup if the Services/Layers split pattern is used consistently elsewhere, so I want to check how widespread that structure actually is before flagging it. The Services/Layers split is a widespread legacy pattern across the repo, so it's not something to flag here. I'm doing one more pass over the diff to check for genuine Effect service convention violations, looking specifically at the imports in the synced client preferences model file for mobile state. The type-only imports and named imports from pure helper subpaths both match allowed patterns. Checking the web hooks file, the package.json export, and the barrel file in contracts — the barrel exports the syncedClientPreferences module with export *, but since that module isn't a service, the "export * as TokenStore" convention for service barrels doesn't apply here. I notice a duplicated constant between the server normalizer and a mobile state file, but that's just duplication, not a convention violation. Given there's nothing substantive to flag, I'm now wrestling with how to reconcile the instruction to respond with exactly "All clear" against the requirement to produce structured JSON output — I'll resolve this by putting "All clear" in the summary field while setting the state to success. I'll finalize the structure: state as success since there are no findings, title noting no issues found, summary as "All clear", and an empty details field. No review comments are needed since there's nothing to flag.