@pzy560117/codex-harness 0.1.2 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/templates/design/visual-parity-review.md

@@ -1,124 +0,0 @@
-# Visual Parity Review 模板
-
-> 目标: 前端实现完成后，必须在真实浏览器中截图，并把实拍图与已评审通过的 UI 设计图对比。没有浏览器截图和图片对比证据，前端 UI 任务不能通过 Stage 1 Review。
-
-## 1. 评审对象
-
-| Feature ID | Page ID | State | Viewport | Route / URL | 设计参考图 | 浏览器实拍图 | 对比结论 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| | | default | Desktop 1440x900 | | `docs/design/assets/<feature>/<page>/default-desktop-reference.png` | `artifacts/visual-review/<feature>/<page>/default-desktop-actual.png` | PASS / FAIL |
-
-## 2. 前置条件
-
-- `ui-image-review.md` 对应图片已 PASS。
-- `image-to-frontend-spec.md` 已把设计图转成布局、组件、CSS/token、状态和数据规格。
-- 页面可以在真实浏览器打开。
-- 测试数据固定，避免商品名、价格、图片数量等动态内容导致误判。
-- 截图前关闭调试浮层、cookie 弹窗、浏览器扩展遮挡和非业务 toast。
-
-## 3. 产物目录规范
-
-```text
-docs/design/assets/<feature>/<page>/
-  <state>-<viewport>-reference.png
-
-artifacts/visual-review/<feature>/<page>/
-  <state>-<viewport>-actual.png
-  <state>-<viewport>-diff.png
-  <state>-<viewport>-review.md
-```
-
-说明:
-
-- `reference.png` 是评审通过的设计图或从设计稿导出的基准图。
-- `actual.png` 必须来自真实浏览器截图，不允许用设计图、静态 mock 图或裁剪后的局部图替代。
-- `diff.png` 可由视觉回归工具生成；如果没有像素 diff 工具，也必须生成 `review.md` 记录视觉模型或人工评审结论。
-- `artifacts/visual-review/` 可以进入 Git，也可以作为 CI artifact；如果不入 Git，trace / handoff 必须记录路径。
-
-## 4. 截图矩阵
-
-| Page ID | State | Viewport | 数据准备 | 参考图 | 实拍图 | 必须评审 |
-| --- | --- | --- | --- | --- | --- | --- |
-| | default | Desktop 1440x900 | | | | Yes |
-| | empty | Desktop 1440x900 | | | | Yes / N/A |
-| | loading | Desktop 1440x900 | | | | Yes / N/A |
-| | error | Desktop 1440x900 | | | | Yes / N/A |
-| | permission | Desktop 1440x900 | | | | Yes / N/A |
-| | long_content | Desktop 1440x900 | | | | Yes / N/A |
-| | default | Tablet 768x1024 | | | | Yes / N/A |
-| | default | Mobile 375x812 | | | | Yes / N/A |
-| | reduced_motion | Desktop 1440x900 | | | | Yes / N/A |
-
-## 5. 浏览器截图命令示例
-
-Playwright CLI 示例:
-
-```powershell
-New-Item -ItemType Directory -Force -Path .\artifacts\visual-review\pet-mall\home | Out-Null
-$env:VISUAL_BASE_URL = "http://localhost:5173"
-npx playwright screenshot --viewport-size=1440,900 "$env:VISUAL_BASE_URL/pets" ".\artifacts\visual-review\pet-mall\home\default-desktop-actual.png"
-```
-
-如果项目使用 browser / devtools 工具执行 E2E，也必须把截图保存到 `artifacts/visual-review/...`，并在报告中写明截图路径。
-
-## 6. 图片对比 Prompt
-
-把设计参考图和浏览器实拍图同时交给具备图片理解能力的 reviewer，使用以下提示词:
-
-```text
-请对比这两张图：
-1. 第一张是已评审通过的 UI 设计参考图。
-2. 第二张是真实浏览器截图。
-
-请只评审视觉还原，不重新设计页面。
-
-必须检查：
-- 页面结构、主次区域、导航、卡片、列表、表单和操作区是否一致。
-- 字体、字号、字重、行高、间距、圆角、阴影、边框、颜色是否明显偏离。
-- 商品图、图标、按钮、标签、价格、状态文本等业务元素是否缺失或多出。
-- 空态、加载态、错误态、移动端状态是否符合设计图和 screen-states。
-- 是否有文字溢出、遮挡、错位、重叠、响应式破版。
-- 动效、reduced motion、focus、hover、disabled 是否符合规格或有截图 / 录像证据。
-- 移动端触控目标、折叠策略、表格替代形态是否符合 screen-states 和 frontend architecture。
-
-输出：
-- Verdict: PASS / FAIL
-- 主要差异清单
-- 必须修复项
-- 可接受差异及原因
-```
-
-## 7. 对比记录
-
-| 检查项 | 参考图表现 | 实拍图表现 | 结论 | 修复任务 |
-| --- | --- | --- | --- | --- |
-| 布局结构 | | | PASS / FAIL | |
-| 字体与字号 | | | PASS / FAIL | |
-| 间距与密度 | | | PASS / FAIL | |
-| 颜色与状态色 | | | PASS / FAIL | |
-| 组件圆角 / 阴影 / 边框 | | | PASS / FAIL | |
-| 业务元素完整性 | | | PASS / FAIL | |
-| 响应式 | | | PASS / FAIL / N/A | |
-| 动效 / reduced motion | | | PASS / FAIL / N/A | |
-| 可访问性可见状态 | | | PASS / FAIL / N/A | |
-
-## 8. 失败处理
-
-如果 Verdict 为 FAIL:
-
-1. 把差异写入当前 task 的 `progress.txt` 或 worker `handoff.md`。
-2. 生成前端修复任务，明确允许修改的文件和必须重跑的截图矩阵。
-3. 修复后重新启动页面，重新截图。
-4. 用新的 `actual.png` 再次对比，直到 Verdict 为 PASS。
-5. 如果连续多轮仍无法一致，输出 `BLOCKED`，说明是设计图、规格、数据或技术约束冲突。
-
-## 9. 通过标准
-
-- [ ] 每个 required UI state 都有参考图或明确豁免。
-- [ ] 每个 required UI state 都有真实浏览器截图。
-- [ ] mobile required viewport 有真实浏览器截图或明确豁免。
-- [ ] 可访问性、focus、reduced motion 的可见状态已有截图、录像或报告证据。
-- [ ] 截图 viewport、测试数据和页面状态与参考图一致。
-- [ ] 图片对比报告存在，并给出 `Verdict: PASS`。
-- [ ] 所有 FAIL 差异都已修复并重新截图。
-- [ ] Stage 1 Review 能读取参考图路径、实拍图路径和对比报告。

