Talebook 产品策划

先建立事实，再定义问题和方案。把 Issue 当作线索，不把单个功能请求直接当作路线图结论。

建立上下文

1. 读取仓库根目录的 AGENTS.md、README.md 和与任务相关的 design/**/*.active.html。
2. 读取 references/product-context.md，确认稳定定位、角色、产品闭环和边界。
3. 需要当前仓库与 GitHub 基线时，运行 python -X utf8 scripts/collect_evidence.py --repo . --pretty。GitHub 失败时使用脚本保留的错误和 Git 证据继续，不把失败解释为没有反馈。
4. 只有需要回看 V1 分析时点时，才读取 references/snapshot-20260721.md；不得把历史快照当作当前事实。
5. 明确本次产物：机会分析、竞品报告、版本路线图、PRD、用户流程、页面规格或可用性评审。请求含糊时，选择最小但足以支持决策的产物。

处理证据

1. 优先使用代码、测试、ACTIVE 方案、Git 历史、Issue/PR/Release 和真实页面。
2. 区分“已发布”“已实现未发布”“仅有方案”“历史提议”“外部仓库依赖”。
3. 为关键结论标记 事实 / 推断 / 建议 和 高 / 中 / 低 置信度。
4. 数量不足时不虚构频次、用户规模、转化率或 RICE 分值。
5. gh 默认只读。除非用户明确要求，不评论、不关闭、不加标签、不创建 Issue/PR。

建模用户与任务

优先覆盖实例管理员、个人读者、家庭/小圈子成员、访客与外部阅读客户端。把信号归入：

部署维护 → 入库与清洗 → 发现与组织 → 阅读与同步 → 分享与设备 → 反馈与恢复

优先修复闭环断点、一致性问题和不可恢复错误，再考虑孤立的新能力。

选择工作路径

产品策划与路线图

1. 将 Issue、提交、反馈和方案聚类为用户任务与痛点。
2. 写清角色、场景、当前替代方案、受影响闭环、证据、后果和信心。
3. 生成 目标 → 用户机会 → 候选方案 → 最小验证 机会树。
4. 按用户价值、影响范围、战略契合、实现与长期维护成本、安全/兼容风险、可逆性排序。
5. 形成 现在 / 接下来 / 以后 / 不做 路线图，并标出外部仓库和迁移依赖。
6. 为路线图、PRD、实验或复盘读取 references/product-metrics.md，选择少量可观测指标，不编造基线。

行业与竞品调研

读取 references/competitor-research.md，先定义研究问题，再选择直接竞品、邻近品类和客户端生态。使用最新官方仓库、文档、Release 及相关 Issue/讨论，输出“借鉴 / 差异化 / 不进入”，不要做无目的的全功能表。

UI 与交互设计

读取 references/ux-design.md。评审现有体验时，只要环境可运行，就检查真实页面，并记录路由、视口、主题、角色和关键状态；不能只从 Vue 代码推断体验。概念设计没有可运行页面时，明确标注未经真实渲染验证的结论。

做取舍

• 保持“简单好用的个人书库”主线；新能力必须改善核心闭环或显著降低管理员成本。
• 同时计算读者价值与自托管总拥有成本，包括镜像、架构、升级、配置、安全和支持成本。
• 把 OPDS、WebDAV、Moke 等视为生态能力，不把所有客户端功能都复制进 Web。
• 涉及公开传播、付费绕过、反爬军备或任意网络/脚本执行时，提高法律与安全门槛。
• 对 candle-reader、Moke、Calibre 和外部客户端明确接口契约与责任仓库。

输出决策级产物

默认使用中文，并至少包含：

1. 结论摘要和建议决策。
2. 范围、时间点、证据来源与限制。
3. 用户、场景、问题和当前替代方案。
4. 机会或方案比较、优先级理由与不做事项。
5. 涉及交互时的用户流程、页面/组件、关键状态和权限规则。
6. 成功指标、风险、依赖、验收条件和待确认项。

链接到具体 Issue、PR、Release、提交、文件、方案或页面证据；不要用笼统的“用户需要”代替证据。

进入实现

若用户只要求分析、评审或规划，不修改业务代码。若用户同时要求实现：

1. 按仓库 AGENTS.md 完成需求复述、设计澄清、WIP 方案、实现、测试回写和 ACTIVE 转换。
2. 新增或修改功能时补对应测试。
3. 前端交互、样式、主题、布局或弹窗变更时，启动开发环境并做真实浏览器验收。
4. 实现偏离产品方案时，先更新方案再继续。