cxpher 2.0.1 → 2.0.2

package/README.md

@@ -21,17 +21,17 @@ The safest way to ship JavaScript. Full stop. The only JavaScript toolchain that
 
 cXpher is a complete JavaScript toolchain that does what no other tool on the market does: it takes your JavaScript or TypeScript project, bundles it, encrypts the source, generates a native binary with the encrypted payload embedded inside, and compiles it into a single executable wrapped in a defense-in-depth runtime envelope. **Your source code never reaches disk at runtime, your binary refuses to run under debuggers, and every build is cryptographically unique.**
 
-It is also a fully functional package manager with dependency resolution, a global content-addressable store, lockfile management, and parallel installation — competing directly with npm, yarn, pnpm, and bun on the package management side, while offering a compilation pipeline that none of them have and a security posture none of them attempt.
+It is also a fully functional package manager with dependency resolution, a global content-addressable store, lockfile management, and parallel installation - competing directly with npm, yarn, pnpm, and bun on the package management side, while offering a compilation pipeline that none of them have and a security posture none of them attempt.
 
-Output is a single native binary for the OS / arch of your choice — **Linux, macOS, Windows, x64, x86, ARM64 or ARM32** — produced from any Node-compatible JavaScript or TypeScript source. A single `cxpher compile-all` produces every binary plus a generated Node CLI wrapper into `dist/` in one pass. Scripts in your `package.json` run with a single command (`cxpher <script>`, yarn-style), and the interactive surface is a clack-prompts-style flow with select menus, validated text inputs, and a clean two-accent palette.
+Output is a single native binary for the OS / arch of your choice - **Linux, macOS, Windows, x64, x86, ARM64 or ARM32** - produced from any Node-compatible JavaScript or TypeScript source. A single `cxpher compile-all` produces every binary plus a generated Node CLI wrapper into `dist/` in one pass. Scripts in your `package.json` run with a single command (`cxpher <script>`, yarn-style), and the interactive surface is a clack-prompts-style flow with select menus, validated text inputs, and a clean two-accent palette.
 
 ## Why cXpher Exists
 
