BrightVision
Native · Lean · Autonomous

AI-assisted coding
without the IDE baggage

BrightVision is a lightweight, cross-platform desktop app built with Tauri and React. Privacy-first: run frontier models locally via Ollama + built-in Local LLM, not rented cloud inference. Cursor-like AI coding through a clean, focused workspace — powered by Cecli (dwash96/cecli): coders, agents, MCP, and local models. BrightVision wraps Cecli with a headless bright_vision_core HTTP/SSE API (no terminal UI in the app). Lineage: Aider → Cecli → BrightVision. We work closely with the Cecli team to improve both products — shared spec/EARS engine, agent behavior, and quality gates that land in Cecli and BrightVision together. Testing (including BrightVision Test Lab) is a key part of that loop. Details ↓

First-class in days, not months Homebrew cask Signed & notarized DMG Tauri v2 + Rust React + TypeScript macOS · Linux · Windows MIT License
BrightVision chat with streaming answer and Mermaid diagram
Chat with Mermaid, tasks, editor, and git in one native shell

Early project — expectations. BrightVision is new software with ambitious goals. You should assume imperfections, rough edges, and incomplete features until proven otherwise. We are actively fixing issues, but this is not a product from a large vendor with dedicated QA — please calibrate expectations accordingly. If something breaks or behaves oddly, report it on GitHub Issues and we will iterate as quickly as we can.

In the app

Long Ollama turns stay legible in the activity bar; risky shell commands get a Yes/No confirm in the shell. Settings records per-turn response, TPS, and CPU/RAM/GPU with CSV export and a live resource overlay in the rail.

Activity bar with Response and Think timers, Ollama wait, and shell command confirmation
Activity bar — FINISHING TURN, Response/Think, ~ETA, Ollama wait + confirm shell command
Tasks tab with spec-driven todos
Tasks — EARS/spec workflow, generate, Implement
Editor with file tabs and explorer
Editor — CodeMirror tabs, explorer, git badges
Git panel with commit graph and working tree
Git — graph, stage, commit, undo (desktop)
Settings with timing history table, TPS and resource columns, CSV export, resource overlay
Settings — timing history (avg/p90, TPS), per-turn CPU/RAM/GPU, CSV, resource overlay

Eight meanings behind the name

BrightVision is not a rebranded terminal wrapper. The name encodes how we think about AI-assisted engineering: spatial clarity, sovereign infrastructure, and supervision over typing.

01

Vision as the visual IDE

The spatial interface angle

The command line is powerful, but it lacks spatial context. Traditional IDEs have context, but they are bogged down by corporate bloat and plugin fatigue.

BrightVision is the bridge. It extracts the raw, terminal-native power of an agentic core and wraps it in a focused, high-telemetry visual command center — inline diffs, token stats, and multi-repo file trees on a lean, memory-efficient Tauri stack. A visual workbench for the systems architect, without heavyweight telemetry tracking every keystroke.

02

Vision of the future

The sovereign stack angle

The industry’s default future is rented: you rent the AI, you rent the compute, and you surrender your IP to the cloud for autocomplete.

BrightVision is a declaration of independence — a future where developers own their infrastructure. Pair Ollama with built-in Local LLM controls to pull and preload models on your hardware. Your prompts, architecture, and proprietary code stay on your machine — not a rented cloud autocomplete bill.

03

Vision as literal sight

The multi-modal angle

Systems engineering is visual — whiteboards, UI layouts, schematics — yet most AI pair programmers have been completely blind.

BrightVision gives your agent eyes. Image and PDF context flow into your local workflow so you stop translating diagrams into prose. Drop in a system diagram, a UI mockup, or a failing terminal snapshot and let the agent see the problem. It closes the loop between the design in your head and the code on disk.

04

Vision as absolute transparency

The unclouded angle

Most modern AI IDEs are black boxes: you send code into the void and an answer comes back.

