# Retaintive

> 健身房垂直 SaaS — AI 电话管理 + Lead 追踪 + 业务分析

## 规划发展

- [一、经营策略](/funding-strategy/01-经营策略.md): Retaintive 合作与出售策略：经营方向、产品价值、验证证据、潜在对象与接洽准备。

## 系统设计

- [Store-Level 数据隔离](/system-design/store-level-isolation.md): Store-Level 数据隔离设计 — 明确 `store_id`(UUID) 为唯一隔离键，规范所有 Neon 表的查询和写入规则，涵盖终态 schema、场景验证、已知漏洞及落地状态

## AI

- [AI 编程助手工具体系指南](/ai/product/ai-tooling-guide.md): AI 编程助手（Claude Code、Cursor、Copilot 等）在帮你写代码时，背后调用了多种不同来源的工具。本文从工程师视角系统讲解这些工具的分类、协议原理和选择逻辑，帮你从"能用"到"理解为什么这样设计"。

## 运维

- [Pipeline Monitoring（SoT 已移至 infra repo）](/operations/runbooks/pipeline-monitoring.md): 已收敛到 infra repo — 本页只留指针。

## 行业知识

- [健身房电话管理概述](/industry-knowledge/gym-call-management-overview.md)

## 竞品研究

- [竞品全景对比](/competitors/competitor-analysis.md): 本文档汇总所有竞品分析，提供全局对比视图。各竞品的深度分析见独立文档。

## 工具

- [AI 工具栈 — 我们用什么、为什么](/tooling/ai-tooling-stack.md): 目标:让 AI 在我们多个 repo 里找对信息、写代码前知道「这个东西已经有了」、不重复造轮子。 这页是结论(用哪个、为什么)。每个工具的详细好坏见 工具调研清单。

## Others

