POST /v1/orgs/:slug/volumes — create a named volume (Admin+).

Optional per-volume storage cap in GiB (#496). Omitted/null = no per-volume limit (the org's plan cap still governs). Must be >= 1 and <= the org's storage cap.

Volume name, unique within the org. Lowercase alphanumeric with single internal hyphens (e.g. team-ml). Creates a managed volume; the host disk is system-provisioned and has no name.

How a volume is physically backed — distinct from [VolumeKind] (ownership). Every volume is Block today; the enum exists so future backings can be added (and reported to the SDK) without another schema change.

The volume's configured per-volume storage cap in bytes, or null when no cap is set (#496). Derived from the stored capacity_gib (the user's configured intent) — the effective ceiling is min(this, org cap).

What kind of volume this is — its storage source / role. The host volume is the org's single shared "host disk"; managed volumes are user-created, named, platform-provisioned (JuiceFS over our object store). (A future External variant — bring-your-own S3/GCS — is intentionally out of scope for now.)

User-facing name. null for the host volume (it has no name; it's identified by kind).

Lifecycle status of a volume.

How a volume is physically backed — distinct from [VolumeKind] (ownership). Every volume is Block today; the enum exists so future backings can be added (and reported to the SDK) without another schema change.

Bytes currently used under this volume's subtree. null when usage is unavailable — the usage service is disabled or unreachable (list degrades gracefully rather than failing) — or on create/delete, which don't sample it.