> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

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

> **状态说明（2026-07-23）**：本文记录 2026-07-17 的 point-in-time 候选判断，不代表 Task V3 已 finalized。当前实施方向以 [Task V2 → Task V2+ → Task V3 工程审计与实施基线](/product-design/v2/tasks-feature/task-v2-plus-engineering-audit.md) 为准。

> 用户给出的 scope："我们不要增加 scope，我们只是说 notification 未来可能做。现在我们只需要看看我们目前的代码 ok 不。"
>
> 判断顺序："先看 high-level 的 design 方向对不对，然后再细看代码。"

本文评估 [Task V3 Target Design Proposal](/product-design/v3/tasks-feature/task-domain-lifecycle.md) 和未来能力边界。它不覆盖 Task V2 当前产品行为，不授权 V3 implementation/cutover，也不宣称 Notification、RingOut、Scripts 已进入当前实施范围。

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

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

```text
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：

```text
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，只需要把它渲染成业务动作：

| Typed effect                           | 前端动作                              |
| -------------------------------------- | --------------------------------- |
| `changeNextAction`                     | `Set as next action`              |
| `recordBusinessProgress(intro_booked)` | `Confirm booking`                 |
| `closeTask(...)`                       | `Review outcome`，打开预填的 close form |

员工执行该动作本身就是 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：

```ts
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 应尽量接近：

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

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

而不是：

```text
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 的修复。