best-peer 0.0.31

best-peer 0.0.31

Each job runs on a disk of its own with a hard size, made and removed by best-peer-disk, a small socket-activated root helper, so the peer itself never needs root or the right to mount.

Commits since v0.0.30

• Review: release opens out with openat and the device check, as the walk opens every directory below it, since the helper's unit answers openat2 ENOSYS (b53e1ac)
• Review: a disk the peer mounts itself, and a job's inputs and outputs, fail in words that name nothing of the host (4ce8521)
• Review: what the disk helper says of the host goes to the peer's log, and an order is told a fixed sentence, so no host path reaches the renter (2289e2f)
• Review: the disks' directory and each disk's root are closed to every user but root and the peer, so no one else on the host reads a job's inputs or plants its outputs (cd85779)
• Review: the loop device behind a peer's own mount is found by the mounted path's device number, so a data folder reached through a link still gets its disks (e3f8bcf)
• Review: a disk's loop device passes no discard on, so a host's fstrim never gives the room reserved for it back (7d87066)
• Review: a disk's image is formatted without discard so its room stays reserved, and list refuses a field it does not take (32d6c8e)
• Review: the disk's total_bytes is described as the largest disk one job may be given here, in the schema, the metric's help and the README (1446ed7)
• Review: a member tells the largest disk it makes as its disk's size, and a cloud places a disk only on a member that makes one that large (9dfef8f)
• Review: each disk is counted once, by the helper's own rule, and the bound on one disk holds each order at ingest, never the room for all (37b748a)
• Review: a disk promised and not yet made counts against the helper's most disks, so the second of two orders admitted at once waits rather than fails at make (6ac6a12)
• Review: the helper lists its bounds and the peer holds its room to them, a failed release is tested, serve is tested over a socket pair, and no client is named (1512be7)
• A release carries best-peer-disk and its two units in the Linux archive, so a node pins the helper with the peer (79700bb)
• BEST_PEER_DISK_HELPER names the disk helper's socket, and the helper ships with its two units and the README's install, so a hardened peer runs jobs with disks (af7d0f2)
• The Docker runtime makes, releases and removes a job's disk through the disk helper when it is given one, so a peer that may not mount still gives each job a disk of its own (775022e)
• A job's disk is laid out by the runtime that makes it and released to the peer before its outputs are packed, so a peer that does not own what the job wrote still reads it (da2ec59)
• A best-peer-disk helper makes, releases and removes a job's disk for a peer that may not mount, since a peer hardened as a service can never mount one dockerd sees (2291ed3)

Run it

