DEV-205664: Add list_data_quality_rule_template_deployments tool

[regmimridul]

🎯 What does this PR do?

DEV-205664. Adds list_data_quality_rule_template_deployments — a read-only MCP tool listing the rules currently deployed from one rule template, so the blast radius of a template change can be seen before the change is made.

This is the read companion to update_data_quality_rule_template / delete_data_quality_rule_template from DEV-205663 (#134): an update always cascades to every deployed rule, and a delete refuses unless cascade is set — but neither tool could tell you how many rules that is, or which. Now you can ask first.

Wraps GET /rest/dq/1.0/ruleTemplates/{ruleTemplateName}/deployments through a new clients.ListDQRuleTemplateDeployments. Per deployment: job name, generated rule name, column, last run and its status, creator, and the Edge connection/site ids.

Stacked on #134 (feature/DEV-205663), which carries the data-quality flag and the sibling template tools. Merge #133 → #134 → this.

Gating

Registered behind the existing data-quality experimental flag, off by default, per §3.2 of docs/TOOL_CONTRIBUTION_STANDARDS.md — one shared feature name per domain rather than a flag per tool. Added to the gated-tool list in register_test.go, so the existing both-direction tests cover it.

Three places the acceptance criteria don't match the API

Each resolved in favour of the real contract (§8.2: derive contracts from the producing service). Flagging them explicitly because they're deviations from the ticket, not oversights:

1. The endpoint accepts no paging parameters. listRuleTemplateDeployments in RuleTemplatesControllerPublic takes only the template name and returns every deployment in one RuleTemplateDeploymentPaginated envelope. page / page_size are therefore honoured but applied client-side, after the read.

That still serves what AC 9 is actually for — keeping a widely-deployed template from flooding the model's context — but it does not save a round trip, and the field descriptions say so plainly rather than implying server-side paging. If you'd rather the DQ API gained real paging, that's a dq-side change and this tool would follow it.

2. A deployment has no id. RuleTemplateDeployment is keyed by jobName + deployedRuleName, which is also exactly how the detach endpoint addresses one. That pair is returned as the identity in place of the "rule ID" the AC asks for.

3. There is no deployment-status field. RuleTemplateDeploymentStatus (DEPLOYED/SKIPPED/FAILED) is the outcome of a deploy call, not something stored per deployment — every row this tool returns is by definition deployed. lastRunStatus (passing/breaking/exception/suppressed/pending_run) is returned instead, documented as the rule's latest evaluation, so a model can't mistake it for a deployment outcome.

Tool name

The ticket specifies dq_list_rule_template_deployments; this ships as list_data_quality_rule_template_deployments. §4.1 requires spelling out domain abbreviations in the tool name, and the siblings this sits beside are already list_/get_/create_data_quality_rule_template. Happy to rename if you'd rather match the ticket exactly.

Behaviour worth reviewing

• Empty ≠ error. A template with no deployments returns success with an empty array and a message saying nothing is deployed, per AC — not a 404-shaped failure.
• Past-the-end is also success, with guidance naming the valid page range.
• total is always the full count, independent of page size, so "how many rules would this affect" never depends on how the caller paged.
• The permission is surprising and the guidance says so: reading deployments needs DATA_QUALITY_DEPLOY_TEMPLATES, not plain template-read, so someone who can list templates may still be refused here.
• Downstream error text is truncated at 200 chars before reaching the model, matching the §2 fix on DEV-205661: Add dq_get_job_run_profile and dq_get_job_run_monitors tools #133 — the DQ client wraps the whole non-2xx body and engine errors echo offending values.

Impact Analysis

Low. Purely additive: one new tool, one new client function, one line in the gated block of RegisterAll. No existing tool, client function or type is modified.

The tool is behind data-quality (off by default), so no existing deployment's tool list changes. chip-service would need data-quality in COLLIBRA_MCP_EXPERIMENTAL to expose it.

Read-only: ReadOnlyHint: true, DestructiveHint: false, a single GET, no confirm checkpoint. Response size is bounded by page_size (default 25, max 200) regardless of how many deployments exist, though the upstream call is unbounded — a template with thousands of deployments still transfers them all to chip. Worth knowing if that's a realistic scale.

Still open: Permissions: []string{} (§9) — needs the real scope identifiers from the DQ team, same as #133.

Verified with gofmt -l, go build ./..., go vet and go test ./pkg/tools/... ./cmd/chip/... — all passing, including 13 new tests covering the default page size and total reporting, the prompt-the-user guidance, paging, past-the-end, empty-deployments, field mapping, never-run deployments, unknown template, the deploy-permission message, error mapping across 401/400/422/500, page-size validation and error truncation.

✅ Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation (if needed).
• My commit messages follow the Conventional Commits standard.

🤖 Generated with Claude Code