插件与扩展平台演练

本文演示一个以命令入口、配置项、宿主集成点和安装路径为核心的插件 / 扩展仓库，如何从需求澄清、兼容性约束到验证收口完整跑通。

1. 场景

• 仓库当前主要维护 extension / plugin、命令、配置项和安装说明
• 团队准备新增一个宿主命令入口，并同步补齐配置、兼容矩阵和安装路径
• 目标不是开发独立业务功能，而是把扩展点和安装链路治理成可验证、可发布、可回退的状态

2. 推荐链路

1. /team-intake
2. /team-plan
3. /tdd
4. /team-execute
5. /verify
6. /team-review

3. 第一步：/team-intake

输入示例

/team-intake
目标：为插件仓库新增命令入口并补齐安装、配置与兼容性说明
范围：命令、配置项、集成点、安装文档、测试计划
不做：无关业务服务改造
约束：必须说明宿主版本边界、升级路径、禁用态和失败回退行为

期望输出重点

• 识别这是插件 / 扩展交付任务，而不是普通应用开发
• 明确参与角色至少包括 tech-lead、architect、qa-engineer
• 风险应聚焦宿主边界不清、命令入口失联、配置升级不兼容和安装回退不明确

4. 第二步：/team-plan

需要拆清的动作

• 命令入口与贡献点调整
• 配置项、默认值与升级兼容策略
• 安装路径、启用 / 禁用路径和失败回退
• 宿主版本矩阵与验证范围
• review 中需要记录的兼容性与发布说明

合格输出应该回答

1. 哪些改动影响命令面
2. 哪些影响配置面
3. 哪些影响安装与升级路径
4. 哪些兼容风险需要 verify 覆盖

5. 第三步：/tdd

在这类仓库里，/tdd 重点是先锁安装与兼容完成标准：

• 命令入口与配置边界是否说清
• 最低宿主版本与升级路径是否明确
• 禁用态、失败态和回退路径是否可验证
• 哪些验证证据必须进入 review

6. 第四步：/team-execute

执行阶段通常包含：

• 调整命令入口或宿主集成点
• 调整配置项、默认值和兼容处理
• 更新安装说明、升级说明与故障回退说明
• 补关键验证用例和测试计划

本阶段输出至少应包含：

• 集成点变更摘要
• 配置与兼容变更摘要
• 安装 / 升级验证结果
• 剩余风险和例外项

7. 第五步：/verify

Verify 阶段要回答：

• 命令入口是否可用
• 配置项和默认值是否兼容既有安装
• 安装、升级和禁用路径是否可执行
• 宿主版本矩阵是否覆盖关键场景

8. 第六步：/team-review

Review 阶段要回答：

• 当前是否还存在阻塞发布的兼容问题
• 哪些例外可以暂时接受
• 是否需要补更多宿主版本或安装路径验证

9. 常见错误

• 只改命令入口，不更新安装和配置说明
• 只验证 happy path，不验证禁用态和升级路径
• 宿主兼容矩阵说得很笼统，无法指导 QA

建议配合阅读：codex-workflow-essentials.md、troubleshooting.md、project-onboarding.md