Repository navigation
quest: plan headless browser sources; move publish-independently to m2 - #53
Conversation
… new m2 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 41 minutes. View limit details
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. |
kixelated
left a comment
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit ebd0e5d. No actionable findings. Deferring independent publishing and investigating clipboard and GPU behavior before removing Xvfb is a reasonable direction; the plan keeps the decisions and dependencies clear.
Verification: GitHub-only static review of the planning documents and relevant surrounding code. I did not run tests or headless and clipboard experiments.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℹ️ Minor suggestions only, nothing blocking.
Reviewed changes
- New m0 quest for headless CEF — plans
--ozone-platform=headlesson the CPU path, with clipboard and GPU-path checks before droppingxvfb-run. - New m2 milestone — a permanent holding milestone for work with no consumer yet.
publish-independentlymoves to m2 — a git rename plus a dated note, its m0 link removed and the two m1 compose links retargeted.- Quest root index — m2 added and m1's one-liner refreshed.
The tree was validated by hand against moq-dev/quest assets/AGENTS.md (no broken quest links, no stale m0 paths); the quest CLI is not installed in this review environment, so quest check did not run here.
ℹ️ m2 waits behind the m1 epic that needs it
publish-independently now says it waits behind m0 and m1, and m2 is defined as held until they ship. But the m1 compose epic treats independently published tracks as the only way a viewer fetches a source (quest/m1/compose/layout.md:51) and defers its delivery and parity to this quest (quest/m1/compose/README.md:49), so m1 already holds the consumer that would move it up. Naming that in the moved quest or in m2 keeps an agent picking up either epic from reading the tree as a cycle.
Technical details
# m2 holds a quest m1 already consumes
## Affected sites
- `quest/m2/publish-independently.md:25` — "so it waits behind m0 and m1"
- `quest/m2/README.md:11` — "A quest moves up to m0 or m1 when a consumer appears"
- `quest/m1/compose/layout.md:51` — only independently published sources give a viewer fetchable tracks
- `quest/m1/compose/README.md:49` — delivery and parity deferred with this quest
## Required outcome
- The tree says when `publish-independently` moves up to m1 (when viewer-side composition starts), or drops "waits behind m0 and m1" if that epic will be replanned without it.
- This is a one-sentence clarity fix to the moved quest or m2's README, not a change to the milestone decision.big-pickle (free) ｜ 𝕏
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
left a comment
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit 80c610f against ebd0e5d, accounting for the merged base. No new actionable findings. Explicitly retaining GPU work if the CPU path lands first resolves the scope ambiguity and is a sensible direction.
Verification: GitHub-only static review; I did not run tests or headless experiments.
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Headless goal now covers both paint paths — the Goal requires no X server on the CPU path and the GPU (shared DMA-BUF texture) path, matching the PR #49 finding that the GPU process failed EGL under headless.
- GPU path fallback spelled out — the Plan now says to land the CPU path and rewrite the quest to the GPU path's remaining work, with the blocking reason, if the GPU path cannot go headless.
xvfb-runremoval scoped correctly — the Plan now drops the wrapper from therender-swrecipe in thejustfileand notes the nightly job inherits it through that recipe, which matchesjustfile:59-61and.github/workflows/nightly.yml:37.
Both prior inline concerns are fixed in 80c610f: the Goal/Plan scope mismatch is resolved, and the nightly claim now describes the actual inheritance.
big-pickle (free) ｜ 𝕏
Follow-ups the maintainer picked on 2026-11-05 through
/quest-plan.--ozone-platform=headless, so Wayland sessions andjust render-swneed no X server. Check the clipboard under Interact and whether the GPU path can go headless before droppingxvfb-run. It waits on the cef-startup quest (fix(scene): browser sources on the CPU path paint in software #49).Decisions
Review
🤖 Generated with Claude Code
(Written by Claude Opus 5.5)