@lexq/cli 2.1.1 → 3.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lexq/cli",
3
- "version": "2.1.1",
3
+ "version": "3.0.0",
4
4
  "mcpName": "io.lexq/lexq",
5
5
  "description": "The Decision Operations Platform for engineering teams",
6
6
  "type": "module",
@@ -46,6 +46,7 @@
46
46
  "test:fact-update": "pnpm build && node tests/fact-update.mjs",
47
47
  "test:rollback": "pnpm build && node tests/rollback.mjs",
48
48
  "test:dataset-upload": "pnpm build && node tests/dataset-upload.mjs",
49
+ "test:export-limit": "pnpm build && node tests/export-limit.mjs",
49
50
  "prepublishOnly": "pnpm build",
50
51
  "knip": "knip",
51
52
  "format": "prettier --write \"src/**/*.ts\"",
@@ -118,26 +118,15 @@ see it.
118
118
  lexq logs get --id <logId>
119
119
  ```
120
120
 
121
- Includes the original payload and error message. Use it to diagnose before marking the log.
121
+ Includes the original payload and error message. Use it to diagnose the failure.
122
122
 
123
- ### Mark a Log
123
+ ### Resolve or Ignore a Log
124
124
 
125
- There is no retry action — the engine does not re-execute a failed task on request. Fix the cause
126
- at the source (webhook endpoint, version state), then mark the log.
127
-
128
- ```bash
129
- lexq logs action --id <logId> --action RESOLVE # cause was fixed
130
- lexq logs action --id <logId> --action IGNORE # does not need fixing
131
- ```
132
-
133
- Both remove the log from `PENDING`; they differ only in recorded intent.
134
-
135
- ### Bulk Operations
136
-
137
- ```bash
138
- lexq logs bulk-action --ids "id1,id2,id3" --action RESOLVE
139
- lexq logs bulk-action --ids "id4,id5" --action IGNORE
140
- ```
125
+ The CLI can read failure logs but cannot resolve or ignore them. An organization admin does that in
126
+ the console: Management → Failure Logs (https://console.lexq.io/management/failure-logs). Resolving
127
+ and ignoring both remove the log from `PENDING`; they differ only in recorded intent. There is no
128
+ retry action either: the engine does not re-execute a failed task on request. Fix the cause at the
129
+ source (webhook endpoint, version state), then ask an admin to resolve the log.
141
130
 
142
131
  ## 3. Deployment Monitoring
143
132
 
@@ -278,9 +267,8 @@ lexq provenance get --trace-id <traceId>
278
267
  # 4. Check for system failures (covers 7 days back by default; add --start-date for older ones)
279
268
  lexq logs list --status PENDING --page 0 --size 10
280
269
 
281
- # 5. Inspect and mark
270
+ # 5. Inspect a failure. Once the cause is fixed, an admin resolves it in the console
282
271
  lexq logs get --id <logId>
283
- lexq logs action --id <logId> --action RESOLVE
284
272
 
285
273
  # 6. Verify deployment integrity
286
274
  lexq deploy overview
@@ -374,11 +374,13 @@ live but from a newer deployment. Start again from step 1.
374
374
 
375
375
  ## Recipe 7: Monitoring + Failure Triage
376
376
 
377
- **Goal:** Check for pending failures and clear the queue.
377
+ **Goal:** Check for pending failures and find their cause.
378
378
 
379
379
  Failure logs are a dead-letter record for background tasks — platform event webhooks and scheduled
380
380
  deployments. There is no retry action: the engine does not re-execute a failed task on request.
381
- Fix the cause at the source (webhook endpoint, version state), then mark the log.
381
+ Fix the cause at the source (webhook endpoint, version state). The CLI can read failure logs but
382
+ cannot resolve or ignore them: an organization admin does that in the console, under
383
+ Management → Failure Logs (https://console.lexq.io/management/failure-logs).
382
384
 
383
385
  ```bash
384
386
  # 1. List pending failures
@@ -387,22 +389,16 @@ lexq logs list --status PENDING --page 0 --size 50
387
389
  # 2. Inspect one to see the original payload and error
388
390
  lexq logs get --id <logId>
389
391
 
390
- # 3. Mark as resolved after fixing the cause externally
391
- lexq logs bulk-action --ids "id1,id2,id3" --action RESOLVE
392
-
393
- # 4. Mark as intentionally skipped (won't appear in PENDING again)
394
- lexq logs bulk-action --ids "id4,id5" --action IGNORE
395
-
396
- # 5. Verify clean state
392
+ # 3. After an admin resolves the logs in the console, check that none are still pending
397
393
  lexq logs list --status PENDING --page 0 --size 10
398
394
  ```
399
395
 
400
396
  Without `--start-date`, `logs list` covers 7 days back through today, in the organization time
401
- zone. An empty list in step 5 means there is no PENDING failure in that window, not that there is
402
- none at all. Add an earlier `--start-date` to steps 1 and 5 to see older ones.
397
+ zone. An empty list in step 3 means there is no PENDING failure in that window, not that there is
398
+ none at all. Add an earlier `--start-date` to steps 1 and 3 to see older ones.
403
399
 
404
- `RESOLVE` and `IGNORE` differ only in intent — both remove the log from PENDING. Use `RESOLVE`
405
- when the underlying problem was fixed, `IGNORE` when it does not need fixing.
400
+ Resolving and ignoring differ only in intent — both remove the log from PENDING. An admin resolves
401
+ a log when the underlying problem was fixed and ignores it when it does not need fixing.
406
402
 
407
403
  ---
408
404
 
@@ -99,7 +99,7 @@ Every command accepts these flags:
99
99
  | `history` | `list`, `get`, `stats` | Execution history |
100
100
  | `replay` | `decision`, `start`, `list`, `get`, `cancel` | Decision replay |
101
101
  | `provenance` | `get`, `reveal-audits` | Decision provenance + PII audit |
102
- | `logs` | `list`, `get`, `action`, `bulk-action` | Failure log management |
102
+ | `logs` | `list`, `get` | Failure logs (read-only) |
103
103
  | `webhook-subscriptions` | `list`, `get`, `save`, `delete`, `test` | Platform event webhooks |
104
104
  | `serve` | `--mcp` | MCP server over stdio |
105
105