DEV-205665: Add detach_data_quality_rule_from_template tool

[regmimridul]

🎯 What does this PR do?

DEV-205665. Adds detach_data_quality_rule_from_template — soft-unlinks one deployed rule from its template, turning it into a standalone rule.

This is not a delete. The rule, its configuration and every historical run result are preserved exactly as they are; only the link is cleared. What changes is the future: once detached, the rule stops receiving cascades, so an update_data_quality_rule_template that rewrites the template's SQL, and a delete_data_quality_rule_template run with cascade, no longer touch it. It also stops appearing in list_data_quality_rule_template_deployments for that template.

Wraps POST /rest/dq/1.0/ruleTemplates/{ruleTemplateName}/detach through a new clients.DetachDQRuleFromTemplate. Gated behind the existing data-quality flag per §3.2.

Stacked on #143 (DEV-205664), which it depends on conceptually — the preview path uses the same deployments endpoint. Merge order: #133 → #134 → #143 → this.

Confirm checkpoint

The ACs don't mention one, but §5 requires it of any tool that writes. confirm=false (the default) does more than echo the payload: it reads the template's deployments and refuses when the rule isn't among them, so the API's opaque 400 becomes an answer the caller can act on, and nobody approves a no-op. confirm=true performs the detach.

Worth noting for review: detaching is one-way. There is no re-link endpoint, and the only way back is redeploying the template onto the rule, which overwrites its SQL. The preview says so explicitly.

Two deviations from the acceptance criteria

Both forced by the API (§8.2: derive contracts from the producing service):

1. There is no rule_id. The AC asks for a single identifier, but RuleTemplateDeployment is keyed by jobName + deployedRuleName, and the endpoint additionally needs the template name in its path — which the ACs don't mention at all. So the tool takes three required inputs: template_name, job_name, deployed_rule_name. All three come from list_data_quality_rule_template_deployments, and the needs-input message says so. Same root cause as the missing rule id in #143.

2. The endpoint answers 204 No Content. The AC asks for "the rule's current standalone definition" on success, so the tool does a follow-up read via clients.GetDQRule. That read-back is best-effort: the write has already committed, so a failure to re-read returns success with a pointer at get_data_quality_rule, rather than implying the detach failed. DQRule.TemplateID doubles as a confirmation signal — if it's still set after a successful detach, the tool reports that rather than claiming a clean result.

The 400 is ambiguous, and the tool says so

RuleTemplatesBll.detach raises the same RULE_NOT_FROM_TEMPLATE for a rule that is already standalone and for one that belongs to a different template. The API gives callers no way to tell them apart, so the error names both possibilities and points at list_data_quality_rule_template_deployments rather than guessing. That satisfies the AC's "clear, descriptive error rather than a silent no-op" — it just can't be more specific than the service is.

Tool name

The ticket specifies dq_detach_rule_from_template; this ships as detach_data_quality_rule_from_template, per §4.1 and consistent with its *_data_quality_rule_template siblings. Happy to rename.

Impact Analysis

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

Behind data-quality (off by default), so no existing deployment's tool list changes.

ReadOnlyHint is deliberately not set — this writes. DestructiveHint: false because nothing is deleted and history survives. IdempotentHint is not set either: a second detach of the same rule fails, since it is no longer linked.

The tool makes up to two calls on the confirm path (detach, then read-back) and one on the preview path (deployments). The read-back uses the internal v1 rule endpoint, the same one get_data_quality_rule already uses, while the detach itself is on the public API — flagging the mix in case you'd rather the read-back were dropped.

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

Verified with gofmt -l, go build ./..., go vet and go test ./pkg/tools/... ./cmd/chip/... — all passing, including 12 new tests covering preview-writes-nothing, preview-echoes-every-field (§5.2), preview refusal for an unlinked rule, the detach payload, the read-back, a surviving template link, read-back failure not masking success, the already-standalone error, unknown rule/template, the deploy-permission message, and 401/422/500 mapping.

✅ 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