cloud-task-orchestrator

Cloud task orchestrator

Contract

Inputs

The human must supply the objective, repository and starting revision, allowed scope, and permission to perform the previewed remote mutations. Obtain the acceptance criteria, branch and merge policy, available cloud-agent interface and credentials, and limits on concurrency, spend, and retries before execution; if any value is absent, treat the corresponding action as unauthorized rather than choosing it. Optional task decomposition or dependency information may be supplied and must be validated against the objective and repository state.

Procedure

1. Validate the repository, starting revision, objective, acceptance criteria, permissions, credentials, and operational limits at their trust boundaries. Reject ambiguous targets, unusable credentials, contradictory criteria, and limits that cannot bound execution. Done when: all inputs are validated at their trust boundaries or rejected with a named conflict.
2. Inspect the bounded work and construct a finite dependency graph whose nodes have a single deliverable, allowed paths, prerequisites, acceptance check, and terminal states. Separate planning, implementation, and independent verification; do not add work that is not required by the objective. Done when: a finite dependency graph is constructed with every node having a deliverable, paths, prerequisites, acceptance check, and terminal states.
3. Present the graph, remote targets, branch plan, concurrency and spend limits, merge policy, and mutation consequences to the human before the first credential use or remote mutation. Stop if the preview does not fit the explicit authorization. Done when: the human approves the preview or the preview is rejected and no mutation occurs.
4. Dispatch only ready nodes. Give each worker its node contract, starting revision, branch, dependencies, acceptance check, and required handoff fields; never let a worker silently widen scope or infer missing evidence. Done when: every ready node is dispatched with its complete node contract.
5. Record each spawn and state transition. A worker handoff must identify its branch and revision, changed artifacts, checks actually run and observed results, unresolved risks, and terminal classification. Empty, malformed, or evidence-free handoffs are failures, not completions. Done when: every spawn and state transition is recorded with complete handoff fields.
6. Run the named acceptance check for each completed node and independently verify that its handoff matches the branch contents and node contract. Return rejected work to a bounded retry only while its retry allowance remains and the next attempt addresses a specific observed failure. Done when: every completed node's acceptance check is run and its handoff is independently verified.
7. Dispatch newly unblocked nodes after their prerequisites verify. Pause dependent dispatch on an andon condition: conflicting branches, stale starting revisions, unavailable checks, unsafe mutations, exhausted limits, repeated equivalent failures, or evidence that the graph is wrong. Done when: all newly unblocked nodes are dispatched or dependent dispatch is paused with a named andon condition.
8. Coordinate merges only in dependency order and under the approved merge policy. Revalidate the target revision and conflicts immediately before each merge; do not merge a node whose verification is missing, stale, or failed. Done when: all approved merges are coordinated in dependency order with revalidated target revisions.
9. Continue until every node is verified and merged as authorized, or terminally blocked, failed, or cancelled. Record the final graph state and report only observed checks and mutations; never claim the done predicate while a node remains running, pending, or unverifiable. Done when: every node has a terminal state (verified/merged, blocked, failed, or cancelled) and the final graph state is recorded.