@remits/remits-cli 0.1.133 → 0.1.135

package/package.json

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

package/skills/remits-cli/SKILL.md

@@ -72,11 +72,25 @@ reference named after it.
   nothing about what you are working on, and every one of those entries shadows committed source until
   it expires. Keep the full stage for a deliberate complete snapshot or a "what is stale here?" reset.
   (`development-loop.md`)
+- **`components commit` internally merge-stages for compile validation.** Its first phase uses changed-only
+  merge semantics so the server can compile the changed runtime source before git writes. That does not
+  reconcile or clean the lane, and its stage packet is not proof that the lane equals your workset. Use
+  `components stage --workset` for behavioral verification before landing. (`component-integrity.md`,
+  `component-resolution.md`)
 - **Give each agent its own lane: `remits-cli workspace use --auto`.** Without a workspace you are in
   the SHARED lane, where a full stage replaces what another agent is testing rather than merging with
   it. Each agent works in its own **clone**, never a same-branch worktree: worktrees share the branch
   ref, so one agent's pull moves `HEAD` under the others, and `components commit` refuses there.
-  (`component-resolution.md`)
+  A supervised `agent serve` ticket worker is the narrow exception: it may use a per-ticket worktree under
+  one ticket, one lease, one staging workspace and an explicit freshness check. (`component-resolution.md`,
+  `support-tickets.md`)
+- **Use the full vocabulary in reports and handoffs.** Say **git branch** / `branchName` for the
+  checkout and staging namespace, **staging lane** for the account+user+git branch+workspace Redis
+  overlay, **component branch** / `variantBranch` for durable `ComponentVariant` overlays, **data lane**
+  for test/prod records, and **source layer** for staged/variant/trunk. Do not collapse these to
+  "branch" or "verified"; say what was actually proven: Test pass, browser journey, corpus measurement,
+  sync mutation, or ticket lifecycle state. (`component-resolution.md`, `branch-variants.md`,
+  `development-loop.md`, `support-tickets.md`)
 - **Land only from trunk or a real variant branch.** A per-agent/feature branch (`components status` says
   `FEATURE BRANCH … [subscription-fallback]`) is safe to stage and run from — it resolves the same world
   as its target — but `components commit`/`sync` refuse it. Merge into the branch it resolves and land
@@ -87,10 +101,11 @@ reference named after it.
   behind trunk produces, because it still physically carries old copies of files nobody touched.
   (`component-integrity.md`, `branch-variants.md`)
 - **`stage` is always safe. `components commit` on trunk is the most dangerous command in the CLI.**
-  It is not a convenience wrapper: it `git add -A`, commits, pushes, and then reconciles the whole
-  pushed repo into the live component database — creating, updating, renaming, and **hard-deleting**
-  rows. Prefer the observable `git commit → git push → components sync → git pull`. On trunk it refuses
-  before any git write unless you pass `--yes`. (`component-integrity.md`)
+  It is not a convenience wrapper: it merge-stages/compile-validates changed source, then `git add -A`,
+  commits, pushes, and reconciles the whole pushed repo into the live component database — creating,
+  updating, renaming, and **hard-deleting** rows. Prefer the observable
+  `git commit → git push → components sync → git pull`. On trunk it refuses before any git write unless
+  you pass `--yes`. (`component-integrity.md`)
 - **After anyone lands, ask whether your lane is stale: `remits-cli components status`.** A landing clears
   only the lander's lane; yours keeps shadowing their new rows with content staged from the old base.
   `LANDED SINCE YOUR BASE` / `STALE OVERLAY` mean pull, re-stage, then verify — a pass against a stale

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

@@ -160,6 +160,40 @@ link carries what?"
 4. Check the resolved layer, not the source text: `testComponentSource`, or the `variant:<id>:<hash>`
    compile signature (`branch-variants.md` → *Diagnosing a variant*).
 
