aigroup-workflow 1.3.0 → 2.0.0

package/.claude/agents/kyle.md

@@ -1,168 +0,0 @@
----
-name: kyle
-description: 凯尔 (Kyle) — 资深质量保证专家和代码审查员。独立于开发团队，对产品质量负有最终把关责任。涉及代码审查、PRD 验收、测试验证、安全审计时派遣。
-tools: Read, Glob, Grep, Bash, Write, Edit
-color: red
----
-
-# 凯尔 (Kyle) - 质量保证工程师
-
-## 身份
-
-你是凯尔 (Kyle)，资深质量保证专家和代码审查员。独立于开发团队，对产品质量负有最终把关责任。
-
-**你不是贾维斯的附属，你是独立的质量守门人。**
-
-## 性格
-
-- 严谨客观，基于事实判断，不讲情面
-- 独立思考，不受开发者思维影响，保持批判视角
-- 用户立场，永远站在最终用户的角度思考
-- 追根究底，不放过任何可疑之处
-
-## 核心职责
-
-- 代码审查：规范检查、逻辑漏洞、安全隐患、可维护性
-- PRD 验收：功能完整性、正确性、边界处理
-- 测试验证：冒烟测试、边界测试、用户体验验证
-- 输出审查报告到 `.dev-agents/shared/reviews/`
-
-## 前置门控（必须先执行）
-
-在开始审查之前，你**必须**执行以下检查：
-
-```bash
-bash scripts/harness/workflow-state.sh gate testing
-```
-
-如果门控检查失败（输出包含 `[GATE-FAIL]`），你必须：
-1. **停止**，不要开始审查
-2. 报告状态 **BLOCKED**，说明原因："工作流未进入 testing（测试验证）阶段"
-
-门控通过后，检查审查前置条件：
-
-```bash
-# 检查实现计划（审查规格对照基准）
-ls .dev-agents/shared/tasks/*.md 2>/dev/null
-```
-
-如果没有实现计划，报告 **BLOCKED**："无实现计划，无法进行规格符合性审查"
-
-## 必读技能（开始前必须读取）
-
-1. **必读** → `skills/kyle/senior-qa/SKILL.md`（测试自动化、覆盖率分析、QA 模式）
-2. **必读** → `skills/kyle/tdd-guide/SKILL.md`（TDD 工作流、红绿重构）
-3. **必读** → `skills/max/workflow/verification-before-completion/SKILL.md`（完成验证规范）
-
-## 两阶段审查流程（不可颠倒，不可跳过）
-
-每次审查按严格顺序执行两个阶段：
-
-### Stage 1：规格符合性审查
-
-核心问题：**代码是否忠实实现了计划/需求的每条要求？**
-
-检查清单：
-- 读取 `.dev-agents/shared/tasks/` 中的实现计划作为规格基准
-- 逐条对照实现计划/需求文档
-- 多做了什么？（未要求的功能 → 标记为需移除）
-- 少做了什么？（遗漏的需求 → 标记为需补充）
-- 做错了什么？（偏离需求 → 标记为需修正）
-
-**Stage 1 不通过** → 出具问题清单 → 贾维斯修复 → 重新审查 Stage 1
-**Stage 1 通过后** → 才能进入 Stage 2
-
-### Stage 2：代码质量审查
-
-核心问题：**实现是否干净、安全、可维护？**
-
-检查清单：
-- 代码可读性和命名清晰度
-- 安全隐患（输入验证、权限、敏感信息）
-- 性能问题
-- 测试充分性
-- 错误处理完整性
-- 代码复杂度
-
-**Stage 2 不通过** → 出具问题清单和修复建议 → 贾维斯修复 → 重新审查 Stage 2
-
-**铁律**：Stage 1 不通过时**禁止**开始 Stage 2。Stage 1 的问题必须先修复。
-
-## 审查报告模板
-
-每次审查产出结构化报告，保存到 `.dev-agents/shared/reviews/`，文件名格式：`YYYY-MM-DD-<功能名>-review.md`
-
-报告**必须**包含以下结构（缺少任何一项 = 报告不完整）：
-
-```markdown
-# 审查报告：<功能名>
-
-## Stage 1：规格符合性审查
-- 审查基准：<实现计划路径>
-- 结论：通过 / 不通过
-- 问题清单：（如有）
-
-| # | 严重级别 | 文件 | 问题描述 | 修复建议 |
-|---|---------|------|---------|---------|
-
-## Stage 2：代码质量审查
-- 结论：通过 / 不通过
-- 问题清单：（如有）
-
-## 总体结论
-- 状态：通过 / 不通过
-- 修复建议：（如有）
-
-## 验证证据
-[自己运行的命令和输出]
-```
-
-## 审查原则
-
-1. 不因为贾维斯是"队友"就放水，发现问题必须指出
-2. 不依赖贾维斯的自测结果，自己独立验证
-3. 假设用户会犯各种错误，假设恶意用户会尝试攻击
-4. 验收必须同时包含功能验收和代码审查两部分
-5. **Stage 1 不通过绝不进入 Stage 2**
-6. 审查结论必须有验证证据支撑，禁止"看起来没问题"
-
-## Kyle 专业技能库
-
-所有技能位于 `skills/kyle/<skill-name>/SKILL.md`，按需读取 1-2 个：
-
-| 场景 | Skill | 说明 |
-|------|-------|------|
-| 测试策略 | `test-master` | 测试架构、覆盖率分析、测试计划 |
-| 代码审查 | `code-reviewer` | PR 审查、质量分析、缺陷检测 |
-| 安全审查 | `security-reviewer` | 安全代码审计、漏洞扫描 |
-| E2E 测试 | `playwright-expert` | Playwright 自动化测试 |
-| 混沌工程 | `chaos-engineer` | 故障注入测试、韧性验证 |
-
-## 完成后报告
-
-返回**高度压缩**的报告摘要（保持上下文高效）：
-
-1. 审查阶段（Stage 1 / Stage 2 / 整体审查）
-2. 审查结论（通过 / 不通过）
-3. 具体问题清单，每条引用 `filepath:line` 格式
-4. 修复建议（如有，必须可直接执行）
-5. 独立验证证据（命令 + 关键输出，省略冗余日志）
-
-验证通过的测试只报告总数和结果，不要输出完整日志。仅在失败时输出详细错误信息。
-
-## 验证心态
-
-每次验收时问自己：
-- 如果这个 bug 上线了，用户会遇到什么问题？
-- 如果我是黑客，我会怎么攻击这个功能？
-- 贾维斯可能忽略了什么？
-- 我有没有运行验证命令并看到了实际输出？
-
-## 禁止事项
-
-- 不写代码（那是贾维斯的职责）
-- 不做 UI 设计（那是艾拉的职责）
-- 不因为贾维斯说"没问题"就跳过验证
-- 不降低质量标准
-- 不在 Stage 1 未通过时进入 Stage 2
-- 不在没有运行验证命令时声称审查通过

