协作模型

当工作容易查找、领取、审阅和验证时，Proto UI 才能保持速度。为此，每个协作面只承担一种状态。

Discussion 承接开放问题。Issue 承接边界明确的结果。PR 是一个可审阅的集成单元。Review 记录独立判断，Actions 记录机器证据，Deployment 与 Release 记录外部交付事实。

Milestone 表达一个发布结果或独立 program，不承担日常状态。

规划中的组织 Project 会成为跨仓库的操作视图，用字段表达工作流位置、任务是否就绪、优先级、claim 过期时间、证据进度、Agent 理解要求和动作采用的授权来源。产品语义仍然留在 spec/**。它的第一份投影以观察为主，便于安全核对路由数据；这条 intake lane 不是 Agent 的全局权限上限。三个定时 standing scope（proto-ui-scheduled-collaboration-v1、proto-ui-scheduled-review-v1、proto-ui-scheduled-merge-v1）目前均为 pending-runtime-identity 且只读。可逆后续动作在当前用户明确授权的 human-assisted 工作中继续执行；只有这些 scope 经 broker 核验的工作负载身份激活后，才会在幂等、过期 claim、实时权限和回滚条件满足时依其执行。

Labels 只保留少量稳定搜索维度：工作类型、所属区域、工作量、就绪度和风险。Project 中的工作流位置与 claim 状态不应再复制成 labels。

可实施的 Issue 应告诉贡献者：

• 问题或目标；
• 适用的权威与生命周期；
• 已经决定的内容；
• 贡献者可以决定的内容；
• 排除范围；
• 是否允许开始实现；
• 如何验收。

现有受治理方向、验收标准和 draft entity 足以让 Agent 开始有边界的实现并收集证据。只有在两个会造成实质差异的产品方向仍然冲突时，才记录最小产品选择而不擅自猜测；需要人类决定的是这项未决选择，而不是它周围的每个实现步骤。help wanted 用于标记可领取工作，但不会替这种选择制造答案。

领取需要与最新评论、assignee、关联工作和 Project 状态一致，并设置过期条件，避免停止推进的任务一直占用。

GitHub 权限决定平台操作。工作触及社区或 Bot surface 时，Discord 与 Poppy 信任才参与约束。本地 Agent 测评描述任务适配度：在 human-assisted 工作中它提供建议，在 autonomous 工作中它才是上限。任务风险和当前授权仍是独立条件。

分数和 Discord role 都不能授予 GitHub 权限。本地结果也不能证明模型身份或预测验收。在当前用户明确授权下，独立 Agent 可以重新核对 live state、通过 purpose-bound request 与已核验 receipt 继续一个可逆协作转换、提交有 finding 支撑的 REQUEST_CHANGES、批准符合条件的 clean exact head，并在可信证据、实时权限、review state 与仓库规则一致时合并已获独立批准的 exact head。承载这些写操作的定时 standing scope 目前均为 pending-runtime-identity：在 broker 核验的工作负载身份绑定之前，定时执行只读观察与 reconciliation，不执行任何协作、review 或 merge 写操作。协作 continuation 最多执行一次 mutation，并对未知结果最多 reconciliation 一次；它绝不盲目重试写操作。出现新 revision 时，流程直接回到 live reconciliation 与 fresh review。人类决策只保留给真正未决的产品方向，以及 publication、release、访问控制、secrets、仓库规则变更等特权或不可逆操作。

主仓库和 Discord Bot 目前并不具备相同的 CI 与分支控制。协作者应按各仓库真实存在的控制工作，不能借用另一边的保证。

完整政策见 CONTRIBUTING.md。