# 2026-09-15

## 能力评估弹窗改为只读 + 强制走长者信息接口

### 改动内容
1. `src/views/elderly/assess/synthetic-ability/Form.vue`
   - 评估基本信息中，从长者信息带出的字段全部置为 `disabled`，不可编辑：
     - 民族、身高、体重
     - 宗教信仰、文化程度、婚姻状况、居住情况、经济来源、医疗费用支付方式
   - 已禁用的字段仍通过 `selectElder` 的 `@elder` 事件（即 `getElderInfoById`）回填，保持数据来自长者信息。

2. `src/views/elderly/assess/synthetic-ability/Print.vue`
   - 引入 `getElderInfoById`。
   - 打印弹窗 `open(id)` 时，先拉取评估记录，再用 `res.elderId` 调用长者信息接口。
   - 基础信息字段（性别、证件、出生日期、年龄、民族、身高体重、宗教信仰、文化程度、婚姻、居住、经济来源、医疗支付、姓名）改为**优先从长者信息接口取**，评估记录与 `res.elder` 仅作为兜底。

### 验证
- 运行 `vue-tsc --noEmit` 全量类型检查：本次改动的两个文件区域无新增报错；`synthetic-ability` 目录下的历史 `{}`/`never` 类型报错为既有问题，与本次改动无关。

## 能力评估增加「修改」功能（评估后可再次编辑）

### 需求
用户指出 `v-show="scope.status == 0 && scope.questionnaireType != 2"` 仅控制「评估」按钮（仅未评估 status==0 可见），评估后无法再改；要求补充「修改」入口并排查隐患。

### 改动
1. `src/views/elderly/assess/synthetic-ability/index.vue`
   - `Table2` 新增 `:show-edit-condition="() => false"`，屏蔽内置「编辑」按钮（其 `emit('edit')` 无 `@edit` 处理，是死按钮）。
   - `#pre` 插槽新增「修改」按钮：`v-show="scope.status != 0 && scope.questionnaireType != 2"`，`@click="openForm(scope)"`，权限复用 `synthetic-ability:audit`。
2. `src/views/elderly/assess/synthetic-ability/Form.vue`（修两个隐藏 bug）
   - `open(id)` 加载记录时，`evaluatorDate` 改为 **保留原评估日期**（原 `new Date()...` 每次编辑都被重置为今天）。
   - `submitForm('1')` 保存时 `obj.status = dataForm.value.status || 1`（原硬写 `obj.status = 1`，会把已签字 status=2 误改回 1）。

### 关键事实
- `Form.open(id)` 已能按 id 加载记录，`submitForm` 走 `elderlySyntheticAbility/addOrUpdate`（upsert），修改链路本来就通，缺的只是列表入口。
- `status` 语义：0=未评估（显示「评估」），1=已评估，2=已签字；`questionnaireType==2` 两类按钮都不显示（保持原行为）。
- 「修改」复用了与「评估」相同的 `openForm`/Form，基础信息字段此前已 disabled（取自长者信息），修改时仍只读，仅评估内容可改。

## 能力评估第四步「长者能力评估」编辑回显为空修复

### 根因
`Form.vue` 的 `open(id)` 编辑流程中：
- `dataForm.value.syntheticAbilityInfoList` 被 `JSON.parse(res.syntheticAbilityInfoList)` 正确解析为数组。
- 但后面回填答案时用的是 **原始 `res.syntheticAbilityInfoList`**，它仍是后端返回的 JSON 字符串（不是数组）。
- 字符串没有 `.map` 方法，执行到 `res.syntheticAbilityInfoList.map(...)` 时抛出异常，整个 `try` 块直接跳到 `finally`，导致**第四步模板的答案回填逻辑被跳过**，表单显示为空白模板。

### 改动
`src/views/elderly/assess/synthetic-ability/Form.vue`
- 在 `open(id)` 内新增 `parseArr` 通用解析函数：兼容 `null` / 数组 / JSON 字符串 / 对象。
- 提前解析 `syntheticAbilityInfoList` 与 `processSequenceList`，并显式写入 `dataForm.value`。
- 回填逻辑改为使用解析后的数组，并增加 `item.template` 存在性保护，避免空指针。
- 同步用 `parseArr` 替代 `medicationSituation`、`absenceOfTeeth`、`dentureWearingCondition`、`dysphagia` 等字段的原 `JSON.parse`，避免后端若返回数组时崩溃。

## 能力评估第四步编辑仍不回显的二次修复