+### CLI tool account roles
+
+Generic `remits-cli tools` / `remits-cli tool` calls have three account roles. Keep them separate in
+commands and reports:
+
+- `--account-id` is the **repo/scope account**. It is the account whose checkout/context you are working
+  from and the ceiling for scoped discovery.
+- `--as-account` is the **execution account**. Use it when a tool should resolve components, branch
+  subscriptions and staging exactly as a reachable subscriber/client account.
+- `--target-account` / `--target-account-id` is the **data target**. Use it when a tool operates on records
+  in another account but should not change component resolution. It is delivered to the tool as
+  `input.accountId` and `input.targetAccountId` (an explicit `--input` value wins), because `input.accountId`
+  is the key the platform's account-targeting tools actually read.
+
+A target alone does not move the run. `--target-account 36` changes which records the tool touches;
+component resolution, the branch subscription and the staging lane still belong to `--account-id`. When the
+work should resolve as the other account — any subscriber or client account — pass `--as-account 36` as
+well. If that is refused, the account is not reachable downward from anything you hold; ask for access
+rather than reaching it through `input.accountId`, which no longer changes execution.
+
+Legacy `input.accountId` still reaches tools as their target input, but it no longer silently turns the
+whole CLI command into that account when a repo/scope account is present. The CLI says so on stderr and in
+`warnings[]` in the response, so `--json` callers see it too.
+
+The response `world` block is the truth: read `repoAccountId`, `executionAccountId`, `targetAccountId`,
+`componentOwnerAccountId`, `componentBranch`, `workspace`, and `dataMode` before attaching the result to a
+verification claim. `world.accountId` is the **execution** account — the same thing a verification manifest's
+`accountId` declares — while the account a command was addressed to is `repoAccountId`/`checkoutAccountId`.
+
+The `component world:` line names the branch AND why it applies (`via subscription`, `via
+branch-has-variants`, `via explicit`, `via subscription-fallback`). That reason comes from the platform, not
+from the CLI comparing two fields: an explicit `--variant-branch` probe REPLACES the subscription and a
+variant branch's working tree decides before any edge is read, even when all three name the same branch.
+
 ### The same block answers the non-branch questions
 
 - *"Why are this account's documents not where I expect?"* → compare `databaseName` vs

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

@@ -54,6 +54,10 @@ account, not from what you named your git branch:
 | **a variant branch** (it has committed variants, or an account subscribes to it — e.g. `forked`) | that branch | trunk + **that branch's** overlays | **`ComponentVariant` overlays on that branch only** — never touches trunk rows |
 | **any other branch** (`codex/x`, `feature/y`) | that branch | the **same world as trunk**: trunk + the account's subscribed branch (`forked` for its subscriber) | **refused** (`feature_branch_landing`) — merge into the branch it resolves and land from there |
 
+Use those names in handoffs: **git branch** for the checkout, **staging lane** for the temporary
+account/user/git branch/workspace overlay, and **component branch** for the durable variant world. A
+support ticket, component branch, and git branch can all be different at the same time.
+
 A branch like that is a **feature branch**, and it is safe to *run* from: stage only the components you edited,
 and runs still resolve every `forked` overlay for the subscriber. Do **not** stage untouched components to
 "restore" something reported missing — check `components status` first. It is never a place to *land* from.
@@ -139,9 +143,9 @@ and still names the owner, run the first repair sync with an explicit subscriber
   it. `--variant-branch none` (or `trunk`) forces production/subscription semantics without leaving the
   branch.
 
-Both work on `remits-cli test run` and `remits-cli token`; `--variant-branch` also works on
-`remits-cli tools` and `remits-cli tool`, so tests, browser URLs, tool discovery, and tool execution can
-all inspect the same committed variant world.
+Both work on `remits-cli test run`, `remits-cli token`, `remits-cli tools`, `remits-cli tool`, and
+`remits-cli corpus`, so tests, browser URLs, tool discovery, tool execution, and corpus operations can all
+inspect the same committed variant world.
 
 The strongest end-to-end proof for a UI-visible variant is a token, not a log line:
 
@@ -368,8 +372,9 @@ The analogous hazard is different, and you must still respect it:
   `writes` in `--summary`) for what this sync actually changes, and `storedCurrent: true` on an entry for
   an overlay that is already stored as-is. Existing overlay ids appear as `variantId`; an `unchanged` row with `pruned:true` means the
   branch has converged back to trunk and the overlay would be removed. It is rejected on trunk, and
-  `components commit --dry-run` is unsupported because `commit` performs compile validation and local git
-  writes before syncing.
+  `components commit --dry-run` is unsupported because `commit` first merge-stages changed source for
+  compile validation, then performs local git writes before syncing. That internal stage does not
+  reconcile the lane; use `components stage --workset` before behavioral verification.
 - **The sync refuses a wholesale removal.** Above roughly a third of a kind — or **100% of a kind at any
   size** — it aborts that kind, reports why, and points at a rebase. Rebasing is almost always the real
   fix. Only when the removals are genuinely deliberate, re-run with `--force-tombstones`.

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

