@thinremote/thinr-cli 1.3.4 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,91 @@
 # Changelog
 
+## [1.4.0] - 2026-10-14
+
+Incompatible change of the MCP tools: thinr is now the generic core it
+shares with the `thinger` CLI, `@thinger-io/cli-core` 0.3.0, plus what only
+a device with the agent can do. From 84 tools to 24, and from about 27,600
+to about 8,000 tokens in `tools/list`. Also incompatible for playbooks: the
+step actions `mv` and `rm` are now `move` and `delete`.
+
+### Changed
+
+- The generic core (API client, auth, profiles, REST helpers, generic
+  commands and MCP tools) comes from `@thinger-io/cli-core`. thinr supplies
+  its identity (`lib/identity.js`) and its own commands, types and tools.
+  Profiles and `THINR_*` variables are unchanged.
+- Server resources (devices, products, buckets, tokens, alarms, properties,
+  product profiles…) go through `thinr_resource_list` / `_get` / `_create` /
+  `_update` / `_delete` / `_clone` / `_call` with a `type`, described by
+  `thinr_resource_describe`; device resources through
+  `thinr_device_resource_list` / `_call`.
+- ThinRemote's own resources are resource types served by those same
+  tools: `device_fs` (a device's files and folders; actions `move`, `push`,
+  `pull`), `device_script`, `product_script`, `product_metric`,
+  `product_log_source` and `product_playbook` (actions `validate`, `run`,
+  `rollout`). Creating one that exists fails, as does updating one that
+  does not (a `device_fs` file is written either way). Actions on devices:
+  `agent_update` and `agent_install` (the install command).
+- The one tool of thinr's own, `thinr_device_exec`, runs a command on one
+  device or on several (`devices`, `product` and `group`, or `all`: every
+  device of the ThinRemote products); offline devices are left out unless
+  `include_offline`, and named when listed by id; `dry_run` lists the
+  targets.
+- Old tools and where they went: `exec` → `device_exec`; `read`, `write`,
+  `ls`, `rm`, `mv`, `mkdir`, `push`, `pull` → type `device_fs`;
+  `script_*` → type `device_script`; `product_script_*` → type
+  `product_script`; `product_metric_*` → type `product_metric`;
+  `product_logs_*` → type `product_log_source` (presets in its
+  description); `product_playbook_*`, `playbook_schema`,
+  `playbook_validate`, `playbook_run` → type `product_playbook`; `update` →
+  action `agent_update`; `agent_install_command` → action `agent_install`;
+  `product_exec` → `device_exec` with `product` (its `all`, which included
+  offline devices, is now `include_offline`); `monitoring` → the device
+  resource `monitoring` (live) and the bucket `monitoring` (history);
+  `product_write` → a playbook (`write` and `move` steps, rolled out);
+  `devices`, `device_info`, `products`, `product_create`… → the
+  `resource_*` tools; `profiles` → `profile_list`; `bucket_read` →
+  `bucket_data_read`.
+- A playbook run needs one explicit target (`device`, `devices`, `group` or
+  `all`): never the whole product by omission. Its variables are checked
+  against what the playbook declares, inline ones too.
+- From the MCP server, `push`, `pull` (and playbook `content_file`) only
+  reach files inside one local folder, `THINR_MCP_LOCAL_DIR` or where the
+  server started; `pull` replaces a file only when asked.
+- Deleting a product also deletes its script storage.
+- MCP calls with a `profile` argument are scoped to that call.
+- `thinr logout` revokes the API token it created at a username/password
+  login (`--keep-token` to keep it) and accepts `--all`.
+- Node 20 or later, as cli-core.
+
+### Added
+
+- Guides for agents, served by `thinr_doc_read` and as MCP resources:
+  `thinremote`, `thinremote-scripts`, `thinremote-playbooks`,
+  `thinremote-metrics-logs`; MCP server instructions with a map of where
+  each thing is.
+- Reading a device with the agent connected adds `agent.system_info`, its
+  file system base path and `agent.where`, the map of its tools.
+- `thinr login --server --username --token` signs in without prompts.
+- `thinr device info`, `create`, `set-product`, `property-set`;
+  `thinr product info`, `create`, `delete`; `thinr bucket list`, `read`.
+- From cli-core: dashboards, storage files, bucket data, endpoints, alarm
+  rule tests and stats, the server's documentation as MCP resources.
+
+### Fixed
+
+- Reading a device showed no system information: it asked the agent for
+  `system_info` instead of `system`.
+
+## [1.3.5] - 2026-09-24
+
+### Fixed
+
+- `thinr_ls` describes what "/" actually resolves to: the agent process's
+  working directory, which is normally the filesystem root. 1.3.4 said it was
+  a base directory "usually /var/log", which was a stale service definition on
+  one device rather than how installs behave.
+
 ## [1.3.4] - 2026-09-24
 
 ### Fixed

