Replies: 1 comment 1 reply
-
|
The pain you're hitting is one of the fundamental tensions in spec-driven workflows: once a spec moves from "proposed" to "applied," there's no clean path back to editing it without creating duplicate documents. I've been wrestling with the same problem on a project I build called SPECLAN (disclosure: I'm the creator, it's a VS Code extension for spec management). The approach that's worked for me is making "modifying a locked spec" a first-class workflow rather than an edge case of the apply workflow. Concretely:
This keeps the "implement the change" and "archive the change" steps you mentioned as distinct events rather than the agent conflating them. The practical effect is that you can iterate on a spec after it's been applied without either losing the audit trail or fighting the tool. Not sure if OpenSpec has a built-in mechanism for this — my read of the current workflow is that it assumes specs are write-once-then-archive, which works for some teams but breaks down as soon as you need to revise a shipped feature. Curious if the OpenSpec maintainers have a different recommendation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
How do you refine specs after /openspec:apply?
Once I run /openspec:apply, I can’t seem to update the spec anymore. Any attempt to change it just creates a new document in the root folder and immediately implements the feature.
What’s the recommended workflow for iterating between “implement the change” and “archive the change”? Is there a config I’m missing?
What's your recommended workflow?
Beta Was this translation helpful? Give feedback.
All reactions