@pzy560117/codex-harness 0.1.0 → 0.1.1

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

@@ -0,0 +1,124 @@
+# 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

@@ -0,0 +1,138 @@
+# 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

@@ -0,0 +1,165 @@
+# 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

@@ -0,0 +1,149 @@
+# 更新日志
+
+## 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

@@ -0,0 +1,61 @@
+# 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`）