OpenSpec 1.5.0 adds support for using a registered store with --store <id>. The generated skills describe this correctly at the start, but two later instructions still assume the main specs always live in the current repository:
sync-specs reads and creates openspec/specs/<capability>/spec.md
archive-change compares delta specs against the same path before offering to sync
This is incorrect when a store is selected. In that case, the change and its main specs belong to the selected store, while the repository may also contain its own openspec/ directory.
The result can be misleading or destructive:
- a sync can update the repository’s specs instead of the selected store’s specs;
- the selected store can remain out of date;
- archive can incorrectly report that specs are already synced, based on the wrong location.
The CLI already resolves the active planning location. The generated workflow instructions should use the same resolved root for main specs, for example:
<planningHome.root>\openspec\specs\<capability>\spec.md
rather than assuming:
openspec/specs/<capability>/spec.md
Suggested template changes:
- In
sync-specs, derive both the main-spec read path and new-main-spec creation path from planningHome.root.
- In
archive-change, use that same derived path for sync assessment.
- Avoid calling CLI-returned delta-spec paths “repo-local,” since they may belong to a selected store.
This preserves current repo-local behaviour while making the workflows consistent with --store <id>.
OpenSpec 1.5.0 adds support for using a registered store with
--store <id>. The generated skills describe this correctly at the start, but two later instructions still assume the main specs always live in the current repository:sync-specsreads and createsopenspec/specs/<capability>/spec.mdarchive-changecompares delta specs against the same path before offering to syncThis is incorrect when a store is selected. In that case, the change and its main specs belong to the selected store, while the repository may also contain its own
openspec/directory.The result can be misleading or destructive:
The CLI already resolves the active planning location. The generated workflow instructions should use the same resolved root for main specs, for example:
rather than assuming:
Suggested template changes:
sync-specs, derive both the main-spec read path and new-main-spec creation path fromplanningHome.root.archive-change, use that same derived path for sync assessment.This preserves current repo-local behaviour while making the workflows consistent with
--store <id>.