The bench. The engine.

Two processes, one boundary

The documented client and daemon are separate local processes connected through a Unix-domain socket. Ribhu does not carry provider keys or its own routing brain.

Local records support execution and recovery. They do not make Ribhu the owner of the daemon’s session identity, memory policy or provider authority.

Routing belongs to the kernel

Ribhu sends the request and coding-tool context to the daemon. Chitragupta selects and runs the model, streams text and tool calls back, and receives the results of tools Ribhu executes locally.

A route preview is provisional. Treat the resolved route and its receipts as the record of what actually ran; don’t infer execution from a proposed provider name.

The user can express a model preference through the documented /model command or per-message #model: tag. That is a request through the bridge, not a second local router. Exact availability and execution still need to be confirmed in the live environment.

A connection is not write authority

The bridge separates ordinary connection authority from workspace mutation. A generic bridge connection may support read and chat operations; it does not, by itself, authorize changing the workspace.

The write path requires operator-provisioned identity and a short-lived daemon-issued binding. Identity, scope and expiry are checked. A missing or unusable write path cannot be replaced with a generic token and called success.

Ribhu’s public product name is Ribhu. The deployed bridge still uses the legacy takumi identity for protocol compatibility; a rename in the interface does not rewrite an authenticated wire identity.

Discover without probing mutations

Startup and --doctor inspect the daemon’s effective method inventory through bridge.capabilities. The list reflects the authenticated caller and its restrictions.

An advertised method is not evidence that a particular request is valid, a provider route is executable or a workspace write is authorized. An unavailable or malformed inventory means availability is unknown; an empty list means no effective methods.

The client documentation explicitly avoids sending empty requests to mutation methods merely to find out whether they exist. Discovery should stay discovery.

Keep unknown outcomes unknown

A disconnected stream, cancelled request or missing receipt can leave a result unresolved. Prose that says “done” cannot settle a mutation.

Use the daemon’s receipts and the local recovery record to reconcile what happened. If the evidence cannot establish an outcome, report that uncertainty and inspect before retrying—especially when another call could duplicate an effect.

This is a fail-closed contract, not an assertion that every provider, daemon build or transport has passed acceptance. A working integration is established by the exact environment and the checks run against it.