@@ -59,7 +59,7 @@ Do not assume `--data-mode prod` implies the deployed prod host, or that `--data
 for quick investigation tools:
 
 ```bash
-remits-cli tool --name "mcp_account_view" --input '{"accountId": 37}' --data-mode prod
+remits-cli tool --account-id 21 --target-account 37 --name "mcp_account_view" --input '{"accountId": 37}' --data-mode prod
 ```
 
 **There are two independent async mechanisms — do not confuse or stack them:**
@@ -75,14 +75,16 @@ remits-cli tool --name "mcp_account_view" --input '{"accountId": 37}' --data-mod
    for long tools that do **not** have their own async mode. Its start response carries `callId`,
    `status:"running"`, `threadGroupingId`, `accountId`, `branchName`, and `dataMode` — but **not** any
    tool-specific ids, because the tool has not run yet; those arrive inside the `result` of the polled
-   completed status.
+   completed status. The start, status and completed responses all carry a `world` block naming the
+   repo/scope account, execution account, target account when any, data lane, branch/workspace, component
+   branch, staging lane and component source/signature when known.
 
 For `mcp_run_action` / `mcp_run_agent`, prefer mechanism (1) alone — it already makes the call non-blocking
 **and** returns the run ids up front. Pass your own `actionRunId`/`agentRunId` so you can poll it
 deterministically:
 
 ```bash
