测试与正式环境
本页帮助执行者选择测试或正式运行面，并在部署前核对隔离与 owning operation。具体拓扑、地址、命令和当前 readiness 由 owning runtime 与运维 evidence 管理。
何时使用
- 任务需要把 Harbor 封存的 release 通过 GitOps 部署到 TEST 或 PRODUCTION、重启或 migration，需要选择目标环境时。
- 部署可能触碰正式数据、正式 issue 或正式 worker，需要确认隔离时。
- 确认 owning Project 的工程授权、部署边界与外部 CI 路由时。
开始前
- 固定待部署的 release version、tag、commit、pipeline、Harbor bundle digest、六组件 digests、目标环境与 rollback 条件。
- 确认环境 owner、可用的部署 workflow 和 owning Project 授权；AutoDev 开发沿用自主执行授权，不增加确认门。
- 若部署 Symphony，确认官方版本、Tracker、项目 WORKFLOW、仓库范围、独立工作目录和必要业务凭据；旧 Coordinator/Worker 不作为备用执行入口。
- 先读取当前 readiness 和 deployment evidence，不用文档中的历史描述代替运行事实。
- 确认 Harbor evidence bundle 已通过 checksums、manifest 与组件 digest 验证；TEST 运行观察和专用业务验收通过后才推进 PRODUCTION。
按序操作
先按任务目的选择环境：
| 选择 | 主要用途 | 进入前提 | 完成证据 |
|---|---|---|---|
| 测试环境 | 部署版本化 Harbor release、验证 health 与功能 | 已封存 release identity、TEST desired state、适用的测试授权 | GitOps MR、Argo sync/health、observed exact digests、隔离证明 |
| 正式环境 | 承载已在 TEST 验证的同一 release | TEST observer 与业务验收通过、PRODUCTION MR CI 通过、可用 rollback | merged GitOps MR、Argo sync/health、availability/version/image evidence |
然后按顺序核对：
- 确认所选环境与任务目的匹配，不用正式环境替代尚未完成的 TEST 验证。
- 核对隔离清单：GitOps environment path、runtime、credential、日志和观测证据均不得跨环境复用。
- 确认目标 release 来自 Harbor 中 exact digest 的 evidence bundle 与六组件镜像；TEST/PRODUCTION 使用独立 desired-state path、namespace、runtime secrets 与 Argo CD Application，不共享可写 truth。
- 核对 Symphony 发布源、项目绑定、WORKFLOW、工作目录和私密凭据配置；配置生成不代表服务部署或实际运行成功。
- 由 owning source / 外部 CI 执行 activation、workflow 或权限配置；遵守当前 Project 授权，不能由运行于服务内部的 worker 替换自己的宿主。
- TEST 由 protected-tag pipeline 生成并合并 exact GitOps MR head，Argo CD 从
master协调plane-test；availability/version/image observation 只证明 deployment identity，不构成功能验收。 - TEST 部署后由 observer 核对 Argo sync/health、migration、workloads、exact image digests 和 endpoint，专用 TEST runner 完成业务验收。
- TEST 两项门禁通过后，tag pipeline 创建复制 TEST exact digests 的 PRODUCTION MR；分支 CI 通过后合并 exact head，由 Argo CD 协调
plane-production，不 rebuild、不 retag、不使用 latest。 - 记录环境、release identity、GitOps MR head、Argo/runtime observation、rollback verdict 和剩余风险。
CI 执行环境与共享边界
跨仓库共享池按基础环境、权限身份和实际资源划分，不按项目名称复制环境。各项目既有保底 Runner 独立保留，其注册、标签、绑定和并发不随共享池归并而改变。共享容量不替代保底容量； 同一宿主的多个注册不代表新增算力。实际成员、可用槽位、项目绑定与运行证据由受审阅基础设施 来源和 GitLab 管理，不在本页维护注册数量或在线状态。
| 执行身份／环境 | 跨仓库接单边界 |
|---|---|
| 普通原生 macOS | 使用独立非管理员 CI 身份，提供 Git、Shell、固定 Node 和 Python 工具链；autodev-macos-short 接轻量检查，autodev-macos-general 接依赖安装和完整构建。没有生产目录、个人 Keychain 或宿主服务维护权限。 |
| 受保护 macOS 发布 | autodev-macos-publish 仅绑定经审阅的发布仓库并接受保护分支任务；当前文档与插件发布身份限定于既有发布宿主 192.168.8.91。普通分支不得借发布池运行检查。 |
| 宿主 owner 运维 | 只服务对应宿主的受审阅持续运维入口，由外部控制面执行服务替换与观察；业务进程及其 worker 不维护自己的宿主。 |
| Unity、GUI、Keychain、模拟器或容器附加环境 | 分别声明 Editor 版本、许可证、交互会话、凭据身份、独占设备和容器边界。基础工具链相同不代表权限或资源可互换；仅在这些约束一致的仓库间共享。 |
文档流水线在所有分支上使用普通检查／构建环境，Node 24.14.1 从固定 PATH 提供，不初始化
宿主 NVM。部署脚本的轻量检查走 short；导航和站点构建走 general。受保护 master 的完整
生产构建仍启用 minification 和既有体验检查；以 2 GiB Node heap 顺序编译 client/server，随后
用 Python 3.12 写入精确 commit、pipeline 与内容摘要的 release metadata，上传完整生产 artifact。
这些准备工作不访问生产目录。只有最终 publication 使用保护发布身份，在既有宿主对 artifact
核验后发布；保留目录锁、不可变 release、原子 current 切换、页面 smoke、失败回滚与历史保留。
一次性安装、迁移或注册切换完成后，删除其操作入口、失效标签及旧注册，不保留长期过渡路由。 后续持续升级若仍有需求，归入受审阅 owner 运维合同；历史交付证据和重要数据保留。
完成标准
- 目标环境选择与任务目的匹配，隔离项逐项可证明。
- activation 由正确 owner/workflow 执行，符合当前 Project 的目标环境与授权范围。
- Symphony 有可追溯的源码、项目配置、外部 CI 和运行观察；源码、配置、凭据和实际启动分别提供证据。
- TEST 与 PRODUCTION 使用独立 desired-state path、namespace、secrets 与 Argo application，不共享可写 release truth。
- PRODUCTION 使用同一 Harbor bundle 与六组件 digests；availability/version/image 只作部署证据。
- 失败时有明确 rollback verdict，没有把未验证环境宣布为 ready。
阻塞、升级与停止
- 任一关键隔离项无法证明时停止 activation，交给环境 owner 修复或补证。
- bundle identity、环境 profile 或 owning operation 不清楚时报告具体缺口，不执行"先试一下"的正式动作。
- TEST 未部署或 health 未 passed 就部署 PROD：停止。
- AutoDev 工程所需 credential、permission、webhook、workflow 或 production activation 按 Project Workspace 自主授权执行；实际访问不足须具体说明。
- 部署和凭据遵循 owning Project 的授权范围；Issue 开关只授予任务执行，不能自行扩大项目或基础设施权限。
- owning workflow 不可用时先记录 blocker；不存在 Go 或本地手工 activation fallback。
Plane 钉钉业务通知
Plane 使用工作区级钉钉企业应用向成员发送一对一机器人私聊。首期只覆盖工作项新增指派，以及描述或评论中的新增提及；不包含群机器人、互动卡片、已读回执、OAuth 或 Automation 事件。
生效条件
一次投递只有同时满足下列条件才会发送：
- 运行环境的全局开关
PLANE_DINGTALK_NOTIFICATIONS_ENABLED=1； - 工作区连接处于
active，且健康、权限、可见范围均为 ready； - 项目管理员启用了对应的“指派”或“提及”规则；
- 接收人是当前有效的工作区和项目成员，账号有效且不是机器人；
- 接收人开启个人钉钉投递偏好，并持有当前连接代次的有效绑定；
- 发送前复核仍与该指派或提及相关。
任何一项不满足都会以脱敏原因抑制或取消，不会降级为不受控的群消息。免打扰时段内的消息延迟到窗口结束。
启用顺序
- 平台运维在目标环境创建独立的 Kubernetes Secret：一个 32 字节身份加密密钥，一个包含钉钉应用 Secret 的键值 Secret。Secret 值不得进入 Git、Plane 数据库或浏览器。
- 在该环境的 Helm values 中启用
notificationSecrets，配置 Secret 名称和身份密钥键名；API 与 worker 只读挂载到/run/secrets/plane/。 - 保持全局开关关闭，工作区管理员填写企业 ID、Client ID、机器人编码和 Secret 文件键名。
- 使用管理员控制且明确授权的中国大陆企业手机号完成目录、成员读取、机器人私聊和应用可见范围检查，并确认测试消息已到达。
- 成员提交手机号绑定申请；管理员核对实时企业身份并批准。Plane 只保留加密身份和脱敏提示。
- 在 TEST 项目分别启用指派、提及规则，成员开启个人钉钉投递偏好。
- 通过受审 GitOps 变更在 TEST 打开全局开关，再由管理员激活工作区连接。
- 验证新增指派、描述提及、评论提及、免打扰延迟、成员移除、解绑和停用。验收必须记录确切 release、环境、接收账号、事件 ID、delivery ID、时间和结果，不记录消息正文或外部身份。
- 只有同一 release 在 TEST 通过适用验收后，才能经 owning release workflow 推进 PRODUCTION；AutoDev 工程任务不另增部署批准门，成员身份与业务连接仍遵循产品授权。
可靠性、诊断与回退
事件、outbox 与业务活动在同一事务提交。路由与投递使用租约抢占和幂等 delivery 身份。连接失败、限流等明确可安全重试的结果采用有上限的指数退避；读取超时、响应不可解析或钉钉返回系统错误等结果记为 outcome_unknown，禁止自动重发，以避免重复消息。
工作区设置的“投递诊断”只显示状态计数、最早待处理时间，以及 delivery/event ID、失败代码、尝试次数和时间。不得展示消息正文、手机号、钉钉 userId、token、Secret、原始请求或响应。
常用停止条件：
global_kill_switch_disabled：环境开关关闭；connection_not_active/connection_not_ready：工作区未激活或就绪门失败；project_rule_disabled：项目规则关闭；recipient_opted_out/binding_unavailable：个人偏好或绑定不满足；recipient_irrelevant：发送前复核发现关系已失效；outcome_unknown：人工核对钉钉后决定是否另建新业务事件，不重放旧 delivery。
回退时优先在工作区设置中停用连接；若影响跨工作区或钉钉异常，先通过受审配置变更关闭全局开关。两者都不会删除审计、事件或投递证据。不要删除绑定、清空队列或改写终态作为回退手段。恢复前必须重新验证连接健康、权限和可见范围，并处理所有 outcome_unknown。
代码合入、TEST 部署、Secret 创建、钉钉应用权限/可见范围变更、工作区激活、PRODUCTION 配置和正式激活是不同动作。各动作由 owning surface 执行；工程授权来自当前 Project Workspace，本文不增加确认门或改变产品用户的授权合同。