@colin4k1024/tsp 2.4.0

package/rules/README.md

@@ -0,0 +1,31 @@
+# Rules Catalog
+
+本目录承载两层规则：
+
+- 平台专属规则：`team-operating-model.md`、`handoff-contract.md`、前端治理规则等
+- ECC harness 规则包：`common/` 与语言分层规则目录
+- 公司领域扩展技能通过 `skills/` 接入时，仍以本目录规则作为主链治理基线
+
+## 使用方式
+
+1. 默认团队协作先遵循平台专属规则和 `/team-*` 命令。
+2. 当启用 specialist agents、ECC commands 或 `skills/` 时，再引入 `common/` 与语言规则包。
+3. 当启用 `skills/` 时，先遵循平台专属规则，再按领域 skill 的附加约束执行。
+4. 当引入开源 skill 或工程实践时，先按 [external-capability-intake.md](../docs/runbooks/external-capability-intake.md) 完成 intake，再决定是否进入 `skills/`、`skills/` 或 `docs/runbooks/`。
+5. 若规则冲突，以平台专属交接与治理规则为准，由 `tech-lead` 仲裁。
+
+## 规则分层
+
+- `common/`：所有 specialist 和精选技能共用的工程规则
+- `typescript/`：TypeScript / JavaScript / 前端专项规则
+- `java/`：Java / Spring Boot / JPA 专项规则
+- `python/`：Python 专项规则
+- `golang/`：Go 专项规则
+
+## 入口建议
+
+- 通用工程治理：见 [common/README.md](common/README.md)、[common/coding-style.md](common/coding-style.md)、[common/testing.md](common/testing.md)
+- 企业架构治理：见 [common/enterprise-architecture-governance.md](common/enterprise-architecture-governance.md)、[common/enterprise-component-baseline.md](common/enterprise-component-baseline.md)
+- specialist 编排：见 [common/agents.md](common/agents.md)、[common/hooks.md](common/hooks.md)
+- 前端与 TypeScript：见 [typescript/frontend.md](typescript/frontend.md)
+- Java / Spring：见 [java/enterprise-java.md](java/enterprise-java.md)、[java/database.md](java/database.md)、[java/redis.md](java/redis.md)、[java/springboot.md](java/springboot.md)、[java/jpa.md](java/jpa.md)

package/rules/artifact-standards.md

