The Web Admin Is a Window, Not a Second Source of Truth

APX has a web admin panel, but that does not make the browser the center of the system.

The design is stricter than that: the daemon owns the state, and the web UI is only a local client.

That split sounds small. It is not. It decides where truth lives, how much can drift, and whether the project still makes sense after a refresh, a restart, or a tool switch.

The rule

APC is the portable context layer. APX is the daily-use runtime and tooling layer.

Inside that split, the web admin belongs firmly to APX. It exists to let you inspect and operate the runtime without leaving the browser, but it does not get its own copy of project truth.

The docs make that clear:

• the daemon is a local HTTP server on 127.0.0.1:7430
• every surface talks to the daemon over HTTP
• the web admin is served by the daemon itself
• the browser fetches a bearer token from GET /admin/web-token on loopback
• the daemon serves the built UI from src/interfaces/web/dist

So the browser is not a peer database. It is just one more surface.

Why this matters

If a web panel becomes a second source of truth, it starts to rot fast.

Two copies of state means two ways to disagree:

• CLI writes one thing, UI caches another
• browser session edits a config, daemon still trusts old state
• a reload shows one project, but another tab keeps stale data
• a “fix” in the UI never reaches the runtime that actually runs agents

APX avoids that by keeping the browser thin. The UI asks the daemon. The daemon asks the core. The core reads or writes the real backing store.

That chain is boring on purpose. Boring is good here.

What the browser should do

A good local panel should do three things well:

1. Show the live state.
2. Send a small action.
3. Revalidate after the action.

That is enough.

For APX, the panel is meant to browse projects, agents, routines, sessions, MCPs, and settings from one place. But it should still feel like a view onto the system, not a fork of the system.

That is why the implementation stays local-first:

• dev mode runs Vite on :7431 and proxies to the daemon on :7430
• production serves the built app from the daemon
• same origin keeps auth and routing simple
• the browser never needs direct repo write access just to render a screen

The win is not visual polish. The win is that every action still resolves through one backend.

Practical example

Say you open the web admin and edit a project setting.

If the panel owned state, it would need its own store, its own save path, its own conflict handling, and its own recovery rules.

APX does not take that tax.

The panel submits the change to the daemon. The daemon updates the runtime or project store. The next render reads the same source of truth the CLI would read. One system, many surfaces.

That also means the UI can disappear without harming the project. You can close the browser, lose the tab, or move to another machine. The important state remains where it belongs: in the daemon for runtime data, and in .apc/ for portable project context.

The deeper reason

APC exists because context should travel with the project.

APX exists because that context needs a runtime that can act on it.

The web admin fits that second half. It is useful because it is local, not because it is special.

So the right mental model is simple:

• APC: what the project is
• APX: how the project runs today
• Web admin: one window into that runtime

If you keep that boundary clean, the stack stays replaceable. The browser stays optional. The daemon stays authoritative. And the project stays portable.