Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -4,5 +4,6 @@
/.openclaw-version
.omx/
.playwright-cli/
site/public/ocvm/
*.log
.DS_Store
3 changes: 3 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@

## Unreleased

- Replaced GitHub raw installer guidance with a static installer path that can be mirrored to OSS/CDN.
- Added website documentation routes for installation, commands, configuration, and release sources.
- Added GitHub and documentation navigation to the landing page.
- Updated landing page and crate metadata for `https://ocvm.vercel.app`.
- Clarified the site Install section around the pinned `v0.1.1` release.
- Added a GitHub Actions site build gate for the Vercel app in `site/`.
Expand Down
24 changes: 20 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -198,12 +198,26 @@ Rollback does not delete unrelated installed versions.

## Install

After a GitHub Release exists:
After a GitHub Release exists, publish `install.sh` to a stable HTTPS path. The
current site publishes the installer as a static asset, and the same layout can
be mirrored to OSS or placed behind a CDN:

```bash
curl -fsSL https://raw.githubusercontent.com/PerfectPan/ocvm/v0.1.1/install.sh | sh
curl -fsSL https://ocvm.vercel.app/ocvm/install.sh | sh
```

For repeatable automation, pin the binary release with `OCVM_VERSION` while
using the same installer script:

```bash
curl -fsSL https://ocvm.vercel.app/ocvm/install.sh | OCVM_VERSION=v0.1.1 sh
```

Maintainers set `OCVM_INSTALLER_BASE_URL` to the published OSS/CDN prefix during
release preparation when mirroring the same layout outside Vercel. Future
releases only need to update the stable installer script when the script itself
changes or when its default pinned release changes.

## Docker E2E

Run real npm OpenClaw install validation in Docker instead of on the host:
Expand All @@ -212,9 +226,11 @@ Run real npm OpenClaw install validation in Docker instead of on the host:
./scripts/e2e-docker.sh
```

## Landing Page
## Website and Docs

The TanStack Start landing page is deployed at https://ocvm.vercel.app. Source lives in `site/` and is configured for Vercel deployments from that directory:
The TanStack Start landing page and documentation site are deployed at
https://ocvm.vercel.app. Source lives in `site/` and is configured for Vercel
deployments from that directory:

```bash
npm ci --prefix site
Expand Down
31 changes: 31 additions & 0 deletions docs/plans/2026-05-17-installer-docs-design.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Installer Distribution and Documentation Design

## Goal

Resolve GitHub issues #19 and #20 by making the installer distribution path resilient outside GitHub raw content and by giving new users a coherent landing and documentation experience.

## Installer Distribution

Common installer hosting should use one public object-storage path:

```text
https://<oss-or-cdn-domain>/ocvm/install.sh
```

The stable `install.sh` path is the recommended copy-paste command for most users. Repeatable automation should pin the binary release with `OCVM_VERSION=v0.1.1` while reusing the same script. This avoids uploading a new installer script for every release unless the script logic or default pinned release changes. The repository should not hard-code an unverified vendor bucket domain. Instead, docs and site copy should expose `OCVM_INSTALLER_BASE_URL` as the release-time value that maintainers set to their OSS or CDN prefix.

The install script itself continues to resolve binaries from GitHub Releases unless `OCVM_REPO`, `GITHUB_API_URL`, or future release-source variables override that behavior. Issue #19 is specifically about avoiding GitHub raw content for downloading the script, not about changing release asset storage in this pass.

## Documentation Site

The existing `site/` app remains the single web project. It should add a `/docs` area that shares navigation, visual language, and install commands with the landing page. The docs area should be content-first and lightweight: installation, command reference, configuration, and release source pages are enough for the current CLI surface.

Fumadocs is the target documentation framework. Because the current app is TanStack Start on Vite, integration should follow Fumadocs' Vite/TanStack path where practical. If package constraints make full Fumadocs UI integration risky in this pass, the repository should still adopt a docs route/content boundary that can be migrated cleanly to Fumadocs components later.

## GitHub Stars

The landing page should show GitHub star visibility without making rendering depend on a live GitHub API request. The first implementation can use a static repository stat value with a direct GitHub link and accessible label. A future enhancement can hydrate the value from GitHub with caching once a server data-loading convention is chosen.

