Architecture and source repositories
EvoX desktop interaction, core runtime, experience engine, and public website have separate source and release artifacts. Identify the change and its interface owner before selecting a repository so each deliverable can be accepted independently.
How the system fits together
Desktop provides the interface, project workspace, and system integration, using a managed core runtime for agent execution. Evolver handles experience assets, reuse, and evolution; its Proxy exposes tools to agents. The Hub serves network identity, asset, and task protocols. The website provides product information, documentation, and download entry points.
| Layer | Source or integration entry | Change ownership | Acceptance evidence |
|---|---|---|---|
| Desktop | EvoMap/evox-desktop | React UI, Go/Wails bindings, workspace, terminal, system integration, installation, and updates | Frontend/backend contracts, desktop interactions, platform builds, and installers |
| Core runtime | EvoMap/evox | Core agent runtime and evox-cli | Owning repository contracts, tests, and release artifacts |
| Evolver | EvoMap/evolver | CLI, Proxy, MCP, Gene/Capsule/Recipe, and local records | Package entry points, schemas, unit/integration tests, and npm artifacts |
| Website | EvoMap/evomap-website | Product pages, docs, download feed consumption, and website interaction | Content and route checks, browser validation, and site release |
| Hub protocol | A2A integration guide | Node authentication, asset submission, and task requests | Server contracts, responses, operation state, and receipts |
Trace actual behavior in source
In Desktop, start with the page or component under frontend/src, then follow the corresponding Go bindings under backend/bindings and their service calls. A visible switch establishes an interaction entry point; persistence, scope, execution, and recovery each require tracing the call chain.
For Evolver integrations, start with the CLI command or Proxy tool schema and trace local writes, remote requests, and outcome records. An internal function is not automatically a stable public interface. Desktop bindings and sidecar calls are not general-purpose HTTP APIs.
Delivering a change across repositories
- Define inputs, outputs, errors, and compatibility in the interface owner and test them.
- Publish a verifiable package or runtime artifact and record its dependency coordinates.
- Validate connectivity, real operations, and failure recovery in Desktop or the agent integration.
- Update website documentation and download entry points against the delivered behavior.
Code merge, desktop installer release, npm publication, and website deployment have separate acceptance checks. Passing one repository's checks does not validate another deliverable's build or execution.
Desktop delivery checks each supported platform independently: installer startup and update behavior, artifact hashes, signatures, macOS notarization or Windows signing/timestamp requirements, and agreement between release manifests and update/download consumers. Trace managed sidecar lifecycle and frontend/backend contracts separately from installer success.
Evolver changes preserve runtime/package entry points, declared Node engines, schemas, existing local data, and credential boundaries. Website download entries consume published release metadata; missing, inconsistent, or unverifiable manifests stop that release entry rather than inventing an artifact URL or marking a release ready. Each owning repository defines its release gates; a website deployment does not publish Desktop or npm packages.
Keep scope explicit
Review interface callers, persistence, and failure paths. Before committing, check for unrelated workspaces, credentials, caches, and generated builds. Use implementation and release artifacts as evidence for public capabilities; screenshots, mocks, and plans do not establish delivery.