@colin4k1024/tsp 2.4.4 → 2.4.6

package/docs/runbooks/frontend-bugfix-one-page.md

@@ -1,82 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 前端缺陷修复一页速查
-
-本文把前端缺陷修复压缩成一页，适合已经知道平台基本工作方式，但不想每次都翻完整 walkthrough 的场景。
-
-## 1. 什么时候用这页
-
-- 页面布局错乱、交互异常、状态显示错误
-- 需要补响应式、A11y 或 UI 验证证据
-- 任务边界清晰，优先考虑短链路
-
-## 2. 最短起手方式
-
-```text
-/team-intake
-目标：修复订阅页在 iPad 横屏下的布局溢出
-范围：页面布局、响应式回归、UI 自测证据
-不做：接口改造
-约束：必须附带 ui-review-checklist
-```
-
-## 3. 优先判断短链路还是长链路
-
-- 只改单页面样式或交互：优先短链路
-- 涉及多个页面、组件结构或状态流：补 `/team-plan`
-- 涉及接口联动、权限或发布风险：直接进入完整主链
-
-## 4. 推荐命令顺序
-
-短链路：
-
-1. `/team-intake`
-2. `/code-review`
-3. `/handoff`
-4. `/team-review`
-
-完整主链：
-
-1. `/team-intake`
-2. `/team-plan`
-3. `/team-execute`
-4. `/handoff`
-5. `/team-review`
-
-## 5. 必须出现的验证点
-
-- 主路径是否恢复正常
-- 响应式断点是否覆盖
-- 关键交互状态是否正常
-- 是否附带 UI 自测或 checklist 证据
-
-## 6. handoff 至少写什么
-
-```text
-已完成
-- 修复 iPad 横屏下的栅格溢出
-
-验证结果
-- 桌面、iPad 横屏、iPhone 视图已验证
-- ui-review-checklist 已补齐
-
-风险
-- 暂未覆盖低版本 Safari
-
-下一角色关注点
-- QA 重点看横屏切换和按钮折行
-```
-
-## 7. 常见错误
-
-- 只说“样式已修复”，没有响应式证据
-- 明明是前端问题，却完全不提 `ui-review-checklist`
-- 任务已经跨页面或跨状态流，还强行走短链路
-
-如果你要看完整长演练，继续看 [bug-fix-complete-walkthrough.md](bug-fix-complete-walkthrough.md) 和 [frontend-refactor-walkthrough.md](frontend-refactor-walkthrough.md)。

package/docs/runbooks/frontend-engineer-daily-operations.md

@@ -1,60 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# Frontend Engineer 日常操作手册
-
-本文面向前端工程师，说明在 Team Skills Platform 下，页面、交互和联调工作应该怎样在主链里落地。
-
-如果你想先看公开命令、UI 相关 specialist 和 runtime 的全景关系，先读 [command-and-capability-matrix.md](command-and-capability-matrix.md)。
-
-## 1. 你的默认职责
-
-- 实现页面、表单、交互与状态流
-- 产出前端自测结果
-- 补齐响应式、A11y、性能和 UI 证据
-- 把前端视角的风险交接给 QA 和 tech-lead
-
-## 2. 开始实现前必须确认什么
-
-- 页面范围和范围外事项
-- 接口契约是否已清楚
-- 设计约束和交互状态是否明确
-- 是否需要 `ui-review-checklist`
-
-## 3. 页面实现的固定检查
-
-- 断点策略
-- 空态与错误态
-- 键盘可达性
-- 异步 loading 状态
-- 视觉回归风险
-
-## 4. 进入 QA 前应交付什么
-
-- 代码变更摘要
-- 自测范围
-- 响应式和 UI 证据
-- 已知限制与剩余风险
-
-## 5. 常用命令组合
-
-- `/team-intake`：确认目标与范围
-- `/team-plan`：拆页面和联调任务
-- `/tdd`：先锁交互边界、回归点和成功标准
-- `/multi-frontend`：做专项拆解
-- `/team-execute`：汇总实现和自测
-- `/handoff`：交给 QA 或 tech-lead
-
-## 6. 常见错误
-
-- 只改 happy path，不补空态和错误态
-- 进入 QA 前没有任何自测证据
-- 明明适合先用 `/tdd` 锁交互和回归口径，却直接开始实现
-- 页面联调后才发现接口字段理解不一致
-
-前端专项场景可继续看 [../../examples/saas-nextjs-CLAUDE.md](../../examples/saas-nextjs-CLAUDE.md)。

package/docs/runbooks/frontend-enterprise-style-profile.md

@@ -1,5 +0,0 @@
-# Frontend Enterprise Style Profile
-
-该企业前端样式 profile 已迁移到私有 `enterprise` overlay 仓库。公开仓不再分发这套企业内部设计资料。
-
-公开安装与 overlay 约定见 [custom-overlay.md](custom-overlay.md)。

package/docs/runbooks/frontend-governance.md

@@ -1,47 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-27
-updated: 2026-03-27
-owner: 工程团队
----
-
-# Frontend Governance Runbook
-
-本文说明当前 Team Skills 平台如何承接 React/Next 优先的前端工程规范与 UI/UX 治理能力。
-
-## 1. 何时启用前端能力包
-
-- 需求包含页面、组件、交互、导航、样式、图表、表单或前端静态资源变更。
-- `tech-lead` 在 `/team-intake` 或 `/team-plan` 已确认存在前端交付物。
-
-## 2. 两层共享 Skill
-
-| Skill | 作用 | 主用角色 |
-|-------|------|----------|
-| `frontend-engineering` | 统一组件结构、状态分层、语义化、可访问性与性能做法 | `frontend-engineer`、`architect` |
-| `frontend-ui-ux-system` | 统一产品类型、视觉方向、设计 token、交互与体验门禁 | `tech-lead`、`frontend-engineer`、`qa-engineer` |
-
-## 3. 推荐工作流
-
-1. `tech-lead` 在 `/team-intake` 锁定目标端、产品类型、设计约束、响应式和 A11y/性能红线。
-2. 需要新界面或较大 UI 变化时，先补 [design-system-brief.md](../../templates/design-system-brief.md)。
-3. `frontend-engineer` 编写 [ui-implementation-plan.md](../../templates/ui-implementation-plan.md)，明确组件结构、状态流和交付风险。
-4. 进入 QA 前，`frontend-engineer` 必须填写 [ui-review-checklist.md](../../templates/ui-review-checklist.md)。
-5. 需要用真实浏览器做关键页面 / 发布前回归时，补用 [browser-smoke-testing](../../skills/browser-smoke-testing/SKILL.md) 明确 smoke 范围与证据。
-6. `qa-engineer` 在 `/team-review` 依据 [frontend-quality-gates.md](../../rules/frontend-quality-gates.md) 给出结论。
-
-## 4. 知识库结构
-
-- 规则入口：[frontend-engineering-standards.md](../../rules/frontend-engineering-standards.md)、[frontend-ui-ux-standards.md](../../rules/frontend-ui-ux-standards.md)
-- 门禁入口：[frontend-quality-gates.md](../../rules/frontend-quality-gates.md)
-- 知识索引：[frontend-design-knowledge-base.md](../../rules/frontend-design-knowledge-base.md)
-- 工程参考：[frontend-engineering](../../skills/frontend-engineering/SKILL.md)
-- 浏览器验证：[browser-smoke-testing](../../skills/browser-smoke-testing/SKILL.md)
-- 设计参考：[frontend-ui-ux-system](../../skills/frontend-ui-ux-system/SKILL.md)
-
-## 5. 默认交付要求
-
-- 任何前端变更都要说明主路径、边界态、异常态和已知风险。
-- 任何设计 token 的新增或调整都要说明原因和适用范围。
-- 任何前端上线都要有 smoke 范围、观察指标和回滚触发条件。

package/docs/runbooks/frontend-refactor-walkthrough.md

