Reverse Spec Generation from Existing Legacy Projects (Spec Reconstruction Mode)

[Brujo2020]

will be awesome add a new "Spec Reconstruction Mode" capable of analyzing an existing project that has little or no formal specifications and automatically

Proposed Feature

Introduce a new operating mode:

"Spec Reconstruction Mode"

The system should:

1. Analyze the existing repository structure
2. Detect modules/features/domains automatically
3. Infer architecture patterns and technologies
4. Generate foundational global documentation:
   • product.md
   • tech.md
5. Detect feature-oriented organization when possible
6. Generate feature-level specifications:
   • requirements.md
   • design.md
   • optionally tasks.md
7. Detect missing or ambiguous areas and flag them for human validation
8. Produce confidence indicators for inferred specs
9. Allow iterative refinement with human-in-the-loop corrections

[m13v]

static analysis bottoms out at behavioral intent. grep over a codebase finds routes, schema fields, and explicit validators, it won't find the implicit invariants that only show up in error paths or the auth middleware that rewrites requests before they hit the handler. confidence scoring doesn't fix that because the missing data isn't 'low confidence', it's 'not represented in source'. reconstruction gets meaningfully better paired with runtime observation, hit the running app, watch what it actually rejects, infer requirements from that surface rather than the AST alone.

[Brujo2020]

Thanks, this is a really good point. I agree , static analysis alone probably gets you the shape of the system, not the real behavioral intent. The reason I started thinking about this is that 1,. I really need this feature and more others friends, and 2.- this problem already shows up in a bunch of places, just in separate forms: legacy modernization teams doing software archaeology, papers on recovering requirements from legacy code, tools that infer API contracts from traffic, static analyzers that map routes/schemas/dependencies, and observability tools that show what the app actually does at runtime. There’s even research around extracting requirements from source code and combining static + dynamic analysis to get better results

So my thought wasn’t “AI magically finds the original requirements.” It was more: can we connect those pieces into one flow?

Your point makes that flow clearer: static analysis for structure, runtime observation for actual behavior, and then human review to decide what’s intentional vs accidental. Maybe the first version is just code archaeology + evidence-based docs. The deeper version would be runtime-assisted spec recovery: hit the app, observe rejects/errors/auth/middleware/side effects, and generate candidate specs with proof and open questions.

That’s a bigger scope, but probably the more honest and useful version. Appreciate the push — it helped me sharpen the idea. BTW I found 2 inspirations :
https://github.com/wcpaxx/spec-kit-brownfield-extensions
https://github.com/GeoloeG-IsT/agents-reverse-engineer