Skip to content
BranchesTags

Repository files navigation

Zenith

Bodhi AI — the local-first desktop agent that does the work, not just chats.

It uses tools, keeps memory, and shows you every step — not just a final answer. Zenith is its home base: the desktop product, UIs, Rust runtime, optional hosted services, shared memory, computer use, IM integration, and docs in one recursive clone.

Submodule Guard Release Train Versioning 中文 README

▶ Start with Bodhi AI · Lotus · Bamboo · Bodhi Server · Pavilion · Architecture Overview

Bodhi AI turns AI from a chat box into a desktop workbench that actually does the work: you hand it a task, it uses tools, keeps memory, and produces results — and you can watch the whole thing happen. Zenith ties the product, the UI, the execution engine, optional hosted services, and the docs together — and keeps their releases in sync.

Key capabilities at a glance

Capability What it means
A map of the whole system One repo shows how product, UI, runtime, backend, and docs divide the work and fit together
Nine submodules, one clone Pull the full product stack and companion services in a single recursive clone
Coordinated release train Lotus → Bamboo → Bodhi published in dependency order, all driven by one config file
Daily nightly versioning Calendar-versioned (YYYY.M.N) auto-bump and nightly release
Submodule guard CI validates submodule pointers on pushes to and pull requests targeting main
Clear "start here" routing Whether you want the product, the frontend, or the runtime, there is a clear door in

Architecture

Zenith holds almost no business logic itself. It is a thin-shell monorepo: it pins nine Git submodules, owns the root-level documentation, and orchestrates releases across repos. The real features live inside the submodules.

