@remits/remits-cli 0.1.129 → 0.1.132

package/package.json

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

package/skills/remits-cli/SKILL.md

@@ -136,8 +136,13 @@ reference named after it.
   returns both lanes mixed; filter it yourself. (`account-targeting.md`)
 - **"Tool call succeeded" means DISPATCHED, not that the tool did what you asked.** A tool that runs and
   refuses returns HTTP 200 with its own `success: false`. For any mutating call, read `result.success`
-  from `./.remits-cli/tool-responses/<callId>.json` before reporting the work as done.
+  from `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json` (or the legacy flat fallback
+  if `doctor local-state` says the response is there) before reporting the work as done.
   (`tool-reference.md`)
+- **Workspace and local actor are different.** `workspace` is the server-side staging lane namespace;
+  `local actor` is the repo-local filesystem namespace for session logs, tool responses, and verification
+  mirrors. Use `REMITS_AGENT_ID=<name>` or `--local-agent <name>` when agents share a checkout, and run
+  `remits-cli doctor local-state` when inheriting one. (`cli-state.md`, `component-resolution.md`)
 - **Writing the code is not finishing the job.** A change is complete when it is verified — a Test
   component (preferred, because it becomes regression protection) or a browser flow through
   `remits-cli token`. "Just do it" and "that's fine, commit it" are not evidence. If you genuinely
@@ -183,6 +188,7 @@ reference named after it.
 ```bash
 remits-cli whoami                 # account, user, branch, data mode, host for the NEXT tool call
 remits-cli workspace use --auto   # your own staging lane, named after this checkout
+remits-cli doctor local-state     # active local actor, state dir, tracked .remits-cli, legacy state
 remits-cli components status      # trunk or variant checkout, staging lane, workset vs overlay, who else is staging
 remits-cli tools                  # which tools this account actually has (tools are per-account)
 ```
@@ -197,8 +203,12 @@ non-default host).
 **Files that are decision inputs — read the one that governs the decision, do not rely on memory:**
 `~/.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/tool-responses/<callId>.json` (the full tool payload), and the
