Documentation

Orgabot is a local-first control plane for an organization of AI and human workers. One instruction becomes a governed, verified, delivered mission.

Clone, install the framework dependencies, link the skills, authenticate your tools, and run orgabot doctor, then stand up an organization and map your first project.

The happy path from a registered project to a delivered draft pull request, plus what to do when the mission holds instead of shipping.

The vocabulary (mission, transcript, project, worktree, task DAG, gate, reviewer, draft PR, audit log, autonomy, approval) and how each one shows up in practice.

Update the Orgabot framework in place while preserving registered projects, organizations, connectors, credentials, missions, schedules, and audit history, then verify each surface deliberately.

The localhost ops dashboard is the day-to-day operating surface (overview, missions, repositories, issues, inbox, analytics and budgets), plus the gotchas that come with a long-running process.

How the interactive terminal works: launching by typing or by dictating, streaming output, the one-row head and metadata, structured mission outcomes and their lifecycle, steering a running mission, acknowledged Escape interrupts, edit-only vs operate, and what a follow-up round actually re-runs.

Mission variants, routing and decomposition, the worker that runs them, observation and control commands, and the recovery paths when one dies.

How a change becomes a merged pull request: the independent review loop, PR-state classification, CI and conflict remediation, and the rules the merge path will not bend.

The orgabot command surface, grouped by what you are trying to do: projects, missions, shipping, organizations, roles, connectors, context, budgets, and recovery.

orgabot catchup and the dashboard's "Since you were gone" panel answer one question - what happened while you were away, and where do I continue - from the records Orgabot already keeps.

The org chart is the routing layer: organizations, departments, roles, actors, templates, and the rule that an org-owned mission is owned by a role.

A capability pack is the job training you install into a role: knowledge, procedures, and declared tool needs. It is knowledge-only: a pack never grants access by itself.

How a role reaches an outside service: GitHub Apps with short-lived scoped tokens, adopted MCP servers, brokered tool runs, and the three places a permission gets clamped.

Approval queues and role inboxes, the autonomy envelope a CISO agent may triage inside, the tamper-evident ledger, and the security properties that hold it all together.

Live Context, context sources, memorialization before execution, git-backed organization memory, and the output sinks work is delivered through.

Two different kinds of limit (USD spend budgets over real accrued cost, and quota-denominated tracking for subscription executors), plus the fallback ladder when a pool runs dry.

Watch a Firebase project's App Hosting rollouts and builds so a failed deploy shows up as an Orgabot incident instead of waiting to be found in the Firebase console.

Connect a repository as a governed skill source, admit its content under an owner approval pinned to a commit, and get the same approved skills on every machine with one connect and one sync.

How a department's charter is a versioned blueprint plus your own overlay, how to preview, propose, review, and roll back a change, and the two changes Orgabot refuses outright.

How a department publishes a typed service other departments can request, what a request and a response must carry, and why a service contract grants nothing.

How a payment, journal, credit, or expense is prepared, approved, executed, and confirmed, why the controls are re-evaluated at execution time, and why an unconfirmed action is a real outcome you reconcile rather than retry.

Where Orgabot actually is: the delivered programs, the ones still in flight, what is honestly not built yet, and what is deliberately off the critical path.

The repository's four independent subprojects, the framework source map, the two seams that must stay swappable, and the commands that gate a change.

The load-bearing safety and correctness properties. Each one was written after something broke silently, and none of them may be weakened by a change.

The failure modes that actually happen: holds, wedged missions, stale dashboards, missing node_modules in worktrees, rate limits, and how to tell a broken base from a broken change.

How these pages are built, how to add one, the markdown subset available, and the standing rule that a change to the system carries its documentation update with it.

A mission executes a workflow rather than being one - stages, gates, environments and events as inspectable data, with policy deciding what no workflow may omit.

What the first beta does not do yet, stated plainly, so you find out here rather than halfway through a mission.

Choose where each Orgabot capability runs - local, a cloud provider, or a supported hybrid - and see the resolved answer, its provenance, and the custody boundaries it crosses.