[FEAT] Feedback loop / rework based on review

[Swahjak]

How does one do rework based on feedback on the initial implementation of a feature? Updating the specs results in the tasks still being marked as complete. Forcing the agents to re-check all tasks does work, but it would be nice if there could be some sort of continuation on the existing spec to allow for providing feedback until the spec is completed.

[TabishB]

@Swahjak Hey yep this is a good point. It's a pain myself and a few others have felt as well.

Creating a new proposal for a tweak usually feels too bulky and sometimes you tweak things during implementation that makes the initial proposed spec invalid. There's currently no good way or step in the process yet to handle this without explicitly or manually updating the proposal and proposed specs etc.

There's probably two approaches we can possibly take here.

1. Forcing a spec check before during every iteration. Such that everytime you provide feedback it verifies or modifies if anything needs to change in the proposal, thus preemptively updating the proposal before any feedback is applied.

Pros: Maintains the spec-first approach,
Cons: Quite a bit of overhead and having to check each time whether spec needs to be updated. Harder to manage context session with this as well.

2. Have some sort of finalization step. Start with initial proposal, then provide feedback as you need. Then at the end finalize the proposal and modify specs as needed.

Pros: Easier and faster to iterate.
Cons: Finalizing would most likely be manual and something you have to remember. Maybe not as robust and things can be missing in the finalized approach at this stage.

[TabishB]

If you have any interesting ideas here, feel free to suggest something!

[Swahjak]

1. I guess the problem with this approach is that specs are not always a 100% clear and reality might give you new insights, requiring a feedback loop after applying the spec.
2. This is actually the method that I would like the most, it gives me the flexibility to adjust when needed.

Another option is to allow adjusting the spec while it's active, but actually unmarking tasks as done when they need re-work / are affected by the spec change (or add tasks)

[carlfriedrich]

I had this situation as well. Created a spec, refined it until I thought it was ready, then applied. During testing I noticed that the result did not work correctly due to a missing piece in the spec.

What I did: I told the agent what does not work and why. It analyzed the problem and came up with a plan to fix it. I then prompted it to update the corresponding OpenSpec change first.

The agent then updated the spec accordingly, added new tasks and removed checkmarks from already finished tasks that needed to be re-executed now.

I reviewed the specs and made sure they were correct now, then ran opsx:apply again.

This worked for my case. Maybe OpenSpec can add a command for this post-implementation refinement of specs? Or would one of the existing extended workflow commands already cover this? I am currently using the basic workflow only, as I am just starting out with OpenSpec.

[clay-good]

Closing as delivered. The command @carlfriedrich asked for at the end of this thread ("Maybe OpenSpec can add a command for this post-implementation refinement of specs?") now exists: /opsx:update (openspec-update-change, shipped in v1.6.0 via #1278, in the default core profile). It revises a change's plan mid-flight, folds new decisions in, and reconciles artifacts — including exactly the rework loop described here: its template handles "Change already implemented (tasks checked off / already applied) → the code may no longer match the revised plan; suggest /opsx:apply to carry the delta into code" (src/core/templates/workflows/update-change.ts), which covers @Swahjak's "unmark tasks that need re-work" option — the update reconciles tasks against the revised spec, then apply carries the delta. The review side (checking implementation against artifacts before archive) is the verify workflow (openspec-verify-change), and docs/editing-changes.md + docs/reviewing-changes.md document the full loop. This is option 2 from TabishB's original comment (iterate freely, reconcile deliberately), made concrete. Deeper cross-artifact review automation is tracked separately in #783 (open PR #893).