What happened?
I'm using opencode-goal-plugin through Zed's ACP integration with OpenCode.
The integration works correctly when a Goal is initially started. The Goal can also continue running in the background for a long time, which is useful behavior and should be preserved.
However, after a Goal has been running for an extended period, the state represented through Zed ACP can become inconsistent with the actual Goal execution state.
For example, the actual Goal can still be actively processing in the background, while Zed appears to consider the current operation stopped or finished and allows another prompt to be entered.
The state effectively becomes:
Actual Goal:
RUNNING → still processing → still processing
Zed / ACP:
RUNNING → STOPPED / IDLE
The Goal itself has not actually stopped. It can continue working in the background, sometimes indefinitely.
The problem therefore appears to be a Goal lifecycle/state synchronization issue between the Goal system, OpenCode, ACP, and Zed.
There is also a related consistency issue with the Goal's internal planning during longer-running work. The Goal can become inconsistent around its overall scope, current phase, current task, completed work, remaining work, and next planned task.
The Goal should not simply keep looping over the same task:
Think
→ do task
→ think
→ do same task
→ think
→ do same task
→ repeat
Instead, it should maintain a persistent overall Goal and use a phase-based execution model:
Goal
→ Create overall plan
→ Plan Phase 1
→ Execute Phase 1
→ Verify Phase 1
→ Update Goal state
→ Reassess remaining work
→ Plan Phase 2
→ Execute Phase 2
→ Verify Phase 2
→ Update Goal state
→ Plan Phase 3
→ ...
The current task should be treated as part of the overall Goal, not as a replacement for the Goal itself.
For example:
Overall Goal:
Make the project production-ready
Current Phase:
Parser correctness
Current Task:
Fix compound query parsing
After that task is completed, the Goal should return to the overall Goal scope, evaluate what remains, and plan the next appropriate phase instead of repeatedly treating the same task as the entire Goal.
I would also like the Goal state to integrate more completely with Zed's ACP capabilities.
The Goal should expose structured information through ACP so that Zed can display the Goal's Todo/task progress and current state using the appropriate Zed UI.
This should include, where supported:
- Goal title and description
- Original Goal scope
- Overall plan
- Current phase
- Current task
- Completed phases
- Completed tasks
- Remaining tasks
- Current execution state
- Next planned task/phase
- Verification state
- Errors/blockers
- Important decisions
- Plan changes
- Final completion state
For example:
Goal: Implement SQLite compatibility
Phase 1: Repository audit
✓ Inspect test corpus
✓ Inspect build system
✓ Identify missing registrations
Phase 2: Parser
✓ Fix tokenizer
✓ Fix expression parsing
→ Fix compound queries
Phase 3: Query execution
○ Planner
○ VM
○ Execution
Current phase:
Phase 2
Current task:
Fix compound query parsing
Status:
Working
Next:
Planner implementation
The exact UI representation should follow Zed ACP's supported capabilities. The important part is that Goal state should be exposed as structured ACP state rather than only being represented through model text.
Another important distinction is that completion of an individual request should not necessarily mean completion of the Goal.
A long-running Goal can contain many internal execution cycles and phases.
Therefore:
Request completed ≠ Goal completed
Phase completed ≠ Goal completed
Goal completed = overall Goal completion criteria satisfied
The ability for Goals to continue running for long periods should remain. I do not want an arbitrary timeout or forced stopping behavior.
The desired behavior is to preserve the current long-running capability while making the Goal lifecycle, planning, and state consistent and correctly represented through Zed ACP.
Expected behavior
Zed ACP should remain synchronized with the actual Goal lifecycle for the entire duration of a long-running Goal.
If the Goal is still working, Zed should continue to represent it as active rather than displaying it as stopped or finished.
The Goal should maintain a consistent overall scope and state across multiple phases.
The expected lifecycle is:
Overall Goal
→ Overall Plan
→ Plan Phase
→ Execute
→ Verify
→ Mark phase completed
→ Update Goal state
→ Reassess remaining work
→ Plan next phase
→ Execute
→ Continue until the overall Goal is actually complete
The Goal should not simply repeat the same task indefinitely.
Each phase should have a clear objective, tasks, execution, verification, and completion state.
After a phase is completed, the Goal should use the updated state and remaining scope to determine the next phase instead of blindly repeating the previous task.
The original Goal scope should remain authoritative throughout the entire execution.
Completed work should remain completed unless there is concrete evidence that it needs to be revisited.
Zed should receive accurate structured Goal/task state through ACP so that its Todo/task UI can represent:
- Overall Goal
- Current phase
- Current task
- Completed tasks
- Remaining tasks
- Current execution state
- Next planned task/phase
- Verification state
- Blockers/errors where supported
The long-running background execution should remain supported.
Most importantly:
Request completion should not be treated as Goal completion.
Phase completion should not be treated as Goal completion.
The Goal should only be reported as completed when its overall completion criteria have actually been satisfied.
Steps to reproduce
-
Install the plugin:
opencode plugin @prevalentware/opencode-goal-plugin
-
Configure the plugin for OpenCode.
-
Open OpenCode through Zed using ACP.
-
Start a sufficiently large Goal using:
/goal
-
Let the Goal run for an extended period and perform multiple tasks/phases.
-
Observe that the Goal initially works correctly through Zed ACP.
-
After some time, observe the state displayed by Zed.
-
Zed may show the operation as stopped or idle and allow another prompt to be entered.
-
Check the actual OpenCode/Goal execution.
-
The original Goal can still be running and processing work in the background even though Zed appears to consider it stopped.
-
Continue observing the Goal's planning behavior across phases.
-
The Goal can also become inconsistent about its current task, overall scope, or next plan, and may repeatedly focus on the same task instead of completing the current phase and planning the next appropriate phase.
A larger implementation Goal that naturally requires multiple phases is more likely to expose the issue.
Plugin version
0.1.52
OpenCode version
1.18.32
Operating system
No response
Model/provider in use
No response
Plugin options
Relevant goal state or logs
What happened?
I'm using opencode-goal-plugin through Zed's ACP integration with OpenCode.
The integration works correctly when a Goal is initially started. The Goal can also continue running in the background for a long time, which is useful behavior and should be preserved.
However, after a Goal has been running for an extended period, the state represented through Zed ACP can become inconsistent with the actual Goal execution state.
For example, the actual Goal can still be actively processing in the background, while Zed appears to consider the current operation stopped or finished and allows another prompt to be entered.
The state effectively becomes:
Actual Goal:
RUNNING → still processing → still processing
Zed / ACP:
RUNNING → STOPPED / IDLE
The Goal itself has not actually stopped. It can continue working in the background, sometimes indefinitely.
The problem therefore appears to be a Goal lifecycle/state synchronization issue between the Goal system, OpenCode, ACP, and Zed.
There is also a related consistency issue with the Goal's internal planning during longer-running work. The Goal can become inconsistent around its overall scope, current phase, current task, completed work, remaining work, and next planned task.
The Goal should not simply keep looping over the same task:
Think
→ do task
→ think
→ do same task
→ think
→ do same task
→ repeat
Instead, it should maintain a persistent overall Goal and use a phase-based execution model:
Goal
→ Create overall plan
→ Plan Phase 1
→ Execute Phase 1
→ Verify Phase 1
→ Update Goal state
→ Reassess remaining work
→ Plan Phase 2
→ Execute Phase 2
→ Verify Phase 2
→ Update Goal state
→ Plan Phase 3
→ ...
The current task should be treated as part of the overall Goal, not as a replacement for the Goal itself.
For example:
Overall Goal:
Make the project production-ready
Current Phase:
Parser correctness
Current Task:
Fix compound query parsing
After that task is completed, the Goal should return to the overall Goal scope, evaluate what remains, and plan the next appropriate phase instead of repeatedly treating the same task as the entire Goal.
I would also like the Goal state to integrate more completely with Zed's ACP capabilities.
The Goal should expose structured information through ACP so that Zed can display the Goal's Todo/task progress and current state using the appropriate Zed UI.
This should include, where supported:
For example:
Goal: Implement SQLite compatibility
Phase 1: Repository audit
✓ Inspect test corpus
✓ Inspect build system
✓ Identify missing registrations
Phase 2: Parser
✓ Fix tokenizer
✓ Fix expression parsing
→ Fix compound queries
Phase 3: Query execution
○ Planner
○ VM
○ Execution
Current phase:
Phase 2
Current task:
Fix compound query parsing
Status:
Working
Next:
Planner implementation
The exact UI representation should follow Zed ACP's supported capabilities. The important part is that Goal state should be exposed as structured ACP state rather than only being represented through model text.
Another important distinction is that completion of an individual request should not necessarily mean completion of the Goal.
A long-running Goal can contain many internal execution cycles and phases.
Therefore:
Request completed ≠ Goal completed
Phase completed ≠ Goal completed
Goal completed = overall Goal completion criteria satisfied
The ability for Goals to continue running for long periods should remain. I do not want an arbitrary timeout or forced stopping behavior.
The desired behavior is to preserve the current long-running capability while making the Goal lifecycle, planning, and state consistent and correctly represented through Zed ACP.
Expected behavior
Zed ACP should remain synchronized with the actual Goal lifecycle for the entire duration of a long-running Goal.
If the Goal is still working, Zed should continue to represent it as active rather than displaying it as stopped or finished.
The Goal should maintain a consistent overall scope and state across multiple phases.
The expected lifecycle is:
Overall Goal
→ Overall Plan
→ Plan Phase
→ Execute
→ Verify
→ Mark phase completed
→ Update Goal state
→ Reassess remaining work
→ Plan next phase
→ Execute
→ Continue until the overall Goal is actually complete
The Goal should not simply repeat the same task indefinitely.
Each phase should have a clear objective, tasks, execution, verification, and completion state.
After a phase is completed, the Goal should use the updated state and remaining scope to determine the next phase instead of blindly repeating the previous task.
The original Goal scope should remain authoritative throughout the entire execution.
Completed work should remain completed unless there is concrete evidence that it needs to be revisited.
Zed should receive accurate structured Goal/task state through ACP so that its Todo/task UI can represent:
The long-running background execution should remain supported.
Most importantly:
Request completion should not be treated as Goal completion.
Phase completion should not be treated as Goal completion.
The Goal should only be reported as completed when its overall completion criteria have actually been satisfied.
Steps to reproduce
Install the plugin:
opencode plugin @prevalentware/opencode-goal-plugin
Configure the plugin for OpenCode.
Open OpenCode through Zed using ACP.
Start a sufficiently large Goal using:
/goal
Let the Goal run for an extended period and perform multiple tasks/phases.
Observe that the Goal initially works correctly through Zed ACP.
After some time, observe the state displayed by Zed.
Zed may show the operation as stopped or idle and allow another prompt to be entered.
Check the actual OpenCode/Goal execution.
The original Goal can still be running and processing work in the background even though Zed appears to consider it stopped.
Continue observing the Goal's planning behavior across phases.
The Goal can also become inconsistent about its current task, overall scope, or next plan, and may repeatedly focus on the same task instead of completing the current phase and planning the next appropriate phase.
A larger implementation Goal that naturally requires multiple phases is more likely to expose the issue.
Plugin version
0.1.52
OpenCode version
1.18.32
Operating system
No response
Model/provider in use
No response
Plugin options
Relevant goal state or logs