package/README.md

@@ -12,7 +12,7 @@ Two operating modes:
 
 - **CLI** — interactive or scripted device management from a shell.
 - **MCP server** — a stdio [Model Context Protocol][mcp] server that
-  exposes the same operations as 80+ typed tools for AI clients like
+  exposes the same operations as 24 typed tools for AI clients like
   Claude Code, Claude Desktop and Cursor.
 
 Both modes share the same auth, profiles, and device API layer, so
@@ -159,6 +159,19 @@ thinr device list --json             # JSON envelope with the raw API records
 
 Combine with the global `-u, --user` flag for admin impersonation.
 
+#### Records — `info` / `create` / `delete` / `set-product`
+
+```bash
+thinr device info <deviceId>                       # server record as JSON
+thinr device create <deviceId> [-t Generic|MQTT|HTTP|Virtual|Subdevice] [-p product]
+thinr device delete <deviceId> [-y]
+thinr device set-product <deviceId> <productId>    # "" to unassign
+thinr device property-set <deviceId> <property> <json>
+```
+
+`create` generates random credentials for Generic/MQTT devices unless
+`-c` is given; they are shown once.
+
 #### `console`
 
 Open an interactive terminal on the device:
@@ -336,9 +349,9 @@ thinr product exec my-product "apt-get -y upgrade" -c 5 --timeout 600
 thinr product exec my-product "systemctl restart agent" -g staging
 ```
 
-Also exposed as an MCP tool (`thinr_product_exec`) with the same
-parameters, so agents can drive a fleet operation with a single call
-instead of looping `thinr_exec` per device.
+Also exposed to MCP clients as `thinr_device_exec` with `product` (and
+`group`), so agents run a fleet operation with a single call instead of
+looping per device.
 
 #### `playbook`
 
@@ -417,25 +430,25 @@ thinr profile delete <name> [--json]
 
 ### `thinr logout`
 
-Remove the active profile's credentials and config:
+Forget the active profile and revoke the API token `thinr` created for it
+at a username/password login:
 
 ```bash
-thinr logout
+thinr logout                 # active profile (or --profile <name>)
+thinr logout --all           # every profile
+thinr logout --keep-token    # leave the token on the server
 ```
 
-Other profiles are left untouched.
+Other profiles are left untouched. `thinr login` re-authenticates the
+active profile; `--server`, `--username` and `--token` skip the prompts.
 
 ---
 
 ## Part 2 — MCP server
 
-`thinr` ships an [MCP][mcp] server that exposes the CLI's device and
-fleet operations as a set of 80+ typed tools. AI clients (Claude Code,
-Claude Desktop, Cursor, and any other MCP-compatible host) can list
-devices, run shell commands, read/write files, call resources, manage
-products, author and roll out playbooks, triage alarms and rotate
-access tokens through the same API the CLI uses — with stable schemas
-and a consistent error contract.
+`thinr` ships an [MCP][mcp] server for AI clients (Claude Code, Claude
+Desktop, Cursor and any other MCP host): 24 tools that reach everything the
+CLI does, through the same API, with stable schemas and one error contract.
 
 ### Starting the server
 
@@ -443,117 +456,91 @@ and a consistent error contract.
 thinr mcp
 ```
 
