zeekayandHanzo Dev
6cbbea2d03
Our history is just-every's with author emails rewritten, so the graphs are
disjoint and git finds no merge base. Supplied one by hand: d1f1f51a41, the
just-every commit matching our Oct-2025 fork point (22 files apart). 9618
upstream commits, 7004 files, +1.81M/-159k, 37 conflicts.
Resolution:
- Upstream code where our side was the Oct-2025 prototype of a feature they
have since reimplemented 3-5x larger (agent_runs, browser_sessions,
history_cell/{agent,browser}, the vt100 harness and its snapshots).
- Upstream's config.rs module split (builder/defaults/sources/validation)
kept; zen5-coder and the provider-follows-model rule re-applied on top.
- Ours where the file IS the identity: README, package.json, postinstall,
release notes pipeline, integration-zed.
- Hybrid where upstream improved a file we had branded: updates.rs (their
release-repo migration, our hanzoai/dev), release.yml (their fail-fast npm
auth check, our package name), chatwidget.rs (their turn handling, our
HANZO_USER_KEY hint), exec human output (their 237 lines, our banner).
Superseded and dropped deliberately: our resume_command_name() coder-alias
hack — upstream's derive_resume_command_name() reads the invocation basename
generically, which yields "dev" for us.
LLM.md now records the real topology and the sync point; AGENTS.md and
CLAUDE.md are symlinks to it again. Single parent on purpose: adopting
jecode/main as a second parent would re-import 13,742 commits carrying the
upstream author emails a prior rewrite deliberately removed.
Version 0.2.188 -> 0.2.189.
Co-authored-by: Hanzo Dev <[email protected]>
rusty_v8 Consumer Artifacts
This directory wires the v8 crate to exact-version Bazel inputs.
Bazel consumer builds use:
- upstream
denoland/rusty_v8release archives on Windows MSVC - source-built V8 archives on Darwin, GNU Linux, musl Linux, and Windows GNU
Local Cargo builds still use upstream prebuilt rusty_v8 archives by default.
Selected Cargo CI, release, and package builds override
RUSTY_V8_ARCHIVE/RUSTY_V8_SRC_BINDING_PATH with Codex release assets. Bazel
sets those variables independently in MODULE.bazel to select source-built
local archives and bindings for its consumer builds.
The Bazel v8 crate feature selection enables V8's in-process sandbox for
Darwin, Linux, and Windows GNU. Windows MSVC remains on upstream non-sandboxed
prebuilts.
Current pinned versions:
- Rust crate:
v8 = =146.4.0 - Embedded upstream V8 source for musl release builds:
14.6.202.9
When bumping the Rust crate version, keep the checked-in checksum manifest and
MODULE.bazel in sync:
python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
The commands read third_party/v8/rusty_v8_<crate_version>.sha256 by default
and validate every matching rusty_v8_<crate_version> http_file entry.
CI runs the check command to block checksum drift.
The consumer-facing selectors are:
//third_party/v8:rusty_v8_archive_for_target//third_party/v8:rusty_v8_binding_for_target
Musl release assets are expected at the tag:
rusty-v8-v<crate_version>
with these raw asset names:
librusty_v8_release_<target>.a.gzsrc_binding_release_<target>.rs
The dedicated publishing workflow is .github/workflows/rusty-v8-release.yml.
It builds musl release pairs from source and keeps the release artifacts as the
statically linked form:
//third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl//third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl
Cargo musl builds use RUSTY_V8_ARCHIVE plus a downloaded
RUSTY_V8_SRC_BINDING_PATH to point at those openai/codex release assets
directly. We do not use RUSTY_V8_MIRROR for musl because the upstream v8
crate hardcodes a v<crate_version> tag layout, while our musl artifacts are
published under rusty-v8-v<crate_version>.
Do not mix artifacts across crate versions. The archive and binding must match
the exact resolved v8 crate version in codex-rs/Cargo.lock.