一次单据复制请求被数据库自定义错误拒绝。提示指向库存质量不允许使用，但现场库存有足够实物数量，质量属性也处于允许状态。

数据库仍然掌握了拒绝写入的有效依据。可用量由实物数量减去已分配数量得到，而两层冗余计数都显示全部数量已经分配。权威预留记录中却找不到对应业务明细。触发器因此计算出可用量为零，并执行了既有业务约束。

本次处理保留了这条约束，在并发保护下修复幽灵占用，同时调整应用边界：多行复制失败时先完成事务回滚，再把数据库错误转换为用户可读的业务提示。

把数据库拒绝当作证据

排查先定位中止事务的具体语句和业务约束。复制流程已经准备好新表头，写入明细时触发数据库检查。检查会计算满足质量条件且尚未 …

一次 Windows 全量测试出现了两组错误，而且都发生在产品断言之前。第一组需要解析子进程返回的 JSON，却拿不到可用的 stdout；第二组刚创建临时 Git 仓库，工作区立即显示已有修改。

应用逻辑没有回归。测试夹具让工作站默认值参与了证据解码和仓库初始化。修复这两个边界后，34 个准备阶段错误消失，原本要验证的业务断言才能正常执行。

两组症状都指向产品代码之外

第一组共有 10 个子进程错误。子命令输出 UTF-8 文本，其中包含非 ASCII 字符。帮助函数使用 text=True 和 capture_output=True，却没有指定编码。受影响的 Windows 主机在捕获路径 …

新增业务记录时，数据库在主键处返回了 ORA-00001。这看起来不合常理，因为应用的主键来自 Oracle 序列。日志却给出了明确解释：本次生成的数值已经属于迁移进来的历史记录。

故障来自迁移后两个必须同步的对象发生漂移：表中的数据已经前进，负责生成后续主键的序列却仍描述旧历史。另一个独立写入流程也出现了相同故障，同时说明只修复第一个失败表并不安全。

从违反的约束开始

Oracle 把 ORA-00001 定义为 INSERT、UPDATE 或 MERGE 试图写入受唯一约束、唯一索引或主键保护的重复值（Oracle ORA-00001）。第一步应确定：

• 违反的是哪个约束或索引；
• 对应哪张 …

浏览器请求返回了 HTTP 200，响应体却是空的，页面也没有数据。状态码看起来成功，后端日志却给出了另一条链路：映射 SQL 在调用 WM_CONCAT 时触发了 ORA-00904。

这次修复不能只做全局文本替换。字符串聚合包含排序、重复值、分隔符、别名和溢出语义。安全迁移到 Oracle 19c，需要逐项保留这些契约，证明运行时产物已经同步变化，并把“源码与数据库验证完成”和“部署后页面已恢复”严格分开。

从第一个失败边界开始

有效的执行链是：

HTTP 200 空响应
  -> 异常被捕获
  -> 映射 SQL 失败
  -> ORA-00904: …

IDE 已经完成编译和产物准备，应用服务器却没有进入部署。真正中断启动的是调试器监听器绑定失败：配置的地址无法绑定，日志提示该地址已被使用。

常见判断是“另一个进程占用了端口”。本次现场却出现了一个容易误导排查的现象：稍后检查时，没有普通进程在监听；Windows 返回的排除 TCP 端口区间却包含这个配置值。只修改调试端口后，完整启动链路恢复。

这说明 Windows 上的固定开发监听器不能只做进程占用检查，还要避开机器当前的动态分配范围和显式排除区间。

先把故障放回启动时序

IDE 启动应用服务器时，会依次跨过多个边界：

编译源码
  -> 构建产物
  -> 绑定调试套接字 …

Typora 的导出菜单里已经出现 DOCX 与 EPUB，但选择后无法启动转换器。编辑器本身工作正常，原生输出路径也没有异常。缺失的环节是这些扩展格式依赖的外部程序。

Typora 官方文档说明，HTML、PDF 和图片可以直接输出，Word、RTF、EPUB 等格式则会调用 Pandoc。文档还建议安装后重启应用；若仍无法发现 Pandoc，应在导出设置中手动选择其可执行文件（Typora 导出文档）。

本次处理严格限制范围：先确认转换器状态，只安装一份 Pandoc，显式绑定可执行文件，再检查真实 DOCX 与 EPUB 包。流程没有增加 PDF 引擎，也没有改写其他 Typora 高级 …