refactor(forges): bind account-scoped adapter operations via getAccountAdapter - #3266
Conversation
|
What do you think of these ergonomics @setchy? I'm a bit on the fence with the naming. Chained, |
let me soak on this PR for a moment 🧽 |
Replace recursive runtime binding and mapped signatures with explicit typed operations, preserving the generic followUrl contract. Cover same-forge account isolation and bound Gitea requests, failures, and response types.
|
@setchy just replaced the recursive binder and mapped types with explicit typed bindings. The account-bound API now stays the same, and followUrl preserves its generic contract throughout. |
|



Summary
ForgeAdapterkeeps the forge-wide members (login flows, token validation, display helpers), and a newForgeAccountAdaptercarries the account-scoped operations with no account parameter.accountOps, still taking the account explicitly; the shape is derived fromForgeAccountAdapterby a mappedWithAccounttype so the two cannot drift.getAccountAdapter(account)in the registry binds them, so call sites readgetAccountAdapter(account).listNotifications()instead ofgetAdapter(account).listNotifications(account).adapter.accountOps.*, and adds registry tests for the binding (argument forwarding, nested capability bundles, optional bundles, call-time member lookup).Follows up on the double-passing pattern raised in #3255 (comment).
Notes
ForgeAccountAdapter.followUrl<T>stays generic on the bound side; on the implementation side the type parameter erases tounknown, matching the trust boundary that existed before.