Specification only in the features? Could be always growing knowledge base? Growing after pull requests help?

[jvcjjj8t2q-sketch]

I build my first application with speckit and I really love it.

But there is one point I am bit confused and ask myself if we couldn't get better.

The point is that with every feature we have the specs/XXX-folders/ where the spec and tasks are contained.

But when I understand it correctly there is no specification which does hold it all together. Wouldn't it be good, that after a pull request the new features and with all its new knowledge is transferred back into one spec, plan, etc. containing everything about the application?

What happens if an old feature 007 is not working together with 042. Would speckit.analyze find such an issue? Or would we need a new database which could be examined to understand that?

[simon-k]

I would like to know too.

For example

• the quickstart.md file. It must be evolving as new specs/features are added.
• the data-model.md file is also evolving over time
• and the spec.md some functional requirements in the first spec might be removed in the next spec and so on. How does a developer onboard a project with many specs folders. If there are many then it's impossible for that person to keep track of.

[anchildress1]

There's a separate conversation about this exact same thing that got spun up in an issue somewhere, but it's since went silent and I cannot remember which one it was. So, yes—the idea of a higher project-level spec has been discussed, but no decisions have been made yet as to whether or not to implement that sort of feature and if so, then how?

While that's being decided, each spec should be treated as an immutable object once dev work is considered complete. So if you implement spec 1 > 2 > 3 and then find something in 1 isn't right after all? You should create spec 4 to address it instead of going back to 1 and trying to fix it there.

[jvcjjj8t2q-sketch]

But that would mean, that the spec would be in a folder like spec/004-xxxx.

So far I have never seen, that those feature specs were read again.

[anchildress1]

Think of it like an immutable release sort of flow. If you're on v3 and find a bug that was originally introduced in v1, you'd still have to release v4 to fix it.

Spec Kit works the same sort of way. Once you kick off that very first /speckit.implement phase 1 prompt, everything documented in the spec up to that point should be considered immutable. You could update it—there's not anything built in to stop you—and I'm sure people do, but the current functionality wasn't built to support that flow—at least, not from anything I've seen or tried myself yet.

[anchildress1]

Also in case it adds a bit more clarity, there is logic built in that matches the name of the current checked out branch to the name of a specific spec. In a typical dev flow, the branch gets check out, you do the work, merge it, delete it, and never think of it again. I really don't know how successful it might be—I've never thought to try it before now—but... in theory you could recreate a branch for a specific spec and behind the scenes that would default the "active" spec to the matching one instead of latest. It might be worth testing? Let me know how it goes!