# Full Business Structuring And Conversation Baseline Design

## 1. Purpose

这份 spec 的目标不是继续给 PMFlow 的问答/执行链路补局部规则，而是把当前 runtime 升级成一套**全量业务结构化**基线：

- 让系统真正理解“当前在围绕哪个业务对象、以什么目标、需要什么回答形状”
- 让 `status / recommendation / draft / execute` 四挡真正独立、可停住、可纠错、可升级
- 让 recommendation 不再只是“给人看的文本”，而是能继续承接澄清、改写、写入与确认的结构化业务对象
- 让 casual chat / greeting 也进入统一结构，而不是继续靠散落的口水词表和轻量快捷回复分支

这份设计建立在已有 `InteractionBoundaryPacket / AnswerControlDecision / unified project AI handoff` 方向之上，但范围更大：它不只处理“不要越权”，还要处理“系统到底有没有全量理解这个业务系统”。

## 2. Problem Statement

当前 PMFlow 已经把协议层和部分上下文层结构化了一部分，但仍没有把**业务系统本体**全量结构化。实际表现就是：

1. 系统能识别“这一轮是 recommendation、不要 draft”，但识别不到“围绕当前项目推荐外部信号源候选”这类更深层业务意图。
2. recommendation 只产出了文本，没有产出后续可引用、可确认、可写入的业务候选集合。
3. 澄清和纠错主要还停留在 `pending_clarification / session_state` 层，没有真正更新业务结构真源。
4. 非 `plan mode` 的写入动作还在默认往 `draft_pending_confirm` 走，而不是走 operational write 主链。
5. casual chat / greeting 仍混在本地 lexical/shortcut 分支里，没有纳入统一语义规划层。

这导致系统在真实业务链里会出现连续错位，而不是单点失误。

## 3. Canonical Failure Chain To Fix

当前最典型、必须打穿的主反例链如下。

### 3.1 Real user intent

用户先拿到一轮信号源 recommendation，然后继续说：

- `感觉不错，写入系统内的信号源吧。`
- `我让你把推荐的信号源写入系统`
- `已经不用查询内部对象了，现在要你把这些外部信号源加入项目里`
- `确认入库`

### 3.2 Actual broken behavior

当前 live 链路的错误表现是：

1. recommendation 本身只变成了正文，没有形成可回溯候选集合
2. 后续“写入系统”被重新当成普通问答解析
3. 又走了一轮“内部对象不清 / target_resolution”式澄清
4. 纠正后又掉进 `signal_source.onboard -> draft_pending_confirm`
5. `确认入库` 没有命中上一轮 pending write object，而是又被当成新问句解析，最后答到完全不相干的内部配置/引擎信息上

### 3.3 Root cause

这不是 recommendation presenter 单点问题，而是当前系统同时缺了下面 4 层：

- 围绕业务对象的完整 `BusinessSemanticFrame`
- recommendation 输出后的 `RecommendationCandidateSet`
- clarification/correction 到结构化真源的 delta 写回
- 非 `plan mode` 下的 direct operational write 主链

## 4. Non-Negotiable Baseline

下面这些是这次设计的**硬基线**，实现时不得违反。

### 4.1 No hard semantics for business decisions

全套业务语义拍板里：

- 不准用中文关键词仓
- 不准用英文关键词仓
- 不准用中文正则/英文正则去拍板业务语义
- 不准在运行时代码里恢复 `looks_like_*`、`*_KEYWORDS`、`*_HINTS`、`*_regex` 这类业务裁决器

这条硬约束覆盖：

- `status / recommendation / draft / execute` 分挡
- internal vs external vs hybrid 路由
- recommendation vs inventory vs impact-jump 判断
- 新项目 / 新业务 / 新线程识别
- clarification / correction 更新
- casual chat / greeting 识别
- signal source recommendation / prepare_write / confirm_write / execute_write 跳转

允许保留的 deterministic 逻辑，只能是**非语义型**：

- `reply/thread/work_item_id/source_message_id` 等强锚点
- schema 校验
- 幂等键和去重
- 文本 hygiene（去空白、去 code fence、句尾清理）
- 结构化 payload 的必填字段校验

### 4.2 Explicit anchors beat memory

显式 `reply/thread`、卡片动作、`work_item_id`、上一轮 recommendation candidate set 绑定，优先级必须高于：

- 旧 session
- 旧 last_subject
- 旧 pending clarification
- 旧 topic / work item 同 scope 模糊回捞

### 4.3 Non-planmode write does not default to draft

只要当前不在 `plan mode`：

