Remote command workflow action

The existing CRM automation builder, REST automation routes and five automation MCP tools share one strict remote_command action. It selects an existing machine, an existing delegated grant and canonical screenshot or click arguments. There is no script, shell or arbitrary command input. Browser-machine profiles are excluded from this initial adapter.

Example action:

{
  "kind": "remote_command",
  "machineId": "<existing machine UUID>",
  "grantId": "<existing delegated grant UUID>",
  "command": { "kind": "click", "args": { "x": 120, "y": 80 } }
}

A browser session can edit a stopped draft. Live enable must be approved by the revision creator using their actual current delegated organization API key with crm, machines and write scopes and the explicitly selected live grant. Ordinary standard user-custody org keys are supported; token-derived, personal/scoped, runner and service-custody credentials are refused. No key, grant, consent or privilege is created by enabling a workflow. Dry run records planned steps and submits zero commands.

Approval atomically stores a content-free audit binding to the organization, workflow, revision/input digests, creator ceiling, key/persona and selected principal/machine/grant. It stores no bearer secret. Current creator permissions, key state, role ceilings, persona, organization policy, machine state and consent are resolved again at dispatch and before continuation. References and the triggering event never supply machine authority.

The workflow transaction commits one waiting step and continuation before admission. The existing once-a-minute automation-wait sweep claims it and calls the canonical machine command producer with a deterministic operation identity. No SQL lock is held while waiting for a device. Exact command/principal/payload readback recovers a command committed before a lost workflow receipt. A dispatch claim with no readable command becomes unknown and never resends automatically.

If the admission response itself is lost, exact readback permits queued-only recall while the run remains failed with an unknown outcome. Sent work stays in flight. A delayed admission receipt cannot overwrite an already terminal failure, including a competing sweep's readback outage.

Queued, awaiting approval, sent and running remain waiting. Only canonical acknowledged ok with valid current authority, lease/approval and an in-time completion can resume the same run. Screenshot success also requires a referenced canonical nonempty screenshot artifact. Artifact bytes remain behind the existing authorized artifact-content endpoint; workflow history stores references and structured state. Failed, cancelled, missing, expired and unknown outcomes block later actions.

Stop, disable and edits fence continuation and attempt canonical queued/awaiting-approval recall. Sent or running work may already have acted and cannot be recalled. History exposes command/artifact IDs and cannot_recall_in_flight; a late acknowledgement never revives the stopped run. Stop does not pause machines or revoke unrelated grants.

The capability catalog derives the action schema from the same runtime schema. Official generated documentation remains parent-owned. Recording-device tests do not establish physical desktop reliability. Other command kinds, physical pilot testing, agentic judgement, key brokerage and the broader agentic workflow remain separate work.