IR: conductor 跨仓事件面扩展——IR/卡生命周期下沉产品仓（QW_Arena1 首个试点）

[randypanding]

背景与由来：owner 在 IR #345 落位讨论中提出「IR 是否应放产品仓」（落位说明已论证：现行架构下 .github 是唯一可行落位，迁移=状态机死锁）。该讨论揭示的不是 #345 放错了位置，而是架构缺口——conductor 事件面尚未扩展到产品仓，产品仓无法承载自己的 IR/卡生命周期。本 IR 将该缺口正式立项，走 C1 治理变更。

IR 账本纪律：本 issue 为 append-only 意图账本——签署（state:ir-signed）后只追加评论/erratum，不编辑正文。

---

IR schema v1 九字段

1. job（要完成的待办）

扩展 conductor 状态机事件面至产品仓：使产品仓的 issues.labeled / issue_comment 事件进入 conductor 路由，IR/卡生命周期（ir-draft → ir-signed → spec → redteam → wave-planned → ready → in-progress → done）可在产品仓 issue 上完整运转；intent 模板与 state 标签集随 template-service 基线下发。QW_Arena1 为首个试点仓（组织首个走 IR→spec→红队全流程的产品仓，缺口首次被实际触发）。

2. 触发场景

• 产品仓开发者（agent）在本仓 issue 上直接走卡生命周期，而非跨仓引用 .github 的卡——owner 在 QW_Arena1 立项时的第一直觉即此（IR 就该跟着新仓走）
• 新产品仓立项时，IR 与实现 PR 分属两仓，工作凭证（卡）与代码落位分离，跨仓 Card: 引用增加认知与审计成本
• 产品仓自身的 bug 流（T 表 B1–B5，ADR-0064）在产品仓 issue 上无法流转，只能借道 .github

3. 当前痛点的证据

1. conductor.yml 路由守卫硬限定 if: github.repository == 'Cloudbird-Software/.github'；头注明示「W0 事件面=本仓（issues.labeled + issue_comment）；跨仓扩展随产品仓接入」——扩展是规划内但未立项的欠账
2. 组织全量检索 label:"type:intent"：7/7 个 IR 均在 .github（含 IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263、IR: 验证体系缺口闭环 + spec 质量测量 + fan-out 生命周期与红队燃料管道 + CNB 免费算力底座（临时措施，可删除层） #315 等产品性工作）——产品性意图被迫寄宿治理仓
3. IR 模板 intent.yml 仅存在于 .github；template-service 基线（72 文件）不含 ISSUE_TEMPLATE——新仓从模板派生即缺失 IR 承载面
4. 产品仓工作 PR 历来以 .github 卡为凭证：agent-tools#5/feat: agent 声明标准与 agent_runtime 治理域 #6 → .github#85、AI_Web_School#56/chore(deps): bump actions/checkout from 5.0.0 to 7.0.1 #57 → .github#90——跨仓引用模式已是既成事实
5. 工具面与状态机面错位：ghcb next [repo] 已支持任意仓参数（入口协议第 2 步），但 conductor 不路由产品仓事件——工具就绪、路由缺失

4. 期望的可观察变化（验收时能在线上看到的事实）

1. QW_Arena1 上创建的 type:intent issue，owner 打 state:ir-signed 后 conductor 成功路由（run 日志 verdict 非 noop，invoke:spec-author 触发）——IR→spec 链路在产品仓可达
2. QW_Arena1 issue 评论 /claim 经 arbiter CAS 裁决置 state:in-progress——租约链路在产品仓可用
3. template-service 基线新增 .github/ISSUE_TEMPLATE/intent.yml（及 bug.yml 状态标签配套），此后新仓派生即自带 IR 承载面
4. 新 ADR 落 agent-registry INDEX + archive 正本（双落盘），conductor.yml 头注「跨仓扩展随产品仓接入」更新为已实现状态
5. drift-check 无新漂移（若触及 org-required-workflows ruleset，§1 对账通过）

5. 非目标（NONGOAL）

• 不迁移既有 IR：IR-0001～IR: QW_Arena1 立项——千问 AI Arena「一键出海」跨境素材参赛 Agent（比赛原始要求全量冻结 + 语言规范豁免 ADR-0084） #345 全部留在 .github（append-only 账本纪律，历史不动）
• 不一次性全组织铺开：仅 QW_Arena1 试点；其他产品仓扩量另行 IR 决策
• 不改 transitions.yaml 转移语义：转移表、守卫、幂等键机制原样，只扩事件接收面
• 不动红队守门落位：adversary/org-gate 仍在中心仓钉点审判（ADR-0046/0082——「PR 改不到审判源」原则不因本 IR 弱化）
• QW_Arena1 开发不依赖本 IR：赛事开发按现行 Card: Cloudbird-Software/.github#345 跨仓引用模式即可开工（AGENTS.md 硬规则 5 已生效）

6. 约束 / 不可违反项

• 治理变更 C1 类（GM-2）：新 ADR 背书 + PR 流程；owner 与 AI 同受约束
• INV-02：状态标签写操作须 App 令牌（GITHUB_TOKEN 无状态写权）——跨仓需为 QW_Arena1 铸单仓作用域 App 令牌（AG-4 已挂载 ✓）
• 宪法 §11 唤醒矩阵：/claim /release 前置转介 arbiter 裁决（ADR-0055），跨仓不豁免
• INV-09：每 issue 单 concurrency group、串行排队——跨仓扩展后幂等语义不变（from_state 匹配承担）
• 宪法 §4D：AGENTS.md ≤30 行——入口协议如需更新不得超限
• fail-closed：路由/裁决 infra 故障红灯不放行（三态 0/1/2 语义保持）

7. 人类愿意接受的验收证据

• QW_Arena1 试卡全链路录屏级可复现：建卡（type:intent）→ 签署（state:ir-signed，conductor run 日志 verdict=allow、invoke=spec-author）→ /claim（arbiter CAS，先到先得）→ 负向用例（非授权 sender 静默丢弃，对齐 AC-11 测试模式，可扩 conductor-negtest 场景）
• 新 ADR 双落盘 sha256 三向闭环（agent-registry INDEX ↔ archive 正本 ↔ 本地）
• drift-check 合并后对账清零

8. 可逆性偏好

整体停用可逆：路由守卫收回仓限定即回滚至现状（单 commit 还原）；试点变更集中三处（conductor.yml、template-service 基线、新 ADR），无数据迁移、无既有卡改写。

9. 质量-速度旋钮

质量优先（治理面变更，fail-closed 不妥协）。速度上明确解耦：QW_Arena1 赛事时间盒（2026-08-31 截止）不传导至本 IR——试点实施可排在赛后从容推进，避免为赶赛期压缩跨仓状态机的验证深度。

---

Card 关联：演进自 .github#345 落位说明「演进通道」节。