BrightVision offers clarity end to end. Running on your own silicon means no opaque cloud endpoint and no hidden scraping of your IP. You get 20/20 vision into what the agent is thinking, doing, and executing — streamed events, proposed edits, and a technical terminal you can audit.

05

Vision as systems-level oversight

The architect angle

Generic tools get lost the moment a project scales beyond a single folder.

BrightVision provides eagle-eye scope. Multi-repo and submodule awareness are first-class: it does not just see a file, it sees the architectural landscape. Macroscopic vision for safely orchestrating complex, interconnected systems — from superproject layouts to stacks like BrightChain.

06

Vision as intent

The spec-driven angle

Standard AI coding is reactive: you ask, it types.

BrightVision shares your intent. The completed EARS module provides lint, index, and trace gates for spec-driven tasks — WHEN/SHALL requirements, layered specs, and steered Implement steps keep the agent aligned with your architecture instead of guessing the next line.

07

Vision as supervision

The director angle

Typing is the lowest-leverage activity an engineer does.

BrightVision elevates you from typist to director. You supply the vision; the agent supplies labor. Review proposed architectural diffs, confirm risky changes, queue and stop turns — guide the project from the captain’s chair instead of grinding syntax.

08

Vision as illumination

The dark code angle

Legacy codebases and undocumented modules are dark matter — known to exist, expensive to map.

BrightVision illuminates those corners. Repo mapping, dependency context, git diffs, and structural signals surfaced in the UI cut hours of mental reverse-engineering. Dark code becomes navigable terrain.

Built for developers who want speed, not bloat

No Electron shell. No VS Code fork. A native Rust shell, minimal React UI, and a headless cecli engine — shipped as a coherent product in days of dogfood, not a demo. Full list: docs/FEATURES.md.

01

Vision HTTP API

Every turn is POST /sessions/…/messages + SSE. React is the head; Cecli is the agent body, bridged by bright_vision_core.

02

Chat & streaming

Thinking / Reasoning / Answer, Mermaid + code fences, proposed edits, confirm, queue/stop, clear history + /clear, Inter chat font (Glass TTY optional in Settings).

03

Turn timing & ETA

Live Response/Think in the activity bar, ~Nm left* estimates, per-model history with TPS and avg/peak CPU/RAM/GPU (desktop).

04

Local LLM & router

Ollama panel, model hopper preload, fast/heavy routing, escalate-to-heavy when the fast model stalls — built for Apple Silicon dogfood.

05

Agents & sub-agents

cecli /agent, /invoke-agent, /spawn-agent, /reap-agent; registry chips in chat; GET …/subagents when session is live.

06

Suggested files

Parses assistant answers for repo paths; tray with Add all, queue /add, and proceed when the model waits.

07

Tasks & specs

.cecli/todos.json, layered EARS specs, generate/refine, background jobs, steered Implement (v1–v5). EARS module complete: lint, index, trace, and spec-driven gates for reliable AI workflows.

08

Editor rail

File tabs, CodeMirror 6, collapsible explorer, git badges, open from chat — separate from Chat on the left rail.

09

Git tab

Branch, ahead/behind, working tree, stage/commit/undo, commit graph — native Rust on desktop.

10

Context & attach

Session file chip, token estimates, images/PDF, terminal tail, folder attach, /add Tab completion (desktop).

11

Superproject git

Multi-repo RepoSet — dogfood BrightVision on the superproject, not the submodule folder alone.

12

Native shell

Tauri v2, resource overlay, signed macOS builds, Playwright e2e + core pytest — lean by charter.

Lineage — Aider → Cecli → BrightVision

BrightVision is built in close partnership with the Cecli team. We collaborate daily on the shared coding agent, spec-driven workflows, and HTTP integration — shipping new features and raising quality for both Cecli and BrightVision rather than forking in silence. The coding agent is Cecli (dwash96/cecli), evolved from Aider. BrightVision adds a desktop shell and headless bright_vision_core/ HTTP/SSE in this repo — users never drive the Cecli terminal UI inside the app.

