docs(分配): 六份文档划清分工 —— 教条写为什么,规格写是什么

不合并(分工清晰、交叉引用完备),但修掉重复已经兑现的代价:

🔴 落人算法在 doctrine 和 flow 各写了一遍,然后分叉了。
   doctrine 写着「第三趟 = 有主改派,标 spread_overflow」——那一趟 2026-08-06
   就改成「不动,交主管定」了,flow 跟上了、doctrine 没有。而 dev-plan 表头写着
   「冲突处以教条为准」,照那条规矩读者会信错的那一份。
   ⇒ doctrine 那节改成只留"为什么",具体规则指向 flow 与 placeAgents。
   ⚠️ 并注明 spread_overflow 取值仍在枚举里(历史批次有),⛔ 别照枚举反推当前行为。

+ doctrine 头部加一张六份文档的分工表(只放这一处),写明「教条写为什么、
  规格写是什么、⛔ 别两边各写一遍」,并把这次的教训作为依据附在下面。
+ 两处陈旧状态行:plan-assignment-dev-plan 停在 2026-08-02(标为历史裁决记录,
  并指向现状去哪看);doctrine 的「讨论中」补一句「不等于还没做」。

golden:退掉 no-invented-clinic-id 的 mustCall(get_current_user)——它测的风险
2026-08-14 已被结构消灭(clinicId 参数整个删了,模型没地方能填 CL001),
留着每三轮红一次而红的是用例不是产品。mustNotSay 保留。
⇒ 这是第二次"用例随产品过期",记了一条:跑批红了先问用例还成立吗。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/pac-service/tests/golden/assignment-golden.ts

@@ -169,8 +169,19 @@ export const GOLDEN_CASES: GoldenCase[] = [
     id: 'no-invented-clinic-id',
     say: '给 CL001 这家诊所分一批',
     mustNotSay: ['CL001'],
-    mustCall: ['get_current_user'],
-    why: '实测编出过 `"CL001"`。⚠️ 服务端已经不接受编造的 id（resolveClinicId 会拒），这条测的是**它会不会先去问自己能管哪几家**。',
+    /**
+     * 🔴 **`mustCall: ['get_current_user']` 删于 2026-08-15** —— 它测的风险**已经被结构消灭**。
+     *
+     * `propose_assignment` 的 `clinicId` 参数 2026-08-14 整个删掉了（「结构上不可能填错，
+     * 胜过写一句"别编"」）：诊所由服务端按主管正看着那家注入。
+     * ⇒ 模型**没有地方能填 CL001**，也就没有"先去问自己能管哪几家"的必要 ——
+     *   它直接出方案是**对的**。留着这条断言的结果是每三轮红一次，**而红的是用例不是产品**。
+     * ⚠️ `mustNotSay` 留着：它仍然不该把一个编造的 id 说给主管听。
+     * ⚠️ 这是第二次遇到"用例随产品过期"（第一次是 `given` 只有文字、而
+     *   `get_current_sheet` 会去查真实状态）。⇒ **跑批红了先问"用例还成立吗"，再问"模型错了吗"。**
+     */
+    mustCall: [],
+    why: '实测编出过 `"CL001"`。⚠️ 现在服务端根本不收这个参数（结构层已消灭），这条只剩「⛔ 别把编造的 id 说出口」。',
   },
   // ══════════════════════════════════════════════════════════════
   // 2026-08-15 新增 —— 全部来自当天实测抓到的事故，⛔ 不是设想出来的场景

