@hasna/loops 0.3.54 → 0.3.55

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/README.md CHANGED
@@ -236,6 +236,11 @@ loops workflows recover <workflow-run-id>
236
236
  loops create workflow repo-morning-loop --workflow repo-morning --cron "0 8 * * *"
237
237
  ```
238
238
 
239
+ Use `recover` only for interrupted `running` workflow runs whose recorded child
240
+ process is gone. Terminal `timed_out` task/event workflow runs are audit
241
+ history; requeue them through the original task/event route after fixing the
242
+ cause.
243
+
239
244
  Workflow specs are stored separately from loops. A loop can schedule a workflow, but workflow runs and step runs have their own durable rows and events. Steps run in dependency order and a scheduled workflow run is idempotent per loop slot.
240
245
 
241
246
  For command steps, `command` is the executable when `shell` is not true. Put flags in `args`:
@@ -302,6 +307,30 @@ Custom reusable workflow templates live under the OpenLoops app data directory:
302
307
  showing, and rendering templates never executes workflow steps or mutates the
303
308
  registry.
304
309
 
310
+ Timeout policy is explicit. Deterministic command/check steps should normally
311
+ keep finite `timeoutMs`/`idleTimeoutMs` guards so broken shell work cannot run
312
+ forever. Agentic work steps default to no timeout in built-in worker/verifier
313
+ and task-lifecycle templates; use `timeoutMs: null` in workflow JSON, or
314
+ `--timeout none` / `--timeout unlimited` for CLI-created targets, when a step
315
+ may need hours or days. Use a positive numeric `timeoutMs` only when an agentic
316
+ step is intentionally bounded.
317
+
318
+ To migrate existing workflow loops, do not edit `workflow_specs.steps_json`
319
+ directly because historical workflow runs must keep pointing at their original
320
+ spec. Use the append-only migrator:
321
+
322
+ ```bash
323
+ loops workflows migrate-agent-timeouts --loop <loop-id-or-name>
324
+ loops workflows migrate-agent-timeouts --loop <loop-id-or-name> --apply
325
+ ```
326
+
327
+ The command dry-runs by default. With `--apply`, it creates a new workflow spec
328
+ with the requested agent timeout policy, retargets only future executions of
329
+ eligible non-running workflow loops, and leaves terminal timed-out workflow runs
330
+ as audit history. Use `loops workflows recover` only for interrupted `running`
331
+ workflow runs whose recorded child process is gone; terminal `timed_out` runs
332
+ must be requeued by re-delivering or draining the original task/event route.
333
+
305
334
  ```json
306
335
  {
307
336
  "id": "custom-report",
@@ -310,8 +339,7 @@ registry.
310
339
  "kind": "workflow",
311
340
  "variables": [
312
341
  { "name": "objective", "required": true, "description": "Report objective." },
313
- { "name": "projectPath", "required": true, "description": "Working directory." },
314
- { "name": "timeoutMs", "default": "300000", "type": "number" }
342
+ { "name": "projectPath", "required": true, "description": "Working directory." }
315
343
  ],
316
344
  "workflow": {
317
345
  "name": "custom-report-${objective}",
@@ -326,9 +354,9 @@ registry.
326
354
  "configIsolation": "safe",
327
355
  "permissionMode": "bypass",
328
356
  "sandbox": "workspace-write",
329
- "timeoutMs": "${timeoutMs}"
357
+ "timeoutMs": null
330
358
  },
331
- "timeoutMs": "${timeoutMs}"
359
+ "timeoutMs": null
332
360
  }
333
361
  ]
334
362
  }