@colin4k1024/tsp 2.4.4 → 2.4.6

package/docs/runbooks/ecc-harness-usage.md

@@ -1,93 +0,0 @@
----
-version: "2.3.0"
-status: draft
-created: 2026-03-27
-updated: 2026-04-18
-owner: 工程团队
----
-
-# ECC Harness Usage
-
-本文说明如何在当前 Team Skills Platform 上使用 ECC 风格的 specialist layer、commands、rules 和运行时 hooks。它回答三个问题：哪些能力是用户直接调用的、哪些能力是后台机制、以及两者怎样回到主链。
-
-## 1. 双层模型
-
-- 主干：role-based Team Skills 平台，默认走 `/team-*`
-- 增强层：ECC harness layer，提供 specialists、快捷 commands、分层规则、runtime hooks 与底层存储/预算/学习机制
-
-## 2. specialist 使用方式
-
-- 规划类：`planner`、`architect`、`chief-of-staff`
-- review 类：`code-reviewer`、`security-reviewer`、语言 reviewers
-- 解决类：`build-error-resolver`、语言 build resolvers
-- 编排类：`loop-operator`、`harness-optimizer`
-
-## 3. 命令接入原则
-
-- `/team-*` 负责正式交付链
-- `/plan`、`/tdd`、`/code-review`、`/build-fix`、`/verify`、`/multi-*`、`/harness-audit` 等负责 specialist 快捷编排
-- specialist 命令的结论必须回落到 role handoff 或 `/team-*`
-
-一个实用判断是：
-
-- 业务任务优先从 `/team-*` 进入
-- 实现路径不清时切 `/plan` 或 `/tdd`
-- 代码已改完时切 `/code-review` 或 `/verify`
-- 平台本身要审视 coverage、hook、文档和集成深度时切 `/harness-audit`
-
-## 4. rules 与 skills
-
-- `rules/common/` 提供 specialist 共用工程规则
-- 语言规则目录提供专项 reviewer 的最小规则支撑
-- `skills/` 提供高频工程技能入口，不替代现有 `skills/`
-
-## 5. 运行时 hooks
-
-- `hooks/hooks.json` 是 hooks 配置入口。
-- `scripts/hooks/session-start.js`：在会话开始时加载最近一次会话摘要、待办和提示。
-- `scripts/hooks/session-end.js`：在会话结束时保存任务摘要、决策和下一次会话提示。
-- `scripts/hooks/pre-compact.js`：在压缩上下文前整理高价值信息。
-- `scripts/hooks/suggest-compact.js`：在上下文使用率升高时给出压缩建议。
-- `scripts/hooks/governance-capture.js`：观察关键工具调用与治理信号，供后续分析使用。
-- `scripts/hooks/cost-tracker.js`：记录成本事件和任务复杂度信号。
-- 底层状态与会话存储位于 [scripts/lib/state-store/index.js](../../scripts/lib/state-store/index.js)，默认写入运行时状态目录。
-
-## 6. runtime 能力分层
-
-### 6.1 用户直接感知到的能力
-
-- memory persistence：重新进入会话时能拿到摘要、待办和提示
-- strategic compact：长会话中出现压缩建议或强制整理
-- parallel execution：可将任务拆分到 worktree 或多实例路径
-- harness audit：可对平台能力面做 7 维评分和优先级建议
-
-### 6.2 后台机制
-
-- observation：`observe.py` 捕获工具与行为模式
-- instinct learning：`instinct_store.py` 维护项目级 / 全局级 instincts
-- cost awareness：`cost_tracker.py` 与 `context_budget.py` 管理成本和上下文预算
-- archive pipeline：`trigger_compact.py`、`context_priority.py`、`context_archiver.py` 负责上下文重组与归档
-
-### 6.3 典型流水线
-
-1. 进入会话：`session_start.py` 加载摘要与 pending items
-2. 执行任务：主链或 specialist 产出结果
-3. 观察记录：`observe.py` 捕获行为信号，必要时更新 instinct 数据
-4. 预算预警：`context_budget.py` 检测 70% / 85% 阈值
-5. 压缩归档：`suggest_compact.py` 或 `pre_compact.py` 配合 archive/priority/trigger 组件做重组
-6. 结束会话：`session_end.py` 保存摘要、决策与下一步提示
-
-## 7. 相关增强能力
-
-- 错误经验库：见 [error-experience-usage.md](error-experience-usage.md)
-- 并行执行框架：见 [parallel-execution-usage.md](parallel-execution-usage.md)
-- 完整 runtime 总览：见 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-- 完整演示场景：见 [demo-scenario.md](demo-scenario.md) 和 [demo-execution-log.md](demo-execution-log.md)
-
-## 8. 使用建议
-
-- specialist 负责专项分析，最终结论仍要回落到 `/handoff` 或 `/team-*`。
-- hooks 和 memory 能力属于运行时增强，不替代主链输出字段。
-- `harness-audit` 适合审视平台本身，不适合替代业务任务的 review 或 release。
-- `tdd`、`eval-harness`、`verify` 适合形成“先定义标准 -> 再实现 -> 再验证”的闭环。
-- 如果你要向团队展示整个平台，可直接使用 [../presentation/README.md](../presentation/README.md) 中的材料。

