@remits/remits-cli 0.1.130 → 0.1.133

package/package.json

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

package/skills/remits-cli/references/branch-variants.md

@@ -170,8 +170,9 @@ resolves `X`.
 
 **Subscribing to a branch and resolving through it are different facts.** An account subscribes on an
 edge; a *request* resolves through that edge only when something named the path (`--as-account`, the
-edge's own host, an explicit `--variant-branch`). An account with no `parentId` and several upward links
-resolves trunk by design — the resolver refuses to guess a path. So this is a normal, explainable state:
+edge's own host, an explicit `--variant-branch`), or when its links leave no doubt — a single upward link, or
+several with exactly one carrying a branch, which every account beneath it inherits too. An account whose
+several links carry several branches refuses to guess a path. So this is a normal, explainable state:
 
 ```
 "componentBranch": null,              // this token resolves TRUNK
@@ -421,9 +422,14 @@ a confirm-gated override when the removal guard refuses. Preview there is the sa
 - A test/tool response reports `testComponentSource` as `staged` | `variant` | `db`, so you can see which
   layer the run resolved without reading logs.
 
-> **A populated staging cache makes a variant look broken.** Anything carrying a CLI `TestMode` — a
+> **A trunk lane never overrides a variant.** Staged edits from your account's trunk branch do not reach an
+> account whose branch overrides that component — production behaves the same way — so `test run` and `token`
+> list them under **NOT RUN FOR THIS ACCOUNT** (`stagedMaskedByVariant`). To change what that account runs, edit
+> the component on its variant branch.
+>
+> **A populated NON-trunk staging lane makes a variant look broken.** Anything carrying a CLI `TestMode` — a
 > `remits-cli token` URL, `/s/<tokenKey>/...`, an `X-Auth-Token` request, a script-loader embed — resolves
-> the STAGED layer, which outranks the variant. So with components staged under the same branch/user, a
+> a variant-branch or feature-branch lane's STAGED layer, which outranks the variant. So with components staged under the same branch/user, a
 > tokenized page reports `Component Branch: <branch>` but `Variant Applied: none` and renders trunk, while
 > an anonymous `?account_id=` request to the same page reports the variant. That is the documented
 > precedence (staged -> variant -> trunk) working correctly, and it reads exactly like "tokens break

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

@@ -173,6 +173,8 @@ remits-cli agent work [--wait SECONDS] [--json]
 remits-cli agent status [--state idle|working|paused] [--ticket ID] [--activity "..."] [--step "..."]
 remits-cli agent list [--account-id ID] [--json]
 remits-cli agent map [--account-ids 1,4] [--json]       # who is EDITING which repository, from which checkout/branch/staging lane
+remits-cli agent inspect [--account-id ID] [--scope self|children] [--user-id ID|--user-email EMAIL] [--limit N] [--json]
+remits-cli activity inspect [--account-id ID] [--scope self|children] [--user-id ID|--user-email EMAIL] [--limit N] [--json]
 remits-cli agent release
 remits-cli ticket read|accept|status|progress|complete|release|reopen|assign|planning --ticket ID [--status S] [--resolution "..."] [--summary "..."] [--category C] [--assignee EMAIL] [--workstream VALUE] [--planned-in VALUE] [--board-stage VALUE] [--rank N] [--size VALUE] [--blocked-by VALUE] [--notes "..."]
 remits-cli ticket lease|unlease|force-unlease --ticket ID [--reason "..."]   # force-unlease breaks SOMEBODY ELSE'S lease; operator only
@@ -236,7 +238,7 @@ remits-cli token inspect --token <token|tokenKey|URL>                  # inspect
 remits-cli tools [--branch <name>] [--data-mode test|prod] [--variant-branch <name|none>]
 remits-cli tool --name <toolName> [--branch <name>] [--input "{...}"] [--data-mode test|prod] [--variant-branch <name|none>] [--timeout-ms 60000] [--async true --wait true]
 remits-cli tool status --call-id <callId> [--data-mode test|prod]
-remits-cli verify start --summary "..." [--manifest file.json] [--ticket ID]
+remits-cli verify start --summary "..." [--manifest file.json] [--ticket ID] [--data-mode test|prod]   # default: test
 remits-cli verify list [--max 50] [--json]
 remits-cli verify use <envelopeId>
 remits-cli verify current
@@ -261,6 +263,30 @@ remits-cli verify abandon --envelope ID --reason "..."
 remits-cli verify supersede --envelope ID --superseded-by <envelopeId> [--reason "..."]
 ```
 
+### Activity inspection
+
+`remits-cli activity inspect` is a read-only operator view for understanding an agent or account
+workstream without touching a checkout or staging lane. It joins the current staging-lane registry,
+verification envelopes, durable Test runs, corpus measurements, and live CLI agent presence, then adds
+heuristic smell signals such as shared lanes, broad overlays, retained staged entries, unfinished
+verification, current evidence failures, repeated test failures, corpus failures, and tests that were run
+outside a verification envelope.
+
+Use it from the platform repo when a remote agent fleet is looping or a human reports that work is going
+around in circles:
+
+```bash
+remits-cli activity inspect --account-id 4 --scope children --data-mode test
+remits-cli activity inspect --account-id 4 --scope children --user-email jason@example.com --json
+remits-cli agent inspect --account-id 1742 --limit 50
+```
+
+`--scope children` expands from the selected account to its hierarchy children, which is usually the right
+shape for platform-level review. `--user-id` / `--user-email` filters the stream to one CLI user when the
+platform can identify them from staged lanes, envelopes, tests, or live agent registration. `--json`
+returns the full structured payload for deeper analysis; the text view is intentionally compact and
+human-readable.
+
 ### Verification envelopes
 
 Use a verification envelope for workflow-shaped work: concrete user journeys, browser-facing changes,

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

@@ -84,6 +84,25 @@ command world. While active, `components stage`, `components status`, `test run`
 `--verify-envelope <id>` to name one explicitly or `--no-verify-envelope` when a command should not be
 attached.
 
+`verify start` proves in the **test** lane unless you pass `--data-mode prod` (your session's lane does not
+decide it). One envelope is active per checkout world (host, account, git branch, workspace); the data lane
+is not part of that selection.
+
+Before stage, test run, token, tool, sync or commit runs, the CLI asks the platform whether its evidence
+would count for the active envelope:
+
+- **attach**: same world, so the evidence attaches.
+- **refuse**: different world and a required evidence item could use this packet. Nothing ran, and the
+  refusal names the fix (`--data-mode prod`, `--as-account 21`, `--workspace x`, ...). Apply the fix that
+  matches your intent. Use `--no-verify-envelope` when the run is not meant as proof, or `verify start` when
+  it is different work. `--allow-wrong-world-evidence` only records context; that evidence never satisfies
+  anything.
+- **detach**: different world and nothing in the manifest could use it. The command runs and one line says
+  nothing was attached.
+
+`verify current` / `verify use` print whether a plain `test run` from this checkout would attach, so you can
+catch a mismatch before the first run.
+
 Use the wrappers when you want the intent to be unmistakable:
 
 ```bash

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

@@ -237,9 +237,10 @@ client accounts beneath it:
 > is a fully supported shape: it resolves the branch, **and so do all of its descendants**. You do not need
 > to make the subscriber a structural child of its owner.
 >
-> What is NOT resolved by default is genuine **ambiguity** — an account with *several* upward links, where
-> the platform refuses to guess which product it was reached through. That account (and its descendants)
-> resolve trunk until a request names the path: `--as-account`, `--variant-branch`, or the edge's own host.
+> Several upward links are fine when exactly one carries the branch: the account and its descendants roll up
+> through that subscription. What is NOT resolved by default is genuine **ambiguity** — several links and no
+> single subscription among them. That account (and its descendants) resolve nothing above it until a request
+> names the path: `--as-account`, `--variant-branch`, or the edge's own host.
 > An account that has a `parentId` **and** a separate membership edge carrying the branch is this case: the
 > `parentId` wins, so put the branch on the link the account actually inherits through.
 >