electrobun-milady

Electrobun × Milady 集成

本技能介绍 electrobun-dev 插件和 SDLC 流水线如何与 milady-ai/milady 项目的 Agent 审查系统、信任评分和 CI/CD 工作流集成。

milady 项目背景

milady-ai/milady 是一款基于 elizaOS、使用 Electrobun 构建的 AI 助手桌面应用。它采用仅限 Agent 的贡献模式：

• 所有代码 PR 均由 AI Agent 提交
• 人类担任 QA 测试人员（提交 Bug 报告，不提交代码）
• 自动化 Claude Code 审查器是唯一的代码审查者
• 审查结果由机器解析，并触发自动合并或关闭

当我们的 electrobun-dev SDLC 流水线向 milady-ai/milady 提交 PR（Electrobun 桌面应用代码、插件文件或技能）时，这些 PR 会经过该系统。

---

Agent 审查系统

流水线

PR opened/updated
    ↓
classify job — categorizes PR as: bugfix/feature/aesthetic/docs/chore/test
    ↓
review-pr job:
  1. Load contributor trust context (score + tier)
  2. Claude Code Action reviews the PR (with trust tier in context)
  3. Codex fallback if Claude unavailable
  4. Extract verdict: APPROVE / REQUEST CHANGES / CLOSE
    ↓
review-postprocess job:
  - Create check run (success/failure/action_required)
  - Apply trust:{tier} label and category:{type} label
    ↓
auto-merge (if APPROVE + checks pass + not targeting main)
create-followup-issues (if APPROVE + review has follow-up section)
close-pr (if CLOSE)

审查协议 — 审查者检查内容

1. 范围检查

类别	处理方式
Bug 修复、安全、性能、测试覆盖率	属于范围内 — 欢迎提交
新功能、新插件、架构变更	需要深入审查
外观/UI 重新设计、主题变更	超出范围 — 关闭
可测试代码的变更未附带测试	超出范围

插件贡献和 Electrobun 相关变更属于“需要深入审查”。审查者会验证它们是否符合项目使命。

2. 代码质量要求

• 符合 TypeScript 严格模式
• 除非绝对必要，否则不得使用 any 类型（必须在代码注释中说明原因）
• 符合 Biome lint/格式规范（milady 使用 Biome，而非 ESLint）
• 文件约 500 LOC 以下 — 更大的文件会被标记
• 变量名有意义；对不明显的逻辑添加简短注释
• 不得提交密钥、真实凭证或有效配置值
• 依赖项：仅在 src/ 代码直接导入时才添加

3. 安全审查

审查者会特别检查：

• 提示词注入向量
• 凭证泄露
• 供应链风险（新依赖、postinstall 脚本）
• 数据外泄模式
• 身份验证、权限或密钥处理相关变更

4. 测试要求

变更类型	测试要求
Bug 修复	必须包含回归测试
新功能	必须包含单元测试
行/函数/语句覆盖率	≥25% 阈值（由 vitest.config.ts 强制执行）
分支覆盖率	≥15% 阈值
DB 路由/适配器/查询变更	必须通过 bun run db:check

5. 黑暗森林意识

审查者会假定提交者怀有对抗意图，直到证明并非如此：

• Agent 为什么要提交此变更？
• 它会破坏哪些不明显的内容？
• 它是否引入了微妙的行为变化？
• 看似无害的变更中是否存在隐藏的副作用？

对我们代码的影响： 每个 PR 都必须显而易见地正确。对于不寻常的模式，必须添加行内注释说明原因。

---

信任评分系统

评分范围和初始状态

• 范围： 0–100
• 初始分数： 35（信任靠赢得，而非给予）
• 存储： .github/contributor-trust.json（由 trust-dashboard cron 每 6h 更新 — 在 CI 中只读）

等级系统

分数	等级	审查方式
90–100	传奇	标准审查，已证明实力出众
75–89	可信	加急审查，检查安全性
60–74	稳定	正常审查深度
45–59	有贡献	标准审查
30–44	观察期	谨慎审查，核实声明，检查边界情况
15–29	未验证	深入审查，逐行检查，加强安全审查
0–14	受限	最严格审查，假定存在对抗意图

新 Agent 从 35 分开始，处于观察期等级。 在建立信任之前，来自我们 SDLC 流水线的每个 PR 都会接受“谨慎审查，核实声明，检查边界情况”的审查。

---

PR 格式要求

Agent 审查系统会通过机器解析审查结果。因此，我们提交的 PR 本身必须结构清晰，以便 Claude 审查后，其回复能够被解析。

判定格式（Claude 的评审输出必须包含的内容）

6. **Decision:** APPROVE

或

6. **Decision:** REQUEST CHANGES

或

6. **Decision:** CLOSE

评审者输出的确切格式（这是 Claude 的输出格式，不是我们的 PR 正文格式）：

1. 分类： 错误修复 / 功能 / 美化 / 安全 / 其他
2. 范围判定： 属于范围 / 需要深入评审 / 超出范围
3. 代码质量： 通过 / 发现问题
4. 安全： 无问题 / 存在隐患
5. 测试： 充分 / 缺失
6. 决定： 批准 / 要求修改 / 关闭

后续事项格式

