docs(integration): FRIDAY 推送契约补齐 — 品牌主档 source、诊所名列、语义澄清记录

对齐 2026-07-20 的新落地内容:
- 新增 §2 `tenant_info` 品牌主档 source(品牌 GUID→中文名;PAC 靠它避免前端显示 GUID),
  source 总数 15→16
- `med_emr_info` / `med_check` 补 `organization_name` 列(诊所展示名来源;此前导出漏列,
  导致工作台诊所显示 GUID)
- 补回丢失的 §7:改为「语义澄清记录」——时间口径/金额/两套关系枚举/treat vs dispose/
  结算 status 全 9 值 + 为何不收 7/8,逐条附源码或数据依据;另列三条推送方留意事项
  (organization_name 仅覆盖有病历的诊所、字典表全量重推、测试环境沙盒数据待生产校准)

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

apps/pac-docs/content/docs/integration/friday-push-payload.mdx

 ---
 title: FRIDAY 推送数据契约
-description: FRIDAY SaaS 按形态 A 推送的 15 个 source 及字段定义;与已验证的存量导出形状一致,push 无缝衔接。
+description: FRIDAY SaaS 按形态 A 推送的 16 个 source 及字段定义;与已验证的存量导出形状一致,push 无缝衔接。
 icon: FileJson
 ---
 
@@ -31,7 +31,7 @@ icon: FileJson
 
 ---
 
-## 2. 患者与关系(3 个 source)
+## 2. 患者与关系(4 个 source)
 
 ### `customer_basic_info` — 患者主档
 
@@ -62,6 +62,17 @@ icon: FileJson
 | `tel_type` | string/number | | 号码类型 |
 | `relationship` | string/number | | 持号人与患者的关系(官方枚举 `PhoneRelationshipEnum`:`1`本人 `2`爸爸 `3`妈妈 `4`爷爷 `5`奶奶 `6`朋友 `7`配偶 `8`子女 `9`其他) |
 
+### `tenant_info` — 品牌主档(低频;变更时全量重推)
+
+> 品牌展示名来源。PAC 侧 `source_unit` 存的是品牌 GUID(宿主原生 `tenant_id`),
+> 靠本表派生出中文名下发前端(否则工作台只能显示 GUID)。
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|---|---|
+| `tenant_id` | string | ✅ | 品牌 GUID(= 各业务表的 `tenant_id`) |
+| `name` | string | ✅ | 品牌名称(如"济南瑞泰济东口腔医院") |
+| `name_ab` | string | | 品牌缩写 |
+
 ### `customer_referee_circle` — 转介绍圈(患者-患者关系)
 
 | 字段 | 类型 | 必填 | 说明 |
@@ -110,6 +121,7 @@ icon: FileJson
 | `appointment_id` | string | | 关联预约 id(有则挂回预约链) |
 | `tenant_id` | string | ✅ | 品牌 GUID(宿主原生 tenantId) |
 | `organization_id` | string | ✅ | 诊所 |
+| `organization_name` | string | | 诊所名称 —— **诊所展示名的主要来源**(PAC 据此派生 id→名字典;缺失则前端显示 GUID) |
 | `patient_id` | string | ✅ | → 患者 id |
 | `user_id` / `user_name` | string | | 接诊医生 id / 姓名 |
 | `clinic_time` | string(datetime) | ✅ | 就诊时刻 |
@@ -143,6 +155,7 @@ icon: FileJson
 | `id` | string | ✅ | 行主键 |
 | `tenant_id` | string | ✅ | 品牌 GUID |
 | `organization_id` | string | ✅ | 诊所 |
+| `organization_name` | string | | 诊所名称(同上,诊所名字典来源之一) |
 | `patient_id` | string | ✅ | → 患者 id |
 | `emr_id` | string | | → 病历号(`med_emr_info.emr_id`) |
 | `class_code` | string | | 影像类型 → `std_check_class` |
@@ -268,5 +281,24 @@ icon: FileJson
 
 ---
 
-## 7. 语义确认状态
-**待确认清单已清零**(患者主档 push 已于 2026-07-20 支持,见 §2;全部语义均有源码/实证依据)。
+## 7. 语义澄清记录(2026-07,源码 + 数据双证)
+
+以下曾是开放问题,现已定案 —— 推送方无需再确认,列此备查:
+
+| 项 | 结论 | 依据 |
+|---|---|---|
+| 时间口径 | MySQL `datetime` = 北京墙钟(`_gmt_` 命名系惯例误导);**Mongo `Date` 是北京墙钟伪装成 UTC** | `clinicTime`/`createdGmtAt` 小时分布呈营业双峰;按真 UTC 解释则半数病历落深夜 |
+| 金额单位 | 元(`decimal(9,2)`) | 洁治单价均值 ¥310、已结算客单均值 ¥1,730 |
+| `contacts.relationship` | `PhoneRelationshipEnum` 1-9(见 §2) | customer 服务枚举类 |
+| `referee_relationship` | `RecommendRelationshipEnum` 17 码,**语义 = 本行 customer 是 referee 的 X**(PAC 侧按逆关系映射) | 枚举类 `reverseValue()` + 双方年龄差数据 |
+| `med_emr_info.treat` vs `dispose` | `treat` = 本次治疗(→ 结构化治疗事实);`dispose` = 处置叙述(→ 病历自由文本) | EMR 接口 DTO 字段注释 |
+| `patient_settlement.status` 全 9 值 | `0`未结算 `1`已结算 `2`只生成uuid `3`含退费行 `4`整单反向冲减 `5`重新结算(废弃历史) `6`医生未提交 `7`流程结束 `8`欠款补缴克隆单 | 实体注释 + `savePatientSettlementQk()` 实现 |
+| 为何不收 `7`/`8` | `8` 是原单克隆(`receivable_this` 原样复制、`payment_arrears` 才是本次补缴额),入消费会**双计应收**;`7` 为零金额流程关单 | 同上 |
+
+### 仍需推送方留意(非阻塞)
+
+| 项 | 说明 |
+|---|---|
+| `organization_name` 覆盖 | 目前仅病历/影像表带诊所名,**只覆盖有病历记录的诊所**;其余诊所前端回退显示 GUID。若贵方有组织树接口(如 `regional_nodes_structure`),提供 `诊所 id → 名称` 全量表可补齐 |
+| 字典表推送频率 | `std_diag` / `std_check_class` / `tenant_info` 变更不频繁,按"变更时全量重推"即可,无需增量 |
+| 测试环境数据特征 | 部分租户为开发沙盒(诊所名如"XX专用诊所勿动"),字典类映射(治疗类别关键词等)待**生产数据**回流后再校准一轮 |