Product Research Integration

渐进式产品研究

目标不是完成一份产品报告，而是让 Agent 在真实执行中逐步认识产品。每次只研究当前任务需要的部分，并更新能够跨轮次复用的稳定认知。

证据层级

按以下顺序区分，不得混写：

1. 已观察事实：代码、配置、路由、界面、公开页面、真实数据或用户明确陈述直接支持。
2. 暂定解释：多条事实共同支持，但仍需要使用或市场证据验证。
3. 工作假设：为了推进当前 loop 提出的可能用户、问题、场景或价值，必须写明验证方式。
4. 未知：没有证据时保留“未知”，不为了填满 SOUL 而补齐。

代码通常只能直接证明产品形态、组成和可见能力。不得从“存在某功能”直接推断“用户最需要它”“它解决了某个核心问题”或“这是产品差异化”。

每次执行

1. 读取现有 SOUL.md 和当前 Model 的相关 Memory，确定这次真正缺少哪一小块产品认知。
2. 定位产品载体：当前/相邻本地仓库、用户指定路径、原型、线上 URL 或用户描述。
3. 只读检查与问题直接相关的代码、文档、路由、配置和页面，不进行无目标的全仓扫描。
4. 需要验证可见行为时，让调用方 Model 使用 screenshot-assets 获取真实页面证据；截图和本次研究记录进入该 Model 的 Memory。
5. 列出“新增事实 / 被修正事实 / 新假设 / 仍未知”，每项附来源路径、URL、截图或用户陈述。
6. 按 SOUL 增量写入协议 修改 SOUL.md。只更新本轮有新证据的字段，不重写整份文件。
7. 将带时间的检查过程、证据清单和下一步验证动作写入调用方 Model 的 memory/<model-name>/products/<product-slug>/。

写入边界

• SOUL.md：产品的稳定认知、明确假设、关键未知和证据链接。
• Model Memory：本轮检查过程、截图、页面状态、临时分析、冲突证据和后续验证任务。
• 产品仓库：产品实现本身；除非用户要求修改，不因研究而写入。
• Collector：只维护研究方法，不保存某个产品的事实。

发现冲突时保留旧说法和新证据，先降级为“待验证”，不要静默覆盖。用户明确纠正产品事实时，记录为用户陈述，并在能验证时补上产品证据。

交付

报告本轮实际研究了什么、SOUL 哪些行发生变化、哪些结论仍只是工作假设、证据保存在哪里，以及下一次应在什么真实行动中验证。不要宣称已经“完整理解产品”。