修改与评审
- 检查 Git 状态。
- 找到相关代码和用户路径。
- 定义可检查的验收条件。
- 多步骤或跨会话工作应创建或更新 JSON 计划。
- 实施前，把计划状态设为
in_progress。
计划示例是 .agents/schemas/examples/proposed.json。
计划契约见 .agents/plans/README.md。
使用稳定的计划和任务 ID。
backlog 条目变为计划后，从 backlog 移除。
每个模块只负责一项职责。
非测试代码接近 800 行时，应拆分模块。
单元测试放在相邻的 tests.rs 或 tests/ 模块。
公开 API 留在模块边界。
启动器文案写入语言目录。
同时补全中文和英文条目。
消息 ID 和参数遵循 lumilio-i18n skill。
每条已实现的用户路径都需要 ia 注释。
// ia[page]: 操作 | 层 / 组件 | 结果与反馈 [| 备注]修改注释后，运行 just ia。
不要手改 docs/ia/paths/。
不要把计划中的功能声明为已实现路径。
UI 修改前，阅读 GPUI skills 和 docs/design-language.md。
检查亮色、暗色和减少动效状态。
只记录实际检查过的状态。
- 实施过程中，运行最窄的适用检查。
- 交接前，修复每项失败。
- 运行开发环境列出的交接检查。
- 完成必要的手动检查。
在正确边界测试行为。 领域测试不依赖 GPUI。 回归测试需暂时重新引入缺陷。 确认测试因该缺陷失败。 然后移除缺陷。 再次运行测试。
不要修改检查来隐藏失败。 不要声称未来 CI 会修复本地失败。
保持计划准确
Section titled “保持计划准确”- 记录验证结果。
- 记录决策、理由和后果。
- 记录失败教训及防止再次发生的 guard。
- 验收完成后，记录 outcome。
- 把任务和计划标为 completed。
- 运行
just plans。 - 运行
just plans-check。
完成或取消后，保留 JSON 文件。
实际条件阻止进展时，使用 blocked。
记录阻塞条件和剩余任务。
完成不等于发布。
说明问题和最终行为。 有助于评审时，提供修改前后的具体例子。 列出已通过的检查。 说明剩余手动检查或已知限制。 复杂修改提供更多细节。
Pull request 应说明最终实现。 不要要求评审者重建对话过程。
链接到 issue 的 pull request，描述要简短、易懂：
在开头链接 issue（例如 Closes #55），
用几句话说明用户能看到的变化和改动方式，
细节留给计划和代码。
任务授权提交时：
- 把已验证的修改提交到工作分支。
- 推送到 fork 或已授权的仓库。
- 向
main创建 pull request。 - 在描述中加入交接报告。
- 合并前，解决检查失败。
main 是唯一的长期分支，并且始终可发布。
所有修改都通过 pull request 进入 main，维护者的修改也一样。
main 不接受直接推送和强制推送。
工作分支名使用与提交相同的类型前缀：
| 前缀 | 用途 |
|---|---|
feat/ |
新功能 |
fix/ |
缺陷修复 |
docs/ |
文档、计划或 harness |
build/ |
构建、检查或 CI |
web/ |
网站 |
合并前，rust、plans 和 web 三项检查必须通过。
每个 pull request 都会启动三项检查。
修改不涉及某项检查的路径时，该检查跳过并视为通过。
例如，只修改文档的 pull request 不运行 Rust 构建。
默认使用 squash 合并。
合并后，GitHub 删除工作分支。
生成文件发生冲突时，不要手动合并：
- 先解决源文件的冲突。
- 生成文件接受任意一侧。
- 计划输出运行
just plans，用户路径运行just ia。 - 提交重新生成的文件。
生成文件包括 docs/plans/、web/src/data/roadmap.generated.json 和 docs/ia/paths/。
版本发布在 main 上创建 v* 标签。
只有维护者可以创建发布标签。
仅当旧版本需要补丁、而 main 已包含下一版本的修改时，才从该版本标签创建 release/<主版本.次版本> 分支。
改编代码应保留来源归属。
项目许可证是 AGPL-3.0-only。
分发修改后的应用前，阅读许可证。