package/docs/runbooks/error-experience-usage.md

@@ -1,116 +0,0 @@
-# Error Experience Library 使用指南
-
-## 概述
-
-Error Experience Library（错误经验库）是一个持续学习的机制，用于：
-- 沉淀错误根因和解决方案
-- 避免重复踩坑
-- 加速问题排查
-
-## 数据存储
-
-```
-~/.claude/memory/error_experience/
-├── patterns/          # 错误模式库
-│   ├── build_error_*.json
-│   ├── runtime_error_*.json
-│   └── ...
-└── decisions/         # 决策快照
-    └── decision_*.json
-```
-
-## 使用场景
-
-### 场景 1：遇到错误时查询
-
-```
-用户：npm run build 失败了，报错 Cannot find module 'lodash'
-Agent：
-1. 调用 search_error_patterns(query="Cannot find module")
-2. 返回匹配的已知模式，按成功率排序
-3. 如果有高成功率匹配，直接提供解决方案
-4. 如果没有匹配，记录新问题并在解决后沉淀
-```
-
-### 场景 2：解决错误后记录
-
-```
-用户：修复了上述错误（需要安装 lodash）
-Agent：
-1. 调用 save_error_pattern() 记录：
-   {
-     "error_type": "module_not_found",
-     "error_message_snippet": "Cannot find module",
-     "root_cause": "missing dependency in package.json",
-     "solution": "npm install lodash",
-     "language": "typescript",
-     "framework": "node",
-     "tags": ["dependency", "npm"]
-   }
-2. 返回保存确认
-```
-
-### 场景 3：验证后反馈
-
-```
-Agent：尝试了解决方案，成功！
-Agent 调用 record_pattern_feedback(pattern_id="xxx", success=true)
-→ success_count +1
-
-Agent：尝试了解决方案，失败了
-Agent 调用 record_pattern_feedback(pattern_id="xxx", success=false)
-→ failure_count +1
-```
-
-## 命令行工具
-
-### 查询错误模式
-
-```bash
-python3 -c "
-from scripts.lib.memory_store import search_error_patterns
-patterns = search_error_patterns('Cannot find module')
-for p in patterns:
-    print(f'[{p.success_count - p.failure_count:+d}] {p.error_type}: {p.root_cause}')
-"
-```
-
-### 查看所有模式
-
-```bash
-ls ~/.claude/memory/error_experience/patterns/
-```
-
-### 查看模式详情
-
-```bash
-cat ~/.claude/memory/error_experience/patterns/<pattern_id>.json
-```
-
-## 与其他模块的配合
-
-### 与 build-error-resolver 配合
-
-`build-error-resolver` 解决错误后，应自动调用 `save_error_pattern()`。
-
-### 与 systematic-debugging 配合
-
-`s Systematic-debugging` 定位根因后，应自动调用 `save_error_pattern()`。
-
-### 与验证循环配合
-
-验证成功后，应自动记录反馈到经验库。
-
-## 最佳实践
-
-1. **具体性**：错误信息片段要具体，便于匹配
-2. **根因分析**：不要只写"代码有 bug"，要分析具体原因
-3. **可操作性**：解决方案要具体，包含实际命令或代码改动
-4. **及时反馈**：验证后立即提供反馈，更新成功率
-5. **标签准确**：标签要准确完整，便于按领域检索
-
-## 持续优化机制
-
-- 成功率 = success_count / (success_count + failure_count)
-- 按 (success_count - failure_count) 排序，优先推荐高置信度模式
-- failure_count 高的模式会被标记为警示