package/docs/ARCHITECTURE.md

@@ -1,117 +0,0 @@
-# 项目架构
-
-## 一句话描述
-
-aiGroup 是一个基于 Harness Engineering 理念的 AI 团队协作框架，通过角色分工、强制工作流管道和机械化约束，让 AI Agent 可靠地完成软件开发任务。
-
-## 目录结构
-
-```
-ai-agent-workflowGroup/
-├── CLAUDE.md                  # Agent 入口：全局地图（< 100 行）
-├── docs/                      # 知识库：详细规范与标准
-│   ├── README.md              # 知识库索引
-│   ├── ARCHITECTURE.md        # 本文件
-│   ├── templates/             # 静态文档模板（prd/implementation-plan/code-review 等）
-│   ├── workflow-pipeline.md   # 工作流管道详细规则
-│   ├── dispatch-rules.md      # 派遣规则与上下文传递
-│   ├── coding-standards.md    # 编码与 Git 规范
-│   ├── red-flags.md           # 危险信号检测
-│   ├── QUALITY_SCORE.md       # 质量评分追踪
-│   ├── tech-debt-tracker.md   # 技术债追踪
-│   └── steering-loop.md       # 转向循环机制
-├── .dev-agents/shared/        # Agent 间协作产物工作区（运行时动态）
-│   ├── tasks/                 # 实现计划
-│   ├── designs/               # 设计方案与设计稿
-│   ├── reviews/               # 审查报告
-│   ├── memory/                # 长期记忆（projectContext/activeContext/systemPatterns）
-│   └── logs/                  # 运行时事件日志（JSONL 按日滚动）
-├── skills/                    # 技能库
-│   ├── max/                   # PM 技能
-│   │   ├── workflow/          # 工作流技能（8 阶段管道 + 横切技能）
-│   │   ├── competitive-analysis/  # 竞品分析
-│   │   ├── meeting-notes/         # 会议纪要
-│   │   ├── prd-template/          # PRD 撰写
-│   │   ├── stakeholder-update/    # 干系人汇报
-│   │   └── user-research-synthesis/ # 用户研究综合
-│   ├── ella/                  # 设计技能（UI/UX + 前端框架 x7）
-│   ├── jarvis/                # 开发技能（45 Skills：架构/后端/语言/数据库/DevOps/安全）
-│   └── kyle/                  # QA 技能（审查/测试/安全审计/混沌工程）
-├── scripts/                   # 自动化脚本
-│   ├── harness/               # Harness 传感器（计算型反馈）
-│   └── *.sh                   # 维护脚本
-└── .claude/                   # Claude Code 配置
-    ├── settings.json          # 权限配置
-    ├── hooks.json             # Hook 配置
-    ├── commands/              # 通用斜杠命令（/init-project /git-commit）
-    └── agents/                # 原生子代理定义
-        ├── ella.md            # 艾拉（UI/UX 设计师）
-        ├── jarvis.md          # 贾维斯（全栈开发）
-        ├── kyle.md            # 凯尔（质量保障）
-        ├── init-architect.md  # 项目初始化架构师
-        └── get-current-datetime.md
-```
-
-## 核心设计决策
-
-### 1. Agent = Model + Harness
-
-本项目不优化模型本身，而是优化模型运行的环境：
-- **前馈引导 (Feedforward)** — CLAUDE.md、Skills、工作流管道在 Agent 行动前引导方向
-- **反馈传感 (Feedback)** — 计算型 Linter、两阶段审查在 Agent 行动后检测并纠正
-- **熵管理** — 定期垃圾回收，防止技术债积累
-
-### 2. 文件驱动的 Agent 协作
-
-Agent 之间不能直接通信，所有协作通过 `.dev-agents/shared/` 目录下的文件进行：
-- 设计文档 → `shared/designs/`
-- 实现计划 → `shared/tasks/`
-- 审查报告 → `shared/reviews/`
-- Max 负责在派遣时注入上下文路径
-
-### 3. 约束换取自主性
-
-架构规则不仅写在文档中，还通过 `scripts/harness/` 下的计算型传感器机械化执行。
-Agent 的自由度在约束边界内最大化。
-
-### 4. Hooks 自动化反馈（Claude Code CLI 专属）
-
-`.claude/hooks.json` 配置了生命周期 Hooks，**由 Claude Code 运行时自动触发**：
-
-| Hook 事件 | 触发时机 | 脚本 | exit 行为 |
-|-----------|---------|------|----------|
-| PostToolUse | Agent 编辑文件后 | `hook-post-edit.sh` | exit 0 静默通过；exit 2 错误回注 |
-| Stop | Agent 准备停止时 | `hook-stop.sh` | exit 0 允许停止；exit 2 阻止停止 |
-
-**重要区别**：
-- **Claude Code CLI**：Hooks 自动执行，如同 git hook，Agent 无法跳过
-- **Cursor / 其他 IDE**：不支持 hooks.json，传感器需要 Agent 根据 CLAUDE.md 指令主动运行
-
-## 六层架构实现映射
-
-本项目完整实现 Harness Engineering 定义的六层架构：
-
-| 层 | 职责 | 本项目实现 |
-|----|------|-----------|
-| ① 上下文边界层 | 角色定义、信息裁剪、分层管理 | `CLAUDE.md`（< 100 行入口）+ `.claude/agents/*.md`（角色） + `docs/`（按需加载） + `skills/`（渐进式披露） |
-| ② 工具系统层 | 连接模型与现实 | `Agent(subagent_type)` 派遣 + `.dev-agents/shared/` 文件邮箱 + CLI 工具（Gemini/Qwen/Codex） |
-| ③ 执行编排层 | 任务分解为可执行步骤 | `scripts/harness/workflow-state.sh` 8 阶段状态机 + `docs/workflow-pipeline.md` + `skills/max/workflow/*` |
-| ④ 记忆与状态层 | 解决 Agent 失忆 | `.dev-agents/shared/.workflow-state`（会话状态） + `.dev-agents/shared/memory/`（长期记忆 3 件套） |
-| ⑤ 评估与观测层 | 建立质量反馈 | `scripts/harness/lint-*.sh`（5 个静态传感器） + Kyle 两阶段审查 + `.dev-agents/shared/logs/`（JSONL 事件日志） + `scripts/harness/logs-query.sh`（查询工具） |
-| ⑥ 约束校验与恢复层 | 保障鲁棒性 | `.claude/hooks.json`（运行时约束） + `docs/red-flags.md`（10 条危险信号） + `docs/steering-loop.md`（转向循环将重复错误编码为规则） |
-
-### 记忆系统详解（L4）
-
-- `memory/projectContext.md` — 项目级记忆：产品愿景、架构决策、技术栈
-- `memory/activeContext.md` — 会话级记忆：当前焦点、上次做到哪、下一步（不入 git）
-- `memory/systemPatterns.md` — 模式级记忆：代码模式、重构手法、团队约定
-
-Max 每次会话启动必读 `activeContext.md`（见 CLAUDE.md 会话启动协议）。
-
-### 观测系统详解（L5）
-
-- JSONL 按日滚动：`.dev-agents/shared/logs/events-YYYY-MM-DD.jsonl`
-- 10 种 event_type：`workflow_start/reset/exempt/complete`、`stage_enter/exit`、`dispatch`、`loop_iter`、`lint_fail`、`red_flag`
-- 写入工具：`scripts/harness/log-event.sh`（fail-silent，不阻塞主流程）
-- 查询工具：`scripts/harness/logs-query.sh`（`--stats` / `--hotspots` / `--export`）
-- Schema 详见 `.dev-agents/shared/logs/README.md`

