The script has no executable bit (git doesn't carry one reliably), so
the bare invocation failed with 'Permission
denied' in the Linux act runs. Every call site now uses
OCIO_RS_ENABLE_REAL=1
OCIO_RS_LINK=static instead.
Linux: 'libffnvcodec-dev' was dropped from Ubuntu noble — the NVDEC
headers are distribution-free, so install them from source
(nv-codec-headers git) like the Fedora branch already did; the
appimage step and install-deps.sh no longer apt-install the package.
Windows: ocio-sys is the GIT fork (pinned in the root manifest), so
the old crate-unpack + build.rs glob patch (registry/cache's
ocio-sys-0.2.1.crate) can never match — git dependencies don't ship a
.crate archive and unpack under registry/src/git/<hash>, hence the
"ls .../ocio-sys-0.2.1/build.rs: No such file" failure. The fork's
build.rs already carries the GNU-toolchain fix; the unpack/glob/sed
step is removed.
Policy change (supersedes the system-first probe): build OpenColorIO
from the vendored sources and link it statically on every platform
that can -- packaged binaries carry no OCIO runtime dependency. The
[patch.crates-io] ocio-sys now tracks shaloong/ocio-rs main
explicitly; its vendored yaml-cpp has the <cstdint> include that makes
the vendored build work on GCC >= 16 (verified on GCC 16.2.1).
Windows/MinGW stays the exception (the vendored source needs MSVC-only
constructs): tooling/ocio-env.sh probes the MSYS2 system OCIO there,
static when libOpenColorIO.a ships, dynamic otherwise. The Linux jobs
drop the system OCIO dev packages the system-first policy needed.
- Install ffnvcodec headers everywhere the project FFmpeg is built
(distro packages on Debian/Ubuntu/Arch/MSYS2, nv-codec-headers from
source on Fedora) so the FFmpeg build picks up NVDEC/NVENC.
- ocio-sys 0.2.1's vendored yaml-cpp misses <cstdint> and fails on
GCC >= 16 (measured on GCC 16.2.1); patch the dependency to the
fixed upstream tree (shaloong/ocio-rs, 933c65dc) until a fixed
release lands on crates.io.
- New tooling/ocio-env.sh decides the OCIO build env per job: system
OCIO >= 2.5 when present (static when the package ships
libOpenColorIO.a, dynamic otherwise), vendored static build as the
fallback. The Arch package gains an 'opencolorio' dependency only
when the binaries link the system OCIO (build-pkg.sh probes ldd).
- CI 'Build' steps switch from cargo build to cargo check: the Test
step links the test binaries anyway, and a full build would codegen
every workspace crate twice.
Gitea prep: .github becomes .gitea (the act runner looks there), and
every actions/cache + Swatinem/rust-cache step is commented out until
the self-hosted instance has a cache provisioned. The remaining
marketplace actions (checkout/upload-artifact are act-compatible;
msys2/setup-msys2, dtolnay/rust-toolchain and softprops/action-gh-release
need a runner test / replacement) are a follow-up.
tests: the two gpui keystroke tests that flaked on Windows CI (undo
pair, snapping toggle — each once, values identical to the pass state,
Global-route keys) now dispatch each key with a double park. The root
cause is not fully pinned: the loss happens inside gpui's synthetic
key dispatch on Windows (both tests hold every test lock; production
is unaffected). The CI retry-once remains the backstop. The earlier
idea of advancing the simulated clock to flush gpui's pending-input
timer is off the table: the mock engine's playback ticks with executor
time, so a clock advance moves the playhead out from under the
assertions (observed: playhead 14 vs expected 9).
Two different gpui keystroke tests flaked on Windows CI with the same
signature: a synthetic keystroke occasionally never reaches the action
(secondary-z lost while secondary-shift-z delivered; then a plain 's'
lost). Both passed every other run — a gpui test-harness delivery
flake, not an oak regression. A single retry pass absorbs it; a real
regression fails both passes.
oakstorage: the sqlite URI parse tests used /tmp/lib.db, which is not
absolute on Windows, so parse_target's is_absolute check rejected it.
Pick the absolute path per platform (C:/tmp/lib.db on Windows).
ci (Linux): wrap the test step in a 1500 s watchdog — a deadlocked
test prints nothing and never fails; on timeout the watchdog dumps
every test/worker process's thread stacks with gdb and then kills the
suite. (One such hang already ate a run; the previous green run needed
~4 min.)
ci+cd: Swatinem/rust-cache gains cache-on-failure everywhere, so a
red run still saves its compile cache (the actions/cache FFmpeg cache
already saves in its post phase regardless of outcome).
Windows: tooling/package/bundle-dylibs-windows.sh collects the MSYS2
runtime DLLs (libstdc++, libgcc, OpenColorIO, ...) with ntldd -R,
iterated to a fixpoint over freshly copied DLLs; a packager resources
glob places them next to the executables in the NSIS installer.
macOS: tooling/package/bundle-dylibs-macos.sh copies every non-system
dylib otool reports into Contents/Frameworks, rewrites the install
names to @executable_path/../Frameworks to a fixpoint, and ad-hoc
re-signs every modified Mach-O (rewriting invalidates the seal).
The CD package version no longer comes from the git tag: the root
Cargo.toml gains [workspace.package] version = "0.5.0", the oak
package inherits it (version.workspace = true — which cargo-packager
also picks up), and the Linux container packaging parses that field.
oakcodec: gate find_ffmpeg_searches_path to unix (chmod 0755 + shebang
fixture) and make find_ffmpeg_missing_returns_empty assert absoluteness
instead of a '/' prefix so the tests compile and pass on Windows.
ci (Windows): export RUSTFLAGS=-C link-args=-lmsvcrt in the build and
test steps. mingw-w64 (Nov 2025) forwards _assert to __msvcrt_assert
inside libmingwex.a, and rustc's link order leaves -lmingwex last, so
binaries that pull _assert.o (oakcommon's real_ocio test) fail to link;
a trailing -lmsvcrt re-scans the CRT import lib afterwards.
ci (Linux): copier_test dies inside ld.so before printing anything.
Replace the LD_DEBUG probe with stronger forensics: exported dynsyms
(interposition suspects), strace tail, valgrind tail, and siginfo
(si_code/si_addr) from the gdb run.
oakaudio: drop cpal's `asio` feature. asio-sys needs the proprietary
Steinberg ASIO SDK at link time (undefined ASIOGetSamplePosition etc.
on the GNU toolchain); WASAPI remains the Windows backend.
ci: the failure-only gdb step passed test args without --args, so gdb
treated --nocapture as a core file. Also collect loader-stage evidence
for the copier_test dl_main SIGSEGV: IRELATIVE reloc count, LD_DEBUG
tail, full backtrace and registers.
- localtime_s/gmtime_s are MinGW header inlines, not symbols — link
_localtime64_s/_gmtime64_s
- copier_test also segfaults only on the Linux runner; add it to the
on-failure gdb backtrace
- oakffmpeg-link forwards pkg-config --static --libs verbatim; FFmpeg's
.pc files can list -ldl via external deps, and MinGW has no libdl
- suites_test segfaults on the Linux runner too; run both plugin test
binaries under gdb on test failure
The crate's build.rs unconditionally adds the MSVC + Windows SDK
include dirs on Windows (for MSVC hosts); on the GNU toolchain that
breaks the bridge compile with MSVC-only headers. The runner's job
hook re-exports INCLUDE/LIB per step, so the in-step unset did not
help — patch the extracted build.rs instead (both the env-var failure
modes are now documented in the step comment).
- the warp runner's job hook re-exports MSVC INCLUDE/LIB per step, so
the GITHUB_ENV clear did not stick — unset in the Build/Test steps
themselves
- node_e2e_test segfaults only on the Linux runner; rerun the binary
under gdb on failure to capture the native stack
Each distro package builds inside that distro's container so declared
dependencies always resolve to native names: hand-rolled deb via
dpkg-shlibdeps + dpkg-deb, rpm via rpmbuild's auto-requires, Arch via
makepkg (non-root builder user). git/curl install before checkout
(container jobs). AppImage keeps cargo-packager on the Ubuntu runner.
The release gates on all four package jobs plus macOS/Windows.
- the Windows runner image exports MSVC's INCLUDE/LIB; cc-rs was
appending the MSVC SDK headers to MinGW compiles (vcruntime.h not
found)
- oak-worker handshake test helper advertised the input pool's total
byte size as per-slot data bytes (macOS tolerated the oversized
attach; Linux correctly rejects it)
- hw/sw decode comparison tolerance 0.05 -> 0.08 (VideoToolbox's
YUV->RGB legitimately differs by ~1 LSB of intermediate depth)
- the vendored OCIO source needs MSVC-only constructs (wide-path
ifstream); MSYS2's mingw build of the exact 2.5.2 the bridge targets
is the sane Windows path — DLLs get packaged next to the binaries
- oak-worker handshake test prints the error response on failure
(CI-only attach failure needs the message)
- rust-toolchain sets CARGO_HOME to the Windows userprofile path while
the msys2 shell's HOME is elsewhere — the yaml-cpp patch targeted an
empty directory and the assertion ls failed
- examples/screenshot.rs uses the macOS-only VisualTestAppContext; its
items are now cfg-gated with a non-macOS stub main so workspace test
builds pass on Linux/Windows
On a fresh runner registry/src has no hash subdir yet, so the unpack
glob never expanded and the step exited 2; derive it from the cache
dir and assert the patched file exists at the end.
- cargo fetch does not extract sources; the yaml-cpp <cstdint> patch
now untars the .crate into the registry src dir first (the glob
found nothing and the step failed with exit 2)
- oakaudio: the watchdog-wrapped audio test called Self::... from a
free-function test module (compile error in lib test)
- Linux: libxkbcommon-x11-dev for the gpui X11 client link
- Windows: patch <cstdint> into the vendored yaml-cpp (a cached cmake
configure ignores CXXFLAGS; the patch is idempotent and runs after
cargo fetch)
- macOS: the hw-decode test skips its VideoToolbox engagement
assertions on hosts where VT cannot initialize (headless/virtualized
runners) instead of failing
- display color management: the display ICC (system or custom) is
applied to viewer frames at present time (F32 in place, or in place
on the BGRA staging copy with the R/B swizzle baked into the OCIO
chain); preferences get a Color section (mode + custom ICC file); on
macOS the Metal layer is tagged with the display colorspace when
self-managing so ColorSync passes pixels through (no double
correction); frame caches track the transform generation so a mode
or profile change drops stale pixels
dpkg-shlibdeps over the three shipped binaries resolves every NEEDED
library to exact build-distro package names (FFmpeg/OCIO are static so
only base-OS packages appear) and rewrites the deb's Depends. Distros
with divergent package names (openKylin) get their own build instead
of a wrong-name dependency list.
Static FFmpeg + static OCIO leave only base-OS libraries; the audit
step prints objdump NEEDED for each packaged binary so any accidental
dynamic dependency (and any distro-specific package-name surface) is
visible in the build log.
- OCIO_RS_LINK=static everywhere: the vendored OCIO is linked into the
binaries statically — the package carries no OCIO dependency
- Linux: libasound2-dev (alsa-sys), libpulse-dev, libsndfile1-dev —
the full audio dev set
- Windows: -include cstdint for the vendored yaml-cpp (pre-GCC-13
transitive includes)
- Windows: install MSYS2's own Rust (x86_64-pc-windows-gnu host); the
rustup MSVC toolchain is not on the msys2 shell's PATH and the MSVC
linker rejects the Unix-style link args the build scripts emit
- Linux: libpipewire-0.3-dev + libspa-0.2-dev for libspa-sys (gpui's
Linux screen-capture/audio stack)
The distro OCIO is too old for the bridge's API floor where it matters
(Ubuntu 24.04 ships 2.1; the bridge uses 2.4+ APIs), and version drift
across platforms is a support hazard — enable ocio-rs' bundled feature
and drop the OCIO_INSTALL_DIR/system-package wiring from CI and CD so
Linux, macOS and Windows all build the same vendored OCIO. cmake/make/
diffutils added where the runners lack them (Windows FFmpeg build needs
make + cmp).
- serializer resolves node types through the factory's dynamic
(runtime-registered OpenFX) entries, so a project carrying plugin
nodes loads again (was: "unknown node type"); covered by a new
CI-gated round-trip test driving the real fixture plugin
- built-in effect nodes expose their inputs as inspector parameters
like the C++ parameter editor: localized input names from the
behavior, combo option tables via the new
NodeBehavior::input_combo_strings (16 nodes, string-for-string from
the C++ set_combo_box_strings), connection/data inputs excluded
- effect library: live drag-and-drop — onto the inspector's effect
stack (lands at the indicator position) and onto the node editor
canvas (creates the node at the drop point); double-click still
appends to the selected clip
- inspector parameter controls are no longer recreated per render
(gpui stack view caches them per effect), so sliders drag and
checkboxes click; the view observes the engine and silently re-syncs
values (undo/redo land on the widgets)
- timeline: left-press selects clips (plain/keep-multi/Ctrl-Cmd
toggle); clip moves clamp the shared delta so no clip of a linked
group lands before frame 0 instead of failing with "invalid move
target"
- oakplugin: createInstance-rejected instances skip the destroyInstance
notification (the plugin never owned them); vendor-suite fetchSuite
misses moved behind OAK_OFX_TRACE; the worker logs the discovered/
registered plugin counts
- CI: the OFX probe step also runs the serialization round-trip test
- gpui submodule: params view caching, clip click-select, library
drag payload, graph_position_at
- new minimal C OFX plugin fixture (ci_test_plugin.c) compiled into a
real .ofx.bundle by build_fixture.sh; the CI step points
OFX_PLUGIN_PATH at it and asserts the scan_probe example discovers
AND registers it (Linux/macOS)
- host bundle binary search now also covers the OFX-standard Win64
platform directory
- cd.yml: restore the Windows NSIS packaging job (obsolete oakengine
cdylib prebuild dropped) and repair the job indentation that had
silently detached the macos/release jobs from the jobs: map;
releases now gate on all three platforms
- save() writes <config>/config.toml (atomic temp+rename), flat keys
at the top level and group/sub keys as [group] tables, values as
native TOML int/float/bool/string (non-finite doubles degrade to
strings and restore via the declared type)
- load() prefers config.toml; a legacy config.ini (C++ or pre-TOML
Rust builds) is read once and immediately re-persisted as TOML; the
INI file is left in place; a corrupt TOML is reported, never
silently discarded
- cd.yml: drop a stale oakengine comment (the crate is retired)
- oakengine is now cdylib-only (no rlib/staticlib consumers anywhere;
cargo tree verified) — the plugin/external C ABI layer; README and
docs updated
- cd.yml drops the dylib embedding/re-sign steps (the app no longer
links it)
- test race root-caused and fixed for good: the global undo stack lock
is now a re-entrant mutex (parking_lot) shared by every test that
drives the stack, including the previously unlocked node/render
families; the render-manager serial-ordering bug (an earlier repro
test initialized the global manager before the not-initialized test)
is fixed with a shared SERIAL guard and a manager shutdown
- 5 consecutive parallel runs clean; serial 209/209
CI matrix: warp-ubuntu-latest-x64-8x / warp-macos-15-arm64-6x /
warp-windows-latest-x64-16x (the macOS steps were still in place, only
the matrix entry was missing). CD: macOS DMG job re-enabled on the warp
Apple Silicon runner; linux and release jobs back on warp-ubuntu;
Windows NSIS stays disabled until the engine links there.
- every job builds -p oakengine first (the dylib is a build-dep-only
artifact otherwise and cli/worker link-search the profile dir)
- 512px icon (tauri-icns only maps 512@1x/1024@2x); dylib embedding
derives the path from the binary's otool reference; fpm invoked from
the gem bin dir; GITHUB_ENV blocks batched (SC2129); actionlint.yaml
whitelists the warp runner labels
- Windows job disabled with a reference block until the engine links
there
- real run: Oak-macOS-arm64.dmg produced, app launches from the volume
(known gap recorded: the dmg still dynamically links Homebrew codec
libs; not self-contained yet)
- CI: push/PR to main only; ubuntu/macos-15-arm64/windows-ucrt64 matrix;
deps via tooling/install-deps.sh; project FFmpeg built once and cached
under .cache/ffmpeg keyed on the build script; rust-cache for target/
- CD: tag v* packages with cargo-packager — deb/AppImage/pacman on
Linux (rpm converted from the deb with fpm), NSIS on Windows, and a
DMG (Apple Silicon) whose .app embeds liboakengine.dylib via
install_name_tool; tag pushes publish a GitHub release with all
packages attached
- root Cargo.toml gains [package.metadata.packager]; the app icon is
generated from Oak_Icon.svg with rsvg-convert in CI
- root build.rs now also links the app on Linux (link-search + rpath +
--export-dynamic); Windows remains blocked on the DLL undefined-symbol
problem (oakcore_* host imports), documented in build.rs
Compiler hygiene (all platforms):
- Silence warnings across the tree: missing override, -Wreorder ctor
init, -Wshadow, -Wsign-compare, missing switch cases, unused
functions/captures, Qt 6.11 deprecations (QMouseEvent/QDropEvent
accessors, qAsConst, Q_FOREACH over non-shared containers,
AA_UseHighDpiPixmaps) and the .bak/ backup tree removal.
- Fix regressions from the cleanup: missing clip decls in
capi/timeline.cpp, plugin.cpp rename fallout, panel setFocus
ambiguity, QGraphicsItem::pos vs event->position(), duplicate
k_push_button case, boolean test variable.
Windows:
- Qt portability: CommandLineParser is_set/add_option, QTimeZone
systemTimeZone (QTimeZone::LocalTime is 6.11-only), k_progress_* enum.
- Linking: stop adding oakengine to OLIVE_LIBRARIES (import lib plus
oakengine-obj caused multiple definitions); add OAKENGINE_STATIC so
internal consumers no longer reference __imp_* stubs.
- oakengine.ver: export olive::Renderer typeinfo so liboakgl.so can be
dlopened (Linux), DynamicRenderer no longer dlcloses backend libraries
(crash in RenderManager's dtor calling into unmapped memory).
- OTIO runtime: copy DLLs next to every binary on Windows instead of
relying on PATH (0xc0000135 in gtest discovery).
- Headless GL: the runner only has GDI OpenGL 1.1, killing every render
worker. Deploy Mesa llvmpipe as opengl32sw.dll (Qt's software-GL
channel) with QT_OPENGL=software, and let QT_OPENGL override the
AA_UseDesktopOpenGL default. ExportTask fails fast after 8 consecutive
undelivered frames instead of segfaulting or grinding forever;
FFmpegEncoder::write_frame tolerates null frames.
- Tests: GetTempPathA+PID temp dirs, GetLongPathNameA for 8.3 names,
forward-slash normalization when comparing project filenames.
Linux:
- Install libshaderc-dev so oakvulkan compiles GLSL (Vulkan tests).
- Accept UNORM floor-or-round (63/64) in the blit ping-pong test.
- Skip MainWindow construction test on the offscreen QPA (cannot paint
QOpenGLWidget).
Also: oak_cli_transcode gets a 300s ctest timeout, worker logs GL
context version and LoadGraph/render_frame stages, and
docs/plans/eliminate-event-bridge-issues.md (English translation).
Install libvulkan-dev + mesa-vulkan-drivers (lavapipe = software Vulkan,
no GPU needed) and stop passing CMAKE_DISABLE_FIND_PACKAGE_Vulkan so the
Vulkan backend and its tests are built and exercised.
- make_oakengine_gtest embeds oakengine-obj; test code must see
OAKENGINE_API as dllexport too (OAKENGINE_BUILD), otherwise MinGW
resolves nothing against __imp_* stubs
- the render worker intentionally drops QT_QPA_PLATFORM=offscreen and
needs a real display for its GL context; run the Linux ctest and the
filtered gtest steps under xvfb-run
- liboakengine.dll does not export engine-internal C++ symbols
(olive::Renderer, FileFunctions, VideoParams, Texture), so oakgl.dll
failed to link on Windows. Embed oakengine-obj instead (same pattern
as the engine tests); MinGW's name-based RTTI keeps cross-DLL casts
working.
- ci.yml: move to warp runners
- Linux: Qt6 metatype static_assert requires complete types; declare
OakEngineBlock with Q_DECLARE_OPAQUE_POINTER in the public header
(outside extern "C")
- Windows: gtest discovery runs the freshly linked test exe at build
time and it cannot find the DLLs (0xc0000135); copy oakcore/oakengine/
ffmpeg_bridge DLLs next to the test binaries on WIN32
- macOS: Imath header mixing between otio-install's stale bundled Imath
and Homebrew's Imath broke ImathBox.h (V2h undeclared); bump the OTIO
cache to v2 and drop bundled Imath headers so the system one is the
only set in play
- OAK_ENABLE_DYNAMIC_RENDER_BACKEND now defaults ON; it was previously
undefined (OFF) unless passed, so CI configure failed on the
unconditional oakgl target references in app/worker/tests
- add git to the MSYS2 package list in ci.yml and cd.yml; the OTIO
build step runs git clone in the msys2 shell, where git is not
installed by default
- app/ no longer includes engine C++ headers nor holds engine C++ types:
engine access goes through the oakengine C ABI plus C++ wrappers
(oakutil/oaknode.h, oakutil/oakvideo.h) and app-local mirror types
(tooltypes, trackreferencehandle, timelinecommonapp, keyframetypes,
subtitleapp, serializedlayoutinfoapp, nodevaluehandle, sliderdisplaytypeapp)
- engine: new C ABI functions for block/track/clip/transition navigation
and predicates, links, caches, waveform/playback, disk folder,
sequence_track_list, node_free, footage_is_valid, block_get_track,
get_brush; loadotio/saveotio ported to the current engine API
- OTIO is now a required dependency: CI and CD build it on every
platform, FindOpenTimelineIO fixed for OTIO 0.16/0.19 (the old deps
include requirement silently disabled OTIO everywhere), runtime
libraries are bundled into packages and copied next to macOS binaries
(oak_copy_otio_runtime)
- fix ProjectViewModel drag&drop mime read/write size mismatch (segfault)
- unify color label naming (k_olive -> "Oak") in the app-side mirror
- docs: OTIO required, FFmpeg minimum corrected to 6.0 (en/zh)
- gtest suite: 1925 passed, 0 failed
Physical split: app/{audio,cli,codec,common,config,node,pluginSupport,
render,task,timeline,undo,tool,shaders} plus coreengine, version and
ui/icons+colorcoding move to a new top-level engine/ tree, built as
liboakengine.so (shared). The render backends (oakgl/oakvulkan) move
with it and link the engine library instead of embedding a static
render-core subset (libolive-rendercore is gone).
- oak-render-worker now links liboakengine instead of the whole
libolive-editor object set: 336MB -> 2.9MB, no Qt Widgets UI
- the editor links liboakengine for the engine and keeps only UI
objects in libolive-editor
- install/packaging: GNUInstallDirs libdir on Linux, bundle copy on
macOS, oakengine.dll staged for NSIS, AppImage validation entry
- fix backend lookup for the new layout: DynamicRenderer searched
../app but backends now live in engine/; a stale pre-split liboakgl
in the build tree got dlopened instead, re-initialized and later
destroyed the interposed engine statics (full-suite segfault at
DialogSequenceParameterTab, found via gdb watchpoint)
liboakcore is now a shared library that exposes only a C ABI:
- every value class (Rational, TimeRange, Color, Bezier, AudioParams,
SampleBuffer) and the free-function groups (StringUtils, fraction
utils, Timecode) is wrapped in an opaque-handle C API under
core/include/olive/core/oakcore/ (init/copy/free + self-first
functions), implemented in core/src/capi/
- consumers keep the original C++ API unchanged through same-name
wrapper classes that hold the handle and forward across the C
boundary; original implementations moved to core/src/oliveimpl
(namespace olive::core::internal) and are hidden from export
- TimeRangeList/TimeRangeListFrameIterator are reimplemented inline
over the wrapper (iterators/containers don't cross C ABI)
- generic Value container stays internal (unused by consumers) and is
no longer part of the public umbrella header
- hidden visibility + OAKCORE_BUILD export macro; nm shows zero
olive::* symbols exported
- install into the platform's standard libdir (GNUInstallDirs);
Windows DLLs next to the executables, macOS into the app bundle
- TimelineWorkArea::in/out/length now return by value: the wrapped
TimeRange getters return values, and forwarding them through const
references dangled (found via RenderWorkerFootageTest crash)
- tests: 9 new pure C ABI test executables (oakcore_*_test) covering
every public C function; 4 stale legacy core tests removed (they
targeted a long-renamed API and were never built due to a malformed
option() that also kept OLIVECORE_BUILD_TESTS off)
- CI/CD: oakcore.dll staged for NSIS, liboakcore.so added to the
AppImage validation list, build-tree DLL copies on Windows
- oak-render-worker now builds from worker/ (own CMakeLists.txt) as a
peer of app/; RenderWorkerPool resolves the new build-tree location
- deduplicated the Linux install() rules for the worker
- worker-spawning tests resolve build/worker instead of build/app
- cd.yml: Windows staging copies the worker from its new output path
Mike-Solar