graph TD
  Z["Zenith (this repo)<br/>submodule pointers + release train"]

  Z --> B["Bodhi AI<br/>desktop product surface (Tauri shell)"]
  Z --> L["Lotus<br/>React + Vite UI layer"]
  Z --> R["Bamboo<br/>local-first Rust agent runtime"]
  Z --> S["Bodhi Server<br/>optional hosted service"]
  Z --> P["Pavilion<br/>website & docs"]
  Z --> J["Jiandu<br/>Rust memory crate + stdio MCP"]
  Z --> N["Nova<br/>computer-use MCP server"]
  Z --> LN["Lotus Next<br/>experimental frontend track"]
  Z --> M["Magpie<br/>IM connector for Bamboo"]

  B -. starts / reuses / health-checks .-> R
  R -. packaged builds serve embedded frontend .-> L
  L -->|HTTP APIs + shared /v2/stream WebSocket| R
  L -. legacy SSE fallback .-> R
  R -. optional /proxy/* when configured .-> S
  P -. explains .-> B
Loading

Note —— Bodhi owns the native desktop shell and the Bamboo sidecar lifecycle: it starts or reuses bamboo serve and waits for it to become healthy. Packaged builds load the Lotus UI served by Bamboo; development keeps Lotus on its Vite dev server while Bamboo runs alongside it. Lotus sends requests over HTTP and receives live events through the shared /v2/stream WebSocket by default, with legacy SSE only when WebSocket is disabled or its initial connection cannot be established. Bodhi Server is optional for local operation and is used, when configured, for accounts/authentication, credential storage, quota/billing, model routing, and provider proxying.

What each module does

Module Path Role Start here
Bodhi AI bodhi/ Product surface: Tauri shell, native integration, packaging, and managed Bamboo sidecar lifecycle Bodhi AI
Lotus lotus/ UI layer: React + Vite, HTTP requests, shared WebSocket live events, legacy SSE fallback, view state, settings Lotus
Bamboo bamboo/ Execution engine and production Lotus host: local-first Rust runtime with HTTP, WebSocket, and legacy SSE APIs Bamboo Agent
Bodhi Server bodhi-server/ Optional hosted Go service: accounts/auth, API keys, encrypted provider credentials, model routing, billing/quota, provider proxy Bodhi Server
Pavilion pavilion/ Website & docs: download page, doc center, public narrative Pavilion
Jiandu jiandu/ Authoritative shared memory: independent filesystem-backed Rust store, embedding-free lexical recall, host-generated Dream snapshot persistence, and one-tool stdio MCP Jiandu · agent guidance · portable Skill
Nova nova/ Computer use: native desktop interaction exposed through MCP Nova
Lotus Next lotus-next/ Experimental parallel UI track: responsive React + Vite rebuild without current feature-parity or production-readiness claims Lotus Next
Magpie magpie/ IM integration: standalone connector and Bamboo service plugin Magpie
Zenith (root) . Coordinator: submodule pointers, root docs, release train You are here

Signature deep-dives

Start here routing

Zenith's biggest job is getting any person to the right door fast.

If you just want to understand the product

If you want to build

  • Desktop product / Tauri shell → bodhi/
  • Frontend interaction / React UI → lotus/
  • Agent runtime / Rust backend → bamboo/
  • Optional hosted accounts / credentials / routing / billing → bodhi-server/
  • Website / docs / public content → pavilion/
  • Shared-memory MCP → jiandu/
  • Computer-use MCP → nova/
  • Experimental next-generation UI → lotus-next/
  • IM connector / Bamboo service plugin → magpie/

The stack, organized on purpose

The core product path is split so each layer can evolve on its own yet converge into one product at release time:

  • UI & experience live in Lotus (React/Vite); requests use HTTP and live events use one shared WebSocket by default, with legacy SSE fallback.
  • Execution and production UI hosting live in Bamboo (Rust), local-first and runnable as a standalone service.
  • Optional hosted accounts, credentials, model routing, quota/billing, and provider proxying live in Bodhi Server (Go) when configured. The local Bodhi + Bamboo path does not require it.
  • The desktop shell lives in Bodhi: it owns native integration, packaging, and the managed Bamboo sidecar lifecycle, while Bamboo serves the embedded Lotus frontend in release builds.
  • Public narrative lives in Pavilion, decoupled from code.

Four companion submodules keep separate boundaries: Jiandu owns the authoritative filesystem memory root, deterministic embedding-free lexical recall, host-generated Dream snapshot bytes, and the one-tool stdio MCP server. Hosts choose query terms, optional reranking, prompt placement and budgets, and Dream generation and cadence; the optional portable Skill teaches this contract but must be explicitly enabled by its host. Nova provides computer use over MCP; Lotus Next is an experimental frontend track developed alongside Lotus and is not the current Bodhi default; Magpie connects IM platforms to Bamboo.

Coordinated release train

Shipping several repos at once, in dependency order, is error-prone. Zenith reduces it to one config plus one workflow.

The order is fixed by the dependency graph:

  1. Lotus → publish npm package @bigduu/lotus (publish-npm.yml in bigduu/Lotus)
  2. Bamboo → publish crates, embedding that exact Lotus as the web frontend (publish-crate.yml in bigduu/Bamboo-agent)
  3. Bodhi → build & ship desktop assets consuming both (release.yml in bigduu/Bodhi-AI)

Between steps, the train waits until the artifact is actually visible on crates.io / npm before continuing (see wait_for_crates_version / wait_for_npm_version in release-train.yml). All versions and refs default to .github/release-train.config.json (from_manifest), and can be overridden when dispatched manually.

The train also supports partial releases: dispatch with targets (e.g. bamboo,bodhi) to release a subset — excluded repos are pinned to the last published versions recorded in the config, and a pre-flight check refuses to reuse an already-published version (pass resume=true to resume a partially completed train instead). After a successful run, the train writes the published versions back to the config, and the nightly bump additionally scans the registries for the month's highest published number — so the counter never collides with an ad-hoc release.

The live refs, release versions, and options are maintained in .github/release-train.config.json; the README intentionally does not copy a version snapshot that will go stale.

Related workflows (under .github/workflows/):

Workflow Purpose
release-train.yml Coordinated release (full or partial via targets): Lotus → Bamboo → Bodhi
nightly-release.yml Daily nightly auto-bump (YYYY.M.N) at 04:00 UTC
submodule-guard.yml Validates submodule pointers on pushes to and pull requests targeting main

Default policy —— Normal releases go through Zenith's release train; per-repo standalone flows are for recovery or special cases only.

Quick start / Development

Clone the full stack

git clone --recursive https://github.com/bigduu/Zenith.git
cd Zenith

Already cloned without submodules:

git submodule update --init --recursive

Run the desktop app

cd lotus
npm install
cd ../bodhi
npm install
npm run tauri:dev

tauri:dev builds ../bamboo as the managed debug sidecar, starts ../lotus with Vite HMR, and launches Bodhi. Bodhi starts or reuses Bamboo and waits for its health endpoint, while the development UI remains on Vite; packaged builds load the Lotus frontend served by Bamboo. See bodhi/package.json and the Bodhi README.

Run the UI on its own

cd lotus
npm install
npm run dev

The Vite UI can start on its own; live agent data requires a separately running Bamboo service.

Run the agent runtime

cd bamboo
cargo run -- serve --port 9562

bamboo serve accepts optional --port / --bind / --data-dir / --static-dir / --workers overrides. Without --port it uses the configured port. Run bamboo --help for the current command surface and see the Bamboo README for authoritative usage.

Manage submodule pointers

# show pinned revisions
git submodule status

# pull latest upstream commits
git submodule update --remote --recursive

# after submodule work, bump pointers from root
git add .gitmodules bamboo bodhi bodhi-server jiandu lotus lotus-next magpie nova pavilion
git commit -m "chore: bump submodule pointers"
git push

Workflow: Develop, commit, and push inside the submodule first, then bump and commit the pointer in Zenith. Full release steps live in AGENTS.md.

The rest of the stack

Module Repository
Bodhi AI — desktop product surface https://github.com/bigduu/Bodhi-AI
Lotus — React UI layer https://github.com/bigduu/Lotus
Bamboo — Rust agent runtime https://github.com/bigduu/Bamboo-agent
Bodhi Server — optional hosted accounts, credentials, routing, billing/quota, and provider proxy https://github.com/bigduu/bodhi-server
Pavilion — website & docs https://github.com/bigduu/Pavilion
Jiandu — filesystem-backed Rust memory library + stdio MCP server https://github.com/bigduu/Jiandu
Nova — computer-use MCP server https://github.com/bigduu/Nova
Lotus Next — experimental parallel frontend track, not the current Bodhi default https://github.com/bigduu/lotus-next
Magpie — IM connector for Bamboo https://github.com/bigduu/Magpie

Key docs

Only clicking one link? Open Bodhi AI. Want the why? Read the Zenith Architecture Overview.

About

Nine-submodule workspace for a local-first AI system: Bamboo runtime, Lotus/Bodhi UX, Jiandu memory, Nova computer use, Magpie connectors, optional hosted services, and docs.

Topics

ai-agentdesktop-agentgollm-agentlocal-firstmcpmonoreporeactrusttauri

Resources

Readme
Activity

Stars

5 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages