Predicate-less goal loops never resolve: a finished graph shows six IDLE cards and keeps six sessions resident

[Yuncun]

Version: 0.1.68 (release dmg), Claude Code backend.

What happened

A leader goal loop fanned out five children (all --type goal, none with --predicate). Every child finished its item, posted a RESULT to the Mailroom, and the leader merged, ticked the backlog, pushed with CI green and posted a CLOSING note. Forty minutes later every one of the six cards still reads IDLE; none ever became SUCCEEDED, no edge downstream of a child would have fired, and six claude sessions (~2 GB RSS) stayed resident until deleted by hand.

The briefing text says a goal loop without a predicate resolves when "finishing the work is what resolves it" — that is not what the daemon does. graphcode status agreed: idle goalBased ×6.

Why it matters for a first-time user

• The canvas has no visual difference between "waiting for mail", "build running in background" and "done". All three are IDLE (see also No clear indicator for which loop is currently performing a task vs just simply being active #45).
• The one place a newcomer would look to know the run is over — the graph — never says so.
• A /goal stop hook keeps the Claude session alive, so "done" from the agent's own point of view is also invisible.

Suggested fix

Treat a predicate-less goal loop as resolved when its backend session ends its turn after the /goal condition has been satisfied (Claude Code already reports this through the Stop hook), or when the loop itself posts a result / calls a graphcode node done verb. Show SUCCEEDED on the card and free the session by policy (keep transcript, end the PTY).

[scgopi]

Thanks for the detailed report — it's accurate, and the briefing text was wrong about what the daemon does.

Why it happened

• A goal loop with --predicate resolved when the predicate exited 0.
• A goal loop without one only resolved when the app's pane saw its process exit. An interactive agent almost never exits, and a loop running with no pane open never reported it at all — so the card sat at IDLE and no downstream edge fired.
• Even a resolved loop kept its session running, which is where the resident memory came from.
• A turn ending looks the same whether the loop is done or waiting on mail, CI or its children, so a turn ending is not treated as success.

What the fix does

1. Records how a loop resolved. The card says whether a predicate passed, the backend recorded its goal as met, the loop reported done, or a human marked it done. A verdict resolves once; a stale report cannot overturn it.

2. Uses the backend's own goal verdict. Goal loops already launch with the backend's /goal, and three backends record when that goal is met:

Backend	Signal
Claude Code	transcript goal_status with met: true (judged by a separate evaluator)
Codex	the thread's goal status becomes complete
Copilot CLI	the autopilot objective's status becomes completed

Each verdict is dated, so a verdict on an earlier goal never counts for a new one. A configured --predicate still has to pass.

3. Adds graphcode node done. A backend-neutral way for a loop to report that its goal is met — the main path for OpenCode and pi, and a fallback for everyone else. The briefing says to call it only when the goal is met, never while waiting on mail, CI, or loops it created.

4. Doesn't resolve a leader early. A leader whose child loops are still running shows WAITING and resolves once they have all succeeded. If one didn't, the leader is told and has to report again.

5. Frees the session, keeps the loop. Once a loop has resolved and delivered its final report, its agent process is ended after a grace period — only when it is confirmed idle and no terminal is attached (Settings: 1 minute, 10 minutes, 1 hour, or never). The card, its history, memory log and transcript all stay. Opening a finished card resumes the conversation; it never starts the met goal again. From there you can:

• Ask a follow-up question — the card stays SUCCEEDED and no edges fire.
• Give it a new goal — the card goes back to RUNNING with the new condition, the earlier goal stays recorded as succeeded, and downstream edges are not re-fired.

A met goal is never re-run.

Before and after

	Before	After
Goal loop without a predicate finishes	IDLE forever	SUCCEEDED, with how it resolved
Edges after it	never fire	fire once
Leader waiting on children	IDLE	WAITING until they succeed
A crash or a pause for mail/CI	IDLE	never counted as success
Memory held by finished loops	stays resident	freed; transcript kept
Opening a finished card	may relaunch the goal	resumes the conversation

For OpenCode and pi, completion depends on the agent calling graphcode node done; a loop that never does stays IDLE rather than looking finished.

The fix is in #350.

[scgopi]

Fixed in 0.1.70-beta4 (https://github.com/scgopi/GraphCode/releases/tag/0.1.70-beta4), through #350, #351 and #352.

A goal loop without a --predicate now resolves on its own, and a finished graph says so:

• It resolves from the backend's own verdict. Claude Code, Codex and Copilot CLI record when their /goal is met, and the daemon reads that record. A turn ending is never taken as success, so loops waiting on mail, CI or their children stay unresolved.
• Any loop can report it with graphcode node done. OpenCode and pi, which record no verdict, are given the exact command in their goal prompt.
• A leader waits for its workers. It shows WAITING until the loops it created have succeeded, then resolves and fires its edges.
• Finished sessions are freed. After a loop resolves, its agent process is ended once it is idle with nothing attached (Settings: 1 minute, 10 minutes, 1 hour, or never). The card and its transcript stay. Opening it resumes the conversation, and a follow-up question leaves it SUCCEEDED.

Checked with live goal loops on all five backends on this build. Thanks for the clear report.