@remits/remits-cli 0.1.133 → 0.1.136

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remits/remits-cli",
-  "version": "0.1.133",
+  "version": "0.1.136",
   "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
@@ -147,11 +162,18 @@ reference named after it.
   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
   cannot verify, say what you would need and ask. (`development-loop.md`)
-- **For concrete user workflows, start a verification envelope before you edit.** `remits-cli verify
-  start --summary "..."` records the account/source/lane tuple and a manifest when you have one.
-  Stage, test, token, tool, and sync commands attach evidence automatically while the envelope is
-  active; finish from `remits-cli verify report`, which separates verified claims from missing or stale
-  evidence. (`development-loop.md`, `component-resolution.md`)
+- **`remits-cli evidence` answers "what have I actually run, and in which world?"** Every stage, test,
+  token, tool and sync appends one world-stamped line automatically, per actor. Nothing to start,
+  nothing to satisfy. Read it before you re-run something, and quote it when you report what you
+  proved. (`development-loop.md`)
+- **Verification envelopes are OPTIONAL and exist for one job: a verdict someone else will rely on.**
+  Start one when a ticket, a human, or a handoff needs a checkable "these specific things are true" —
+  not as a routine step before editing. `remits-cli verify start --summary "..."` then
+  `remits-cli verify claim <id> --text "..." [--test "<suite>"]` names what must be true; add
+  `--claim <id>` to the command that proves it; `remits-cli verify report` gives the verdict. An
+  envelope with no claims is simply an evidence log, which is a complete state — not something to
+  chase. If you find yourself opening an envelope to answer a question about your own work, use
+  `remits-cli evidence` instead. (`development-loop.md`, `component-resolution.md`)
 - **Read the component's `.meta.yml` before changing behavior.** Sidecar descriptions can be dated
   decision records. Before changing a displayed value, helper, calculation, schema field, or prompt
   contract, check the sidecar and either preserve its decision or explicitly supersede it.
@@ -194,8 +216,9 @@ remits-cli tools                  # which tools this account actually has (tools
 ```
 
 plus the repo's `account-info.json` → `resolution` block for the account's shape.
-For a workflow-shaped request, also run `remits-cli verify start --summary "..."` once the target tuple
-is understood, then keep that envelope active through stage/test/token/sync.
+For a workflow-shaped request, rely on the automatic `remits-cli evidence` trail unless someone else needs
+a checkable verdict. Only then start `remits-cli verify start --summary "..."`, declare claims, and keep
+that envelope active through stage/test/token/sync.
 
 If any command returns 401, run `remits-cli auth` (with the same `--base-url` if you were targeting a
 non-default host).

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,22 +301,67 @@ 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,
-branch variants, subscriber/forked accounts, production-vs-test lane questions, support tickets, and
-multi-agent work. Start it after you know the target account/branch/workspace/data-mode tuple and before
-the first edit:
+**First, the thing you probably want instead.** `remits-cli evidence` prints what you have actually run
+and in which world, grouped by world, with no envelope and nothing to start:
+
+```bash
+remits-cli evidence            # this actor's trail
+remits-cli evidence --json     # structured, for your final report
+```
+
+Every stage, test, token, tool and sync appends to it automatically. Use it for "what have I already
+run?", "did that execute in the prod lane?" and "what do I put in my final message?".
+
+**Verification envelopes are optional, and exist for a verdict someone ELSE will rely on** — a support
+ticket, a human who asked you to prove specific things, a handoff another agent will act on. They are not
+a routine step before editing. An envelope you started for your own benefit is nearly always
+`remits-cli evidence` in disguise, and it costs you turns that prove nothing.
+
+When a verdict is genuinely wanted, start it after you know the target
+account/branch/workspace/data-mode tuple:
 
 ```bash
 remits-cli workspace use --auto