package/package-source/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/templates/docs/frontend-quality-rules.md

@@ -1,138 +0,0 @@
-# Frontend Quality Rules
-
-本文件定义前端页面从“能用”到“可交付”的最低质量尺子。它服务于 `spec-to-ui-to-code-workflow.md`、`design-brief.md`、`image-to-frontend-spec.md`、`component-map.md`、`screen-states.md` 和 `visual-parity-review.md`，不替代项目自己的品牌规范或产品需求。
-
-## 1. 质量分级
-
-| 等级 | 定义 | 必备证据 | 不能声称 |
-| --- | --- | --- | --- |
-| P0 可用 | 主路径能完成，关键控件可操作 | 主路径 story 或 E2E，基本截图 | 生产级体验 |
-| P1 完整 | default / loading / empty / error / permission / long content / mobile 有规格和验证 | 状态矩阵、story 覆盖、移动端截图 | 视觉精修完成 |
-| P2 精修 | 视觉层级、响应式、动效、可访问性和文案有明确标准并通过评审 | visual parity、a11y smoke、responsive matrix | 可无限复用 |
-| P3 生产级 | 架构可维护，组件边界清晰，性能预算和回归证据完整 | frontend architecture、performance budget、regression evidence | 无需后续治理 |
-
-`feature_impl` 的前端任务如果没有写明目标等级，默认按 P1 验收；用户可见核心流程默认至少 P2。
-
-## 2. 审美反模式
-
-以下情况出现任意一项，Stage 1 或视觉评审应要求返工，除非 Design Brief 明确说明原因：
-
-- 页面只由大块卡片堆叠组成，缺少信息层级。
-- 全页面灰白无重点，主要操作、危险操作和状态反馈不可区分。
-- 使用无意义渐变、装饰图形或营销式 hero 来包装操作型后台页面。
-- 所有按钮、标签、状态、表格行的视觉权重相同。
-- 表格密度失控：行高、列宽、数字、标签和操作区没有扫描节奏。
-- 移动端只做横向滚动，没有重排、折叠或卡片化策略。
-- loading / empty / error 只是一行临时文案，没有恢复路径。
-- 图标、颜色或动画只起装饰作用，不能帮助识别状态或操作。
-
-## 3. 动效规则
-
-动效必须解释状态变化，不承担主要信息表达。
-
-| 场景 | 推荐动效 | 时长 | 约束 |
-| --- | --- | --- | --- |
-| 弹窗 / 抽屉打开 | opacity + scale 或 translate | 120-180ms | 必须有焦点管理 |
-| 筛选 chip 增删 | opacity + slight translate | 100-160ms | 不得推动整页大范围跳动 |
-| 表格刷新 | skeleton / row fade | 120-220ms | 高频刷新时禁用行级动画 |
-| 空态 / 错误态切换 | opacity | 120-180ms | 文案和恢复操作优先 |
-| 保存成功 / dirty 清除 | button state + inline status | 120-180ms | 不得只依赖 toast |
-
-硬约束：
-
-- 首选 `transform` 和 `opacity`，不得用会持续触发布局的动画属性。
-- 必须支持 `prefers-reduced-motion` 或等价 reduced motion 开关。
-- 动效不能隐藏错误、禁用、权限不足或保存失败。
-- 动效失败时页面仍必须可用。
-
-## 4. 响应式规则
-
-每个用户可见页面都必须写清楚 desktop / tablet / mobile 的布局策略。
-
-| 视口 | 必须说明 | 常见策略 |
-| --- | --- | --- |
-| Desktop >= 1200px | 主内容宽度、侧栏、表格列、操作区位置 | 横向筛选条 + 数据表 + 分页 |
-| Tablet 768-1199px | 筛选换行、列显隐、操作折叠 | 筛选条换行，次要列隐藏 |
-| Mobile < 768px | 筛选入口、表格替代形态、底部操作、触控尺寸 | 筛选抽屉，表格转卡片，分页简化 |
-
-移动端禁止只依赖横向滚动完成主要流程。若表格必须横向滚动，必须说明原因、最小宽度、冻结列或摘要卡片替代方案。
-
-## 5. 组件复用边界
-
-- `ui primitives`: 只放按钮、输入、弹窗、菜单、表格基础结构等无业务语义组件。
-- `data-table`: 只放排序、筛选、分页、列显隐、空态容器等表格通用行为。
-- `features/<domain>`: 放业务组件、业务 hooks、字段映射、权限逻辑和页面组合。
-- `api-client`: 放契约生成或手写 API 调用，不直接依赖 UI。
-- `model/schema`: 放类型、枚举、表单校验和 URL query 解析。
-
-复用准入：
-
-- 新通用组件必须至少有两个明确使用场景，或是基础 primitive。
-- 业务语义不稳定时留在 feature 内，不提前抽到 `packages/ui`。
-- 通用组件必须有 props 契约、状态矩阵、story 和可访问性说明。
-- generated types 可以作为数据输入类型，不能决定 UI primitive 的命名和职责。
-
-## 6. 交互与文案规则
-
-每个关键操作必须定义：
-
-- 触发条件、禁用条件、加载反馈、成功反馈、失败反馈。
-- inline error、toast、modal confirm 的使用边界。
-- dirty 状态如何产生、如何保存、何时清除。
-- 重试、取消、关闭、返回是否保留用户输入。
-- 空态文案、错误文案、权限文案、按钮文案和长文本截断规则。
-
-空态必须区分“系统没有数据”和“筛选后没有结果”。错误态必须包含用户可执行的恢复路径。
-
-状态不是给评审看的页面说明。`loading / empty / error / disabled / permission / mobile` 等状态必须由真实状态源驱动，例如 API 请求状态、权限结果、空数据集合、表单 dirty/valid 状态、路由或 query 参数、feature flag、响应式断点、story controls 或可控 mock。页面可以有用户可见文案，但不能出现“这里是 loading 状态”“权限态展示如下”等占位说明来冒充实现。
-
-每个 P0/P1 状态都必须能在代码和证据中追溯到：
-
-- 状态源：store、query、hook、props、fixture、mock response、viewport 或权限判断。
-- 渲染分支：组件条件分支、状态组件、disabled 属性、error boundary、empty renderer 或 responsive layout。
-- 触发路径：用户操作、API 响应、测试 seed、story control、query 参数、mock scenario 或 viewport。
-- 复验证据：story、interaction test、E2E 步骤、截图矩阵或 visual parity finding。
-
-## 7. 可访问性规则
-
-前端规格至少覆盖：
-
-- 键盘路径和焦点顺序。
-- 弹窗、抽屉、菜单的 focus trap 和关闭方式。
-- 表单错误与输入控件的关联。
-- 加载、保存成功、失败的屏幕阅读器提示。
-- 色彩不能作为唯一信息来源。
-- 移动端触控目标不小于 44x44px，除非平台规范另有说明。
-
-## 8. 性能预算
-
-前端设计阶段必须说明是否存在以下风险：
-
-- 首屏依赖过多组件、图标、图表或动画库。
-- 表格超过 100 行、复杂筛选、虚拟滚动或服务端分页需求。
-- 图片、头像、缩略图或远程媒体影响布局稳定。
-- 动效或重排可能影响滚动和输入响应。
-
-如果页面包含复杂表格、图表或列表，必须在 `frontend-architecture.md` 或 DEV-PLAN 中写明 client/server 分界和性能验证方式。
-
-## 9. 证据要求
-
-前端任务完成声明至少包含：
-
-- story / interaction / E2E 中的对应状态覆盖。
-- desktop 和 mobile 的真实浏览器截图。
-- visual parity 结论。
-- 可访问性 smoke 结论或明确豁免。
-- 性能风险检查结论；复杂页面需附性能预算验证。
-
-## 10. State Surface Gate
-
-前端任务进入实现前，必须把状态暴露方式写进 plan 或当前 task 的 `state_surface`。可接受的状态表面包括：
-
-- Storybook / story 文件：适合组件、页面片段、状态矩阵和视觉回归。
-- 真实 route + query / fixture：适合页面级状态、权限态和深链路复现。
-- Mock scenario / MSW / API fixture：适合 loading、empty、error、权限和异常返回。
-- E2E seed / test data：适合跨页面流程、保存、删除、批量操作和副作用验证。
-- Viewport matrix：适合响应式、移动端重排和触控行为。
-
-每个 P0/P1 状态至少要有一个可运行入口，并写明评审看哪里、回归跑什么、失败证据放哪里。状态只存在于设计稿、截图或聊天说明中时，Stage 1 应要求补状态表面，而不是让实现任务继续猜。

package/package-source/docs/codex-harness-engineering/templates/package-assets/docs/ecc-zh-CN/AGENTS.md

@@ -1,165 +0,0 @@
-# Everything Claude Code (ECC) — 智能体指令
-
-这是一个**生产就绪的 AI 编码插件**，提供 48 个专业代理、183 项技能、79 条命令以及自动化钩子工作流，用于软件开发。
-
-**版本:** 1.10.0
-
-## 核心原则
-
-1. **智能体优先** — 将领域任务委托给专业智能体
-2. **测试驱动** — 先写测试再实现，要求 80%+ 覆盖率
-3. **安全第一** — 绝不妥协安全；验证所有输入
-4. **不可变性** — 总是创建新对象，永不修改现有对象
-5. **先规划后执行** — 在编写代码前规划复杂功能
-
-## 可用智能体
-
-| 代理 | 用途 | 使用时机 |
-|-------|---------|-------------|
-| planner | 实现规划 | 复杂功能、重构 |
-| architect | 系统设计与可扩展性 | 架构决策 |
-| tdd-guide | 测试驱动开发 | 新功能、错误修复 |
-| code-reviewer | 代码质量与可维护性 | 编写/修改代码后 |
-| security-reviewer | 漏洞检测 | 提交前、敏感代码 |
-| build-error-resolver | 修复构建/类型错误 | 构建失败时 |
-| e2e-runner | 端到端 Playwright 测试 | 关键用户流程 |
-| refactor-cleaner | 死代码清理 | 代码维护 |
-| doc-updater | 文档和代码地图更新 | 更新文档时 |
-| docs-lookup | 文档和 API 参考研究 | 库/API 文档问题 |
-| cpp-reviewer | C++ 代码审查 | C++ 项目 |
-| cpp-build-resolver | C++ 构建错误 | C++ 构建失败 |
-| go-reviewer | Go 代码审查 | Go 项目 |
-| go-build-resolver | Go 构建错误 | Go 构建失败 |
-| kotlin-reviewer | Kotlin 代码审查 | Kotlin/Android/KMP 项目 |
-| kotlin-build-resolver | Kotlin/Gradle 构建错误 | Kotlin 构建失败 |
-| database-reviewer | PostgreSQL/Supabase 专家 | 模式设计、查询优化 |
-| python-reviewer | Python 代码审查 | Python 项目 |
-| java-reviewer | Java 和 Spring Boot 代码审查 | Java/Spring Boot 项目 |
-| java-build-resolver | Java/Maven/Gradle 构建错误 | Java 构建失败 |
-| chief-of-staff | 沟通分类与草拟 | 多渠道邮件、Slack、LINE、Messenger |
-| loop-operator | 自主循环执行 | 安全运行循环、监控停滞、干预 |
-| harness-optimizer | Harness 配置调优 | 可靠性、成本、吞吐量 |
-| rust-reviewer | Rust 代码审查 | Rust 项目 |
-| rust-build-resolver | Rust 构建错误 | Rust 构建失败 |
-| pytorch-build-resolver | PyTorch 运行时/CUDA/训练错误 | PyTorch 构建/训练失败 |
-| typescript-reviewer | TypeScript/JavaScript 代码审查 | TypeScript/JavaScript 项目 |
-
-## 智能体编排
-
-主动使用智能体，无需用户提示：
-
-* 复杂功能请求 → **planner**
-* 刚编写/修改的代码 → **code-reviewer**
-* 错误修复或新功能 → **tdd-guide**
-* 架构决策 → **architect**
-* 安全敏感代码 → **security-reviewer**
-* 多渠道沟通分流 → **chief-of-staff**
-* 自主循环 / 循环监控 → **loop-operator**
-* 线束配置可靠性及成本 → **harness-optimizer**
-
-对于独立操作使用并行执行 — 同时启动多个智能体。
-
-## 安全指南
-
-**在任何提交之前：**
-
-* 没有硬编码的密钥（API 密钥、密码、令牌）
-* 所有用户输入都经过验证
-* 防止 SQL 注入（参数化查询）
-* 防止 XSS（已清理的 HTML）
-* 启用 CSRF 保护
-* 已验证身份验证/授权
-* 所有端点都有限速
-* 错误消息不泄露敏感数据
-
-**密钥管理：** 绝不硬编码密钥。使用环境变量或密钥管理器。在启动时验证所需的密钥。立即轮换任何暴露的密钥。
-
-**如果发现安全问题：** 停止 → 使用 security-reviewer 智能体 → 修复 CRITICAL 问题 → 轮换暴露的密钥 → 审查代码库中的类似问题。
-
-## 编码风格
-
-**不可变性（关键）：** 总是创建新对象，永不修改。返回带有更改的新副本。
-
-**文件组织：** 许多小文件优于少数大文件。通常 200-400 行，最多 800 行。按功能/领域组织，而不是按类型组织。高内聚，低耦合。
-
-**错误处理：** 在每个层级处理错误。在 UI 代码中提供用户友好的消息。在服务器端记录详细的上下文。绝不静默地忽略错误。
-
-**输入验证：** 在系统边界验证所有用户输入。使用基于模式的验证。快速失败并给出清晰的消息。绝不信任外部数据。
-
-**代码质量检查清单：**
-
-* 函数小巧（<50 行），文件专注（<800 行）
-* 没有深层嵌套（>4 层）
-* 适当的错误处理，没有硬编码的值
-* 可读性强、命名良好的标识符
-
-## 测试要求
-
-**最低覆盖率：80%**
-
-测试类型（全部必需）：
-
-1. **单元测试** — 单个函数、工具、组件
-2. **集成测试** — API 端点、数据库操作
-3. **端到端测试** — 关键用户流程
-
-**TDD 工作流（强制）：**
-
-1. 先写测试（RED） — 测试应该失败
-2. 编写最小实现（GREEN） — 测试应该通过
-3. 重构（IMPROVE） — 验证覆盖率 80%+
-
-故障排除：检查测试隔离 → 验证模拟 → 修复实现（而不是测试，除非测试是错误的）。
-
-## 开发工作流
-
-1. **规划** — 使用规划代理，识别依赖关系和风险，分阶段推进
-2. **测试驱动开发** — 使用 tdd-guide 代理，先写测试，再实现和重构
-3. **评审** — 立即使用代码评审代理，解决 CRITICAL/HIGH 级别的问题
-4. **在适当位置记录知识**
-   * 个人调试笔记、偏好和临时上下文 → 自动记忆
-   * 团队/项目知识（架构决策、API 变更、操作手册）→ 项目现有文档结构
-   * 如果当前任务已生成相关文档或代码注释，请勿在其他地方重复相同信息
-   * 如果没有明显的项目文档位置，在创建新的顶层文件前先询问
-5. **提交** — 采用约定式提交格式，提供全面的 PR 摘要
-
-## Git 工作流
-
-**提交格式：** `<type>: <description>` — 类型：feat, fix, refactor, docs, test, chore, perf, ci
-
-**PR 工作流：** 分析完整的提交历史 → 起草全面的摘要 → 包含测试计划 → 使用 `-u` 标志推送。
-
-## 架构模式
-
-**API 响应格式：** 具有成功指示器、数据负载、错误消息和分页元数据的一致信封。
-
-**仓储模式：** 将数据访问封装在标准接口（findAll, findById, create, update, delete）后面。业务逻辑依赖于抽象接口，而不是存储机制。
-
-**骨架项目：** 搜索经过实战检验的模板，使用并行智能体（安全性、可扩展性、相关性）进行评估，克隆最佳匹配，在已验证的结构内迭代。
-
-## 性能
-
-**上下文管理：** 对于大型重构和多文件功能，避免使用上下文窗口的最后 20%。敏感性较低的任务（单次编辑、文档、简单修复）可以容忍较高的利用率。
-
-**构建故障排除：** 使用 build-error-resolver 智能体 → 分析错误 → 增量修复 → 每次修复后验证。
-
-## 项目结构
-
-```
-agents/          — 48 个专业子代理
-skills/          — 183 个工作流技能和领域知识
-commands/        — 79 个斜杠命令
-hooks/           — 基于触发的自动化
-rules/           — 始终遵循的指导方针（通用 + 每种语言）
-scripts/         — 跨平台 Node.js 实用工具
-mcp-configs/     — 14 个 MCP 服务器配置
-tests/           — 测试套件
-```
-
-## 成功指标
-
-* 所有测试通过且覆盖率 80%+
-* 没有安全漏洞
-* 代码可读且可维护
-* 性能可接受
-* 满足用户需求

