@colin4k1024/tsp 2.4.0

package/examples/full-lifecycle-demo-30min.md

@@ -0,0 +1,458 @@
+# 完整交付生命周期演示脚本（30 分钟深度版）
+
+> 适用对象：要完整展示 Team Skills Platform 新版主链的人。  
+> 重点展示：为什么平台不是“多几个命令”，而是把需求分析、设计收口、上线准入和上线后收口变成一条真正可治理的流水线。
+
+## 1. 演示定位
+
+这份版本适合：
+
+- 对内做平台能力宣讲
+- 对新项目做 onboarding
+- 对管理层演示“为什么 release 不是结束”
+- 对团队解释新版 `solo mode` 和 `team mode` 的共同门禁
+
+它和 [full-lifecycle-demo.md](full-lifecycle-demo.md) 的区别是：
+
+- 那份更像通用主脚本
+- 这份是带时间切片、讲解重点、切屏顺序和问答预案的深度版
+
+## 2. 30 分钟议程
+
+| 时间段 | 环节 | 目标 |
+|--------|------|------|
+| 0-3 分钟 | 开场与问题定义 | 先让观众知道平台解决什么问题 |
+| 3-7 分钟 | `/team-intake` | 展示不会直接跳到实现 |
+| 7-12 分钟 | `/team-plan` | 展示 challenge、动态分组、design review |
+| 12-17 分钟 | `/team-execute` + `/handoff` | 展示实现如何消费方案与交接 |
+| 17-21 分钟 | `/team-review` | 展示测试事实和上线准入分离 |
+| 21-25 分钟 | `/team-release` | 展示 deployment context、release plan、观察窗口 |
+| 25-28 分钟 | `/team-closeout` | 展示最终验收、遗留项、backlog 回写 |
+| 28-30 分钟 | 总结与问答 | 回答 team mode / solo mode / 成本问题 |
+
+## 3. 开场怎么讲
+
+### 3.1 开场目标
+
+开场不要先讲命令，要先讲旧问题：
+
+- 需求没分析完就开始 plan
+- 方案没收口就开始 execute
+- 测试通过和允许上线混在一起
+- 发布后没有正式收口
+
+### 3.2 建议开场串词
+
+> 今天这 30 分钟我不演示“几个命令怎么跑”，而是演示一条完整流水线。  
+> 这条流水线解决的是：从需求进入，到方案冻结，到实现，到评审，到上线，到上线后的最终收口，怎么形成同一套事实源。
+
+### 3.3 第一屏建议展示
+
+先展示这条主链：
+
+```text
+/team-intake
+-> /team-plan
+-> /team-execute
+-> /handoff
+-> /team-review
+-> /team-release
+-> /team-closeout
+```
+
+然后强调两句话：
+
+- `release` 不是结束
+- `closeout` 才是正式收口
+
+## 4. 场景设定
+
+本次演示继续使用企业项目语境：
+
+**审批与交付协同系统**
+
+### 4.1 为什么选这个场景
+
+- 有需求复杂度，但不抽象
+- 同时包含产品、流程、权限、前后端、通知、归档
+- 很适合演示 custom overlay、shared skills、主链命令和 artifact 落盘
+
+### 4.2 现场展示的需求摘要
+
+```text
+需求名称：员工离职交接管理系统
+
+目标：
+1. 替代邮件 + Excel 的离职交接方式
+2. 覆盖申请、审批、交接、通知、归档全流程
+3. 支持员工、接班人、主管、HR、IT、财务六类角色
+
+约束：
+1. 企业内部系统，需要接 SSO、审批流、数据权限
+2. 技术栈：Spring Boot + MySQL + Redis + React + TypeScript
+3. 员工数据涉及合规与审计
+```
+
+## 5. 环节一：/team-intake（3-7 分钟）
+
+### 5.1 这一段要证明什么
+
+证明平台不会直接进入开发，而是先锁定：
+
+- 做什么
+- 不做什么
+- 风险是什么
+- 需要哪些角色
+- 哪些问题必须进入 challenge
+
+### 5.2 建议输入脚本
+
+```text
+请按 Team Skills Platform 工作模型处理当前任务。
+先执行 /team-intake，基于下面需求锁定目标、范围、约束、参与角色和主要风险。
+
+任务背景：
+[粘贴需求摘要]
+
+特别关注：
+1. 是否属于企业内部应用
+2. 是否需要启用审批流、数据权限、企业 SDK
+3. 前后端和 QA、DevOps 是否都要进入主链
+4. 哪些问题必须进入 requirement challenge
+```
+
+### 5.3 屏幕上重点看什么
+
+- 有 `In Scope / Out of Scope`
+- 有 `待确认项`
+- 有 `参与角色`
+- 有 `候选技能装配`
+- 有风险，而不是“先做再说”
+
+### 5.4 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/prd.md`
+- `docs/artifacts/INDEX.md`
+
+### 5.5 主持人说明词
+
+> Intake 阶段的关键价值，是把“模糊需求”变成“可进入下一阶段的结构化输入”。  
+> 这一步如果没做扎实，后面的 plan 和 execute 本质上都是在赌。
+
+### 5.6 可选展开点
+
+如果观众对企业项目感兴趣，可以多讲 1 分钟：
+
+- 为什么这里会识别 custom overlay
+- 为什么数据合规和权限问题要在 intake 就出现
+
+## 6. 环节二：/team-plan（7-12 分钟）
+
+### 6.1 这一段要证明什么
+
+这是整场演示最核心的一段，要证明：
+
+- `plan` 不是第一反应
+- 先有 `Requirement Challenge Session`
+- 再有动态分组讨论
+- 再做 `Design Review`
+- 最后才冻结成可执行计划
+
+### 6.2 建议输入脚本
+
+```text
+基于当前 intake 结果执行 /team-plan。
+
+要求：
+1. 先完成 Requirement Challenge Session
+2. 明确动态讨论分组和各角色质疑点
+3. 输出 delivery plan、风险、依赖、阶段负责人
+4. 明确什么时候才算 handoff-ready
+5. 若需要，补充架构设计与 API contract 的落盘位置
+```
+
+### 6.3 屏幕上重点看什么
+
+- `Requirement Challenge Session`
+- `Dynamic Discussion Group`
+- `Design Review Board`
+- `handoff-ready`
+- 风险、依赖、阶段负责人
+
+### 6.4 这段怎么讲
+
+建议主持人这样解释：
+
+> 旧问题不是不会做 plan，而是太早做 plan。  
+> 新主链的关键变化是：plan 之前必须先让不同角色挑战假设，确认我们没有在错误的问题上做高质量执行。
+
+### 6.5 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/delivery-plan.md`
+- `docs/artifacts/{date}-{slug}/arch-design.md`
+- `docs/memory/project-context.md`
+- 必要时 `docs/adr/ADR-xxx-*.md`
+
+### 6.6 这段最值得停一下的点
+
+建议现场停 30 秒，明确讲：
+
+- 以前很多团队把 “开需求会” 当 challenge
+- 但 challenge 不是开会本身，而是要留下结构化质疑和结论
+
+## 7. 环节三：/team-execute + /handoff（12-17 分钟）
+
+### 7.1 这一段要证明什么
+
+证明 execute 不是自由开工，而是：
+
+- 消费已冻结的方案
+- 消费 handoff-ready 的输入
+- 输出可被下游直接消费的实现事实
+
+### 7.2 建议分两段讲
+
+先讲后端 execute，再讲 handoff；前端 execute 可以用较短时间带过。
+
+### 7.3 后端 execute 输入脚本
+
+```text
+按已确认的 delivery plan 和 arch design 执行 /team-execute。
+
+本轮只做后端部分：
+1. 离职申请接口
+2. 交接任务生成
+3. 数据权限接入边界
+
+请输出：
+- 实现范围
+- 关键改动
+- 自测结果
+- 风险与未完成项
+```
+
+### 7.4 handoff 输入脚本
+
+```text
+请基于当前后端实现结果执行 /handoff。
+
+要求：
+1. 说明已完成事实
+2. 说明未完成项和风险
+3. 说明下一跳角色要做什么
+4. 标明当前阶段、目标阶段与 readiness
+```
+
+### 7.5 屏幕上重点看什么
+
+- `execute-log.md`
+- handoff 的结构化内容
+- `当前阶段 -> 目标阶段`
+- readiness 不是口头说“差不多好了”
+
+### 7.6 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/execute-log.md`
+- `docs/artifacts/{date}-{slug}/handoffs/*.md`
+- 必要时 `docs/memory/decisions.md`
+
+### 7.7 这段怎么讲
+
+> 这里的重点不是“AI 写了多少代码”，而是“实现结果有没有变成下游能消费的事实”。  
+> 只有这样 QA 和 DevOps 才不会重新猜前面的上下文。
+
+## 8. 环节四：/team-review（17-21 分钟）
+
+### 8.1 这一段要证明什么
+
+证明测试事实和上线准入必须分开。
+
+### 8.2 建议输入脚本
+
+```text
+请执行 /team-review。
+
+要求：
+1. 基于前后端交付物做测试与风险评审
+2. 给出阻塞项和放行建议
+3. 单独输出 launch acceptance 结论
+4. 明确是 Go、Conditional Go 还是 No-Go
+```
+
+### 8.3 屏幕上重点看什么
+
+- `test-plan.md`
+- `launch-acceptance.md`
+- Go / Conditional Go / No-Go
+- 已接受风险 vs 阻塞项
+
+### 8.4 这段怎么讲
+
+> 很多团队最大的问题不是不测，而是把“测到了什么”和“现在能不能发”混成一句话。  
+> 平台把这两件事拆开，是为了让上线决策真正可追溯。
+
+### 8.5 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/test-plan.md`
+- `docs/artifacts/{date}-{slug}/launch-acceptance.md`
+
+## 9. 环节五：/team-release（21-25 分钟）
+
+### 9.1 这一段要证明什么
+
+证明 release 阶段会正式沉淀：
+
+- deployment context
+- release plan
+- 观察窗口
+- 回滚入口
+- 值守责任
+
+### 9.2 建议输入脚本
+
+```text
+请执行 /team-release。
+
+要求：
+1. 基于 launch acceptance 结论组织发布
+2. 输出 deployment context 与 release plan
+3. 明确观察窗口、关键指标和值守责任
+4. 给出回滚条件与回滚入口
+```
+
+### 9.3 屏幕上重点看什么
+
+- `deployment-context.md`
+- `release-plan.md`
+- 观察窗口定义
+- 回滚条件
+
+### 9.4 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/deployment-context.md`
+- `docs/artifacts/{date}-{slug}/release-plan.md`
+
+### 9.5 这段怎么讲
+
+> 这里要强调：平台不是只会说“可以发了”。  
+> 它会留下一个真正能被别人接手的发布上下文，告诉你怎么发、怎么回滚、发完看什么。
+
+## 10. 环节六：/team-closeout（25-28 分钟）
+
+### 10.1 这一段要证明什么
+
+这是深度版一定要重点讲的一段：
+
+- 发布完成不等于任务完成
+- 观察窗口结束才进入 closeout
+- closeout 会决定最终状态
+- closeout 会把遗留项回写 backlog
+
+### 10.2 建议输入脚本
+
+```text
+请基于发布结果和观察窗口数据执行 /team-closeout。
+
+要求：
+1. 判断观察窗口是否可以结束
+2. 给出最终验收状态
+3. 说明残余风险如何处置
+4. 把遗留项回写 backlog
+5. 明确任务状态是 closed、follow-up-required 还是 re-open
+```
+
+### 10.3 屏幕上重点看什么
+
+- `closeout-summary.md`
+- `docs/memory/backlog.md`
+- `docs/memory/lessons-learned.md`
+- `docs/memory/sessions/*.md`
+
+### 10.4 要展示的文件
+
+- `docs/artifacts/{date}-{slug}/closeout-summary.md`
+- `docs/memory/backlog.md`
+- `docs/memory/lessons-learned.md`
+- `docs/memory/sessions/{date}-{nnn}-{slug}.md`
+
+### 10.5 这段怎么讲
+
+建议原话：
+
+> 新版主链最大的变化不是增加了一个命令，而是增加了一个治理阶段。  
+> 现在 release 之后不再靠口头说“没问题了”，而是通过 closeout 明确：观察窗口结束了吗、风险怎么处理、任务到底关不关闭。
+
+## 11. 收尾总结（28-30 分钟）
+
+### 11.1 建议总结结构
+
+最后 2 分钟建议只讲 3 件事：
+
+1. 平台把“需求、设计、实现、上线、收口”串成了同一条事实链
+2. 每一步都有 artifact，而不是只有聊天记录
+3. `closeout` 让平台从“做到上线”为止，升级到“做到正式收口”为止
+
+### 11.2 建议总结串词
+
+> 如果把今天的演示压缩成一句话，就是：  
+> Team Skills Platform 不只是帮你把任务拆给不同角色，而是把原来分散在会话、脑子和临场判断里的关键事实，固化成一条可治理、可演示、可回溯的交付流水线。
+
+## 12. 高概率问答预案
+
+### Q1：这会不会太重？
+
+回答建议：
+
+> 对多人协作项目，这不是变重，而是把原来隐性的成本显性化。  
+> 对一人开发项目，可以走 `solo mode`，压缩角色，但不丢 gate。
+
+可引用：
+
+- [solo-delivery-mode.md](../docs/runbooks/solo-delivery-mode.md)
+- [solo-delivery-one-page.md](../docs/runbooks/solo-delivery-one-page.md)
+
+### Q2：为什么 release 后还要 closeout？
+
+回答建议：
+
+> 因为“发出去了”和“稳定了、验收了、可以正式结案了”不是一回事。  
+> 没有 closeout，遗留项、观察窗口和最终状态会重新掉回聊天记录里。
+
+### Q3：这是不是只适合大项目？
+
+回答建议：
+
+> 不是。  
+> 大项目强调多人协作；小项目可以走 solo mode。  
+> 变化的是角色压缩，不是核心门禁消失。
+
+## 13. 演示时建议打开的文件顺序
+
+如果你想边讲边切文件，推荐这样切：
+
+1. [full-lifecycle-demo.md](full-lifecycle-demo.md)
+2. [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)
+3. [artifact-persistence.md](../docs/runbooks/artifact-persistence.md)
+4. `docs/artifacts/{date}-{slug}/prd.md`
+5. `docs/artifacts/{date}-{slug}/delivery-plan.md`
+6. `docs/artifacts/{date}-{slug}/test-plan.md`
+7. `docs/artifacts/{date}-{slug}/launch-acceptance.md`
+8. `docs/artifacts/{date}-{slug}/deployment-context.md`
+9. `docs/artifacts/{date}-{slug}/release-plan.md`
+10. `docs/artifacts/{date}-{slug}/closeout-summary.md`
+
+## 14. 推荐搭配材料
+
+- 总脚本：[full-lifecycle-demo.md](full-lifecycle-demo.md)
+- 新项目接入：[../docs/runbooks/project-onboarding.md](../docs/runbooks/project-onboarding.md)
+- 发布示例：[../docs/runbooks/team-release-example.md](../docs/runbooks/team-release-example.md)
+- 收口示例：[../docs/runbooks/team-closeout-example.md](../docs/runbooks/team-closeout-example.md)
+
+## 15. 一句话使用说明
+
+如果你明天就要正式讲一场，建议做法是：
+
+1. 用这份文件做主持人脚本
+2. 用 [full-lifecycle-demo.md](full-lifecycle-demo.md) 做补充台词
+3. 现场重点展示 `launch-acceptance.md`、`deployment-context.md` 和 `closeout-summary.md`
+4. 最后用 `solo mode` 收尾，回答“小项目会不会太重”