Documentation Getting started
Examples
Start with a working CLI example, then explore the agent handoff and app-testing workflows Cella is building.
On this page
Inspect your setup
Available today · CLI inspectionAfter building the CLI or using the Debian CLI-only bootstrap, inspect its version, build information, and runtime prerequisites. Run these from the repository root.
./target/debug/cella --version
./target/debug/cella info
./target/debug/cella doctor --wallAlternative: installed Debian CLI
If you used the bundled CLI on Debian 13 x86-64, Rust and a C compiler were not required. Use its installed command name:
cella --version
cella info
cella setup --plan
cella doctor --wallThe bundled unsigned alpha artifact is SHA-256 checked by ./install.sh. It installs only the user-local CLI, not the runtime. setup --plan remains read-only and reports that release installation is not authorized.
What to expect: version and build-target information, followed by a report of runtime prerequisites. Before runtime setup, missing dependencies and a nonzero doctor exit are expected. These commands inspect your setup; they do not start an agent.
Explore the CLI referenceContinue a password reset task
Planned workflowYou start a password reset feature with Codex. Later, you want Claude to finish the tests without reconstructing the work.
- Start the task. Codex edits a private repository copy within a Workstream for the password reset feature.
- Save a checkpoint. Retain the files, declared task state, completed checks, and notes about what remains.
- Hand off the work. Claude starts a new Run from that checkpoint and finishes the reset-token tests.
- Review the result. Inspect the selected patch, checks, policy, and required approvals together before delivery.
The checkpoint carries explicit work state and handoff notes. It does not transfer hidden model reasoning.
How Workstreams carry the taskTest an app with scoped access
Planned workflowThe reset flow depends on an app and a database. The agent needs to test the behavior; the database credentials belong to the app.
- Run the app separately. A Service Cell runs an approved, sealed app revision with its own authorized secrets.
- Grant the test connection. A named Channel allows the Agent Cell to reach the approved app endpoint.
- Check the behavior. The agent tests reset-token expiry through that scoped connection, without receiving the app’s reusable credentials.
- Approve updates explicitly. Testing new code in a secret-bearing service requires a new sealed revision and the applicable policy and approvals.
A connection to the app does not grant general host networking or permission to read the Service Cell’s secrets.