> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/release-and-readiness/public-release.md).

# Public release artifact

This runbook creates and verifies the immutable standalone artifact used by the already approved `nytshift.xyz` VPS. It does not deploy, contact the VPS, mutate `/opt/nytshift`, change DNS, edit systemd/Nginx/TLS or enable execution.

## Builder requirements

* fresh detached worktree at the exact accepted commit;
* Linux x64;
* Node 24 and pnpm 11.7.0;
* dependencies installed from the committed lockfile;
* Python 3.10-3.12 with `services/execution-py[dev]` discoverable from `python3` so the mandatory Python and signer gates can run;
* no tracked or untracked source changes;
* no root or web `.env*` file;
* an existing plain output directory outside the repository;
* enough free space for the build, stage, raw archive and compressed artifact.

The official builder deliberately refuses Windows and macOS. A Next.js standalone bundle can trace native optional packages such as `sharp`; the deployable artifact must therefore be compiled for the VPS platform, not merely copied from a developer workstation.

## Build

From the exact detached Linux worktree:

```bash
commit="$(git rev-parse HEAD)"
mkdir -p "/home/nytshift-release/$commit"
pnpm release:public:build -- \
  --output-directory "/home/nytshift-release/$commit" \
  --expected-commit "$commit"
```

The command runs the full repository handoff verification with a private temporary NIGHTSHIFT home and a scrubbed environment. It then emits three create-once files:

* `nytshift-<short-commit>-standalone.tar.gz`;
* `nytshift-<short-commit>-standalone.sha256`;
* `nytshift-<short-commit>-standalone.release.json`.

Before the gates run, the builder probes the exact Python interpreter and user package base, creates a temporary wrapper inside the private build home, and proves `terminal_execution`, pytest, and Ruff are available through that wrapper. The temporary path is passed only as `NIGHTSHIFT_PYTHON`, is removed after the run, and is not packaged. Node, pnpm, Next.js, Python, and tar versions are recorded in the signed-by-digest manifest/receipt pair.

Turbo's build cache is partitioned by the standalone flag, exact release commit, disabled execution/mainnet locks, RHC mode, advanced-chart mode and every supported public compile identifier. A normal local `.next` output therefore cannot satisfy this release build.

The archive contains `RELEASE_COMMIT` and `NIGHTSHIFT_RELEASE_MANIFEST.json`. It intentionally does not contain `RELEASE_SHA256` because that value is the digest of the completed archive.

Only these presentation values may enter compilation when explicitly supplied: `NEXT_PUBLIC_PRIVY_APP_ID`, `NEXT_PUBLIC_PRIVY_CLIENT_ID`, `NEXT_PUBLIC_PRIVY_WALLETCONNECT_PROJECT_ID` and `NYTSHIFT_TOKEN_ADDRESS`. They are public identifiers, and their compiled effect is covered by the artifact tree digest. Server secrets and provider URLs are removed from the build environment and remain runtime-only service configuration.

## Independent verification

Run verification on the builder and again after transfer:

```bash
pnpm release:public:verify -- \
  --archive "/absolute/path/nytshift-<short>-standalone.tar.gz" \
  --receipt "/absolute/path/nytshift-<short>-standalone.release.json" \
  --expected-commit "<40-character-commit>"
```

Accept only `state: verified`. The returned archive SHA-256, bytes, tree SHA-256, file count, unpacked bytes and application command must equal the receipt. Verification extracts only into a private temporary directory after member-path checks and removes it afterward.

## Promotion boundary

Promotion remains the separately approved operator workflow:

1. Re-run the verifier against the transferred server files.
2. Run the content-addressed release-capacity audit using the receipt's compressed and unpacked byte counts. Do not prune implicitly.
3. Extract into a fresh seven-character release directory under `/opt/nytshift/releases`; never extract over `current` or an existing release.
4. Confirm the embedded `RELEASE_COMMIT` begins with the directory name and equals the accepted 40-character commit.
5. Write `RELEASE_SHA256` as one lowercase digest plus a newline using the exact verified archive SHA-256. Do not copy a value from chat or retype it manually.
6. Preserve ownership, the existing loopback `127.0.0.1:3333` service configuration, Nginx site and TLS configuration. Confirm their pre/post hashes.
7. Atomically repoint `/opt/nytshift/current`, restart only `nytshift.service`, and require active/running state plus verified `/api/health` before acceptance.
8. Verify HTTP-to-HTTPS redirect, `/`, `/terminal`, `/nightshift`, health, brand assets and every discovered Next CSS/JS asset. Run desktop and 390-pixel browser QA with no overflow, console warning/error or page error.
9. Confirm `EXECUTION_MODE=disabled`, `ARCUS_EXECUTION_MODE=disabled`, both mainnet flags false and operator authentication unconfigured unless a separate authorized activation task says otherwise.

Do not promote if the archive/receipt pair changes, public health does not report the exact pair, capacity is critical, a service/config hash changes unexpectedly, or browser/runtime checks fail.

## Rollback

Keep the previously verified release. If post-promotion checks fail, atomically repoint `current` to that retained verified directory, restart `nytshift.service`, and repeat health/public/browser checks. Preserve the rejected archive, receipt, service journal and failure evidence for diagnosis; do not edit the failed immutable release in place.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://nytshift.gitbook.io/nytshift-docs/release-and-readiness/public-release.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
