Commit Graph

3110 Commits

Author SHA1 Message Date
b36bf4e1be fix(#581): 请修复 Bug #581:[一般] 【住院医生站-临床医嘱-手术】手术申请单缺失多项核心业务字段与强拦截逻辑,导致医疗安全制度无法落地且阻断手术室排班闭环
根因:
- Bug #请修复 Bug #581 存在的问题

修复:
- 变更摘要
- ### 修改文件
- 1. `src/views/inpatientDoctor/home/components/order/applicationForm/surgery.vue`**
- 在"发往科室"字段之后,依次新增了以下 9 个业务字段:
- | 字段 | 控件类型 | 必填 | 数据来源 |
- |---|---|---|---|
- | 手术等级 | `el-select` 下拉 |  | 字典 `surgery_level` |
- | 麻醉方式 | `el-select` 下拉 |  | 字典 `anesthesia_type` |
- | 手术部位 | `el-select` 下拉 |  | 字典 `surgery_site` |
- | 切口类别 | `el-select` 下拉 |  | 字典 `incision_level` |
- | 手术性质 | `el-select` 下拉 |  | 字典 `surgery_type` |
- | 主刀医生 | `el-select` 可搜索 |  | `listUser` API,默认当前登录医生 |
- | 第一助手 | `el-select` 可搜索 |  | `listUser` API |
- | 第二助手 | `el-select` 可搜索 |  | `listUser` API |
- | 预定手术时间 | `el-date-picker` datetime |  | 无默认值 |
- 新增逻辑:
- `loadDictOptions()`** — 并行加载 5 个字典选项
- `loadDoctorOptions()`** — 加载医生列表,自动设当前登录用户为主刀医生默认值
- `submit()` 新增强拦截校验** — 手术等级、麻醉方式、手术部位、主刀医生、预定手术时间为必填,为空时阻断提交并提示
- 2. `src/views/inpatientDoctor/home/components/applicationShow/surgeryApplication.vue`**
- `labelMap` 新增 9 条标签映射,确保详情弹窗能正确显示新字段的中文标签。
- ### 全链路完整性
- 录入  前端弹窗增加输入控件
- 保存  通过 `descJson: JSON.stringify(form)` 序列化,后端无需改动
- 查询  详情展示组件新增 labelMap 映射
- 修改 ⏸ 申请单编辑功能不在本轮范围(后续迭代可复用 submit 逻辑)
- 删除  不影响
- 关联  门诊手术申请走独立 API,不共享 descJson,无需修改
- ### 验证
- `npm run lint` —  通过,无错误
2026-05-29 02:42:14 +08:00
6baac543c9 fix(#580): 请修复 Bug #580:[一般] [住院医生工作站-临床医嘱-手术] 手术申请单穿梭框组件非标:检索框溢出至卡片外部且检索机制存在“3字硬性限制”,需恢复
根因:
- Bug #请修复 Bug #580 存在的问题

修复:
- 修复 Bug #580
- 文件修改**: `src/views/inpatientDoctor/home/components/order/applicationForm/surgery.vue`
- ### 问题 1:检索框溢出至卡片外部
- 原因**: 搜索框(`<el-input>`)被放置在 `el-transfer` 组件外部,导致脱离了穿梭框面板,排版错乱
- 移除外部的搜索框 `<div>` 和加载提示 `<div>`
- 改用 `el-transfer` 内置的 [`filterable`](https://element-plus.org/zh-CN/component/transfer.html#transfer-%E5%B1%9E%E6%80%A7) 属性,搜索框会自动渲染到左侧面板「待选择」的标题下方
- ### 问题 2:检索机制存在"3字硬性限制"
- 原因**: `onSearchInput` 函数中有 `val.length >= 3` 的判断逻辑,少于 3 个字符不触发搜索
- 移除 `searchKey` ref、`searchDebounceTimer`、`onSearchInput` 函数
- 新增 `filterMethod` 函数,使用 `el-transfer` 的内置过滤机制,支持任意字符即时前端模糊匹配
- 占位提示改为 `"项目代码/名称"`
- 过滤逻辑:同时匹配项目名称(`label`)和项目 ID/代码(`key`),忽略大小写
- ### 验证
- `npm run lint` 通过 
- 模板/脚本/样式标签结构完整 
2026-05-29 02:36:11 +08:00
b96d327646 fix(#579): 请修复 Bug #579:[一般] [报表管理-院内整体收入明细查询-门诊收费报表]列表的格式错乱
根因:
- `processListWithSubtotals` 中的小计行使用 `...list[i]` 展开第一行所有字段
- 导致小计行在 **姓名、医保号、药品项目、规格** 等 10+ 个列中显示第一行的错误数据,形成"字段不对应"的格式错乱
- 2. 表格缺少视觉分隔**
- `<el-table>` 缺少 `border` 和 `stripe` 属性,合并单元格后难以区分行列边界
- ### 修改内容
- | 文件 | 变更 |
- |---|---|
- | `src/views/medicationmanagement/statisticalManagement/outPatientCharge.vue` | 2 处改动 |
- 改动明细:**
- 1. **`el-table` 添加 `border` + `stripe`** — 使单元格有清晰边框,交替行色提升可读性
- 2. **小计行移除 `...list[i]` 字段展开** — 小计行仅保留 `departmentName: '小计'` 和 `totalPrice`,其他列自动为空,确保字段一一对应
- ### 验证
-  ESLint 无错误
-  Vite build 编译成功
-  修改范围最小化(仅 2 处改动,+3/-1 行)

修复:
- Bug #579 门诊收费报表格式错乱
- ### 分析过程
- 通过全链路代码审查,发现两个核心问题:
2026-05-29 02:29:55 +08:00
09b7f8b632 fix(#578): 请修复 Bug #578:[一般] [患者管理] 修改患者信息时,级联省市区回显为空,且详细地址字段发生重复、循环拼接
根因:
- Bug 1 — 级联省市区回显为空:** `patientAddDialog.vue` 的 `convertAddressToCodes` 函数是存根(stub),始终返回 `null`,导致回显时级联选择器无法选中任何值。
- ### 修改文件
- `src/views/charge/outpatientregistration/components/patientAddDialog.vue`
- | 位置 | 改动 |
- |---|---|
- | `convertAddressToCodes` 函数 | 从存根替换为递归名称→代码查找(`findCodeByName`),使用 `options.value`(pcas 数据树)按名称匹配返回 code |
- | `setFormData`(级联回显块后) | 新增地址前缀剥离逻辑:用 `addressProvince`+`addressCity`+`addressDistrict`+`addressStreet` 拼接前缀,从全地址 `address` 中去除前缀,使 `form.value.address` 只保留用户输入的详细地址部分(如"村道120号") |
- ### 验证
- `npx eslint` — 0 errors, 仅 pre-existing warnings

修复:
- 修改相关代码文件
2026-05-29 02:20:20 +08:00
6e90c32736 fix(#577): 请修复 Bug #577:[一般] [住院医生工作站-检验] 检验申请单项目列表中的单价/使用单位展示异常,单位回显为字典数字ID(如 6, 16)而非中文
根因:
- JEECG/MyBatis-Plus 字典翻译插件的默认输出格式为 `{field}_dictText`(**下划线**格式),但代码中有 3 处使用了 `unitCodeDictText`(**驼峰**格式),导致字典翻译字段始终返回 `undefined`,回退显示了原始字典数字 ID(如 6、16)。

修复:
- | 文件 | 行号 | 修改前 | 修改后 |
- |---|---|---|---|
- | `laboratoryTests.vue` | 291, 415 | `item.unitCodeDictText` | `item.unitCode_dictText` (已有提交) |
- | `surgery.vue` | 202 | `item.unitCodeDictText` | `item.unitCode_dictText`  |
- | `medicalExaminations.vue` | 364 | `item.unitCodeDictText` | `item.unitCode_dictText`  |
- ### 全链路验证
- 展示**  — `el-transfer` 的 label 渲染现在能正确获取字典翻译中文名
- 搜索**  — 搜索逻辑中的单位生成也已同步修正
- 保存**  — `submit` 中的 `unitCode` 字段使用原始编码,不受影响
2026-05-29 02:16:20 +08:00
5b194948a1 fix(#577): 请修复 Bug #577:[一般] [住院医生工作站-检验] 检验申请单项目列表中的单价/使用单位展示异常,单位回显为字典数字ID(如 6, 16)而非中文
根因:
- JEECG/MyBatis-Plus 字典翻译插件的默认输出格式为 `{field}_dictText`(**下划线**格式),但 `laboratoryTests.vue` 中使用了 `unitCodeDictText`(**驼峰**格式),导致 `unitCodeDictText` 始终为 `undefined`,回退显示了原始数字ID。
- 对比证据:
- `bloodTransfusion.vue`(输血,展示正常):  `unitCode_dictText`
- `laboratoryTests.vue`(检验,本Bug):  `unitCodeDictText`
- ### 修改内容
- 文件**: `src/views/inpatientDoctor/home/components/order/applicationForm/laboratoryTests.vue`
- | 行号 | 修改前 | 修改后 |
- |------|--------|--------|
- | 291 | `item.unitCodeDictText` | `item.unitCode_dictText` |
- | 415 | `searchData.unitCodeDictText \|\| searchData.unitCode_dictText` | `searchData.unitCode_dictText` |
- 两处都修正为下划线格式 `unitCode_dictText`,与项目其他正常工作组件保持一致。
- ### 全链路检查
- 录入/展示**  — el-transfer 的 `buildTransferData` 现在能正确获取字典翻译名
- 搜索**  — `handleSearch` 中的单位生成逻辑也已修正
- 保存**  — `submit` 中的 `unitCode` 字段提交不受影响
- ### ⚠️ 同类型问题提醒

修复:
- 修改相关代码文件
2026-05-29 02:12:40 +08:00
66dd93908d fix(#573): 请修复 Bug #573:[一般] [门诊医生工作站-诊断] 确诊配置了“报卡类型”的疾病后,保存诊断未自动触发传染病报卡弹窗
根因:
- 但后端其实已经准备好了:**
- `getEncounterDiagnosis` 接口返回的每个诊断项包含了 `reportTypeCode`(报卡类型)和 `hasInfectiousReport`(是否已有报卡)字段
- 前端 `getList()` 获取数据后,这些字段已经挂载在 `form.value.diagnosisList` 的诊断项上
- 只是 `handleInfectiousDiseaseReport()` 一直没使用它们
- ### 修改文件
- `src/views/doctorstation/components/diagnosis/diagnosis.vue`
- ### 修改内容
- 将 `handleInfectiousDiseaseReport()` 的判断逻辑从**仅依赖硬编码名称映射**改为**三阶段判断**:
- 1. **精确名称匹配** — 优先匹配已有映射表中的疾病名(如"霍乱"→'0102')
- 2. **部分名称匹配** — 对有 `reportTypeCode` 但名称不精确匹配的诊断,尝试子串匹配(如"古典生物型霍乱"包含"霍乱"→'0102')
- 3. **`reportTypeCode` 兜底** — 配置了报卡类型但无法匹配任何已知疾病名,仍弹出弹窗(`diseaseCode = 'OTHER'`),让医生手动填写
- 同时保留原有规则:
- 跳过已有已提交报卡的诊断(`hasInfectiousReport === 1`)

修复:
- ### 问题分析
2026-05-29 02:06:02 +08:00
78eb68315e fix(#572): 请修复 Bug #572:[一般] [门诊医生工作站-诊断] 传染病报告卡未自动同步并填充患者档案中的“现住址”与“职业”信息
根因:
- 医生站 `PatientInfoDto` 中不包含患者地址和职业字段,传染病报卡弹窗的 `show()` 函数使用 `diagnosisData?.addressProv || ''`(诊断数据中的地址,始终为空)和硬编码 `occupation: ''`,完全未从患者档案获取数据。
- ### 修改内容(4 个文件)
- 后端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `openhis-application/.../dto/PatientDetailsDto.java` | 新增 `addressProvince`、`addressCity`、`addressDistrict`、`addressStreet` 4 个地址字段 |
- | `openhis-application/.../mapper/doctorstation/DoctorStationPtDetailsAppMapper.xml` | SQL 查询增加 `p.address_province`、`p.address_city`、`p.address_district`、`p.address_street` |
- 前端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `src/views/doctorstation/components/api.js` | 新增 `getPatientDetails(encounterId)` API 函数 |
- | `src/views/doctorstation/components/diagnosis/infectiousDiseaseReportDialog.vue` | `show()` 中调用 `getPatientDetails`,将患者档案中的地址和职业自动填入报卡表单 |
- ### 数据字段映射
- adm_patient表          PatientDetailsDto    报卡表单字段
- ─────────────────────────────────────────────────────
- address_province  →  addressProvince     →  addressProv
- address_city      →  addressCity         →  addressCity
- address_district  →  addressDistrict     →  addressCounty
- address_street    →  addressStreet       →  addressTown
- prfs_enum         →  prfsEnum_enumText   →  occupation
- ### 全链路验证
- 录入** → 报卡弹窗自动调用 `/doctor-station/patient-details/patient-details?encounterId=X` ✓
- 保存** → 地址和职业字段已包括在 `saveInfectiousDiseaseReport` 提交数据中 ✓
- 查询/回显** → `showReport()` 正确读取已有报卡的地址和职业 ✓
- 编译** → 前端 `npm run lint` ✓,后端 `mvn compile` ✓

修复:
- 变更摘要
2026-05-29 01:56:42 +08:00
3a29797808 fix(#570): 请修复 Bug #570:[一般] [门诊预约挂号] 患者预约成功后的状态显示错误为“已锁定”,导致查询“已预约”状态数据为空
根因:
- 后端将预约成功后的槽位状态设为 `LOCKED(2)`,但前端 `SlotStatusDescriptions` 将 `2` 映射为 `"已锁定"`,导致:
- 页面显示为 `"已锁定"` 而非正确的 `"已预约"`
- 状态筛选栏按 `"已预约"` 过滤时匹配不到数据
- ### 修改内容(2 个文件,+3/-4 行)
- `src/utils/medicalConstants.js`** — 状态映射修正
- `SlotStatus.LOCKED` 注释:`已锁定` → `已预约(预约后未签到)`
- `SlotStatusDescriptions[2]`:`'已锁定'` → `'已预约'`
- `SlotStatusClassMap`:删除不再使用的 `'已锁定': 'status-locked'`(表中已有 `'已预约': 'status-booked'`)
- `src/views/appoinmentmanage/outpatientAppointment/index.vue`** — 提示文案更新
- 预约成功提示:从 `"预约成功,号源已锁定。患者到院签到时需缴费取号。"` 改为 `"预约成功,请提醒患者按时到院签到取号。"`
- ### 验证
- `eslint` 对修改文件检查通过,无新错误
- 修改范围精准,仅涉及状态字符串映射,不影响其他逻辑

修复:
- Bug #570
2026-05-29 01:49:06 +08:00
ffe01ae68e fix(#570): 请修复 Bug #570:[一般] [门诊预约挂号] 患者预约成功后的状态显示错误为“已锁定”,导致查询“已预约”状态数据为空
根因:
- 预约成功后,槽位状态从 `AVAILABLE(0)` → `LOCKED(2)`。后端 `TicketAppServiceImpl.listTicket` 方法中将 `LOCKED(2)` 映射为 `"已锁定"`,但业务上此状态应显示为 **"已预约"**(预约后未签到)。
- 状态流转正确语义:
- `LOCKED(2)` = 已预约但未签到 → 应显示 **"已预约"**
- `BOOKED(1)` = 已签到/已取号 → 应显示 **"已取号"**(原本正确)
- ### 修改文件
- 后端(1 个文件)**
- `openhis-server-new/openhis-application/src/main/java/com/openhis/web/appointmentmanage/appservice/impl/TicketAppServiceImpl.java`
- 第 202 行:`dto.setStatus("已锁定")` → `dto.setStatus("已预约")`
- 第 383 行:同上(两处相同逻辑)
- 前端(1 个文件)**
- `openhis-ui-vue3/src/views/appoinmentmanage/outpatientAppointment/index.vue`
- 状态筛选下拉框移除 `"已锁定"` 选项
- 移除 `STATUS_CLASS_MAP` 中的 `"已锁定": "status-locked"`
- 移除 `applyStatusFilter` 中的 `locked: ['已锁定']`
- ### 验证结果
-  后端 `mvn compile` 通过
-  前端 `npm run lint` 通过(无新增错误)

修复:
- Bug #570 修复
2026-05-29 01:45:05 +08:00
2aaafb408b fix(#569): 请修复 Bug #569:[一般] [住院护士站-医嘱管理] 各业务节点状态名称与《药品医嘱状态映射表》不一致,存在严重歧义
根因:
- 后端 `requestStatus_enumText` 返回旧枚举值(如"已发送""已完成"),前端部分组件直接使用原始枚举文本而未做名称映射,导致界面显示与标准映射表不一致。
- ### 关键映射关系(按《药品医嘱状态映射表》修订版)
- | 业务节点 | 规范名称 | 旧枚举文本 |
- |---|---|---|
- | 开具 | 待签发 | 待发送 |
- | 签发 | 已签发 | 已发送/已发送/待执行 |
- | 校对 | 已校对 | 已完成 |
- | 汇总申请(护士站) | 已提交 | 待配药/已汇总 |
- | 发药(护士站→药房) | 已发药/已完成 | 已发放 |
- ### 修改文件
- 1. `src/views/inpatientNurse/medicalOrderProofread/components/prescriptionList.vue`**

修复:
- 将 `STATUS_DISPLAY_BY_TAB`(基于页签过滤条件的显示)替换为行级别的状态映射
- 新增 `REQUEST_STATUS_DISPLAY`:按 `row.requestStatus` 数值映射规范名称(待签发/已签发/已校对/已停止)
- 新增 `DISPENSE_STATUS_DISPLAY`:按 `row.dispenseStatus` 映射发药状态(已提交/已发药)
- 新增 `LEGACY_STATUS_TEXT`:兼容旧后端返回的 "已发送"→"已签发"、"已完成"→"已校对" 等
- 2. `src/views/drug/inpatientMedicationDispensing/components/MedicationDetails.vue`**
- 新增 `DRUG_STATUS_DISPLAY` + `LEGACY_DRUG_STATUS_TEXT` 映射
- `statusEnum=2` 显示"待配药"(原显示"已提交"),`statusEnum=4` 显示"已发药"
- 3. `src/views/drug/inpatientMedicationDispensing/components/DetailMedicationTable.vue`**
- 新增 `DETAIL_DRUG_STATUS_DISPLAY` + `DETAIL_LEGACY_STATUS_TEXT` 映射
- ### 已存在的正确映射(无需修改)
- `medicalOrderExecution/components/prescriptionList.vue` — 已有完整映射
- `drugDistribution/components/summaryMedicineList.vue` — 已有 `SUMMARY_STATUS_DISPLAY`
- `inpatientMedicationDispensing/components/MedicationSummary.vue` — 已有 `SUMMARY_STATUS_DISPLAY`
- ### 验证
-  ESLint 检查通过(无新增错误)
-  `vite build` 编译成功
2026-05-29 01:31:59 +08:00
504875b011 fix(#568): 请修复 Bug #568:[一般] [收费工作站-门诊日结]排版很乱
根因:
- Bug #请修复 Bug #568 存在的问题

修复:
- 给 `.data-label` 添加 `min-width: 90px`,确保所有数据标签有统一的最小宽度,值从同一水平位置开始,对齐清晰。
- 验证**: `eslint` 检查通过 (无错误)
- ### 页面布局说明
- 当前页面结构已比较完善——搜索栏(`label-width="auto"`)、信息头(4列flex布局)、3个区块的数据卡片(收入汇总/医保支付/费用明细)。本次改动只加了一行 CSS,解决了"每个都能对应上"的核心对齐问题。
- > 注:`vite.config.js.timestamp-*.mjs` 临时文件较多(可能是多次热更新残留),如有需要可清理。
2026-05-29 01:22:05 +08:00
c9122d58be fix(#568): 请修复 Bug #568:[一般] [收费工作站-门诊日结]排版很乱
根因:
- Bug #请修复 Bug #568 存在的问题

修复:
- ### 变更摘要
- 文件**: `src/views/clinicmanagement/dayEnd/index.vue`
- 1. **搜索表单布局修正**
- 将 `label-width="90px"` 改为 `label-width="auto"`,消除固定宽度导致的 label 列空白
- 移除 `search-buttons` 自定义 class,按钮改为独立的 `el-form-item`(不带 label),与查询条件在同一视觉基线
- 2. **标签/值对齐统一**(排版混乱的核心原因)
- 所有 `data-label` 改为**左对齐**(原来右对齐),符合报表"左标签右数值"的常规排版
- 标签去掉末尾冒号 `:`(`data-cell` 的 `justify-content: space-between` + 清晰的边框已足以区分)
- `data-value` 保持**右对齐**,金额数字加粗 `font-weight: 600` + 等宽数字字体 `font-variant-numeric: tabular-nums`
- `info-label` min-width 统一为 `90px`,与 data-label 规格一致
- 3. **数据卡片视觉增强**
- 新增浅色边框 `border: 1px solid #f0f0f0`,每个数据项有清晰的外框
- `padding` 从 `8px 12px` 加大到 `10px 16px`,间距更舒适
- 背景色仅在 hover 时变化(`transition: background-color 0.2s`)
- 圆角从 `4px` 提升到 `6px`
- 4. **分隔与间距优化**
- `el-divider` 上下间距从 `12px` 增加到 `16px`
- `summary-row` 上边距从 `8px` 增加到 `12px`
- `info-row` 每项底部加浅色分隔线 `border-bottom: 1px solid #f0f0f0`
- 5. **响应式适配**
- 小屏幕下 `data-cell` 缩小内边距,`data-label` 取消固定 min-width
- ### 验证结果
- `eslint` 检查通过 (无错误)
- `vite build` 构建通过 
2026-05-29 01:17:29 +08:00
8054cb31be fix(#619): 请修复 Bug #619:[一般] [住院登记] 已登记病人点击“查看”时,入院日期回显错误(显示为当前系统时间而非实际入院时间)
根因:
- 在 `registerForm.vue` 的 `setValue()` 函数中,**没有将 `props.inHospitalInfo?.startTime` 赋值给表单的 `startTime` 字段**。
- 表单初始化时,`startTime` 固定为 `formatDateStr(new Date(), 'YYYY-MM-DD HH:mm:ss')`(当前系统时间)
- 点击"查看"时,`inHospitalInfo` 虽然从 API 正确获取了入院日期,但 `setValue()` 并未将此值回填到表单
- 因此弹窗始终显示当前时间,而非实际入院日期

修复:
- 修改文件**: `src/views/inHospitalManagement/charge/register/components/registerForm.vue`
- 在 `setValue()` 函数中添加了 `startTime` 字段的回显逻辑:
- ```javascript
- submitForm.startTime = props.inHospitalInfo?.startTime
- ? formatDateStr(props.inHospitalInfo.startTime, 'YYYY-MM-DD HH:mm:ss')
- : submitForm.startTime;
- 当存在已保存的入院日期时 → 使用 API 返回的实际值
- 当没有保存的入院日期(新登记场景)→ 保持默认的当前时间
- ### 全链路验证
- | 环节 | 状态 |
- |------|------|
- | 保存 | 后端 `InHospitalInfoDto.startTime` 字段已正确存储入院日期 |
- | 查询 | API `getInHospitalInfo` 已返回 `startTime` 字段 |
- | 回显 | `setValue()` 现正确将 `startTime` 赋值给表单 |
- | 编辑/修改 | 已登记状态下日期字段为 `disabled`,不会误改 |
- | 其余字段 | 不受影响 |
2026-05-29 01:01:24 +08:00
cdd05cbe0e fix(#593): 请修复 Bug #593:【住院医生工作站-临床医嘱】长期医嘱模块缺失取消停嘱功能
根因:
- Bug #请修复 Bug #593 存在的问题

修复:
- ## 变更摘要
- ### Bug #593:长期医嘱缺失"恢复"功能
- #### 修改的文件(5个)
- 前端 (Vue 3)**
- `src/views/inpatientDoctor/home/components/api.js`
- 新增 `cancelStopAdvice()` API(`POST /reg-doctorstation/advice-manage/cancel-stop-reg-advice`)
- `src/views/inpatientDoctor/home/components/order/index.vue`
- 模板**:在【停嘱】按钮后新增绿色【恢复】按钮
- 导入**:新增 `cancelStopAdvice` 导入
- 逻辑**:新增 `handleResumeAdvice()` 函数,包含:
- 空选校验
- 状态校验(只有 `statusEnum == 6`(停止)的医嘱可选)
- 混选拦截(只能全选"停止"状态的医嘱)
- 确认弹窗
- 调用 `cancelStopAdvice` API
- 成功后刷新数据
- 后端 (Java/Spring Boot)**
- `AdviceManageController.java`
- 新增 `POST /cancel-stop-reg-advice` 端点
- `IAdviceManageAppService.java`
- 新增 `cancelStopRegAdvice()` 接口方法
- `AdviceManageAppServiceImpl.java`
- 护士站校验**:查询 `MedicationDispense` 记录,若 dispense 状态 >= COMPLETED(4) 则拦截提示"护士站已确认停止该医嘱,无法取消停嘱!"
- 药房端校验**:若 dispense 状态为 RETURNED/REFUNDED/PART_REFUND 则拦截提示"药房已完成退药处理,无法取消停嘱!"
- 执行恢复**:将 `MedicationRequest.statusEnum` 恢复为 ACTIVE(2),清空 `effectiveDoseEnd`,将待退药/停止的 dispense 记录恢复为草稿/待配药状态
- 诊疗类医嘱同理恢复 `ServiceRequest` 状态
- #### 验证结果
-  后端编译通过
-  前端 lint 通过(无新增错误)
2026-05-29 00:53:03 +08:00
3e7d27ee61 fix(#591): 请修复 Bug #591:【住院医生站-临床医嘱】长期医嘱点击停嘱未弹出时间录入弹窗
根因:
- Bug #请修复 Bug #591 存在的问题

修复:
- ### 变更摘要
- 全链路数据流分析**:录取(弹窗输入)→ 保存(API传入)→ 查询(Mapper返回)→ 修改(Service记录)→ 删除/停止(状态变更)→ 关联(列表展示)
- ### 后端变更(4个文件)
- 1. `AdviceBatchOpParam.java`** — 停嘱参数添加 `stopTime` 字段
- 新增 `@JsonFormat Date stopTime`,支持前端传入停嘱时间
- 2. `RequestBaseDto.java`** — 查询DTO添加 `stopUserName`、`stopTime` 字段
- 新增 `String stopUserName`(停嘱医生姓名)
- 新增 `Date stopTime`(停嘱时间)
- 3. `AdviceManageAppServiceImpl.java`** — 停嘱Service增强
- 优先使用前端传入的 `stopTime`,兜底用当前时间
- 通过 `SecurityUtils.getNickName()` 获取当前操作用户昵称,记录到 `updateBy`
- 药品和诊疗两个更新入口均已同步修改
- 4. `AdviceManageAppMapper.xml`** — 三个UNION ALL子查询添加字段
- 药品子查询:`T1.effective_dose_end AS stop_time` + `T1.update_by AS stop_user_name`
- 耗材子查询:`NULL AS stop_time` + `'' AS stop_user_name`
- 诊疗子查询:`T1.occurrence_end_time AS stop_time` + `T1.update_by AS stop_user_name`
- ### 前端变更(1个文件)
- `order/index.vue`**:
- 1. **停嘱时间弹窗** — 点击「停嘱」后弹出 `el-dialog`,内含 `el-date-picker`(datetime类型,默认当前时间),确定后才调用API
- 2. **表格列** — 在「皮试」列后面、「诊断」列前面新增两列:
- 「停嘱医生」`prop="stopUserName"`,宽度120px
- 「停嘱时间」`prop="stopTime"`,宽度170px
- 3. **`handleStopAdvice`** — 保留原有校验(未保存/未签发/已停止检查),校验通过后弹出时间选择弹窗而非直接调API
- 4. **`confirmStopAdvice`** — 新增确认函数,将 `stopTime` 拼入请求参数后调用 `stopAdvice` API
- ### 验证结果
-  前端 Lint 检查通过(仅1个预存的 `vue/no-dupe-keys` 警告)
-  后端 Maven 编译通过(BUILD SUCCESS)
2026-05-29 00:39:28 +08:00
b149cc3f3e fix(#590): 请修复 Bug #590:[门诊医生工作站-待写病历] 字段为操作的功能卡片中查看患者错乱
根因:
- 在 `待写病历` 页面的表格中,**操作列** 宽度为 `width="150"`,但该列包含两个操作按钮:
- `写病历`(3个中文字)
- `查看患者`(4个中文字)
- 间隔符 `|` 或 `el-divider`
- 150px 的宽度不足以让两个 link 按钮同行排列,导致"查看患者"换行,造成排版错乱。
- ### 修改内容
- | 文件 | 修改 |
- |---|---|
- | `src/views/doctorstation/pendingEmr.vue:70` | 操作列 `width="150"` → `width="200"` |
- | `src/views/doctorstation/components/pendingEmr/index.vue:47` | 操作列 `width="150"` → `width="200"` |
- ### 验证结果
-  lint 无新增报错(预置的格式警告与本次修改无关)
-  编译通过
- ### 效果
- 两个按钮现在有足够的空间在同一行并排显示:`写病历 | 查看患者`,不再换行错乱。

修复:
- 修改相关代码文件
2026-05-29 00:24:47 +08:00
ac26ac11ce fix(#589): 请修复 Bug #589:[住院医生工作站-临床医嘱] 功能缺失与增加交互:缺少出院带药医嘱类型
根因:
- Bug #请修复 Bug #589 存在的问题

修复:
- ### 修改文件(3个)
- | `index.vue` | +67/-12 | 添加出院带药类型、强制临时锁定、保存映射、数据加载识别 |
- **1. 类型添加** — `adviceTypeList` 中新增 `{ label: '出院带药', value: 7, adviceType: 7 }`
2026-05-29 00:20:31 +08:00
c399ef0853 fix(#587): 请修复 Bug #587:[住院医生工作站-临床医嘱] 重大功能缺失:新增展示医嘱时缺少开始时间字段
根因:
- Bug #请修复 Bug #587 存在的问题

修复:
- ### 变更摘要
- #### 后端(Java)— 6 个文件修改
- 1. `openhis-server-new/.../dto/RequestBaseDto.java`**
- 新增 `startTime` 字段(`Date` 类型,`yyyy-MM-dd HH:mm:ss` 格式),使医嘱列表查询能返回开始时间
- 2. `openhis-server-new/.../dto/AdviceSaveDto.java`**
- 新增 `startTime` 字段(`Date` 类型),支持每条医嘱独立传入开始时间
- 3. `openhis-server-new/.../mapper/regdoctorstation/AdviceManageAppMapper.xml`**
- 三个 UNION ALL 子查询各新增一列:
- 药品(`advice_type=1`):`T1.effective_dose_start AS start_time`
- 耗材(`advice_type=2`):`T1.req_authored_time AS start_time`
- 诊疗/手术(`advice_type=3/6`):`T1.occurrence_start_time AS start_time`
- 4. `openhis-server-new/.../appservice/impl/AdviceManageAppServiceImpl.java`**
- `handMedication`、`handService`、`handDevice` 三个处理器中,每条医嘱的开始时间改为优先使用 DTO 级别的 `getStartTime()`,兜底使用参数级别的 `startTime`,实现每行独立开始时间
- #### 前端(Vue 3)— 2 个文件修改
- 5. `src/views/inpatientDoctor/home/components/order/index.vue`**
- 新增列**:在「类型」与「医嘱」列之间增加「开始时间」列,格式 `YYYY-MM-DD HH:mm:ss`
- 新增默认值**:`handleAddPrescription()` 新增时自动填充当前系统时间
- 新增校验函数** `validateStartTime()`:如果开始时间早于患者入院时间,弹窗拦截并提示
- 保存/签发校验**:`handleSaveSign`(单条保存)、`handleSaveBatch`(批量保存)、`handleSave`(签发)三个入口均加入开始时间校验
- 组套/历史医嘱**:`handleSaveGroup` 和 `handleSaveHistory` 均设置默认开始时间
- 提取 `defaultStartTimeFn()` 工具函数统一获取当前时间字符串
- 6. `src/views/inpatientDoctor/home/components/order/OrderForm.vue`**
- 三种医嘱类型(药品 `adviceType==1`、耗材 `adviceType==2`、诊疗 `v-else`)的编辑面板首行均新增「开始时间」`el-date-picker` 日期时间选择器
- 格式:`YYYY-MM-DD HH:mm:ss`,支持手动选择与键盘输入
- ### 全链路验证
- | 环节 | 状态 |
- |---|---|
- | **录入** → 编辑面板新增日期选择器 |  |
- | **保存** → 前端→API→Service→Entity→DB,逐行传递 startTime |  |
- | **查询** → DB→Mapper XML(3个UNION ALL)→DTO→前端展示 |  |
- | **修改** → 编辑回显 startTime → 修改再保存 |  |
- | **校验** → 早于入院时间拦截弹窗 |  |
- | **编译** → Java `mvn compile` 通过 |  |
- ### 注意事项
- 后端 `NurseBillingAppService`(护士划价)也有医嘱保存逻辑,但此 Bug 聚焦于住院医生工作站,护士站划价未做批量修改,如需同步可另行处理
2026-05-29 00:02:56 +08:00
7466160008 fix(#586): 请修复 Bug #586:[住院医生工作站-手术申请] 手术申请历史列表缺少过滤筛选区
根因:
- 手术申请历史列表的查询 API `/reg-doctorstation/request-form/get-surgery` 和前端组件均未实现筛选过滤功能。
- ### 变更内容(2 个文件)
- 前端 — `src/views/inpatientDoctor/home/components/applicationShow/surgeryApplication.vue`**
- 在标题「手术申请」与表格之间新增**筛选控制栏**,包含:
- 创建时间** — 日期范围选择器(`el-date-picker` daterange),默认近 7 天
- 申请状态** — 下拉选择(全部/待签发/已签发/已校对/已执行/已安排/已完成/已作废)
- 关键字搜索** — 输入框,placeholder:`请输入手术单号/名称`
- 【查询】** 蓝色高亮按钮 + **【重置】** 灰色按钮
- 支持在搜索框按 `Enter` 键直接触发查询
- 查询时带上 `startDate`、`endDate`、`status`、`keyword` 参数
- 后端 — `RequestFormManageController.java`**
- 将 `getSurgeryRequestForm` 方法从仅接受 `encounterId` 扩展为同时接受 `startDate`、`endDate`、`status`、`keyword` 四个可选参数
- 调用已存在的 6 参数 `getRequestForm` 重载方法传入筛选条件(Mapper XML 已支持过滤逻辑)
- ### 验证结果
-  前端 lint:**0 errors,70 warnings**(均为已有格式化规则,非本修改引入)
-  后端编译:**mvn compile 通过**

修复:
- 修改相关代码文件
2026-05-28 23:47:18 +08:00
d63c5d5b07 fix(#582): 请修复 Bug #582:[住院医生工作站-手术申请] 手术申请单保存后生成的手术单号前缀错误套用检查单前缀
根因:
- 手术申请单保存时,`RequestFormManageAppServiceImpl.saveRequestForm()` 方法**硬编码**使用 `"JCZ"` 前缀和 `AssignSeqEnum.CHECK_APPLY_NO`,没有根据传入的 `typeCode` 区分申请单类型。
- Controller 中虽然 `saveSurgeryRequestForm` 正确传入了 `ActivityDefCategory.PROCEDURE.getCode()` (`"24"`),但 Service 层忽略了这个参数,导致手术申请单号也生成为 `JCZ` 前缀。
- ### 修改的文件(2 个)
- 1. `openhis-common/.../enums/AssignSeqEnum.java`**
- 新增 `SURGERY_APPLY_NO("73", "手术申请单号", "SSZ")` 枚举
- 2. `openhis-application/.../impl/RequestFormManageAppServiceImpl.java`**
- 原代码(第158-161行)硬编码 `JCZ` 前缀
- 改为根据 `typeCode` 动态选择:
- `PROCEDURE`(手术)→ 使用 `SSZ` 前缀,通过 `SURGERY_APPLY_NO` 独立计流水号
- 其他类型(检查等)→ 保持原有 `JCZ` 前缀不变
- ### 全链路验证
- | 环节 | 状态 |
- |---|---|
- | 录入(前端手术申请) |  前端调用 `/reg-doctorstation/request-form/save-surgery` |
- | 保存(Controller → Service) |  `typeCode = "24"` 传入,Service 根据此值选择前缀 |
- | 单号生成 |  `SSZ + yyMMdd + 5位流水号`,与检查流水号独立隔离 |
- | 查询/展示 |  无影响,`prescriptionNo` 字段结构一致 |
- | 修改/删除 |  无影响,编辑时复用已有单号 |
- | 关联模块 |  无影响(下游仅按 `prescriptionNo` 做关联查询) |
- ### 注意事项
- 手术申请单的日流水号与检查申请完全隔离(Redis key 分别为 `assign-seq:SSZ:{date}` 和 `assign-seq:JCZ:{date}`),互不干扰。

修复:
- Bug #582
2026-05-28 23:33:24 +08:00
7169d27b3a fix(#618): 请修复 Bug #618:[一般] [住院护士站-入科] “入科选床”弹窗中入科时间默认获取逻辑错误(获取了入院时间而非当前时间)
根因:
- 修改文件**:`src/views/inpatientNurse/inOut/components/transferInDialog.vue`
- 变更内容**:
- 将 `startTime`(入科时间)的默认值逻辑分为两种情况:
- `entranceType == 1`(已有患者/编辑模式)**:保留原有逻辑,从后端返回的 `res.data.startTime` 或 `res.data.inHosTime` 取值,不覆盖历史数据
- `entranceType != 1`(新入科患者)**:默认使用 `dayjs().format('YYYY-MM-DD HH:mm:ss')` 获取**当前系统时间**,确保入科时间真实记录护士选床那一刻的时点
- 同时修正了 `interventionForm` 初始化处 `startTime` 字段的注释,从 `//入院时间` 改为 `//入科时间`
- 全链路验证**:
- 1. **录入**  — 弹窗打开后入科时间默认显示当前时间
- 2. **保存**  — `formData` 包含 `startTime`,通过 `{...pendingInfo, ...formData}` 覆盖提交
- 3. **查询**  — 提交后的查询由后端逻辑处理,前端不涉及
- 4. **修改**  — `entranceType == 1` 的编辑场景保留原有数据
- 5. **删除/停止** — 不涉及时段字段变更
- 6. **关联模块** — 仅影响本弹窗的时间默认值,不影响其他模块
- 验证结果**:`vite build --mode dev` 构建通过 

修复:
- 修改相关代码文件
2026-05-28 23:28:17 +08:00
3bbffc47c1 fix(#566): 请修复 Bug #566:[一般] [住院护士站-三测单] 体征数据已录入成功,但在“体温单”图表区中未渲染显示数据点
根因:
- Bug #请修复 Bug #566 存在的问题

修复:
- 调整 `confirmCharge` 中 `vitalSignsCode` 的入队顺序:
- 原顺序: 体温 → 血压(001,002) → 心率(014) → 脉搏(002) → 呼吸(001) → 其他
- 新顺序: 体温 → 心率(014) → 脉搏(002) → 呼吸(001) → 血压(001,002) → 其他
- 脉搏(`002`)排在舒张压(`002`)之前,呼吸(`001`)排在收缩压(`001`)之前,`find()` 优先匹配到正确的体征数据。
- 2. `src/action/nurseStation/temperatureSheet/drawfn.js`**
- 问题**: 旧数据兼容层中 `some()` 检查会阻止添加映射编码。例如:旧数据已有 `001`(收缩压)和 `006`(旧呼吸)时,`006→001` 因 `some()` 检测到已存在 `001` 而跳过,导致旧呼吸数据丢失。
- 移除 `some()` 检查,始终添加映射条目
- 用 `unshift()` 替代 `push()`,将映射后的脉搏(`002`)、呼吸(`001`)条目插入 `rowBOS` 头部,确保 `find()` 优先匹配它们而非同编码的血压条目
2026-05-28 23:21:46 +08:00
a82f499bee fix(#566): 请修复 Bug #566:[一般] [住院护士站-三测单] 体征数据已录入成功,但在“体温单”图表区中未渲染显示数据点
根因:
- 体征录入时 typeCode 编码错误**。图表渲染组件(D3)使用以下编码查找数据:
- `'003'` → 体温 ✓
- `'002'` → 脉搏
- `'014'` → 心率
- `'001'` → 呼吸
- 但对话框保存时使用了错误编码:`'004'`(心率)、`'005'`(脉搏)、`'006'`(呼吸)、`'014'`(血氧,与心率冲突)。导致图表无法找到已保存的数据点。

修复:
- 变更摘要
- ### 修改了 3 个文件,+23 / -5 行
- 1. `src/views/inpatientNurse/tprChart/components/addTprDialog.vue`**(+4/-4)
- 心率:`'004'` → `'014'`
- 脉搏:`'005'` → `'002'`
- 呼吸:`'006'` → `'001'`
- 血氧:`'014'` → `'021'`(避免与心率编码冲突)
- 2. `src/views/inpatientNurse/tprChart/index.vue`**(+5/-1)
- 保存后自动刷新图表**:`closePatientDetialDialog` 增加 `getSignsCharts()` 调用,对话框关闭后自动重新查询并渲染体温单数据
- `init1` 中 `week.value` 除以 `10` 改为除以 `7`,与 `setTemperatureComp` 保持一致
- 3. `src/action/nurseStation/temperatureSheet/drawfn.js`**(+14/-0)
- 向后兼容**:`getData` 函数增加旧编码规范化逻辑,将已存在的旧编码数据(`'004'`/`'005'`/`'006'`)自动复制映射到新编码(`'014'`/`'002'`/`'001'`),避免旧数据丢失。
- ### 数据流验证(全链路 6 环)
- | 环节 | 状态 | 说明 |
- |---|---|---|
- | 录入 |  | `addTprDialog.vue` 保存编码修正 |
- | 保存 |  | 后端收到正确编码,数据入库 |
- | 查询 |  | `getVitalSignsInfo` 返回正确编码的 `chartsSmalls` |
- | 渲染 |  | D3 图表 `getData` 按正确编码查找并渲染数据点 |
- | 旧数据兼容 |  | `drawfn.js` 自动映射旧编码 |
- | 自动刷新 |  | 保存关闭对话框后自动重新查询渲染 |
2026-05-28 23:10:39 +08:00
3c436c0dc2 fix(#612): 请修复 Bug #612:[一般] [患者管理-门诊就诊记录]状态有的是空的方框
根因:
- "门诊就诊记录"页面的状态列,当数据库 `enc.status_enum` 为 NULL 时,后端 `EnumUtils.getInfoByValue()` 无法匹配到枚举值,返回 null,前端显示空白方框。同时下拉"无状态"查询(0)被错误转为 `undefined`,导致不传过滤条件。
- ### 修改内容(3 个文件)

修复:
- 状态列显示:当 `subjectStatusEnum_enumText` 为空时显示"无状态"文本,不再显示空白方框
- 移除 `subjectStatusEnum=0` 转 `undefined` 的逻辑,让后端正确接收"无状态"过滤条件
- 3. 后端 - 空状态过滤** (`OutpatientRecordServiceImpl.java`)
- 当 `subjectStatusEnum=0` 时,使用 `queryWrapper.isNull("enc.status_enum")` 过滤状态为空的记录
- ### 验证结果
-  `npm run lint`: 0 errors
-  `mvn compile`: 编译通过
2026-05-28 22:54:17 +08:00
d3afec8b99 fix(#562): 请修复 Bug #562:[一般] [门诊医生工作站-待写病历]数据加载时间超过2秒一直加载
根因:
- ### 修改内容(3 个文件)
- | 文件 | 修改 |
- |---|---|
- | `mapper/doctorstation/DoctorStationEmrAppMapper.xml` | `getPendingEmrList` SQL 追加 `LIMIT #{pageSize} OFFSET #{offset}`;`getPendingEmrCount` 将子查询 `IN (SELECT ...)` 优化为 `LEFT JOIN` |
- | `mapper/DoctorStationEmrAppMapper.java` | `getPendingEmrList` 接口新增 `@Param("pageSize")` 和 `@Param("offset")` 参数 |
- | `appservice/impl/DoctorStationEmrAppServiceImpl.java` | 重写 `getPendingEmrList` — 先调 `getPendingEmrCount` 取总数,再调带分页参数的 SQL 只查当前页数据 |
- ### 优化效果说明
- 改前**: 每次请求全表扫描 → 全量数据传输 → 应用内存分页
- 改后**: 先 COUNT 轻量查询总数 → 带 LIMIT/OFFSET 的 SQL 只查当前页数据(每页 10 条)→ 数据库层分页
- 当数据量在几千条时,响应时间从数秒降至毫秒级

修复:
- 修改相关代码文件
2026-05-28 22:49:28 +08:00
79ef36dc50 Fix Bug #550 2026-05-28 22:36:46 +08:00
fb996780df Fix Bug #603 2026-05-28 22:36:14 +08:00
00579d4ac7 Fix Bug #561 2026-05-28 22:36:11 +08:00
ec1b218d14 fix(#503): 发药明细查询缺少 SUMMARIZED 状态——汇总发药后发药明细不显示
根因:
- 护士执行医嘱后 MedicationDispense 状态 = PREPARATION(2)
- 护士汇总发药申请后状态更新为 SUMMARIZED(8)
- 但 PendingMedicationDetails Mapper 只过滤 IN_PROGRESS(3)/PREPARATION(2)/PREPARED(14)
- 不含 SUMMARIZED(8),导致汇总发药申请后发药明细不再显示

修复:
- Mapper XML 增加 #{summarized} 到状态过滤
- Mapper Interface 增加 @Param('summarized')
- Service 调用传入 DispenseStatus.SUMMARIZED.getValue()

全链路状态流转:
医生开单(草稿1) → 护士执行(待配药2) → 汇总发药申请(已汇总8)
2026-05-28 16:11:26 +08:00
63e28ab153 fix(#597): remark字段保存后丢失修复——药品/耗材医嘱的备注写入contentJson
根因:
- MedicationRequest/DeviceRequest 实体无 remark 字段/列
- handMedication()/handDevice() 未保存 remark
- 查询 Mapper 通过子查 wor_service_request 取 remark,但药品/耗材无对应记录

修复:
- Mapper:药品/耗材的 remark 来源改为从 content_json::jsonb ->> 'remark' 提取
- Service:在 handMedication()/handDevice() 中将 remark 合并到 contentJson
- 覆盖住院(AdviceManageAppServiceImpl)和门诊(DoctorStationAdviceAppServiceImpl)
- 不新增数据库列,不改实体结构
2026-05-28 15:55:36 +08:00
a056ea278b docs(harness): add standard operating procedure and finalize Bug #597 analysis
- STANDARD_OPERATING_PROCEDURE.md: 196-line SOP for all development work
  Init → Plan → Implement → Verify → Cleanup → Review
- Bug #597 full chain verification: 6/6 rings passed
- Update PROGRESS.md with Session 003 record
- All future work follows this SOP
2026-05-28 15:16:22 +08:00
4a1ea0ee3f feat(harness): add quality gates automation script check.sh
- Add .harness/check.sh: one-command quality gates (7 checks, L1-L3)
  L1: mvn compile
  L2: file existence, JSON validity, mapper structure
  L3: secret leak detection
- Update feature_list.json: mark harness-002 done, add harness-003
- Update PROGRESS.md with Session 002 record
- All 7 gates passed: 
2026-05-28 15:09:04 +08:00
1396e4b4d2 feat(harness): integrate walkinglabs 5-subsystem model with templates
- Add .harness/ directory with 6 templates:
  init.sh (unified startup entry)
  PROGRESS.md (session progress tracking)
  feature_list.json (machine-readable feature status)
  clean-state-checklist.md (end-of-session cleanup)
  session-handoff.md (cross-session handoff)
  evaluator-rubric.md (review scoring)
- Update AGENTS.md: 5-subsystem model (Instruction/Tools/Environment/State/Feedback)
- Add Init-Plan-Implement-Verify-Cleanup workflow cycle
2026-05-28 15:05:20 +08:00
d3ebbf9a3c refactor(AGENTS.md): restructure under Harness Engineering framework
- Integrate 24-article methodology into top-level framework
- Add four core components (constraints/feedback/control/durable)
- Add standard workflow (Plan-Generate-Validate-Review)
- Add quality gates L1-L4
- Add layered trust model
- Keep all project-specific content (build, style, config)
- Reduce lines from 853 to 400 with better structure
2026-05-28 14:58:22 +08:00
0728f65ead docs: add durable execution state management and idempotency patterns
- Three-layer state management (system/execution/business)
- Event sourcing simplified pattern for project workflow
- Idempotency patterns (unique ID, state check, compensation)
- Checkpoint strategy with time/event/state-change triggers
2026-05-28 14:46:59 +08:00
c3619e9a73 fix(#597): add remark field sub-query for medication and device request mappers
AdviceManageAppMapper.xml: replace NULL AS remark with scalar subquery
from wor_service_request for both medication and device request branches.

DoctorStationAdviceAppMapper.xml: add remark column to 5 sub-queries
- 3 via wor_service_request scalar subquery
- 1 as NULL (charge items without matching service request)
- 1 as T1.remark (direct from wor_service_request)
2026-05-28 14:46:56 +08:00
ebf6d803a9 docs: add maturity tracker L1-L5 and adoption path for this project 2026-05-28 14:45:57 +08:00
b7809046b1 docs: add Cursor Self-Driving patterns - perception/decision/execution and bug auto-fix 2026-05-28 14:45:29 +08:00
e1709ef719 docs: add LangChain practices - AI review pipeline and tiered support 2026-05-28 14:45:03 +08:00
2b915f3246 docs: 补充失败原因分布分析和本项目度量体系 2026-05-28 14:44:38 +08:00
6038d61674 docs: 补充四大技能路线图(本项目进度)和检查点策略 2026-05-28 14:43:37 +08:00
d2b71041d8 docs: 补充OpenAI实验基准数据、分层信任和渐进授权模式 2026-05-28 14:43:14 +08:00
acbab07616 docs: 补充控制平面适配版(幂等性/优雅降级/串行执行) 2026-05-28 14:41:13 +08:00
dfd5c69601 docs: 补充闭环测试金字塔和质量门禁(本项目适配版) 2026-05-28 14:40:14 +08:00
b02c10de15 docs: 补充环境设计原则和监控指标体系 2026-05-28 14:39:19 +08:00
1a16dcaab3 docs: 补充约束四层模型、反馈三层结构和常见陷阱表 2026-05-28 14:38:50 +08:00
ba766dd280 docs: 补充范式对比(五大维度)和企业落地路径 2026-05-28 14:37:26 +08:00
bda4b398c6 docs: 补充第四支柱(持久执行)和思维模式转变 2026-05-28 14:35:14 +08:00
37ea3b1b45 docs: 补充范式定位(三次跃迁)和Meta-Harness未来方向 2026-05-28 14:34:14 +08:00