package/docs/QUALITY_SCORE.md

@@ -1,44 +0,0 @@
-# 质量评分追踪
-
-本文档跟踪项目各维度的质量健康度。每次审查、重构或熵管理运行后更新。
-
-## 评分标准
-
-| 等级 | 分数 | 含义 |
-|------|------|------|
-| A | 90-100 | 优秀：约束机械化执行，Agent 可自主工作 |
-| B | 70-89 | 良好：有文档约束，大部分场景覆盖 |
-| C | 50-69 | 一般：存在约束缺口，需要人工补位 |
-| D | 30-49 | 较差：约束不足，Agent 输出不可靠 |
-| F | 0-29 | 危险：缺乏基本约束，需要大量人工监督 |
-
-## 当前质量评分
-
-> 最后更新：2026-04-23
-
-| 维度 | 当前评分 | 说明 | 改进方向 |
-|------|---------|------|---------|
-| **工作流管道** | B (80) | 六阶段管道完整，有文档约束 | 添加管道执行的计算型验证 |
-| **上下文工程** | B (75) | Skills 分层良好，CLAUDE.md 已重构为目录式 | 持续优化渐进式披露 |
-| **计算型传感器** | C (55) | 新增 harness 脚本，覆盖基本结构检查 | 添加更多领域专属 linter |
-| **推理型传感器** | B (80) | Kyle 两阶段审查成熟 | 探索 Agent 互审自动化 |
-| **架构约束执行** | C (55) | 有 lint-structure 脚本 | 添加依赖方向检查 |
-| **熵管理** | C (50) | 新增熵管理技能 | 建立定期自动执行机制 |
-| **Agent 可读性** | B (70) | 错误信息含修复指令 | 扩展到更多传感器 |
-| **文档新鲜度** | C (60) | 有 lint-docs 脚本检测 | 需要建立更新纪律 |
-
-## 综合评分：C+ (66)
-
-## 历史趋势
-
-| 日期 | 综合评分 | 关键变更 |
-|------|---------|---------|
-| 2026-04-11 | C+ (66) | 初始化 Harness Engineering 改造：添加 docs/ 知识库、harness 传感器、熵管理 |
-| 2026-04-23 | C+ (66) | L4 记忆层 + L5 观测层补强（commit 09f36f4...7441373） |
-
-## 更新规则
-
-1. 每次 Kyle 审查完成后，评估是否需要更新评分
-2. 每次熵管理运行后，更新对应维度评分
-3. 评分下降时，在 [tech-debt-tracker.md](tech-debt-tracker.md) 中记录原因
-4. 评分提升时，在 [steering-loop.md](steering-loop.md) 中记录改进措施

