Use Protobuf

Use Protobuf

Treat Protobuf as the canonical typed contract for gRPC, REST gateway bindings, OpenAPI, generated SDKs, and shared data structures. Model the domain before optimizing generated code.

Workflow

1. Read repository instructions and inspect existing .proto files, packages, versions, imports, generation configuration, and generated output conventions.
2. Classify each service as gRPC-only or HTTP-exposed before adding annotations.
3. Model every RPC, stream packet, enum, error, and reusable message with concrete types.
4. Apply transport-specific validation and documentation rules.
5. Evaluate compatibility according to the package's release state and version.
6. Generate every configured SDK and OpenAPI artifact. Use $use-buf and $use-buf-plugins when available.
7. Run repository tests and inspect generated diffs; never hand-edit generated code.

Define RPC Contracts Explicitly

• Define a dedicated RPC method for every gRPC operation.
• Name unary messages MethodRequest and MethodResponse.
• Keep request and response messages distinct even when their current fields happen to match.
• Use TitleCase service, method, message, and enum names; use lower_snake_case fields and UPPER_SNAKE_CASE enum values.
• Prefer comments that explain semantics, units, identity, presence, ordering, and lifecycle rather than restating the field name.

rpc GetDocument(GetDocumentRequest) returns (GetDocumentResponse);

Model Streaming Without Base Payloads

Use the appropriate gRPC streaming form:

rpc ImportRecords(stream ImportRecordsStreamRequest) returns (ImportRecordsResponse);
rpc WatchJob(WatchJobRequest) returns (stream WatchJobStreamResponse);
rpc Transfer(stream TransferStreamRequest) returns (stream TransferStreamResponse);

MUST NOT create an abstract, generic, inherited, or catch-all base event/base payload for stream requests or responses. Define concrete stream event, step, or packet messages. When several variants may occur, use oneof whose alternatives are separate messages. Use one homogeneous stream message only when every packet genuinely has the same body and semantics, such as fixed-shape file chunks.

Read references/schema-design.md before designing or changing any streaming RPC.

Separate gRPC-Only and HTTP-Exposed Schemas

For gRPC-only services, do not add google.api.http, grpc-gateway, or grpc.gateway.protoc_gen_openapiv2 imports, method options, message options, enum options, or field options.

For every *Request exposed through grpc-gateway, regardless of GET, POST, body, path, or query placement:

• validate accepted input with buf.validate annotations;
• document every request field with appropriate openapiv2 information such as example, description, format, range, length, pattern, or collection bounds;
• keep runtime validation authoritative and make OpenAPI constraints agree with it;
• define the google.api.http binding and operation documentation intentionally.

Do not hardcode a Buf cache path when researching extension fields. Follow the export/query workflow in references/http-and-openapi.md.

Prefer Strong Domain Types

• Use an enum whenever the value belongs to a finite controlled vocabulary; do not disguise it as an unconstrained string.
• Give enums an explicit zero value and document what the enum classifies.
• Prefer dedicated messages, well-known types, repeated fields, maps, and oneof over google.protobuf.Struct or google.protobuf.Any.
• Use Struct or Any only for a real open-world boundary. Document why typed modeling is impossible and how consumers validate the payload.
• In Go, use protojson for Protobuf JSON and a registered type resolver for Any; do not route Protobuf through generic encoding/json. Research the canonical library for every other target language before implementing serialization.