Should SDD include a discovery and validation loop?

[pandeyshivendra]

I tried SDD yesterday and found the workflow a bit linear:

spec → plan → tasks → code

In practice, some assumptions in the spec can only be validated by inspecting the existing system and challenging the design against how it actually behaves.

I wonder if the workflow could be more iterative:

discover → spec → challenge → plan → implement → verify → update spec ↻

Or perhaps the workflow should vary depending on the type of system being built.

Curious if others have had a similar experience or if there’s already a recommended approach for this.

[mnriem]

Great observation — and the good news is SDD is meant to be exactly this composable. The linear spec → plan → tasks → implement is the core cycle, and the discovery/challenge/verify loops you're describing are provided as extensions and presets layered on top, rather than baked into the core:

• discover (inspect the existing system first) → brownfield extensions like brownkit do evidence-driven capability discovery for existing codebases.

• challenge (stress-test assumptions before planning) → the bundled assess extension (intake → research → define → shape → decide).

• verify / update spec ↻ → /speckit.analyze flags spec-drift between artifacts, and there's in-progress work on /speckit.revise ([Feature]: /speckit.revise - update the current spec without rewriting artifacts #4156) for updating a spec without rewriting everything.

• "vary by system type" → that's what presets (compose different command-template flavors) and bundles (package a tailored pipeline) are for.

So you'd build your discover → spec → challenge → … → verify ↻ flow by composing those pieces for your project type. If you try it and hit a gap none of them cover, that's worth a feature-assess issue. Thanks for the thoughtful write-up.