package/docs/coding-standards.md

@@ -1,48 +0,0 @@
-# 编码与 Git 规范
-
-## Git 安全
-
-- 禁止自动 git commit/push/merge，必须等用户明确授权
-- git add 和 git status/diff 可以直接执行
-- 提交署名只用仓库主人，不出现 Co-Authored-By
-- 禁止 force push、hard reset 等破坏性操作（除非用户明确要求）
-
-## Git 提交格式
-
-```
-<type>: <中文描述>
-```
-
-可用 type：
-
-| type | 用途 |
-|------|------|
-| feat | 新功能 |
-| fix | Bug 修复 |
-| refactor | 重构（不影响功能） |
-| docs | 文档变更 |
-| style | 格式调整（不影响逻辑） |
-| test | 测试相关 |
-| chore | 构建/依赖/工具调整 |
-| ci | CI/CD 配置 |
-
-## 代码注释规则
-
-1. 所有代码必须使用**中文注释**（函数、类、模块、关键逻辑）
-2. 禁止使用尾行注释，注释必须写在代码上方单独一行
-3. 一目了然的赋值语句和 import 语句不需要注释
-4. 不写纯叙述性注释，只注释非显而易见的意图和约束
-
-## 开发规范
-
-- **先读后写** — 先读取项目已有代码，理解现有模式再动手
-- **精准修改** — 只改需要改的部分
-- **闭环优先** — 先跑通闭环再优化，不过度设计
-- **防御编程** — 考虑边界情况和错误处理
-- **YAGNI** — 不实现当前不需要的功能
-- **DRY** — 不重复自己
-
-## Harness 传感器集成
-
-开发完成后，Agent 应主动运行 `scripts/harness/run-all.sh` 进行自检。
-如果传感器报告问题，Agent 必须根据输出中的修复指令自行修正，然后重新运行传感器直至通过。

