status.md

Project status

This page is the single source of truth for what current main supports and what evidence backs each claim. Other documents describe how things work and link here for status. When this page and another document disagree, this page wins; please report the mismatch.

v0.7.0 is published as a GitHub pre-release: the six example release archives from its Release qualification run, unchanged, with their SHA-256 files and GitHub artifact attestations. There is no npm release and no signed update channel operated by the project; no release key is pinned. v0.7.1 is published the same way as a GitHub pre-release and is an earlier baseline. v0.8.0 is published the same way as a GitHub pre-release and is an earlier baseline. v0.8.1 is published the same way as a GitHub pre-release and is an earlier baseline. v0.9.0 is published the same way as a GitHub pre-release and is an earlier baseline. v0.9.1 is published the same way as a GitHub pre-release and is an earlier baseline. v0.11.0 is published the same way as a GitHub pre-release and is an earlier baseline, replacing v0.9.1; v0.10.0 was never published and shipped inside it. v0.12.0 is published the same way as a GitHub pre-release and is the previous baseline, replacing v0.11.0. v0.13.0 is published the same way as a GitHub pre-release and is the production-validation baseline, replacing v0.12.0. Every milestone below is a preview milestone.

v0.13.0 production-validation baseline

v0.13.0 is the one PiShip baseline a production consumer pins for production validation, replacing v0.12.0. A production consumer pins tag v0.13.0 and installs its qualified release artifact directly; it does not track main. It is a minor milestone on Pi 1.1.0 and the stable contracts piship/v1 and piship-lock/v1, with piship/v1alpha6 and piship-lock/v1alpha6 accepted for the migration window. The changelog lists every change since v0.12.0.