-repo's `account-info.json`. `cli-state.md` maps every remaining question to its file.
+(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
+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
+files when you need the full tool result.
 
 ## Efficiency rules
 
@@ -209,8 +219,8 @@ Keep support and development sessions lean:
   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.
-- Do not read entire `.remits-cli/sessions/*.jsonl` or large tool response files unless you first narrow
-  to the relevant request, endpoint, tool, or ticket.
+- 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`
   values instead of broad collection scans.
 - Do not call `mcp_account_view` repeatedly once you already have the needed account/component context.

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/cli-state.md

@@ -36,14 +36,18 @@ These files are decision inputs. Read them when the related decision depends on
   - Read when diagnosing service lifecycle, websocket, agent registration, or ticket-routing failures.
 - `~/.remits-cli/sessions.json`
   - Read when authentication state, active accounts, base URLs, websocket topics, or per-account data mode matters.
-- `./.remits-cli/current-session.txt`
-  - Read before opening repo-local session logs so you know which session file is current.
-- `./.remits-cli/sessions/<current-session>.jsonl`
-  - Read when the question is about what HTTP calls the repo recently made through remits-cli, which payload was sent, or what response/error came back.
-- `./.remits-cli/tool-responses/<callId>.json`
+- `./.remits-cli/workspace`
+  - The staging lane selector for this checkout. It is not the local filesystem session namespace.
+- `./.remits-cli/actors/<local-agent>/current-session.txt`
+  - Read before opening repo-local session logs so you know which actor-scoped session file is current.
+- `./.remits-cli/actors/<local-agent>/sessions/<current-session>.jsonl`
+  - Read when the question is about what HTTP calls this local actor recently made through remits-cli. Request entries and ordinary response bodies contain bounded summaries/hashes by default, not raw nested payloads.
+- `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json`
   - Read when `remits-cli tool` says the full payload was stored externally.
-- `./.remits-cli/tools/tools.json`
+- `./.remits-cli/shared/tools/tools.json`
   - Read when the question is about available tool names, cached schemas, or why a tool invocation shape may be invalid.
+- `./.remits-cli/actors/<local-agent>/verification/`
+  - Local mirror and active pointers for verification envelopes for this actor.
 - `account-info.json`
   - Read in the target repo before making component changes or assuming account ownership.
 - `account-configurations.json`
@@ -67,15 +71,28 @@ Think about remits-cli as two cooperating layers:
 2. **Per-repo state** in `./.remits-cli/`
    - This is the request/response and cache layer for one specific working tree.
    - It answers questions like:
-     - which repo-local session log is current
+     - which local actor/session log is current
      - which `/cli/*` calls were made from this repo
      - where a large tool response was written
      - which tool schemas were most recently cached here
 
-Tool response files under `./.remits-cli/tool-responses/` are the full CLI results. The CLI may print a
-size/hash hint for large files so you can inspect them selectively with `jq`, `rg`, or byte-range reads,
-but it does not truncate the local JSON file. Do not confuse this with the in-platform OpenRouter client,
-which can offload large tool results inside the model conversation and inject a read-back tool for the AI.
+Per-repo state has two independent namespaces:
+
+- **Workspace** (`--workspace`, `REMITS_WORKSPACE`, `.remits-cli/workspace`) chooses the server-side
+  Redis staging lane. It changes what staged entries a run resolves.
+- **Local actor** (`--local-agent`, `REMITS_AGENT_ID`, generated fallback) chooses the local filesystem
+  namespace under `.remits-cli/actors/<local-agent>/`. It changes where session logs, tool responses,
+  verification mirrors, and diagnostics are written.
+
+Run `remits-cli doctor local-state` to print the active actor, state directory, workspace source,
+foreign actors, git-tracked `.remits-cli` files, legacy flat state, and large/suspicious logs.
+
+Tool response files under `./.remits-cli/actors/<local-agent>/tool-responses/` are the full CLI results.
+The CLI may print a size/hash hint for large files so you can inspect them selectively with `jq`, `rg`, or
+byte-range reads, but it does not truncate the local JSON file. Legacy flat
+`./.remits-cli/tool-responses/` files remain readable as fallback; `doctor local-state` labels them as
+legacy state. Do not confuse this with the in-platform OpenRouter client, which can offload large tool
+results inside the model conversation and inject a read-back tool for the AI.
 
 When a user asks an indirect question, map it to the right layer first:
 
@@ -143,21 +160,33 @@ If the index file doesn't exist yet, run any `remits-cli` command from an accoun
   - This is usually the best forensic file for "what happened?" questions.
 
 **Per-repo** (`./.remits-cli/`):
-- `tools/tools.json`
+- `workspace`
+  - Staging lane selector for this checkout. Precedence is `--workspace` > `REMITS_WORKSPACE` >
+    `.remits-cli/workspace` > shared default lane. A workspace does not choose local log directories.
+- `shared/tools/tools.json`
   - Cached tool definitions for this repo context.
   - Read this when tool availability or input shape is unclear.
-- `sessions/<name>.jsonl`
-  - Repo-local HTTP request/response log for `/cli/*` calls.
-  - Tokens are redacted and large content fields are summarized.
+- `actors/<local-agent>/sessions/<name>.jsonl`
+  - Actor-scoped HTTP request/response log for `/cli/*` calls.
+  - Tokens are redacted. Request payloads are summarized with keys, sizes, hashes, and redaction markers
+    by default; raw nested tool input is not logged unless `REMITS_CLI_UNSAFE_LOG_PAYLOADS=1` was set.
+  - Ordinary response bodies are also summarized so guide syncs, verification packets, and other large
+    responses do not bloat the session log. Full `remits-cli tool` results are stored in
+    `actors/<local-agent>/tool-responses/<callId>.json`.
   - This is the first file to inspect when the question is "what exactly did remits-cli send or receive from this repo?"
-- `tool-responses/<callId>.json`
+- `actors/<local-agent>/tool-responses/<callId>.json`
   - Full payload for `remits-cli tool` responses that were too large for the session log.
   - Prefer this over terminal summaries when investigating tool behavior.
-- `current-session.txt`
+- `actors/<local-agent>/current-session.txt`
   - Pointer to the active repo-local session log name.
-  - Always read this before opening `sessions/<name>.jsonl`.
+- `actors/<local-agent>/verification/`
+  - Local verification envelope mirror and active context pointers for this actor.
+- Legacy fallbacks: `sessions/`, `tool-responses/`, `verification/`, `tools/`, and `current-session.txt`
+  - New writes do not use these flat paths. Existing files remain readable for compatibility and are
+    reported by `remits-cli doctor local-state`.
 
 Reading rules:
-- Read `current-session.txt` before opening a session log by name.
-- When a tool call says the response was stored externally, open `tool-responses/<callId>.json` instead of inferring from the terminal summary.
+- Read `actors/<local-agent>/current-session.txt` before opening a session log by name.
+- When a tool call says the response was stored externally, open `actors/<local-agent>/tool-responses/<callId>.json` instead of inferring from the terminal summary.
+- Use `remits-cli doctor local-state` first when inheriting a checkout or when more than one actor directory exists.
 - If a question spans both global and repo-local behavior, inspect both layers and explain which facts came from which layer.

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

@@ -85,10 +85,13 @@ deterministically:
 remits-cli tool --name "mcp_run_action" --input '{"accountId":49,"actionId":200,"executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
 ```
 
-Every tool response is saved in full to `./.remits-cli/tool-responses/<callId>.json`. Large responses may
-print an early size/hash line and a selective-read hint before any preview text, but the saved CLI file is
-not truncated or offloaded. That is separate from the platform's OpenRouter model loop, where the AI
-client may offload large tool results before feeding context back to the model.
+Every tool response is saved in full to
+`./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json`. Large responses may print an early
+size/hash line and a selective-read hint before any preview text, but the saved CLI file is not truncated
+or offloaded. Legacy flat `./.remits-cli/tool-responses/<callId>.json` files remain readable as fallback;
+`remits-cli doctor local-state` shows which state belongs to the active actor. This is separate from the
+platform's OpenRouter model loop, where the AI client may offload large tool results before feeding
+context back to the model.
 
 ### Hierarchy-scoped tool reads
 
@@ -170,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
@@ -192,6 +197,7 @@ remits-cli start [--foreground true] [--port 8787]
 remits-cli stop
 remits-cli status [--base-url URL] [--account-id ID] [--data-mode test|prod] [--json]
 remits-cli whoami [--base-url URL] [--account-id ID] [--data-mode test|prod] [--json]
+remits-cli doctor local-state [--json]                  # active local actor, workspace source, legacy state, tracked .remits-cli files
 remits-cli listen [stop|status] [--foreground true]   # compatibility alias
 remits-cli data-mode [set test|prod]
 remits-cli components stage [--workset | --changed-only] [--branch <name>] [--workspace <name>] [--empty-workset clear] [--data-mode test|prod] [--json|--verbose]   # default = FULL SNAPSHOT of the repo; --workset = only what git says changed, lane reconciled to it
@@ -210,13 +216,29 @@ remits-cli components branch <name> --subscribe <accountId> [--parent-account <i
 remits-cli components branch <name> --unsubscribe <accountId>                          # return that account to trunk
 remits-cli components branch <name> --retire [--force]                                 # delete the branch's overlays
 remits-cli test run --test <id|name> [--branch <stagingScope>] [--names "a|b"] [--watch true|false] [--data-mode test|prod] [--as-account <ID>] [--variant-branch <name|none>] [--json]
-remits-cli test status --task-id <taskId> [--branch <stagingScope>] [--data-mode test|prod] [--json]
+remits-cli test status --task-id <taskId> [--branch <stagingScope>] [--data-mode test|prod] [--json]   # falls back to the DURABLE run record once the live status expires
+remits-cli test runs [--test <id|name>] [--limit 20] [--compare] [--as-account <ID>] [--json]              # durable run history: pass counts, live AI cost, lane, content hash
+remits-cli test compare --base <taskId> --head <taskId> [--json]                                            # per-case improved / regressed / changed, cost and world deltas
+remits-cli corpus import --manifest corpus-manifest.json [--corpus <name>] [--as-account <ID>] [--data-mode test|prod --confirm-prod] [--json]   # seed an evaluation corpus: cases + immutable artifacts; idempotent by caseKey
+remits-cli corpus cases --corpus <name> [--split S] [--tag T|--tags T,U] [--key K|--keys K,L] [--include-values] [--include-retired] [--limit N] [--json]
+remits-cli corpus runs --corpus <name> [--limit 20] [--json]                                   # runs that measured the corpus: outcomes, AI mode (live|MOCKED|none), cost, world
+remits-cli corpus results --corpus <name> [--case <caseKey>] [--task-id <taskId>] [--json]
+remits-cli corpus compare --corpus <name> --base <taskId> --head <taskId> [--json]              # per-case direction, metric deltas, expectedChanged
+remits-cli corpus consistency --corpus <name> --case <caseKey> [--json]                        # did the case produce the same metrics every run?
+remits-cli corpus retire --corpus <name> --case <caseKey> [--case ...] [--restore] [--json]    # drop a case from future runs; past measurements stay readable
+```
+
+A run labelled **`AI MOCKED`** replayed every AI turn from `aiMock`: it produces the same outcomes, scores and
+metrics a measured run would, so read that label before treating green as evidence. `compare` warns when base and
+head used different AI modes; `consistency` warns before calling a case unstable when its runs mixed modes.
+
+```bash
 remits-cli token [--path <embeddablePathOrId>] [--data-mode test|prod] [--as-account <ID>] [--variant-branch <name|none>]
 remits-cli token inspect --token <token|tokenKey|URL>                  # inspect token metadata, safety/dataMode evidence, and full context
 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
@@ -241,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,
@@ -254,10 +300,12 @@ remits-cli components status
 remits-cli verify start --summary "Hosted upload updates an existing profile" --manifest acceptance.json
 ```
 
-An active envelope is stored per command world: `baseUrl + accountId + branch + workspace + dataMode`.
-The legacy `./.remits-cli/verification/active` pointer is still understood for compatibility, but normal
-auto-attachment uses `./.remits-cli/verification/active-contexts.json`, so a localhost envelope does not
-silently capture evidence from a production command. Stage/test/token/tool/sync commands attach evidence
+An active envelope is stored per command world (`baseUrl + accountId + branch + workspace + dataMode`)
+inside the active local actor's mirror:
+`./.remits-cli/actors/<local-agent>/verification/active-contexts.json`. The legacy flat
+`./.remits-cli/verification/active` pointer is still understood for compatibility, but normal
+auto-attachment uses the actor-scoped context map, so one actor's localhost envelope does not silently
+capture another actor's production command. Stage/test/token/tool/sync commands attach evidence
 automatically while an envelope is active for that context. The explicit wrappers do the same thing and
 make the intent visible in terminal history:
 

package/skills/remits-cli/references/component-integrity.md

@@ -192,7 +192,8 @@ file is catastrophic.
 If sync reports unexpected `deleted` / `created` / `renamed`, uniqueness errors, or missing components — or you
 discover id drift — **stop. Do not re-run sync, do not `components commit`, and do not create replacement
 components to "make ids line up" or replace a deleted component.** Those actions compound the corruption.
-Preserve the repo-local session log and tool responses, and reconcile source-of-truth first.
+Run `remits-cli doctor local-state`, preserve the active actor's repo-local session log and tool
+responses, and reconcile source-of-truth first.
 
 **Safe recovery pattern (repo ↔ DB drift):**
 1. Establish DB truth: `mcp_account_view` for the full live inventory; `mcp_component_view` to confirm and read

package/skills/remits-cli/references/component-resolution.md

@@ -202,6 +202,13 @@ account, and the run still resolves whatever committed variant branch the accoun
 does **not** have the side effects of inventing a throwaway git branch per agent (which would make a
 commit write `ComponentVariant` overlays for a branch nobody subscribes to).
 
+Workspace is not the repo-local filesystem identity. The CLI also has a **local actor** namespace
+(`REMITS_AGENT_ID` or `--local-agent`) for `.remits-cli/actors/<local-agent>/` session logs, tool
+responses, verification mirrors, and diagnostics. Two agents that share one checkout should set distinct
+local actors even if they intentionally use the same or different staging workspaces. Run
+`remits-cli doctor local-state` to see the active actor, state directory, legacy flat state, and other
+actor directories.
+
 - `.remits-cli/workspace` is per-checkout and gitignored, so each clone keeps its own lane.
 - Precedence: `--workspace NAME` > `REMITS_WORKSPACE` > `.remits-cli/workspace` > shared default lane.
 - `--no-workspace` targets the shared lane for one command without clearing the file.

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

@@ -77,12 +77,32 @@ remits-cli verify start --summary "Hosted upload updates an existing profile" --
 ```
 
 The envelope records the account, host, data lane, branch, workspace, git heads, staging lane, and the
-acceptance manifest. It is mirrored locally under `.remits-cli/verification/<envelopeId>/` and becomes
-active for this checkout. While active, `components stage`, `components status`, `test run`, `token`,
+acceptance manifest. It is mirrored locally under
+`.remits-cli/actors/<local-agent>/verification/<envelopeId>/` and becomes active for this local actor and
+command world. While active, `components stage`, `components status`, `test run`, `token`,
 `token inspect`, `tool`, and `components sync` attach evidence packets automatically; pass
 `--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
@@ -345,10 +365,26 @@ remits-cli test run --test "Invoice Tests" --names "specific test case"
 remits-cli test status --task-id <TASK_ID>
 ```
 
-Tests run on the platform against your staged snapshot. They stream results in real-time. If they fail,
-read the printed pivots first: failed cases include timing, trace ids, bounded `report(...)`
-diagnostics, live HTTP signals, and resolved component provenance when available. Fix the code,
-re-stage, and re-run only after those pivots explain the failure.
+Tests run on the platform against your staged snapshot. They stream results in real-time. **Read the
+`World:` block printed before the run** — host, execution account, data lane, component world, staging lane
+id + content hash, platform sync vs local HEAD. If it is not the world you meant, stop: the result will be
+about a different world.
+
+If cases fail, read the printed summary and pivots first: each case has an `outcome`
+(`failed`, `error`, `budget_exceeded`, `provider_unavailable`, …) with its reason, timing, trace id, AI usage
+(live vs mocked, cost), bounded `report(...)` diagnostics, live HTTP signals, and resolved component
+provenance. Fix the code, re-stage, and re-run only after those pivots explain the failure.
+
+Every finished run is recorded durably: `remits-cli test status --task-id <id>` answers after the live status
+expires, `remits-cli test runs --test <name> --compare` compares the latest run with the previous one, and
+`remits-cli test compare --base <id> --head <id>` compares any two. For evaluation suites (a `corpus(name)` of
+cases seeded with `remits-cli corpus import`, one case per corpus case, intentional live AI inside
+`withAiBudget(...)`, measurements compared with `remits-cli corpus compare` / `corpus consistency`), read
+`guides/test-components.md` → *Evaluation Suites And Corpora*.
+Use `remits-cli corpus cases --corpus <name> --split dev --tag reviewed --key case-001` to inspect subsets;
+`split`, repeated/comma-separated tags, keys and `limit` are applied on the platform before rows are returned.
+For per-case AI totals, start and await the workflow inside that `test(...)` case; setup and late async calls are
+only visible in the persisted run-level AI history.
 
 Important test-runner constraints:
 - `remits-cli test run` now defaults to `test` dataMode unless you explicitly pass `--data-mode prod`.
@@ -553,6 +589,8 @@ The CLI now returns the post-sync branch SHA from the platform and verifies that
 subcommand help variants such as `remits-cli components commit --help` to discover behavior. Consult the `remits-cli` skill and its references,
 the CLI source, or `remits-cli components` documentation instead. If an exploratory or commit command behaves
 unexpectedly, stop and inspect the repo-local session log before running any mutating follow-up command.
+Use `remits-cli doctor local-state` first if you did not create the checkout; it names the active local
+actor and points at the actor-scoped session log/tool-response directories.
 
 **Git is required for durable sync.** The platform syncs by pulling from the git remote (`GitHubClient.syncFromRepository`). If `git push` fails, the server has nothing new to sync. You can still **stage** and **test** without git — only durable sync requires it.
 

package/skills/remits-cli/references/support-tickets.md

@@ -202,7 +202,9 @@ remits-cli verify start --ticket 22454 --summary "Fix hosted upload recovery"
 ```
 
 Keep it active while you stage, run Tests, mint browser tokens, call tools, and sync. Those commands
-attach evidence packets to the platform envelope and mirror them locally under `.remits-cli/verification/`.
+attach evidence packets to the platform envelope and mirror them locally under
+`.remits-cli/actors/<local-agent>/verification/`. Use `remits-cli doctor local-state` when handing off a
+checkout so the next agent can see which local actor owns the mirror.
 Before completing or handing off the ticket, run:
 
 ```bash

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

@@ -47,7 +47,9 @@
 remits-cli tool --name "mcp_firestore_search" --input '{"accountId": 37, "collection": "invoices"}' --data-mode prod
 ```
 
-Response saved to `./.remits-cli/tool-responses/<callId>.json`. Read the file to see results.
+Response saved to `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json`. Read the file to
+see results. Legacy flat `./.remits-cli/tool-responses/<callId>.json` files remain readable as fallback;
+`remits-cli doctor local-state` shows both locations.
 
 **"Tool call succeeded" means DISPATCHED, not that the tool did what you asked.** A tool that runs
 and refuses — an unmet precondition, a rejected enum value, a failed validation — returns HTTP 200
@@ -235,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.
 >
@@ -373,7 +376,9 @@ Front-stage references:
 | Parameter | Required | Description |
 |-----------|----------|-------------|
 | `action` | no | `search` (default), `detail`, or session control `pause`/`unpause`/`interrupt` |
-| `dataMode` | no | Explicit execution lane: `prod` or `test`. Response echoes `dataMode`, but persisted groupings do not have durable per-row lane flags. |
+| `dataMode` | no | Explicit execution lane: `prod` or `test`. Response echoes the lane THIS CALL ran in. A grouping's own lane is on each row as `lanes` (from the per-turn lane the platform records). |
+| `testTaskId` | no | Search mode: only groupings caused by this Test suite run (`taskId` from `remits-cli test run`) |
+| `lane` | no | Search mode: `test` or `prod` — the lane the grouping's AI turns ran in |
 | `search` | no | Broad text match against session IDs and grouping IDs |
 | `sessionId` | no | Session ID filter in search mode, or grouping/session key in detail mode |
 | `groupingId` | no | Grouping ID filter in search mode, or grouping key in detail mode |
@@ -393,6 +398,13 @@ Front-stage references:
 | `toolCallIds` | no | Detail mode: return the FULL exact input/result from `ai_tool_call` for these tool-call ids (what the tool PRODUCED — see the lens caveat) |
 | `consolidateContext` | no | When `true`, collapses repeated XML-like prompt context into a consolidated section |
 
+Spend: each search row carries `liveRequestCount`, `mockedRequestCount`, `lanes`, `testTaskId` and
+`estimatedCost`/`estimatedCostUsd` = **live spend only** (a mocked turn is never priced, even when it replays a
+recording with a cost). `pageTotals` sums the page. Turns recorded before the platform stored the mock flag are
+`unclassified` — unverified, not spend. A custom `range` with an unparseable `from`/`to`, or an unknown `range`,
+is refused rather than silently widened; the applied bounds are echoed as `filters.rangeStart`/`rangeEnd`.
+To audit one Test run: `{"action":"search","testTaskId":"<taskId>","pageSize":100}`.
+
 Audit flow: `action:"search"` to find the grouping → `action:"detail"` + `summaryOnly:true` for the MAP → re-call detail with `recordIds`/`toolCallIds` + `parts` to open exactly what you need. Prefer the map → open flow over a full-detail dump. Remember the two-lens rule: `tool_calls`/`toolCallIds` is what the tool PRODUCED; `conversation_messages`/`transcript` is what the AI CONSUMED (after any `_offload`/`_hideResult`/`_message`/supersede/evict transform).
 
 ### `mcp_run_action`
@@ -448,6 +460,16 @@ Returned fields on the async/event start: `actionRunId`, `status:"running"`, `ex
 `threadGroupingId`, `componentSource`, `componentSignature`, and (event mode) `eventId`/`eventStatus`. The
 `status` poll adds `result` on completion, or `message`/`error` on failure.
 
+Every response (describe, direct, async start, and failures) also states the world the run resolved:
+`executionAccountId`, `componentOwnerAccountId`, `componentSource` (`staged` / `variant` / `db`),
+`componentSignature`, `componentBranch`, `stagingLane`, `dataMode`, `workspace`, and `traceId`. Direct runs add
+`aiUsage` (live vs mocked calls and live cost for the run's trace).
+
+**A staged-only `new_` Action runs by name.** Its `actionId` is `null` and the response says why
+(`componentIdNote`) — that is valid, not "missing". When a name does not resolve, the error lists the accounts
+searched, the staging lane (branch + workspace) and the staged Actions it holds, the component branch, and the
+closest existing names; check that the lane named there is the one you staged into.
+
 > **In event mode the EVENT is the source of truth, not the promise.** `status` is driven by the Event's
 > own state; the value the dispatch call returned is reported separately as `dispatchResult` and is **not**
 > the Action's result. Read `eventStatus` for the outcome.

package/skills/remits-cli/references/troubleshooting.md

@@ -22,13 +22,13 @@
 | Stage shows 0 updated | No changes since last stage (hash dedup) |
 | Test runs old code after edit | You forgot to stage, or you are looking at DB while a staged entry is still active. Run `remits-cli components status`; then `remits-cli components stage` to update staged code or `remits-cli components clear` to fall back to DB. |
 | "Git credentials" or `git push` error | Git auth is required for commit (server pulls from git remote). Fix git authentication (SSH keys or HTTPS credentials) before retrying. Staging and testing still work without git. |
-| Need to learn command behavior | Read the `remits-cli` skill and its references, repo docs, or CLI source. Do not run unsupported mutating subcommand variants such as `remits-cli components commit --help`; if a command unexpectedly mutates or commits, stop and inspect the repo-local session log before doing anything else. |
+| Need to learn command behavior | Read the `remits-cli` skill and its references, repo docs, or CLI source. Do not run unsupported mutating subcommand variants such as `remits-cli components commit --help`; if a command unexpectedly mutates or commits, run `remits-cli doctor local-state` and inspect the active actor's repo-local session log before doing anything else. |
 | Sync response reports unexpected deletes, creates, renames, uniqueness errors, or component ID drift | Stop immediately. Do not rerun sync, do not create replacement components to paper over the mismatch, and do not promote more changes. Preserve session logs/tool responses, compare `account-info.json`, local filenames, live inventory, and git history, then prepare a repair/escalation summary. |
 | 500 / `Internal Server Error` from Remits | Stop normal task work. Capture the exact command, error, and response artifact, then escalate to a Remits system admin. Do not invent a workaround. |
-| Tool parameters rejected | Tool schemas may be cached. Run `remits-cli tools` to refresh `.remits-cli/tools/tools.json` with latest schemas. |
-| Tool response missing | Check `./.remits-cli/tool-responses/` |
+| Tool parameters rejected | Tool schemas may be cached. Run `remits-cli tools` to refresh `.remits-cli/shared/tools/tools.json` with latest schemas. |
+| Tool response missing | Run `remits-cli doctor local-state`, then check `./.remits-cli/actors/<local-agent>/tool-responses/` and any legacy flat `./.remits-cli/tool-responses/` fallback it reports. |
 | Long-running tool times out | For `mcp_run_action`/`mcp_run_agent`, use the tool's own `executionMode:"async"` and poll with a `controlAction:"status"` call (see `command-reference.md` → *Tool Execution Lifecycle*). For other long tools without their own async, use `remits-cli tool --async true` and poll `remits-cli tool status --call-id <callId>`. `--timeout-ms` only adjusts the per-request HTTP timeout; it is not a substitute for async. |
-| Need to continue tracking a long Action or Agent after terminal disconnect | Read `./.remits-cli/tool-responses/<callId>.json` for the returned `actionRunId`/`agentRunId`/`sessionId`/`threadGroupingId`. Re-poll the run with a `controlAction:"status"` call carrying that `actionRunId`/`agentRunId`, or inspect the agent session via `mcp_ai_session_search` with the `sessionId`. |
+| Need to continue tracking a long Action or Agent after terminal disconnect | Read `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json` for the returned `actionRunId`/`agentRunId`/`sessionId`/`threadGroupingId` (or the legacy flat fallback if `doctor local-state` reports it there). Re-poll the run with a `controlAction:"status"` call carrying that `actionRunId`/`agentRunId`, or inspect the agent session via `mcp_ai_session_search` with the `sessionId`. |
 | 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.md`. |
 | Need to know an account's shape (role, type, parents, namespace, branch, host/login routes) | 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`, `domainName`/`resolvedDomainName`, `authPath`/`targetPath`, `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. |
@@ -111,14 +111,16 @@ which is the source served to every account repo. Better guides over time are an
      - ticket ID if applicable
      - component names / IDs involved
    - Copies or references for the relevant supporting artifacts:
-     - `./.remits-cli/current-session.txt`
-     - the active repo session log from `./.remits-cli/sessions/`
-     - any `./.remits-cli/tool-responses/<callId>.json` files involved
+     - `remits-cli doctor local-state` output
+     - `./.remits-cli/actors/<local-agent>/current-session.txt`
+     - the active actor's repo session log from `./.remits-cli/actors/<local-agent>/sessions/`
+     - any `./.remits-cli/actors/<local-agent>/tool-responses/<callId>.json` files involved
+     - legacy flat `.remits-cli/` files only when `doctor local-state` says the relevant artifact is there
      - `~/.remits-cli/account-repos.json` if repo resolution may be relevant
      - `~/.remits-cli/activity.log` if service / websocket / agent-routing behavior may be relevant
 
 2. **Use the global Remits CLI state to make the bundle self-contained.**
-   - Read `./.remits-cli/current-session.txt` to identify the active repo session log.
+   - Run `remits-cli doctor local-state` to identify the active local actor and repo session log directory.
    - Record the exact repo directory and account context from `account-info.json`.
    - If repo selection or account targeting may be part of the issue, include the relevant entry from `~/.remits-cli/account-repos.json`.
    - If the problem involves support-ticket routing, agent registration, or websocket events, include the relevant lines from `~/.remits-cli/activity.log`.