@@ -0,0 +1,139 @@
+# Artifact Standards
+
+## 标准交付物
+
+| 交付物 | 模板 | 主责角色 | 存储路径（消费方仓库） |
+|--------|------|----------|------------------------|
+| PRD | 本文最小字段要求 | `product-manager` | `docs/artifacts/{slug}/prd.md` |
+| Delivery Plan | 本文最小字段要求 | `project-manager` | `docs/artifacts/{slug}/delivery-plan.md` |
+| Arch Design | 本文最小字段要求 | `architect` | `docs/artifacts/{slug}/arch-design.md` |
+| ADR | 本文最小字段要求 | `architect` | `docs/adr/ADR-{NNN}-{title}.md` |
+| API Contract | `templates/api-contract.md` | `architect` / `backend-engineer` | `docs/artifacts/{slug}/api-contract.md` |
+| Execute Log | 本文最小字段要求 | `backend-engineer` / `frontend-engineer` | `docs/artifacts/{slug}/execute-log.md` |
+| Design System Brief | `templates/design-system-brief.md` | `tech-lead` / `frontend-engineer` | `docs/artifacts/{slug}/` |
+| UI Implementation Plan | `templates/ui-implementation-plan.md` | `frontend-engineer` | `docs/artifacts/{slug}/` |
+| Test Plan | 本文最小字段要求 | `qa-engineer` | `docs/artifacts/{slug}/test-plan.md` |
+| Deployment Context | `templates/deployment-context.md` | `devops-engineer` / `tech-lead` | `docs/artifacts/{slug}/deployment-context.md` |
+| Launch Acceptance | `templates/launch-acceptance.md` | `qa-engineer` / `tech-lead` | `docs/artifacts/{slug}/launch-acceptance.md` |
+| UI Review Checklist | `templates/ui-review-checklist.md` | `frontend-engineer` / `qa-engineer` | `docs/artifacts/{slug}/` |
+| Release Plan | `templates/release-plan.md` | `devops-engineer` | `docs/artifacts/{slug}/release-plan.md` |
+| Closeout Summary | `templates/closeout-summary.md` | `tech-lead` / `devops-engineer` | `docs/artifacts/{slug}/closeout-summary.md` |
+| Backlog Snapshot | `templates/backlog-snapshot.md` | `tech-lead` / `project-manager` | `docs/memory/backlog.md`（持续更新） |
+| Incident Brief | 本文最小字段要求 | `tech-lead` / `devops-engineer` | `docs/artifacts/{slug}/` |
+| Project Context | 最小字段：项目名 / tech stack / 当前任务 / 风险 | `tech-lead` | `docs/memory/project-context.md`（覆盖更新） |
+| Decisions Log | 最小字段：日期 / 决策标题 / 背景 / 决策 / 影响 | `backend-engineer` / `architect` | `docs/memory/decisions.md`（追加） |
+| Lessons Learned | 最小字段：日期 / 标题 / 场景 / 问题 / 建议 | `qa-engineer` / `devops-engineer` | `docs/memory/lessons-learned.md`（追加） |
+| Session Summary | 最小字段：链路起止 / 任务 / 产出 / 遗留事项 | `devops-engineer` / `tech-lead` | `docs/memory/sessions/{YYYY-MM-DD}-{NNN}-{slug}.md` |
+
+## 编写要求
+
+- 结论先行，假设与风险显式列出。
+- 使用中文说明，保留必要英文技术名词。
+- 若启用文档架构能力，必须严格映射到现有 artifact 文件，不新增平行主目录作为交付事实源。
+- 能复用现有模板时不重新发明结构；PRD、Delivery Plan、Test Plan、Incident Brief 直接按本文字段生成。
+- 任何跨角色交接产物都要可直接被下游执行。
+- `/team-*` 主链命令的输出结构统一遵循 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)；涉及 role handoff 时，再叠加 [handoff-contract.md](handoff-contract.md) 的字段要求。
+- **所有产物必须持久化到文件**：`/team-*` 命令执行完毕后，按 [artifact-persistence.md](../docs/runbooks/artifact-persistence.md) 约定写入消费方项目仓库，不允许仅在对话中输出。
+- 涉及前端变更时，至少补齐设计系统摘要、实现计划或 UI 评审清单中的一项；进入 QA 前必须有 `templates/ui-review-checklist.md` 证据。
+- 进入正式发布前，至少应存在 `deployment-context.md` 与 `launch-acceptance.md`；solo mode 下也不能把这两类事实压缩进对话。
+- 发布后进入收口阶段时，必须产出 `closeout-summary.md`，并同步更新 `docs/memory/backlog.md` 承接遗留项、技术债和下一阶段候选。
+- ADR 至少包含：决策信息、背景与约束、备选方案、决策结果、企业内控补充、后续动作。
+- Release Plan 至少包含：发布信息、变更与风险、执行步骤、验证与监控、回滚方案、放行结论。
+
+### 文档能力映射规则
+
+- Project Profile Card 回落到 `prd.md` 的背景 / 约束与 `delivery-plan.md` 的版本目标。
+- Service Catalog、Communication Matrix、NFR Summary 回落到 `arch-design.md`，必要时在 `api-contract.md` 细化。
+- API、事件、鉴权契约回落到 `api-contract.md` 与 `docs/adr/`。
+- 一致性审计结果回落到 `test-plan.md` 的风险与放行建议，阻塞项必须可追溯到具体 artifact。
+- 部署、配置、密钥、值守和回滚入口统一回落到 `deployment-context.md`，发布决策与执行步骤回落到 `release-plan.md`。
+- 上线准入结论回落到 `launch-acceptance.md`，不能只写在 `test-plan.md` 或 `release-plan.md` 的尾部。
+- 发布后观察、收口判断和 backlog 回填统一回落到 `closeout-summary.md`、`docs/memory/backlog.md` 和 `docs/memory/sessions/*.md`。
+
+## 通用文档最小字段
+
+### PRD
+
+- 背景：业务问题、触发原因、当前约束。
+- 目标与成功标准：业务目标、用户价值、成功指标。
+- 用户故事：至少包含用户故事和可验证的验收标准。
+- 范围：In Scope、Out of Scope。
+- 风险与依赖：关键依赖、风险、待确认项。
+
+### Delivery Plan
+
+- 版本目标：版本或里程碑、范围说明、放行标准。
+- 工作拆解：工作项、主责角色、依赖、计划时间。
+- 风险与缓解：风险、影响、缓解措施、Owner。
+- 节点检查：方案评审、开发完成、测试完成、发布准备。
+
+### Arch Design
+
+- 系统边界：外部依赖、集成点、边界内外划分。
+- 组件拆分：主要模块 / 服务及其职责。
+- 关键数据流：核心路径的数据流转，可用 Mermaid。
+- 接口约定：主要 API 入口、协议、认证方式。
+- 技术选型：关键语言、框架、中间件选择及原因。
+- 风险与约束：已知技术风险和上线前必须解决的约束。
+
+### ADR
+
+- 决策信息：编号、决策标题、状态、日期、Owner、关联需求或命令入口。
+- 背景与约束：当前问题、业务目标、约束条件、非目标。
+- 备选方案：选项、适用条件、优点、风险或成本、不选原因。
+- 决策结果：采用方案、原因、影响范围、兼容性或迁移影响、失败或回退思路。
+- 企业内控补充：应用等级、技术架构等级、关键组件或平台偏离、资产文档入口。
+- 后续动作：需要同步的文档、需要通知的角色、Owner、完成条件。
+
+### Execute Log
+
+- 计划 vs 实际：原计划完成哪些，实际完成哪些，偏差原因。
+- 关键决定：实施过程中做出的技术决定。
+- 阻塞与解决：遇到的阻塞、根因和最终解决方式。
+- 影响面：涉及的模块、接口、数据库、配置。
+- 未完成项：因范围或时间调整而延后的内容。
+
+### Test Plan
+
+- 测试范围：功能范围、非功能范围、不覆盖项。
+- 测试矩阵：场景、类型、前置条件、预期结果。
+- 风险：高风险路径、回归关注点、数据准备。
+- 放行建议：是否建议放行、阻塞项、补充验证。
+
+### Deployment Context
+
+- 环境清单：各环境用途、访问入口、部署目标。
+- 部署入口：主入口、手工入口、回退入口、前置条件。
+- 配置与密钥：环境变量、配置项、密钥来源、访问方式。
+- 运行保障：feature flag、灰度控制、监控、告警、值守安排、观察窗口。
+- 恢复能力：回滚触发条件、回滚路径、验证方法。
+
+### Launch Acceptance
+
+- 验收概览：对象、时间、角色、验收方式。
+- 验收范围：业务、技术、非功能边界与不在范围内项。
+- 验收证据：测试结果、关键 artifact、关键环境。
+- 风险判断：已满足项、可接受风险、阻塞项。
+- 上线结论：是否允许上线、前提条件、观察重点、确认记录。
+
+### Closeout Summary
+
+- 收口对象：关联任务、release、观察窗口、收口角色。
+- 结果判断：发布后观察结果、目标达成情况、当前状态判断。
+- 残余事项：遗留项、残余风险、是否需要补丁或再次发布。
+- 知识沉淀：lessons learned、后续 owner、回看时间。
+- Backlog 回填：必须标明是否已同步到 `docs/memory/backlog.md`。
+
+### Backlog Snapshot
+
+- 快照信息：来源任务、更新时间、更新角色。
+- 事项分类：未完成项、发布后遗留项、技术债、下一阶段候选。
+- 排序信息：优先级、触发条件、建议处理阶段。
+- 真相源：跨任务以 `docs/memory/backlog.md` 为准，不再只存在于 release 备注或对话。
+
+### Incident Brief
+
+- 事件概览：事件编号、发现时间、影响范围、当前状态。
+- 初步判断：现象、疑似原因、临时止血措施。
+- 协作分工：角色、负责人、当前动作。
+- 后续动作：下一次同步时间、需升级的问题、复盘要求。

package/rules/common/README.md

@@ -0,0 +1,9 @@
+# Common Rules
+
+本目录承载所有 specialist 与共享技能都会复用的工程规则。
+
+## 入口
+
+- 协作与工作流：`agents.md`、`hooks.md`、`patterns.md`、`git-workflow.md`
+- 通用质量基线：`coding-style.md`、`testing.md`、`security.md`、`performance.md`
+- 企业治理补充：`enterprise-architecture-governance.md`、`enterprise-component-baseline.md`

package/rules/common/agents.md

@@ -0,0 +1,19 @@
+# Common Agents
+
+## 何时使用 specialist
+
+- 任务需要专业视角，但还不应打断主团队角色的责任边界。
+- 需要更细颗粒度的规划、review、验证或 build 归因。
+- 多角色并行任务需要一个中间编排层降低上下文噪音。
+
+## 何时不用 specialist
+
+- 问题很简单，主责角色可以直接完成。
+- specialist 结论不能改变当前路径，只会增加来回传递成本。
+- 当前任务缺少最基本的输入，先回到 `tech-lead` 补齐上下文。
+
+## 协作红线
+
+- specialist 不替代 `tech-lead` 仲裁。
+- specialist 不对未验证的结论作最终承诺。
+- 所有关键结论必须回落到 role handoff 或 `/team-*` 命令。

