plan(v0.35): cut what shipped, split the remainder - #866
Merged
Conversation
Maintainer approved "cut and split". v0.35.0 goes out with what is done; the rest moves with a logged decision rather than silently. v0.35.0 keeps 12 artifacts. Three verified (REQ-274/275/276, the customer UI trio) and nine implemented: REQ-299, 304, 305, 309, 310, 311, 312, 313, plus REQ-303 which is held here while its PR (#864) is in flight. Every issue a human reported this cycle — #848, #852, #853, #854, #856 — is fixed in this set, which is the release's identity. The implemented ones stay `implemented` rather than being rounded up to `verified`: each carries a named undischarged clause (the --fail-under policy on REQ-309, the git: fallback on REQ-312, release-status categories on REQ-313). Shipping them is not the same as claiming their acceptance is complete. Holding the release until every clause is discharged would recreate, at release scope, exactly the deadlock REQ-313 exists to detect: a criterion that can only be discharged by a release shipping. v0.36.0 takes 4 — the gate-potency and verification-evidence cluster that keeps costing diagnosis mid-tick: REQ-295 (nested-workspace scan, Defect 1 already shipped in #830), REQ-306 (#807 Defect 2, name-existence vs command-reachability), REQ-307 (#812 residual, 52 flat top-level commands), and REQ-314 (27 test files resolve the binary at runtime, so nextest with a custom CARGO_TARGET_DIR cannot find it). Backlog takes 9, in two groups. Older features that have not converged in three weeks — REQ-281, 282, 285, 286 date from Aug 4-7, plus REQ-292, 296, 301 — and two items that need a design decision before they can be scheduled at all: REQ-300 (assisted authoring) and REQ-308 (per-clause verification, which needs clauses to become addressable and is therefore a schema migration across every artifact). Putting a version label on those would move the stall, not resolve it. Also corrects the fourth instance of status drift this cycle: REQ-304 and REQ-305 shipped in #863 earlier today and were still `proposed`. REQ-299 (shipped 6b3be3c) and REQ-309 were corrected previously. Shipping code and leaving the artifact behind is now a recurring failure of mine, not an isolated slip. Confirmed with rivet validate (exit 0), rivet docs check (exit 0), YAML parses, 284 artifacts, no duplicate ids. Refs: REQ-303, REQ-304, REQ-305, REQ-314
📐 Rivet artifact delta
Graphgraph LR
REQ_303["REQ-303"]:::modified
REQ_304["REQ-304"]:::modified
REQ_305["REQ-305"]:::modified
REQ_315["REQ-315"]:::added
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
Added
Modified
Posted by |
…eps causing it REQ-303 shipped in #864 and was still `proposed`. That is the fifth instance in one release cycle — REQ-309 (#850), REQ-299 (6b3be3c), REQ-295 (#830), REQ-304 and REQ-305 (#863, found still proposed within the hour), and now REQ-303 — all mine, all caught only by manual audit. REQ-315 records the cause rather than the instances. A trailer is a LINK, not a state transition: `rivet commits` checks that trailers reference real artifacts and nothing checks the converse, that an artifact a merged commit claims to implement is no longer sitting at `proposed`. Release readiness is defined as a query over `release:` + `status`, so the effect is that shipped scope reads as unshipped and a human has to re-derive the truth from git log — the same defect class this tool exists to prevent, in its own artifacts. The proposed check reports; it does not auto-advance. Whether shipped code discharges every acceptance clause is a judgement (REQ-308), and a tool that flipped status on the strength of a trailer would manufacture precisely the false confidence REQ-308 is about. Confirmed with rivet validate (exit 0), rivet docs check (exit 0), 285 artifacts, no duplicate ids. Implements: REQ-303 Refs: REQ-308, REQ-315
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.
Maintainer decision: cut and split.
v0.35.0 keeps 12
3 verified — REQ-274/275/276, the customer UI trio.
9 implemented — REQ-299, 304, 305, 309, 310, 311, 312, 313, plus REQ-303
(held here while #864 is in flight).
Every issue a human reported this cycle is fixed in this set — #848, #852,
#853, #854, #856. That's the release's identity.
Why
implementedand notverifiedEach carries a named undischarged clause — the
--fail-underpolicy on REQ-309,the
git:fallback on REQ-312, release-status categories on REQ-313. Shippingthem isn't the same as claiming acceptance is complete.
Holding the release until every clause is discharged would recreate, at release
scope, exactly the deadlock REQ-313 exists to detect: a criterion that can
only be discharged by a release shipping.
v0.36.0 takes 4 — the cluster that keeps costing diagnosis
CARGO_TARGET_DIRcan't find itBacklog takes 9, in two groups
Not converging — REQ-281/282/285/286 date from Aug 4–7 and haven't moved
in three weeks, plus REQ-292, 296, 301. Three weeks of not being picked is
evidence they aren't next, not that they need another label.
Need a design decision before scheduling — REQ-300 (assisted authoring) and
REQ-308 (per-clause verification, which requires clauses to become addressable
— a schema migration across every artifact). Putting a version on those would
move the stall, not resolve it.
Status drift, fourth instance
REQ-304 and REQ-305 shipped in #863 earlier today and were still
proposed.REQ-299 (shipped
6b3be3c) and REQ-309 were corrected previously.Shipping code and leaving the artifact behind is now a recurring failure of
mine, not an isolated slip. Worth a mechanical guard — a check that an artifact
named in a merged commit's trailers isn't still
proposedwould have caught allfour.
Verification
rivet validateexit 0 ·rivet docs checkexit 0 · YAML parses · 284artifacts · no duplicate ids.