Local-first AI coding cockpit
Product
ADDOM is shaped as an operating surface for real repositories. The product depth is in how execution, review, continuity, and policy fit together.
Core layers
Projects, threads, event timelines, and current working context are first-class parts of the app. ADDOM is designed to reopen work in context, not restart from an empty box.
Changes are staged as artifacts so they can be inspected, applied, rolled back, or tied back to the flow that produced them.
Facts, decisions, and open loops can be carried forward so longer tasks keep their shape. The target is durable project continuity, not fragile prompt memory.
File operations, command execution, and browser tooling sit behind explicit approval and policy layers. The product is designed so machine-side actions stay visible and controllable.
ADDOM is built around provider choice. It can route between remote providers and local model paths instead of forcing one vendor shape.
Multi-agent work inside ADDOM is meant to be staged and reviewable. Delegation is integrated into the workspace instead of being a hidden autonomous black box.
Workflow shape
Start from the repository, not a detached text session.
Pull prior thread state, current files, and continuity signals into the working loop.
Search, read, plan, run tools, and prepare changes under explicit machine-action controls.
Inspect file changes and outcomes before they become accepted state.
Carry the project forward with context, decisions, and open loops still attached.
Codebase proof
Main process, preload boundary, renderer state, IPC surface, memory store, tools, browser paths, and provider adapters.
Broad contract coverage across tools, chat flows, renderer capability surfaces, staging, and multi-agent edges.
File, git, browser, review, and command surfaces integrated into the desktop environment.
The foundation is substantial. The current work is cleanup, refinement, and sharper workflow fit.