Support Custom Work Item Fields in testplan_create_test_case

[panneer-subramanian]

Summary

Enhance the testplan_create_test_case tool to support custom work item fields (including mandatory Custom.* fields) when creating Azure DevOps Test Case work items.

Currently, the tool hardcodes a limited set of fields (Title, Steps, Priority, AreaPath, IterationPath) and does not allow callers to specify additional fields required by inherited processes. This prevents creation of Test Case work items in projects where custom fields are mandatory.

This change should introduce support for passing arbitrary work item fields using their reference names, consistent with Azure DevOps Work Item Tracking REST API behavior.

Tools

Enhance the following tool with full parameter support:

testplan_create_test_case

Add support for an optional parameter:

fields

Type:

Record<string, string | number | boolean | null>

Purpose:

Allow callers to pass additional work item fields (including Custom.* fields) using Azure DevOps field reference names.

Example usage:

{
"title": "Login - Happy Path",
"fields": {
"Custom.TestCategory": "Regression",
"Custom.Component": "Authentication"
}
}

Implementation Requirements

Merge the fields map into the JSON Patch document used by witClient.createWorkItem.

For each provided field:

{ op: "add", path: /fields/${referenceName}, value }

Ensure compatibility with Azure DevOps Work Item REST API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create

Maintain support for existing predefined fields:

System.Title

Microsoft.VSTS.TCM.Steps

Microsoft.VSTS.Common.Priority

System.AreaPath

System.IterationPath

Prevent overriding of tool-controlled fields to avoid ambiguity.

Block modification of system-managed fields such as:

System.Id

System.Rev

System.CreatedDate

System.CreatedBy

System.ChangedDate

System.ChangedBy

Treat field names strictly as reference names, not display names.

Preserve backward compatibility for existing consumers of the tool.

Rules

Adhere strictly to existing project standards and coding conventions.

Follow the current MCP tool registration and Zod schema validation patterns.

Use the official Azure DevOps Node API to interact with Work Item APIs.

Ensure validation errors are explicit and developer-friendly.

Update docs/TOOLSET.md to document the new fields parameter with examples.

Include appropriate input validation and error handling.