The rule change flow guides users through requirement confirmation, preview, apply, and validation when official DistSQL-only features create reviewable database governance changes. It is not a standalone business feature. Users usually enter this flow from a concrete data encryption, data masking, broadcast, readwrite-splitting, shadow, or sharding task.
| Phase | User action | Focus |
|---|---|---|
| Describe the requirement | Provide the logical database, table, column, and governance goal. | Clear input makes the generated plan more stable. |
| Provide missing information | Add algorithm choices, parameters, secret placeholders, or execution preferences when asked. | Sensitive values should be provided through protected channels. |
| Review the plan | Review generated rule DistSQL, change artifacts, and impact scope. | Confirm that the plan matches business expectations. |
| Preview the change | Ask to preview first without changing runtime state. | Check statements and side effects before execution. |
| Apply the change | Confirm automatic execution, or export a manual package for operators. | Side-effecting changes must be confirmed. |
| Validate the result | Check rule state or workflow execution results returned by the feature plugin. | Confirm that the change has taken effect. |
Planning tools return a plan_id that links the generated plan to workflow resources, preview, apply, and validation tools.
Use the workflow resource to review the persisted plan before applying it.
Use preview before execution when the user needs one more confirmation step.
Model-facing planning responses may include:
algorithm_recommendations: candidate algorithms selected from Proxy-visible plugin catalogs or explicit user input.property_requirements: required or optional properties for the selected algorithms. Missing required properties keep the workflow in clarification instead of generating unsafe artifacts.resources_to_read and next_actions: resource and tool navigation hints for continuing the workflow.distsql_artifacts: reviewable rule DistSQL generated inside the current feature plugin boundary.| User wording | What users receive | Focus |
|---|---|---|
| “Preview first, do not execute.” | Change content and impact scope only. | Use this to confirm statements, change artifacts, and side effects first. |
| “Confirm and execute the previous plan.” | The previewed and confirmed change is executed. | Use this only after the user has completed review. |
| “Export a manual execution package.” | Statements that operators can review and execute manually. | Use this when approval, a change window, or a controlled execution environment is required. |
Rule changes may require sensitive fields such as keys or credentials. These values should not be written into ordinary documents, chat records, or logs.
Recommended handling:
{"secret_ref": "placeholder://secret-value-1"}.execution_mode=preview; preview responses show only neutral placeholders or ******.secret_reference_manual_execution_required.ShardingSphere-MCP only records the sensitive slot that requires manual replacement; it does not fetch real sensitive values from external systems.