What we're exploring
Could a change keep the specs up to date as the work happens, so there's no separate archive step at the end?
Why
Today the specs are updated when a change is archived, which happens after the work is done. Some users have told us they'd expect the specs to update alongside the code once it merges, without an extra step to think about. We'd like to see whether the workflow can get simpler.
One idea to try: let the tasks drive it
Tasks already drive a change, so they could also keep the specs current:
- when a group of tasks is done, its docs and the specs it implemented are updated (a sync, not an archive)
- the last task closes the change
- when every task is done, the change is complete and ready to merge
The spec changes are still written and reviewed before any code, so you still see what will change first.
Other directions
This is one idea among several. Another is to show a change as a view computed from the branch instead of a stored delta, so nothing needs applying or archiving at all.
Next steps
Research and prototyping before deciding anything. Questions to answer:
- how people plan and merge work
- what happens with several changes in progress at once
- what happens when specs live in a separate repo
We're trying the task-driven idea in one of our own projects, using its openspec/config.yaml task rules, and will share what we learn here.
What we're exploring
Could a change keep the specs up to date as the work happens, so there's no separate archive step at the end?
Why
Today the specs are updated when a change is archived, which happens after the work is done. Some users have told us they'd expect the specs to update alongside the code once it merges, without an extra step to think about. We'd like to see whether the workflow can get simpler.
One idea to try: let the tasks drive it
Tasks already drive a change, so they could also keep the specs current:
The spec changes are still written and reviewed before any code, so you still see what will change first.
Other directions
This is one idea among several. Another is to show a change as a view computed from the branch instead of a stored delta, so nothing needs applying or archiving at all.
Next steps
Research and prototyping before deciding anything. Questions to answer:
We're trying the task-driven idea in one of our own projects, using its
openspec/config.yamltask rules, and will share what we learn here.