@remits/remits-cli 0.1.110 → 0.1.113

package/README.md

@@ -21,6 +21,7 @@ remits-cli stop
 remits-cli install --skills
 remits-cli tools
 remits-cli tool --base-url http://localhost:8080 --name "My Tool" --input '{"foo":"bar"}'
+remits-cli tool --name mcp_firestore_search --input '{"collection":"statements","documentId":"1234"}' --scope children
 remits-cli components stage
 remits-cli components status
 remits-cli components clear
@@ -70,7 +71,8 @@ remits-cli install --skills --overwrite true
 - `components commit` is a convenience wrapper that performs local git commit/push, then `components sync`, then local `git fetch`/`git pull --ff-only`.
 - `components sync` returns the post-sync branch SHA produced by the platform. `components commit` verifies that `origin/<branch>` and local `HEAD` both match that exact SHA after the final pull.
 - `components push` is deprecated and currently behaves the same as `components stage`.
-- `accountId` resolution for CLI commands: explicit `--account-id` flag wins, then the current repo's `account-info.json` (`resolution.accountId`, then the short-lived `repoContext.accountInfoAccountId`, then the legacy top-level id — legacy files are rooted at the hierarchy ROOT, so their top-level `id` may be an ancestor), then the active session. For `remits-cli tool` calls the server applies a further precedence — explicit `--account-id` > `input.accountId` > session/repo default — so a tool can execute against a different account than the surrounding repo.
+- `accountId` resolution for CLI commands: explicit `--account-id` flag wins, then the current repo's `account-info.json` (`resolution.accountId`, then the short-lived `repoContext.accountInfoAccountId`, then the legacy top-level id — legacy files are rooted at the hierarchy ROOT, so their top-level `id` may be an ancestor), then the active session.
+- For `remits-cli tool`, read/discovery tools treat that resolved account as the **scope root**. You do not need the owning child account id for an exact document/record lookup: pass `--scope children`, or put `scope:"children"` in `--input`, and use the returned `resolvedTargetAccountId` for follow-up writes/runs. Use `--target-account-id` when you already know the exact owner, `--account-ids` for an explicit bounded owner list, and `--anchor-account-id` only to disambiguate multi-parent paths. Mutating tools still require an exact target.
 - Auth sessions are stored per `accountId + dataMode + baseUrl`, so the same account can stay authenticated against both localhost and production without overwriting the other session.
 - `--base-url` and `--data-mode` are independent. `--base-url` chooses the Remits host (`http://localhost:8080` vs deployed prod), while `--data-mode` chooses the data segment on that host (`test` vs `prod`). Do not assume `--data-mode prod` means the deployed prod host, or that `--data-mode test` means localhost.
 - `remits-cli start` scans the machine for `account-info.json` files and rebuilds `~/.remits-cli/account-repos.json` before bringing up the background service.
@@ -112,33 +114,30 @@ remits-cli install --skills --overwrite true
 - If the machine sleeps, the network drops, or auth sessions change while the daemon is already running, the service now attempts to reconnect and resubscribe automatically once connectivity returns.
 - Incoming websocket messages of type `remits-cli` are dispatched into dedicated tmux windows so the selected agent can continue working interactively with a full terminal view.
 - The listener creates a shared tmux session named `remits-listener`.
-- Support tickets are the primary unit of dispatched work. Each ticket gets its own tmux window/workstream.
-- The listener enables tmux mouse support, increases scrollback history, and keeps exited panes visible for inspection.
-- Follow-up messages with the same `ticketId` are routed back to the existing pane when it is still alive.
-- Legacy payloads that only include `taskId` are still supported as a fallback routing key.
-- If a pane for a tracked ticket has exited or is dead, the listener removes that mapping and creates a replacement pane.
-- Pane commands are launched through the user's login shell so the pane inherits the normal interactive `PATH`.
-- The preferred agent comes from `remits-cli config set --agent claude|codex|gemini`. The default is `claude`.
+- Support tickets are the primary unit of dispatched work. A serving agent launches one fresh worker process per routed ticket.
+- Agent sessions register themselves with `remits-cli agent register` or `remits-cli agent serve`; `serve` also starts the local supervisor.
+- Tickets are delivered by durable routing on the ticket record, then the agent asks for routed work with `remits-cli agent work`.
+- The preferred worker comes from `remits-cli config set --agent claude|codex|gemini`. The default is `claude`.
 
 ## Support Tickets
 
 - Support tickets are stored as documents in the `support_tickets` collection.
-- New tickets and ticket updates are delivered over the `remits-cli` websocket channel and appear as local tmux workstreams.
-- Think of this as a lightweight local support queue: the platform creates and updates tickets centrally, and local agents receive those tickets to investigate and resolve.
+- New tickets and ticket updates are recorded centrally; local agents receive work by polling for tickets routed to their registered session.
+- Think of this as a lightweight local support queue: the platform owns the record and lifecycle verbs, while account components can layer their own helpdesk workflow on top.
 - `accountId` / `accountName` identify the account that owns the ticket.
 - If present, `implementationAccountId` / `implementationAccountName` identify the platform or product context that owns the shared implementation.
-- Listener repo dispatch prefers `implementationAccountId` when present, then falls back to `accountId`. If one of those repos is indexed locally in `~/.remits-cli/account-repos.json`, it will be preferred as the tmux working directory.
+- Worker repo resolution prefers `implementationAccountId` when present, then falls back to `accountId`. If one of those repos is indexed locally in `~/.remits-cli/account-repos.json`, it is used as the worker's directory.
 - Agents must resolve account `type` (`PLATFORM`, `PRODUCT`, `CLIENT`) before deciding which local repo to use. A `CLIENT` ticket may still require code changes in a parent `PLATFORM` or `PRODUCT` repo.
-- Use `mcp_support_ticket` to manage ticket state:
+- Use `remits-cli ticket` to manage the generic platform ticket lifecycle:
 
 ```bash
-remits-cli tool --name "mcp_support_ticket" --input '{"action":"read","ticketId":"123"}' --data-mode prod
-remits-cli tool --name "mcp_support_ticket" --input '{"action":"accept","ticketId":"123","assignee":"codex"}' --data-mode prod
-remits-cli tool --name "mcp_support_ticket" --input '{"action":"update_status","ticketId":"123","status":"in_progress","notes":"Investigating logs"}' --data-mode prod
-remits-cli tool --name "mcp_support_ticket" --input '{"action":"complete","ticketId":"123","resolution":"Fixed and verified"}' --data-mode prod
+remits-cli ticket read --ticket 123 --data-mode prod
+remits-cli ticket accept --ticket 123 --data-mode prod
+remits-cli ticket status --ticket 123 --status in_progress --notes "Investigating logs" --data-mode prod
+remits-cli ticket complete --ticket 123 --resolution "Fixed and verified" --data-mode prod
 ```
 
-- Recommended ticket flow: `read` first, then `accept`, then `update_status` as work progresses, then `complete` or `release`.
+- Recommended ticket flow: `read` first, then `accept`, then `status` as work progresses, then `complete`, `ask`, or `release`.
 
 ## Logging and State Files