#Task V3 高层设计评估（Historical Candidate）

状态说明（2026-07-23）：本文记录 2026-07-17 的 point-in-time 候选判断，不代表 Task V3 已 finalized。当前实施方向以 Task V2 → Task V2+ → Task V3 工程审计与实施基线 为准。

用户给出的 scope："我们不要增加 scope，我们只是说 notification 未来可能做。现在我们只需要看看我们目前的代码 ok 不。"

判断顺序："先看 high-level 的 design 方向对不对，然后再细看代码。"

本文评估 Task V3 Target Design Proposal 和未来能力边界。它不覆盖 Task V2 当前产品行为，不授权 V3 implementation/cutover，也不宣称 Notification、RingOut、Scripts 已进入当前实施范围。

#1. End state：我们真正要构建什么

retaintive 的核心不是让员工维护更多流程，而是把真实 communication 中的 revenue opportunity 翻译成一条低摩擦执行链：

Evidence / opportunity
  → Task：要解决到底的业务目标
  → Next Action：当前已经采用、现在要做的唯一下一步
  → Activity：员工或系统实际做过什么
  → Business Progress：发生了哪些非终局业务事实
  → Outcome：目标最后怎么样、为什么停止

会议原始 transcript 反复强调两个产品约束：

1. 价值来自更快捕获 revenue opportunity，并让员工更容易行动，而不是让员工多维护 A/B/C/D 步骤。
2. 员工不应先打开多个系统、查面板、阅读一堆上下文，再开始一次简单 Call；系统应把明确的 Next Action 和必要的 Script 直接送到他面前。

因此，以下概念值得作为候选原则继续评估；是否进入 Task V2+ 或未来 Task V3，仍要逐项证明必要性和 parity：

• Task 是长期 Objective，不是一条 notification、一次电话或一张审批单。
• Next Action 是当前采用的计划，不是 AI 生成的所有可能建议。
• Activity 是不可变的执行事实，不是 Task state。
• Business Progress 与 terminal Outcome 分开；intro_booked、intro_attended 不等于 conversion。
• Task 主状态保持 open / closed；Needs attention / Scheduled 等是 projection。
• AI 只能产生 proposal 或在 Policy 授权范围内行动；真正的 mutation 由 deterministic code 校验、执行并记账。
• 不引入 rigid Steps，也不建立所有 Task 共用的 approval stage。

#2. Scenario validation：长期方向怎样与 Task V3 配套

#2.1 Notification

Notification 是 Task/Next Action projection 的消费者，不是新的 domain state。

它可以读取：

• nextActionAt
• first-response SLA projection
• priority / assignee
• evidence 摘要

Notification 自己的 queued / delivered / acknowledged / snoozed 属于 delivery 系统，不进入 Task lifecycle。员工没点 notification，不代表 Task 进入一个新的业务状态。

当前 scope 只需要确认这个边界，不实现 notification。

#2.2 RingOut / Quick Connect

RingOut 是执行 Next Action 的 adapter：

Task detail / notification
  → [Call]
  → controlled RingCentral execution
  → provider-confirmed result
  → Activity
  → evidence triggers next projection/reasoning

ringing / connected / no_answer / voicemail 是 Call/Activity 事实，不是 Task state。RingOut 不能绕过 DNC、store/contact scope 或 audit，也不能让 AI 直接调用外部电话 API。

#2.3 Scripts 与 Coaching

Scripts 是独立、可版本化、可按场景或门店定制的 guidance/content：

• 可以根据 Task kind、Next Action 和 scenario 选择内容。
• 可以直接显示在 Call 旁边，减少员工切换页面的 friction。
• 可以被员工复制、隐藏、评价或替换。
• 不能改变 Task state，也没有 progress/close authority。

Scripts 不应被建模为 rigid Task Steps。会议中的长期方向是“员工打开即可看、可以直接打”，不是“先逐步勾完 Script 才能继续”。

Coaching 同理：它是练习和指导，不是 Task mutation，也不需要 Accept。

#2.4 Staff confirmation 与 staff input

必须区分两类情况：

#A. 已经知道要做什么，但 AI 没有 authority

这是 needs_staff_confirmation。系统已有完整 typed command，只需要把它渲染成业务动作：