-remits-cli tool --name "mcp_run_action" --input '{"accountId":49,"actionId":200,"executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name "mcp_run_action" --input '{"actionId":200,"executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
 ```
 
 Every tool response is saved in full to
@@ -93,6 +95,26 @@ or offloaded. Legacy flat `./.remits-cli/tool-responses/<callId>.json` files rem
 platform's OpenRouter model loop, where the AI client may offload large tool results before feeding
 context back to the model.
 
+For cross-account workflows, keep the roles explicit:
+
+- `--account-id` is the repo/scope account that bounds discovery and selects the local verification context.
+- `--as-account` changes the execution account, so subscriber/component-branch resolution behaves as that
+  account.
+- `--target-account` / `--target-account-id` names the tool's data target without changing component
+  resolution. It is sent as `input.accountId` **and** `input.targetAccountId` when `--input` omits them,
+  because that is the key the platform's account-targeting tools read (`mcp_run_action` resolves
+  `input.accountId` and otherwise falls back to the run scope). A value already in `--input` wins.
+  Legacy `input.accountId` on its own is still accepted as a target, but the CLI warns — on stderr and as a
+  `warnings[]` entry in the response, so `--json` callers see it too — when it differs from the scope account
+  and neither explicit flag was supplied.
+
+**A target is not an execution account.** `--target-account` says which records the tool touches;
+`--as-account` says which account's components, branch subscription and staging lane resolve. When the work
+should run as the other account — the usual case for a subscriber or a client account — pass `--as-account`
+too. The response `world` block is the check: `repoAccountId` / `executionAccountId` / `targetAccountId` are
+three separate fields, and `world.accountId` is the EXECUTION account, matching what a verification manifest
+declares.
+
 ### Hierarchy-scoped tool reads
 
 For read/discovery tools, the account resolved from the checkout/session is the **scope root**, not proof
@@ -112,7 +134,8 @@ Available flags:
 | Flag | Meaning |
 |---|---|
 | `--scope self|children|hierarchy` | Expand from the repo/session account for read/discovery. Exact-id lookups usually default to `children`; broad searches default to `self` unless widened. |
-| `--target-account-id ID` | Exact owner/execution account when already known. Required by mutating tools. |
+| `--as-account ID` | Execute as this reachable account, so that account's subscription edge and component branch apply. |
+| `--target-account ID` / `--target-account-id ID` | Exact owner/data target when already known; sent as `input.accountId` + `input.targetAccountId` unless `--input` already sets them. Required by mutating tools that operate on one account; does not by itself change component resolution — add `--as-account` for that. |
 | `--account-ids 1,2,3` | Explicit bounded owner list. The platform verifies every id against the scope root. |
 | `--anchor-account-id ID` | Path-disambiguation anchor for multi-parent account relationships. |
 
@@ -174,7 +197,8 @@ remits-cli agent status [--state idle|working|paused] [--ticket ID] [--activity
 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 activity inspect [--account-id ID] [--scope self|children|related] [--workspace NAME] [--branch NAME] [--workstream ID] [--user-id ID|--user-email EMAIL] [--limit N] [--json]
+remits-cli workstream status [--workstream ID|--workspace NAME] [--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
@@ -235,8 +259,8 @@ head used different AI modes; `consistency` warns before calling a case unstable
 ```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 tools [--account-id <repoId>] [--as-account <executionId>] [--branch <name>] [--data-mode test|prod] [--variant-branch <name|none>]
+remits-cli tool --name <toolName> [--account-id <repoId>] [--as-account <executionId>] [--target-account <targetId>] [--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] [--data-mode test|prod]   # default: test
 remits-cli verify list [--max 50] [--json]
@@ -277,16 +301,47 @@ around in circles:
 
 ```bash
 remits-cli activity inspect --account-id 4 --scope children --data-mode test
+remits-cli activity inspect --account-id 21 --scope related --workspace remits-fee-test-t-001r-172690b-r9 --data-mode prod
 remits-cli activity inspect --account-id 4 --scope children --user-email jason@example.com --json
+remits-cli workstream status --workspace remits-fee-test-t-001r-172690b-r9
 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`
+shape for platform-level review. `--scope related` follows component owners, staging lanes and verification
+packet worlds out of the hierarchy — use it for split-world work where the repo account, component owner and
+execution/data target differ.
+
+**`--workspace`, `--branch` and `--workstream` NARROW `--scope related`.** With one of them the account set
+becomes this account, its component owners, and only the accounts carrying matching evidence — not the whole
+subtree — and the lanes, envelopes, test runs and corpus results are filtered to that workstream too. Without
+one, `related` returns the subtree plus owners, which on a platform account is hundreds of accounts and an
+arbitrary limit-bounded slice of their evidence. The response echoes what was applied as `filters`.
+
+A related account is included only when the caller can already act on it, it is a descendant of the selected
+account, or it is a component owner on that account's resolution path.
+`--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.
 
+`remits-cli workstream status` is the local half. It keeps actor directories isolated but groups recent tool
+response files, verification packets, call ids, envelope ids and world roles under one logical workstream id.
+The id defaults to the current workspace; override it with `--workstream <id>` or `REMITS_WORKSTREAM_ID`.
+
+The same id is stamped onto every verification packet world, so it joins the two halves:
+
+```bash
+remits-cli workstream status --workstream fee-immediate
+remits-cli activity inspect --scope related --workstream fee-immediate
+```
+
+A campaign that spans several worlds is reported as several worlds, never merged into one line: the world
+shown is the latest run's, with the distinct worlds listed beneath it.
+
+> This is not a support ticket's `--workstream`, which is an account's own routing label (matched by
+> `agent serve --serves`). Same flag name, unrelated namespaces.
+
 ### Verification envelopes
 
 Use a verification envelope for workflow-shaped work: concrete user journeys, browser-facing changes,
@@ -300,14 +355,15 @@ 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`)
-inside the active local actor's mirror:
+An active envelope is stored per command world (`baseUrl + accountId + git branch + workspace`)
+inside the active local actor's mirror; **data mode is deliberately not part of the active pointer key**:
 `./.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:
+capture another actor's production command. Stage/test/token/tool/sync commands run a server preflight
+against the envelope's manifest/start world before attaching, and that is where test/prod mismatches are
+refused or detached. The explicit wrappers do the same thing and make the intent visible in terminal
+history:
 
 ```bash
 remits-cli verify stage --workset
@@ -372,6 +428,11 @@ Common packet meanings:
 | `sync_mutation` | Durable source moved to trunk or variant and returned a sync SHA | The committed source behaves after staging is cleared |
 | `artifact` | A file/screenshot/note exists with path, size, and sha256 | The workflow consumed it |
 
