Replies: 1 comment 4 replies
-
|
This is a good question! In an ideal world any drift between code and spec should be "reconciled". Ideally this happens automatically without you having to worry about. In these cases where a drift does occur, my view is it's ok to update the source of truth directly to match the changed implementation. I'm looking at ways to see if this is possible to detect in a simpler automatic way, but up till then this process has to be manual unfortunately. Similar to my comment on this other thread, I think the only 2 options are either
|
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I understand that the OpenSpec flow is designed to keep openspec/specs/** as the source of truth, with changes proposed under openspec/changes/** and archived back into specs after implementation.
What I’m finding hard to reconcile is this:
If I directly edit code in my repo (instead of generating it from a spec/task), the specs don’t automatically know about those changes.
That seems to introduce “spec drift” — code and spec are no longer aligned. Like with the spec driven development can i edit my code manually as part of a bets practice workflow? or is all code to be written by my AI based on specs?
Beta Was this translation helpful? Give feedback.
All reactions