@@ -1,42 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 前端重构演练
-
-本文演示页面或组件重构任务如何拆解、验证和交接。重点不是新增功能，而是在不破坏现有体验的前提下改善结构。
-
-## 1. 场景
-
-- 重构控制台列表页的筛选区和表格结构
-- 目标是提升可维护性和响应式一致性
-- 不改变接口契约
-
-## 2. 推荐链路
-
-1. `/team-intake`
-2. `/team-plan`
-3. `/multi-frontend`
-4. `/team-execute`
-5. `/code-review`
-6. `/handoff`
-7. `/team-review`
-
-## 3. 关键输出
-
-- 为什么要重构，而不是继续堆补丁
-- 哪些行为保持不变
-- UI、响应式和空态是否回归
-- 哪些技术债仍然保留
-
-## 4. 常见错误
-
-- 把重构写成纯代码整理，不说明用户影响
-- 缺少回归范围
-- 引入样式变化却没有证据
-
-与前端角色说明配合阅读：[frontend-engineer-daily-operations.md](frontend-engineer-daily-operations.md)

package/docs/runbooks/git-pr-workflow.md

@@ -1,63 +0,0 @@
-# Git / PR 收口工作流
-
-本手册承接 `obra/superpowers` 中与 `using-git-worktrees`、`finishing-a-development-branch` 相关的工程实践。它用于规范分支隔离、PR 收口、验证证据和分支清理，不替代 [git-workflow.md](../../rules/common/git-workflow.md) 的基础规则。
-
-## 适用场景
-
-- 任务需要开独立分支提交、发起 PR、处理 review 再完成合并收口。
-- 当前改动风险较高、并行任务较多，或需要用 worktree 把上下文隔离开。
-- 团队希望把“写完代码”延伸到“PR 可审、可验、可清理”的完整闭环。
-
-## 何时使用 worktree
-
-优先考虑 `git worktree` 的场景：
-
-- 同一仓库要并行推进两个以上任务。
-- 当前主工作区已经有脏改动，不适合混进新任务。
-- 需要在不打断现有上下文的前提下，开一个干净环境做修复或 review follow-up。
-
-不必额外开 worktree 的场景：
-
-- 单一任务、改动很小、当前工作区本来就是干净的。
-- 只是补一两个 review comment，没有上下文污染风险。
-
-## 默认做法
-
-1. 先确认 base branch、任务边界、是否需要独立 worktree，再开始编码。
-2. 若使用 worktree，保持“一任务一 worktree / 一分支”，不要让多个任务共享同一临时目录。
-3. 提交按单一意图组织，保证每次提交都能说明“做了什么、为什么、怎么验证”。
-4. 发 PR 前先补齐验证命令、风险、文档影响和回滚说明，不把这些信息留给 reviewer 反向追问。
-5. 处理 review 时优先做增量修复和定向验证，避免把 unrelated cleanup 混进 follow-up。
-6. 合并前确认 checks、review 状态和最终验证结果；合并后清理分支、临时 worktree 和过期上下文。
-
-## PR 最小清单
-
-- 目标：这次变更解决什么问题
-- 范围：做了什么，明确没做什么
-- 风险：可能影响哪些路径、模块或发布动作
-- 验证：本地或 CI 跑了什么命令、覆盖了哪些关键路径
-- 文档：是否同步了模板、规则、runbook、README 或交接说明
-
-## 分支收口清单
-
-1. 所有必要 review comment 已处理或显式记录暂不处理原因。
-2. 最终验证结果与 PR 描述一致，没有“代码已变、描述没跟”。
-3. 若使用 worktree，合并后清理对应目录，避免保留无主上下文。
-4. 若变更影响发布、规则或知识入口，回写 `/handoff`、`/team-review` 或相关文档。
-
-## 反模式
-
-- 用一个分支混多个不相关任务。
-- 为了“快一点”跳过本地验证，把失败风险留到 PR checks 或 reviewer 身上。
-- review follow-up 顺手重构一大片，导致 reviewer 无法判断真正改了什么。
-- worktree 创建了但不清理，后续没人知道哪个目录仍有效。
-
-## 输出回落
-
-- 开发与 review 阶段：回落到 PR 描述、`/handoff` 和 `/team-review` 的验证证据。
-- 发布前：若 PR 收口影响上线判断，把最终分支状态、tag、验证结果回写到 `/team-release`。
-
-## 参考来源
-
-- [obra/superpowers](https://github.com/obra/superpowers)
-- [rules/common/git-workflow.md](../../rules/common/git-workflow.md)

package/docs/runbooks/github-actions-supply-chain-demo-execution-log.md

@@ -1,158 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
----
-
-# GitHub Actions 与供应链治理演示执行记录
-
-本文记录一条以 GitHub Actions、权限治理与供应链证据链为核心的演示路径，重点展示团队如何把 workflow 门禁、发布证据和 release 收口串成一条可审计链路。
-
-## 1. 场景定义
-
-### 背景
-
-- 仓库已经通过 GitHub Actions 承担构建与发布
-- 但 workflow 权限、scorecard、SBOM、attestation、签名和 SLSA 还没有形成统一治理口径
-- 团队希望把“安全门禁”从零散脚本升级为主链可解释、可复盘的治理任务
-
-### 演示目标
-
-- 让观众理解 workflow lint、权限收敛和供应链证据不是一回事
-- 让观众看到 `/tdd` 如何前置定义治理完成标准
-- 让观众看到 `/harness-audit` 如何检查文档、runbook 和 release 出口是否同步
-
-## 2. 阶段 1：/team-intake
-
-### 输入
-
-```text
-/team-intake
-目标：补齐 GitHub Actions 发布链路的供应链门禁与证据记录
-范围：workflow、permissions、scorecard、SBOM、attestation、签名、release 检查项
-不做：业务服务逻辑改造
-约束：必须说明 workflow lint、token 权限、provenance、artifact attestation 的边界
-```
-
-### 产出
-
-| 字段 | 内容 |
-|------|------|
-| 任务类型 | 平台治理 / 供应链治理 |
-| 主体对象 | workflow、permissions、artifact 证据链、release 手册 |
-| 主要风险 | 权限过宽、证据链缺失、workflow 改动不可追溯 |
-| 收口要求 | review 与 release 必须能承接供应链证据 |
-
-## 3. 阶段 2：/team-plan
-
-### 拆解结果
-
-| 模块 | 动作 | 收口位置 |
-|------|------|----------|
-| Workflow 结构 | 调整 job、step、触发条件和复用关系 | workflow 文件 |
-| 权限治理 | 收敛 `permissions`、减少默认写权限 | workflow 文件 + review |
-| 供应链门禁 | 接入 actionlint、scorecard、SBOM、attestation、签名 | CI / release |
-| 文档与 runbook | 更新治理入口和证据说明 | runbook / release 文档 |
-| 最终验证 | 逐项检查门禁、证据与发布收口 | `/team-review`、`/team-release` |
-
-### 关键判断
-
-- `actionlint` 解决的是 workflow 结构与语法质量
-- `scorecard` 和 token 权限基线解决的是仓库治理与权限风险
-- `SBOM`、`attestation`、签名与 `SLSA` 解决的是发布证据链问题
-
-## 4. 阶段 3：/tdd
-
-### 定义的完成标准
-
-```text
-1. workflow lint 与权限基线通过
-2. release 阶段能产出 SBOM、attestation 或等价证明
-3. review 结论能明确记录 workflow 风险与例外
-4. release 记录能落地 artifact、digest、签名或 provenance 信息
-5. 仓库校验通过
-```
-
-### 价值说明
-
-- 把治理任务的“完成”从主观感觉变成显式标准
-- 避免只改 workflow 文件，不改 release 与 review 记录
-
-## 5. 阶段 4：/team-execute
-
-### 执行批次
-
-#### 批次 A：workflow 基线
-
-- 清理 workflow 结构问题
-- 拆分过宽的 job 权限
-- 接入 lint 与基础门禁
-
-#### 批次 B：供应链证据
-
-- 生成 SBOM
-- 接入 attestation / provenance
-- 补签名或 digest 记录
-
-#### 批次 C：治理出口
-
-- 更新 release 检查项
-- 更新 review 结论模板
-- 补 runbook 导航和落地说明
-
-## 6. 阶段 5：/harness-audit
-
-### 体检前缺口
-
-- workflow 已改，但治理文档没有同步
-- release 手册还没显式承接 attestation 和签名信息
-- 观众容易把所有供应链门禁混成同一个概念
-
-### 体检后收敛结果
-
-| 维度 | 收敛动作 | 状态 |
-|------|----------|------|
-| Workflow 质量 | lint 与结构治理已明确 | 已补齐 |
-| 权限治理 | token 权限边界有记录 | 已补齐 |
-| 证据链 | SBOM、attestation、签名进入 release 说明 | 已补齐 |
-| 导航入口 | 相关 runbook 与 walkthrough 已串起来 | 已补齐 |
-
-## 7. 阶段 6：/team-review 与 /team-release
-
-### Review 结论
-
-- 风险分层已明确：workflow、权限、证据链分别检查
-- 例外项必须进入 review，而不是留在口头说明
-
-### Release 结论
-
-- 发布记录必须包含 artifact、digest、SBOM、attestation 或签名信息
-- 一旦 workflow 异常，回退步骤应绑定上一版本的 workflow / release 配置
-
-## 8. 校验结果
-
-### 文档静态检查
-
-- 本轮新增 walkthrough 与 execution log 无错误
-
-### 仓库校验
-
-```text
-Validation passed.
-- Roles: 8
-- Shared skills: 3
-- ECC skills: 9
-- Private overlay skills: not shipped in public repo
-- Specialist agents: 27
-- Generated artifacts: 70
-```
-
-## 9. 推荐搭配材料
-
-- [github-actions-supply-chain-walkthrough.md](github-actions-supply-chain-walkthrough.md)
-- [../../examples/github-actions-supply-chain-CLAUDE.md](../../examples/github-actions-supply-chain-CLAUDE.md)
-- [../../examples/vertical-project-conversation-scripts.md](../../examples/vertical-project-conversation-scripts.md)
-- [actionlint-workflow-gates.md](actionlint-workflow-gates.md)
-- [scorecard-supply-chain-gates.md](scorecard-supply-chain-gates.md)

package/docs/runbooks/github-actions-supply-chain-demo-script.md

@@ -1,150 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
----
-
-# GitHub Actions 与供应链治理演示剧本
-
-本文是一份可直接照着讲的演示脚本，面向 GitHub Actions、权限治理、SBOM、attestation、签名和 release 证据链场景。
-
-## 1. 演示目标
-
-- 说明 workflow lint、权限治理、供应链证据链是三层不同问题
-- 说明 `/tdd` 如何前置定义治理完成标准
-- 说明 `/harness-audit` 如何检查 runbook、review 和 release 出口是否同步
-
-## 2. 适用对象
-
-- 需要介绍 CI/CD 治理能力的 Tech Lead
-- 需要做 workflow 安全与供应链汇报的 DevOps / QA
-- 需要向团队解释 release 证据链的讲解人
-
-## 3. 演示时长建议
-
-- 5 分钟：讲 workflow、permissions、证据链三层边界
-- 10 分钟：再讲 `/tdd` 与 `/harness-audit` 的作用
-- 15 分钟：完整走一遍 intake -> plan -> tdd -> execute -> audit -> review/release
-
-## 4. 演示脚本
-
-### Step 1. 先用 1 分钟讲清这类任务到底在治理什么
-
-建议讲法：
-
-```text
-这类仓库要治理的不是一件事，而是三件事：
-第一是 workflow 结构和 lint 质量；
-第二是 token 权限和仓库治理边界；
-第三是 SBOM、attestation、签名和 provenance 组成的发布证据链。
-```
-
-配套材料：
-
-- [actionlint-workflow-gates.md](actionlint-workflow-gates.md)
-- [github-token-permissions-baseline.md](github-token-permissions-baseline.md)
-- [artifact-attestation-gates.md](artifact-attestation-gates.md)
-
-### Step 2. 用 `/team-intake` 讲清治理目标和边界
-
-建议输入：
-
-```text
-/team-intake
-目标：补齐 GitHub Actions 发布链路的供应链门禁与证据记录
-范围：workflow、permissions、scorecard、SBOM、attestation、签名、release 检查项
-不做：业务服务逻辑改造
-约束：必须说明 workflow lint、token 权限、provenance、artifact attestation 的边界
-```
-
-讲解重点：
-
-- 这是平台治理任务，不是业务需求开发
-- 一开始就要分清结构问题、权限问题和证据链问题
-
-### Step 3. 用 `/team-plan` 说明如何拆治理任务
-
-建议输入：
-
-```text
-/team-plan
-基于当前 intake 结果，拆 workflow 调整、权限收敛、供应链证据生成、review 收口和 release 记录动作。
-输出必须指出哪些完成标准应先进入 /tdd，哪些文档缺口最终应通过 /harness-audit 检查。
-```
-
-讲解重点：
-
-- 不能只改 workflow 文件
-- release 和 review 文档必须同步承接新的治理结果
-
-### Step 4. 用 `/tdd` 讲“先定义治理完成标准”
-
-建议输入：
-
-```text
-/tdd
-基于当前 /team-plan 结果，先定义本轮供应链治理的完成标准。
-至少覆盖：
-1. workflow lint 与权限基线通过
-2. release 阶段有 SBOM、attestation 或等价证明
-3. review 结论记录风险、例外与阻塞项
-4. release 记录包含 artifact、digest、签名或 provenance 信息
-```
-
-讲解重点：
-
-- `/tdd` 在这里锁的是治理标准，不是业务测试代码
-- 这样可以避免“改完了但说不清到底完成了什么”
-
-### Step 5. 用 `/team-execute` 讲实际收敛动作
-
-建议讲法：
-
-```text
-执行阶段通常会先调 workflow 和 permissions，再接入 SBOM、attestation、签名，最后补 review / release 的治理出口。
-```
-
-可展示材料：
-
-- [scorecard-supply-chain-gates.md](scorecard-supply-chain-gates.md)
-- [sbom-generation-gates.md](sbom-generation-gates.md)
-- [slsa-generator-patterns.md](slsa-generator-patterns.md)
-
-### Step 6. 用 `/harness-audit` 讲平台体检的价值
-
-建议输入：
-
-```text
-/harness-audit
-请从 workflow 治理覆盖、权限边界、release 证据链、runbook 同步和最终校验五个方向审视当前仓库。
-输出立即修补项、下一轮收敛项和建议回写位置。
-```
-
-讲解重点：
-
-- audit 不是重复 review，而是检查治理出口是否形成闭环
-- 特别适合 workflow 和 runbook 同时变动的场景
-
-### Step 7. 用 review 与 release 收尾
-
-建议讲法：
-
-```text
-最终交付不是“workflow 能跑了”，而是 review 能解释风险，release 能解释证据链。
-```
-
-## 5. 建议演示顺序
-
-1. 先展示 workflow / permissions / evidence 三层边界
-2. 再展示 `/team-intake` 与 `/team-plan`
-3. 然后讲 `/tdd`
-4. 再讲 `/team-execute`
-5. 最后讲 `/harness-audit`、`/team-review` 和 `/team-release`
-
-## 6. 演示后建议发给观众的材料
-
-- [github-actions-supply-chain-demo-execution-log.md](github-actions-supply-chain-demo-execution-log.md)
-- [github-actions-supply-chain-walkthrough.md](github-actions-supply-chain-walkthrough.md)
-- [../../examples/github-actions-supply-chain-CLAUDE.md](../../examples/github-actions-supply-chain-CLAUDE.md)