neuron-explorer
Steering-first neuron explorer for Qwen3.5-4B: push every MLP neuron, keep every rollout, browse the results
翻譯準備中
A Javascript and TypeScript runtime built on Rust and V8, for TypeScript and MCP servers
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
The reliable TypeScript runtime for the AI era.
Fast is table stakes. Reliable is the product.
oam is a JavaScript/TypeScript runtime built in Rust on V8, designed around three ideas:檢視完整 README ↗The reliable TypeScript runtime for the AI era.
Fast is table stakes. Reliable is the product.
oam is a JavaScript/TypeScript runtime built in Rust on V8, designed around three ideas:
tsgo) daemon checks it on demand: oam check, oam run --check=warn to
report type errors after the run, or --check=block to gate on them. Node strips without
checking; Bun executes types-blind. oam closes the loop.repairs field,
but nothing populates it yet. Today oam ships an MCP server (oam mcp) that checks, runs and
explains code for agents, Node's permission model as an opt-in sandbox (--permission plus
--allow-* grants; a run without it is all-granted, as in Node), and oam.fork(), a
pool of pre-warmed isolates for parallel eval loops — not checkpoint/restore of a running
isolate.Beta. Breaking changes before 1.0 are still possible and are called out in
CHANGELOG.md; there is no LTS yet, so security fixes land on the latest
release only — SECURITY.md says how they are disclosed. npm resolution against existing
node_modules, CommonJS interop, the node: builtins (fs, path, process, Buffer, events,
util, assert, os, tty, module, stream, http, async_hooks — AsyncLocalStorage rides V8's
continuation-preserved embedder data), TypeScript and JSX/TSX without a build step,
node:vm on real V8 contexts including vm.SourceTextModule, node's permission model
(--permission plus the --allow-* grants), and oam test (fresh isolate per file,
mocking + fake timers). Real packages run unmodified: zod, lodash, ms, chalk, debug,
semver, @opentelemetry/context-async-hooks, eventsource-parser, split2, jsonwebtoken,
etag, uuid.
Receipts, all generated and regenerated by the CI gate (scripts/ci-local.sh), never
hand-edited:
See ROADMAP.md, docs/why-oam.md (how oam compares to Node, Deno and Bun, and when to pick one of those instead), and docs/cli-reference.md (commands, Node-compat flags, environment variables).
oam run hello.ts # strip + execute instantly (add --check=warn for types)
oam test # *.test.ts in fresh isolates, ODIF output for agents
oam check # tsgo type-check with a warm daemon
curl -fsSL https://oamjs.org/install.sh | sh # Linux / macOS
irm https://oamjs.org/install.ps1 | iex # Windows
Both installers pick the binary for your OS/arch, verify the release, and install per-user
(~/.oam/bin, %LOCALAPPDATA%\oam\bin) — no sudo, no admin. oam self-update updates in
place with the same checks.
From v0.18.0 every release carries a RELEASE-MANIFEST signed with oam's release key
(fingerprints in SECURITY.md). Both installers and
oam self-update verify that signature and take the binary's checksum from the signed
manifest. The installers need an ssh-keygen with -Y (OpenSSH 8.1+) for this. Releases
before v0.18.0 are checked against pinned SHA256SUMS digests. The Windows binaries are
Authenticode-signed (publisher "Yaw Labs LLC"). The macOS binaries are signed with oam's own
pinned, self-signed identity, not Apple Developer ID, and are not notarized: Gatekeeper still
blocks a browser download, while curl and brew installs are unaffected.
install/README.md has the details.
Knobs:
OAM_VERSION pins a tag, OAM_INSTALL_DIR moves the target directory, OAM_GH_API points
at a GitHub Enterprise host, OAM_INSECURE_SKIP_SIGNATURE=1 installs on a host with no
usable ssh-keygen, without checking the signature.
Rust stable (see rust-toolchain.toml). Five targets have shipped binaries: windows-x64,
windows-arm64, macos-x64, macos-arm64, linux-x64. linux-arm64 builds from the same tree but
has never been released — the V8 snapshot forbids cross-compiling, so it needs a native ARM
Linux builder, and the installer refuses that target by name rather than guessing.
cargo build --workspace
cargo test --workspace
crates/oam_engine — the only crate that touches V8 (rusty_v8). Isolates, snapshots, code cache.crates/oam_core — event loop, op system, Promise<->Future bridge.crates/oam_diagnostics — ODIF, the diagnostic envelope everything else speaks.crates/oam_cli — the oam binary.xtask — repo automation (V8 bump bot, snapshot rebuilds, packaging).Wider layout (loader, web/node compat, http, test runner, package manager, sandbox, tsgo sidecar, inspector) lands per the roadmap; crates are created when their workstream starts.
ring, sync_wrapper, self_cell) are statically
linked, so the shipped binary can never be GPLv2-compatible regardless.cargo about generate about.hbs -o THIRD_PARTY_LICENSES.md and drift-gated by CI.
NOTICE carries everything that tool cannot see: V8 itself, the 16 third-party
trees bundled inside the prebuilt V8 static library (ICU, abseil, highway, libc++ and the
rest), the vendored Node.js sources, and the vendored web-platform-tests data. None of those
appear in the cargo graph — the v8 crate declares itself MIT, which covers only its Rust
bindings — so that section is hand-maintained and must be revisited on a V8 bump.Domain: https://oamjs.org — the installer and update channel serve from there exclusively.
It also carries the pages the binary itself links to: debugging with the
inspector, the diagnostic code
reference that every --json diagnostic points
at, and the ODIF envelope. Everything else lives
here, beside the code it describes.
Distribution: the install script is canonical. An npm package is planned under
@yawlabs/oam — that name is not published yet, so install via the script above (bare
oam on npm belongs to an unrelated project).