package/rules/common/coding-style.md

@@ -0,0 +1,20 @@
+# Common Coding Style
+
+## 核心原则
+
+- 先保证可读性、可验证性和变更边界清晰，再追求抽象和“优雅”。
+- 小步修改、结论先行，避免一次提交多种不相干重构。
+- 命名表达意图，不把上下文藏进缩写和模糊术语。
+- 结构优先于技巧；能直写清楚的逻辑，不用炫技式压缩。
+
+## 文件与模块
+
+- 一个文件只承载一个主职责，避免既定义协议又处理 IO 又做格式转换。
+- 复杂逻辑拆成可验证的小单元，公共逻辑优先沉淀到稳定边界。
+- 变更要附带影响面说明，帮助 reviewer 快速判断风险。
+
+## Review 红线
+
+- 未处理错误路径、边界态或回滚路径。
+- 为了短期快而引入隐式耦合或难以追溯的副作用。
+- 没有验证依据，却宣称“应该没问题”。

package/rules/common/development-workflow.md

@@ -0,0 +1,45 @@
+# Development Workflow
+
+> This file extends [common/git-workflow.md](./git-workflow.md) with the full feature development process that happens before git operations.
+
+The Feature Implementation Workflow describes the development pipeline: research, planning, TDD, code review, and then committing to git.
+
+## Feature Implementation Workflow
+
+0. **Research & Reuse** _(mandatory before any new implementation)_
+   - **GitHub code search first:** Run `gh search repos` and `gh search code` to find existing implementations, templates, and patterns before writing anything new.
+   - **Library docs second:** Use Context7 or primary vendor docs to confirm API behavior, package usage, and version-specific details before implementing.
+   - **Exa only when the first two are insufficient:** Use Exa for broader web research or discovery after GitHub search and primary docs.
+   - **Check package registries:** Search npm, PyPI, crates.io, and other registries before writing utility code. Prefer battle-tested libraries over hand-rolled solutions.
+   - **Search for adaptable implementations:** Look for open-source projects that solve 80%+ of the problem and can be forked, ported, or wrapped.
+   - Prefer adopting or porting a proven approach over writing net-new code when it meets the requirement.
+
+1. **Plan First**
+  - Use **planner** agent to create implementation plan
+  - Generate planning docs before coding: PRD, architecture, system_design, tech_doc, task_list
+  - Identify dependencies and risks
+  - Break down into phases
+  - Do not enter implementation until the relevant plan is `handoff-ready` and upstream challenge / design review evidence exists
+
+2. **TDD Approach**
+   - Use **tdd-guide** agent
+   - Write tests first (RED)
+   - Implement to pass tests (GREEN)
+   - Refactor (IMPROVE)
+   - Verify 80%+ coverage
+
+3. **Code Review**
+   - Use **code-reviewer** agent immediately after writing code
+   - Address CRITICAL and HIGH issues
+   - Fix MEDIUM issues when possible
+
+4. **Commit & Push**
+   - Detailed commit messages
+   - Follow conventional commits format
+   - See [git-workflow.md](./git-workflow.md) for commit message format and PR process
+
+5. **Pre-Review Checks**
+   - Verify all automated checks (CI/CD) are passing
+   - Resolve any merge conflicts
+   - Ensure branch is up to date with target branch
+   - Only request review after these checks pass

package/rules/common/enterprise-architecture-governance.md

