The quests.* RPC methods, for game clients.

asobi.rpc("quests.list",  {})
asobi.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.