Two corrections and one promotion, all from evidence rather than inference.
1. The "macOS packaging gap (known, unfixed)" section was WRONG, and it
contradicted the release notes for the same build. It claimed the artifact
is "a bare streamer-tools-camera.so" with a relative libobs install name
that "will not load in OBS.app as it stands". Downloading and inspecting
the shipped streamer-tools-camera-v0.1.0-macos.zip shows otherwise:
- a proper streamer-tools-camera.plugin bundle -- Contents/MacOS/<name> is
Mach-O MH_BUNDLE (what OBS loads), with Info.plist (BNDL, correct
CFBundleExecutable), Contents/Resources/locale/en-US.ini, and both
LiveKit dylibs in Contents/Frameworks/
- install names are right: the module loads
@rpath/libobs.framework/Versions/A/libobs and carries
LC_RPATH @executable_path/../Frameworks, which inside OBS.app resolves to
OBS.app/Contents/Frameworks; @rpath/liblivekit.dylib resolves through
LC_RPATH @loader_path/../Frameworks to the bundle's own copy, and
liblivekit.dylib finds liblivekit_ffi.dylib through LC_RPATH @loader_path.
Nothing points into a build tree.
- all three binaries carry LC_CODE_SIGNATURE, which is not optional:
arm64 macOS refuses to load unsigned code.
The real macOS limitation is different and now stated: the bundle is
arm64-only (no x86_64 slice), macOS 13+. Nobody has still ever opened it in
OBS.app -- well formed and signed is a prior, not a load.
2. Linux and Windows are confirmed working in the OBS GUI: video and audio
both arrive and hold up across a session, Linux by the project owner and
Windows by two directors independently, and the plugin carried a live show
on 2026-09-07. Since listing cameras requires an API call, that also
retires "the WinHTTP backend has never run against a real streamer-tools
server".
Scoped, not inflated: MEASURED A/V sync and latency against the egress path
are still unverified (no drift reported is not a measurement), as is
mid-show publisher restart. The "Not verified anywhere" list is now
deduplicated and says exactly that.
3. The CI table's Windows row still said "Failing, fix pushed and awaiting a
completed run". It is green, after the WinHTTP deadline fix.
Release notes template updated to match, and v0.1.0's published notes have
been regenerated through it so the public page stops repeating the bare-.so
claim.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9