@colin4k1024/tsp 2.4.5 → 2.4.7

package/docs/runbooks/checkov-iac-gates.md

@@ -1,104 +0,0 @@
-# Checkov IaC 门禁手册
-
-本手册承接 `bridgecrewio/checkov` 的工程实践，用于把基础设施即代码的误配置检查前置到 PR、评审和发布准备阶段。它补的是“IaC 配置是否违反已知安全与合规检查”这一层，不替代运行时漏洞扫描、依赖变更审查或团队自定义策略评审。
-
-## 用途 / 定位
-
-Checkov 的核心价值，是在构建期对 IaC、云配置和相关模板做静态检查，尽早发现不安全默认值、暴露面、权限过宽和结构性误配置。官方资料显示，它支持 Terraform、Terraform Plan、Terraform JSON、CloudFormation、Kubernetes、Helm、Kustomize、Dockerfile、Serverless、Ansible、Bicep、ARM、OpenTofu，以及部分 CI/CD 工作流文件；同时支持属性型和图关系型自定义策略，也能输出 CLI、JSON、JUnit XML、SARIF 和 Markdown 结果。
-
-在本仓库里，建议把它视为“IaC 安全基线门禁”，而不是万能安全扫描器。
-
-## 适用场景
-
-- 变更涉及 Terraform、Kubernetes、Helm、CloudFormation、ARM、Bicep、OpenTofu 或其他结构化基础设施配置。
-- 团队希望在 PR 级别提前发现云资源的高风险属性，例如公开暴露、弱默认值、过宽权限、未加密配置或危险网络入口。
-- 团队希望将一部分已知的 IaC 安全检查固定为可重复执行的门禁，而不是完全依赖人工 review。
-- 需要把检查结果以 SARIF、JUnit XML 或 Markdown 的形式回落到 CI、代码扫描或评审流程。
-- 团队需要复用 Checkov 的内置检查，或者基于其属性 / 图策略能力做局部扩展。
-
-## 不适用场景
-
-- 主要问题是容器镜像漏洞、文件系统漏洞或仓库 secret 泄漏，这类场景应优先看 `trivy-security-gates`。
-- 主要问题是依赖新增、依赖漏洞、许可证变化或 lockfile 差异，这类场景应优先看 `dependency-review-gates`。
-- 主要诉求是把团队自己的结构化配置规则写成 Rego policy 并做统一预检，这类场景应优先看 `conftest-policy-gates`。
-- 变更只是应用业务逻辑，而不是 IaC 或模板配置。
-- 团队没有准备好维护规则基线、误报处理和例外流程，却希望一步到位把所有检查都设成强阻塞。
-
-## 推荐落地方式
-
-1. 先限定扫描面，不要一上来把所有支持的 framework 全部打开。
-   - PR 阶段优先扫当前仓库真实使用的 IaC 类型
-   - 只对高信号检查先设门禁
-2. 先把“发现”和“阻塞”分开。
-   - 先输出结果、建立基线、确认误报
-   - 再逐步把高风险检查升级为 fail gate
-3. 优先使用 Checkov 的内置检查覆盖通用云配置风险，再决定是否补充自定义属性策略或 graph 策略。
-4. 如果团队已经有自己的策略语言和例外治理模型，把 Checkov 放在“预检”层，不要让它承载所有组织规则。
-5. 输出格式按用途选型：
-   - 人工 review 优先 CLI 或 Markdown
-   - CI 归档和自动化处理优先 JSON
-   - GitHub code scanning 优先 SARIF
-   - 需要测试系统消费时可用 JUnit XML
-6. 结果必须回写到 `/team-review` 或 `/team-release`，不要只停在流水线日志里。
-
-## 与其他门禁的边界
-
-- `trivy-security-gates` 负责镜像、文件系统、secret 和 IaC 相关的漏洞或 misconfiguration 扫描结果，偏“制品与运行前资产安全”。
-- `conftest-policy-gates` 负责用 Rego 表达团队自己的配置策略，偏“组织规则与 policy-as-code 预检”。
-- `dependency-review-gates` 负责依赖清单、lockfile、许可证变化和已知依赖风险，偏“依赖变更审查”。
-- `checkov-iac-gates` 负责 IaC / 模板层的安全与合规检查，偏“云配置基线与结构性误配置”。
-
-简单说，Checkov 不是依赖审查器，也不是镜像漏洞扫描器；如果团队要表达的是“这类配置应该怎么写”，优先考虑 Conftest。如果团队要回答的是“这次依赖改动带来了什么”，优先考虑 Dependency Review。如果团队要回答的是“镜像、文件系统或 secret 有没有问题”，优先考虑 Trivy。
-
-## 最小门禁模型
-
-- `target layer`：Terraform、Kubernetes、Helm、CloudFormation、ARM、Bicep、OpenTofu 或其他 IaC 输入
-- `scan layer`：Checkov 内置检查、属性策略、图策略和输出格式化
-- `triage layer`：误报确认、例外说明、存量问题与本次变更区分
-- `decision layer`：`qa-engineer`、`devops-engineer`、`tech-lead` 决定是否阻塞合并或发布
-
-先把“扫描出什么”与“这次是否要拦”拆开，团队更容易持续使用。
-
-## 重点检查项
-
-- 是否存在公开暴露、过宽入站规则或默认不安全的网络入口
-- 是否存在过度授权的 IAM、角色、服务账户或访问策略
-- 是否存在未加密、弱默认值或资源级保护缺失
-- 是否存在高风险的容器、工作负载或模板配置，例如特权运行、危险挂载或不安全的安全上下文
-- 是否存在基础设施之间的危险关系，例如不应直接连通的资源路径
-- 是否把高风险 IaC 改动写成“看起来只是格式调整”的提交，导致 review 失焦
-
-## 反模式
-
-- 把 Checkov 当成通用漏洞扫描器，顺手替代 Trivy、Dependency Review 或人工 review。
-- 一开始就全量启用所有框架和所有规则，结果误报过多，团队很快弃用。
-- 只有失败结果，没有基线、例外和责任人，最后没人知道该改哪条配置。
-- 把自定义规则全堆进一个工具里，既不区分组织策略，也不区分 IaC 基线与发布门禁。
-- 只看扫描通过与否，不看输出类型是否方便回落到 PR、review 或 release 记录。
-
-## 输出回落
-
-- PR 阶段：把新增高风险检查、误报判断和建议修复写入 review 摘要。
-- 评审阶段：在 `/team-review` 中说明哪些问题来自 Checkov，哪些已经人工接受或需要阻塞。
-- 发布阶段：若关键 IaC 风险未关闭，必须回写到 `/team-release` 的风险、放行结论或后续观察项。
-- 自动化阶段：如果要给 GitHub code scanning、测试报告或机器消费使用，优先分别输出 SARIF、JUnit XML 或 JSON，避免把所有信息挤进单一日志。
-
-## 许可证与使用边界
-
-- `bridgecrewio/checkov` 仓库与官方容器包标注为 Apache-2.0。
-- 如果要接入 Prisma Cloud 或其他平台能力，应另外确认账号、API、数据流和合规边界。
-- 本手册只建议把 Checkov 用作 IaC 预检与门禁参考，不建议把它扩展成团队唯一的安全真相来源。
-
-## 参考来源
-
-- [bridgecrewio/checkov](https://github.com/bridgecrewio/checkov)
-- [Checkov 官方站点](https://www.checkov.io/)
-- [Reviewing Scan Results](https://www.checkov.io/2.Basics/Reviewing%20Scan%20Results.html)
-- [Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)
-- [Suppressing and Skipping Policies](https://www.checkov.io/2.Basics/Suppressing%20and%20Skipping%20Policies.html)
-- [SARIF 输出](https://www.checkov.io/8.Outputs/SARIF.html)
-- [JUnit XML 输出](https://www.checkov.io/8.Outputs/JUnit%20XML.html)
-- [Checkov GitHub Action](https://github.com/bridgecrewio/checkov-action)
-- [trivy-security-gates.md](trivy-security-gates.md)
-- [conftest-policy-gates.md](conftest-policy-gates.md)
-- [dependency-review-gates.md](dependency-review-gates.md)

package/docs/runbooks/claude-code-review-workflow.md

@@ -1,72 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Claude 代码评审工作流
-
-本文聚焦 Claude 中的 `/code-review` 使用方式，目标不是解释命令存在本身，而是说明何时触发、如何输入、如何把结论回落到主链。
-
-## 1. 何时触发 `/code-review`
-
-- 代码已经初步完成，准备联调前
-- 涉及接口、权限、数据库或前端质量门禁
-- 有明显回归风险，希望在 QA 前先暴露问题
-
-## 2. 推荐输入方式
-
-好的输入应该包含：
-
-- 本次改动的目标
-- 涉及的关键风险点
-- 希望重点关注的方面
-
-示例：
-
-```text
-/code-review
-目标：评审订单导出接口与前端触发改动
-重点关注：权限校验、错误处理、前端空态和导出失败路径
-```
-
-## 3. 如何理解输出
-
-优先按严重度看：
-
-- Critical：必须先修
-- High：通常不应带着进入 QA
-- Medium：能修就修，至少要记录
-- Low：作为优化建议
-
-## 4. 如何回到主链
-
-`/code-review` 的结果不要停留在本地结论，建议立刻补一句：
-
-```text
-请把上面的评审结论整理为可直接进入 /handoff 的格式。
-```
-
-这样可以直接把结论并入下一步交接。
-
-## 5. 前端与后端的差异
-
-- 前端更关注：响应式、A11y、状态切换、视觉回归
-- 后端更关注：兼容性、幂等性、错误码、数据库与权限边界
-
-## 6. 与 `/team-review` 的区别
-
-- `/code-review` 更偏工程实现质量
-- `/team-review` 更偏测试和放行结论
-
-不要把 `/code-review` 当作 QA 的替代。
-
-## 7. 常见错误
-
-- 还没明确目标就跑 `/code-review`
-- 评审结论没有回落到 handoff
-- 只看建议，不处理严重问题
-
-如果要看完整循环，继续看 [code-review-collaboration-walkthrough.md](code-review-collaboration-walkthrough.md)。

package/docs/runbooks/claude-conversation-prompt-recipes.md

@@ -1,132 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Claude 对话提示模板
-
-本文给出更贴近 Claude 日常对话的起手模板。它们和 [team-commands-quick-prompts.md](team-commands-quick-prompts.md) 的区别是：这里不是只给命令骨架，而是给一段可以直接发给模型的完整说法。
-
-如果你想先知道当前有哪些公开命令、ECC skills 和推荐组合，先看 [command-and-capability-matrix.md](command-and-capability-matrix.md)。如果你想先搞清后台机制，再看 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)。
-
-## 1. 第一次把任务拉进主链
-
-```text
-请按 Team Skills Platform 工作模型处理当前任务。
-先以 tech-lead 视角执行 /team-intake，输出目标、范围外事项、参与角色、主要风险和下一步建议。
-
-任务背景：
-- 目标：新增订单审批状态查询接口
-- 范围：接口、权限校验、测试计划
-- 不做：前端页面和发布脚本重构
-- 约束：需要判断 私有流程与权限集成 是否启用
-```
-
-适用场景：还没进入具体实现，需要先把边界锁住。
-
-## 2. 已有 intake，要求继续拆计划
-
-```text
-基于当前 intake 结果继续执行 /team-plan。
-请拆出角色职责、依赖、handoff 节点、风险和技能装配清单。
-如果 custom overlay 不启用，也请明确写出未启用原因。
-```
-
-适用场景：你不想自己拼 plan 的字段，只想让输出直接变成可执行计划。
-
-## 3. 要求 Claude 先做专项分析，再回到主链
-
-```text
-基于当前任务先调用 /code-review 做专项风险分析。
-分析完成后，不要停在专项结论，请把结果整理成可直接进入 /handoff 的格式，包含：风险、建议动作、验证要求和下一角色关注点。
-```
-
-适用场景：中途插入 specialist，但不希望结果散掉。
-
-## 4. 走短链路的小任务
-
-```text
-这是一个边界清晰的小修复。
-请先判断是否可以走短链路；如果可以，按 /code-review -> /handoff -> /team-review 的顺序给出建议。
-如果不适合短链路，请说明必须补 /team-plan 的原因。
-```
-
-适用场景：你怀疑任务不需要完整长链，但不想自己拍板。
-
-## 5. 前端任务的常用起手式
-
-```text
-请按 Team Skills Platform 处理这个前端问题。
-先执行 /team-intake，并明确输出是否命中 frontend-quality-gates、响应式验证和 ui-review-checklist。
-
-任务：修复订阅页在 iPad 横屏下的布局溢出。
-范围：页面布局、响应式回归、UI 自测证据。
-不做：接口改造。
-```
-
-适用场景：你希望模型主动把前端门禁带进来，而不是只盯着代码。
-
-## 6. 后端加 company 判断的起手式
-
-```text
-请先以 /team-intake 方式处理当前后端任务，并重点判断是否命中 custom overlay 候选项。
-如果涉及流程审批、权限中心或公司专属平台，请给出候选项；如果不启用，也要说明原因。
-
-任务：新增订单审批流转接口与权限校验。
-范围：接口、权限、测试计划。
-不做：前端页面。
-```
-
-适用场景：后端任务容易提前把 custom overlay 混成默认启用，这段模板可以把判断动作显式化。
-
-## 7. 发布前让 Claude 帮你收口
-
-```text
-基于当前实现、自测和 QA 结论，执行 /team-release。
-请输出发布方案、观察窗口、回滚条件、责任链，并补充是否需要 GitLab 手动流水线或 Langfuse 追踪。
-如果这些能力只是 runbook 补充，而不是正式 custom overlay，也请写清楚。
-```
-
-适用场景：发布阶段最容易把企业扩展写丢，这段模板可以把判断和回写一起带出来。
-
-## 8. 先走测试先行的说法
-
-```text
-基于当前 /team-plan 结果，不要直接进入实现。
-先执行 /tdd，输出 red-green-refactor 路径、优先测试点、边界行为和实现顺序。
-最后把结果整理成可直接进入 /team-execute 的动作清单。
-```
-
-适用场景：需求已经拆完，但你希望先把测试与成功标准锁住，减少返工。
-
-## 9. 对平台本身做体检的说法
-
-```text
-当前仓库刚新增了一批命令、skills、hooks 和文档入口。
-请先执行 /harness-audit，重点审视命令覆盖、skills 完整度、hooks 有效性、文档同步和集成深度。
-输出时请区分：必须立即补齐的问题、可排到下一轮的问题、建议先改哪些 runbook / example / README。
-```
-
-适用场景：你不是在做单个业务需求，而是在收敛平台本身。
-
-## 10. 让 Claude 强制给出结构化结果
-
-```text
-请不要只给结论摘要。
-输出必须包含：已确认事项、未确认事项、风险、下一步命令建议。
-如果涉及 specialist 结果，请再补一段“如何回收到 /handoff 或 /team-*”。
-```
-
-适用场景：模型回答开始发散，或者只给了松散建议时。
-
-## 11. 常见错误
-
-- 把自然语言提示写得太短，导致目标、范围和约束缺失
-- 要求 specialist 分析，却没有追加“回到主链”的要求
-- 已经需要 `/tdd` 或 `/harness-audit`，却还停留在泛化问法，导致输出无法直接落成动作
-- overlay、runbook、toolkit 明明只是在当前任务按场景使用，却被写成默认长期启用
-
-如果你要看纯命令骨架，回到 [team-commands-quick-prompts.md](team-commands-quick-prompts.md)；如果你要看最短上手路径，继续看 [first-team-command-60-seconds.md](first-team-command-60-seconds.md)；如果你要看 specialist 的适用边界，继续看 [specialist-commands-playbook.md](specialist-commands-playbook.md)。

package/docs/runbooks/claude-end-to-end-conversation-example.md

@@ -1,198 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Claude 完整对话样例
-
-本文给出一份偏 Claude 使用方式的成品对话样例。重点不是模拟真实模型逐字输出，而是演示用户通常该怎么说，平台输出至少应长什么样，以及怎样把结果继续推进到下一步。
-
-## 1. 场景
-
-- 任务：新增订单审批状态查询接口
-- 范围：接口、权限校验、测试计划
-- 不做：前端页面
-- 约束：判断 私有流程与权限集成 是否启用
-
-## 2. 第一步：用户发起 intake
-
-用户可直接这样说：
-
-```text
-请按 Team Skills Platform 工作模型处理当前任务。
-先以 tech-lead 视角执行 /team-intake，输出目标、范围外事项、参与角色、主要风险和下一步建议。
-
-任务背景：
-- 目标：新增订单审批状态查询接口
-- 范围：接口、权限校验、测试计划
-- 不做：前端页面
-- 约束：判断 私有流程与权限集成 是否启用
-```
-
-期望得到的结果应至少像这样：
-
-```text
-目标
-- 新增订单审批状态查询接口，支持权限校验和测试计划落地
-
-范围外事项
-- 不包含前端页面和发布脚本改造
-
-参与角色
-- tech-lead
-- architect
-- backend-engineer
-- qa-engineer
-
-主要风险
-- 审批状态字段口径是否与历史接口一致
-- 权限过滤口径是否需要接入 私有权限中心
-
-领域技能包启用建议
-- 私有流程引擎：候选，原因是任务涉及审批状态语义
-- 私有权限中心：候选，原因是任务涉及权限过滤
-
-下一步建议
-- 进入 /team-plan，由 architect 和 backend-engineer 明确接口契约与技能装配清单
-```
-
-## 3. 第二步：用户继续要 plan
-
-用户可以直接跟一句：
-
-```text
-基于当前 intake 结果继续执行 /team-plan。
-请拆出角色职责、依赖、handoff 节点、风险和技能装配清单。
-如果 custom overlay 不启用，也请明确写出未启用原因。
-```
-
-期望结果至少包含：
-
-```text
-角色职责
-- architect：确认接口契约、权限边界、兼容性约束
-- backend-engineer：实现接口、权限校验、测试
-- qa-engineer：准备功能、权限和边界测试
-
-依赖
-- architect 先确认返回字段和权限边界
-- backend-engineer 再实现并补自测
-
-技能装配清单
-- shared：启用
-- ecc：按需启用 `/verify` 对应的验证收口能力
-- enterprise：未启用
-- 原因：本次未进入流程运行态或 私有权限中心 正式集成，仅保留候选判断
-
-handoff 节点
-- architect -> backend-engineer：接口契约和权限边界
-- backend-engineer -> qa-engineer：实现结果、自测证据、风险说明
-```
-
-## 4. 第三步：用户要求专项分析并回主链
-
-如果用户想先做一次风险分析，可以这样说：
-
-```text
-基于当前任务先调用 /code-review 做专项风险分析。
-分析完成后，不要停在专项结论，请把结果整理成可直接进入 /handoff 的格式。
-```
-
-期望结果应像这样收口：
-
-```text
-风险
-- 权限过滤口径若与旧接口不一致，可能导致审批记录数量异常
-
-建议动作
-- 在 execute 前固定返回字段和权限边界
-- 自测覆盖无权限、非法参数、空结果三类场景
-
-下一角色关注点
-- backend-engineer 需要在 handoff 中写清兼容性说明
-- qa-engineer 需要重点验证旧调用方兼容性
-```
-
-## 5. 第四步：用户要求 execute
-
-```text
-/team-execute
-按当前 plan 执行 backend-engineer 的实现和自测。
-输出代码变更摘要、自测结果、待确认事项，以及需要进入 handoff 的信息。
-```
-
-期望结果至少包含：
-
-```text
-实现结果
-- 新增订单审批状态查询接口
-- 增加权限校验和异常返回
-
-自测结论
-- 正常查询、无权限、非法参数已验证
-
-待确认事项
-- 历史客户端是否依赖旧字段顺序
-
-领域扩展执行记录
-- enterprise：未启用
-- 原因：未进入 私有流程 / 权限集成 正式集成
-```
-
-## 6. 第五步：用户要求 handoff
-
-```text
-/handoff
-请把当前阶段结论整理成结构化交接，供 QA 继续处理。
-```
-
-期望得到：
-
-```text
-已完成
-- 接口实现完成
-- 权限校验与异常处理完成
-
-验证结果
-- 已完成后端自测
-
-风险
-- 兼容旧客户端字段顺序仍需 QA 确认
-
-下一角色动作清单
-- QA 验证权限边界、空结果和旧客户端兼容性
-```
-
-## 7. 第六步：用户要求 review
-
-```text
-/team-review
-基于当前 handoff 结果，输出测试结论、阻塞项、放行建议和残余风险。
-```
-
-期望得到：
-
-```text
-评审结论
-- 结论：有条件通过
-
-阻塞项
-- 无
-
-残余风险
-- 旧客户端字段顺序兼容性需上线前再确认一次
-
-放行建议
-- 可进入 /team-release，发布前补一次兼容性 smoke
-```
-
-## 8. 这份样例说明了什么
-
-- Claude 的最佳使用方式，不是只发一个命令，而是附上目标、范围、不做和约束
-- specialist 可以插入，但必须要求“整理成可进入 /handoff 的格式”
-- overlay 候选项可以在 intake 提到，但不必强行在 plan 中启用
-
-如果你想要更短的复制模板，继续看 [claude-conversation-prompt-recipes.md](claude-conversation-prompt-recipes.md)；如果你想看完整主链说明，继续看 [first-team-workflow-walkthrough.md](first-team-workflow-walkthrough.md)。

package/docs/runbooks/claude-feature-development-guide.md

@@ -1,112 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Claude 新功能开发指南
-
-本文说明在 Claude 中如何用 Team Skills Platform 跑一条完整的新功能开发链路，适合日常功能开发而不是仅做快速试验。
-
-如果你想先看新增命令与能力映射，先看 [command-and-capability-matrix.md](command-and-capability-matrix.md)。如果你想先理解后台机制怎样影响长会话，再看 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)。
-
-## 1. 适用场景
-
-- 需要明确范围、依赖和角色分工的新功能
-- 需要前后端协作或至少涉及 QA 验证
-- 希望把 specialist 作为辅助，而不是主链替代品
-
-## 2. 推荐链路
-
-1. `/team-intake`
-2. `/team-plan`
-3. `/team-execute`
-4. `/handoff`
-5. `/team-review`
-6. `/team-release`
-
-如果任务很小，可把 `/team-release` 留到需要真正发布时再进入。
-
-## 3. 第一步：锁定目标和约束
-
-典型输入：
-
-```text
-/team-intake
-目标：新增订单导出功能
-范围：导出接口、前端触发按钮、测试计划
-不做：导出模板重构、历史数据修复
-约束：需要评估是否涉及权限中心
-```
-
-Claude 里这一段最关键的不是“需求描述多完整”，而是把 `范围`、`不做` 和 `约束` 写清楚。
-
-## 4. 第二步：拆解角色与交付物
-
-进入 `/team-plan` 时，建议显式要求输出：
-
-- 任务拆解
-- 依赖关系
-- handoff 最小交付物
-- custom overlay 是否启用
-
-如果 plan 没写交付物，后续 Claude 很容易在长对话中丢信息。
-
-## 5. 第三步：执行与 specialist 配合
-
-Claude 中使用 specialist 的原则：
-
-- 先跑主链，再插入 specialist
-- specialist 只负责专项结论
-- specialist 结果必须回到 `/handoff` 或 `/team-*`
-
-常见组合：
-
-- 方案复杂：`/plan`
-- 想先锁测试：`/tdd`
-- 代码改完：`/code-review`
-- 构建失败：`/build-fix`
-- 最终验证：`/verify`
-
-推荐顺序通常是：
-
-1. `/team-intake`
-2. `/team-plan`
-3. 如果需求边界已清楚且返工成本高，补 `/tdd`
-4. `/team-execute`
-5. `/handoff`
-6. `/team-review`
-
-## 6. 第四步：交接与 QA
-
-进入 `/handoff` 时，至少要覆盖：
-
-- 改了什么
-- 自测了什么
-- 剩余风险是什么
-- QA 接手时最该关注什么
-
-如果功能涉及 custom overlay，还要把 `技能装配清单` 或 `领域扩展执行记录` 合并进去。
-
-## 7. 第五步：收口与发布
-
-`/team-review` 应该输出：
-
-- 测试范围
-- 测试结论
-- 阻塞项
-- 是否建议放行
-
-是否进入 `/team-release`，由任务是否真正触及发布窗口决定。
-
-## 8. 常见错误
-
-- 直接从实现开始，跳过 intake 和 plan
-- 该先用 `/tdd` 锁测试与成功标准，却直接进入实现
-- 把 specialist 当最终决策者
-- handoff 只有一句“已完成开发”
-- custom overlay 被用到了，但没有记录启用原因和执行结果
-
-需要完整实例时，继续看 [first-team-workflow-walkthrough.md](first-team-workflow-walkthrough.md)。如果你想看 specialist 的边界，继续看 [specialist-commands-playbook.md](specialist-commands-playbook.md)。