fix(mobile): reduce dev-client reload and Metro startup cost - #8694

💭 I'm reviewing the diff for Effect service convention violations, focusing on the runtime and state management files in the mobile app connection and atom registry areas. I want to check whether the hot-swappable atom runtime's global map of runtimes keyed by id conflicts with the rule against creating per-feature managed runtimes to smuggle owned resources into multiple consumers, though this looks like dev-only HMR support. I also need to check what runtime refers to in the disposal call within apps/mobile/src/lib/runtime.ts, and confirm the Scope.fork change in the registry is a safe behavior change backed by a test. Let me pull up these files to verify.

1. browse_code — apps/mobile/src/lib/runtime.ts

2. browse_code — apps/mobile/src/connection/runtime.ts

💭 These look like application boundary modules where ManagedRuntime.make is expected. The registry.ts change forking a scope looks like a legitimate behavior change backed by a test. Checking remote-environment-projections.ts now, which just uses Atom with module-level closures for memoization rather than Effect services. The Atom.family memoization via closure state isn't really an Effect service convention issue, and the hot-swappable-atom-runtime.ts's global Symbol map for HMR registry seems borderline but acceptable since it's a single connection runtime, not smuggling shared resources across consumers. I don't see any new error classes in the diff, so nothing to flag there. Now I'm checking the imports in hot-swappable-atom-runtime.ts against repo conventions. I confirm the import style matches other files like connection/runtime.ts, and the test files follow consistent patterns except remote-environment-projections.test.ts, which uses a different test import than the rest — not something I need to address. The AGENTS.md guidance about avoiding tests that merely assert callback wiring or mirror implementation doesn't apply here since home-thread-navigation.test.ts covers genuine new behavior. Now I want to look at registry.ts in client-runtime to see how the Scope change is handled there.

3. browse_code — packages/client-runtime/src/connection/registry.ts

💭 That looks conformant, with make correctly acquiring dependencies from the environment. Checking the mobile state files next, the atom factory pattern in the projections file looks fine since it's dealing with pure atoms rather than services, and the fast-refresh utility just uses a promise-based dispose pattern without touching Effect services. Actually, dispose returning a Promise at a dev hot-refresh module boundary should be acceptable per the runtime boundary rule. The hotSwappableAtomRuntime helper also just creates a runtime atom from a layer atom, nothing service-defining there. I'm now scanning imports across the new files to confirm they consistently use namespace imports from effect subpaths, and checking how AtomRegistry is imported and used elsewhere in the repo for consistency. I don't see any violations of the service conventions so far. The connection atom runtime correctly composes its context from the app-level ManagedRuntime rather than spinning up a duplicate runtime, which matches the rule about not smuggling owned resources through separate runtimes. I'm now examining whether module-level mutable state in an Atom.family closure could leak previous values across separate registries in tests, since the family memoizes per environmentId. There's shared closure state across registries, but that's a general state-management concern rather than an Effect service convention issue, so I won't flag it. I'm double-checking that the diff introduces no new Layer.succeed or ManagedRuntime.make calls inside service constructors, and confirming the duplicated hot-module type declaration across three files is just a style repetition, not a convention violation. I feel confident the changes are clean on this front. Checking the runtime layer usage in hot-swappable-atom-runtime.ts looks fine, requiring AtomRegistry and Reactivity as expected. I'll do a quick grep to see if there's a convention requiring namespace imports for effect/unstable/reactivity.

4. git_tools — from "effect/unstable/reactivity"

💭 Everything checks out consistently, no violations found.