@colin4k1024/tsp 2.4.4 → 2.4.6

package/docs/runbooks/release-governance-reading-path.md

@@ -1,56 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 发布治理阅读路径
-
-本文把发布相关 runbook 串成一条阅读路径，帮助团队按问题类型进入正确文档，而不是在多个发布手册里来回找。
-
-## 1. 日常版本发布
-
-先看这些：
-
-- [devops-engineer-daily-operations.md](devops-engineer-daily-operations.md)
-- [team-release-example.md](team-release-example.md)
-- [canary-staging-release-walkthrough.md](canary-staging-release-walkthrough.md)
-- [pre-release-checklist.md](pre-release-checklist.md)
-- [canary-decision-matrix.md](canary-decision-matrix.md)
-
-## 2. 紧急修复与事故响应
-
-先看这些：
-
-- [hotfix-emergency-release-walkthrough.md](hotfix-emergency-release-walkthrough.md)
-- [production-incident-response-walkthrough.md](production-incident-response-walkthrough.md)
-- [release-rollback-recovery-walkthrough.md](release-rollback-recovery-walkthrough.md)
-- [incident-severity-triage-tree.md](incident-severity-triage-tree.md)
-- [post-rollback-verification-checklist.md](post-rollback-verification-checklist.md)
-
-## 3. GitLab 或公司扩展参与发布
-
-先看这些：
-
-- [gitlab-manual-pipeline-release.md](gitlab-manual-pipeline-release.md)
-- [gitlab-release-integration-playbook.md](gitlab-release-integration-playbook.md)
-- 
-- 
-- [custom-overlay.md](custom-overlay.md)
-
-## 4. 需要附加可观测性
-
-先看这些：
-
-- [langfuse-coding-trace.md](langfuse-coding-trace.md)
-- [langfuse-and-observability-integration-guide.md](langfuse-and-observability-integration-guide.md)
-- 
-
-## 5. 不知道先看哪篇时
-
-- 正常发布：从 [team-release-example.md](team-release-example.md) 开始
-- 需要灰度：看 [canary-staging-release-walkthrough.md](canary-staging-release-walkthrough.md)
-- 事故或回滚：看 [production-incident-response-walkthrough.md](production-incident-response-walkthrough.md)
-- 涉及 GitLab 或 Langfuse：先看对应 runbook，再回到 `/team-release`

package/docs/runbooks/release-notes-automation.md

