WorkItemDetail.labels validation fails when API returns unexpanded label IDs

Summary

work_items.retrieve() (and any code path returning a WorkItemDetail) raises a pydantic.ValidationError for any work item that has labels attached, when labels is not explicitly expanded.

Repro

Call the retrieve endpoint for a work item that has one or more labels, without expand=labels:

client.work_items.retrieve(
    workspace_slug=workspace_slug,
    project_id=project_id,
    work_item_id=work_item_id,
)

Result: pydantic.ValidationError — Input should be a valid dictionary or instance of Label — deterministic, not intermittent, for every work item that has labels.

Root cause

The Plane API returns labels as an array of label ID strings when the field isn't expanded (the normal/default response shape). The WorkItemDetail model types labels as list[Label] unconditionally, so pydantic rejects the plain ID strings instead of accepting either shape.

Expected behavior

labels should accept both shapes depending on whether the caller expanded it — e.g. list[Label] | list[str], or the model should coerce string IDs into a minimal Label reference, consistent with how the API actually behaves when expand isn't requested.

Environment

• plane-sdk==0.2.19 (PyPI)
• Found via makeplane/plane-mcp-server (retrieve_work_item / retrieve_work_item_by_identifier tools), but the bug is in the SDK's model, not the MCP server.
• Server tested against: self-hosted Plane Community 1.3.1.

Workaround in use

Using list_work_items (which doesn't hit this validation path) instead of retrieve_work_item*, and filtering client-side.

Find the WorkItemDetail model in the SDK and reproduce the failure through work_items.retrieve without expand=labels. Verify that labels accepts the API's unexpanded label ID strings as well as expanded Label objects, and confirm the retrieve_work_item paths no longer raise ValidationError.