The APX CLI Is a Daily Loop, Not a Dashboard

APX CLI is designed as a small daily loop rather than a comprehensive dashboard, maintaining a clear boundary between portable context (APC) and local runtime (APX). The developer advocates for a focused workflow using commands like `apx status`, `apx memory reviewer`, and `apx messages tail` to keep context drift under control.

The easiest way to use APX is also the one that keeps APC honest: treat the CLI as a small daily loop, not as a giant control panel. That matters because the split between APC and APX is the whole design. APC is the portable context layer in the repo. APX is the local runtime and tooling layer on the machine. If you try to make the CLI hold everything, the boundary gets fuzzy fast. If you keep the CLI focused, the boundary stays useful. My rule is simple: That loop sounds boring. It is also what keeps context drift under control. A project becomes an APX project when it has AGENTS.md and .apc/project.json , then you register it with APX. apx init apx project add . From there, the repo stays portable. The committed .apc/ tree holds the project contract: agents, skills, MCP hints, and project config. APX keeps runtime state local under ~/.apx/projects/<id / . That split is not cosmetic. It means you can clone the repo, open it on another machine, and recover the same project shape without dragging along one laptop's runtime history. When I sit down, I do not jump straight into an agent run. I check the runtime first. apx status The docs describe apx status as the quick view for daemon health, super-agent, engines, Telegram, and registered projects. That is enough to catch the common failure mode: the repo is fine, but the local runtime is not. If a project moved, I do not guess. I refresh the registration: apx project rebuild <project That keeps the stable .apc/ contract linked to the right local runtime folder. APX memory is curated, not a transcript dump. That is the right shape for daily use. apx memory reviewer If I need to add one durable note, I append one line instead of rewriting the whole file: apx memory reviewer --append "Prefers short PR summaries and a direct verdict" This is the part people often skip. They keep asking the same question because they keep feeding the model raw context instead of stable context. Memory solves that only if you keep it short, durable, and specific. If memory tells me what should be true, messages tell me what actually happened. apx messages tail --channel runtime -n 20 That command is the fastest audit trail in the system. It shows the recent agent run messages, not a polished summary. When something feels off, I check the log instead of trusting my recollection. That distinction matters: memory.md is for durable facts. messages are for recent activity. sessions are for invocation history.APX keeps those different on purpose. One file should not try to do three jobs. This is the practical payoff of APC plus APX. APC says what the project is. APX says what happened today. A good daily loop uses both: For a single terminal session, that is enough to stay oriented: apx project list apx memory reviewer apx messages tail -n 20 That sequence is small on purpose. It is not meant to replace the whole web admin or every advanced command. It is meant to be the first thing you reach for when you want to know whether the project, the memory, and the runtime still agree. The APX CLI works best when it behaves like a daily habit, not a dashboard. Use the repo for portable context. Use the machine for runtime state. Use the CLI to check the boundary every day. That is how APC stays portable and APX stays useful.