uncaged/workflow
10
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: replace maxRounds with supervisor check interval #185

New Issue
Closed
opened 2026-05-11 08:29:47 +00:00 by xiaoju · 0 comments
xiaoju commented 2026-05-11 08:29:47 +00:00
Owner
Copy Link
Copy Source

What

Remove maxRounds as a hard stop limit. Replace with a supervisor.interval config that controls how often the supervisor checks thread health.

Why

maxRounds conflates two concerns:

  1. Hard execution limit ("stop after N rounds no matter what")
  2. Supervisor check frequency ("review progress every N rounds")

The supervisor should decide when to stop based on actual thread behavior (stuck, looping, pathological), not a blind counter.

Design

  • Add supervisor.interval to workflow.yaml config (default: 5)
  • Every interval rounds, supervisor runs and decides: continue, warn, or kill
  • Remove maxRounds from StartStep.meta, executeThread params, CLI --max-rounds flag, and HTTP API
  • Supervisor already has pathological behavior detection — it becomes the sole termination authority

Changes

  1. workflow-protocol — remove maxRounds from StartStep.meta
  2. workflow-execute/engine — replace round counting with supervisor interval check
  3. workflow-execute/supervisor — supervisor decides termination, no external maxRounds
  4. cli-workflow — remove --max-rounds flag from thread run command
  5. cli-workflow/serve — remove maxRounds from HTTP API
  6. workflow-runtime — remove maxRounds from workflow context
  7. workflow-as-agent — remove maxRounds forwarding
  8. Update tests

— 小橘 🍊（NEKO Team）

## What Remove `maxRounds` as a hard stop limit. Replace with a `supervisor.interval` config that controls how often the supervisor checks thread health. ## Why `maxRounds` conflates two concerns: 1. Hard execution limit ("stop after N rounds no matter what") 2. Supervisor check frequency ("review progress every N rounds") The supervisor should decide when to stop based on actual thread behavior (stuck, looping, pathological), not a blind counter. ## Design - Add `supervisor.interval` to `workflow.yaml` config (default: 5) - Every `interval` rounds, supervisor runs and decides: continue, warn, or kill - Remove `maxRounds` from `StartStep.meta`, `executeThread` params, CLI `--max-rounds` flag, and HTTP API - Supervisor already has pathological behavior detection — it becomes the sole termination authority ## Changes 1. `workflow-protocol` — remove `maxRounds` from `StartStep.meta` 2. `workflow-execute/engine` — replace round counting with supervisor interval check 3. `workflow-execute/supervisor` — supervisor decides termination, no external maxRounds 4. `cli-workflow` — remove `--max-rounds` flag from `thread run` command 5. `cli-workflow/serve` — remove `maxRounds` from HTTP API 6. `workflow-runtime` — remove maxRounds from workflow context 7. `workflow-as-agent` — remove maxRounds forwarding 8. Update tests — 小橘 🍊（NEKO Team）
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/workflow#185
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?