- [Factory 操作手册](/ai/factory/agentic-software-factory-playbook.md): 这不是参考文档。 参考文档见 agentic-software-factory.md。 这是你今晚可以跟着走的手册：设计 → 验证 → 睡觉 → 醒来有 PR。创建日期：2026-03-20
- [Factory 参考文档](/ai/factory/agentic-software-factory.md): 核心目标：从"我指挥 Claude 一步步执行"变成"我设方向，Agent 自主执行，我审批结果"
- [Botmux 能力地图：Lark 里的 AI CLI Runtime](/ai/factory/botmux-capability-map.md): Botmux 的能力地图，说明它如何把 Lark 会话映射成 AI CLI runtime，以及 session、terminal、multi-bot、workflow 与安全边界。
- [Diátaxis 文档框架](/ai/factory/diataxis-guide.md): Diátaxis 是 retaintive 文档站的信息架构标准。本文说明我们为什么采用它，以及每种文档类型如何映射到我们的目录结构。适合所有写文档的人——产品、工程、运营。
- [文档组织策略](/ai/factory/doc-structure-for-agents.md): 本文是一个通用框架：在 AI agent 深度参与开发的团队里，文档应该怎么组织。 适用于任何多 repo 项目。新建 repo 或重组文档体系时，以本文作为参考基线。读者：工程师，以及执行 factory-audit 的 AI agent。两个用途：工程师参考：了解如何组织文档对 agent 友好，评估现有 repo 是否合规factory-audit 标准规范：执行 factory-audit 时，agent 主动读取本文，以此判断 repo 是否符合 Agentic Software Factory 的基础设施要求注意：本文不是每次 session 自动加载的文件。factory-audit skill 被调用时，会通过 execution-policy.md 里的指针主动读取本文。
- [Factory 演进路线图](/ai/factory/factory-evolution-roadmap.md): 这是 retaintive 自己的工厂演进计划。三个阶段，按需推进——每个阶段都能独立交付价值，不需要等下一阶段才能跑通。最后更新：2026-03
- [Lark Agent Control Plane 设计](/ai/factory/lark-agent-control-plane.md): Lark Agent Control Plane 设计：把 Lark、Beads、botmux、lark-dm-bot 和 agent loop 串成可验证、可审计、以 PR 为人工审查终点的自动化控制面。
- [Lark CLI + Botmux：从 AI Developer 到 AI Employee Operating Layer](/ai/factory/lark-botmux-ai-employee-operating-layer.md): 组合 Lark CLI、Botmux、Beads/devbot DB 和 policy/audit/measurement，设计从 AI Developer 扩展到 research employee 和 project manager employee 的 operating layer。
- [Lark CLI 能力地图：AI 如何操作 Lark 工作系统](/ai/factory/lark-cli-capability-map.md): Lark CLI 的能力地图，说明其三层命令系统、主要 Lark 工作域覆盖、auth/risk 边界，以及为什么它适合作为 AI employee 的 workspace 操作层。
- [外部工具生态](/ai/factory/tools-ecosystem.md): 这是研究性参考文档。记录 2025-2026 年主流 Agentic Factory 工具的架构、对比，以及与 retaintive 现有系统的关系映射。最后更新：2026-03
- [Design: LLM Application Foundation Concepts](/ai/product/2026-06-23-llm-application-foundation-concepts.zh.md): retaintive LLM application foundation concepts: context retrieval, request builder, schema/tool contract, writer, ledger, and eval.
- [Design: LLM Output Contract 与 Prompt 管理方式](/ai/product/2026-06-23-llm-output-contract-architecture.zh.md): Current legacy contacts-analyzer output contract snapshot；typed metadata 分层可参考，具体 Task vocabulary 不代表 V3 Target。
- [retaintive LLM 平台架构终态与 Traceability](/ai/product/2026-06-24-llm-platform-architecture-and-traceability.zh.md): retaintive LLM 平台架构终态 — 用 Governance / Data / Cross-cutting 三平面模型,讲清每个现有组件(contacts-analyzer / Traceplane / Policy Guard / Neon)落在哪一层、execution bundle 怎么 resolve、ID 怎么穿过全链路、traceability 三层(Neon / Decision Ledger / Traceplane)各负责什么、给客户展示什么,以及向 agent / tool calling 演进的路径。
- [retaintive LLM 平台架构图解](/ai/product/2026-06-25-llm-platform-architecture-diagrams.zh.md): retaintive LLM 平台架构图解 — 用三平面模型(Governance/Release · Data · Cross-cutting)讲清现有系统该怎么分层,以及加 RAG/tool/Vapi 时新功能该放哪一层。含 Mermaid flowchart(架构分层)+ sequenceDiagram(tool loop 时序)。这是 2026-06-24-llm-platform-architecture-and-traceability.zh.md 的图解配套版。
- [Retaintive AI Operating System 长期蓝图](/ai/product/2026-06-25-retaintive-ai-operating-system-roadmap.zh.md): Historical Objective-first AI Operating System exploration；独立 Objective → Task 产品模型已被 Task System Design V3 supersede。
- [AI Agent Foundation 最终态与当前缺口](/ai/product/ai-agent-foundation-final-state.md): retaintive AI Agent Foundation 的当前态、最终态、缺口和 demo 前后路线图。
- [AI Agent 底座完整入门：从 API 到 Runtime](/ai/product/ai-agent-foundation-roadmap.md): AI Agent 底座入门与投入路线图；API/SDK/CLI/MCP/runtime 原则可参考，具体 Task 例子属于 Current legacy。
- [AI 集成路线图](/ai/product/ai-integration-roadmap.md): retaintive 产品的 AI 能力升级路线图。本文回答三个问题：我们有什么 AI 能力可用、该优先做什么（ROI 排序）、具体怎么做（架构 + Workflow）。 读者：产品负责人、后端工程师、Tech Lead。读完后能判断每个集成机会的优先级和技术可行性。 前置阅读：AI 工具体系指南 — 理解 Built-in Tools / MCP / Skills / CLI 的分层模型和 Host/Client/Server 架构。
- [Ask AI：官方 Agent 能力、账户与受控业务操作](/ai/product/ask-ai-platform.md): Ask AI 的完整产品目标、官方 harness 选型、设计原型与真实 test 截图、账户付款边界、受控修改、验收证据和后续条件。
- [怎样用 REST API 和 Anthropic Skill 构建 CLI 工具](/ai/product/build-cli-with-skills-2026.md): 你已经有 REST API, 想让 LLM 帮内部团队跑日常工作。最便宜可行的方式不是 MCP server, 是 CLI + Anthropic Skill 组合。1 个工程师 1 周 ship。
- [Call Accuracy](/ai/product/call-accuracy/index.md): Call Accuracy 相关文档入口，聚焦单次 call transcript / call analysis 是否被正确理解。
- [Call Input Smoke](/ai/product/call-accuracy/input-smoke.md): calls 表和 call analysis structured fields 的 lightweight smoke 设计，用于 demo 前确认上游 call facts 没有喂歪。
- [ChatGPT 商业接入：申请与准备](/ai/product/chatgpt-partner-application.md): Retaintive 申请商业 Sign in with ChatGPT 和订阅额度使用的官方入口、申请文案、审批前后能做的事及费用边界。
- [Contact Accuracy](/ai/product/contact-accuracy/index.md): Contact Accuracy 相关文档入口，聚焦多次互动后的 contact context / lifecycle / safety state 是否正确。
- [Contact Context Smoke](/ai/product/contact-accuracy/input-smoke.md): contacts / messages / leads / tasks / task_progress_events 输入上下文的 lightweight smoke 设计，用于 demo 前确认 contacts-analyzer 看到的 contact context 没有喂歪。
- [HTTP、API、REST、认证、MCP 核心概念入门](/ai/product/fundamentals-http-rest-cli-mcp-2026.md): 写给: 有一点 programming 概念、但不写代码,每天要跟 engineer / vendor / 客户聊技术的人。 目标: 读完之后,任何技术对话不再 nodding-and-pretending,而且能拿一句话判断对方说得靠不靠谱。 怎么读: 全文用一个餐厅点单系统的类比贯穿到底。每节先讲"没它之前什么痛",再讲"它一句话是什么",最后给你"开会时可以这么说"。
- [AI 产品与平台文档](/ai/product/index.md): AI 产品与平台文档入口：先读 Task System Design V3，再区分通用 AI foundation、Current legacy contracts/evals 与 historical Objective-first exploration。
- [MCP 自建还是用托管平台:决策指南](/ai/product/mcp-platforms-vs-build-yourself.md): 2026 年 MCP "as a service" 生态已经成熟, 几乎不需要自建团队。这份 playbook 帮你判断哪条路适合你公司当前阶段。
- [MCP、CLI、Skill 三者如何选择](/ai/product/mcp-vs-cli-vs-skills-2026.md): 决定一个 AI feature 该用 MCP server / CLI / Skills / LLM function calling, 不是技术品味问题, 是 token economics + audience + governance 三轴决策。
- [Task Accuracy Baseline v1 设计稿](/ai/product/task-accuracy/baseline-v1-design.md): Current legacy Task Accuracy Baseline v1；用旧 production prompt/Zod/scenarios 做兼容性回归，不定义 V3 Target。
- [Task Accuracy Baseline v1 Scenario Review](/ai/product/task-accuracy/baseline-v1-scenario-review.md): Current legacy Task Accuracy Baseline v1 scenario snapshot；旧 expected decisions 仅用于兼容性回归。
- [AI Evaluation Playbook](/ai/product/task-accuracy/evaluation-playbook.md): Current legacy AI evaluation playbook；说明旧 Task Golden Eval、DB Replay、Input Smoke 和 Revenue Rehearsal 的运行边界。
- [Task Accuracy](/ai/product/task-accuracy/index.md): Current legacy Task Accuracy scenario/eval 入口；验证现有 taskDecisions，不定义 V3 Task contract。
- [Task Prompt Architecture And Agent Evolution](/ai/product/task-accuracy/prompt-architecture-and-agent-evolution.md): Current legacy contacts-analyzer prompt architecture；分层和 context 方法可参考，具体 Task/Objective contract 已 superseded。
- [Revenue Rehearsal Playbook](/ai/product/task-accuracy/revenue-rehearsal-playbook.md): Current legacy Revenue Rehearsal pack；旧 objective policy/category/result 仅用于兼容性回归。
- [Voice Agent 可行性](/ai/product/voice-agent-feasibility.md): 作者: Max + AI (Claude Opus 4.7) + Codex 日期: 2026-05-25 状态: 调研报告 — 非 implementation plan, 不给时间表 读者: retaintive 团队 (含 non-technical 成员) 这份提到 "tenant-scoped tool API" / "capability token" / "control plane" 等架构概念。如果不熟悉 layered vs hexagonal 分层 / ports & adapters / Dependency Inversion / SOLID, 先看 Backend 架构 Pattern。
- [系统架构总览](/architecture/0-system-overview.md): 系统全景总览 — 架构概念导航（Level 0）+ repo / 存储 / 跨 repo 共享边界 / 环境表（Level 1）。前后端代码细节见 1-frontend.md / 2-backend.md，工程实操层见 system-design/
- [前端架构](/architecture/1-frontend.md): 前端架构总览 — Vue 3 SPA(174 pages / 38 query hook / 391 components / 10 Pinia store)。用 4 层(Mental Model / 五层架构 / 数据流时序 / 部署)展示。所有图都是手写 SVG,clickable 节点跳代码位置。
- [后端架构(Unified Pipeline 当前状态)](/architecture/2-backend.md): 后端架构总览 — 用 4 层(Mental Model / 后端拓扑 / Prompt 全景 / Prompt Before-After)展示 retaintive 后端处理逻辑全景:5 Lambda + 共享写入层 + 7 张 Neon 表 + 7 AI prompt 分布;每张图标 ✅⚠️❌ Phase 1 真实接入进度,点击节点跳 prompt md。
- [Prompt 架构与接入规则](/architecture/3-prompt-architecture.md): Prompt 架构与接入规则 — 说明 prompt、Zod schema、taxonomy registry、LLM call、deterministic guard 的职责边界,以及 prompt 接入 production 前的标准 template / schema audit checklist。
- [架构文档](/architecture/index.md): 架构文档入口 — retaintive 系统的封面级展示。按"跨层全景 / 前端 / 后端 / Prompt 架构"导航,每个文档回答一个清晰问题。工程实操层(字段细节 / 隔离设计 / pattern 选型 / write-matrix)见 ../system-design/。
- [Balto — 实时通话辅助 AI 平台分析](/competitors/balto-analysis.md): Balto 是专注于通话中实时辅助的 AI 平台，核心能力是在销售/客服人员打电话时提供实时话术提示、动态清单和 AI 辅导。与 Gong（通话后分析）不同，Balto 的重点是通话过程中的实时介入。 与 retaintive 的关系：Balto 的"实时通话辅助"能力是 retaintive 规划中的 P2 功能"AI 辅助通话提示"的直接参照物。Balto 不做健身行业，但其产品设计值得深度借鉴。
- [Glofox 分析](/competitors/glofox-analysis.md): Glofox 是面向精品健身工作室（Boutique Studio）的一体化管理平台，2022 年被 ABC Fitness（北美最大健身软件集团）收购。其核心差异化是品牌化白标 App 和简洁易用的操作体验。 与 retaintive 的关系：Glofox 是健身房现有的管理系统（MMS），retaintive 是接入其上的 CI + BI 分析层。两者更多是互补而非竞争——但 Glofox 的 XLerate CRM 在 Lead 跟进和自动化上与 retaintive 存在部分重叠。
- [Gong — CI 品类开创者分析](/competitors/gong-analysis.md): Gong 是 Conversation Intelligence（对话智能）品类的开创者和领导者。retaintive 不与 Gong 直接竞争，但 Gong 是产品方向的参照物和投资人叙事的锚点。 定位关系：Gong 证明了 CI 的市场价值（$72.5 亿估值），retaintive 是健身行业垂直的 CI + BI 平台。
- [Keepme ANTARES 仪表盘深度分析](/competitors/keepme-antares-dashboard-analysis.md): 本文档基于 Keepme ANTARES Insights 仪表盘的实际截图进行逆向分析，重点拆解其产品逻辑、数据架构和商业叙事，为 retaintive 产品设计提供参考。
- [Mindbody — 行业巨头分析](/competitors/mindbody-analysis.md): Mindbody 是健身 & Wellness 行业最大的一体化管理软件，拥有消费端 Marketplace 的双边网络护城河。 与 retaintive 的关系：Mindbody 是健身房的运营管理系统（MMS），retaintive 通过 API 与其集成，补上 Mindbody 缺失的 CI 通话分析和 BI 深度指标能力。两者互补，不竞争。
- [Revenue.io 分析](/competitors/revenue-io-analysis.md): Revenue.io（前身 ringDNA）是 Salesforce 生态内领先的收入编排平台，集 Dialer、Sales Engagement、Conversation Intelligence、Real-time Coaching 于一体。retaintive 不与 Revenue.io 直接竞争（目标市场和 CRM 生态完全不同），但其产品架构、AI Coaching 和 Conversation Intelligence 能力值得深入研究。 定位关系：Revenue.io 证明了"AI 电话管理 + 对话智能 + 实时指导"的商业价值，retaintive 是健身行业垂直的 CI + BI + Automation 平台，不依赖 Salesforce。
- [Salesforce：全球 CRM 平台分析](/competitors/salesforce-analysis.md): Salesforce 是全球最大的 CRM 平台，拥有最成熟的销售管理、营销自动化和 AI 能力（Agentforce + Einstein）。它不针对健身行业，但部分大型连锁健身品牌使用 Salesforce 管理销售流程——这使它成为 retaintive 需要理解的市场背景。 与 retaintive 的关系：Salesforce 是通用 CRM 巨头，健身行业渗透率低（定价过高、过于复杂）。retaintive 的部分客户可能用 Salesforce 做 CRM，两者通过 API 集成互补。Salesforce 不是竞争对手，但其 AI 能力（Agentforce）代表了行业最前沿，值得关注。
- [Zenoti 分析](/competitors/zenoti-analysis.md): Zenoti 是美容、健身、SPA 行业的一体化管理平台，覆盖从运营管理到 AI 获客/留存的完整链路。与 Keepme（纯 AI 对话）和 Mindbody（传统管理软件）不同，Zenoti 试图用一个平台解决所有问题。 ⚠️ 本文阅读顺序建议：先看顶部 TL;DR + v2 Update（2026-05-05 deep dive，是当前 SoT），v1 内容保留作 historical reference 但多处已被 v2 修正，每节有标注。
- [Zenoti + Keepme 借鉴详情](/competitors/zenoti-keepme-borrow-details.md): 用途:File 2 Part B 是 high-level 选型(Z1-Z6 / K1-K6 12 个名字 + ranking)。这份是 detail 版 — 每个抄的项目展开:他们的页面长什么样、为什么重要、我们抄过来该显示什么、关键 UI 元素 / 数据字段 / 注意事项。不写代码 / CSS / 组件 props。写:文字、信息架构、字段映射(指向我们 schema)、关键 interaction、不要踩的坑。配套:File 1 zenoti-keepme-resources.md(链接 inventory)+ File 2 zenoti-keepme-feature-comparison-and-borrow.md(对比表 + ranking)。 阅读顺序:§1 Zenoti 6 件(Z1-Z6)→ §2 Keepme 6 件(K1-K6)→ §3 开源资源 4 个怎么用(OSS1-OSS4)→ §4 附录:Zenoti 真技术栈解码(HyperConnect / Twilio / Amazon Transcribe — 你这次问的)。
- [Zenoti vs Keepme 对比](/competitors/zenoti-keepme-feature-comparison-and-borrow.md): 用途:一份 dedicated 文档帮 Max 拍板 "下周做什么"。配套:zenoti-keepme-resources.md(所有公开资源链接 inventory)。 阅读顺序:Part A 三方 Feature 对比表(扫表 5 分钟知道差距在哪)→ Part B 我们抄什么 + 回报最大 + low-hanging ranking(直接拍板的清单)→ Part C schema 一段话总结。
- [Zenoti + Keepme 资源](/competitors/zenoti-keepme-resources.md): 用途:retaintive 团队做 UI 借鉴 / 竞品监控 / 销售 narrative 准备时,直接来这一份查所有公开资源。配套文档:zenoti-keepme-feature-comparison-and-borrow.md(对比表 + 抄什么)。 阅读顺序:Keepme 资源(他们 UI 视频丰富,最高价值)→ Zenoti 资源(主要靠 marketing page + help docs)→ Design vocabulary(Dribbble / Behance / Mobbin)→ 开源代码模板(可直接 fork)。
- [ADR：采用两层 GitHub ruleset](/engineering/decisions/2026-07-org-ruleset-baseline.md): 历史 ADR — 最初用全组织 baseline 加 production tier 迁移散落的 repo-level branch rules，现已被当前治理模型替代。
- [工程治理决策记录](/engineering/decisions/index.md): 工程治理决策记录 — 保存 Context、Decision、Consequences 与重新评估条件。
- [GitHub 组织治理与仓库基线](/engineering/github-governance.md): Retaintive GitHub 组织治理标准 — 谁能修改、谁能合并、Team ownership、rulesets、CI 与新仓库基线。
- [工程治理](/engineering/index.md): 工程治理入口 — GitHub 组织规则、代码责任、变更决策与团队协作标准。
- [1. My Stores](/funding-strategy/02-产品说明书/01-my-stores.md): My Stores：多店对比报表——Leads、Tasks、Calls 三张表的指标口径、对比期间、单店跳转、CSV 导出与截图。
- [2. Dashboard](/funding-strategy/02-产品说明书/02-dashboard.md): 单店 Dashboard 五个页签：Leads、Tasks、Calls、Team、Revenue 的指标口径、管理价值与使用方法。
- [3. Tasks](/funding-strategy/02-产品说明书/03-tasks.md): Tasks 产品说明：按侧栏入口、顶部分类、查询工具、任务卡片、行动指导、客户资料与历史、操作工具栏的页面顺序说明，再介绍任务处理流程。
- [4. Calendar](/funding-strategy/02-产品说明书/04-calendar.md): Calendar：任务按 Next action 落到时间轴，拖拽改期、已到期与未排期区域及 Lead Line 的关系。
- [5. Coaching](/funding-strategy/02-产品说明书/05-coaching.md): Coaching 产品说明：按顶部分类、操作与筛选、列表卡片、辅导详情的页面顺序说明，再介绍辅导记录的生成规则。
- [6. Leads](/funding-strategy/02-产品说明书/06-leads.md): Leads 产品说明：按顶部日期与查询工具、表头筛选、线索行和客户与任务跳转的页面顺序说明，再介绍进线与去重规则。
- [7. Calls](/funding-strategy/02-产品说明书/07-calls.md): Calls 产品说明：按顶部工具栏、表头筛选、通话行与详情操作的页面顺序，说明通话记录、业务结果和任务与辅导跳转。
- [8. Contacts](/funding-strategy/02-产品说明书/08-contacts.md): Contacts 产品说明：按顶部工具栏、表头筛选、客户行与详情操作的页面顺序，说明客户资料、沟通历史和 DNC。
- [9. Scripts](/funding-strategy/02-产品说明书/09-scripts.md): Scripts 产品说明：按话术库三栏、卡片操作、新建与编辑弹窗、变量和 Tasks 使用顺序，说明 Call、SMS、Email 话术管理。
- [10. Lead Line](/funding-strategy/02-产品说明书/10-lead-line.md): Lead Line 产品说明：侧栏面板、标题栏、客户卡片、联系状态与跳转操作，以及首次联系退出规则和自动提醒电话。
- [11. Account Settings](/funding-strategy/02-产品说明书/11-account-settings.md): Account Settings 产品说明：按 Profile、Appearance、Store Access、Notifications、Change Password 的界面顺序，说明个人资料、外观、门店权限、浏览器通知与密码修改。
- [12. Store Setup](/funding-strategy/02-产品说明书/12-store-setup.md): Store Setup 产品说明：按账号列表、账号概览、Stores、未分配号码和门店编辑弹窗的界面顺序，分别介绍账号接入、门店启停、号码分配、员工及经营配置。
- [13. Access Management](/funding-strategy/02-产品说明书/13-access-management.md): Access Management 产品说明：按门店列表、成员表、Add Member 弹窗、角色修改和移除权限的界面顺序，介绍多店成员授权及 Owner、Editor、Viewer 的权限边界。
- [14. Ask AI：门店经营问答助手](/funding-strategy/02-产品说明书/14-ask-ai.md): Ask AI 的门店经营问答、客户与沟通查询、任务跟进、Lead 分析、员工辅导、多店比较和收入估值，以及使用范围与限制。
- [15. 数据接入与处理流程](/funding-strategy/02-产品说明书/15-数据接入与处理流程.md): 电话、短信、邮件线索如何进入系统并被处理。
- [16. 员工如何处理客户工作](/funding-strategy/02-产品说明书/16-员工如何处理客户工作.md): 员工一天的工作路径，以及哪些操作只是记录或跳转。
- [二、产品说明书](/funding-strategy/02-产品说明书/index.md): 按代码核对产品能力、AI、电话、Task、报表及实现边界；本目录按模块分篇。
- [三、产品论证](/funding-strategy/03-产品论证.md): 围绕 Retaintive 的产品价值，明确验证方向、方法、已有证据和待补证据，区分产品效果与外部经营背景。
- [四、West Harlem 生产证据](/funding-strategy/04-West-Harlem生产证据.md): West Harlem 生产观察、指标口径、匿名案例及待验证项。
- [五、潜在合作方竞品分析](/funding-strategy/05-潜在合作方竞品分析.md): 竞品功能清单及与 Retaintive 的逐项对比。
- [RingCentral 与 Claude 会议：客户需求与竞品反馈](/funding-strategy/06-潜在合作方-RingCentral/RingCentral与Claude会议问题整理.md): 从 RingCentral 与 Claude 会议的客户提问中，分析需求、购买顾虑、竞品反馈，以及对 Retaintive 的启示。
- [RingCentral 功能调研与合作分析](/funding-strategy/06-潜在合作方-RingCentral/RingCentral功能调研与合作分析.md): RingCentral 功能调研：当前账号可见功能、RingEX、AI 产品、RingCX、工作流与开放接口，以及 Retaintive 的合作评估重点。
- [七、OTF Momentum 2026大会参会计划](/funding-strategy/07-OTF-Momentum-2026大会参会计划.md): OTF Momentum 2026 大会调研：公开参会公司与人员、Max 与 Vivian 分别从纽约和西雅图出发的行程、增量预算及接洽安排。
- [八、初版市场与渠道研究（历史存档）](/funding-strategy/08-初版市场与渠道研究（历史存档）.md): 历史市场与渠道研究，保留来源和条件供按需追溯。
- [九、融资资源全景](/funding-strategy/09-融资资源全景.md): 目的：一次讲清 Retaintive 可申请的所有 funding 通道，按优先级和 fit 排序。Retaintive 定位：B2B SaaS（健身房 CRM + AI 通话分析），已有付费客户，co-founder Oliver 在 Columbia University。
- [工程资产清单](/funding-strategy/10-技术资产与交接/01-工程资产清单.md): 用于模型评估、接入运维和经营主体管理的工程资产。
- [接手依赖与交接边界](/funding-strategy/10-技术资产与交接/02-接手依赖与交接边界.md): 运行依赖、账号授权与所有权迁移需要核对的事项。
- [待开发能力与集成方向](/funding-strategy/10-技术资产与交接/03-待开发能力与集成方向.md): 尚不能作为已上线功能销售的语音能力与业务事实集成方向。
- [十、技术资产与交接](/funding-strategy/10-技术资产与交接/index.md): 供技术接手方阅读的工程资产、运行依赖、交接边界与待开发方向。
- [十一、接洽清单](/funding-strategy/11-接洽清单.md): 74 项历史接洽入口与文案，关联最新 LinkedIn 评论、邀请和跟进记录；加 Will、Alan、Kyle 共 77 项记录，按实际状态去重。
- [十二、通信平台合作与收购分析](/funding-strategy/12-通信平台合作与收购分析.md): 分析 RingCentral、Twilio、Aircall、Vonage、Zoom、Dialpad、Nextiva 和 Telnyx 的合作价值、能力重叠、收购可能性及进一步投入条件。
- [十五、Will 与 Alan 恢复联系](/funding-strategy/15-Will与Alan恢复联系.md): Will 与 Alan 的已有合作、实际邮件记录、当前 LinkedIn 入口及恢复联系文案，供 Max Review 后交 Muse 执行。
- [十六、Email 与 X 接洽执行记录](/funding-strategy/16-Email与X接洽执行记录.md): 2026 年 10 月 2 日 Email 与 X 阶段记录：19 封已发邮件、原 5 封草稿正文、Mindbody 回复、8 条已发布回复、退信及 74 项历史状态；最新 LinkedIn 执行见第 18 页。
- [十七、Muse 接洽操作交接](/funding-strategy/17-Muse接洽操作交接.md): LinkedIn 接洽执行后的 Muse 交接：77 条名录按最新评论、邀请、回复和限制去重；承接 Kayla／Kyle，Will／Alan 使用无电话新稿。
- [十八、LinkedIn 接洽执行记录](/funding-strategy/18-LinkedIn接洽执行记录.md): 2026 年 10 月 2 日 LinkedIn 执行记录：27 条新评论及链接、28 个邀请、Kayla 与 Kyle 已连接和实际跟进、四条评论修订及未执行入口。
- [OTF Compliance 功能分析](/industry-knowledge/OTF/OTF Compliance 功能分析.md): 这里的 Compliance 不是法律合规，而是门店运营和收入规则执行的合规。 所以它关注的是： 它不是收入构成表，但会影响收入质量。比如免费课太多会稀释收入，late cancel 管理不好会影响收费纪律，退款太多会直接冲减 revenue。
- [OTF Revenue Management 分析](/industry-knowledge/OTF/OTF Revenue Management 分析.md)
- [OTF Revenue Model 分析](/industry-knowledge/OTF/OTF Revenue Model 分析.md): OTF 本质上是一个 高客单价、会员订阅驱动、加盟扩张的 boutique fitness 模型。 它卖的不是普通健身房的“随便进场使用器械”，而是： 教练带课小团课/团体训练心率监测和数据反馈标准化课程体验会员制自动扣费跨门店品牌网络 用户端付费给门店，门店端再向 OTF 品牌方支付加盟相关费用。
- [OTF 课程与会员组合说明](/industry-knowledge/OTF/OTF 课程与会员组合说明.md): 整理日期：2026-07-12 适用范围：Orangetheory Fitness（OTF）美国地区公开规则，以及客户 Studio 2026 年 6 月 Revenue 明细中的实际产品价格。其他 Studio 的价格、课程开放情况和附加费用可能不同。
- [集成战略与 OTF 客户策略](/industry-knowledge/OTF/integration-strategy.md): 最后更新：2026-03-28
- [OTF Lead Temperature 与 Follow-up Cadence](/industry-knowledge/OTF/lead-temperature-follow-up-cadence.md): OTF Lead Temperature 与 Follow-up Cadence 参考规则：Lead 越新联系越密集，随后按 Red Hot、Hot、Warm、Lukewarm、Cold、Dormant 逐步降频。
- [OTF 店主核心痛点](/industry-knowledge/OTF/otf-owner-pain-points.md): 基于 OTF 业内人士访谈整理的门店店主核心痛点，包括获客、Lead 跟进、品牌定位、店主成本压力、竞争和教练质量。
- [OTF Telephone Inquiry Coaching 评审逻辑](/industry-knowledge/OTF/telephone-inquiry-coaching-scorecard.md): 将 OTF Telephone Inquiry Scorecard 转化为可用于人工或 AI Coaching 的通话评审逻辑。
- [Appointment Reminder Call（预约提醒电话）](/industry-knowledge/call-types/appointment-reminder-call.md)
- [Lead Call（潜在客户电话）](/industry-knowledge/call-types/lead-call.md)
- [Referral Call（转介绍电话）](/industry-knowledge/call-types/referral-call.md)
- [Retention Call（留存关怀电话）](/industry-knowledge/call-types/retention-call.md)
- [Service Call（售后服务电话）](/industry-knowledge/call-types/service-call.md)
- [Win-back Call（召回电话）](/industry-knowledge/call-types/win-back-call.md)
- [BI 商业智能知识体系](/industry-knowledge/frameworks/BI商业智能知识体系.md)
- [CI 对话智能知识体系](/industry-knowledge/frameworks/CI对话智能知识体系.md)
- [AI 多通道扩展行业调研](/industry-knowledge/frameworks/ai-insertion-analysis-industry.md): Created: 2026-02-22 Purpose: Research industry best practices for extending AI analysis beyond phone calls to SMS, Lead Tracking, and PhoneBook (unified customer profiles) Context: retaintive currently uses AI only for phone call analysis (Deepgram transcription + Amazon Bedrock LLM). This document examines how industry leaders handle multi-channel AI analysis and recommends patterns for our system.
- [跟进机制（Follow-up）](/industry-knowledge/sales-process/follow-up-mechanism.md)
- [OrangeTheory Fitness 销售流程与定价体系](/industry-knowledge/sales-process/orangetheory-sales-process.md)
- [Alert Coverage(已并入 On-Call Guide)](/operations/alert-coverage.md): 已并入 On-Call Guide — 本页只留指针。
- [Operations — 从这里选路](/operations/index.md): Operations 入口 — 按你现在的处境选文档,30 秒内找到该看的那份。
- [On-Call Guide — 被告警打扰时看这页](/operations/on-call-guide.md): 被 page 了先看这页 — 告警分级、每条告警的含义和第一步动作、覆盖边界、升级路径。
- [Reprocess AI Analysis SOP](/operations/reprocess-ai-analysis.md): Standard Operating Procedure for re-triggering AI analysis on calls that have already been processed or failed.
- [AI Analysis Processor Runbook](/operations/runbooks/ai-analysis.md): AI Analysis Processor（ResultProcessorTS）深度排障 runbook — 为什么分析失败/质量差/怎么补，对照 callytics-infrastructure 代码
- [Lambda Concurrency Decisions(已移至 system-design)](/operations/runbooks/lambda-concurrency-decisions.md): 已移至 system-design — 本页只留指针。
- [OpenRouter 仪表盘反查 Runbook](/operations/runbooks/openrouter-dashboard-lookup.md): 从客户报告的电话号码出发，4 步反查到 OpenRouter（openrouter.ai）某一次 AI 调用的完整 payload；含 CloudWatch ai_usage 字段速查 + 常见 debug 场景。
- [数据对账系统 Runbook](/operations/runbooks/reconciliation.md): Reconciliation（数据对账）系统运维手册 — Orchestrator/Worker SQS fan-out、4-state 检测、DLQ 恢复、429 处理、告警响应
- [转录处理器 Runbook](/operations/runbooks/transcribe-processor.md): TranscribeProcessorTS Lambda 运维手册 — RingCentral 录音下载、S3 上传、Deepgram 转录（Gemini 二次重写）、6-phase 流程、DLQ 恢复、404/429 处理
- [全链路 AI 赋能规划](/product-design/future-plans/ai-full-funnel-enhancement.md): 全链路 AI 赋能规划 — 基于 Keepme ANTARES 竞品分析，规划在获客和留存环节引入 AI 即时响应、生成 SMS、通话辅助、流失预测等 5 项能力，强调"AI 赋能人工"的人机协同策略而非 AI 全自动替代，充分利用 CI 语义信号和 BI 分析深度形成差异化优势。
- [近期后端能力产品化 Roadmap](/product-design/future-plans/backend-capability-productization-roadmap.md): 近期后端能力产品化 Roadmap — 把 2026-06 下旬完成的 Task、Lead、AI 决策审计、Store/Phone 归属和 Dashboard 性能底座，转成下一轮前端与后端可交付的产品改进。
- [通话分析数据逻辑](/product-design/future-plans/call-analysis-classification.md): Per-Call AI 数据分类体系 — 基于 44,151 条通话的 Per-Call AI 输出字段分析，梳理 customer_type、primary_category、primary_subcategory、primary_outcome 等 8 个关键字段的分布与映射规律，为 Cross-Call AI Follow-up Task 生成逻辑提供数据基础。
- [AI 对话式营销引擎](/product-design/future-plans/campaign-engine.md): Campaign Engine 产品设计 — AI 对话式营销顾问功能，老板用自然语言与 AI 讨论营销活动，AI 从 PhoneBook 48 字段客户画像中匹配目标受众、融合外部竞争情报（Yelp/Google Maps）、生成定制 SMS，员工审核后批量发送至 RingCentral，追踪回复、通话、成交效果，补填 AI 运营顾问五层能力金字塔中的数据模型和执行机制空白。
- [流失会员赢回逻辑细化](/product-design/future-plans/churned-member-logic.md): Churned Member 赢回逻辑细化方案（待实现） — 基于 frozen/active/terminal 三态模型，提议增加 churned_min_winback_attempts 阈值以区分"真流失"vs"员工失职"，参考健身行业最佳实践定义 30-90 天赢回周期内的最少联系次数，并列举其他待细化的设计维度（子状态细分、季节性策略等）。
- [Contacts 字段设计](/product-design/future-plans/contacts-field-design.md): Contacts 字段规格设计 — 逐字段对照 UI 和数据指标需求，定义 PhoneBook 主表 47 个字段的数据来源、存储策略、write pipeline 和展示布局；涵盖身份信息、生命周期、AI 跨通话分析、Lead 专属状态等全生命周期字段。
- [联系人扩展指标](/product-design/future-plans/contacts-metrics-extended.md): Contacts 扩展指标实现计划（暂未启动）— 列举 DNC 标记率、手动里程碑（Showed/Trialed/Converted）、AI 增强字段（purchaseIntent / suggestedActions / customerSummary 等）和 7 项衍生指标，定义这些未来功能的数据来源和业务用途。
- [仪表盘数据源完整列表](/product-design/future-plans/dashboard-data-sources-full.md): Dashboard 数据与指标计算全景 — 定义 Lead / Tasks / Revenue / Contacts 四大 tab 的 69 个指标如何计算、从哪张表取数、V1 是否就绪（77% 系统自动可用、13% 需手动输入、3% 需 AI 分析）。包含状态来源（contacts / contact_timeline / tasks）、top-level KPI（转化率/响应时间/完成率等）和营收归因映射表。
- [Lead 成交归因设计](/product-design/future-plans/lead-attribution.md): Lead 成交提成分配设计（待实现）— 定义当一个 Lead 经多名员工接触后最终成交时，如何用 Setter/Closer 两段分工模型记录贡献、分配提成，包含防作弊逻辑和管理配置方案。
- [Lead 联系节奏设计](/product-design/future-plans/lead-contact-cadence.md): Lead 联系节奏设计方案 — 根据温度(Hot/Warm/Cold)和阶段(首次触达/跟进)自动计算每条 Lead 的联系时间基准,通过任务提醒驱动员工执行、预警策略监控执行质量、短信模板支持内容发送,并提供店铺级自定义参数。
- [Lead 状态与指标汇总](/product-design/future-plans/lead-metrics-summary-full.md): Lead 指标体系汇总 — 整合 Outreach 与 Follow-up 两阶段的 12 个状态和四级指标分类（战略级 KPI / 漏斗健康度 / 管理预警 / 诊断下钻），阐明乘法漏斗逻辑、跨阶段指标关系、数据可用性分析，及当前 Dashboard 能追踪的指标和行业基准。
- [Lead 员工执行质量指标](/product-design/future-plans/lead-staff-performance.md): 员工个人和排行绩效指标体系 — 定义 6 个员工维度的个人指标（处理数、响应时间、漏跟率、触达率、预约率、沟通质量）和 4 个排行指标（触达率排行、预约率排行、沟通质量评分、工作量排行），明确 V1 阶段暂不实现（因缺 Lead 分配机制），留待 assignedTo 字段上线后。
- [潜在客户温度评级（Lead Temperature）](/product-design/future-plans/lead-temperature.md): Lead Temperature 自动衰减机制 — 基于 Hot/Warm/Cold 三个温度标签，按时间窗口自动降温，通过客户互动事件升温；Cold 后系统自动判定最终状态（Unreachable / Lost Contact / Neglected），支持条件下重激活。
- [下一轮产品迭代执行逻辑(5 件事)](/product-design/future-plans/next-iteration-execution-logic.md): 产品线 5 件事的执行逻辑 — 每件回答为什么做/现状事实/要做什么/关键设计点/验收,基于 2026-07-01 跨 repo 代码实测。含执行批次:哪些是 low-hanging 立刻做,哪些要先拍设计。
- [任务与营收归因](/product-design/future-plans/revenue-attribution.md): Tasks 与营收关联设计 — 通过追踪员工和 AI 自动完成的任务，量化跟进对 New/Retained/Saved/Expansion/Renewal/Referral MRR 的贡献，并估算 Leakage 和 ROI。
- [角色深度剖析 v2](/product-design/future-plans/role-deep-dive-v2.md): 角色深度剖析 v2 — 跳转页面，实际内容在独立 HTML（含 Hypothesis 批注）。包含 retaintive 用户角色分析和产品定位深度探讨。
- [Retaintive Insight Digest — 产品文件](/product-design/future-plans/task 看板设计/insight-digest-product.md): 在数据看板之上，提供一层由 Retaintive 团队主动解读数据、给出精准结论的服务。
- [Task Trends 信号组合分析框架](/product-design/future-plans/task 看板设计/task-trend-signals.md): 适用于 Retaintive 通话分析系统，所有任务（除 Lead Outreach 外）均由电话分析触发。 核心原则：任务创建量 = 系统从通话中检测到的信号数；任务完成量 = 团队的跟进行为
- [Task 改进建议](/product-design/future-plans/task-improvement-proposals.md): Task 系统改进建议池 — 收集四类未来迭代方向：Autoclose 结果修正、同一会员多任务营收去重、归因系数线性化、以及接入真实收益数据替代固定 MRR 单价。
- [Task 员工归因与任务流转设计](/product-design/future-plans/task-staff-attribution.md): Task 员工归因与任务流转设计方案 — 扩展当前 Task 字段设计，补充员工执行动作记录、区分任务关闭人与业务促成人、实现多触点信用分配、支持任务分配与转接流转。包含新增字段规范、典型场景和 6 项待讨论设计决策。
- [Zenoti 竞品分析与长期产品定位](/product-design/future-plans/zenoti-learnings-and-next-goal.md): Zenoti 竞品学习和 Retaintive 长期定位 — 基于 Zenoti 8 个 AI agent 的 4 象限评估、Keepme 竞争对手分析和健身房角色驱动的产品设计(Owner / Manager / FD),阐述 customer-specific gold standards 作为 killer feature 的 12-18 月产品蓝图、短中长期落地路径和真实 positioning statement("我们评估你的员工怎么卖,用你自己定的 playbook,不替换真人员工")。
- [产品设计准则](/product-design/index.md): 用户体验 — 用户在每个页面看到什么、业务规则是什么、DB schema 为什么这样设计、AI prompt 怎么写。功能规格、display/calculation 规则、产品策略。
- [产品北极星](/product-design/north-star.md): retaintive 产品本质与北极星 — 基于电话、短信、Email Lead 和员工 context 的 AI Revenue Workbench，形成 Task、Next Action、Activity 与有证据的 Outcome。
- [下钻分析设计](/product-design/product-architecture/drill-down-analysis.md): 下钻分析设计 — 从汇总指标逐层拆解找根因的交互框架，涵盖两种分析类型（指标拆解、维度归因）、可下钻的核心指标、维度定义、交互呈现方式及智能提示机制，用于帮助老板/经理/员工快速定位问题
- [全流程数据分析框架](/product-design/product-architecture/full-process-analytics-framework.md): 全流程数据分析框架总览 — 从 Lead 初始接触到最终成交的完整分析体系，涵盖 Lead Outreach 业务流程、沟通分析、Follow-up 策略、12 个 Lead 阶段状态、及预约/到店/试课/转化等关键指标。
- [模块化服务策略](/product-design/product-architecture/modular-service-strategy.md): 模块化服务策略总览 — 根据 6 种健身房业态设计分层模块组合（核心基础/业务场景/AI分析/培训赋能/增值服务），支持客户按需选配，配合定价套餐和合作开发机制提升市场匹配度
- [产品定位](/product-design/product-architecture/product-positioning.md): retaintive 产品战略定位 — 在健身房管理软件之上叠加的智能分析层。从市场策略（Add to 而非 Replace）、五大能力架构（CI 感知、BI 度量、AI 决策、Automation 执行、Coaching 赋能）、与竞品差异化、到产品边界清晰划分。
- [角色化仪表盘设计](/product-design/product-architecture/role-based-dashboard.md): 角色化仪表盘设计 — 根据老板（Owner）、经理（Manager）、员工（Staff）三种角色的不同决策需求，分别设计仪表盘展示内容、数据粒度、呈现方式，同时支持跨角色钻取分析。
- [系统世界观](/product-design/system-worldview.md): retaintive 系统世界观 — 写代码前必读。讲清这台系统信什么、谁说了算:判断信刚发生的事、动手只能在代码授权范围内、任务绝不能静默消失。含向 AI agent 平台演进的方向,以及一个真实 bug 反面教材。
- [Coaching Highlights 规格](/product-design/v1/coaching-highlights-feature/coaching-highlights-spec.md): Coaching Highlights 规格 — AI 对销售通话的 5 个维度（Booking Ask、Objection Handling、Retention Technique、Rapport Building、Information Accuracy）逐通话打分，用分数阈值推导 flag（需教练）和 highlight（样板）标签，供前端 Staff Performance 面板和 Rules 消费。
- [Contacts Specification](/product-design/v1/contacts-feature/contacts-spec.md): Contacts 数据规格 — v1 版本，定义前端 Contacts 页面的 27 个字段来源（contacts 直读、contact_timeline 聚合、跨表派生、API 计算），字段类型、写入权限和展示位置。
- [客户生命周期管理](/product-design/v1/contacts-feature/user-lifecycle-management.md): 客户全生命周期管理框架 — 以 phone number 为主线，概括从 Lead 获取到 Churn 再到 Win-back 的完整客户旅程；定义 Lifecycle Stage (Lead/Member/Churned/Unknown) × Lifecycle State (Active/Frozen/Terminal) 的状态矩阵，以及客户画像体系（基础属性、健身画像、消费决策画像、行为标签、AI 预测指标等）与意向信号链。
- [Dashboard 规格说明](/product-design/v1/dashboard-feature/dashboard-spec.md): Dashboard v1 规格 — 定义 Overview 两个图表（Total Tasks 任务状态分布、Impacted Revenue 营收归因表格）的数据源、字段映射、计算逻辑和 SQL 实现。
- [Lead Cadence Checkbox](/product-design/v1/lead-tracker-feature/lead-cadence-checkbox.md): Lead Cadence Checkbox — 用客户提供的六档温度跟进节奏表，把「今天该联系哪些 Lead」变成一个勾选框：员工勾掉即记录一次接触，系统自动算出下一次应联系日期。温度由天数纯函数推导，不新增状态机，不依赖 AI。
- [Lead Contact Cadence](/product-design/v1/lead-tracker-feature/lead-contact-cadence-v1.md): Lead Contact Cadence v1 简化版 — 定义首次响应 SLA（默认 5 分钟）与静默时间约束（TCPA 夜间禁联规则），说明店铺如何自定义响应时限，以及系统如何通过 SLA 记录判定 lead 最终状态。
- [Follow-up 阶段工作流与分析（潜在客户跟进）](/product-design/v1/lead-tracker-feature/lead-follow-up.md): Lead Follow-up 工作流与状态模型（v1 旧版）— 定义潜在客户跟进的 4 个场景（触达未预约、预约未到店、到店未试课、试课未成交）、9 个状态转移、漏斗指标和隐性拒绝判断逻辑，以及失联 vs 漏跟的核心区分规则。
- [Lead Funnel 与 Status 汇总](/product-design/v1/lead-tracker-feature/lead-funnel-status.md): Lead 状态模型定义（v1） — 定义 9 个可追踪的 Lead Status、3 个 Lifecycle State（Active / Paused / Terminal）及其映射关系，以及 Lead Funnel 的 5 个漏斗阶段分类。
- [Outreach 阶段工作流与分析（潜在用户首次联系尝试）](/product-design/v1/lead-tracker-feature/lead-outreach.md): Lead Outreach 阶段指南 — 从 Lead 采集到预约的完整流程、8 个 Lead Status、核心指标定义、无法触达 vs 漏跟的区分，以及按来源渠道、员工、触达原因的诊断下钻方式，v1 旧版文档。
- [潜在客户温度（Lead Temperature）](/product-design/v1/lead-tracker-feature/lead-temperature-v1.md): Lead Temperature v1 简化版 — 定义 Hot/Warm/Cold 三个时间窗口来衡量首次联系的紧迫度，规定 Cold 后系统自动判定两个终态（Unreachable 和 Neglected），员工无需手动管理温度。
- [Lead Tracker 规格说明](/product-design/v1/lead-tracker-feature/lead-tracker-spec.md): Lead Tracker 页面规格 — 定义 Pipeline tab（漏斗卡片分组）和 Leads tab（列表筛选）的所有数据来源、计算方式、占比公式和交互映射。基于 contacts 表的 lifecycleStage 和 leadStatus 字段。
- [Lead Line 自动 Lead Outreach 队列](/product-design/v1/lead-tracker-feature/leadline.md)
- [Prompt 中 Coaching 部分的待解决问题](/product-design/v1/prompt-improvement/2026-05-coaching-open-issues.md): 来源：分析 oliver-proposals/prompts/03-coaching-system-prompt.txt 与 oliver-proposals/prompts/03b-coaching-playbook-brain.txt 的职责、输出 schema 和 downstream dashboard 需求后得出。
- [Prompt 中 Task 部分的待解决问题](/product-design/v1/prompt-improvement/2026-05-task-decision-open-issues.md): Oliver 2026-05 Prompt 改版的待解决问题汇总 — 逐句分析 contact-analyzer task 部分 14 个问题，包括 leadStatus 定义缺时间约束、task status 命名漂移、typeCategory↔closeResult 映射不完整、AI update 机制字段不全等，每条给出具体建议，v1 旧版。
- [Task Playbook 改进建议](/product-design/v1/prompt-improvement/2026-05-task-playbook-open-issues.md): Oliver 2026-05 Prompt 改版的 Task Playbook 待解决问题汇总 — 分析 Action Plan 数据链路、06 task playbook prompt 职责、05 task decision 配合边界、PlaybookContent 字段语义和分阶段实现建议。
- [Oliver 改进方案](/product-design/v1/prompt-improvement/oliver-proposals/index.md): Oliver 针对通话分析各阶段 Prompt 提出的改进方案，包含重写后的 System Prompt 源文件。
- [Rules Feature 设计](/product-design/v1/rules-feature/rules-feature.md): Rules Feature 产品设计总览 — 店铺管理者自定义的 7 个业务规则配置（Lead 温度时长、阈值、首次响应时限、Follow-up 任务截止、静默时段、营收基准），影响 Lead 温度自动降级、任务到期、状态终态判定和营收归因计算。
- [Rules 规格说明](/product-design/v1/rules-feature/rules-spec.md): Rules 功能规范 — 店铺管理者配置运营参数的完整规范，涵盖 Lead 温度窗口、Lead 阈值、首次联系时限、task 截止时间、Quiet Hours（TCPA 合规）和营收基准等 6 个可配置块。v1 版本。
- [Task 生命周期（Prompt 设计视角）](/product-design/v1/tasks-feature/prompt-task-lifecycle.md): Task 生命周期的 prompt 设计反推 — 从四个 AI prompt（Triage / Classification / Coaching / Contact Analyzer）的实际代码逆向工程 Task 的创建、更新、关闭决策逻辑，与产品设计视角互补，并列出 prompt 与现有 spec 的七处差异（v1 研究稿，基于 2026-05 四 prompt 改动版）。
- [Task Impacted Revenue 归因设计](/product-design/v1/tasks-feature/revenue-attribution-2.md): Impacted Revenue 产品与数据设计：基于 Task positive outcome 和可配置 benchmark，估算 recurring 与 one-time revenue impact，并说明当前数据库基础、计算口径、UI 规则和待实现能力。
- [Task 与营收归因](/product-design/v1/tasks-feature/revenue-attribution.md): Task 与营收归因设计 — v1 版本。定义 9 种关闭原因（closeResult）如何映射到 MRR / 一次性收入类型，给出计算公式和 8 个可配置的假设值（客单价、归因系数等），采用混合归因模型（因果链清晰的全额计入，存在自然恢复的用系数折扣），未来可演进为 Before/After 对比或动态系数。
- [Task 生成、更新与关闭机制](/product-design/v1/tasks-feature/task-lifecycle.md): Task 生成、更新与关闭的完整机制 — 讲述 Contact Analysis Pipeline 如何根据 12 个业务场景（Lead 开发、投诉挽留、支付恢复等）生成跟进任务，任务优先级规则（High 4h / Medium 24h / Low 72h），员工手动调整与 AI 自动关闭的流程设计，以及待确认的员工手动调整丢失问题。v1 旧版本。
- [Task 字段设计](/product-design/v1/tasks-feature/tasks-field-design.md): Task 表字段设计（v1 旧版）— 定义 23 个字段的名称、类型、写入源、业务含义；说明 typeCategory 11 值枚举（Lead Outreach / Follow-up / Booked Not Converted 等）和 closeResult 13 值枚举（用于营收归因）。以 callytics-common schema 为准。
- [Tasks 功能概览](/product-design/v1/tasks-feature/tasks-overview.md): Tasks v1 总览 — 员工每日执行工作台。定义任务来源（Lead SLA 和 AI 自动生成）、两类任务类型（Lead Outreach 和 Follow-up）、显示逻辑（按时间和优先级维度分组排序）和关闭规则（AI 自动和员工手动）。
- [Tasks Specification](/product-design/v1/tasks-feature/tasks-spec.md): Tasks 特性产品规格 (v1) — 定义 tasks 表数据字段、前端展示逻辑（汇总卡片、筛选器、任务卡片、关闭弹窗）及 type_category / close_result 枚举值，并标注当前 schema 与设计目标的 7 项差异。
- [Dashboard 重新设计 — 时间与内容矩阵视图](/product-design/v1/ui/2026-05-24-dashboard-reshape.md): Dashboard 单店深挖页 reshape 设计 — 统一 time × content 正交矩阵，从 4 个 time tab + 变化 layout 改为 1 个 unified time picker + 固定 7 块 layout，包含 AI Quick Scan / KPI 卡条 / Staff Performance 表 / Cancellation & Complaint Reasons / Impacted Revenue / Task by Reason，全部带计算公式和后端实现指导。
- [My Stores 仪表板 — 两个标签重设计](/product-design/v1/ui/2026-05-24-my-stores-2tab-design.md): My Stores 仪表板 2-Tab 重设计方案 — 用统一 time range picker 和 Call Activity / Outcomes 两个功能 tab 替代旧 mvp-v3 的按时间切换模式,包含完整的计算公式(call-level 和 task-level KPI)、后端 API 改动清单和两个待决策项(Membership 口径、Complaint subcategory 范围)。
- [Activity Timeline Schema](/product-design/v2/activity-timeline/activity-timeline-schema.md): Live contact_timeline schema 与历史兼容语义；Task V3 selected Target 和 rollout 状态分别由当前 V3 文档维护。
- [Calls — 页面展示](/product-design/v2/calls-feature/calls-display.md): Calls 页面展示规格 — 三栏式布局（筛选面板、通话列表、详情面板）、通话卡片内容、AI 分析与 transcript 展示、Flag for Coaching 功能
- [Calls Schema](/product-design/v2/calls-feature/calls-schema.md): Calls 表完整 schema — 单表全字段视图。Mirrors RingCentral Call Log API + AI 分析结果；Coaching 相关字段虽在 calls 表内，逻辑归 coaching-schema.md。
- [Coaching — 计算配置](/product-design/v2/coaching-feature/coaching-calculations.md): Coaching 功能的计算配置 — 定义触发条件（duration / call_state gate）、coaching flag rate 公式、KPI 数据来源、AI feedback 字段、以及待开发功能的数据需求（read/unread/note 功能）。
- [Coaching — 页面展示](/product-design/v2/coaching-feature/coaching-display.md): Coaching 页面展示 — manager mailbox-style review workspace，审阅 AI 标记的辅导通话，处理 read/archive/remove/note。
- [Coaching Schema](/product-design/v2/coaching-feature/coaching-schema.md): Coaching schema — AI coaching 内容存于 calls 表，manager inbox workflow 存于 coaching_reviews 表，AI 内容反馈存于 ai_feedback。
- [Contacts — 页面展示](/product-design/v2/contacts-feature/contacts-display.md): Contacts 页面展示规格 — 左右分栏布局（联系人列表 + 详情面板）、顶部汇总卡片、可搜索可排序的字段列（姓名、电话、阶段、Lead 状态、购买意愿、信用卡、短信、待跟进、投诉），以及 Overview 和 Communication Log 两个标签的字段设计。
- [Contacts Schema](/product-design/v2/contacts-feature/contacts-schema.md): Contacts 表 2026-06 historical snapshot；Task V3 是 selected Target，当前 schema 与 rollout 状态仍须分别核验。
- [Name Trust — 名字写入规则](/product-design/v2/contacts-feature/name-trust.md): Name Trust 设计 — 多来源名字写入时的优先级机制（6 级信任分：员工手填 100 分最高、lead form 80 分、RC API 60 分、AI 转录 40 分、webhook 20 分、未知 0 分），UPSERT 时高分覆盖低分，同分新值胜。
- [Dashboard — 计算配置](/product-design/v2/dashboard-feature/dashboard-calculations.md): Dashboard 指标计算规范 — 定义 Performance 和 Team 两个 tab 的 KPI 卡片、快捷牵引、人员聚合维度，对标后端 endpoint(`dashboard-summary.ts`、`dashboard-staff.ts`)，标注已接线状态与待开发部分。
- [Dashboard — 页面展示](/product-design/v2/dashboard-feature/dashboard-display.md): Dashboard 页面展示规格 — 店长视角的运营总览，包括 Performance（通话量、任务完成）、Team（员工维度汇总）、Impact/Reports（预留标签）三个 tab 的设计，含 KPI 卡片、快捷牵引和数据表的具体字段定义及后端接线状态
- [Dashboard Schema](/product-design/v2/dashboard-feature/dashboard-schema.md): Dashboard metric lineage 的 2026-06 historical snapshot；Task V3 reporting 是 selected Target，当前 SQL 与 rollout 状态仍须分别核验。
- [V2 产品设计完整规格](/product-design/v2/index.md): V2 产品设计文档索引；Task V2 路径保留为 compatibility/historical 资料，Task V3 是 selected Target，实施状态单独跟踪。
- [Lead Funnel 与 Task](/product-design/v2/lead-tracker-feature/lead-funnel-status.md): Lead Funnel 与 Task 的边界：Funnel 是基于 Email Lead、RingCentral communication、Task Activity/Business Progress/Outcome 和员工确认的 versioned projection，不是 Task status，也不假定 CRM/provider truth。
- [Lead Tracker — 计算配置](/product-design/v2/lead-tracker-feature/lead-tracker-calculations.md): Lead Tracker 数据定义与计算规则 — 详细说明 Speed to Lead、漏斗转化（Received → First Outreach → Booked Intro）、转化率及同期比的数据口径、SQL 实现与当前接线状态。
- [Lead Tracker — 页面展示](/product-design/v2/lead-tracker-feature/lead-tracker-display.md): Lead Tracker 页面展示 — Pipeline overview + Received lead visibility，实际跟进行动跳转 Tasks。
- [Lead Tracker Schema](/product-design/v2/lead-tracker-feature/lead-tracker-schema.md): Leads schema — email intake 原始 lead 表，以及它和当前 Lead 页面 contacts-based 读法的边界。
- [Operating Hours Schema](/product-design/v2/operating-hours/operating-hours-schema.md): Operating Hours 三表完整 schema — operating_schedules / operating_overrides / blackout_periods。给 prompt reviewer + SLA 接入工程师用。
- [Rules Schema](/product-design/v2/rules-feature/rules-schema.md): Rules 配置的 2026-06 historical inventory；Task V3 Policy Catalog 是 selected Target，当前 rollout 状态单独跟踪。
- [My Stores — 计算配置](/product-design/v2/stores-feature/stores-calculations.md): My Stores 多门店首页的 Call Activity 和 Task Outcomes 两个页签的数据定义 — Call Volume、Intro Calls、Membership Calls、Cancellation Calls 等指标的 SQL 口径、表源和实现状态，以及每个指标的期间对比趋势计算方式。
- [My Stores — 页面展示](/product-design/v2/stores-feature/stores-display.md): My Stores 多门店总览页面设计 — 展示 8 家门店卡片，下分两个 tab 分别从通话和任务维度展示各门店业绩（Call Volume / Intro / Membership / Cancellation / Core Productivity 等指标）。包含时间筛选、voicemail 开关、趋势对比，并标注了哪些指标已接线到后端 endpoint、哪些待开发。
- [Stores Schema](/product-design/v2/stores-feature/stores-schema.md): Stores 域完整 schema — 6 张表单表全字段视图(rc_stores / rc_store_phones / store_config / staff / store_members / DDB StoresV2)。给 reviewer 验证字段定义与隔离架构用。
- [Cadence（草稿）](/product-design/v2/tasks-feature/cadence-overview.md): Cadence 功能设计草稿（未定稿）— Task 列表之外的时间线操作视图。员工按一天的时间轴看任务，延后任务会挪到新的时间点；打开任务自动带出 AI Playbook 话术和最近通话记录。复用现有 task_progress_events / task_playbooks schema，不新建任务数据模型。
- [Task Pipeline Architecture Addendum](/product-design/v2/tasks-feature/design/research/task-pipeline-architecture-addendum.md): Task V2 与 Unified Pipeline 架构的关系 — 厘清 Task Orchestrator 应作为共享 mutation layer 而非单一 feature 内部逻辑，给出 closeResult / progress 区分、API contract 定义、Phase 1 推荐实施顺序的设计补强
- [Task Pipeline 设计 Brief](/product-design/v2/tasks-feature/design/research/task-pipeline-design-brief.md): Task Pipeline 架构设计 Brief — 给新 session 的完整设计指南,定义代码层与 AI prompt 层在 task 生命周期各个决策点的职责划分,附 acceptance criteria、关键冲突问题、调研成果和材料清单。
- [Task Pipeline Deliverable (Codex)](/product-design/v2/tasks-feature/design/task-pipeline-deliverable-codex.md): Task Pipeline 最终架构设计 — Codex 独立产出，定义 task 作为统一 work object 的设计：lifecycle (open/closed)、progress events、business outcomes、state machine、orchestrator、AI 与代码的职责分工、API contract 与 prompt contract、完整场景覆盖。
- [Tasks V2（Historical / Compatibility）](/product-design/v2/tasks-feature/index.md): Tasks V2 compatibility/historical 入口；当前 selected Target 与 rollout 状态统一由 Task V3 文档维护。
- [Task V2 历史兼容入口](/product-design/v2/tasks-feature/task-domain-lifecycle.md): Task V2 historical compatibility pointer；Task V3 是 selected Target，实施状态由独立 rollout 快照维护。
- [Task V2 → Task V2+ → Task V3 工程审计与设计建议（Historical）](/product-design/v2/tasks-feature/task-v2-plus-engineering-audit.md): Historical Task V2+ engineering audit captured in 2026-07；保留当时的工程假设与演进背景，不再是当前实施路线。
- [Tasks Calculations](/product-design/v2/tasks-feature/tasks-calculations.md): Task V2 Calculations historical compatibility 入口；Task V3 是 selected Target，当前公式和环境状态仍须从 live evidence 复核。
- [Tasks Display](/product-design/v2/tasks-feature/tasks-display.md): Task V2 Display historical compatibility 入口；Task V3 是 selected Target，实际 UI 与 rollout 状态仍须从 live evidence 复核。
- [Tasks Schema](/product-design/v2/tasks-feature/tasks-schema.md): Task V2 Schema historical compatibility 入口；Task V3 selected Target 与 rollout 状态分别维护，live schema 仍以代码和 migration state 为准。
- [Unified Pipeline Phase 1 — Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/normative-spec.md): Phase 1 实现计划 — 统一 task 和 contact mutation 到共享 module，完成 task_progress_events 表上线、applyTaskAction 状态机、store_id 数据隔离。包含 final schema、module contract、6 个 caller 的迁移步骤、end-state invariant tests 和 SaaS 安全 checklist。
- [Plan 01 — callytics-common Schema Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-01-callytics-common-schema.md): Phase 1 schema 实现计划 — 6 步添加 task_progress_events 表 + tasks 过渡期字段，新增 enum 和 UI 常量，生成 Drizzle migration，发布 @retaintive/common v1.1.0（additive only，破坏性操作延至 Plan 07 cutover）。
- [Plan 02 — callytics-common Modules Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-02-callytics-common-modules.md): callytics-common 4 个共享 module 实现计划 — task-orchestrator / policy-guard / contact-writer / timeline-writer 模块设计,含 7 个 task 分解、SQL 不变量验证、CTE 事务原子性、幂等键设计和 snapshot 模式检查。
- [Plan 03 — contacts-analyzer Caller Migration Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-03-contacts-analyzer-migration.md): contacts-analyzer Caller Migration — 9 个 task 把 contacts-analyzer Lambda 从 inline Drizzle SQL 迁移到 @retaintive/common/domain 共享模块（TaskDecision 6-action union、applyTaskAction() / upsertIdentity() / closeAllOpenForContact() / writeTimelineEvent() 委托等）。
- [Plan 04 — lead-processor Caller Migration Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-04-lead-processor-migration.md): lead-processor 迁移实现计划 — 替换硬编码的 task/contact/timeline SQL，改用 Plan 02 共享模块(applyTaskAction + upsertIdentity + writeTimelineEvent)，5 个分阶段 task 逐步完成 caller 迁移，附落地时 3 个 frame uncertainty 的验证清单。
- [Plan 05 — message-processor STOP cascade migration Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-05-message-processor-migration.md): Plan 05 实现方案 — SMS STOP keyword DNC cascade 从自拼 SQL 迁移到 @retaintive/common 共享 module，包含依赖更新、STOP cascade 重写、status filter sweep 和 integration test 4 个任务。
- [Plan 06 — studio-api Migration Implementation Plan](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-06-studio-api-migration.md): Phase 1 studio-api 迁移计划 — 把 6 个 task endpoint (close / reopen / postpone / progress) 和 3 个读路径收口到 @retaintive/common/domain 的 buildTaskActionSQL() adapter,核心目标是统一 state machine + Policy Guard 并确保所有写操作通过 sql.transaction() 原子提交。包含 9 个 task 分别改造各路由、新增 progress endpoint、处理过渡期 status 兼容性、重构 action_needed 读路径、以及 E2E 集成测试。
- [Plan 07 — Cutover Runbook](/product-design/v2/unified-pipeline/implementation-plan/plans/2026-06-02-07-cutover-runbook.md): Phase 1 cutover runbook — Step-by-step ops procedure to migrate from transitional schema (3-value status enum + legacy columns) to final state (2-value status, legacy columns dropped, store_id NOT NULL), with preflight checklist, rollback paths, and invariant verification.
- [Unified Pipeline Phase 1 (Codex)](/product-design/v2/unified-pipeline/original/unified-pipeline-phase-1-codex.md): Phase 1 统一 pipeline 实现设计 — 定义如何在保留现有 SQS/Lambda/API 架构下，将 task/contact/timeline 写入统一收口到 shared mutation boundary，规范 Task Orchestrator、Contact Writer、Timeline Writer 等共享模块的 contract，并明确 4 类 caller（Studio API、contacts-analyzer、lead-processor、message-processor）的迁移顺序。
- [Unified Pipeline Target State (Codex)](/product-design/v2/unified-pipeline/original/unified-pipeline-target-state-codex.md): Unified Pipeline 终态架构设计 — 7 层分层模型，说明多个 entrypoint (Lambda / UI / AI agent) 如何共享统一的 Policy Guard + Task Orchestrator / Contact Writer / Timeline Writer 进行状态变更，核心原则是 AI proposes structured output，code validates + executes。
- [Unified Pipeline Target State (Opus)](/product-design/v2/unified-pipeline/original/unified-pipeline-target-state-opus.md): 统一 pipeline 目标架构 — 通过四个共享写入层模块（Task Orchestrator / Contact Writer / Timeline Writer / Policy Guard）解决跨 5 条 pipeline 的 contacts、tasks、contact_timeline 表写入逻辑不一致问题，分两层设计(shared mutation + processing capability)。
- [01 — Triage](/product-design/v2/unified-pipeline/prompts/01-triage.md): Stage 1 triage — classifies call state (human/voicemail/no_answer/system_error), matches staff name against the studio's staff list, and decides whether the call is worth deeper analysis.
- [02 — Classify(2026-06-02 重写版)](/product-design/v2/unified-pipeline/prompts/02-classify.md): Stage 2 classify(2026-06-02 重写版)— 单 prompt 输出 customer_profile + primary_topic + secondary_topics + revenue_priority + summary + follow_up,严格 enum 互斥(standard outcome vs cancellation outcome 不可混用);online booking follow-up 强制归 service,不允许误判为 revenue_impacting。
- [03 — Verify](/product-design/v2/unified-pipeline/prompts/03-verify.md): Stage 2.5 verify — independent re-classification when Stage 2 lands on a known-confusable subcategory. Reasons from contrastive examples and the transcript, returns its own subcategory + confidence; the pipeline only adopts it on confident disagreement.
- [04 — Coaching(2026-06-02 重写版)](/product-design/v2/unified-pipeline/prompts/04-coaching.md): Stage 3 coaching(2026-06-02 重写版)— 只保留框架 / 决策规则 / 输出 schema,**所有 SALES / RETENTION / FREEZE / BILLING / COMPLAINT domain knowledge 已拆出**到 04b-coaching-brain.md。每通电话只选一个最有 business impact 的 coaching moment。
- [04b — Coaching Brain / Playbook(2026-06-02 新增)](/product-design/v2/unified-pipeline/prompts/04b-coaching-brain.md): Coaching Brain / Playbook(2026-06-02 新增)— read-only 知识库,被 04 Coaching prompt 读取。包含 SALES / CANCELLATION / FREEZE / BILLING / COMPLAINT / GENERAL communication 6 大 domain 知识 + category focus areas + 强弱 coaching output 示例。**不写库**,不定义 output schema,纯参考。
- [05 — Contact Analyzer (current, combined)](/product-design/v2/unified-pipeline/prompts/05-contact-analyzer-current.md): Current (combined) Contact Analyzer prompt — cross-call synthesis. Reads a contact's full call + SMS + lead + pending-task snapshot, outputs lifecycle/leadStatus/risk profile AND taskDecisions[] (create / close / update) in a single JSON call.
- [05a — Contact Profile Prompt(2026-06-02 新增)](/product-design/v2/unified-pipeline/prompts/05a-contact-profile.md): Contact Profile Prompt(2026-06-02 新增)— Stage 4 Contact Analyzer 拆分后的 **模板 1**,负责画像段。Cross-call analysis 产出 contacts 表 JSON(lifecycle / DNC / leadStatus / purchaseIntent / goals / objections / customerSummary / hasOpenComplaint)。**不输出** taskDecisions(由配对的 06 Task Decision prompt 负责)。仍跟 06 拼成 1 个 system prompt,1 次 LLM 调用。
- [06 — Task Decision Prompt(2026-06-02 新增)](/product-design/v2/unified-pipeline/prompts/06-task-decision.md): Task Decision Prompt(2026-06-02 新增)— Stage 4 Contact Analyzer 拆分后的 **模板 2**,负责 task 决策段。读 Contact Profile + recent calls/messages + pending tasks + recently closed tasks + playbook,输出 `taskDecisions[]`(create / close / update,**future** record_progress)。**不输出** contact 画像字段(由配对的 05a Contact Profile prompt 负责)。
- [07 — Task Playbook Prompt](/product-design/v2/unified-pipeline/prompts/07-task-playbook.md): Task Playbook prompt — generate front-desk execution playbook for one selected task. Read-only(不写库),输出员工话术。Stage in unified pipeline:Task Decision 之后的 read-only 步骤。
- [Unified Pipeline Prompts](/product-design/v2/unified-pipeline/prompts/README.md): Prompts folder index — 8 prompt surfaces + 1 read-only brain layer in the unified pipeline。包含 Phase 1 live 5 + 2026-06-02 用户交付 4 份新版(02 classify 重写 / 03 coaching 拆 framework + brain / 05a contact profile / 06 task decision)+ 07 task playbook(代码未接入)。Reviewer 用这个 index 找 prompt 跟它写入的 schema 表配对。
- [Unified Pipeline 现状调研 (Codex)](/product-design/v2/unified-pipeline/research/unified-pipeline-current-state-codex.md): Unified Pipeline 现状调研 — 调研本地代码中 unified pipeline 架构的现有基础（shared mutation modules、policy guards、task/contact/timeline writers）与待统一的部分，为 Phase 1 设计提供事实依据。
- [Unified Pipeline Architecture 设计 Brief](/product-design/v2/unified-pipeline/research/unified-pipeline-design-brief.md): 统一 pipeline 架构设计任务 brief — 从 task pipeline 出发检查 retaintive 5 条独立 pipeline（call/contact/SMS/lead）的设计问题，定义共享 mutation module（Task Orchestrator / Contact Writer / Timeline Writer）和 processing capability module 的两层架构，明确代码和 AI 的职责分界，设计 one-time AI call 模式的统一抽象并确保向 tool calling 模式平滑演进。
- [Unified Pipeline Reference Checklist](/product-design/v2/unified-pipeline/research/unified-pipeline-reference-checklist.md): Unified Pipeline 设计执行 brief — 调查现有 call/SMS/lead/contact/task pipeline 的 schema、prompt、code 职责边界，梳理 code vs AI 的分工模式，设计 Phase 1 共享模块 contract (Task Orchestrator / Contact Writer / Timeline Writer) 和未来 tool calling 兼容性。
- [Unified Pipeline Research Appendix](/product-design/v2/unified-pipeline/research/unified-pipeline-research-appendix.md): Unified pipeline 研究附录 — 代码调研结论确认"统一 shared mutation layer"方向，对比两份设计文档定位，列举 10 个关键发现（contacts/tasks/timeline 混淆、STOP 处理、Tool calling 定位）和 Phase 1 执行建议（Task Orchestrator 优先、Timeline Catalog、Contact Writer、触发契约）。
- [Unified Pipeline 统一设计](/product-design/v2/unified-pipeline/unified-pipeline-final.md): Historical Unified Pipeline architecture snapshot；shared mutation 思路可参考，旧 progress table/global closeResult proposal 已 superseded，Task V2 create_closed 语义仍需保持。
- [Product Design V3（Selected Target）](/product-design/v3/index.md): V3 产品设计入口：区分已选定的 Target contract 与按日期核验的 rollout 状态，避免把 merge、deployment、TEST validation 或 PROD release 混为一谈。
- [Tasks V3（Selected Contract / Rollout）](/product-design/v3/tasks-feature/index.md): Tasks V3 入口：分别指向稳定 Product / Domain Contract 与按日期维护的 rollout 状态快照，并保留历史设计评估资料。
- [Task V3 Product / Domain Contract](/product-design/v3/tasks-feature/task-domain-lifecycle.md): Task V3 稳定 Product / Domain Contract：Task、Next Action、Activity、Business Progress、Outcome、Task Policy、AI authority、backend、Workbench 与 measurement；动态 rollout status 单独维护。
- [Task V3 高层设计评估（Historical Candidate）](/product-design/v3/tasks-feature/task-v3-design-evaluation.md): Task V3 历史候选设计评估：记录 2026-07-17 对核心概念、Notification、RingOut、Scripts 和 staff review 边界的判断。
- [Task V3 Implementation Audit 与修复路线](/product-design/v3/tasks-feature/task-v3-implementation-audit-remediation.md): Task V3 implementation audit 与修复路线：以 live code 为事实，记录 production wiring 前 blocker、可信 Gate 设计和 anti-gaming 规则。
- [Task V3 Rollout 状态快照](/product-design/v3/tasks-feature/task-v3-rollout-status.md): Task V3 rollout 的 2026-08-04 source-state 快照：merged/open PR、checked-in environment gates、authority defaults、evaluation、legacy retirement 与尚不能声称的发布状态。
- [AI 决策可追溯性：把 AI 做事过程变成可查的账](/system-design/ai-decision-traceability.md): AI 决策可追溯性的目标状态、现有表复用策略、需要新增/修改的表和字段 schema。
- [AI Objective / Evidence 数据模型目标态](/system-design/ai-objective-evidence-data-model-final-state.md): AI Objective / Evidence 数据模型目标态：如何把开放式 AI 判断落成可展示、可审计、可演进的 objective、source、ledger 和 registry。
- [AI 产出数据架构(AI Output Data Architecture)](/system-design/ai-output-data-architecture.md): AI 产出(建议/指导/教练反馈)的存储架构 — trace→improve 闭环、append-only 分层模式、三表职责、覆盖语义边界、多租户就绪。2026-06-10 Max 拍板。
- [Backend 架构 Pattern](/system-design/backend-patterns.md): Backend 架构总览 — retaintive 两类 backend（HTTP API vs async processing Lambda）的 pattern 对比、request lifecycle、Layered vs Hexagonal 架构选择标准，以及 auth/ORM/新功能落位指南
- [Call Lifecycle Tracking](/system-design/call-lifecycle-tracking.md): Call Lifecycle Tracking 系统设计 — 将 RingCentral webhook 事件完整保存到 Neon contact_timeline 表，补全中间状态数据（Setup/Proceeding/Answered/Hold/Voicemail 等），支持下游对通话生命周期的查询和分析。
- [Contacts API — Read Patterns](/system-design/contacts-api-reads.md): /v2/contacts/* API 读取模式 — profile 端点读客户档案字段，communications 端点用 UNION ALL 读 calls + messages 表的通话/SMS 历史，两者支撑前端 ContactDetailSheet 共享组件。
- [DynamoDB 表关系图](/system-design/dynamodb-table-map.md): DynamoDB 全表清单与迁移规划 — 26 张生产表(Call Analytics / 电话管理 / 门店运营 / 线索追踪)的所有权、状态、迁移进度、安全现状及 Archive 候选清单,含 Neon-primary 双写现状、孤儿表处理路线图和 4 阶段 archive plan。
- [Identity 字段速查](/system-design/identity-fields.md): Identity 字段总览 — 系统中 8 个身份字段的完整速查（userId / store_id / account_id / franchise_id / client_id / connection_id / phone 相关字段 / extensionId），包含字段含义、层级角色、存储位置、历史别名、跨 repo 命名 crosswalk，以及一次通话穿过全部字段的完整流程演示。
- [系统设计](/system-design/index.md): 工程设计工作区 — 工程师在这里推敲设计细节:数据怎么隔离、字段怎么定、每个 Lambda 写哪些表、代码用什么 pattern、pipeline 逐条工程分析、multi-tenant 怎么演进。比 architecture 更深、更进阶,是改代码 / 做设计时查的实操层。
- [Lambda 并发决策](/system-design/lambda-concurrency-decisions.md): 决策记录（DDR）——为什么 contacts-analyzer / transcribe-processor / ai-analysis-processor 的并发值这样定：历史演变、burst 实测容量、扩容 baseline 与 frame correction trail。live 值以 lib/stacks/*.ts 代码为准。
- [Multi-Tenant 架构最佳实践](/system-design/multi-tenant/best-practices.md): Multi-tenant SaaS 架构最佳实践通用参考 — Strategic 设计层 + Tactical 实现层（AWS 5 pillar）+ 业界对标。讲方法，不讲 retaintive 具体落地。
- [数据模型关系总图(Entity Relationship Map)](/system-design/multi-tenant/entity-relationship-map.md): 全系统表关系总图 — data plane / control plane / DDB 三层的实体关系,每条边标注类型(硬 FK / 跨库软引用 / 写入时 stamp / 运行时推导);所有"会变的归属关系"的变更策略现状与目标。2026-07-02 会议(Peter)+ codex 审计的落地文档。
- [V1 上线后的长期演进路径](/system-design/multi-tenant/final/migration-plan.md): Final 长期演进路径 — 从 V1 Control Plane / pool_orange_theory 演进到中性 schema、Silo-first、future Pool/Hybrid。
- [Multi-Tenant 架构总览(从这里开始)](/system-design/multi-tenant/overview.md): Multi-tenant 架构总览 — 给团队第一次看的版本。用 3 个客户的故事 + 多图讲清现状、终态、为什么。
- [Multi-Tenant 上 Prod 铺开 Checklist](/system-design/multi-tenant/prod-rollout-checklist.md): Multi-tenant 上 prod 铺开 checklist — 前置条件 + 6 步执行顺序,每步带验证命令。补齐 v1-gaps 缺口 1,正式上 prod 那天按此执行。
- [DB Redesign 需求分析(场景清单 + 查询清单)](/system-design/multi-tenant/redesign-requirements.md): DB redesign 需求分析(6 阶段流程第 1 步)— 23 个业务场景清单 + studio-api 全读路径查询清单 + 6 处口径冲突 + 4 个待答业务问题。配对 entity-relationship-map.md 读。
- [Tenant Onboarding:新客户怎么获得 tenant,存量客户怎么桥接](/system-design/multi-tenant/tenant-onboarding.md): Tenant onboarding 现状实测与 V1 设计 — 新客户 onboard 全程不建 tenant(代码证据),V1 用 admin-led 建档 + 对账 auto-heal 兜底,现有 4 个店主中 3 个待确认/桥接。含 3 个待拍板决策。
- [Multi-Tenant V1 已知缺口与补齐路线](/system-design/multi-tenant/v1-gaps.md): Multi-tenant V1 已知缺口与补齐路线 — 6 个缺口,每条含现状(代码 + 2026-07-01 Neon 实测证据)、风险、怎么做对、退出条件。当前一切在 test,按 pre-launch 优先级排。配对 why-tenant.md 读。
- [为什么 retaintive 需要 Tenant:从 user-store 到 customer boundary 的决策说明](/system-design/multi-tenant/why-tenant.md): 决策说明 — 为什么 retaintive 需要 tenant 层:user-store 是 access model 不是 customer ownership model;行业标准分层、分水岭判据、目标模型各层用法、V1 identity-only 落地口径。
- [Observability](/system-design/observability.md): retaintive 三端 observability stack — frontend Sentry + 自建 session analytics / apps/api Sentry + AWS Lambda Powertools / backend Lambda logger fan-out 到 Lark + Sentry。每个端的 SDK / 上报内容 / cold start / 调试入口 / file:line 来源。
- [电话号码规范化策略](/system-design/phone-normalization-strategy.md): Phone Normalization Strategy — 电话号码 E.164 格式化方案,定义系统统一存储和查询电话号码的标准化格式、实施路径、技术选型(libphonenumber-js)、以及从 DDB 到 Neon 迁移期间的读写策略(dual-read fallback)。
- [Pipeline 全景分析](/system-design/pipeline-architecture-analysis.md): Historical 2026-05 Pipeline 全景审计；问题发现与 shared mutation 方向可参考，旧 Task Deliverable 不再是 Target。
- [RingCentral Call Log、录音就绪与 Rate Limit 调查](/system-design/ringcentral-call-log-readiness-and-rate-limits.md): RingCentral 通话处理调查记录 — Call Log 与 webhook 的职责、录音延迟、重复请求根因、429 retry 边界、reconciliation gap 和 CloudWatch 排障方法
- [Flow 3: Contact Analysis](/system-design/write-matrix/contact-analysis-writes.md): Current legacy Contact Analysis write-path snapshot；旧 taskDecisions/typeCategory/closeResult 仅供追溯，不定义 V3 Target。
- [Lambda 写入矩阵](/system-design/write-matrix/index.md): Lambda 写入矩阵 — 5 个 Lambda (lead-tracking / Per-Call Analysis / Contact Analysis / message-processor / studio-api) 对 Neon 各表的字段级写入职责清单、db.batch() 原子性模式、contacts 字段所有权规则、contact_timeline 事件设计、触发源管理、以及字段清理计划与已知隐患。
- [Flow 1: Lead Tracking](/system-design/write-matrix/lead-tracking-writes.md): Lead tracking 写入流程总览 — 详述 IMAP poller 轮询邮件、UPSERT leads 到 Neon、circuit breaker + SQS DLQ 重试路径、发布 EventBridge LeadCreated 事件、lead-processor Lambda 原子批处理 contacts/tasks/timeline 的完整数据流、字段映射规则、前置条件校验和错误重试机制。
- [Flow 5: Message Processor](/system-design/write-matrix/message-processor-writes.md): Message processor 数据写入矩阵 — Lambda message-processor 通过 SQS 消费 RingCentral SMS/voicemail 事件，原子化写入 messages / contacts / contact_timeline 三表，详细字段映射与 ON CONFLICT 行为。
- [Flow 2: Per-Call Analysis](/system-design/write-matrix/per-call-analysis-writes.md): Per-call analysis 写入矩阵 — 单通通话 AI 分析完成后，向 Neon calls/contacts/contact_timeline 表原子写入 33 个 AI 字段、基础联系人信息、事件记录，并触发 Contact Analysis 重新分析
- [Flow 4: Studio API](/system-design/write-matrix/studio-api-writes.md): Studio API 数据写入矩阵 — 记录员工 UI 操作（关闭 task / 重开 task / 推迟 dueAt）对 Neon 的写入流程，包括已实施的 Close 和 Reopen 端点、未实施的 Postpone 设计，及 contact_timeline/contacts.lastActivityAt 更新的 gap。
- [AI 工具调研清单 — 完整对比](/tooling/research/ai-tooling-inventory.md): 2026-05-29 调研。目标:让 AI 在多 repo 找对信息 + 写代码前知道东西已经有了、不重复造轮子。 每个工具的好坏都查过资料核实(部分来自 GitHub issue、Reddit、G2 真实用户反馈),不是凭印象编的。 这是详细对比;直接看结论去 AI 工具栈选定。
- [DESIGN](/ui-design/DESIGN.md): Gym SaaS design system — AI-powered call analytics + lead tracking + business intelligence
- [霓虹脉动](/ui-design/color-schemes/nihong-maidong.md): 6 色体系 — Primary 紫、Secondary 蓝、Success 绿、Warning 黄、Alert 粉、Surface 浅青。
- [森野暖阳](/ui-design/color-schemes/senye-nuanyang.md): Insighture 暖色调色彩方案 — 常青绿、赤陶红、琥珀金与蜜桃橘。
- [Neutral Monochrome](/ui-design/color-schemes/sumo-liubai.md): shadcn/ui 默认中性色方案 — 黑白灰阶 + 红色警示，支持 Light / Dark 双模式。
- [UI 设计](/ui-design/index.md): UI 设计 — retaintive 的 Design System、色彩方案、UI 原型与改进方案。设计 token、组件规范、配色风格、各版本交互原型。
- [V1.1](/ui-design/ui-prototype/mvp-v1.md)
- [V1.2](/ui-design/ui-prototype/mvp-v2.md)
- [V1.3](/ui-design/ui-prototype/mvp-v3.md)
- [V1.4](/ui-design/ui-prototype/mvp-v4.md)
- [V1.5](/ui-design/ui-prototype/mvp-v5.md)
- [远期规划](/ui-design/ui-prototype/ui-full-plan.md)