Known limitations

Orgabot's governing principle is that a refusal you can act on beats a guess you have to detect. This page applies the same rule to the product itself: everything below is something Orgabot currently does not do, written down so you meet it here instead of at the point of failure.

Where a limitation shows up as a hold, that is deliberate. A held mission has kept its branch, its worktree, and its evidence, and it is waiting for something specific. It is not lost work.

Platform

The local product is macOS-first. The dashboard, CLI, workers, launchd scheduler, and voice app receive their primary end-to-end testing on macOS. Linux and Windows secret custody are implemented, and the provider contract can compose hosted and hybrid deployments, but this is not a promise that every local surface has equal cross-platform packaging and acceptance coverage.

The full cloud-only profile is not runnable yet. Isolated hosted tenant control planes, managed PostgreSQL, object storage, cloud secret custody, and the published GitHub App trust service are implemented. Managed Restate, cloud sandbox workers, managed edge ingress, managed scheduling, and managed backup remain declared providers that resolution refuses until implemented. Use orgabot topology --matrix for the code-derived status of every provider.

Setup that still needs a terminal

The first-run journey now saves and resumes its safe draft, connects GitHub, imports a project, records an explicit verification choice, selects an issue source, and launches the first mission. The CLI remains necessary for advanced topology configuration, migration and recovery commands, package-signing operations, and low-level diagnostics.

Workflows

Ten workflow shapes are supported: conversation, bounded interactive task, troubleshooting, research and report, review and audit, issue creation, repository change, external operation, Orgabot control, and release. A turn resolves to exactly one, and a turn with no repository change takes no outward action at all.

Two terminals cannot yet be confirmed, so they hold:

• External operations through a connector. Orgabot can act through a governed connector but cannot yet independently re-observe the effect, and it will not report an effect it has not seen. Such a turn records the worker's account and holds.
• Control actions other than cancel. cancel is performed and confirmed by re-reading the mission. retry, reprioritize, pause, and resume are recognised and refused as unsupported rather than half-attempted.

A control action names its target explicitly. "Cancel the stuck one" is refused. Orgabot will not choose which mission you meant, because the cost of choosing wrongly is cancelling someone's running work.

Changing intent mid-session starts a new mission. A follow-up that crosses between read-only and effectful work is refused in place and offered as Continue in New Mission, which inherits the conversation and the correlation id. The new run re-resolves scope, role, authority, policy, and gates, none of which continuing in place would have done.

The dashboard terminal

The terminal persists the mission session, streams output, supports follow-up rounds, and renders the resolved workflow outcome and its evidence. Some specialized governance and recovery actions still live in their dedicated tabs or the CLI rather than in the terminal itself.

Live steering across processes is disabled. A mission launched by the CLI and steered from the dashboard queues the instruction for the next round rather than injecting it. This is a decision, not an oversight: the bridge stays off until worker isolation and a capability issuer exist.

Onboarding

The full-screen first-run journey is resumable across refreshes and the GitHub round trip. It deliberately stores only safe draft choices in the browser; credentials and connector secrets are never part of that draft.

Durability

Quick start works with Restate absent, and those missions are labelled Not restart-safe. Durable mode is the restart-safe one. Enabling durability later does not rewrite history, so missions run before the switch stay labelled as they ran.

What holds instead of failing

Orgabot prefers a hold to a confident wrong answer. You will see one when:

• a gate cannot be decided by the process that produced the change;
• a required approval is not recorded;
• a release or external effect cannot be re-observed;
• a connector a role depends on is unavailable, and falling back would silently re-attribute the action to your personal identity;
• an organization maps the project but no role can be selected for the mission.

Each of these names the one thing that resolves it. See Troubleshooting for the hold-by-hold table, and Invariants for why these refusals exist.