@remits/remits-cli 0.1.97 → 0.1.98

package/README.md

@@ -63,7 +63,7 @@ remits-cli install --skills --overwrite true
 - `components clear` clears staged entries. Scope it with `--component-type` and/or `--component-id`. Component ids are type-local, so an id alone clears that one component when the id is staged in only one family; if the same id is staged across multiple families it returns an ambiguity error asking you to add `--component-type`. With no filter it clears every staged entry for the current branch; pass `--all` to force the full-branch wipe explicitly.
 - `components stage`, `components status`, and `components clear` print concise summaries by default. Add `--json` or `--verbose` to print the full server response. `components stage` separates local working-tree component deltas from the full materialized staging cache count.
 - `components sync` performs a server-side sync from the git remote into the Remits platform for the selected branch. It does not run local git commands. After a successful non-dry-run sync, the platform clears the branch/user staging scope so staged aliases cannot keep shadowing the newly synced DB rows.
-- On trunk, `components sync` performs the full repo-to-DB reconcile. On a non-trunk branch, it writes `ComponentVariant` overlays only and may refresh branch-local `account-info.json` / `account-hierarchy.json` for the subscribing account that initiated the sync. `--dry-run` is accepted only for non-trunk variant syncs and reports overrides/additions/tombstones without writing variants, caching the sync SHA, updating metadata, or clearing staging. Add `--summary` to dry-run output when you only need counts, removals/tombstones, errors, skipped items, and warnings. `--force-tombstones` is accepted only for non-trunk variant syncs and should be used only when missing trunk component files are intentional tombstone overrides.
+- On trunk, `components sync` performs the full repo-to-DB reconcile. On a non-trunk branch, it writes `ComponentVariant` overlays only and may refresh branch-local `account-info.json`, `account-hierarchy.json`, and `account-configurations.json` for the subscribing account that initiated the sync. `--dry-run` is accepted only for non-trunk variant syncs and reports overrides/additions/tombstones without writing variants, caching the sync SHA, updating metadata, or clearing staging. Add `--summary` to dry-run output when you only need counts, removals/tombstones, errors, skipped items, and warnings. `--force-tombstones` is accepted only for non-trunk variant syncs and should be used only when missing trunk component files are intentional tombstone overrides.
 - `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`.
@@ -173,7 +173,7 @@ There are two separate state areas:
 
 - `remits-cli start` prints or records a localhost dashboard URL such as `http://127.0.0.1:8787/`.
 - Open that page in a browser to inspect the full local remits-cli integration state without manually opening JSON files.
-- The page refreshes automatically and includes the latest global state files plus per-repo `account-info.json`, local tools snapshot, and current session log tail for every indexed account repo.
+- The page refreshes automatically and includes the latest global state files plus per-repo `account-info.json`, local tools snapshot, and current session log tail for every indexed account repo. Large account configuration fields live in `account-configurations.json` and should be opened only when needed.
 
 ## Tmux Activity Log
 

package/package.json

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

package/skills/remits-cli/SKILL.md

@@ -31,6 +31,7 @@ description: Use remits-cli for fast branch-scoped component staging, test execu
   - [HTTP audits](#http-audits)
   - [AI activity](#ai-activity)
   - [Node Reference Table](#node-reference-table)
+  - [Runtime node and `localMode`](#runtime-node-and-localmode)
 - [Getting Started](#getting-started)
   - [Authentication](#authentication)
   - [Host vs Data Mode](#host-vs-data-mode)
@@ -345,6 +346,8 @@ These files are decision inputs. Read them when the related decision depends on
   - Read when the question is about available tool names, cached schemas, or why a tool invocation shape may be invalid.
 - `account-info.json`
   - Read in the target repo before making component changes or assuming account ownership.
+- `account-configurations.json`
+  - Read only when account configuration values matter. It is generated separately because configuration maps can be large and `account-info.json` deliberately omits them.
 
 Do not rely on memory for these indexes. Read the file that governs the decision you are making.
 
@@ -602,6 +605,29 @@ before reading the persisted request/response is guessing.
 
 `mcp_system_logs` accepts `node` directly and resolves it automatically.
 
+### Runtime node and `localMode`
+
+The deployed `remits` service in `us-east5` (`remitsAdmin-east5`) runs with the platform setting
+`localMode=true`. If someone says "localModel" in this context, confirm they mean this `localMode`
+setting. Operationally, immediate async follow-on work stays on the same Cloud Run service/node instead of
+being sharded to `remits-actions`:
+
+- Pub/Sub-style follow-on messages are handled locally after commit.
+- Near-immediate tasks are handled locally when `localMode` is enabled. Future scheduled tasks still use
+  Cloud Tasks.
+- Local worker hops preserve the run context, including staged-source resolution, data mode,
+  `threadGroupingId`, and trace correlation.
+- Durable boundaries such as async HTTP ingress and Events carry that same run context across the queue.
+
+For investigations on the default deployed host (`https://remits-529558023549.us-east5.run.app`), do not
+assume "async" means `remitsActions` / `us-east1`. Start with `node:"remitsAdmin-east5"` and the
+`threadGroupingId`; pivot to `remitsActions` only when the Event delivery envelope, log line, or returned
+node says the work actually ran there.
+
+This does not change the data-lane rule: a non-null `TestMode` can exist only to carry branch/staged-source
+resolution. Data isolation is decided by CLI `--data-mode`: a branch-scoped `--data-mode prod` run is still
+prod data, while `--data-mode test` remains isolated test data.
+
 ## Getting Started
 
 ### Authentication
@@ -2530,6 +2556,7 @@ For tests specifically:
 | Staged change has no effect in a live (non-CLI) run | Staged overrides resolve only under a CLI TestMode (`branchName`+`cliUserId`). Live webhooks and other non-CLI runtime paths still use the DB (trunk, or the account's subscribed variant). `commit` to make it durable. See "Component Resolution". |
 | Need to know an account's shape (role, type, parents, namespace, branch) | Read `resolution` — from the repo's `account-info.json`, or `mcp_account_user_admin` `action:'account'` (cheap), or `mcp_account_view` (full inventory): `role`/`summary`, `type`, `resolvedDatabaseName`, `relationships`, `componentBranch`, plus top-level `componentBranches`. Never infer structure from the account's name. |
 | Need the account tree below an account, or its users | In a local repo, read `account-hierarchy.json` for the generated tree. For live data, use `mcp_account_user_admin` (`action:'hierarchy'` with a `depth`, or `action:'users'`). `account-info.json` deliberately omits the tree. |
+| Need account configuration values | In a local repo, read `account-configurations.json`. For live data, use `mcp_account_user_admin` (`action:'account'`) or `mcp_account_view`. `account-info.json` deliberately omits configurations. |
 | An account has two parents and you don't know which one a run used | `resolution.relationships` lists every link with its own `branchName`/`databaseName`/`domainName`. A membership-only account with SEVERAL edges resolves **trunk and inherits nothing** until a path is named (`--as-account`, `--variant-branch`, or an edge host) — that is by design, not a bug. With exactly ONE membership edge it inherits normally, descendants included. |
 | Documents missing / written to the wrong place | Compare `resolution.databaseName` (the account's own override) with `resolution.resolvedDatabaseName` (what is actually in effect), and check for a `databaseName` on one of the `relationships` edges. Data does not inherit; components do. |
 | A custom hostname resolves to an unexpected account | Compare `resolution.domainName` with `resolvedDomainName` and the edge `domainName`s. An **edge** host wins over the account's own host and additionally supplies the path travelled (which is what makes that edge's branch variants apply). |