hanzoai/ai folded every route it serves under /v1/ai (HIP-0139 §3.1): a
capability answers at one address, and /v1/rag and /v1/router were two more
top-level addresses belonging to the same app. The old spellings die when cloud
picks up the module — there is no alias — so the calls move with them.
RagClient now posts /v1/ai/rag/{embed,query,query-multiple,delete} and reads
/v1/ai/rag/context; RoutingDefaults reads /v1/ai/router/defaults. Nothing else
changes: same bodies, same forwarded IAM bearer, same soft-fail.
The reward signal is NOT moved. Its URL is built inside @hanzo/ai's sendFeedback
(node_modules/@hanzo/ai/dist), not here, so client/src/utils/rewardSignal.ts and
its spec still name /v1/feedback and will keep doing so until that package
publishes the fold. Moving the assertion here would only make the spec disagree
with what the SDK actually posts.
librechat-data-provider → @hanzochat/data-provider
@librechat/data-schemas → @hanzochat/data-schemas
@librechat/client → @hanzochat/client
(@hanzochat/api already forked; external @librechat/agents fork follows)
All imports, package.json names/deps, tsconfig path aliases, jest
moduleNameMapper, and rollup/vite build aliases updated. The data-provider
react-query subpath resolves via the exports map. Lockfiles regenerated in a
follow-on once the canonical package manager is confirmed.
New conversations resolve smart routing from the org's server-driven
defaults (GET /v1/chat/routing-defaults proxying cloud's
/v1/get-routing-defaults on-behalf-of) with the local toggle as a
nullable user override (null = follow org default). Fail-soft: an older
cloud-api (404), network error, or non-ok wrapper behaves exactly as
today (local preference only). When auto_routing_active is false the
toggle is locked with honest copy.
Effective state is one pure function, resolveSmartRouting
(client/src/utils/endpoints.ts), unit-tested in endpoints.spec.ts.
Co-authored-by: Hanzo Dev <[email protected]>
zeekay
