docs: refresh rc1 release readiness evidence

Add the May 13 rc.1 publication evidence refresh and update the release-readiness/GA roadmap gates after #1846.

- record current queue, security-gate, harness audit, adapter, observability, Node, markdownlint, release-surface, npm publish-surface, and ecc2 Rust evidence
- update the publication-readiness checklist with the May 13 evidence artifact
- normalize zh-CN CLAUDE list markers so markdownlint passes

Validation:
- node tests/docs/ecc2-release-surface.test.js
- node tests/docs/harness-adapter-compliance.test.js
- node tests/docs/stale-pr-salvage-ledger.test.js
- npx markdownlint-cli '**/*.md' --ignore node_modules
- git diff --check
- node tests/run-all.js (2376 passed, 0 failed)
- npm run harness:audit -- --format json (70/70)
- npm run harness:adapters -- --check
- npm run observability:ready -- --format json (16/16)
- node tests/scripts/npm-publish-surface.test.js
- cd ecc2 && cargo test (462 passed, 0 failed)

No release, tag, npm publish, plugin tag, marketplace submission, or announcement was performed.
This commit is contained in:
Affaan Mustafa
2026-05-13 00:05:51 -04:00
committed by GitHub
parent 797f283036
commit da04a6e344
5 changed files with 138 additions and 69 deletions

View File

@@ -31,40 +31,40 @@ node tests/hooks/hooks.test.js
项目组织为以下几个核心组件:
* **agents/** - 用于委派的专业化子代理规划器、代码审查员、TDD 指南等)
* **skills/** - 工作流定义和领域知识(编码标准、模式、测试)
* **commands/** - 由用户调用的斜杠命令(/tdd, /plan, /e2e 等)
* **hooks/** - 基于触发的自动化(会话持久化、工具前后钩子)
* **rules/** - 始终遵循的指南(安全、编码风格、测试要求)
* **mcp-configs/** - 用于外部集成的 MCP 服务器配置
* **scripts/** - 用于钩子和设置的跨平台 Node.js 工具
* **tests/** - 脚本和工具的测试套件
- **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 历史记录生成技能
- `/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
- 包管理器检测npm、pnpm、yarn、bun可通过 `CLAUDE_PACKAGE_MANAGER` 环境变量或项目配置设置)
- 跨平台:通过 Node.js 脚本支持 Windows、macOS、Linux
- 代理格式:带有 YAML 前言的 Markdown名称、描述、工具、模型
- 技能格式:带有清晰章节的 Markdown何时使用、如何工作、示例
- 钩子格式:带有匹配器条件和命令/通知钩子的 JSON
## 贡献
遵循 CONTRIBUTING.md 中的格式:
* 代理:带有前言的 Markdown名称、描述、工具、模型
* 技能:清晰的章节(何时使用、如何工作、示例)
* 命令:带有描述前言的 Markdown
* 钩子:带有匹配器和钩子数组的 JSON
- 代理:带有前言的 Markdown名称、描述、工具、模型
- 技能:清晰的章节(何时使用、如何工作、示例)
- 命令:带有描述前言的 Markdown
- 钩子:带有匹配器和钩子数组的 JSON
文件命名:小写字母并用连字符连接(例如 `python-reviewer.md`, `tdd-workflow.md`

View File

@@ -19,34 +19,34 @@
### 1. 代码组织
* 多个小文件优于少量大文件
* 高内聚,低耦合
* 每个文件典型 200-400 行,最多 800 行
* 按功能/领域组织,而非按类型
- 多个小文件优于少量大文件
- 高内聚,低耦合
- 每个文件典型 200-400 行,最多 800 行
- 按功能/领域组织,而非按类型
### 2. 代码风格
* 代码、注释或文档中不使用表情符号
* 始终使用不可变性 - 永不改变对象或数组
* 生产代码中不使用 console.log
* 使用 try/catch 进行适当的错误处理
* 使用 Zod 或类似工具进行输入验证
- 代码、注释或文档中不使用表情符号
- 始终使用不可变性 - 永不改变对象或数组
- 生产代码中不使用 console.log
- 使用 try/catch 进行适当的错误处理
- 使用 Zod 或类似工具进行输入验证
### 3. 测试
* TDD先写测试
* 最低 80% 覆盖率
* 工具函数进行单元测试
* API 进行集成测试
* 关键流程进行端到端测试
- TDD先写测试
- 最低 80% 覆盖率
- 工具函数进行单元测试
- API 进行集成测试
- 关键流程进行端到端测试
### 4. 安全
* 不硬编码密钥
* 敏感数据使用环境变量
* 验证所有用户输入
* 仅使用参数化查询
* 启用 CSRF 保护
- 不硬编码密钥
- 敏感数据使用环境变量
- 验证所有用户输入
- 仅使用参数化查询
- 启用 CSRF 保护
## 文件结构
@@ -96,14 +96,14 @@ DEBUG=false
## 可用命令
* `/tdd` - 测试驱动开发工作流
* `/plan` - 创建实现计划
* `/code-review` - 审查代码质量
* `/build-fix` - 修复构建错误
- `/tdd` - 测试驱动开发工作流
- `/plan` - 创建实现计划
- `/code-review` - 审查代码质量
- `/build-fix` - 修复构建错误
## Git 工作流
* 约定式提交:`feat:`, `fix:`, `refactor:`, `docs:`, `test:`
* 切勿直接提交到主分支
* 合并请求需要审核
* 合并前所有测试必须通过
- 约定式提交:`feat:`, `fix:`, `refactor:`, `docs:`, `test:`
- 切勿直接提交到主分支
- 合并请求需要审核
- 合并前所有测试必须通过