-The server speaks [MCP over stdio][mcp-stdio]. Every tool call carries
-its own `device`, `user` and `profile` arguments, so a single running
-server handles any device of any configured environment without a
-restart.
+The server speaks [MCP over stdio][mcp-stdio]. Every tool call carries its
+own `profile` and `user` arguments, so a single running server handles any
+device of any configured environment without a restart.
 
 [mcp-stdio]: https://modelcontextprotocol.io/specification/server/transport#stdio
 
-### Tool catalog
-
-Grouped by capability. Every tool accepts optional `device` (when
-relevant), `user` and `profile` arguments, so a single session can
-target any device, account or environment without restart.
-
-| Area                         | Tools                                                                                                                                                                                                                |
-| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Discovery                    | `thinr_devices` (with optional `query` for regex filtering), `thinr_device_info`, `thinr_profiles`                                                                                                                   |
-| Provisioning and lifecycle   | `thinr_agent_install_command`, `thinr_device_set_product`, `thinr_device_delete`                                                                                                                                     |
-| Shell                        | `thinr_exec` (buffered), with streaming stdout/stderr                                                                                                                                                                |
-| Filesystem                   | `thinr_read`, `thinr_write`, `thinr_push`, `thinr_pull`, `thinr_ls`, `thinr_mkdir`, `thinr_rm`, `thinr_mv`                                                                                                           |
-| Resources                    | `thinr_resource_list` (with `in`/`out` schemas), `thinr_resource_call`                                                                                                                                               |
-| Properties (device)          | `thinr_property_get`, `thinr_property_set`                                                                                                                                                                           |
-| Scripts (device)             | `thinr_script_list`, `thinr_script_write`, `thinr_script_delete`                                                                                                                                                     |
-| Monitoring and agent updates | `thinr_monitoring`, `thinr_bucket_read`, `thinr_update`                                                                                                                                                              |
-| Alarms                       | `thinr_alarm_instances`, `thinr_alarm_instance_stats`, `thinr_alarm_instance_get`, `thinr_alarm_instance_update`, `thinr_alarm_instance_delete`, `thinr_alarm_rules`, `thinr_alarm_rule_read/write/delete`           |
-| Access tokens                | User: `thinr_token_list`, `thinr_token_get`, `thinr_token_create`, `thinr_token_update`, `thinr_token_delete`. Device: `thinr_device_token_list`, `thinr_device_token_create`, `thinr_device_token_delete`           |
-| Products                     | `thinr_products`, `thinr_product_create`, `thinr_product_update`, `thinr_product_delete`, `thinr_product_exec`, `thinr_product_write`                                                                                |
-| Product scripts              | `thinr_product_script_list`, `thinr_product_script_read`, `thinr_product_script_write`, `thinr_product_script_delete`                                                                                                |
-| Product properties           | `thinr_product_property_get`, `thinr_product_property_set`, `thinr_product_property_delete`                                                                                                                          |
-| Product profile schema       | `thinr_product_profile_api_{list,get,set,delete}`, `thinr_product_profile_bucket_{list,get,set,delete}`, `thinr_product_profile_property_{list,get,set,delete}`                                                      |
-| Product log sources          | `thinr_product_logs_list`, `thinr_product_logs_add`, `thinr_product_logs_remove`, `thinr_product_logs_presets`, `thinr_product_logs_set_default`                                                                     |
-| Product metrics              | `thinr_product_metric_list`, `thinr_product_metric_set`, `thinr_product_metric_delete`                                                                                                                               |
-| Playbooks (authoring)        | `thinr_playbook_schema`, `thinr_playbook_validate`, `thinr_playbook_run` (ad-hoc)                                                                                                                                    |
-| Product playbooks            | `thinr_product_playbook_list`, `thinr_product_playbook_read`, `thinr_product_playbook_write`, `thinr_product_playbook_run` (single device), `thinr_product_playbook_rollout` (fleet), `thinr_product_playbook_delete` |
-
-Full input/output schemas are published via standard MCP
-`list_tools`; the client will show them when you connect.
+### Tools
+
+thinr is built on [`@thinger-io/cli-core`][cli-core], the core it shares
+with the `thinger` CLI, and serves its 23 generic tools with the `thinr_`
+prefix plus one of its own:
+
+| Tools                                                                                                                                                    | What for                                                                                                               |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `thinr_resource_describe`, `_list`, `_get`, `_create`, `_update`, `_delete`, `_clone`, `_call`                                                           | Every resource type: the server's and ThinRemote's (below), and their actions                                          |
+| `thinr_device_resource_list`, `thinr_device_resource_call`                                                                                               | What a connected device exposes: agent resources (`monitoring`, `cmd`…) and its scripts                                |
+| `thinr_bucket_data_read`, `thinr_bucket_data_write`                                                                                                      | Time series, monitoring history included (bucket `monitoring`)                                                         |
+| `thinr_storage_file_*`, `thinr_dashboard_publish`, `thinr_plugin_call`, `thinr_product_resource_call`, `thinr_device_data_send`, `thinr_device_overview` | Storages, web dashboards, plugins, product APIs, HTTP devices, account usage                                           |
+| `thinr_doc_read`, `thinr_profile_list`                                                                                                                   | Guides for agents (`thinremote`, `thinremote-scripts`, `thinremote-playbooks`, `thinremote-metrics-logs`) and profiles |
+| `thinr_device_exec`                                                                                                                                      | A shell command on one device, or on several at once (`devices`, `product`, `group`, `all`)                            |
+
+ThinRemote adds its own resource types to the generic tools, so they are
+listed, read, written and deleted like a device or a token:
+
+| Type                 | Parent  | What it is                                                                     | Actions (`thinr_resource_call`) |
+| -------------------- | ------- | ------------------------------------------------------------------------------ | ------------------------------- |
+| `device_fs`          | device  | Files and folders of the device (id: the path)                                 | `move`, `push`, `pull`          |
+| `device_script`      | device  | Scripts of the agent, each a resource of the device                            |                                 |
+| `product_script`     | product | Scripts run on any device of the product, kept once in its storage             |                                 |
+| `product_metric`     | product | Metrics of thinr's terminal dashboard                                          |                                 |
+| `product_log_source` | product | Log sources an operator streams from a device                                  |                                 |
+| `product_playbook`   | product | Playbooks: YAML steps validated, tried on one device and rolled out in batches | `validate`, `run`, `rollout`    |
+
+and two actions to the server's `device` type: `agent_update` (check for or
+install a new agent) and `agent_install` (the command that installs the
+agent on a new machine). Live monitoring is the device resource
+`monitoring`; its history, the bucket `monitoring`.
+
+Full input schemas come with the standard MCP `tools/list`, and
+`thinr_resource_describe` gives each type's fields and actions.
+
+[cli-core]: https://github.com/thinger-io/thinger-cli-core
 
 ### Authoring playbooks from natural language
 