Docs: BrightVision (this site) · Cecli (agent docs at cecli.dev) · BrightVision on GitHub (bright_vision_core/ + cecli/ submodule).

Head and body, cleanly separated

BrightVision beheads the Cecli terminal UX for this product. The Cecli engine still runs every turn; users interact only through the Vision HTTP API — not the interactive CLI. Engine improvements flow both ways: Cecli upstream and the cecli/ submodule in this repo are kept aligned through shared development and automated testing.

Backend Rust + Tauri v2 Frontend React + TypeScript + Vite Styling MUI v6 + Emotion Packages Yarn (PnP) Agent Cecli

Self-evolving by design. Primary validation is dogfooding on real repos via yarn tauri dev — same API and chat workflow you use for your own projects. See the living roadmap.

What’s shipped, what’s next

Summary aligned with docs/ROADMAP.md — update that file (and this page when publishing) when statuses change.

Done Partial Open Longer-term

Current focus: Dogfooding — workspace = superproject root (BrightVision/), not a submodule folder alone. Quick test: yarn test:local; before bigger changes: yarn test:full. Submodule verification sections A–D gate “hack on Vision itself.”

Done Chat & session

  • Stream dedupe + tool timeline order
  • Proposed edits, confirms, queue/stop, clear + /clear
  • Fences, Mermaid, timing bar, turn ETA
  • Agents bar, suggested files, model router

