Skip to main content

FAQ

Q: Do business users need to know CLI commands?​

No.

Lovrabet CLI is better thought of as the execution layer behind an Agent.
Business users mainly need to:

  • describe the business problem clearly
  • say whether the request is read-only or allowed to write
  • provide key identifiers such as order number, mobile number, or customer ID when available

The actual commands are usually decided in the background by the Agent and its skills.

Q: Why is there no sql list or bff list?​

This is intentional.

SQL and BFF often point to real business logic. It is usually safer not to let a generic Agent browse them freely and execute them at will.

The preferred model is:

  • maintainers define in skills which SQL or BFF belongs to which workflow
  • business users describe the business goal
  • the Agent follows the skill boundary

Q: What does --global mean?​

It controls whether configuration reads and writes explicitly target the global config.

In simple terms:

  • global config works across the machine
  • local config is the optional .lovrabet.json in the current directory; it stores user intent and does not represent a Lovrabet platform project

Common cases:

  • auth login usually leans global because one AccessKey is often reused across projects
  • app use only sets the defaultApp candidate
  • config set and config delete are advanced local config maintenance commands. If there is no local config and --global is not passed, the CLI refuses to write instead of silently polluting global config.

If you only use Lovrabet through an Agent, you usually do not need to manage this detail yourself.

Q: Why is there no app add?​

Because the runtime CLI no longer treats “maintain a local list of app profiles” as its main model.

The recommended path now is:

  • use app list to see the apps visible to the current account
  • use app use to set the default app candidate
  • rely on the remote app directory plus local cache as the source of truth

The default app candidate is not strong context. If a request clearly points to a business domain such as orders, products, inventory, or CRM, first validate the default candidate by searching datasets. If that does not match, expand the search to the app list.

Q: Do I have to know appcode, dataset code, or sqlcode?​

Not always.

The ideal split is:

  • business users usually do not need to know them
  • skill maintainers usually should know them
  • Agents can do discovery first when needed

If you can provide them, execution is faster.
If you cannot, the Agent can still explore first.

Q: How should I phrase requests so the Agent gets them right?​

Try to make these points clear in one message:

  • which business system or business domain
  • which business object
  • what time range or filter conditions
  • what final result you want
  • whether the request is read-only or allowed to write

For example:

Help me find paid but unshipped orders from the last 7 days, group by warehouse, and give me an exception list. Read-only.

That works much better than:

Help me check the orders.

Q: How should I phrase write requests more safely?​

Add one of these lines directly into the request:

  • Preview first, then execute.
  • Read-only. Do not write data.

That makes it much easier for the Agent to follow the safe path.

Q: What does --dry-run do?​

It shows what the CLI is about to do, but it does not really perform the write.

It is especially useful for:

  • batch fixes
  • manual backfills
  • status changes
  • final confirmation before deletion

No.
The current Lovrabet Runtime CLI uses AccessKey as the main path.

If you see old docs talking about Cookie as the normal path, use the new AccessKey model instead.

Q: What if the Agent gets the wrong result?​

Split the problem into two cases:

  • the command did not run at all: check login, the default app candidate, doctor, and logs first
  • the command ran, but the business result is wrong: check the skill, the business prompt, and the workflow assumptions first

Many real issues come from outdated skills or unclear business prompts, not from the CLI itself.