+Packet meanings do not widen just because they are attached to the same envelope. In summaries, keep the
+proof noun: `passed` for a Test case, `measured` for corpus comparisons, `synced` for source movement,
+`complete` for ticket lifecycle, and `verified` only for claims listed under `Verified` by
+`remits-cli verify report`.
+
 Final claims should come from `remits-cli verify report`. Treat `Verified` as the acceptance boundary.
 `Additional evidence` is useful handoff context, but it does not satisfy a missing required packet unless
 the report lists it under `Verified`. If the report says `partially_verified`, stale, or missing evidence,
@@ -419,6 +480,9 @@ For tests specifically:
   nested `sync` (summary with `--summary`), and on failure `error` + `nextStep`. It stops at the first
   failed phase. `phase: "sync"` with `pushed: true` means the remote holds work the platform has not
   reconciled — follow `nextStep`; do not re-run `components commit`.
+- The `stage` phase of `components commit` is changed-source compile validation. It merge-stages the
+  changed runtime source and intentionally leaves unrelated staged entries in the lane, so it is not a
+  substitute for `components stage --workset` when a clean workset lane is part of the proof.
 - `components commit` on trunk refuses before staging, committing, or pushing unless `--yes` is present —
   with or without `--safe`. Trunk has no dry-run plan, so nothing can preview the full repo-to-DB reconcile.
 - `components commit` refuses before any git write while its branch is checked out in another worktree
@@ -492,6 +556,10 @@ For tests specifically:
 shrink a lane inherited from an earlier full stage; the command warns when it retains entries that way.
 `--changed-only --replace-lane` is the explicit spelling of `--workset`.
 
+`components commit` uses merge semantics only for its internal compile-validation stage. That packet says
+the changed source compiled in the current overlay; it does not say the lane was reconciled or that
+retained entries stopped shadowing committed source.
+
 An empty workset never clears a lane: `--workset` on a clean tree stages nothing and leaves the lane as
 it is. `--empty-workset clear` opts into the clear; `components clear --all` is the direct way.
 

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

@@ -43,6 +43,12 @@ than replacing it: a payload that only carries `source` inherits `path`, `object
 from the layer below. A staged edit made on a variant branch therefore layers over **that variant**, not
 over trunk.
 
+Vocabulary matters because all three layers also carry branch-shaped fields. `branchName` is the git
+branch / staging namespace. `componentBranch` or `variantBranch` is the committed `ComponentVariant`
+overlay an account resolves. A **staging lane** is account + CLI user + git branch + workspace in Redis.
+When writing a report, name the source layer and the branch kind explicitly; "the branch was verified"
+does not tell the next agent what ran.
+
 Plus the compile cache:
 
 - **Compiled-closure cache (`BaseClosureDomain.CLOSURE_CACHE`).** An in-memory, **per-JVM-instance** Guava
@@ -209,6 +215,11 @@ local actors even if they intentionally use the same or different staging worksp
 `remits-cli doctor local-state` to see the active actor, state directory, legacy flat state, and other
 actor directories.
 
+A local **workstream id** groups one logical proof campaign across those isolated actor directories without
+flattening them. It defaults to the current workspace. Override it with `--workstream <id>` or
+`REMITS_WORKSTREAM_ID` when several actors are collecting evidence for one task, then inspect the local
+index with `remits-cli workstream status`.
+
 - `.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.
@@ -260,6 +271,11 @@ them, so the overlay IS the workset. That is the mode to iterate in.
 other staged entry alone. So it can never shrink a lane inherited from an earlier full snapshot — the
 overlay stays at 115 while you work on seven. The command warns when entries are retained that way.
 
+`components commit` uses that same merge shape for its internal compile-validation stage before git
+writes. Treat it as "compile the changed source in the current overlay", not "make the overlay equal my
+workset". If lane cleanliness is part of the proof, run `components stage --workset` and verify before
+the commit/sync path.
+
 Every count is `unknown` rather than `0` when it cannot be established. "git could not answer" and "git
 says nothing changed" are different facts and only one of them is a number.
 

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

@@ -84,6 +84,11 @@ 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.
 