- `signal source` 写入动作默认不出 requirement draft
- recommendation 后的“写入系统 / 加入项目 / 确认入库”默认走 operational write 主链
- 只有两种情况允许出 draft：
  - 用户显式说“先出草稿”
  - 当前线程已经明确处于 `plan mode`

### 4.4 Every turn must remain correctable

每一挡都必须支持：

- `澄清`
- `纠错`
- `再次思考 / 自检`
- `显式升级 / 降级`

系统目标不是“一次就猜对”，而是“不越权 + 可纠错 + 可停住”。

## 5. Existing Structured Layers vs Missing Layers

当前仓库已经做好的结构层有：

- `InteractionBoundaryPacket / AnswerControlDecision`
- `ProjectOperatingContext / ProjectFitBrief / ExecutionRecipe`
- `analysis_packet` / `ExternalQueryPlan` / `SignalSourceRecommendationPacket`

但真正缺的，是下面这些业务本体层。

| Layer | Current state | Missing truth | User-visible symptom |
| --- | --- | --- | --- |
| Interaction boundary | Partially structured | still not connected to deeper business frame | 能识别“不要 draft”，但不能稳定识别“我要推荐外部信号源候选” |
| Query semantics | coarse `query_type/subject_focus` | no business goal frame | recommendation 被吞成 internal list / inventory |
| Recommendation output | mostly presentational | no durable candidate set | 后续“把推荐的写入系统”无法引用上一轮对象 |
| Clarification/correction | session-oriented | no structural delta | 纠正后仍容易带旧结论继续跑 |
| Operation contract | draft/write still mixed | no direct write phases outside plan mode | 非 `plan mode` 还在默认 `draft_pending_confirm` |
| Casual chat | local shortcuts | no structured ambient-chat posture | 打招呼和业务链互相污染 |

## 6. Target Runtime Model

这次建议把 runtime 收成 6 层，并且每层只做一件事。

```mermaid
flowchart TD
    A["User Message"] --> B["InteractionBoundaryPacket"]
    B --> C["BusinessSemanticFrame"]
    C --> D["AnswerShapeContract"]
    D --> E["RecommendationCandidateSet / OperationIntentContract"]
    E --> F["SelfReviewResult"]
    F --> G["Presenter / Executor"]
```

### 6.1 InteractionBoundaryPacket

职责：

- 识别这一轮最高允许做到哪一挡
- 哪几挡被禁止
- 是否允许写
- 是否需要先澄清

这层继续存在，但不再承担“理解业务对象是什么”的职责。

### 6.2 BusinessSemanticFrame

这是这次新增的业务真源层，也是全量结构化的核心。

建议字段：

- `goal_kind`
  - `status_lookup`
  - `recommendation`
  - `impact_judgment`
  - `bounded_explanation`
  - `prepare_write`
  - `confirm_write`
  - `execute_write`
  - `drafting`
  - `clarify`
  - `casual_chat`
  - `mixed`
- `target_scope`
  - `current_project`
  - `explicit_project`
  - `thread_context`
  - `global`
- `resource_role`
  - `signal_source`
  - `external_input`
  - `project_object`
  - `task`
  - `signal`
  - `config`
  - `people`
  - `none`
- `source_kind`
  - `internal`
  - `external`
  - `hybrid`
  - `none`
- `expected_answer_shape`
  - `inventory`
  - `ranked_candidates`
  - `impact_chain`
  - `bounded_explanation`
  - `clarify_prompt`
  - `write_confirmation`
  - `write_result`
  - `social_reply`
- `conversation_posture`
  - `business_operating`
  - `ambient_chat`
  - `mixed`
- bindings
  - `project_binding`
  - `subject_binding`
  - `object_binding`
  - `candidate_set_binding`

这层的目标不是打一个粗标签，而是让 planner 真的理解：

- 围绕哪个项目
- 在问什么业务目标
- 对象在业务里扮演什么角色
- 用户期待的回答形状是什么

### 6.3 AnswerShapeContract

这一层单独存在，避免 route/gateway 和 presenter 各自脑补回答形状。

建议枚举：

- `inventory`
- `ranked_candidates`
- `impact_chain`
- `bounded_explanation`
- `clarify_prompt`
- `write_confirmation`
- `write_result`
- `social_reply`

关键规则：

- `status` 不能被答成 recommendation
- `recommendation` 不能被答成 inventory
- `prepare_write` 不能被答成 draft
- `confirm_write` 不能掉回普通 QA

### 6.4 RecommendationCandidateSet

