User Story
As an OpenShell SDK user, I want a curated gateway-capabilities API so that I can determine which portable CPU, memory, and GPU requests a gateway’s compute drivers support without depending on generated protobuf types.
Problem Statement
Issue #2902 adds static resource capability fields to the compute-driver and gateway protobuf APIs. Rust callers can already access them through OpenShellClient::raw_grpc() and openshell_sdk::raw::proto, but the curated SDK surface has no typed gateway-info method or capability models.
Impact / Why This Matters
Consumers that need an idiomatic SDK API must currently use generated wire types and direct gRPC calls. That is workable but makes application code depend on protobuf details and produces inconsistent ergonomics across SDKs.
Proposed Design
Expose gateway information and per-driver resource capabilities through each curated SDK surface. Preserve absence when a driver does not report capabilities, and document that capability flags describe static implementation support rather than live inventory or available capacity.
Acceptance Criteria
Alternatives Considered
Keep the new fields available only through generated protobuf clients. This preserves wire-level access but leaves users to manage generated types directly and does not provide a consistent SDK-level experience.
Agent Investigation
The Rust SDK re-exports generated protobufs through openshell_sdk::raw::proto; protobuf bindings are regenerated from the full proto/ tree by openshell-core during Rust builds. This follow-up is therefore curated API work rather than a prerequisite for protocol access.
Related to #2902 and draft PR #3010.
User Story
As an OpenShell SDK user, I want a curated gateway-capabilities API so that I can determine which portable CPU, memory, and GPU requests a gateway’s compute drivers support without depending on generated protobuf types.
Problem Statement
Issue #2902 adds static resource capability fields to the compute-driver and gateway protobuf APIs. Rust callers can already access them through
OpenShellClient::raw_grpc()andopenshell_sdk::raw::proto, but the curated SDK surface has no typed gateway-info method or capability models.Impact / Why This Matters
Consumers that need an idiomatic SDK API must currently use generated wire types and direct gRPC calls. That is workable but makes application code depend on protobuf details and produces inconsistent ergonomics across SDKs.
Proposed Design
Expose gateway information and per-driver resource capabilities through each curated SDK surface. Preserve absence when a driver does not report capabilities, and document that capability flags describe static implementation support rather than live inventory or available capacity.
Acceptance Criteria
Alternatives Considered
Keep the new fields available only through generated protobuf clients. This preserves wire-level access but leaves users to manage generated types directly and does not provide a consistent SDK-level experience.
Agent Investigation
The Rust SDK re-exports generated protobufs through
openshell_sdk::raw::proto; protobuf bindings are regenerated from the fullproto/tree byopenshell-coreduring Rust builds. This follow-up is therefore curated API work rather than a prerequisite for protocol access.Related to #2902 and draft PR #3010.