jsonlee12138 Tech Research（领域调研协议）
为一个明确领域回答“现状是什么、方案是否可行、推荐什么、风险如何验证”。它是开发前编排的内部能力，不要求老板逐项调用。
输入
- 已确认的
intake.md、关联 PRD、项目约束； - 仓库和历史决策的只读上下文；
- 单一研究使命、边界、时间盒；
- 其他领域已知接口，但不共享未验证结论。
内部 subagent 契约
pre-development判定某领域未知项会影响设计、风险或验收时，该领域 research 为required，必须通过平台原生机制真实派发；主 Agent 自己读代码不能冒充领域 Subagent。- 每个 subagent 只研究一个领域，使用
pre-development的领域报告模板返回内容。 - 先查现有代码与一方资料，再比较方案；技术问题优先使用官方文档、规范或原始论文。
- 明确标注事实、推断、假设、来源和置信度。
- 只返回分析，不修改仓库、不写 VibeRig 文件、不操作 Linear、不开始实现。
- 主 agent 负责合并、去重、裁决冲突和落盘。
- 每次派发保存 dispatch receipt；同一 invocation 不得同时充当 research、红队和白队。
L2 只派发受未知项影响的最小领域集合。L3 对相互独立的领域使用同轮并行 fan-out；不为凑角色数量派发无关领域。
调研维度
- 现有能力、模块边界、技术债和可复用资产；
- 业务/技术可行性与外部依赖；
- 候选方案、成本、收益、约束和淘汰理由；
- 接口、数据、权限、错误语义及跨领域影响；
- 性能、容量、兼容、迁移、发布、回滚和可观测性；
- 单元、集成、契约、E2E、回归和非功能验证；
- 风险、触发信号、缓解、兜底、负责人建议；
- 需要 spike 的未知项及最小时间盒。
Spike 规则
只有查资料和读代码无法得到可信结论时才做 spike。每个 spike 必须写明目标、时间盒、最小实验、结果证据和“可行/不可行/仍需权限信息”的结论，不得顺便开发产品功能。
产出
主 agent 写入：
.vibeRig/requirements/<req-id>/research/
<domain>.md
feasibility.md
spike-<topic>.md
feasibility.md 必须给出总体推荐、关键证据、跨领域冲突、风险和开放问题。内部模式不单独同步 Linear，由 CTO 审批包汇总；用户明确要求独立调研时可以同步 Document，但仍不得创建 Issue / Milestone。
红线
- 未读代码和权威来源就凭经验给结论。
- 多个 subagent 研究相同使命，造成重复 token 消耗。
- required research 没有真实 dispatch receipt，却由主 Agent 直接写成“领域报告”。
- 把推断写成事实，或引用无法支持结论的来源。
- subagent 写文件、碰 Linear 或直接修改实现。
- 把调研推荐当成架构定稿；最终裁决属于
architecture-design。
完成检查
- 研究使命和边界单一明确。
- 事实/推断/假设、来源、置信度可区分。
- 方案比较含推荐、淘汰理由、成本、风险和验证方式。
- 跨领域契约及运行影响已说明。
- spike 有时间盒和明确结论，或注明不需要。
- 主 agent 已合并冲突；subagent 无副作用。
- required research 有真实 receipt，agent、artifact fingerprint 和输出引用完整。