协作角色、审核和发布

维护者 Aha-xiaoQ 负责玩法方向与最终发布。普通贡献者 Fork/PR；稳定贡献者通过实际合作后再考虑权限。当前没有自动添加成员、创建远端 Issue、PR 或更改分支保护。

工作划分

输入纯逻辑可由一个贡献者独立修改；测试/验证脚本、资料与许可清单可由其他贡献者并行做。原大运行文件、桥接、基线锁和 CI 属于敏感接缝，变更需维护者仔细复核。 一个 PR 只做一个主题；大角色、新关卡、玩法改动先讨论。任务认领在 GitHub Issue 明确记录，本地 WORK_ITEMS.json 不是在线锁定系统。

GitHub 页面需要维护者手动完成

推送本包后检查 Mario Mix collaboration 工作流真实运行。再将 Mario Mix / collaboration checks 按需设置为主分支必需检查，禁用 force push，并选择适合单维护者的审核规则，避免要求自己给自己批准。 新检查对所有 PR 都运行，避免路径过滤导致必需检查一直处于等待状态；push 仅对游戏相关路径触发。网页 PR 也会执行这组轻量工程检查。首次运行成功后，以 GitHub 实际显示的检查名称设置规则。 CODEOWNERS 只是审核责任，不是目录级写权限。不要向普通网友开放主仓库写权限。分支保护不能通过 ZIP 文件自动生效。

CI 信任边界

新工作流使用 pull_request / push / workflow_dispatch、contents:read、固定 Action 提交、无持久凭证、无缓存、无部署。外部 PR 只运行临时 GitHub 托管 runner；不得改为持有密钥的自建 runner，也不得用高权限 pull_request_target 拉取运行陌生分支。 维护者还应检查默认 Actions 权限、fork 首次执行审批和发布流程。

合并与发布分开

功能可以先合并为候选源码，不代表立即上线。发布由维护者根据 ACCEPTANCE 与 RELEASE_REVIEW 核验；不要直接复制候选覆盖 games/，第一条发布升级还需单独核对基线迁移和可回退版本。 覆盖 games/ 会改变下一次构建的输入基线，因此发布升级需要独立审核基线迁移与回退方案。