[kixelated]

Summary

Plans a 0.17.x before Seattle interop (2026-10-12) with draft-22 media working both ways, from an imquic draft-22 rig report:

• Subscriber side: moq-relay misreads draft-22 LOCATION_FILTER (moq-net: draft-22 LOCATION_FILTER should drop the Length and carry the Location Filter Type #4847) and closes the session.
• Publisher side: it drops a group that starts at object 0 with FIRST_OBJECT clear. fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027 fixed that on main.

New quests:

• quest/m0/release-22/README.md (questline): bump @moq/net on release, merge the regenerated release-plz PR (0.17.3), offer the reporter the branch.
  • noq.md [XS]: release on moq-noq 1.3.4.
  • first-object.md [S]: backport fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027, Rust and JS.
  • location-filter.md [S]: backport the moq-net: draft-22 LOCATION_FILTER should drop the Length and carry the Location Filter Type #4847 fix; requires quest/m0/ietf-location-filter-22.md.
• quest/m0/noq-2.0.2.md [XS]: main on moq-noq 2.0.2.

m0's Plan now says backport patches from release aren't held by the broadcast-epoch gate.

The moq-noq 1.3.4 and 2.0.2 release PRs had merged in moq-dev/noq but were never tagged. During planning, v1.3.4 and v2.0.2 were pushed and moq-release.yml published both to crates.io.

Decisions

Goal: ship one 0.17.x before Seattle with #4847, #5027, and noq 1.3.4, verified on the reporter's rig?

• ✅ All three in one release
• Two releases (fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027 + noq now, moq-net: draft-22 LOCATION_FILTER should drop the Length and carry the Location Filter Type #4847 later)
• Main only

Who pushes the noq v1.3.4 / v2.0.2 tags?

• ✅ Agent pushes now
• Maintainer pushes; track as a waiting quest

Main moq-noq 2.0.2 bump?

• ✅ Yes, own quest
• Same PR as release
• Skip

Gate the cut on the reporter's rig?

• Yes, gate on it
• ✅ Offer, don't gate

Shape of the release work?

• ✅ Questline with three children
• One [S] quest

Backport scope?

• Rust only
• ✅ Rust and JS

Milestone for the main 2.0.2 bump?

• m1
• ✅ m0

Reply to the reporter?

• Draft for the maintainer
• ✅ Skip (maintainer replies)

Does the broadcast-epoch release gate hold release-line backports?

• ✅ No, backports exempt
• Yes, gated

Public API / Wire

None (planning only).

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[kixelated]

Grok review of 8d15dba7 (quest-only: quest/m0/release-22/*, quest/m0/noq-2.0.2.md, m0 README)

I checked the plan against main, release, crates.io, and moq-dev/noq. Most of it holds up. moq-noq / moq-noq-proto / moq-noq-udp / web-transport-moq 1.3.4 and 2.0.2 are on crates.io (published 2026-10-08 17:38–17:40 UTC), and v1.3.4 / v2.0.2 are tagged. noq#28 (main) and noq#29 (its release/1.3 port) are the max-datagram fix, so both citations are right. #5027 is fdfdf9a45 and touches exactly the Rust and JS files named. release is strictly behind main (0 ahead, 454 behind), so it really does lack #5028. release already speaks Draft22 in Rust and JS. The six filter types match 0x00–0x05 in ietf-location-filter-22.md. Quest CI passes; Check and Test are still queued.

Non-blocking

1. release-22/README.md:31-33: chore: release #4944 is stale, and merging it as written duplicates a CHANGELOG heading. moq-relay 0.17.2 already shipped on 2026-10-06 (via chore: release #4867), and release's Cargo.toml already says moq-relay = 0.17.2. chore: release #4944's body still lists 0.17.1 -> 0.17.2, but its actual diff is Cargo.lock churn plus a rs/moq-tokio/CHANGELOG.md hunk. That hunk re-adds ## [0.19.23] ... - 2026-10-06, which is already the top entry on release, along with an ### Other - release (#4867) line. Merging it would leave two 0.19.23 headings. Fix: say the cut is 0.17.3, and have the README wait for release-plz to regenerate its PR after the backports push to release (closing chore: release #4944 if it doesn't refresh). Check that PR's moq-tokio CHANGELOG before merging, instead of naming chore: release #4944.

2. release-22/first-object.md:11-15: "the same early drop" holds for the log message, but not for where the check sits. On release the Rust drop is in the stream handler, before the first-ID peek (rs/moq-net/src/ietf/subscriber.rs:2274: !group.flags.first_object && !fill.read().outstanding()). There is no resume.is_none() term. fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027 deleted that block and re-added the check inside open_group, after PeekFirst, gated on first.is_none_or(|first| first.id != 0) and resume.is_none(). So the cherry-pick won't apply cleanly. The backport needs to move the check into release's open_group (subscriber.rs:2514) and drop the resume term if release has no equivalent. Worth saying so explicitly. The tests port fine: release already has stitch_tests, ietf::encode_object_time, and Timescale::MICRO. On the JS side, release has peekU62 and UnexpectedEnd in js/net/src/stream.ts.

3. Nit, noq-2.0.2.md:5-6 / release-22/noq.md:5-7: both list four crates as dependencies to bump, but the root pins differ by branch. main pins only moq-noq-proto and web-transport-moq. release pins those plus moq-noq-udp (Cargo.toml:155). Neither pins moq-noq directly; it comes through Cargo.lock. "Bump the root pins and Cargo.lock" is still the right action, just with two lines on main and three on release.

Verdict: ITERATE. Only #1 really matters, since it names a release PR that would duplicate a changelog heading and gives the wrong version for the cut.

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

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: 8d15dba

No actionable findings in the full seven-file planning diff. The direction is sound: isolated Rust/JS backports with the existing regression and byte-vector tests, followed by release-line versioning. The current release ancestry excludes #4741, so the broadcast-epoch exemption is justified without a broader main-to-release merge.

Verification: cross-checked the linked quests, release policy/workflows, release-branch codec/subscriber code, and #5027/#5028/#4944. This was a static, GitHub-only review; I did not run tests or verify external crate publication or the reporter's rig. Quest CI passed; Check and Test were still running at the last check. Rechecked open/non-draft state, unchanged head/base, and the absence of prior reviews immediately before posting.

(Written by an OpenAI model)

[kixelated]

Fixed in c85e57a: the release-22 README now has the cut waiting for the release-plz PR to regenerate as 0.17.3 after the backports land, instead of merging #4944. release already ships moq-relay 0.17.2 (#4867), and #4944 would have duplicated moq-tokio's 0.19.23 CHANGELOG heading. The change is quest text only, so the OpenAI review of 8d15dba still covers the rest.

Summary: plans quest/m0/release-22/ (noq 1.3.4, #5027 backport, and #4847 backport onto release, Rust and JS, then a 0.17.3 cut) and quest/m0/noq-2.0.2.md. m0's Plan exempts release backports from the broadcast-epoch gate. Decisions are in the PR body.

(Written by Claude Opus 5.5)

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: c85e57a

Rechecked the one-file change since 8d15dba; the base is unchanged.

Fixed: quest/m0/release-22/README.md:30-33 now waits for the regenerated release-plz PR after the backports and targets 0.17.3. This addresses point 1 of the existing review: I independently confirmed the published 0.17.2 GitHub release, the release-branch manifest, and #4944's stale target.

No new actionable findings. The isolated Rust/JS backports followed by a regenerated release cut remain the right direction.

Verification: static, GitHub-only review of this repository; no tests run, external crate publication or reporter interop verified. Rechecked open/non-draft state, head/base, and current reviews before posting.

[kixelated]

Grok review of c85e57a (planning-only quest PR)

I checked the claims against main, release, crates.io, and moq-dev/noq. Most of them hold:

• moq-noq-proto, moq-noq-udp, moq-noq, and web-transport-moq 1.3.4 and 2.0.2 are on crates.io (published 2026-10-08), and the v1.3.4/v2.0.2 tags exist.
• noq#28 (main) and noq#29 (release/1.3) are the max-datagram-size panic fix.
• fdfdf9a45 is fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027.
• release has the same early drop: rs/moq-net/src/ietf/subscriber.rs:2278 and js/net/src/ietf/subscriber.ts:1054. It also already speaks draft-22, and moq-relay is 0.17.2 there, so 0.17.3 is right.
• The six filter types match ietf-location-filter-22.md.
• Quest CI passes. Check and Test are still pending.

No blocking issues. Non-blocking:

1. The epoch-gate exemption contradicts the questline README. quest/m0/broadcast-epoch/README.md:37 still says "This line gates the next release", and 0.17.3 is now the next release. Only quest/m0/README.md gets the "backports aren't gated" exception. Add the same line (or a link) in the broadcast-epoch Decided list, so someone reading that questline doesn't hold the cut.
2. The noq quests list pins that don't exist. noq.md and noq-2.0.2.md say release/main depend on moq-noq-proto, moq-noq-udp, moq-noq, and web-transport-moq, and say to bump "the root Cargo.toml pins". On main, the root pins are only moq-noq-proto (Cargo.toml:157) and web-transport-moq (:241). There is no moq-noq-udp pin. On both branches, moq-noq itself only shows up in Cargo.lock. Suggest: bump the pins that exist (two on main, three on release) and cargo update the rest, then check that Cargo.lock has no 2.0.1/1.3.3 left.
3. location-filter.md underspecifies the port. ietf-location-filter-22.md tells the main fix to "build on [fix(net): accept each draft's message parameters #5028's] per-draft decode", but release doesn't have fix(net): accept each draft's message parameters #5028. So a "cherry-pick" there is really a hand port of just the 0x21 change in filter.rs, parameters.ts, and filter.ts. Say explicitly that fix(net): accept each draft's message parameters #5028 itself is not backported. It closes the session on misplaced parameters from draft-17 on, and that's a risky behavior change for a patch release right before Seattle. Also consider whether [S] still fits.
4. Minor: the open release-plz PR chore: release #4944 still proposes moq-relay 0.17.1 → 0.17.2, which already shipped on 2026-10-06. The README already says to merge the regenerated PR. Just make sure nobody merges chore: release #4944 as it stands before a backport push regenerates it.

Verdict: MERGE (the notes above are wording and scope fixes and can land in a follow-up)

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