-Playbooks are declarative YAML documents — steps like `exec`, `write`,
-`install_package`, `service`, plus a `target` block and a `vars`
-block — that the runner applies to a device or a fleet. With the MCP
-server connected, an AI assistant can turn a natural-language request
-into a validated playbook and store it on the relevant product
-without the user ever writing YAML by hand.
-
-The intended authoring loop is:
-
-1. **Fetch the schema.** Call `thinr_playbook_schema` once at the
-   start of the session to get the authoritative list of top-level
-   fields, target block, step actions with their parameters, and the
-   two accepted forms of the `vars` block (plain and extended).
-2. **Draft the YAML.** Translate the user's request into a playbook
-   draft. Use the extended `vars` form
-   (`default` / `description` / `type` / `overridable` / `required`)
-   whenever the user hints at knobs the caller may need to tune at
-   run time.
-3. **Validate and iterate.** Call `thinr_playbook_validate` with the
-   draft. On failure, read the consolidated error message, fix the
-   YAML, and call validate again. Never skip this step.
-4. **Upload.** Once validation is clean, call
-   `thinr_product_playbook_write` with the product id, a short name
-   (letters / digits / underscore / dash), and the validated YAML.
-   The tool re-validates server-side; never pass `skip_validation` to
-   mask a real error.
-5. **Pre-flight on one device.** Call
-   `thinr_product_playbook_run` with a single `device` (plus
-   `dry_run: true` or `check: true` for a read-only preview) to
-   confirm the steps behave as expected.
-6. **Roll out.** Finally, `thinr_product_playbook_rollout` rolls the
-   playbook across the fleet in batches with a failure-rate kill
-   switch, and writes a persistent report to `playbooks/runs/` in the
-   product file storage.
-
-Example prompt the user can give the assistant:
-
-> "On product `edge-gateways`, create a playbook called
-> `nginx-upgrade` that updates the nginx package, renders
-> `/etc/nginx/nginx.conf` from a template, and restarts nginx only
-> if the config check passes. Make `worker_connections` an
-> overridable integer variable, default 1024. Then try it on
-> `edge-gw-17` in check mode."
-
-A well-behaved assistant translates this into:
-
-- `thinr_playbook_schema` → read the authoring contract.
-- Draft YAML → `thinr_playbook_validate` until clean.
-- `thinr_product_playbook_write` with `product="edge-gateways"`,
-  `name="nginx-upgrade"`, and the validated content.
-- `thinr_product_playbook_run` with `device="edge-gw-17"` and
-  `check: true` to preview what would change.
-
-After that a second message like "looks good, roll it out to staging"
-maps to `thinr_product_playbook_rollout` with the matching
-`group` / `filter` and a conservative `batch_size`.
+Playbooks are YAML documents with ordered steps (`exec`, `write`, `move`,
+`delete`, `script_install`…), a `target` and `vars`, that the agent applies
+on each device. With the MCP server connected, an assistant can turn a
+request into a validated playbook stored on the product, without anyone
+writing YAML by hand:
+
+1. **Read the format.** `thinr_resource_describe` type `product_playbook`:
+   its `playbook_format` lists the document fields, the target, the two
+   forms of `vars` (plain and extended) and every step action.
+2. **Draft and validate.** Write the YAML and call `thinr_resource_call`
+   type `product_playbook`, action `validate`, with it in `body.content`;
+   fix what it reports until it is clean.
+3. **Save.** `thinr_resource_create` type `product_playbook`, parent the
+   product, id a short name, body `{content}`. It is validated again and
+   nothing is saved if invalid.
+4. **Pre-flight on one device.** Action `run` with the playbook's id and
+   `body.device`, with `dry_run: true` or `check: true` for a read-only
+   preview, then for real.
+5. **Roll out.** Action `rollout` runs it across the fleet in batches with a
+   failure-rate stop, and writes a report to `playbooks/runs/` in the
+   product storage.
+
+Example prompt:
+
+> "On product `edge-gateways`, create a playbook called `nginx-upgrade`
+> that updates the nginx package, renders `/etc/nginx/nginx.conf` from a
+> template, and restarts nginx only if the config check passes. Make
+> `worker_connections` an overridable integer variable, default 1024. Then
+> try it on `edge-gw-17` in check mode."
+
+A second message like "looks good, roll it out to staging" maps to the
+`rollout` action with `group` and a conservative `batch_size`.
 
 ### Per-call controls
 