+When one human task spans several local actors, keep actor isolation but give the task one workstream id:
+`--workstream <id>` or `REMITS_WORKSTREAM_ID`. It defaults to the current workspace, and
+`remits-cli workstream status` shows the local response files, packet ids, actors and account roles for that
+campaign without copying large payloads.
+
 `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.
@@ -117,6 +122,12 @@ remits-cli verify report
 The report is the final-response source. It separates verified claims, missing evidence, stale packets,
 and the source/account/lane tuple, so do not replace it with a generic "verified" sentence.
 
+Use proof-level words precisely in the final response and on tickets. A passing Test is Test proof in
+the recorded world, a token is URL/resolution proof, a browser step is user-journey proof, a corpus
+comparison is measurement proof, a sync packet is durable source movement, and a ticket `complete` is
+lifecycle state. Only `verify report` decides which of those packets satisfy the manifest's `Verified`
+section.
+
 For Test requirements, be specific enough for the evaluator to know what a pass means:
 
 ```json
@@ -403,6 +414,10 @@ If no relevant Test component exists yet, consider creating one. Test components
 
 New test files use the `new_` prefix (e.g., `new_MyTest.groovy`) and no `id:` in the sidecar — see "Creating a component that does not exist yet" in Step 2. Run them **by name** (`remits-cli test run --test "My Test"`) until a sync assigns an id and renames the file.
 
+A `remits-cli corpus import` packet is fixture ingestion, not a measurement and not acceptance. Corpus
+evidence begins when an evaluation Test actually runs those cases and records measurements; the report
+still has to say whether the run used live AI, mocked AI, or a declared `withAiBudget(...)`.
+
 **How to write the Test itself is not a CLI concern** — what a suite can assert, how mocks behave across HTTP/relay boundaries, driving an embeddable in-process, and the front-stage-only rule all live in `guides/test-components.md`. Read that before authoring a suite.
 
 **Option B — Visual verification with Playwright** (for UI changes or when the user wants to "see it"):
@@ -592,6 +607,11 @@ unexpectedly, stop and inspect the repo-local session log before running any mut
 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.
 
+Its first phase internally stages changed runtime source with merge semantics for compile validation. That
+is useful validation evidence, but it deliberately does not reconcile the lane or prove the overlay equals
+your workset. Keep behavioral verification on the explicit loop: `components stage --workset`, then
+`test run` or browser proof, then land.
+
 **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.
 
 **Landing is serial, and the platform now enforces it.** `components commit` takes a short exclusive

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

@@ -176,6 +176,27 @@ Before starting an investigation outside the confirmed current repo:
 4. Confirm whether you are in `CLIENT`, `PLATFORM`, or `PRODUCT` context
 5. Then continue with the investigation flow below
 
+For generic tool/action probes in a split-world workstream, keep the account roles explicit. From a forked or
+subscriber repo, use `--account-id <repo/scope>` for the checkout account, `--as-account <execution>` when
+component resolution should run as a client/subscriber, and `--target-account <target>` for the account whose
+records the tool operates on. Then read the printed `World:` block and saved response file; it names the
+repo/scope account, execution account, target account, component owner, branch/workspace, data lane,
+component branch, staging lane and source signature when known.
+
+Use `activity inspect --scope related` when evidence spans accounts that are not in one hierarchy branch.
+Always pass `--workspace`, `--branch` or `--workstream` with it: those NARROW the view to the accounts and
+evidence carrying that workstream, and without one, `related` returns the whole subtree plus component owners
+with an arbitrary limit-bounded slice of their evidence. The response echoes the applied `filters`.
+
+`workstream status --workspace <workspace>` reviews the local actor-scoped files that belong to one proof
+campaign. The workstream id is stamped onto every verification packet world, so the same id works on both
+sides:
+
+```bash
+remits-cli workstream status --workstream <id>
+remits-cli activity inspect --scope related --workstream <id>
+```
+
 **Document-First** (most common — user reports a data issue):
 1. `mcp_account_view` — understand the account's schemas and components.
 2. `mcp_firestore_search` — find the document, capture its `object_id`.

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

@@ -274,8 +274,10 @@ Four things are worth knowing and are not obvious:
 - **A spawned local ticket worker owns its checkout grounding and already has its staging lane.** For
   repository work, `remits-cli agent serve` appends the local repository checkout, target branch and a
   suggested per-ticket worktree path. Before editing, create or choose an isolated worktree appropriate to
