项目治理¶

WutherCore 采用轻量维护模式。规则的目标是让日常改动可审查，同时避免小型维护团队因为人员暂时不可用而永久阻塞。

角色¶

• 仓库拥有者 / 管理员：管理仓库设置、安全事件、发布和紧急处置。
• 维护者：Review、Issue 分类、技术决策和发布准备。
• 贡献者：通过 Issue、Discussion、代码、文档或测试参与项目。

写权限和维护者身份基于持续贡献、判断力、沟通质量和安全意识授予，不因提交数量自动获得。

决策与合并¶

日常改动通过 Pull Request 完成。main 默认要求：

• Required CI 成功；
• 至少一名具备权限的 Reviewer 批准；
• 最近一次可审查推送由其他人批准；
• 所有 Review 对话已解决；
• 分支与最新 main 保持同步。

项目优先通过代码、测试结果和可复现证据形成共识。无法快速达成一致时，由负责该模块的维护者决定；跨模块或高风险变更由仓库拥有者做最终决定并记录理由。

紧急合并（break-glass）¶

当 Reviewer 长时间无法响应，而修复涉及已确认的安全问题、数据损坏、严重网络故障或发布阻塞时，仓库管理员可以在 Pull Request 中绕过人工批准。

紧急合并必须满足：

1. 已创建 Pull Request，不直接向 main 推送；
2. Required CI 已通过；
3. PR 中写明紧急原因、风险、验证和回滚方式；
4. 使用管理员合并入口，保留 GitHub bypass 审计记录；
5. 恢复协作后安排一次事后 Review。

Required CI、禁止强推和禁止删除由单独 Ruleset 保护，没有日常 bypass。若 GitHub Actions 本身发生长期故障，需要修改该 Ruleset，必须作为第二级紧急操作单独记录，并在事件结束后立即恢复。

发布¶

发布基于带版本号的 Git tag 和 GitHub Release。发布说明使用 .github/release.yml 分类生成，并补充兼容性、配置迁移、已知限制和校验信息。

安全修复应优先完成私有协作和受影响版本评估，再公开发布安全公告。