Use autocore in the AutoFlow CLI

Romuald Atchadérequested to merge
942-use-autocore-in-autoflow-cli into master

Closes #942 (closed).

The autoflow CLI's run-local command ran flows through its own hand-rolled backend (localAutoFlowBackend) that bypassed autocore entirely — faked workflow key, reflect.Select over Go channels, in-memory-only state, and channels/poll/run left unimplemented. That meant a second execution backend to maintain and no guarantee the CLI behaved like production.

This replaces it with a thin gRPC client of the existing AutoFlow API, so the CLI drives the same engine as production against a running Relay/KAS (e.g. GDK). No new server code was needed — StartWorkflow/GetWorkflow/CancelWorkflow already accept an inline flow definition.

New commands:

  • autoflow run -s flow.star [--arg …] [--kwarg …] [-d/--detach] — submits the flow, prints the workflow key immediately, then polls to completion and prints the result (skip the wait with --detach). Exits non-zero on a failed/timed-out/canceled workflow.
  • autoflow get <workflow-key> [--wait]
  • autoflow cancel <workflow-key>

Connection flags are shared: --address (default 127.0.0.1:8153), --secret-file (the KAS API auth secret), and optional --tls/--ca-cert-file. Auth mirrors the KAS API client used in the integration tests (HMAC-JWT, audience gitlab-kas). The --arg/--kwarg parsing and the sensitive() builtin are carried over unchanged.

Two commits: the first adds the client command package, the second wires it in and deletes the run-local backend (each compiles independently). The command had no users yet, so there's no deprecation window.

Behavior change: the CLI now requires a running Relay/KAS with the AutoFlow module and its Postgres DBs configured; it no longer executes flows in-process.

Follow-ups (module-developer debuggability)

This MR intentionally keeps the CLI a thin client. It's a solid base, but the debugging story for module authors can be improved in separate iterations:

  • Stream workflow logs to the client. Today a flow's print() output and step progress go to the server's logs, not the CLI — the API has no streaming endpoint. A StreamWorkflowLogs/history RPC would enable live run output and a logs -f <key> command.
  • GDK-free local engine. A one-command local mode that boots the production AutoFlow assembly against ephemeral, auto-provisioned Postgres/Redis, so module authors can iterate without a full GDK.
  • In-process module execution. Register a developer's module through the existing ModuleManager seam (same mechanism as built-in modules) so the engine and the module run in one process with breakpoints — no agent, no tunnel.

These are noted as directions, not commitments; each should be tracked as its own issue if approved.

Merge request reports