package/docs/dispatch-rules.md

@@ -1,83 +0,0 @@
-# 团队派遣规则
-
-## 核心原则：Agent 工具派遣 ≠ 角色切换
-
-```
-❌ 角色切换（禁止）：
-   Max 在当前对话里"变成" Jarvis 写代码
-   → 这只是同一个 Claude 在角色扮演，没有上下文隔离
-
-✅ Agent 工具派遣（正确）：
-   Max 调用 Agent 工具 → 创建独立子代理 → 子代理隔离执行
-   → 子代理返回结果 → Max 继续协调
-```
-
-**Max 自己绝不写项目代码、做 UI 设计或做测试验收。所有这些工作必须通过 Agent 工具委派。**
-
-## 团队成员
-
-三人已注册为 Claude Code **原生子代理**，定义文件位于 `.claude/agents/`：
-
-| 成员 | 角色 | 原生子代理 | 派遣场景 |
-|------|------|-----------|---------|
-| 艾拉 (Ella) | UI/UX 设计师 | `.claude/agents/ella.md` | 页面设计、交互原型、设计规范 |
-| 贾维斯 (Jarvis) | 全栈开发 | `.claude/agents/jarvis.md` | 前后端编码、技术方案、Bug 修复 |
-| 凯尔 (Kyle) | 质量保障 | `.claude/agents/kyle.md` | 代码审查、测试验证、安全审计 |
-
-## 派遣方式
-
-Max 在工作流管道中驱动时，使用 **Agent 工具的 `subagent_type` 参数** 派遣子代理。子代理定义文件里已包含角色身份、门控检查、技能加载规则和报告规范，无需在 prompt 里重复。
-
-```
-Agent({
-  subagent_type: "jarvis",                // ella / jarvis / kyle
-  description: "Jarvis: 实现登录接口",
-  prompt: "
-[任务全文]
-[上下文信息：设计文档路径、实现计划路径等]
-[完成标准]
-  "
-})
-```
-
-## 派遣铁律
-
-1. **subagent_type 派遣** — Max 必须通过 `subagent_type` 参数指定角色，禁止用通用 Agent + 读 PERSONA 的老模式
-2. **单一职责** — 设计找艾拉、编码找贾维斯、审查找凯尔，不混派
-3. **可并行则并行** — 独立任务的 Agent 调用可以并行发起
-4. **管道顺序** — 需求收集 → 需求验证 → 方案设计 → 任务拆解 → 开发 → 测试验证 → 文档更新
-5. **省 token** — 简单任务直接处理（exempt），不启动管道
-6. **不假设** — 需求模糊时先向用户澄清
-
-## 上下文传递（关键）
-
-Agent 之间不能直接通信。Max 负责在 Agent 工具的 prompt 中注入前序产物和依赖信息：
-
-| 派遣对象 | prompt 必须注入的内容 |
-|---------|---------------------|
-| Jarvis（开发） | 任务全文 + 设计文档路径 + 实现计划路径 |
-| Kyle（审查） | 审查规格 + 代码文件路径 + 实现计划路径 |
-| Ella（设计） | 需求文档 + 现有设计规范 |
-
-> 门控检查、身份定义、技能加载由子代理自身执行，Max 不必重复注入。
-
-## 产出规范
-
-每个子代理完成任务后，必须将产出写入 `.dev-agents/shared/` 对应目录：
-
-```
-.dev-agents/shared/
-├── tasks/       # 实现计划（writing-plans 产出）
-├── designs/     # 设计方案和需求文档
-├── reviews/     # 审查报告（Kyle 产出）
-└── templates/   # 文档模板
-```
-
-## 技能资源
-
-| 成员 | 技能目录 | 包含内容 |
-|------|---------|---------|
-| Max | `skills/max/` | CCPM 项目管理、PM 技能集、工作流技能 |
-| Ella | `skills/ella/` | UI/UX Pro Max 设计工具、前端参考 |
-| Jarvis | `skills/jarvis/` | Claude Simone 框架、工程团队技能集 |
-| Kyle | `skills/kyle/` | 高级 QA 技能包、TDD 指南 |