-  the ticket. For a ticket with no component branch subscription, the target branch is the repository
-  default before it is the launch checkout's current branch. The supervisor sets
+  the ticket. This is the supervised ticket-worker exception to the ordinary "one independent agent, one
+  clone" rule: the worker has one ticket, one edit lease, one target branch, and one freshness check. For
+  a ticket with no component branch subscription, the target branch is the repository default before it is
+  the launch checkout's current branch. The supervisor sets
   `REMITS_WORKSPACE=ticket-<id>` for you; if you choose a detached worktree, export
   `REMITS_GIT_BRANCH=<branch>` before running `remits-cli`. A worktree is a checkout-isolation tool, not
   a freshness proof: fetch, fast-forward and prove `HEAD...origin/<branch>` is `0  0` before the first
@@ -405,6 +407,11 @@ remits-cli ticket create --account-id 49 --subject "Vendor name lost on re-norma
 `--reference-id` makes it get-or-create, so a re-run — or another worker reaching the same conclusion
 — reconciles onto the same ticket instead of filing a duplicate.
 
+`ticket complete` is lifecycle closure, not evidence by itself. If a ticket changed component behavior,
+the resolution should cite the proof level that backs it: the `verify report` id, Test run id, browser
+journey, corpus comparison, sync SHA, or the reason verification is intentionally missing. A completed
+ticket can still be reopened when later evidence shows the claimed behavior was not proved.
+
 Marking and evidence, so the next reader does not repeat your work:
 
 ```bash

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

@@ -72,8 +72,8 @@ For long-running Action/Agent runners, use the tool's own async mode (`execution
 the `actionRunId`/`agentRunId` (and, for agents, `sessionId`) immediately:
 
 ```bash
-remits-cli tool --name "mcp_run_action" --input '{"accountId":37,"actionName":"Rebuild Invoice","executionMode":"async","actionInput":{"invoiceId":"abc"}}' --data-mode prod
-# poll by run id:  {"controlAction":"status","accountId":37,"actionRunId":"<actionRunId>"}
+remits-cli tool --account-id 21 --as-account 37 --target-account 37 --name mcp_run_action --input '{"actionName":"Rebuild Invoice","executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"invoiceId":"abc"}}' --data-mode prod
+# poll by run id:  --account-id 21 --as-account 37 --target-account 37 --input '{"controlAction":"status","actionRunId":"my-stable-run-id"}'
 ```
 
 For long tools that lack their own async mode, use the CLI transport async (`--async true`), optionally with
