refactor(archive)!: use inclusive group ranges

[kixelated]

Problem

Archive callers had to reverse group bounds across related APIs, and direct Key::Groups construction could bypass range validation.

Approach

Use finite RangeInclusive<u64> values in first-to-last order throughout keys, object bounds, validation, decoding, and store reads. Validate empty, reversed, exhausted, and out-of-profile ranges before serialization or decoding while keeping the private filename codec largest-first.

Impact

• Public API: Key::Groups now contains range: RangeInclusive<u64> instead of separate largest and smallest fields.
• Public API: Key::groups, Store::get_groups, Object::decode_groups, and Object::check_bounds now accept RangeInclusive<u64>.
• Public API: Object::bounds now returns RangeInclusive<u64>.
• Wire/persisted format: unchanged. Existing largest.smallest paths and segment bytes are preserved.

Alternatives

A new archive-specific bounds type was rejected because the standard inclusive range expresses the finite contract directly.

Follow-ups

None.

(written by GPT-5)

[moq-bot]

No issues found.
Verdict: approve
(Written by Muse Spark)

opencode session  |  github run

[coderabbitai]

Understand this PR’s impact

Explore downstream dependencies and potential security impact with Blast Radius.

View blast radius →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 3b4e9bc8-f675-4bd0-81ff-c0c861027ac7

📥 Commits

Reviewing files that changed from the base of the PR and between 162da68 and 771c83b.

📒 Files selected for processing (8)

• quest/m0/README.md
• quest/m0/archive-ranges.md
• quest/m1/release.md
• rs/moq-archive/src/error.rs
• rs/moq-archive/src/lib.rs
• rs/moq-archive/src/path.rs
• rs/moq-archive/src/segment.rs
• rs/moq-archive/src/store.rs

💤 Files with no reviewable changes (3)

• quest/m0/README.md
• quest/m1/release.md
• quest/m0/archive-ranges.md

Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review.

---

Walkthrough

The archive range API now uses RangeInclusive<u64> values instead of separate largest and smallest bounds. Keys, segments, and stores use the new representation. Range validation covers endpoints, inverted ranges, and exhausted ranges during construction and serialization. Tests and crate documentation use inclusive range syntax. Related quest planning and release checklist entries were removed.

Priority: ➖ Normal

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: refactoring archive group bounds to use inclusive ranges.
Description check	✅ Passed	The description accurately explains the API refactor, validation changes, and unchanged wire and persisted formats.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 25 functions across 5 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

✨ Simplify code

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kixelated]

Recommendation: MERGE

Positive improvement? Yes. Callers no longer reverse-order group bounds between Object::bounds and Key::groups / Store::get_groups / decode_groups / check_bounds. Using RangeInclusive<u64> matches Rust's inclusive-range convention and moq-net's RangeBounds style, while keeping the private filename codec largest-first so the wire and persisted layout stay byte-identical.

Worth the complexity? Yes. The change is a focused breaking rename for a 0.0.1 crate, not a new bounds type. Validation is centralized in check_range (empty, reversed/exhausted, out-of-profile IDs) and reapplied on serialization so a hand-built Key::Groups cannot bypass checks.

Different approach? A custom Bounds type was rightly rejected — RangeInclusive already expresses the finite inclusive contract. The tests cover singleton/sparse ranges, inverted construction, exhausted iterators, ID endpoints, and round-trip through put/get.

Ship it.

This is an automated review, not the maintainer's decision
(Written by Grok)