@oonacode/linux-x64 0.3.131 → 0.3.157

package/README.md

@@ -15,28 +15,33 @@ same reason — nothing is published for it yet.
 | `oonaclaude`            | the pinned Claude Code engine, run through the Claude Agent SDK (sidecar)    |
 | `web-ui/`               | the local web UI static assets served by the host service                   |
 | `build/`, `prebuilds/`  | native addons (SQLite, node-pty) laid out where the bundle looks for them    |
+| `registry.json`         | the provider registry — the host refuses to start without it beside `oona`   |
 | `oonacode-release.json` | version / arch / commit / build mode stamp                                  |
 
 `oonaclaude` is a byte-for-byte copy of the pinned, **unmodified** native binary from
 `@anthropic-ai/claude-agent-sdk-linux-x64`. OonaCode does not fork or patch Claude Code — it ships
 under our own filename only so it can never be confused with, or collide with, a user's own
-`claude` on PATH.
+`claude` on PATH. It is in the package only when the build bundled the engine
+(`packaging/build-linux.sh --bundle-engine`); otherwise the PC downloads the pinned engine once
+into its own store on the first message (`docs/engine-once.md`).
 
 Both binaries must arrive **executable**: a copy that loses its exec bit does not fail loudly, it
 hangs — the SDK neither answers nor throws when it cannot spawn the engine (see
-`docs/linux-port.md`). `prepare-npm.mjs` sets mode 0755 on them, and the host repairs the engine's
-bit before every turn.
-
-The binaries are **never committed** (they are git-ignored). They are produced on a Linux machine
-by `packaging/build-linux.sh` — a Windows box cannot build them, because the payload carries a
-native `better-sqlite3` addon — and injected here with:
-
-```bash
-node packaging/scripts/prepare-npm.mjs --platform linux-x64 --stage dist/linux/stage --version <x.y.z>
-```
+`docs/linux-port.md`). The release is packed on Windows, which carries no POSIX mode into the
+tarball, so the wrapper's `postinstall.mjs` sets mode 0755 on them on the user's machine, and the
+host repairs the engine's bit before every turn.
 
 ## Publishing
 
-Both this package and the wrapper are still `"private": true`; flip both at the first publish.
+In the source repository this directory is only a skeleton — `package.json` and this README; the
+payload is git-ignored. The binaries are produced on a Linux machine by `packaging/build-linux.sh`
+— a Windows box cannot build them, because the payload carries a native `better-sqlite3` addon.
+The package that is published is staged OUTSIDE the repository by `packaging/scripts/stage-npm.mjs`
+from that build's tarball (`oonacode-linux-x64.tar.gz`, which a stable `packaging/release.ps1` run
+given `-LinuxArtefacts` unpacks in step 6b), and the staging refuses a build of another version or
+one pinned to another engine than the release publishes. Without `-LinuxArtefacts` this package is
+**not published** for that version and the wrapper does not name it. `release.ps1` never packs
+this directory. (Until 0.3.131 it did, as the directory sat on disk, and this package went out
+with no binary in it — review C18/C26.)
 See [`docs/release-distribution.md`](../../../docs/release-distribution.md) and
 [`docs/linux-app.md`](../../../docs/linux-app.md).

package/oona

@@ -0,0 +1,4 @@
+[diffend] Oversized file quarantined before diffing.
+name: package/oona
+size: 105473504 bytes
+sha256: 369bd928f2cc860d030f10a6a98583d04dc3f7108aa051f36f3b0d48af7265de

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oonacode/linux-x64",
-  "version": "0.3.131",
+  "version": "0.3.157",
   "description": "OonaCode native binaries for Linux x64: oona (CLI + headless host service), the pinned oonaclaude engine sidecar, local web UI assets. Installed automatically as an optional dependency of `oonacode`.",
   "license": "UNLICENSED",
   "homepage": "https://oonacode.oonak.ai",
@@ -26,6 +26,7 @@
     "prebuilds",
     "lib",
     "oonacode-release.json",
+    "registry.json",
     "README.md"
   ],
   "preferUnplugged": true