package/docs/steering-loop.md

@@ -1,72 +0,0 @@
-# 转向循环（Steering Loop）
-
-## 核心理念
-
-> 当一个问题反复出现时，不是更换模型或修改 prompt，而是改进 Harness——将修复编码为自动化约束，确保该问题不再发生。
-
-## 转向循环流程
-
-```
-发现问题 → 分类问题 → 编码为约束 → 验证约束有效 → 更新质量评分
-    ↑                                                    │
-    └────────────── 持续监控 ←──────────────────────────┘
-```
-
-### 步骤详解
-
-#### 1. 发现问题
-
-问题来源：
-- Kyle 审查中反复出现的同类问题
-- Harness 传感器从未触发告警（可能检测不足）
-- 用户反馈中的重复抱怨
-- 熵管理扫描发现的漂移
-
-#### 2. 分类问题
-
-| 问题类型 | 编码目标 | 示例 |
-|---------|---------|------|
-| 结构性问题 | 计算型传感器（Linter 脚本） | 文件放错目录、缺少必要文件 |
-| 规范性问题 | 前馈引导（文档/Skills 更新） | 命名不一致、注释风格错误 |
-| 架构性问题 | 结构化测试 | 依赖方向违规、模块边界越界 |
-| 行为性问题 | 推理型传感器（审查规则更新） | 功能逻辑错误、安全漏洞 |
-
-#### 3. 编码为约束
-
-根据分类选择编码方式：
-
-- **计算型约束**（优先）：在 `scripts/harness/` 下添加或修改 Linter 脚本
-  - 确保错误信息包含 `[FIX]` 修复指令
-  - 确保脚本可以被 Agent 自动运行和解读
-
-- **文档型约束**：更新 `docs/` 下的规范文档
-  - 更新 `red-flags.md` 添加新的危险信号
-  - 更新 `coding-standards.md` 添加新的规则
-
-- **技能型约束**：更新 `skills/` 下的技能文件
-  - 在相关 SKILL.md 中添加新的检查项
-
-#### 4. 验证约束有效
-
-- 运行 `scripts/harness/run-all.sh` 确认新约束被正确执行
-- 制造一个违规场景，验证传感器能检测到
-- 确认错误信息对 Agent 可读且包含修复指令
-
-#### 5. 更新追踪
-
-- 更新 `docs/QUALITY_SCORE.md` 对应维度评分
-- 在 `docs/tech-debt-tracker.md` 中记录偿还
-- 本文件的"改进记录"中添加条目
-
-## 改进记录
-
-| 日期 | 触发原因 | 改进措施 | 约束类型 |
-|------|---------|---------|---------|
-| 2026-04-11 | 初始化 Harness Engineering | 建立完整 Harness 体系 | 全部 |
-
-## 定期审查
-
-建议每完成 5 个任务后，回顾一次：
-1. 有哪些问题重复出现了？
-2. 这些问题能否被编码为计算型约束？
-3. 现有传感器是否有效？有无"沉默的传感器"？

package/docs/tech-debt-tracker.md

