Session continuity and zero-drift enforcement across context boundaries — anyone working on this?

[jdrake6789]

Hey all,

I've been following the SDD space closely and I'm glad to see Spec Kit gaining traction. I think spec-driven development is heading in the right direction, but I keep running into a set of problems that I don't see anyone fully addressing yet — and I've spent the past year building a methodology specifically around them.

The core issue: session continuity and cumulative drift over long development timelines.

Spec Kit does a solid job of grounding a single development session in a specification. But real-world projects don't happen in one session. They happen across dozens or hundreds of sessions over weeks and months, often with context windows resetting, models losing architectural intent, and specifications gradually falling out of sync with implementation in ways that are hard to detect.

I think I have an answer. I'm a mechanical engineer, not a dedicated application/software developer. It's possible I'm behind the curve, but I'd like to know for sure. I'm looking for a developer interested in collaborating on this. Please send me a message or reply.

Thank you!

— Josh Drake, P.E.

[dhilipkumars]

Hello @jdrake6789 thanks for the issue, would love to hear your thoughts on this.

i have exactly been thinking about this problem and was toying with an idea recently, Im building this as a potential spec-kit extension, but one of the main goal is to bring the project's source of truth within a single (for small projects) or a bunch of .prose files (today its the source code), this especially after the project has gone through a series of /specify commands. My focus is bringing decorativeness towards logic / algorithm ie: technical aspects than business or specs at the moment.

The project is an infant atm only few days old, have only been playing with example as part of the project but would love user feedback/input at this stage.

Right now the best way to play with it is on its own (as im yet to bring this up for discussion with @mnriem and the community, will do when ready). This is the link. Let me know your thoughts.

related to #1533

[longicorn]

Hi Josh,

This resonates strongly. I've spent the past few months building a tool called goose-sdd and arriving at a methodology I call ISE (Intent-Synchronized Engineering) — which directly addresses the session continuity and drift problem you're describing.

My core finding: the issue isn't which order you develop in (spec-first or code-first), but the time gap before intent is recorded. Context window resets are just one instance of a broader problem — intent evaporates whether it's across AI sessions or simply o
ver time in a human's memory.

I've documented the thinking here: (part 3 of 5, the core concept):
https://gist.github.com/longicorn/69db9c58c156f788cd777543779ec54b

Thank you

[mnriem]

Look at the extensions that are published at https://github.com/github/spec-kit?tab=readme-ov-file#-community-extensions

Some of them clearly are looking at this in some form or shape. For the core workflow I would say for now we are going to keep it the way it is, but we will evaluate on a monthly basis to see if anything needs to happen there and if so how.

[lihan3238]

This is a useful framing, @jdrake6789 — I think the honest split is between semantic continuity (keeping the model's architectural intent alive across months) and boundary continuity (making sure nothing silently bypasses the spec). The first is the hard, open problem you and @longicorn are chasing with full methodologies. The second is small and shippable today, and worth separating out.

Picking up @mnriem's "some community extensions address parts of this": I went after only the boundary slice, with a deliberately thin Spec Kit extension. Two mechanisms:

• a tiny persisted pointer (superpowers-handoff.json: which feature, which phase, artifact-owner, status) so a fresh session — or a different model — resumes at the exact point instead of re-deriving where it was;
• a handful of hardcoded guard rules that block the operations that cause drift, e.g. you can't re-open constitution or fire a one-shot implement while execution is mid-flight, so the spec/constitution stay authoritative rather than quietly diverged-from.

What it explicitly does not do is preserve the model's semantic memory of intent — that still has to be re-read from the spec/constitution each session (so I agree with the "many tokens lost on reload" caveat people raise here). It only guarantees the artifacts you reload from haven't been silently bypassed. Narrow, but it's the part that's enforceable with code rather than methodology. Repo if useful: https://github.com/lihan3238/speckit-superpowers-bridge

[jdrake6789]

So, I'm actually an engineer with a heavy AI interest and have been working on this for a little over a year, now. What I really need is someone to work with who can support our mutual interests. Apparently, I also need friends. Lol.