Brownfield walkthrough - adopt an existing app

Most tools assume you are starting fresh. Real work usually is not - you inherit a codebase and have to make it safe to change. Here we adopt an existing TaskFlow app (say, an Express + React task manager with some tests and a CI file) and bring it under the full discipline, without rewriting a line to begin with.

Tip

Try before you commit. Before adopting anything, /sdlc-studio audit --profile repo runs a read-only, refute-panel-verified audit of the repo and files what it finds - zero setup, nothing written to your code. A good way to see what SDLC Studio notices about a codebase it has never seen.

One command, forked for existing code

In the existing taskflow/ repo:

/sdlc-studio init guided

Guided init finds package.json (and friends), classifies the project brownfield, and forks every stage from author to reverse-engineer - you never choose create versus generate, it chooses for you.

1. agents - seeds AGENTS.md / CLAUDE.md (leaving anything you already have untouched).

2. prd - instead of interviewing you, it reads your routes, components, tests and config and reverse-engineers sdlc-studio/prd.md, marking every inferred claim [HIGH], [MEDIUM] or [LOW]. You see TaskFlow’s real feature inventory extracted from the code, with the guesses flagged as guesses.

   The explicit form: prd generate

3. trd - it reverse-engineers sdlc-studio/trd.md from the code and runs an architecture assessment: pattern alignment, smells (Big Ball of Mud, Distributed Monolith), technology fit - reported with [CRITICAL] / [REVIEW] / [INFO]. This is the “document the code and tell me where it hurts” step.

   The explicit form: trd generate

4. tsd - it reads your existing tests and CI, identifies the frameworks (Jest, Playwright, pytest…), and infers the test strategy with [INFERRED] markers - what you cover today and where the gaps are.

   The explicit form: tsd generate

5. personas - it grows the team and the design personas from the extracted PRD, so review has domain teeth from day one.

6. decompose and 7. plan - the extracted spec becomes epics and stories, and you get a first sprint plan over the parts you want to change.

The one rule that makes brownfield safe

Caution

A generated spec is a migration blueprint, not documentation - and it is worthless until proven. Do not trust a generated specification until its tests pass against the existing code. An unvalidated extraction is a guess dressed as a fact.

So the brownfield loop has an extra beat the greenfield one does not. For the slice you are adopting, SDLC Studio writes tests from the extracted spec and runs them against your real implementation:

/sdlc-studio story generate --epic EP0001    # extract implementation-ready stories from the code
/sdlc-studio code verify --story US0003       # do the extracted ACs actually hold against the code?

Acceptance criteria that pass are trusted; ones that fail are where your spec and your code disagree - which is exactly the list of things to fix or re-specify. Only once the extracted spec is green do you plan real change over it, from there following the same build → verify → review → close path as the greenfield walkthrough.

What you have

A codebase you inherited, now with a spec that is proven against the code rather than assumed, an architecture assessment that names the risks, a test strategy that reflects reality, and a team that reviews with your domain’s non-negotiables. From here, every change goes through the discipline - but the adoption cost was reading, not rewriting.

Where to next

• Greenfield walkthrough - the same lifecycle from an empty repo.
• The specification layer - create vs generate, and the confidence markers, in detail.
• The two-backlog model - how the extracted work becomes planned sprints.