@colin4k1024/tsp 2.4.4 → 2.4.6

package/docs/runbooks/slsa-verification-gates.md

@@ -1,75 +0,0 @@
-# SLSA Verification 门禁手册
-
-本手册承接 `slsa-framework/slsa-verifier` 的工程实践，用于把 provenance / attestation 的独立验证接入发布链、审计链和供应链治理。它补的是“这些证明文件是否真的可信、是否匹配目标产物”的验证环节，不替代 SBOM、签名、漏洞扫描或人工放行判断。
-
-## 适用场景
-
-- 团队已经开始生成 provenance attestation，希望在发布前或审计时独立验证它。
-- 需要确认某个 artifact、image 或 release asset 的 attestation 是否与目标产物、来源仓库和构建链匹配。
-- 团队希望把“有 attestation”升级成“attestation 已被验证”。
-
-## 不适用场景
-
-- 当前还没有稳定的 attestation 产出，却先引入验证工具。
-- 团队还没有明确验证对象、验证策略或失败处置方式。
-- 期望只靠 SLSA verifier 替代签名验证、SBOM 归档或漏洞扫描。
-
-## 推荐落地方式
-
-1. 先把验证范围锁定到最关键的正式制品，不要一开始覆盖所有历史产物。
-2. 第一阶段先固定三件事：
-   - 哪些产物必须做 provenance 验证
-   - 验证输入来自哪里
-   - 验证失败时谁决定阻塞或降级处理
-3. 将验证与现有链路分层：
-   - `artifact-attestation-gates` 负责生成 provenance attestation
-   - `slsa-generator-patterns` 负责 GitHub Actions 侧的 provenance 生成模式与 workflow 约束
-   - `in-toto-attestation-framework` 负责 attestation 的 predicate、schema 和 evidence model 设计
-   - `cosign-signing-gates` 负责签名与验签链路
-   - SLSA verification 负责独立验证 provenance / attestation 是否匹配目标产物
-   - `devops-engineer`、`tech-lead` 负责最终放行判断
-4. 若团队后续要做 policy enforcement，先把验证规则和失败处置跑顺，再考虑强制化策略。
-5. 结果必须回写到 `/team-release`、审计记录或外部交付说明中，不让验证结果只停在命令输出里。
-
-## 最小门禁模型
-
-- `subject layer`：待发布的 artifact、image 或 release asset
-- `evidence layer`：attestation、digest、来源仓库与 workflow 信息
-- `verification layer`：验证规则、验证结果与失败原因
-- `decision layer`：`devops-engineer`、`tech-lead` 决定“验证失败”是否阻塞发布
-
-重点不是“有一份证明文件”，而是证明文件已经被独立验证且匹配目标产物。
-
-## 重点检查项
-
-- 验证对象是否与实际要发布的 artifact、镜像 digest 或 release asset 一一对应
-- 验证输入是否来自可信来源，而不是手工拼接的本地文件
-- provenance / attestation 是否和目标仓库、workflow、commit 或 digest 匹配
-- 验证失败时是否有清晰的 triage 和阻塞策略
-- 团队是否把验证结果回写到发布记录，而不是只保留终端日志
-
-## 反模式
-
-- 已生成 attestation，但从未做独立验证。
-- 验证时不校验目标产物，只验证“文件格式大致正确”。
-- 验证失败后没有回到 release 记录，后续没人知道为什么被放行或拦截。
-- 还没稳定产出 provenance，就先把验证失败设成硬阻塞。
-
-## 输出回落
-
-- 构建阶段：记录哪些产物做了独立 provenance 验证，以及验证输入来源。
-- 发布阶段：把验证结果、失败摘要或例外结论写入 `/team-release` 的检查结果或放行结论。
-- 审计阶段：若需要追溯某次发布，必须能同时定位到 attestation 本身和验证结果。
-
-## 许可证与使用边界
-
-- `slsa-framework/slsa-verifier` 采用 Apache-2.0。
-- 启用前应确认 attestation 来源、目标产物类型、runner 环境和团队可接受的验证策略。
-
-## 参考来源
-
-- [slsa-framework/slsa-verifier](https://github.com/slsa-framework/slsa-verifier)
-- [artifact-attestation-gates.md](artifact-attestation-gates.md)
-- [slsa-generator-patterns.md](slsa-generator-patterns.md)
-- [in-toto-attestation-framework.md](in-toto-attestation-framework.md)
-- [cosign-signing-gates.md](cosign-signing-gates.md)

package/docs/runbooks/solo-delivery-mode.md

@@ -1,142 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-04-03
-updated: 2026-04-03
-owner: 工程团队
----
-
-# Solo Delivery Mode
-
-本文定义 Team Skills Platform 在“一人从需求到上线”场景下的运行方式。它不是 Team Mode 的替代品，而是把多人协作链路压缩成单人可执行的闭环。
-
-## 1. 核心原则
-
-- solo mode 压缩的是角色数量，不是治理门禁
-- 一个人可以同时承担 `tech-lead`、研发、QA、DevOps 职责
-- 需求澄清、方案收口、验证、发布准备、观察窗口、上线后收口都不能跳过
-- 不能因为没有多人 handoff，就把关键决策只留在对话里
-
-一句话判断：
-
-- Team Mode：多人分工 + 结构化 handoff
-- Solo Mode：单人承接 + 同样的关键事实落盘
-
-## 2. 适用场景
-
-适合使用 solo mode 的典型场景：
-
-- 单个开发者独立交付一个中小需求
-- 需要快速闭环，但仍然要保留发布与回滚治理
-- 只有一个主要实施人，但希望以后还能被别人接手
-
-不适合直接使用 solo mode 的场景：
-
-- 多团队依赖明显
-- 需求边界仍然高度不确定
-- 发布风险高，必须多人共同决策
-
-这类场景应继续走 Team Mode，或至少在关键节点升级为多人评审。
-
-## 3. Solo Mode 不省略什么
-
-solo mode 下可以把角色压缩到一个人，但下面这些 gate 不能省略：
-
-1. intake gate：目标、范围、不做项、约束、成功标准清楚
-2. plan gate：实现边界、关键设计、风险和验收路径清楚
-3. execute gate：实现前先知道怎么验证，不允许边做边猜
-4. review gate：至少完成自测、回归判断和上线风险判断
-5. release gate：有发布入口、回滚路径、观察窗口和监控项
-6. closeout gate：观察窗口结束后有最终结论、遗留项和下一步
-
-如果其中任一项答不上来，就说明 solo mode 不是“更快”，而是“跳步骤”。
-
-## 4. 角色压缩方式
-
-推荐把单人职责映射成下面四个视角，而不是假装只存在“开发”：
-
-| 视角 | 你要回答的问题 |
-|------|----------------|
-| `tech-lead` | 为什么做、做多少、什么算完成、有什么风险 |
-| `engineer` | 具体怎么实现、怎么验证、边界怎么控制 |
-| `qa` | 哪些行为必须测、哪些风险可接受、什么情况下不放行 |
-| `devops` | 怎么发布、怎么回滚、观察什么、何时算上线稳定 |
-
-实际写文档时，不要求拆成 4 份 handoff，但要求这些视角都能在主链产物里找到。
-
-## 5. 推荐最短主链
-
-solo mode 的推荐路径是：
-
-1. `intake`
-2. `plan`
-3. `execute`
-4. `review`
-5. `release`
-6. `closeout`
-
-对应最小动作：
-
-| 阶段 | 最少要回答的事 |
-|------|----------------|
-| intake | 做什么、不做什么、成功标准是什么 |
-| plan | 方案怎么做、风险是什么、如何验证 |
-| execute | 改了什么、做了哪些验证、还有什么未完成 |
-| review | 是否达到可上线质量、剩余风险是否可接受 |
-| release | 如何发布、如何回滚、观察窗口看什么 |
-| closeout | 观察窗口结果、最终验收、遗留项和 lessons learned |
-
-## 6. 推荐产物
-
-如果项目仓库已经按主链落盘，solo mode 建议至少保留这些文件：
-
-- `docs/artifacts/.../prd.md`
-- `docs/artifacts/.../delivery-plan.md`
-- `docs/artifacts/.../execute-log.md`
-- `docs/artifacts/.../test-plan.md` 或等价验证记录
-- `docs/artifacts/.../release-plan.md`
-- `docs/artifacts/.../closeout-summary.md`
-
-其中 `closeout-summary.md` 负责承接发布后的观察窗口和最终状态，不要让这一步停留在聊天记录里。
-
-## 7. Release 后的观察窗口
-
-solo mode 最容易漏掉的是“上线成功”和“上线稳定”之间的区别。
-
-建议把观察窗口单独写清楚：
-
-- 起止时间
-- 观察指标
-- 告警阈值
-- 人工检查点
-- 升级/回滚条件
-
-closeout 只能在观察窗口结束后做。  
-如果观察窗口未结束，只能说“已发布”，不能说“已收口”。
-
-## 8. Closeout 要产出什么
-
-closeout 阶段至少回答四个问题：
-
-1. 本次发布最终是否成立
-2. 观察窗口内是否出现异常，以及如何处理
-3. 哪些遗留项要进入下一个版本或 backlog
-4. 这次交付有哪些 lessons learned
-
-可以直接参考 [team-closeout-example.md](team-closeout-example.md)。
-
-## 9. 和 Team Mode 的边界
-
-当出现下面任一情况时，solo mode 应升级回 Team Mode 或引入至少一次多人评审：
-
-- 需求反复变化，单人无法锁定边界
-- 有跨系统依赖，需要别人承诺配合
-- 有高风险发布动作，需要共同背书
-- 有合规、权限、数据安全等高风险决策
-
-solo mode 的目标是减少形式成本，不是把高风险决策私有化。
-
-## 10. 快速入口
-
-如果你想按一页纸最短路径执行，直接看 [solo-delivery-one-page.md](solo-delivery-one-page.md)。  
-如果你想把 solo mode 放进新项目接入流程，继续看 [project-onboarding.md](project-onboarding.md)。

package/docs/runbooks/solo-delivery-one-page.md

@@ -1,111 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-04-03
-updated: 2026-04-03
-owner: 工程团队
----
-
-# Solo Delivery One Page
-
-这一页给的是 solo mode 最短闭环。适合你已经知道需求大致方向，只需要一个不跳 gate 的执行路径。
-
-完整原则见 [solo-delivery-mode.md](solo-delivery-mode.md)。
-
-## 1. 一句话规则
-
-- 压缩角色，不压缩 gate
-- 发布不是结束，观察窗口结束后的 closeout 才是收口
-
-## 2. 最短路径
-
-1. `intake`
-2. `plan`
-3. `execute`
-4. `review`
-5. `release`
-6. `closeout`
-
-## 3. 每一步最少要做什么
-
-| 阶段 | 最少输入 | 最少输出 | 进入下一步前必须确认 |
-|------|----------|----------|----------------------|
-| intake | 需求、背景、约束 | 目标、范围、不做项、成功标准 | 需求边界不是模糊口号 |
-| plan | intake 结论 | 实现思路、风险、验证路径 | 知道怎么做，也知道怎么证明做对 |
-| execute | 已确认方案 | 代码/文档变更、执行记录、自测结果 | 没有把关键问题留给 review 才发现 |
-| review | execute 输出 | 放行意见、剩余风险、是否可上线 | “测试通过”与“可以上线”分开判断 |
-| release | review 结论 | 发布动作、回滚入口、观察窗口 | 已知看什么、谁来判断是否稳定 |
-| closeout | 发布结果、观察数据 | 最终结论、遗留项、lessons learned | 观察窗口已结束并完成状态收口 |
-
-## 4. Solo Mode 检查清单
-
-每次交付至少过这一轮：
-
-- 目标和不做项写清楚了
-- 验收标准不是口头默认
-- 已提前想好验证方法
-- 发布入口和回滚入口是明确的
-- 观察窗口有起止时间和指标
-- closeout 有最终结论和遗留项归档
-
-## 5. 什么时候不要继续往前
-
-出现这些情况时，先停下来补齐，而不是继续推进：
-
-- 还说不清这次到底交付什么
-- 设计方案没有收口，只是在边做边试
-- 没有回滚路径就准备发布
-- 观察窗口还没结束就想宣布完成
-
-## 6. 最小示例节奏
-
-```text
-intake
-目标：
-范围：
-不做：
-成功标准：
-```
-
-```text
-plan
-方案：
-关键风险：
-验证方法：
-```
-
-```text
-execute
-改动：
-自测：
-剩余问题：
-```
-
-```text
-review
-放行结论：
-剩余风险：
-是否允许进入 release：
-```
-
-```text
-release
-发布步骤：
-回滚步骤：
-观察窗口：
-关键指标：
-```
-
-```text
-closeout
-观察窗口结论：
-最终验收：
-遗留项：
-lessons learned：
-```
-
-## 7. 参考
-
-- [project-onboarding.md](project-onboarding.md)
-- [team-release-example.md](team-release-example.md)
-- [team-closeout-example.md](team-closeout-example.md)

package/docs/runbooks/specialist-commands-playbook.md

@@ -1,85 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Specialist 命令工作簿
-
-本文回答三个问题：何时用 specialist、用完之后怎么收口、什么时候不该用 specialist。若你先想看全局映射，配合阅读 [command-and-capability-matrix.md](command-and-capability-matrix.md)。
-
-## 1. 常用 specialist 命令
-
-| 命令 | 何时用 | 最小输入模板 | 常见回落位置 |
-|------|--------|--------------|--------------|
-| `/plan` | 任务复杂、阶段不清、依赖多 | 目标、约束、依赖、风险 | `/team-plan`、`/handoff` |
-| `/tdd` | 想先测后码、缩短返工 | 功能目标、现有缺口、边界行为 | `/team-execute`、`/handoff` |
-| `/code-review` | 代码已改完，要查回归/质量/风险 | 目标、改动摘要、关注点 | `/handoff`、`/team-review` |
-| `/build-fix` | 构建、lint、校验失败 | 失败现象、日志、预期产物 | `/team-execute`、`/handoff` |
-| `/verify` | 关键路径或放行前证据不足 | 当前结论、要验证的关键路径 | `/team-review`、`/team-release` |
-| `/multi-frontend` | 前端要从实现、UI/UX、QA 多视角并行分析 | intake 结果、关键断点、设计约束 | `/handoff`、`/team-plan` |
-| `/multi-backend` | 后端要从接口、权限、测试策略多视角并行分析 | intake / plan 结果、服务边界 | `/handoff`、`/team-plan` |
-| `/harness-audit` | 想审视平台本身的 agent/skill/hook/rule/doc 覆盖面 | 当前平台现状、关注维度 | 平台治理、文档补齐、后续收敛计划 |
-
-## 2. 何时用
-
-- 需要专项拆解：`/plan`
-- 想先定义测试和成功标准：`/tdd`
-- 需要前端多视角：`/multi-frontend`
-- 需要后端多视角：`/multi-backend`
-- 需要实现质量审查：`/code-review`
-- 需要构建修复：`/build-fix`
-- 需要补最终验证：`/verify`
-- 想知道平台能力面哪里还薄：`/harness-audit`
-
-## 3. 何时不用
-
-- 目标和范围还没锁定
-- 主链还没确定由谁收口
-- 你只是在用 specialist 替代思考和交接
-
-## 4. 回落规则
-
-所有 specialist 输出都应回到：
-
-- `/handoff`
-- `/team-execute`
-- `/team-review`
-
-最常用的回落提示：
-
-```text
-请把上面的专项结论整理为可直接进入 /handoff 的格式。
-```
-
-## 5. 和主链的关系
-
-- specialist 用于缩短专项分析路径
-- 主链负责最终责任和交付收口
-
-## 6. 常见组合
-
-- 新功能：`/team-plan` + `/plan`
-- 新功能想走测试先行：`/team-plan` + `/tdd`
-- 前端改造：`/team-plan` + `/multi-frontend`
-- 后端改造：`/team-plan` + `/multi-backend`
-- 代码改完：`/code-review`
-- 构建失败：`/build-fix`
-- 放行前补证据：`/verify`
-- 平台自检：`/harness-audit` -> 文档 / 命令 / skills 收口计划
-
-## 7. 不要什么时候用 `/harness-audit`
-
-- 不要把它当业务需求的 `/team-review`
-- 不要用它替代 `/verify` 的关键路径验证
-- 不要用它替代真实实现或 QA 放行
-
-它更适合做平台治理、能力面自检和“下一轮该补什么”的排序。
-
-## 8. 常见错误
-
-- specialist 跑得很多，handoff 却为空
-- 只把结论当建议，不转成结构化交付物
-- 把 specialist 当成主链角色替代

package/docs/runbooks/sub-agent-invocation-map.md

@@ -1,144 +0,0 @@
----
-version: "1.0.0"
-status: active
-created: 2026-04-02
-updated: 2026-04-17
-owner: 工程团队
-doc_tier: governance
-last_verified: 2026-04-17
-source_of_truth:
-  - ../../scripts/lib/team-skills-data.json
-  - ./agent-governance.md
----
-
-# 子 Agent 调用映射
-
-本文是当前平台 **唯一权威的调用映射来源**：明确每条命令触发哪个 agent、该 agent 可以调用哪些子 agent、以及贯穿全链路的管控约束。
-
-所有 agent（role + specialist）必须同时遵循 [agent-governance.md](../runbooks/agent-governance.md) 中的统一管控策略。
-
----
-
-## 1. 调用模型说明
-
-平台采用两层 agent 调用模型：
-
-```
-用户命令
-  └─ 主链 Role Agent（owner，对产出负最终责任）
-       ├─ 可调用 Specialist Agent（分析、评审、规划）
-       └─ 产出落盘到 docs/artifacts/ 或通过 /handoff 交接下游 Role Agent
-```
-
-- **Role Agent**：有主责输出、交接责任、需落盘
-- **Specialist Agent**：只产出建议，结论必须回落到 Role Agent 的输出中
-- **调用方式**：在 Claude 对话中明确说 `用 <agent-id> 角色执行`，或通过 `runSubagent` 工具调用（agent 名称对应 `agents/roles/` 或 `agents/specialists/` 中的文件名去掉 `.md`）
-
----
-
-## 2. 主链命令 → Role Agent 映射
-
-| 命令 | 调用 Role Agent | 可调用 Specialist | 典型输出 |
-|------|----------------|-------------------|----------|
-| `/team-intake` | `tech-lead` | `planner`（复杂需求拆解）、`ui-ux-designer`（涉及 UI 时提供初步体验约束） | `prd.md` + `requirement-challenge` 输入 |
-| `/team-plan` | `tech-lead` | `planner`、`architect`、`ui-ux-designer`、`project-manager`（动态分组讨论与挑战会） | `delivery-plan.md`、`arch-design.md`、`design-review` 结论 |
-| `/handoff` | 当前主责角色 | — | handoff 结构化记录，写入下游，推进到 `handoff-ready` |
-| `/team-execute` | `backend-engineer` 或 `frontend-engineer` | `planner`、`build-error-resolver`（遇到构建失败）、语言 reviewer（问题定位）、`loop-operator`（多轮验证） | `execute-log.md`，前提为 `handoff-ready` |
-| `/team-review` | `qa-engineer` | `code-reviewer`、`security-reviewer`、语言 reviewer、`tdd-guide` | `test-plan.md`，放行结论 |
-| `/team-release` | `devops-engineer` | `chief-of-staff`（跨角色同步）、`harness-optimizer`（平台审计） | `release-plan.md` |
-
----
-
-## 3. Specialist 命令 → Specialist Agent 映射
-
-| 命令 | 调用 Specialist Agent | 结论回落 |
-|------|-----------------------|----------|
-| `/plan` | `planner` | 回落到 `/team-plan` 或 `/handoff` |
-| `/tdd` | `tdd-guide` | 回落到 `/team-execute` 或 `/team-review` |
-| `/code-review` | `code-reviewer` | 回落到 `/team-review` 或 `/handoff` |
-| `/build-fix` | `build-error-resolver`（通用），或 `java-build-resolver`、`go-build-resolver`、`rust-build-resolver`、`python-reviewer`、`typescript-reviewer`、`kotlin-build-resolver`、`pytorch-build-resolver`（语言专项） | 回落到 `/team-execute` |
-| `/verify` | `loop-operator`、`tdd-guide` | 回落到 `/team-review` 或 `/team-execute` |
-| `/multi-frontend` | `planner` 编排，`frontend-engineer` 执行 | 回落到 `/team-execute` |
-| `/multi-backend` | `planner` 编排，`backend-engineer` 执行 | 回落到 `/team-execute` |
-| `/harness-audit` | `harness-optimizer` | 输出平台改进建议，更新 `docs/memory/` |
-
----
-
-## 4. Role Agent 之间的标准传递路径
-
-```
-product-manager
-      │ PRD、用户故事、UI/UX 约束摘要
-      ▼
-  tech-lead ◄────────────────────────── 所有冲突/升级
-      │ Delivery Plan、任务拆解
-      ├──────────────────────────────────────────┐
-      ▼                                          ▼
-  architect ──► frontend-engineer ◄── ui-ux-designer
-      │ ADR        │ 前端实现           │ 交互流、设计 token
-      │            │                    │ 体验风险清单
-      ▼            ▼                    │
-  backend-engineer ──────► qa-engineer ◄┘
-      │ 后端实现、自测       │ 测试计划、放行建议
-      │                    │
-      └────────────────────┼──► devops-engineer
-                           │         │ 发布方案、回滚
-                           ▼         ▼
-                       tech-lead（最终收口）
-```
-
-每次传递必须经过 `/handoff`，结构化字段见 [handoff-contract.md](../../rules/handoff-contract.md)。
-
----
-
-## 5. 并行调用场景
-
-以下场景允许多个 agent 并行调用，使用 `parallel-execution` skill 或 Git worktree 隔离：
-
-| 场景 | 并行 Agent 组合 | 汇总角色 |
-|------|----------------|----------|
-| 需求挑战会 | `product-manager` + `project-manager` + `architect` + `tech-lead` | `tech-lead` |
-| 四方并行设计 | `architect` + `ui-ux-designer` + `frontend-engineer` + `backend-engineer` | `tech-lead`（Design Review Board） |
-| 多服务后端 | 多个 `backend-engineer` 实例（按服务拆分） | `planner` 编排 → `tech-lead` 收口 |
-| 多模块前端 | 多个 `frontend-engineer` 实例（按页面拆分） | `planner` 编排 → `tech-lead` 收口 |
-| Build-fix 并行 | 多个语言 `build-resolver` 并发修复各模块 | `build-error-resolver` 汇总 |
-
-并行任务之间禁止写冲突；共享状态通过文件传递，由汇总角色负责合并。
-
-### 5.1 动态分组规则
-
-`/team-plan` 不能只按固定四方并行启动，必须按任务类型动态装配最小讨论组：
-
-| 任务特征 | 基础参与角色 | 增补角色 |
-|----------|--------------|----------|
-| 业务目标/范围不清 | `product-manager`、`project-manager`、`tech-lead` | `architect` |
-| 架构/接口/数据模型变更 | `architect`、`backend-engineer`、`project-manager`、`tech-lead` | `frontend-engineer`（若影响 UI） |
-| UI / 体验变更 | `product-manager`、`ui-ux-designer`、`frontend-engineer`、`tech-lead` | `architect`、`backend-engineer` |
-| 全栈改动 | `architect`、`frontend-engineer`、`backend-engineer`、`project-manager`、`tech-lead` | `ui-ux-designer`、`devops-engineer` |
-
-每个被拉入的角色都必须对上游输入提出至少 1 条质疑，并把结论回落到 `/team-plan` 或 `/handoff`。
-
----
-
-## 6. 单次 agent 调用的标准流程
-
-无论是 role agent 还是 specialist agent，每次调用都必须：
-
-1. **读取自身 agent 文件**：`agents/roles/<id>.md` 或 `agents/specialists/<id>.md`
-2. **确认管控约束**：遵循 [agent-governance.md](../runbooks/agent-governance.md)
-3. **确认输入依据**：来源 artifact、handoff 记录或用户输入
-4. **执行并产出**：按角色定义的标准输出
-5. **落盘或交接**：role agent 必须落盘；specialist agent 结论回落到 role agent 输出
-6. **升级判断**：命中升级条件时，立即通知 `tech-lead`
-
----
-
-## 7. 相关文档
-
-- [agent-governance.md](../runbooks/agent-governance.md)：统一管控策略（所有 agent 必读）
-- [handoff-contract.md](../../rules/handoff-contract.md)：交接字段要求
-- [handoff-governance.md](../runbooks/handoff-governance.md)：全量 Handoff 流程图与交接矩阵
-- [artifact-persistence.md](../runbooks/artifact-persistence.md)：落盘约定
-- [parallel-execution-usage.md](../runbooks/parallel-execution-usage.md)：并行执行指南
-- [ecc-harness-usage.md](../runbooks/ecc-harness-usage.md)：ECC 层使用说明
-- [team-command-output-contracts.md](../runbooks/team-command-output-contracts.md)：命令输出字段定义

package/docs/runbooks/system-architecture-design-walkthrough.md

@@ -1,49 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 系统架构设计与 ADR 演练
-
-本文演示一个中等以上复杂度任务如何完成架构设计、ADR 决策和跨角色交接。重点不是细节实现，而是把设计结论变成可执行输入。
-
-## 1. 场景
-
-- 任务：审批中心要接入新的数据权限判断链路
-- 涉及：接口边界、权限判定、跨服务依赖、兼容性
-- 目标：在实施前把关键决策写清楚
-
-## 2. 推荐链路
-
-1. `/team-intake`
-2. `/team-plan`
-3. `/plan` 或 `/multi-backend`
-4. `/handoff`
-5. `/team-review`
-
-## 3. 关键输出
-
-- 方案摘要
-- ADR 或等价决策记录
-- 服务边界与关键依赖
-- 接口与兼容性约束
-- 实施阶段需要特别关注的风险
-
-如果需要结构化 ADR，直接按 [artifact-standards.md](../../rules/artifact-standards.md) 中的 ADR 最小字段组织：决策信息、背景与约束、备选方案、决策结果、企业内控补充、后续动作。
-
-## 4. 合格结果的检查点
-
-- 研发能基于方案直接拆实施任务
-- QA 知道应验证哪些关键边界
-- Tech Lead 能看出是否需要升级风险等级
-
-## 5. 常见错误
-
-- 只描述理想状态，不写迁移路径
-- 把实现细节和架构决策混在一起
-- 方案里没有明确舍弃什么
-
-与这些文档配合阅读：[architect-daily-operations.md](architect-daily-operations.md)、[team-command-output-contracts.md](team-command-output-contracts.md)

package/docs/runbooks/team-closeout-example.md

@@ -1,73 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-04-03
-updated: 2026-04-03
-owner: 工程团队
----
-
-# Team Closeout 完整示例
-
-本文给出 closeout 阶段的完整示例。它关注的是“发布后如何收口”，不是替代发布方案本身。发布前动作仍然应先参考 [team-release-example.md](team-release-example.md)。
-
-## 1. 场景
-
-- 导出能力已经灰度上线
-- 发布时定义了 30 分钟观察窗口
-- 现在需要给出最终状态、遗留项和下一步建议
-
-## 2. 输入示例
-
-```text
-closeout
-基于当前发布结果和观察窗口数据，整理最终状态、遗留项和 lessons learned。
-```
-
-## 3. 完整输出示例
-
-```text
-Closeout 结论
-- 发布对象：审批列表导出能力
-- 发布时间：2026-04-03 14:00
-- 观察窗口：14:00 - 14:30
-- 最终状态：成立，本次发布完成收口
-
-观察窗口结果
-- 导出成功率：稳定，高于预期阈值
-- 接口错误率：未出现异常峰值
-- 前端反馈时延：可接受，无明显卡顿投诉
-- 人工抽检：导出文件字段、权限控制、空数据提示均符合预期
-
-最终验收声明
-- 验收结论：通过
-- 验收依据：测试放行结论 + 观察窗口指标 + 人工抽检结果
-- 仍接受的风险：大批量导出性能尚未做极限压测，但不影响当前灰度范围
-
-遗留项与后续动作
-- 遗留项 1：补一次 5 万条数据的导出压测
-- 遗留项 2：增加导出超时提示文案
-- 进入 backlog：是
-- 建议优先级：中
-
-Lessons Learned
-- 本次先定义观察窗口再上线，明显减少了上线后判断分歧
-- 发布前增加前端空数据抽检，有效避免了只盯接口成功率
-- 下次应在 release 前就准备大数据量压测记录
-```
-
-## 4. Closeout 最少应包含什么
-
-- 观察窗口起止时间
-- 观察结果与异常结论
-- 最终验收结论
-- 遗留项与是否进入 backlog
-- lessons learned
-
-## 5. 常见错误
-
-- 把 release 结论直接当成 closeout 结论
-- 观察窗口未结束就宣布完成
-- 只写“已上线”，不写最终验收和遗留项
-- 已知风险没有进入后续待办
-
-如果你是在 solo mode 下执行 closeout，建议同时参考 [solo-delivery-mode.md](solo-delivery-mode.md) 和 [solo-delivery-one-page.md](solo-delivery-one-page.md)。