release-validation

name	release-validation
description	Validates release readiness with related bun tests, make release-check, current-binary scripted tmux interactions, and release/docs consistency. Use before declaring a release ready or for release validation, 发布验收, release-check, binary-side verification, README/CHANGELOG accuracy, or a final release gate.
version	0.1.0

Release Validation

为当前 Claude Code 工作区执行不可拆分的四路发布门禁。该流程用于发布结论，不以单个测试、单次构建或一次手工交互替代完整验收。

强制规则

1. 开始前读取 CLAUDE.md、Makefile、相关 diff，并运行 scripts/capture-release-baseline.py 动态记录当前 HEAD、分支、Git 状态、版本和 binary 信息。Agent brief 只能引用本轮 baseline 文件，禁止手写或沿用上一轮 commit/hash。
2. Binary interaction 必须使用 scripts/run-binary-gate.py。该脚本先执行独立 readiness smoke，只有 smoke 通过才串行启动完整交互矩阵；readiness 失败时停止，不得继续 fan-out 或把 driver/fixture 错误归因于产品 runtime。
3. 使用一条消息并行启动四个独立 Agent；每个 Agent 必须明确写明 只读验证，不得修改源码、测试、文档、配置、版本或提交。允许验证命令生成必要的 binary、日志、tmux evidence 和临时 config root，但必须报告路径与 Git side effects。
4. 四路职责不得互相替代：
   • Feature tests：确认 feature 契约和相关 bun test 通过，检查测试是否覆盖关键状态矩阵。
   • Release checks：运行并核对 make release-check 的全部阶段。
   • Binary interaction：本轮 make build 后，用脚本驱动 tmux 验证 built-claude；交互场景必须覆盖本次改动、直接受影响的 runtime 入口和相邻组件，通用启动 smoke test 不算 feature 交互验收。
   • Release/docs audit：检查版本、release 范围、README、CHANGELOG、Makefile 与实际代码和验证证据一致。
5. Feature 验收是不可拆分的组合门禁：无论改动是否直接用户可见，相关 bun test 和本轮 built-claude 中所有受影响交互流程的 scripted tmux 验收必须同时 。内部改动必须通过其真实调用入口触发，并检查相邻组件和副作用；任一失败、仍在运行或证据不足，feature 均不得判定为通过。单测与交互证据不能互相替代。