Skip to content

Fix durable subagent wait policy - #42

Merged
tolibear merged 2 commits into
tolibear:mainfrom
bogdan0dzuba:codex/durable-subagent-waits
Aug 3, 2026
Merged

Fix durable subagent wait policy#42
tolibear merged 2 commits into
tolibear:mainfrom
bogdan0dzuba:codex/durable-subagent-waits

Conversation

@bogdan0dzuba

Copy link
Copy Markdown
Contributor

Summary

  • treat a single wait_agent timeout as an observation-window boundary, then inspect actual agent_status and delivered messages
  • keep bounded waits role-aware: Scout/Judge 20 minutes, Worker 30 minutes, with no file-change liveness requirement for read-only roles
  • require proven failure before interruption or PM fallback and set Claude Opus architecture-review waits to at least 1200 seconds
  • bump GoalBuddy to 0.4.3, mirror the canonical skill tree, and add regression coverage

Verification

  • npm run check (130/130)
  • npm run pack:dry-run
  • node internal/cli/check-publish-version.mjs
  • git diff --check
  • node internal/cli/sync-skill-tree.mjs

@bogdan0dzuba

Copy link
Copy Markdown
Contributor Author

@tolibear Hi! We're moving quickly on our Codex workflow, and this issue is currently blocking reliable use of Scout, Judge, and Worker agents. The patch is intentionally narrow, includes regression tests, and bumps the package to 0.4.3. When you have a moment, could you please approve the workflow and take a look? Happy to adjust anything you prefer. Thanks!

@tolibear
tolibear merged commit d706e07 into tolibear:main Aug 3, 2026
2 checks passed

tolibear commented Aug 3, 2026

Copy link
Copy Markdown
Owner

Thanks, @bogdan0dzuba. We reviewed and integrated the fix, including the final timeout-path safeguards. CI is green on Node 18 and 24, and goalbuddy@0.4.2 is now published and verified on npm. Everything is ready to go. Appreciate you surfacing this and putting together the patch.

@bogdan0dzuba
bogdan0dzuba deleted the codex/durable-subagent-waits branch August 4, 2026 19:32
@bogdan0dzuba

Copy link
Copy Markdown
Contributor Author

@tolibear One follow-up idea from field use, if you are open to another PR.

We found that GoalBuddy can still push long sequential goals into too many operational cards, even with the current "largest safe useful slice" guidance. One real board grew to 229 tasks: 88 PM, 82 Judge, 24 Scout, and only 35 Worker tasks. It ended with 27 unfinished blocked cards. Running the 0.4.2 checker on that board returns ok: true with warnings: [], so the current micro-slice heuristic does not catch this shape.

The recurring pattern was Worker/PM -> Judge -> next micro-step, with separate cards for planning, individual checks, CI, readback, and receipts. The board started duplicating the native Codex Goal and repository PR/CI evidence instead of reducing risk.

Possible backward-compatible follow-up:

  • seed 3-7 outcome-sized phases by default;
  • treat one task as a complete vertical result, usually including implementation, targeted tests, PR/CI, and readback when the authority and risk boundary stay the same;
  • warn when unfinished tasks exceed roughly 12, including blocked boards with no active task;
  • after two consecutive planning/audit/process-only tasks without a new verifiable capability, prompt the PM to consolidate the future plan;
  • reserve Scout for material uncertainty and Judge for phase, risk, rejected-verification, or final boundaries;
  • explicitly say that duration alone is not a reason to use GoalBuddy: a long single-owner sequential goal may be better served by the native Goal, while GoalBuddy remains valuable for durable multi-stream coordination and formal audit;
  • preserve historical receipts and compact only future work;
  • keep these as advisory warnings so old boards remain valid.

I would be happy to implement this with checker, prompt-renderer, seed-board, and policy regression tests if the direction fits the project.

@tolibear

tolibear commented Aug 5, 2026

Copy link
Copy Markdown
Owner

Thanks for the concrete field evidence. The 229-task shape and the clean 0.4.2 checker result make the gap clear.

I opened #44 with the accepted direction: advisory checker and prompt warnings, outcome-sized seed guidance, no invalidation of old boards, and no rewriting historical receipts. A focused PR against current main covering the checker, prompt renderer, policy/seed guidance, and regression tests would be welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants