拉取请求必须经过至少一位项目维护者的审查和批准才能合并。
本项目不反对 AI 辅助开发，但反对作者本人没有充分检查、没有真正理解、也没有能力在出现问题后独立修复，却仅因为“代码看起来能跑”就提交的改动。
对于非微小改动，建议在 PR 中按模板说明以下内容：
- 这次改动要解决什么问题。
- 关键行为发生了什么变化。
- 自己亲自检查了哪些文件、路径或风险点。
- 最可能出错的边界条件是什么。
- 测试覆盖了什么，尚未覆盖什么。
- 哪些部分使用了 AI，以及自己做了哪些核对与修正。
对于涉及 asco/core，或影响调度、取消、生命周期、并发语义、资源释放路径等基础行为的核心改动，建议先使用 issue 模板说明改动目标、语义约束、主要风险与验证方式，再提交 PR。
维护者可以要求提交者解释关键路径、边界条件、失败路径或资源释放顺序，也可以要求提交者补测试、修正边界条件或调整关键逻辑。如果提交者无法独立完成这些工作，该改动可能不会被接受。
更完整的说明见：反对纯 Vibe Coding。
- 如果你有想要贡献的新特性，可以先发 issue 讨论，并可以申请加入这个仓库成为协作者。
- (Optional) 如果不想直接在本仓库参与开发，可以先 fork 这个仓库到你的个人账户。
- 从最新的
main分支创建一个新分支。新分支的命名格式为：feature/<feature-name>。 - 在新分支上开发你的新特性。
- 提交你的更改并推送到新分支。
- 创建一个拉取请求，请求将你的更改合并到
main分支。
- 新特性必须包含全面的单元测试和中文或英文的文档，否则将不被接受。 文档要求较为灵活——只需提供对特性功能的大体描述即可。
- 本仓库提供了 skill
/asco-test-doc，可以用来生成测试和文档的草案，提交者可以在此基础上进行核对和修正。
- 从
main分支创建一个新分支用于新特性。 - 实现该特性。
- 为该特性编写单元测试。
- 为该特性编写文档。
- 当特性准备好后，将特性分支合并到
main。 - 删除特性分支。
- 所有加入本仓库的人都可以在特性分支上进行贡献。
版本号采用三段式格式：a.b.c。发布时应使用带注释的 Git 标签进行标记（例如，v0.2.0）。
-
重大变更发布
a版本号递增。- 取得里程碑式的重大变更，可能包含不兼容的 API 更改、重大的新特性或架构重构。
-
定期小版本发布（每 3 个月）：
b版本号递增。- 可能包含自上次小版本发布以来积累的新特性、改进和错误修复。
-
补丁发布（根据需要）：
c版本号递增。- 由关键错误修复或计划外的重要特性添加触发。