这层是 recommendation 能继续工作的关键。

当前 recommendation 的最大缺陷是“只有文本，没有结构对象”。这次必须补成可持久化的候选集合。

建议结构：

- `candidate_set_id`
- `project_binding`
- `resource_role = signal_source`
- `source_kind`
- `evidence_mode`
- `candidates[]`
  - `candidate_ref`
  - `display_name`
  - `business_value`
  - `why_now`
  - `materialization_payload`
  - `source_origin`
  - `candidate_rank`

用法：

- recommendation 回答给用户看
- 同时把候选集合持久化到当前 `reply/thread/work_item`
- 后续用户说：
  - `把推荐的写入系统`
  - `把第一个加进去`
  - `确认入库`
  不需要重新猜，而是通过锚点 + candidate_set 继续操作

### 6.5 ClarificationDelta / CorrectionDelta

澄清和纠错必须更新结构化真源，不只是更新聊天状态。

要更新的字段包括：

- `goal_kind`
- `resource_role`
- `source_kind`
- `expected_answer_shape`
- `project_binding`
- `candidate_set_binding`
- `action_ceiling`

例如：

- `不是现状，我要推荐`
- `不是内部对象，我要外部信号源`
- `不是这个项目，是 AI客服`
- `别起草，现在直接写入`

这些都必须变成对 frame 的结构化 delta，而不是只在 session 里记一句“用户已澄清”。

### 6.6 OperationIntentContract

这层把 recommendation / draft / direct write 真正拆开。

建议拆成：

- `recommendation`
- `prepare_write`
- `confirm_write`
- `execute_write`
- `drafting`

规则：

- `recommendation` 只出候选和理由
- `prepare_write` 表示用户已经决定往写链走，但系统还要回显对象和影响
- `confirm_write` 明确回显即将写入哪些对象、写到哪个项目
- `execute_write` 才是真正方法调用
- `drafting` 只在 `plan mode` 或显式“先出草稿”时进入

## 7. Clarification And Correction Must Update Structure

这是这次设计里最容易被实现层偷懒的点，所以单独拉出来。

### 7.1 What is not enough

下面这些都不够：

- 只更新 `pending_clarification`
- 只更新 `last_subject`
- 只把“不是这个项目”记进 session history
- 文本上说“我知道了”，但 route / frame / answer shape 没变

### 7.2 Required behavior

当用户澄清或纠错后：

1. 生成 `ClarificationDelta / CorrectionDelta`
2. 重算 `BusinessSemanticFrame`
3. 再重算 `AnswerShapeContract`
4. 必要时重建 `RecommendationCandidateSet` 或 `OperationIntentContract`
5. 最后再决定 route / presenter / executor

### 7.3 User-visible contract

纠错之后，回答里要明确承认：

- `现在按你刚才纠正的口径重算`

而不是继续拿旧 frame 扩写。

## 8. Non-Planmode Direct Signal-Source Write

这是这次设计的另一个硬基线。

### 8.1 Why current behavior is wrong

当前非 `plan mode` 下，用户说：

- `把推荐的写入系统`
- `把这些外部信号源加入项目里`
- `确认入库`

系统仍然容易走：

- `signal_source.onboard -> draft_pending_confirm`

这违背了当前产品预期：用户并不是在收需求，而是在做运营式写入动作。

### 8.2 Required path

非 `plan mode` 的 signal-source 写入必须走：

1. `recommendation`
2. `prepare_write`
3. `confirm_write`
4. `execute_write`

只有在下面两种情况，才允许走 `draft_pending_confirm`：

- 用户显式说：
  - `先出草稿`
  - `帮我整理成一版方案`
  - `进 plan mode`
- 当前线程已经明确处于 `plan mode`

### 8.3 prepare_write contract

`prepare_write` 必须：

- 绑定项目
- 绑定候选集合
- 回显将写入哪些对象
- 明确这是“准备写入”，不是普通问答，也不是 requirement draft

### 8.4 confirm_write contract

`confirm_write` 必须：

- 指向明确候选对象
- 指向明确项目
- 告知将调用的操作类型
- 告知新增/复用/更新语义

### 8.5 execute_write contract

只有显式确认后才能 `execute_write`。

一旦执行：

- 必须有幂等键
- 必须有写入结果回显
- 必须能和之前的 candidate set / confirm object 对上

## 9. Casual Chat / Greeting Must Join The Same Structure

用户已经明确要求：打招呼、口水聊天也要接入。

但这不意味着 PMFlow 变成泛化聊天产品。

### 9.1 Required posture

