Architecture

A CLI, a local mirror and a vendor-hosted phone expose different parts of the workflow.

Read path

Alibaba account on phone
  -> vendor structured feed
  -> pull
  -> local SQLite + media cache
  -> threads / messages / media gap

The feed has its own capture state. A working HTTP connection or a completed pull cannot prove that the source captured all new messages. Local reads answer from the mirror; they do not refresh it automatically.

Device actions

send opens an existing conversation and checks the screen before typing. contact identifies a product page before opening a first chat. contact inspect reads the product-page supplier. search-api --trigger invokes the vendor search operation. These paths are deterministic in the CLI and do not fall back to a vision agent.

Boundaries

The local account lock coordinates callers sharing the same store directory. It cannot lock human activity or another client outside that directory. Login is human-only. Real outgoing messages need approval in the caller’s workflow; the send CLI itself has no interactive approval prompt. Orders have a separate interactive approval model and currently require manual placement.

This is an account/device integration, not an official general Alibaba API or a multi-tenant hosting portal. Provisioning, customer billing and assistant OAuth onboarding are not commands provided by this build.

Related

auth · send · contact · order approval