Release 6.0.0

Released 2026-09-29. A sprint is one plan you approve, one independent review per unit and one signature; the ceremony v5 wrapped round each unit is gone. This page summarises the release notes, which carry every figure’s source; every breaking change, with its replacement, is in the CHANGELOG.

This page is the record of 6.0.0. The current release is 6.1.0, and Getting started has its checksum-verified install.

What changed for you

• One plan, one review, one signature. You approve the plan once. Each unit gets one reviewer who did not write it, in at most two rounds, and you sign the run once. A question a persona seat can answer no longer waits for you.
• A one-page report. A v5 sprint report ran to 14 sections and a 22-row checklist. A v6 report has five sections - goal, estimates, delivered to plan, known issues, sign-off - and an appendix, and it states every known issue rather than being withheld over one.
• The ceremony that caught nothing is gone. In the back-to-basics review of this repository, 82% of the last 116 sprint units built or repaired the sprint, review and gate machinery rather than the product; plan review rejected 255 of 428 plans, and its 566 recorded fixes changed test plans, not code. Plan review, the test-plan and repair-plan gates, depth tiers as a gate, the mutation ledger, per-unit sign-off and the batch review are removed. The delivery review stays, because it finds real defects: in one v5 run, 9 of 10 REJECT rounds changed production behaviour.
• It learns from its own runs. What went wrong in a run is recorded as a failure class, and its rule is carried into the next plan, build and review brief. See Lessons.
• The forecast follows the newest runs. The v5 token forecast missed by 4.07x on geometric mean. The first five v6 runs came in at 1.14x, 0.50x, 1.03x, 0.51x and 0.53x of theirs, so three were forecast at about twice what they spent. The rate per point is now re-measured from the newest runs, and estimate.tokens_per_point in .config.yaml sets it by hand. A time forecast is new, and it has missed by between 0.59x and 2.51x.

The loop

Six steps, each performed by one command. The whole of it is on the dark factory page and in the skill’s reference-sprint.md.

Step	Command	What it does
Plan	sprint.py plan	orders and sizes the batch against one sprint goal of 20 words or fewer; you approve it once
Build	verify_ac.py run	runs each unit’s acceptance criteria as it is built test-first
Review	critic.py brief	briefs one reviewer who did not write the unit; critic.py record writes the verdict; at most two rounds, and a unit still rejected is carried as a bug
Close	sprint.py close	runs the close once and files a one-page report that states each known issue
Sign	sprint.py sign	your one signature; refuses a principal who authored or reviewed a unit
Learn	retro.py extract	turns the retro’s Try items into lessons and failure-class hits

A question in a persona seat’s lens is ruled by that seat with decisions.py rule. A question only you can answer sets its unit aside with sprint.py decision defer, and the rest of the batch carries on.

Upgrading

Upgrading to v6 is the full path, including what migrate leaves to you.

From 6.0.0-rc.1. Reinstall at a tagged release, then run migrate in each project. Your installed candidate will not tell you to move: its version check reads 6.0.0-rc.1 and 6.0.0 as equal. From 6.0.0 on, an installed candidate is prompted to move to its final release.

/sdlc-studio migrate            # a dry run: lists what it would change, writes nothing
/sdlc-studio migrate --apply    # stamps the project 6.0.0, files signed reports' run records

migrate --apply files the run record of each sprint report you signed on the candidate, so the report checks in any full clone, and only when the report re-derives to the fingerprint it was signed at; it never rewrites a signed page. Since the candidate, 6.0.0 also keeps root config files such as package.json or astro.config.mjs in a unit’s review scope, records a fresh project’s version at init, and makes the close and the signature agree on which units still owe an answer.

From 5.1. The same two commands. migrate --apply removes every retired .config.yaml key with its children and strips the two retired [check:] tags from the Definition of Ready and Done, keeping each criterion as a human-judged line. It leaves three things to you, and names them: instruction files that mention a retired key or verb, your own scripts and CI, and the frozen review records, which stay as history.

v6 retires 19 verbs, 20 flags, 11 config keys, 2 [check:] ids and 4 gate lanes, and changes 2 defaults: review.line_coverage now defaults to off, and triage.low_consolidation to false. Most retired verbs and flags are refused by name, with the reason and the replacement printed and nothing written.

How it was checked

• The migration was rehearsed on copies of two real consuming projects that had not moved since v4 or earlier: a v4.1 project of 687 stories and a v2.4 project of 593. Every run exited 0 in under 10 seconds, neither dry run wrote a byte, and the validation errors were the same before and after. It filed four Medium defects in what migrate reports (BG0842 to BG0845). The rehearsal record has both commands’ exit codes for each project.
• The evals. A fresh agent ran a whole sprint from the docs alone (eval 09), and the independence gate that failed on the candidate passed on the final skill (eval 06). Each is one run, with caveats: see How we know it works.
• The release run itself is RPT0011 on the evidence page: 55 units, each independently reviewed, with 8 operator rulings.

Known issues

35 open defects: 35 Medium, 0 Low

6.0.0 ships with 35 open Medium defects, each listed by id on the known-issues page. The bar for 6.0 is zero open Critical or High finding at the tag; the open Mediums are triaged to 6.1 under decisions D0273 and D0284 rather than waived one by one. None of them stops the lifecycle running.

Read from each finding’s Affects line, 28 of the 35 are in code you run and 7 are in places you will not meet in use. Where a first-week user can meet one:

• The upgrade. migrate’s report undercounts index drift, names no engagement-floor cutoff, leaves out the .gitignore that init writes, and proposes a conformance cutoff that also exempts units written after the project’s own adoption point (BG0842 to BG0845).
• The review. The brief does not name the base ref it asks the reviewer to judge origin against (BG0827); the bug-close guidance never says to hand the reviewer the brief whole (BG0817); a unit carried at the review cap is filed as a bug sprint plan cannot take until it is groomed (BG0829).
• The close and its report. ULID ids are printed without their hyphen (BG0825); the scaffolded retro carries no run id (BG0826); token capture reads NOT ATTRIBUTABLE on a project whose path holds . or _ (BG0835).
• init guided’s personas stage seeds the legacy flat personas.md, which the persona registry and sprint plan --serves never read (BG0824).

On a fresh project the report’s token actual can read NOT MEASURED, because nothing stamped the run’s token meter when it opened.

Where to next

• All releases
• Upgrading to v6
• Evidence and How we know it works