建议在 `BusinessSemanticFrame` 里引入：

- `goal_kind = casual_chat`
- `conversation_posture = ambient_chat`
- `expected_answer_shape = social_reply`

### 9.2 Benefits

这样做的好处：

- casual chat 不再依赖本地词面快捷回复
- 不会继续污染业务链
- 一旦用户切回业务：
  - `还是回到自动开票系统`
  - `刚才那组候选继续`
  能重新绑定到业务 frame

## 10. Required Code Changes

这次不是一两个文件补丁，而是一次结构升级。

### 10.1 Semantic truth layer

需要改动：

- `backend/app/services/ai_pmo/semantic_context/decision_schema.py`
- 新增 `backend/app/services/ai_pmo/semantic_context/business_frame_schema.py`
- `backend/app/services/ai_pmo/semantic_context/packet_schema.py`
- `backend/app/services/ai_pmo/semantic_context/semantic_decision_service.py`
- `backend/app/services/ai_pmo/workflow_semantic_planner/service.py`

目标：

- 让 planner 一次产出：
  - `InteractionBoundaryPacket`
  - `BusinessSemanticFrame`
  - `AnswerShapeContract`
  - `OperationIntentContract`

### 10.2 Mainline route / fast path cleanup

需要改动：

- `backend/app/services/adaptive_rag_service/mixin_query_route_gateway.py`
- `backend/app/services/adaptive_rag_service/mixin_core_intent.py`
- `backend/app/services/adaptive_rag_service/mixin_fast_answer_project_main.py`
- `backend/app/services/ai_pmo/ai_pmo_typed_executor_execute/mixin_execute_query_project.py`

目标：

- 不再让 coarse `query_type=list/status/explain` 直接吞业务问题
- 清掉 lexical/regex 语义快捷分支
- 让 route/gateway 只消费结构化业务 frame

### 10.3 Clarification / correction

需要改动：

- `backend/app/services/adaptive_rag_service/mixin_session_state.py`
- `backend/app/services/adaptive_rag_service/mixin_followup_anchor.py`

目标：

- clarification/correction 更新结构化 frame
- 新项目 / 新业务 / 新层级切换时重建 frame
- follow-up 不再只靠 session state

### 10.4 Recommendation and signal-source write

需要改动：

- `backend/app/services/external_query_service/schemas.py`
- `backend/app/services/external_query_service/planner.py`
- `backend/app/services/external_query_service/presenter.py`
- `backend/app/services/ai_pmo/ai_pmo_typed_executor_execute/mixin_execute_signal_source.py`

目标：

- recommendation 产出 `RecommendationCandidateSet`
- non-planmode 走 `prepare_write / confirm_write / execute_write`
- 只有 `plan mode` 或显式草稿请求才走 `draft_pending_confirm`

## 11. Broad Scenario Matrix

这次不能再只做 12 条黄金样例。基线升级为**58 条广覆盖业务语义问题**，覆盖业务、澄清、闲聊、写入、确认。

### 11.1 Greeting / ambient chat（6）

1. `早上好，你在线吗？`
2. `今天先不推进需求，聊两句。`
3. `你先别那么严肃。`
4. `我有点烦，先陪我理一理。`
5. `先不说系统，随便聊两句。`
6. `你现在忙吗？`

### 11.2 Status / current-state（6）

7. `自动开票系统现在主要靠哪些数据在跑？`
8. `AI客服这个项目当前已经在用哪些数据？`
9. `门店库存异常日报助手现在是谁接收异常？`
10. `确认立项现在 assignee 推荐做到哪了？`
11. `直播复盘辅助工具当前主要依赖什么输入？`
12. `测试产能警告现在有没有成型信号源？`

### 11.3 Recommendation / external signal-source candidates（8）

13. `自动开票系统如果想更早发现票开不出去，最该先盯哪几类外部信号？`
14. `AI客服这个项目除了现在这些数据，还值得补哪些外部线索？`
15. `门店库存异常日报助手如果要更早发现问题，先看哪几类外部信号最值？`
16. `直播复盘工具除了录屏和评论，还该盯什么外部线索？`
17. `测试产能警告除了内部数据，还该看什么外部信号？`
18. `采购经理库存项目外面还有哪些信号值得加进来？`
19. `如果只给建议，不出草稿，你会推荐哪些外部信号源？`
20. `你按业务优先级排一下要补的外部信号。`

### 11.4 Impact judgment（6）

