grpc-architectlisted

# gRPC Architecture Vanilla gRPC over HTTP/2 — backend-to-backend services. Pair with [protobuf-architect](../../encoding/protobuf-architect/SKILL.md) for schema design. Go-specific implementation skeletons in [RECIPES.md](RECIPES.md); pinned deps in [STACK.md](STACK.md). Other languages follow the same protocol-level conventions with idiomatic substitutions. ## 1. Service definition One service per file, named after the resource. Methods are verb-noun, request and response are always typed messages — never raw primitives or `google.protobuf.Empty` as input. Example in [RECIPES.md](RECIPES.md). - **`<Verb><Noun>Request` / `<Verb><Noun>Response`** naming for every method's I/O message. Even when the response is a single resource, prefer `CreateUserResponse { User user = 1; }` over returning `User` directly — leaves room to add fields without bumping the major version. - **Pagination via cursor**, mirroring [rest-api-architect §5](../../protocols/rest-api-architect/SKILL.md#5-pagination--cursor-not-offset). `ListUsersRequest { string cursor = 1; int32 limit = 2; }` → `ListUsersResponse { repeated User users = 1; string next_cursor = 2; }`. - **`google.protobuf.Empty`** only as a response type for "fire and forget" actions with no useful return. Never as input. ## 2. Error handling — `status.Error` with codes Use gRPC standard codes, return errors via `status.Error(code, msg)`. Map domain errors to codes in one central place (skeleton in [RECIPES.md](RECIPES.md)). ### Sta