-The server starts with no per-session pin: every tool call must say
-which device it's for, and may optionally override the account or
-profile for that single call.
-
-- **`device`** — required for any device-scoped tool. Use
-  `thinr_devices` (optionally with `query` to filter by regex) to
-  discover ids.
-- **`user`** — optional admin impersonation; falls back to the
-  authenticated user of the active profile.
-- **`profile`** — optional. Switches the active profile for that
-  single tool call so an agent can hop between prod and staging
-  without restarting the server. List the configured profiles with
-  `thinr_profiles`.
+- **`profile`**: optional on every tool. Uses another configured server for
+  that call only; `thinr_profile_list` lists them.
+- **`user`**: optional admin impersonation; defaults to the profile's user.
+- Devices are named per call (`device`, or `parent` for a device's
+  resources): list them with `thinr_resource_list` type `device`.
 
 ### Integrating with Claude Code
 
@@ -563,9 +550,8 @@ Register the server once with the Claude Code CLI:
 claude mcp add thinr -s user -- thinr mcp
 ```
 
-That's it — a single MCP server entry handles every device of the
-active profile. Tool calls pass `device` (and optionally `user` /
-`profile`) per call.
+That's it: a single MCP server entry handles every device of every
+configured profile.
 
 ### Integrating with Claude Desktop, Cursor and other MCP hosts
 
@@ -625,13 +611,21 @@ Use `thinr profile use <name>` to change the persisted default, or
 ```
 thinr-cli/
 ├── bin/           # CLI entry point (thinr)
