test-release

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Test Release

发布版本测试

Automated smoke test for a released archon binary. Covers three install paths:

```
brew
```
— Homebrew tap on macOS (tests the formula and checksums)
```
curl-mac
```
—
```
curl install.sh
```
on macOS (tests the install script, sandboxed to a temp dir)
```
curl-vps
```
—
```
curl install.sh
```
on a remote Linux VPS (tests the Linux binary and full install path)

Every path installs the binary, runs a fixed smoke test suite, and cleans up. The dev

bun link

binary is never touched and remains the default

archon

on PATH throughout.

When NOT to use this skill:

There is no release yet — build a local binary via
```
bash scripts/build-binaries.sh
```
and run it from
```
dist/binaries/
```
directly
You want to test the dev clone — use
```
bun run validate
```
or invoke source directly via
```
bun packages/cli/src/cli.ts
```
You want to test the full server + web UI deploy flow — use the cloud-init from
```
deploy/cloud-init.yml
```
on a real VPS

针对已发布的Archon二进制文件的自动化冒烟测试，涵盖三种安装路径：

```
brew
```
— macOS上的Homebrew源（测试公式与校验和）
```
curl-mac
```
— macOS上通过
```
curl install.sh
```
安装（测试安装脚本，在临时目录中沙箱运行）
```
curl-vps
```
— 远程Linux VPS上通过
```
curl install.sh
```
安装（测试Linux二进制文件与完整安装路径）

每种路径都会安装二进制文件、运行固定的冒烟测试套件并完成清理。开发环境的

bun link

二进制文件全程不会被触碰，始终作为PATH中的默认

archon

。

不适用此技能的场景：

版本尚未发布 — 通过
```
bash scripts/build-binaries.sh
```
构建本地二进制文件，直接从
```
dist/binaries/
```
运行
想要测试开发克隆版本 — 使用
```
bun run validate
```
或通过
```
bun packages/cli/src/cli.ts
```
直接调用源代码
想要测试完整的服务器+Web UI部署流程 — 在真实VPS上使用
```
deploy/cloud-init.yml
```
中的cloud-init配置

Local build for pre-release QA

预发布QA的本地构建

To build a binary locally with the exact same flags and constants that CI uses, invoke

scripts/build-binaries.sh

directly. The script supports two modes:

bash

undefined

要使用CI所用的完全相同的标志和常量在本地构建二进制文件，直接调用

scripts/build-binaries.sh

脚本。该脚本支持两种模式：

bash

undefined

Multi-target mode (builds all 4 local platforms into dist/binaries/)

多目标模式（将所有4个本地平台构建到dist/binaries/）

VERSION=0.3.1 GIT_COMMIT=abc12345 bash scripts/build-binaries.sh

Single-target mode (matches one CI matrix job)

单目标模式（匹配一个CI矩阵任务）

VERSION=0.3.1
GIT_COMMIT=abc12345
TARGET=bun-darwin-arm64
OUTFILE=dist/test-archon-darwin-arm64
bash scripts/build-binaries.sh

Verify the binary — use the path from the mode you built:

验证二进制文件 — 使用你构建时选择的模式对应的路径：

multi-target → ./dist/binaries/archon-darwin-arm64

多目标 → ./dist/binaries/archon-darwin-arm64

single-target → the OUTFILE you passed above

单目标 → 你传入的OUTFILE路径

./dist/test-archon-darwin-arm64 version

Expected: Archon CLI v0.3.1, Build: binary, Git commit: abc12345

预期输出：Archon CLI v0.3.1, Build: binary, Git commit: abc12345


Run this **before tagging a release** to catch build-time-constant issues
locally. The script is the canonical entry point — both local dev and the
release workflow call it the same way, so a green local build means the CI
build will exercise the same code path.


在打发布标签**之前**运行此脚本，以在本地捕获构建时常量相关问题。该脚本是标准入口点 — 本地开发和发布工作流都会以相同方式调用它，因此本地构建成功意味着CI构建会执行相同的代码路径。

Phase 1 — Determine scope

阶段1 — 确定范围

Parse the arguments. The skill takes up to three:

Install path (
```
brew
```
|
```
curl-mac
```
|
```
curl-vps
```
): which install flow to exercise
Expected version (optional): the version tag the release should report, e.g.
```
0.3.1
```
. If not provided, fetch it:

bash

gh release list --repo coleam00/Archon --limit 1 --json tagName --jq '.[0].tagName'

VPS target (only for
```
curl-vps
```
): SSH target in the form
```
user@host
```
or
```
host
```
(uses default SSH config)

If any argument is missing, ask the user for clarification BEFORE doing anything. Never guess the install path or the expected version.

Confirm the plan with the user before proceeding to Phase 2. Output should look like:

About to test:
  Path:     brew (Homebrew tap on macOS)
  Version:  0.3.1 (expected)
  Cleanup:  will uninstall after tests (brew uninstall + untap)
            If `archon-stable` symlink is detected in Phase 2, it will be
            restored at the end of Phase 5 by reinstalling the tap formula.

Proceed? (y/N)

Do not continue without explicit confirmation. Release testing touches install state and the user should be aware.