One binary, and on Linux the disk helper best-peer-disk with its two systemd units beside it, for a peer run as a user of its own (the README's "Run as a service with the disk helper"). Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.31. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.31-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.31-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.31-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.30

best-peer 0.0.30

A resolve and a pull can carry a registry token, sent to the image's own registry alone and never shown, so a node can pull an image a platform's registry keeps private.

Commits since v0.0.29

• Review: a runtime that keeps the trait's defaults is tested to refuse a credential, since only runtimes that carry one were (89178fa)
• Review: the Docker adapter's credentials are tested as the engine receives them, since only a host run proved them (a7e2cb1)
• Review: the registry test names a neutral host, since a client's platform is named nowhere in best-peer (c171aba)
• Review: a first part with an uppercase letter names a registry, as Docker reads it, so a Docker Hub token never goes to it (da63399)
• Review: a registry token's registry is read as a bare host and port, so a name with @ or another sign never reaches Docker Hub (9ec29b6)
• Review: a registry token names its registry by a host, a pull refused before the registry is asked is not counted as pulled, and the README tells the credential (62e8766)
• Resolve and pull with a registry token for the image's own registry, so a node can pull an order's image from a registry that grants that one pull (8ec27e7)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.30. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.30-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.30-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.30-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.29

best-peer 0.0.29

An order's image is resolved at the registry and pulled, run and removed by digest, so no tag on the host is moved or removed, and a pull that leaves a held image as it was succeeds whatever it unpacks to.

Commits since v0.0.28

• Review: resolve's doc says plainly that neither its request nor a pull's carries credentials, since "as a pull's does not" read as if a pull's did (59d8fe8)
• Review: resolve's doc says its request carries no credentials, as a pull's does not, since it said the engine sends what it keeps for the registry and the daemon keeps none (aa08571)
• Review: the README says a digest is held only under its own repository however spelled, that holds is the engine's answer alone, and what holding a pinned reference means for the peer, since the rows said any listing of the digest and the peer's text did not say (a8cfdb9)
• Review: a digest is held only under its own repository however it is spelled, and holds and resolve say a caller resolves every reference first, since a digest matched under any repository and holds alone answers from the engine (55780a1)
• A runtime resolves a reference at its registry to one pinned by digest, which pulls, runs and removes that image without touching a tag, since a pull by tag moved an owner's tag and a removal by tag took one the owner pulled meanwhile (4673827)
• A pull that leaves the image the engine held as it was succeeds whatever that image unpacks to, since none of it landed on the disk and an owner's own large image failed every order (5e49bde)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.29. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.29-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.29-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.29-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.28

best-peer 0.0.28

A boxed job runs as uid 65534 whatever its image names, and a pull is held to the room it takes on the engine's disk and to the floor it leaves.

Commits since v0.0.27

• Review: owner and opened jobs are said to run as their image's user, a floor whose room cannot be read is its own error with its own fix, and a job's inputs are readable by it whatever the peer's umask (5bc4bd8)
• Review: a boxed job's user is in the catalogue, a held reference a pull moved past its limits names the owner's image again, a pull is held to one last reading of the room, and the README names pulls held to limits (d51ccb0)
• A pull is held to what lands on the engine's disk while it runs, its room taken and the floor left, since a bound on compressed layer sizes let an image unpack to several times as much (51fe079)
• A job's container runs as uid 65534 whatever its image names, since root in a container is root on a host without userns-remap (73f672e)
• Review: say in section 2 that what the spec does not mention is best-peer's own, as section 1 does (5a1fc9f)
• Say that a behaviour the spec does not mention is best-peer's own, never an entry on spec#37 (283aa43)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.28. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.28-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.28-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.28-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.27

best-peer 0.0.27

A runtime follows what a container writes from its first byte, and the Docker adapter keeps an exited container until its followers have read it all; the room for images is read at the mount holding the engine's root when that root is closed to the peer.

Commits since v0.0.26

• The free-room test asserts what each platform reads, the room on unix and Unsupported elsewhere, since free_or_why reads no room off unix by design and the test failed the gate on Windows (56d23df)
• Review: a container that exits before its first follower is removed and its follow answers NoSuchContainer, set aside, since Runtime::follow promises a container running or exited and not yet removed, and the adapter counts a follower before its first await, so a caller that follows the moment start answers is never too late in practice; Windlet.Node does so (2997298)
• Review: a follower dropped by its caller ends at once even while the container writes nothing, a container removed between the look and the feed is told as gone, the fake says aloud when a follower falls behind, and the README names following (7e19734)
• A runtime follows what a container writes from its first byte, and the Docker adapter removes an exited container only once its followers have read it all, keeping the engine's copy bounded (8edd82f)
• Review: read the mount table only when the engine's root is closed, and say so when the table itself cannot be read (8dab8a1)
• Review: say why the room for images is not known, a root not on this host, closed with no mount holding it, or a mount that cannot be read, instead of one warning naming a mount lookup that may never have run (18c791e)
• Review: resolve the links above a closed engine root as far as the peer reaches before matching it in the mount table, which names real paths (7a03238)
• Review: tell an engine on this host by the loopback its ports are bound to, not by DOCKER_HOST, which the client's local connection never reads (bfea9b8)
• Review: read the mount holding the engine's root only when a directory above it is closed, so a root not on this host, as one in a virtual machine, has no room here (f1f27dc)
• Read the room for images on the file system holding the engine's root, found in the mount table when the directory is closed to the peer, and never on this host for an engine elsewhere (c62ff50)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.27. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.27-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.27-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.27-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.26

best-peer 0.0.26

A job's closed box takes half the host's cores and 65536 open files at most and dumps no core, a volume its image declares is a private tmpfs, a container handed a card gets the driver's compute and utility capabilities alone, and the engine's seccomp and AppArmor profiles are named on each container; and a caller of the runtime crate may remove an image it pulled, read the room free where the engine keeps its images, and bound what a pull downloads.

Commits since v0.0.25

• Review: say in run-job which ceilings of the box the operator sets and that no core dump and the driver's capabilities hold for every container, and why an engine set unconfined is still named the built-in profile. (baa9d4d)
• Review: leave a declared volume the spec mounts over to its mount, set the driver's capabilities once, name the built-in seccomp profile only where the engine knows the name, and say what the box and a given-up pull now are. (6a8d342)
• A runtime pull may be bounded by what it downloads and is given up with TooLarge once the layers' sizes pass the bound, so a caller that runs strangers' images can refuse an image too large for the host before it has downloaded it. (2fb1044)
• The runtime removes an image by the reference it was pulled as and says the room free where the engine keeps its images, so a caller that runs strangers' images can refuse a pull that would fill the host's disk and remove each image once its run is over. (f7684dd)
• Name the engine's built-in seccomp profile and AppArmor's docker-default on every container where the engine's info offers them, since a container otherwise rests on daemon defaults that a change to the engine's configuration could drop. (c9f28e5)
• Give a container handed a card the NVIDIA driver's compute and utility capabilities alone, set last in its environment, since an image could otherwise ask the toolkit for every capability of the host's driver. (7d90931)
• Mount a private tmpfs the size of /tmp over each volume a boxed container's image declares, since the engine otherwise makes an unbounded anonymous volume on the host's disk for it. (a3f3c22)
• Hold a job's box to half the host's cores and 65536 open files, and let no container dump a core, since a stranger's job could otherwise take every core, every file handle, and write its memory to the host through the core handler. (85ae447)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.26. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.26-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.26-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.26-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.25

best-peer 0.0.25

A key creates workspaces only with the workspaces scope and up to its limit, and an owner archives one; a workspace door asks its store nothing while it admits an order, so a missing or oversized input is now a JobFailed with a code, not a 400; and a caller of the runtime crate may name the container it starts and find it again by that name, or is told the runtime cannot.

Commits since v0.0.24

• Review: say on Spec.name that only an adapter which finds containers by name carries it as a label, since the native runtime ignores the name and the line implied a label it never writes. (c5ef2bf)
• Review: say on NoName that it is the runtime's inability, not a name without a container, which is Ok(None), since the doc line read as if a missing name were an error. (7da95b4)
• Review: give a runtime that finds no container by name its own error, since the engine variant told a host with no engine that its engine failed and to read logs it does not have. (0e949ac)
• Make a runtime that cannot find a container by name answer an error, not none, since a reconciling caller would read none as nothing to stop and leak the container. (edfcbb3)
• Review: choose the newest same-named container in a pure function that keeps the engine's order on a tie, and test it, since created is whole seconds and max_by_key kept the oldest of a tie. (8a69226)
• Review: pick the newest of several same-named containers by their creation time, not by the order the engine lists them. (51bcdfd)
• Review: keep the caller's name out of the adapter's log and answer the newest container when several carry one name, on the Fake as on Docker. (038dc46)
• The runtime can name a container for its caller and find it by that name, so a caller reconciles by name instead of remembering ids (cfed3ec)
• Review: a store removed or replaced before an order's inputs are sized ends it with no code, as at dispatch, and a question past the order's deadline is late, not unreachable (9760879)
• A workspace door asks its store nothing while it admits an order: the inputs are sized once the order is taken, eight questions at a time for the workspace within a minute, and what the store says ends the order in JobFailed (d72a1e0)
• Review: the README says the root tells an owner the archive of its workspace, and that a workspace's stream ends with it (077de94)
• Review: every way an archive's late commands fail is run by hand in the archive test, each caught when its check is taken out (5c14726)
• Review: a create whose credential was taken back before it ran, and the start deleting what an archive left, are tested (947eeb4)
• Review: a membership or cloud command admitted before its workspace was archived fails when it runs after, and a member's stream held open ends on the archive (66f86a2)
• Review: a set-store admitted before its workspace is archived keeps no credential when it runs after, and two archives at once end the workspace once (c3e8870)
• A key creates workspaces only with the workspaces scope and owns 8 at most, or the count its approver set, and its owner archives one for good to free its place, so no key can exhaust the peer's open files with workspaces or make one to reach a store it chose (0a0923d)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.25. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.25-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.25-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.25-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.24

best-peer 0.0.24

Every peer serves /metrics to a collector holding a key that may read them and nothing else, and a cloud door serves its members' series under the workspace, the cloud and the peer; best-peer answers -h and --help with its commands and settings.

Commits since v0.0.23

• Review: a renamed or re-pointed member's series are cleared after the members are swapped, and a scrape checks its member and writes under the one series lock, so the machine a name stood for before cannot be shown as the one it stands for now (006a612)
• Review: a key held to the accelerators reads no member's CPU among the federated series, and a scrape answered after its member was removed, re-pointed or no longer admits the cloud is dropped (aa96633)
• Review: a cloud door serves of a member only what is the cloud's to show, to whom it may show it: the machine's own series and the workloads the cloud placed there, the door's labels winning, to a collector for every cloud and to a key approved for all for the workspaces it is a member of; a removed, re-pointed or no longer admitted member has none, and the scrape never holds back the tick (90159ea)
• A cloud door serves its members' series under where they sit: each cloud reads a member's /metrics with its own credential at every reconcile tick, and the door serves them labelled workspace, cloud and peer to a key that reads the whole door; a member that does not answer has none. A metrics key stands alone, and a workspace's door serves no /metrics (behavioralstate/spec#47) (4665888)
• Every peer serves /metrics, how its devices, workloads and door move, to a collector holding a key that may read them and nothing else (behavioralstate/spec#47) (2ba23d0)
• best-peer answers -h and --help with its commands and the settings to start with, and each command with its usage, so an operator or an agent setting a peer up can ask the binary what it takes (behavioralstate/spec#83) (1f430dc)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.24. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.24-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.24-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.24-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.23

best-peer 0.0.23

A card its owner is using takes no new work, and the owner holds and releases the machine by hand; a key taken back takes its work with it; a peer that cannot mount makes no disk for a job and never takes the last of its file system. An agent driving a workspace on a GPU host from the manifest alone is recorded in acceptance.

Commits since v0.0.22

• Review: a credential taken back is checked before a hold that ended a starting workload, and a hold that could not stop one leaves it to come ready, so neither depends on timing nor leaves a deployment starting for ever (29a7c58)
• A peer that cannot mount makes no disk for a job and reserves no room for one, and a disk never takes the last of its file system, so a job asking for a disk cannot fill the peer's volume (3271f4e)
• A key the operator takes back takes its work with it: its waiting orders end before they start, its jobs stop and its deployments end, unless revoke is told --keep-running, so a key taken back for misuse leaves nothing to start later in its name (5023f68)
• A card its owner is using takes no new work, found from the driver and never logged, and the owner holds and releases the machine by hand, so a personal GPU can be lent without competing with its owner (55ad893)
• Review: an issue filed for an epic's work is made its sub-issue and carries its label, and enhancement is never used since an issue that is not a bug is one by default (9975a5a)
• The board's labels say which one epic an issue belongs to: an epic carries epic and a label of its own, the product's name with a number, and every issue of it carries that label and no other epic's (f8f58c0)
• Review: the release script's usage example is the next patch, not a minor, as SDLC.md now says (3fc2391)
• A release is a patch, and the minor or the major goes up only when the owner asks for it, so SDLC.md no longer has a capability raise the minor on its own (e8587b2)
• Review: the run's record gives the joining read as two thirds of a second before the door's poll and the engine image's pull as 1 minute 17 seconds, as the logs have them (8b5fc95)
• Review: the run's record says the agent's code was approved six seconds after the client showed it and only the member's before it asked, scopes the cloud on every fact to those from CloudConfiguredV1 on, counts the client's two questions among the 31 calls, gives 6:02 from the person's sentence, and the README's definition of done names the new record (92e9430)
• Review: the run's record says when each approval was made and that the agent's joining read came half a second before the door's poll, names the peer on the facts a member told and not on the job's order, gives the client's time as 6:20 with 2:37 waiting and the model ready 13 s after the pull, and says how the member was seen empty; the run's credential file is deleted as the record says (7091df2)
• An agent drives a workspace on a GPU host from the manifest alone, recorded in acceptance: Copilot through best-mcp 2.6.0 signs in to best-peer 0.0.22's door, creates a workspace, configures a cloud with a V100 member, deploys, prompts as a command and reads PromptAnswered with the cloud and peer, runs a job whose end carries its output, and undeploys; the README's step 5 links it (behavioralstate/spec#62, behavioralstate/spec#73) (80c7f53)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.23. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.23-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.23-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.23-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.

best-peer 0.0.22

best-peer 0.0.22

An agent reaches the workspace it made through the published connector (best-mcp 2.6.0): the root's sign-in names no tenant, and a stranger is told to act with the credential that made or joined the workspace. A job's end carries the last lines it printed, and its outputs are its files, directories and links, streamed to the store, cut by a stop or the order's deadline.

Commits since v0.0.21

• Review: a stranger to a workspace is told to act with the credential that made or joined it, the README names the best-mcp that reaches a workspace, and the departure is entries 2 and 23 of spec#37 (ab18754)
• The root's token answer names no tenant_id, and a stranger's NO_SUCH_WORKSPACE says that a sign-in is a new identity, so an agent reaches the workspace it made with the credential that made it (behavioralstate/spec#73) (b371ef7)
• Review: the peer bounds a job's output itself, the Docker read keeps only its end, and the outputs paths and the size rule say where output is (e46684b)
• A job's end carries the last lines it printed, so an agent that ran a job reads what it said from the manifest alone (091ba39)
• A job's outputs are its files, directories and links, streamed to the store as they are packed, and a stop or the order's deadline ends their sending (#53) (a05db7f)
• Review: the main a pull request is squashed onto is noted from the worktree, after the fetch (267d366)
• Review: a pull request's reviewed head is recorded and compared in full, and a merge waits for the gate again when main moved since it (a47680b)
• Review: a pull request's head is compared at seven characters, and its merge is pinned to the head that was gated (30129bb)
• Review: every rule says the pull request's gate runs on what would land, a push since its review sends it back to the review, and the scratch worktree is removed by force (1b4d430)
• Review: a contributor's pull request is gated on what would land, its head squashed onto the current main (7521f59)
• Review: the review skill's opening, CLAUDE.md and SDLC.md section 6 say the whole merge and rebase rule (1d21212)
• Review: a rebase that brings commits in sends the gate back to the new head, a fork's code runs only after its diff is read, and a red gate is reported as not ready (0ca7164)
• Review: a set-aside finding is recorded in an empty Review: commit, the gate runs last on the head pushed, and a contributor's pull request is read and gated at its own head (14ddb69)
• Every change is made on main and pushed there, after the local gate and the mandatory review, so work no longer waits in pull requests (62aa106)
• An epic is In progress as soon as any of its issues is In progress, In review or Done, and Backlog before that, so the board's columns say which goals have work under way (#52) (fd3e72a)

Run it

One binary. Download the archive for the machine, check it against SHA256SUMS, unpack it and run best-peer with the environment the README's Run section names; best-peer --version says best-peer 0.0.22. Each archive is here twice, byte for byte the same: under the name with the version, for pinning, and under the name without it, which releases/latest/download/<name> resolves to the newest release, as the README's commands use.

Machine	Archive	Same file, unversioned
Linux x86_64 (glibc 2.35 or newer)	best-peer-0.0.22-x86_64-unknown-linux-gnu.tar.gz	best-peer-x86_64-unknown-linux-gnu.tar.gz
Windows x86_64	best-peer-0.0.22-x86_64-pc-windows-msvc.zip	best-peer-x86_64-pc-windows-msvc.zip
macOS Apple silicon	best-peer-0.0.22-aarch64-apple-darwin.tar.gz	best-peer-aarch64-apple-darwin.tar.gz

Every archive carries a build provenance attestation: gh attestation verify <archive> --repo behavioralstate/best-peer.