## Validation

Run the Rust checks because this remains a publishable CLI repository. Run the site build because the web app changes user-facing behavior. Run a publish-safety scan before pushing. If dependency installation or networked package fetches fail, record the exact blocker and verify all offline-capable checks.
108 changes: 108 additions & 0 deletions docs/plans/2026-05-17-installer-docs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
# Installer Distribution and Documentation Implementation Plan

> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.

**Goal:** Resolve GitHub issues #19 and #20 by replacing GitHub raw installer guidance with an OSS/CDN-ready distribution convention and adding a coherent documentation experience to the existing site.

**Architecture:** Keep the Rust CLI at the repository root and the web experience in `site/`. Treat installer distribution as release documentation plus a reusable URL contract, and treat docs as a first-class route group in the existing TanStack Start app so landing and docs share copy, navigation, and styles.

**Tech Stack:** Rust CLI, POSIX shell installer, TanStack Start, React, TypeScript, Vite, CSS, Fumadocs-compatible documentation structure.

---

### Task 1: Document the Installer Distribution Contract

**Files:**
- Modify: `README.md`
- Modify: `docs/release.md`
- Modify: `CHANGELOG.md`

**Steps:**

1. Add an OSS/CDN installer URL convention with one stable script path:
- `https://<oss-or-cdn-domain>/ocvm/install.sh`
2. Document repeatable automation as `curl .../install.sh | OCVM_VERSION=v0.1.1 sh`.
3. Keep GitHub raw as a maintainer fallback, not the primary user-facing install path.
4. Document `OCVM_INSTALLER_BASE_URL` as the release-time prefix maintainers publish to object storage.
4. Update changelog with user-facing installer guidance changes.
5. Verify with `rg -n "raw.githubusercontent.com|OCVM_INSTALLER_BASE_URL|oss-or-cdn" README.md docs site install.sh CHANGELOG.md`.

### Task 2: Add Shared Site Content for Install and Docs Navigation

**Files:**
- Create: `site/src/content.ts`
- Modify: `site/src/routes/index.tsx`

**Steps:**

1. Extract current release, installer base URL, install command, repo URL, release URL, docs URL, and star label into `site/src/content.ts`.
2. Use the shared install command on the landing page.
3. Add a GitHub star link in the top navigation with a static accessible label.
4. Point Docs navigation to `/docs` instead of a GitHub blob URL.
5. Verify TypeScript imports by running `npm run build --prefix site`.

### Task 3: Add Documentation Routes

**Files:**
- Create: `site/src/routes/docs.tsx`
- Create: `site/src/routes/docs.installation.tsx`
- Create: `site/src/routes/docs.commands.tsx`
- Create: `site/src/routes/docs.configuration.tsx`
- Create: `site/src/routes/docs.release-sources.tsx`

**Steps:**

1. Build `/docs` as an overview page with links to the four documentation pages.
2. Add install docs covering the OSS/CDN convention and local bin setup.
3. Add command docs matching the README command surface.
4. Add configuration docs for `OCVM_HOME`, `OCVM_NPM_PACKAGE`, `OCVM_SOURCE`, and release manifest URL.
5. Add release-source docs for npm and manifest source behavior.
6. Keep docs content concise and current.
7. Verify route generation/build with `npm run build --prefix site`.

### Task 4: Unify Landing and Docs Styling

**Files:**
- Modify: `site/src/styles.css`

**Steps:**

1. Add shared top navigation styles that work for both landing and docs pages.
2. Add docs layout styles with readable width, sidebar-like page index, and code blocks.
3. Keep card radius at 8px or less and avoid nested cards.
4. Check responsive rules for mobile and desktop.
5. Verify visually with a local site server and browser screenshots when feasible.

### Task 5: Verify Repository Gates

**Commands:**

```bash
cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test
npm run build --prefix site
cargo build --release
cargo package --allow-dirty
rg --hidden --no-ignore -n "private-token|secret|internal-domain.example|HOME_PATH_PLACEHOLDER" . --glob '!target/**' --glob '!.git/**' --glob '!.omx/**' --glob '!AGENTS.md' --glob '!CONTRIBUTING.md' --glob '!SECURITY.md'
```

