Skip to content

YOK-2787: merge queue landing - #852

Merged
beebauman merged 2 commits into
mainfrom
YOK-2787
Sep 3, 2026
Merged

YOK-2787: merge queue landing#852
beebauman merged 2 commits into
mainfrom
YOK-2787

Conversation

@beebauman

Copy link
Copy Markdown
Contributor

Item branch for YOK-2787; lands through the merge queue's merge_group integration gate.

@beebauman
beebauman enabled auto-merge September 3, 2026 04:57
beebauman and others added 2 commits September 3, 2026 01:44
A clean macOS host with no Homebrew could not run `yoke qa browser setup`:
the setup path shelled out to `brew install node` and, finding no Homebrew,
exited 2 before materializing the runtime or Chromium. That made the
supported browser-recovery path depend on developer-machine knowledge and
blocked fresh-host QA entirely.

Yoke now owns the toolchain. `yoke_cli.browser_node_toolchain` resolves a
Node 18+ with npm already on PATH, else the pinned release already unpacked
under ~/.yoke/node/<version>/, else a checksum-verified download of
node-v24.20.0 from nodejs.org/dist. Every browser process runs against that
one resolved toolchain with its bin directory leading PATH, because npm and
npx are `#!/usr/bin/env node` scripts and Playwright spawns further Node
processes of its own: daemon start on both the harness and core paths,
`npm install`, the Chromium probe, `npx playwright install`, and the
sign-in window. The Homebrew path is gone.

Every refusal names a code and the operator action that clears it
(node_platform_unsupported, node_download_failed,
node_archive_digest_mismatch, node_archive_unusable,
node_provisioned_but_unusable), in both the text message and the --json
payload, and `yoke qa browser status` reports the resolved Node version and
whether it came from the host or from Yoke.

The shared external-artifact fetch gateway moves from yoke_core to
yoke_cli: yoke-harness and yoke-cli sit below yoke-core and cannot import
it, and yoke_cli is the declared home of shared client transport substrate.
The architecture model's external_artifact_fetch approved_modules follows.

Verified against a clean-host simulation (isolated machine home, PATH with
neither node nor brew): setup downloaded and checksum-verified v24.20.0,
ran npm install through it, and started the daemon; status reported
"node: ready (v24.20.0) [managed]" with chromium ready; a rerun reported no
prerequisite actions and an already-running daemon.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The builder stage runs one module straight from the source tree before any
wheel exists, so the interpreter resolves its imports from the PYTHONPATH the
Dockerfile spells out. That list named only contracts and core, so moving the
external-artifact fetch gateway into yoke-cli left the bootstrap unable to
import it and failed the image build with ModuleNotFoundError.

yoke-core declares yoke-contracts, yoke-cli, and yoke-harness as dependencies,
so listing every split package makes the bootstrap path the declared closure
rather than a hand-picked subset that goes stale without a reader.

Add a guard that walks the bootstrap entry module's first-party imports
transitively and resolves each against exactly the roots the Dockerfile
declares, so the next omission fails in seconds naming the package and the
fix, instead of minutes into a container build naming only the module.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@beebauman
beebauman added this pull request to the merge queue Sep 3, 2026
Merged via the queue into main with commit f6135d5 Sep 3, 2026
24 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators Sep 3, 2026
@beebauman
beebauman deleted the YOK-2787 branch September 3, 2026 06:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant