Sub-issue of #3171 (provider boundary in step 5). Follows #3299 / PR #3383, which made provider profiles import-only. Coordinated pre-0.1.0 breaking change under #2565.
User Story
As an operator, I want an imported provider profile to declare every behavior it activates, so I can inspect, fork, and rename the profile without silently changing the sandbox environment.
Problem Statement
#3299 removed the compiled provider profile catalog, but two compiled adapters remain:
google-cloud projects provider config into GCP SDK variables and sets GCE_METADATA_HOST.
google-vertex-ai projects project and region config into GCP and Vertex variables and sets a GOOSE_PROVIDER default.
ProviderRegistry::inject_env_for_profile_id selects these adapters by the resolved profile ID. Importing the same profile as google-cloud and acme-gcp therefore produces different environments even though the imported definitions are identical.
Other provider-specific behavior is also compiled rather than declared: Vertex discovery scans a fixed list of config variables, and child-environment preparation contains GCP-specific metadata and non-secret configuration handling. ProviderProfile can declare credential environment variables, but not non-secret config projection, fixed non-secret values, discovery config keys, or a required platform adapter.
Impact / Why This Matters
An imported profile is not currently its complete definition. Operators must preserve canonical IDs and know release-specific implementation details, or provider creation succeeds while the workload later fails because expected SDK configuration is absent. This contradicts the import-only contract and makes profile forks unsafe.
Proposed Design
Inventory every compiled provider behavior reachable from an imported profile and give it one disposition:
- Express in the profile. Add bounded declarative fields for generic non-secret behavior such as config-to-environment projection, fixed values, and discovery config keys. Do not introduce templating or scripting.
- Declare a platform adapter. If behavior is genuinely platform-specific, the profile names the required adapter. Import or attachment fails with a bounded diagnostic when the adapter is unavailable.
- Remove it. Delete behavior or APIs with no remaining caller, including
ProviderDiscoverySpec and discover_with_spec unless a supported use is identified.
Projection must preserve the existing rule that caller-supplied environment values win. Linting must reject collisions between non-secret projection and credential env_vars.
Update the Google Cloud and Vertex examples so their YAML describes their complete environment and discovery effects. A fork imported under a different ID must behave identically to the canonical example.
Credential refresh strategies are out of scope because profiles already declare them.
Acceptance Criteria
Alternatives Considered
- Delete both adapters: restores a clean boundary but breaks existing GCP and Vertex workloads at upgrade.
- Document ID-keyed behavior only: leaves profile forks behaviorally different and the binary authoritative for part of the profile definition.
- Add a general templating language: unnecessarily turns reviewable profile data into executable configuration; bounded projection covers the observed generic cases.
- Restore aliases: cannot support an unbounded operator catalog and reintroduces hidden ID coupling.
Technical Notes
crates/openshell-providers/src/lib.rs: ProviderRegistry registers the two remaining adapters and selects them by exact profile ID.
crates/openshell-providers/src/discovery.rs: discover_from_profile special-cases google-vertex-ai config keys.
crates/openshell-core/src/provider_credentials.rs: child environment preparation contains GCP-specific metadata and non-secret resolution.
crates/openshell-server/src/grpc/provider.rs: provider environment assembly and key-collision validation are the runtime integration points.
proto/openshell.proto and crates/openshell-providers/src/profiles.rs: the public profile schema and YAML/protobuf conversion currently lack this declaration surface.
Checklist
Sub-issue of #3171 (provider boundary in step 5). Follows #3299 / PR #3383, which made provider profiles import-only. Coordinated pre-
0.1.0breaking change under #2565.User Story
As an operator, I want an imported provider profile to declare every behavior it activates, so I can inspect, fork, and rename the profile without silently changing the sandbox environment.
Problem Statement
#3299 removed the compiled provider profile catalog, but two compiled adapters remain:
google-cloudprojects provider config into GCP SDK variables and setsGCE_METADATA_HOST.google-vertex-aiprojects project and region config into GCP and Vertex variables and sets aGOOSE_PROVIDERdefault.ProviderRegistry::inject_env_for_profile_idselects these adapters by the resolved profile ID. Importing the same profile asgoogle-cloudandacme-gcptherefore produces different environments even though the imported definitions are identical.Other provider-specific behavior is also compiled rather than declared: Vertex discovery scans a fixed list of config variables, and child-environment preparation contains GCP-specific metadata and non-secret configuration handling.
ProviderProfilecan declare credential environment variables, but not non-secret config projection, fixed non-secret values, discovery config keys, or a required platform adapter.Impact / Why This Matters
An imported profile is not currently its complete definition. Operators must preserve canonical IDs and know release-specific implementation details, or provider creation succeeds while the workload later fails because expected SDK configuration is absent. This contradicts the import-only contract and makes profile forks unsafe.
Proposed Design
Inventory every compiled provider behavior reachable from an imported profile and give it one disposition:
ProviderDiscoverySpecanddiscover_with_specunless a supported use is identified.Projection must preserve the existing rule that caller-supplied environment values win. Linting must reject collisions between non-secret projection and credential
env_vars.Update the Google Cloud and Vertex examples so their YAML describes their complete environment and discovery effects. A fork imported under a different ID must behave identically to the canonical example.
Credential refresh strategies are out of scope because profiles already declare them.
Acceptance Criteria
ProviderDiscoverySpecanddiscover_with_specare removed or have a documented supported caller.ProviderProfile.sourceandresource_versiondocumentation no longer refers to built-in profiles orbuiltinprovenance.0.1.0migration notes describe the resulting contract.Alternatives Considered
Technical Notes
crates/openshell-providers/src/lib.rs:ProviderRegistryregisters the two remaining adapters and selects them by exact profile ID.crates/openshell-providers/src/discovery.rs:discover_from_profilespecial-casesgoogle-vertex-aiconfig keys.crates/openshell-core/src/provider_credentials.rs: child environment preparation contains GCP-specific metadata and non-secret resolution.crates/openshell-server/src/grpc/provider.rs: provider environment assembly and key-collision validation are the runtime integration points.proto/openshell.protoandcrates/openshell-providers/src/profiles.rs: the public profile schema and YAML/protobuf conversion currently lack this declaration surface.Checklist