如果我们的 PR 描述包含带项目符号的“Follow-up”或“Next Steps”部分，milady 会在合并后自动根据这些要点创建 GitHub issue。请有意使用此功能：

## Follow-up

- Add integration test for X edge case
- Benchmark the new rendering path under load
- Document the RPC schema in Mintlify

最多可自动转换 12 项为 issue。除非确实需要，否则不要添加后续事项。

milady 的 PR 正文结构

## Summary

One clear sentence of what this does and why.

- Bullet 1: specific change
- Bullet 2: specific change

## Motivation

Why this change is needed. Reference the issue/bug if applicable.

## Changes

- `src/file.ts`: what changed
- `src/other.ts`: what changed

## Tests

What tests were added/updated and what they verify.

## Follow-up

- Any recommended next steps (become GitHub issues automatically)

---

milady 发布工作流（release-electrobun.yml）

milady 项目有自己的 Electrobun 发布工作流，其使用的密钥名称与标准 Electrobun 构建文档中描述的不同。在处理 milady 的 Electrobun 应用代码时，请使用以下名称：

密钥（milady 专用名称）

milady 密钥名称	用途	标准 Electrobun 名称
CSC_LINK	Base64 编码的 .p12 证书	MACOS_CERTIFICATE
CSC_KEY_PASSWORD	证书密码	MACOS_CERTIFICATE_PWD
APPLE_ID	Apple ID 邮箱	ELECTROBUN_APPLEID
APPLE_APP_SPECIFIC_PASSWORD	App 专用密码	ELECTROBUN_APPLEIDPASS
APPLE_TEAM_ID	Team ID	ELECTROBUN_TEAMID
RELEASE_UPLOAD_KEY	用于 [email protected] 的 SSH 密钥	（milady 专用）
RELEASE_HOST_FINGERPRINT	milady.ai 的 SSH 主机指纹	（milady 专用）

milady 工作流会导入证书并自动提取 Developer ID 身份字符串，然后将其作为 ELECTROBUN_DEVELOPER_ID 传入。你无需单独将 ELECTROBUN_DEVELOPER_ID 设置为密钥。

版本／渠道判定

Tag contains alpha/beta/rc/nightly → BUILD_ENV=canary
All other version tags             → BUILD_ENV=stable

示例：v2.0.0-alpha.3 → canary，v2.0.0 → stable

Bun 版本

milady 在其发布工作流中将 Bun 固定为 1.3.9。这可能不同于最新的 Bun 版本。在本地构建 milady 时，请使用相同版本，以避免行为差异。

---

SDLC 流水线与 milady 的对齐

为 milady-ai/milady 开发功能并运行 /electrobun-sdlc 时，每个阶段都必须考虑 milady 的要求：

研究员（阶段 1）

• 检查该功能是否涉及 milady 的 elizaOS 插件系统（与 Electrobun API 不同）
• 检查是否存在 Biome 配置（.biome.json 或 biome.json）——记录当前启用的规则
• 检查测试覆盖率基线：vitest.config.ts 中的覆盖率阈值

架构师（阶段 2）

• 新文件不得超过 500 行代码
• 为每个新模块规划测试文件
• 记录哪些变更需要运行 bun run db:check

规划员（阶段 3）

• 错误修复的每项任务都必须包含回归测试任务
• 新功能的每项任务都必须包含单元测试任务
• 覆盖率目标：行／函数 25%，分支 15%

开发小组（阶段 4）

• 不得使用 any 类型——如确实无法避免，请使用显式类型断言并添加注释
• 提交前使用 Biome 格式化：bunx biome check --write .
• 文件不得超过约 500 行——接近上限时应拆分

QA 工程师（阶段 5）

添加以下 milady 专用检查：

[ ] Biome compliance: run bunx biome check --diagnostic-level=error
[ ] TypeScript strict: no implicit any, no unchecked types
[ ] File LOC: all files ≤ ~500 lines
[ ] Test coverage: bug fixes have regression test, features have unit tests
[ ] No any types (flag all occurrences for justification)
[ ] No committed secrets or live config values
[ ] Dependencies: only added if src/ imports them
[ ] DB changes: bun run db:check noted if applicable

测试编写者（阶段 6）

• 编写 vitest 测试（milady 使用 vitest，而非 Kitchen Sink defineTest）
• 以 vitest.config.ts 中的覆盖率阈值为目标
• 每项错误修复都必须编写回归测试

对齐 Agent（阶段 7）

• 将 bunx biome check --write . 纳入清理流程
• 强制执行 500 行代码限制——拆分超出限制的文件

文档 Agent（阶段 8）

• PR 正文必须遵循上文的 milady PR 格式
• 仅在“Follow-up”部分中包含确实需要的后续事项
• Mintlify 文档应放在 milady 的 docs/ 目录中（检查现有结构）

---

常见错误

错误	milady 审查响应
未作说明的 any 类型	要求修改 — TypeScript 质量
修复 Bug 时未编写测试	要求修改 — 测试要求
文件超过 500 行	要求修改 — 代码质量
美观性／UI 更改	关闭 — 超出范围
新依赖未导入	要求修改 — 依赖管理规范
违反 Biome 格式规范	要求修改 — 代码质量
PR 未提供范围背景	按需深度审查处理
每周 PR 超过 10 个	已施加信任度速率惩罚
在 CI 配置中使用错误的密钥名称	构建失败