Integrate claim-machinery-api + claims for parameterized workflow trigger

[patrick-hermann-sva]

Context

Today, triggering a Dapr workflow (e.g. BackstageTemplateWorkflow) means hand-editing one of the static input-*.json files in workflows/<workflow>/ and invoking ./run.sh. Per-run parameters (VM name, sizing, lab, provisioning profile, …) live as raw JSON without schema, validation, or interactive prompts.

We already have two projects in the org that solve exactly this for Crossplane claims:

• claim-machinery-api — backend that owns KCL-based templates, parameter schema (types, enums, defaults, validation), and renders them via OCI.
• claims — terminal CLI client with huh-based interactive forms, dry-run rendering, git/PR integration.

Reusing this stack for Dapr workflow inputs gives us schema-driven prompts, central template versioning, and a single UX across Crossplane claims and Dapr workflows.

Proposed architecture

claims (CLI)  ──HTTP──▶  claim-machinery-api  ──KCL──▶  rendered JSON
     │                                                       │
     └─── interactive huh form ────────────────────┐         │
                                                   ▼         ▼
                                       /tmp/dapr-trigger-<ts>.json
                                                   │
                                                   ▼
                                         dapr-workflows run.sh
                                         (POST to Dapr sidecar)

Phase 1 — Spike (additive, no upstream changes)

• Author a KCL template dapr-backstage-execution (in the templates registry consumed by claim-machinery-api) that renders the stages: [...] JSON shape currently in input-vm-ansible.json.
• Parameter schema covers at least: lab, cloud, vm_name, vm_sizing, vm_template, provisioning_profile, optional provisioning_type (stage 2 ansible target — kind-cluster, rke2, …), kind_cluster_name, collection version pins.
• Replace the trigger task in Taskfile.yaml (currently gum-selects a static input file) with a flow that calls claims render --templates dapr-backstage-execution --dry-run --single-file, writes to /tmp/dapr-trigger-<ts>.json, then pipes into ./run.sh.
• Keep input-*.json files as smoke-test fixtures only.

Phase 2 — Native dapr execute (architecture cleanup)

• Add a claims dapr-execute (or equivalent) subcommand that, after rendering, POSTs the JSON directly to http://<host>:<port>/v1.0-beta1/workflows/dapr/<WorkflowName>/start?instanceID=... and tails the run status — replacing run.sh entirely.
• Same code path then works for Backstage scaffolder steps and CI triggers, not just local dev.
• Decide auth model against the Dapr sidecar (today: open on localhost; remote needs token/mTLS).

Out of scope

• Migrating other workflows (golden-image-workflow, build-scan-changed, …) — they can adopt the same template once dapr-backstage-execution is proven.
• Replacing the Backstage scaffolder calls inside the Dapr workflow itself; this issue is only about how the workflow is triggered.

Related

• Multi-stage chain tracking issue: Multi-stage Backstage template chain (VM → Ansible → Flux) in backstage-template-execution #21
• claim-machinery-api: https://github.com/stuttgart-things/claim-machinery-api
• claims: https://github.com/stuttgart-things/claims