@remits/remits-cli 0.1.137 → 0.1.138

package/index.js

@@ -14,8 +14,8 @@
 - L7104  Branches, Promotion, Commit, And Test Runs
 - L9193  Tokens, Tools, Verification, And Config
 - L10620  Service Dashboard And WebSocket Listener
-- L12742  Agent And Ticket Workflows
-- L16337  Help, Auto Update, And Command Dispatch
+- L12743  Agent And Ticket Workflows
+- L16338  Help, Auto Update, And Command Dispatch
 */
 
 /*
@@ -11339,6 +11339,7 @@ function buildRepoSnapshot(entry) {
     ? path.join(localPaths.legacy.sessionsDir, legacySessionName + '.jsonl')
     : null;
   const repoFiles = [
+    { label: 'account-boot.json', path: path.join(directory, 'account-boot.json'), mode: 'json' },
     { label: 'account-info.json', path: entry.accountInfoPath || path.join(directory, 'account-info.json'), mode: 'json' },
     { label: 'account-hierarchy.json', path: path.join(directory, 'account-hierarchy.json'), mode: 'json' },
     { label: 'account-analytics.json', path: path.join(directory, 'account-analytics.json'), mode: 'json' },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remits/remits-cli",
-  "version": "0.1.137",
+  "version": "0.1.138",
   "description": "Local CLI for auth, component sync, and live test execution against Remits",
   "license": "MIT",
   "private": false,

package/skills/remits-cli/SKILL.md

@@ -140,6 +140,12 @@ reference named after it.
   (`component-resolution.md`, `command-reference.md`)
 - **Host and data mode are two independent decisions.** `--base-url` picks the Remits host,
   `--data-mode` picks the data segment on it. Neither implies the other. (`command-reference.md`)
+- **Localhost being down is not a verification blocker.** `remits-cli` can talk to any reachable Remits
+  host, including the deployed production host, by passing `--base-url`. If `http://localhost:8080`
+  refuses a connection, retry the same stage/test/tool/status command against the intended deployed host
+  with the same account, branch, workspace and data-mode facts; do not stop unless no reachable host or
+  valid session exists. A deployed host can still run test-lane verification: `--base-url` selects the
+  server, while `test run` still defaults to `--data-mode test`. (`command-reference.md`)
 - **`test run` ignores the stored session data lane.** It defaults to `test` even when `whoami` shows
   the session parked on prod; production Test runs require explicit prod provenance (`--data-mode prod`)
   or Test source declaring `dataMode 'prod'` / `[dataMode:'prod']`. Check returned `dataModeSource`
@@ -216,7 +222,8 @@ remits-cli components status      # trunk or variant checkout, staging lane, wor
 remits-cli tools                  # which tools this account actually has (tools are per-account)
 ```
 
-plus the repo's `account-info.json` → `resolution` block for the account's shape.
+plus the repo's `account-boot.json` → `resolution` block for the account's shape (`account-info.json`
+only when you need full inventory detail).
 For a workflow-shaped request, rely on the automatic `remits-cli evidence` trail unless someone else needs
 a checkable verdict. Only then start `remits-cli verify start --summary "..."`, declare claims, and keep
 that envelope active through stage/test/token/sync.
@@ -228,7 +235,8 @@ non-default host).
 `~/.remits-cli/account-repos.json` (every local repo, plus the reserved `platform` entry for the core
 platform clone), `~/.remits-cli/sessions.json` (auth state and lanes), `~/.remits-cli/agents.json`
 (agents registered here), `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json` (the full
-tool payload), and the repo's `account-info.json`. `cli-state.md` maps every remaining question to its
+tool payload), the repo's `account-boot.json`, and `account-info.json` when compact context is not enough.
+`cli-state.md` maps every remaining question to its
 file, including legacy flat `.remits-cli/` fallbacks.
 Repo-local session JSONL is intentionally a bounded audit log: request payloads and ordinary response
 bodies are summarized with keys, sizes, hashes, and redaction markers. Open actor-scoped tool response
@@ -242,7 +250,7 @@ Keep support and development sessions lean:
   `mcp_component_view` / `mcp_component_grep` are fallback surfaces for agents without that checkout,
   or for confirming what the live DB has stored after you already understand the files. For a ticket
   with `implementationAccountId`, resolve that account's indexed repo first, pull the appropriate
-  branch when the checkout is clean, and inspect `account-info.json` + `components/` there.
+  branch when the checkout is clean, and inspect `account-boot.json` + relevant `components/` there.
 - Do not read entire `.remits-cli/actors/<local-agent>/sessions/*.jsonl` (or legacy flat session logs) or
   large tool response files unless you first narrow to the relevant request, endpoint, tool, or ticket.
 - Prefer targeted Firestore queries: use `documentId`, tight `filters`, narrow `fields`, and low `limit`

package/skills/remits-cli/references/account-targeting.md

@@ -23,13 +23,14 @@
 against, and where a fix belongs are answered by the account's structure — never by its name.
 
 The account model itself — types, component inheritance, primary vs membership edges, the three independent
-edge properties, the user model — is in the always-loaded `platform-overview.md` and in depth in
+edge properties, the user model — is summarized in `platform-core.md` and in depth in
 `features/account-management.md` (`mcp_get_guide`). What follows is only what changes **what you type**.
 
 ### Read the shape first
 
-`account-info.json` (in a repo) and `mcp_account_view` (remotely) both carry a `resolution` block — the one
-place these facts appear. Field-by-field detail is under **`mcp_account_view`** in `tool-reference.md`. The
+`account-boot.json` (in a repo), `account-info.json` (full local inventory), and `mcp_account_view`
+(remotely) all carry a `resolution` block — the one place these facts appear. Field-by-field detail is
+under **`mcp_account_view`** in `tool-reference.md`. The
 four that decide a CLI action:
 
 | Read | To decide |
@@ -57,7 +58,8 @@ Two more, easily confused: top-level **`componentBranches`** lists the variant b
   current before reading source or editing. Run `git fetch origin`; when the tree is clean,
   `git pull --ff-only origin <branch>`; then confirm `git log origin/<branch>..<branch>` and
   `git log <branch>..origin/<branch>` are both empty. A worktree can have an isolated staging workspace
-  and still be based on a stale commit. Then read `account-info.json` and inspect `components/` directly.
+  and still be based on a stale commit. Then read `account-boot.json` and inspect relevant `components/`
+  directly; use `account-info.json` only for full inventory detail.
 - **Inside one repo but supporting a different account**: switch to that account's indexed repo if it
   exists. For tickets, prefer `implementationAccountId` / `implementationAccountName` over the reporting
   `accountId` when choosing that repo; a subscriber or client often reports the symptom while the
@@ -84,7 +86,7 @@ still go to the test lane. `Object.testMode` /
 `Event.testMode` / `Alert.testMode` (and `testMode` inside test-lane Audit documents) identify lifecycle
 rows in the test data lane. Agent-facing surfaces expose these fields:
 
-- `account-info.json`, `account-hierarchy.json`, and `mcp_account_view`: `resolution.testAccount` for the
+- `account-boot.json`, `account-info.json`, `account-hierarchy.json`, and `mcp_account_view`: `resolution.testAccount` for the
   described account, and `testAccount` on returned hierarchy nodes.
 - `mcp_account_user_admin`: `testAccount` on `hierarchy`, `account`, and `account_create` results;
   `testUser` on `users` / `user` results.

package/skills/remits-cli/references/command-reference.md

@@ -42,6 +42,10 @@ Treat host selection and data mode as two separate decisions:
 
 - `--base-url` chooses the Remits host: localhost vs a deployed environment.
 - `--data-mode` chooses the data segment on that host: `test` vs `prod`.
+- A connection failure to `http://localhost:8080` only says the local back-stage app is not reachable.
+  It does **not** mean staging, testing, tokens, or investigation are blocked. If a deployed Remits host
+  is the right target, pass it explicitly with `--base-url` and keep the same account/branch/workspace
+  and `--data-mode` facts.
 
 Examples:
 
@@ -49,11 +53,20 @@ Examples:
 # Deployed prod host, but test data segment
 remits-cli tools --base-url https://your-prod-host --data-mode test
 
+# Deployed prod host, test data, staged component verification
+remits-cli components stage --workset --base-url https://your-prod-host
+remits-cli test run --test "Statement Reader Calculations" --base-url https://your-prod-host
+
 # Localhost host, but prod data segment on that localhost instance
 remits-cli tool --base-url http://localhost:8080 --name mcp_account_view --data-mode prod
 ```
 
-Do not assume `--data-mode prod` implies the deployed prod host, or that `--data-mode test` implies localhost. If host matters, read `~/.remits-cli/sessions.json` first and pass `--base-url` explicitly.
+Do not assume `--data-mode prod` implies the deployed prod host, or that `--data-mode test` implies
+localhost. Likewise, do not assume localhost is required because the current checkout is a back-stage
+repo or because a previous command used localhost. If host matters, read `~/.remits-cli/sessions.json`,
+`remits-cli whoami`, or the recent `remits-cli evidence` world blocks, then pass `--base-url` explicitly.
+Only call verification blocked after trying the intended reachable host and finding that no authenticated
+session or usable network path exists.
 
 ### Tool Execution Lifecycle
 

package/skills/remits-cli/references/development-loop.md

@@ -172,7 +172,7 @@ wants to proceed rather than reporting the work as done.
 This is how every development task should flow:
 
 #### Step 1: Understand the Request
-Read the user's request. If you may need a repo other than the current one, read `~/.remits-cli/account-repos.json` first. Then review `account-info.json` and `README.md` to understand what components exist and how they relate. Read the source of any component you'll modify before changing it.
+Read the user's request. If you may need a repo other than the current one, read `~/.remits-cli/account-repos.json` first. Then review `account-boot.json` and `README.md` to understand the account shape and component routing inventory. Read `account-info.json` only when the compact file lacks detail you need. Read the source of any component you'll modify before changing it.
 
 **Establish a steady git baseline before the first edit.** The platform syncs from the GitHub remote, not
 from your local files, and a worktree can be stale even when its staging lane is isolated. In the checkout
@@ -191,14 +191,14 @@ that the branch is behind trunk or that overlays were computed from an old SHA,
 code. A workspace prevents staged-cache collisions; it does not make a stale branch current.
 
 **Establish the account's shape too, not just its components.** Read the `resolution` block in
-`account-info.json` (or `mcp_account_view`): the account `type` decides whether this repo is even the right
+`account-boot.json` (or `mcp_account_view`): the account `type` decides whether this repo is even the right
 place to change code, `resolution.relationships` shows whether the account has more than one parent (and
 which link carries a branch/namespace/host), and `resolvedDatabaseName` tells you where its data actually
 lands. See `account-targeting.md` and `features/account-management.md` (`mcp_get_guide`).
 
 **Also establish which world you are working in.** `remits-cli components status` reports whether the
 working tree is a **trunk** checkout or a **variant branch** checkout — which decides both what your test
-runs resolve and what a sync writes. If `account-info.json` carries a `componentBranches` section, branch
+runs resolve and what a sync writes. If `account-boot.json` carries a `componentBranches` section, branch
 variants of these components exist: editing an origin component will drift them, so check
 `remits-cli components branches` before changing shared code. See `branch-variants.md`.
 
@@ -265,7 +265,7 @@ the file. Omit the key; the platform fills it in on sync:
 ```yaml
 # components/embeddables/new_MerchantPortal.meta.yml   — no `id:` yet
 name: Merchant Portal
-summary: One-line statement of what this component is for. This is the compact text account-info.json uses first.
+summary: One-line statement of what this component is for. This is the compact text account-boot.json uses first.
 description: |
   Longer technical description with line-number references to the key logic.
 path: /page/merchant-portal        # Readers and Embeddables only
@@ -568,7 +568,7 @@ If the work is tied to a support ticket:
 
 Before committing, update metadata so the next session understands what changed:
 
-1. **`.meta.yml` sidecars** — Update `summary`, `description`, and `mermaid` for each modified component. `summary` is what drives the compact component description in generated `account-info.json`; `description` is the fallback when no summary is set and is capped in that file. Preserve or explicitly revise dated decision notes; do not delete the evidence the next agent needs.
+1. **`.meta.yml` sidecars** — Update `summary`, `description`, and `mermaid` for each modified component. `summary` is what drives the compact component description in generated `account-boot.json`; `description` is the fallback when no summary is set and is capped there. Preserve or explicitly revise dated decision notes; do not delete the evidence the next agent needs.
 2. **`README.md`** — If the change affects account-level capabilities or workflows.
 3. **New components** — Always fill in `.meta.yml` immediately.