Coordinate a change across repositories
Update an API and its clients, review each branch and approve their integration.
What this example covers
Section titled “What this example covers”- Multiple repositoriesOne task per checkout, each with its own sandbox and branch.
- Typed responsesThe API agent returns a validated description of its change.
- Tasks and dependenciesThe clients start after the API and read its output.
- Concurrency, retries and timeoutsBoth clients run at the same time.
- ApprovalsA maintainer decides before anything merges.
- Durable runsThe checkpoint keeps finished work between runs.
Write the script
Section titled “Write the script”Save the script next to the configuration from Installation, and replace its three repository paths with your checkouts. Each repository gets a separate branch; one approval controls the integration steps.
Define the API change and the output that the clients will receive.
Update the clients, wait for approval, then integrate each branch explicitly.
Keep the run in a checkpoint and use rename-field.ts to start or resume it.
Run the script
Section titled “Run the script”Run the entry script to create the branches and pause at the approval gate. It leaves the changes available for review in each repository.
It prints paused: the three branches exist and wait for review. Inspect outpost/rename-user-name in each checkout, then decide.
It prints done. The branches are merged into each checkout’s current branch, API first. Nothing is pushed.
Understand the steps
Section titled “Understand the steps”Checkpoints hold JSON only. Each wrapper task therefore calls its isolated task’s perform() and keeps repository, branch and commits, not the dispatch result.
Handle a repository failure
Section titled “Handle a repository failure”Each repository has its own branch and history: nothing spans them. By default a failure cancels the running tasks; stopOnError: false lets the other client finish.
| What you see | What to do |
|---|---|
api failed, clients skipped | Read task.error, fix the cause, run node rename-field.ts retry. |
One client failed, the other done | retry reruns only the failed client, on the same branch. The others come from the checkpoint. |
approve rejected, merge skipped | The branches stay. Rework them, then start a new run with another runId. |
merge failed after merging the first checkouts | Update the blocked branch, then retry: already merged branches are no-ops. |
Adapt the example
Section titled “Adapt the example”Add repositories
Section titled “Add repositories”Add an entry to clients, such as client("cli", "/projects/cli"). The approval, the merge and concurrency follow the list.
Use cloud sandboxes
Section titled “Use cloud sandboxes”Replace sandboxProvider with a provider from Cloud sandboxes. Each task uploads its repository, and the agent’s commits come back to the host checkout before merge runs.
Review before approval
Section titled “Review before approval”Insert a read-only review task per client between the clients and approve, and list the reviews in the gate’s after.
The paused run then holds each review: read it with result.value(task) before deciding.
API: defineIsolatedTask · defineJsonResponse · defineApprovalTask · WorkflowOptions · WorkflowCheckpointOptions.