解析参数。该技能最多接受三个参数：

安装路径 (
```
brew
```
|
```
curl-mac
```
|
```
curl-vps
```
)：要测试的安装流程
预期版本（可选）：发布版本应报告的标签，例如
```
0.3.1
```
。如果未提供，则通过以下命令获取：

bash

gh release list --repo coleam00/Archon --limit 1 --json tagName --jq '.[0].tagName'

VPS目标（仅适用于
```
curl-vps
```
）：SSH目标，格式为
```
user@host
```
或
```
host
```
（使用默认SSH配置）

如果任何参数缺失，在执行任何操作前询问用户以明确信息。切勿猜测安装路径或预期版本。

在进入阶段2前与用户确认计划。输出应如下所示：

即将执行测试：
  路径：     brew（macOS上的Homebrew源）
  版本：     0.3.1（预期）
  清理：     测试后将卸载（brew uninstall + untap）
            如果在阶段2检测到`archon-stable`符号链接，将在阶段5结束时通过重新安装源公式恢复它。

是否继续？(y/N)

未获得明确确认前请勿继续。发布测试会影响安装状态，用户应知晓相关操作。

Phase 2 — Pre-flight

阶段2 — 预检

Before touching anything:

Capture the current dev binary state for reference:

bash

which -a archon
archon version 2>&1 | head -5

Record the path and version of the dev binary so the final report can show "dev binary was untouched".

Verify prerequisites for the chosen path:
- brew:
```
brew --version
```
  must succeed. If not, abort with "Homebrew not installed — see https://brew.sh/"
- curl-mac:
```
curl --version
```
  must succeed (effectively always true on macOS)
- curl-vps:
```
ssh <target> 'uname -a'
```
  must succeed. If not, abort with "Cannot SSH to <target>". Also verify
```
ssh <target> 'command -v curl'
```
  returns a path.
Confirm the release exists on GitHub:

bash

gh release view v<version> --repo coleam00/Archon --json tagName,assets --jq '{tag: .tagName, assetCount: (.assets | length)}'

If the release does not exist or has no assets, abort with a clear message. Do not proceed to install a non-existent release.

Detect persistent
archon-stable
install (brew path only). If the user has renamed a prior brew install to
```
archon-stable
```
(the dual-homebrew pattern — see
```
~/.config/fish/functions/brew-upgrade-archon.fish
```
), Phase 5's
```
brew uninstall
```
will wipe it. Capture the state so Phase 5b can restore it:

bash

ARCHON_STABLE_WAS_INSTALLED=""
if [ -L /opt/homebrew/bin/archon-stable ] || [ -L /usr/local/bin/archon-stable ]; then
  ARCHON_STABLE_WAS_INSTALLED="yes"
  echo "Detected persistent archon-stable — will restore after Phase 5 uninstall."
fi

Export

ARCHON_STABLE_WAS_INSTALLED

into the environment used by Phase 5b. Only applies to the

brew

path —

curl-mac

and

curl-vps

don't go through brew and don't disturb

archon-stable

在进行任何操作前：

捕获当前开发二进制文件状态以供参考：

bash

which -a archon
archon version 2>&1 | head -5

记录开发二进制文件的路径和版本，以便最终报告能够显示“开发二进制文件未被触碰”。

验证所选路径的先决条件：
- brew：
```
brew --version
```
  必须执行成功。否则，终止操作并提示“未安装Homebrew — 请查看https://brew.sh/”
- curl-mac：
```
curl --version
```
  必须执行成功（在macOS上基本始终成立）
- curl-vps：
```
ssh <target> 'uname -a'
```
  必须执行成功。否则，终止操作并提示“无法SSH连接到<target>”。同时验证
```
ssh <target> 'command -v curl'
```
  返回有效路径。
确认GitHub上存在该版本：

bash

gh release view v<version> --repo coleam00/Archon --json tagName,assets --jq '{tag: .tagName, assetCount: (.assets | length)}'

如果版本不存在或没有资产，终止操作并给出明确提示。请勿尝试安装不存在的版本。

检测持久化的
archon-stable
安装（仅brew路径）。如果用户已将之前的brew安装重命名为
```
archon-stable
```
（双Homebrew模式 — 详见
```
~/.config/fish/functions/brew-upgrade-archon.fish
```
），阶段5的
```
brew uninstall
```
会将其删除。捕获此状态以便阶段5b能够恢复它：

bash

ARCHON_STABLE_WAS_INSTALLED=""
if [ -L /opt/homebrew/bin/archon-stable ] || [ -L /usr/local/bin/archon-stable ]; then
  ARCHON_STABLE_WAS_INSTALLED="yes"
  echo "检测到持久化的archon-stable — 将在阶段5卸载后恢复。"
fi

将

ARCHON_STABLE_WAS_INSTALLED

导出到阶段5b使用的环境中。仅适用于

brew

路径 —

curl-mac

和

curl-vps

不通过brew安装，不会干扰

archon-stable

。

Phase 3 — Install

阶段3 — 安装

Path: brew

路径：brew

bash