If network or package-cache constraints block the site build, record the exact command and failure output, then run all checks that do not require new network access.

### Task 6: Publish the Branch

**Steps:**

1. Inspect `git status --short --branch`.
2. Review changed files for generated output, secrets, and machine paths.
3. Commit with a concise conventional commit message ending with:

```text
Generated with Codex

Co-Authored-By: Codex <noreply@openai.com>
```

4. Push the branch.
5. Create or reuse a GitHub Pull Request.
6. Include validation commands and remaining risks in the PR summary.
23 changes: 20 additions & 3 deletions docs/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,16 +25,33 @@ The `Release` workflow builds platform binaries, packages archives, generates SH

## Install Script

Users can install a specific release with:
Publish the installer to object storage or a CDN after the GitHub Release is
created. Use one stable script path for onboarding and pin the binary release
with `OCVM_VERSION` when automation needs repeatable installs:

```bash
curl -fsSL https://raw.githubusercontent.com/PerfectPan/ocvm/v0.1.1/install.sh | sh
export OCVM_INSTALLER_BASE_URL="https://ocvm.vercel.app/ocvm"

# Stable installer path for the current release.
curl -fsSL "$OCVM_INSTALLER_BASE_URL/install.sh" | sh

# Repeatable install pinned to a specific binary release.
curl -fsSL "$OCVM_INSTALLER_BASE_URL/install.sh" | OCVM_VERSION=v0.1.1 sh
```

Override `OCVM_VERSION` to install a different release:

```bash
curl -fsSL https://raw.githubusercontent.com/PerfectPan/ocvm/v0.1.1/install.sh | OCVM_VERSION=latest sh
curl -fsSL "$OCVM_INSTALLER_BASE_URL/install.sh" | OCVM_VERSION=latest sh
```

GitHub raw content can remain a maintainer fallback while testing release tags,
but it should not be the primary user-facing install command.

For an OSS bucket, mirror the same files and replace the prefix:

```text
ocvm/install.sh
```

## Docker E2E
Expand Down
12 changes: 12 additions & 0 deletions scripts/check-release-prep.sh
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,15 @@ expect_file_text() {
}
}

expect_files_equal() {
left="$1"
right="$2"
cmp -s "$left" "$right" || {
echo "expected $left and $right to match" >&2
exit 1
}
}

expect_output "asset=ocvm-x86_64-unknown-linux-gnu.tar.gz" \
env OCVM_INSTALL_DRY_RUN=1 OCVM_TEST_UNAME_S=Linux OCVM_TEST_UNAME_M=x86_64 ./install.sh

Expand All @@ -36,11 +45,14 @@ expect_output "asset=ocvm-aarch64-apple-darwin.tar.gz" \
expect_output "api_url=https://api.github.com/repos/PerfectPan/ocvm/releases/tags/v0.1.1" \
env OCVM_INSTALL_DRY_RUN=1 OCVM_VERSION=v0.1.1 OCVM_TEST_UNAME_S=Darwin OCVM_TEST_UNAME_M=arm64 ./install.sh

./scripts/sync-site-installer.sh >/dev/null

expect_file_text .github/workflows/release.yml "target: x86_64-unknown-linux-gnu"
expect_file_text .github/workflows/release.yml "target: x86_64-apple-darwin"
expect_file_text .github/workflows/release.yml "target: aarch64-apple-darwin"
expect_file_text .github/workflows/release.yml "target: x86_64-pc-windows-msvc"
expect_file_text .github/workflows/release.yml 'shasum -a 256 "${name}.tar.gz" > "${name}.tar.gz.sha256"'
expect_file_text .github/workflows/release.yml '"$hash $name.zip"'
expect_files_equal install.sh site/public/ocvm/install.sh

echo "release prep checks passed"
11 changes: 11 additions & 0 deletions scripts/sync-site-installer.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
#!/bin/sh
set -eu

root="$(CDPATH= cd -- "$(dirname -- "$0")/.." && pwd)"
install_script="$root/install.sh"
site_installer_dir="$root/site/public/ocvm"

mkdir -p "$site_installer_dir"
cp "$install_script" "$site_installer_dir/install.sh"

echo "synced site installer asset"
Loading
Loading