v5.3.30 — Desktop Bridge: four read-only CLI commands

External UIs that want to wrap NEXO Brain — NEXO Desktop being the first — have, until now, been forced to hardcode the list of editable preferences, the onboarding questions, the location of the assistant name, and the shape of the user profile. Each time the Brain added a new field, the downstream UI had to ship a release to catch up. That is the wrong coupling: the runtime already knows all of that, it just had no honest way to tell a client.

v5.3.30 closes that gap with four small, strictly read-only commands. No existing surface changes. Nothing new is written unless the operator explicitly asks for it.

1. nexo schema --json

Returns the editable-field schema: a schema_version, a list of groups, and a list of fields. Each field declares its dot-notation path, which file it lives in (calibration.json or profile.json), its type, its label in multiple languages, and — for selects — its options with multilang labels too.

The rule a client should follow is simple: render the UI from this payload, do not hardcode field lists. When the Brain adds a new preference next month, the client renders it automatically. schema_version is the only field clients need to watch to know when a format change has happened.

2. nexo identity --json

Historically the assistant's name (NEXO, Nora, etc.) lived in at least four possible locations across calibration.json and profile.json. That meant every client had to re-implement the probe order — and write back to the wrong place half the time.

This command returns {name, source, writable_source}. source is the field the current value came from; writable_source is the canonical path a client should write to if the user renames the assistant. One probe, one canonical destination.

3. nexo onboard --json

Exposes the onboarding wizard as data: a list of steps with id, prompt (multilang), type, the writes path, the target file, plus optional, default, and an optional validate regex. The last step is a welcome message clients can render at the end.

A Desktop onboarding screen becomes a loop over steps, not a set of hardcoded React components. When the Brain wants to ask one more question during first-run, the wizard grows on its own.

4. nexo scan-profile

The last command is the one with moving parts, so it is deliberately the most cautious. scan-profile builds a profile.json payload from CLAUDE.md and calibration.json heuristics — useful for older installations where profile.json was never generated. Default behavior is preview only: it prints the payload without touching disk. --apply writes the file, and --force is required to overwrite an existing profile. Clients that want to show the operator what would be written can request --json and render the diff locally.

Why read-only

None of the four commands mutate runtime state without explicit opt-in. They read, they describe, they predict. This matters because the Brain is where the truth lives; external UIs are renderers, not sources of truth. Exposing JSON describes the truth once, and lets any client — Desktop today, mobile or web later — pull from the same description.

Update

npm update -g nexo-brain
nexo update

If you are not building a UI on top of NEXO Brain, nothing changes for you. If you are, you now have a stable contract to build against.