The quests.* RPC methods, for game clients.

Called over the game socket as an rpc.call frame. The SDK spelling differs per engine - ws.rpc(...) in JS, rpc_call(...) in Godot, realtime:rpc(...) in Defold and LOVE:

await ws.rpc("quests.list", {});
await ws.rpc("quests.claim", { quest_key: "daily_kills" });

Thin by design: decode params, call asobi_quests, encode. Every decision is in the domain module, which is what makes the same implementation reachable from Lua, from a client and from a job.

The handler signature

Specified by core now (asobi_rpc), and this module invented it first:

-spec claim(asobi_rpc:params(), asobi_rpc:ctx()) -> asobi_rpc:reply().

{ok, map()} | {error, Code} | {error, Code, Details}. The failure half is a code, not a status and an object: both are derived from the code, and codes/0 on the manifest is what makes a quests code answer as itself rather than as internal.

Params is the request's params object with binary keys; Ctx carries the authenticated caller. A handler never reads a player id out of Params - that would let any client claim any player's rewards.

Core also runs asobi_readiness:guard/0 before dispatching, so the readiness check this module used to make itself is gone.