[kixelated]

Plans two follow-ups of queued PRs:

• quest/m0/test-flakes-2/gst-sibling-reannounce.md, from moq-dev/moq#8438, which disabled the flaky moq-gst sibling-reannounce test. The epic README drops its size again now that it has a child.
• quest/m1/webtransport-close-reason.md, from moq-dev/moq#8478: a client's error reads cancelled because the SETUP stream's reset beats the close capsule.

Decisions

Asked in /quest-complete's follow-up planning, 2026-11-11 (maintainer):

• gst flake: ✅ plan it as an [S] child of the m0 flakes epic (rejected: drop it and leave the test ignored).
• WebTransport close reason: ✅ plan it as an [S] quest in m1 (rejected: m3; drop it).

Overlap checked: no existing quest, deleted quest, or open PR covers either.

Public API: none. Wire: none.

Models

Size: XS
Implementer: Claude Code, claude-opus-5-5, high effort

🤖 Generated with Claude Code

(Written by Claude Opus 5.5 with high)

Review

Rewritten by quest review after each round.

• Reviewer: Codex, gpt-6.1-sol, low effort
• Session: 01a1c9cc-c8ed-7c93-ae7e-98f13f7aeb33, round 1
• Head: b079d51
• Base: origin/main at bcc8911
• Score: 10/10, The head adds follow-up plans and updates an epic heading without changing executable behavior, and no actionable defects were found.
• Findings: none

(Written by Claude Opus 5.5 with high)

[coderabbitai]

Pre-merge checks: 2

Failed checks: 2 inconclusive

Check name	Status	Explanation	Resolution
Title check		This assessment has not completed. The check will be retried on the next pre-merge check run.
Description check		This assessment has not completed. The check will be retried on the next pre-merge check run.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[pullfrog]

✅ No new issues found.

Reviewed changes

• quest/m0/test-flakes-2/gst-sibling-reannounce.md (new) — [S] child of the m0 flakes epic that fixes moq-gst's a_reannounced_sibling_instance_does_not_replay_its_finish at its cause and re-enables it.
• quest/m1/webtransport-close-reason.md (new) — [S] quest so a WebTransport client always reads the peer's close code and reason, with WT_SESSION_GONE on session teardown as the proposed mechanism.
• quest/m0/test-flakes-2/README.md — title drops [S] now that the epic has a child.

Every claim in the diff checks out against the tree: the test exists at rs/moq-gst/src/source/imp.rs:4706 inside mod session_tests and asserts exactly one Seen::Start on the pad (the reported "2 starts instead of 1"); session_gone exists at rs/moq-tokio/src/quic/web/error.rs:137 and rs/moq-uring/src/quic/web.rs:921, both returning Error::SessionGone until the reason is recorded, and nothing sends WT_SESSION_GONE today; and dropping the epic's size tag matches the convention (quest/m0/ci, quest/m0/nightly, quest/m1/audio-jitter-target and quest/m1/stream-credit carry children and no tag, while childless quest/m0/interop-green keeps [XS]). Neither m0 nor m1 lists its direct children, so no milestone index edit is missing, and neither topic has an existing or deleted quest that already covers it.

ℹ️ Both source PRs are still open, so both plans rest on their landing

The gst quest describes #8438 as having disabled the test, but on main the test still has no #[ignore] and sh/gh/test-inventory.allow has no entry for it; likewise #8478's version-refusal symptom is the premise of the WebTransport quest. That is normal for the queue-then-plan flow, but if either PR is dropped or reshaped, its quest needs to move with it rather than outlive the premise.

Technical details

# Plans depend on unmerged PRs

## Affected sites
- `quest/m0/test-flakes-2/gst-sibling-reannounce.md:11` — "#8438 disabled it after one failure" describes an open PR; `rs/moq-gst/src/source/imp.rs:4706` and `sh/gh/test-inventory.allow` contain no quarantine on `main` yet.
- `quest/m1/webtransport-close-reason.md:13` — same shape, built on #8478's `err=cancelled` observation.

## Required outcome
- Nothing to change in this PR. When either source PR is amended or abandoned, the corresponding quest file is updated or deleted in the same change, per the repo's rule that a quest deletion drops the file plus every inbound link.

## Open questions for the human
- If #8438 lands pointing its inventory entry at the epic README rather than this child, does the child still own the re-enable step?

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) ｜ 𝕏}