Upgrading from v1 / v4

If you have used SDLC Studio since the early, mostly human-driven days, the tool has grown a lot of discipline. The good news: nothing changes in an existing project until you say so.

The upgrade is opt-in

Re-run the installer (or /sdlc-studio skill-update). It is a drop-in: no project migration, and existing sdlc-studio/ directories keep working exactly as they did. The v5 workflow changes - the two-backlog gates, sizing demands, terminal-status derivation - are off by default. An existing project upgrades with zero disruption and keeps its old flow until you turn enforcement on.

What is new to learn

The two-backlog model. The single biggest shift: a request (CR/RFC) is not work until refine sizes it into delivery units. This is new if you last drove the pipeline by hand.
Sizing is compulsory. Delivery units carry points (stories/bugs) or a T-shirt size (CRs/RFCs/epics). The planner refuses an un-sized unit.
Two-role review. Past a configurable threshold, Done needs an independent, non-author sign-off.
Sprint planning and autosprint. A deliberate batch driven to a goal, closed with reconcile and review.

Turning enforcement on

Three deliberate steps, documented in the repo’s upgrade guide:

migrate_v3 sizing - convert existing requests and containers to a T-shirt size deterministically, and report the delivery units that need re-sizing.
refine the accepted requests into sized delivery work.
Set two_backlog.enforce: true in .config.yaml.

The sizing migration only adds a Size: line and the workflow is one config line, so the upgrade is reversible.

The numbering question

New projects mint collision-free ULIDs (US-01JQK3F8) so parallel agents never fight over sequential ids. An existing project is asked the numbering question explicitly on upgrade, with three supported answers - it is never auto-flipped.