@dura-run/cli 0.1.5 → 0.2.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": "@dura-run/cli",
3
- "version": "0.1.5",
3
+ "version": "0.2.0",
4
4
  "description": "CLI for the dura.run managed automation platform",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -9,6 +9,7 @@
9
9
  },
10
10
  "files": [
11
11
  "dist/dura.js",
12
+ "skills/",
12
13
  "README.md",
13
14
  "LICENSE"
14
15
  ],
@@ -43,8 +44,12 @@
43
44
  "typecheck": "tsc --noEmit",
44
45
  "test": "vitest run"
45
46
  },
47
+ "dependencies": {
48
+ "tsx": "^4.21.0"
49
+ },
46
50
  "devDependencies": {
47
51
  "@dura/shared": "workspace:*",
48
- "commander": "^14.0.3"
52
+ "commander": "^14.0.3",
53
+ "esbuild": "^0.28.0"
49
54
  }
50
55
  }
@@ -0,0 +1,360 @@
1
+ # Dura.run — Debugging Guide
2
+
3
+ > This skill teaches an AI agent how to trigger automations, read logs, run diagnostics, replay executions, and use snapshot tests for debugging and quality assurance.
4
+
5
+ ## Triggering Automations
6
+
7
+ ### `dura run <name>` — Manual Trigger
8
+
9
+ Manually trigger any automation in your project:
10
+
11
+ ```bash
12
+ # Trigger the "hello" automation
13
+ dura run hello --project proj_abc123
14
+
15
+ # Trigger with a JSON payload
16
+ dura run process-webhook --project proj_abc123 \
17
+ --payload '{"event": "user.created", "userId": "u_456"}'
18
+ ```
19
+
20
+ **Output:**
21
+
22
+ ```
23
+ executionId exec_abc123
24
+ status completed
25
+ duration 142ms
26
+ ```
27
+
28
+ This is useful for:
29
+ - Testing automations without waiting for their trigger
30
+ - Debugging failed cron jobs by re-running them manually
31
+ - Running one-off automations with `{ "type": "manual" }` triggers
32
+
33
+ ## Reading Logs
34
+
35
+ ### `dura logs` — View Execution Logs
36
+
37
+ ```bash
38
+ # List recent executions
39
+ dura logs --project proj_abc123
40
+
41
+ # View logs for a specific execution
42
+ dura logs exec_abc123 --project proj_abc123
43
+
44
+ # Filter by log level
45
+ dura logs --project proj_abc123 --filter 'level=error'
46
+
47
+ # Filter by automation name
48
+ dura logs --project proj_abc123 --filter 'automation=sync-users'
49
+
50
+ # Text search in log messages
51
+ dura logs --project proj_abc123 --filter 'text=payment'
52
+
53
+ # Structured field query
54
+ dura logs --project proj_abc123 --filter 'field.orderId=ord_789'
55
+
56
+ # Logs from the last hour
57
+ dura logs --project proj_abc123 --last 1h
58
+
59
+ # Logs from the last 7 days
60
+ dura logs --project proj_abc123 --last 7d
61
+ ```
62
+
63
+ ### `dura logs -f` — Live Tail
64
+
65
+ Stream logs in real time:
66
+
67
+ ```bash
68
+ # Tail all logs
69
+ dura logs --project proj_abc123 -f
70
+
71
+ # Tail only errors
72
+ dura logs --project proj_abc123 -f --filter 'level=error'
73
+
74
+ # Tail a specific automation
75
+ dura logs --project proj_abc123 -f --filter 'automation=process-webhook'
76
+ ```
77
+
78
+ Live tail uses WebSocket to stream log entries as they happen. Press `Ctrl+C` to stop.
79
+
80
+ ### Understanding Log Entries
81
+
82
+ Each log entry includes:
83
+
84
+ | Field | Description |
85
+ |-------|-------------|
86
+ | `timestamp` | When the log was emitted |
87
+ | `level` | `debug`, `info`, `warn`, or `error` |
88
+ | `message` | The log message string |
89
+ | `data` | Optional structured metadata (from `dura.log.info("msg", data)`) |
90
+ | `executionId` | Which execution produced this log |
91
+ | `automationName` | Which automation was running |
92
+
93
+ ### Writing Effective Logs
94
+
95
+ Structure your logs for easy debugging:
96
+
97
+ ```typescript
98
+ // Bad — hard to search and filter
99
+ dura.log.info("done");
100
+
101
+ // Good — descriptive message with structured data
102
+ dura.log.info("User sync completed", {
103
+ syncedCount: 42,
104
+ failedCount: 3,
105
+ durationMs: 1523,
106
+ source: "salesforce",
107
+ });
108
+ ```
109
+
110
+ Use log levels consistently:
111
+
112
+ - **debug** — Detailed diagnostic info (hidden by default in production)
113
+ - **info** — Normal operational events (request handled, job completed)
114
+ - **warn** — Something unexpected but recoverable (retry triggered, rate limit approaching)
115
+ - **error** — Something failed and needs attention (API call failed, validation error)
116
+
117
+ ## AI-Powered Diagnostics
118
+
119
+ ### `dura diagnose` — Root Cause Analysis
120
+
121
+ When an execution fails, `dura diagnose` uses AI to analyze the failure, identify the root cause, and suggest a fix:
122
+
123
+ ```bash
124
+ # Diagnose a specific execution
125
+ dura diagnose exec_abc123 --project proj_abc123
126
+
127
+ # Diagnose the most recent failure
128
+ dura diagnose --latest --project proj_abc123
129
+
130
+ # Include a wider lookback window for pattern detection
131
+ dura diagnose exec_abc123 --project proj_abc123 --lookback 48h
132
+
133
+ # Force regeneration (ignore cached diagnosis)
134
+ dura diagnose exec_abc123 --project proj_abc123 --force
135
+ ```
136
+
137
+ **Output:**
138
+
139
+ ```
140
+ Root Cause: External API timeout (87% confidence)
141
+
142
+ The handler at routes/sync-users.ts timed out waiting for a response from
143
+ https://api.salesforce.com/v2/users. The API returned HTTP 504 after 10.2s,
144
+ exceeding the automation's 10s timeout.
145
+
146
+ Evidence:
147
+ • [log:14] dura.fetch("https://api.salesforce.com/v2/users") started at T+0.1s
148
+ • [log:15] No response received before timeout at T+10.0s
149
+ • [metric] p99 latency for this API endpoint: 8.7s (last 24h)
150
+
151
+ Suggested Fix:
152
+ Increase the automation timeout and add a retry with exponential backoff.
153
+ File: dura.json
154
+ - "timeout": 10000
155
+ + "timeout": 30000
156
+
157
+ Related: exec_abc121, exec_abc119 (same error)
158
+
159
+ Prevention: Add circuit breaker logic for the Salesforce API call.
160
+ ```
161
+
162
+ ### Diagnosis Options
163
+
164
+ | Flag | Description | Default |
165
+ |------|-------------|---------|
166
+ | `--project <id>` | Project ID (required) | — |
167
+ | `--latest` | Diagnose the most recent failed execution | — |
168
+ | `--lookback <duration>` | Window for finding related failures (`24h`, `7d`) | `24h` |
169
+ | `--force` | Regenerate diagnosis even if cached | `false` |
170
+
171
+ ## Replaying Executions
172
+
173
+ ### `dura replay <execution-id>` — Replay an Execution
174
+
175
+ Re-run a past execution with its original inputs:
176
+
177
+ ```bash
178
+ # Replay with original inputs
179
+ dura replay exec_abc123 --project proj_abc123
180
+
181
+ # Replay with a modified body
182
+ dura replay exec_abc123 --project proj_abc123 \
183
+ --body '{"event": "user.updated", "userId": "u_456"}'
184
+
185
+ # Dry run — show payload without executing
186
+ dura replay exec_abc123 --project proj_abc123 --dry-run
187
+ ```
188
+
189
+ **Use cases:**
190
+ - Retry a failed execution after fixing a bug
191
+ - Test a fix by replaying the exact input that caused a failure
192
+ - Compare behavior between deployments
193
+
194
+ ### `dura replays <execution-id>` — List Replays
195
+
196
+ View all replays of a specific execution:
197
+
198
+ ```bash
199
+ dura replays exec_abc123 --project proj_abc123
200
+ ```
201
+
202
+ ## Snapshot Testing
203
+
204
+ ### `dura test --snapshots` — Snapshot Tests
205
+
206
+ Snapshot tests record automation responses and compare future runs against the stored snapshots:
207
+
208
+ ```bash
209
+ # Run snapshot tests
210
+ dura test --snapshots
211
+
212
+ # Update snapshots to match current output
213
+ dura test --update-snapshots
214
+ ```
215
+
216
+ ### How Snapshot Tests Work
217
+
218
+ 1. **First run** — Executes each automation with test inputs and saves the response to `__snapshots__/*.snap.json`
219
+ 2. **Subsequent runs** — Executes again and compares the response to the stored snapshot
220
+ 3. **Mismatch** — If the response differs, the test fails and shows a diff
221
+ 4. **Update** — Use `--update-snapshots` to accept new output as the expected baseline
222
+
223
+ ### Snapshot File Location
224
+
225
+ ```
226
+ my-project/
227
+ ├── routes/
228
+ │ ├── hello.ts
229
+ │ └── __snapshots__/
230
+ │ └── hello.snap.json
231
+ ├── jobs/
232
+ │ ├── cleanup.ts
233
+ │ └── __snapshots__/
234
+ │ └── cleanup.snap.json
235
+ ```
236
+
237
+ ## Running Tests
238
+
239
+ ### `dura test` — Full Test Suite
240
+
241
+ ```bash
242
+ # Run all tests
243
+ dura test
244
+
245
+ # Run tests in a specific directory
246
+ dura test --dir ./my-project
247
+
248
+ # Run with snapshot mode
249
+ dura test --snapshots
250
+
251
+ # Update snapshots
252
+ dura test --update-snapshots
253
+ ```
254
+
255
+ ### What `dura test` Does
256
+
257
+ 1. Sets `DURA_ENV=test` and `NODE_ENV=test`
258
+ 2. Loads `.env.local` secrets
259
+ 3. Discovers test files matching `*.test.{ts,js}` or `*.spec.{ts,js}`
260
+ 4. Spawns the test runner (vitest by default)
261
+
262
+ ### Writing Tests for Automations
263
+
264
+ Create test files adjacent to your handlers:
265
+
266
+ ```typescript
267
+ // routes/hello.test.ts
268
+ import { describe, it, expect } from "vitest";
269
+
270
+ // Import your handler directly
271
+ import handler from "./hello";
272
+
273
+ describe("hello handler", () => {
274
+ it("returns a greeting", async () => {
275
+ const response = await handler({
276
+ method: "GET",
277
+ path: "/hello",
278
+ headers: {},
279
+ query: {},
280
+ body: null,
281
+ });
282
+
283
+ expect(response.status).toBe(200);
284
+ expect(response.body).toEqual({ message: "Hello from Dura!" });
285
+ });
286
+ });
287
+ ```
288
+
289
+ ## Debugging Workflow — Step by Step
290
+
291
+ When an automation fails, follow this workflow:
292
+
293
+ ### 1. Check Recent Logs
294
+
295
+ ```bash
296
+ dura logs --project proj_abc123 --filter 'level=error' --last 1h
297
+ ```
298
+
299
+ ### 2. Find the Failed Execution
300
+
301
+ ```bash
302
+ dura logs --project proj_abc123 --filter 'level=error'
303
+ # Note the execution ID from the output
304
+ ```
305
+
306
+ ### 3. View Full Execution Logs
307
+
308
+ ```bash
309
+ dura logs exec_abc123 --project proj_abc123
310
+ ```
311
+
312
+ ### 4. Run AI Diagnosis
313
+
314
+ ```bash
315
+ dura diagnose exec_abc123 --project proj_abc123
316
+ ```
317
+
318
+ ### 5. Fix and Replay
319
+
320
+ After fixing the bug:
321
+
322
+ ```bash
323
+ # Replay the failed execution to verify the fix
324
+ dura replay exec_abc123 --project proj_abc123
325
+
326
+ # Or redeploy and test
327
+ dura deploy --project proj_abc123 --env staging
328
+ dura run my-automation --project proj_abc123
329
+ ```
330
+
331
+ ### 6. Add a Test
332
+
333
+ Write a test that reproduces the failure to prevent regressions:
334
+
335
+ ```typescript
336
+ // routes/my-automation.test.ts
337
+ it("handles empty payload gracefully", async () => {
338
+ const response = await handler({
339
+ method: "POST",
340
+ path: "/webhook",
341
+ headers: {},
342
+ query: {},
343
+ body: {}, // The input that caused the failure
344
+ });
345
+
346
+ expect(response.status).toBe(400);
347
+ expect(response.body).toHaveProperty("error");
348
+ });
349
+ ```
350
+
351
+ ## JSON Output Mode
352
+
353
+ All debugging commands support `--json` for machine-readable output:
354
+
355
+ ```bash
356
+ dura run hello --project proj_abc123 --json
357
+ dura logs --project proj_abc123 --json
358
+ dura diagnose --latest --project proj_abc123 --json
359
+ dura replay exec_abc123 --project proj_abc123 --json
360
+ ```
@@ -0,0 +1,272 @@
1
+ # Dura.run — Deployment Guide
2
+
3
+ > This skill teaches an AI agent how to deploy automations, manage deployments, handle rollbacks, and configure multi-environment workflows.
4
+
5
+ ## Deploying Your Project
6
+
7
+ ### `dura deploy` — Bundle and Deploy
8
+
9
+ The deploy command handles the full pipeline: bundle, upload, validate, activate.
10
+
11
+ ```bash
12
+ # Deploy to the default environment (production)
13
+ dura deploy --project proj_abc123
14
+
15
+ # Deploy to a specific environment
16
+ dura deploy --project proj_abc123 --env staging
17
+
18
+ # Deploy from a specific directory
19
+ dura deploy --project proj_abc123 --dir ./my-project
20
+ ```
21
+
22
+ **What happens during deploy:**
23
+
24
+ 1. **Bundle** — All automation entrypoints are bundled into a single archive
25
+ 2. **Upload** — The bundle is uploaded to Dura's object storage via presigned URL
26
+ 3. **Validate** — The control plane validates the manifest and bundle integrity
27
+ 4. **Activate** — If validation passes, the new deployment becomes `active`
28
+
29
+ **Output:**
30
+
31
+ ```
32
+ Bundling project...
33
+ Bundle created: 42381 bytes
34
+ Requesting upload URL...
35
+ Deployment dep_xyz789 created
36
+ Uploading bundle...
37
+ Validating and activating...
38
+ deploymentId dep_xyz789
39
+ status active
40
+ activatedAt 2026-04-05T14:30:00.000Z
41
+ bundleSize 42381
42
+ automations 3
43
+ ```
44
+
45
+ ### Deploy Options
46
+
47
+ | Flag | Description | Default |
48
+ |------|-------------|---------|
49
+ | `--project <id>` | Project ID (required) | — |
50
+ | `--env <name>` | Target environment | `production` |
51
+ | `--dir <path>` | Project directory | `.` (current dir) |
52
+ | `--api-url <url>` | API base URL | From config |
53
+ | `--token <token>` | Auth token | From config |
54
+
55
+ ### Authentication Requirement
56
+
57
+ You must be logged in before deploying:
58
+
59
+ ```bash
60
+ # Login first
61
+ dura login
62
+
63
+ # Or use an API key
64
+ dura login --api-key dura_k_your_key_here
65
+ ```
66
+
67
+ ## Managing Deployments
68
+
69
+ ### `dura deployments list` — View Deployment History
70
+
71
+ ```bash
72
+ dura deployments list --project proj_abc123
73
+ ```
74
+
75
+ **Output:**
76
+
77
+ ```
78
+ ID STATUS CREATED
79
+ dep_xyz789 active 2026-04-05T14:30:00Z
80
+ dep_xyz788 superseded 2026-04-04T10:15:00Z
81
+ dep_xyz787 superseded 2026-04-03T09:00:00Z
82
+ dep_xyz786 failed 2026-04-02T16:45:00Z
83
+ ```
84
+
85
+ ### `dura deployments get` — Deployment Details
86
+
87
+ ```bash
88
+ dura deployments get --id dep_xyz789 --project proj_abc123
89
+ ```
90
+
91
+ Shows detailed information about a specific deployment including status, bundle size, validation results, and activation timestamp.
92
+
93
+ ### `dura rollback` — Revert to a Previous Deployment
94
+
95
+ ```bash
96
+ # Rollback to the previous deployment (auto-selected)
97
+ dura rollback --project proj_abc123
98
+
99
+ # Rollback to a specific deployment
100
+ dura rollback --project proj_abc123 --to dep_xyz787
101
+ ```
102
+
103
+ This deactivates the current deployment and reactivates the target. The current deployment's status becomes `rolled_back`.
104
+
105
+ ## Environment Management
106
+
107
+ ### `dura env create <name>` — Create an Environment
108
+
109
+ ```bash
110
+ # Create a staging environment
111
+ dura env create staging --project proj_abc123 --type staging
112
+
113
+ # Create with options
114
+ dura env create preview-pr-42 \
115
+ --project proj_abc123 \
116
+ --type preview \
117
+ --inherit-secrets staging \
118
+ --auto-deploy
119
+ ```
120
+
121
+ ### `dura env list` — List Environments
122
+
123
+ ```bash
124
+ dura env list --project proj_abc123
125
+ ```
126
+
127
+ **Output:**
128
+
129
+ ```
130
+ NAME TYPE SLUG AUTO-DEPLOY
131
+ production production production false
132
+ staging staging staging true
133
+ preview-42 preview preview-42 true
134
+ ```
135
+
136
+ ### `dura env delete <name>` — Delete an Environment
137
+
138
+ ```bash
139
+ # Requires --confirm for safety
140
+ dura env delete preview-42 --project proj_abc123 --confirm
141
+ ```
142
+
143
+ ### `dura env diff <env1> <env2>` — Compare Environments
144
+
145
+ ```bash
146
+ dura env diff staging production --project proj_abc123
147
+ ```
148
+
149
+ Shows differences in deployed version, secrets, and configuration between two environments.
150
+
151
+ ## Promoting Between Environments
152
+
153
+ ### `dura promote <source> <target>` — Promote a Deployment
154
+
155
+ ```bash
156
+ # Promote staging deployment to production
157
+ dura promote staging production --project proj_abc123
158
+
159
+ # This deploys the currently active deployment from staging
160
+ # into the production environment
161
+ ```
162
+
163
+ The promote command is a safe way to move a tested deployment from one environment to another without re-building.
164
+
165
+ ## Canary Deployments
166
+
167
+ ### `dura canary status` — Check Canary Progress
168
+
169
+ ```bash
170
+ dura canary status --project proj_abc123
171
+ ```
172
+
173
+ Shows the active canary deployment progress including traffic split percentage, error rates, and health checks.
174
+
175
+ ### `dura canary complete` — Complete a Canary
176
+
177
+ ```bash
178
+ dura canary complete --project proj_abc123
179
+ ```
180
+
181
+ Shifts 100% of traffic to the canary version and marks it as the active deployment.
182
+
183
+ ### `dura canary rollback` — Rollback a Canary
184
+
185
+ ```bash
186
+ # Requires --confirm
187
+ dura canary rollback --project proj_abc123 --confirm
188
+ ```
189
+
190
+ Reverts traffic to the previous deployment and cancels the canary.
191
+
192
+ ## Secrets Management
193
+
194
+ ### `dura secrets set` — Set a Secret
195
+
196
+ ```bash
197
+ # Set a secret for the default environment
198
+ dura secrets set DATABASE_URL "postgres://..." --project proj_abc123
199
+
200
+ # Set for a specific environment
201
+ dura secrets set API_KEY "sk_live_..." --project proj_abc123 --env production
202
+ ```
203
+
204
+ ### `dura secrets list` — List Secret Names
205
+
206
+ ```bash
207
+ dura secrets list --project proj_abc123
208
+ ```
209
+
210
+ Lists secret names (not values) for the project.
211
+
212
+ ### `dura secrets remove` — Remove a Secret
213
+
214
+ ```bash
215
+ dura secrets remove OLD_API_KEY --project proj_abc123 --confirm
216
+ ```
217
+
218
+ ## Deployment Workflow — Step by Step
219
+
220
+ Here is the recommended workflow for deploying a Dura project:
221
+
222
+ ### 1. Develop and Test Locally
223
+
224
+ ```bash
225
+ dura dev # Start local dev server
226
+ curl http://localhost:3000/hello # Test your handlers
227
+ dura test # Run the test suite
228
+ ```
229
+
230
+ ### 2. Deploy to Staging
231
+
232
+ ```bash
233
+ dura deploy --project proj_abc123 --env staging
234
+ ```
235
+
236
+ ### 3. Verify in Staging
237
+
238
+ ```bash
239
+ dura logs --project proj_abc123 --filter 'level=error'
240
+ dura run hello --project proj_abc123 # Manual trigger test
241
+ ```
242
+
243
+ ### 4. Promote to Production
244
+
245
+ ```bash
246
+ dura promote staging production --project proj_abc123
247
+ ```
248
+
249
+ ### 5. Monitor
250
+
251
+ ```bash
252
+ dura logs --project proj_abc123 -f # Live tail logs
253
+ dura status --project proj_abc123 # Check health
254
+ ```
255
+
256
+ ### 6. Rollback If Needed
257
+
258
+ ```bash
259
+ dura rollback --project proj_abc123
260
+ ```
261
+
262
+ ## JSON Output Mode
263
+
264
+ All deployment commands support `--json` for machine-readable output:
265
+
266
+ ```bash
267
+ dura deploy --project proj_abc123 --json
268
+ dura deployments list --project proj_abc123 --json
269
+ dura rollback --project proj_abc123 --json
270
+ ```
271
+
272
+ JSON output wraps responses in `{ "status": "success", "data": {...} }` or `{ "status": "error", "code": "...", "message": "..." }`.