feat(controlplane): accept a workflow template reference on workflow create

Merged
MI
2mo ago
+433-16

Summary

Workflows can already be bound to a platform workflow template through the workflows.workflow_template_id column, but the only writer is the in-process repository auto-setup path. The gRPC surface never saw the field, so a template-backed workflow could only be created via project onboarding.

This exposes that binding over the API:

  • WorkflowServiceCreateRequest.workflow_template_id (field 8), validated as a UUID and ignored when empty.
  • WorkflowItem.workflow_template_id (field 13), so the binding reads back through create, view and list without a second request.
  • WorkflowService.Create parses the reference into the create options, and bizWorkflowToPb emits it.
  • pkg/action carries the field on both NewWorkflowCreateOpts and WorkflowItem, so template-aware clients reuse the existing action rather than reimplementing the call.

The biz and data layers already carried and persisted the field and are unchanged.

Notes

The reference is unvalidated by design. There is no workflow_template table in the control plane and no foreign key on the column, so existence, org ownership and soft-deletion cannot be checked here. Nothing in the control plane dereferences the value; validation belongs to the platform, which resolves it through its own org-scoped queries.

Contract semantics are unchanged: a template-bound workflow created this way gets the contract the caller passed, or the default empty one, not a contract rendered from the template. Closing that gap needs a template-aware create endpoint and is deferred.

The open-source CLI command layer is untouched and exposes no --template flag, as it has no notion of templates.

AI assistance

Implemented with the assistance of Claude Code. Each commit carries an Assisted-by: Claude Code trailer.