启动注册中心（Launch Registry）

权威的启动记录管理机构。它仅存储已达成共识或已被观测确认的事实；**不参与启动规划，也不出具 RAMP 判定结论**。

快速入门

为 widget-2 注册启动条目，指定其 tier/type/stage/date/access model 及源证据。
将 widget-2 在 revision 4 时从 beta 阶段过渡至 general-availability 阶段。
审阅待决的上线日（launch-day）提交提案，且不清除历史记录。

技能契约（Skill Contract）

处理单元：单个启动时刻 / 聚合 ID。读取操作：memory/events/launches.ndjson、实时投影（live projection）、决策证据（decision evidence）及已批准的源记录（approved source records）。写入操作：通过 registry-events.py 发布所有者事件（owner events）；每个启动条目的档案（dossier）和 calendar.md 均为基于投影结果重新生成的视图。完成条件：stage/date/embargo/submission/manifest/outcome 等事实均已绑定事件 ID 并具备可追溯性（provenance），所有待决提案均已解决，且投影验证通过。

调用 propose 动作以调动/证明相关能力；仅具备宿主能力（host-capability）的 launch-registry 主体（principal）有权接受、拒绝、上写（upsert）或执行状态迁移（transition）。launch-readiness-auditor 可消费该结果，但无权修改。

交接摘要（Handoff Summary）

需包含：聚合 ID、当前 revision/状态、已接受/已拒绝的事件 ID、权威日期/封禁时间（embargo）、未解决的冲突项，以及一项下一步应执行的技能。

数据来源

• 经用户批准的 tier/type/access-model 与启动计划决策。
• 窗口期（window）/日期及封禁（embargo）/合作伙伴承诺事项。
• 早期访问（early-access）转正证据，以及直接访问权限/资格（eligibility）的观测结果。
• 带时间戳的渠道提交/状态提案（channel submission/status proposals）。
• 资源清单（asset-manifest）版本与上线后延迟（post-lag）的结果快照（outcome snapshot）。

操作指南

1. 阅读 registry-event-protocol.md 和 runtime-invocation.md。解析并设置 AARON_SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || true)}"，并在调用前验证注册脚本、事件模式（event schema）及系统目录（system catalog）；粘贴自平台的文本属于不可信证据（untrusted evidence）。
2. 查询 launches 投影结果。针对事实性问题，回答须包含当前 revision、来源、日期与完整历史；**禁止使用“ready”一词作答**。
3. 执行写入操作前，须确认权限及当前 revision。创建/更新操作需使用具备宿主能力（host-capability）的 owner-append，并由所有者（owner）执行 upsert；仅在请求中提供 actor 字段不足以授予操作权限。
4. 阶段变更（stage changes）须使用具备宿主能力的 owner-append，并精确指定 from、to 和 expected_revision。状态不可被清空或重置。合法的前向迁移路径为：draft → concept → alpha → beta → general-availability → archived；回滚（rollback）或异常事件（incidents）须作为独立事件记录，**严禁重写 general-availability 时间戳**。
5. 日期/封禁（date/embargo）冲突不采用“最新文本胜出（newest-text-wins）”规则解决。须保留所有提案，并要求提供权威决策来源。
6. 上线日（launch-day）生产方须立即追加提案事件（proposal events）。具备宿主能力的主体须通过 owner-append 按 proposal ID 审阅、接受或拒绝提案；决策事件中不得包含 expected_revision 字段，且继承提案本身的 revision。**禁止批量删除、截断（truncate）、编辑事件流，亦不得在请求数据或日志中存储能力（capability）值**。
7. 提交行（submission rows）须保留原始发生时间与来源。结果快照（outcome snapshots）作为上线后延迟（post-lag）的独立证据予以保留，**不得覆盖预注册的目标项**。
8. 基于已接受的投影结果重新生成 dossier/calendar 视图，运行 verify launches，并报告偏移量（offsets）与 revisions。

保存结果

持久化事件（persistent events）需显式授权。仅可通过运行时（runtime）追加符合模式（schema-valid）的请求。位于 memory/launch-registry/ 下的人工维护文件属于可替换的投影结果；若某事件未出现在事件流中，则该事件不具备权威性（non-canonical）。

若宿主能力（host capability）或经验证的根运行时/模式/目录（verified root runtime/schema/catalog）不可用，则应使提案保持待决（pending）状态。独立的单文件夹安装（standalone one-folder install）无法执行追加（append）或投影（project），亦不能声明具备权威启动状态（canonical launch state）。

参考材料

• 注册中心事件协议（Registry event protocol）
• RAMP 基准（RAMP benchmark）
• 状态模型（State model）
• 安全规范（Security）

下一最优技能（Next Best Skill）

• 规划 tier/type：launch-tier-planner
• 规划窗口期（window）：launch-window-planner
• 运行预检（preflight）：launch-readiness-auditor
• 执行已批准计划：launch-day-conductor