@@ -300,18 +369,48 @@ 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:
+**Name what must be true, or there is no verdict to reach.** An envelope with no `claims` and no
+`requiredEvidence` reports `evidence_only` — a world-stamped log. That is a complete, final state, not a
+partial one, and nothing about it is outstanding. When you DO want a verdict, a manifest file is one way to
+declare the contract; `verify claim` is the one-command way, and it works on a live envelope:
+
+```bash
+remits-cli verify claim market-filter --text "US market scoring excludes AU and GB statements"
+remits-cli verify claim pilot-green --text "the pilot suite passes" --test "Acquirer Pilot"
+```
+
+Prove a claim by naming it on the command that already proves it. `--claim <id>` is stamped onto the
+evidence packet every command sends, so it works on `verify test`, `token`, `tool`, `stage`, `sync` and
+`attach` alike, and takes a comma-separated list:
+
+```bash
+remits-cli verify test --test "Acquirer Pilot" --claim pilot-green
+remits-cli verify tool --name mcp_run_action --as-account 36 --claim market-filter
+remits-cli verify attach --claim market-filter --note "AU statements excluded and counted"
+```
+
+A claim with no shape is satisfied by any successful packet tagged with its id. A claim that names a
+`--test` suite (or `--packet-type`) must be proven by that shape. Re-declaring an id replaces it, so
+tightening a claim is also one command.
+
+**When an envelope with a contract will not close, read the report — do not start another one.** Several
+open envelopes for the same goal, or workspaces named `...-r7`/`-r8`/`-r9`, is the loop signature, and
+`activity inspect` reports both as smells. Close what you are not finishing: `verify supersede --envelope
+<old> --superseded-by <new>` or `verify abandon --envelope <old> --reason "false start"`.
+
+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
-remits-cli verify test --test "Adyen Import Recovery" --names "browser upload recovery"
+remits-cli verify test --test "Adyen Import Recovery" --names "browser upload recovery" --claim recovery
 remits-cli verify token --path /page/pricing-config --as-account 21 --data-mode test
 remits-cli verify sync --safe
 remits-cli verify report
@@ -372,12 +471,17 @@ 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,
-say that plainly instead of widening the claim. In particular, staged proof is not committed variant/trunk
-proof, a token is not browser proof, and a direct DOM or Alpine state mutation is not the same as a user
-action.
+the report lists it under `Verified`. If the report says `evidence_only`, no verdict was requested; if it
+says `partially_verified`, stale, or missing evidence, say that plainly instead of widening the claim. In
+particular, staged proof is not committed variant/trunk proof, a token is not browser proof, and a direct
+DOM or Alpine state mutation is not the same as a user action.
 
 Evidence from the wrong world is excluded before it can satisfy a requirement. When the manifest declares
 fields such as `repoAccountId`, `gitBranch`, `componentBranch`, `workspace`, or `dataMode`, the report names
@@ -419,6 +523,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 +599,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
@@ -190,9 +201,39 @@ runs resolve and what a sync writes. If `account-info.json` carries a `component
 variants of these components exist: editing an origin component will drift them, so check
 `remits-cli components branches` before changing shared code. See `branch-variants.md`.
 
-If the request names a journey or acceptance behavior, start the envelope here, after the target tuple is
-understood and before editing. A manifest can be lightweight JSON; the point is that the required
-evidence is durable before the proof is collected.
+**You do not need to start anything to have a record.** Every stage, test, token, tool and sync appends a
+world-stamped line to your actor's evidence trail automatically. Read it with:
+
+```bash
+remits-cli evidence
+```
+
+That is the right tool for "what have I already run?", "did that test actually execute in the prod lane?",
+and "what should I put in my final message?". It is per-actor, so agents sharing a checkout never read each
+other's trail.
+
+**Start a verification envelope only when someone else needs a verdict** — a support ticket, a human who
+asked you to prove specific things, or a handoff another agent will act on. It is not a routine step before
+editing, and an envelope you open for your own benefit is almost always `remits-cli evidence` in disguise.
+
+When you do want a verdict, name what must be true. One command, no manifest file:
+
+```bash
+remits-cli verify start --summary "Hosted upload updates an existing profile"
+remits-cli verify claim fees-balance --text "statement fee totals reconcile to source within five cents"
+remits-cli verify claim pilot-green --text "the pilot suite passes" --test "Acquirer Pilot"
+```
+
+Prove a claim by naming it on the command that already proves it — `--claim <id>` works on `verify
+test`, `token`, `tool`, `stage`, `sync` and `attach` alike:
+
+```bash
+remits-cli verify test --test "Acquirer Pilot" --claim pilot-green
+remits-cli verify attach --claim fees-balance --note "34025 reconciles at 0.02 variance"
+```
+
+An envelope with no claims reports `evidence_only`. That is a complete, final state — a log, not a
+half-finished exam. Nothing about it is outstanding.
 
 #### Step 2: Make the Change
 Edit component files under `components/`. This is local file editing — the platform doesn't know about your changes yet.
@@ -403,6 +444,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 +637,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