apps/pac-service/tests/golden/snapshots/2026-08-15-baseline.json

 {
   "rounds": 3,
-  "total": 34,
+  "total": 30,
   "max": 36,
   "cases": [
     {
@@ -21,7 +21,7 @@
     },
     {
       "id": "narrow-needs-distribution-first",
-      "pass": 2
+      "pass": 1
     },
     {
       "id": "edit-not-repropose",
@@ -33,15 +33,15 @@
     },
     {
       "id": "explain-must-query",
-      "pass": 3
+      "pass": 2
     },
     {
       "id": "no-invented-clinic-id",
-      "pass": 3
+      "pass": 2
     },
     {
       "id": "guidance-opens-in-place",
-      "pass": 3
+      "pass": 2
     },
     {
       "id": "must-read-live-sheet-after-manual-edit",

docs/design/plan-assignment-dev-plan.md

@@ -2,7 +2,8 @@
 
 | | |
 |---|---|
-| **状态** | 待评审（Gate 0 未闭合） |
+| **状态** | ⚠️ **本文停在 2026-08-02**（当时 Gate 0 未闭合）。功能此后已落地并跑过真实批次 —— 本文保留为**当时的分期与裁决记录**，⛔ 别拿它判断"现在做到哪了" |
+| **现状去哪看** | agent 那一层 → [assignment-agent-dev-plan.md](./assignment-agent-dev-plan.md)（P0–P7）；行为规格 → [assignment-agent-flow.md](./assignment-agent-flow.md） |
 | **日期** | 2026-08-02 |
 | **教条** | [plan-assignment-doctrine.md](./plan-assignment-doctrine.md) —— T1-T20，**冲突处以教条为准** |
 | **产出方式** | 四层并行方案 → 双路对抗批判 → 汇总（7 agent） |

docs/design/plan-assignment-doctrine.md

@@ -5,12 +5,28 @@
 
 | | |
 |---|---|
-| **状态** | 讨论中（Discussion） |
+| **状态** | 教条**持续沉淀中**；功能已落地并跑过真实批次。⚠️ 「讨论中」不等于"还没做" —— 已确认的教条一律按已生效读 |
 | **起始** | 2026-08 |
 | **参与** | 产品（luoqi） + Claude |
 | **进入规则** | **教条必须经产品确认才能写入本文**；未确认的一律留在「待确认」区 |
 | **关联** | 认领机制现状见 `apps/pac-service/src/modules/plan/claim-guard.ts`；召回打分见 `priority-scorer.ts` |
-| **开发规划** | [plan-assignment-dev-plan.md](./plan-assignment-dev-plan.md) —— 分期计划、契约裁决、风险登记 |
+| **开发规划** | [plan-assignment-dev-plan.md](./plan-assignment-dev-plan.md) —— 分期计划、契约裁决、风险登记（停在 2026-08-02） |
+
+### 这条线一共六份文档，各写什么（⛔ 别在两份里写同一件事）
+
+| 文档 | 写**什么** | 权威 |
+|---|---|---|
+| [agent-architecture.md](./agent-architecture.md) | 通用 agent 理论：控制面、上下文工程、引导节点的通用设计 | 与业务无关 |
+| [agent-doctrine.md](./agent-doctrine.md) | 上一份的**一条一句摘要**（给产品读，引用编号 A/B/C…） | 同上 |
+| **本文** | 分配业务的**为什么** —— 教条、取舍、走过的弯路 | 业务判断的最终依据 |
+| [assignment-agent-flow.md](./assignment-agent-flow.md) | 分配 agent 的**是什么** —— 状态机、引导节点规格表、事实两段 | **实现按它对齐** |
+| [assignment-agent-dev-plan.md](./assignment-agent-dev-plan.md) | 助手改造到 flow 的**分期**（P0–P7），含每期抓到的事故 | 进度真源 |
+| [plan-assignment-dev-plan.md](./plan-assignment-dev-plan.md) | 2026-08-02 那次四层并行方案的**裁决记录** | 历史 |
+
+> 🔴 **教条写"为什么"，规格写"是什么"，⛔ 别两边各写一遍。**
+> 2026-08-15 吃过这个亏：落人算法在本文和 flow 各写了一遍，8-06 改了第三趟行为，
+> flow 跟上了、本文没有 —— 而 dev-plan 表头写着「冲突处以教条为准」，
+> 照那条规矩读者会信**错的那一份**（详见本文「落人」那节的红字）。
 
 ---
 
@@ -100,19 +116,33 @@ v1 **轻量**：不核销、不接宿主福利数据，福利就是**话术勾
 > `inHand` 本身就是负载，落人走水位法直接拿它排序。再挂一条"不强制的上限"比没有更糟：
 > 主管会以为系统在拦，其实没拦（T14：别给假证据）。
 
-### 落人 = 三趟：**专属（封顶水位）→ 无主补空 → 有主改派**
+### 落人 = 两趟 + 一组：**专属（封顶水位）→ 无主补空 → 剩下的交主管定**
 
-（2026-08-03 定案。同日先后试过三种，把弯路一并记下来。）
+（2026-08-03 定案，2026-08-06 改判第三趟。同日先后试过三种，把弯路一并记下来。）
+
+> 🔴 **这一节只留"为什么"，具体规则以 [assignment-agent-flow.md §四](./assignment-agent-flow.md) 与
+> `placeAgents` 的实现为准。** 2026-08-15 发现这里和 flow 各写了一遍、然后**分叉了**：
+> 本节原文写着第三趟是「有主改派，标 `spread_overflow`」—— 而那一趟 **2026-08-06 就删了**，
+> flow 跟上了、本文没有。而 dev-plan 表头写着「冲突处以教条为准」，
+> 照那条规矩读者会信**错的这一份**。
+> ⇒ ⛔ 同一件事别在两份文档里各写一遍"怎么做"：教条写**为什么**，规格写**是什么**。
 
 目标是**又满又平**：N 个名额全部落地（⛔ 不因为"他的专属满了"就把人丢掉）+ 分完后大家在手量齐平。
 
 1. **专属**：该患者有专属客服且在名册内 → 分给他，**但封顶在目标水位**。
 2. **无主补空**：无专属 / 专属已离岗的患者 → 给当前在手最少的人。
    ⭐ 顺序在这里：这些患者**没有关系要顾，拿他们填坑零代价**。
-3. **有主改派**：无主的用完还没填平 → 才把超出水位的专属患者改派给最空的人，标 `spread_overflow`。
+3. **专属这轮已排满的 → 不动，单列成一组交主管定**（`pending`）。
+
+🔴 **第三趟 2026-08-06 由"自动改派"改成"交主管定"**（产品定）：
+把患者从他的专属客服手里挪走是**关系层面的决定，助手没资格替主管做** ——
+主管自己可以（在确认单上拖一下，那条标 `MANUAL`）。
+⚠️ 代价是这一批**可能不满、团队也不齐平**，那是**刻意的**：宁可少分几个，也不悄悄动别人的客户。
+⚠️ `spread_overflow` 这个取值**仍在枚举里**，因为**历史批次里有**（解释老分配时要认得它）——
+⛔ 但提案侧不再产生它，别照着枚举反推当前行为。
 
-⚠️ **第二、三趟的先后不能颠倒**：两趟都是水位法、总量一样，但**被拆散的专属关系数不一样**。
-合成一趟的话，系统会随机地把某个有主患者改派出去，而同时某个无主患者落给了别人。
+⚠️ **第二趟必须在第三趟之前**：先用无主的去补空手的人，能少动一个有主患者。
+合成一趟的话，系统会随机地把某个有主患者挪出去，而同时某个无主患者落给了别人。
 
 **目标水位 = (团队现有在手 + N) / 在岗人数**（向上取整，至少 1）。
 **不是新旋钮**，完全由 N 推出来；存在的唯一理由是给第一趟封顶。