feat(release): surface unscoped unstarted work in release status (REQ-345) - #935
Merged
Conversation
…-345) `release status` filters on `release: <version>`, so an artifact carrying no release field appears in NO readiness query. 601 of this repository's 706 artifacts had none, and 165 of those were draft or proposed — real unstarted work nothing ever asked about. #104 sat five months for exactly that reason. It was not untracked: REQ-059 covers it, with no release field. Nothing was deferred or rejected, because nothing surfaced it. Absence of a `release:` resembles a decision from a distance; `backlog` is one. The count now appears beside the scoped set in both text and JSON, as `unscoped_unstarted` — in front of whoever is already asking about a release, which is when it matters. TWO DESIGN CHOICES, BOTH NEGATIVE-CONTROLLED. Only draft and proposed are counted. An approved or implemented artifact with no release is finished work from before scoping existed, and a release field on it would mean nothing. Counting all 601 would report a number nobody can act on, which is the defect class this exists to fix rather than reproduce. Removing the status filter counts three instead of two in the fixture and reddens the JSON assertion. It is information, not a gate. The cuttable verdict is untouched: a release whose own scope is ready stays ready regardless of unscoped work elsewhere, which is by definition not part of that release. Adding 161 items to a blocking set would make the gate unpassable and read as noise within a day. Making `unscoped_unstarted` block the verdict reddens the guard. VERIFIED against this repository's own store, which is where the finding came from: rivet reports 161 and an independent count over every artifact file agrees at 161. The figure moved from the 165 recorded when this was filed. That is not measurement drift — REQ-059, REQ-247, REQ-250, REQ-252 and DD-074 were given release fields since, and left the unscoped population. A count that goes down as artifacts get decided about is the behaviour wanted; one that never moved would be the suspicious one. Confirmed with fmt 0, clippy 1.97.0 --all-targets -D warnings 0, cargo test --workspace 0 (2371 passed), cargo test -p rivet-cli --test cli_commands 0 (216 passed), rivet validate 0, rivet docs check 0, yamllint 0, diagnose_test.sh 0. Implements: REQ-345 Verifies: REQ-345
📐 Rivet artifact delta
Graphgraph LR
REQ_345["REQ-345"]:::modified
classDef added fill:#d4edda,stroke:#28a745,color:#155724
classDef removed fill:#f8d7da,stroke:#dc3545,color:#721c24
classDef modified fill:#fff3cd,stroke:#ffc107,color:#856404
classDef overflow fill:#e2e3e5,stroke:#6c757d,color:#495057,stroke-dasharray: 3 3
Modified
Posted by |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
release statusfilters onrelease: <version>, so an artifact carrying no release field appears in no readiness query. 601 of this repo's 706 artifacts had none, and 165 of those were draft/proposed — real unstarted work nothing ever asked about.#104 sat five months for exactly that reason. It wasn't untracked — REQ-059 covers it, with no release field. Nothing was deferred or rejected, because nothing surfaced it. Absence of a
release:resembles a decision from a distance;backlogis one.What it looks like
Plus
unscoped_unstartedin the JSON, so tooling doesn't scrape text.Two design choices, both negative-controlled
Only draft/proposed count. An approved artifact with no release is finished work from before scoping existed — a release field on it means nothing. Counting all 601 would report a number nobody can act on, which is the defect class this fixes rather than repeats.
→ Removing the status filter counts 3 instead of 2 and reddens.
Information, not a gate. The
cuttableverdict is untouched. Adding 161 items to a blocking set would make the gate unpassable and read as noise within a day.→ Making it block the verdict reddens the guard.
Verified against rivet's own store
The figure moved from the 165 recorded when filed. Not drift — REQ-059, REQ-247, REQ-250, REQ-252 and DD-074 were given release fields since and left the population. A count that drops as artifacts get decided about is the behaviour wanted; one that never moved would be suspicious.
fmt/clippy -D warnings(1.97.0)cargo test --workspacecargo test -p rivet-cli --test cli_commandsvalidate/docs check/yamllint/diagnose_test.shImplements: REQ-345