package/docs/runbooks/evolution-usage.md

@@ -1,162 +0,0 @@
-# Evolution System Usage Guide
-
-> 让 Agent 复用其他 Agent 的验证过经验，而不是每次从零开始。
-
-## 概述
-
-Evolution 系统受 [Oris](https://github.com/Colin4k1024/Oris) 框架启发，为 TSP（Team Skills Platform）提供 **经验基因（Gene）** 的创建、验证、衰退、共享能力。核心思路是：成功解决过的问题方案应该被沉淀为可复用的"基因"，在未来遇到相似信号时优先尝试已验证方案（Replay-First），而不是每次都走完整 LLM 推理。
-
-## 快速开始
-
-### 1. 启用 Evolution
-
-在环境变量中设置：
-
-```bash
-export ECC_ENABLE_EVOLUTION=1
-```
-
-或在 `hooks/hooks.json` 中将 `pre:evolution:replay-first` 和 `post:evolution:solidify` 的 enabled flag 设为 true。
-
-### 2. 迁移现有经验
-
-将已有的 error-experience-library 模式和 continuous-learning instinct 导入到 evolution store：
-
-```bash
-# 预览迁移（不写入）
-python3 scripts/evolution/migrate.py
-
-# 执行迁移
-python3 scripts/evolution/migrate.py --apply --verbose
-```
-
-### 3. 查看 Evolution 状态
-
-```bash
-# 查看 store 统计
-python3 -c "
-from scripts.evolution.store import EvolutionStore
-import json
-store = EvolutionStore()
-print(json.dumps({
-    'genes': len(store._genes),
-    'capsules': len(store._capsules),
-    'events': sum(1 for _ in open(store._events_path) if _.strip()),
-}, indent=2))
-"
-```
-
-## 核心概念
-
-### Gene（经验基因）
-
-| 字段 | 说明 |
-|------|------|
-| `gene_id` | 唯一标识 |
-| `signals` | 触发条件列表（错误模式、命令模式等） |
-| `strategy` | 解决方案（描述 + 步骤 + 约束） |
-| `confidence` | 置信度 0.10 – 0.95 |
-| `state` | `candidate` → `promoted` → `archived`（或 `quarantined` → `revoked`） |
-| `tags` | 分类标签（语言、框架、工具） |
-| `env_fingerprint` | 环境特征（生态系统、框架） |
-
-### Confidence 模型
-
-- 初始值：0.40
-- 每次成功复用：+0.05
-- 每次失败：-0.10
-- 上限：0.95，下限：0.10
-- 提升到 `promoted`：≥ 0.60 且至少 3 次成功
-- 连续 3 次失败：`quarantined`
-- 降到 0.15 以下：`revoked`
-
-### Replay-First 流程
-
-```
-Tool Call
-  ↓
-PreToolUse Hook → extract_signal()
-  ↓
-query_genes(signal, env) → ranked candidates
-  ↓
-confidence ≥ threshold? → Replay verified strategy
-  ↓ (no match)
-Normal LLM execution
-  ↓
-PostToolUse Hook → solidify outcome → create/reinforce gene
-```
-
-## 文件布局
-
-| 路径 | 说明 |
-|------|------|
-| `~/.claude/evolution/events.jsonl` | 追加式事件日志（真相源） |
-| `~/.claude/evolution/genes.json` | 基因投影缓存 |
-| `~/.claude/evolution/capsules.json` | 胶囊投影缓存 |
-| `~/.claude/evolution/governor.json` | Governor 配置 |
-| `~/.claude/evolution/network/` | 网络共享目录 |
-
-## Governor 安全控制
-
-Governor 防止 evolution 系统失控：
-
-| 限制 | 默认值 | 说明 |
-|------|--------|------|
-| `max_replays_per_session` | 20 | 单会话最大 replay 次数 |
-| `max_solidify_per_session` | 10 | 单会话最大 solidify 次数 |
-| `max_gene_creates_per_session` | 5 | 单会话最大基因创建数 |
-| `max_consecutive_failures` | 3 | 连续失败次数触发隔离 |
-| `gene_replay_cooldown_seconds` | 60 | 同一基因重试冷却时间 |
-
-配置覆盖顺序：默认值 → `~/.claude/evolution/governor.json` → 环境变量 `EVOLUTION_GOVERNOR_*`。
-
-## 网络共享
-
-启用跨 Agent 基因共享：
-
-```bash
-export EVOLUTION_NETWORK_ENABLED=1
-
-# 导出 promoted 基因
-python3 scripts/evolution/network.py share --verbose
-
-# 导入其他 agent 的基因
-python3 scripts/evolution/network.py pull --verbose
-
-# 查看网络状态
-python3 scripts/evolution/network.py status
-```
-
-网络接收的基因初始 confidence 为 0.30，需要本地成功执行 1 次才提升为正常候选。导出前自动脱敏路径和用户名。
-
-## 命令速查
-
-| 命令 | 说明 |
-|------|------|
-| `/evolve` | 分析 instinct 并建议演进 |
-| `/evolve migrate` | 迁移 error patterns + instincts |
-| `/evolve status` | 显示 evolution store 统计 |
-| `/evolve share` | 导出 promoted 基因 |
-| `/evolve pull` | 导入外部基因 |
-| `/replay` | 查看 replay 状态和近期匹配 |
-
-## 环境变量
-
-| 变量 | 默认值 | 说明 |
-|------|--------|------|
-| `ECC_ENABLE_EVOLUTION` | 未设置 | 设为 `1` 启用 evolution hooks |
-| `EVOLUTION_DISABLED` | 未设置 | 设为 `1` 禁用 evolution |
-| `EVOLUTION_MIN_CONFIDENCE` | `0.40` | replay 最低置信度 |
-| `EVOLUTION_MAX_CANDIDATES` | `3` | replay 最大候选数 |
-| `EVOLUTION_NETWORK_ENABLED` | 未设置 | 设为 `1` 启用网络共享 |
-
-## 与现有系统的关系
-
-| 现有系统 | 关系 |
-|---------|------|
-| error-experience-library | 可通过 `migrate.py` 导入为基因 |
-| continuous-learning (instincts) | 可通过 `migrate.py` 导入为基因 |
-| hooks 系统 | PreToolUse/PostToolUse hook 驱动 |
-| session persistence | session-end 可触发 solidify |
-
-Evolution 是对现有经验系统的增强，不替代它们。migrate 是可选操作，未迁移的 pattern/instinct 仍然独立工作。

package/docs/runbooks/executive-value-one-page.md

@@ -1,55 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
----
-
-# 管理层价值速查一页
-
-本文面向管理层、平台赞助人和需要快速判断投入产出的人，目标是在一页内回答 Team Skills Platform 值不值得继续推进。
-
-## 1. 先判断这页适不适合你
-
-- 你要的是价值判断，不是安装细节
-- 你要的是平台边界、落地面和当前成熟度
-- 你需要在 3 到 5 分钟内完成内部汇报或立项判断
-
-## 2. 一句话说明
-
-这不是 prompt 仓库，而是一套把角色分工、命令主链、specialist 能力、runtime 增强和 vertical 演示材料打包在一起的团队协作平台。
-
-## 3. 当前能直接说明的价值
-
-- 把需求、方案、研发、测试、发布收敛到统一主链：`/team-intake` 到 `/team-release`
-- 把高频专项能力变成可控插拔，而不是每次临时拼 prompt：`/plan`、`/tdd`、`/code-review`、`/build-fix`、`/verify`
-- 把 memory、并行分析、cost、compact 这类运行时能力沉淀成平台能力，而不是操作者个人技巧
-- 已经具备 9 条完整 vertical 闭环，可直接用于 onboarding、方案汇报和内部演示
-
-## 4. 管理层最关心的三个判断点
-
-### 4.1 是否只是文档堆积
-
-不是。平台有 canonical source、生成产物、安装脚本、校验脚本、命令面、角色面和 runbook/presentation 辅助资产。
-
-### 4.2 是否只能做单点试验
-
-不是。现在既能支撑首次接入，也能支撑日常研发、专项 review、跨角色 handoff 和发布收口。
-
-### 4.3 是否有可复用演示资产
-
-有。当前已经按 vertical 和按听众两条线把演示资产组织好，不需要每次从零准备讲稿。
-
-## 5. 最短阅读顺序
-
-1. [../presentation/executive-briefing-talk-track.md](../presentation/executive-briefing-talk-track.md)
-2. `docs/presentation/team-skills-platform-intro.pptx`（运行 generate_ppt.py 生成）
-3. `docs/presentation/agent-capability-matrix.pptx`（运行 generate_capability_matrix.py 生成）
-4. [vertical-scenario-capability-matrix.md](vertical-scenario-capability-matrix.md)
-
-## 6. 什么时候需要继续下钻
-
-- 想看实施接入方式：继续看 [implementation-onboarding-reading-path.md](implementation-onboarding-reading-path.md)
-- 想看团队培训材料：继续看 [team-training-reading-path.md](team-training-reading-path.md)
-- 想按听众选 presentation 材料：继续看 [../presentation/audience-presentation-route-map.md](../presentation/audience-presentation-route-map.md)

package/docs/runbooks/external-capability-approval-and-enablement-workflow.md

@@ -1,39 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-28
-updated: 2026-03-28
-owner: 工程团队
----
-
-# 开源能力评估到启用的完整流程
-
-本文说明一个外部能力如何从 `candidate` 进入 `approved`，再落到 `ecc`、`runbook` 或其他正式层，而不是只停留在 intake 台账里。
-
-## 1. 流程阶段
-
-1. intake：登记来源、许可证、适配层级和原因
-2. approval：判断是否值得引入
-3. enablement：本地化改写、链接 runbook、补校验
-4. rollout：接入命令流或文档索引
-
-## 2. approval 时必须确认什么
-
-- 许可证是否允许当前使用方式
-- 是否和现有能力重叠
-- 是要做 skill、runbook 还是 toolkit
-- 谁负责后续维护
-
-## 3. enablement 时必须完成什么
-
-- 本地化而不是整包搬运
-- 明确目标层级和目标名称
-- 更新文档入口和校验链路
-
-## 4. 常见错误
-
-- 台账里标记 `approved` 之后长期不落地
-- 能力已接入，但没有文档入口和维护责任人
-- 没判断 portability 就直接进入正式层
-
-与这些文档配合阅读：[external-capability-intake.md](external-capability-intake.md)、