brew tap coleam00/archon
brew install coleam00/archon/archon
BINARY="$(brew --prefix coleam00/archon/archon)/bin/archon"

Capture

$BINARY

for Phase 4. Verify the file exists and is executable.

bash

brew tap coleam00/archon
brew install coleam00/archon/archon
BINARY="$(brew --prefix coleam00/archon/archon)/bin/archon"

捕获

$BINARY

供阶段4使用。验证文件存在且可执行。

Path: curl-mac

路径：curl-mac

Install to a dedicated tmp directory so the dev

bun link

binary stays on PATH unchanged:

bash

INSTALL_DIR=/tmp/archon-test-release-$(date +%s)
mkdir -p "$INSTALL_DIR"
INSTALL_DIR="$INSTALL_DIR" curl -fsSL https://raw.githubusercontent.com/coleam00/Archon/main/scripts/install.sh | bash
BINARY="$INSTALL_DIR/archon"

Verify

$BINARY

exists and is executable. Capture the install directory for cleanup.

安装到专用临时目录，确保开发环境的

bun link

二进制文件在PATH中保持不变：

bash

INSTALL_DIR=/tmp/archon-test-release-$(date +%s)
mkdir -p "$INSTALL_DIR"
INSTALL_DIR="$INSTALL_DIR" curl -fsSL https://raw.githubusercontent.com/coleam00/Archon/main/scripts/install.sh | bash
BINARY="$INSTALL_DIR/archon"

验证

$BINARY

存在且可执行。捕获安装目录以便清理。

Path: curl-vps

路径：curl-vps

Run the install script on the VPS:

bash

ssh <target> 'curl -fsSL https://raw.githubusercontent.com/coleam00/Archon/main/scripts/install.sh | bash'

Determine where the binary landed —

install.sh

uses

/usr/local/bin/archon

by default, or falls back to

$HOME/.local/bin/archon

/usr/local/bin

is not writable:

bash

ssh <target> 'command -v archon'

Capture the remote path as

$REMOTE_BINARY

. For the rest of Phase 4, wrap every command as

ssh <target> '<cmd>'

在VPS上运行安装脚本：

bash

ssh <target> 'curl -fsSL https://raw.githubusercontent.com/coleam00/Archon/main/scripts/install.sh | bash'

确定二进制文件的安装位置 —

install.sh

默认使用

/usr/local/bin/archon

，如果

/usr/local/bin

不可写则回退到

$HOME/.local/bin/archon

：

bash

ssh <target> 'command -v archon'

将远程路径捕获为

$REMOTE_BINARY

。在阶段4的剩余部分，所有命令都需要包裹为

ssh <target> '<cmd>'

。

Capture SHA256 and version

捕获SHA256与版本

Immediately after install, capture:

bash

undefined

安装完成后立即捕获以下信息：

bash

undefined

Local paths (brew / curl-mac)

本地路径（brew / curl-mac）

shasum -a 256 "$BINARY" | awk '{print $1}' "$BINARY" version 2>&1

Remote path (curl-vps)

远程路径（curl-vps）

ssh <target> "shasum -a 256 $REMOTE_BINARY || sha256sum $REMOTE_BINARY" | awk '{print $1}' ssh <target> "$REMOTE_BINARY version" 2>&1


Record both for the report. The SHA256 lets us confirm later that a user reporting a bug is running the exact same artifact we tested.

ssh <target> "shasum -a 256 $REMOTE_BINARY || sha256sum $REMOTE_BINARY" | awk '{print $1}' ssh <target> "$REMOTE_BINARY version" 2>&1


将两者记录到报告中。SHA256可用于后续确认提交bug报告的用户运行的是否为我们测试的完全相同的工件。

Phase 4 — Smoke tests

阶段4 — 冒烟测试

Run these in order against

$BINARY

(or

ssh <target> $REMOTE_BINARY

for curl-vps). Always use the full binary path, never the
archon
on PATH, so there is no ambiguity about which binary is under test.

Each test should capture the full command output for the final report. If a test fails, continue to the next test (so the report is complete) but mark the overall result as FAIL.

按顺序针对

$BINARY

运行以下测试（curl-vps路径则使用

ssh <target> $REMOTE_BINARY

）。始终使用完整的二进制文件路径，绝不要使用PATH中的
archon
，以明确测试的是哪个二进制文件。

每个测试都应捕获完整的命令输出用于最终报告。如果某个测试失败，继续执行下一个测试（以便报告完整），但将整体结果标记为FAIL。

Test 1 — Version reports correctly

测试1 — 版本报告正确

bash

"$BINARY" version

Pass criteria:

Exit code 0
Output contains
```
Archon CLI v<expected-version>
```
Output contains
```
Build: binary
```
(not
```
Build: source (bun)
```
)
Output contains a non-
```
unknown
```
git commit (i.e.,
```
Git commit: <sha>
```
)

Common failures:

Exit code non-zero → pino-pretty crash (#960) or similar startup failure
Wrong version reported → binary is stale or the build script failed to update
```
bundled-build.ts
```
```
Build: source (bun)
```
→
```
BUNDLED_IS_BINARY
```
was not set to
```
true
```
during the build (regression of #979)
```
Git commit: unknown
```
→ build script did not capture the commit

bash

"$BINARY" version

通过标准：

退出码为0
输出包含
```
Archon CLI v<expected-version>
```
输出包含
```
Build: binary
```
（而非
```
Build: source (bun)
```
）
输出包含非
```
unknown
```
的git提交（即
```
Git commit: <sha>
```
）

常见失败情况：

退出码非零 → pino-pretty崩溃（#960）或类似启动失败
报告版本错误 → 二进制文件过时或构建脚本未能更新
```
bundled-build.ts
```
```
Build: source (bun)
```
→ 构建期间
```
BUNDLED_IS_BINARY
```
未设置为
```
true
```
（#979的回归）
```
Git commit: unknown
```
→ 构建脚本未捕获提交信息

Test 2 — Bundled workflows load

测试2 — 内置工作流可加载

Create a temporary git repository so the CLI has something to operate on:

bash

TESTREPO=/tmp/archon-test-repo-$(date +%s)
mkdir -p "$TESTREPO"
cd "$TESTREPO"
git init -q
git commit -q --allow-empty -m init
"$BINARY" workflow list

Pass criteria:

Exit code 0
Output lists at least 20 bundled workflows (archon-assist, archon-fix-github-issue, archon-comprehensive-pr-review, etc.)
No errors about missing workflow files or JSON parse failures

Common failures:

Empty list → bundled defaults were not embedded in the binary (regression of the
```
isBinaryBuild
```
detection path)
```
Not in a git repository
```
→ working directory handling bug
Parse errors → the embedded JSON is corrupt or stale

创建临时git仓库供CLI操作：

bash

TESTREPO=/tmp/archon-test-repo-$(date +%s)
mkdir -p "$TESTREPO"
cd "$TESTREPO"
git init -q
git commit -q --allow-empty -m init
"$BINARY" workflow list

通过标准：

退出码为0
输出列出至少20个内置工作流（archon-assist、archon-fix-github-issue、archon-comprehensive-pr-review等）
无缺失工作流文件或JSON解析失败的错误

常见失败情况：

列表为空 → 内置默认值未嵌入二进制文件（
```
isBinaryBuild
```
检测路径的回归）
```
Not in a git repository
```
→ 工作目录处理bug
解析错误 → 嵌入的JSON损坏或过时

Test 3 — SDK path works (assist workflow)

测试3 — SDK路径正常工作（assist工作流）

Prerequisite. Compiled binaries require Claude Code installed on the host and a configured binary path. Before running this test, ensure one of:

bash

undefined

先决条件。编译后的二进制文件要求主机上已安装Claude Code并配置了二进制路径。运行此测试前，确保满足以下任一条件：

bash

undefined

Option A — env var (easy for ad-hoc testing)

选项A — 环境变量（适用于临时测试）

After the native installer (Anthropic's default):

原生安装程序（Anthropic默认）后：

export CLAUDE_BIN_PATH="$HOME/.local/bin/claude"

Or after npm global install:

或npm全局安装后：

export CLAUDE_BIN_PATH="$(npm root -g)/@anthropic-ai/claude-code/cli.js"

Option B — config file (persistent)

选项B — 配置文件（持久化）

Add to ~/.archon/config.yaml:

添加到~/.archon/config.yaml：

assistants:

claude:

claudeBinaryPath: /absolute/path/to/claude


Then in the same `$TESTREPO`:

```bash
"$BINARY" workflow run assist "say hello and nothing else" 2>&1 | tee /tmp/archon-test-assist.log

Pass criteria:

Exit code 0
The Claude subprocess spawns successfully (no
```
spawn EACCES
```
,
```
ENOENT
```
, or
```
process exited with code 1
```
in the early output)
No
```
Claude Code CLI not found
```
error (that means the resolver rejected the configured path — verify the cli.js actually exists)
A response is produced (any response — even just "hello" — proves the SDK round-trip works)

Common failures:

```
Claude Code not found
```
→
```
CLAUDE_BIN_PATH
```
/
```
claudeBinaryPath
```
is unset or points at a non-existent file. Fix the path and re-run.
```
Module not found "/Users/runner/..."
```
→ regression of #1210: the resolver was bypassed and the SDK's
```
import.meta.url
```
fallback leaked a build-host path. Investigate
```
packages/providers/src/claude/provider.ts
```
and the resolver.

Credit balance is too low

→ auth is pointing at an exhausted API key (check

CLAUDE_USE_GLOBAL_AUTH

and

~/.archon/.env

)

unable to determine transport target for "pino-pretty"

→ #960 regression, binary crashes on TTY

package.json not found (bad installation?)

→ #961 regression,

isBinaryBuild

detection broken

Process exits before producing output → generic spawn failure, capture stderr


然后在同一个`$TESTREPO`中：

```bash
"$BINARY" workflow run assist "say hello and nothing else" 2>&1 | tee /tmp/archon-test-assist.log

通过标准：

退出码为0
Claude子进程成功启动（早期输出中无
```
spawn EACCES
```
、
```
ENOENT
```
或
```
process exited with code 1
```
）
无
```
Claude Code CLI not found
```
错误（这意味着解析器拒绝了配置的路径 — 验证cli.js是否确实存在）
生成响应（任何响应 — 即使只是"hello" — 都证明SDK往返流程正常）

常见失败情况：

```
Claude Code not found
```
→
```
CLAUDE_BIN_PATH
```
/
```
claudeBinaryPath
```
未设置或指向不存在的文件。修复路径后重新运行。
```
Module not found "/Users/runner/..."
```
→ #1210的回归：解析器被绕过，SDK的
```
import.meta.url
```
回退暴露了构建主机路径。调查
```
packages/providers/src/claude/provider.ts
```
和解析器。

Credit balance is too low

→ 认证使用的API密钥已耗尽（检查

CLAUDE_USE_GLOBAL_AUTH

和

~/.archon/.env

）

unable to determine transport target for "pino-pretty"

→ #960的回归，二进制文件在TTY上崩溃

package.json not found (bad installation?)

→ #961的回归，

isBinaryBuild

检测失效

进程在生成输出前退出 → 通用启动失败，捕获stderr

Test 3b — Resolver error path (run without

CLAUDE_BIN_PATH

)

测试3b — 解析器错误路径（未设置

CLAUDE_BIN_PATH

时运行）

Quickly verify the resolver fails loud when nothing is configured:

bash

(unset CLAUDE_BIN_PATH; "$BINARY" workflow run assist "hello" 2>&1 | tee /tmp/archon-test-no-path.log)

Pass criteria (when no
~/.archon/config.yaml
configures
claudeBinaryPath
):

Error message contains
```
Claude Code not found
```
Error message mentions both
```
CLAUDE_BIN_PATH
```
and
```
claudeBinaryPath
```
as remediation options
No
```
Module not found
```
stack traces referencing the CI filesystem

If you do have

claudeBinaryPath

set globally, skip this test or temporarily rename

~/.archon/config.yaml

快速验证未配置任何内容时解析器是否会明确报错：

bash

(unset CLAUDE_BIN_PATH; "$BINARY" workflow run assist "hello" 2>&1 | tee /tmp/archon-test-no-path.log)

通过标准（当
~/.archon/config.yaml
未配置
claudeBinaryPath
时）：

错误消息包含
```
Claude Code not found
```
错误消息提及
```
CLAUDE_BIN_PATH
```
和
```
claudeBinaryPath
```
作为修复选项
无引用CI文件系统的
```
Module not found
```
堆栈跟踪

如果你全局设置了

claudeBinaryPath

，请跳过此测试或临时重命名

~/.archon/config.yaml

。

Test 4 — Env-leak gate refuses a leaky .env (optional, for releases including #1036/#1038/#983)

测试4 — 环境变量泄漏拦截器拒绝存在泄漏的.env（可选，针对包含#1036/#1038/#983的版本）

Create a second throwaway repo with a fake sensitive key:

bash

LEAKREPO=/tmp/archon-test-leak-$(date +%s)
mkdir -p "$LEAKREPO"
cd "$LEAKREPO"
git init -q
git commit -q --allow-empty -m init
printf 'ANTHROPIC_API_KEY=sk-ant-test-fake\n' > .env
"$BINARY" workflow run assist "hello" 2>&1 | tee /tmp/archon-test-leak.log

Pass criteria:

The command exits with a non-zero code, OR produces an error message containing
```
Cannot add codebase
```
or
```
Cannot run workflow
```
The error mentions the dangerous key name (
```
ANTHROPIC_API_KEY
```
)
No Claude subprocess was actually spawned (the gate short-circuited)

Common failures:

Command proceeds normally → the env-leak gate is not active (regression of #1036)
Error is generic or unclear → the context-aware error message from #983 has regressed
Gate blocks but with wrong remediation text →
```
formatLeakError
```
context detection is broken

Clean up the leak test repo:

bash

rm -rf "$LEAKREPO"

创建第二个临时仓库，包含伪造的敏感密钥：

bash

LEAKREPO=/tmp/archon-test-leak-$(date +%s)
mkdir -p "$LEAKREPO"
cd "$LEAKREPO"
git init -q
git commit -q --allow-empty -m init
printf 'ANTHROPIC_API_KEY=sk-ant-test-fake\n' > .env
"$BINARY" workflow run assist "hello" 2>&1 | tee /tmp/archon-test-leak.log

通过标准：

命令以非零码退出，或生成包含
```
Cannot add codebase
```
或
```
Cannot run workflow
```
的错误消息
错误提及危险密钥名称（
```
ANTHROPIC_API_KEY
```
）
未实际启动Claude子进程（拦截器已提前终止流程）

常见失败情况：

命令正常执行 → 环境变量泄漏拦截器未激活（#1036的回归）
错误消息通用或不清晰 → #983的上下文感知错误消息出现回归
拦截器触发但修复文本错误 →
```
formatLeakError
```
上下文检测失效

清理泄漏测试仓库：

bash

rm -rf "$LEAKREPO"

Test 5 — Isolation list works (sanity check)

测试5 — 隔离列表正常工作（ sanity检查）

In the same

$TESTREPO

bash

"$BINARY" isolation list

Pass criteria:

Exit code 0
No errors (the list may be empty if no worktrees have been created, which is fine)

This catches regressions in the isolation subsystem that would not surface from the other tests.

在同一个

$TESTREPO

中：

bash

"$BINARY" isolation list

通过标准：

退出码为0
无错误（如果未创建任何工作树，列表为空也正常）

此测试可捕获其他测试未覆盖的隔离子系统回归问题。

Test 6 — Cleanup test repos

测试6 — 清理测试仓库

bash

rm -rf "$TESTREPO"

For

curl-vps

path, also clean up any remote test repos created via SSH.

bash

rm -rf "$TESTREPO"

对于

curl-vps

路径，还需通过SSH清理远程创建的测试仓库。

Phase 5 — Uninstall

阶段5 — 卸载

Always run uninstall, even if Phase 4 failed. The goal is to leave the system in the same state as before the test.

无论阶段4是否失败，始终执行卸载。目标是将系统恢复到测试前的状态。

Path: brew

路径：brew

bash

brew uninstall coleam00/archon/archon
brew untap coleam00/archon

Verify the dev binary is still the default:

bash

which -a archon

bash

brew uninstall coleam00/archon/archon
brew untap coleam00/archon

验证开发二进制文件仍为默认：

bash

which -a archon

should show only the ~/.bun/bin/archon path, not a brew path

应仅显示~/.bun/bin/archon路径，而非brew路径

archon version | head -1

should match the dev version captured in Phase 2

应与阶段2捕获的开发版本匹配


**Restore `archon-stable` if it existed before the test** (dual-homebrew pattern — see Phase 2 item 4):

```bash
if [ -n "$ARCHON_STABLE_WAS_INSTALLED" ]; then
  echo "Restoring archon-stable (detected before test)..."
  brew tap coleam00/archon
  brew install coleam00/archon/archon
  BREW_BIN="$(brew --prefix)/bin"
  if [ -e "$BREW_BIN/archon" ]; then
    mv "$BREW_BIN/archon" "$BREW_BIN/archon-stable"
    echo "archon-stable restored: $(archon-stable version 2>/dev/null | head -1)"
  else
    echo "WARNING: brew install succeeded but $BREW_BIN/archon missing — check formula"
  fi
fi

Note on the restored version: this reinstalls from whatever the tap currently ships, which is typically the release you just tested (so
archon-stable
ends up at the newly-tested version). That's usually what the operator wants — you just verified the new release works, and you want
archon-stable
pointed at it. If you were testing an older version for back-version QA, the restored
archon-stable
will be the current tap formula, not the pre-test version. For that rare case, the operator should re-run
brew-upgrade-archon
manually after the test.


**如果测试前存在`archon-stable`则恢复它**（双Homebrew模式 — 详见阶段2第4项）：

```bash
if [ -n "$ARCHON_STABLE_WAS_INSTALLED" ]; then
  echo "正在恢复archon-stable（测试前已检测到）..."
  brew tap coleam00/archon
  brew install coleam00/archon/archon
  BREW_BIN="$(brew --prefix)/bin"
  if [ -e "$BREW_BIN/archon" ]; then
    mv "$BREW_BIN/archon" "$BREW_BIN/archon-stable"
    echo "archon-stable已恢复: $(archon-stable version 2>/dev/null | head -1)"
  else
    echo "警告：brew安装成功但$BREW_BIN/archon缺失 — 请检查公式"
  fi
fi

关于恢复版本的说明：此操作会从源当前提供的版本重新安装，通常就是你刚测试的版本（因此
archon-stable
会指向新测试的版本）。这通常是操作人员想要的结果 — 你刚验证了新版本正常工作，希望
archon-stable
指向它。如果你是为了旧版本QA测试的是旧版本，恢复后的
archon-stable
将是当前源公式的版本，而非测试前的版本。对于这种罕见情况，操作人员应在测试后手动重新运行
brew-upgrade-archon
。

Path: curl-mac

路径：curl-mac

bash

rm -rf "$INSTALL_DIR"

bash

rm -rf "$INSTALL_DIR"

Path: curl-vps

路径：curl-vps

bash

ssh <target> "sudo rm -f /usr/local/bin/archon || rm -f \$HOME/.local/bin/archon"

Optional: the user may want to LEAVE the VPS binary installed for ongoing QA. Ask before removing.

bash

ssh <target> "sudo rm -f /usr/local/bin/archon || rm -f \$HOME/.local/bin/archon"

可选：用户可能希望保留VPS上的二进制文件用于持续QA。删除前请询问用户。

Phase 6 — Report

阶段6 — 报告

Produce a structured report with:

Header: release version tested, install path, timestamp, SHA256 of the tested binary
Environment: dev binary path + version (proof the dev install was not disturbed)
Test results table: one row per test with PASS / FAIL / SKIP
Captured output: for any FAIL, include the exact command, exit code, and last 20 lines of stderr/stdout
Overall verdict: PASS if all tests passed, FAIL if any test failed
Next steps: if FAIL, suggest concrete actions (file a hotfix issue, re-tag, check the build workflow, etc.)

Example PASS report:

Test Release Report — archon v0.3.1 via brew
────────────────────────────────────────────
Tested at:    2026-04-08 15:42 UTC
Binary SHA:   e62eb73547b3740d56f242859b434a91d3830360a0d18f14de383da0fd7a0be6
Binary path:  /opt/homebrew/Cellar/archon/0.3.1/bin/archon
Dev binary:   /Users/rasmus/.bun/bin/archon → ../install/.../cli.ts (unchanged)

  [PASS]  Test 1  version reports 0.3.1, Build: binary, commit abc1234
  [PASS]  Test 2  workflow list returned 21 bundled workflows
  [PASS]  Test 3  workflow run assist produced output
  [PASS]  Test 4  env-leak gate refused leaky .env with context-aware error
  [PASS]  Test 5  isolation list executed without errors
  [PASS]  Cleanup brew uninstall + untap clean, dev binary unchanged

Overall: PASS

This release is safe to announce. Next steps:
  - Update release notes on GitHub if not done already
  - Announce on whatever channels you use

Example FAIL report:

Test Release Report — archon v0.3.1 via curl-vps
────────────────────────────────────────────────
Tested at:    2026-04-08 15:42 UTC
Binary SHA:   0cf83e15e6af228e3c3473467ca30fa7525b6d7069818d85f97a115ea703d708
Binary path:  user@vps:/usr/local/bin/archon
Dev binary:   /Users/rasmus/.bun/bin/archon (unchanged)

  [PASS]  Test 1  version reports 0.3.1, Build: binary
  [FAIL]  Test 2  workflow list returned 0 workflows

    Command:  archon workflow list
    Exit:     0
    Output:
      Discovering workflows in: /tmp/archon-test-repo-1712590923
      Found 0 workflow(s):

  [SKIP]  Test 3  SDK test skipped because Test 2 failed
  [SKIP]  Test 4  env-leak gate test skipped because Test 2 failed
  [PASS]  Test 5  isolation list executed without errors
  [PASS]  Cleanup VPS binary removed

Overall: FAIL

Likely cause: bundled workflows were not embedded in the binary.
Check the build workflow for missing asset embedding, or verify that
BUNDLED_WORKFLOWS in packages/workflows/src/defaults/bundled-defaults.ts
was populated at build time.

Next steps:
  1. File a P0 hotfix issue with the captured output
  2. Do NOT announce v0.3.1 until the hotfix ships as v0.3.2
  3. Consider adding a CI guard that blocks releases if BUNDLED_WORKFLOWS is empty

生成结构化报告，包含：

标题：测试的版本、安装路径、时间戳、测试二进制文件的SHA256
环境：开发二进制文件路径+版本（证明开发环境未被干扰）
测试结果表：每个测试一行，标记PASS / FAIL / SKIP
捕获的输出：对于任何FAIL，包含确切命令、退出码和stderr/stdout的最后20行
整体结论：所有测试通过则为PASS，任何测试失败则为FAIL
下一步操作：如果FAIL，建议具体操作（提交热修复issue、重新打标签、检查构建工作流等）

示例PASS报告：

发布版本测试报告 — archon v0.3.1 via brew
────────────────────────────────────────────
测试时间：    2026-04-08 15:42 UTC
二进制SHA：   e62eb73547b3740d56f242859b434a91d3830360a0d18f14de383da0fd7a0be6
二进制路径：  /opt/homebrew/Cellar/archon/0.3.1/bin/archon
开发二进制：   /Users/rasmus/.bun/bin/archon → ../install/.../cli.ts（未变更）

  [PASS]  测试1  版本报告0.3.1，Build: binary，提交abc1234
  [PASS]  测试2  工作流列表返回21个内置工作流
  [PASS]  测试3  workflow run assist生成输出
  [PASS]  测试4  环境变量泄漏拦截器拒绝存在泄漏的.env并给出上下文感知错误
  [PASS]  测试5  isolation list执行无错误
  [PASS]  清理  brew卸载+untap完成，开发二进制未变更

整体结论：PASS

此版本可安全发布。下一步操作：
  - 若尚未完成，更新GitHub上的版本说明
  - 在你使用的渠道发布公告

示例FAIL报告：

发布版本测试报告 — archon v0.3.1 via curl-vps
────────────────────────────────────────────────
测试时间：    2026-04-08 15:42 UTC
二进制SHA：   0cf83e15e6af228e3c3473467ca30fa7525b6d7069818d85f97a115ea703d708
二进制路径：  user@vps:/usr/local/bin/archon
开发二进制：   /Users/rasmus/.bun/bin/archon（未变更）

  [PASS]  测试1  版本报告0.3.1，Build: binary
  [FAIL]  测试2  工作流列表返回0个工作流

    命令：  archon workflow list
    退出码：     0
    输出：
      Discovering workflows in: /tmp/archon-test-repo-1712590923
      Found 0 workflow(s):

  [SKIP]  测试3  SDK测试因测试2失败而跳过
  [SKIP]  测试4  环境变量泄漏拦截器测试因测试2失败而跳过
  [PASS]  测试5  isolation list执行无错误
  [PASS]  清理  VPS二进制文件已删除

整体结论：FAIL

可能原因：内置工作流未嵌入二进制文件。
检查构建工作流是否缺失资产嵌入，或验证构建时packages/workflows/src/defaults/bundled-defaults.ts中的BUNDLED_WORKFLOWS是否已填充。

下一步操作：
  1. 提交包含捕获输出的P0热修复issue
  2. 在热修复发布为v0.3.2前，请勿发布v0.3.1
  3. 考虑添加CI防护措施，若BUNDLED_WORKFLOWS为空则阻止发布

Key behaviors

核心行为

Never touch the dev
bun link
binary. Always use the installed binary path for Phase 4 tests. Verify before and after.
Clean up on failure. If Phase 4 fails mid-way, still run Phase 5 so the next run starts clean.
Capture SHA256 immediately after install. This lets bug reports reference the exact artifact under test.
Explicit confirmation before install. Never surprise the user by installing a second binary.
Report the dev binary state in both preamble and postamble. Proof that the test did not disturb the dev environment.
Exit non-zero if any test failed. The skill should propagate failure so automated wrappers (CI, scripts) can detect it.

绝不触碰开发环境的
bun link
二进制文件。阶段4测试始终使用安装的二进制文件路径。前后都要验证。
失败时仍需清理。如果阶段4中途失败，仍需运行阶段5以便下次运行时环境干净。
安装后立即捕获SHA256。这可让bug报告引用我们测试的确切工件。
安装前需明确确认。绝不要通过安装第二个二进制文件给用户带来意外。
在报告开头和结尾都提及开发二进制文件状态。证明测试未干扰开发环境。
任何测试失败则返回非零退出码。技能应传播失败状态，以便自动化包装器（CI、脚本）能够检测到。

test-release

Original

Translation

Test Release

发布版本测试

Local build for pre-release QA

预发布QA的本地构建

Multi-target mode (builds all 4 local platforms into dist/binaries/)

多目标模式（将所有4个本地平台构建到dist/binaries/）

Single-target mode (matches one CI matrix job)

单目标模式（匹配一个CI矩阵任务）

Verify the binary — use the path from the mode you built:

验证二进制文件 — 使用你构建时选择的模式对应的路径：

multi-target → ./dist/binaries/archon-darwin-arm64

多目标 → ./dist/binaries/archon-darwin-arm64

single-target → the OUTFILE you passed above

单目标 → 你传入的OUTFILE路径

Expected: Archon CLI v0.3.1, Build: binary, Git commit: abc12345

预期输出：Archon CLI v0.3.1, Build: binary, Git commit: abc12345

Phase 1 — Determine scope

阶段1 — 确定范围

Phase 2 — Pre-flight

阶段2 — 预检

Phase 3 — Install

阶段3 — 安装

Path: brew

路径：brew

Path: curl-mac

路径：curl-mac

Path: curl-vps

路径：curl-vps

Capture SHA256 and version

捕获SHA256与版本

Local paths (brew / curl-mac)

本地路径（brew / curl-mac）

Remote path (curl-vps)

远程路径（curl-vps）

Phase 4 — Smoke tests

阶段4 — 冒烟测试

Test 1 — Version reports correctly

测试1 — 版本报告正确

Test 2 — Bundled workflows load

测试2 — 内置工作流可加载

Test 3 — SDK path works (assist workflow)

测试3 — SDK路径正常工作（assist工作流）

Option A — env var (easy for ad-hoc testing)

选项A — 环境变量（适用于临时测试）

After the native installer (Anthropic's default):

原生安装程序（Anthropic默认）后：

Or after npm global install:

或npm全局安装后：

Option B — config file (persistent)

选项B — 配置文件（持久化）

Add to ~/.archon/config.yaml:

添加到~/.archon/config.yaml：

assistants:

assistants:

claude:

claude:

claudeBinaryPath: /absolute/path/to/claude

claudeBinaryPath: /absolute/path/to/claude

Test 3b — Resolver error path (run without CLAUDE_BIN_PATH)

测试3b — 解析器错误路径（未设置CLAUDE_BIN_PATH时运行）

Test 4 — Env-leak gate refuses a leaky .env (optional, for releases including #1036/#1038/#983)

测试4 — 环境变量泄漏拦截器拒绝存在泄漏的.env（可选，针对包含#1036/#1038/#983的版本）

Test 5 — Isolation list works (sanity check)

测试5 — 隔离列表正常工作（ sanity检查）

Test 6 — Cleanup test repos

测试6 — 清理测试仓库

Phase 5 — Uninstall

阶段5 — 卸载

Path: brew

路径：brew

should show only the ~/.bun/bin/archon path, not a brew path

应仅显示~/.bun/bin/archon路径，而非brew路径

should match the dev version captured in Phase 2

应与阶段2捕获的开发版本匹配

Path: curl-mac

路径：curl-mac

Path: curl-vps

Test 3b — Resolver error path (run without
`CLAUDE_BIN_PATH`
)

测试3b — 解析器错误路径（未设置
`CLAUDE_BIN_PATH`
时运行）