I found no blockers. The change keeps every RPC method, auth scope and middleware it had before, and costs nothing at runtime.

**Reviewed:** [#23813](https://git.cafe/pingdotgg/t3code/pulls/23813) (GitHub [#23813](https://github.com/pingdotgg/t3code/pull/23813)), head [de44c6e1b7](https://github.com/pingdotgg/t3code/commit/de44c6e1b7bee2bb7d41e124bdf8c22b8911075c), against merge-base [22840ab943](https://github.com/pingdotgg/t3code/commit/22840ab943b8418744b48223411e46ba4fdcef1a). The diff only touches `apps/server/src/ws.ts` (+28/−3). I read committed objects only, plus the vendored effect@4.0.5 source.

**Each method lands in exactly one partition**
- `SplitWsRpcGroup` and `OtherWsRpcGroup` are both built from `ServerWsRpcGroup.requests.values()`, filtered by `isSplitWsRpc` and its exact negation `!isSplitWsRpc`. Every RPC goes to one side, and none to both.
- The type-level split matches the runtime split. The type uses `` `${prefix}.${string}` `` and the runtime checks `startsWith(`${prefix}.`)`, so a name like `serverBrowser.*` stays in the "other" group in both.
- From the contract's string-literal prefixes, the split is roughly 100 vs 98 out of the 198 RPCs (server 39, pullRequests 33, orchestration 16, provider 14). That is balanced.
- The handler object is still built with `ServerWsRpcGroup.of({...})`, so a missing handler is still a type error over the full group. The two `Pick<...>` assignments only narrow it.

**Middleware and auth: no lost guard**
- `RpcScopeAuthorization` is attached at `WsRpcGroup = RpcGroup.make(...).middleware(RpcScopeAuthorization)` (`packages/contracts/src/rpc.ts:2081`). `RpcInstrumentation` wraps it in `ServerWsRpcGroup` (ws.ts:550). `.middleware()` copies onto each Rpc object, and the partitions reuse those same Rpc objects, so both keep both middlewares.
- More decisively, the server is still started with `RpcServer.make(ServerWsRpcGroup, ...)` (ws.ts:3228). Middleware dispatch reads the full group. The partitions are only used for `toHandlers`, which builds a map from `rpc.key` to `{handler, context}`. `RpcServer` looks handlers up by `rpc.key` (`RpcServer.ts:258`, `:715`).
- The partitions drop the group-level annotations, because `RpcGroup.make` starts from an empty context. That doesn't matter: `toHandlers` never reads them, and the server reads the full group.

**Requirement types**
- `Layer.effectContext(Effect<Context<A>, E, R>)` produces `Layer<A, E, Exclude<R, Scope>>`, which is exactly what `toLayer` does internally (`RpcGroup.ts:336`).
- The output is `ToHandler<Split> | ToHandler<Other>`, which equals `ToHandler<all>`.
- The requirements are `HandlersServices` for each half plus what the build effect needs, so they are typed precisely and not `any`.

**Runtime cost**
- The work happens once, when the layer is built: two `forEach` passes over about 100 entries each, and one `Context.merge` of two contexts with no shared keys.
- Both `toHandlers` calls run in the same `Effect.gen`, so each handler entry captures the same `services` context. Behaviour matches the old single `toLayer`. Nothing changes per request.

**Smaller shape**
I don't see a materially smaller correct version. `ServerWsRpcGroup.omit(...)` would need every tag listed. The prefix list is a maintenance knob: the comment explains why it exists, and the PR says the 318-method probe still fails, so the headroom has a limit. That is a non-blocking note, not a defect.

**Current state**
- `cafe pr status`: 34 of 34 checks pass on de44c6e1b7, with no conflicts.
- The only comments are bot reports, and the thread-transfer report shows ±7 B, which is noise.
- I did not run the compiler probes or tests myself. I'm relying on the parent's evidence: the +6 and +60 probes pass, +120 fails as disclosed, and the 6 ws tests and both live partition calls pass.

**Findings:** no blockers. There is one optional maintainability note: the prefix partition may need rebalancing if one prefix group grows a lot, and the existing comment already covers why.

VERDICT: MERGE