用途：当架构、库或技术方案的决策依赖尚未经一手来源确认的事实时使用；也用于在难以回退的决策前比较备选方案，或核实某个假定的行为在当前依赖版本中是否仍然成立。不应用于为已定的选择补写理由（那是确认偏差而非研究）。当研究直接支撑可记入 ADR 的结构性决策时，可与 $specsfy-specialist-software-architecture 配合。
流程：先明确具体问题、它支撑的决策、范围与所需时效；事先定义何种证据可证实或推翻每个备选方案；来源优先级为规范/标准、带版本官方文档、官方源码与变更日志、目标环境中的可复现实验，最后才是二手来源；核对版本、发布日期与项目实际环境；对关键论断用第二个独立来源三角验证，文档无法解决时做受控实验；明确区分已确认事实、推断、风险与仍无证据的缺口；结论以直达来源链接紧邻对应论断，并给出对决策的具体影响。
规范：有可获取一手来源时，不以论坛片段、个人博客或通用 AI 回答作为 API 行为权威；引用具体页面与章节而非文档首页；保留决策所需上下文，避免大段转抄；记录可能随版本变化的来源版本与日期；来源冲突时显式说明冲突而非默默取舍；不另建与项目规范来源平行的 research.md，研究应被索引于使用方 spec 指定的位置；厂商自测基准视为有利益相关的证据，可作为起点，未经独立复现不作为最终结论。
反模式：先决定再找确认；引用“文档说”却不给链接与版本；把厂商营销基准当作中性测量；在存在多源冲突时只选支持原有偏好的一条且不记录冲突。
验证：支撑决策的每个结论都有直接可追溯证据（链接+版本+日期）；所用来源对应使用方项目真实版本与运行时；实验可被他人复现且不改动生产或真实数据；最终综合中显式列出缺口与残余不确定性；不得把未经三角验证的假设表述为事实。
相关技能：$specsfy-specialist-domain-modeling、$specsfy-specialist-prototyping、$specsfy-specialist-software-architecture、$specsfy-specialist-laravel-package-manager、$specsfy-specialist-debugging。另见 references/standards.md 中的来源层级、证据评估矩阵与综合格式。