[Priority: Low] [Ops] 明确当前项目的版本管理与发布策略（main/tag/release/commit）

[liujuanjuan1984]

背景

当前项目已经具备自部署与运维脚本，但对于“对外推荐用户安装哪一版源码 / 哪一种版本标识”还没有形成明确、统一的策略。

当前 scripts/init_system.sh 在主机 bootstrap 时默认 clone main，这只是该问题的一个表象。更底层的问题是：当前项目自身的版本管理与发布策略还没有明确沉淀为“给自部署用户信任哪一个版本边界”的统一规则。

这不是单一脚本问题，而是会影响多个面：

• bootstrap / init
• deploy / update / rollback
• 文档中的自部署推荐入口
• 安装可复现性与安全审计

问题描述

当前仓库缺少一条明确结论：

• 自部署用户默认应跟随 main、固定 commit、固定 tag，还是正式 release
• 开发者路径与对外推荐路径是否应区分
• 版本更新、回滚、问题回溯时应以什么版本标识为准

当前行为

• init_system.sh 默认 checkout main
• 部署文档默认围绕“当前仓库源码”展开，但没有统一声明推荐版本入口
• 不同时间执行 bootstrap / 自部署，可能得到不同源码快照

期望行为

• 明确当前项目的版本管理与发布策略
• 明确“开发使用”和“对外自部署推荐”分别应采用什么版本入口
• 明确相关脚本和文档应如何收口到同一版本策略

范围

1. 明确版本策略
   • main 的角色
   • tag 的角色
   • release 的角色
   • commit 在审计/回滚中的角色
2. 明确自部署推荐策略
   • 对外文档默认推荐哪个版本入口
   • 哪些场景允许继续直接使用 main
3. 明确受影响的实现与文档面
   • scripts/init_system.sh
   • scripts/init_system_readme.md
   • docs/agent_deploy_sop.md
   • 其它引用默认安装入口的文档/脚本
4. 必要时给出最小实现建议
   • 是否引入默认 tag / release 变量
   • 是否调整 bootstrap / update 的默认行为

非目标

• 不在本 issue 内处理 Node.js / uv / OpenCode installer 的供应链脚本风险（这些属于 #149）
• 不在本 issue 内重构完整 CI/CD 或 release automation
• 不扩展到 Docker / 多实例编排策略

验收标准

• 给出明确结论：当前项目推荐的版本与发布策略是什么
• 明确自部署用户默认应信任哪种版本入口，以及原因
• 明确 main / tag / release / commit 的适用边界
• 明确需要同步调整的脚本与文档面

关联

• Relates to [Priority: High] [Feature] 支持消费方按需自部署 opencode-a2a-server（参数化拉起） #145
• Relates to [Priority: Low] [Security] 加固 init_system 供应链安全基线（脚本安装链路） #149

参考快照

• repo HEAD: 7173d6b

[liujuanjuan1984]

本次已明确采用以下版本策略：

• 继续以 main 作为唯一开发主线，不引入长期维护的发布分支
• 外部可用版本不再默认信任 main，而是以 git tag / GitHub Release 作为正式版本入口
• main 仅承担持续集成与日常开发角色
• tag 作为不可变版本锚点，用于发布、回滚与审计
• release 作为对外推荐入口，对应用户安装与部署时默认应信任的版本
• commit 仅作为最低层问题追溯与审计标识，不作为普通用户默认入口

基于这条策略，后续实现会收敛为：

1. 不再采用“每次发布前单独 bump 版本号并提交到主干”的方式
2. 改用 tag 派生版本号，避免为发布制造额外主干提交
3. init_system / 部署相关实现后续应从“默认 main”逐步收口到“默认 release/tag 对应版本”

当前已在分支 ops/issues-178-188-release-strategy-eval 上开始落实相关实现。