@orchestraworks/worker 0.0.134

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Living Computers
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,518 @@
+# The worker
+
+One Go program runs inside every machine and speaks the Factory Worker Protocol to the
+platform. This tree is that program, and it is also the `@orchestraworks/worker` npm package: the launcher on
+the path, and one per-platform package carrying the binary for the machine it is installed on.
+
+The worker exposes no API of its own. Every route it calls is the platform's.
+
+## The tree
+
+| path | what it holds |
+|---|---|
+| `cmd/worker/` | the one binary: `run`, `install`, `enroll`, `check`, `version` |
+| `identity/` | the four identity exchanges — claim, refresh, reattach-challenge, reattach — the holder key, and the loop that keeps the machine token alive |
+| `broker/` | the protocol on the message broker: the connection, the register on every connect, the heartbeat and the status cadence, the pull of this machine's own work consumer, and the publisher every other package sends through |
+| `env/` | the machine-side environment the platform composes onto a launch, read from the names the contract declares |
+| `facts/` | what this build knows about the four harness families: the program to install and the digest that authenticates it, the environment each family is handed, the templates it seeds, and every location its content lands in — embedded in the binary, so one release digest covers the facts and the program that reads them |
+| `harness/` | the only place family-specific knowledge lives: the launch plan, the content layout, the store lookup, the mid-turn message each family accepts, and the installer that puts the pinned Node and a family's programs under the worker root |
+| `process/` | the agent's setup and the harness process behind each session placement: the start, the stop and the last save a remove asks for, the startup fence over what a previous run left, and the stop of everything when the worker is told to stop |
+| `stream/` | the queue: every placement message and every prompt, steer and cancel pulled off this machine's work consumer, the ACP client that opens a session's harness conversation and runs its turns, each turn's events batched to the platform and published live, and the answer every placement message is owed |
+| `mount/` | the volumes the launch declares, placed on the lanes that mount them: the home volume first, because anything written under a mount point before the mount is hidden by it |
+| `network/` | the transparent redirect on the virtual-machine lanes, as the iptables rules the launch describes: what the worker's own uid reaches directly, and what every uid on the machine reaches through the egress edge |
+| `shim/` | the in-guest transparent proxy: the listener the redirect lands on, the recovery of the destination each connection was actually for, the hop to the egress edge under the machine-identity proof, the WinDivert half that is the Windows redirect, and the loopback feed a separate shim reads this machine's token from |
+| `egress/` | what puts that proxy in place on the virtual-machine lanes: the edge's certificate authority in this machine's trust store, the inbound firewall rule Windows needs, the redirect itself, and the state line an operator reads off the machine's console |
+| `ingress/` | the machine's half of the preview tunnel: the connection this worker holds open to the preview gateway, the challenge and the signed upgrade that authenticate it, and the loopback pipe that carries each viewer request to a port this machine declared and refuses every other |
+| `termination/` | the cloud's notice that this machine is being reclaimed, delivered to the broker so the next status report carries it |
+| `paths/` | which native place a logical path denotes, and when two logical paths denote one place — pinned against the platform's own answer by committed vectors |
+| `service/` | `worker run` under this operating system's service manager, in one of two scopes: a system or user `systemd` unit, a Windows service or logon task, a launchd daemon or launch agent |
+| `file/` | everything that moves bytes onto this machine and back off it: the install of the skills, memory, instructions and model settings an agent placement's apply carries, against the install journal, the capture that offers the machine's declared roots back to the platform, the restore that lays a previous machine's capture down before a manifest is installed over it, and the self-update that replaces this worker's own release package |
+| `script-harness/` | the first-party `script` harness program, which is the one family the worker package carries rather than installs |
+| `bin/worker.js` | the npm launcher: it runs the binary out of the per-platform package installed for this machine, stays in front of it, and forwards the signal a service manager ends it with. Its own tests sit beside it and are not packed |
+| `npm/<platform>/` | the five per-platform packages, one per release target: the binary, and the `script` harness copied in beside it at build time |
+
+`../fwp` is the protocol. Every wire shape comes from `github.com/livingcomputers/fwp/go/wire`
+through a relative `replace`, so the program and the conformance suite compile against the exact
+shapes the schema ships, and nothing here re-declares one.
+
+## The commands
+
+- **`worker run`** claims this machine's identity — or reattaches, where its row is already bound to
+  the key this machine holds — and then serves the machine. `run` hands the held identity, with the
+  broker credential the claim co-issued, to the registrar seam in `cmd/worker/run.go`, which the
+  `broker` package fills: it dials, registers the machine on every connect, pulls the machine's own
+  work consumer and reports on the cadence.
+
+  Before any of that, `run` starts what the launch describes: it places the declared volumes, puts
+  the in-guest egress in place where the launch names an intercept set, opens the egress shim's token
+  feed, and — on a machine the cloud can reclaim — watches for the notice that it is going away. Each
+  is started only where it is described: a Kubernetes pod places its own volumes and its egress
+  sidecar installs its own redirect, so a launch there names neither. If one of those duties is
+  installed and then dies, `run` ends rather than serving a machine the platform counts as healthy
+  with no route off it; the service manager starts the worker again.
+
+  `--service` is how the process is hosted rather than what it does: on Windows it hands the body to
+  the service control manager, which kills a service that does not answer its handshake, and on the
+  other operating systems it is refused by name, because systemd and launchd supervise a foreground
+  process from outside.
+
+  On a machine that hosts a harness, `run` also builds the three lanes that answer the platform's
+  verbs: `process`, which holds the placements, `stream`, which carries their turns, and `file`,
+  which installs what an agent is made of and captures what its work left behind. The three are
+  built before the broker, because the broker's configuration carries their handlers, and each
+  reaches it afterwards through the deferred link in `cmd/worker/serve.go`.
+
+  Once the register has been answered, `run` starts the capture cadence and, where the platform named
+  a version other than the one this process is running, the self-update: the release package is
+  fetched from the npm registry when this machine can reach one and from the platform when it cannot,
+  checked against the digest the register answer named, unpacked over the release package directory,
+  and the process restarted — but only once no turn has been open for five seconds together, because one
+  open turn per machine is the platform's rule and killing one would lose its answer. A machine whose
+  turns never leave that gap keeps running the version it has until some later start picks the unpacked
+  one up.
+- **`worker install --role worker|image|laptop --harness <families> --yes [--root <dir>] [--service=user|none]`**
+  installs the worker on this machine and starts its service. Every answer comes from a flag: a missing
+  one is an error and never a default. It installs the harness half itself — the pinned Node, then each
+  named family's programs from the facts file's own pins, with the tarball checked against the pinned
+  digest before anything is unpacked — and then registers the service. The per-operating-system service
+  forms fill the installer seam in `cmd/worker/install.go`; a build with none refuses rather than
+  reporting an install it did not perform.
+
+  **`--service` says which session the worker is registered in, and neither of its two values needs any
+  privilege.** `user` registers it in the invoking account's own session: a launch agent under
+  `~/Library/LaunchAgents` on macOS, a `systemd --user` unit under `~/.config/systemd/user` on Linux, a
+  scheduled task the account's logon starts on Windows. `none` installs the files and registers nothing,
+  for the one host that has no service manager — a container image, whose own command is the worker —
+  and `false` is that same answer under its older spelling. The default is `user`. An install run as
+  root is refused, because it would put the worker's root under root's home and run every harness as
+  root; there is no privileged install to redirect it to, and `--service=system` is refused with the
+  same answer. Nothing on a machine somebody owns needs privilege: network enforcement is outside the
+  machine, at the egress edge and the directional security group.
+
+  **The machine-wide service is the image role's, and the role is the whole of what asks for it.** An
+  `image` gets it — a property list under `/Library/LaunchDaemons`, a unit under `/etc/systemd/system`,
+  a Windows service — because the platform builds the image with nobody logged in to it and nobody
+  typing the command, and the builder is already root. No flag selects that scope, on any role.
+
+  `--root` follows the scope the same way: `~/.sfdk/worker` (`%LOCALAPPDATA%\sfdk\worker` on Windows) for
+  a `user` install, `/var/lib/sfdk/worker` (`%ProgramData%\orchestra\worker`) for the other two. A `user`
+  install writes its log under that root, at `log/worker.log`, because no service manager in that scope
+  keeps one a person can read.
+
+  What the role decides is when the service runs — a `worker` starts now and at every boot, an `image`
+  being baked starts at the first boot of a machine made from it and claims no identity now, and a
+  `laptop` starts when a person enrolls a machine and says so. An `image` install also refuses, before
+  it installs anything, when a bootstrap file already sits at any path the run would read: an image is
+  copied onto every machine made from it, so a baked bootstrap would hand one machine's identity to all
+  of them.
+
+  Each form carries one thing its machine would otherwise be wrong without. A macOS launch DAEMON — the
+  image role's form, which a person never reaches — names the account that ran the install, because
+  launchd's system domain runs a daemon as root otherwise, and a harness runs as whoever this worker is;
+  the worker's own root and the daemon's log file are handed to that account in the same step, so the
+  service can read the owner-only bootstrap the root install just wrote, write its state file beside it,
+  and say in its log why it did not start. A launch AGENT names no account: it is
+  already the session's. The Windows service is registered to restart itself three times at two seconds,
+  on a clean non-zero exit as well as a crash — the control manager restarts nothing it was not told to,
+  and this worker exits non-zero deliberately to be started again on a release its self-update put in
+  place — and the logon task carries the task scheduler's nearest equivalent, three restarts a minute
+  apart.
+
+  A `worker` install run as root on Linux refuses outright where the `agent` account a harness is
+  dropped to is not on the machine, and names the command that creates it: a root worker runs its
+  harness as root without that account, so this machine would register with no harness capability,
+  report healthy, and refuse every conversation sent to it, having reported an install that succeeded.
+  Creating a system account on a machine somebody else owns is the operator's to do, so the install
+  names it rather than making it. One `worker` install can still be root's — `--service=none` on a
+  machine whose own command is the worker — and every other one is refused as root before it gets this
+  far. An `image` carries the account already, and an install that registers a service in the invoking
+  account's session has no second account at all: the harness runs as the person who installed it.
+
+  A family a placement names and this machine lacks is installed on the preparation path instead,
+  before its harness starts, so a first provision is not slowed by a download of hundreds of megabytes
+  that nobody asked for. The root is where both paths install. It is deliberately not the release
+  package's own directory, which a self-update replaces whole. Under it sit the pinned Node, each
+  family's programs, and `workspaces/<family>`, the directory that family's harness runs in — one
+  create at install covers all three, and a worker enrolled on somebody's own machine can take no
+  second one.
+- **`worker enroll`** redeems the enrollment token this machine was given, prints the row it was
+  issued, and then serves that machine. It does not stop at the redemption, because the holder key
+  the redemption bound lives in this process.
+- **`worker check [--harness <families>] [--root <dir>]`** reads the runtime image contract from
+  inside an image, which is where the rest of that contract cannot be read. An inspection from the
+  container runtime sees the command, the account it starts as, the platform it was built for and the
+  version label; whether a family's programs are there at the versions this build's facts pin, whether
+  the Orchestra CLI is on the path that family's harness is handed, whether a Linux image has the `agent`
+  account at uid 1000 with home `/home` and glibc's loader, and whether a Windows image has
+  `WinDivert.dll` and `WinDivert64.sys` under `<root>\bin`, where the redirect loads them, are only
+  visible from within. Each miss names the line of
+  `agents/runtime/image/Dockerfile` that fixes it, and every miss is reported in one run, because the
+  rows are independent and a person rebuilding an image should read the whole list once.
+
+  It starts nothing, claims no identity and speaks to no platform, so it needs neither a bootstrap nor
+  a daemon: `docker run --rm --entrypoint worker <image> check --harness <family>` is the whole of how
+  it is used. With no `--harness` it checks the rows that belong to no family and says so — a customer
+  image installs the families it needs, so holding one to every family this build can host would
+  refuse it for lacking programs nothing on it was ever going to run.
+- **`worker trust-nested [--registry <host>]... [--root <dir>]`** lets the containers this machine
+  runs trust the egress edge, which nothing does by default. It reads the authority from
+  `SFDK_EGRESS_CA_FILE`, which the worker sets on every harness process and on the setup script;
+  writes it into dockerd's `certs.d` for the well-known registries and each one named; writes
+  `k3d-registries.yaml` under the root, whose `ca_file` is the authority's path inside each k3d node;
+  and prints the flags `docker run`, compose and `k3d cluster create` need. On a machine that names no
+  authority, such as one with no edge in front of it, it says so, writes nothing and succeeds.
+- **`worker version`** prints this binary's version, the release package it belongs to, and the
+  protocol versions it speaks.
+
+The version is stamped at link time by the publishing lane, and both `package.json` files carry
+`0.0.0` until that lane stamps them; a build that stamps nothing says so rather than claiming a
+version it is not.
+
+## The bootstrap a machine is started with
+
+Everything above assumes the worker already knows where its platform is. That is the one family of
+names it reads before it can speak to anything, so they are the worker's own rather than the
+contract's: the environment document owns the other `SFDK_` names the platform or the worker sets for a
+running machine and says these are outside its scope. They carry the same reserved prefix, so an environment
+cannot declare one; the only `SFDK_` names an environment may declare are the release settings
+`fwp/schema/environment-v1.json` lists under `customerDeclarable`, which the worker reads from its own
+environment in preference to the register answer. The platform composes what is listed here; a value it does not
+set is a concern this machine does not have.
+
+| name | what it carries |
+|---|---|
+| `SFDK_CLAIM_ENDPOINT_URL` | the platform's origin, not a route: the paths belong to the protocol |
+| `SFDK_TRANSPORT_TRUST_ROOTS` | the certificate bundle this machine trusts, inline |
+| `SFDK_TRANSPORT_TRUST_ROOTS_FILE` | the same bundle as an absolute path, for a delivery that cannot carry the newlines; setting both is refused |
+| `SFDK_CLAIM_LOCATOR` | the machine row this worker claims as |
+| `SFDK_ENROLLMENT_TOKEN` | the show-once token an enrolling machine redeems; mutually exclusive with the locator |
+| `SFDK_ENROLLMENT_TOKEN_FILE` | the same token as an absolute path; setting both is refused |
+| `SFDK_HOLDER_KEY_ALGORITHM` | which of the protocol's two holder-key algorithms this registration declares |
+| `SFDK_SUBSTRATE` | which evidence this worker gathers, so an unknown value is refused rather than defaulted |
+| `SFDK_CLAIM_AUDIENCE` | who the presented caller-identity request was meant for; required on the virtual-machine lanes |
+| `SFDK_STS_ENDPOINT_URL` | the security-token endpoint the platform will send that request to |
+| `SFDK_SERVICE_ACCOUNT_TOKEN_FILE` | where the audience-bound projected token is mounted, on the Kubernetes lane |
+| `SFDK_TPM_DEVICE_PATH` | the chip's device path where it is not this operating system's default |
+| `SFDK_SUBSTRATE_TOKEN` | the `local` substrate's stand-in factor, inline |
+| `SFDK_SUBSTRATE_TOKEN_FILE` | the same factor as an absolute path; setting both is refused |
+| `SFDK_INTERCEPT_PORTS` | the destination ports whose traffic goes to the egress edge, comma separated; naming none installs no redirect |
+| `SFDK_INTERCEPT_BYPASS` | the shared services the worker's own uid reaches directly, as `[{"host": …, "port": …}]` — our broker and our gateway, and nothing broader |
+| `SFDK_INTERCEPT_SKIP_RANGES` | the private ranges the redirect never takes, for any uid on any port, as comma-separated CIDR ranges; a range that is not wholly private is refused |
+| `SFDK_EDGE_ENDPOINT_URL` | where the redirect sends this machine's traffic; its scheme is the whole TLS statement for that hop |
+| `SFDK_EGRESS_LISTEN_PORT` | where the redirect lands, which is the shim's own listen port |
+| `SFDK_EGRESS_IPV6` | `true` mirrors the redirect through `ip6tables` |
+| `SFDK_EGRESS_PROXY` | `on`, the default, or `off`; `off` tells each harness that no edge of ours stands in front of this machine, as on an enrolled one. The platform writes `off` into every Launcher machine's boot file, because no proxy entrance of ours stands in front of one yet |
+| `SFDK_RUNTIME_ENVIRONMENT` | a whole environment folded into one JSON object of string values, for a boot file whose lines cannot carry a line break; each pair is placed unless already set |
+| `SFDK_VOLUME_MOUNTS` | the volumes this launch declares, as one JSON document |
+| `SFDK_MACHINE_SLUG` | the machine's platform-minted slug: the leading label of its preview hostnames, and what the tunnel's upgrade signs |
+| `SFDK_TUNNEL_ENDPOINT_URL` | where the preview gateway serves its tunnel listener; its scheme is the whole TLS statement for that hop |
+| `SFDK_INGRESS_PORTS` | the loopback ports this machine projects through that tunnel, comma separated; with no reserved ports below, naming none holds no tunnel |
+| `SFDK_INGRESS_ANY_PORT_EXCEPT` | the reserved loopback ports, comma separated; set, the tunnel is held from start, forwards every other port whatever `SFDK_INGRESS_PORTS` says, and the worker registers `ingress-any-port` |
+
+**The worker reads that file itself, on every operating system, and no service manager is handed it.**
+Every `worker run` places each pair into its own environment before it serves, leaving alone any name
+that is already set, so a person's own foreground run still wins over the file. systemd's
+`EnvironmentFile=` is deliberately not used: it processes backslash escapes in an unquoted value, so
+the two characters `\n` that carry a line break inside `SFDK_RUNTIME_ENVIRONMENT` would arrive as a bare
+`n` and the certificate folded in there would hold no certificate at all. A machine with no file
+starts anyway — that is an enrolled machine's ordinary start — and a line that is not `NAME=VALUE`
+stops the start and is named.
+
+Where the file sits is the one thing that differs, and only because of who may write it. On a Linux
+machine the platform launched, cloud-init writes `/etc/sfdk/machine.env` from the user data and the run
+reads it; no install by a person writes there. A `worker` install that registers a service writes
+`<root>/machine.env` under the worker's own root — `C:\ProgramData\sfdk\worker\machine.env` on a default
+machine-wide Windows install — because an install that registers the worker in one person's own session
+cannot write under `/etc`. A Linux run reads both, the machine-wide one first. The platform's user data writes that file on a machine
+it launched, and a person enrolling one writes it or exports the same names in the shell that runs
+`worker enroll`.
+
+Beside them the worker keeps one file of its own, `<root>/state/machine-identity.json`, owner-only.
+It records the row this worker is bound to and — on a machine with no chip — the software holder key
+it is bound under, and it decides whether the next start claims or reattaches. A row this
+worker has already claimed cannot be claimed again, so a start that finds its own record takes the
+next generation under the key instead, and it treats the enrollment token its bootstrap file still
+carries as spent rather than refusing to start beside the row it names. The record also carries the
+last run that registered with the platform and the epoch it registered under, which is what an
+install waits for: everything else in it is written at the claim, before there is a broker link at
+all. It is kept only where the row outlives the program: a virtual
+machine that parks and wakes with its own disk, and a machine a person enrolled. A pod is replaced
+rather than woken, and its row is fresh with it.
+
+## The in-guest egress
+
+On the virtual-machine lanes this worker's own process is the transparent proxy, and it puts three
+things in place in one order that is not interchangeable:
+
+1. **The edge's certificate authority into this machine's trust store**, from the file the launch
+   wrote (or, where that file is not there, from the URL it names). Windows reads the machine
+   certificate stores and nothing else, so a certificate that is not there is every TLS client on
+   the machine failing its handshake with the edge; and on Windows a chain verdict computed before
+   the import stays cached machine-wide, so an import that actually wrote also throws that cache
+   away. It happens first because the redirect is live the moment it lands.
+2. **The listener**, bound before any rule exists, so no connection is ever sent to a port with
+   nothing behind it. On Windows an inbound firewall rule is written first as well: the rewritten
+   packet arrives as an inbound connection, which Windows Server blocks by default.
+3. **The redirect** — `iptables` on Ubuntu, WinDivert on Windows. The two WinDivert files are loaded
+   by absolute path from `<root>\bin`, where the image bake stages them, and never through the
+   operating system's own search order: opening the driver installs and starts a kernel service.
+
+Each accepted connection's original destination is recovered (`SO_ORIGINAL_DST` on Linux, the
+redirect's own proxy-port map on Windows; a recovery that misses is refused rather than sent to the
+peer, which carries the right host and the wrong port) and carried to the edge under the machine
+token this worker holds. There is no loopback round trip on these lanes: the process that holds the
+token is the process that presents it.
+
+What the worker's own uid reaches **without** the redirect is the launch's list — our broker and our
+gateway — plus three the launch cannot state: the egress edge, because redirecting the hop that
+carries a redirected connection is a loop with no exit; the platform's identity endpoint, because
+this worker calls it before it holds the token the edge would identify it by; and the metadata
+service, which answers the evidence that call presents. Nothing is uid-wide, so the object store
+stays intercepted and this worker's own content pulls meet the platform's rule at the edge.
+
+The redirect takes its Windows form on Windows and its `iptables` form everywhere else, whatever the
+substrate. A pod with an egress sidecar runs only the certificate step: the sidecar installs that
+lane's redirect and runs its own shim, which reads the token from the loopback feed below. A pod with
+no sidecar, as a customer's Launcher creates, names an intercept set and this worker installs the
+redirect itself.
+
+The private ranges `SFDK_INTERCEPT_SKIP_RANGES` names are never redirected, for any uid on any port:
+the rules return them ahead of the redirect, a nested container reaches them through its bridge, and
+the Windows filter excludes each range beside the single destinations.
+
+The proxy names a customer declares (`HTTPS_PROXY`, `HTTP_PROXY` and `NO_PROXY`, in either case) serve
+this worker's own calls to the platform and the broker. `NO_PROXY` must then hold `169.254.169.254`,
+because the metadata service is never reached through a proxy. Where a redirect is in place, the same
+names are left out of the environment each harness and the setup script are handed, so the agent's
+calls reach the redirect, which carries them to the edge.
+
+## The egress shim's token feed
+
+The shim that intercepts this machine's traffic stamps the machine token on it, and the worker is
+what holds that token. On Kubernetes the two are in different containers of one pod, so the only
+channel between them is the network: the worker listens on `127.0.0.1:7788` — a constant both halves
+carry, not a placed value — and the shim connects with retry.
+
+Each frame is one JSON line, newline-terminated:
+
+```
+{"generation": 7, "token": "<the machine token>", "expiresAt": "2026-09-12T10:15:00.123456Z"}
+```
+
+On connect the worker writes the generation this machine holds now, and one line per rotation after
+that. It writes nothing else on that socket and never reads from it, and it listens on loopback and
+nowhere else. A worker restart drops the connection; the shim reconnects and is fed the current
+generation again. The broker credential co-issued beside the token never crosses this channel, and
+neither does the holder key.
+
+## Building and testing
+
+```
+make verify    # gofmt, then vet for linux, windows and macOS
+make vet-all   # the vet half on its own, which is what type-checks the per-operating-system files
+make test      # the script harness's own tests, then go test with the coverage gate
+make build     # one static binary per release package, into npm/<platform>/, with the script harness beside it
+```
+
+### What a release is
+
+`make build` writes the five per-platform binaries into their package directories and copies the
+`script` harness in beside each, and those directories are what the publishing workflow packs. Two
+shapes of tarball come out of it, and the layout is stated here because that workflow reads it
+rather than deciding it:
+
+```
+@orchestraworks/worker-<platform>          @orchestraworks/worker
+  package.json                     package.json
+  worker (worker.exe on win32)     bin/worker.js
+  script-harness/                  README.md
+    package.json                   LICENSE
+    index.js
+    fetch-failure.js
+  LICENSE
+```
+
+Six published packages redistribute this tree, and an Apache-2.0 package that ships without the licence
+is redistributed on terms it does not carry — so `LICENSE` is one file here and a copy in every tarball.
+
+The per-platform tarball is the release artifact: its SHA-256 is the one digest the catalog carries,
+the register answer names and both fetch paths check, and it covers the binary and the `script`
+harness together, so a self-update carries the program with the binary. The launcher package holds
+no binary at all — it depends on the five as optional dependencies and runs whichever one npm
+installed for this machine. The build's output is ignored by `.gitignore`: the packages are
+published from a build rather than from the tree.
+
+The tests are Go tests plus two sets of Node's own — the `script` harness's, and the npm launcher's: no container runtime, no
+database, no stack, and no harness family is ever downloaded — a fake registry serves small archives
+that prove the install's own rules. The tests that
+need a real trusted platform module skip where there is none, and the broker suite drives a real
+`nats-server` named by `WORKER_TEST_NATS_SERVER` and skips when that is unset — so a `make test`
+meant to meet the coverage gate sets it:
+
+```
+WORKER_TEST_NATS_SERVER=/path/to/nats-server-2.14.6 make test
+```
+
+`WORKER_TEST_NATS_SERVER` is a knob a test process sets for itself, not a variable the platform sets
+on a machine, which is why it carries no `SFDK_` prefix and appears in no environment document.
+
+## Where a family keeps its state
+
+Every family keeps its conversation history — the transcripts that let a later session pick up where an
+earlier one stopped — in a directory it derives from `$HOME`. That is true of all four, and nothing in the
+runtime image baits any of them elsewhere:
+
+| family | state directory | how it resolves |
+| --- | --- | --- |
+| claude | `$HOME/.claude/` | Node `os.homedir()` — `$HOME` first, `getpwuid` fallback. |
+| codex | `$HOME/.codex/` | The Rust `home` crate, used when `CODEX_HOME` is unset. |
+| pi | `$HOME/.pi/agent/` (transcripts under `sessions/`) | `process.env.PI_CODING_AGENT_DIR ? resolve(...) : join(homedir(), ".pi", "agent")` — `pi-acp@0.0.33` `dist/index.js:1381` and `:1725`, and the harness's own `getAgentDir()` at `@earendil-works/pi-coding-agent@0.84.4` `dist/config.js:420-426`, whose variable NAME is assembled at `:405` from `APP_NAME` (`"pi"`). Transcripts: harness `dist/config.js:456-457`, adapter `dist/index.js:1397-1399` — the adapter prefers a `sessionDir` key in `<agentDir>/settings.json` when one is set (`:1383-1396`), and the baked settings file sets none. `pi-acp` also keeps its own session map at `$HOME/.pi/pi-acp/` (`:352`). |
+| script | none | The harness holds no conversational state. |
+
+An environment makes that state durable by declaring a volume mount at `/home`, which is where the
+account inside the runtime image already has its home directory. An environment that declares no such
+mount behaves exactly as it did before: the state is written to the machine's own disk and goes with it.
+
+That is why no image bakes `CODEX_HOME` or `PI_CODING_AGENT_DIR`. A pointer to a path outside `$HOME` is
+exactly what a durable home cannot survive: it would send codex's and pi's transcripts to the container's
+writable layer, which a recycle discards. Leaving both knobs unset lets each family's own `$HOME` fallback
+engage. Injecting a literal `CODEX_HOME="$HOME/.codex"` instead was rejected because env-value expansion is
+not portable — Kubernetes expands only `$(VAR)` and Docker expands nothing.
+
+### First-boot seeding
+
+codex and pi each need one file to already exist inside their state directory: codex's egress-placeholder
+`auth.json`, pi's provider-pinning `settings.json`. Both are image content, but the directory they belong
+in lives on a volume that is empty the first time a machine boots. So the image bakes each file as a
+template and the family's `seed` list in `facts/families.json` says where it goes:
+
+```
+codex: /opt/software-factory-codex/auth.json  ->  .codex/auth.json
+pi:    /opt/software-factory-pi/settings.json ->  .pi/agent/settings.json
+```
+
+The worker copies each pair before it spawns the harness, resolving every destination against `$HOME`. The
+copy is **copy-if-absent**: the first placement lays the templates down, and every later one finds whatever
+the harness has written since — a refreshed token, an edited setting — and leaves it alone. Seeded files are
+created `0600`, parent directories `0700`, and the step never creates `$HOME` itself. The claude and script
+families declare an empty `seed`, so the step is a no-op for them.
+
+### Whether a conversation resumes
+
+Durable storage makes state survive a recycle; whether a family *resumes* a conversation also needs its ACP
+adapter to implement `session/load`. All three model-backed adapters do, verified against the shipped
+artifacts:
+
+- **`claude-agent-acp@0.70.0`** — advertises `agentCapabilities.loadSession: true` and implements
+  `loadSession(params)`, registered on the connection as the `session/load` request handler
+  (`dist/acp-agent.js:788`, `:6909`).
+- **`codex-acp@1.11.0`** — implements `session/load` by resuming the codex thread and replaying that
+  thread's history as `session/update` notifications before it answers the request. Read in the adapter's
+  built code at the pinned version; the `0.16.0` adapter it replaced carried the same method inside its own
+  native binary.
+- **`pi-acp@0.0.33`** — advertises `agentCapabilities.loadSession: true` and implements `loadSession(params)`,
+  which respawns pi against the stored session file and replays its messages (`dist/index.js:1935`, `:2460`;
+  the helper that binds a session object to an existing pi process is at `:753`). Confirmed on the wire: an
+  ACP `initialize` against the shipped binary answers `protocolVersion: 1` with
+  `agentCapabilities.loadSession: true`. That is the *capability*, not the replay itself — pi still has no
+  captured `session/load` transcript, which is the one resume-evidence gap open on this lane.
+
+## The command's environment is the family's pass-through list, and nothing else
+
+The worker does not *merge* an environment into a harness process: the family's `passEnv` enumeration in
+`facts/families.json` **is** that process's complete environment. An environment cannot declare an
+`SFDK_` name for it, because `SFDK_` is reserved apart from the four `SFDK_WORKER_*` release settings, which
+reach the worker and never a harness process. A derived image that bakes a name the list does not carry, such as `ENV JOB_TARGET=…`, gets **silence**,
+not an override: the variable never reaches the command, and a job running under `set -u` aborts on the
+first reference to it. Per-job configuration travels the prompt, the agent's instructions, or a file in the
+image.
+
+Every family's harness process also gets `SFDK_SESSION_ID`, which the worker sets from the `sessionId` on
+`session_placement.apply`: the worker adds it itself, so it needs no `passEnv` entry, whatever the worker's
+own environment holds. The `script` family adds only
+`SFDK_ORGANIZATION_ID` to the command it runs, from its stored conversation metadata; its command inherits
+the session variable from the harness process. Neither grants egress authority.
+
+**On Windows that list is shorter than the operating system's own habits assume.** It is
+OS-independent, so a Windows job sees `PATH`, `HOME` and `USERPROFILE` and *not* `TEMP`, `APPDATA` or
+`ComSpec` — names a PowerShell one-liner reaches for without thinking (`$env:TEMP`). The list is not a
+filter over the environment: the worker *builds* the child's environment from it, so a name the platform
+set on the service and the family does not declare is simply gone by the time the command runs.
+
+**Three names are backfilled for Windows and none of them is on any family's list.** A backfill is the
+treatment for operating-system *plumbing* — a variable the machine needs to work at all, as opposed to
+configuration a customer chose — and it is if-absent, so a declared spelling always wins. Two come from
+libraries: Go's `os/exec` adds `SYSTEMROOT` whenever a caller sets an explicit environment, and libuv copies
+its own required-variable set into a spawned child from *this* process's environment — which is why `PATH`
+reaching the command is what lets `powershell.exe` and `taskkill.exe` resolve at all. The third is ours:
+**`PATHEXT`**, the list of extensions PowerShell treats as *executable*. With it unset the effective list
+collapses to `.CPL`, so a `curl.exe` PowerShell resolved on `PATH` is a **document** rather than a program
+and invoking it throws `CantActivateDocumentInPipeline` — before a process starts, before a packet leaves.
+Every network probe on the Windows lane came back `000`, which reads exactly like a blocked connection.
+
+The neighbours a reader expects beside it were **measured and left out**, each changing nothing on a Windows
+Server 2025 runtime AMI: `cmd.exe` and `.bat` files run from CreateProcess's own default without `ComSpec`,
+`%SystemRoot%` expands from the `SYSTEMROOT` `os/exec` already backfills, `SystemDrive` and `windir` are
+unused by realistic work, and a service's temp directory falls back to `C:\Windows\SystemTemp` without
+`TEMP` or `TMP`. Add a fourth name only with that kind of evidence. Machine plumbing is not configuration
+and must never be pushed into the prompt: a job cannot set `PATHEXT` for a shell that has already refused to
+start its first program.
+
+Three more bounds a job author should know:
+
+- **Turn wall clock.** The platform bounds a turn with its own response timeout (default 600 seconds,
+  configurable). A job that can run longer needs that raised, or it is killed mid-turn and reported as a
+  runtime failure regardless of what the script was doing.
+- **`session/load` re-executes.** The script harness holds no conversational state, so a resumed
+  conversation's command runs again. That is the safe direction — a fresh, deterministic run — and another
+  reason to keep commands idempotent.
+- **`cwd` is the session's.** `session/new` (and `session/load` on a revival) carries the workspace path, the
+  worker maps it to this machine's native filesystem — `C:\sf\workspace` on Windows — and the harness spawns
+  the command there. A session that declares none inherits the harness's own directory; one that does not
+  exist fails the spawn, which the turn reports as an ordinary exit-127 failure with the operating system's
+  message attached.
+
+## What the `script` harness answers
+
+The worker runs one harness process per session placement and speaks ACP to it as its client. The `script`
+family's harness is the one the worker carries itself (`script-harness/`), and its dispatch table is:
+
+- `initialize` — the harness identifies itself.
+- `session/new` — a fresh session id, with the session's declared working directory anchored on it.
+- `session/load` — the session's replay, as the `session/update` notifications emitted between the request
+  and its response. It executes nothing and calls nothing, and it restores the duplicate-execution guard
+  below, which the notifications cannot carry.
+- `session/prompt` — execute the agent's instructions, stream stdout and stderr as `session/update`
+  notifications, move platform state from the exit code, then answer. Streaming is bounded twice: each frame
+  is sliced at 32000 characters (one over-long line would trip the line scanner and kill every session on
+  the pipe, not just this turn), and a turn's **total** streamed volume is capped at 5 MiB of **wire** bytes
+  — the JSON-encoded frame text, since that is what the platform records, and JSON escaping inflates
+  control-heavy output up to about six times (one NUL byte is six wire bytes). Past the ceiling the harness
+  emits one truncation notice and stops streaming, while the command still runs to completion with its
+  exit-code contract unchanged.
+- `session/cancel` — stop the in-flight command **and everything it started**, then answer. On Linux that is
+  a `SIGTERM` to the command's whole **process group** (commands run detached, so the group dies with the
+  command and not just with the `bash -c` parent); on Windows there are no process groups to signal, so it
+  is `taskkill /T /F /PID <pid>`, which walks the process tree. A cancelled turn made no determination, so
+  it claims nothing and answers the prompt with a JSON-RPC error. Whether a turn counts as cancelled is read
+  off an observed **fact about the kill**, never off the arrival of the cancel, and each operating system
+  supplies the fact it can: on Linux the command's **exit shape** (one the signal actually killed reports
+  `signal = SIGTERM`, one that had already exited reports its own status), and on Windows — which terminates
+  a process with an exit *code* and no signal — the kill's own answer, so the harness checks whether the
+  shell was still running when the cancel arrived and only then kills. Either way a cancel racing a script's
+  own `exit 0`, including the window after the shell exits but before the harness reaps it, leaves the turn
+  with the result it earned, claim included. (That liveness check is also a safety requirement on Windows,
+  which recycles process ids: a `/T` on a stale one would kill a stranger's process tree.)
+
+A turn that settles while a backgrounded grandchild still holds the pipes signals that process group and
+detaches the streams, so nothing leaks into the next turn's transcript. That sweep is **conditional and
+best-effort**, and a job author should not read it as a guarantee that background work dies with the turn:
+it runs only on the grace-timer path, so a background job whose stdio is redirected (`cmd >/dev/null 2>&1 &`)
+lets the pipes close promptly, settles the turn before the timer, and survives it untouched. It is also
+`SIGTERM`-only — a process that traps or ignores `TERM` survives either way. Nothing of the sort leaks into
+the *transcript*; what survives is the process.
+
+A second prompt on a **workflow-step** session whose earlier claim is confirmed landed is answered as a
+no-op turn without re-executing the command (warm reuse and steer promotion both make that routine); an
+earlier claim that is merely *attempted* is re-confirmed against the run first. The no-op is step-scoped on
+purpose: an ordinary message appended to a direct-start session is a real new turn and always executes.

package/bin/worker.js

@@ -0,0 +1,80 @@
+#!/usr/bin/env node
+// The launcher npm puts on the path. It runs the binary out of the per-platform package npm installed
+// for this machine and stays in front of it for the process's whole life, because a service manager
+// supervises the command it started: the pod's SIGTERM lands on this process, and the worker's shutdown
+// report and orderly harness stop only happen if it reaches the binary behind it.
+
+import { spawn } from "node:child_process";
+import { createRequire } from "node:module";
+import { constants } from "node:os";
+import { existsSync } from "node:fs";
+
+const require = createRequire(import.meta.url);
+
+const OPERATING_SYSTEMS = { linux: "linux", darwin: "darwin", win32: "win32" };
+const ARCHITECTURES = { x64: "x64", arm64: "arm64" };
+
+// The three a supervisor ends a process with. Everything else is either unforwardable (SIGKILL, SIGSTOP)
+// or something the worker has no shutdown meaning for.
+const FORWARDED_SIGNALS = ["SIGTERM", "SIGINT", "SIGHUP"];
+
+function binaryPath() {
+  const operatingSystem = OPERATING_SYSTEMS[process.platform];
+  const architecture = ARCHITECTURES[process.arch];
+  if (!operatingSystem || !architecture) {
+    throw new Error(`there is no worker release for ${process.platform}/${process.arch}`);
+  }
+
+  const packageName = `@orchestraworks/worker-${operatingSystem}-${architecture}`;
+  const binary = operatingSystem === "win32" ? "worker.exe" : "worker";
+  let resolved;
+  try {
+    resolved = require.resolve(`${packageName}/${binary}`);
+  } catch {
+    // The per-platform packages are optional dependencies, so an install that skipped this one — a
+    // lockfile from another machine, or `--no-optional` — leaves the launcher with nothing to run.
+    throw new Error(
+      `${packageName} is not installed; install it, or reinstall @orchestraworks/worker on this machine`,
+    );
+  }
+  if (!existsSync(resolved)) {
+    throw new Error(`${packageName} carries no ${binary}`);
+  }
+  return resolved;
+}
+
+// A signal is not an exit status: reported as the shell convention so a supervisor reading the status
+// can tell a killed worker from one that exited.
+function statusFor(code, signal) {
+  if (!signal) {
+    return code ?? 1;
+  }
+  return 128 + (constants.signals[signal] ?? 0);
+}
+
+function run(binary) {
+  const child = spawn(binary, process.argv.slice(2), { stdio: "inherit" });
+
+  for (const signal of FORWARDED_SIGNALS) {
+    // Listening at all is what stops Node ending the launcher on its own and orphaning the worker
+    // mid-shutdown: the launcher outlives the signal and exits on the child's exit instead.
+    process.on(signal, () => {
+      if (child.exitCode === null && child.signalCode === null) {
+        child.kill(signal);
+      }
+    });
+  }
+
+  child.on("error", (failure) => {
+    console.error(`worker: ${failure.message}`);
+    process.exit(1);
+  });
+  child.on("exit", (code, signal) => process.exit(statusFor(code, signal)));
+}
+
+try {
+  run(binaryPath());
+} catch (failure) {
+  console.error(`worker: ${failure.message}`);
+  process.exit(1);
+}

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@orchestraworks/worker",
+  "version": "0.0.134",
+  "type": "module",
+  "description": "The Software Factory worker: the one program that runs inside a machine and speaks the worker protocol to the platform.",
+  "license": "Apache-2.0",
+  "author": "Living Computers",
+  "homepage": "https://orchestraworks.ai",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/livingcomputers/software-factory.git"
+  },
+  "engines": {
+    "node": ">=22"
+  },
+  "bin": {
+    "worker": "bin/worker.js"
+  },
+  "files": [
+    "bin",
+    "README.md"
+  ],
+  "optionalDependencies": {
+    "@orchestraworks/worker-linux-x64": "0.0.134",
+    "@orchestraworks/worker-linux-arm64": "0.0.134",
+    "@orchestraworks/worker-darwin-x64": "0.0.134",
+    "@orchestraworks/worker-darwin-arm64": "0.0.134",
+    "@orchestraworks/worker-win32-x64": "0.0.134"
+  }
+}