-├── commands/      # Commander subcommand modules
-├── lib/           # Core: api, auth, config, device-api, errors,
-│                  # output, mcp-server, proxy, console, …
+├── commands/      # ThinRemote subcommands (agent, fleet, playbooks…)
+├── lib/           # ThinRemote modules: identity, device-api, proxy,
+│                  # console, playbooks, product scripts, MCP tools…
 ├── package.json
 └── README.md
 ```
 
+The generic part — API client, auth, profiles, REST helpers, the generic
+commands (login, logout, profile, device list/info/property/resource,
+product list/property-\_, bucket) and the generic MCP tools — comes from
+[@thinger-io/cli-core](https://github.com/thinger-io/cli-core), shared
+with the `thinger` CLI. `lib/identity.js` is what makes it `thinr`: names,
+`~/.config/thinr-cli`, `THINR\__`, the OAuth client and the product
+template.
+
 Local development:
 
 ```bash
@@ -685,7 +679,7 @@ The script only touches resources it creates itself (identified by
 the `playbook-e2e-` product-id prefix). If a run is interrupted
 before the `finally` cleanup executes — e.g. the process is killed
 — list leftovers with `thinr product list --json` and drop each one
-through the MCP `thinr_product_delete` tool (from an AI client) or
+through the MCP `thinr_resource_delete` tool with type `product` (from an AI client) or
 via a Node one-liner reusing `deleteProductWithStorage` from
 `lib/product.js`.
 

package/bin/thinr.js

@@ -3,11 +3,22 @@
 import { readFileSync } from 'fs';
 import { fileURLToPath } from 'url';
 import { dirname, resolve } from 'path';
-import { Command } from 'commander';
 import figlet from 'figlet';
-import { accent, info } from '../lib/format.js';
-import { configExists, getActiveProfile, readConfig, setActiveProfile } from '../lib/config.js';
-import { detectJsonModeFromArgv } from '../lib/output.js';
+import { defineIdentity } from '@thinger-io/cli-core/identity';
+import { runCli } from '@thinger-io/cli-core/cli';
+import { authenticate } from '@thinger-io/cli-core/auth';
+import { configExists } from '@thinger-io/cli-core/config';
+import { accent, info } from '@thinger-io/cli-core/format';
+import { mcpInstructions, thinrIdentity } from '../lib/identity.js';
+import { tools as mcpTools } from '../lib/mcp/registry.js';
+import { resourceHooks } from '../lib/mcp/resource-hooks.js';
+import { resourceActions, resourceTypes } from '../lib/mcp/resource-types.js';
+import { guides } from '../lib/guides.js';
+import { registerDeviceCommands } from '../commands/device/index.js';
+import { registerProductCommands } from '../commands/product/index.js';
+import { fleetCommand } from '../commands/fleet/index.js';
+import { playbookCommand } from '../commands/playbook/index.js';
+import { runDashboard } from '../commands/dashboard.js';
 
 // Single source of truth for the version: package.json. Avoids the drift
 // between `package.json#version` and a hardcoded string in this file.
@@ -15,110 +26,40 @@ const pkg = JSON.parse(
     readFileSync(resolve(dirname(fileURLToPath(import.meta.url)), '../package.json'), 'utf8'),
 );
 