### 根因
上一轮修复后，用户反馈第四步已保存的选项**仍未选中**。深入排查发现：
- `res.processSequenceList` 本身虽是数组，但内部每个 `item.template` 字段在后端落库/返回时被**二次 JSON 序列化成字符串**（或极少数场景下是数组）。
- 原回填逻辑直接用 `item.template.templateName` 做匹配：当 `item.template` 是字符串时，`templateName` 为 `undefined`，匹配永远失败，`templateProperties` 不会被替换成已保存的 `evaluationContent`，FCForm 只能渲染空模板。
- 此外，原匹配使用 `item.template.templateName`，但保存时 `evaluationName` 取的是**顶层** `processSequenceList[index].templateName`，存在名字不一致导致匹配失败的风险。

### 改动
`src/views/elderly/assess/synthetic-ability/Form.vue`
- `open(id)` 中解析 `processSequenceList` 时，对每个 `item.template` 做标准化：
  - 字符串 → `JSON.parse` 为对象；
  - 数组 → 取第一项（与业务实际一致，一个序列只有一个模板）；
  - 解析失败则置 `undefined`，避免后续空指针。
- 回填匹配改为优先使用 `item.templateName`（顶层），兜底 `item.template.templateName`，与保存时的 `evaluationName` 来源一致。
- 删除已废弃的 `processSequenceList` ref 声明（模板直接使用 `dataForm.processSequenceList`）。

### 验证
- 全量 `vue-tsc --noEmit`：`src/views/elderly/assess/synthetic-ability/Form.vue` 改动区域**无新增类型错误**；`synthetic-ability/components/FCForm.vue` 与 `evaluation-process/*` 的历史类型报错为既有问题，与本次改动无关。

## 能力评估第五步「评估报告」推荐护理等级未回显修复

### 根因
- 第五步「评估报告」由 `Result.vue` 渲染，其中的 `推荐护理等级` 下拉框绑定的是 `Result.vue` 自己的 `nursingLevel` ref，初始值为空字符串。
- `Form.vue` 虽然把 `res.recommendedNursingLevel` 回填到了 `dataForm.recommendedNursingLevel`（第四步也有同名字段），但**从未把这个值传给 `Result.vue`**。
- 提交时（`submitForm`）又只取 `resultRef.value.nursingLevel`，所以新增时只要第五步选了就能保存；但编辑时第五步的下拉框因为没收到 prop，始终保持为空。

### 改动
1. `src/views/elderly/assess/synthetic-ability/components/Result.vue`
   - 新增 prop `recommendedNursingLevel`（String，默认空）。
   - 添加 `watch(() => props.recommendedNursingLevel, ...)`，在 prop 变化或初始化时同步到 `nursingLevel` ref，实现回填。

2. `src/views/elderly/assess/synthetic-ability/Form.vue`
   - `<Result>` 组件调用处新增 `:recommendedNursingLevel="dataForm.recommendedNursingLevel"`。

### 验证
- 全量 `vue-tsc --noEmit`：本次改动文件无新增类型错误。

## 能力评估第五步推荐护理等级回显为数字的修复

### 根因
- 上一步虽然把 `recommendedNursingLevel` 传给了 `Result.vue`，但后端返回的是字符串 `"13"`，而 `nurseLevelList` 中 option 的 `:value="n.id"` 是数字 `13`（或相反）。
- Element Plus 的 `el-select` 对 `v-model` 与 `el-option :value` 做严格等值比较，类型不一致时匹配失败，组件直接显示原始值（如 `13`）而不是中文 label。

### 改动
1. `src/views/elderly/assess/synthetic-ability/components/Result.vue`
   - prop `recommendedNursingLevel` 类型改为 `[String, Number]`。
   - `watch` 中按 `String(n.id) === String(val)` 查找匹配项，把 `nursingLevel` 设为匹配项的 `id`（与 option value 保持同类型），保证 `el-select` 能正确显示中文 label。
   - `nursingLevel` ref 类型改为 `string | number`。

### 验证
- 全量 `vue-tsc --noEmit`：本次改动文件无新增类型错误。
- 期间引入并即时修复了 `Result.vue(351)` `Property 'id' does not exist on type '{}'`（`props.nurseLevelList` 元素类型推断为 `{}`），改用 `(props.nurseLevelList as any[]).find(...)` 并 `matched as any` 断言解决。
- 注意：本仓库的 `vue-tsc` 通过 `node ./node_modules/vue-tsc/bin/vue-tsc.js --noEmit` 运行；Git Bash 环境下 `grep/head` 常缺失，过滤需用绝对路径的 python/node 读 `tsc_out.txt`（/tmp 在 Windows 不存在，输出应写到项目目录下）。