One CI runtime for missions, the CLI and agents

Once a project is migrated onto Orgabot's CI runtime, every way of verifying it goes through one path. A mission launched from the CLI, from the dashboard terminal or from an agent skill, the pre-merge gate in the review loop and ship path, the post-merge check, Fix Epic children, and orgabot cicd verify all ask the same question: is this exact commit verified? They all get the same answer.

A project that is not migrated keeps running its registered verification exactly as before. Nothing changes until you give a target ownership of the mission_verification event in the routing config described in CI routing and required checks.

How a verification is routed

The decision depends only on the project and the routing config. It never depends on which surface asked, so two surfaces cannot resolve different definitions.

• If a target owns mission_verification (with a recorded authorization), the project is routed. Every verification runs that target's jobs on the exact commit.
• Otherwise the project uses its registered verification: setup, runtime.verify, and the per-phase authority from its verify policy.

orgabot cicd explain <project-id> prints the decision and the reasons for it, along with a digest of the routing definition. Two requests that show the same digest were decided by the same definition and policy.

A routed project runs its targets even when a phase's verify authority is set to CI. For a migrated project, Orgabot's target is the CI, so a mission runs it instead of waiting on hosted checks. A phase whose authority is none is still skipped.

One commit, one run, one result

Each verification claims a logical key made of the repository, the target, the exact commit, and the context. The first request runs the jobs. Every later request for the same commit (the mission's next phase, the pre-merge gate's second run, an agent checking the same commit, you running orgabot cicd verify) reads that same signed result instead of running the suite again.

A run is retried as a new attempt only when it has no result: a job was blocked, its result is unknown, it was canceled, or the process running it is gone. A new attempt reuses every job that already passed on that commit. If another process is still running the same commit, the request waits for its result instead of starting a second copy.

What a result means

Only the trusted gate decides, from signed exit codes:

A submitted or queued job never counts as passed.

Human actions

When a job is blocked on something only a person can provide, Orgabot records it as a Human TODO on the mission. Examples are an approval, a credential or permission, an unavailable runner, or a spend limit. You can see these with orgabot todos and on the mission's detail page. Each one names the exact action, why an agent cannot take it, and how to confirm it worked. They are cleared the next time the verification gets a real result.

Automation can finish every safe step, but it never reports a run, a migration or a release as complete while one of these actions is still open. orgabot cicd inspect --json reports complete: false in that case, and orgabot cicd plan prints "Migration not complete" until every stage is done and no human task remains.

Legacy workflows stay retired

While a project is migrating, a change must not turn a retired GitHub Actions workflow back on. If a target lists a workflow in legacyWorkflows and Orgabot owns an event for that target, any change that makes the workflow trigger on that event again fails verification. The failure explains which trigger to remove, and it goes through the normal repair round. This applies to every mission, including Fix Epic children, so an epic cannot quietly restart expensive hosted runs. A trigger that was already there before the change is not blamed on it.

Commands

All commands accept --json for agents. The same commands work in the dashboard terminal (orgabot shell).

The dashboard offers the same read views at GET /api/cicd/explain/<project-id> and GET /api/cicd/runs/<run-id>.

Costs are reported as durations for every job. Local jobs have no metered spend. Spend for remote jobs is recorded by the dispatch backend (orgabot ci-dispatch status), so the run view shows it as unknown rather than guessing.

Automation permissions

These rules hold no matter who runs the command, a person or an agent inside a mission:

• Retry re-runs the same target on the same commit in the same context. It cannot change the commit, the commands, the jobs or where they run. An agent may retry. Retrying a real failure re-runs it; it does not turn it into a pass.
• Remote fallback happens only when the repository's routing config records an approved remoteFallback. No flag turns it on. Without one, a local job whose controller is offline stays pending, and the required check stays expected.
• Placement, ownership and approvals come only from the routing config. Unknown flags are refused, so a flag like --remote or --force does nothing but print the usage.
• Policy changes are refused inside a mission. orgabot cicd policy set exits with an error when an agent runs it. When you run it, every new authorization in the file must be an approved request in the approval store. A hand-written approval id is refused.
• Production gates are not part of this surface. Releases, signing, promotion and deployment keep their own approval gates, and nothing here can bypass them.