diff --git a/docs/refs/20261011-投云长护险管理系统-产品介绍（完整版）.md b/docs/refs/20261011-投云长护险管理系统-产品介绍（完整版）.md
new file mode 100644
index 0000000..3e6b7f9
--- /dev/null
+++ b/docs/refs/20261011-投云长护险管理系统-产品介绍（完整版）.md
@@ -0,0 +1,197 @@
+# 投云长护险管理系统 · 产品介绍（完整版 · V2）
+
+**云南投云科技有限公司**
+
+> **⚠️ 阅读说明（2026-10-12 加）**：**本文档描述产品的完整形态，不是首期交付承诺。**首期实际交付范围以《产品介绍（首期版）》与《P0 PRD》为准；本文中标注"〔二期〕/升级项"的功能，属分期落地。
+>
+> **📝 版本修订注（2026-10-12，只动以下 5 处，其余逐字保留）**：①"五种状态"→**七种**、"自动拦截"→"状态标为住院后拦截"；②"申报即生成"→**"申报底稿自动汇总"**（讲清"底稿≠最终提交，提交以医保平台为准"）；③第②节"资质校验"补"资质库建成后升级为自动拦截"；④第⑥节"无资质自动拦截派单"→**"无资质派单拦截（升级项）"**；⑤第⑧节新增**"身份核验"边界说明**（扫脸/现场核验由官方 APP 承担，我方当前只做实名建档兜底，核验机制待确认，不写成卖点）。**理由**：消除"把二期能力当现有卖点讲"的超载表述（见 `20261012-22条答问返工决议单`）。
+>
+> **📝 版本修订注（2026-10-12 第二轮，只动以下 5 处，其余逐字保留）**：按机构老板二轮 5 问回填——①第一节新增"会不会变成'录两次'"小节；②第①节"老人建档"补**批量导入**（此前漏讲的卖点，PRD §5.5.1 B1-B 已写定）；③第五节新增"培训与上手""手机与流量"两段；④第八节第 3 条"与医保平台的对接"扩写为**三步走**（补医保办发〔2024〕21 号／〔2025〕19 号依据）；⑤第八节新增第 6 条"责任边界"（只讲原则，赔付数字归合同）。**用户版微调一律保留。**详见《20261012-机构老板二轮5问应答-大白话版》。
+
+---
+
+## 一、这套系统是做什么的
+
+> **投云长护险管理系统，是帮护理机构把"长护险服务"这件事，做得「省事、合规、能结回钱」的内部运营系统。**
+
+云南省级层面统一建了打卡留痕的官方 APP，护理员签到、留痕都走「云南医保服务平台」APP。但机构自己的那摊子事——**谁服务谁、什么时候去、去了做什么、做得对不对、台账怎么对得上、钱怎么报回来**——官方 APP 管不到，还得靠机构自己拿纸、拿 Excel、拿微信群去撑。
+
+**我们做的，就是官方管不到的这一段：服务计划、派单、台账、质控、对账。**
+
+一句话：**官方管"打卡留痕"，我们管"内部运营"。**
+
+**三个"不做"（边界，从一开始就写清）：**
+
+| 不做             | 原因                        |
+| -------------- | ------------------------- |
+| 不做打卡 APP，不替代官方 | 云南省级统建，护理员统一用官方 APP，这条路不碰 |
+| 不做评估、不做诊疗判断    | 医学判断由机构持证人员做，系统不越界        |
+| 不做"全能系统"       | 功能越多，一线越不用。能砍就砍，砍到一线愿意用为止 |
+
+**那护理员会不会变成"录两次"？（机构问得最多的一条，先答掉）**
+
+不会。官方 APP 的打卡照打——那是给医保的考勤，谁也替代不了；**我们这边她不打字、不填表，说一句"给老人做了什么"、该拍的项目拍张照，就完事**。真实工作量是"打卡照旧＋多说一句话"，不是"同一套东西录两遍"。往后还有两步减法：当地经办若能导出数据，可做文件级对账、不用手工誊；医保接口规范一发布，两套系统直接对接（国家明文路径，详见第八节第 3 条）。
+
+---
+
+## 二、系统全景：三个端 + 一个后台
+
+| 端                | 谁用            | 干什么                          |
+| ---------------- | ------------- | ---------------------------- |
+| **护理员 APP**（安卓）  | 一线护理员         | 干活现场的唯一操作面：今天去哪几家、签到、勾项目、报异常 |
+| **机构管理后台**（电脑网页） | 组长 / 质控员 / 院长 | 排班派单、查记录、质控放行、对账、看经营         |
+| **家属公众号**（微信）    | 老人子女          | 只看看：这周谁来过、做了什么，可顺手点个"知道了"    |
+
+三个端不是三套系统，是**同一套数据的三个入口**。护理员录一次，后台和家属端都看得到，谁都不用再抄一遍。
+
+> **设计原则一句话**：一线端做减法（功能最少、最好上手），管理端做加法（信息最全、一眼看到该管的事）。
+
+---
+
+## 三、完整功能体系（七大模块，一页看清）
+
+| 模块          | 解决什么                                | 主要用户   |
+| ----------- | ----------------------------------- | ------ |
+| ① 服务对象与待遇管理 | 无有效待遇不得服务；计划有法定时限                   | 质控员    |
+| ② 派单与工单     | 不漏派、不重派、时间不冲突                       | 组长     |
+| ③ 履约留痕（核心）  | 记录真实、完整、可追溯                         | 护理员    |
+| ④ 内部质控与风险闸门 | 上报前自检，把问题拦住                         | 质控员/院长 |
+| ⑤ 结算与对账     | 一次录入、三账同源，**自动汇总申报底稿**（提交以医保平台为准）   | 质控员/院长 |
+| ⑥ 资质与人员管理   | 资质到期提醒、人岗匹配（**派单校验提示；资质库建成后升级为拦截**） | 质控员    |
+| ⑦ 院长看板      | 只看三块：可结算 / 风险 / 人效                  | 院长     |
+
+---
+
+## 四、七大模块逐一说明
+
+### ① 服务对象与待遇管理
+
+- **老人建档**：给每位老人建一份电子档案，含待遇信息、护理等级、注意事项。签约后 **1 个月内**须建档，系统**倒计时提醒、超期标红**。
+- **档案批量导入**：现有 Excel 台账不用重录——老人档案、护理员档案、服务项目价格**三类均可 Excel 整批导入**；系统提供标准模板，导入前**逐行校验**（身份证 18 位＋校验位、必填非空、参保地合法、项目须在属地目录内），**错误行不写入、单独生成错误清单**（第几行、什么原因），改完再导；每次导入留操作日志。纸质台账建议先建在保老人跑起来，历史档案分批补。
+- **待遇状态管理**：待建档、正常享受、住院暂停、死亡、长期异地居住、待遇到期、已终止，**七种状态**一眼分清；**老人状态标为住院后，系统立即拦截派单**（状态由机构维护）。
+- **服务计划**：签约后 **5 个工作日内**须制定计划；从属地目录选项目、定频次和时长；**项目数量按属地规则校验，不满足不能提交**；计划需家属或长护专员确认后生效；**变更全程留痕**。
+- **目录外服务**：需书面同意的项目，须先上传同意件才能落单。
+
+### ② 派单与工单
+
+- **自动生成工单**：计划生效后，系统按周期和频次自动生成每日工单。
+- **排班表**：日视图、周视图切换，每个护理员的负荷一眼可见；空缺、时间冲突自动标出。
+- **调单**：护理员临时请假，组长**不超过 3 步**把单转给别人，不比微信群慢。
+- **冲突检测**：同一护理员同一时段被派两单，系统**直接拦住不让保存**。
+- **派单时资质校验提示**：派单时系统对护理员资质进行校验，资质过期或不匹配的**给予提示**（**资质库建成后升级为自动拦截**）。
+
+### ③ 履约留痕（核心）
+
+护理员上门：签到 → 干活 → 签退，项目照着勾。
+
+- **首屏即任务**：打开 APP 就知道今天去哪几家、几点、做什么。
+- **完成一次记录不超过 4 次点击，不打一个字**——全用勾选和语音。
+- **签到自动定位取时，签退自动算时长**，不用手工填。
+- **没信号也能用**，联网后自动补传。
+- **拍照分档**（下面第五节详述）。
+- **异常一键上报**：发现压疮、呛咳、跌倒等，选个分类、说句话即可，**即时推给组长和质控员**。
+
+### ④ 内部质控与风险闸门
+
+- **全量审核，不抽检**：护理员交回的每一条记录都进质控队列，有问题退回补正，没问题放行。
+- **主动推送，不等人翻**：谁没拍照、谁时长异常、谁住院了还有派单——系统**主动推到质控员面前**。
+- **异常联动改计划**：护理员上报压疮 → 质控员判断要加压疮护理 → **直接改计划**，下次派单自动带出该项目。
+- **改不了原始证据**：签到时间、定位、照片本身不可改，只能补正、保留原值。
+
+### ⑤ 结算与对账
+
+- **申报底稿自动汇总**：月底系统自动汇总本月可结算数据、生成**申报底稿（可结算清单）**，**数据直接来自服务留痕，不二次手填**。**申报底稿是"拿来申报的底稿"，最终提交与数据以医保平台为准**——系统不代替官方申报口径。
+- **三价一致性校验**〔二期〕：机构价、备案价、公示价不一致即拦截。**⚠️ 如实说明：该能力属二期（结算对账模块）**——现阶段库内**仅有"机构价"一个字段**，**备案价/公示价暂无数据来源**，此时三价一致性**以机构台账人工核对为准**（备案价取值口径待核）。**对客不得表述为"系统现已自动校验三价"。**
+- **回款看得见**：钱报回来多少、卡在哪一步，一眼清楚（只读展示，不碰资金池）。
+- **差异可对账**：结算数据与系统记录有出入时，人工核对、全程留痕。
+
+### ⑥ 资质与人员管理
+
+- **人员库与资质台账**：所有护理员的证书、有效期统一管理。
+- **到期自动提醒**：证书快过期，提前推给质控员和护理员本人。
+- **无资质派单拦截（升级项）**：资质过期就不能派他做对应项目（**首期先做派单提示，资质库建成后升级为自动拦截**）。
+- **实名制动态管理 + 工作质量考核**：入离职、资质变动全程实名可查，考核标准机构可配置。
+
+### ⑦ 院长看板
+
+院长一登录，**只看三块**：本月能报回多少钱、有没有"雷"（资质到期、台账缺失等风险）、同样的人能不能多接单（人效趋势）。**不堆指标，只看结果。**
+
+---
+
+## 五、为什么护理员愿意用（这是本系统的根）
+
+功能堆得再多，一线不用，就是空壳。这套系统的设计，**处处为"一线用不惯"让路**：
+
+- **最多 4 次点击**完成一次服务记录，**不打一个字**；
+- **没信号也能用**，联网后自动补传；
+- **关键按钮大字号**，不做层层菜单，**打开就是今天要去哪几家**；
+- **录错了能撤销**，先提示、不直接扣钱；
+- **拍照分档**，不搞一刀切：
+  - 高风险项目（沐浴、搬抬转移、导管护理、鼻饲喂食）——**必须拍照**，这是机构唯一的免责证据；
+  - 日常项目（翻身、喂饭、陪伴、剪指甲、整理床铺）——**语音描述即可**，不用逼老人摆拍；
+  - 中间项目（擦身、更衣、协助如厕）——默认免拍，出现异常才补拍。
+
+**我们做的是"把政策本来就要的事，做成一线干得动的样子"，不是给一线再加一套麻烦。**
+
+**培训与上手**：我们的验收标准是"不教也会用"——找一位从没见过系统的护理员，不给培训、只给手机，**10 分钟内独立完成一次服务记录**，测不过就改设计，不怪护理员。落地配套：不集训全员，**只训组长和质控员（一次约 2 小时）**；护理员侧配一页图文卡＋60 秒短视频＋APP 内首次引导；上线首周建"陪跑群"，客服远程兜底；打字不会的全程可用语音。（上门/远程形式、次数、响应时限属实施条款，写进合同。）
+
+**手机与流量**：APP 按低配安卓机设计，老机型跑得动；照片自动压缩、没信号先存着有网再传，流量目标控制在**每人每月 500MB 以内**（联调期实测后给数）。机构常见做法是给护理员**每人每月 10–20 元通讯补贴**，十几人一年约两三千——对比一笔拒付就回本（发不发属机构内部决定）；个别没有智能机的，可备两三台二手安卓做工作机轮换，系统支持同账号换设备登录。
+
+---
+
+## 六、合规这件事，怎么落在系统里
+
+合规不是贴在墙上的口号，是**干活时自然产生的**。系统里，政策的每一条要求都有对应的落点，其中最关键的是**六条硬锁**（系统强制，点不动、绕不过）：
+
+| 硬锁    | 含义                                |
+| ----- | --------------------------------- |
+| 无有效待遇 | 不能建档、不能服务                         |
+| 无服务计划 | 不能生成工单                            |
+| 无有效工单 | 不能录入留痕                            |
+| 无完整留痕 | 不能进上报池                            |
+| 无质控放行 | 不能上报结算                            |
+| 无有效资质 | 不能派该项目的单（**首期为派单提示，资质库建成后升级为硬拦**） |
+
+> **⚠️ 口径纪律（写死）**：**前五条为系统"点不动"的硬锁；第六条（资质）首期为提示级、后续升级为硬锁。**对外不得把第六条讲成"现已自动禁派"。另："无完整留痕→不能进上报池""无质控放行→不能上报结算"两条，**与"结算对账"同属分期落地**，见首页阅读说明。
+
+其他关键落点：服务项目**只能从国家目录选、不得自创**；护理记录**一次录入、三端同源**；**记录不可无痕修改**，改动留补正痕迹、原值保留；档案**一人一档、随时可导出**，格式对齐国家 2026 版文书。
+
+---
+
+## 七、昆明和州市，目录不一样怎么办
+
+云南实行**州（市）级统筹**，各地服务项目目录并不完全相同：
+
+- **昆明市**（老试点）执行**本地目录 45 项**；
+- **新建制州市**（曲靖、玉溪、楚雄、文山、西双版纳、大理、临沧等）执行**国家统一目录 36 项**。
+
+系统**预置了这两套目录**，机构注册时选定参保地，系统**自动加载对应目录**；机构只需**勾选自己开展的项目、填好价格**即可使用，不用自己一条条录，也不用担心录错成"目录外项目"。以后新增一个州市，加一份配置即可，**不改程序、不影响现有机构**。
+
+---
+
+## 八、几点说明
+
+以下几项，需要机构了解（**这也是对机构负责**）：
+
+1. **资质信息由机构维护**：护理员资质信息由机构录入维护，系统据此在派单时**校验提示**；**资质库建成后，对过期资质升级为自动拦截。**
+2. **参保人状态由机构维护**：参保人住院、死亡、异地居住等状态，由机构在系统内及时更新，系统据此进行派单拦截和提醒。
+3. **与医保平台的对接（三步走，如实说）**：**眼下**，官方 APP 打卡照常，我方侧录入压到"一句话＋必要拍照"，不做重复录入；**过渡**，若当地经办系统支持导出数据，系统提供标准模板做文件级对账，不用手工誊抄（能否导出以当地经办为准，签约前我们协助核实）；**长远**，国家已明文给出"机构自建管理系统并与全国统一的医保信息平台对接"的路径（医保办发〔2024〕21 号第十八条），且国家巡查表中"自建系统并对接"为加分项、值 5 分（医保办发〔2025〕19 号）——系统已按医保部门统一接口规范预留对接口径。**接口规范何时发布由统筹区经办机构定，我们不承诺日期、不表述"已接通"。**
+4. **巡查评分**：本系统只做日常留痕与国家文书查阅项的对照，**不预测巡查评分、不承诺合格**；评分判定权在统筹地区医疗保障经办机构。
+5. **服务时的身份核验**：国家文书要求"服务前核验参保人有效身份凭证、人证不符不得服务"。**这一步的扫脸/现场核验由官方 APP 承担；我方系统当前只做到"实名制建档＋档案里有这个老人"兜底，"上门的老人是不是档案里那个老人"的核验机制正在与医保/机构确认中。**对客**不得表述为"我方系统已做身份核验/扫脸"**。
+6. **责任边界（出了问题算谁的）**：分三份、写进合同——①**系统该拦没拦住的**（如待遇失效仍放行派单），是我方责任：上文"六条硬锁"将逐条翻译为对客《系统拦截承诺清单》作合同附件，**漏拦即违约**；②**系统看不见的事**（医保侧状态变化、属地口径调整），由机构按本节第 1、2 条承担维护义务，签约时讲透；③**属地化口径**（如拍照分档的当地要求），签约前双方对照《属地核对确认单》逐条核对、签字为界。**赔付上限等具体数字属商务条款，以合同为准。**
+
+---
+
+## 九、这套系统不做什么
+
+| 不做             | 原因                        |
+| -------------- | ------------------------- |
+| 不做打卡 APP，不替代官方 | 云南省级统建，护理员统一用官方 APP，这条路不碰 |
+| 不做评估、不做诊疗判断    | 医学判断由机构持证人员做，系统不越界        |
+| 不做"全能系统"       | 功能越多，一线越不用。能砍就砍，砍到一线愿意用为止 |
+
+---
+
+**云南投云科技有限公司**
+
+（落款日期待确认后填写）
diff --git a/docs/refs/20261011-数据字典与接口契约（第4步·V1待确认）.md b/docs/refs/20261011-数据字典与接口契约（第4步·V1待确认）.md
new file mode 100644
index 0000000..501e4f6
--- /dev/null
+++ b/docs/refs/20261011-数据字典与接口契约（第4步·V1待确认）.md
@@ -0,0 +1,687 @@
+# 投云长护险管理系统 · 数据字典与接口契约
+
+**第 4 步 · 交付物（V1 · 待确认）**
+
+> **本文档是什么**：把第 3 步四份 PRD 里"用中文描述的对象、字段、状态"，落成**开发能直接照着建库、照着写接口的技术契约**。这是 PRD 与代码之间的那一层——**PRD 说"要什么"，本文档说"怎么存、怎么传"**。
+> **前置文档**：第 1 步产品大纲（已确认）→ 第 2 步总体方案与信息架构（V2 锁定 P0）→ 第 3 步四份 PRD（PRD-00 全局规范 / 01 护理员 APP / 02 机构后台 / 03 家属端）→ **本文档**。
+> **本期范围（写死）**：**P0 四块**（①待遇档案／②派单工单／③履约留痕／④质控闸门）。二期三块（⑤结算对账／⑥资质人员／⑦院长看板）**只落结构，不落功能**。
+> **恒定总纲**：**既满足长护险政策要求，又让机构用得方便、不复杂。**
+> **编制**：滇小构｜2026-10-11
+
+---
+
+## 〇、读法说明（先看这三条，否则容易误用）
+
+1. **本文档的字段一律用英文键名**（`snake_case`），中文名只在"说明"列。
+   - **理由**：字段名要在数据库、接口、代码里统一；中文只在界面文案层出现。**界面文案与字段名解耦**，改名不改库。
+2. **每个字段标注【本期】/【预留】/【系统】三种标记**：
+   - **【本期】**＝本期必须落库、必须进界面；
+   - **【预留】**＝本期只建字段、界面不出现（对应 PRD-00 §8 的 R1–R6）；
+   - **【系统】**＝系统自动生成，人不填（如 ID、时间戳、MD5）。
+3. **本文档不含**：接口的**具体传输协议**（HTTP/HTTPS 皆可）、服务器部署、加密算法选型——这些属于技术方案，不属产品文档。
+
+---
+
+## 一、术语与技术口径对齐（防开发歧义）
+
+| PRD 里的中文 | 技术口径 | 说明 |
+|---|---|---|
+| 老人档案 | `elder` 表 | 主键 `elder_id` |
+| 服务计划 | `plan` / `plan_item` 两张表 | 计划头 ＋ 计划项目明细 |
+| 工单 | `order` 表 | 一次服务＝一条工单 |
+| 服务留痕 | `record` 表（主记录）＋ `record_photo`（照片）＋ `record_abnormal`（异常） | 一对多 |
+| 质控记录 | `qc` 表 | 一条留痕对应一条质控（可多次退回补正，留历史） |
+| 服务项目 | `svc_national`（L1）／`svc_local`（L2）／`svc_mapping`（L3）／`svc_org`（L4） | **四层四表，对应 PRD-00 §2.2** |
+| 人员与资质 | `staff` 表 | 【预留】R2 |
+| 上报 | `report` 表 | 【预留】R4 |
+| 结算 | `settlement` 表 | 【预留】R1 |
+
+> **⚠️ 命名纪律**：**不得使用 `checkin`／`clockin`／`punch` 作为留痕表名**——术语表明确"打卡记录"是禁用说法，留痕＝`record`。**这是合规口径在代码层的落地**（对应"不做打卡工具"的产品定性）。
+
+---
+
+## 二、数据库表总览
+
+### 2.1 本期建表清单（12 张）
+
+| # | 表名 | 中文 | 对应对象 | 本期用途 |
+|:---:|---|---|---|---|
+| 1 | `org` | 机构 | — | 机构信息、属地、账号根 |
+| 2 | `user` | 账号 | — | 登录账号（后台三端角色） |
+| 3 | `staff` | 人员 | ⑥〔预留〕 | 护理员/医护基础信息＋**资质字段预留** |
+| 4 | `elder` | 老人档案 | ① | 待遇状态、等级、参保地（**含 `biz_line` 多业务线预留 R8**） |
+| 5 | `elder_status_log` | 待遇状态变更日志 | ① | **状态变更留痕（不可无痕修改）** |
+| 6 | `plan` | 服务计划（头） | ② | 周期、等级、护理方式、确认信息 |
+| 7 | `plan_item` | 服务计划（项） | ② | 计划内含哪些服务项目、频次、时长 |
+| 8 | `svc_national` | 国家基准库 | L1 | 国家 36 项＋官方代码（**17 字符，字段 varchar(20) 留余量**） |
+| 9 | `svc_local` | 属地目录库 | L2 | 昆明 45 项；州市引用 L1 |
+| 10 | `svc_mapping` | 属地↔国家映射 | L3 | **机构不可见** |
+| 11 | `svc_org` | 机构项目库 | L4 | 机构勾选＋配价 |
+| 12 | `order` | 工单 | ③ | 一次服务任务（**含 `biz_line` 多业务线预留 R8**） |
+
+### 2.2 本期建表清单（续，6 张）
+
+| # | 表名 | 中文 | 对应对象 | 本期用途 |
+|:---:|---|---|---|---|
+| 13 | `record` | 服务留痕（主） | ③ | 签到签退、时长、语音、状态 |
+| 14 | `record_item` | 留痕项目明细 | ③ | 每个项目的"做了/没做/免拍" |
+| 15 | `record_photo` | 留痕照片 | ③ | 照片存储引用 |
+| 16 | `record_abnormal` | 异常上报 | ③ | 9 宫格分类＋语音＋照片 |
+| 17 | `qc` | 质控记录 | ④ | 放行/退回、异常处理 |
+| 18 | `report` | 上报池 | R4〔预留〕 | 建表，本期不写业务数据 |
+| 19 | `settlement` | 结算 | R1〔预留〕 | 建表，本期不写业务数据 |
+
+> **另有 3 张"字典/配置表"**：`dict_abnormal_type`（异常分类 9 宫格）／`dict_photo_tier`（拍照分档）／`loc_config`（统筹区配置，含目录来源）。合计 **22 张**。
+
+---
+
+## 三、核心表字段定义
+
+> **通用字段**（每张表都有，下文不再重复）：`created_at`（创建时间）／`created_by`（创建人）／`updated_at`（更新时间）／`updated_by`（更新人）／`is_deleted`（软删除标志，**本期一律软删除，不物理删**）。
+
+### 3.1 `org` 机构表
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `org_id` | varchar(32) | ✅ | 机构 ID（主键） | 【系统】 |
+| `org_name` | varchar(100) | ✅ | 机构全称（**须与备案名称一致**） | 【本期】 |
+| `org_type` | varchar(20) | ✅ | 机构类型：`medical_care`（医养结合）／`nursing_home`（养老机构）／`home_care`（居家上门）／`home_individual`（居家个体） | 【本期】 |
+| `credit_code` | varchar(18) | ✅ | 统一社会信用代码 | 【本期】 |
+| `loc_code` | varchar(12) | ✅ | **参保地／统筹区代码**（决定加载哪套目录） | 【本期】 |
+| `loc_name` | varchar(50) | ✅ | 统筹区名称（冗余，便于展示） | 【本期】 |
+| `svc_source` | varchar(10) | ✅ | 本机构目录来源：`national`（引用国家36）／`local`（昆明本地45） | 【本期】 |
+| `license_no` | varchar(50) | ○ | 定点服务机构编号 | 【本期】 |
+| `address` | varchar(200) | ✅ | 机构地址 | 【本期】 |
+| `contact_name` / `contact_phone` | varchar | ✅ | 联系人／电话 | 【本期】 |
+| `bed_count` | int | ○ | **床位备案数**（机构护理类必填） | 【本期】 |
+| `sign_date` | date | ○ | 定点服务协议签订日（建档倒计时基准） | 【本期】 |
+
+### 3.2 `user` 账号表
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `user_id` | varchar(32) | ✅ | 账号 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| `login_name` | varchar(50) | ✅ | 登录名（手机号） | 【本期】 |
+| `real_name` | varchar(30) | ✅ | 真实姓名 | 【本期】 |
+| `role` | varchar(50) | ✅ | **角色（可多值，逗号分隔）**：`nurse`（护理员）／`leader`（组长）／`qc`（质控员）／`admin`（机构管理员）／`director`（院长）；如 `director,admin`、`leader,qc` | 【本期】 |
+| `staff_id` | varchar(32) | ○ | 关联 `staff` 表（护理员角色必填） | 【本期】 |
+| `status` | varchar(10) | ✅ | `active`／`disabled` | 【本期】 |
+
+> **⚠️ 权限落地纪律**：**角色不写在界面里做开关，写在后端权限校验**。**判权＝角色并集**（一人可兼多角色，见 PRD-00 §6.4 补充 2）。**"院长不改数据"修正为"仅当账号只持 `director` 时，写接口返回 403"**——若同时持 `qc`／`admin`（院长兼质控/兼管理员是常态），**按并集放行**。
+> **⚠️ 唯一例外**：**禁止"自审自放行"**——同一账号录入的记录不得由自己质控放行（校验 `record.created_by ≠ qc.operator_id`），否则返回 `4001`。
+
+### 3.3 `staff` 人员表（含 R2 预留）
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `staff_id` | varchar(32) | ✅ | 人员 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
+| `id_card_no` | varchar(18) | ✅ | 身份证号（**实名制**，加密存储） | 【本期】 |
+| `person_code` | varchar(20) | ○ | **医保人员编码**（按国家编码规范：`LN`+6位区划+6位顺序＝14 位；**字段留余量 varchar(20)**） | 【预留】R4 |
+| `phone` | varchar(15) | ✅ | 手机号（APP 登录用） | 【本期】 |
+| `job_type` | varchar(20) | ✅ | `nurse`（护理员）／`nurse_medical`（医护）／`manager` | 【本期】 |
+| `work_type` | varchar(10) | ✅ | `fulltime`／`parttime` | 【本期】 |
+| `entry_date` / `leave_date` | date | ○ | 入职／离职日（**离职自动移出可派列表**） | 【本期】 |
+| `employ_status` | varchar(10) | ✅ | `on_job`／`leave`（离职）／`transfer` | 【本期】 |
+| `cert_type` | varchar(30) | ○ | 证书类型（长期照护师/养老护理员/护士执业证/医师执业证） | **【预留】R2** |
+| `cert_no` | varchar(50) | ○ | 证书编号 | **【预留】R2** |
+| `cert_level` | varchar(20) | ○ | 等级（五级/四级/三级） | **【预留】R2** |
+| `cert_expire` | date | ○ | 有效期至 | **【预留】R2** |
+| `cert_status` | varchar(20) | ○ | `valid`／`expiring`／`expired`／`none`（本期人工填） | **【预留】R2** |
+| `cert_verify_url` | varchar(200) | ○ | 联网查验结果留痕（如 osta.org.cn 截图路径） | **【预留】R2** |
+| **`group_leader_id`** | varchar(32) | ○ | **归属组长**（＝该护理员所在"组"的组长 `staff_id`；**本组界定的唯一依据**，见 PRD-00 §6.4 补充 4）。**可为空＝机构未分组**，由 `admin` 在人员管理指定 | 【本期】 |
+
+> **⚠️ 本期数据不空转纪律**（PRD-00 §8.1 第 2 条）：**`cert_*` 五字段本期就要人工录入**——签约机构手上都有证书信息，**先录进去，二期直接可用**，不浪费这一期的录入工作。
+> **⚠️ 界面纪律**：本期 `cert_*` 字段**只在"人员管理（精简版）"里可填可看**，**不做到期提醒、不做禁派拦截**（那是二期）。
+
+### 3.4 `elder` 老人档案表（① 待遇档案）
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `elder_id` | varchar(32) | ✅ | 老人 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| **`loc_code`** | varchar(12) | ✅ | **参保地／统筹区**（→ 数据铁律 3，全链路取目录依据） | 【本期】 |
+| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
+| `gender` | char(1) | ✅ | `M`／`F` | 【本期】 |
+| `birth_date` | date | ✅ | 出生日期（系统算年龄） | 【本期】 |
+| `id_card_no` | varchar(18) | ✅ | 身份证号（加密） | 【本期】 |
+| `phone` | varchar(15) | ○ | 联系电话 | 【本期】 |
+| `address` | varchar(200) | ✅ | 居住地址（服务上门用） | 【本期】 |
+| `guardian_name` / `guardian_phone` | varchar | ○ | 紧急联系人 | 【本期】 |
+| `insur_no` | varchar(30) | ✅ | **医保参保号** | 【本期】 |
+| `insur_type` | varchar(10) | ✅ | `employee`（职工）／`resident`（居民） | 【本期】 |
+| `biz_line` | varchar(20) | ✅ | **业务线**：`ltci`（长护险）／`self_pay`（自费）／`residence`（居养）／`civil_subsidy`（民政补贴）——**本期恒 `ltci`，多业务线二期扩展** | **【预留】R8** |
+| `assess_level` | varchar(20) | ✅ | **失能等级**：`sev_1`（重度一级·**最高级**）／`sev_2`／`sev_3` | 【本期】 |
+| `care_level` | varchar(20) | ✅ | **护理等级**：`care_1`（一级·**最高级**）／`care_2`／`care_3` | 【本期】 |
+| `assess_date` | date | ✅ | 评估结论日期 | 【本期】 |
+| `assess_org` | varchar(100) | ○ | 评估机构名称 | 【本期】 |
+| `benefit_start` / `benefit_end` | date | ✅ | **待遇有效期起止** | 【本期】 |
+| `treat_status` | varchar(20) | ✅ | **待遇状态**（见 §3.5 状态机） | 【本期】 |
+| `status_source` | varchar(10) | ✅ | 状态来源：`manual`（人工）／`api`（接口）——**本期恒 `manual`** | **【预留】R5** |
+| `status_change_date` | date | ○ | 状态最后变更日 | 【本期】 |
+| `hosp_start` / `hosp_end` | date | ○ | **住院起止日**（`treat_status = 住院暂停` 时必填） | 【本期】 |
+| `photo_tier_override` | json | ○ | 机构对本老人拍照分档的**加严覆盖**（**只能加严，不能放宽**） | 【本期】 |
+| `note` | text | ○ | 备注（**含"注意事项"区块内容**，如吞咽障碍提示） | 【本期】 |
+
+> **⚠️ 等级显示纪律**：`assess_level`／`care_level` 在界面上**必须带"最高级"字样**——`sev_1` 显示为"**重度失能一级（最高级）**"，`care_1` 显示为"**一级护理（最高级）**"。**这是 PRD-00 §2.5 写死的，不允许前端省略。**
+> **⚠️ 认知衰退边界**：`assess_level` 只反映**日常活动 6 项**自评＋正式评估结论；**认知/感知觉 7 项须上门评估，系统不筛**。此口径须出现在任何展示等级的页面注脚。
+
+### 3.5 `elder_status_log` 待遇状态变更日志（数据铁律 2 落地）
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `log_id` | varchar(32) | ✅ | 主键 |
+| `elder_id` | varchar(32) | ✅ | 老人 ID |
+| `from_status` / `to_status` | varchar(20) | ✅ | 变更前后状态 |
+| `change_reason` | varchar(200) | ✅ | **变更原因（必填，不允许空）** |
+| `source` | varchar(10) | ✅ | `manual`／`api` |
+| `operator_id` | varchar(32) | ✅ | 操作人 |
+| `evidence_file` | varchar(200) | ○ | 佐证材料（如出院小结照片路径） |
+| `changed_at` | datetime | ✅ | 变更时间 |
+
+> **⚠️ 关键设计**：**待遇状态的每一次变更都必须写一条日志，且 `change_reason` 强制必填**。
+> **理由**：`treat_status` 直接决定"能不能服务、能不能计费"。**如果不留痕，"住院期间照做"这类问题将无法追溯**——而官渡区公示的高频事由正是"账账不符、记录不详"。**这条日志是机构自己的护身符。**
+
+### 3.6 `plan` 服务计划表（② 服务计划）
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `plan_id` | varchar(32) | ✅ | 计划 ID | 【系统】 |
+| `elder_id` | varchar(32) | ✅ | 老人 ID | 【本期】 |
+| `org_id` | varchar(32) | ✅ | 机构 ID | 【本期】 |
+| `plan_period_start` / `plan_period_end` | date | ✅ | **计划周期**（月度/周期） | 【本期】 |
+| `care_level` | varchar(20) | ✅ | 计划对应的护理等级（**改等级须重新制定计划**） | 【本期】 |
+| `care_mode` | varchar(20) | ✅ | 护理方式：`inst_medical`／`inst_nursing`／`home_org`／`home_individual` | 【本期】 |
+| `item_count` | int | ✅ | **计划项目数**（系统按属地规则校验） | 【本期】 |
+| `item_count_rule` | varchar(100) | ○ | 校验依据快照（如"昆明·医养结合·一级护理 ≥18 项"） | 【本期】 |
+| `extra_item_count` | int | ○ | 附加项数（**≤5**） | 【本期】 |
+| `week_freq` / `month_hours` | int | ○ | 居家类的**每周次数／每月小时数**（昆明居家必填） | 【本期】 |
+| `plan_status` | varchar(20) | ✅ | `draft`（草稿）／`active`（执行中）／`changed`（已变更）／`ended`（已结束） | 【本期】 |
+| `confirm_elder` | tinyint | ○ | 老人/家属确认（0/1） | 【本期】 |
+| `confirm_guardian` | tinyint | ○ | 家属确认（0/1，**可选，不强制**） | 【本期】 |
+| `confirm_time` | datetime | ○ | 确认时间 | 【本期】 |
+| `change_from_plan_id` | varchar(32) | ○ | **变更来源计划**（改计划时新建一条，指向旧计划，**旧计划不删**） | 【本期】 |
+
+> **⚠️ 计划变更纪律**：**改计划＝新建一条计划 + 指向旧计划**，**绝不原地改**。
+> **理由**：政策要求"服务与计划相吻合"。若原地改，历史工单会突然"对上"一个当时不存在的计划——**这恰恰是"篡改数据"的典型形态**。**留旧版＝留证据。**
+
+### 3.7 `plan_item` 计划项目明细表
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `plan_item_id` | varchar(32) | ✅ | 主键 | 【系统】 |
+| `plan_id` | varchar(32) | ✅ | 计划 ID | 【本期】 |
+| `svc_id` | varchar(32) | ✅ | **引用 `svc_local` 或 `svc_national` 的 ID**（按机构属地取） | 【本期】 |
+| `svc_name_snapshot` | varchar(100) | ✅ | **项目名快照**（防目录改名后历史计划显示错乱） | 【本期】 |
+| `svc_code_snapshot` | varchar(20) | ○ | **国家代码快照**（上报基准，二期用） | 【预留】R4 |
+| `freq_type` | varchar(20) | ○ | 频次类型：`daily`／`weekly_n`／`monthly_n`／`as_needed` | 【本期】 |
+| `freq_value` | int | ○ | 频次值（如每周 3 次填 3） | 【本期】 |
+| `duration_min` | int | ○ | **单次时长（分钟）** | 【本期】 |
+| `photo_tier` | varchar(10) | ✅ | **拍照档位**：`must`（必拍）／`optional`（可拍）／`free`（免拍） | 【本期】 |
+| `caution_note` | text | ○ | **注意事项**（显示在护理员 APP M4，如"进食慢、小口、坐起90度"） | 【本期】 |
+| `is_medical` | tinyint | ✅ | 是否医疗护理类（**决定是否需医护资质**） | 【本期】 |
+| `need_cert` | tinyint | ✅ | 是否要求持证（医疗类＝1） | 【本期】 |
+
+> **⚠️ `svc_name_snapshot` 不是冗余，是必需**：目录会更新（国家曾"合并同类项"、昆明可能改版）。**快照保证历史计划与历史留痕永远显示当时的项目名**，否则三年前的服务记录会突然"变成"另一个项目名——**这在稽核中是致命的**。
+
+### 3.8 服务项目四层表（L1–L4）
+
+**`svc_national`（L1 国家基准库 · 36 项）**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `nat_id` | varchar(32) | ✅ | 主键（`NAT_` 前缀） |
+| `nat_code` | varchar(20) | ✅ | **国家项目代码**（经复核定型为 **17 字符**：`L`+`0000`+大类(1生活照护/2医疗护理)+类别2位+项目序号2位+`0`+`010000`；字段留余量） |
+| `nat_name` | varchar(100) | ✅ | 项目名称 |
+| `nat_category` | varchar(20) | ✅ | 大类：`life`／`medical` |
+| `nat_sub_category` | varchar(50) | ○ | 类别 |
+| `recommend_staff` | varchar(50) | ○ | 推荐服务人员 |
+| `recommend_duration` | int | ○ | 推荐时长（分钟） |
+| `is_medical` | tinyint | ✅ | 是否医疗护理类 |
+| `version` | varchar(20) | ✅ | 版本（如 `2025-24号`） |
+
+**`svc_local`（L2 属地目录库）**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `loc_id` | varchar(32) | ✅ | 主键（`LOC_` 前缀） |
+| `loc_code` | varchar(12) | ✅ | **适用统筹区代码**（`530100`＝昆明等） |
+| `local_item_name` | varchar(100) | ✅ | 本地项目名（**昆明 45 项实际名称**） |
+| `local_category` | varchar(50) | ○ | 本地分类（昆明四大类：基础生活照料/非治疗性护理/功能维护/医疗护理） |
+| `svc_time` | varchar(50) | ○ | 服务时间要求（昆明原文） |
+| `min_freq` | varchar(50) | ○ | 最低服务频次（昆明原文） |
+| `staff_qual` | varchar(100) | ○ | 护理人员资质要求（**昆明医疗类：仅限医疗机构/医养结合机构及持证医护人员**） |
+| `is_medical` | tinyint | ✅ | 是否医疗护理类 |
+| `source_doc` | varchar(100) | ✅ | 来源文件（如 `昆医保2021-45项`） |
+| `map_status` | varchar(20) | ✅ | **映射状态**：`mapped`（可映射国家）／`local_only`（**仅属地执行**） |
+
+**`svc_mapping`（L3 属地↔国家映射 · 机构不可见）**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `map_id` | varchar(32) | ✅ | 主键（`MAP_` 前缀） |
+| `loc_id` | varchar(32) | ✅ | 属地项目 ID |
+| `nat_id` | varchar(32) | ○ | 对应国家项目 ID（**可空＝无法映射**） |
+| `map_type` | varchar(20) | ✅ | **五值（与《逐项映射表》§0.2 一致）**：`one_to_one`（完全对应）／`many_to_one`（被合并，多个昆明项→国家 1 项，如头面清洁等→擦浴）／`partial`（近似对应，内涵不完全重合）／`local_only`（仅属地，国家目录无此项）／`national_only`（国家新增，昆明无、国家有） |
+| `map_note` | varchar(200) | ○ | 映射说明（**我方内部技术资产**） |
+| `status` | varchar(20) | ✅ | `confirmed`（人工核定）／`pending`（待核） |
+
+**`svc_org`（L4 机构项目库）**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `org_svc_id` | varchar(32) | ✅ | 主键（`ORG_` 前缀） |
+| `org_id` | varchar(32) | ✅ | 机构 ID |
+| `src_type` | varchar(10) | ✅ | 来源层级：`local`（从昆明45选）／`national`（从国家36选） |
+| `src_id` | varchar(32) | ✅ | 来源项目 ID |
+| `is_enabled` | tinyint | ✅ | 是否开展（**机构只能开关，不能删**） |
+| `biz_line` | varchar(20) | ✅ | **业务线**：`ltci`／`self_pay`／`residence`／`civil_subsidy`——**本期恒 `ltci`，多业务线二期扩展** | **【预留】R8** |
+| `price` | decimal(10,2) | **【预留】R1** | 服务价格（**本期可填可看，不参与结算**） |
+| `price_effective` | date | **【预留】R1** | 价格生效日 |
+| `is_new_national` | tinyint | ○ | **是否"国家新增项"**（昆明目录没有、国家有：吞咽功能训练等 5 项 → **必须显式提示**） |
+
+> **⚠️ 五条多属地纪律在表结构上的落地**（对应 PRD-00 §2.4）：
+> 1. **走配置不走代码** → 新增州市＝插一行 `loc_config` + 一批 `svc_local`，**代码零改动**；
+> 2. **必须可映射** → `svc_mapping` 保证每项可追；`map_status = local_only` 的项**上报时自动排除**；
+> 3. **机构不可改目录** → `svc_org` **只有 `is_enabled` 和 `price` 可改**，其余字段只读；
+> 4. **国家新增项显式提示** → `is_new_national = 1` 的项在机构勾选页**独立区块显示**，不隐藏；
+> 5. **映射表不对外** → `svc_mapping` 表**不提供任何机构侧接口**。
+
+### 3.9 `order` 工单表（③ 派单工单）
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `order_id` | varchar(32) | ✅ | 工单 ID | 【系统】 |
+| `elder_id` | varchar(32) | ✅ | 老人 ID | 【本期】 |
+| `biz_line` | varchar(20) | ✅ | **业务线**：`ltci`／`self_pay`／`residence`／`civil_subsidy`——**本期恒 `ltci`，多业务线二期扩展** | **【预留】R8** |
+| `plan_id` | varchar(32) | ✅ | **来源计划**（L2 硬锁落地） | 【本期】 |
+| `org_id` | varchar(32) | ✅ | 机构 ID | 【本期】 |
+| `service_date` | date | ✅ | **服务日期** | 【本期】 |
+| `time_slot_start` / `time_slot_end` | datetime | ✅ | **服务时段**（用于冲突检测） | 【本期】 |
+| `assignee_id` | varchar(32) | ○ | 派给谁（`staff_id`） | 【本期】 |
+| `assign_time` | datetime | ○ | 派单时间 | 【本期】 |
+| `assign_mode` | varchar(20) | ○ | 派单方式：`manual`／`batch_recommend`（**批量必须人工确认**） | 【本期】 |
+| `order_status` | varchar(20) | ✅ | **工单状态**（见 PRD-00 §4.2 七态） | 【本期】 |
+| `item_list` | json | ✅ | 本次工单项目的快照（来自 `plan_item`） | 【本期】 |
+| `need_photo` | tinyint | ✅ | 本次是否含必拍项（**含则签退前强制拍照**） | 【本期】 |
+| `cancel_reason` | varchar(200) | ○ | 取消原因（`order_status = 已取消` 必填） | 【本期】 |
+| `reschedule_log` | json | ○ | **调单记录**（调过几次、谁调的、为什么） | 【本期】 |
+| `qualification_check` | varchar(20) | **【预留】R2** | 资质校验结果（**本期恒 `unchecked`**） | **【预留】R2** |
+| **`billable`** | tinyint | **【预留】R1** | 可计费标志（**本期恒 1**，不做结算判断） | **【预留】R1** |
+| **`price_snapshot`** | decimal(10,2) | **【预留】R1** | 服务时点价 | **【预留】R1** |
+| **`settle_period`** | varchar(20) | **【预留】R1** | 结算周期（如 `2026-10`） | **【预留】R1** |
+| `exception_flag` | tinyint | **【预留】R6** | 是否异常费用 | **【预留】R6** |
+
+> **⚠️ 一种硬冲突、其余软提示（PRD-02 §B2 落地）**：派单/调单时，**只对"同一 `assignee_id` 且 `time_slot` 重叠"返回硬错误（拒绝保存）**；其余情况（跨区距离远、项目不擅长、当日已排满）**一律只返回提示、不拦**。
+> **理由**：**拦截要准，不能把便利性拦掉。** 组长宁愿微信群说一句就改了，也不会忍受系统处处拦住。
+
+### 3.10 `record` 服务留痕表（③ 履约留痕）
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `record_id` | varchar(32) | ✅ | 留痕 ID | 【系统】 |
+| `order_id` | varchar(32) | ✅ | **来源工单**（L3 硬锁落地） | 【本期】 |
+| `elder_id` / `assignee_id` | varchar(32) | ✅ | 老人／护理员 | 【本期】 |
+| `checkin_time` | datetime | ✅ | **签到时间（系统自动取，不允许手工改）** | 【本期】 |
+| `checkout_time` | datetime | ○ | **签退时间（同上）** | 【本期】 |
+| `duration_min` | int | ○ | 实际时长（＝签退-签到，**系统算，人不能改**） | 【本期】 |
+| `checkin_lat` / `checkin_lng` | decimal(10,6) | ○ | 签到定位（**定位失败不阻塞**，允许空） | 【本期】 |
+| `locate_status` | varchar(20) | ✅ | `ok`／`failed`／`denied`（**失败照常可提交**） | 【本期】 |
+| `record_status` | varchar(20) | ✅ | **留痕状态**：`draft`／`submitted`／`pending_qc`／`passed`／`returned`／`reported` | 【本期】 |
+| `voice_file` | varchar(200) | ○ | 语音备注（免拍档留痕四要素之一） | 【本期】 |
+| `offline_flag` | tinyint | ✅ | 是否离线创建（补传标记） | 【本期】 |
+| `client_md5` | varchar(32) | ✅ | **客户端指纹**（防重复上传、防篡改） | 【系统】 |
+| `submit_time` | datetime | ○ | 提交时间 | 【系统】 |
+| `actual_duration_tier` | varchar(10) | ○ | 时长档位（**<5 分钟标黄**，供质控参考） | 【系统】 |
+
+> **⚠️ 三条硬设计（都是合规点）**：
+> 1. **签到签退时间、时长一律系统取，接口不接受客户端传入的这两个值**——防"补录时间"（对应"不得伪造/变造数据"）；
+> 2. **定位失败不阻塞提交**（`locate_status = failed` 照常落库）——老人家里弱网是常态，**不能因为定位不到就不让干活**；
+> 3. **时长不设"最低时长硬拦"**，只记 `actual_duration_tier`，**由质控看，不由系统罚**（对应 PRD-01 §4.7）。
+
+### 3.11 `record_item` 留痕项目明细表
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `record_item_id` | varchar(32) | ✅ | 主键 |
+| `record_id` | varchar(32) | ✅ | 留痕 ID |
+| `svc_id` | varchar(32) | ✅ | 项目（来自 `plan_item`） |
+| `exec_result` | varchar(20) | ✅ | **执行结果**：`done`（做了）／`undo_not_done`（**本次未执行**）／`undo_refused`（老人拒绝） |
+| `undo_reason` | varchar(100) | ○ | 未执行原因（**选择项，非自由文本**） |
+| `extra_flag` | tinyint | ○ | 是否临时加项（APP M2 §4.6） |
+| `photo_required` | tinyint | ✅ | 本次是否需拍照（由 `photo_tier` 推导） |
+
+> **⚠️ 措辞纪律落到数据层**：`exec_result` 的枚举值**必须是 `undo_not_done`（本次未执行）而不是 `not_done`（未做）**。
+> **理由**：家属端与导出文书都要显示这个状态。**"未做"含指责意味，"本次未执行"是事实陈述**——这条在字段命名层就要卡住，不让前端有机会写"未做"。
+
+### 3.12 `record_photo` 留痕照片表
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `photo_id` | varchar(32) | ✅ | 主键 |
+| `record_id` | varchar(32) | ✅ | 留痕 ID |
+| `svc_id` | varchar(32) | ○ | 关联项目（必拍项时） |
+| `file_path` | varchar(300) | ✅ | 存储路径（**压缩后 ≤500KB**） |
+| `file_size` | int | ✅ | 字节数（校验压缩是否生效） |
+| `visible_to_family` | tinyint | ✅ | **是否对家属可见（本期默认 0）** |
+| `upload_batch` | varchar(32) | ○ | 补传批次号（离线补传用） |
+| `keep_until` | date | ✅ | **保留至（补传后至少 7 天）** |
+
+> **⚠️ `visible_to_family` 本期恒为 0**（PRD-03 §4.2 决策）。**字段先建好**——等用户定了"是否给机构开关"，**只改默认值或加一个开关，不改结构**。
+
+### 3.13 `record_abnormal` 异常上报表
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `abnormal_id` | varchar(32) | ✅ | 主键 |
+| `record_id` | varchar(32) | ✅ | 留痕 ID |
+| `elder_id` / `reporter_id` | varchar(32) | ✅ | 老人／上报人 |
+| `abnormal_type` | varchar(30) | ✅ | **分类（9 宫格，必选）**：皮肤异常/跌倒/呛咳进食/意识精神/发热感染/管路异常/疼痛/排泄异常/其他 |
+| `abnormal_desc` | text | ○ | 描述（**可选**，语音转写或手填） |
+| `voice_file` | varchar(200) | ○ | 语音（可选） |
+| `has_photo` | tinyint | ○ | 是否附照片（可选） |
+| `notify_status` | varchar(20) | ✅ | 通知状态：`pending`／`notified`（**上报后即时推送机构**） |
+| `handle_status` | varchar(20) | ✅ | 处理状态：`new`／`processing`／`handled` |
+| `handle_result` | varchar(200) | ○ | 处理结论 |
+| `link_plan_change` | varchar(32) | ○ | **是否联动变更计划**（指向新 `plan_id`） |
+
+> **⚠️ "一切可选、分类必选"的落地**：**只有 `abnormal_type` 是必填，其余全可选**（PRD-01 §M3）。
+> **理由**：需填会导致"不报"，而"发现了没进系统"是最严重的断链。**宁要一条没人名没照片的异常，也不要一条没报上来的压疮。**
+
+### 3.14 `qc` 质控记录表（④ 质控闸门）
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `qc_id` | varchar(32) | ✅ | 主键 |
+| `record_id` | varchar(32) | ✅ | 被质控的留痕 |
+| `qc_type` | varchar(20) | ✅ | `normal`（常规）／`auto_push`（系统主动推送）／`recheck`（退回后复检） |
+| `push_reason` | varchar(100) | ○ | **推送原因（五类）**：必拍未拍／时长异常／异常上报未处理／住院状态仍有派单／项目数与计划不符 |
+| `qc_result` | varchar(20) | ○ | `passed`（放行）／`returned`（退回） |
+| `qc_note` | varchar(200) | ○ | 质控意见（**退回时必填**） |
+| `qc_staff_id` | varchar(32) | ✅ | 质控员 |
+| `qc_time` | datetime | ✅ | 质控时间 |
+| `pass_time` | datetime | ○ | 放行时间（→ 进上报池，二期） |
+| `first_qc_id` | varchar(32) | ○ | **首次质控 ID**（退回补正后重提，形成链） |
+
+> **⚠️ 全量非抽检（落库层面保证）**：**每一条 `record_status = submitted` 的留痕，都必须生成一条 `qc` 记录**（由定时任务扫描生成，`qc_type = normal`）。
+> **理由**：抽检＝总有漏的；而**"先质控再上报"是国家明文**（PRD-00 hard lock L5）。**全量生成 qc 记录，是把"不抽检"从人工承诺变成数据结构。**
+
+---
+
+## 四、状态机 ↔ 字段值对照（一份表说清"什么状态能干什么"）
+
+### 4.1 待遇状态 `elder.treat_status`（十态）
+
+> **⚠️ 2026-10-12 修订（与 `P0 PRD §3.2／§7.4` 对齐）**：七态 → **十态**，新增 `waiting_period`／`review_waiting`／`transferring`。**本表为分册同源表，改合稿必改此处**（防"合稿改了、分册没改"）。
+
+| 值 | 中文 | 可否新建计划 | 可否派单 | 可否服务 | 可否计费 |
+|---|---|:---:|:---:|:---:|:---:|
+| `pending_file` | 待建档 | ✅ | ❌ | ❌ | ❌ |
+| `waiting_period` | **待起付（等待期/垫付期）** | ✅ | ✅ | ✅（**仅垫付台账**） | ❌ |
+| `active` | 正常享受 | ✅ | ✅ | ✅ | ✅ |
+| `hosp_pause` | 住院暂停 | ❌ | ❌ | ❌ | ❌ |
+| `review_waiting` | **复评等待期** | ❌ | ❌ | ❌ | ❌ |
+| `transferring` | **跨统筹区转移中** | ❌ | ❌ | ❌ | ❌ |
+| `dead` | 死亡 | ❌ | ❌ | ❌ | ❌ |
+| `long_away` | 长期异地居住 | ❌ | ❌ | ❌ | ❌ |
+| `benefit_expired` | 待遇到期 | ❌ | ❌ | ❌ | ❌ |
+| `terminated` | 已终止 | ❌ | ❌ | ❌ | ❌ |
+
+> **接口层强制**：任何创建 `order` 的请求，**先校验 `elder.treat_status ∈ {active, waiting_period}`**，不满足**直接拒绝**（不是警告）。**这就是 L1 的代码落地。** **⚠️ `waiting_period` 是 L1 唯一例外**：允许建 `order`，但其 `record` 打 `is_prepaid=1`、`billable=0`（不进结算池）。
+
+### 4.2 工单状态 `order.order_status`（八态）
+
+| 值 | 中文 | 后续可流转到 |
+|---|---|---|
+| `to_assign` | 待派单 | `assigned` / `cancelled` |
+| `assigned` | 已派单 | `serving` / `cancelled` / `**to_assign**`（调单） |
+| `serving` | 服务中 | `done` / `abnormal` |
+| `done` | 已完成 | —（仅补正留痕） |
+| `abnormal` | 异常 | `done` / `cancelled` |
+| `cancelled` | 已取消 | — |
+| `overdue` | 逾期未做 | → 风险预警 |
+| `not_met` | **未遇（扑空）** | 已到访未服务；到访时间＋定位＋原因必留 → 推组长决策 |
+
+### 4.3 留痕状态 `record.record_status`（六态）
+
+| 值 | 中文 | 说明 |
+|---|---|---|
+| `draft` | 草稿 | 服务中；**离线也在此状态** |
+| `submitted` | 已提交 | 护理员签退提交 |
+| `pending_qc` | 待质控 | 进入质控队列（自动生成 `qc` 记录） |
+| `passed` | 已放行 | 质控通过 → 进上报池〔二期〕 |
+| `returned` | 已退回 | 可补正后重提 |
+| `reported` | 已上报 | 〔二期〕 |
+
+---
+
+## 五、接口契约
+
+> **说明**：本节定义**接口的语义契约**（谁调、传什么、返什么、什么情况拒），**不定义传输协议细节**。三端（APP／后台／家属端）共用同一套后端接口。
+> **统一响应结构**（所有接口）：
+
+```json
+{
+  "code": 0,              // 0=成功；非0=失败（见 5.1 错误码）
+  "message": "成功",       // 面向开发；错误时给可读原因
+  "data": { },            // 业务数据
+  "hint": ""              // ⚠️ 面向用户的"怎么解"提示（硬锁拒绝时必须返回）
+}
+```
+
+### 5.1 统一错误码表（硬锁与业务规则）
+
+| code | 含义 | 前端处置 |
+|:---:|---|---|
+| `0` | 成功 | — |
+| `1001` | **无有效待遇，不可服务**（L1） | 显示 `hint`，禁止进入服务页 |
+| `1002` | **无有效计划，不可派单**（L2） | 引导"先制定计划" |
+| `1003` | **无有效工单，不可录痕**（L3） | 拒绝提交 |
+| `1004` | **留痕不完整，不可进上报池**（L4） | 列出缺什么 |
+| `1005` | **未质控放行，不可上报**（L5） | 提示先质控 |
+| `1006` | **资质不匹配（本期仅提示，不拦截）**（L6） | **仅提示，允许继续** |
+| `2001` | 派单时间冲突（同人同时段重叠） | **硬拒**，提示换人或改时 |
+| `2002` | 计划项目数不满足属地规则 | **仅提示**，可保存 |
+| `3001` | 必拍项未拍照，不可签退 | 硬拒，引导拍照 |
+| `3002` | 定位失败（**非错误，仅标记**） | 允许提交 |
+| `4001` | 越权：非本机构/非本人数据 | 403 |
+
+> **⚠️ `1006` 的设计是刻意的**：**资质校验本期返回一个"提示级"错误码而不是"拒绝级"**。
+> 这样**二期只需把 `1006` 从"提示"改成"硬拒"**，前端代码基本不用动——**这就是"预留位"在接口层的价值**。
+
+### 5.2 本期接口清单（按 P0 四块）
+
+**A · 待遇档案（①）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/elder/create` | POST | 新建老人档案 | 建档时限倒计时；`loc_code` 必填 |
+| `/elder/detail` | GET | 档案详情 | 权限：本机构 |
+| `/elder/status/change` | POST | **变更待遇状态** | **`change_reason` 必填**；写 `elder_status_log` |
+| `/elder/status/log` | GET | 状态变更历史 | 只读 |
+| `/elder/list` | GET | 老人列表（后台 B1） | 支持按待遇状态/护理等级筛 |
+
+**B · 服务计划（②）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/plan/create` | POST | 制定计划 | **项目数按属地规则校验**（`2002` 提示级） |
+| `/plan/change` | POST | **变更计划（新建＋指向旧）** | **不原地改**；旧计划转 `changed` |
+| `/plan/detail` | GET | 计划详情 | 含 `item_list` |
+| `/plan/confirm` | POST | 老人/家属确认 | 可选 |
+| `/svc/local/list` | GET | **按参保地加载属地目录** | 昆明→45项；州市→36项 |
+| `/svc/org/list` | GET | 机构项目库 | — |
+| `/svc/org/config` | POST | 勾选＋配价 | **只允许改 `is_enabled`/`price`** |
+| `/svc/org/new-national` | GET | **国家新增项列表** | 昆明机构**必须显式展示** |
+
+**C · 派单工单（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/order/generate` | POST | 由计划生成工单 | **L2**：无计划拒绝 |
+| `/order/assign` | POST | 派单 | **L1**：待遇非 `active` 拒绝；`2001` 时间冲突硬拒；`1006` 资质提示 |
+| `/order/reassign` | POST | 调单 | 记 `reschedule_log`；**≤3 步** |
+| `/order/batch-recommend` | GET | 批量推荐 | **仅返回推荐，必须人工确认后逐个 assign** |
+| `/order/today` | GET | 护理员今日任务（M1） | 仅本人 |
+| `/order/cancel` | POST | 取消工单 | `cancel_reason` 必填 |
+| `/order/detail` | GET | 工单详情（M4） | 含**注意事项区块** |
+
+**D · 履约留痕（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/record/checkin` | POST | 签到 | **服务器取时间**；定位失败不阻塞（`3002`） |
+| `/record/item/save` | POST | 保存项目执行 | `exec_result` 枚举 |
+| `/record/photo/upload` | POST | 上传照片 | **压缩校验 ≤500KB**；返回 `photo_id` |
+| `/record/checkout` | POST | 签退提交 | **必拍未拍拒绝**（`3001`）；计算时长 |
+| `/record/offline/sync` | POST | **离线补传** | `client_md5` 去重；**静默不弹窗** |
+| `/record/detail` | GET | 留痕详情 | — |
+| `/abnormal/report` | POST | **异常上报** | 仅 `abnormal_type` 必填 |
+| `/abnormal/list` | GET | 异常列表（后台 B4） | 主动推送来源 |
+
+**E · 质控闸门（④）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/qc/pending/list` | GET | 待质控列表（含主动推送） | **全量**，非抽检 |
+| `/qc/detail` | GET | 质控详情 | 含留痕全文与照片 |
+| `/qc/pass` | POST | 放行 | 写 `qc_result=passed`、`pass_time` |
+| `/qc/return` | POST | 退回 | **`qc_note` 必填** |
+| `/qc/exception/link` | POST | **异常联动改计划** | 生成新 `plan_id` 并回填 `link_plan_change` |
+
+**F · 家属端（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/family/bind` | POST | 绑定（姓名＋手机号后4位） | **只看自家** |
+| `/family/elder` | GET | 我家老人信息 | 过滤 `visible_to_family` |
+| `/family/records` | GET | 服务记录列表 | **不返回价格字段** |
+| `/family/ack` | POST | **可选确认** | **非必做，不记录"未确认"为异常** |
+| `/family/feedback` | POST | 反馈 | — |
+
+### 5.3 硬锁在接口层的落点总表（L1–L6）
+
+| 锁 | 接口 | 触发条件 | 结果 |
+|---|---|---|---|
+| **L1** | `/order/assign`、`/record/checkin` | `elder.treat_status ∉ {active, waiting_period}` | `1001` **拒绝**；**`waiting_period` 放行但打 `is_prepaid=1`、不计费** |
+| **L2** | `/order/generate` | 无 `plan_status=active` 的计划 | `1002` **拒绝** |
+| **L3** | `/record/*` | 无有效 `order` | `1003` **拒绝** |
+| **L4** | `/qc/pass` | 留痕缺必填要素 | `1004` **拒绝** |
+| **L5** | `/report/*`〔二期〕 | 无 `qc_result=passed` | `1005` **拒绝** |
+| **L6** | `/order/assign` | `staff.cert_status ≠ valid` | `1006` **仅提示，不拒绝**（**二期改硬拒**） |
+
+---
+
+## 六、⭐ 二期预留位落地对照（R1–R6，逐项核对）
+
+> 对应 PRD-00 §8。**本节证明"只加不改"是可验证的**——二期每项功能，都能在本期表结构里找到它要用的字段。
+
+| # | 二期功能 | 本期已建的字段/表 | 二期要新增的 | **要改的** |
+|:---:|---|---|---|---|
+| **R1** | 结算对账 | `order.billable`／`price_snapshot`／`settle_period`；`svc_org.price` | `settlement` 表（**字段已预定义，见 §6.1**）、申报页、导出格式 | **无** |
+| **R2** | 资质人员 | `staff.cert_*` 五字段；`order.qualification_check` | 到期提醒任务、禁派逻辑、资质管理页 | **无**（`1006` 改硬拒属逻辑开关） |
+| **R3** | 院长看板 | 数据层可直接聚合现有表 | 聚合视图、图表页 | **无** |
+| **R4** | 上报池与接口 | `report` 表；`order`/`plan_item` 的 `official_no`/`loc_code`/代码快照 | 适配层实现、上报页 | **无** |
+| **R5** | 医保状态同步 | `elder.status_source`（人工/接口） | 接口实现 | **无**（只改字段值来源） |
+| **R6** | 异常费用 | `order.exception_flag`／`exception_reason`／`handle_deadline` | 异常处理页、超时提醒 | **无** |
+
+### 6.1 `report` 上报表（本期建表，不写入业务数据）
+
+| 字段 | 类型 | 说明 | 标记 |
+|---|---|---|---|
+| `report_id` | varchar(32) | 主键 | 【系统】 |
+| `record_id` / `order_id` | varchar(32) | 来源 | 【预留】 |
+| `report_status` | varchar(20) | `to_report`／`reported`／`rejected`／`corrected` | **【预留】R4** |
+| `report_time` | datetime | 上报时间 | **【预留】R4** |
+| `official_no` | varchar(50) | **官方受理号** | **【预留】R4** |
+| `loc_code` | varchar(12) | 上报归属统筹区 | **【预留】R4** |
+| `nat_code_snapshot` | varchar(20) | 上报时使用的**国家代码** | **【预留】R4** |
+| `adapter_result` | json | 适配层返回（A/B/C 档） | **【预留】R4** |
+
+### 6.2 `settlement` 结算表（本期建表，不写入业务数据）
+
+| 字段 | 类型 | 说明 | 标记 |
+|---|---|---|---|
+| `settle_id` | varchar(32) | 主键 | 【系统】 |
+| `org_id` / `settle_period` | varchar | 机构／结算周期 | **【预留】R1** |
+| `amount_total` | decimal(12,2) | 申报总额 | **【预留】R1** |
+| `amount_passed` | decimal(12,2) | 审核通过额 | **【预留】R1** |
+| `amount_rejected` | decimal(12,2) | 拒付额 | **【预留】R1** |
+| `submit_date` / `pay_date` | date | 申报日／拨付日 | **【预留】R1** |
+| `exception_reason` | varchar(200) | 差异说明 | **【预留】R6** |
+| `handle_deadline` | date | **说明超时（3 工作日）** | **【预留】R6** |
+
+> **⭐ 这就是"一次设计到位、免得返工"的验证**：二期要做结算，**`settlement` 表的字段今天就定好了**，二期只写页面和申报逻辑，**不碰任何已上线的表**。
+
+### 6.3 接口契约层预留
+
+| 预留项 | 本期定义（写死） | 二期 |
+|---|---|---|
+| **适配层输入输出格式** | **按国家编码规范定稿**（机构编码 13 位 `LH`+区划+序号、人员编码 14 位 `LN`+区划+序号、**项目代码 17 字符**：`L`+`0000`+大类+类别2位+序号2位+`0`+`010000`） | 直接实现 |
+| **A/B/C 三档** | A 人工登记／B 文件导入导出【本期】／C 专线前置机【预留】 | 实现 C 档 |
+| **错误码 `1006`** | **提示级**（不拦） | 改**拒绝级** |
+
+> **⚠️ 项目代码位数说明**：原写"14 位"系归纳有误。**经专项复核定型为 17 字符**，且**仅内部逻辑推演、未与官方原件对照** ⇒ **正式上报前必须以官方电子版核对**。详见《20261011-国家36项代码复核报告（位数问题解构）》。**字段长度一律按 `varchar(20)` 设计，留余量。**
+
+---
+
+## 七、⭐ 数据安全与留痕（合规条款的工程落地）
+
+> 这一节不是"技术选型"，是**政策明文要求在本系统的落地方式**。巡查表"信息管理 15 分"里的实名制、动态管理、材料调取，全都落在这一节。
+
+| 要求（政策） | 工程实现 | 对应巡查点 |
+|---|---|---|
+| **一人一档** | `elder` 表 ＋ 全链路 `elder_id` 外键，`order`/`record`/`qc` 均可回溯到人 | 信息管理 |
+| **实名制管理** | `staff.id_card_no` 加密存储、唯一约束；`user` 绑定 `staff_id` | 信息管理第 1 条 |
+| **不可伪造/变造** | ①`checkin/checkout` 服务器取时；②`elder_status_log` 必填原因；③`record` 软删除不物理删；④`client_md5` 防重复提交 | 巡查高频扣分项 |
+| **记录与计划/数据/考勤相吻合** | `plan_item` → `order.item_list` → `record_item` **三级快照一致**（同一 `svc_id`） | 服务管理 |
+| **材料调取（巡查时能取证）** | 全表导出接口，按老人/时间段/项目导出，**导出即合规版式** | 档案管理 6 分 |
+| **数据保留** | 照片 `keep_until`（补传后 ≥7 天），业务数据软删除保留 | 档案管理 |
+| **隐私号／不展示真实号码** | 家属端接口**一律不返回护理员真实手机号**（扫码端走隐私号，与 C 端口径一致） | 合规红线 |
+
+> **⚠️ 一条容易忽略的工程纪律**：**`record` 与 `qc` 表一律软删除**——`is_deleted` 置 1，**原始记录永久保留**。
+> **理由**：长护险数据是**基金支付凭证**。若允许物理删除，"事后删记录"就变成可能，那就丧失了留痕的意义。**软删除＋软删除也要留操作日志，是"不可无痕修改"的最后一道工程防线。**
+
+---
+
+## 八、⚠️ 与文档/规范的差异与待确认（不阻塞开发）
+
+| # | 事项 | 影响 | 处置 |
+|:---:|---|---|---|
+| 1 | **45↔36 完整逐项映射表**（`svc_mapping` 全量数据） | 昆明机构上报准确性 | ✅ **已完成**，见《20261011-昆明45项↔国家36项-逐项映射表（L3数据·可入库）》（45 行逐项数据）。**遗留风险已转移至下方第 2 项（代码位数）** |
+| 2 | **国家项目代码复核** | 上报字段准确性 | ✅ **已完成内部复核**（位数问题已解构，规则定型 17 字符，3 项短形态已补正）——见《20261011-国家36项代码复核报告（位数问题解构）》。⚠️ **仍须官方电子版最终确认**（复核为逻辑推演，非原件对照）；字段按 `varchar(20)` 设计 |
+| 3 | 各州市 `loc_config` 是否另有自建目录 | 属地目录库内容 | 签约前逐一核实（推定＝36 项） |
+| 4 | 昆明 45 项是否已更新 | 属地目录库内容 | 建议 0871-65919196 核实 |
+| 5 | 照片**保留期限**（政策要求 vs 机构成本） | 存储策略 | 有地方要求"保存 10 年"；建议按属地要求配置化，**不当统一硬编码** |
+
+> **⚠️ 处置原则**：**这 5 项都不阻塞开发启动**——前 4 项是"数据内容"和"配置值"，不是"结构"；**唯第 2 项须在真正对接上报前收口**（因上报字段错＝功能不可用），但**不影响 P0 四块的开发**（P0 不含上报）。
+
+---
+
+## 九、本份交付说明
+
+### 9.1 本文档定义了什么
+
+- 22 张表清单与用途
+- **6 张核心表的完整字段定义**（老人档案／计划／工单／留痕／质控／机构）
+- **服务项目四层表（L1–L4）字段结构**
+- 状态机 ↔ 字段值对照（待遇／工单／留痕）
+- **统一响应结构与错误码表**（含 L1–L6 落点）
+- **本期接口清单 6 组 40+ 接口**
+- **R1–R6 二期预留位的逐项落地对照**
+- 数据安全与留痕的工程实现（政策条款 → 代码）
+
+### 9.2 下一步可做
+
+| 序 | 文档 | 内容 |
+|:---:|---|---|
+| 1 | **45↔36 完整映射表**（数据表） | 补 §8 第 1 项，昆明每一项对应到国家项目 |
+| 2 | 界面线框稿 | 把 PRD 页面画成可看的样子 |
+| 3 | 开发排期与模块拆分 | 按 P0 四块拆开发任务 |
+
+---
+
+**云南投云科技有限公司**
+编制：滇小构｜2026-10-11（第 4 步 · 数据字典与接口契约 · 待确认）
diff --git a/docs/requirements/20261011-投云长护险管理系统-P0 PRD（交付开发·V1）.md b/docs/requirements/20261011-投云长护险管理系统-P0 PRD（交付开发·V1）.md
new file mode 100644
index 0000000..80b0130
--- /dev/null
+++ b/docs/requirements/20261011-投云长护险管理系统-P0 PRD（交付开发·V1）.md	
@@ -0,0 +1,2027 @@
+# 投云长护险管理系统 · P0 PRD
+
+**交付版本 · 2026-10-11 · 云南投云科技有限公司**
+
+> **📝 修订注（2026-10-12 · R1–R9 质疑回填）**：依机构老板 22 条质疑，**把产品能改的直接写进需求**，做不到的如实标注。**改动清单**：①§3.2 待遇状态 **七态 → 十态**（新增 `待起付/等待期`、`复评等待期`、`跨统筹区转移中`；`住院暂停` 补恢复出路）；②§3.2 工单状态 **七态 → 八态**（新增 `未遇/扑空`）；③新增 **§4.5.1 拒拍出路**、**§4.5.2 拍照分档属地核对**、**§4.9.1 扑空专门形态**；④§5.5.1 新增 **B1-A 垫付台账与结转**、**B1-B 批量导入**；⑤§7.4 字段对照同步＋新增 6 个字段；⑥§8.1 新增 `3003/3004` 错误码；⑦新增 **§十三 质疑回填记录**（能改的 vs 做不到的分开列）；⑧新增 **§7.3.1 多业务线扩展（R8 预留）**＋`elder/order/svc_org` 三表加 `biz_line` 字段（本期恒 `ltci`）、§8.4 增 R8 行；⑨新增 **§13.2b 待补清单（P-9 身份核验缺口）**＋§14 增第 8 条对客边界；⑩新增 **§5.5.2 老人个人项目库（`elder_svc` 表，R10）**＋§7.2 增 `elder_svc` 表（**22 表 → 23 表**）＋§7.4 增 2 个字段＋§8.3 增 2 个接口＋§9 增验收项。**逐条依据见 §十三。** 其余章节逐字保留。
+
+> **📝 修订注（2026-10-14 · 居家护理六流程对齐 · 只补字段不动交互）**：依《居家护理》六份流程文档（流程 01–05＋4.5）与 PRD 交叉核对，**补齐流程文档已明确、但 PRD 数据字典缺字段的 5 处硬缺口**（**只补字段、不做功能**，交互细则后补）：①`record` 表补 `biz_line` 字段（R8 从三表扩到四表，自费单独计时落点）；②`elder` 表补参保核验留痕（`insur_verify_status`/`insur_verify_date`）＋缴费年限（`insur_years`）＋上门评估五块信息（`need_assess` JSON）；③`plan` 表补 `plan_basis`（计划依据/护理服务建议）；④`settlement` 表补 `amount_fund`/`amount_self_pay`（个人自付拆分）。**自费服务（当场收款/同意凭证）本期不做、只留字段**（与 §11.2「平台不碰资金」红线一致）。
+
+---
+
+## 〇、怎么用这份文档（开发先看这里）
+
+| 项 | 说明 |
+|---|---|
+| **这份文档是什么** | **本期要开发的东西，全在这里，不用再看别的文档。** 前面的 PRD-00～03、数据字典与接口契约，内容已全部并入本文档 |
+| **本期范围** | **P0 四块**：①待遇档案／②派单工单／③履约留痕／④质控闸门。**二期三块（结算对账／资质人员／院长看板）不做，只留字段** |
+| **本期要交付几个端** | **三个端 ＋ 一套后端**：护理员 APP（安卓）／机构管理后台（Web）／家属端（微信公众号 H5） |
+| **设计总纲（一句话）** | **既满足长护险政策要求，又让机构用得方便、不复杂。两者冲突时——换实现方式，不砍合规、不逼一线硬扛。** |
+| **文档结构** | 第一～三章＝全局规则（三端通用）；第四～六章＝三个端各自的页面；第七章＝数据库；第八章＝接口；第九章＝验收；第十章＝不做什么 |
+
+### 0.1 先记住这五条，能少走一半弯路
+
+1. **硬锁要"点不动"，不要"弹提醒"**——提醒会被忽略，点不动才会被遵守。
+2. **锁得少、锁得准**——只锁政策明文要求的，日常照护一律宽松。
+3. **必填自由文本 = 0**——护理员端不许有任何必须打字的字段。
+4. **状态靠人工维护**——本期**没有**医保接口，别按"能自动感知状态"来设计。
+5. **属地差异走配置、不走代码**——新增一个州市＝加配置数据，**不改代码、不发版**。
+
+### 0.2 术语与技术口径对齐（防歧义）
+
+| PRD 里的中文 | 技术口径 |
+|---|---|
+| 老人档案 | `elder` 表，主键 `elder_id` |
+| 服务计划 | `plan` / `plan_item` 两张表 |
+| 工单 | `order` 表，一次服务一条 |
+| 服务留痕 | `record` ＋ `record_item` ＋ `record_photo` ＋ `record_abnormal` |
+| 质控记录 | `qc` 表（可多次退回补正，留历史） |
+| 服务项目 | `svc_national`(L1) / `svc_local`(L2) / `svc_mapping`(L3) / `svc_org`(L4) |
+| 人员与资质 | `staff` 表【预留】 |
+
+> **⚠️ 命名纪律（写死）**：**不得使用 `checkin`／`clockin`／`punch` 作为留痕表名**——留痕＝`record`。这是合规口径在代码层的落地（不做打卡工具）。
+
+---
+
+## 一、全局术语与分期用语
+
+### 1.1 业务对象术语（全系统统一，不得混用）
+
+| 术语 | 定义 | 禁止的说法 |
+|---|---|---|
+| **参保人** | 参加长护险的人员（政策用语） | 不说"客户""用户" |
+| **待遇享受对象** | 已通过评估、正在享受待遇的参保人 | — |
+| **服务对象 / 老人** | 机构实际提供护理服务的人（**界面用"老人"更亲和**） | 正式文书用"参保人" |
+| **护理员** | 执行上门/院内护理服务的一线人员 | 正式文书用"护理服务人员" |
+| **服务项目** | 长护险目录内的护理项目（核心主数据） | 不说"服务内容""护理项" |
+| **服务计划** | 针对某位老人、由机构制定并经确认的周期服务安排 | 不说"护理方案" |
+| **工单** | 计划落地后生成的一次具体服务任务 | 不说"订单""派工单" |
+| **留痕** | 服务执行过程的记录（签到、项目、时长、语音、照片、异常） | **不说"打卡记录"** |
+| **异常上报** | 服务现场发现问题的上报（压疮、呛咳、跌倒等） | 不说"报警" |
+| **质控放行** | 质控员审核后允许该记录进入上报流程 | 不说"通过审核" |
+| **上报池** | 已质控放行、待上报医保的记录集合（**二期**） | — |
+
+### 1.2 分期用语（对客材料必须区分）
+
+| 说法 | 含义 |
+|---|---|
+| **首期 / P0** | 本次交付的四块 |
+| **二期 / P1** | 结算对账、资质人员、院长看板 |
+| **预留位** | 数据结构与接口已留好，**功能未开发** |
+
+---
+
+## 二、⭐⭐ 多属地规范（本系统最大的架构特征）
+
+> **背景**：**云南实行州（市）级统筹**（云政办规〔2025〕9 号原文），每个州市是**独立统筹区**。系统必须**同时服务昆明机构与其他州市机构**。
+
+### 2.1 属地目录两类（规则只有两句）
+
+| 地区类型 | 服务项目目录 | 项目数 | 官方代码 |
+|---|---|:---:|:---:|
+| **新建制州市**（曲靖/玉溪/楚雄/文山/西双版纳/大理/临沧 等） | **国家统一目录** | 36 | ✅ 有 |
+| **昆明市**（老试点） | **本地目录** | 45 | ❌ 无 |
+
+> **⚠️ 推定项纪律**：七州市中**仅西双版纳有原文明确**"执行国家统一的长护险服务项目目录"；其余 6 个州市为**推定**。**签约前须向属地医保机构逐一核实**，不得在正式对客材料中当既定事实写。
+
+### 2.2 目录四层结构（数据模型基础）
+
+| 层 | 编号前缀 | 内容 | 维护方 | 机构可见 | 可修改 |
+|---|---|---|---|---|---|
+| **L1 国家基准库** | `NAT_` | 国家 36 项 ＋ 官方项目代码 | 我方 | 只读 | ❌ |
+| **L2 属地目录库** | `LOC_` | 每统筹区一套（昆明 45 项；州市直接引用 L1） | 我方 | 只读 | ❌ |
+| **L3 属地↔国家映射表** | `MAP_` | 昆明 45 ↔ 国家 36 逐项映射 | 我方 | **不可见** | ❌ |
+| **L4 机构项目库** | `ORG_` | 机构勾选的项目 ＋ 自填价格 | **机构** | 机构自管 | ✅ 仅价格与启用状态 |
+
+### 2.3 属地加载规则（机构无感知）
+
+```
+① 机构注册 → 必填【参保地 / 统筹区】
+        ↓
+② 系统自动加载该统筹区的 L2 属地目录
+        ↓
+   州市机构：看到国家 36 项（含代码）
+   昆明机构：看到本地 45 项（系统已内置 L3 映射）
+        ↓
+③ 机构在属地目录中【勾选】本机构开展的项目 → 【配价】→ 形成 L4 机构项目库
+        ↓
+④ 派单时 → 读 L4（机构实际开展的项目）
+   上报时 → 读 L3 转换出的国家代码（二期对接时生效）
+```
+
+### 2.4 ⭐ 五条多属地纪律（写死）
+
+1. **属地差异走配置、不走代码**——新增州市＝加一份 L2 配置，**不改代码、不发版**；
+2. **属地项目必须可映射**——L2 中每一项都必须在 L3 里有映射；**昆明 45 项中无法映射国家的 5 项，标注"仅属地执行、不可按国家目录上报"**；
+3. **机构不可改目录、不可自创项目**——只能选用＋配价。**改目录＝合规事故**；
+4. **国家新增项必须显式提示**——昆明目录里没有、国家目录里有的 5 项（**吞咽功能训练／言语功能训练／雾化吸入／压疮预防照护及指导／理发**），在昆明机构勾选界面**必须显式列出并标注"过渡期新增·建议纳入"**，**不得因为本地目录没有就默认隐藏**；
+5. **映射表不进对客材料**——L3 是我方技术资产，对客只说"预置属地目录＋国家目录，自动映射"。
+
+> **⭐ 昆明 45 项 ↔ 国家 36 项映射统计（已逐项核过）**：完全对应 **19** 项／被合并 **15** 项／近似对应 **6** 项／仅属地 **5** 项 ＝ 45。L3 全量数据见《20261011-昆明45项↔国家36项-逐项映射表》。
+
+### 2.5 ⭐ 服务计划的项目数量规则（属地差异，必须内置）
+
+| 地区 | 护理方式 | 一级护理 | 二级护理 | 三级护理 | 附加 |
+|---|---|:---:|:---:|:---:|---|
+| **昆明** | 医养结合机构 | ≥18 项 | ≥15 项 | ≥13 项 | 可再选 ≤5 项 |
+| **昆明** | 养老机构 | ≥18 项 | ≥15 项 | ≥13 项 | 可再选 ≤5 项 |
+| **昆明** | 居家（机构上门） | 每周 ≥6 次／月 ≥40 小时 | 每周 ≥5 次／月 ≥36 小时 | 每周 ≥4 次／月 ≥32 小时 | — |
+| **昆明** | 居家（个体护理人员） | ≥15 项 | ≥13 项 | ≥10 项 | 可再选 ≤5 项 |
+| **州市** | 按属地实施细则配置 | **本期不校验** | **本期不校验** | **本期不校验** | — |
+
+> **⚠️ 州市规则本期怎么做（已定，写死）**：**州市机构本期不做项数校验**——界面只提示"**州市项数规则待属地实施细则明确**"，**不拦、不卡**。
+> **理由**：①各州市实施细则尚未发布，规则无从谈起；②国家 36 项**没有**"一级≥18 项"这类表述，它与昆明 45 项的颗粒度对不上，**照搬昆明＝给了错规则**；③项数规则是**配置数据不是代码结构**，细则出来后**补一份配置即可，不改代码、不发版**（属地差异走配置的既定纪律）。
+> **⚠️ 不得的做法**：**不得把昆明规则（18/15/13）照搬给州市机构**——给错规则比不给更糟。
+
+> **⚠️ 等级方向（全系统必须写清，不得省略）**：昆明口径**"重度失能一级＝失能等级最高级，一级护理＝护理级别最高级"**。
+> ⇒ **一级护理要求最高**（≥18 项／每周 6 次），与"一级最轻"的直觉**相反**。**界面上必须写"一级护理（最高级）"，不得只写"一级护理"。**
+
+---
+
+## 三、数据主干、状态机、硬锁、权限
+
+### 3.1 数据主干（五个核心对象的关系）
+
+```
+        ┌─────────────┐
+        │  ① 老人档案  │  ← 待遇状态（有效期、护理等级、参保地）
+        │  ELDER      │
+        └──────┬──────┘
+               │ 1 : N
+        ┌──────▼──────┐
+        │  ② 服务计划  │  ← 周期、项目清单、频次、时长、三方确认
+        │  PLAN       │
+        └──────┬──────┘
+               │ 1 : N
+        ┌──────▼──────┐
+        │  ③ 工单      │  ← 某天某次某项目、派给谁、状态
+        │  ORDER      │
+        └──────┬──────┘
+               │ 1 : 1
+        ┌──────▼──────┐
+        │  ④ 服务留痕  │  ← 签到/签退、时长、语音、照片、项目执行
+        │  RECORD     │
+        └──────┬──────┘
+               │ N : 1（汇总）
+        ┌──────▼──────┐
+        │  ⑤ 质控记录  │  ← 审核结论、放行/退回、异常处理
+        │  QC         │
+        └─────────────┘
+
+   横向：⑥ 人员与资质（〔二期〕，本期=人工登记）
+   出口：⑦ 上报池 → 结算对账（〔二期〕）
+```
+
+**三条数据铁律**：
+1. **一次录入、三端同源**——同一事实只录一次，不在别处手工重填；
+2. **不可无痕修改**——任何修改留补正痕迹、保留原值；
+3. **属地字段贯穿**——每个老人档案必带**参保地**，全链路据此取目录与规则。
+
+### 3.2 状态机（三个核心对象）
+
+**① 老人档案 · 待遇状态（十态）**
+
+> **⭐ 2026-10-12 修订（R2·质疑回填）**：原七态，**新增三类真实业务态**——`待起付/等待期`、`复评等待期`、`跨统筹区转移中`，并把 `住院暂停` 补上"恢复"出路。**每一态都必须明确三件事：能否派单 / 能否计费 / 如何恢复**（见下表末三列），避免"状态定义不清 ⇒ 误拦正常业务"。
+
+| 状态 | 触发 | 系统动作（硬锁） | 可否派单 | 可否计费 | 如何恢复 |
+|---|---|---|:---:|:---:|---|
+| **待建档** | 签约后未建档 | 提醒倒计时（签约后 1 个月内）；超期标红 | ❌ | ❌ | 建档完成 ⇒ 转 `正常享受` |
+| **待起付（等待期/垫付期）** | 待遇已受理、**6 个月等待期未满** | **允许录服务（进"垫付期服务台账"）、不计费**（见 §5.5.1 B1-A） | ✅ | ❌ | 等待期满、待遇生效 ⇒ **勾选"结转"** 转 `正常享受`（原垫付记录保留） |
+| **正常享受** | 待遇有效期内 | 允许建档、计划、派单、服务 | ✅ | ✅ | — |
+| **住院暂停** | 老人住院 | ⚠️ **L1 生效：不可新增服务、不可计费**；已有服务保留 | ❌ | ❌ | **出院后人工确认 ⇒ 走"恢复"流程**，校验待遇仍有效 ⇒ 转 `正常享受` |
+| **复评等待期** | 待遇到期、**复评结论未出** | 停止新增服务；**保留已有记录、提示续评进度** | ❌ | ❌ | 复评结论出 ⇒ 按新等级转 `正常享受` 或 `已终止` |
+| **跨统筹区转移中** | 老人**参保地变更**（如昆明→玉溪） | **冻结派单**；触发**目录切换预览**（旧 45 项 → 新属地目录）；历史记录**全保留** | ❌ | ❌ | 新参保地确认 ⇒ **重载属地目录** + 重制服务计划 ⇒ 转 `正常享受`（旧记录只读留档） |
+| **死亡** | 老人去世 | 终止一切服务流程；档案转存档 | ❌ | ❌ | 不可恢复 |
+| **长期异地居住** | 迁居外地 | 暂停服务 | ❌ | ❌ | 回迁 ⇒ 人工确认 ⇒ `正常享受` |
+| **待遇到期** | 待遇有效期届满 | 停止新增服务；提示续评 | ❌ | ❌ | 续评通过 ⇒ `正常享受`；未续 ⇒ `已终止` |
+| **已终止** | 协议终止 | 只读归档 | ❌ | ❌ | 不可恢复 |
+
+> **⚠️ 状态变更靠人工维护（本期）**：**首期不做医保状态自动同步**（省级接口规范未发布）。系统**只能"提醒该核状态＋录后拦派单"，不能替代机构发现状态变化**。此条必须写进对客边界说明。**上表"如何恢复"均为"人工确认后系统放行"，不是系统自动发现。**
+
+> **⭐⭐ 关于"等待期/垫付期"的设计要点（2026-10-12 新增）**：
+> - **为什么要这个态**：长护险有 **6 个月等待期**，机构常在等待期内先垫钱上门。**这段时间的服务"录得进、留得住痕、但不计费"**——若不给状态而一律按"无有效待遇"拦（L1），等于把最需要凭证的一段变成纸面空白。
+> - **与 L1 的关系**：L1（`1001` 无有效待遇不可服务）**只拦"要计费的在享服务"**；`待起付` 态走**独立形态的垫付台账**，**不被误拦**。
+> - **不自动转正**：等待期满**不自动**把垫付记录转为正式记录（计费规则不同，自动转＝埋合规雷）；改由机构**勾选 + 一键结转**（见 §5.5.1 B1-A）。
+
+**② 工单状态（八态）**
+
+| 状态 | 说明 | 可否编辑 |
+|---|---|---|
+| **待派单** | 计划已生成工单，未指定护理员 | ✅ |
+| **已派单** | 已指定护理员 | ✅ 可调整（调单） |
+| **服务中** | 护理员已签到 | ❌ |
+| **已完成** | 已签退并留痕 | ❌（仅补正） |
+| **异常** | 服务中上报异常 | ❌ |
+| **已取消** | 请假/轮岗等取消 | ❌（留取消原因） |
+| **逾期未做** | 过了服务时段仍无记录 | ❌（进风险预警） |
+| **未遇（扑空）** | **已到访但未能服务**（老人不在家/拒绝服务/临时改期） | ❌（**到访时间＋定位＋原因必留**，见 §4.9.1） |
+
+> **⭐ 2026-10-12 新增「未遇（扑空）」态**：原口径下"白跑一趟"只能靠**口头说明**，**无佐证 ⇒ 巡查看作"空单废单"**，有被判"虚假服务"的风险。新增此态后，**"到了、没人、怎么处理"三件事都留痕**，把"白跑"从"说不清"变成"有据可查"。**它是异常上报的一个专门子类，不是新流程。**
+
+**③ 留痕与质控状态**
+
+| 状态 | 说明 |
+|---|---|
+| **草稿** | 服务中未提交（离线也在此状态） |
+| **已提交** | 护理员签退提交 |
+| **待质控** | 进入质控队列 |
+| **已放行** | 质控通过 → 进上报池〔二期〕 |
+| **已退回** | 质控退回，护理员可补正 |
+| **已上报** | 〔二期〕 |
+
+### 3.3 六条硬锁（本期实现口径，含降级说明）
+
+| # | 硬锁 | 本期实现 | 说明 |
+|---|---|---|---|
+| **L1** | 无有效待遇 → 不能建档/服务 | ✅ **点不动** | 状态人工维护，系统不感知变化。**⚠️ 例外：`待起付（等待期）` 态允许服务，但走垫付台账、不计费**（见 §3.2、§5.5.1 B1-A） |
+| **L2** | 无服务计划 → 不能生成工单 | ✅ **点不动** | — |
+| **L3** | 无有效工单 → 不能录入留痕 | ✅ **点不动** | — |
+| **L4** | 无完整留痕 → 不能进上报池 | ✅ **点不动** | 上报池本身为二期 |
+| **L5** | 无质控放行 → 不能上报 | ✅ 本期以"放行"为准 | 上报动作在二期 |
+| **L6** | 无有效资质 → 不能派该项目的单 | ⚠️ **本期降级：人工登记＋派单提示** | **本期不做自动禁派**；二期升级为**自动拦截** |
+
+> **⚠️ L6 的对客口径（必须逐字使用）**：
+> **"『无资质不派单』是政策硬要求，但资质库在二期。首期处理方式是『人工登记＋派单时系统提示』，不是自动禁派。二期升级为自动拦截。"**
+> **对客材料不得写"系统自动禁派"**——本期做不到。
+
+**硬锁的设计纪律**：
+1. **"点不动"优先于"弹提醒"**；
+2. **只锁政策明文要求的 6 条**——日常照护记录方式**一律宽松**；
+3. **锁的位置要"最早"**——在流程起点拦，不在终点拦；
+4. **拦截必须给"怎么解"**——不能只说"不能做"，要说"先做什么才能做"（接口的 `hint` 字段）。
+
+### 3.4 角色与权限
+
+**角色定义**
+
+| 角色 | 谁 | 主要场景 |
+|---|---|---|
+| **护理员** | 一线服务人员 | 手机 APP：看任务、干活、留痕 |
+| **组长 / 主管** | 排班与派单负责人 | 后台：排班、派单、调单 |
+| **质控员** | 服务质量把关人 | 后台：建档、计划、审核、异常处理 |
+| **院长** | 机构负责人 | 后台：查看（**本期无看板，只见列表**） |
+| **家属** | 老人家属 | 公众号：查看、可选确认 |
+| **机构管理员** | 系统配置人 | 后台：机构信息、账号权限、属地配置 |
+
+**权限矩阵（五角色 × 本期操作）**
+
+| 操作 | 护理员 | 组长 | 质控员 | 院长 | 家属 |
+|---|:---:|:---:|:---:|:---:|:---:|
+| 查看今日任务 | ✅ 自己 | ✅ 本组 | ✅ 全部 | ✅ 全部 | — |
+| 签到／签退／录服务 | ✅ | ✅ | — | — | — |
+| 上报服务异常 | ✅ | ✅ | ✅ | — | ✅ 可反馈 |
+| 老人建档 | — | — | ✅ | — | — |
+| 制定/变更服务计划 | — | ✅ | ✅ | — | — |
+| 排班派单／调单 | — | ✅ 本组 | ✅ 全部 | — | — |
+| 质控审核／放行 | — | ✅ 本组 | ✅ 全部 | — | — |
+| 机构项目库配价 | — | — | ✅ | — | — |
+| 查看服务记录 | 自己 | 本组 | 全部 | 全部 | **仅自家老人** |
+| 人员资质维护 | — | — | 〔二期〕 | — | — |
+| 结算申报／对账 | — | — | 〔二期〕 | 〔二期〕 | — |
+| 经营看板 | — | 〔二期〕 | 〔二期〕 | 〔二期〕 | — |
+
+**三条权限原则（写死）**：
+1. **最小必要**——护理员只能看/操作**派给自己的任务**；
+2. **家属只见自家、默认只读**；
+3. **院长不改数据**——院长**不设任何数据修改权限**（后端在所有写接口上一律返回 403）。
+
+> **⚠️ 第 3 条的修正（详见下方补充 2）**：上述"院长写接口 403"**修正为"仅当账号只持 `director` 时 403"**；**若同时持 `qc`／`leader`／`admin`，按角色并集放行**。**"院长不改数据"的本意是"不许凭身份直接改记录"，不是"院长永远不能写"**——院长要能配账号（`admin`）、兼质控时审记录（`qc`）。两处必须一起读。
+
+#### 3.4.1 角色补充说明（四条，开发按此实现，不得自行发挥）
+
+> **为什么单列这一节**：上面那张矩阵是"业务操作视角"，开发照着做还差四件事没说清——**机构管理员归谁管、一个人能不能兼多个角色、敏感字段谁能看、什么叫"本组"**。这四条**逐条定死**，不留解释空间。
+
+---
+
+**补充 1｜机构管理员（`admin`）的归属与权限**
+
+| 项 | 规定 |
+|---|---|
+| **它是不是一个独立岗位** | **不是**。它是**"系统配置权限"**，不是业务角色 |
+| **本期由谁担任** | **本期默认由院长（`director`）兼任**——即院长账号同时持有 `director` + `admin` 两个角色（见补充 2） |
+| **它能做什么** | 后台：**机构信息维护、账号新增/停用、角色分配、属地配置**（＝B8 系统设置全部） |
+| **它不能做什么** | **不得触碰任何业务数据**（不建档、不定计划、不派单、不审记录）——**配置权与业务权分离**，防止"改配置绕过硬锁" |
+| **单人机构怎么办** | 若机构只有一人（个体护理人员），**该账号可同时持 `admin` + `qc`**；**但其自身录入的业务记录仍须由他人质控**（见补充 2 末尾例外条） |
+
+> **⚠️ 落地纪律**：`admin` **只在后台"系统设置"菜单可见**；持 `admin` 但未持 `qc`／`leader` 的账号，**登录后看不到 B1–B4 业务菜单**。
+
+---
+
+**补充 2｜一人多角色规则（小机构必需）**
+
+| 项 | 规定 |
+|---|---|
+| **能不能一人多角色** | **能**。**小机构"院长兼质控""组长兼质控"是常态**，不允许多角色＝系统用不起来 |
+| **数据怎么存** | `user.role` **改为可存多值**：**逗号分隔字符串**（如 `director,admin`／`leader,qc`）；**字段长度 varchar(50)**（足够 5 个角色） |
+| **权限怎么算** | **取并集**——某人持多个角色，则**拥有各角色权限的合并**（如"组长+质控"＝能派单**且**能审记录） |
+| **切换角色？** | **不做**。按当前账号**全部角色**计算，**本期不做角色切换器**（避免复杂） |
+| **⚠️ 唯一例外（重要）** | **禁止"自审自放行"**：**同一账号录入的服务记录，不得由该账号自己质控放行**——系统须校验 `record.created_by ≠ qc.operator_id`，否则返回 **`4001`**。<br>**为什么**：这是**"先质控再上报"铁律**的底线，**不因"小机构人手少"而放宽**；机构若只有一人，**必须再配一个能审的人**（哪怕兼职），否则**该记录无法进上报池** |
+| **院长兼质控时，写接口还 403 吗** | **不返回**。按**角色并集判权，不按"院长"身份一刀切** |
+
+---
+
+**补充 3｜字段级权限（敏感信息谁能看）**
+
+> 矩阵只到"操作级"（能不能建档），但**同一张档案里不同字段敏感度不同**。以下**三个字段**必须做**字段级控制**：
+
+| 字段 | 所属表 | 谁能看 | 规则 |
+|---|---|---|---|
+| **身份证号** `id_card_no` | `staff`／`elder` | **仅 `admin` 与 `qc`** | 列表页**一律掩码**（如 `5301**********1234`）；**点"查看完整"才明文**，且**每次查看留痕**（谁、何时、看了谁的） |
+| **手机号** `phone` | `staff`／`elder` | **`admin`／`qc`／`leader`（仅本组）** | 护理员端**只显示"姓氏+称呼"**，**不显示任何手机号**；家属端**一律不返回护理员手机号**（走机构统一联系） |
+| **服务照片** `record_photo` | 留痕 | **`qc`／`leader`（本组）／护理员看自己**；**`director` 可看** | **家属端本期一律不展示**（`visible_to_family` 恒 0） |
+
+> **⚠️ 两条落地纪律**：
+> ① **掩码在服务端做，不在前端做**——前端掩码＝明文已下发到浏览器，等于没掩码；
+> ② **明文查看必须留痕**（写操作日志表）——对应巡查表·信息管理第 4 条"数据不出机构、访问可追溯"。
+
+---
+
+**补充 4｜"本组"的定义（组织架构）**
+
+| 项 | 规定 |
+|---|---|
+| **"本组"指什么** | **一个"护理组"**＝**1 名组长 + N 名护理员**，是**派单与质控的最小单位** |
+| **本期怎么建组** | **不单独建"组"表**。**改为**：`staff` 表增加字段 **`group_leader_id`**（该护理员归属的组长），**由 `admin` 在人员管理里指定** |
+| **组长看 "本组" 怎么算** | 组长登录 → **查 `staff` 表中 `group_leader_id = 本人 staff_id` 的护理员** → **只看这些人的任务与记录** |
+| **质控员看 "全部"** | `qc` **不受组限制**，**看本机构全部** |
+| **组长兼质控** | 按**权限并集**——**既是本组组长（管本组派单），又是质控员（审全部记录）** |
+| **没有组长的机构** | **允许为空**——若机构不分组，护理员 `group_leader_id` **留空**，此时**只有 `qc`／`admin` 看全部**；**`leader` 看不到任何人**（提示"您尚未被指派组员，请联系管理员"） |
+
+> **⭐ 为什么用 `group_leader_id` 而不建"组表"**：**本期是单机构、组数少、结构简单**，一个外键字段就够；**建组表＝多一张表、多一套增删改查界面**，**本期不值当**。二期若做"多机构/连锁"（P2），**再升级为独立组织架构模块**——**迁移路径已留**（把 `group_leader_id` 升格为 `group` 表 + 关系表即可，不影响已有数据）。
+
+---
+
+**补充小节汇总（开发速查）**
+
+| # | 事项 | 一句话结论 |
+|:---:|---|---|
+| 1 | 机构管理员归谁 | **不是独立岗位**，本期由**院长兼任**；只管配置、不碰业务 |
+| 2 | 一人多角色 | **允许**，`user.role` 存多值、**权限取并集**；**唯一禁止"自审自放行"**（`4001`） |
+| 3 | 字段级权限 | **身份证仅 admin/qc 明文可见且留痕**；**手机号与照片按端控制**；**掩码在服务端做** |
+| 4 | "本组"定义 | **1 组长 + N 护理员**；**用 `staff.group_leader_id` 实现，不建组表** |
+
+
+
+---
+
+## 四、护理员移动端 APP（P0 主战场：③履约留痕）
+
+> **形态**：**独立 APP**（安卓为主），**我方统一上架**。
+> **一句话设计目标**：**让一个 50 岁上下、不擅长智能手机的护理员，在老人家里、可能没网的情况下，不学就会、不误操作地完成一次服务记录。**
+
+### 4.1 用户画像（**有据可查，非臆测**）
+
+| 项 | 数据 | 来源 |
+|---|---|---|
+| 年龄 | **40–59 岁占 83.25%**，30 岁以下仅 2% | 《2025 养老护理员职业现状调研报告》 |
+| 学历 | 初中及以下 **56.13%** | 《2024 报告》 |
+| 性别 | 女性 **89.25%** | 《2025 报告》 |
+| 使用障碍 | 中老年 **82.9% 有使用障碍、仅 24.44% 能独立操作** | CNNIC 第 56 次报告 |
+| 官方自陈 | 昆明医保局承认护理员"**年龄偏大、智能设备操作困难**" | 昆明市医保局公开材料 |
+
+**⇒ 设计含义**：**这个群体"学不会"不是态度问题，是能力现实**。任何需要"培训才会用"的设计，都是失败的设计。
+
+**三条不可协商的原则**：
+1. **不为留痕而留痕**——记录必须对护理员**自己也**有用；
+2. **不是增加一个系统，是减少她要开的**——替代纸质本、微信群汇报；
+3. **不许比现在更慢**——比现有习惯慢的操作，两周内会被绕过。
+
+### 4.2 页面地图（5 个页面，不再多）
+
+| 序 | 页面 | 一句话职责 | 进入方式 |
+|:---:|---|---|---|
+| **M1** | **今日任务**（首页） | 今天去哪几家、几点、做什么 | 打开 APP 直接进 |
+| **M2** | **服务执行** | 签到 →（干活）→ 签退，勾项目 | 点 M1 的卡片进入 |
+| **M3** | **异常上报** | 一键上报压疮/呛咳/跌倒等 | M2 内入口＋M1 底部 |
+| **M4** | **任务详情** | 老人情况、服务计划、注意事项 | M1 卡片长按/侧滑 |
+| **M5** | **我的** | 我的工时、我的消息、我的资质 | 底部第二栏 |
+
+> **⚠️ 刻意不做**：统计报表、排班管理、对话聊天、打字录入、消息广场、积分排名。
+> **底部导航只有两栏**：📋 任务（默认）／👤 我的。**不做第三栏。**
+
+### 4.3 M1 今日任务（首页）
+
+```
+┌───────────────────────────────────────┐
+│  今天 10月11日 周六          [王大娘]  │  ← 顶部：日期 + 我的名字（大字）
+├───────────────────────────────────────┤
+│  ┌─────────────────────────────────┐  │
+│  │ ⏰ 09:00  李奶奶家               │  │  ← 任务卡片（大卡）
+│  │ 翻身 · 喂饭 · 口腔清洁           │  │  ← 项目摘要（最多 3 项 + 等 N 项）
+│  │ 预计 60 分钟          [ 开始 ]  │  │  ← 大按钮
+│  └─────────────────────────────────┘  │
+│  ┌─────────────────────────────────┐  │
+│  │ ⏰ 11:00  张爷爷家      ✅已完成 │  │  ← 已完成卡片（灰底）
+│  └─────────────────────────────────┘  │
+│  ┌─────────────────────────────────┐  │
+│  │ ⏰ 14:30  赵奶奶家               │  │
+│  └─────────────────────────────────┘  │
+│  今天 3 家 · 已完成 1 家               │  ← 底部汇总（小字）
+└───────────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **日期行** | 大字；**当天**，不显示其他日期（不做日历） |
+| **任务卡片** | 按**时间顺序**排列；**待办在前、已完成沉底** |
+| **卡片三要素** | **时间**（大字）＋ **老人称呼**（大字）＋ **项目摘要**（最多 3 项，多的显示"等 N 项"） |
+| **状态分色** | 待办＝白底；已完成＝灰底＋✅；**异常＝橙底**；**逾期未做＝橙红底** |
+| **主按钮** | **[开始]** —— 唯一的大按钮，**点击即进入 M2** |
+| **已完成卡片** | 不可点进 M2（防重复提交）；点进 M4 可看记录 |
+| **底部汇总** | "今天 N 家 · 已完成 M 家"，**小字、不可点** |
+
+**关键交互规则**
+
+| 场景 | 规则 |
+|---|---|
+| **老人住院中** | 卡片**置灰并显示"住院中·暂停服务"**，**[开始] 按钮不可点**（L1 硬锁） |
+| **待遇已到期** | 同上，显示"待遇已到期·请联系机构" |
+| **无任务** | 显示大图＋"今天没有任务，好好休息"（**不给空白页**） |
+| **逾期未做** | 卡片转橙红＋顶部条提示（**不是责怪语气**，写"这单还没记录，别忘了"） |
+
+> **⭐ 住院状态显示（已定：显示）**：护理员上门前就知道**别白跑一趟**。**⚠️ 前提**：状态靠**机构人工维护**（本期无接口自动同步），所以提示语**不说"系统检测到住院"**，只说"**住院中·暂停服务**"（事实陈述）。
+
+### 4.4 M2 服务执行（核心页面）
+
+> **目标：≤4 次点击完成一次服务记录，不打一个字，没网也能做。**
+
+**点击路径（严格 ≤4 击）**
+
+```
+① 点【开始】（M1）
+        ↓
+② 【签到】  ← 自动定位＋时间，无需输入
+        ↓
+   （干活）
+        ↓
+③ 【勾选服务项目】← 项目已按计划预勾，她只需"取消没做的"
+        ↓
+④ 【签退】  ← 自动计算时长
+        ↓
+   完成（自动提交或进离线队列）
+──────────────────────────────
+合计：4 击
+```
+
+> **⭐ 关键设计**：**项目默认全部预勾选**。护理员只需"**取消没做的那一项**"。
+> **理由**：计划内项目**绝大多数都会做到**。默认全勾＝她多数情况直接点签退（**实际 2 击**）。**这是把"4 击"进一步降成"常态 3 击"的关键。**
+
+**页面布局（三段式，不跳页）**
+
+```
+┌───────────────────────────────────────┐
+│  ← 李奶奶家 · 翻身·喂饭·口腔清洁        │
+├───────────────────────────────────────┤
+│         ┌───────────────┐             │
+│         │   [ 签 到 ]   │             │  ← ① 签到区（超大按钮）
+│         │  09:02 已定位  │             │
+│         └───────────────┘             │
+├───────────────────────────────────────┤
+│  本次服务项目（已按计划预选）            │  ← ② 项目区
+│  ☑ 协助翻身叩背排痰        📷 需拍照   │  ← 必拍档：显式标 📷
+│  ☑ 协助进食/水及指导                   │
+│  ☑ 口腔清洁                            │
+│  ☐ 生命体征测量（本次未做）             │  ← 她取消勾选的
+│  ＋ 临时加项                            │  ← 少用入口
+├───────────────────────────────────────┤
+│      ┌─────────────────────┐          │
+│      │    [ 签  退 ]       │          │  ← ③ 签退区
+│      │  已完成 · 58 分钟    │          │
+│      └─────────────────────┘          │
+└───────────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **签到** | **一键**；自动记录**时间＋定位**（定位失败不阻塞，标"未获取"）；**不允许手工改时间** |
+| **项目清单** | 来源＝服务计划；**默认全勾**；顺序＝计划顺序 |
+| **取消勾选** | 点一下即取消；**取消必拍档会提示** |
+| **签退** | **一键**；自动算时长；**不填任何文字** |
+| **时长** | 系统自动计算；不设最低时长强制（**提示但不拦**） |
+| **提交** | 有网＝自动提交；无网＝**进离线队列，界面无差别** |
+
+### 4.5 ⭐ 拍照分档规则（本期核心设计）
+
+| 档 | 适用项目 | 记录方式 | 系统行为 |
+|---|---|---|---|
+| **必拍档** | **沐浴、转移（搬抬类）、导管类（导尿/置管/深静脉置管/气管切开）、鼻饲/喂食（协助进食/水含管饲）、压疮护理** | **强制拍照 ＋ 结构化标签**（压疮专项） | **未拍照 → [签退] 按钮不可点**，提示"这项需要拍一张照片" |
+| **免拍档** | **翻身、喂饭、陪伴聊天、剪指甲、整理床铺、口腔清洁、协助更衣等日常项** | **语音描述 ＋ 家属可选确认** | 不要求拍照；**默认不弹语音**，她可主动录 |
+| **可拍档** | **擦身（擦浴）、协助如厕、失禁照护** | 默认免拍，**出现异常才要求补拍** | 异常上报时引导补拍 |
+
+> **⭐ 压疮护理：已定"加"，实现方式＝"照片＋结构化标签"（2026-10-11 定）**
+>
+> **为什么加**：①**国家 36 项目录里本就有独立项**「压疮预防照护及指导」（`L0000106020010000`）；②**压疮是唯一"照片几乎无法替代"的项目**——严重程度与进展只能靠前后对比图；③**出事时没有照片，机构无法自证不是自己造成的** ⇒ **这一项加的其实是机构的免责能力**。
+>
+> **⚠️ 不能做成"多一项必拍"**（那等于又给一线加活）。正确做法＝**拍照后附结构化标签**：
+
+| 步骤 | 交互 | 说明 |
+|:---:|---|---|
+| 1 | 拍照 | 与既有必拍流程一致 |
+| 2 | **点选部位** | 9 个常见部位：骶尾部／足跟／髋部／坐骨结节／肩胛部／枕部／耳廓／踝部／其他 |
+| 3 | **点选分期** | 1 期／2 期／3 期／4 期／不可分期／深部组织损伤（**采用临床指南标准分期，不自行发明**） |
+| 4 | （可选）备注 | 一句话描述，可跳过 |
+
+> **为什么必须结构化**：**照片只能看，数据才能用**——有了部位＋分期，质控端可做"同一部位持续未愈合"预警、导出文书可直接填"压疮情况"栏。**纯照片做不到这两件事。**
+> **⚠️ 纪律**：结构化标签**全部为点选，不打字**；**标签可跳过不填**（只强制拍照，不强制标签）。
+
+**三条设计纪律（写死）**：
+
+1. **免拍 ≠ 不留痕**——免拍项仍自动记录**四要素**：签到时间、服务时长、项目清单、语音描述（如有）。**四要素齐全即算留痕**；
+2. **分档可配置**——机构可按自身风险偏好**调整哪些项必拍**。默认按上表，**机构可加严、不建议放宽**；
+3. **照片不为"好看"**——**不要求老人摆姿势、不要求面对镜头**。**APP 内不得出现任何"请正面拍摄""请露出老人面部"之类提示**。
+
+> **⚠️ 分档默认值的来源与纪律（2026-10-12 新增，S5 回填）**：**上表分档是我方"建议默认值"，不是医保规定值。** 签约/上线前**必须与当地医保/服务规范逐项核对后确认**（列入《签约前必办清单》）。**理由**：属地巡查对"哪些项须留照片"的口径不完全一致——**把它做成"可配置"是为了改得动，把它"明示出来"才是消除风险**。**不得用"可配置"三个字把这项风险藏起来。**
+
+### 4.5.1 ⭐ 拒拍/无法拍摄的出路（2026-10-12 新增，Q13 回填）
+
+> **要解决的真问题**：必拍项**只有"拍"这一条路**时——老人/家属坚决不让拍，护理员**要么强行拍（挨投诉）**，**要么放弃签退（活干不下去）**。**两条路对一线都是死路。** 必须给**第三条路**。
+
+| 元素 | 规则 |
+|---|---|
+| **入口** | 必拍项拍照区下方**小字**：【无法拍摄？】 |
+| **点击后** | 弹**原因点选**（不打字，4 选 1）：①老人/家属拒绝 ②老人状态不宜拍（如已休息/情绪激动） ③设备故障／无拍摄条件 ④其他 |
+| **选完** | **可直接签退**（解除 `3001` 拦截）；该记录打 `is_refused_photo=1`＋原因 |
+| **标记后果** | 质控端**显著标出"未拍（原因）"**，进**质控重点关注**；**不视为违规**（这是"如实说明"，不是"漏做"） |
+| **留痕** | 拒拍动作本身**记入操作日志**，与补正记录同源可查 |
+
+> **⭐ 设计要点**：**让"没拍"本身变成一个"有痕的证据"**——比"逼她拍"或"让她拍不了就走不掉"都强。**注意**：`is_refused_photo=1` **不等于免责**，只是**把"为什么没拍"说清楚**；是否认账由医保/机构判定。
+> **与 §4.9 异常上报的区别**：异常上报是"**发现了问题**"（压疮/呛咳）；拒拍登记是"**该拍的没拍成**"。**两件事，两个入口，不混。**
+
+### 4.5.2 拍照分档的"属地核对清单"（S5·签约前必办）
+
+| 步 | 动作 | 产出 |
+|:---:|---|---|
+| 1 | 取当地（统筹区）巡查/服务规范原文 | 一份可引用的官方件 |
+| 2 | 逐项比对"哪些项须留照片" vs 上表默认分档 | 差异清单 |
+| 3 | 差异项在**机构配置层**调整（不改代码） | 配置值 |
+| 4 | 写入签约/上线确认单，双方签字 | 存证 |
+
+> **登记落点**：`20261012-签约前必办清单`（含拍照分档核对项）。**未完成此核对，不得对外宣称"拍照分档已符合当地要求"。**
+
+> **⭐ 责任划法（R-3 补，2026-10-12）**：
+> - **我方＝供"建议值"**（上表默认分档）；**机构＝"核对确认"**（逐项比对、签字）。
+> - **核对遗漏的责任，以签约前《属地核对确认单》签收为界**——签字前发现的差异＝协作核对范畴；签字后属地要求变化的＝新的适用要求，另行处理。
+> - **交付要求**：**首次交付即支持"分档批量改"**（整批调整，非逐项手调），列入 **P-5 验收**。
+
+### 4.6 临时加项（少用但必须有）
+
+| 项 | 规则 |
+|---|---|
+| 入口 | 项目区底部 **[＋ 临时加项]**（**小字、不显眼**） |
+| 如何选 | **只能从属地目录里选**（不能自由输入）——保障"不得自创项目" |
+| 记录 | 加项**单独标记**，质控端显示"计划外加项" |
+| 提示 | 选完提示"计划外项目已记录，机构会看到"（**告知，不是警告**） |
+
+> **为什么必须有**：护理员现场发现老人需要额外照护，**如果没有入口，她会口头说、然后不记录**——这正是"**发现了没进系统**"的断链点。
+
+### 4.7 时长提示（不强制）
+
+| 情况 | 系统行为 |
+|---|---|
+| 时长 ≥ 计划时长的 70% | 正常，无提示 |
+| 时长 < 计划时长的 70% | **提示**"本次用时较短，确认要签退吗？"——**可继续**，不拦 |
+| 时长 < 5 分钟 | 提示"用时很短，是否误操作？"——**可继续**，但质控端标黄 |
+
+> **⚠️ 两条纪律**：①**不设最低时长硬拦**（硬拦会逼护理员"耗时间"或"造假"）；②**提示不能带责怪语气**——写"确认要签退吗"，**不写"服务时长不足"**。
+>
+> **⭐ 补充基线（2026-10-11）**：国家目录官方电子版**逐项给了「推荐服务时长」**（沐浴 30–60 分钟、常规换药 20–30 分钟、快速血糖 3–5 分钟…）。已提取全 36 项，见
+> `20261011-服务时长参考基线（源自官方电子版）.md`。**建议二期或本期末**把它接入为**项目级**时长基线（现表为"计划时长百分比"通用口径，不涉具体项目）。
+> **接入时的红线不变**：仍为**提示级＋标签级，不拦截、不扣分**；措辞用"推荐时长"，**不得**写成"标准时长/规定时长"。
+
+### 4.8 离线逻辑（关键）
+
+| 场景 | 行为 |
+|---|---|
+| 完全无网 | **签到/勾选/签退全部可用**；数据进本地队列；**界面无任何"网络异常"红字** |
+| 弱网（有信号但慢） | 同上；不弹"加载中" |
+| 恢复联网 | **后台自动补传**；补传成功**不弹窗打扰**（只在"我的"里显示"已同步"） |
+| 补传失败 | 重试 3 次 → "我的"里标"待同步"，**提示"回家连上 WIFI 就会自动传"** |
+| 照片 | 本地压缩后存储（**避免占满手机**）；补传后**默认保留 7 天**再清理 |
+
+> **⭐ 为什么这是硬指标**：老人家里（尤其老旧小区、城中村）**无网/弱网是常态**。**要求"必须联网才能记录"＝要求护理员在门口等信号**。
+
+### 4.9 M3 异常上报
+
+```
+┌───────────────────────────────────────┐
+│  ← 上报异常                            │
+├───────────────────────────────────────┤
+│  这是谁？（自动带入：李奶奶）            │  ← 自动，不用选
+│  什么问题？（点选，可多选）              │  ← 九宫格大按钮
+│  ┌──────┬──────┬──────┐               │
+│  │ 压疮  │ 呛咳  │ 跌倒  │               │
+│  ├──────┼──────┼──────┤               │
+│  │ 发热  │ 皮肤破损│ 情绪异常│             │
+│  ├──────┼──────┼──────┤               │
+│  │ 进食困难│ 排泄异常│ 其他  │             │
+│  └──────┴──────┴──────┘               │
+│  【按住说话】 说一句就行                 │  ← 语音，非必填
+│  📷 拍一张（可选）                      │
+│        ┌──────────────────┐            │
+│        │   提交上报        │            │
+│        └──────────────────┘            │
+└───────────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **对象** | **自动带入**（从当前任务），不需选择 |
+| **问题分类** | **9 宫格点选**，**点击即选中**，可多选 |
+| **语音说明** | **按住说话**；**非必填**；最长 60 秒；自动转文字（仅内部记录用） |
+| **照片** | **可选**；不强制（**避免吓得不敢报**） |
+| **提交** | 一键；**即时推送**给组长与质控员 |
+
+> **⚠️ 关键取舍**：**异常上报"一切可选"（分类必选，其余可选）**——**异常上报的价值在于"报上来"，不在于"报得多详细"**。如果要求必填照片、必填描述，**护理员会选择不报**。
+
+**提交后**：推送给组长＋质控员（APP 推送＋后台待办）；护理员侧显示"已上报，机构看到了"，**不留任务在 APP 里**；异常记录关联到该次留痕；**不影响计划**（改计划是质控员的事，**APP 不提供改计划功能**）。
+
+### 4.9.1 ⭐ 未遇（扑空）专门形态（2026-10-12 新增，Q12 回填）
+
+> **要解决的真问题**：护理员按时到了、**老人不在家 / 家属临时不让做 / 老人已住院**——原口径下**只能口头跟组长说**，**系统无佐证 ⇒ 巡查看作"空单废单"**，机构被判"虚假服务"的风险落在自己头上。
+
+| 元素 | 规则 |
+|---|---|
+| **入口** | M2 服务执行页底部小字：【没见到老人？】 |
+| **点击后** | 弹**原因点选**（不打字，4 选 1）：①老人/家属不在家 ②家属临时不同意服务 ③老人已住院/已送医 ④其他 |
+| **随手可留** | **到访时间自动取**、**定位自动取**（证明"我确实来过"）；可语音补一句（非必填） |
+| **结果** | 工单转 **`not_met`（未遇）**，**不是"已完成"、也不是"逾期未做"**；**不产生服务记录、不计费** |
+| **推送** | 推给组长＋质控员，**组长可当场决定**：改期（生成新工单）或作废（留原因） |
+
+> **⭐ 与"异常上报"的关系**：**扑空是"异常上报"下的一个专门子类，复用同一套推送与留痕机制，不是新流程**（避免另起一套把 APP 做重）。
+> **与"逾期未做"的区别**：**逾期未做＝到点没记录**（可能压根没去）；**未遇＝去了、有到访时间与定位、但没做成**。**两者性质完全不同，必须分开——这正是"空单废单"能被说清的关键。**
+
+### 4.10 M4 任务详情（只读）
+
+| 区块 | 内容 |
+|---|---|
+| **老人基本信息** | 称呼、性别、年龄（**不显示身份证号等敏感信息**） |
+| **本次服务计划** | 项目清单、频次、预计时长 |
+| **⚠️ 注意事项** | **醒目区块**：过敏史、吞咽障碍、压疮位置、禁食要求等 |
+| **上次服务** | 时间＋项目（**帮她想起来上次做到哪**） |
+| **家属联系人** | 一键拨号（**走隐私号**，不显示真实号码） |
+
+**权限**：**纯只读**——**不得在此页修改任何内容**（防误改）。
+
+> **⭐ 注意事项区块的填写来源**：**这一块是"该加的专项漏加"的防线**。内容由**质控员在制定服务计划时填写**，**护理员只读**。例：老人有吞咽障碍 → 写"**进食需慢、小口、坐起 90 度，出现呛咳立即停止**"。**这比"系统提示加项"更直接有效**——因为它告诉护理员"怎么做"，不只是"要做什么"。
+
+### 4.11 M5 我的
+
+| 区块 | 内容 | 说明 |
+|---|---|---|
+| **我的工时** | 本月服务次数、总时长 | **不显示金额**（本期无结算） |
+| **我的消息** | 机构通知、异常反馈 | 系统通知＋机构群发 |
+| **我的资质** | 资质类型、有效期 | **本期人工登记展示**；〔二期〕做到期提醒 |
+| **同步状态** | "已同步 / N 条待同步" | **离线补传的可见出口** |
+| **设置** | 字号调节、退出登录 | **字号可再放大**（照顾老花） |
+
+> **⚠️ 不做**：不做积分、不做排名、不做"服务之星"——**评比会诱发造假**。
+
+### 4.12 APP 已定事项
+
+| # | 事项 | 定论 |
+|:---:|---|---|
+| 1 | **必拍档是否加"压疮护理"** | ✅ **已定：加**。实现＝**照片 ＋ 结构化标签**（部位 9 选项 ＋ 分期 6 选项，均可跳过）。详见 §4.5 |
+| 2 | **APP 名称与图标** | ✅ **开发期占位名"投云长护"**；图标用**青蓝色板＋简洁图形**（不用人脸、不用心形）。**上架前再定终名**（改名成本极低） |
+
+> **⚠️ APP 名的一个前置问题（上架前必须想清）**：公司与品牌是两套——**公司＝云南投云科技有限公司、品牌＝滇云守护**。**APP 叫"投云长护"还是"滇云守护"，本质是回答"这个 APP 是公司产品线的一员，还是品牌下的一个端口"。** 本期不影响开发。
+
+---
+
+## 五、机构管理后台（①②④ ＋ 文书/设置）
+
+> **本期只做 B1–B4 ＋ B7/B8 精简版**；**B0 院长看板、B5 结算对账、B6 人员资质为二期，本期不在导航中出现**。
+> **一句话设计目标**：**让组长"调单比微信群快"，让质控员"日常做完就是合规记录"，不用天天补台账。**
+
+### 5.1 主导航（登录后，只有 6 项）
+
+```
+投云长护 · 机构后台
+┌──────────────────────────────────────┐
+│  服务对象  排班派单  工单留痕  质控中心  │  ← 4 个主功能
+│  文书档案  系统设置                     │  ← 2 个辅助
+└──────────────────────────────────────┘
+```
+
+| 序 | 导航项 | 分期 | 谁用 |
+|:---:|---|:---:|---|
+| 1 | **服务对象**（B1） | **本期** | 质控员 |
+| 2 | **排班派单**（B2） | **本期** | 组长 |
+| 3 | **工单留痕**（B3） | **本期** | 质控员/院长 |
+| 4 | **质控中心**（B4） | **本期** | 质控员 |
+| 5 | **文书档案**（B7 精简版） | **本期** | 质控员 |
+| 6 | **系统设置**（B8 精简版） | **本期** | 机构管理员 |
+
+> **⚠️ 本期不出现的导航项**：**院长看板（B0）／结算对账（B5）／人员资质（B6）**。
+> **对客口径**：**"首期就做了这几块，余下二期上"**——**不承诺菜单**。**不做"导航都在、点进去没数据"**。
+
+**登录后落在哪（已定）**：**直接落"服务对象"列表页（B1），不做看板首页**。理由：本期机构日常最常进的就是"找人"。
+
+**⭐ 登录页的属地信息（多属地提示）**
+
+```
+┌──────────────────────────────┐
+│   投云长护 · 机构后台          │
+│   机构：XX 养老服务中心        │
+│   属地：昆明市                │  ← 显示参保地
+│   目录：昆明市 45 项           │  ← 显示加载了哪套目录
+│   [ 账号 ]  [ 密码 ]  [ 登录 ] │
+└──────────────────────────────┘
+```
+
+> **⭐ 为什么显示"属地"和"目录"**：①让机构**知道自己在哪套规则下**；②**这是多属地能力的可视化**——**对客演示时，这一行就是卖点**；③**属地不可自助修改**（改属地＝重新签约）。
+
+### 5.2 B1 服务对象
+
+```
+┌────────────────────────────────────────────────────────────┐
+│ 服务对象                     [+ 新建老人档案]  [搜索]        │
+├────────────────────────────────────────────────────────────┤
+│ [全部] [正常享受] [住院暂停] [待建档] [待遇到期]  ← 状态筛选   │
+├────────────────────────────────────────────────────────────┤
+│ 姓名     护理等级   状态       计划    下次服务    操作      │
+│ 李奶奶   一级(最高)  正常享受   ✓已制定  10-11 09:00  查看   │
+│ 张爷爷   二级       住院暂停   ✓已制定  —（暂停）     查看   │
+│ 赵奶奶   三级       ⚠️待建档   —        —          建档   │
+│ 王大爷   一级(最高)  待遇到期   ✓已制定  —（暂停）     查看   │
+└────────────────────────────────────────────────────────────┘
+```
+
+| 字段 | 规则 |
+|---|---|
+| **姓名** | 显示老人称呼（**不显示身份证号**，点进详情才可见且需权限） |
+| **护理等级** | **必须带"（最高级）"标注在一级后** |
+| **状态** | 5 色标签：正常（绿）／住院暂停（橙）／待建档（黄）／待遇到期（橙红）／已终止（灰） |
+| **计划** | 显示"✓已制定"或"—"；**未制定的标黄并显示倒计时** |
+
+**⭐ 建档（含法定时限倒计时）**
+
+| 项 | 规则 |
+|---|---|
+| **建档时限** | **签约后 1 个月内**（政策要求）；顶部显示 **"距建档截止还有 N 天"**，超期标红 |
+| **必填** | 称呼、性别、年龄、参保地、护理等级、待遇有效期、家属联系人 |
+| **注意事项区块** | ⚠️ **醒目区块**：过敏史、吞咽障碍、压疮位置、禁食要求等——**这是 APP 端 M4 的数据来源** |
+| **属地字段** | 参保地**自动取机构属地**（跨属地老人需手工选，并提示规则差异） |
+| **敏感信息** | 身份证号等**加密存储、按权限查看、访问留痕** |
+| **参保核验（第 1 步·前置）** | 建档前先核参保：凭**身份证号＋医保参保号**核对参保状态、参保类别（职工/居民）。**本期无医保接口，不做在线核验**——核验以机构线下确认为准、结果记备注留痕；接口发布后升级为在线核验（入站接口预留） |
+| **录入方式（降负担）** | 身份证 **OCR 拍照自动回填**（回填后仍走 18 位＋校验位校验，OCR 只是省打字不替代校验）；出生日期由身份证带出；地址＝**行政区划级联选择＋门牌文字/语音**；全表**语音双通道兜底** |
+| **评估结论承载（等级唯一来源）** | 失能等级**只能来自评估结论**：A 路径＝**拍照上传评估结论副本（系统自动打水印＋时间戳）**；B 路径＝官方接口拉取〔接口发布后〕。**禁止**建档人自行"勾选/填写"出等级；**无结论佐证的档案不能转"正常享受"** |
+
+> **⚠️ 建档时限来源**：昆医保通〔2025〕27 号第三十四条"建立服务实名制档案，**1 个月内**"。
+
+**服务计划（建档后第二步）**
+
+| 项 | 规则 |
+|---|---|
+| **计划时限** | **签约后 5 个工作日内**制定（政策要求）；页面显示倒计时 |
+| **计划内容** | 服务项目（**从属地目录中选**）、频次、时长、配比 |
+| **护理方式（决定校验规则）** | **在制定计划时选择**（医养结合／养老机构／居家机构／居家个体）——**它不属老人档案的固定属性**（同一老人换护理方式＝换计划），**系统据此套用 §2.5 对应的项数规则**（州市本期无规则，见下） |
+| **项目数量校验** | **按属地规则**：**昆明**＝一级≥18 项/二级≥15/三级≥13，居家按周次数与月时长，**不满足则不能提交**；**州市**＝**本期不校验**（只提示"州市项数规则待属地实施细则明确"），**不拦不卡** |
+| **目录外提示** | 昆明机构勾选时，**国家新增项（吞咽训练等 5 项）显式列出并标"过渡期新增·建议纳入"** |
+| **三方确认** | 计划需经**家属/长护专员确认**后生效——本期以**系统内确认记录**为准 |
+| **变更留痕** | 计划变更**全程留痕**（谁改、何时改、原值、新值） |
+
+> **⭐ 为什么"项目数量校验"是硬要求**：昆明 45 项明确规定了不同护理方式/等级的最低项数，**这是巡查会查的**。系统拦住，比事后被查出来好。
+> **⚠️ 州市为何本期不校验（已定）**：各州市**实施细则未发布**，且国家 36 项**没有项数规则表述**、与昆明 45 项颗粒度对不上 ⇒ **照搬昆明＝给错规则**。项数规则属**配置数据**，细则出来后**补配置即可，不改代码**。**界面提示语固定为"州市项数规则待属地实施细则明确"。**
+
+### 5.3 B2 排班派单（组长主战场）
+
+```
+┌────────────────────────────────────────────────────────────────┐
+│ 排班派单          [日视图 ●] [周视图 ○]    10-11 周六  [← →]   │
+├────────────────────────────────────────────────────────────────┤
+│          09:00      11:00      14:30      16:00                │
+│ 王阿姨   ●李奶奶               ●赵奶奶                         │
+│ 刘阿姨           ●张爷爷              ●孙奶奶                  │
+│ 陈阿姨                                  ⚠️ 空缺                 │  ← 空缺自动标
+├────────────────────────────────────────────────────────────────┤
+│ ⚠️ 2 个空缺待派  ·  1 个时间冲突  ·  王阿姨今日 3 单（负荷偏高） │
+└────────────────────────────────────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **默认视图** | **日视图**（组长每天实际是按天调的） |
+| **横轴** | 时间段；**纵轴**＝护理员 |
+| **卡片** | 显示老人称呼＋项目数；点击即**调单面板** |
+| **自动提示** | ① **空缺** ② **时间冲突** ③ **负荷偏高** |
+| **颜色** | 正常＝蓝；冲突＝红；空缺＝橙虚框 |
+
+**⭐ 调单：严格 ≤3 步**
+
+```
+① 点卡片（或点空缺位）
+        ↓
+② 弹出「改派给谁」，列出可用护理员（含负荷显示）
+        ↓
+③ 点选目标护理员 → 确认
+────────────────────────────
+合计：3 步
+```
+
+| 环节 | 设计要点 |
+|---|---|
+| **第 2 步** | **只列"可派的人"**：该时段空闲的、有资质的（**本期为提示，非拦**）、不在休假的 |
+| **资质提示** | 〔本期〕**该护理员资质已过期/无该项目资质，请确认** ——**红色提示但可继续**（L6 降级口径） |
+| **负荷显示** | 每个人后面显示"今日已有 N 单"，**不排序、不强制** |
+| **确认** | **一次确认即生效**；**自动通知护理员 APP** |
+| **留痕** | 调单记录**谁改的、改前改后、时间**（评查用） |
+
+> **⭐ 计时验收标准**：**同一调单操作，"微信群沟通"与"系统操作"各计时，系统不得更慢。** 这是第 7 条硬指标。**如果做不到，组长两周内就会绕过系统。**
+
+**批量派单（提效，但非必须）**
+
+| 项 | 规则 |
+|---|---|
+| **一键派单** | 选时间段 → 系统按"同资质 → 历史服务过该老人 → 距离近 → 当日负荷低"**推荐** → 组长确认 |
+| **批量确认** | 推荐的**可整批确认**，也可逐条改 |
+| **⚠️ 纪律** | **推荐 ≠ 自动派**——**必须组长确认**（自动派单一旦出错，责任无法归属） |
+
+> **⚠️ 推荐权重说明**：默认权重如上；**不做"熟练度/口碑"排序**（易引发"偏心"质疑）。**这项属现场实测型**——真实排序是否合理，须在机构走访中**观察组长实际派单 10 次**后校准。**不阻塞开发**，代码写成可配置参数。
+
+**冲突检测（自动，不可绕过）**
+
+| 冲突类型 | 系统行为 |
+|---|---|
+| **同一护理员时间重叠** | **红色警示＋不可保存**（硬拦） |
+| **同一老人同时段两次服务** | **红色警示＋不可保存**（硬拦） |
+| **跨机构/跨站点冲突** | 本期不做（单机构内检测） |
+| **护理员休假/离职** | 排班表已排除；如手工指定则提示 |
+
+> **⚠️ 只有时间冲突硬拦**，其余（负荷、资质、距离）**都只是提示**——**"锁得少、锁得准"**。
+
+### 5.4 B3 工单留痕（查看与追溯）
+
+**列表筛选**：按老人（默认，最常用）／按时间／按护理员／按状态。
+
+**留痕详情（一条记录看全）**
+
+```
+┌──────────────────────────────────────────────┐
+│ 李奶奶 · 10-11 09:02–10:00 · 王阿姨            │
+├──────────────────────────────────────────────┤
+│ ✅ 签到 09:02  📍 已定位                       │
+│ ✅ 签退 10:00  时长 58 分钟                    │
+├──────────────────────────────────────────────┤
+│ 协助翻身叩背排痰   ✔️ 已执行  📷 照片 1 张     │
+│ 协助进食/水及指导  ✔️ 已执行                  │
+│ 口腔清洁          ✔️ 已执行                  │
+│ 生命体征测量      ✖️ 未执行（计划内）          │
+│ ⭐ 临时加项：协助如厕（计划外）                │
+├──────────────────────────────────────────────┤
+│ 🎤 语音说明：[播放]                           │
+│ ⚠️ 异常上报：无                               │
+├──────────────────────────────────────────────┤
+│ 质控：待审核     [ 放行 ]  [ 退回 ]            │
+└──────────────────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **照片** | 缩略图＋点击放大；**显示拍摄时间**（防事后补拍） |
+| **未执行项** | **显式标出**（这是质控重点） |
+| **临时加项** | **单独标记**"计划外" |
+| **语音** | 可播放；自动转文字（辅助阅读，**不作为正式记录**） |
+| **修改** | **不可直接改**——只能"补正"，**保留原值＋补正痕迹** |
+
+### 5.5 B4 质控中心（质控员主战场）
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ 质控中心                                                     │
+├──────────────────────────────────────────────────────────────┤
+│ 【待我处理】14 项                     ← ① 主动推送区（最关键） │
+│  ⚠️ 3 条异常上报待处理                                        │
+│  🔴 2 条逾期未做（超 24 小时）                                │
+│  🟡 5 条留痕待放行                                            │
+│  🟡 2 位老人计划未制定（含倒计时）                             │
+│  ⚠️ 2 条住院状态老人仍有派单                                   │
+├──────────────────────────────────────────────────────────────┤
+│ 【待放行队列】  记录列表 → 逐条放行 / 退回                     │
+├──────────────────────────────────────────────────────────────┤
+│ 【异常处理台】  异常上报列表 → 处理 / 转派 / 关闭（附处理意见） │
+└──────────────────────────────────────────────────────────────┘
+```
+
+**⭐ 五类主动推送（不等人工查）**
+
+| # | 推送项 | 触发条件 | 优先级 |
+|:---:|---|---|:---:|
+| 1 | **异常上报待处理** | 护理员提交异常 | 🔴 高 |
+| 2 | **逾期未做** | 工单过时段仍无记录（**超 24 小时标红**） | 🔴 高 |
+| 3 | **住院状态仍有派单** | 老人状态＝住院暂停，但存在待办工单 | ⚠️ 高 |
+| 4 | **计划未制定/超期** | 签约后 5 个工作日未制定计划 | 🟡 中 |
+| 5 | **留痕待放行** | 服务完成未审核 | 🟡 中 |
+
+> **⭐ 第 3 条是本系统的一个特色防线**：老人住院了，**如果机构没及时改状态，系统仍然允许派单**（因为状态靠人工维护）。所以这里加一道**"交叉检查"**：**只要挂了住院标记，就回头查有没有未取消的工单**——**用事后校验弥补"状态非自动"的短板**。
+> **⚠️ 注意措辞**：这是**内部质控线索**，对客不说"系统自动发现住院"。
+
+**放行与退回**
+
+| 操作 | 规则 |
+|---|---|
+| **放行** | 一键；**放行后进"上报池"**〔二期〕；本期放行＝记录"质控通过" |
+| **退回** | 必填**退回原因**（下拉选择，不要求打字）；**退回后护理员可补正** |
+| **批量放行** | 支持；但**异常记录、未执行项记录不可批量放行**（必须逐条看） |
+| **全量＋分级** | **不是抽检**——所有记录都过质控队列，**异常与高危级别不允许跳过** |
+
+> **⚠️ 为什么"全量而不是抽检"**：抽检是**监管方的**做法；**机构自己的质控必须是全量的**——因为出问题时，**"我们抽检了没抽到"不是理由**。
+
+**异常处理**
+
+| 环节 | 规则 |
+|---|---|
+| 收到 | 即时推送（组长＋质控员同时收到） |
+| 判断 | 质控员判断：**需改计划？需上报医保？需联系家属？** |
+| 处理 | 记录处理意见（**下拉＋可选补充**，不强制打字） |
+| 联动 | ⚠️ **如判断需加专项 → 联动到服务计划变更**（对应"该加的专项漏加"防线） |
+| 关闭 | 处理完关闭，**全过程留痕** |
+
+> **⭐ 这个联动是关键**：**护理员发现压疮 → 上报 → 质控员判断需加压疮护理 → 直接改计划 → 下次派单自动带出该项目**。**这一条链走通，"发现了没进系统"的断链就补上了。**
+
+> **质控超时提醒（已定）**：**设**，默认阈值 **24 小时**，**每天最多提醒 1 次**，且**不阻塞任何流程**（未放行只影响"能否上报"，不影响护理员接单与服务）。属**现场实测型**——真实值须问机构质控岗"您现在多久看一次服务记录"；做成**机构可在 B8 自行配置**的项。
+
+### 5.5.1 ⭐ B1–B4 交互细则（开发按此实现，逐条不省）
+
+> **这一节补的是"字段级校验 ＋ 边界态 ＋ 反馈"**——上面说了"有什么"，这里说**"填错/漏填/状态不对时系统怎么办"**。**完整版见 `PRD-02 机构管理后台` §3.5／§4.6／§5.4／§6.6**，本节为交付开发用的收口版。
+
+**【B1 服务对象】**
+
+| 项 | 规则 |
+|---|---|
+| **建档必填校验** | 身份证 **18 位＋校验位算法**；出生日期**由身份证自动带出**（手改须填原因）；参保地默认取机构属地、**跨属地须二次确认**；待遇止 > 起 |
+| **身份证防重** | 同机构内 `id_card_no` **不可重复建档**；命中已有档案⇒**提示"已有档案，是否查看"**（不报错，避免重复建档＝档案管理扣分） |
+| **建档连锁动作** | 保存成功⇒自动生成档案号＋状态转"正常享受"＋倒计时切"距计划截止 N 天"＋待办出现"制定服务计划" |
+| **防误操作** | **档案不可物理删除**，只能"终止"；**变更护理等级须二次确认＋必填原因** |
+| **边界态** | 无档案⇒空状态＋大按钮（不留白表格）；超期⇒行标红＋顶部红条；住院中⇒"制定计划/派单"按钮**置灰**并提示"住院期间不可新增服务" |
+
+**【B1-A 垫付期台账与"结转"】（2026-10-12 新增，Q7 回填）**
+
+> **背景**：长护险有 **6 个月等待期**，机构常先垫钱上门。这段服务**录得进、留得住痕、但不计费**。
+
+| 项 | 规则 |
+|---|---|
+| **录得进** | `待起付（等待期）` 态下**允许派单、允许服务、允许留痕**（`record.is_prepaid=1`） |
+| **不计费** | `is_prepaid=1` 的记录 `billable=0`，**不进结算池、不进医保可见的上报池** |
+| **不误拦** | L1（`1001`）**只拦"要计费的在享服务"**；等待期走垫付台账，**不被误拦** |
+| **结转入口** | 待遇生效（转 `正常享受`）后，档案页出现**〔结转垫付期服务〕**按钮 |
+| **结转规则** | 机构**勾选**若干垫付记录 ⇒ 一键生成对应**正式服务记录**；**原垫付记录永久保留**（只读），两套并存；**不自动转**（计费规则不同，自动转＝埋合规雷） |
+| **原始时间戳（R-1 补，2026-10-12）** | **结转不改变原始时间戳**：转正后的记录，其**签到时间、定位、照片仍为该次服务的原始值**（**不改为"结转日"**），仅新增 **"来源＝垫付台账（`is_prepaid=1`）"** 标记。**目的**：①不踩"无有效待遇不能服务"硬锁；②不制造虚假"补正痕迹"。 |
+| **留痕** | 结转动作**记操作日志**（谁、何时、结转了哪几条） |
+
+> **⭐ 设计要点**：**等待期恰是最需要台账的阶段**——机构垫了钱要留证、要跟家属交代、要跟医保说清"这段是我先做的"。做成**独立台账 + 手动结转**，既不违反"无待遇不能结算"，又不让这段服务变纸面空白，**还不埋"自动算钱算错"的雷**。
+
+**【B1-B 数据初始化 · 批量导入】（2026-10-12 新增，Q17 回填）**
+
+| 项 | 规则 |
+|---|---|
+| **支持对象** | **参保人档案、护理员档案、服务项目配价** 三类均支持 **Excel 批量导入** |
+| **模板** | 系统提供**标准模板**（含必填列、格式说明）；**模板下载**在导入页 |
+| **校验** | 导入前**逐行校验**（身份证 18 位＋校验位、必填非空、参保地合法、项目须在属地目录内）；**错误行不写入、生成错误报告**（行号＋原因） |
+| **重复处理** | 命中已有 `id_card_no` ⇒ **标"已存在"**，由机构选"跳过/更新"，**不静默覆盖** |
+| **上限** | 单次导入 **[待定·建议 ≤2000 行]**（开发联调时定）；超限提示分批 |
+| **留痕** | 每次导入**记操作日志**（导入人、时间、成功/失败条数、文件名） |
+
+> **⭐ 为什么必须有**：机构手里的老人/护理员名单**本来就在 Excel 里**——若只能一条条手录，**上线第一周就劝退**。**"换新账本，不用手抄几百个名字"是能否落地的关键一环。**
+
+**【B1-C 老人个人项目库】（2026-10-12 新增，R10）**
+
+> **触发**：机构提出"床位护理 + 居家护理"双线，且要求**目录能按老人维度适配**——即同一机构里，不同老人应有各自长期固定的服务项目组合，派单时直接带入，而不是每次从机构大目录重新挑一遍。
+
+**它与"服务计划"的分工（先讲清，防两套数据打架）**：
+
+| 结构 | 回答的问题 | 性质 | 变化频率 |
+|---|---|---|---|
+| **`elder_svc` 老人个人项目库** | 这个老人**长期能做 / 常做**哪些项目 | **稳定底表**（派单带入源） | 低（老人能力变了才改） |
+| **`plan` / `plan_item` 服务计划** | 这个周期内**按什么规格**执行（频次／时长／拍照档／护理方式） | **周期生效的正式安排**（版本化） | 中（随评估等级、周期调整） |
+
+**关系一句话**：**派单时先读 `elder_svc` 带入"该老人常做项目"当默认勾选，再叠加 `plan` 的规格（频次／时长／拍照档）落成工单。** `elder_svc` 只回答"做哪些"，`plan` 只回答"怎么做"——**两者不互相替代、不重复存。**
+
+**核心规则**：
+
+| 项 | 规则 |
+|---|---|
+| **归属** | 一张 `elder_svc` 挂在一位老人 `elder_id` 下（**一人一份**，一账号一老人天然一致） |
+| **项目来源** | 只能从**本机构 L4 项目库（`svc_org`）**里勾选，**不可自创、不可写机构目录外的项目**（与 `plan_item` 同纪律） |
+| **数量约束** | **沿用 §2.5 属地项数规则**（昆明按护理等级 ≥13/15/18 项，附加 ≤5 项）——**不是无上限自由堆**，防止"个人项目库"绕过属地合规 |
+| **默认带入** | 制定服务计划时，**一键"从个人项目库带入"**，自动生成 `plan_item` 初稿；派单时再按 `plan` 展开 |
+| **护理方式切换** | 老人换护理方式（如居家 → 机构）＝ **重制个人项目库**（因 §2.5 项数规则按护理方式套用），**旧库只读留档**（同"计划变更留旧版"纪律） |
+| **变更留痕** | 增删项目**全程留痕**（谁、何时、原值、新值）——与计划变更同标准 |
+| **可空** | 老人可不维护个人项目库；此时制定计划仍从 L4 手动勾选（**回退路径不变**，新能力是**可选加速**，不是**新增强制步骤**） |
+
+**交互落地（后台）**：
+- 老人档案页新增「**个人项目库**」区块；未维护时显"未设置，制定计划时手动选"；
+- 制定/续计划弹层新增「**从个人项目库带入**」按钮——**点了带入可改**（带入只是初稿，最终仍以计划为准）；
+- 质控员 / 管理员可编辑（与"制定/变更服务计划"同权限，见 §3.4 权限表），护理员端**只读**。
+
+> **⭐ 为什么这么做**：你要的"按老人维度适配"，本质是"**每个老人的默认项目清单**"。直接做成独立 `elder_svc` 底表，①**不污染** `plan` 的"周期生效 + 版本化"语义；②**派单带入**省掉"每次重新挑一遍"；③**可空**保证老机构、老流程**零迁移成本**。**"双线机构"尤其受益**——床位线和居家线可以各维护各的老人清单，互不串。
+
+**【B2 排班派单】**
+
+**派单前置校验（按序跑，前 5 条硬拦、6–7 条仅提示、第 8 条可见性过滤）**：
+
+| 序 | 校验 | 不通过 |
+|:---:|---|---|
+| 1 | 工单状态＝待派单/已派单 | 拒绝 |
+| 2 | 老人状态＝正常享受 | **硬拦**（L1） |
+| 3 | 有有效计划 | **硬拦**（L2） |
+| 4 | 护理员当班未休假 | **硬拦** |
+| 5 | 时间不冲突 | **硬拦**（`2001`） |
+| 6 | 有该项目/等级资质 | **仅提示**（`1006`，红字可继续，L6 降级） |
+| 7 | 属组长本组 | **不出现该人选**（过滤，非报错） |
+
+- **"可派的人"列表**：只给**事实**（姓名／今日 N 单／资质状态），**不排序**——排序＝暗示，组长会盲从；
+- **调单严格 3 步**：点卡片（弹层不跳页）→点"改派给谁"→点人确认（**即时生效＋自动推 APP＋写留痕**）；**不弹二次确认**（高频操作，且可改回）；
+- **批量派单**：推荐**必须人工确认**，**不做一键全派**；**B-1 权重未取值时不显示推荐列**（宁可不给，不给错的）；
+- **边界态**：今日无排班⇒空状态＋"生成工单"；全是空缺⇒顶部黄条＋空缺位橙虚框；调单时**原护理员已签到⇒不允许调**（提示已开始，如需处理走异常上报）。
+
+**【B3 工单留痕】**（含**补正**的正确做法）
+
+| 项 | 规则 |
+|---|---|
+| **补正（本页最易做错）** | **原记录永久保留**，补正产生**新增更正说明**，两条并列；**❌ 不给"编辑"按钮直接改** |
+| **不能补正什么** | **签到时间、定位、照片本身**——**这三项是"服务发生过"的证据，结构上不可动** |
+| **补正次数** | 不限但每次留痕；同记录补正 **≥3 次⇒自动进质控重点** |
+| **照片** | 后台 `qc`/`leader`(本组)/`director` 可看；**默认不可下载**；**家属端一律不展示** |
+| **时间线** | 按时间倒序，**逾期未做显式占一行**（"少做一次"比"做错"更需被看见） |
+| **导出** | **必须记操作日志**＋文件**带水印**（机构名＋时间＋操作人） |
+
+> **⚠️ 为什么这么严**：巡查表违法违规查处类明确列"**伪造、变造服务记录**"。**给一个"随便改"的按钮，就是把机构架在火上。**
+
+**【B4 质控中心】**
+
+**放行前"对账自检"（按序，任一不通过不放行）**：
+
+| 序 | 检查 | 不通过 |
+|:---:|---|---|
+| 1 | 留痕四要素齐（时间/项目/时长/护理员） | `1004` |
+| 2 | 必拍项已拍 | `3001` |
+| 3 | 状态＝待质控 | 幂等提示"已放行" |
+| 4 | **放行人 ≠ 记录录入人** | **`4001`** 自审自放行 |
+
+- **退回原因用下拉**（6 选项，不要求打字——质控员可能也是 50 岁）；
+- **批量放行的安全边界**：有**异常/未执行项/临时加项/时长异常/补正过**的，**一律不可批量**——**批量是为省手，不是为省眼**；
+- **五类推送必须有"消除条件"**（否则列表只长不消，两周后就被无视）；
+- **时效可视**：每条待放行记录显示"已等待 X 小时"，超阈值（默认 24h，**待走访回填**）标黄、超 2 倍标红；**提醒不阻塞流程**；
+- **边界态**：全部处理完⇒显示"✅ 今日已清空"（不留空表格）；待处理 >50⇒分批＋总数提示；已被他人认领⇒标"处理中（张质控）"避免重复处理。
+
+---
+
+### 5.6 B7 文书档案（精简版）
+
+| 功能 | 说明 |
+|---|---|
+| **一人一档** | 每位老人的档案（基本信息＋服务计划＋全部服务记录＋异常记录） |
+| **导出即合规版式** | 导出对齐**国家 2026 版文书**格式（第 9 条硬指标） |
+| **按需检索** | 按老人/时间导出 |
+| **协议期满移交** | 支持整包导出 |
+
+> **⭐ 措辞纪律（写死，所有界面文案适用）**：**本模块不得出现"迎检""应对巡查""守住分值""检查前准备"等表述。** **正确表述**：**"日常留痕，随时可导出"**。理由：巡查是监管方的评价动作，**把它说成"要应对的事"，等于承认平时没做好**。
+> **本期不做**：电子签章、公文流转、模板自定义 —— **留二期**。
+
+### 5.7 B8 系统设置（精简版）
+
+| 分组 | 内容 |
+|---|---|
+| **机构信息** | 名称、地址、法人、联系方式、**参保地（只读）** |
+| **属地与目录** | 显示当前属地与加载的目录（**只读**）；**国家新增项提示开关**（默认开） |
+| **账号与权限** | 新增/停用账号、分配角色（护理员/组长/质控员/院长，**可多选**，见 §3.4.1 补充 2）、**指定护理员归属组长**（下拉选本机构组长，可留空＝未分组，见 §3.4.1 补充 4） |
+| **服务项目与配价** | **L4 机构项目库**：从属地目录勾选 ＋ 配价 |
+| **对接档位** | 显示当前档位（A 人工登记／B 文件导入导出）；**C 档预留，显示"待接口发布"** |
+| **拍照分档配置** | 机构可**加严**必拍项（**不建议放宽**，界面会提示） |
+| **质控提醒配置** | 质控超时提醒阈值（默认 24 小时） |
+
+**⭐ 服务项目与配价（多属地的落地页）**
+
+```
+┌────────────────────────────────────────────────────────────┐
+│ 服务项目与配价        属地：昆明市  →  加载：昆明市目录(45项)  │
+├────────────────────────────────────────────────────────────┤
+│ [全部] [生活照护] [医疗护理]      ← 按属地目录分类           │
+├────────────────────────────────────────────────────────────┤
+│ ☑ 头面部清洁、梳理     ¥XX /次   [启用●]                    │
+│ ☑ 温水擦浴            ¥XX /次   [启用●]                    │
+│ ☐ 会阴护理            ¥XX /次   [停用○]                    │
+├────────────────────────────────────────────────────────────┤
+│ ⭐ 国家目录新增项（本地方案未含，建议纳入）                    │
+│ ☐ 吞咽功能训练        国家代码 L0000204030010000            │
+│ ☐ 言语功能训练        国家代码 L0000204040010000            │
+│ ☐ 压疮预防照护及指导   国家代码 L0000106020010000            │
+│ （以上为过渡期新增，纳入后可按国家目录上报）                   │
+└────────────────────────────────────────────────────────────┘
+```
+
+| 规则 | 说明 |
+|---|---|
+| **项目来源** | **只能从属地目录勾选**（不可自创、不可自由输入） |
+| **配价** | 机构自填价格；**公示价＝备案价＝上传价须一致**（三价一致，二期校验，本期提示） |
+| **启用/停用** | 停用的项目不参与派单 |
+| **国家新增项区** | ⭐ **独立区块、显式列出**——即使本地目录没有，**也要让机构看见并可选** |
+| **属地切换** | **不可自助**——变更属地须联系我方（属重新配置） |
+
+### 5.8 后台权限与已定事项
+
+| 操作 | 组长 | 质控员 | 院长 | 机构管理员 |
+|---|:---:|:---:|:---:|:---:|
+| 服务对象建档/改计划 | — | ✅ | — | — |
+| 排班派单/调单 | ✅ **本组** | ✅ 全部 | — | — |
+| 工单留痕查看 | **本组** | ✅ 全部 | ✅ 全部 | — |
+| 质控放行/退回 | ✅ **本组** | ✅ 全部 | — | — |
+| 文书导出 | — | ✅ | ✅ | — |
+| 系统设置（B8） | — | — | — | ✅ |
+
+> **⚠️ 四条口径（与 §3.4.1 一致）**：① **"本组"＝查 `staff.group_leader_id = 本人 staff_id` 的护理员**，不分组时组长看不到任何人；② **机构管理员不碰业务数据**，只在 B8 系统设置里有权限；③ **"院长无修改权限"修正为"仅当只持 `director` 时写接口 403"**，兼 `qc`／`admin` 按并集放行；④ **一人可兼多角色**，**唯一禁止"自审自放行"**（`4001`）。
+
+---
+
+## 六、家属轻量端（微信公众号）
+
+> **形态**：**微信公众号**（不做独立 APP、不做小程序）。**服务号优先**，**菜单 → H5 页面**。
+> **一句话设计目标**：**让家属"偶尔看一眼"就够——不装 APP、不打卡、不被派任务。**
+
+### 6.1 ⭐ 三条铁律（本端最重要的设计约束）
+
+1. **零任务**——**不做每日打卡、不做强制确认、不做任何"必须完成"的事**；
+2. **默认只读**——家属**没有任何修改权限**（可"反馈"，但改不了任何记录）；
+3. **只看得见自家**——**只能看自己关联的老人**。
+
+> **⚠️ 第 1 条的实践依据**：已有公开报道——某些地区要求家属"**每日线上打卡 1 小时**"，**操作困难、怨声载道**。
+> **我方判断**：**家属是"外援"，不是"员工"**。**给家属派任务，是把机构的责任转嫁给家属**。
+
+### 6.2 页面地图（3 个页面，不再多）
+
+| 序 | 页面 | 一句话职责 | 是否必须 |
+|:---:|---|---|:---:|
+| **F1** | **我家老人** | 老人基本情况、当前服务计划（只读） | ✅ |
+| **F2** | **服务记录** | 谁来过、做了什么、多久（只读） | ✅ |
+| **F3** | **确认与反馈** | 可选确认某次服务 ／ 留言反馈 | ⭕ 可选 |
+
+**公众号菜单**：`[ 我家老人 ]` `[ 服务记录 ]` `[ 有问题找机构 ]`——**只有三个菜单项**。
+
+**首次进入：绑定老人（仅一次）**
+
+```
+┌──────────────────────────────────┐
+│  绑定家里的老人                   │
+│  请输入老人姓名 + 手机号后 4 位    │
+│  [ 姓名 ]  [ 手机号后4位 ]        │
+│     [  绑  定  ]                 │
+│  温馨提示：绑定后，您可以查看      │
+│  老人的服务记录。如绑定不成功，    │
+│  请联系机构。                     │
+└──────────────────────────────────┘
+```
+
+| 规则 | 说明 |
+|---|---|
+| **绑定方式** | 姓名 ＋ 手机号后 4 位（**不用验证码，简化**） |
+| **绑定失败** | 提示"请联系机构核对信息" |
+| **可绑几位** | 允许多人绑同一位老人 |
+| **解绑** | 需联系机构 |
+| **⚠️ 防泄露** | 姓名＋手机号后 4 位**已足以防止随机猜测**；**不做"输入身份证"这类高门槛验证** |
+
+### 6.3 F1 我家老人
+
+| 字段 | 规则 |
+|---|---|
+| **老人称呼** | 只显示称呼，**不显示身份证、住址等敏感信息** |
+| **护理等级** | **必须写"一级护理（最高级）"** |
+| **服务计划** | 项目＋频次；**只读** |
+| **服务人员** | 显示**姓名**（本期 `staff` 表**无"工号"字段**，不做工号；**不显示手机号**，走机构统一联系） |
+| **不显示** | 价格、费用、限额、基金支付比例——**家属端不涉及钱** |
+
+### 6.4 F2 服务记录
+
+```
+┌───────────────────────────────────┐
+│  李奶奶的服务记录                  │
+├───────────────────────────────────┤
+│  今天 10-11                        │
+│  ┌─────────────────────────────┐  │
+│  │ 09:02–10:00  王阿姨 · 58 分钟 │  │
+│  │ 翻身叩背、进食、口腔清洁        │  │
+│  │                  [知道啦 ○]  │  │  ← 可选确认
+│  └─────────────────────────────┘  │
+│  昨天 10-10                        │
+│  ┌─────────────────────────────┐  │
+│  │ 09:15–10:05  王阿姨 · 50 分钟 │  │
+│  │ 翻身叩背、进食、擦浴           │  │
+│  │                  ✅ 已确认     │  │
+│  └─────────────────────────────┘  │
+└───────────────────────────────────┘
+```
+
+| 元素 | 规则 |
+|---|---|
+| **排序** | 时间倒序（最新的在最上） |
+| **每条显示** | 日期、时间段、**服务人员姓名**、**时长**、**服务项目清单** |
+| **照片** | ⚠️ **本期一律不展示**——见 §6.7 |
+| **异常** | 如有异常上报，显示"已向机构反馈"（**不展示异常细节**，避免家属过度焦虑） |
+| **服务人员** | 显示姓名；**如由多位护理员服务，如实显示实际那个人**（对不上号＝信任问题） |
+
+> **⭐ 家属端最实在的一件事**：**看到"计划里有的项目，实际做了没有"。** 例：计划含"生命体征测量"，某天记录里标"未执行"——**家属能看到**。
+> **⚠️ 但措辞要格外小心**：**不呈现为"护理员没做"，而呈现为"本次未执行"**——因为"未执行"可能是老人当时状态不适合，原因在机构侧。
+
+### 6.5 F3 确认与反馈
+
+**可选确认（与拍照分档配套）**
+
+```
+┌───────────────────────────────────┐
+│  10-11 09:02–10:00                 │
+│  王阿姨上门做了：翻身叩背、进食、口腔清洁 │
+│  您知道这次服务吗？                 │
+│  [ ✅ 知道啦 ]   [ 有疑问 ]        │
+│  （不点也没关系）                    │  ← 明确告知"非必须"
+└───────────────────────────────────┘
+```
+
+| 规则 | 说明 |
+|---|---|
+| **是否必须** | **完全可选**——不点，**不影响服务记录成立** |
+| **点击"知道啦"** | 记为该次服务的**家属确认**（软证据） |
+| **点击"有疑问"** | 跳转到反馈，**通知机构**（走独立通道，不进异常上报流程） |
+| **明确告知** | **必须显示"不点也没关系"**——否则等同于隐性派任务 |
+| **次数限制** | 一条记录只能确认一次 |
+
+> **⭐ 为什么"不点也没关系"必须写在界面上**：**我们承诺零任务，就必须把这句话写出来。** 否则家属会认为"是不是应该点"，**那就变成了软性任务**。
+
+**反馈（有问题找机构）**
+
+| 项 | 规则 |
+|---|---|
+| **入口** | 菜单第三项 ＋ 每次服务记录下方 |
+| **形式** | **可选分类**（服务态度/时间不准/项目没做/其他）＋ **可选文字或语音** |
+| **必填** | **只有分类必选** |
+| **响应** | 通知机构（组长＋质控员）；**机构应在 24 小时内响应**（内部要求，非对外承诺） |
+| **闭环** | 机构处理后，家属端显示"已处理" |
+| **⚠️ 边界** | **反馈不是投诉受理**——不承诺处理时效、不替代医保投诉渠道 |
+
+### 6.6 边界（写死，本端最容易出事）
+
+| 项 | 边界 |
+|---|---|
+| **费用** | **家属端完全不涉及钱**——不显示价格、不显示限额、不显示基金支付比例、不做账单 |
+| **评价** | **不做星级评分**——评分会让护理员为好评而"讨好"或"摆拍" |
+| **异常细节** | 不展示异常上报的具体内容（只显示"已向机构反馈"） |
+| **真人联系** | **不提供护理员个人手机号**；联系走机构 |
+| **医疗建议** | **不给任何医疗判断或建议** |
+| **替代官方** | 家属端**不是官方渠道**——待遇查询、评估申请等仍走官方 |
+
+**⭐ 隐私号（与全站口径一致）**：**真实号码永不展示**（全站统一，无开关）。**家属→机构**通过机构统一电话；**家属→护理员不提供**。
+
+### 6.7 措辞纪律（本端专属，写死）
+
+| # | 规则 | 反例 | 正例 |
+|:---:|---|---|---|
+| 1 | **不写"未做"，写"本次未执行"** | "护理员没做翻身" | "本次未执行" |
+| 2 | **不写"迟到"，写实际时间** | "护理员迟到了" | "09:15 到达" |
+| 3 | **不写"缺勤"** | "今天没人来" | "今天暂无服务记录" |
+| 4 | **不出现"监督""考核""举报"** | "您可以监督护理员" | — |
+| 5 | **"知道啦"不设默认勾选** | 默认已勾选 | 必须主动点 |
+| 6 | **不承诺任何时效** | "我们会在 2 小时内处理" | "我们会尽快处理" |
+| 7 | **等级必带"（最高级）"** | "一级护理" | "一级护理（最高级）" |
+
+### 6.8 家属端已定事项
+
+| # | 事项 | 定论 |
+|:---:|---|---|
+| 1 | **照片对家属可见** | **本期不给**：字段 `visible_to_family` **恒为 0**，后台**不建开关**，家属端**一律不展示服务照片**。核心判断：**这个口子一旦开就回不去**——家属看惯了照片，某次因隐私或疏忽没拍，反而会被理解成"没做"。二期若要开，须先定照片保留期限与打码规则 |
+| 2 | **"知道啦"是否显示确认人姓名** | **显示**，格式 **"姓氏＋关系"**（如"张女士（女儿）"），**不显示全名、不显示手机号**。多位子女时能避免重复追问，也让机构知道谁来对接的 |
+
+---
+
+## 七、数据库设计（23 张表）
+
+> **通用字段**（每张表都有，下文不再重复）：`created_at`／`created_by`／`updated_at`／`updated_by`／`is_deleted`（**本期一律软删除，不物理删**）。
+
+### 7.1 表总览（23 张）
+
+| # | 表名 | 中文 | 本期用途 |
+|:---:|---|---|---|
+| 1 | `org` | 机构 | 机构信息、属地、账号根 |
+| 2 | `user` | 账号 | 登录账号（后台四角色） |
+| 3 | `staff` | 人员 | 护理员/医护基础信息＋**资质字段预留** |
+| 4 | `elder` | 老人档案 | 待遇状态、等级、参保地 |
+| 5 | `elder_status_log` | 待遇状态变更日志 | **状态变更留痕** |
+| 6 | `elder_svc` | 老人个人项目库 | **老人长期可做/常做项目清单（派单带入源，R10）** |
+| 7 | `plan` | 服务计划（头） | 周期、等级、护理方式、确认信息 |
+| 8 | `plan_item` | 服务计划（项） | 计划内含哪些项目、频次、时长 |
+| 9 | `svc_national` | 国家基准库 | 国家 36 项＋官方代码 |
+| 10 | `svc_local` | 属地目录库 | 昆明 45 项；州市引用 L1 |
+| 11 | `svc_mapping` | 属地↔国家映射 | **机构不可见** |
+| 12 | `svc_org` | 机构项目库 | 机构勾选＋配价 |
+| 13 | `order` | 工单 | 一次服务任务 |
+| 14 | `record` | 服务留痕（主） | 签到签退、时长、语音、状态 |
+| 15 | `record_item` | 留痕项目明细 | 每个项目的"做了/没做/免拍" |
+| 16 | `record_photo` | 留痕照片 | 照片存储引用 |
+| 17 | `record_abnormal` | 异常上报 | 9 宫格分类＋语音＋照片 |
+| 18 | `qc` | 质控记录 | 放行/退回、异常处理 |
+| 19 | `report` | 上报池 | 【预留】R4，建表不写业务数据 |
+| 20 | `settlement` | 结算 | 【预留】R1，建表不写业务数据 |
+| 21 | `dict_abnormal_type` | 异常分类字典 | 9 宫格配置 |
+| 22 | `dict_photo_tier` | 拍照分档字典 | 必拍/免拍/可拍配置 |
+| 23 | `loc_config` | 统筹区配置 | 含目录来源（昆明 45 / 州市 36） |
+
+### 7.2 核心表字段定义
+
+**`org` 机构表**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `org_id` | varchar(32) | ✅ | 机构 ID（主键） | 【系统】 |
+| `org_name` | varchar(100) | ✅ | 机构全称（**须与备案名称一致**） | 【本期】 |
+| `org_type` | varchar(20) | ✅ | `medical_care`（医养结合）／`nursing_home`（养老机构）／`home_care`（居家上门）／`home_individual`（居家个体） | 【本期】 |
+| `credit_code` | varchar(18) | ✅ | 统一社会信用代码 | 【本期】 |
+| `loc_code` | varchar(12) | ✅ | **参保地／统筹区代码**（决定加载哪套目录） | 【本期】 |
+| `loc_name` | varchar(50) | ✅ | 统筹区名称（冗余，便于展示） | 【本期】 |
+| `svc_source` | varchar(10) | ✅ | 本机构目录来源：`national`／`local` | 【本期】 |
+| `license_no` | varchar(50) | ○ | 定点服务机构编号 | 【本期】 |
+| `address` | varchar(200) | ✅ | 机构地址 | 【本期】 |
+| `contact_name` / `contact_phone` | varchar | ✅ | 联系人／电话 | 【本期】 |
+| `bed_count` | int | ○ | **床位备案数**（机构护理类必填） | 【本期】 |
+| `sign_date` | date | ○ | 定点服务协议签订日（建档倒计时基准） | 【本期】 |
+
+**`user` 账号表**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `user_id` | varchar(32) | ✅ | 账号 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| `login_name` | varchar(50) | ✅ | 登录名（手机号） | 【本期】 |
+| `real_name` | varchar(30) | ✅ | 真实姓名 | 【本期】 |
+| `role` | varchar(50) | ✅ | **角色（可多值，逗号分隔）**：`nurse`／`leader`／`qc`／`admin`／`director`；如 `director,admin`、`leader,qc`。**判权＝并集**（见 §3.4.1 补充 2） | 【本期】 |
+| `staff_id` | varchar(32) | ○ | 关联 `staff` 表（护理员角色必填） | 【本期】 |
+| `status` | varchar(10) | ✅ | `active`／`disabled` | 【本期】 |
+
+> **⚠️ 权限落地纪律**：**角色写在后端权限校验，不在界面做开关**。**仅当账号只持 `director` 时，写接口返回 403**；**若同时持 `qc`／`leader`／`admin`，按角色并集放行**（§3.4.1 补充 2）。
+
+**`staff` 人员表（含 R2 预留）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `staff_id` | varchar(32) | ✅ | 人员 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
+| `id_card_no` | varchar(18) | ✅ | 身份证号（**实名制**，加密存储） | 【本期】 |
+| `person_code` | varchar(20) | ○ | **医保人员编码**（LN+6位区划+6位顺序；**字段留余量**） | 【预留】R4 |
+| `phone` | varchar(15) | ✅ | 手机号（APP 登录用） | 【本期】 |
+| `job_type` | varchar(20) | ✅ | `nurse`／`nurse_medical`／`manager` | 【本期】 |
+| `work_type` | varchar(10) | ✅ | `fulltime`／`parttime` | 【本期】 |
+| `entry_date` / `leave_date` | date | ○ | 入职／离职日 | 【本期】 |
+| `employ_status` | varchar(10) | ✅ | `on_job`／`leave`／`transfer` | 【本期】 |
+| `cert_type` / `cert_no` / `cert_level` / `cert_expire` / `cert_status` | varchar/date | ○ | **资质五字段**（本期**人工录入**） | **【预留】R2** |
+| `cert_verify_url` | varchar(200) | ○ | 联网查验结果留痕 | **【预留】R2** |
+| **`group_leader_id`** | varchar(32) | ○ | **归属组长**（＝该护理员所在"组"的组长 `staff_id`；本组界定的唯一依据，见 §3.4.1 补充 4）。**可为空＝机构未分组** | 【本期】 |
+
+> **⚠️ 本期数据不空转纪律**：**`cert_*` 字段本期就要人工录入**——签约机构手上都有证书信息，**先录进去，二期直接可用**。
+> **⚠️ 界面纪律**：本期 `cert_*` 字段**只在精简版人员管理里可填可看**，**不做到期提醒、不做禁派拦截**（那是二期）。
+
+**`elder` 老人档案表（① 待遇档案）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `elder_id` | varchar(32) | ✅ | 老人 ID | 【系统】 |
+| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
+| **`loc_code`** | varchar(12) | ✅ | **参保地／统筹区**（全链路取目录依据） | 【本期】 |
+| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
+| `gender` | char(1) | ✅ | `M`／`F` | 【本期】 |
+| `birth_date` | date | ✅ | 出生日期（系统算年龄） | 【本期】 |
+| `id_card_no` | varchar(18) | ✅ | 身份证号（加密） | 【本期】 |
+| `phone` | varchar(15) | ○ | 联系电话 | 【本期】 |
+| `address` | varchar(200) | ✅ | 居住地址（服务上门用） | 【本期】 |
+| `guardian_name` / `guardian_phone` | varchar | ○ | 紧急联系人 | 【本期】 |
+| `insur_no` | varchar(30) | ✅ | **医保参保号** | 【本期】 |
+| `insur_type` | varchar(10) | ✅ | `employee`／`resident` | 【本期】 |
+| `insur_years` | int | ○ | **缴费年限**（参保核验时登记，流程 01 第 1 步） | 【本期】 |
+| `insur_verify_status` | varchar(20) | ○ | **参保核验状态**：`verified`／`unverified`——**本期无医保接口，核验以机构线下确认为准**，结果记此字段留痕；接口发布后升级在线核验 | 【本期】 |
+| `insur_verify_date` | date | ○ | 参保核验日期（留痕） | 【本期】 |
+| `assess_level` | varchar(20) | ✅ | **失能等级**：`sev_1`（重度一级·**最高级**）／`sev_2`／`sev_3` | 【本期】 |
+| `care_level` | varchar(20) | ✅ | **护理等级**：`care_1`（一级·**最高级**）／`care_2`／`care_3` | 【本期】 |
+| `assess_date` | date | ✅ | 评估结论日期 | 【本期】 |
+| `assess_org` | varchar(100) | ○ | 评估机构名称 | 【本期】 |
+| `benefit_start` / `benefit_end` | date | ✅ | **待遇有效期起止** | 【本期】 |
+| `treat_status` | varchar(20) | ✅ | **待遇状态**（见 §7.4） | 【本期】 |
+| `status_source` | varchar(10) | ✅ | `manual`／`api`——**本期恒 `manual`** | **【预留】R5** |
+| `status_change_date` | date | ○ | 状态最后变更日 | 【本期】 |
+| `hosp_start` / `hosp_end` | date | ○ | **住院起止日**（`住院暂停` 时必填） | 【本期】 |
+| `photo_tier_override` | json | ○ | 机构对本老人拍照分档的**加严覆盖**（**只能加严**） | 【本期】 |
+| `need_assess` | json | ○ | **上门需求评估五块信息**（流程 02 第 2 步采集，供第 3 步制定计划引用）：`living_env`（居住环境）／`care_condition`（照护条件）／`svc_demand`（服务项目诉求）／`special_risk`（特殊风险）／`time_preference`（时间偏好）。**结构化 JSON 承载，非纯文本备注** | 【本期】 |
+| `note` | text | ○ | 备注（**含"注意事项"区块内容**） | 【本期】 |
+
+> **⚠️ 等级显示纪律**：`assess_level`／`care_level` 在界面上**必须带"最高级"字样**，**不允许前端省略**。
+> **⚠️ 认知衰退边界**：`assess_level` 只反映**日常活动 6 项**自评＋正式评估结论；**认知/感知觉 7 项须上门评估，系统不筛**。此口径须出现在任何展示等级的页面注脚。
+
+**`elder_status_log` 待遇状态变更日志**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|:---:|---|
+| `log_id` | varchar(32) | ✅ | 主键 |
+| `elder_id` | varchar(32) | ✅ | 老人 ID |
+| `from_status` / `to_status` | varchar(20) | ✅ | 变更前后状态 |
+| `change_reason` | varchar(200) | ✅ | **变更原因（必填，不允许空）** |
+| `source` | varchar(10) | ✅ | `manual`／`api` |
+| `operator_id` | varchar(32) | ✅ | 操作人 |
+| `evidence_file` | varchar(200) | ○ | 佐证材料（如出院小结照片路径） |
+| `changed_at` | datetime | ✅ | 变更时间 |
+
+> **⚠️ 关键设计**：**待遇状态每一次变更都必须写一条日志，`change_reason` 强制必填**。
+> **理由**：`treat_status` 直接决定"能不能服务、能不能计费"。**如果不留痕，"住院期间照做"这类问题将无法追溯**。**这条日志是机构自己的护身符。**
+
+**`elder_svc` 老人个人项目库（R10，派单带入源）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `elder_svc_id` | varchar(32) | ✅ | 主键 | 【系统】 |
+| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
+| `svc_id` | varchar(32) | ✅ | **引用 L4 `svc_org.org_svc_id`**（只从本机构项目库选） | 【本期】 |
+| `svc_name_snapshot` | varchar(100) | ✅ | **项目名快照**（同 `plan_item` 纪律，防目录改名） | 【本期】 |
+| `svc_code_snapshot` | varchar(20) | ○ | **国家代码快照**（上报基准，二期用） | 【预留】R4 |
+| `care_mode` | varchar(20) | ✅ | **护理方式**（`inst_medical`／`inst_nursing`／`home_org`／`home_individual`）——**换方式＝重制个人项目库** | 【本期】 |
+| `is_active` | tinyint | ✅ | 是否启用（软停用不物理删） | 【本期】 |
+
+> **⚠️ 关键设计（三条，写死）**：
+> 1. **`elder_svc` 只存"做哪些"，`plan` 只存"怎么做"**——前者是长期稳定底表（派单带入源），后者是周期生效的正式安排（频次／时长／拍照档）。**两者不互相替代、不重复存规格字段**。
+> 2. **项目只能从 L4 选**——`svc_id` 必须落在本机构 `svc_org` 内，**不可自创、不可写机构目录外项目**（与 `plan_item` 同纪律，防"个人项目库"绕开属地合规）。
+> 3. **`care_mode` 是硬键**——老人换护理方式（居家→机构）必须**重制**个人项目库（因 §2.5 项数规则按护理方式套用），**旧库只读留档**（同"计划变更留旧版"纪律）。**可空**：老人可不维护，此时制定计划仍从 L4 手动勾选。
+
+**`plan` 服务计划表（② 服务计划）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `plan_id` | varchar(32) | ✅ | 计划 ID | 【系统】 |
+| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
+| `plan_period_start` / `plan_period_end` | date | ✅ | **计划周期** | 【本期】 |
+| `care_level` | varchar(20) | ✅ | 计划对应护理等级（**改等级须重新制定计划**） | 【本期】 |
+| `care_mode` | varchar(20) | ✅ | `inst_medical`／`inst_nursing`／`home_org`／`home_individual` | 【本期】 |
+| `item_count` | int | ✅ | **计划项目数**（系统按属地规则校验） | 【本期】 |
+| `item_count_rule` | varchar(100) | ○ | 校验依据快照（如"昆明·医养结合·一级护理 ≥18 项"） | 【本期】 |
+| `extra_item_count` | int | ○ | 附加项数（**≤5**） | 【本期】 |
+| `week_freq` / `month_hours` | int | ○ | 居家类的**每周次数／每月小时数** | 【本期】 |
+| `plan_status` | varchar(20) | ✅ | `draft`／`active`／`changed`／`ended` | 【本期】 |
+| `confirm_elder` / `confirm_guardian` | tinyint | ○ | 确认（0/1，**可选，不强制**） | 【本期】 |
+| `confirm_time` | datetime | ○ | 确认时间 | 【本期】 |
+| `plan_basis` | json | ○ | **计划依据**（流程 02 第 3 步结构化留痕"定计划参考了什么"）：护理服务建议的**来源机构／建议方向／建议项目／日期**。评估/经办侧给的**外部参考**，机构据实录入，证明"计划不是凭空定的" | 【本期】 |
+| `change_from_plan_id` | varchar(32) | ○ | **变更来源计划**（**旧计划不删**） | 【本期】 |
+
+> **⚠️ 计划变更纪律**：**改计划＝新建一条计划 + 指向旧计划**，**绝不原地改**。
+> **理由**：政策要求"服务与计划相吻合"。若原地改，历史工单会突然"对上"一个当时不存在的计划——**这恰恰是"篡改数据"的典型形态**。**留旧版＝留证据。**
+
+**`plan_item` 计划项目明细表**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `plan_item_id` / `plan_id` | varchar(32) | ✅ | 主键／计划 ID | 【系统】/【本期】 |
+| `svc_id` | varchar(32) | ✅ | **引用 `svc_local` 或 `svc_national` 的 ID** | 【本期】 |
+| `svc_name_snapshot` | varchar(100) | ✅ | **项目名快照**（防目录改名后历史计划显示错乱） | 【本期】 |
+| `svc_code_snapshot` | varchar(20) | ○ | **国家代码快照**（上报基准，二期用） | 【预留】R4 |
+| `freq_type` | varchar(20) | ○ | `daily`／`weekly_n`／`monthly_n`／`as_needed` | 【本期】 |
+| `freq_value` | int | ○ | 频次值 | 【本期】 |
+| `duration_min` | int | ○ | **单次时长（分钟）** | 【本期】 |
+| `photo_tier` | varchar(10) | ✅ | **拍照档位**：`must`／`optional`／`free` | 【本期】 |
+| `caution_note` | text | ○ | **注意事项**（显示在 APP M4） | 【本期】 |
+| `is_medical` / `need_cert` | tinyint | ✅ | 是否医疗护理类／是否要求持证 | 【本期】 |
+
+> **⚠️ `svc_name_snapshot` 不是冗余，是必需**：目录会更新。**快照保证历史计划与历史留痕永远显示当时的项目名**，否则三年前的服务记录会突然"变成"另一个项目名——**这在稽核中是致命的**。
+
+**服务项目四层表（L1–L4）**
+
+`svc_national`（L1 · 36 项）：`nat_id`／`nat_code`（**17 字符**，字段留余量 `varchar(20)`）／`nat_name`／`nat_category`（`life`/`medical`）／`nat_sub_category`／`recommend_staff`／`recommend_duration`／`is_medical`／`version`
+
+`svc_local`（L2）：`loc_id`／`loc_code`／`local_item_name`／`local_category`／`svc_time`／`min_freq`／`staff_qual`／`is_medical`／`source_doc`／`map_status`（`mapped`/`local_only`）
+
+`svc_mapping`（L3 · **机构不可见**）：`map_id`／`loc_id`／`nat_id`（**可空＝无法映射**）／`map_type`（`one_to_one`／`many_to_one`／`partial`／`local_only`／`national_only`）／`map_note`／`status`（`confirmed`/`pending`）
+
+`svc_org`（L4）：`org_svc_id`／`org_id`／`src_type`／`src_id`／`is_enabled`／`price`【预留R1】／`price_effective`【预留R1】／`is_new_national`
+
+> **⚠️ 五条多属地纪律在表结构上的落地**：
+> 1. **走配置不走代码** → 新增州市＝插一行 `loc_config` + 一批 `svc_local`，**代码零改动**；
+> 2. **必须可映射** → `svc_mapping` 保证每项可追；`map_status = local_only` 的项**上报时自动排除**；
+> 3. **机构不可改目录** → `svc_org` **只有 `is_enabled` 和 `price` 可改**，其余只读；
+> 4. **国家新增项显式提示** → `is_new_national = 1` 的项**独立区块显示**；
+> 5. **映射表不对外** → `svc_mapping` 表**不提供任何机构侧接口**。
+
+**`order` 工单表（③ 派单工单）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `order_id` | varchar(32) | ✅ | 工单 ID | 【系统】 |
+| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
+| `plan_id` | varchar(32) | ✅ | **来源计划**（L2 硬锁落地） | 【本期】 |
+| `service_date` | date | ✅ | **服务日期** | 【本期】 |
+| `time_slot_start` / `time_slot_end` | datetime | ✅ | **服务时段**（用于冲突检测） | 【本期】 |
+| `assignee_id` | varchar(32) | ○ | 派给谁（`staff_id`） | 【本期】 |
+| `assign_time` | datetime | ○ | 派单时间 | 【本期】 |
+| `assign_mode` | varchar(20) | ○ | `manual`／`batch_recommend`（**批量必须人工确认**） | 【本期】 |
+| `order_status` | varchar(20) | ✅ | **工单状态**（见 §7.4） | 【本期】 |
+| `item_list` | json | ✅ | 本次工单项目的快照 | 【本期】 |
+| `need_photo` | tinyint | ✅ | 本次是否含必拍项 | 【本期】 |
+| `cancel_reason` | varchar(200) | ○ | 取消原因（已取消必填） | 【本期】 |
+| `reschedule_log` | json | ○ | **调单记录** | 【本期】 |
+| `qualification_check` | varchar(20) | ○ | 资质校验结果（**本期恒 `unchecked`**） | **【预留】R2** |
+| **`billable`** / **`price_snapshot`** / **`settle_period`** | varies | ○ | 可计费／服务时点价／结算周期 | **【预留】R1** |
+| `exception_flag` | tinyint | ○ | 是否异常费用 | **【预留】R6** |
+
+> **⚠️ 一种硬冲突、其余软提示**：派单/调单时，**只对"同一 `assignee_id` 且 `time_slot` 重叠"返回硬错误（拒绝保存）**；其余情况**一律只返回提示、不拦**。
+> **理由**：**拦截要准，不能把便利性拦掉。** 组长宁愿微信群说一句就改了，也不会忍受系统处处拦住。
+
+**`record` 服务留痕表（③ 履约留痕）**
+
+| 字段 | 类型 | 必填 | 说明 | 标记 |
+|---|---|:---:|---|---|
+| `record_id` | varchar(32) | ✅ | 留痕 ID | 【系统】 |
+| `order_id` | varchar(32) | ✅ | **来源工单**（L3 硬锁落地） | 【本期】 |
+| `elder_id` / `assignee_id` | varchar(32) | ✅ | 老人／护理员 | 【本期】 |
+| `checkin_time` | datetime | ✅ | **签到时间（系统自动取，不允许手工改）** | 【本期】 |
+| `checkout_time` | datetime | ○ | **签退时间（同上）** | 【本期】 |
+| `duration_min` | int | ○ | 实际时长（**系统算，人不能改**） | 【本期】 |
+| `checkin_lat` / `checkin_lng` | decimal(10,6) | ○ | 签到定位（**定位失败不阻塞**） | 【本期】 |
+| `locate_status` | varchar(20) | ✅ | `ok`／`failed`／`denied`（**失败照常可提交**） | 【本期】 |
+| `record_status` | varchar(20) | ✅ | **留痕状态**（见 §7.4） | 【本期】 |
+| `voice_file` | varchar(200) | ○ | 语音备注（免拍档留痕四要素之一） | 【本期】 |
+| `offline_flag` | tinyint | ✅ | 是否离线创建 | 【本期】 |
+| `client_md5` | varchar(32) | ✅ | **客户端指纹**（防重复上传、防篡改） | 【系统】 |
+| `submit_time` | datetime | ○ | 提交时间 | 【系统】 |
+| `actual_duration_tier` | varchar(10) | ○ | 时长档位（**<5 分钟标黄**） | 【系统】 |
+| `biz_line` | varchar(20) | ✅ | **业务线**：本期恒 `ltci`（长护险）。**预留 `self_pay`（自费）等分线位**——自费服务须落在留痕层单独计时、单独记账，与待遇服务**两条时间线不重叠**（见 §7.3.1 R8 与流程 04 第 4 步） | 【预留】R8 |
+
+> **⚠️ 三条硬设计（都是合规点）**：
+> 1. **签到签退时间、时长一律系统取，接口不接受客户端传入这两个值**——防"补录时间"；
+> 2. **定位失败不阻塞提交**——老人家里弱网是常态，**不能因为定位不到就不让干活**；
+> 3. **时长不设"最低时长硬拦"**，只记 `actual_duration_tier`，**由质控看，不由系统罚**。
+
+**`record_item` 留痕项目明细表**：`record_item_id`／`record_id`／`svc_id`／`exec_result`（**`done`／`undo_not_done`（本次未执行）／`undo_refused`（老人拒绝）**）／`undo_reason`／`extra_flag`／`photo_required`
+
+> **⚠️ 措辞纪律落到数据层**：`exec_result` 的枚举值**必须是 `undo_not_done`（本次未执行）而不是 `not_done`（未做）**。
+> **理由**：**"未做"含指责意味，"本次未执行"是事实陈述**——这条在字段命名层就要卡住，不让前端有机会写"未做"。
+
+**`record_photo` 留痕照片表**：`photo_id`／`record_id`／`svc_id`／`file_path`（**压缩后 ≤500KB**）／`file_size`／`visible_to_family`（**本期恒 0**）／`upload_batch`／`keep_until`（**补传后至少 7 天**）
+
+**`record_abnormal` 异常上报表**：`abnormal_id`／`record_id`／`elder_id`／`reporter_id`／`abnormal_type`（**9 宫格，必选**）／`abnormal_desc`（可选）／`voice_file`／`has_photo`／`notify_status`／`handle_status`／`handle_result`／`link_plan_change`
+
+> **⚠️ "一切可选、分类必选"的落地**：**只有 `abnormal_type` 是必填，其余全可选**。**宁要一条没人名没照片的异常，也不要一条没报上来的压疮。**
+
+**`qc` 质控记录表（④ 质控闸门）**：`qc_id`／`record_id`／`qc_type`（`normal`／`auto_push`／`recheck`）／`push_reason`（**五类**）／`qc_result`／`qc_note`（**退回时必填**）／`qc_staff_id`／`qc_time`／`pass_time`／`first_qc_id`
+
+> **⚠️ 全量非抽检（落库层面保证）**：**每一条 `record_status = submitted` 的留痕，都必须生成一条 `qc` 记录**（定时任务扫描生成）。
+> **理由**：抽检＝总有漏的；而**"先质控再上报"是国家明文**。**全量生成 qc 记录，是把"不抽检"从人工承诺变成数据结构。**
+
+### 7.3 二期预留表（本期建表，不写入业务数据）
+
+**`report` 上报表**：`report_id`／`record_id`／`order_id`／`report_status`／`report_time`／`official_no`（**官方受理号**）／`loc_code`／`nat_code_snapshot`／`adapter_result`
+
+**`settlement` 结算表**：`settle_id`／`org_id`／`settle_period`／`amount_total`／`amount_passed`／`amount_rejected`／**`amount_fund`（基金支付部分）／`amount_self_pay`（个人自付部分）**／`submit_date`／`pay_date`／`exception_reason`／`handle_deadline`
+
+> **⚠️ 个人自付拆分（流程 05 对齐）**：长护险基金支付 70%（职工）/ 50%（居民），**个人自付 30% / 50%**。结算时须**分开记、分开展示**——`amount_fund`＝待医保结算的基金部分，`amount_self_pay`＝待老人自付的应收部分（由机构向老人/家属直接收取，不走基金）。**与"自费项目"是两回事**：个人自付＝待遇内个人掏的部分；自费项目＝目录外、100% 自购。
+
+### 7.3.1 ⭐ 多业务线扩展（R8 预留 · 2026-10-12 新增）
+
+> **问题**：机构不止有长护险业务，还有**自费陪护、居养（养老机构）、民政补贴**等其他业态。**本系统是"长护险这一条业务线的专业账本"，不是机构全业务 ERP**——但须**结构上留口子**，避免将来"多业务"变成"推倒重来"。
+
+**① 定位（写死，不膨胀）**：
+- **本期只做长护险这一条线**（`biz_line` 恒 `ltci`），把这条线的合规账做扎实。
+- **不把其他业务硬塞进长护险规则**——自费不需要评估等级、民政补贴走民政通口径、居养走民政系统，各是各的规则，**混在一个状态机里会把长护险的账弄脏**。
+
+**② 预留方式（只留结构，不改本期逻辑）**：
+- 在 `elder`／`order`／`svc_org`／`record` **四表加 `biz_line` 字段**（默认恒 `ltci`）——**这是"开一条新线"的锚点，不是"本期实现多业务"**。**`record` 表加 `biz_line` 是流程 04 自费服务"单独计时、不走基金"的落点**：自费服务与待遇服务同在一张 `record` 表，靠 `biz_line` 区分两条时间线。
+- 二期若机构确有需求，则**按业务线挂不同"规则包"**：`ltci` 挂"评估等级＋待遇状态＋36/45 目录＋六条硬锁"；`self_pay` 挂"不要求等级、不拦派单、只记账"；`civil_subsidy` 挂"补贴目录＋民政通口径"；`residence` 挂"居养管理"。
+
+**③ 三条不可越界的线（软件管不了，须靠机构＋规则）**：
+1. **资金不能串**：长护险基金（政府管）与自费（老板自己的钱）**财务上必须分开**，系统只能"分开记、分开展示"，**"该不该混着花"是合规问题，系统拦不住人**。
+2. **政府接口各走各的**：长护险走医保平台、民政补贴走民政通、居养走民政系统——**三条接口是三个政府系统**，系统可预留对接位，**接口何时通由政府定，我方不承诺**。
+3. **业务线优先级由机构定**：同一老人可能同时有"长护险档案"和"自费档案"，**哪个优先、能不能叠加**，是机构的经营决策，系统只忠实记录。
+
+**④ 对客口径（一句可用）**："这个系统管的是你长护险这条线；你另外的自费/居养/补贴业务，我们在同一个账号里给你**预留了分线位置**，但**先别把三套规则揉在一起**——揉在一起，长护险的合规账就脏了。"
+
+### 7.4 状态机 ↔ 字段值对照
+
+**待遇状态 `elder.treat_status`（十态）**
+
+| 值 | 中文 | 可否新建计划 | 可否派单 | 可否服务 | 可否计费 |
+|---|---|:---:|:---:|:---:|:---:|
+| `pending_file` | 待建档 | ✅ | ❌ | ❌ | ❌ |
+| `waiting_period` | **待起付（等待期/垫付期）** | ✅ | ✅ | ✅（**仅垫付台账**） | ❌ |
+| `active` | 正常享受 | ✅ | ✅ | ✅ | ✅ |
+| `hosp_pause` | 住院暂停 | ❌ | ❌ | ❌ | ❌ |
+| `review_waiting` | **复评等待期** | ❌ | ❌ | ❌ | ❌ |
+| `transferring` | **跨统筹区转移中** | ❌ | ❌ | ❌ | ❌ |
+| `dead` | 死亡 | ❌ | ❌ | ❌ | ❌ |
+| `long_away` | 长期异地居住 | ❌ | ❌ | ❌ | ❌ |
+| `benefit_expired` | 待遇到期 | ❌ | ❌ | ❌ | ❌ |
+| `terminated` | 已终止 | ❌ | ❌ | ❌ | ❌ |
+
+> **接口层强制**：任何创建 `order` 的请求，**先校验 `elder.treat_status ∈ {active, waiting_period}`**，不满足**直接拒绝**（不是警告）。**这就是 L1 的代码落地。** **⚠️ 新增 `waiting_period` 是唯一例外**：允许创建 `order`，但该 `order` 生成的 `record` **标记 `is_prepaid=1`**，**不计入结算池**（`billable=0`）。**L1 拒绝逻辑不变，只是把等待期从"一律拒"改为"允许但隔离"。**
+
+**工单状态 `order.order_status`（八态）**：`to_assign`（待派单）／`assigned`（已派单）／`serving`（服务中）／`done`（已完成）／`abnormal`（异常）／`cancelled`（已取消）／`overdue`（逾期未做）／**`not_met`（未遇·扑空）**
+
+**留痕状态 `record.record_status`（六态）**：`draft`／`submitted`／`pending_qc`／`passed`／`returned`／`reported`〔二期〕
+
+> **⭐ 2026-10-12 新增字段（供开发建表/改表）**：
+> - `record.is_prepaid`（`tinyint(1)` 默认 0）——**垫付台账标记**；为 1 的记录 `billable=0`。
+> - `record.is_refused_photo`（`tinyint(1)` 默认 0）——**拒拍/无法拍摄标记**；与 `refuse_photo_reason` 配套（见 §4.5.1）。
+> - `record.refuse_photo_reason`（`varchar(50)`）——拒拍原因枚举（见 §4.5.1）。
+> - `order.not_met_reason`（`varchar(50)`）——扑空原因枚举；`order.not_met_at`（`datetime`）到访时间；定位沿用签到定位字段。
+> - `elder.prev_loc_code`（`varchar(20)`）——**跨统筹区转移前的参保地**，用于"转移中"态展示与目录切换预览。
+> - `elder.transfer_confirm_at`（`datetime`）——转移确认时间（人工确认后写入）。
+> - `elder_svc.care_mode`（`varchar(20)`）——**个人项目库护理方式键**（R10，换方式＝重制库）。
+> - `elder_svc.is_active`（`tinyint(1)` 默认 1）——个人项目库启用状态（软停用不物理删）。
+
+---
+
+## 八、接口契约
+
+> **三端（APP／后台／家属端）共用同一套后端接口。** 本节定义**语义契约**（谁调、传什么、返什么、什么情况拒），不定义传输协议细节。
+> **统一响应结构**（所有接口）：
+
+```json
+{
+  "code": 0,              // 0=成功；非0=失败（见 8.1）
+  "message": "成功",       // 面向开发；错误时给可读原因
+  "data": { },            // 业务数据
+  "hint": ""              // ⚠️ 面向用户的"怎么解"提示（硬锁拒绝时必须返回）
+}
+```
+
+### 8.1 统一错误码表
+
+| code | 含义 | 前端处置 |
+|:---:|---|---|
+| `0` | 成功 | — |
+| `1001` | **无有效待遇，不可服务**（L1） | 显示 `hint`，禁止进入服务页 |
+| `1002` | **无有效计划，不可派单**（L2） | 引导"先制定计划" |
+| `1003` | **无有效工单，不可录痕**（L3） | 拒绝提交 |
+| `1004` | **留痕不完整，不可进上报池**（L4） | 列出缺什么 |
+| `1005` | **未质控放行，不可上报**（L5） | 提示先质控 |
+| `1006` | **资质不匹配（本期仅提示，不拦截）**（L6） | **仅提示，允许继续** |
+| `2001` | 派单时间冲突（同人同时段重叠） | **硬拒**，提示换人或改时 |
+| `2002` | 计划项目数不满足属地规则 | **仅提示**，可保存 |
+| `3001` | 必拍项未拍照，不可签退 | 硬拒，引导拍照；**提供【无法拍摄？】出路**（见 §4.5.1，选原因即放行） |
+| `3002` | 定位失败（**非错误，仅标记**） | 允许提交 |
+| `3003` | **未遇（扑空）已登记**（非错误，状态变更） | 工单转 `not_met`，推组长决策 |
+| `3004` | **垫付期记录不可计费**（非错误，仅标记） | `billable=0`，允许提交 |
+| `4001` | 越权：非本机构/非本人数据；**或"自审自放行"**（同一账号录入的记录不得由本人质控放行，见 §3.4.1 补充 2） | 403 |
+
+> **⚠️ `1006` 的设计是刻意的**：**资质校验本期返回"提示级"而不是"拒绝级"**。这样**二期只需把 `1006` 从"提示"改成"硬拒"**，前端代码基本不用动——**这就是"预留位"在接口层的价值**。
+
+### 8.2 本期接口清单（40+ 接口）
+
+**A · 待遇档案（①）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/elder/create` | POST | 新建老人档案 | 建档时限倒计时；`loc_code` 必填 |
+| `/elder/detail` | GET | 档案详情 | 权限：本机构 |
+| `/elder/status/change` | POST | **变更待遇状态** | **`change_reason` 必填**；写 `elder_status_log` |
+| `/elder/status/log` | GET | 状态变更历史 | 只读 |
+| `/elder/list` | GET | 老人列表（后台 B1） | 支持按状态/等级筛 |
+
+**B · 服务计划（②）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/plan/create` | POST | 制定计划 | **项目数按属地规则校验**（`2002` 提示级） |
+| `/plan/change` | POST | **变更计划（新建＋指向旧）** | **不原地改**；旧计划转 `changed` |
+| `/plan/detail` | GET | 计划详情 | 含 `item_list` |
+| `/plan/confirm` | POST | 老人/家属确认 | 可选 |
+| `/svc/local/list` | GET | **按参保地加载属地目录** | 昆明→45项；州市→36项 |
+| `/svc/org/list` | GET | 机构项目库 | — |
+| `/svc/org/config` | POST | 勾选＋配价 | **只允许改 `is_enabled`/`price`** |
+| `/svc/org/new-national` | GET | **国家新增项列表** | 昆明机构**必须显式展示** |
+
+**C · 老人个人项目库（R10）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/elder-svc/list` | GET | 某老人的个人项目库 | 权限：本机构 |
+| `/elder-svc/save` | POST | 增删个人项目库（整表覆盖） | **`svc_id` 必须落在本机构 `svc_org` 内**；`care_mode` 变更＝重制（旧库留档）；写操作日志 |
+
+**C · 派单工单（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/order/generate` | POST | 由计划生成工单 | **L2**：无计划拒绝 |
+| `/order/assign` | POST | 派单 | **L1**：待遇非 `active` 拒绝；`2001` 时间冲突硬拒；`1006` 资质提示 |
+| `/order/reassign` | POST | 调单 | 记 `reschedule_log`；**≤3 步** |
+| `/order/batch-recommend` | GET | 批量推荐 | **仅返回推荐，必须人工确认** |
+| `/order/today` | GET | 护理员今日任务（M1） | 仅本人 |
+| `/order/cancel` | POST | 取消工单 | `cancel_reason` 必填 |
+| `/order/detail` | GET | 工单详情（M4） | 含**注意事项区块** |
+
+**D · 履约留痕（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/record/checkin` | POST | 签到 | **服务器取时间**；定位失败不阻塞（`3002`） |
+| `/record/item/save` | POST | 保存项目执行 | `exec_result` 枚举 |
+| `/record/photo/upload` | POST | 上传照片 | **压缩校验 ≤500KB**；返回 `photo_id` |
+| `/record/checkout` | POST | 签退提交 | **必拍未拍拒绝**（`3001`）；计算时长 |
+| `/record/offline/sync` | POST | **离线补传** | `client_md5` 去重；**静默不弹窗** |
+| `/record/detail` | GET | 留痕详情 | — |
+| `/abnormal/report` | POST | **异常上报** | 仅 `abnormal_type` 必填 |
+| `/abnormal/list` | GET | 异常列表（后台 B4） | 主动推送来源 |
+
+**E · 质控闸门（④）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/qc/pending/list` | GET | 待质控列表（含主动推送） | **全量**，非抽检 |
+| `/qc/detail` | GET | 质控详情 | 含留痕全文与照片 |
+| `/qc/pass` | POST | 放行 | 写 `qc_result=passed`、`pass_time` |
+| `/qc/return` | POST | 退回 | **`qc_note` 必填** |
+| `/qc/exception/link` | POST | **异常联动改计划** | 生成新 `plan_id` 并回填 `link_plan_change` |
+
+**F · 家属端（③）**
+
+| 接口 | 方法 | 说明 | 关键校验 |
+|---|---|---|---|
+| `/family/bind` | POST | 绑定（姓名＋手机号后4位） | **只看自家** |
+| `/family/elder` | GET | 我家老人信息 | 过滤 `visible_to_family` |
+| `/family/records` | GET | 服务记录列表 | **不返回价格字段** |
+| `/family/ack` | POST | **可选确认** | **非必做，不记录"未确认"为异常** |
+| `/family/feedback` | POST | 反馈 | — |
+
+### 8.3 硬锁在接口层的落点总表（L1–L6）
+
+| 锁 | 接口 | 触发条件 | 结果 |
+|---|---|---|---|
+| **L1** | `/order/assign`、`/record/checkin` | `elder.treat_status ≠ active` | `1001` **拒绝** |
+| **L2** | `/order/generate` | 无 `plan_status=active` 的计划 | `1002` **拒绝** |
+| **L3** | `/record/*` | 无有效 `order` | `1003` **拒绝** |
+| **L4** | `/qc/pass` | 留痕缺必填要素 | `1004` **拒绝** |
+| **L5** | `/report/*`〔二期〕 | 无 `qc_result=passed` | `1005` **拒绝** |
+| **L6** | `/order/assign` | `staff.cert_status ≠ valid` | `1006` **仅提示，不拒绝**（**二期改硬拒**） |
+
+### 8.4 ⭐ 二期预留位落地对照（R1–R6，逐项核对）
+
+> **本节证明"只加不改"是可验证的**——二期每项功能，都能在本期表结构里找到它要用的字段。
+
+| # | 二期功能 | 本期已建的字段/表 | 二期要新增的 | **要改的** |
+|:---:|---|---|---|---|
+| **R1** | 结算对账 | `order.billable`／`price_snapshot`／`settle_period`；`svc_org.price` | `settlement` 表、申报页、导出格式 | **无** |
+| **R2** | 资质人员 | `staff.cert_*` 五字段；`order.qualification_check` | 到期提醒任务、禁派逻辑、资质管理页 | **无**（`1006` 改硬拒属逻辑开关） |
+| **R3** | 院长看板 | 数据层可直接聚合现有表 | 聚合视图、图表页 | **无** |
+| **R4** | 上报池与接口 | `report` 表；`order`/`plan_item` 的 `official_no`/`loc_code`/代码快照 | 适配层实现、上报页 | **无** |
+| **R5** | 医保状态同步 | `elder.status_source` | 接口实现 | **无**（只改字段值来源） |
+| **R6** | 异常费用 | `order.exception_flag`／`exception_reason`／`handle_deadline` | 异常处理页、超时提醒 | **无** |
+| **R8** | 多业务线 | `elder.biz_line`／`order.biz_line`／`svc_org.biz_line`／`record.biz_line`（本期恒 `ltci`） | 业务线规则包、分线档案、分线记账 | **无**（本期只留字段，不改逻辑） |
+
+**接口契约层预留**
+
+| 预留项 | 本期定义（写死） | 二期 |
+|---|---|---|
+| **适配层输入输出格式** | **按国家编码规范定稿**（机构编码 13 位 `LH`+区划+序号、人员编码 14 位 `LN`+区划+序号、**项目代码 17 字符**） | 直接实现 |
+| **A/B/C 三档** | A 人工登记／B 文件导入导出【本期】／C 专线前置机【预留】 | 实现 C 档 |
+| **错误码 `1006`** | **提示级**（不拦） | 改**拒绝级** |
+
+> **⚠️ 项目代码位数说明**：原写"14 位"系归纳有误。**经专项复核定型为 17 字符**，且**仅内部逻辑推演、未与官方原件对照** ⇒ **正式上报前必须以官方电子版核对**。详见《20261011-国家36项代码复核报告》。**字段长度一律按 `varchar(20)` 设计，留余量。**
+
+---
+
+## 九、数据安全与留痕（合规条款的工程落地）
+
+> 这一节不是"技术选型"，是**政策明文要求在本系统的落地方式**。
+
+| 要求（政策） | 工程实现 |
+|---|---|
+| **一人一档** | `elder` 表 ＋ 全链路 `elder_id` 外键，`order`/`record`/`qc` 均可回溯到人 |
+| **实名制管理** | `staff.id_card_no` 加密存储、唯一约束；`user` 绑定 `staff_id` |
+| **不可伪造/变造** | ①`checkin/checkout` 服务器取时；②`elder_status_log` 必填原因；③`record` 软删除不物理删；④`client_md5` 防重复提交 |
+| **记录与计划/数据/考勤相吻合** | `plan_item` → `order.item_list` → `record_item` **三级快照一致** |
+| **材料调取** | 全表导出接口，按老人/时间段/项目导出，**导出即合规版式** |
+| **数据保留** | 照片 `keep_until`（补传后 ≥7 天），业务数据软删除保留 |
+| **隐私号** | 家属端接口**一律不返回护理员真实手机号** |
+
+> **⚠️ 一条容易忽略的工程纪律**：**`record` 与 `qc` 表一律软删除**——`is_deleted` 置 1，**原始记录永久保留**。
+> **理由**：长护险数据是**基金支付凭证**。若允许物理删除，"事后删记录"就变成可能。**软删除＝"不可无痕修改"的最后一道工程防线。**
+
+---
+
+## 十、验收条款
+
+### 10.1 12 条易用性硬指标（**验收圣经**，每个页面都要回指）
+
+| # | 硬指标 | 验收方式 | 本期 |
+|:---:|---|---|:---:|
+| 1 | 完成一次服务记录 **≤4 次点击** | 计数验收 | ✅ |
+| 2 | **必填自由文本 = 0** | 走查 | ✅ |
+| 3 | **离线可用＋自动补传** | 断网实测 | ✅ |
+| 4 | 关键字号 **≥20pt**、不做多层菜单 | 走查 | ✅ |
+| 5 | **首屏即任务** | 走查 | ✅ |
+| 6 | **误操作可撤销**、录错不直接扣钱 | 功能验收 | ✅ |
+| 7 | 组长**调单 ≤3 步**、不比微信群慢 | 计时验收 | ✅ |
+| 8 | **异常主动推送** | 触发验证 | ✅ |
+| 9 | **导出即合规版式** | 导出比对国家 2026 版文书 | ✅ |
+| 10 | 院长看板**只放三块** | 走查 | **〔二期〕** |
+| 11 | 家属端**零任务** | 走查 | ✅ |
+| 12 | **最小必要留痕** | 规则验收 | ✅ |
+
+> **本期验收 11 条**（第 10 条随院长看板延至二期）。
+
+**验收方式定义（避免扯皮）**
+
+| 方式 | 具体做法 |
+|---|---|
+| **计数验收** | 真人从"打开 APP"到"提交一次服务记录"，**实际点击数 ≤4** |
+| **走查验收** | 逐屏人工检查，打勾确认 |
+| **断网实测** | 飞行模式下完成一次完整服务记录，联网后确认自动补传成功 |
+| **计时验收** | 同一调单操作，"微信群沟通"与"系统操作"各计时，系统**不得更慢** |
+| **规则验收** | 构造规则用例（高风险项不拍照能否提交／日常项不拍照能否提交） |
+
+### 10.2 分端专项验收
+
+**护理员 APP 端**
+
+| # | 条款 | 验收方式 |
+|:---:|---|---|
+| 1 | ≤4 击（常态预勾选时为 3 击） | 实测 |
+| 2 | M2/M3 **无任何必填文本输入框** | 走查 |
+| 3 | 飞行模式下完成完整服务记录；联网自动补传 | 断网实测 |
+| 4 | 正文 ≥20pt；**页面层级 ≤2** | 走查 |
+| 5 | 打开 APP **直接进 M1**，登录态保持 | 走查 |
+| 6 | 误点签退 → **10 秒内可撤销** | 功能验收 |
+| 12 | 必拍档未拍照 → 不可签退；免拍档未拍照 → **可正常签退** | 规则验收 |
+| **A1** | **新用户 10 分钟内独立完成一次记录**（不给培训、只给手机） | 真人实测（**本端最硬的一条**） |
+| A2 | 住院状态老人卡片置灰且不可开始 | 构造用例 |
+| A3 | 定位失败不阻塞签到 | 关闭定位权限实测 |
+| A4 | 照片本地压缩后单张 ≤500KB | 技术验收 |
+| A5 | 异常上报全程 ≤30 秒（不含拍照） | 计时验收 |
+
+> **⭐ A1 说明**：**如果新护理员需要培训才会用，说明设计失败了**。建议上线前找**未接触过系统的真实护理员**实测。
+
+**机构后台端**
+
+| # | 条款 | 方式 |
+|:---:|---|---|
+| 7 | 从点卡片到改派生效 **≤3 步**；与微信群计时对比**不更慢** | 实测 |
+| 8 | 护理员提交异常 → **组长/质控员 10 秒内**收到推送 | 触发验证 |
+| 9 | 导出档案 → 逐项比对**国家 2026 版文书**格式 | 走查 |
+| 6 | 调单可撤销；放行可撤回（**限时 10 分钟内**） | 功能验收 |
+| B1 | **登录后 1 屏内看到"待我处理"事项** | 走查 |
+| B2 | 本期不出现的功能**在导航中完全不存在**（不是置灰） | 走查 |
+| B3 | 一级护理显示为"一级护理（最高级）" | 走查 |
+| B4 | 昆明机构登录可见"国家新增项"区块 | 构造用例（以昆明属地登录） |
+| B5 | 州市机构登录**只看到 36 项**、无映射提示 | 构造用例 |
+| B6 | 计划项目数不满足属地规则 → **不可提交** | 构造用例 |
+| B7 | 留痕记录**不可直接改**，只能补正且保留原值 | 技术验收 |
+| B8 | **老人个人项目库**：项目只能从本机构 L4 选；`care_mode` 变更＝重制（旧库只读留档）；制定计划可"一键带入"且可改 | 构造用例＋技术验收 |
+
+**家属端**
+
+| # | 条款 | 方式 |
+|:---:|---|---|
+| 11 | **无任何"必须完成"的交互**；"知道啦"默认不勾选、可跳过；界面显式写"不点也没关系" | 走查 |
+| 4 | 字号 ≥20pt（**家属中含老年人，字号尤其重要**） | 走查 |
+| F1 | **绑定成功率**：模拟 20 位家属，**≥18 位一次成功** | 真人实测 |
+| F2 | 家属**看不到非关联老人**（换绑测试、URL 手工改参测试） | 安全验收 |
+| F3 | 照片**默认不可见** | 走查 |
+| F4 | 家属端**任何页面均无价格/金额字样** | 走查（搜"元""费用""限额"零命中） |
+| F5 | 家属端**无评分/星级组件** | 走查 |
+| F6 | 反馈提交后**机构端 10 秒内可见** | 触发验证 |
+| F7 | 措辞检查：**"未做""迟到""缺勤""监督""举报"零命中** | 走查 |
+
+---
+
+## 十一、不做什么（写死，防后续加需求）
+
+### 11.1 全系统不做的（红线）
+
+| 不做 | 理由 |
+|---|---|
+| 做评估机构 | 不参与失能等级评估、不出评估结论 |
+| 碰基金资金 | 不经手长护基金、不做资金池 |
+| 替代官方系统 | 官方 APP／省平台是"只对接"，不替代 |
+| 卖老人数据 | 平台不对外提供老人原始数据 |
+| 承诺结果 | 不承诺遴选通过、不承诺巡查得分、不承诺不被罚 |
+| 用广告法禁用词 | 不用"最／第一／国家级"等 |
+
+### 11.2 护理员 APP 不做的
+
+| 不做 | 理由 |
+|---|---|
+| 打字录入 | 与"必填自由文本 = 0"矛盾 |
+| 排班/调班 | 属组长职责，APP 上做会乱 |
+| 查看/修改服务计划 | 属质控职责；**防一线改计划绕过合规** |
+| 统计报表、排行榜 | 与"干活现场"无关，且评比诱发造假 |
+| 家属沟通功能 | 隐私号转接由机构侧统一处理 |
+| 服务评价（护理员评老人） | **伦理风险**，坚决不做 |
+| 积分、勋章、打卡日历 | 把照护变成游戏，**方向错** |
+| 支付/收款相关 | 本期无结算，且平台不碰资金 |
+
+### 11.3 机构后台不做的
+
+| 不做 | 理由 |
+|---|---|
+| 院长看板（B0） | 二期；**本期不做空首页** |
+| 结算对账（B5） | 二期 |
+| 人员资质管理（B6） | 二期；本期**只在排班时提示** |
+| 自动派单（无人确认） | 出错无法归属责任 |
+| 抽检式质控 | 机构质控必须全量 |
+| 自定义服务项目 | 合规红线 |
+| 属地自助切换 | 属重新配置 |
+| 员工绩效排名 | 评比诱发造假，且与长护合规无关 |
+| "迎检"类功能与话术 | 措辞纪律 |
+
+### 11.4 家属端不做的
+
+| 不做 | 理由 |
+|---|---|
+| 每日打卡/签到 | **核心红线**（已有反面案例） |
+| 强制确认 | 同上 |
+| 星级评分 | 诱发摆拍与讨好，且不真实 |
+| 费用/账单展示 | 家属端不涉及钱 |
+| 在线支付 | 平台不碰资金 |
+| 展示护理员手机号 | 隐私号原则 |
+| 医疗建议 | 合规红线 |
+| 展示异常细节 | 避免过度焦虑 |
+| 替代官方渠道 | 不做评估申请、待遇查询入口 |
+| 家属上传照片/视频 | 与"零任务"矛盾，且涉隐私 |
+
+---
+
+## 十二、遗留待确认（**均不阻塞开发**）
+
+| # | 事项 | 影响 | 处置 |
+|:---:|---|---|---|
+| 1 | 各州市实施细则是否另行细化服务项目 | 属地目录库内容 | 签约前逐一核实；**推定不影响结构** |
+| 2 | 昆明 45 项是否已更新 | 属地目录库内容 | 建议 0871-65919196 核实 |
+| 3 | ⚠️ **国家项目代码须官方电子版最终确认** | 二期上报准确性 | **仅影响二期上报**（P0 不含上报）；字段已按 `varchar(20)` 留余量 |
+| 4 | 照片**保留期限**（政策要求 vs 机构成本） | 存储策略 | 有地方要求"保存 10 年"；**按属地要求配置化，不当统一硬编码** |
+| 5 | 派单推荐权重、质控提醒阈值 | 配置值 | **已有默认值，可直接开发**；走访后只改配置、不改代码 |
+
+> **⚠️ 处理原则**：**这 5 项都不阻塞 P0 开发**——前 4 项是"数据内容"和"配置值"，不是"结构"。**唯第 3 项须在真正对接上报前收口**（属二期）。
+
+---
+
+## 十三、⭐ 本轮质疑回填记录（2026-10-12）
+
+> **本节回答一件事**：机构老板的 22 条质疑里，**哪些我们改了 PRD（能改就改）、哪些是产品客观做不到（如实说明）。**
+> **原则**：**能改的写进需求；做不到的不硬撑。** 本节只记"改了什么"，不重复需求正文。
+
+### 13.1 已改入 PRD 的（产品能做的 —— 已写进需求）
+
+| # | 质疑 | 改动落点 | 性质 |
+|:---:|---|---|---|
+| **R1** | Q7 等待期 6 个月空窗，服务"录不进" | **新增 `待起付（等待期）` 态**（§3.2）＋**垫付台账与结转**（§5.5.1 B1-A）＋字段 `is_prepaid`（§7.4） | 能改，已改 |
+| **R2** | Q8 状态颗粒度不够（复评中/跨市搬家/住院回来） | **新增 `复评等待期`、`跨统筹区转移中` 两态**，**`住院暂停` 补"恢复"出路**（§3.2、§7.4），状态由七态 → **十态** | 能改，已改 |
+| **R3** | Q12 临时加单/取消/**白跑一趟**无佐证 | **新增工单态 `未遇（扑空）`**（§3.2）＋**异常上报子形态**（§4.9.1）＋字段 `not_met_reason/not_met_at`（§7.4） | 能改，已改 |
+| **R4** | Q13 必拍项**只有"拍"一条路**，不让拍就卡死 | **新增拒拍出路**（§4.5.1）：选原因即放行＋`is_refused_photo` 标记 + `3001` 出口 | 能改，已改 |
+| **R5** | Q14 拍照分档**依据谁**、属地不一致怎么办 | **明示"默认值须属地核对"**＋**属地核对清单**（§4.5.2）；分档本就可配置（§4.5 纪律 2） | 能改，已明示 |
+| **R6** | Q17 几百人资料**谁录** | **参保人/护理员/项目配价 Excel 批量导入**（§5.5.1 B1-B） | 能改，已改 |
+| **R7** | Q2 等级变动联动 | **`跨统筹区转移中`/`复评等待期` 均绑"重制计划"动作**；限额联动属二期院长看板 | 部分改，已改骨架 |
+| **R8** | 机构不止长护险业务 | **多业务线预留 `biz_line`**（§7.3.1）：本期恒 `ltci`，只留字段不动逻辑 | 能改，已留口子 |
+| **R9** | 履约留痕**身份核验**怎么做 | **PRD 现无身份核验机制（缺口）**：谁在现场、是不是本人，需补"扫脸/人证一致/签字"三类核验方式与字段（见下表 ⚠️ 待补） | ⚠️ 缺口，待补 |
+| **R10** | 目录能否**按老人维度**适配（双线机构诉求） | **新增 `elder_svc` 老人个人项目库**（§5.5.2 B1-C）＋`elder_svc` 表（§7.2，**22→23 表**）＋2 字段（§7.4）＋2 接口（§8.2 C）＋验收 B8（§10.2）。**床位线明确 P0 不做**，仅保留 `bed_count` 备案数占位 | 能改，已改 |
+| **R11** | 居家护理六流程与 PRD 字段缺位对齐（2026-10-14） | **只补字段、不做功能**：①`record.biz_line`（R8 三表→四表）②`elder.insur_years`/`insur_verify_status`/`insur_verify_date`/`need_assess` ③`plan.plan_basis` ④`settlement.amount_fund`/`amount_self_pay`。**自费服务（收款/同意凭证）本期不做、只留字段** | 能改，已补字段 |
+
+> **说明**：**R1–R6 全部为"设计已定"，开发排期须按此更新**（此前 `开发排期与模块拆分（第5步）` 未含这 6 项，须回填工时）。**R9 为新增待补项，尚未进需求正文**——待确认后补入 §4.5（履约留痕拍照）＋§7.4（字段）＋验收指标。
+
+### 13.2 产品客观做不到的（如实说明，不硬撑）
+
+| # | 质疑 | 为什么做不到 | 对客正确表述 |
+|:---:|---|---|---|
+| **N1** | Q3 昆明/省级**接口何时发**、时间表 | **接口规范发布权在统筹区经办机构**，非我方可控；昆明在省级平台（易联众建） | "**具备按医保部门统一接口规范对接的条件**"，**不给日期、不说"已接通"** |
+| **N2** | Q6 **备案价**来源口径 | `昆医保通〔2025〕27号` 提三价一致，但**备案价取值口径未获公开原文** | "**备案价口径须回官方原件核实**"；系统侧只做三价不一致拦截 |
+| **N3** | Q10 **昆明经办认不认**"补正" | **行政认可与否由经办机构定**，非产品能力 | "系统侧原值永久保留、只增更正说明"；**认不认须与医保核** |
+| **N4** | Q11 昆明**认不认国家 2026 版文书** | 同上，**属地采纳权在医保** | "导出模板可按国家文书双向适配"；**采纳与否须核** |
+| **N5** | Q4 **等保备案 / 公司存续** | **公司资质与商务层面事项**，非产品模块 | 由公司另出**书面材料**，产品文档不代答 |
+| **N6** | Q15 昆明**逐项计价口径** | 属属地政策，未获逐项原文 | 系统只算时长、**不参与报账**；计价口径须核 |
+| **N7** | Q20 **有上线客户吗** | **没有就是没有** | **如实说**：首个客户（玉溪自红）在实施阶段；用**对冲包**补信任（见 §14.3） |
+| **N8** | Q19/Q21/Q22 报价/SLA/退出条款 | **商务决策**，不是产品能力 | 由商务出**书面条款**，产品文档不代答 |
+
+> **⭐ 一句话**：**上表 8 条不是"我们没做"，是"这事不由我方单方面定"。** 对客时**如实说"这部分要一起找医保/由公司出材料"**，比硬答更可信。
+
+### 13.2b ⭐ 待补清单（已识别缺口 · 尚未进需求正文）
+
+> **本节回答一件事**：哪些是"产品能做、但当前 PRD 还没定义"的缺口。**待补 ≠ 做不到**，是**尚未设计、留待确认后补入**。补入后移出本节。
+
+| # | 缺口 | 现状 | 待补内容（确认后补入 §4.5 / §7.4 / 验收） |
+|:---:|---|---|---|
+| **P-9** | **履约留痕·身份核验** | 现有 PRD **只有"拍照留痕"，没有"谁在现场、是不是本人"的核验机制** | 三选一或组合：①**扫脸核验**（护理员/老人人脸比对，需第三方识别或医保 APP 能力）；②**人证一致**（身份证号＋姓名比对＋签字）；③**签字确认**（护理员＋老人/家属电子签名）。须补字段：核验方式、核验结果、核验时间、经办人，并明确**无网络/老人无法扫脸的兜底**（如家属代签＋拍照佐证）。**注意：是否可调用医保 APP 扫脸，须与统筹区经办机构确认，非我方可自行定** |
+
+> **原则**：**P-9 是"待补"不是"已做"**。对客表述＝"**身份核验的落地方式，正在与医保/机构确认核验手段**"，**不得说"已实现扫脸"**。
+
+### 13.3 需商务/公司配合出书面材料的（产品侧无法单独收口）
+
+| # | 事项 | 归属 | 建议动作 |
+|:---:|---|---|---|
+| **B-1** | **首个客户对冲包**（POC 试运行 / 首年实施费减免 / 达标付费） | 商务 | 三选一或组合，**写进报价与合同** |
+| **B-2** | **等保备案现状、公司后续维护存续** | 公司 | 出**书面承诺/资质说明** |
+| **B-3** | **SLA、驻场、响应时限、退款、试用期数据条款** | 商务 | 写入**服务合同附件** |
+| **B-4** | **拍照分档属地核对**（§4.5.2） | 实施 | 列入**签约前必办清单**，双方签字 |
+
+---
+
+## 十四、对客边界说明（**六条，逐字可用**）
+
+1. **首期范围**：本期交付**待遇档案／派单工单／履约留痕／质控闸门**四块；**结算对账、人员资质、院长看板为二期**。
+2. **资质校验**：**"无资质不派单"是政策要求，但资质库在二期**。首期＝**人工登记＋派单时提示**，**不是自动禁派**。
+3. **医保状态同步**：首期**不做自动同步**。状态**由机构人工维护**，系统只能"提醒该核状态＋录后拦派单"，**不能替你发现状态变化**。
+4. **接口对接**：首期按**"人工登记＋文件导入导出"**设计，**预留专线口**。**不得表述为"已接通医保系统"**——正确表述是"**具备按医保部门统一接口规范对接的条件**"。
+   > **背景事实（昆明现状，写死）**：昆明长护险信息系统已于 **2025-01-01 切换到云南省医疗保障信息平台**，定点护理机构的护理员是**直接用「云南医保服务平台」APP 手工录入**服务数据（签到/签退、扫脸、定位、拍照、**服务项目与时长明细**）。**系统只自动算开始/结束时间，项目明细靠护理员护理完成后手工选择、手工录入**，机构须 **T+2 内**上传。⇒ **这不是"系统间自动传递"，而是"护理员在医保 APP 上人肉录入"**。故我方系统 P0 **不接医保直连、不自动同步评估/服务数据**，是符合昆明现行事实的正确边界，**不得误设计成"自动同步医保数据"的接口**。
+5. **结算数据**：首期**不自动生成结算申报数据**；服务记录可导出，**申报仍按现行方式人工办理**。
+6. **巡查与评分**：本系统只做**日常留痕与国家文书查阅项对照**，**不预测巡查评分、不承诺合格**；判定权在统筹地区医疗保障经办机构。
+7. **本轮新增能力（2026-10-12）**：**等待期垫付台账、十态待遇状态、扑空登记、拒拍出路、批量导入**等，均为**"需求已写定、开发中"**；**对客不得表述为"现已上线可验收"**。
+8. **身份核验（2026-10-12 新增待补）**：**首期不承诺"扫脸/人证识别"**。系统当前只做**拍照留痕**，**"谁在现场、是不是本人"的核验机制仍在确认中**。对客正确表述＝"**身份核验的落地方式正在与医保/机构确认**"，**不得说"已实现扫脸核验"**。
+
+---
+
+**云南投云科技有限公司**
+编制：滇小构｜2026-10-11（P0 PRD · 交付开发版 · V1）｜2026-10-12 按 22 条质疑回填修订｜2026-10-14 居家护理六流程字段对齐（只补字段）
diff --git a/docs/requirements/服务机构端-P0范围清单.md b/docs/requirements/服务机构端-P0范围清单.md
new file mode 100644
index 0000000..59c6e37
--- /dev/null
+++ b/docs/requirements/服务机构端-P0范围清单.md
@@ -0,0 +1,66 @@
+# 服务机构端 · 本期（P0）范围清单
+
+> 依据：`docs/requirements/20261011-投云长护险管理系统-P0 PRD（交付开发·V1）.md` + `docs/refs/` 数据字典与接口契约。
+> 用途：后续拆任务 / 开 openspec change 的**范围基线**。与 PRD 冲突时以 PRD 为准。
+
+## 1. 定位与形态
+
+- 长护险**护理服务机构端**，机构内部运营系统：官方医保 APP 管打卡留痕，本系统管内部运营（计划/派单/台账/质控/对账）。
+- **三端共用一套后端**：护理员 APP（安卓）／机构管理后台（Web）／家属公众号（H5 只读）。
+- 多租户按 `org_id` 隔离；属地（统筹区）决定服务目录与规则，**走配置不走代码**。
+
+## 2. P0 四块（本期交付）
+
+### ① 待遇档案
+- 老人建档：OCR 回填、参保地、参保核验留痕、**等级唯一来源＝评估结论**
+- 待遇状态机（**十态**）＋ `elder_status_log` 状态变更留痕
+- 老人个人项目库 `elder_svc`（派单带入源）
+- 批量导入（老人／护理员／项目配价）
+
+### ② 派单工单
+- 服务计划：制定／变更（新建＋指向旧，不原地改）／三方确认／属地项数校验
+- 排班派单：日视图、调单 ≤3 步、时间冲突硬拦、批量推荐需人工确认
+- 工单状态机（**八态**，含「未遇/扑空」）
+- 垫付期台账与「结转」（`is_prepaid`）
+
+### ③ 履约留痕
+- 签到/签退：**服务器取时**、定位失败不阻塞、离线可用、`client_md5` 去重
+- 项目勾选：默认全勾、`exec_result` 枚举（`done/undo_not_done/undo_refused`）、临时加项
+- 拍照分档（必拍/免拍/可拍）＋ 拒拍出路 ＋ 压疮结构化标签
+- 异常上报（9 宫格、语音、照片可选）
+- 未遇（扑空）专门形态
+
+### ④ 质控闸门
+- 全量质控（非抽检）＋ 五类主动推送
+- 放行/退回（退回必填原因；**禁止自审自放行 `4001`**）
+- 异常联动改计划
+
+## 3. 支撑能力（横切）
+
+- 多属地目录四层 L1–L4（`svc_national/svc_local/svc_mapping/svc_org`）＋ 五条纪律
+- RBAC：五角色（`nurse/leader/qc/admin/director`）多值 + 并集判权 + 字段级权限（身份证/手机号/照片）+ 本组界定
+- 六条硬锁 L1–L6（L6 本期降级为**提示**，二期改硬拦）
+- 统一响应 `{code,message,data,hint}` + 错误码表（`1001`–`4001`）
+- 字典（异常分类、拍照分档）、文书导出（合规版式、服务端掩码、访问留痕）
+- 离线队列 + 自动补传
+
+## 4. 数据层（23 表）
+
+- **业务主链**：`org` `user` `staff` `elder` `elder_status_log` `elder_svc` `plan` `plan_item` `order` `record` `record_item` `record_photo` `record_abnormal` `qc`
+- **目录四层**：`svc_national` `svc_local` `svc_mapping` `svc_org`
+- **字典/配置**：`dict_abnormal_type` `dict_photo_tier` `loc_config`
+- **预留（建表不写数据）**：`report` `settlement`
+
+## 5. 接口层
+
+6 组 40+：A 待遇档案 / B 服务计划 / C 派单工单 / D 履约留痕 / E 质控闸门 / F 家属端。
+
+## 6. 二期不做（只留字段，本期不实现）
+
+- 结算对账（B5）、人员资质（B6）、院长看板（B0）
+- 上报池、医保接口对接、扫脸/身份核验（P-9 待补）
+- 多业务线（`biz_line` 恒 `ltci`，只留锚点）
+
+## 7. 验收基线（11 条硬指标）
+
+≤4 击（常态 3 击）、必填自由文本 = 0、离线可用＋自动补传、字号 ≥20pt、首屏即任务、误操作可撤销、调单 ≤3 步、异常主动推送、导出即合规版式、家属端零任务、最小必要留痕。
diff --git a/docs/requirements/评估机构端-待设计清单.md b/docs/requirements/评估机构端-待设计清单.md
new file mode 100644
index 0000000..e851a20
--- /dev/null
+++ b/docs/requirements/评估机构端-待设计清单.md
@@ -0,0 +1,30 @@
+# 评估机构端 · 待设计清单（后续阶段）
+
+> 状态：**宏观要做，但当前无任何文档定义，是纯缺口**。本文只列「需要设计什么」与「开放问题」，**不含既定需求**。补入正式需求后移出本文。
+
+## 1. 现状（唯一落点）
+
+- 服务机构端 PRD 仅在 `elder` 表记录**外部**评估机构：`assess_org`（评估机构名）、`assess_date`（评估结论日期）、`assess_level`（失能等级）。
+- 无评估端产品、门户、接口、角色。
+- 政策口径：服务机构端「不做评估、不出评估结论」，评估属评估机构职责（P0 PRD §11.1）。
+
+## 2. 待设计领域（开放）
+
+1. **定位与形态**：评估机构端是独立后台？独立 APP？还是与服务机构端同一平台下的另一类租户？
+2. **角色与账号**：评估机构管理员、评估员；与服务机构端 `org`/`user` 的关系（多租户模型如何区分两类机构）。
+3. **评估任务生命周期**：受理 → 派评估员 → 上门评估 → 出结论 → 回传。
+4. **评估量表与等级判定**：国家/云南失能评估标准、量表结构化、等级计算（`sev_1..3`）。
+5. **结论回流**：评估结论如何写入服务机构端 `elder.assess_level`（接口直连 vs 文件导入）。
+6. **与医保/官方对接**：评估结论是否来自省平台；接口规范未发布（同服务机构端 R5 预留口径）。
+7. **复评/到期重评**：与服务机构端「复评等待期」「待遇到期」状态联动。
+
+## 3. 关键开放问题（待确认）
+
+- 评估机构是否也是「多租户 `org`」？`org.org_type` 是否需要新增评估机构类型？
+- 评估结论的**权威来源**：我方系统自产，还是对接官方/医保平台拉取？
+- 现有 `elder.assess_*` 三字段是否够用，还是需扩展为独立评估域（如 `assess_task`/`assess_result`）？
+
+## 4. 结构预留建议（本期可做、不改逻辑）
+
+- 保持 `elder.assess_*` 字段现状，未来升级为独立评估域表（任务/结果/量表）。
+- 服务机构端 P0 **不阻塞**：评估结论当前以「机构线下确认为准」落 `elder.insur_verify_*` 留痕，字段已留。