@@ -0,0 +1,40 @@
+# Enterprise Architecture Governance
+
+## 来源
+
+本规则由企业原始规范整理而来，当前仓库以本文件作为可执行口径，不再依赖 `规范合集/` 目录作为生效范围。
+
+## 规划前置
+
+- 企业内部应用在 `/team-intake`、`/team-plan` 或 ADR 阶段，必须先判断业务评定等级、底线评定等级，并以更高等级作为最终应用等级。
+- 需要显式确认是否属于主营业务主链路、是否要求 `7x24`、是否涉及敏感数据/跨境数据/监管风险；无法确认时按更高风险等级处理。
+- 方案阶段要先确认所属领域分类和治理模式；如果分委会边界不清晰，默认按“统一规则、统一能力、资产可视可控”的更严口径设计。
+
+## T1-T4 基线
+
+- `T1`：在 `T2` 基础上进一步强调关键资源独占或强隔离，核心中间件、数据库、缓存、注册/配置等要有独立容量与回滚准备。
+- `T2`：在 `T3` 基础上强调多实例、集群、高可用与跨机房/跨地域能力，发布与容灾策略不能只靠单点部署。
+- `T3`：必须具备限流、熔断、扩缩容、多版本冗余、统一技术栈/运行环境/中间件/能力底座，并完成资产可视可控接入。
+- `T4`：可以简化架构复杂度，但不能绕过安全、合规、审计、可回滚这些底线要求。
+
+## 统一架构约束
+
+- 架构设计默认遵循 `IAAS / PAAS / SAAS / BAAS` 的分层思路，下层提供稳定能力，上层只组合和扩展，不重复造底座。
+- 默认使用集团认可的 PAAS、能力底座、技术底座和中间件，不私自新增未经评审的自建平台或非稳定版本依赖。
+- 涉及前端时，要明确统一框架选型、基础组件库、数据流方案和兼容性基线；涉及后端时，要明确统一运行环境、统一中间件与统一可观测接入。
+- 任何偏离集团标准组件或部署方式的方案，都必须通过 ADR 记录原因、替代方案、风险和回退路径。
+
+## 资产可视可控
+
+- 进入开发前至少要能追溯应用等级、ADR、接口契约、代码仓、部署架构图与负责人。
+- 进入联调或发布前，`T1-T3` 应用必须补齐 TA/技术架构图、接口文档、部署架构图、监控/日志/告警接入信息。
+- 资产文档要和真实部署保持同步；“先上线，后补图”不视为合格交付。
+- 企业内部应用的 ADR 与 Release Plan，统一使用模板中的“企业内控补充（按需填写）”区块承载应用等级、技术架构等级、关键组件偏离、资源隔离和资产文档入口。
+
+## 角色要求
+
+- `tech-lead`：判断等级、冲突和偏离是否需要升级仲裁。
+- `architect`：把等级要求落到部署、组件、数据、观测和回滚方案里。
+- `backend-engineer` / `frontend-engineer`：按统一栈实现，不默认跳过集团底座和公共能力。
+- `qa-engineer`：验证等级对应的高可用、观测、隔离和回滚证据是否真实存在。
+- `devops-engineer`：把资源隔离、发布窗口、回滚和监控项写进发布方案，而不是口头承诺。

package/rules/common/enterprise-component-baseline.md

@@ -0,0 +1,35 @@
+# Enterprise Component Baseline
+
+## 来源
+
+本规则由企业原始规范整理而来，当前仓库以本文件作为可执行口径，不再依赖 `规范合集/` 目录作为生效范围。
+
+## 选型原则
+
+- 默认优先使用集团已经批准的组件、版本、基础平台和公共能力，不重复建设同类底座。
+- 新增中间件、框架、基础设施或组件版本前，先确认集团是否已有同类能力；若已有能力，优先复用而不是自建。
+- 与集团组件规范不一致的选型，必须通过 ADR 说明业务原因、维护责任人、升级策略和退场路径。
+
+## 典型基线示例
+
+以下版本用于提示当前平台默认参考方向，精确版本仍以原始规范正文为准：
+
+| 类别 | 典型基线 |
+|------|----------|
+| Java 运行时 | `jdk-8u202`、`openjdk11` |
+| 微服务套件 | `Spring Cloud Greenwich / Hoxton` |
+| 流量治理 | `Sentinel 1.7` |
+| 配置中心 | `Apollo 1.7.x` |
+| 关系型数据库 | `MySQL 8.0.4` |
+| 操作系统 | `CentOS 7.9+`，Windows 仅在必要情况下使用并明确 License 责任 |
+
+## 公共能力约束
+
+- 统一账号、权限、配置、日志、调度、OpenAPI、静态资源、AI/数据平台等公共能力，默认优先走集团平台能力。
+- 禁止为了局部便利引入私有网关、私有注册中心、私有配置中心或同类重复组件，导致后续资产不可控。
+- 前端兼容性保障、体验数据统计、质量监控等能力如果集团已有通用方案，优先复用，不单独造轮子。
+
+## 交付要求
+
+- 任何组件选型都要明确版本、用途、归属团队、监控方式和升级窗口。
+- `T1-T3` 应用在发布前应留下组件清单，确保运行环境、镜像、依赖和平台能力可以审计。

package/rules/common/git-workflow.md

