@remits/remits-cli 0.1.146 → 0.1.149

package/package.json

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

package/skills/remits-cli/SKILL.md

@@ -83,7 +83,8 @@ reference named after it.
   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.
   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`,
+  one ticket, one lease, one staging workspace and an explicit freshness check. Prune finished worktrees
+  safely with `remits-cli agent prune-worktrees`. (`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
@@ -216,7 +217,10 @@ reference named after it.
   proof that a code change works. And never copy live customer data into another account's test
   collection to get realistic verification. (`development-loop.md`)
 - **`remits-cli agent serve` is the whole answer to "work support tickets".** No flags, no setup, no need
-  to be in an account repo. `agent register` makes the session routable and starts nothing.
+  to be in an account repo. Pass `--role <role>` (e.g. `developer`, `triage`, `release_manager`) to declare
+  what kind of agent the session is; the account's `remits-policy` rules match it, and it is fixed until
+  the session is released. `agent register` makes the session
+  routable and starts nothing. Use `remits-cli agent prune-worktrees` to clean up finished ticket worktrees.
   (`support-tickets.md`)
 - **`remits-cli ticket` is the platform's own ticket surface** and works on every Remits platform.
   `mcp_support_ticket` is one System Account's convention and refuses tickets it does not own.

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

@@ -231,6 +231,7 @@ remits-cli ticket participant --ticket ID --email E [--role watcher|requester|ag
 remits-cli ticket field --ticket ID --key K --value V  # the ORGANIZATION's own field, outside the planning slots
 remits-cli ticket reclaim [--ticket ID | --account-id ID] [--stale-hours 24] [--apply]   # OPERATOR: take back an agent's abandoned ticket
 remits-cli ticket queue --account-id ID [--status ...] [--unrouted] [--unassigned] [--awaiting-response] [--min-runs N] [--workstream W] [--board-stage S] [--planned-in P] [--search "..."] [--sort-by ...] [--json]
+remits-cli ticket queue --all-accounts [--account-ids 4,11] [--status ...] [--inactive-days N|--updated-before YYYY-MM-DD] [--limit N] [--json]  # operator sweep across indexed account repos; de-dupes overlapping child queues
 remits-cli ticket create --account-id ID --subject "..." --type defect|question|task|incident|enhancement [--priority P] [--description "..."] [--tags a,b] [--workstream W] [--affected-component C] [--implementation-account-id ID] [--reference-id KEY]
 remits-cli start [--foreground true] [--port 8787]
 remits-cli stop
@@ -245,7 +246,7 @@ remits-cli components status [--branch <name>] [--component-type <type>] [--comp
 remits-cli components lanes [--json]                         # every indexed staging lane on the account
 remits-cli components entries --lane-id <id> [--json|--verbose]  # authoritative staged files for one lane
 remits-cli components clear [--branch <name>] [--component-type <type>] [--component-id <id>] [--all] [--json|--verbose]   # id alone scopes to one component when unambiguous (ids are type-local; add --component-type if the same id is staged in multiple families); no filter clears the whole branch scope; --all forces the full wipe
-remits-cli components sync [--safe [--yes]] [--branch <name>] [--data-mode test|prod] [--force-tombstones] [--dry-run] [--create-variant-branch] [--summary] [--changed-only [--changed-since <ref>]]   # gated; on trunk = full repo->DB reconcile, on a variant branch = ComponentVariant overlays only
+remits-cli components sync [--safe [--yes]] [--branch <name>] [--data-mode test|prod] [--force-tombstones] [--dry-run] [--create-variant-branch] [--summary] [--changed-only [--changed-since <ref>]] [--timeout-ms <ms>]   # gated; on trunk = full repo->DB reconcile, on a variant branch = ComponentVariant overlays only
 remits-cli components sync doctor [--branch <name>] [--json]     # read-only: local/remote/platform sync facts, staging shadow risk, promotion freshness, recommended next action
 remits-cli components commit [--yes] [--safe] [--allow-shared-branch] [--create-variant-branch] [--message|-m "msg"] [--data-mode test|prod] [--force-tombstones] [--json [--summary]]   # phase 1 merge-stages + compile-validates changed source (never reconciles the lane); on TRUNK refuses before any git write unless --yes; --safe gates variant sync writes
 remits-cli components branches [--json]                                # branches carrying committed variants, with counts + drift
@@ -580,6 +581,8 @@ For tests specifically:
 - `--summary` on `components sync` prints compact counts plus named updated (with the fields that
   changed), renamed, skipped, removal/tombstone, error, and gate details instead of the full payload. A
   trunk sync reports an untouched component under `unchanged`, not `updated`.
+- `--timeout-ms` on `components sync` controls the per-request HTTP timeout for every sync request,
+  including `--safe` status/preflight and the durable sync write.
 - `components sync doctor` does not mutate. Use it when a sync timed out, status/promotion disagree, or
   you need to know whether staged entries would shadow committed-variant verification. It prints local
   `HEAD`, `origin/<branch>`, platform last-sync SHA, overlay freshness, repository mismatch, and a

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

@@ -17,6 +17,8 @@
   - [Before you edit anything: where you are, and whether you may](#before-you-edit-anything-where-you-are-and-whether-you-may)
   - [Your account's process is binding, and it is already in your brief](#your-accounts-process-is-binding-and-it-is-already-in-your-brief)
   - [Some of that process is enforced, not requested](#some-of-that-process-is-enforced-not-requested)
+  - [Roles and who may launch them](#roles-and-who-may-launch-them)
+  - [Cleaning up ticket worktrees](#cleaning-up-ticket-worktrees)
   - [Verification envelopes on tickets](#verification-envelopes-on-tickets)
   - [Seeing the queue as a human does](#seeing-the-queue-as-a-human-does)
   - [Agent components are workers too](#agent-components-are-workers-too)
@@ -81,13 +83,18 @@ and it expires on its own so a killed worker cannot park a ticket forever. You d
 
 ```bash
 remits-cli agent serve                          # workers are whichever agent THIS session is
-remits-cli agent serve --worker-agent codex --max-concurrent 2
-remits-cli agent serve --mode investigate       # read-only workers: no file edits
+remits-cli agent serve --role developer --worker-agent codex --max-concurrent 2
+remits-cli agent serve --role triage --mode investigate       # read-only workers: no file edits
 remits-cli agent serve --serves support,sdlc    # only these workstreams are routed here
 remits-cli agent workers                        # what is running right now
+remits-cli agent prune-worktrees                # safely clean up finished ticket worktrees
 remits-cli agent release                        # stop serving, go offline
 ```
 
+`--role` (and optionally `--persona`) declares what kind of agent this session is — opaque names the
+account's `remits-policy` rules match. It is fixed for the life of the session; see
+[Roles and who may launch them](#roles-and-who-may-launch-them).
+
 `--mode investigate` is still autonomous ticket work. The supervisor claims a ticket, launches a
 worker, and the worker should read/reproduce/localize the issue and update the ticket with useful
 findings or a handoff. What it must **not** do is become the repository editor: investigation-mode
@@ -325,12 +332,44 @@ discouraged.
   absence of an agent run identity, which your commands always carry. Record what you found with
   `ticket progress` and hand off.
 - **`[warn]` rules let the call through and write a `policy` worklog entry.** Mention it in your handoff.
+- **Rules can name your role** (`"when":{"role":"triage"}`, or `"role":{"not":["release_manager"]}` for
+  "only release managers"). Your role is the one your session registered with; you cannot change it from a
+  worker, and passing one on a call does nothing. A refusal naming your role means hand off to the role that
+  may.
 - **If you see "POLICY NOT ENFORCED"**, the account's rules could not be parsed. Do not read the absence
   of a refusal as permission — say so on the ticket. It is a defect in the account's `OPERATIONS` prompt.
 
 The same rules govern `components stage` and `components commit`. A `no-commit` rule is why
 `remits-cli components commit` refuses rather than asks.
 
+### Roles and who may launch them
+
+```bash
+remits-cli agent serve --role developer --serves sdlc
+remits-cli agent serve --role triage --mode investigate --serves support
+```
+
+The role is checked when the session registers against the person's own limits — `allowedAgentRoles`,
+`allowAutonomousAgents`, `allowedWorkstreams`, `maxAgentConcurrent` on their user record or home account —
+and re-checked on every supervisor poll. A refusal names the limit and what to pass instead (a
+workstream-restricted person must name `--serves`). To change role, `agent release` and start again.
+
+Every entry you write records the person you act for (`createdBy`) and your session (`agent`: id, run id,
+role), and your brief shows earlier entries the same way — so you can tell which run established what.
+
+### Cleaning up ticket worktrees
+
+```bash
+remits-cli agent prune-worktrees                 # every indexed account repo on this machine
+remits-cli agent prune-worktrees --dry-run       # preview
+remits-cli agent prune-worktrees --account-id 52 # one account's checkouts
+remits-cli agent prune-worktrees --force         # also remove worktrees with uncommitted changes
+```
+
+It keeps a worktree whose ticket still has a running worker, one with uncommitted changes (unless
+`--force`), one git cannot report on, and — always — one holding commits no branch or remote has. Push those
+or give them a branch first.
+
 ### Seeing the queue as a human does
 
 `remits-cli start` opens a browser control center showing the same facts you are acting on: which
@@ -391,11 +430,17 @@ ticket.
 remits-cli ticket queue --account-id 49                       # triage order, most urgent first
 remits-cli ticket queue --account-id 49 --unrouted --status open
 remits-cli ticket queue --account-id 49 --search "firestore index"
+remits-cli ticket queue --all-accounts --inactive-days 45     # stale cleanup candidates across indexed repos
 ```
 
 The `repo` column is the account the **edit lease** excludes on, so it also tells you which of these
 could be worked at the same time and which will serialize behind one another.
 
+For operator cleanup, prefer `--all-accounts` over hand-looping account ids. It scans indexed account
+repos with descendants included, de-dupes child queues that are already covered by a parent/root queue,
+and reports per-account read failures in `--json` so one inaccessible account does not hide the rest of
+the queue.
+
 Found a second, unrelated problem while working yours? **File it rather than widening the ticket you
 were given** — a ticket that describes two things cannot be closed by either fix.
 

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

@@ -216,10 +216,12 @@ test-lane Firestore fields moved.
 - `action: 'reparent'` — move the account's **primary** edge (and `Account.parentId`) to `parentAccountId`.
 
 > **The namespace guard.** An account's storage namespace resolves as
-> `databaseName ?: platform.code ?: code`, and `Account.setName` **regenerates `code`** — so renaming an
-> account whose namespace falls through to its own code silently repoints its storage. Any write that would
-> move the resolved namespace is **refused** unless you pass `confirmSegmentChange: true`, and the refusal
-> names both namespaces. To rename without moving storage, pin `code` to the old value in the same call.
+> `databaseName ?: platform.code ?: code`. `code` is derived from the name once, at creation (with `_2`,
+> `_3`, … appended when it is taken), and **never changes on a rename** — so renaming is always safe. Any
+> write that WOULD move the resolved namespace — an own `databaseName` set or cleared, a `type` change into
+> or out of `PLATFORM`, an explicit `code` change, an edge `databaseName` — is **refused** unless you pass
+> `confirmSegmentChange: true`, and the refusal names both namespaces. An explicit `code` another account
+> holds is refused, never adjusted.
 >
 > Because the namespace follows the **path** (see *Account Structure* in `platform-overview.md`), an
 > `edge_update` that sets `databaseName` repoints storage for **everything below that edge**, and the