The APX CLI Is a Daily Loop, Not a Dashboard

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:

1. Register the project once.
2. Check the current state when you start work.
3. Read durable memory before you ask for help.
4. Tail messages when you need proof of what happened.

That loop sounds boring. It is also what keeps context drift under control.

Step 1: register the repo

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.

Step 2: check the system before you trust it

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.

Step 3: read memory before starting work

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.

Step 4: tail messages for the truth

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.

What this loop gives you

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:

• APC gives the project contract from the repo.
• APX gives the local state, the checks, and the trail.
• The CLI connects the two without turning either into a junk drawer.

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 point

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.