@@ -0,0 +1,15 @@
+# Common Git Workflow
+
+## 提交原则
+
+- 提交要围绕单一意图组织，标题能直接说明“做了什么、为什么”。
+- 先有可验证结果，再提交；不要把明显未完成的半状态混进主提交。
+- 当改动影响文档、规则、命令或 skills 时，一并更新相关入口。
+
+## Review 与 PR
+
+- PR 描述应包含目标、风险、验证命令和文档影响。
+- reviewer 优先指出行为回归、风险和缺测，不围绕风格争吵。
+- 若 specialist 给出建议，最终决策仍由主责角色和 `tech-lead` 收口。
+- 需要 worktree 并行隔离、PR 收口或分支清理时，参考 [git-pr-workflow.md](../../docs/runbooks/git-pr-workflow.md)。
+- 若仓库希望把依赖升级从手工处理转成持续发现、分批 triage 和可控自动化，参考 [dependency-update-automation.md](../../docs/runbooks/dependency-update-automation.md)。

package/rules/common/hooks.md

@@ -0,0 +1,13 @@
+# Common Hooks
+
+## 当前策略
+
+- 本仓库的 hooks skeleton 以“先有结构、后启用”为原则。
+- `hooks/hooks.json` 默认禁用，不要求 Node 运行时。
+- Python 占位脚本只提供接口契约和启用说明，不默认执行副作用。
+
+## 启用门槛
+
+- 明确触发事件、输入输出、失败回退与禁用策略。
+- 对每个 hook 说明它是“提示类”“持久化类”还是“阻断类”。
+- 不把必须成功的核心流程绑定到尚未验证的 hook 上。

package/rules/common/patterns.md

@@ -0,0 +1,14 @@
+# Common Patterns
+
+## 规划模式
+
+- 先收敛目标、边界和验证标准，再进入实现。
+- 多模块任务先拆依赖，再拆代码；多角色任务先拆交接，再拆文件。
+- 复杂改动优先采用“先骨架、后细化、最后验证”的节奏。
+- 企业内部应用在规划时先判断应用等级、架构等级和集团组件约束，再决定实现路径与交付节奏。
+
+## 交付模式
+
+- specialist 产出建议，role agent 产出承诺与最终交接。
+- 任何多阶段工作流都要显式列出阶段完成条件和升级点。
+- 当方案存在多个合理路线时，记录取舍而不是伪装成唯一正确答案。

package/rules/common/performance.md

@@ -0,0 +1,13 @@
+# Common Performance
+
+## 工作方式
+
+- 先识别真正的性能瓶颈，再决定是否需要 specialist 或更重工具链。
+- 控制上下文与任务规模，避免无差别把所有文件塞进同一轮分析。
+- 在 harness 层优先减少重复工作、重复搜索和重复验证。
+
+## 代码与流程
+
+- 大改动前先做最小可行验证，避免先写一大轮再发现方向错。
+- 产出中明确说明慢点、热点和可能的缓存/批处理机会。
+- 不为了“理论上更快”牺牲可读性和正确性。

package/rules/common/quality-gates-taxonomy.md

