# Dedicated Components Details

## Current Design

- `GET /orgs/{oid}/clusters/{cid}/resource-pool/components` returns `[]view.ResourcePoolComponent`.
- Resource pool clusters read shared pool component groups and exclude cluster-owned `tidb` / `tiproxy`.
- Premium / BYOC clusters read TiDB groups plus their parent shared pool and return the cluster-owned `tidb` / `tiproxy` component groups.
- Dedicated clusters already have component data from mgmt dedicated cluster components, but this endpoint rejects `dedicated` and the UI does not mount the details panel for dedicated clusters.

## Target Contract

- The endpoint remains the single details API for topology/component details.
- Dedicated clusters return the same `view.ResourcePoolComponent` shape using mgmt dedicated component data.
- Dedicated conversion includes component type, component id, node count, CPU, memory, storage name/type/size/iops/throughput.
- Read paths do not persist or repair cluster model data.

## Risks

- Dedicated component proto does not provide `phase`, `version`, or image repo/tag equivalent to nextgen component groups, so those fields stay empty.
- Dedicated storage type is not identical to nextgen storage type; use volume type when present, otherwise disk type.
- The old cluster detail `components` field remains unchanged.

## Implementation Steps

1. Add a dedicated component to `view.ResourcePoolComponent` converter in datasource utils with unit coverage.
2. Add a dedicated branch in `GetResourcePoolComponents` API handler.
3. Expose the existing topology details panel for dedicated clusters in the cloud cluster page.

## Verification Checklist

- Dedicated converter unit test covers component fields and storage fields.
- Backend package tests for datasource utils pass.
- Frontend type-check or focused lint verifies the expanded mount condition compiles.