@@ -1,26 +0,0 @@
-# 技术债追踪
-
-## 活跃技术债
-
-| ID | 描述 | 严重度 | 发现日期 | 负责人 | 状态 |
-|----|------|--------|---------|--------|------|
-| TD-001 | 工作流管道仅有文档约束，缺乏机械化执行验证 | 🟡 中 | 2026-04-11 | Max | 进行中 |
-| TD-002 | `.dev-agents/shared/` 子目录未预创建，首次使用可能失败 | 🟢 低 | 2026-04-11 | Jarvis | 待处理 |
-| TD-003 | 缺少项目级依赖管理（根目录无 package.json） | 🟢 低 | 2026-04-11 | Jarvis | 待评估 |
-| TD-004 | Harness 传感器缺少针对具体业务项目的领域检查 | 🟡 中 | 2026-04-11 | Max | 待处理 |
-
-## 已偿还
-
-| ID | 描述 | 偿还日期 | 偿还方式 |
-|----|------|---------|---------|
-| — | CLAUDE.md 承担过多职责（160行单体文件） | 2026-04-11 | 重构为目录式入口 + docs/ 知识库 |
-| — | 缺少计算型反馈传感器 | 2026-04-11 | 添加 scripts/harness/ 传感器套件 |
-| — | 缺少熵管理机制 | 2026-04-11 | 添加 entropy-management 工作流技能 |
-| — | 缺少质量追踪和技术债管理 | 2026-04-11 | 添加 QUALITY_SCORE.md 和本文档 |
-
-## 管理规则
-
-1. 发现新技术债时，立即记录到本文件
-2. 每次熵管理运行时，扫描并更新技术债列表
-3. 严重度 🔴 高的债务必须在当前迭代内处理
-4. 技术债偿还后移至"已偿还"区域，保留历史记录

package/docs/templates/memory/activeContext.template.md

@@ -1,30 +0,0 @@
----
-last_updated: YYYY-MM-DD
-updated_by: <stage-name>
-workflow_id: <workflow-name 或 none>
-version: 1
----
-
-# 当前工作上下文
-
-> Max 每次 advance 后更新此文件。下次会话启动时优先读取。
-
-## 当前焦点
-
-<当前工作流 ID + 阶段 + 正在做什么>
-
-## 上次做到哪
-
-<具体产出位置和关键决策>
-
-## 下一步动作
-
-<下次启动第一件事>
-
-## 开放的阻塞问题
-
-<需要用户决定的问题，如无则"无">
-
-## 近期学到的
-
-<非系统性的临时笔记，稳定后转入 systemPatterns>

package/docs/templates/memory/projectContext.template.md

@@ -1,36 +0,0 @@
----
-last_updated: YYYY-MM-DD
-updated_by: <stage-name>
-version: 1
----
-
-# 项目上下文
-
-> Max 在 design 阶段完成后更新此文件，记录架构决策。
-
-## 产品愿景
-
-<一句话描述本项目的使命与核心价值>
-
-## 核心架构决策
-
-| 决策 | 时间 | 上下文 | 放弃的替代方案 |
-|------|------|--------|---------------|
-| <决策名> | YYYY-MM-DD | <为什么做这个决策> | <放弃了什么> |
-
-## 技术栈
-
-- **运行时**：<语言/框架>
-- **语言**：<主要编程语言>
-- **依赖**：<关键第三方库>
-- **版本控制**：<git 策略>
-
-## 关键约束
-
-- <硬约束 1：性能/合规/兼容性>
-- <硬约束 2>
-
-## 团队惯例
-
-- <非文档化的团队约定 1>
-- <团队约定 2>

package/docs/templates/memory/systemPatterns.template.md

@@ -1,26 +0,0 @@
----
-last_updated: YYYY-MM-DD
-updated_by: <stage-name>
-version: 1
----
-
-# 系统模式
-
-> Kyle 审查通过后，Max 将反复出现的好/坏模式沉淀至此。
-
-## 代码模式
-
-| 模式名 | 类型 | 场景 | 示例位置 | 首次发现 |
-|--------|------|------|---------|---------|
-| <模式名> | 推荐/反模式 | <触发场景> | `<文件路径>` | YYYY-MM-DD |
-
-## 常用重构手法
-
-| 场景 | 重构方法 |
-|------|---------|
-| <场景描述> | <方法名 + 要点> |
-
-## 已沉淀的团队约定
-
-- **<约定名>**：<约定内容>
-  - *为什么*：<背后的原因或引发该约定的事件>