@@ -1,48 +0,0 @@
-# Release Notes 自动化手册
-
-本手册承接 `semantic-release` 与 `release-notes-generator` 的工程实践，用于规范 changelog / release notes 自动生成的接入方式。它是发布说明自动化补充，不替代 `/team-release` 的责任链、放行结论和回滚方案。
-
-## 适用场景
-
-- 团队希望减少手工整理版本说明的成本。
-- 仓库已经有较稳定的提交规范、PR 标题规范或版本发布节奏。
-- 需要把版本说明、tag、发布记录和变更面更稳定地关联起来。
-
-## 先判断采用层级
-
-优先顺序建议如下：
-
-1. `notes-only`
-只自动生成 release notes / changelog，不自动发版。
-
-2. `notes + tag`
-在 notes 稳定后，再接自动打 tag 或创建 release 草稿。
-
-3. `full semantic release`
-只有当提交规范、分支策略、发版权限和回滚策略都成熟时，再考虑自动发版。
-
-## 推荐落地方式
-
-1. 先统一提交或 PR 标题策略，保证版本说明有稳定输入来源。
-2. 第一阶段只生成草稿 release notes，让团队确认分组、噪音和遗漏。
-3. 第二阶段再接 tag / GitHub Release 草稿，仍保留人工放行。
-4. 只有在发布权限、版本规则和回滚链都稳定后，才考虑全自动 semantic release。
-5. 对基础设施变更、手工数据库操作、灰度策略等“代码之外的发布动作”，继续在 [release-plan.md](../../templates/release-plan.md) 和 `/team-release` 中人工补充，不要指望 changelog 自动生成完整发布说明。
-
-## 反模式
-
-- 提交标题混乱，却直接上全自动 semantic release。
-- 把版本说明自动化误当成发布流程自动化，忽略人工放行和回滚准备。
-- 只记录代码提交，不记录配置、数据迁移、静态资源或手工操作影响。
-- 生成的 notes 从未被人使用，却持续增加维护复杂度。
-
-## 输出回落
-
-- 日常发布：将自动生成的 notes 作为 `/team-release` 的补充输入，而不是替代发布方案。
-- 对外发布：若创建了 tag / release 草稿，把链接和版本号回写到 handoff 或发布记录。
-- 风险沟通：自动生成内容不足以说明风险时，仍由 `devops-engineer` 或 `tech-lead` 手工补充。
-
-## 参考来源
-
-- [semantic-release/semantic-release](https://github.com/semantic-release/semantic-release)
-- [semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator)

package/docs/runbooks/release-rollback-recovery-walkthrough.md

@@ -1,47 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 发布后回滚与恢复演练
-
-本文演示版本发布后发现问题时，如何判断是否回滚、如何验证恢复结果，以及如何把恢复过程记录回主链。
-
-## 1. 场景
-
-- 版本已全量发布
-- 监控发现错误率或性能指标异常
-- 团队需要在前向修复和回滚之间快速决策
-
-## 2. 推荐链路
-
-1. `/team-execute`
-2. `/verify`
-3. `/handoff`
-4. `/team-release`
-
-如果问题严重，可先走 [production-incident-response-walkthrough.md](production-incident-response-walkthrough.md) 的事故分级。
-
-## 3. 关键输出
-
-- 回滚还是前向修复的判断依据
-- 回滚执行步骤
-- 恢复后的验证结果
-- 后续改进项
-
-## 4. 合格结果的检查点
-
-- 回滚条件事先或当场明确
-- 恢复后关键指标恢复正常
-- 数据一致性和依赖服务状态被复核
-
-## 5. 常见错误
-
-- 回滚之后不做恢复验证
-- 只关注服务状态，不看数据一致性
-- 问题消失后不补记录
-
-与这些文档配合阅读：[canary-staging-release-walkthrough.md](canary-staging-release-walkthrough.md)、[devops-engineer-daily-operations.md](devops-engineer-daily-operations.md)

package/docs/runbooks/requirement-clarity-and-scope-walkthrough.md

@@ -1,46 +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. `/handoff`
-
-必要时在 intake 前先由产品经理完成业务澄清，再进入主链。
-
-## 3. 关键输出
-
-- 问题定义
-- In Scope / Out of Scope
-- 用户故事和验收标准
-- 优先级和风险提醒
-
-## 4. 合格结果的检查点
-
-- 研发能看懂目标和边界
-- Project Manager 能基于此拆依赖和里程碑
-- QA 能据此写出测试点
-
-## 5. 常见错误
-
-- 用模糊形容词代替明确目标
-- 只说想要什么，不说不做什么
-- 验收标准没有行为或数据依据
-
-与这些文档配合阅读：[product-manager-daily-operations.md](product-manager-daily-operations.md)、[project-onboarding.md](project-onboarding.md)

package/docs/runbooks/reviewdog-pr-gates.md

@@ -1,49 +0,0 @@
-# Reviewdog PR 门禁手册
-
-本手册承接 `reviewdog/reviewdog` 与 `reviewdog/action-eslint` 的工程实践，用于把现有 lint / test / static check 结果安全地暴露到 PR 上。它是 review 自动化的补充手册，不替代本地验证和 `/team-review`。
-
-## 适用场景
-
-- 仓库已经有稳定的 lint、静态检查或测试命令，希望把结果自动贴到 PR。
-- 团队希望在 GitHub PR 中直接看到代码级问题，而不是只看 CI 日志。
-- 需要逐步建设 PR gate，但不想一上来就把所有检查都做成阻塞项。
-
-## 前置条件
-
-- 已有可重复执行的本地检查命令，例如 `eslint`、`ruff`、`golangci-lint`、`mvn test` 等。
-- 团队已经接受这些检查的规则质量，至少不存在大量历史噪音。
-- 已明确本次 gate 是 `warning-first` 还是 `blocking`。
-
-## 推荐落地方式
-
-1. 先把本地检查命令稳定下来，reviewdog 只负责“转译和呈现结果”，不负责定义规则。
-2. 第一阶段只接 1-2 个高信号检查，例如 ESLint、Ruff、格式化或一个稳定的单测集合。
-3. 先用非阻塞模式观察噪音水平，再决定是否升级为阻塞 gate。
-4. 对同一类问题只保留一个权威来源，避免同一错误在 CI summary、PR comment、inline comment 里重复轰炸。
-5. 将 gate 的阻塞策略同步到 `/team-review` 和发布准备说明里，避免“CI 阻塞了但团队不知道这是正式门槛”。
-
-## 最小门禁模型
-
-- `source of truth`：项目原生检查命令
-- `annotation layer`：reviewdog 将输出映射到 PR check 或 inline review
-- `decision layer`：`/team-review` 与 `tech-lead` 判断问题是否阻塞
-
-先把这三层分清，再决定是否扩大自动化范围。
-
-## 反模式
-
-- 还没有稳定规则，就急着把 reviewdog 接成阻塞门禁。
-- 把低价值、纯风格或高噪音问题全部推到 PR inline comment。
-- 本地与 CI 的命令不一致，导致开发者无法复现 PR 报错。
-- 用 reviewdog 替代 code review，本该由 reviewer 判断的设计和行为问题却只看机器结果。
-
-## 输出回落
-
-- PR 阶段：把启用的 gate、阻塞策略和主要发现写入 PR 描述或 review 结论。
-- 团队协作：在 `/team-review` 中说明哪些问题来自自动门禁，哪些仍需人工判断。
-- 发布前：若某项 gate 属于正式放行门槛，回写到 `/team-release` 的发布检查结果。
-
-## 参考来源
-
-- [reviewdog/reviewdog](https://github.com/reviewdog/reviewdog)
-- [reviewdog/action-eslint](https://github.com/reviewdog/action-eslint)

package/docs/runbooks/role-prompt-recipes.md

@@ -1,130 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 角色高频提示模板
-
-本文把高频角色的常用说法收成一页，适合在 Claude 或 Codex 里直接复制。它不替代主链命令规范，而是帮你更快拿到接近可执行产物的输出。
-
-如果你想先看当前公开命令和能力映射，先读 [command-and-capability-matrix.md](command-and-capability-matrix.md)。如果你关心 memory、observe、budget、compact、instinct 这些后台机制，再读 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)。
-
-## 1. Tech Lead 起手模板
-
-```text
-请以 tech-lead 视角处理当前任务。
-先执行 /team-intake，输出：目标、范围外事项、参与角色、主要风险、是否命中 overlay 候选项、下一步建议。
-
-任务背景：
-- 目标：
-- 范围：
-- 不做：
-- 约束：
-```
-
-适用场景：任务刚进入平台，还没有统一边界。
-
-## 2. Tech Lead 收口模板
-
-```text
-基于当前 intake、plan、specialist 和 handoff 结果，请以 tech-lead 视角收口。
-输出必须包含：已确认结论、未决问题、阻塞风险、非阻塞风险、下一步命令建议。
-如果 specialist 已参与，请说明哪些结论已经回收到主链，哪些还没有。
-```
-
-适用场景：并行分析很多，但没有统一收口时。
-
-## 3. Product Manager 澄清模板
-
-```text
-请以 product-manager 视角整理当前需求。
-输出：业务目标、核心用户场景、In Scope、Out of Scope、验收标准、待确认事项。
-最后补一段：这些内容怎样进入 /team-intake。
-```
-
-适用场景：需求描述还是业务语言，尚未转成主链输入时。
-
-## 4. Project Manager 计划模板
-
-```text
-请以 project-manager 视角拆当前任务。
-输出：里程碑、关键依赖、角色协作顺序、风险、升级条件。
-如果存在并行开发，请说明哪些 handoff 必须提前约定。
-```
-
-适用场景：任务不只是“能不能做”，而是“怎么稳妥推进”时。
-
-## 5. Architect 方案模板
-
-```text
-请以 architect 视角处理当前任务。
-输出：系统边界、接口契约、数据约束、主要技术风险、是否需要 custom overlay。
-如果需要 custom overlay，请区分候选项和正式启用项。
-```
-
-适用场景：涉及接口、数据边界、流程引擎或权限中心时。
-
-## 6. QA 放行模板
-
-```text
-请以 qa-engineer 视角给出当前任务的测试结论。
-输出：测试范围、已验证项、阻塞项、非阻塞风险、放行建议、上线后观察建议。
-如果存在 custom overlay 或发布扩展，请说明是否需要额外验证证据。
-```
-
-适用场景：研发已交付，需要形成明确的 review 结论时。
-
-## 7. DevOps 发布模板
-
-```text
-请以 devops-engineer 视角执行 /team-release。
-输出：发布方案、观察窗口、核心指标、回滚条件、回滚步骤、责任链。
-如果 GitLab 手动流水线或 Langfuse 追踪只作为 runbook 补充，而不是正式 custom overlay，也请明确写出。
-```
-
-适用场景：发布阶段最容易漏写企业扩展和观察窗口时。
-
-## 8. Review 重新收口模板
-
-```text
-请基于当前 handoff、自测和专项分析结果，生成一次正式 /team-review 输出。
-要求区分：
-- 可以放行的依据
-- 必须阻塞的问题
-- 上线后继续观察的问题
-- overlay、runbook、toolkit 的执行记录是否需要进入结论
-```
-
-适用场景：信息很多，但你需要一份正式评审结论时。
-
-## 9. Tech Lead 测试先行模板
-
-```text
-请以 tech-lead 视角衔接当前计划结果。
-基于已有 /team-plan 输出，先整理进入 /tdd 所需的最小上下文。
-输出必须包含：功能目标、边界行为、测试优先级、实现前置条件、完成后如何回收到 /team-execute 或 /handoff。
-```
-
-适用场景：任务已经拆清，但你希望先锁定 red-green-refactor 路径，而不是直接进入实现。
-
-## 10. 平台能力体检模板
-
-```text
-请以 tech-lead 视角执行一次 /harness-audit。
-重点审视：命令覆盖、skills 完整度、hooks 有效性、文档同步情况、集成深度。
-输出必须包含：高风险缺口、可延后问题、建议优先级、哪些结论需要回写到 README / runbooks / examples。
-```
-
-适用场景：刚新增了命令、skills、hooks、规则或安装入口，想快速确认平台文档和能力面是否同步。
-
-## 11. 常见错误
-
-- 只指定角色，不说明希望输出什么结构
-- 没有要求把 specialist 结论回收到主链
-- 已经适合用 `/tdd` 或 `/harness-audit`，却还只写笼统的“帮我分析一下”
-- 在 architect、qa、devops 场景里把 overlay、runbook、toolkit 的角色写混
-
-如果你想看更偏 Claude 的完整说法，继续看 [claude-conversation-prompt-recipes.md](claude-conversation-prompt-recipes.md)；如果你想看更偏 Codex 的并行说法，继续看 [codex-parallel-prompt-recipes.md](codex-parallel-prompt-recipes.md)。

package/docs/runbooks/rtk-integration-intake.md

@@ -1,45 +0,0 @@
-# External Capability Intake: rtk (Rust Token Killer)
-
-## Intake Card
-
-| Field | Value |
-|-------|-------|
-| source_name | rtk (Rust Token Killer) |
-| source_url | https://github.com/rtk-ai/rtk |
-| license | Apache-2.0 |
-| trust_tier | B-proven-community |
-| maintenance_signal | Active (frequent releases, Homebrew formula, 10+ AI tool integrations) |
-| portability | claude + cursor (hook-based); codex/opencode (instruction-based) |
-| import_mode | adapt-into-local-skill |
-| target_layer | hooks + skills |
-| status | approved |
-
-## What It Does
-
-High-performance Rust CLI proxy that intercepts shell command output and compresses it before it reaches the LLM context. Reduces token consumption by 60-90% across 100+ common dev commands.
-
-## Why Integrate
-
-- Direct cost reduction: 60-90% fewer tokens per Bash command
-- Zero workflow change: transparent hook rewrite
-- Broad coverage: git, gh, cargo, npm, docker, kubectl, aws, test runners, linters
-- Already supports Claude Code via PreToolUse hook
-
-## Integration Approach
-
-- **Adapted hook** (`hooks/rtk-rewrite.sh`): modified from upstream to NOT auto-allow, preserving harness safety hook chain
-- **Skill** (`skills/rtk-token-optimization/`): documents capabilities, commands, and savings estimates
-- **Install module** (`rtk-optimization`): registered in manifests, included in `full` and `team` profiles
-- **Post-install check** (`bin/lib/post-install-rtk.js`): detects rtk/jq availability, prints install instructions
-
-## Risk Assessment
-
-- Low risk: hook silently skips if rtk/jq not installed
-- No binary bundling: rtk installed separately via Homebrew/curl
-- No upstream code copied: only adapted hook script and documentation
-- Apache-2.0 license: fully compatible with MIT
-
-## Approval
-
-- Approved for integration into `hooks` + `skills` layers
-- Not bundled as binary (unlike oris-claude-bridge) — external dependency

package/docs/runbooks/rtk-token-optimization-usage.md

@@ -1,107 +0,0 @@
-# RTK Token Optimization — Usage Guide
-
-## Overview
-
-[rtk](https://github.com/rtk-ai/rtk) is a high-performance CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. It's integrated into the harness via a PreToolUse:Bash hook that transparently rewrites shell commands.
-
-## Prerequisites
-
-```bash
-# macOS (recommended)
-brew install rtk
-
-# Linux / macOS alternative
-curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
-
-# Cargo
-cargo install --git https://github.com/rtk-ai/rtk
-```
-
-Also requires `jq` for the hook script:
-```bash
-brew install jq   # macOS
-apt install jq     # Debian/Ubuntu
-```
-
-## How It Works
-
-After harness installation (`install-apply.js --profile full`), the `pre:bash:rtk-rewrite` hook is registered in `hooks.json`. When Claude Code executes any Bash command:
-
-1. The hook captures the command text
-2. Calls `rtk rewrite "<command>"` to check for an optimized version
-3. If found, rewrites the command (e.g., `git status` → `rtk git status`)
-4. The rewritten command produces compressed output, saving 60-90% tokens
-5. Other safety hooks (block-no-verify, commit-quality) still execute normally
-
-## Token Savings Estimate (30-min Session)
-
-| Operation | Standard Tokens | With rtk | Savings |
-|-----------|----------------|----------|---------|
-| ls / tree (10x) | 2,000 | 400 | -80% |
-| cat / read (20x) | 40,000 | 12,000 | -70% |
-| git status/diff/log (20x) | 15,500 | 3,600 | -77% |
-| cargo/npm test (5x) | 25,000 | 2,500 | -90% |
-| **Total** | **~118,000** | **~23,900** | **-80%** |
-
-## Analytics
-
-```bash
-rtk gain                # Summary stats
-rtk gain --graph        # ASCII graph (last 30 days)
-rtk gain --daily        # Day-by-day breakdown
-rtk discover            # Find missed savings opportunities
-rtk session             # Show adoption across recent sessions
-```
-
-## Configuration
-
-RTK config: `~/.config/rtk/config.toml` (macOS: `~/Library/Application Support/rtk/config.toml`)
-
-```toml
-[hooks]
-exclude_commands = ["curl", "playwright"]  # skip rewrite for these
-
-[tee]
-enabled = true          # save raw output on failure
-mode = "failures"       # "failures", "always", or "never"
-max_files = 20          # rotation limit
-```
-
-## Hook Coexistence
-
-The harness rtk hook is **adapted** from the upstream version:
-
-- Does NOT return `permissionDecision: allow` (upstream does)
-- This ensures safety hooks (block-no-verify, commit-quality, prompt-guard) still execute
-- Placed near the end of the PreToolUse:Bash chain, after all safety checks
-- If rtk or jq is not installed, the hook silently exits (zero impact)
-
-## Tee: Full Output Recovery
-
-When a command fails, rtk saves the full unfiltered output:
-```
-FAILED: 2/15 tests
-[full output: ~/.local/share/rtk/tee/1707753600_cargo_test.log]
-```
-
-## Scope Limitations
-
-The hook only applies to **Bash tool calls**. Claude Code built-in tools (`Read`, `Grep`, `Glob`) bypass the hook. To get RTK filtering for those workflows, use shell commands (`cat`, `rg`, `find`) or call `rtk read`, `rtk grep`, `rtk find` directly.
-
-## Troubleshooting
-
-| Issue | Fix |
-|-------|-----|
-| `rtk` not found | Run `brew install rtk` or check PATH |
-| `jq` not found | Run `brew install jq` |
-| Hook not firing | Check `rtk init --show` and verify hooks.json has `pre:bash:rtk-rewrite` |
-| Wrong rtk package | `rtk gain` should work; if not, uninstall and use `cargo install --git https://github.com/rtk-ai/rtk` |
-| Conflicts with safety hooks | The adapted hook does not auto-allow; if issues persist, disable with hook flags |
-
-## References
-
-- [rtk GitHub](https://github.com/rtk-ai/rtk)
-- [rtk Troubleshooting](https://github.com/rtk-ai/rtk/blob/master/docs/TROUBLESHOOTING.md)
-- [rtk Architecture](https://github.com/rtk-ai/rtk/blob/master/docs/contributing/ARCHITECTURE.md)
-- Skill definition: `skills/rtk-token-optimization/SKILL.md`
-- Hook: `hooks/rtk-rewrite.sh`

package/docs/runbooks/runner-egress-hardening.md

@@ -1,81 +0,0 @@
-# Runner Egress Hardening 手册
-
-本手册承接 `step-security/harden-runner` 的工程实践，用于把 GitHub Actions runner 的出站网络控制、实时监测和告警纳入供应链治理链。它补的是“runner 在执行 workflow 时能访问什么、实际访问了什么、异常访问如何被发现”这一层，不替代 `scorecard-supply-chain-gates`、`artifact-attestation-gates`、`slsa-verification-gates`、`trivy-security-gates` 或人工发布判断。
-
-## 适用场景
-
-- 仓库大量依赖 GitHub Actions 执行构建、测试、打包或发布。
-- 团队希望限制 runner 的出站访问面，减少被恶意 workflow、依赖投毒或意外脚本带出凭据的风险。
-- 需要把 runner 的 runtime egress 行为纳入审计，并在异常访问、未知域名或可疑连接出现时及时发现。
-- 仓库已经有仓库级供应链基线检查，但还缺“runner 运行时层”的硬化与监测。
-
-## 不适用场景
-
-- 仓库没有 GitHub Actions，或 runner 不在团队控制范围内。
-- 团队还没有整理清楚 workflow 需要访问的外部域名、包仓库、镜像仓库和发布端点。
-- 期望 runner egress hardening 替代 Scorecard、依赖门禁、代码扫描或制品证明链。
-- 团队没有人负责维护 allowlist、例外流程和告警 triage。
-
-## 推荐落地方式
-
-1. 先把 runner egress hardening 看成“执行时防线”，不要一开始就把它设成全集仓库硬门禁。
-2. 第一阶段先收窄到少量关键 workflow：
-   - 构建与发布 workflow
-   - 访问私有包仓库或制品仓库的 workflow
-   - 处理敏感凭据、签名或 provenance 的 workflow
-3. 先建立 egress 基线：
-   - runner 必须访问哪些固定域名
-   - 哪些第三方服务必须显式放行
-   - 哪些连接应当被默认拒绝
-4. 将 runner egress hardening 与现有链路分层：
-   - `scorecard-supply-chain-gates` 负责仓库、workflow、token 权限和 action pinning 的静态基线
-   - `dependency-review-gates` 负责依赖漏洞与许可证变化
-   - `codeql-pr-security-gates` 负责代码级语义问题
-   - `runner-egress-hardening` 负责 workflow 运行时的出站访问控制与监测
-5. 先从“观察模式”或“少量 workflow 强化”开始，再逐步收紧 allowlist。
-6. 结果必须回写到 `/team-review`、`/team-release` 或仓库治理记录，不让 runner 告警只停在 action 日志里。
-
-## 最小门禁模型
-
-- `workflow layer`：被硬化的 GitHub Actions workflow 与 job
-- `egress layer`：允许或拒绝的出站域名、IP、协议和端点
-- `monitoring layer`：runner 运行时捕获到的访问事件、命中规则和告警
-- `decision layer`：安全评审角色、`devops-engineer`、`tech-lead` 决定异常 egress 是否阻塞发布或需要治理
-
-重点不是“装了一个 runner wrapper”，而是 runner 的实际访问行为能够被解释、审计和回放。
-
-## 重点检查项
-
-- workflow 是否明确列出必须访问的外部服务，而不是默认放开全网
-- allowlist 是否覆盖包仓库、镜像仓库、签名/证明服务和必要的 API 端点
-- 是否能区分“预期访问”和“异常访问”，避免大量误报淹没告警
-- secret、token 或构建凭据是否会在 runner 运行时被意外外带
-- 当新 workflow 或新依赖加入时，allowlist 是否同步更新，而不是长期漂移
-
-## 反模式
-
-- 只把 hardening 当成一个装饰性 action，实际上没有真正限制 egress。
-- allowlist 写得过宽，最后等于没有硬化。
-- 发现异常连接后只看一次性告警，没有 triage、回退和例外处理。
-- 把 runner egress hardening 当成 Scorecard 的替代品，而忽略它只是运行时防线。
-- 只在生产发布 workflow 上启用，开发和测试 workflow 完全不管，导致基线不一致。
-
-## 输出回落
-
-- PR 阶段：把新增的外部访问面、allowlist 变化和异常 egress 结论写入 review 摘要。
-- 团队协作：在 `/team-review` 中说明哪些访问是预期的，哪些是需要治理或阻塞的异常。
-- 发布阶段：若 runner egress 出现高风险异常或 allowlist 未收敛，必须回写到 `/team-release` 的风险、放行结论或后续观察项。
-- 治理阶段：把长期保留的例外、第三方端点和网络依赖沉淀到 runbook 或治理待办中。
-
-## 许可证与使用边界
-
-- `step-security/harden-runner` 采用 Apache-2.0。
-- 启用前应确认 GitHub Actions 使用方式、runner 类型、网络出口控制能力和告警 triage 人力。
-- 若团队尚未有 `scorecard-supply-chain-gates`、`dependency-review-gates` 等基础门禁，runner egress hardening 应先作为补充防线，而不是唯一安全控制。
-
-## 参考来源
-
-- [step-security/harden-runner](https://github.com/step-security/harden-runner)
-- [scorecard-supply-chain-gates.md](scorecard-supply-chain-gates.md)
-- [dependency-review-gates.md](dependency-review-gates.md)
-- [codeql-pr-security-gates.md](codeql-pr-security-gates.md)