-// Pick up --profile early so subsequent config reads use the right one.
-// Commander parses options later, but the config is touched before that.
-for (let i = 2; i < process.argv.length; i++) {
-    const a = process.argv[i];
-    if (a === '--profile' && process.argv[i + 1]) {
-        setActiveProfile(process.argv[i + 1]);
-        break;
-    }
-    if (a.startsWith('--profile=')) {
-        setActiveProfile(a.slice('--profile='.length));
-        break;
-    }
-}
-
-// Set JSON mode before any command runs so spinners/logs can opt out.
-detectJsonModeFromArgv();
-import { authenticate } from '../lib/auth.js';
-import { deviceCommand } from '../commands/device/index.js';
-import { fleetCommand } from '../commands/fleet/index.js';
-import { logoutCommand } from '../commands/logout.js';
-import { playbookCommand } from '../commands/playbook/index.js';
-import { productCommand } from '../commands/product/index.js';
-import { profileCommand } from '../commands/profile.js';
-import { runDashboard } from '../commands/dashboard.js';
-import { setBaseURL } from '../lib/api.js';
-import { startMCPServer } from '../lib/mcp/server.js';
-
 function displayBanner() {
     console.log(accent(figlet.textSync('thinr-cli', { horizontalLayout: 'full' })));
     console.log(info('Thin Remote CLI - Remote management for IoT devices'));
     console.log();
 }
 
-const program = new Command();
-
-program
-    .name('thinr')
-    .description('CLI for ThinRemote - Remote management for IoT devices')
-    .version(pkg.version)
-    .option('-u, --user <username>', 'API user override (admin impersonation)')
-    .option('--profile <name>', 'Configuration profile to use (defaults to the saved default)');
+defineIdentity(thinrIdentity);
 
-deviceCommand(program);
-fleetCommand(program);
-productCommand(program);
-playbookCommand(program);
-profileCommand(program);
-logoutCommand(program);
+await runCli({
+    version: pkg.version,
+    mcpTools,
+    resourceHooks,
+    resourceTypes,
+    resourceActions,
+    docs: guides,
+    mcpInstructions,
+    register(program, groups) {
+        registerDeviceCommands(groups.device);
+        registerProductCommands(groups.product);
+        fleetCommand(program);
+        playbookCommand(program);
 
-program
-    .command('login')
-    .helpGroup('Profile:')
-    .description('Re-authenticate the current profile (renew an expired session)')
-    .action(async () => {
-        try {
-            // Pin the target to the active/default profile by name so the
-            // refreshed credentials overwrite it in place, even when the
-            // profile name differs from the server hostname.
-            const name = getActiveProfile();
-            if (name) setActiveProfile(name);
-            await authenticate();
-            console.log(info('Signed in.'));
-        } catch (error) {
-            console.error(`Error: ${error.message}`);
-            process.exit(1);
-        }
-    });
-
-program
-    .command('mcp')
-    .helpGroup('Integration:')
-    .description('Start the MCP server (stdio) for AI tool integration')
-    .action(async () => {
-        try {
-            await startMCPServer({ version: pkg.version });
-        } catch (error) {
-            console.error(`Error: ${error.message}`);
-            process.exit(1);
-        }
-    });
-
-// Handle help
-const originalHelp = program.help;
-program.help = function (cb) {
-    displayBanner();
-    return originalHelp.call(this, cb);
-};
-
-// initialize API base URL
-if (configExists()) {
-    const config = readConfig();
-    if (config.server) {
-        // Initialize API with the server if configured
-        setBaseURL(`https://${config.server}`);
-    }
-}
-
-// Handle no command (just "thinr"): launch the dashboard when running
-// interactively. Non-TTY contexts (pipes, scripts, `thinr | cat`) fall
-// back to `--help` so they get something useful instead of an Ink crash.
-if (process.argv.length <= 2) {
-    if (!process.stdout.isTTY) {
-        program.help();
-    } else {
+        const originalHelp = program.help;
+        program.help = function (cb) {
+            displayBanner();
+            return originalHelp.call(this, cb);
+        };
+    },
+    // Just `thinr`: launch the dashboard when running interactively (signing
+    // in first if there is no profile yet). Non-TTY contexts (pipes,
+    // scripts, `thinr | cat`) fall back to `--help` so they get something
+    // useful instead of an Ink crash.
+    async onNoCommand(program) {
+        if (!process.stdout.isTTY) program.help();
         if (!configExists()) {
             displayBanner();
             try {
@@ -129,8 +70,5 @@ if (process.argv.length <= 2) {
             }
         }
         await runDashboard();
-    }
-} else {
-    // Parse arguments - don't show banner for regular commands
-    program.parse(process.argv);
-}
+    },
+});