Advanced Usage: Config, Cache, and Integration Troubleshooting

This page is for enterprise IT, delivery engineers, extension developers, and skill maintainers. Business users usually do not need to understand .lovrabet.json, app cache, AccessKey scope, or integration details.

Summary

Lovrabet CLI is an AI operation suite for business scenarios. For business users, the main path should be: describe the business goal and let the Agent call the right capabilities to query, verify, execute, and collaborate. Config, cache, and app resolution belong to the technical maintenance layer.

The current model can be summarized as:

Local config stores “how I prefer to use it”; remote platform plus cache stores “what apps actually exist.” defaultApp is the first candidate to validate, not forced context.

Who should read this

Scenario	Why it matters
Enterprise IT prepares Agent environments	Standardize CLI, Skill, AccessKey, and default candidates
Delivery teams troubleshoot customer environments	Check AK, environment, app cache, dataset permissions
Extension or private deployment work	Understand configurable names, packages, domains, and Skill sources
Skill maintainers encode workflows	Understand defaultApp, --app, and --appcode priority
CI / automation integration	Control --format compress, --jq, --dry-run, and --yes

What local config stores

.lovrabet.json stores user intent only, such as:

• accessKey
• env
• format
• riskLevel
• defaultApp
• the top-level compatibility field appcode

It does not store the full platform app directory and does not represent a Lovrabet platform project.

App directory and cache

The visible app directory for the current AK is maintained by:

lovrabet app list
lovrabet app pull

The local cache is stored under paths like:

~/.lovrabet/cache/<env>/<ak-fingerprint>/my-apps.json

Use these commands when troubleshooting:

lovrabet app list
lovrabet app list --local
lovrabet app list --no-cache
lovrabet app pull --env daily

App resolution

Runtime commands such as dataset, data, sql, and bff generally resolve the app in this order:

1. explicit --appcode
2. explicit --app
3. confirmed current app context
4. configured defaultApp candidate
5. top-level compatibility field appcode

defaultApp is a weak candidate. If the user asks about a new business domain such as orders, products, inventory, CRM, or tickets, validate the default candidate with dataset search first. If it does not match, expand the search to the app list.

Integration and extension points

For extension work or independent Lovrabet deployments, product constants live mainly in:

src/constant/product.ts
src/constant/distribution.ts

Typical configurable items include:

Type	Examples
CLI display and binary names	lovrabet / Lovrabet CLI
npm package name	@lovrabet/lovrabet-cli
Skill source	lovrabet/lovrabet-cli
Domains and console URLs	website, docs, user center, AccessKey page
Local config names	.lovrabet.json
Cache and logs	cache directories, runtime log file

Prefer changing constants instead of scattering string replacements through command implementations.

Practical troubleshooting order

1. Confirm lovrabet auth info --format compress returns the current AK user.
2. Confirm lovrabet app list can see the target app.
3. Use dataset list --name <keyword> to validate the business object.
4. Use dataset detail --code <datasetCode> to inspect fields and permissions.
5. Add --dry-run before write operations.

Final note

Business users do not need this page. Technical teams use it to make Lovrabet CLI a stable, debuggable, extensible runtime operation entry that Agents can call safely.