• Qualification: tag v0.13.0 is commit 7f9e167d7e78d54783f47db5455f8196e98dc79c (the squash of #255, which is also the version change). Release qualification run 37887824632 passed on that exact commit on its first attempt: 54 jobs passed and 2 were skipped (the issue-report jobs, which run only on schedule). They are CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode with reproducibility 9 of 9 payload-equal, verify-release, tamper rejection, offline install checks, attestations verified, registry signatures passed on 9 of 9, and vulnerabilities passed on 9 of 9). The devcode archives of the two builds differ in bytes only because vulnerabilities.json records the scan time. Release qualification excludes live Chrome startup, which the nightly and manual Portable E2E keep. During the qualification cycle two macOS sandbox conformance test failures (the seatbelt reference tests, which are timing sensitive) appeared on pull-request runs and passed on the next run. The pre-release, published 2026-10-09, carries the nine attested archives with their SHA-256 files; the digests are below (recorded evidence).
• Changes since v0.12.0, in short (the changelog has the full list): pi-code's subagent tool works in a distribution, its children taking the same governed launch (model allowlist, broker credential, print mode's JSON events) only from a running session of the same user, only with the options pi-code passes, and only in the parent's workspace or a verified git worktree; parallel children wait up to about three seconds for the package-configuration lock instead of failing on it; resources.packages[].pretranspile writes the TypeScript modules a package's extensions import as JavaScript at build time (esbuild 0.28.2); the Pi pin and its seven sibling packages move from 1.0.3 to 1.1.0; and on Windows, looking up a lock owner that had just exited no longer prints PowerShell's error text.
• PiShip version: 0.13.0 (every @piship/* package and PISHIP_VERSION in compatibility.ts); every example is relocked with it. piship diff against the v0.12.0 locks reports risk high for all three examples only because the Pi runtime changed from 1.0.3 to 1.1.0 (the other changes are the PiShip version and the seam digest).
• Schemas: manifest piship/v1 and lock piship-lock/v1, unchanged; piship/v1alpha6 and piship-lock/v1alpha6 stay accepted for the migration window (version map). The optional resources.packages[].pretranspile field is new and off by default. A release built with it is not accepted by a runtime built before v0.13.0: v0.12.0 stops with INTEGRITY_FAILED ... Unknown field pretranspile and the installed release stays healthy, so the runtime has to be updated first (manifest, changelog).
• Pinned Pi: @earendil-works/pi-coding-agent 1.1.0, exact-pinned in packages/pi/package.json, with its seven sibling packages pinned exactly. compatibility/pi.json and the copy in @piship/core list 1.1.0 beside 1.0.3, 1.0.2, 1.0.0, and 0.87.1 with the same four surface statuses (personal supported; managed, governance, and lifecycle candidate), carried over from 1.0.3 and not earned again. Release qualification run 37887824632 is the first on Pi 1.1.0, so the installed E2E of every target is now recorded on it (Pi compatibility, upgrade to Pi 1.1.0). Pi 1.1.0's interactive mode sends status reports to the terminal (session name and the first line of an error message, never prompts or model output); PiShip leaves Pi's default, and PI_PROGRAM_STATUS=0 in the shell turns it off.
• Open issues at v0.13.0: #64 and #139, both upstream Pi, as at v0.12.0. #238, open at v0.12.0, is closed. Every other issue cited on this page is closed.
• Open gaps: the same as at v0.12.0 (the macOS packages/sandbox/src/boundary.test.ts heartbeat test has flaked with no root cause found; the footprint budgets of linux-x64 and win32-x64 are unrecorded; project-trust and permission rule cases run on Linux and macOS only; vendored Pi packages are not checked for registry signatures, follow-ups; no test updates and rolls back a deduped devcode payload; and repair --from-source does not exist), plus: the macOS seatbelt reference conformance tests are timing sensitive and failed twice on loaded pull-request runs during this cycle. Not verified: a real pi-code isolated or background agent run (the temp-directory modes and worktree layout were read from pi-code 1.4.2's source, not run), and the package-configuration lock under real Windows contention (a scanner holding a file).
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later, the release targets the Release candidate builds and the targets in compatibility; npm 11 or later on the machine that runs piship lock for a distribution that declares Pi packages. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.13.0 archives

The nine archives on the v0.13.0 pre-release, from Release qualification run 37887824632. The .sha256 file beside each archive carries the same digest. Check an archive's attestation with:

gh attestation verify <archive> --repo tc3oliver/piship --signer-workflow tc3oliver/piship/.github/workflows/release-candidate.yml --source-ref refs/heads/main

Archive	SHA-256
acmecode-1.0.0-linux-x64.tar.gz	f8a02103bc450e1adc41cf94f22a51c50e7071355502c4837ed1b6b643127f02
acmecode-1.0.0-darwin-arm64.tar.gz	5c8a3f9b9d4d6f9e83c32e4c5f4f2a24aca63643839a43375291899df4528c02
acmecode-1.0.0-win32-x64.tar.gz	b9c536224460ccdf0a31b4d94d38201a80b466a23e9253712d1c14c6ecc6e937
mypi-1.0.0-linux-x64.tar.gz	7d5e32f0a349657bc9b190467860a2b3bc0888b47837659ac219f8325eee2652
mypi-1.0.0-darwin-arm64.tar.gz	62a5f449695a1ff0b568075224e4e057d368adff11af205bdf489d1cfa1eebe7
mypi-1.0.0-win32-x64.tar.gz	55981ed59ffbd6f3244f50dbff499db93ed4c42007bcadbdb52796398ea37823
devcode-1.0.0-linux-x64.tar.gz	62739be5d9222326e069fd8845b8e685c848230203306678571dc6c20fe66c50
devcode-1.0.0-darwin-arm64.tar.gz	39d2c45aed7d9da608aadc6f91ce608e901808f50eed790c714e325247686ff5
devcode-1.0.0-win32-x64.tar.gz	cf033451abb96356d995e5e65039a555293f4ddd3d57985e0c0c7c821afdebbf

v0.12.0 previous production-validation baseline

v0.12.0 was the one PiShip baseline a production consumer pinned for production validation until v0.13.0 replaced it. It stays published and qualified, and is documented here as the previous baseline. A production consumer pinned tag v0.12.0 and installed its qualified release artifact directly; it did not track main. It is a minor milestone on Pi 1.0.3 and the stable contracts piship/v1 and piship-lock/v1, with piship/v1alpha6 and piship-lock/v1alpha6 accepted for the migration window. The changelog lists every change since v0.11.0.

• Qualification: tag v0.12.0 is commit 8d40a68f825b9f527fcf8c52a7869f571f1ae50b (the squash of #246; the version change is #245, commit 0404e4842eff2c4477670ac0d8db9212850a6db4). Release qualification run 37678031776 passed on that exact commit on its first attempt: 54 jobs passed and 2 were skipped (the issue-report jobs, which run only on schedule). They are CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode with reproducibility 9 of 9 payload-equal, verify-release, tamper rejection, offline install checks, attestations verified, registry signatures passed on 9 of 9, and vulnerabilities passed on 9 of 9). The devcode archives of the two builds differ in bytes only because vulnerabilities.json records the scan time. An earlier run, 37669522371 on the version commit 0404e484, failed one Windows end-to-end job (a test downloaded fd and rg from GitHub and timed out) and was cancelled; #246 fixed the cause before run 37678031776. The pre-release, published 2026-10-07, carries the nine attested archives with their SHA-256 files; the digests are below (recorded evidence).
• Changes since v0.11.0, in short (the changelog has the full list): fixes for the crashes, dead ends, and repeated prompts a user meets from install to daily use; plain HTTP to private hosts by default; remembered project-trust answers (config trust list and config trust forget); <command> uninstall; an optional runtime.pi; the mypi example's relaxed project-trust defaults (piship diff reports risk high); and express-rate-limit 8.7.1 in devcode.
• PiShip version: 0.12.0 (every @piship/* package and PISHIP_VERSION in compatibility.ts); every example is relocked with it.
• Schemas: manifest piship/v1 and lock piship-lock/v1, unchanged; piship/v1alpha6 and piship-lock/v1alpha6 stay accepted for the migration window (version map). runtime.pi may be left out of a manifest. A release that leaves it out cannot be updated to from a runtime built before v0.12.0, so an installed distribution needs one bridge release that still states runtime.pi first (changelog).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.3, unchanged from v0.11.0 (Pi compatibility, upgrade to Pi 1.0.3). v0.13.0 moved to Pi 1.1.0 (upgrade to Pi 1.1.0).
• Open issues at v0.12.0, #64 and #139 still open at v0.13.0: both upstream Pi, as at v0.11.0. #238 was also open: the nightly Portable E2E failure on f1b3d7f; its cause is not analyzed here, and Portable E2E passed on the release commit inside the qualification run. It is closed since. Every other issue cited on this page was closed.
• Open gaps: the same as at v0.11.0 (the macOS packages/sandbox/src/boundary.test.ts heartbeat test has flaked with no root cause found; the footprint budgets of linux-x64 and win32-x64 are unrecorded; project-trust and permission rule cases run on Linux and macOS only; and vendored Pi packages are not checked for registry signatures, follow-ups), plus: no test updates and rolls back a deduped devcode payload, and repair --from-source does not exist.
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later, the release targets the Release candidate builds and the targets in compatibility; npm 11 or later on the machine that runs piship lock for a distribution that declares Pi packages. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.12.0 archives

The nine archives on the v0.12.0 pre-release, from Release qualification run 37678031776. The .sha256 file beside each archive carries the same digest. Check an archive's attestation with:

gh attestation verify <archive> --repo tc3oliver/piship --signer-workflow tc3oliver/piship/.github/workflows/release-candidate.yml --source-ref refs/heads/main

Archive	SHA-256
acmecode-1.0.0-linux-x64.tar.gz	144d0834b95aa8c70733b5cd288ad714d81ea7aabb63dc561c33018ec8d69f28
acmecode-1.0.0-darwin-arm64.tar.gz	d772946d5052e0b0fb66c3c7f4e7fbd7f3fe80a19c3476853f0ba4a91a974aae
acmecode-1.0.0-win32-x64.tar.gz	31123842c18173eebe8ae83c631cc57550815823a11ce4e2984a33751f7843dd
mypi-1.0.0-linux-x64.tar.gz	e96aebabb84346d536f6441826c81e07256bdb058e714aa6945485ca2fdaffb1
mypi-1.0.0-darwin-arm64.tar.gz	5b1f3144fa4b4975811970ff5f0dc356fa049b98dbcc863025d8b8286673c034
mypi-1.0.0-win32-x64.tar.gz	aad44bbf5e068731e4bf3a853992a3d5eef891d9667b77f8a6dfd70f7e9f6f75
devcode-1.0.0-linux-x64.tar.gz	1ebb0594428549ff0bafbaab7af7fa732cc0453b268f327da1fd38405c9d986c
devcode-1.0.0-darwin-arm64.tar.gz	82c938e0d6c72f534d30fee726561410332d430106c0ba6cd181b65f7c1cf541
devcode-1.0.0-win32-x64.tar.gz	21014c3e451e462fd7bfbde4707ed7be8a38197dae527c01262791e024f1ae16

v0.11.0 previous production-validation baseline

v0.11.0 was the one PiShip baseline a production consumer pinned for production validation until v0.12.0 replaced it. It stays published and qualified, and is documented here as an earlier baseline. A production consumer pinned tag v0.11.0 and installed its qualified release artifact directly; it did not track main. It is the stable-contract milestone on Pi 1.0.3: piship/v1 and piship-lock/v1, with piship/v1alpha6 and piship-lock/v1alpha6 accepted for the migration window. v0.10.0 was never published: it has no tag, release, or archives, and its changes (devcode, session --yolo, package environment and agent-file declarations, package capability providers, and managed Claude project trust controls) shipped inside v0.11.0. The changelog lists every change since v0.9.1.

• Qualification: tag v0.11.0 is commit d4f740f0ce7c1b7bebc244e0d4cfa471ede81813 (the squash of #237). Release qualification run 37538011406 passed on that exact commit, all 56 jobs on their first attempt: CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode with reproducibility 9 of 9 equal, verify-release, tamper rejection, offline install with the shipped script on fresh runners, attestations, registry signatures passed on 9 of 9, and vulnerabilities passed). The pre-release, published 2026-10-07, carries that run's nine attested archives with their SHA-256 files; the digests are below (recorded evidence).
• Changes since v0.9.1, in short (the changelog has the full list): the stable piship/v1 and piship-lock/v1 contracts and piship migrate; Pi 1.0.3; the developer distribution and --yolo; project trust for Claude Code configuration; package environment and agentFiles and package capability providers; the bundled, stripped payload with the authoring snapshot and shared Pi package dependencies; the shared file store, on by default (hardlink) on Windows; and the footprint budgets.
• Qualification and security review: a qualification matrix traces every step of the managed, personal, and developer clean-machine qualifications and every supply-chain item to the test that proves it and the workflow that runs it, and lists the gaps with their reasons. Its clean machine is an empty set of temporary homes on a runner, not a fresh operating system image; its model requests go to a fixture gateway, a stand-in server, or a mock upstream, not to a real provider; the interactive terminal is not driven. The security review found and fixed three defects: the registry signature check audited no package in the release candidates examined, those of v0.9.1 and local builds (F1); the SBOM carried no source or integrity for a vendored Pi package's dependencies (F2); and two installs opening a new shared file store at once could leave one of them without it (F3). Run 37538011406 is the first CI evidence of a verified registry signature: it audited the runtime closure and passed on all nine distribution and target combinations. Release candidate checks the evidence every release records about itself (scripts/check-release-evidence.mjs) and fails a release whose signature check audited nothing.
• PiShip version: 0.11.0 (every @piship/* package and PISHIP_VERSION in compatibility.ts); every example is relocked with it.
• Schemas: manifest piship/v1 and lock piship-lock/v1, the same fields, defaults, and validation as piship/v1alpha6 and piship-lock/v1alpha6, which stay accepted. A runtime built before piship/v1 rejects a piship/v1 release with INTEGRITY_FAILED when it updates, so an installed distribution needs one bridge release built with PiShip 0.11.0 and still on piship/v1alpha6 first (support policy, version map).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.3, exact-pinned in packages/pi/package.json, with its seven sibling packages pinned exactly. compatibility/pi.json and the copy in @piship/core list 1.0.3 beside 1.0.2, 1.0.0, and 0.87.1 with the same four surface statuses (personal supported; managed, governance, and lifecycle candidate), carried over from 1.0.2 and not earned again. Release qualification run 37538011406 is the first on Pi 1.0.3, so the installed E2E of every target is now recorded on it (Pi compatibility, upgrade to Pi 1.0.3).
• Open issues at v0.11.0, all three still open at v0.12.0: #64 and #139, both upstream Pi, as at v0.9.1. #238 was also open: the automatic tracking issue for a scheduled Portable E2E failure on f1b3d7f, the commit before the release commit; its cause is not analyzed here, and Portable E2E passed on the release commit inside the qualification run. Every other issue cited on this page was closed.
• Open gaps: the macOS packages/sandbox/src/boundary.test.ts heartbeat test has flaked with no root cause found; there is no automated update or rollback of a developer (devcode) release; the footprint budgets of linux-x64 and win32-x64 are unrecorded (scripts/performance-budgets.json holds darwin-arm64 only, and the Windows file-count figures are reported, not budgeted); project-trust and permission rule cases run on Linux and macOS only; and vendored Pi packages are not checked for registry signatures (follow-ups).
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility; npm 11 or later on the machine that runs piship lock for a distribution that declares Pi packages. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.11.0 archives

The nine archives on the v0.11.0 pre-release, from Release qualification run 37538011406. The .sha256 file beside each archive carries the same digest. Check an archive's attestation with:

gh attestation verify <archive> --repo tc3oliver/piship --signer-workflow tc3oliver/piship/.github/workflows/release-candidate.yml --source-ref refs/heads/main

Archive	SHA-256
acmecode-1.0.0-linux-x64.tar.gz	07da9407a7c8377cf5bc7a20d94dedd63035ed88883639ae0ac791b05c35bfc1
acmecode-1.0.0-darwin-arm64.tar.gz	1f50ee1b0e61f5d8ddef351f1091313f76ca52704256194fdbe2f341ceb275fe
acmecode-1.0.0-win32-x64.tar.gz	9562ce966868ba34be8642bf51d9f7ebe873a741d6f5aee7ab0a0e6eed022207
mypi-1.0.0-linux-x64.tar.gz	18d32a15bd661a59cd3d6d2cdd85462450ad42ac79a5006a5705bfd00a95598c
mypi-1.0.0-darwin-arm64.tar.gz	257758f326e64e0bb287363202657089716604dba7a25701b2148fb96181dd6d
mypi-1.0.0-win32-x64.tar.gz	4744cae3527f270ebd969f11511a3394d021f86828561ebc0041a48dc4c56d12
devcode-1.0.0-linux-x64.tar.gz	187170f2aaf357b707593a043169bd0c8b9db2827bc7a8296ea64c49ee720af9
devcode-1.0.0-darwin-arm64.tar.gz	71a230fa3f67fbddd635b8e6e221b07b52f8d1f8d653c602d8ae6707eeddf706
devcode-1.0.0-win32-x64.tar.gz	442200b99eb75915a3443334a6ca10e352ff12a815c57217f4593fa19aba29a2

v0.9.1 previous production-validation baseline

v0.9.1 was the one PiShip baseline a production consumer pinned for production validation until v0.11.0 replaced it. It stays published and qualified, and is documented here as an earlier baseline. A production consumer pinned tag v0.9.1 and installed its qualified release artifact directly; it did not track main. It is a patch milestone that collects the changes made on main after v0.9.0, on the same schemas and the same Pi; the changelog lists them.

• Qualification: tag v0.9.1 is commit a97ba4302f56e3a59464434084f38b2af9556123 (the squash of #215). Release qualification run 37297400038 passed on that exact commit, every job on its first attempt: CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners). The pre-release carries that run's six attested archives (acmecode and mypi for each target), with their SHA-256 files; the digests are below (recorded evidence).
• Changes since v0.9.0:
  • MCP plain HTTP and identity headers (#212): a streamable-http server may opt in to plain HTTP to a private or internal host with httpTransport: http-allowed, and may receive a claim of the signed-in OIDC identity as a request header with headers (manifest).
  • Plain HTTP to internal endpoints (#213): the gateway, the credential broker, the OIDC issuer, audit sinks, and the sandbox may each opt in to plain HTTP to a private or internal host with httpTransport: http-allowed; every other host keeps the loopback-only rule, and an opt-in request an inherited public HTTP_PROXY would carry is refused (manifest, security).
  • Bundled search tools (#214): runtime.searchTools: { mode: bundled } pins fd and rg per release target in the lock and ships them in the payload, so Pi's find and grep tools and @ completion work on a managed machine without the network (manifest). The branded command now sets Pi's agent directory before Pi loads, so Pi no longer uses ~/.pi/agent/bin.
  • Docs (#211): the agent setup guide asks its questions in batches, with a question tool when the agent has one.
  • Dependencies (#206): undici 8.11.2 and @biomejs/biome 2.5.15.
• PiShip version: 0.9.1 (every @piship/* package and PISHIP_VERSION in compatibility.ts); every example is relocked with it.
• Schemas: unchanged from v0.9.0 (manifest piship/v1alpha6, lock piship-lock/v1alpha6). The new fields (httpTransport, MCP headers, runtime.searchTools) are additive and optional, and no schema id changes (version map).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.2, unchanged.
• Open issues at v0.9.1. These two were the complete list of open issues, the same as at v0.9.0: #64 and #139, both upstream Pi. Every other issue cited on this page was closed.
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility; npm 11 or later on the machine that runs piship lock for a distribution that declares Pi packages. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.9.1 archives

The six archives on the v0.9.1 pre-release, from Release qualification run 37297400038. The .sha256 file beside each archive carries the same digest, and gh attestation verify checks the archive's attestation.

Archive	SHA-256
acmecode-1.0.0-linux-x64.tar.gz	5713cb00846671bf920ef1c48c5a0b0f91a3ed7cdad3bbf6b1b40d0b522cd3d4
acmecode-1.0.0-darwin-arm64.tar.gz	04e16dc594972ba15587e662e0cfe3aa4d5b3fdd4f1438f406ad70edb52ad113
acmecode-1.0.0-win32-x64.tar.gz	403ad1032312a4ac285bf185a2157f1e0347ccd597b66f24670d40a2cd5651e1
mypi-1.0.0-linux-x64.tar.gz	13006b8c54e6aacb122ac7f5822d48feed87b775940ac39abf16e57c704880e6
mypi-1.0.0-darwin-arm64.tar.gz	eb6a01dccea679da790021a8327dd6f6db4732b1999c5aadec6b9903d2c4faf0
mypi-1.0.0-win32-x64.tar.gz	05a7c1c3d40540e146bbb060fb2b9ba8d56012e0b6d363a7402501736b1365cb

v0.9.0 previous production-validation baseline

v0.9.0 was the one PiShip baseline a production consumer pinned for production validation until v0.9.1 replaced it. It stays published and qualified, and is documented here as an earlier baseline. A production consumer pinned tag v0.9.0 and installed its qualified release artifact directly; it did not track main. It adopts Pi 1.0.2 and brings Pi 1.x-native governance and the last alpha schemas, piship/v1alpha6 and piship-lock/v1alpha6; v0.11 freezes these contracts as piship/v1 and piship-lock/v1. The changelog lists every change.

• Qualification: tag v0.9.0 is commit ff3c382c5462373c18e94667f873bb578fb28a20 (the squash of #209). Release qualification run 37247881318 passed on that exact commit: CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners). On its first attempt one Windows unit test with a one-second timing window failed; the failed job was rerun on the same commit and passed (recorded evidence). The pre-release carries that run's six attested archives (acmecode and mypi for each target), with their SHA-256 files.
• Changes since v0.8.1:
  • Schemas: manifest piship/v1alpha6, lock piship-lock/v1alpha6; update root, channel, and signature schemas unchanged. v1alpha5 manifests that name runtime.pi: "1.0.2" and older locks keep loading; a manifest still pinning Pi 1.0.0 is refused until its pin is updated. piship migrate takes v1alpha5 to v1alpha6 without broadening, and --check exits non-zero on an effective change (migration). Every example uses piship/v1alpha6.
  • Pi 1.0.2 (#205), with its sibling packages pinned exactly; #129 is closed by the upgrade (upgrade to Pi 1.0.2).
  • Model governance: model.select for the selected model and model.dispatch for the physical model a request reaches, on every request path, with virtual model routes and classifier and image models.
  • Enforcement status: every action is reported enforced, audit-only, or unsupported from the runtime seam table; a managed deny or ask on an unsupported action fails with POLICY_UNENFORCEABLE unless acknowledged (enforcement status).
  • Tool exposure, excludeTools, Codemode, and tool search, with the bypass regression rows in the compatibility suite.
  • The data lifecycle (retention sweep after a session ends and at logout, logout purge, data.swept) and session.export status, always reported in the lock and doctor; support counts as enforced only where Pi runs offline (managed mode).
  • Pi packages: locked to immutable identities, vendored into the payload by piship build with --ignore-scripts, gated by release.sources, the install-script review, and npm audit, and checked file by file at launch; Pi's installer never runs (manifest). A Portable E2E test locks, builds, installs, and launches a distribution with a local and a git package.
  • Runtime mutation governance (the enforced prompt sections and tools re-asserted on every request, runtime.mutation.reverted, a failed repair blocks the session) and cache warming (off unless declared, cache_warming_decision answered stop, /settings refused unless userOverride).
  • doctor (a Governance group) and piship diff report the v1alpha6 governance state; install-path tests launch v0.8.1-shaped state with a v1alpha5 manifest without rewriting a state file.
  • Examples: every example is on piship/v1alpha6 and relocked; examples/enterprise-reference and its sandbox variant declare the packages/pi-platform local Pi package.
  • Docs (#208): the guides follow v0.9.0, and the agent setup guide walks an existing distribution through the upgrade.
• PiShip version: 0.9.0 (every @piship/* package and PISHIP_VERSION in compatibility.ts).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.2, exact-pinned in packages/pi/package.json, with its seven sibling packages pinned exactly. compatibility/pi.json lists 1.0.2 (and 1.0.0 and 0.87.1, kept so that releases built on them are recognized) with the personal surface supported and the managed, governance, and lifecycle surfaces candidate (Pi compatibility).
• Vulnerability exceptions: none. Pi 1.0.2 ships the fixed brace-expansion, and the example manifests carry no allow entries.
• Open issues at v0.9.0. These two were the complete list of open issues, and were still open at v0.9.1, v0.11.0, v0.12.0, and v0.13.0; every other issue cited on this page was closed. #129 is closed by v0.9.0.
  • #64, upstream Pi: a user's ! shell command still writes its full output through Pi's temp file, so a temp filesystem that fills while Pi writes it (ENOSPC) is not contained.
  • #139, upstream Pi: an identity or credential failure inside the TUI shows PiShip's action, but Pi still adds its own /bug hint.
• Upstream: the Pi gaps v0.9 works around are raised upstream: a model ID on before_provider_request, a tool-set change event, tool-search discover and activate events, a way to disable or intercept /share and /export, a capability discovery API, and package installation without lifecycle scripts.
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility; npm 11 or later on the machine that runs piship lock for a distribution that declares Pi packages. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.8.1 previous production-validation baseline

v0.8.1 was the one PiShip baseline a production consumer pinned for production validation until v0.9.0 replaced it. It stays published and qualified, and is documented here as a previous baseline. A production consumer pinned tag v0.8.1 and installed its qualified release artifact directly; it did not track main. It collects the changes made on main after v0.8.0, on the same schemas and the same Pi; the changelog lists them.

• Qualification: tag v0.8.1 is commit d0691041d4235d208a269b30f79d1ecb8ec352fe (the squash of #203). Release qualification run 37127974973 passed on that exact commit: CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners). The pre-release carries that run's six attested archives (acmecode and mypi for each target), with their SHA-256 files (recorded evidence).
• Changes since v0.8.0:
  • Secret store unavailable (#196, #198): a sign-in through a system secret store that cannot be reached leaves no reference behind, and a discarded marker lists the references never confirmed written (unconfirmed), so only those are dropped when the store command is not installed. purge and uninstall --purge apply the same rule, and login, logout, and sandbox login say which references they dropped.
  • User auto mode (#197, #200): policy.userAuto: allowed lets a managed distribution's user switch on an audited auto mode that approves an ask from the distribution's defaults without a prompt; deny and every other ask are untouched (manifest).
  • Plain-HTTP update channel (#199, #201): updates.transport: http-allowed lets the update channel use plain HTTP to a private or internal host; it requires a bootstrap trust root, and signature, digest, sequence, expiry, and root-refresh checks are unchanged (manifest).
  • Review fixes (#202): an explicit shell ask from enforced, team, project, or a managed user's own rules also applies to a chained command, so auto mode cannot approve git push origin main; true past it; discarded-marker tracking and purge as above; a single-label host that is a public top-level domain counts as public for a plain-HTTP update channel; and the auto mode audit: switching off applies first and is audited best effort, so an audit sink that is down cannot keep auto mode on, /auto on refuses when a required sink has not taken its event, and policy explain reports AUTO-APPROVED only for actions a session decides itself.
  • Docs (#195): the agent setup guide says to sign in with the built command, in the directory where piship test ran, before it is run again.
• PiShip version: 0.8.1 (every @piship/* package and PISHIP_VERSION in compatibility.ts).
• Schemas: unchanged from v0.8.0 (manifest piship/v1alpha5, lock piship-lock/v1alpha5, update root piship-update-root/v1). policy.userAuto and updates.transport are optional, and a manifest without them locks byte-identically. The policy.auto_* audit events are new names in piship-audit/v1 (version map).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.0, unchanged. Pi 1.0.1 was published on 2026-10-03, after the 1.0.0 review below; it is not reviewed or adopted here, so the brace-expansion exception (#129) is unchanged and expires on 2026-12-31 as before.
• Open issues at v0.8.1. These three were the complete list of open issues, the same as at v0.8.0; every other issue cited on this page was closed. #129 is closed by v0.9.0. #196, #197, and #199 are closed by v0.8.1.
  • #64, upstream Pi: a user's ! shell command still writes its full output through Pi's temp file, so a temp filesystem that fills while Pi writes it (ENOSPC) is not contained.
  • #139, upstream Pi: an identity or credential failure inside the TUI shows PiShip's action, but Pi still adds its own /bug hint.
  • #129: the reviewed brace-expansion exception above, until upstream Pi shipped a fixed version or the exception expired on 2026-12-31 (GHSA-qhr7-859c-m2p7 and GHSA-6j4f-fj2g-mc7p; GHSA-q2hr-2g5m-vwhr is moderate and reported below failOn: high). Details in known limits.
• After v0.8.1: Pi 1.0.2 was pinned, with its sibling packages pinned exactly, and #129 was closed by the upgrade: Pi 1.0.2 ships the fixed brace-expansion, and the example manifests carry no exception (upgrade to Pi 1.0.2). That upgrade shipped in v0.9.0.
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.8.0 previous production-validation baseline

v0.8.0 was the one PiShip baseline a production consumer pinned for production validation until v0.8.1 replaced it. It stays published and qualified, and is documented here as a previous baseline. A production consumer pinned tag v0.8.0 and installed its qualified release artifact directly; it did not track main. v0.8.0, pre-production trust and validation hardening, freezes the contracts that are expensive to change once real installations exist: manifest piship/v1alpha5 with a bootstrap trust root, an installation trust state with root refresh, multiple signatures with root rotation and emergency channel-key revocation, encrypted PEM signing keys, explicit piship init --personal and --managed, and the production validation protocol. The scope is in the roadmap.

• Qualification: tag v0.8.0 is commit 8550282784fc7d85142907fa4632b847d4c96b26 (the squash of #193). Release qualification run 37108519783 passed on that exact commit: CI on Ubuntu, macOS, and Windows, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners). The pre-release carries that run's six attested archives (acmecode and mypi for each target), with their SHA-256 files. The commit includes three fixes made after the release pull request (#190): #191 and #192 make the E2E flows follow the v0.8 keygen output and the root probe, and #193 builds a release with an update source and no bootstrap trust as update-disabled instead of refusing it (recorded evidence).
• PiShip version: 0.8.0 (every @piship/* package and PISHIP_VERSION in compatibility.ts).
• Schemas: manifest piship/v1alpha5, lock piship-lock/v1alpha5, update root piship-update-root/v1. Channel metadata stays piship-channel/v1, and piship-signature/v1 gains an optional signatures[] (version map).
• Pinned Pi: @earendil-works/pi-coding-agent 1.0.0, exact-pinned in packages/pi/package.json, reviewed on 2026-10-03 and deliberately kept. 1.0.0 was then the newest published Pi, and its npm-shrinkwrap.json still pins brace-expansion 5.0.9, so the reviewed exception (#129) is not cleared and is not extended: it expires on 2026-12-31 as before. compatibility/pi.json lists 1.0.0 (and 0.87.1, kept so that releases built on it are recognized) with the personal surface supported and the managed, governance, and lifecycle surfaces candidate (Pi compatibility).
• Open issues at v0.8.0. These three were the complete list of open issues; every other issue cited on this page is closed. #181 (signed channel hardening) is closed by v0.8.0, and #187 (the Pi latest canary) is closed: the canary is green since the upgrade to Pi 1.0.0 (#188).
  • #64, upstream Pi: a user's ! shell command still writes its full output through Pi's temp file, so a temp filesystem that fills while Pi writes it (ENOSPC) is not contained.
  • #139, upstream Pi: an identity or credential failure inside the TUI shows PiShip's action, but Pi still adds its own /bug hint.
  • #129: the reviewed brace-expansion exception above, until upstream Pi ships a fixed version or the exception expires on 2026-12-31 (GHSA-qhr7-859c-m2p7 and GHSA-6j4f-fj2g-mc7p; GHSA-q2hr-2g5m-vwhr is moderate and reported below failOn: high). Details in known limits.
• Update channel: the project operates no signed update channel, and the example distributions pin no bootstrap trust root, so the published archives are update-disabled and cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly, and compares its SHA-256 and pinned update keys with the values the distribution owner published (distribution bootstrap).
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

v0.7.1 previous production-validation baseline

v0.7.1 was the one PiShip baseline a production consumer pinned for production validation (#173) until v0.8.0 replaced it. It stays published and qualified, and is documented here as a previous baseline. A production consumer pinned tag v0.7.1 and installed its qualified release artifact directly; it did not track main.

• Qualification: tag v0.7.1 is commit bd4bc09eac22aefdb2b5c576884934e8d6200318 (the squash of #174). Release qualification run 36857734987 passed on that exact commit: CI, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, verify-release, tamper rejection, and install on fresh runners). The pre-release carries that run's six attested archives unchanged, with their SHA-256 files.
• PiShip version: 0.7.1 (every @piship/* package and PISHIP_VERSION in compatibility.ts).
• Pinned Pi: @earendil-works/pi-coding-agent 0.87.1, exact-pinned in packages/pi/package.json at that commit. compatibility/pi.json at that commit lists it as supported, with the personal surface supported and the managed, governance, and lifecycle surfaces candidate. v0.8.0 pins Pi 1.0.0 (after v0.7.1, Pi compatibility).
• Manifest schema: piship/v1alpha4. Lock schema: piship-lock/v1alpha4. Both unchanged since v0.4 (version map).
• Known vulnerability exceptions: GHSA-qhr7-859c-m2p7 and GHSA-6j4f-fj2g-mc7p (high, brace-expansion 5.0.9 pinned by Pi 0.87.1, and by Pi 1.0.0 in v0.8.0), a reviewed exception that every example manifest allows with a reason until 2026-12-31, after which the release vulnerability gate fails again (#129). GHSA-q2hr-2g5m-vwhr (moderate, same package) is not an exception: it is reported below failOn: high. Details in known limits.
• Open issues at v0.7.1. These five were the complete list of open issues; every other issue cited on this page is closed. #176 is resolved by the upgrade to Pi 1.0.0 in v0.8.0 (after v0.7.1) and #181 is closed by v0.8.0; the other three remain open:
  • #64, upstream Pi: a user's ! shell command still writes its full output through Pi's temp file, so a temp filesystem that fills while Pi writes it (ENOSPC) is not contained.
  • #139, upstream Pi: an identity or credential failure inside the TUI shows PiShip's action, but Pi still adds its own /bug hint.
  • #129: the reviewed brace-expansion exception above, until upstream Pi ships a fixed version or the exception expires on 2026-12-31.
  • #176: the latest Pi adds AssistantMessage.thinkingLevel, which must be classified in the redaction map, with the governance review a Pi upgrade needs, before any Pi upgrade. No effect on the pinned Pi 0.87.1. Resolved in v0.8.0.
  • #181: signed channel hardening (key validity, revocation before activation, multiple signatures, signer hardening), needed before a broad rollout that relies on a signed update channel, not before production validation. Closed by v0.8.0.
• Update channel: the project operates no signed update channel and pins no release key in the examples, so an installation of the published archives cannot update through a channel. Key custody belongs to each distribution owner (trust root). A production consumer pins and installs the exact qualified artifact directly.
• Production evidence: the manual Live provider workflow has passed with a real upstream model provider through the reference stack (after v0.7.1). There is still no validation against a real company identity provider or company gateway in production; the production validation protocol says how it is run and what a report may carry.
• Supported production-validation platforms: linux-x64, darwin-arm64, and win32-x64 with Node.js 22.19.0 or later (qualified on Node 22.19.0), the release targets the Release candidate builds and the targets in compatibility. Native Windows has no sandbox adapter: a distribution that requires the sandbox fails closed there with SANDBOX_UNAVAILABLE (sandbox backends).

On main after v0.7.1

main moved past v0.7.1 before v0.8.0. These changes are not in v0.7.1; they are in v0.8.0 and listed under it in the changelog:

• #178: piship install --sha256 <hex> and --expect-key sha256:<fingerprint> check the published archive digest and the pinned update keys before anything is installed, and piship inspect shows the pinned keys (distribution bootstrap).
• #180: the trust root records the decisions that the project operates no official channel for the examples and that key custody belongs to the distribution owner; the remaining signed-channel gaps move to #181.
• #182: a failed Live provider run reports the gateway's HTTP status and PiShip's error code, and the workflow takes an optional model for a single run.
• Pi 1.0.0: v0.8.0 pins @earendil-works/pi-coding-agent exactly at 1.0.0. compatibility/pi.json and the copy in @piship/core list 1.0.0 and 0.87.1 with the same surface statuses (personal supported; managed, governance, and lifecycle candidate); 0.87.1 stays so that releases built on it are still recognized, and the launcher runs only 1.0.0. v0.7.1 stays on Pi 0.87.1. The v0.8.0 Release qualification is the first one recorded for a commit with Pi 1.0.0: the earlier ones ran on 0.87.1. The upgrade notes are in compatibility.
• #176: AssistantMessage.thinkingLevel, new in Pi 1.0 (optional; the thinking level the agent loop requested), is classified metadata in the redaction map. The governance review of the built-in extensions of Pi 0.99 and 1.0 (builtin:mcp, builtin:codemode, builtin:tool-search, builtin:llama) found that a PiShip session loads none of them: only Pi's CLI adds them, PiShip builds sessions through the SDK with noExtensions: true, and a compatibility test asserts that no builtin:* extension loads. A tool an extension runs through ctx.executeTool still emits tool_call, which the policy hook decides (security).
• The governed bash follows Pi 1.0's result shape: it returns Pi's structuredContent (output up to 1 MiB, and the first and last 512 KiB when longer; truncated; full_output_path when truncated and saved; exit_code; wall_time_seconds), which codemode scripts receive, and a non-zero exit returns an isError: true result instead of throwing. The full output file still lives in PiShip's session-owned output store.
• Every launch sets Pi's defaults (security): no pi.dev version check and no update notice, no Pi telemetry or install report, Pi's agent directory (its crash log and the fd and rg it downloads) in the distribution's state instead of ~/.pi/agent, a quiet startup, and the terminal's own scrollback instead of Pi 1.0's fullscreen. A managed launch also runs Pi offline.

Status terms

Status	Meaning
supported	The surface is marked supported in compatibility/pi.json: installed E2E has passed on every advertised target (Ubuntu x64, macOS arm64, Windows x64 with Node 22.19.0) as defined in compatibility.
candidate	The surface is marked candidate in compatibility/pi.json: public-API, unit, and local-fixture checks pass, while live-service evidence or complete current-head target evidence is still missing.
preview	Implemented and tested, but not a surface of its own in compatibility/pi.json, or only proven with deterministic local fixtures. Expect changes.
unavailable	Nothing exists to run, or nothing was available to run it on. A backend with no adapter on a platform is unavailable there (native Windows: a required sandbox fails closed with SANDBOX_UNAVAILABLE), and a live qualification that had no service, account, or cluster to run against is unavailable. It is a statement about the evidence, never a pass.

Capability matrix

The evidence column names the CI tier that produces the evidence, the example it exercises, and the platforms it runs on. The most recent Release qualification is v0.13.0's (v0.13.0); the per-job counts below were recorded for the v0.7 candidate.

Area	Mode	Status	Evidence
Distribution core: portable payload, install, uninstall, isolated state, inspect, doctor, --smoke, session resume	Personal	supported (Pi surface personal)	Fast gate: build, unit, and Pi compatibility on Ubuntu, macOS, and Windows. Portable E2E: personal-lifecycle and cli on all three targets with examples/personal; personal-clean-machine-mypi also takes MyPi from install to uninstall, with a model request, session resume, update, and rollback.
Distribution core	Managed	candidate (Pi surface managed)	Fast gate as above. Portable E2E: managed with examples/demo-company against local fixtures, on all three targets; it also checks that one launch writes the metadata-only local metrics (logs/metrics.json).
Managed access: OIDC + PKCE login, http-broker credentials, platform secret store, OpenAI-compatible gateway, model governance, layered configuration	Managed	candidate (Pi surface managed)	Fast gate: the live platform secret-store test on all three targets (macOS Keychain, Windows Credential Manager, Linux Secret Service under GNOME Keyring). Portable E2E: managed, managed-clean-machine (one continuous flow: install, launch, login, credential acquire, model discovery, an authenticated model request, session resume, doctor, sandboxed commands, update, rollback, logout, uninstall and purge), user switching (file and system store), the secret-store lifecycle (file and system store), headless, enterprise networking through the real launcher (network), and the security suite (security-controls, security-sweep, security-lifecycle, security-findings-session, security-sandbox, lifecycle-credentials), all on all three targets (on Windows, lifecycle-credentials and security-sweep skip some steps; see known limits) against deterministic loopback fixtures (OIDC provider, broker, gateway). The secrets of managed-clean-machine and of the system variants are in the live platform store, while managed, headless, and the file variants use the file store. The clean-machine flow's model request is authenticated by the fixture gateway, which is not a model. Reference E2E, Ubuntu only: the AcmeCode reference distribution signs in on a real Keycloak, exchanges the identity at the reference broker, keeps the credential in the Linux Secret Service, and sends model requests through a real LiteLLM gateway to a deterministic mock upstream, as one flow from install to uninstall (including commands in the required sandbox, update, rollback, and logout) and across a user switch. No production identity provider or gateway, and no model provider behind the gateway.
Access modes local-secret, none, and a local OpenAI-compatible model	Personal	preview	Portable E2E on all three targets: personal-access-modes, personal-local-model with examples/personal/local-model, and the personal clean-machine flows (personal-clean-machine-mypi, personal-clean-machine-local), which take MyPi (key delegated to Pi) and MyPi Local (key in its own secret store) from install to uninstall, send a model request with that key to a stand-in model server on loopback, and update and roll back through a signed loopback channel. No request to a real model provider is claimed.
Governance: policy, resource/provider/project trust, capabilities and Plan/Build, governed MCP, OS sandbox, audit	Managed and personal	candidate (Pi surface governance)	Fast gate: the live sandbox probe and boundary tests run in the unit suite with a required sandbox on Ubuntu (bubblewrap) and macOS (Seatbelt); a missing sandbox fails the job instead of skipping the tests. Portable E2E: governance on all three targets; on Windows only with the sandbox optional, because Windows has no sandbox adapter and a required sandbox fails closed. managed-clean-machine also runs the commands the fixture gateway asks for through the required native sandbox on Linux and macOS and checks that each escape is refused; on Windows it runs none. Reference E2E: the same commands in the required sandbox on Ubuntu. Per backend in sandbox backends.
Sandbox backends: custom adapters, e2b-compatible (E2B, CubeSandbox), kubernetes-agent-sandbox (sandbox backends)	Managed and personal	preview	Per backend in sandbox backends below.
Lifecycle: piship release, verify-release, signed channels, update, rollback, migration check	Managed	candidate (Pi surface lifecycle)	Portable E2E: lifecycle-install, lifecycle-integrity, lifecycle-update, and lifecycle-rollback with the demo on all three targets (Windows with the sandbox optional). Release candidate: two builds per target, reproducibility, verify-release on a fresh runner, tamper rejection, attestation, and install with the shipped script; recorded on v0.13.0 7f9e167 (run), and earlier on v0.12.0 8d40a68 (run), on v0.11.0 d4f740f (run), on v0.9.1 a97ba43 (run), on v0.9.0 ff3c382 (run), on v0.8.1 d069104 (run), on v0.8.0 8550282 (run), on v0.7.1 bd4bc09 (run), on 21de31a, on the freeze SHA ab3e7f2 (run), on the v0.7 candidate ee8b4a9 (run), and on v0.7.0 4994eee (run).
Lifecycle	Personal	candidate (Pi surface lifecycle)	Portable E2E: personal-lifecycle covers signed update and rollback of the personal example. Release candidate: the same two builds, reproducibility, verification, attestation, and install as the demo, plus the installed release's offline --smoke and doctor; recorded on v0.13.0 7f9e167 (run), and earlier on v0.12.0 8d40a68 (run), on v0.11.0 d4f740f (run), on v0.9.1 a97ba43 (run), on v0.9.0 ff3c382 (run), on v0.8.1 d069104 (run), on v0.8.0 8550282 (run), on v0.7.1 bd4bc09 (run), on 21de31a, on the freeze SHA ab3e7f2 (run), on the v0.7 candidate ee8b4a9 (run), and on v0.7.0 4994eee (run).
Release supply-chain evidence: reproducibility, SBOM, notices, vulnerability and registry-signature checks, provenance, attestation	Managed and personal	candidate (Pi surface lifecycle)	Release candidate on all three targets for acmecode, mypi, and devcode: two builds compared by piship reproducibility, verify-release and tamper rejection on a fresh runner, attestation verified with gh attestation verify, and the release's recorded evidence checked by scripts/check-release-evidence.mjs (qualified, tests and scan passed, every SBOM package in the notices, one audit record per vendored Pi package, the signature verdict). Before v0.11 the registry signature check verified nothing (security review); run 37538011406 on the fixed code is the first to record a verified signature, passed on all nine distribution and target combinations, and runs 37678031776 (v0.12.0) and 37887824632 (v0.13.0) again passed on all nine. Matrix: v0.11 qualification matrix.
Shared file store (PISHIP_STORE, off by default)	Managed and personal	preview	Fast gate: the store, collection, and boundary tests on three targets. Portable E2E: shared-store (a real release installed, updated, rolled back, and diagnosed with a store, and installed with an unusable one) and the shared file store test of developer-profile (the developer payload placed from an empty store). No release path depends on it.

The endpoints a company must provide for managed access, and how PiShip calls them, are in the enterprise integration contract.

Not claimed anywhere: sign-in at a production identity provider, inference through a production gateway, a model request to a real model provider outside the reference stack (the manual Live provider workflow has sent one through the reference LiteLLM and AcmeCode, see after v0.7.1; that is evidence for the reference stack only), a Windows OS sandbox, a verified shared or synchronized workspace on a Windows host (known limits), a live E2B, CubeSandbox, or Kubernetes sandbox, an InferenceProvider adapter for a gateway that is not OpenAI-compatible (out of scope for v0.7), the managed path of the first production consumer (open, see distribution qualification), macOS notarization or code signing, Windows Authenticode signing, targets other than the three above, or an npm publication.

Sandbox backends

Each sandbox backend has its own maturity; a distribution's containment is only as strong as the backend it selects. What each backend enforces and reports is in sandbox backends. The statuses use the terms above, which are defined by compatibility/pi.json: a native backend is candidate because the governance surface it belongs to is, and no row is promoted beyond what that record says.

Every run named below used Node 22.19.0 and Pi 0.87.1, the pin at the time, except the v0.8.0 and v0.8.1 Release qualifications, which ran on Pi 1.0.0, the v0.9.0 and v0.9.1 Release qualifications, which ran on Pi 1.0.2, the v0.11.0 and v0.12.0 Release qualifications, which ran on Pi 1.0.3, and the v0.13.0 Release qualification, which ran on Pi 1.1.0. The per-test results were recorded for the v0.7 candidate; the Release qualifications of v0.7.0, v0.7.1, v0.8.0, v0.8.1, v0.9.0, v0.9.1, v0.11.0, v0.12.0, and v0.13.0 passed the same jobs on their own commits.

Backend	Status	Environment and versions	Evidence and results
native on Linux (bubblewrap)	candidate (part of the Pi surface governance)	ubuntu-latest: Ubuntu 24.04 image, bubblewrap 0.9.0. The workflows set kernel.apparmor_restrict_unprivileged_userns=0, because Ubuntu restricts, by default, the unprivileged user namespaces bubblewrap needs.	Fast gate, with the sandbox required: the live probe and the boundary and escape tests (boundary.test.ts: 18 of 19 tests run, the 19th is the macOS launchd test), the workspace and backend-contract tests, and the sandbox conformance kit against the native backend all passed. Portable E2E: governance and managed-clean-machine with a required sandbox (four commands run: one writes inside the workspace, and reading the user's SSH key, writing outside the workspace, and connecting to a loopback listener are each refused), and the installed E2E files on both Ubuntu shards. Reference E2E: AcmeCode's commands run in the required sandbox and each escape is refused (distribution-flow). Bubblewrap cannot guard a protected git file that does not exist yet, so git control is reported not-verified in every regular repository; doctor names the files and the sandbox still runs (protected git paths).
native on macOS (Seatbelt)	candidate (part of the Pi surface governance)	macos-latest: macOS 26 arm64 image, Seatbelt through /usr/bin/sandbox-exec.	Fast gate, with the sandbox required: all 19 boundary and escape tests passed, including the launchd test, which first confirms that an unsandboxed launchd job runs and then sees six attempts (launchctl, a copied launchctl, open, a copied open, osascript, and osascript from Node) refused with no escape marker created; the workspace and backend-contract tests and the conformance kit against the native backend passed as on Linux. Portable E2E: governance and managed-clean-machine with a required sandbox (the same four commands), and the installed E2E files on all three macOS shards. Not run on Reference E2E, which is Ubuntu only.
native on Windows	unavailable	windows-latest: the windows-2025-vs2026 image.	There is no Windows sandbox adapter. A distribution that requires the sandbox fails closed with SANDBOX_UNAVAILABLE (Portable E2E governance asserts it on Windows). With the sandbox optional, the Windows E2E runs no command in a sandbox: managed-clean-machine says so in its output and skips the step, and doctor reports containment not-required and isolation none. The native sandbox tests skip on Windows. Governed children there run in a kill-on-close Job Object that ends descendants with their leader; it isolates nothing.
custom	preview	The reference container sandbox and its single-file adapter on ubuntu-latest: Ubuntu 24.04 image, Docker 28.0.4.	Unit tests of the adapter lifecycle and capability checks with fake adapters, and the sandbox conformance kit against reference backends. Reference E2E, Ubuntu only: sandbox passed 16 tests: the service and adapter pass every kit behavior against real containers with none skipped, and a governed session with a stored sandbox credential verifies the shared workspace in both directions. An adapter that declares a network probe has its network denial verified (unit tests with fakes); otherwise it is attested. The reference adapter declares no network probe in v0.7, so its network denial is attested, never verified. PiShip ships no company adapter.
e2b-compatible (E2B, CubeSandbox)	preview (live qualification unavailable)	Fixtures only; no E2B service and no CubeSandbox. See external backends.	remote.test.ts (52 tests, Fast gate on all three targets) runs the backend against a mock E2B control plane and envd that enforces the sandbox user (user, or root as CubeSandbox needs), checks that the API key appears only as X-API-Key on control requests, and checks every request for leaked credentials. The conformance kit against a fake E2B service fails two behaviors where the kit is stricter than PiShip (kit self-tests). The backend declares no network probe, so network denial is attested by the service, never verified.
kubernetes-agent-sandbox	preview (live qualification unavailable)	Fixtures only; no cluster. See external backends.	It does not claim network denial, so a required deny sandbox fails closed. remote.test.ts runs it against a mock API server and router (claim lifecycle, renewal across clock jumps, expired and removed claims). Portable E2E sandbox-credential and security-sandbox on all three targets launch a governed session whose bash runs in that mock with a stored sandbox credential, through a change of user, a rejected credential, and an outage in which the command never runs on the host instead. The conformance kit is not run against it: there is no fake of its runtime API that runs commands.

The backends are recorded here and not in compatibility/pi.json: their maturity does not change which Pi surface a release records.

External backends

Live qualification of E2B, CubeSandbox, and Kubernetes Agent Sandbox needs a service the project does not operate, and never gates a release. It was checked, read-only, on the maintainer's machine that prepared the v0.7 evidence, on 2026-09-30 (UTC):

• command -v kubectl kind minikube k3d orb docker found kubectl (client v1.33.9), orb, and docker; kind, minikube, and k3d are not installed.
• kubectl config get-contexts lists no context, no current context is set, and KUBECONFIG is unset. There is no cluster to reach, so kubectl get crd was not run: there was nothing to run it against. No cluster was started and no context was changed; OrbStack's Kubernetes was neither started nor queried.
• No E2B account or API key and no CubeSandbox deployment was provided for this qualification.

Backend	Live qualification	What it needs
E2B-compatible (E2B)	unavailable	An E2B account and API key, or a self-hosted service that implements the E2B API
CubeSandbox	unavailable	A CubeSandbox deployment and its API URL (commands run as user: root)
Kubernetes Agent Sandbox	unavailable	A cluster with the Agent Sandbox custom resources (SandboxClaim, SandboxWarmPool) and its sandbox router

All three stay preview on the fixture-level evidence in the table above, and none of it is live evidence. E2B and CubeSandbox network denial is backend-attested: neither backend declares a network probe, so the service's word stands and PiShip reports it as attested. Kubernetes Agent Sandbox claims no network denial at all.

Distribution qualification

What each kind of distribution has been shown to do. The test counts are from the v0.7 candidate; the same suites passed in the v0.7.1, v0.8.0, v0.8.1, v0.9.0, v0.9.1, v0.11.0, v0.12.0, and v0.13.0 Release qualifications.

Distribution	Role	Evidence	Status
AcmeCode reference distribution (examples/enterprise-reference)	A neutral managed distribution that depends on no company's infrastructure	Reference E2E, Ubuntu: distribution-flow (14 tests) takes one user from install to uninstall against a live Keycloak 26.7.4, the reference credential broker, and LiteLLM v1.103.0 (PostgreSQL 17.11 and a deterministic mock upstream behind it): install, sign-in, credential, models, a model request and session resume, doctor, commands in the required sandbox, update, rollback, logout, and uninstall and purge. user-switching signs a second user in over the first without a logout: the second gets none of the first's credential, entitlement, or model selection. The demo distribution (examples/demo-company) runs the same flow against local fixtures on all three targets.	Recorded for v0.13.0 7f9e167
DevCode (examples/developer)	A personal distribution with six Pi packages, a certified permission provider seeded from its manifest, and a hardened managed variant	Release candidate: devcode is wired to be built, verified, and installed with acmecode and mypi. The developer-profile E2E and the example's unit checks are in the nightly Portable E2E and the unit tier. Release qualification runs 37887824632 (v0.13.0), 37678031776 (v0.12.0), and 37538011406 (v0.11.0) built, verified, and installed devcode on all three targets, and the developer profile E2E is part of their Portable E2E; the managed variant is validated, never launched, and no developer update or rollback is automated.	preview
MyPi and MyPi Local (examples/personal)	Personal regression: no enterprise identity, a local or direct model	Portable E2E on all three targets: personal-clean-machine-mypi, personal-clean-machine-local, personal-lifecycle, personal-access-modes, and personal-local-model.	Recorded for v0.13.0 7f9e167
The first production consumer	The managed path of a real company distribution	Not available in this repository. It follows the production validation protocol: collected downstream with the owner's approval, reported only as de-identified step results, and summarized here without identifiers.	open

Known limits and non-claims

Limits of v0.13.0 as shipped, with earlier releases named where a bullet says so, each checked against the code or document it cites. None of them is claimed as handled. Only the issues listed under the baseline, #64 and #139, are open; a closed issue cited here records where a limit was decided, not open work.

• Shell output is stopped at 64 MiB, but in v0.7.0 Pi still writes the complete output to its own pi-bash-*.log file in the OS temp directory: PiShip does not remove it after the session, and a full temp filesystem while Pi writes it is not contained. After v0.7.0 the agent's bash tool keeps its full output in a session-owned directory removed at close, and a full temp filesystem there is contained. A user's ! command still goes through Pi's file: PiShip removes the files Pi recorded for the session at close and keeps the command's output within the free temp space, but a temp filesystem that fills anyway while Pi writes it is not contained, and a crash leaves the file. Closing that needs a change in Pi upstream (#64; security).
• --smoke-model classifies a failed request by the gateway's status, an aborted request as REQUEST_CANCELLED, and a managed endpoint's request that got no answer (refused or reset connection, DNS failure, deadline) as GATEWAY_UNREACHABLE. A stream that failed after it started, and a Pi-native provider's request that got no answer, are still GATEWAY_PROTOCOL_ERROR: Pi's message keeps no structured transport error, and PiShip owns the fetch only for a managed endpoint (kept as a known limit when #85 closed; inference).
• On Windows, a governed child that writes the launcher's startup-failure marker to stderr has that output dropped and its exit reported as a startup failure (a low-severity review finding on #104, not tracked by an open issue).
• On Windows, the Job Object helper is compiled from C# for every governed child, which adds startup time to each one (a low-severity review finding on #104, not tracked by an open issue).
• On Windows, the request that carries a child's file, arguments, working directory, and approved environment travels base64-encoded in one environment variable of the launcher, so it is bound by Windows' 32,767-character limit for a variable (a low-severity review finding on #104, not tracked by an open issue).
• The native sandbox probe connects to 1.1.1.1:443 and to a host loopback listener in deny mode as negative probes: each must fail, and the probe never requires an address to be reachable. The positive control is in the boundary tests, where a sandbox with the network allowed does reach the loopback listener (network denial).
• E2B and CubeSandbox network denial is backend-attested, never verified; Kubernetes Agent Sandbox claims none, and a required deny sandbox on it fails closed.
• The reference container sandbox declares no network probe in v0.7, so its network denial is attested.
• Bubblewrap cannot guard a protected git file that does not exist yet, so git control is not-verified under it in every regular repository (sandbox); Seatbelt can guard a missing file.
• The Live provider workflow is manual, uses a paid provider key held in the protected live-provider environment, and is never part of Release qualification. Its passing runs (after v0.7.1) show one model request from AcmeCode through the reference Keycloak, broker, and LiteLLM to a real upstream provider. They are not evidence for a company identity provider or gateway, and no such validation exists yet.
• PiShip refuses state, install, and bin homes that are equal or nested in one another, so an install home that contains the bin home is rejected with CONFIG_INVALID.
• Windows has no evidence for the host-side check of a shared or synchronized workspace. Of the 103 workspace tests (workspace.test.ts and governance-workspace.test.ts), 63 are POSIX-only and skip on Windows: the two-way sentinel, the git control file checks, the sentinel location, the propagation and validity windows, and the governed session's workspace check. 7 more need a native sandbox, which Windows does not have. The 33 that run there cover declaration handling and helper logic. The only run against a real shared workspace is the reference container sandbox, on Ubuntu.
• Two security E2E files cover less on Windows than on Linux and macOS. lifecycle-credentials locks the file store by removing POSIX permissions, which Windows ignores. So on Windows it does not test logout with a locked store, the discarded credential and identity records that logout leaves, or the rollback that clears them: logout runs with the store unlocked. security-sweep runs the demo with the sandbox optional on Windows. It skips the four bash tool steps: reading a stored secret and the credential metadata with cat, listing the state directory, and a long output that Pi saves to a temp file. It also does not check that the run used its temp directory. Both files still pass on Windows and sweep for leaked secrets there.
• A system clock set forward cannot be told from a suspend and counts as elapsed time: the sandbox workspace check and a Kubernetes claim come due or expire early (sandbox).
• Releases up to v0.8.1 ship brace-expansion 5.0.9, which Pi 0.87.1 and 1.0.0 pin in their npm-shrinkwrap.json; it has two high advisories (GHSA-qhr7-859c-m2p7, GHSA-6j4f-fj2g-mc7p: local stack-exhaustion DoS from crafted nested brace patterns) and one moderate (GHSA-q2hr-2g5m-vwhr). Their example manifests allow the two high IDs as a reviewed exception until 2026-12-31. In v0.9.0 and v0.9.1, Pi 1.0.2 pins 5.0.12, which fixes them, so the example manifests carry no allow entries and the release vulnerability gate passes with no findings (#129, upgrade to Pi 1.0.2).
• The branded command has no non-interactive prompt, print, or RPC mode: without a terminal the interactive command fails at once, and headless runs (CI, automation, a workload identity) use --smoke, --smoke-model, and the subcommands (#135).
• Fixed in v0.7.1: a stray file in the installed payload is named and piship repair restores the release (#136); a corrupt versioned state file no longer blocks update and rollback (#143); the lifecycle lock and launch gate record process identity and host (#144); adapter and custom sandbox calls have deadlines (#145); Kubernetes sandbox commands may run past 300 seconds and an unknown outcome is never retried (#146); proxy and CA failures name the proxy or the TLS chain (#148); login explains a busy port, a provider client error, and SSH (#149); validate catches configuration certain to fail at launch (#142). Still open: an identity or credential failure inside the TUI shows PiShip's action, but Pi still adds its own /bug hint, which no public Pi API can turn off (#139).
• The v0.7.x follow-ups tracked under #125 (#157 to #162) are fixed in v0.7.1, and #125 is closed.
• The project operates no signed update channel. Installation trust state, sequential root refresh, root / channel role separation, threshold multi-signatures, and emergency channel-key revocation are implemented in v0.8.0 and covered by its Release qualification, and again by that of v0.8.1; the remaining gaps are partial root signing across machines and external signers (trust root gaps).
• In v0.8.0, v0.8.1, v0.9.0, and v0.9.1, some Pi 1.x behavior has no public Pi switch, and PiShip does not patch Pi: the terminal title is still "π" (Pi's APP_TITLE); the exit hint still says pi --session-dir ... --session ...; Pi still adds its /bug hint (#139); and the built-in /share command uploads the session file as a GitHub gist through the user's own gh CLI, a child process outside PiShip's in-process network policy, so a session can leave the machine that way in managed mode too (security).
• Session export has no Pi seam for /share's gist fallback or /export, so session.export public and local are unsupported in v0.9.0 and v0.9.1, and support is unsupported in personal mode, where Pi's /bug upload is open; the lock and doctor always report them (security).
• A managed distribution runs Pi offline (PI_OFFLINE=1), so Pi downloads no fd or rg. From v0.9.1, a piship/v1alpha6 distribution can bundle them with runtime.searchTools: { mode: bundled }: they are pinned per release target in the lock, shipped in the payload, and found by Pi before PATH, without the network (bundled search tools). Without it, and in v0.8.0, v0.8.1, and v0.9.0, they must be on PATH for @ completion and Pi's find and grep tools. A personal distribution without bundled tools lets Pi download its own fd and rg; in v0.9.0 and earlier Pi put them, and looked for them first, in ~/.pi/agent/bin despite PiShip's agent directory, because Pi fixes that directory when it is imported. From v0.9.1 the branded command sets the agent directory before Pi loads, so they go to <state>/agent/bin (security).
• On macOS, the heartbeat test of packages/sandbox/src/boundary.test.ts is a known flake on macOS, and no root cause is established. The unit tier of the v0.11.0, v0.12.0, and v0.13.0 Release qualifications passed it on its first attempt. The seatbelt reference conformance tests on macOS are timing sensitive too: they failed twice on loaded pull-request runs during the v0.13.0 cycle and passed on the next run.
• Not verified for v0.13.0: a real pi-code isolated or background agent run (the temp-directory modes and worktree layout were read from pi-code 1.4.2's source, not run), and the package-configuration lock under real Windows contention (a scanner holding a file).

Pi compatibility

compatibility/pi.json is the machine-readable record, and @piship/core carries a copy that the compatibility suite keeps equal. For the pinned Pi 1.1.0 it lists four surfaces (1.0.3, 1.0.2, 1.0.0, and 0.87.1, kept so that releases built on them are recognized, have the same four with the same statuses):

Surface	Status	What it covers
personal	supported	The portable personal distribution core
managed	candidate	Managed access and configuration
governance	candidate	Policy and trust, capabilities, governed MCP, the OS sandbox, and audit (piship/v1alpha3 and later)
lifecycle	candidate	Release, signed channels, update, and rollback

release.json records the weakest of the distribution's deployment surface, the governance surface when the distribution declares governance (every piship/v1alpha3 or later manifest does), and the lifecycle surface, so every release built today records candidate. The statuses of 1.0.0 were set equal to those of 0.87.1 at that upgrade, those of 1.0.2 equal to those of 1.0.0 at the upgrade after v0.8.1, those of 1.0.3 equal to those of 1.0.2 at the upgrade after v0.9.1 (v0.11.0 and v0.12.0 ship on it), and those of 1.1.0 equal to those of 1.0.3 at the upgrade after v0.12.0 (v0.13.0 ships on it); the Release qualifications of v0.8.0 and v0.8.1 are the ones recorded on Pi 1.0.0, those of v0.9.0 and v0.9.1 are the ones recorded on 1.0.2, those of v0.11.0 and v0.12.0 are the ones recorded on 1.0.3, that of v0.13.0 is the one recorded on 1.1.0, and the earlier evidence on this page was produced on 0.87.1. See compatibility for the Pi public API PiShip uses and the upgrade policy.

CI evidence tiers

AGENTS.md defines three tiers. A result is evidence only for the tier and commit it ran on.

Tier	Workflows	When it runs	What it proves
Fast merge gate	CI (build, unit tests, and Pi compatibility on Ubuntu, macOS, and Windows; the live platform secret store on Ubuntu (GNOME Keyring), macOS, and Windows; format, lint, types, and boundaries on Ubuntu), CodeQL	Every pull request and every main push	A change is safe to merge
Full Portable E2E	Portable E2E (npm run test:e2e on three targets, each split into shards on runners of their own that together run every E2E file; Ubuntu also runs the repeated-build qualification), Reference E2E (npm run test:reference and the broker contract tests against the enterprise reference stack on Ubuntu, with the Linux Secret Service)	Nightly, workflow_dispatch, and inside Release qualification; not a pull request gate	The cross-platform installed integration surface, and the managed distribution against live identity, broker, and gateway services
Release qualification	Release qualification: CI, CodeQL, Portable E2E, and Reference E2E in parallel, then Release candidate (demo company, personal example, and developer example)	workflow_dispatch only, on the exact candidate commit	A specific commit and its artifacts are ready to ship

Outside these tiers, Pi latest canary runs the compatibility suite nightly against the newest published Pi. It is early warning for the next Pi upgrade, not evidence for the pinned version. Scheduled failures of the canary, of Portable E2E, and of Reference E2E open or update a tracking issue.

Recorded evidence

A result is evidence only for the commit and tier it ran on. A run that has not happened is listed as not recorded; it is never inferred from another commit.

v0.6 freeze

ab3e7f2 on main is the v0.6 freeze SHA: the last commit before any v0.7 pull request merges. v0.7 work branches from it.

Tier	Commit	Result
Fast merge gate	ab3e7f2 (freeze)	CI and CodeQL passed
Portable E2E	ab3e7f2 (freeze)	Passed on Ubuntu, macOS, and Windows inside the Release qualification run below
Release qualification	ab3e7f2 (freeze)	Run, dispatched manually on the exact commit: CI, CodeQL, Portable E2E, and Release candidate (demo company and personal example: two builds per target, reproducibility, verification, attestation, and install) passed on all three targets
Fast merge gate	4830b07, the commit before the freeze	CI: the Windows job failed in packages/audit/src/log.test.ts, an audit log rotation test whose assertion depended on how two concurrent writers interleave; the macOS and Ubuntu jobs and CodeQL passed
Release qualification	21de31a, three commits before the freeze	Run: CI, CodeQL, Portable E2E, and Release candidate (demo company, personal example, and developer example) passed on all three targets. It is not evidence for ab3e7f2: the commits after it change an E2E fixture and the E2E hook timeout (#36), ignore rules (#37), and SECURITY.md (#38)

Consequence: the personal surface stays supported in compatibility/pi.json, and the Release qualification on 21de31a covered the piship/v1alpha4 personal example on all three targets. The freeze SHA ab3e7f2 now has its own green Release qualification, so the v0.6 baseline is implemented, frozen, and qualified at its exact commit. Still, a v0.7 result is evidence only for the v0.7 commit it ran on and does not stand in for the v0.6 baseline.

v0.13.0

Tag v0.13.0 is commit 7f9e167 (the squash of #255, which is also the version change), the production-validation baseline.

Tier	Commit	Result
Release qualification	7f9e167 (v0.13.0)	Run 37887824632, first attempt on that exact commit: 54 jobs passed and 2 were skipped (the issue-report jobs that run only on schedule). CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode, reproducibility 9 of 9 payload-equal, verify-release, tamper rejection, offline install checks, attestations verified, registry signatures passed 9 of 9, vulnerabilities passed 9 of 9). The devcode archives of the two builds differ in bytes only because vulnerabilities.json records the scan time. Live Chrome startup is excluded from Release qualification. The GitHub pre-release carries the run's nine attested archives, with their SHA-256 files (digests)

The commit includes the changes since v0.12.0 listed in the changelog.

v0.12.0

Tag v0.12.0 is commit 8d40a68 (the squash of #246), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	8d40a68 (v0.12.0)	Run 37678031776, first attempt on that exact commit: 54 jobs passed and 2 were skipped (the issue-report jobs that run only on schedule). CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode, reproducibility 9 of 9 payload-equal, verify-release, tamper rejection, offline install checks, attestations verified, registry signatures passed 9 of 9, vulnerabilities passed 9 of 9). The devcode archives of the two builds differ in bytes only because vulnerabilities.json records the scan time. The GitHub pre-release carries the run's nine attested archives, with their SHA-256 files (digests)
Release qualification	0404e484 (the version change, #245)	Run 37669522371: one Windows end-to-end job failed (a test downloaded fd and rg from GitHub and timed out) and the run was cancelled. #246 fixed the cause, and run 37678031776 above is on the commit that contains the fix. It is not evidence for 8d40a68

The commit includes the changes since v0.11.0 listed in the changelog.

v0.11.0

Tag v0.11.0 is commit d4f740f (the squash of #237), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	d4f740f (v0.11.0)	Run 37538011406, dispatched manually on the exact commit: all 56 jobs passed on their first attempt, on Pi 1.0.3 and Node 22.19.0. CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E on all three targets, Reference E2E, and Release candidate (two builds per target for acmecode, mypi, and devcode, reproducibility 9 of 9 equal, verify-release, tamper rejection, offline install with the shipped script on fresh runners, attestations, registry signatures passed 9 of 9, vulnerabilities passed). The GitHub pre-release carries the run's nine attested archives, with their SHA-256 files (digests)
Windows benchmark (unbundled layout)	486545e	Run 37519509590, manual, finished after the release was built: the concurrency sweep on the unbundled payload (7,477 files) kept the defaults (performance). It is a measurement, not a qualification

The commit includes the v0.10.0 changes and the other changes since v0.9.1 listed in the changelog.

v0.9.1

Tag v0.9.1 is commit a97ba43 (the squash of #215), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	a97ba43 (v0.9.1)	Run 37297400038, dispatched manually on the exact commit: CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target for the demo company acmecode and the personal example mypi, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners) passed, on Pi 1.0.2 and Node 22.19.0, every job on its first attempt. The GitHub pre-release carries the run's six attested archives, with their SHA-256 files (digests)

The commit includes the changes since v0.9.0 listed in the baseline section: the dependency updates of #206, the setup guide change of #211, the MCP plain HTTP and identity headers of #212, plain HTTP to internal endpoints of #213, the bundled search tools of #214, and #215, which sets the version to 0.9.1.

v0.9.0

Tag v0.9.0 is commit ff3c382 (the squash of #209), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	ff3c382 (v0.9.0)	Run 37247881318, dispatched manually on the exact commit: CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target for the demo company acmecode and the personal example mypi, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners) passed, on Pi 1.0.2 and Node 22.19.0. On the first attempt the Windows check job failed in one unit test, kills the whole process tree on timeout in packages/sandbox/src/process.test.ts: its one-second deadline killed the child before the child wrote its first output. The failed job was rerun on the same commit (attempt 2), and every job passed. The GitHub pre-release carries the run's six attested archives, with their SHA-256 files

The commit includes the changes since v0.8.1 listed in the baseline section: the Pi 1.0.2 upgrade of #205, the governance and v1alpha6 contracts of #207, the guide updates of #208, and #209, which copies the Pi package and its lockfile with the reference distribution in Reference E2E. After v0.9.0, that test's deadline on main is five seconds.

v0.8.1

Tag v0.8.1 is commit d069104 (the squash of #203), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	d069104 (v0.8.1)	Run 37127974973, dispatched manually on the exact commit: CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target for the demo company acmecode and the personal example mypi, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners) passed, on Pi 1.0.0 and Node 22.19.0. The GitHub pre-release carries the run's six attested archives, with their SHA-256 files

The commit includes the changes since v0.8.0 listed in the baseline section: #198, #200, #201, and the review fixes of #202, with the setup guide fix of #195.

v0.8.0

Tag v0.8.0 is commit 8550282 (the squash of #193), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	8550282 (v0.8.0)	Run 37108519783, dispatched manually on the exact commit: CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target for the demo company acmecode and the personal example mypi, attestation, verify-release, tamper rejection, and install with the shipped script on fresh runners) passed, on Pi 1.0.0 and Node 22.19.0. The GitHub pre-release carries the run's six attested archives, with their SHA-256 files

The commit includes #191 and #192, which make the E2E flows expect the root refresh's request for root/2.json and parse the v0.8 keygen output, and #193, which lets a release with an update source and no bootstrap trust build as update-disabled.

After v0.7.1 on main

Manual real-provider evidence for the reference stack. Both runs were dispatched by the maintainer from main at 9e458f0 (after #182), in the protected live-provider environment with its stored provider secrets. Each sent one --smoke-model request from the AcmeCode reference distribution, signed in on the reference Keycloak with a credential from the reference broker, through the reference LiteLLM to a real upstream model provider, and checked for a non-empty reply that ended with stop.

Tier	Commit	Result
Live provider	9e458f0	Run 36877709332, with the stored secrets as they are: passed
Live provider	9e458f0	Run 36877168540, with a model given for that run only (the model input from #182): passed. Supporting evidence

This is evidence for the reference stack against a real provider, not for a company's identity provider or gateway: no validation against a real company identity provider or company gateway in production is recorded. The first production consumer collects that downstream.

v0.7.1

Tag v0.7.1 is commit bd4bc09 (the squash of #174), the previous production-validation baseline.

Tier	Commit	Result
Release qualification	bd4bc09 (v0.7.1)	Run 36857734987, dispatched manually on the exact commit: CI, CodeQL, Portable E2E, Reference E2E, and Release candidate (two byte-identical builds per target, verify-release, tamper rejection, attestation, and install on fresh runners) passed. The GitHub pre-release carries the run's six attested archives unchanged, and a fresh install from the published asset was verified

v0.7.0 release candidate

The release blockers found after ee8b4a9 (#122, #123, #124) were fixed in pull request #163, and the selected hardening items of #157, #158, and #159 in pull request #164, which also sets the PiShip version to 0.7.0. Its Release qualification found three test and example gaps, fixed in pull request #165. The squash commit of #165, 4994eee, is v0.7.0: Release qualification (CI, CodeQL, Portable E2E, Reference E2E, and Release candidate) passed on that exact commit, it is recorded in #121, the v0.7.0 tag is set on it, and its GitHub pre-release carries that run's archives. The ee8b4a9 evidence below is kept for its own commit.

Pi stays at 0.87.1 for v0.7.0. The latest stable Pi when the candidate was frozen, 0.99.2 (2026-09-30), still pins brace-expansion 5.0.9 in its npm-shrinkwrap.json, so it would not clear the advisory below, and its 0.99.0 adds built-in MCP, codemode, and tool search extensions that run tools outside the paths PiShip governs, which needs a compatibility review of its own. Upstream tracking: earendil-works/pi#10273.

v0.7 candidate

The last v0.7 code change is pull request #118, head 44d11e2. Its squash commit on main, 3110556, has the same tree as 44d11e2 (e1b374e). CI, CodeQL, and Portable E2E ran on 44d11e2 or on the merge ref built from it, before the squash, and cover that tree. Reference E2E ran on 3e935a5; see its row. None of them ran on 3110556 itself. Pull request #119 then changed documentation only; its squash commit ee8b4a9 is the v0.7 candidate, and its Release qualification ran on that exact commit. The rows before it are the pull request evidence, kept for their own commits. A review of ee8b4a9 after that run found release blockers (#122), so ee8b4a9 was never tagged; Release qualification ran again on 4994eee, which became v0.7.0. This section is kept as history.

Tier	Commit	Result
Fast merge gate	a185470, the pull request's merge ref (44d11e2 merged into main at 6fc3345; tree e1b374e, the tree of 44d11e2)	CI: check passed on Ubuntu, macOS, and Windows. Unit tests: Ubuntu 2803 passed and 8 skipped, macOS 2805 and 6, Windows 2596 and 198 (platform-gated tests skip). Pi compatibility: 31 tests on each. The live platform secret store passed on each. With the sandbox required on Ubuntu and macOS, the live probe and the boundary tests ran, per sandbox backends. CodeQL passed on the same ref.
Portable E2E	44d11e2, the branch head	Run, dispatched on the branch head: passed on all nine shards (Ubuntu 2, macOS 3, Windows 4). Together the shards ran all 27 E2E files once on each target, and every file passed on every target: Ubuntu 71 tests passed and 1 skipped, macOS 71 and 1, Windows 70 and 2 (tests gated to another platform skip; the one skipped in governance on Ubuntu and macOS is the Windows-only refusal). managed-clean-machine ran its whole flow on each target in the live platform store; its sandboxed commands ran under bubblewrap on Ubuntu and under Seatbelt on macOS, and on Windows it ran none (unavailable).
Reference E2E	3e935a5	Run on Ubuntu 24.04 with Docker 28.0.4, bubblewrap 0.9.0, and the Linux Secret Service: passed, the stack job and all four test groups (78 tests passed, 1 skipped: the Live provider test skips itself without its provider variables). The groups ran the AcmeCode flow, user switching, sign-in security cases against Keycloak, gateway evidence, usage continuity, budgets, rate limits, and the reference sandbox. 44d11e2 differs from 3e935a5 only in two test files that Reference E2E does not run (packages/pi/src/launch/session-file.test.ts and tests/e2e/personal-lifecycle.test.ts), so the run is cited for 44d11e2 on that ground and is otherwise evidence for 3e935a5.
Live qualification of E2B, CubeSandbox, and Kubernetes Agent Sandbox	none	unavailable: no service, account, or cluster was available (external backends).
Live provider	none	Not recorded for this candidate; the first runs are recorded after v0.7.1.
First production consumer's managed path	none	open: collected downstream, see distribution qualification.
Release qualification	ee8b4a9 (candidate)	Run, dispatched manually on the exact commit: CI (check on Ubuntu, macOS, and Windows), CodeQL, Portable E2E (all nine shards: Ubuntu 2, macOS 3, Windows 4), Reference E2E (the stack job and all four test groups), and Release candidate passed. The Release candidate built the demo company (acmecode) and the personal example (mypi) twice per target, and each distribution passed reproducibility, attestation, verification on a fresh runner with tamper rejection, and install on all three targets; the installed mypi also passed the offline --smoke and doctor. The Windows acmecode candidate is the patched variant, with the sandbox optional and its lock generated in CI (artifact contract). It does not tag, sign a channel, or publish.

Earlier milestones

Tier	Commit	Result
Fast merge gate	v0.5 03c33cf on main	CI, Pi compatibility, Secret store, and CodeQL passed
Portable E2E	v0.5 03c33cf	No run recorded
Portable E2E	Last head of the v0.5 pull request	Run: Ubuntu and Windows passed, macOS failed
Portable E2E	Earlier v0.5 pull request head (personal examples relocked)	Run: passed on all three targets
Release candidate	v0.5 03c33cf	No run recorded
Release candidate	Last head of the v0.5 pull request	Run: passed on all three targets
Governance sandbox on macOS	v0.3 pull request	CI run with the Seatbelt live probe and launchd boundary test; Portable E2E passed on all three targets
Personal surface first qualified	v0.1 pull request	Pi compatibility run with build and installed E2E on all three targets, for the piship/v1alpha1 personal example of that time

Version map

Product milestones and schema versions are separate. A milestone is a unit of project work; a schema version changes only when the manifest or lock format changes.

Milestone	Theme	Manifest schema	Lock schema
v0.1	Portable personal distribution core	piship/v1alpha1	piship-lock/v1alpha1
v0.2	Managed access and configuration	piship/v1alpha2	piship-lock/v1alpha2
v0.3	Governance and security baseline	piship/v1alpha3	piship-lock/v1alpha3
v0.4	Production release lifecycle	piship/v1alpha4	piship-lock/v1alpha4
v0.5	Gap closure across governance, access, supply chain, and the personal profile	piship/v1alpha4 (unchanged)	piship-lock/v1alpha4 (unchanged)
v0.6 (implemented, frozen and qualified at ab3e7f2)	Project consolidation	piship/v1alpha4 (unchanged)	piship-lock/v1alpha4 (unchanged)
v0.7 (v0.7.0 at 4994eee, the squash of #165; v0.7.1 at bd4bc09, the squash of #174)	Enterprise integration and qualification	piship/v1alpha4 (unchanged)	piship-lock/v1alpha4 (unchanged)
v0.8 (v0.8.0 at 8550282, the squash of #193; v0.8.1 at d069104, the squash of #203)	Pre-production trust and validation hardening	piship/v1alpha5	piship-lock/v1alpha5
v0.9 (v0.9.0 at ff3c382, the squash of #209; v0.9.1 at a97ba43, the squash of #215)	Pi 1.x-native governance	piship/v1alpha6	piship-lock/v1alpha6
v0.10 (never published; shipped inside v0.11.0)	Portability and Windows hot-path performance	piship/v1alpha6 (unchanged)	piship-lock/v1alpha6 (unchanged)
v0.11 (v0.11.0 at d4f740f, the squash of #237; v0.10.0 never published)	Runtime footprint, Windows performance, stable v1 contracts, production readiness	piship/v1 (stable; v1alpha6 accepted for the migration window)	piship-lock/v1 (stable; v1alpha6 read)
v0.12 (v0.12.0 at 8d40a68, the squash of #246; the version change is #245)	Install to daily use: fewer crashes, dead ends, and repeated prompts	piship/v1 (unchanged)	piship-lock/v1 (unchanged)
v0.13 (v0.13.0 at 7f9e167, the squash of #255, which is also the version change)	Subagents through the governed launcher, TypeScript Pi package transpilation, Pi 1.1.0	piship/v1 (unchanged; optional pretranspile field)	piship-lock/v1 (unchanged; records pretranspile)

All seven manifest schemas are accepted. piship/v1 is stable and freezes the semantics of piship/v1alpha6; the six alpha schemas are experimental, kept for the migration window. Only piship/v1alpha5, piship/v1alpha6, and piship/v1 can build a release, and piship migrate takes an older manifest step by step to v1 (migration). Every example uses piship/v1. The schema details live in manifest; the history lives in the changelog; what comes next is in the roadmap.