Done Spec-driven (#18)

  • Tasks v1–v5: todos API, layered specs
  • Generate/refine spec, Implement steps
  • Background generate-spec jobs
  • EARS module v1: lint, index, trace, verify gates

Done Git & engine

  • Git tab (#27): diffs, graph, stage/undo
  • Core lifecycle, manual commit option
  • Activity-bar scan progress

In progress & backlog

# Status Item
19 Done Submodule verify — automated green; dogfood gate & integration tests
26 Partial Git status poll (8s); native file watcher open
28 Done Context attach, images/PDF, folder attach, suggested-files tray
32 Done Suggested files — parse Answer paths; tray + Add all / queue /add batch
30 Partial Web dev via proxy; desktop-first generate-spec parity
31 Done Release hygiene — tag core, bump submodule pointer, verify script
20–22 Done Spec agent UX, EARS linter/index/trace, repo-wide spec index
29 Longer-term Plugin / extension system

Suggested order while dogfooding: #19 manual pass → friction from real use → #28 if context hurts → #31 when sharing builds → #20–22 spec depth → plugins / web parity.

Full roadmap on GitHub →

Up and running in minutes

macOS

Homebrew — signed & notarized DMG

The fastest way to install on macOS. The cask downloads a universal (Apple Silicon + Intel) signed and notarized DMG — ready for Gatekeeper — and installs BrightVision.app to /Applications/.

brew tap digital-defiance/tap
brew trust --cask digital-defiance/tap/brightvision
brew install --cask brightvision

Homebrew 4.6+ requires trusting the cask once before install. If brew install fails with a trust error, run the brew trust line above and retry.

Tap: digital-defiance/homebrew-tap

Local LLM (recommended)

Privacy-first: Ollama + built-in Local LLM

Install Ollama from ollama.com (Vision does not bundle weights). The desktop app can start Ollama, pull your model, and preload it — you configure a small env file first, then use Settings or Terminal → Local LLM.

Where to put env variables

Use one of these (same keys; different filenames). If you use more than one, later paths win (repo local-llm.env overrides XDG env).

Location Filename Notes
./local-llm.env (repo root) local-llm.env Recommended for development — copy from local-llm.env.example
~/.config/local-llm/env env (no .env extension) XDG / legacy local-llm layout — the file is literally named env

Option A — repo root (recommended)

# In the BrightVision clone
cp local-llm.env.example local-llm.env
# Edit DATA_MODEL and optional OLLAMA_HOST

Option B — XDG config

mkdir -p ~/.config/local-llm
cat > ~/.config/local-llm/env <<'EOF'
OLLAMA_HOST=http://127.0.0.1:11434
DATA_MODEL=qwen3.6:27b-q4_K_M
EOF

Example contents (either file):

OLLAMA_HOST=http://127.0.0.1:11434
DATA_MODEL=qwen3.6:27b-q4_K_M
# Optional — fast/heavy model router (Settings → Sync from env files)
# MODEL_ROUTER=1
# FAST_MODEL=deepseek-coder:6.7b
# HEAVY_MODEL=qwen3.6:27b-q4_K_M
Variable Maps to
OLLAMA_HOST Settings → Ollama API base
DATA_MODEL (or LLM_MODEL / CHAT_MODEL) Settings → LLM model as ollama_chat/<tag>
FAST_MODEL / HEAVY_MODEL Model hopper fast/heavy tiers (bare Ollama tags)
MODEL_ROUTER 1 / true → enable local model router on sync

In the app (three steps)

  1. Settings → Ollama env files — confirm paths, click Sync from env files (fills LLM model as ollama_chat/<DATA_MODEL>, Ollama API base, and optional model router hopper from FAST_MODEL / HEAVY_MODEL / MODEL_ROUTER).
  2. Same section — Start Local LLM, then Ping stack (or use Terminal → Local LLM). Ping checks Ollama inference; it does not start the coding session.
  3. Terminal → Start — spawns the Cecli-based engine (Vision HTTP on :8741) for chat (or enable Auto before session on the Local LLM panel).

Optional: LOCAL_LLM_DIR or Settings → Extra config directory for another folder containing local-llm.env (applied last). Full guide →

Build from source

For development, Linux, Windows, or hacking on the app itself. Requires Node.js 18+, Rust (stable), Yarn 3+, Python venv via activate.sh, and a running LLM (see Local LLM above).

  1. Clone and init submodules

    Fetch the superproject, init cecli/, then source activate.sh (editable Cecli + bright_vision_core).

    git clone https://github.com/Digital-Defiance/BrightVision.git
    cd bright-vision
    git submodule update --init --recursive
    source activate.sh
  2. Install dependencies

    Yarn Plug'n'Play manages packages without a bloated node_modules tree.

    yarn install
  3. Configure local LLM

    Copy local-llm.env.examplelocal-llm.env at the repo root (or use ~/.config/local-llm/env — see Local LLM). In the app: Settings → Sync from env files, then Start Local LLM and Ping stack.

    cp local-llm.env.example local-llm.env
    # yarn tauri dev → Settings → sync → Start → Ping → Terminal → Start
  4. Start development

    Launches the Tauri shell with hot reload for the React front end.

    yarn tauri dev
  5. Build for production

    Package a native binary for your platform.

    yarn tauri build

BrightVision Test Lab

BrightVision Lab screenshot

BrightVision Test Lab is an integral part of how we build both BrightVision and Cecli. It is a separate desktop app (apps/test-lab) that runs the full confidence suite — mocked Playwright, Python core pytest, optional real-LLM lanes, and GPU timing — with live progress, step logs, and resume. The same manifest powers yarn test:everything on the CLI.

Testing is not an afterthought. Spec engine work (EARS, tasks, steering, implement progress) lands in cecli/spec/ with yarn verify:cecli-spec and yarn verify:ears; BrightVision adds HTTP, UI, and e2e coverage before we pin the submodule. Test Lab is the daily loop for dogfooding that shared stack and catching regressions before release.

Docs: TESTING.md · Test Lab README · from source: yarn lab or yarn test-lab:dev

BrightVision Test Lab Remote

BrightVision Lab Remote screenshot

BrightVision Lab Remote is a companion app for BrightVision Test Lab that runs on your phone and shows the progress of the test suite.

VS Code Extension

Kiro users might find this extension handy.