Skip to main content

0.9.0 — Knowing which backlog items are ready

Released 2026-09-01.

A backlog tells you what you might build. It has never told you what is ready to be built. This release works that out for you, continuously, from what is already recorded.

What's new​

Elaboration stages. Every backlog item now carries a stage from E0 to E4, derived from the evidence attached to the requirements it names — is a requirement linked, has it been analysed with its findings settled, does it have features, does it have stories. Nothing is typed in and nothing is guessed: the stage is read off the record, and no AI call is involved anywhere, so the same inputs always give the same answer.

Where an item reached a later stage without passing through an earlier one, the skipped stage is shown with the reason it was skipped — no completed analysis, open findings exist, no active feature suggestions. A gap with a reason is a to-do list.

Scopeable items. Filter the backlog to the items whose evidence is complete enough to put into a release. This is the question the stages exist to answer.

Requirement links. Backlog items can be linked to the requirements they concern. The system proposes links by scanning item text for requirement references, and you confirm them in bulk or one at a time. References it cannot resolve are reported rather than dropped. Links survive requirement renumbering, and removing one requires a reason.

Dependency ordering. Record that one item must wait for another — either outright or on a stated condition. From those, the backlog shows you the full set of items a release must wait for, detects circular dependencies, and asks you to determine whether a cycle is genuinely decomposable. Removing a dependency requires a reason, because an ordering that changed for no recorded reason cannot be explained afterwards.

Stage history. Every stage change is recorded with its cause, including changes that move an item backwards — reopening a finding, or rejecting the last feature suggestion. You can ask what stage an item was at on a given date and how long it spent in each. This history deliberately outlives the item it describes.

Stages stay current on their own. When you dispose of a finding, add a story or accept a feature, the affected stages are recomputed within a minute without anyone asking. If recomputation has not caught up, the stage is shown as stale rather than shown as wrong.

Bug fixes​

  • Backlog list pagination dropped some filters. With a stage or Scopeable filter active, moving to page 2 silently widened the results — it answered a different question from page 1 while looking like a continuation. Both page links now carry every active filter. If you have paged through a filtered backlog before this release, page 2 onwards may have shown you more than you asked for.
  • Filter counts disagreed with the filtered list. The stage and Scopeable chips counted every item regardless of the other active filters, so a chip could promise 62 and deliver 58. Counts now follow the usual rule: each chip reflects every other active filter but not its own.
  • Several icons were invisible. Five icons across the new pages rendered as blank space.
  • A CSV import test fixture was missing, so requirement CSV import was not being exercised by the test suite. The import itself was unaffected.

Behind the scenes​

  • Eleven new tables and 26 indexes support the links, dependencies, stage index and history.
  • Stage recomputation runs on a new dedicated queue served by exactly one worker. Several backlog items can share a requirement, so their recomputations can collide; a single worker makes that impossible rather than merely unlikely. If the worker stops, stages are reported as stale — the failure is visible rather than silent.
  • Each recomputation checks whether the index is already current and exits if it is, so recomputation is cheap to trigger often.
  • 427 scenarios covering this release are executed by automated tests, at controller level and through the browser.
  • Twenty-five unused Python packages were removed from the installation. None was referenced anywhere in the product; between them they carried half of the known advisories against our dependencies. Nothing about how REQQA behaves changes as a result.

Upgrade notes​

This release adds eleven tables and alters none. No existing data is changed or migrated, and the upgrade is safe to apply to a live database.

Self-hosted installations must also install the new single-worker queue service. Without it no elaboration stage is ever recomputed — every stage reads as stale and nothing appears broken. The migration directory for this release contains the steps and the verification queries.