员工执行该动作本身就是 adoption。页面不再先显示一个通用 Accept AI decision，然后让员工再执行第二次。

#B. AI 无法形成安全、具体的 proposal

这是 staff_input_required，只用于确实缺少 human-only input 的少数情况：

• Contact identity 真冲突。
• 两条强 evidence 互相矛盾。
• 系统看不到的线下事实必须由员工确认。

它不是 Task status，不是普通 Task 必经步骤，也不能用于 model timeout、schema error、低置信度或工程故障。员工即使看不到/不处理这张 contextual card，Task lifecycle 也不会进入一个新的 “waiting for approval” 状态。

推荐的 typed shape：

type StaffInputRequest = {
  reasonCode: 'identity_ambiguous' | 'conflicting_evidence' | 'offline_fact_required';
  taskRef?: string;
  question: string;
  evidenceRefs: [TaskEvidencePointer, ...TaskEvidencePointer[]];
  expiresAt: string;
};

如果 AI 已经知道具体 command，就必须走 proposal → Guard，而不是同时生成 StaffInputRequest。

#2.5 员工日常界面应该是什么

普通 lead flow 应尽量接近：

Sarah · New Lead
Next action: Call now
Why: New email lead at 10:02
[Call] [Text]

Script
“Hi Sarah, I saw you asked about ...”

而不是：

Needs Staff Review
[Accept AI decision]
[Approve task]
[Open task]
[Call]

Task detail 的最短闭环保持三块：行动区、Record activity + plan、Timeline。只有 effect-specific 的 terminal/high-risk action 才打开确认表单。

#3. Current vs gap

截至 2026-07-17，Current Workbench 已有：

• Needs attention / Scheduled / Closed queue projection。
• Task detail 中的 Call、Text、assignee、Update Task、Close Task。
• Activity、next-action time、deadline 等 mutation form。
• text-only AI suggestions 和 feedback。

但它还不是上面的 Target：

• 第一条 AI suggestion 仍可能被前端当成 “What to do”，没有 adopted nextActionText contract。
• 其余 suggestions 被展示成 numbered Steps，容易重新引入 rigid workflow 心智。
• Call/Text 目前是浏览器 link，不是受控 RingCentral execution，也不自动产生 Activity。
• close UI 仍使用 Task V2 global result vocabulary，不是 Policy-specific Outcome。
• 没有 typed TaskProposal / staff_input_required reader、API 或 UI。
• request_human_review 当前只有一个 disposition 字符串，没有 reason、question、evidence 或 response effect。

这些 gap 说明当前前端没有“多加了一道 review step”；真实问题是它还没有把 review/confirmation 建模成可执行的业务 effect。

#4. Design guardrails 与实施顺序

#4.1 不可破坏的边界

• Notification delivery state 不进入 Task state。
• RingOut provider state 不进入 Task state；结果写 Activity。
• Scripts/Coaching 不获得 mutation authority。
• 没有通用 Approve/Accept gate。
• staff_input_required 只在员工确实能补充关键事实时出现。
• hallucinated/cross-store/invalid evidence 走 reject + audit/engineering observability，不转嫁成员工 review。
• DNC 是 deterministic hard guard，不是可由普通员工点击绕过的 confirmation。

#4.2 当前实施范围

当前只完成 Task V3 最短闭环和 safety floor：

1. lead_conversion Managed Policy。
2. intro_booked progress。
3. 清楚并持久化的 Next Action。
4. RingCentral/员工 Activity ledger。
5. staff-confirmed Outcome。
6. store isolation、DNC、idempotency、evidence binding、audit、human-wins。

Notification、RingOut 产品化、Scripts customization 和 Coaching enhancement 均为 future consumers，不进入本轮代码 scope。

#4.3 仍需产品决定，但不阻塞 safety 修复

• staff_input_required 在 Workbench 中采用 inline card、detail banner 还是独立 filter projection。
• email-only/no-phone Contact 的 canonical subject identity。
• 不同 Task kind 的 Script ownership、versioning 与 store customization。
• production rollout 的绝对 accuracy/staff-burden thresholds。

这些决定不能阻塞 server-derived scope、DNC、claim-specific evidence、atomicity 和诚实 eval 的修复。