workflow-local

# Run a team workflow unattended The local driver runs a whole run in one process on this machine: each command step as a process, each prompt step through a headless tool. Nobody is asked anything while it runs, so every answer the run needs is decided before it starts. ## When - A CI job or a cloud agent runs the workflow. - `teamai workflow start --describe <name> --driver skill` answered `ask.kind: local`: a coding session cannot run some step, and `ask.reason` says which. - A run continues on this machine without a coding session: after a retry, an answer, a stopped driver, or a session that handed it over. ## Run it 1. Run `teamai workflow start <name> --describe` and read the inputs it lists. 2. Start the run: `teamai workflow start <name> --driver local`, with the inputs as one JSON object in `--inputs`. `teamai workflow start --help` lists the other options, such as answering optional approvals and picking the prompt tool. 3. To continue a run that stopped, run `teamai workflow resume <run>`. The command exits when the run ends: 0 when it succeeded, 1 when it failed or was cancelled. It also exits 0 when it hands the run to a person (see Approvals). A failed run names each failed step, its message and its `teamai workflow retry` command on stderr. Done when it has exited and the outcome, the failing step's message and the pull requests the run opened are reported where the person reads them: the job log, or your reply. ## Approvals Without a terminal, nobody answers a gate during the run: - With `--auto-approve`, or the member's `workflows.auto_approve`, an optional approval is answered yes and a choice takes its default. - Without either, an optional approval is skipped. - A required approval, an interactive step, or a choice neither answers hands the run to a person: the command publishes the run offered on teamai-reports, prints the step and `teamai workflow resume <run> --claim` on stderr, and exits 0. Report that command where the person reads it. - When the run cannot be offered, that step fails `hitl_required`, and its message says why and how to continue it. ## From an agent session A coding agent's session may start or continue only a workflow whose `invoke` allows it, with `start` or `resume`. `invoke: allow` goes on. `invoke: ask` goes on once the person agreed, with `--confirmed`, and never in an unattended run (CI or a cloud agent), where it answers `unattended_denied`. `invoke: deny`, the default, answers `invoke_denied`. Tell the person the `message`, which names the command for their own terminal. Inside a workflow step, every `teamai workflow` command that changes a run answers `nested_workflow`. Do the step's own work there instead. ## Env and secrets A step gets the team env keys its `requires.env` lists, and no other team key. A key with no value on this machine fails the step `missing_env` before it runs, and the message names the fix: `teamai env set KEY` for a key the team declares; for one it does not, the environment, or `teamai env add KEY --secret` followed by `teamai env set KEY`. The person runs `env set` in their own terminal. A CI job exports each secret under its key name instead. TeamAI masks the value of every key in `env/secrets.yaml` in run files and output. ## CI When you set up a CI job that starts a run, or one that takes the runs members offer, read `references/ci.md`.