Vigla

<!-- Generated by scripts/build-site.mjs from README.md and ARCHITECTURE.md. -->
<!-- Edit the source documents, then run: node scripts/build-site.mjs --write-llms -->

Open-source mission control for coding agents.
Run cross-vendor workers in parallel worktrees. Audit every submission.
Revert the whole mission when the result is wrong.

---

Five coding agents should not mean five terminals, five diff reviews, and five
unread merges. Vigla gives the work one operations room and gives you one job:
set the authority envelope, then judge the verdict.

| WORK | WATCH | VERDICT | REVERT |
|---|---|---|---|
| Claude Code, Codex CLI, Antigravity, and profile-backed CLIs share one mission | Each worker gets an isolated git worktree and typed event stream | A supervisor checks scope, reversibility, risk, and quality before merge | The accepted mission can be undone with a normal Git revert commit |

Vigla is local-first: a Rust orchestrator, Tauri shell, and SQLite event store,
with no cloud control plane, product account, or product telemetry. It
supervises the command-line tools you already use; it does not wrap model APIs
or add another billing layer.

> **Recovery receipt — 27/27.** Every seeded failure trajectory escalated
> within the default retry bounds. Reproduce the credential-free case set with
> `cargo xtask receipt`, then inspect the public
> [method, data, and limitations](https://github.com/Kilbex/Vigla/blob/main/docs/evidence/recovery-receipt.md).

## How it works

**1 — Assign a mission inside an envelope.** Describe the goal, choose
the worker roster and models, and set the authority envelope. In review
mode the supervisor proposes a plan first — task graph, file scope, risk
fit — and waits for your approval:

<div align="center">

<img src="docs/media/plan-review.png" width="640" alt="Vigla plan review: the proposed task graph is checked against the Scope, Reversibility, Risk, and Quality bounds before any agent starts" />

</div>

**2 — The supervisor arbitrates; you stay out of the loop.** Workers
execute in parallel worktrees while the supervisor reviews each
submission and decides **Accept / Extend / Scrub / Escalate** — inside
your envelope, without pinging you. Live state, diffs, tests, cost, and
raw terminals are always one click away if you *want* to watch.

<div align="center">

<img src="docs/media/ops-room.png" width="900" alt="Vigla Operations Room: five coding-agent workers progress in parallel while one completed submission waits in the review queue" />

</div>

**3 — You judge results, not keystrokes.** Finished missions land in
your inbox with a structured verdict: audit score, test results, files
changed, residual-risk band, unresolved issues — and a revert button
that undoes the whole mission atomically:

<div align="center">

<img src="docs/media/mission-inbox.png" width="900" alt="Vigla mission inbox: a merged mission with audit breakdown, subtask status, low-risk verdict, and one-click revert" />

</div>

The vocabulary is small and precise — *mission*, *worker*, *envelope*,
*arbiter*, *verdict* — and defined in [docs/lexicon.md](https://github.com/Kilbex/Vigla/blob/main/docs/lexicon.md).

## Vendor support

Real workers are driven from the in-app Deploy panel; the mock harness
covers demos and CI. Two independent tiers of evidence back a vendor, and
they are not interchangeable:

- **Adapter goldens (CI).** Committed transcript-and-golden pairs run through
  the shared `vigla-adapter-conformance` harness on every pull request. They
  pin the byte-to-event contract. They prove nothing about the vendor binary.
- **Real-CLI gate (local, opt-in).** An `#[ignore]`d integration test that
  spawns the actual CLI against a failing fixture repository and asserts the
  agent fixed the defect. It needs a working binary and credentials, so **no
  CI workflow runs it** — a maintainer runs it by hand.

| Vendor | Binary | Role | Real-CLI gate (local, opt-in) | Adapter goldens (CI) |
|---|---|---|---|---|
| Claude Code | `claude` | supervisor + worker; session retry / continue | `real_claude_gate.rs`, `supervisor_live.rs` | 6 conformance cases + `from_fixture.rs` |
| Codex CLI | `codex` | worker | `real_codex_run.rs`, `supervisor_live.rs` | 4 conformance cases + `from_fixture.rs` |
| Antigravity | `agy` | profile-backed worker | `real_antigravity_run.rs` | 4 conformance cases |
| Gemini CLI | `gemini` | legacy / enterprise worker | `supervisor_live.rs` | 4 conformance cases + `from_fixture.rs` |
| Kiro | `kiro-cli` | profile-backed worker | none yet | 4 conformance cases |
| GitHub Copilot | `copilot` | profile-backed worker | none yet | 4 conformance cases |

Google ended consumer **Login with Google** access for Gemini CLI on
2026-06-18. Vigla retains the adapter for existing enterprise and legacy
configurations, but Gemini CLI is no longer a primary launch path. Google
directs affected consumer users to Antigravity in its
[official deprecation notice](https://developers.google.com/gemini-code-assist/docs/deprecations/code-assist-individuals).

**Mission supervision is Claude-only today.** The Supervisor dropdown offers
exactly two values — *Claude* (spawns the real `claude` CLI) and *Mock (demo)*
(the scripted runtime, no vendor process) — and `host_services` rejects any
other `supervisor_model` with `UnsupportedSupervisorModel`. There is no
experimental non-Claude supervisor to opt into; a second *real* supervisor is
[roadmap work](https://github.com/Kilbex/Vigla/blob/main/ROADMAP.md). Vigla does not pin vendor CLI versions — the
launch path verifies each configured binary, and the real-CLI gates track
adapter compatibility:

```sh
cargo test -p vigla-orchestrator --test real_claude_gate -- --ignored --nocapture
cargo test -p vigla-orchestrator --test real_codex_run   -- --ignored --nocapture
cargo test -p vigla-orchestrator --test real_antigravity_run -- --ignored --nocapture --test-threads=1
VIGLA_LIVE=1 cargo test -p vigla-orchestrator --test supervisor_live -- --ignored --nocapture
```

`VIGLA_LIVE=1` is not optional on the last line: without it every test in
`supervisor_live.rs` prints a skip line and passes, so the gate looks green
without having run.

The Claude and Codex gates use `tests/samples/sandbox/`, a workspace-excluded
crate with a deliberately wrong `multiply` function. The Antigravity gate
creates the same kind of isolated failing Rust fixture in a temporary
repository. Each of those three asserts that the agent fixed the defect. The
supervisor gate builds its own throwaway repositories instead — a wrong `add`,
a broken test, and a docs task — and asserts that a real `claude` supervisor
drives each mission to a completed, audited verdict.

## Requirements

- **macOS 12+.** Linux and Windows are on the [roadmap](https://github.com/Kilbex/Vigla/blob/main/ROADMAP.md) —
  the non-host Rust workspace is built, linted, and tested on Linux in CI;
  desktop packaging and platform UX are scoped on the roadmap.
- Development: Rust 1.95 (pinned via `rust-toolchain.toml`), Node 22.x,
  pnpm 10.x, Xcode Command Line Tools.
- Vendor CLIs are optional and only needed for real (non-mock) workers.

## Build a local DMG

Vigla publishes no maintainer-built binaries today: there is no signing
identity, notarization credential, or update channel to trust, and the only
supported artifact is the one your machine produces. (A Mac App Store release
would replace that trust model with Apple's; whether to make that trade is
[undecided and under investigation](https://github.com/Kilbex/Vigla/blob/main/docs/roadmap/mac-app-store.md).) On a
Mac, clone the source and run one command:

```sh
./scripts/build.sh
```

The script installs the locked frontend dependencies, builds the application,
ad-hoc signs it without an Apple account or personal signing identity, verifies
the app and disk image, and prints the DMG path and SHA-256 checksum. The local
artifact remains under `target/release/bundle/dmg/`; no workflow uploads it.

Keep the printed checksum with the artifact. [SECURITY.md](https://github.com/Kilbex/Vigla/blob/main/SECURITY.md#verifying-a-local-build)
documents the independent `shasum`, `hdiutil`, and `codesign` checks.

Prerequisites are the development tools listed in [Requirements](#requirements).
Set `EMBEDDINGS=1` when running the command to include the optional embeddings
feature. Its first use downloads the public FastEmbed model into the per-user
cache; if that download is unavailable, retrieval falls back to local BM25.

## Known limitations

Design trade-offs in the current build, not bugs:

- **Real supervisor execution is Claude-only.** `supervisor_model` accepts
  `claude` (the real CLI) or `auto` (the scripted mock); everything else is
  rejected. Cross-vendor applies to workers, not to the supervisor.
- **Memory retrieval is local and best-effort.** Alias-expanded BM25
  with optional embedding / hybrid re-ranking; degrades to lexical
  retrieval instead of blocking workers.
- **The supervisor sees typed mission events, not raw worker
  dialogue.** By design — escalation is bounded on outcomes, not
  chain-of-thought.
- **Session resume requires vendor session-ID support.** CLIs that
  don't expose a session ID can't be continued across app restarts.

## Contributing

Start with [CONTRIBUTING.md](https://github.com/Kilbex/Vigla/blob/main/CONTRIBUTING.md) and
[ARCHITECTURE.md](https://github.com/Kilbex/Vigla/blob/main/ARCHITECTURE.md); project authority and maintainer
succession are explicit in [GOVERNANCE.md](https://github.com/Kilbex/Vigla/blob/main/GOVERNANCE.md).
Newcomer-friendly tasks live in
[docs/GOOD_FIRST_ISSUES.md](https://github.com/Kilbex/Vigla/blob/main/docs/GOOD_FIRST_ISSUES.md) — adapter
fixture work is the recommended first PR and is designed to land in
under two hours.

Questions and bug-report routing: [SUPPORT.md](https://github.com/Kilbex/Vigla/blob/main/SUPPORT.md). Security reports:
see [SECURITY.md](https://github.com/Kilbex/Vigla/blob/main/SECURITY.md). Reviewing or recording Vigla? The public
[creator kit](https://github.com/Kilbex/Vigla/blob/main/docs/operations/creator-kit.md) provides a 10-minute script,
credential-free inputs, media, evidence, and exact claim boundaries.
Operators coming from vibe-kanban can use the
[concept-by-concept migration guide](https://github.com/Kilbex/Vigla/blob/main/docs/migrations/from-vibe-kanban.md);
it does not claim a database importer or kanban-board parity.

## Canonical resources

- Source: https://github.com/Kilbex/Vigla
- Browser replay: https://kilbex.github.io/Vigla/demo/
- Architecture: https://github.com/Kilbex/Vigla/blob/main/ARCHITECTURE.md
- Security: https://github.com/Kilbex/Vigla/blob/main/SECURITY.md
- Support: https://github.com/Kilbex/Vigla/blob/main/SUPPORT.md
- License: Apache-2.0