@@ -0,0 +1,96 @@
+# Quality Gates Taxonomy
+
+## 来源
+
+融合 GSD gates 分类法与 Team Skills Platform 现有质量门禁（前端门禁、handoff 契约、放行机制），
+统一为四类 gate，使所有角色和 `/team-*` 命令使用一致的门禁语言。
+
+## 分类
+
+### Pre-flight Gate（预飞检查）
+
+在进入某个阶段**之前**必须满足的条件。不满足则不允许进入。
+
+| 阶段入口 | 典型检查项 |
+|----------|-----------|
+| `/team-plan` | intake 完成、PRD 存在、关键待确认项已收敛 |
+| `/team-execute` | plan 完成、handoff 状态为 `handoff-ready`、接口契约已锁定 |
+| `/team-review` | 代码自测通过、execute-log 已写入、UI review checklist（若前端）已提交 |
+| `/team-release` | 测试计划执行完毕、放行建议为"建议放行"、deployment-context 已就绪 |
+
+### Revision Gate（修订门禁）
+
+发现问题后**要求修改**但不阻塞整条链路的检查。
+
+- 代码 review 中的 MEDIUM 级别问题
+- 文档不完整但不影响理解的补充项
+- 非阻塞的前端体验优化建议
+- 非阻塞的性能改进建议
+
+处理方式：标记为待修改、指定 owner，在当前阶段内或下一迭代中解决。
+
+### Escalation Gate（升级门禁）
+
+发现的问题超出当前角色决策范围，需要**升级给 tech-lead 或更高层级**。
+
+- 需求范围、优先级或时间目标发生冲突
+- 两个及以上角色对方案或质量结论不一致
+- 跨团队依赖或外部阻塞
+- 安全漏洞或合规风险超出预设等级
+- 线上故障影响范围扩大
+
+升级信息见 `rules/escalation-policy.md`。
+
+### Abort Gate（中止门禁）
+
+问题严重到必须**停止当前流程**，不允许继续推进。
+
+- 发现 CRITICAL 级别安全漏洞（合并前必须修复）
+- 发现数据丢失或不可逆损害风险
+- 关键依赖不可用且无替代方案
+- 测试结果与需求严重不符
+- 前端一票否决项命中（见 `rules/frontend-quality-gates.md`）
+
+触发 abort 后：
+1. 立即停止当前流程
+2. 通知 `tech-lead` 和相关角色
+3. 记录 abort 原因和影响面
+4. 确定恢复路径后才可重新启动
+
+## 与现有规则的映射
+
+| 现有规则 | 对应 Gate 类型 |
+|---------|---------------|
+| `handoff-contract.md` 中的 `就绪状态: blocked` | Abort Gate |
+| `handoff-contract.md` 中的 `就绪状态: not-ready` | Pre-flight Gate |
+| `frontend-quality-gates.md` 中的一票否决项 | Abort Gate |
+| `frontend-quality-gates.md` 中的 `/team-execute` 门禁 | Pre-flight Gate |
+| `escalation-policy.md` 中的升级场景 | Escalation Gate |
+| 代码 review 中的 CRITICAL/HIGH | Abort Gate |
+| 代码 review 中的 MEDIUM | Revision Gate |
+| 代码 review 中的 LOW | 信息提示（不构成 gate） |
+
+## 使用方式
+
+### 在 `/team-*` 命令中
+
+每个 `/team-*` 命令应在标准输出中包含门禁检查结果：
+
+```
+## 门禁状态
+- Pre-flight: ✅ 全部通过 / ❌ {未满足项}
+- Revision: {N} 项待修改
+- Escalation: {N} 项需升级
+- Abort: ✅ 无阻塞 / 🛑 {阻塞项}
+```
+
+### 在 Handoff 中
+
+handoff 的 `就绪状态` 字段与 gate 的关系：
+
+| 就绪状态 | Gate 含义 |
+|---------|----------|
+| `handoff-ready` | Pre-flight 全部通过、无 Abort |
+| `ready-for-review` | Pre-flight 通过但有 Revision 待处理 |
+| `blocked` | 存在 Abort Gate 或未解决的 Escalation |
+| `not-ready` | Pre-flight 未通过 |

package/rules/common/security.md

@@ -0,0 +1,33 @@
+# Common Security
+
+## 默认检查点
+
+- 认证、授权、输入处理、敏感数据、依赖来源、日志暴露。
+- 依赖升级、新增包、漏洞等级和许可证变化要能被追溯。
+- 仓库级 secret scanning 若已启用，也要能追溯新增命中、baseline 记录、误报 triage 和泄漏后的旋转/撤销动作。
+- 代码级语义安全扫描结果若已启用，也要能追溯其 triage 结论和阻塞策略。
+- GitHub Actions token 权限基线若已启用，也要能追溯默认 workflow 权限、job 级 `permissions`、例外 scope 和收敛结论。
+- IaC 安全与合规预检若已启用，也要能追溯其规则来源、命中项、例外处理和是否阻塞当前变更。
+- Kubernetes manifest schema 校验若已启用，也要能追溯目标版本、schema 来源、CRD 覆盖范围和被跳过的资源类型。
+- Kubernetes 原生策略引擎若已启用，也要能追溯策略范围、`Audit/Enforce` 状态、background scan 结果、policy reports 和例外处理。
+- 容器镜像、仓库文件系统和 IaC 扫描结果若已启用，也要能追溯其 triage 结论和放行策略。
+- 仓库级供应链基线检查若已启用，也要能追溯其 triage 结论、整改计划和是否阻塞当前变更。
+- GitHub Actions workflow 级语法 / 结构 lint 若已启用，也要能追溯其命中项、修复结论和是否阻塞合并。
+- GitHub Actions workflow 安全审计若已启用，也要能追溯其 triage 结论、误报处理和是否阻塞当前变更。
+- GitHub Actions runner 的 egress hardening 若已启用，也要能追溯 allowlist、异常访问、例外处理和运行时告警结论。
+- 配置策略的 policy-as-code 预检若已启用，也要能追溯其规则来源、例外条件、失败命中和发布前处置结论。
+- 构建产物的 SBOM 若已启用，也要能追溯其生成时间、对应版本和归档位置。
+- 构建产物 provenance attestation 若已启用，也要能追溯其生成时间、对应产物、归档位置和发布记录回链。
+- attestation 的 predicate、schema 和 evidence model 若已启用，也要能追溯其版本、字段语义、证据来源和适用范围。
+- 构建产物或镜像签名若已启用，也要能追溯其签名范围、验签入口和发布记录回链。
+- provenance / attestation 的独立验证若已启用，也要能追溯其验证输入、验证结果和失败处置策略。
+- 集群 admission 层的策略强制若已启用，也要能追溯其策略范围、拒绝原因、例外处理和回退方案。
+- 基于执行证据的高级 policy gate 若已启用，也要能追溯其 evidence 来源、policy 规则、评估结果、triage 结论和例外处理。
+- 配置与示例中不放真实密钥、真实 endpoint 或私人账号信息。
+- 发布前明确回滚路径和最小暴露面。
+
+## 常见风险
+
+- 把“内部系统”当成不需要鉴权的借口。
+- 把用户输入直接进入 SQL、命令或模板渲染。
+- 在日志、错误栈或示例中泄漏 token、cookie、邮件、手机号等敏感信息。

