@remits/remits-cli 0.1.92 → 0.1.93

package/package.json

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

package/skills/remits-cli/SKILL.md

@@ -95,6 +95,7 @@ description: Use remits-cli for fast branch-scoped component staging, test execu
 - Line 2169: `mcp_run_agent`
 - Line 2205: `mcp_system_logs`
 - Line 2228: `mcp_performance_trace`
+- Line 2260: `mcp_event_diagnostics`
 - Line 2263: `mcp_component_view`
 - Line 2286: `mcp_component_grep`
 - Line 2299: `mcp_support_ticket`
@@ -1747,7 +1748,13 @@ Before starting an investigation outside the confirmed current repo:
 **Stuck / failed / recovered Event:**
 
 Do **not** open the Action source first. The platform records each attempt's delivery envelope (which
-queue delivered it, which delivery attempt this was, and how long it was ever allowed to run) and will classify the failure for you. From a Test or any component:
+queue delivered it, which delivery attempt this was, and how long it was ever allowed to run) and will classify the failure for you. From remits-cli / MCP, use `mcp_event_diagnostics` first:
+
+```bash
+remits-cli tool --name mcp_event_diagnostics --input '{"accountId":49,"eventId":18838}' --data-mode prod
+```
+
+From a Test or any component, the same platform classifier is available directly:
 
 ```groovy
 eventDiagnostics(18838)
@@ -1771,6 +1778,8 @@ Read `classification` before anything else:
 non-idempotent side effect may have run more than once — check for duplicate records before concluding
 the component "ran twice for no reason".
 
+`mcp_event_diagnostics` returns the same classification, `delivery.threadGroupingId`, and ready-to-run
+`pivots` for `mcp_performance_trace`, `mcp_system_logs`, `mcp_record_listing`, and `mcp_object_activity`.
 `delivery.threadGroupingId` is the same id everything else uses, so you can pivot straight into
 `mcp_performance_trace` (`action:"trace"`) or `mcp_system_logs` with it. `logQuery` in the response
 carries ready-made Cloud Logging filters, including the container-lifecycle and 504 queries.
@@ -1896,9 +1905,10 @@ account).
   tells you when the fields shown belong to a different account.
 - `action: 'account_update'` — write Account-schema configuration `fields`, and/or `name`/`status`
   (`ACTIVE`/`ON_HOLD`/`PENDING`).
-- `action: 'user_update'` — write User-schema `fields` under the named account (refused unless the user is a
-  member or you pass `addAccount: true`, because the write would otherwise land on another account), plus
-  `name`/`enabled` and membership add/remove.
+- `action: 'user_update'` — write User-schema `fields` under the named account, plus `name`/`enabled` and
+  membership add/remove. Refused unless the user is a member or you pass `addAccount: true`, because the
+  write would otherwise land on another account. If an email does not exist globally, `addAccount: true`
+  intentionally creates that user first, then binds them to the named account before writing fields.
 
 **Building an account hierarchy** (the structural writes — this is how a coding agent provisions accounts
 without a browser):
@@ -2339,6 +2349,38 @@ Reading rule: first use `slowest` to get candidate trace ids, then call `trace`
 unaccounted wall time is itself a finding: check cold compile, queueing, blocking I/O, or missing
 `measure(...)` instrumentation.
 
+### `mcp_event_diagnostics`
+Diagnose one Event's infrastructure outcome through the same `eventDiagnostics(eventId)` DSL described in
+`docs/guides/features/observability.md`. Use this before opening Action source when an Event is stuck,
+recovered, timed out, retried, or appears to have been killed.
+
+```bash
+remits-cli tool --name mcp_event_diagnostics --input '{"accountId":49,"eventId":18838}' --data-mode prod
+```
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `accountId` | yes | Tenant scope. The Event must belong to this account unless `includeChildren:true`. |
+| `eventId` / `id` | yes | Event primary key to diagnose. |
+| `includeChildren` | no | Allow the Event to belong to the requested account or one of its child accounts. Default: `false`. |
+
+Read `classification` first:
+
+- `APPLICATION_FAILURE` — the Action failed in application code; read `event.errorMessage`, correlated
+  alerts, and the producing component.
+- `ORPHANED_*` / `RECOVERED_*` — the attempt was abandoned; read `abandonmentCause`.
+- `REQUEST_TIMEOUT_LIKELY` means the work likely used its whole deadline, so split it into resumable batches.
+- `PROCESS_TERMINATED_LIKELY` means the worker likely disappeared before its deadline; inspect JVM/node
+  health and container lifecycle logs.
+- `UNKNOWN_NO_DEADLINE_EVIDENCE` means the platform refuses to guess; use the returned `logQuery` filters.
+- `AWAITING_DELIVERY` means the Event has not been claimed; check queue delivery and action-node health.
+- `IN_FLIGHT_HEALTHY` means the Event is still heartbeating; inspect trace/logs before interrupting.
+
+The response returns `threadGroupingId`, the full `result` map, `diagnosisHints`, and `pivots` containing
+ready-to-run inputs for `mcp_performance_trace`, `mcp_system_logs`, `mcp_record_listing`, and
+`mcp_object_activity` when those handles are present. For a performance question, open the returned
+`mcp_performance_trace` pivot next; for raw failure context, open logs and records by `threadGroupingId`.
+
 ### `mcp_component_view`
 Read component field content with line numbers.