package/package-source/docs/codex-harness-engineering/templates/package-assets/docs/ecc-zh-CN/CHANGELOG.md

@@ -1,149 +0,0 @@
-# 更新日志
-
-## 1.9.0 - 2026-03-20
-
-### 亮点
-
-* 选择性安装架构，采用清单驱动流水线和 SQLite 状态存储。
-* 语言覆盖范围扩展至 10 多个生态，新增 6 个代理和语言特定规则。
-* 观察器可靠性增强，包括内存限制、沙箱修复和 5 层循环防护。
-* 自我改进的技能基础，支持技能演进和会话适配器。
-
-### 新代理
-
-* `typescript-reviewer` — TypeScript/JavaScript 代码审查专家 (#647)
-* `pytorch-build-resolver` — PyTorch 运行时、CUDA 及训练错误解决 (#549)
-* `java-build-resolver` — Maven/Gradle 构建错误解决 (#538)
-* `java-reviewer` — Java 和 Spring Boot 代码审查 (#528)
-* `kotlin-reviewer` — Kotlin/Android/KMP 代码审查 (#309)
-* `kotlin-build-resolver` — Kotlin/Gradle 构建错误 (#309)
-* `rust-reviewer` — Rust 代码审查 (#523)
-* `rust-build-resolver` — Rust 构建错误解决 (#523)
-* `docs-lookup` — 文档和 API 参考研究 (#529)
-
-### 新技能
-
-* `pytorch-patterns` — PyTorch 深度学习工作流 (#550)
-* `documentation-lookup` — API 参考和库文档研究 (#529)
-* `bun-runtime` — Bun 运行时模式 (#529)
-* `nextjs-turbopack` — Next.js Turbopack 工作流 (#529)
-* `mcp-server-patterns` — MCP 服务器设计模式 (#531)
-* `data-scraper-agent` — AI 驱动的公共数据收集 (#503)
-* `team-builder` — 团队构成技能 (#501)
-* `ai-regression-testing` — AI 回归测试工作流 (#433)
-* `claude-devfleet` — 多代理编排 (#505)
-* `blueprint` — 多会话构建规划
-* `everything-claude-code` — 自引用 ECC 技能 (#335)
-* `prompt-optimizer` — 提示优化技能 (#418)
-* 8 个 Evos 操作领域技能 (#290)
-* 3 个 Laravel 技能 (#420)
-* VideoDB 技能 (#301)
-
-### 新命令
-
-* `/docs` — 文档查找 (#530)
-* `/aside` — 侧边对话 (#407)
-* `/prompt-optimize` — 提示优化 (#418)
-* `/resume-session`, `/save-session` — 会话管理
-* `learn-eval` 改进，支持基于清单的整体裁决
-
-### 新规则
-
-* Java 语言规则 (#645)
-* PHP 规则包 (#389)
-* Perl 语言规则和技能（模式、安全、测试）
-* Kotlin/Android/KMP 规则 (#309)
-* C++ 语言支持 (#539)
-* Rust 语言支持 (#523)
-
-### 基础设施
-
-* 选择性安装架构，支持清单解析 (`install-plan.js`, `install-apply.js`) (#509, #512)
-* SQLite 状态存储，提供查询 CLI 以跟踪已安装组件 (#510)
-* 会话适配器，用于结构化会话记录 (#511)
-* 技能演进基础，支持自我改进的技能 (#514)
-* 编排框架，支持确定性评分 (#524)
-* CI 中的目录计数强制执行 (#525)
-* 对所有 109 项技能的安装清单验证 (#537)
-* PowerShell 安装器包装器 (#532)
-* 通过 `--target antigravity` 标志支持 Antigravity IDE (#332)
-* Codex CLI 自定义脚本 (#336)
-
-### 错误修复
-
-* 解决了 6 个文件中的 19 个 CI 测试失败 (#519)
-* 修复了安装流水线、编排器和修复工具中的 8 个测试失败 (#564)
-* 观察器内存爆炸问题，通过限制、重入防护和尾部采样解决 (#536)
-* 观察器沙箱访问修复，用于 Haiku 调用 (#661)
-* 工作树项目 ID 不匹配修复 (#665)
-* 观察器延迟启动逻辑 (#508)
-* 观察器 5 层循环预防防护 (#399)
-* 钩子可移植性和 Windows .cmd 支持
-* Biome 钩子优化 — 消除了 npx 开销 (#359)
-* InsAIts 安全钩子改为可选启用 (#370)
-* Windows spawnSync 导出修复 (#431)
-* instinct CLI 的 UTF-8 编码修复 (#353)
-* 钩子中的密钥擦除 (#348)
-
-### 翻译
-
-* 韩语 (ko-KR) 翻译 — README、代理、命令、技能、规则 (#392)
-* 中文 (zh-CN) 文档同步 (#428)
-
-### 鸣谢
-
-* @ymdvsymd — 观察器沙箱和工作树修复
-* @pythonstrup — biome 钩子优化
-* @Nomadu27 — InsAIts 安全钩子
-* @hahmee — 韩语翻译
-* @zdocapp — 中文翻译同步
-* @cookiee339 — Kotlin 生态
-* @pangerlkr — CI 工作流修复
-* @0xrohitgarg — VideoDB 技能
-* @nocodemf — Evos 操作技能
-* @swarnika-cmd — 社区贡献
-
-## 1.8.0 - 2026-03-04
-
-### 亮点
-
-* 首次发布以可靠性、评估规程和自主循环操作为核心的版本。
-* Hook 运行时现在支持基于配置文件的控制和针对性的 Hook 禁用。
-* NanoClaw v2 增加了模型路由、技能热加载、分支、搜索、压缩、导出和指标功能。
-
-### 核心
-
-* 新增命令：`/harness-audit`, `/loop-start`, `/loop-status`, `/quality-gate`, `/model-route`。
-* 新增技能：
-  * `agent-harness-construction`
-  * `agentic-engineering`
-  * `ralphinho-rfc-pipeline`
-  * `ai-first-engineering`
-  * `enterprise-agent-ops`
-  * `nanoclaw-repl`
-  * `continuous-agent-loop`
-* 新增代理：
-  * `harness-optimizer`
-  * `loop-operator`
-
-### Hook 可靠性
-
-* 修复了 SessionStart 的根路径解析，增加了健壮的回退搜索。
-* 将会话摘要持久化移至 `Stop`，此处可获得转录负载。
-* 增加了质量门和成本追踪钩子。
-* 用专门的脚本文件替换了脆弱的单行内联钩子。
-* 增加了 `ECC_HOOK_PROFILE` 和 `ECC_DISABLED_HOOKS` 控制。
-
-### 跨平台
-
-* 改进了文档警告逻辑中 Windows 安全路径的处理。
-* 强化了观察者循环行为，以避免非交互式挂起。
-
-### 备注
-
-* `autonomous-loops` 作为一个兼容性别名保留一个版本；`continuous-agent-loop` 是规范名称。
-
-### 鸣谢
-
-* 灵感来自 [zarazhangrui](https://github.com/zarazhangrui)
-* homunculus 灵感来自 [humanplane](https://github.com/humanplane)

package/package-source/docs/codex-harness-engineering/templates/package-assets/docs/ecc-zh-CN/CLAUDE.md

@@ -1,61 +0,0 @@
-# CLAUDE.md
-
-本文件为 Claude Code (claude.ai/code) 处理此仓库代码时提供指导。
-
-## 项目概述
-
-这是一个 **Claude Code 插件** - 一个包含生产就绪的代理、技能、钩子、命令、规则和 MCP 配置的集合。该项目提供了使用 Claude Code 进行软件开发的经验证的工作流。
-
-## 运行测试
-
-```bash
-# Run all tests
-node tests/run-all.js
-
-# Run individual test files
-node tests/lib/utils.test.js
-node tests/lib/package-manager.test.js
-node tests/hooks/hooks.test.js
-```
-
-## 架构
-
-项目组织为以下几个核心组件：
-
-* **agents/** - 用于委派的专业化子代理（规划器、代码审查员、TDD 指南等）
-* **skills/** - 工作流定义和领域知识（编码标准、模式、测试）
-* **commands/** - 由用户调用的斜杠命令（/tdd, /plan, /e2e 等）
-* **hooks/** - 基于触发的自动化（会话持久化、工具前后钩子）
-* **rules/** - 始终遵循的指南（安全、编码风格、测试要求）
-* **mcp-configs/** - 用于外部集成的 MCP 服务器配置
-* **scripts/** - 用于钩子和设置的跨平台 Node.js 工具
-* **tests/** - 脚本和工具的测试套件
-
-## 关键命令
-
-* `/tdd` - 测试驱动开发工作流
-* `/plan` - 实施规划
-* `/e2e` - 生成并运行端到端测试
-* `/code-review` - 质量审查
-* `/build-fix` - 修复构建错误
-* `/learn` - 从会话中提取模式
-* `/skill-create` - 从 git 历史记录生成技能
-
-## 开发说明
-
-* 包管理器检测：npm、pnpm、yarn、bun（可通过 `CLAUDE_PACKAGE_MANAGER` 环境变量或项目配置设置）
-* 跨平台：通过 Node.js 脚本支持 Windows、macOS、Linux
-* 代理格式：带有 YAML 前言的 Markdown（名称、描述、工具、模型）
-* 技能格式：带有清晰章节的 Markdown（何时使用、如何工作、示例）
-* 钩子格式：带有匹配器条件和命令/通知钩子的 JSON
-
-## 贡献
-
-遵循 CONTRIBUTING.md 中的格式：
-
-* 代理：带有前言的 Markdown（名称、描述、工具、模型）
-* 技能：清晰的章节（何时使用、如何工作、示例）
-* 命令：带有描述前言的 Markdown
-* 钩子：带有匹配器和钩子数组的 JSON
-
-文件命名：小写字母并用连字符连接（例如 `python-reviewer.md`, `tdd-workflow.md`）