Skip to content

The Box console

Why a console at all: agents act through the cafe CLI, and humans need to see what the agents did — and to get started themselves. The console is the human surface of the control plane: trust, visibility, onboarding. It is a client of the same API the CLI calls — same auth, same tenancy, same billing service, no separate logic — never a second system.

Decision record (settled, do not reopen): on 2026-10-15 the owner re-scoped cafaye/box from “the installer web UI” to “the console”. Box is not deleted and not demoted out of existence. The parity rule governs both clients: “If CLI can do it, Box can show it. If Box can do it, CLI can do it.” The console surface lives in cafaye/website (boundary 1); this repository holds the API it calls.

Phase 1 — hosted identity / courier dashboard. Keys, MAU/emails usage, per-tenant logs, free-tier meter, billing.

Phase 2 — orgs. Orgs, members, roles, SSO config, audit.

Phase 3 — fleet. Fleet health, policy, provenance, advisories, verified pantry.

A phase is done when both clients can do it: anything visible in the console must be reachable from the CLI, and anything the CLI can do must be visible in the console. A one-sided capability is a boundary violation, not a head start.

The installer-wizard-as-homepage is gone. The landing offers two clear paths:

  • Use hosted (30 sec, free). The fastest way to trust: copy a cafe command, run it, watch the web UI confirm it.
  • Deploy to your box (you own it). Same shape — copy a cafe command, run it, watch the web UI confirm it — except the box is yours.

Both paths lead to copyable cafe commands with the web UI as visual confirmation. Likewise curl -fsSL https://cafaye.com/box/install | bash is not a separately maintained thing: it is what cafe box init generates.

Plainly: almost none of the console surfaces above are built yet. This repository holds the API foundation, and the phases and paths above are planned, not implemented. Nothing in this file should be read as claiming they exist.