Module digitalocean 

DigitalOceanEnvoy — second native cloud.vps.* adapter, spike scope (R409-T10). Together with [HetznerEnvoy] this is the catalog-shape validator R409-T11’s postmortem decides on.

Layering differs from Hetzner: there is no separate MachineProvider impl in the way. Hetzner has a long-lived [HetznerDriver] that the orchestration code (provision.rs, cloud_init.rs) calls into, and the envoy was retrofitted on top. DigitalOcean has never had such a driver, so DigitalOceanClient is built thin and lives only behind DigitalOceanEnvoy — no parallel MachineProvider impl. If T11 says “expand”, the client lifts into its own crates/yah/digitalocean crate the way Hetzner did in R040-F14.

The spike is pre-envoy-host: nothing wires DigitalOceanEnvoy through KgToolRegistry (that’s R409-T9). Verification is unit tests of the conversion layer — the network methods are not exercised in tests.

Post-T11 shape

Three findings drove revisions in the R409-T11 postmortem (see W144 §“Catalog-shape postmortem”):

• D5: wire location is now a coarse region tag (na-west, na-east, eu-central); [do_region] maps each tag to the nearest DO slug (sfo3, nyc3, fra1).
• D6: CloudVpsCreateInput.project is gone — DO Projects remain available as a future cloud.project.* verb tree but are no longer a free parameter on cloud.vps.create.
• D7: ssh_keys is now Vec<String>; DO accepts both numeric IDs and SHA-256 fingerprints as JSON strings, so the spec passes the values through verbatim.

Structs

DigitalOceanClient

Minimal DigitalOcean Cloud API client — droplet lifecycle only.

DigitalOceanEnvoy

Tier-S, native-flavored envoy adapter that bridges the DigitalOcean droplet API to the cloud.vps.* verb framework. Spike scope (R409-T10): only the three verbs from crate::envoy::cloud_vps are wired.

DoCreateDropletSpec

Request body for POST /v2/droplets. Field names match DO’s API exactly so this serializes straight to the wire.