21. `税控平台状态波动，会不会直接影响自动开票系统？`
22. `WMS接口变更，会先打到哪一步？`
23. `评论流异常，会不会先影响直播复盘？`
24. `政策更新会先影响开票校验还是发送环节？`
25. `供应商接口延迟，会不会先影响采购经理库存日报？`
26. `门店上报延迟会先影响哪条业务链？`

### 11.5 Clarification（6）

27. `不是现状，我要推荐。`
28. `不是内部对象，我要外部线索。`
29. `我说的不是这个项目。`
30. `不是问配置，是问信号源。`
31. `你先别起草，我只要建议。`
32. `我要的是写入，不是继续分析。`

### 11.6 Correction / reframing（6）

33. `不是自动开票，是 AI客服。`
34. `不是第一个，写第二个。`
35. `刚才方向不对，换成现状回答。`
36. `刚才不要草稿，现在可以起草。`
37. `刚才是建议，现在直接写入。`
38. `不是这三个候选，按门店库存那组来。`

### 11.7 Recommendation -> non-plan write（6）

39. `把你刚推荐的这几个信号源写进项目。`
40. `把第一个加进去。`
41. `就按刚才那三类，加入系统。`
42. `不要出草稿，直接按刚推荐的候选准备写入。`
43. `先回显你准备写哪几个。`
44. `确认把这几个加进来。`

### 11.8 Plan mode / explicit drafting（4）

45. `先给我起一版信号源接入草稿。`
46. `这次进 plan mode，把外部信号接入方案整理成草稿。`
47. `先别执行，只出草稿。`
48. `把这几个候选扩成正式需求草稿。`

### 11.9 Confirm / execute（4）

49. `确认入库。`
50. `确认写入第一个。`
51. `确认执行这次接入。`
52. `就按你回显的对象执行。`

### 11.10 Sparse / mixed / edge（6）

53. `这个项目最容易卡在哪一步？`
54. `你按业务同事口吻说，不要系统话。`
55. `先别推进执行，我就想知道今天最可能先从哪暴露问题。`
56. `如果今天要先做最小版，你觉得先盯哪个外部信号最值？`
57. `我现在只想轻松聊两句，等会儿再回业务。`
58. `从聊天切回自动开票系统，刚才那组候选继续。`

## 12. Scoring Rubric

这次每个 case 不是看平均分，而是看**每一项都 > 9**。

### 12.1 Dimensions

每条 case 至少按下面 6 个维度评分：

1. `Semantic frame correctness`
   - 目标、对象、来源、回答形状识别是否正确
2. `Boundary correctness`
   - 没有越权，没偷偷升挡
3. `Business binding`
   - 项目、对象、候选集合绑定是否正确
4. `Clarification / correction fidelity`
   - 用户纠正后是否真的重算结构
5. `Answer naturalness`
   - 回复是否业务化、自然、像同事，而不是架构师/系统提示词
6. `Safety / no irrelevant drift`
   - 不答非所问，不掉进无关 internal fast path，不泄漏内部术语

### 12.2 Pass rule

任一 case 只要有任一维度 `< 9.0`，直接判失败。

不允许：

- 用综合均分掩盖单项缺口
- 用“主链绿了”掩盖 recommendation / correction / greeting 失真

## 13. Expected User-Visible Behaviors

如果这版设计落地正确，用户应该能看到这些变化：

1. `推荐外部信号源` 不再掉成 `当前项目列表如下`
2. recommendation 后续可以直接说：
   - `把第一个加进去`
   - `确认入库`
   系统不会重新猜，也不会答偏
3. 非 `plan mode` 下，默认不会再先出 draft
4. 用户一句：
   - `不是这个项目`
   - `不是现状，我要推荐`
   - `别起草，直接写`
   系统会真改结构，不只是嘴上承认
5. casual chat / greeting 可以自然接入，也能自然切回业务

## 14. Rollout Order

推荐分四步落地：

1. 先补 `BusinessSemanticFrame / AnswerShapeContract / OperationIntentContract`
2. 再补 `RecommendationCandidateSet`
3. 再把 clarification/correction 改成 structural delta
4. 最后清掉 fast path / lightweight chat / lexical semantic shortcuts

每一步都要伴随矩阵级测试扩展，不能只靠单条回归。

## 15. Out Of Scope For This Spec

这份 spec 先不包含：

- requirement-plan 本体重写
- signal-source domain orchestration 业务逻辑重构
- generic chatbot 产品化
- 前端视觉大改版

这份 spec 的边界是：**先把 PMFlow 的问答、推荐、澄清、写入、确认和闲聊纳入一套完整、无硬语义、可纠错的业务结构真源。**