Publish: M153, the sender slice, and what the rollover cost Branch selection had M152 as the chosen stable milestone, which it stopped being on 2026-09-19, and gains a section on what a rollover does to a project mid-flight. Troubleshooting gains the three M153 failure modes, none of which was findable from its symptom: the Windows SDK pin mismatch, disk exhaustion presenting as a linker crash that says nothing about disk, and an Android archive that builds clean and is then rejected by its consumer over bytecode level. Two of those entries say what not to do, because both were tried. Consuming the artifacts gains how to check that bytecode level, and the Mac Catalyst slice writing PrivacyInfo.xcprivacy one directory too deep. The Interop ABI page catches up with the sender parameter and capture format work, including the measurement that contradicted the issue describing it: scale_resolution_down_by survives a capturer that ignores adaptation, because the encoder scales too, so outbound-rtp frameWidth is no evidence about the source. max_framerate is the one only the source can apply.
Windows interop builds; correct the exception guidance The ABI page prescribed try/catch, which cannot compile under WebRTC's -fno-exceptions and is unnecessary anyway. Also records the keep-both decision for webrtc.dll and WebRtcInterop.dll, and gives Windows a partial tier 3 in the figure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mac Catalyst now has its own workflow Documents the split: two Apple workflows sharing one toolchain, differing only in arch list, and the need to pin webrtc_branch across both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Give Mac Catalyst the column instead of macOS Catalyst is what WebRTCme ships and it rides the iOS xcframework, so it now appears as a first-class column in the figure and tables. Native macOS is reduced to a note: built, unconsumed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Correct the macOS framing: built, but not consumed Mac Catalyst is served by the iOS xcframework, so libwebrtc.dylib has no consumer and its missing camera path is not a gap worth closing. The workflows are kept as an Apple-silicon build check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add Platform layers Records what each artifact actually contains: the three-layer model, a capability matrix across all six platforms, who compiles each one, and the three consequences -- no H.264 on desktop, no camera capture on macOS, and screen capture being desktop-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Document the build workflows and branch selection Nine pages covering how a build is dispatched, how the WebRTC branch is resolved from the Chromium dashboard, what each of the eight workflows does, the static-to-shared library patch, how the artifacts feed into WebRTCme, and the failures seen in practice. Source lives in wiki/ in the main repository. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>