package/rules/common/testing.md

@@ -0,0 +1,22 @@
+# Common Testing
+
+## 默认要求
+
+- 先确认主路径、边界态、失败场景，再决定测试层级。
+- 测试不是“补形式”，而是为高风险行为建立回归保护。
+- 任何修复类改动，优先补能复现该问题的测试或验证步骤。
+
+## 分层策略
+
+- 单元测试保护纯逻辑、边界和条件组合。
+- 对 Helm chart、模板分支和 values 组合，优先考虑 chart 层单元测试或 snapshot 断言，再交给 schema / policy / server-side 预检。
+- 当参数、配置或角色组合过多时，优先用 pairwise 等组合设计方法压缩矩阵，再为高风险路径补定向用例。
+- 集成测试保护接口、数据库、消息和外部依赖编排。
+- 当存在明确的 consumer/provider 边界时，优先评估是否需要契约测试来保护跨服务行为约定。
+- E2E 或 smoke 测试保护关键用户路径和上线回归风险。
+
+## 不合格信号
+
+- 只有 happy path。
+- 缺少失败路径、异常输入或兼容性验证。
+- 改动大却没有任何新增验证依据。

package/rules/cpp/coding-style.md

@@ -0,0 +1,44 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# C++ Coding Style
+
+> This file extends [common/coding-style.md](../common/coding-style.md) with C++ specific content.
+
+## Modern C++ (C++17/20/23)
+
+- Prefer **modern C++ features** over C-style constructs
+- Use `auto` when the type is obvious from context
+- Use `constexpr` for compile-time constants
+- Use structured bindings: `auto [key, value] = map_entry;`
+
+## Resource Management
+
+- **RAII everywhere** — no manual `new`/`delete`
+- Use `std::unique_ptr` for exclusive ownership
+- Use `std::shared_ptr` only when shared ownership is truly needed
+- Use `std::make_unique` / `std::make_shared` over raw `new`
+
+## Naming Conventions
+
+- Types/Classes: `PascalCase`
+- Functions/Methods: `snake_case` or `camelCase` (follow project convention)
+- Constants: `kPascalCase` or `UPPER_SNAKE_CASE`
+- Namespaces: `lowercase`
+- Member variables: `snake_case_` (trailing underscore) or `m_` prefix
+
+## Formatting
+
+- Use **clang-format** — no style debates
+- Run `clang-format -i <file>` before committing
+
+## Reference
+
+See skill: `cpp-coding-standards` for comprehensive C++ coding standards and guidelines.

package/rules/cpp/hooks.md

@@ -0,0 +1,39 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# C++ Hooks
+
+> This file extends [common/hooks.md](../common/hooks.md) with C++ specific content.
+
+## Build Hooks
+
+Run these checks before committing C++ changes:
+
+```bash
+# Format check
+clang-format --dry-run --Werror src/*.cpp src/*.hpp
+
+# Static analysis
+clang-tidy src/*.cpp -- -std=c++17
+
+# Build
+cmake --build build
+
+# Tests
+ctest --test-dir build --output-on-failure
+```
+
+## Recommended CI Pipeline
+
+1. **clang-format** — formatting check
+2. **clang-tidy** — static analysis
+3. **cppcheck** — additional analysis
+4. **cmake build** — compilation
+5. **ctest** — test execution with sanitizers