用途：维护者编排（Maintainer Orchestrator）是一个控制面技能，用于在多个彼此独立的 issue、pull request 或仓库之间协调真实维护队列，而不是处理普通单项仓库工作的默认方式。
激活门槛：创建 worker、心跳、账本或队列扫描前先分类请求。若请求只涉及一个 issue、一个 PR、一个 bug、一个功能、一次发布或一份连贯实现（即使跨多文件、多阶段、测试、CI 或紧耦合仓库），属于单项工作，应继续在当前会话用常规技能与流程完成，不因任务繁琐就建项目 worker；若误触发，应说明无需编排模式并直接继续。
有界编排条件：用户要求处理多个独立 issue/PR、协调多个仓库或并行工作流、要求队列/批量/组合/维护夜/持续分诊，或独立条目确实受益于并发归属与协调时才使用。编号任务列表不等于编排队列。
持久组合监控：心跳、循环监控、自动补队列、广泛所有者扫描、依赖回填与持久编排日志，仅在用户明确要求持续/自主维护、监控、组合扫描或维护队列时启用。
范围契约：激活时写下显式队列——具名仓库、具名 issue/PR 或用户要求的发现边界、是否允许超出该集合发现工作、监控是一次性还是持久、授权哪些公开动作。不得将具名批次扩展到无关仓库、依赖更新、发布或积压清理。
Worker 模型：优先每个仓库一个 Codex 应用项目线程，同仓库条目串行处理；worker 不得创建或管理其他 worker，层级止于根协调者到仓库 worker。协作子代理只读，不拥有实现、提交、推送、PR 变更、合并、发布、部署或实时验证。若无可用的项目线程机制，用当前会话的常规仓库流程，而非模拟 worker 层级。
仓库保护：分配或改动仓库前记录 git status -sb、分支、上游、HEAD、暂存/未暂存/未跟踪状态及领先/落后计数；拉取当前引用；在干净默认分支上快进拉取并确认仍干净；不得为开始编排而切换、stash、rebase、reset、clean、删除或覆盖脏的/非默认工作。
队列分诊：将每个范围条目分类为自主、需所有者决定、或未计划/无效。贡献者 PR 视为提案而非已接受设计，保留贡献者署名。
执行与公开门：私下调查、实现、本地测试与评审可跨 worker 独立进行；仅对会造成歧义或冲突的对外动作串行化，如推送到同一仓库/分支族、PR 创建/更新、工作流批准/重跑、最终同步、合并、发布或公开发布。
监控：每个外部等待指定一个所有者；仓库 worker 负责其精确 CI/部署监听；失败日志只拉一次并复用；仅在报告阻塞、反复无进展、范围/仓库错误、破坏性或未授权动作、安全风险或重大设计偏离时干预。
落地标准：要求仓库自身门禁加上症状复现或根因确认、最佳修复/所有者边界判断、聚焦回归覆盖、足够的面广检查、构建/实时/E2E 证明、全新自动评审无未决发现、精确头 CI 绿、评审线程已解决且已知证明缺口已明确说明。
所有者决策：一次问一个准备好的决策，包含完整规范 URL 与标题、行为与受影响用户、为何现在需要决策、已完成证明与当前 CI/可合并性、权衡与残余风险、协调者建议、确切选项与后果。
发布：队列调用不隐含发布权限；仅当用户明确要求发布或当前仓库工作流已授权时才进入发布规划/执行。
报告：有界批次只报告范围内工作（进行中、已干预、需所有者决定、已落地/关闭、剩余）；持久组合模式才允许紧凑账本与 ~/oss-orchestrator.md 日志。始终使用完整 GitHub URL。