-Every JavaScript bundler on the market produces readable output. Minification is obfuscation theatre — any competent engineer can reverse it in an afternoon. Bytecode compilation (V8 snapshots, Bun's bytecode) is equally reversible with widely available decompilers. Even tools that produce "binaries" (pkg, nexe, bun --compile) embed the source as plaintext or trivially-decompiled bytecode inside the executable.
+Every JavaScript bundler on the market produces readable output. Minification is obfuscation theatre - any competent engineer can reverse it in an afternoon. Bytecode compilation (V8 snapshots, Bun's bytecode) is equally reversible with widely available decompilers. Even tools that produce "binaries" (pkg, nexe, bun --compile) embed the source as plaintext or trivially-decompiled bytecode inside the executable.
 
-If you're shipping a commercial Node.js application, a proprietary CLI tool, a paid API server, or an internal enterprise tool, **with every other toolchain on the market, your source code is exposed.** There is currently no production-grade JavaScript packaging solution that takes source protection seriously — except cXpher.
+If you're shipping a commercial Node.js application, a proprietary CLI tool, a paid API server, or an internal enterprise tool, **with every other toolchain on the market, your source code is exposed.** There is currently no production-grade JavaScript packaging solution that takes source protection seriously - except cXpher.
 
-cXpher doesn't obfuscate. It doesn't minify and hope. It encrypts with modern symmetric crypto, hardens the runtime against debuggers, removes the disk surface entirely, randomises every component of every build, and wraps the result in a binary that requires real reverse-engineering effort to crack. **Software-only protection has a mathematical ceiling — but cXpher pushes that ceiling as high as it will go.**
+cXpher doesn't obfuscate. It doesn't minify and hope. It encrypts with modern symmetric crypto, hardens the runtime against debuggers, removes the disk surface entirely, randomises every component of every build, and wraps the result in a binary that requires real reverse-engineering effort to crack. **Software-only protection has a mathematical ceiling - but cXpher pushes that ceiling as high as it will go.**
 
 ## The Safest Package Manager Built for JavaScript
 
@@ -49,7 +49,7 @@ cXpher is the only JavaScript toolchain that combines a full package manager wit
 
 **At runtime:**
 
-- **Zero-disk source delivery.** The primary execution path streams decrypted source directly into the JavaScript interpreter through an in-memory channel. No filesystem entry is ever created in the primary path — your source has no path on the disk, no entry in process listings, no name to grep for.
+- **Zero-disk source delivery.** The primary execution path streams decrypted source directly into the JavaScript interpreter through an in-memory channel. No filesystem entry is ever created in the primary path - your source has no path on the disk, no entry in process listings, no name to grep for.
 - **Native debugger-resistance on every platform.** Linux, macOS, and Windows each ship platform-specific runtime checks that detect debugger attachment and exit silently. The exits are silent on purpose: an attacker cannot learn which check fired or what triggered it.
 - **Timing-attack detection.** The runtime self-monitors execution timing against a tight budget. Single-step debugging blows the budget and the process exits silently within milliseconds.
 - **Key material never exists whole.** The encryption key is reconstructed inside the running process only at the moment of decryption, wiped immediately after use, and never appears as a contiguous byte sequence anywhere in the binary's data sections.
@@ -59,13 +59,13 @@ cXpher is the only JavaScript toolchain that combines a full package manager wit
 **At distribution time:**
 
 - One command (`cxpher compile-all`) produces native binaries for **every supported platform and architecture in a single pass**, plus a generated Node wrapper that auto-selects the right binary at install time. Ship the entire matrix as one npm package.
-- Compile cache disabled by default — `--cache` is opt-in. Every fresh build is a clean build with new key material unless you explicitly opt back in.
+- Compile cache disabled by default - `--cache` is opt-in. Every fresh build is a clean build with new key material unless you explicitly opt back in.
 
 ### What this means in practice
 
-A determined reverse engineer with significant time and the right tooling can eventually defeat any software-only protection. That's not specific to cXpher, that's the mathematical floor of running encrypted code on hardware you don't control. What cXpher does is **push the cost of extraction from "five minutes with a tutorial" to "one to two weeks of dedicated, skilled reverse engineering effort"** — which rules out 99.9% of would-be attackers, leaves only adversaries with serious budget and intent, and protects against every realistic threat short of a nation-state.
+A determined reverse engineer with significant time and the right tooling can eventually defeat any software-only protection. That's not specific to cXpher, that's the mathematical floor of running encrypted code on hardware you don't control. What cXpher does is **push the cost of extraction from "five minutes with a tutorial" to "one to two weeks of dedicated, skilled reverse engineering effort"** - which rules out 99.9% of would-be attackers, leaves only adversaries with serious budget and intent, and protects against every realistic threat short of a nation-state.
 
-For the remaining cases — where you need a hard floor against any conceivable attacker — cXpher is the strongest building block. Combine it with server-side key fetch, hardware TEE (SGX, TrustZone, Secure Enclave), or licensed runtime checks and you have a protection model nothing in the JavaScript ecosystem can match.
+For the remaining cases - where you need a hard floor against any conceivable attacker - cXpher is the strongest building block. Combine it with server-side key fetch, hardware TEE (SGX, TrustZone, Secure Enclave), or licensed runtime checks and you have a protection model nothing in the JavaScript ecosystem can match.
 
 ## How the Pipeline Works (High Level)
 
@@ -74,7 +74,7 @@ The compilation flow has four high-level stages:
 1. **Bundle.** Detect your project's entry point and bundle all source files and `node_modules` into a single JavaScript blob. Self-contained, zero external requirements.
 2. **Encrypt + randomise.** The bundle is wrapped with an argv-forwarding shim and encrypted with per-build random keying material. The key is decomposed across the binary in a layout that's different for every build.
 3. **Generate C runtime.** A platform-specific runtime stub is generated, containing the encrypted payload, the key reconstruction logic, the anti-tampering checks, and the in-memory source delivery channel. The stub is compiled into the final binary with full optimizations.
-4. **Compile to native binary.** GCC, Clang, MinGW, or MSVC produces a standard ELF (Linux), Mach-O (macOS), or PE (Windows) executable. The binary is fully self-contained — no runtime dependency on OpenSSL, libcrypto, or any other shared library beyond libc.
+4. **Compile to native binary.** GCC, Clang, MinGW, or MSVC produces a standard ELF (Linux), Mach-O (macOS), or PE (Windows) executable. The binary is fully self-contained - no runtime dependency on OpenSSL, libcrypto, or any other shared library beyond libc.
 
 The runtime stub's internal mechanics are intentionally not enumerated. They are designed to be effective, not catalogued for would-be attackers. What matters externally: the binary runs anywhere the target platform's libc runs, your source never reaches disk, and your binary refuses to run under inspection.
 
@@ -116,9 +116,9 @@ The SEA path runs the same protection stack as the standard path, plus eliminate
 
 ### Why not just use Bun's `--compile`?
 
-Bun's compile flag produces a binary that contains JavaScriptCore bytecode. Bytecode is not source protection — it is a performance optimization. Decompilers for JS bytecode exist and are actively maintained. The original source structure, variable names, and logic are recoverable in minutes by anyone with the right tool.
+Bun's compile flag produces a binary that contains JavaScriptCore bytecode. Bytecode is not source protection - it is a performance optimization. Decompilers for JS bytecode exist and are actively maintained. The original source structure, variable names, and logic are recoverable in minutes by anyone with the right tool.
 
-cXpher ships a fundamentally different class of artifact: a compiled native binary with encrypted source, per-build randomised key material that never exists whole on disk, runtime debugger detection, timing-attack defences, and a delivery channel to Node that never touches the filesystem. Recovering source from an cXpher binary requires real reverse-engineering against a hardened runtime — typically days to weeks of dedicated effort by a skilled adversary, not minutes with a decompiler.
+cXpher ships a fundamentally different class of artifact: a compiled native binary with encrypted source, per-build randomised key material that never exists whole on disk, runtime debugger detection, timing-attack defences, and a delivery channel to Node that never touches the filesystem. Recovering source from an cXpher binary requires real reverse-engineering against a hardened runtime - typically days to weeks of dedicated effort by a skilled adversary, not minutes with a decompiler.
 
 ### Why not pkg or nexe?
 
@@ -153,35 +153,35 @@ cxpher test
 cxpher dev
 
 # Build (runs your build script)
-cxpher build
+cx build
 
 # Compile to encrypted native binary
-cxpher compile
+cx compile
 
 # Compile to standalone binary (embeds Node.js)
-cxpher compile --standalone
+cX compile --standalone
 
 # Cross-compile to a 32-bit Windows machine
-cxpher compile -w32
+cX compile -w32
 
 # Or target a specific OS / arch combo
-cxpher compile --target linux-x86
-cxpher compile --target win-arm64
+cXpher compile --target linux-x86
+cXpher compile --target win-arm64
 
 # Build every binary plus a CLI wrapper into dist/ in one shot
-cxpher compile-all
+cx compile-all
 
 # Same, plus ARM64 + ARM32 for linux and win (8 total)
-cxpher compile-all --arm
+cx compile-all --arm
 
 # Just refresh the dist/cli.js wrapper, no binaries
-cxpher compile-all --cli-only
+cX compile-all --cli-only
 
 # Add a local package (no npm round-trip, ever)
-cxpher add ./packages/shared
+cXpher add ./packages/shared
 cxpher add file:../sibling-pkg
-cxpher add link:./local-dev-pkg          # symlink instead of hardlink
-cxpher add myname@file:./other-package   # explicit alias
+cx add link:./local-dev-pkg          # symlink instead of hardlink
+cX add myname@file:./other-package   # explicit alias
 ```
 
 ## Commands
@@ -197,7 +197,7 @@ cxpher add myname@file:./other-package   # explicit alias
 | `cxpher add <pkg>` | Add a registry dependency (npm → yarn → jsr → github fallback chain) |
 | `cxpher add -D <pkg>` | Add a dev dependency |
 | `cxpher add <path>` | Add a **local** package by relative or absolute path (no registry round-trip) |
-| `cxpher add file:<path>` | Same as above, explicit protocol — hardlinks the package tree into `node_modules/` |
+| `cxpher add file:<path>` | Same as above, explicit protocol - hardlinks the package tree into `node_modules/` |
 | `cxpher add link:<path>` | Symlink the local package into `node_modules/` instead of hardlinking. Live edits picked up instantly. |
 | `cxpher add portal:<path>` | Alias of `link:` |
 | `cxpher add <name>@file:<path>` | Local install under an explicit dependency name |
@@ -232,7 +232,7 @@ cxpher add myname@file:./other-package   # explicit alias
 | `-l` / `-w` / `-m` | Shorthand: Linux / Windows / macOS (defaults to `x64`) |
 | `-l32` / `-w32` / `-m32` | Shorthand: 32-bit (`x86`) Linux / Windows / macOS |
 | `-l64` / `-w64` / `-m64` | Explicit 64-bit shorthand - aliases of `-l` / `-w` / `-m` |
-| `--arm` | ARM target. Defaults to `arm64`; combine with `-l` / `-w` for cross-compile. |
+| `--arm` | ARM target. Defaults to `arm64`. Combine with `-l` / `-w` for cross-compile. |
 | `--arm64` / `--arm32` | Explicit ARM 64-bit or 32-bit. |
 | `--arch <arch>` | Target architecture independently of `--target`. Accepts `x64` (default), `x86`, `arm64`, `arm32`, plus aliases (`ia32`, `i386`, `i686`, `amd64`, `x86_64`, `aarch64`, `armv7`, `armv7l`, `armhf`, `arm`). |
 | `--minify` | Minify source before encryption |
@@ -341,9 +341,9 @@ cXpher hashes your source tree before compilation. If the hash matches a previou
 
 `cxpher add` skips the registry entirely when given a local path. The package's own `package.json` is read off disk to pull the name, version, and transitive dependencies, and the resulting tree entry is marked `local: true` so the installer takes the local-install path. Three protocols are recognised:
 
-- **`file:`** — copy/hardlink the local package tree into `node_modules/`. Default for bare paths (`./pkg`, `../sibling`, `/abs/path`, `~/lib`).
-- **`link:`** — create a directory symlink instead. Live edits to the source pick up immediately. Equivalent to `npm link` / `yarn link` but scoped to a single dependency.
-- **`portal:`** — alias of `link:`.
+- **`file:`** - copy/hardlink the local package tree into `node_modules/`. Default for bare paths (`./pkg`, `../sibling`, `/abs/path`, `~/lib`).
+- **`link:`** - create a directory symlink instead. Live edits to the source pick up immediately. Equivalent to `npm link` / `yarn link` but scoped to a single dependency.
+- **`portal:`** - alias of `link:`.
 
 The local install hardlink skips the source package's own `node_modules/`, `.git/`, and `.cxpher-stored` markers so consumers don't recurse into the dependency's dependency tree.
 
@@ -352,11 +352,11 @@ The local install hardlink skips the source package's own `node_modules/`, `.git
 `fetchPackument` walks an ordered list of registries on every lookup and short-circuits on the first 200. Default chain:
 
 1. `https://registry.npmjs.org` (npm)
-2. `https://registry.yarnpkg.com` (yarn — npm mirror with different caching)
-3. `https://npm.jsr.io` (jsr — the JS Registry)
+2. `https://registry.yarnpkg.com` (yarn - npm mirror with different caching)
+3. `https://npm.jsr.io` (jsr - the JS Registry)
 4. `https://npm.pkg.github.com` (github packages)
 
-404 / 401 / 403 from any registry is treated as "not here, try the next one" — the chain only throws when every registry has rejected the name. A 200 response is cached against the package name (not the registry), so subsequent lookups hit the cache regardless of which registry served the packument.
+404 / 401 / 403 from any registry is treated as "not here, try the next one" - the chain only throws when every registry has rejected the name. A 200 response is cached against the package name (not the registry), so subsequent lookups hit the cache regardless of which registry served the packument.
 
 Override the chain via `~/.cxpher/config.json`:
 
@@ -376,13 +376,13 @@ Override the chain via `~/.cxpher/config.json`:
 
 ### `compile-all` and the Generated CLI Wrapper
 
-`compile-all` produces every binary plus a generated Node script (`dist/cli.js`) in a single pass. The wrapper detects `process.platform` and `process.arch` at runtime and execs the matching binary out of the same directory — install one npm package that ships all four (or eight with `--arm`) binaries plus the wrapper as the `bin` entry, and the right binary runs on every platform the user installs it on.
+`compile-all` produces every binary plus a generated Node script (`dist/cli.js`) in a single pass. The wrapper detects `process.platform` and `process.arch` at runtime and execs the matching binary out of the same directory - install one npm package that ships all four (or eight with `--arm`) binaries plus the wrapper as the `bin` entry, and the right binary runs on every platform the user installs it on.
 
 When `dist/` already exists, a select prompt asks (the same prompt is shared with `cxpher compiler`):
 
-- **Install alongside existing files** — overwrite only the targets being built and leave everything else in `dist/` untouched.
-- **Backup current dist** — copies `dist/` to the next free `dist_backup_NNN/` (zero-padded 3-digit, based on the highest existing number in the project root), then wipes `dist/` and continues. Default.
-- **Wipe and start fresh** — removes `dist/` without a backup.
+- **Install alongside existing files** - overwrite only the targets being built and leave everything else in `dist/` untouched.
+- **Backup current dist** - copies `dist/` to the next free `dist_backup_NNN/` (zero-padded 3-digit, based on the highest existing number in the project root), then wipes `dist/` and continues. Default.
+- **Wipe and start fresh** - removes `dist/` without a backup.
 
 `--cli-only` skips every binary and just (re)writes `dist/cli.js`. Useful for refreshing the wrapper after a package rename without rebuilding everything.
 
@@ -405,19 +405,19 @@ Any unsupported platform/arch combination throws a clear `Unsupported platform:`
 
 Before any binary is built, `compile-all` runs a toolchain preflight check against every requested target. If any cross-compilers are missing, you get a three-way prompt:
 
-- **Install missing toolchains and build all** — calls `install-toolchain` for the missing targets, then continues.
-- **Skip missing targets, build the rest** — drops the targets whose toolchains aren't available and carries on with the ones that are.
-- **Abort** — does nothing.
+- **Install missing toolchains and build all** - calls `install-toolchain` for the missing targets, then continues.
+- **Skip missing targets, build the rest** - drops the targets whose toolchains aren't available and carries on with the ones that are.
+- **Abort** - does nothing.
 
 `--yes` / `-y` auto-picks install. Individual compile failures during the loop are warned-and-skipped rather than fatal, so one bad target never kills the rest of the batch.
 
-### `install-toolchain` — auto-install cross-compilers
+### `install-toolchain` - auto-install cross-compilers
 
 `cxpher install-toolchain` detects the host OS, distro and package manager and installs the cross-compilers required for any compile target. Supported package managers:
 
 | OS / Distro | Manager | Notes |
 |-------------|---------|-------|
-| Arch / Manjaro / EndeavourOS | `pacman` + `yay` / `paru` | Repo packages via pacman with sudo; AUR / chaotic-aur via yay/paru without sudo |
+| Arch / Manjaro / EndeavourOS | `pacman` + `yay` / `paru` | Repo packages via pacman with sudo. AUR / chaotic-aur via yay/paru without sudo |
 | Debian / Ubuntu | `apt-get` | sudo |
 | Fedora / RHEL / CentOS | `dnf` | sudo |
 | openSUSE | `zypper` | sudo |
@@ -427,13 +427,13 @@ Before any binary is built, `compile-all` runs a toolchain preflight check again
 
 Invocations:
 
-- `cxpher install-toolchain` — interactive. Lists every target with installed/missing flags, multiselect to pick what to install.
-- `cxpher install-toolchain --all` — install every cross-compiler cxpher knows about.
-- `cxpher install-toolchain --arm` — install only ARM (linux/win × arm64/arm32).
-- `cxpher install-toolchain --x86` — install only 32-bit x86 (linux + win).
-- `cxpher install-toolchain --win` / `--linux` — install all cross-compilers for that OS.
-- `cxpher install-toolchain linux-arm32 win-x86 ...` — install only the named targets.
-- `cxpher install-toolchain --yes` — skip the confirm prompt.
+- `cxpher install-toolchain` - interactive. Lists every target with installed/missing flags, multiselect to pick what to install.
+- `cxpher install-toolchain --all` - install every cross-compiler cxpher knows about.
+- `cxpher install-toolchain --arm` - install only ARM (linux/win × arm64/arm32).
+- `cxpher install-toolchain --x86` - install only 32-bit x86 (linux + win).
+- `cxpher install-toolchain --win` / `--linux` - install all cross-compilers for that OS.
+- `cxpher install-toolchain linux-arm32 win-x86 ...` - install only the named targets.
+- `cxpher install-toolchain --yes` - skip the confirm prompt.
 
 Targets with no native package on the current distro (Windows ARM on debian/fedora, macOS cross from anything) are reported with a manual-install link rather than silently skipped.
 
@@ -441,15 +441,15 @@ Targets with no native package on the current distro (Windows ARM on debian/fedo
 
 Each target carries an ordered list of install steps. The installer walks the chain in order, verifies after each attempt, and only moves on if the current step fails or installs without putting the expected binary on PATH. Example: `linux-arm32` on Arch tries
 
-1. **Linaro precompiled binary** (`arm-linux-gnueabihf-gcc13-linaro-bin` from AUR) — fast, but depends on snapshots.linaro.org being reachable.
-2. **Official ARM GNU toolchain** — downloads the `arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz` archive from developer.arm.com, extracts to `/opt/cxpher-toolchains/arm-none-linux-gnueabihf/`, and symlinks both the Arm-official names (`arm-none-linux-gnueabihf-*`) and the standard names (`arm-linux-gnueabihf-*`) into `/usr/local/bin/`. Reusable for `linux-arm64` (triplet `aarch64-none-linux-gnu`) as well.
-3. **Build from source** (`arm-linux-gnueabihf-gcc` from AUR) — last resort, takes 1-2 hours.
+1. **Linaro precompiled binary** (`arm-linux-gnueabihf-gcc13-linaro-bin` from AUR) - fast, but depends on snapshots.linaro.org being reachable.
+2. **Official ARM GNU toolchain** - downloads the `arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz` archive from developer.arm.com, extracts to `/opt/cxpher-toolchains/arm-none-linux-gnueabihf/`, and symlinks both the Arm-official names (`arm-none-linux-gnueabihf-*`) and the standard names (`arm-linux-gnueabihf-*`) into `/usr/local/bin/`. Reusable for `linux-arm64` (triplet `aarch64-none-linux-gnu`) as well.
+3. **Build from source** (`arm-linux-gnueabihf-gcc` from AUR) - last resort, takes 1-2 hours.
 
 Failed steps print a one-line reason and the chain continues. If every step fails the target is reported as still-missing in the final status section.
 
 #### macOS native targets
 
-On a macOS host, `darwin-x64` and `darwin-arm64` are detected as installed when native `clang` plus `xcode-select -p` both resolve — those are the prerequisites for `clang -arch x86_64` and `clang -arch arm64` native compiles. The `darwin-x64` / `darwin-arm64` install step on a macOS host calls `xcode-select --install` to trigger Apple's GUI installer for the Command Line Tools. From a Linux host, the same targets fall back to a `manual` osxcross install step (no automated install path exists for osxcross — it requires the Xcode SDK which can't be redistributed). Apple dropped 32-bit Intel and 32-bit ARM support in macOS Catalina (10.15), so no `darwin-x86` or `darwin-arm32` target exists.
+On a macOS host, `darwin-x64` and `darwin-arm64` are detected as installed when native `clang` plus `xcode-select -p` both resolve - those are the prerequisites for `clang -arch x86_64` and `clang -arch arm64` native compiles. The `darwin-x64` / `darwin-arm64` install step on a macOS host calls `xcode-select --install` to trigger Apple's GUI installer for the Command Line Tools. From a Linux host, the same targets fall back to a `manual` osxcross install step (no automated install path exists for osxcross - it requires the Xcode SDK which can't be redistributed). Apple dropped 32-bit Intel and 32-bit ARM support in macOS Catalina (10.15), so no `darwin-x86` or `darwin-arm32` target exists.
 
 #### `llvm-mingw` post-install symlink hook
 
@@ -457,18 +457,18 @@ On Arch, `llvm-mingw` from chaotic-aur / AUR installs into `/opt/llvm-mingw/bin/
 
 ## Security Model
 
-cXpher is the strongest software-only source protection in the JavaScript ecosystem. It is not a DRM system — pure software protection has a theoretical floor that nothing can move without external trust (server-fetched keys or hardware TEE) — but it pushes that floor as high as it goes.
+cXpher is the strongest software-only source protection in the JavaScript ecosystem. It is not a DRM system - pure software protection has a theoretical floor that nothing can move without external trust (server-fetched keys or hardware TEE) - but it pushes that floor as high as it goes.
 
 **What cXpher protects against:**
 
 - Direct source code reading from the distributed binary.
 - Trivial decompilation (the entire class of attack that defeats every other JS packager).
 - Casual filesystem extraction during runtime (your source never reaches the disk in the primary execution path).
-- Common debugger inspection — Linux, macOS, and Windows binaries refuse to run when a debugger is attached and exit silently.
-- Single-step debugging — runtime timing checks detect single-stepping and silently exit within milliseconds.
-- Bulk extraction across versions — every build is cryptographically independent.
+- Common debugger inspection - Linux, macOS, and Windows binaries refuse to run when a debugger is attached and exit silently.
+- Single-step debugging - runtime timing checks detect single-stepping and silently exit within milliseconds.
+- Bulk extraction across versions - every build is cryptographically independent.
 - Casual copying of proprietary logic by employees, customers, or anyone with the binary but without serious tooling.
-- Source exposure in containerised, cloud, or shared-filesystem deployments — there is no source file to expose.
+- Source exposure in containerised, cloud, or shared-filesystem deployments - there is no source file to expose.
 
 **What cXpher does not protect against:**
 
@@ -476,9 +476,9 @@ cXpher is the strongest software-only source protection in the JavaScript ecosys
 - Runtime memory inspection performed at the kernel level by an attacker with root access on the host.
 - Hardware-level memory dumps from a cold-boot or DMA attack.
 
-For the realistic threat model — protecting commercial JavaScript IP against employees, customers, competitors, security researchers without unlimited budget, and the entire long tail of opportunistic extraction attempts — **cXpher is the strongest answer the JavaScript ecosystem has.**
+For the realistic threat model - protecting commercial JavaScript IP against employees, customers, competitors, security researchers without unlimited budget, and the entire long tail of opportunistic extraction attempts - **cXpher is the strongest answer the JavaScript ecosystem has.**
 
-This is the same security model as any compiled C, C++, Go, or Rust application — but with the added per-build-randomised, debugger-aware, disk-free runtime envelope that no other JavaScript packager attempts.
+This is the same security model as any compiled C, C++, Go, or Rust application - but with the added per-build-randomised, debugger-aware, disk-free runtime envelope that no other JavaScript packager attempts.
 
 ## System Requirements
 
@@ -503,7 +503,7 @@ This is the same security model as any compiled C, C++, Go, or Rust application
 | Windows ARM32 | ✓ ² | - | ✓ (via `armv7-w64-mingw32-clang`) |
 
 <sup>¹ Standalone (`--standalone`) embeds the host Node.js binary, and Node has not shipped 32-bit Linux or 32-bit ARM builds for years. For these targets use the default encrypted-binary path - it cross-compiles cleanly via the system C toolchain.</sup>
-<sup>² Windows ARM requires the [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) toolchain; the default MinGW packages from most distros only ship x86_64 / i686 targets.</sup>
+<sup>² Windows ARM requires the [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) toolchain. The default MinGW packages from most distros only ship x86_64 / i686 targets.</sup>
 
 ## License
 

package/cli-wrapper.cjs

@@ -10,14 +10,17 @@
 
  * © Agentics (Pty) Ltd - All Rights Reserved
  * https://agentics.co.za <-> info@agentics.co.za
-*/
 
-// Fallback launcher for cxpher.
+ ---
+
+ * Fallback launcher for cxpher.
 
-// Normally install.cjs (postinstall) copies the native binary over
-// bin/<brand>.exe, so this file is never invoked. It exists for environments
-// where postinstall doesn't run (--ignore-scripts) — pay the Node-process
-// overhead and forward to the native binary anyway.
+ * Normally install.cjs (postinstall) copies the native binary over
+ * bin/<brand>.exe, so this file is never invoked. It exists for environments
+ * where postinstall doesn't run (--ignore-scripts) — pay the Node-process
+ * overhead and forward to the native binary anyway.
+
+*/
 
 const { spawnSync } = require('child_process');
 const { arch, constants } = require('os');

package/install.cjs

@@ -10,13 +10,18 @@
 
  * © Agentics (Pty) Ltd - All Rights Reserved
  * https://agentics.co.za <-> info@agentics.co.za
+
+ ---
+
+ * Postinstall for cxpher.
+
+ * binary from the matching optional-dependency subpackage. After this runs,
+ * invocations of `cxpher` (and aliases) exec the native binary directly on
+ * Unix. The fallback launcher logic stays inside bin/cXpher.js itself in
+ * case postinstall is skipped (--ignore-scripts).
+
 */
 
-// Postinstall for cxpher: replace bin/cXpher.js placeholder with the native
-// binary from the matching optional-dependency subpackage. After this runs,
-// invocations of `cxpher` (and aliases) exec the native binary directly on
-// Unix. The fallback launcher logic stays inside bin/cXpher.js itself in
-// case postinstall is skipped (--ignore-scripts).
 
 const { spawnSync } = require('child_process');
 const { copyFileSync, linkSync, unlinkSync, chmodSync, mkdirSync } = require('fs');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cxpher",
-  "version": "2.0.1",
+  "version": "2.0.2",
   "type": "module",
   "description": "Agentics Package Manager — Encrypted native binary compiler + package manager for JavaScript",
   "main": "bin/cXpher.js",
@@ -50,15 +50,15 @@
   "author": "Connor Etherington <connor@agentics.co.za>",
   "license": "MIT",
   "optionalDependencies": {
-    "cxpher-darwin-arm64": "2.0.1",
-    "cxpher-darwin-x64": "2.0.1",
-    "cxpher-linux-arm32": "2.0.1",
-    "cxpher-linux-arm64": "2.0.1",
-    "cxpher-linux-x64": "2.0.1",
-    "cxpher-linux-x86": "2.0.1",
-    "cxpher-win-arm32": "2.0.1",
-    "cxpher-win-arm64": "2.0.1",
-    "cxpher-win-x64": "2.0.1",
-    "cxpher-win-x86": "2.0.1"
+    "cxpher-darwin-arm64": "2.0.2",
+    "cxpher-darwin-x64": "2.0.2",
+    "cxpher-linux-arm32": "2.0.2",
+    "cxpher-linux-arm64": "2.0.2",
+    "cxpher-linux-x64": "2.0.2",
+    "cxpher-linux-x86": "2.0.2",
+    "cxpher-win-arm32": "2.0.2",
+    "cxpher-win-arm64": "2.0.2",
+    "cxpher-win-x64": "2.0.2",
+    "cxpher-win-x86": "2.0.2"
   }
 }