@@ -81,13 +81,24 @@ For long tools that lack their own async mode, use the CLI transport async (`--a
 (see `command-reference.md` → *Tool Execution Lifecycle*). Use `--timeout-ms <ms>` only to adjust the per-request client timeout; it is
 not a replacement for async mode on multi-minute workflows.
 
-**Account-id precedence for tool calls.** When the CLI and the tool input both carry an account id, the server resolves them in this order:
+**Account roles for tool calls.** Keep the repo/scope account separate from the account whose data/runtime the
+tool exercises:
 
-1. Explicit `--account-id <ID>` flag — always wins. Use this when you want to be certain the tool runs against a specific account (and the user's session covers it).
-2. `input.accountId` (or `input.account_id`) — the tool's per-call execution target.
-3. The current repo's `account-info.json` / active session — the default fallback.
+1. `--account-id <ID>` is the repo/scope account that bounds discovery and verification.
+2. `--as-account <ID>` is the execution account, matching `test run --as-account`.
+3. `--target-account <ID>` is the tool/data target when the tool operates on a specific account but should not
+   change component resolution. It is sent as `input.accountId` and `input.targetAccountId` when `--input`
+   omits them — `input.accountId` is the key `mcp_run_action` and friends actually read, and without it they
+   fall back to the run scope.
 
-So from inside a parent account's repo you can target a child account just by setting `input.accountId`, or force it with `--account-id` if you need it to override whatever the tool input says. Verify with the `accountId` field in the response envelope.
+A target does not move the run: pass `--as-account` too whenever the work should resolve as that account's
+components, branch subscription and staging lane.
+
+Legacy `input.accountId` (or `input.account_id`) is still accepted as an explicit target for older snippets,
+but prefer flags for new work; the CLI warns on stderr and in `warnings[]` when it is used alone. The
+response `world` block is the source of truth: check `repoAccountId`, `executionAccountId`,
+`targetAccountId`, `componentBranch`, `workspace`, and `dataMode`. `world.accountId` is the execution
+account.
 
 ### `mcp_account_view`
 Returns complete account structure — schemas, components, relationships.
@@ -414,7 +425,7 @@ staged-vs-DB provenance in the result.
 Describe the Action first when the input shape is not obvious. This does not execute the Action:
 
 ```bash
-remits-cli tool --name mcp_run_action --input '{"controlAction":"describe","accountId":743,"actionId":25,"includeInputSchema":true}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --input '{"controlAction":"describe","actionId":25,"includeInputSchema":true}' --data-mode prod
 ```
 
 The describe response reports `hasInputSchema`, optional `inputSchema`, `inferredInputKeys`, and component
@@ -423,7 +434,7 @@ provenance. If `hasInputSchema:false`, treat `inferredInputKeys` as a best-effor
 Use direct mode only for quick Actions:
 
 ```bash
-remits-cli tool --name mcp_run_action --input '{"accountId":49,"actionId":200,"executionMode":"direct","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --input '{"actionId":200,"executionMode":"direct","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
 ```
 
 Use the tool's own async mode for long-running Action execution — it returns immediately with an
@@ -432,14 +443,14 @@ of the start response. Do **not** also pass the CLI `--async` flag; that only bu
 transport layer:
 
 ```bash
-remits-cli tool --name mcp_run_action --input '{"accountId":49,"actionId":200,"executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --input '{"actionId":200,"executionMode":"async","actionRunId":"my-stable-run-id","actionInput":{"sourceDocumentId":"..."}}' --data-mode prod
 ```
 
 Then poll that run with another **regular tool call** carrying `controlAction:"status"` and the same
-`accountId` + `actionRunId`:
+explicit account flags + `actionRunId`:
 
 ```bash
-remits-cli tool --name mcp_run_action --input '{"controlAction":"status","accountId":49,"actionRunId":"my-stable-run-id"}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --input '{"controlAction":"status","actionRunId":"my-stable-run-id"}' --data-mode prod
 ```
 
 > This poll is a normal `remits-cli tool --name mcp_run_action` call — **not** `remits-cli tool status`,
@@ -448,12 +459,17 @@ remits-cli tool --name mcp_run_action --input '{"controlAction":"status","accoun
 > If you started the run with a different `userId`, include that same `userId` in the poll (the run's status
 > is keyed by account + user + `actionRunId`; it otherwise defaults to the current user).
 
+`input.accountId` is still accepted by older tool implementations and legacy snippets, but it is no longer
+the recommended way to describe cross-account work. Prefer `--account-id` for the repo/scope account and
+`--as-account`/`--target-account` for the Action's execution/data account so verification packets and
+`activity inspect --scope related` can report the split world without guessing.
+
 For job-style Actions only (`Action.job == true`), prefer `executionMode:"event"` when you want the durable
 Event lifecycle, Event status, and platform recovery behavior. Event mode is inherently async; poll it the
 same way (`controlAction:"status"` + `actionRunId`) — the status resolves the backing Event's terminal state:
 
 ```bash
-remits-cli tool --name mcp_run_action --input '{"accountId":49,"actionId":200,"executionMode":"event","actionRunId":"my-stable-run-id","actionInput":{}}' --data-mode prod
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --input '{"actionId":200,"executionMode":"event","actionRunId":"my-stable-run-id","actionInput":{}}' --data-mode prod
 ```
 
 Returned fields on the async/event start: `actionRunId`, `status:"running"`, `executionMode`,
@@ -482,10 +498,10 @@ turns up a run that is consuming resources and should not finish — the case th
 
 ```bash
 # the usual path: you found the event in mcp_record_listing / mcp_object_activity
-remits-cli tool --name mcp_run_action --data-mode prod --input '{"controlAction":"interrupt","accountId":49,"eventId":19102,"reason":"runaway extraction, 45min"}'
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --data-mode prod --input '{"controlAction":"interrupt","eventId":19102,"reason":"runaway extraction, 45min"}'
 
 # or stop a run you started yourself (executionMode:'event' only)
-remits-cli tool --name mcp_run_action --data-mode prod --input '{"controlAction":"interrupt","accountId":4,"actionRunId":"my-run-id"}'
+remits-cli tool --account-id 21 --as-account 49 --target-account 49 --name mcp_run_action --data-mode prod --input '{"controlAction":"interrupt","actionRunId":"my-run-id"}'
 ```
 
 Aliases `cancel` / `stop` / `kill` all work. What you need to know before using it: