技能介绍

解决发布状态的混沌状态

在复杂的发布流程中，团队常面临一个痛点：事实与计划混淆。开发团队可能在文档、聊天和各类看板中记录了海量信息，但当需要回答“当前确切的 GA（正式发布）时间是什么”或“当初定的 Embargo（禁发）约束是否生效”时，往往找不到唯一的权威来源。Launch Registry 旨在成为发布决策与观察事实的唯一权威台账。

它专注于记录“已决定”和“已观测”的事实，而非参与发布计划的制定或审批（RAMP）。该技能通过 registry-events.py 将每一次状态变更都转化为带有来源证明（Provenance）的事件流，确保所有发布记录具备可追溯性。

核心机制与操作

该技能的核心在于基于事件溯源的状态管理，主要包含以下能力：

只增不改的事件流：系统不直接覆盖历史，所有变更均通过 owner-append 写入新事件。例如，一旦进入 general-availability 阶段，该时间戳即不可被修改，回滚或事故只能作为新的事件记录在案。
严格的状态流转：发布阶段遵循 draft → concept → alpha → beta → general-availability → archived 的正向路径。技能在每次状态转换（Transition）时都会校验 expected_revision，防止并发修改导致的状态丢失。
提案与决策分离：对于发布当天的请求，技能要求先将“提案”（Proposal）事件追加到流中，随后由具备 Host Capability 的权威角色进行审核（Accept/Reject），从而在数据层面实现了权责分离。
视图自动生成：Dossier（档案）和 Calendar（日历）等文件并非存储介质，而是从权威事件流中动态生成的派生视图。

适用边界与注意事项

该技能依赖特定的运行环境和规范：

强依赖运行时：必须验证 registry 脚本、事件 Schema 和系统目录。如果宿主环境缺乏必要的 Capability 或无法验证根目录，技能会将提案保留为 pending 状态，拒绝写入。
无权自赋：仅在请求参数中填充 actor 字段无法获得写入权限，必须由具备 host-capability 的 Principal 角色完成权限授予。
禁止合并或删除：严禁批量删除、截断或编辑事件流。任何试图篡改事件顺序或重写历史记录的行为都是不被允许的。