ERP/requirements/_xlsx_audit_round2.json

{
 "counts": {
  "met": 47,
  "partial": 158,
  "missing": 26,
  "logicGap": 54
 },
 "chains": [
  {
   "chain": "工程业务流程：查网→制作标书→开标→领取中标通知书→签订总包合同→施工前准备→施工图审查→材料等分包合同→办理施工许可证→季度考评→竣工备案→资料存档",
   "verdict": "LOGIC_GAP"
  },
  {
   "chain": "合同流程：供应商入库→系统取模板合同(IT维护)→线上填写→自动化比对→合约部在线审核→进入OA审批→通知合同专员下载/上传盖章→电子签自动进入盖章系统",
   "verdict": "LOGIC_GAP"
  },
  {
   "chain": "资金确认：项目部向甲方请款 → 财务资金到账确认 → 开票 → 应付(应收)入账",
   "verdict": "PARTIAL"
  },
  {
   "chain": "支付流程：供应商 → 人材机审核确认 → 支付申请审批 → 打款 → 写入财务系统",
   "verdict": "MET"
  },
  {
   "chain": "资料流程：项目部(发起)→办事处→资料室→工程中心→法务→董事长→档案室。在本系统中由「表单模板多节点串行流转(FormTemplate.flowSchemaJson)+ WorkflowService.advance 逐节点推进 + TriggerRuleEngine 办结后下游联动 + 资料室在线归档状态机(ArchiveSubmission)」共同承载；前端 archive 档案知识中心模块承载资料室/档案库。",
   "verdict": "PARTIAL"
  },
  {
   "chain": "流程驱动/自动触发：表单办结(条件生成) → WorkflowService.finalize → triggerDownstream → TriggerRuleEngine.fire(规则矩阵) → 创建/回写真实下游实体(付款/发票/合同/项目/用印/供应商/档案) + AutomationLog 留痕 + 可配置规则补充触发；前端 /datacenter/automation 留痕页 + /appdev/ruleconfig 规则配置页承载。",
   "verdict": "PARTIAL"
  },
  {
   "chain": "跨模块数据自动采集（申报条件自查自动取数 + 研发费用归集证据链自动化）",
   "verdict": "PARTIAL"
  },
  {
   "chain": "BOM差异自动核算: 工单领料(MaterialIssue,实际成本原始凭据) → 按物料名/项目聚合回填 BOM 项 actualQty(BomAnalysis.backfill) → 量价差异核算 cost-compare(投标量价 vs 实际量价 → 超支/超量,自动算) → 标准成本台账 StandardCost(料+工+费=标准, 实际−标准=差异,服务端自动算) → 成本中心上卷 rollup/rollup-tree → 前端承载: 量价比对(costcompare.vue)/工程量比对(bom.vue)/标准成本(standardcost.vue)/领料回填面板(mfg/issues.vue)",
   "verdict": "PARTIAL"
  },
  {
   "chain": "三系统数据打通（OA / 财务T+ / ERP 数据共享 + 支付中心写入财务 + 做账数据共享）",
   "verdict": "PARTIAL"
  }
 ],
 "critic": {
  "suspiciousMet": [
   "市场部/办事处 (MET7 PART1) — OrgBranchController/BranchAsset/BranchBudgetLine 都存在且 BranchPnl 有 305 行真聚合逻辑，但活体 /api/oa/org-branches、/branch-assets、/branch-budget-lines 全部返回 data:[]（0 条），/branch-pnl/board totalBranches=0 全空。代码壳齐但无种子数据，MET7 是按控制器存在判的、实跑是空板，需把'有数据闭环'纳入复判。",
   "市场部/分公司 (MET8 PART1 MISS0) — 与办事处同一套 org-branch 数据底座，同样 0 条种子记录；8 项 MET 中至少分公司台账/资产/预算口径在活体为空，疑似按需求行与控制器名匹配给分而非验证运行结果，需重查。",
   "创新研发中心/知识产权部 (MET4) — IpAsset 控制器有 16 端点却活体 /api/oa/ip-assets 返回 0 条；只有 /patents 有 15 条真数据。MET4 里挂在 IpAsset/IpInsight 上的认定（资产盘点/预警洞察）实跑为空，可疑，应区分 Patent(真) 与 IpAsset(空壳)。",
   "运营管理中心/工业废水运营中心 (MET4 MISS0) — /wastewater-clients 有 8 条，但 /water-quality-records 与 /discharge-contracts 均 0 条。水质记录/排放合同相关的 MET 认定缺数据支撑，MET4 偏高，需逐项核对哪几项真有闭环。",
   "内控部/审计监察部 (MET3 MISS2) — /audit-projects 有 9 条但 /audit-findings 返回 0 条。若 MET 含'问题整改/发现台账'一项则为空壳认定，需确认 MET3 具体落在哪三行、是否含 findings。"
  ],
  "underCovered": [
   "财务部/支付中心 (判 MET0 PART11 MISS1) — 严重漏审/假阴性。后端实有 Invoice/TaxFiling/ExpenseClaim(9ep)/FixedAsset/Voucher(9ep)/ArAp/Account/CompanySubject 全套控制器，活体 /vouchers 47 条、/payments 85 条、/invoices 16 条均有真数据。11 项全判 PART、0 MET 与实现面严重不符，几乎确定是未把控制器映射到需求行，必须整域重审。",
   "支付中心/结算中心 (判 MET0 PART6) — SettlementController 8 端点、活体 /settlements 返回真数据(JS-1 付款 50万 等)，BankReconciliation/FundPlan/Voucher 齐备。MET0 与'结算复核·资金保障'实有实现矛盾，疑漏审。",
   "支付中心/金融办·贷款融资 (判 MET0 PART3 MISS2) — FinancingController 10 端点、活体 /financings 有真数据(RZ-1 工行长沙分行 银行贷款)，另有 PolicyApplication/Policy/FundPlan。MISS2+MET0 明显低估，融资域已从 0 建起，需重审。",
   "创新研发中心/实验室 (判 MET0 PART4 LOGIC5) — LabSample/TestTask(8ep)/TestReport(7ep)/Reagent(8ep)/TestMethod/LabInstrument 全套，活体 /lab-samples 有真数据(YP-2026-001 靖州污水厂进水水样)。0 MET 与全流程实现不符，疑整域漏审。",
   "创新研发中心/产品开发部 (判 MET0 PART8 LOGIC3) — DevProject 多达 15 端点，另有 ProductRequirement(8ep)/PrototypeOrder(9ep)/DevProjectBudget/TechAchievement。控制器密度极高却 0 MET，疑似覆盖映射缺失。",
   "工程管理中心/工程监理部 (判 MET0 PART3 MISS3) — 实有 SupervisionProject/SupervisionInspection/SupervisionLog 三个控制器各 5-6 端点，活体 /supervision-projects 1 条、/supervision-logs 10 条有数据。MISS3 与已建监理域不符，疑高估缺口。",
   "内控部/法务合规中心(legal/contract/audit) (判 MET0 PART8) — LegalConsult(7ep)/LitigationCase(8ep)/ComplianceObligation/InternalControlMatrix/ClauseCompare 全建（活体接口通但暂空数据）。控制器面已覆盖法务+合同+内控矩阵，0 MET 偏低，至少应有几项 MET，需重审并补种子后复判。",
   "工程管理中心/质安部 (判 MET0 PART5 MISS3) — SafetyCheck/Rectification(8ep)/QmsRecord/QcInspection(8ep)/RiskAssessment 五控制器齐全。MISS3+0MET 与安全检查-整改-风评闭环实现不符，疑漏审。",
   "行政/综合部·资质管理办 (判 MET4 PART9 MISS4) — StaffDossier(11ep)/StaffCredential(11ep)/QualCert(10ep)/MarketQualification(9ep)/PersonnelCert 控制器极厚。MISS4 为全表最高缺口数，但实现密度反而最高，缺口判断与代码面强烈背离，需整域重审。"
  ],
  "note": "根因：本轮覆盖统计存在系统性口径错位——MET/MISS 判定主要按'需求行↔控制器名'的人工映射，未与活体运行结果对齐，导致两类错误并存。(1) 假阳性 MET：办事处/分公司(MET7/8)、知识产权 IpAsset、工业废水水质/排放合同、审计 findings——代码壳与聚合逻辑齐全(如 BranchPnl 305 行真算)，但活体接口返回空数组(org-branches/branch-assets/branch-pnl/ip-assets/water-quality-records/discharge-contracts/audit-findings 均 0 条)，是'有引擎无数据'的空板。(2) 假阴性 MISS/PART：财务部(MET0 却 vouchers47/payments85/invoices16 条真数据+全套控制器)、结算中心、金融办、实验室、产品开发部、质安部、工程监理、资质管理办——控制器密度与种子数据都很厚，却被判 0 MET 或高 MISS。建议复判规则：每条 MET 必须同时满足'控制器端点存在 + 活体返回非空 + 有写入/审批/聚合闭环'三条，并对上述假阴性域重新做需求行到控制器的映射。活体 :8091 admin/123456 可逐项复跑验证。所有路径基于 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/*Controller.java。"
 },
 "survivedGaps": [
  {
   "area": "创新研发中心/产品开发部",
   "module": "1. 产品规划与立项管理",
   "verdict": "PARTIAL",
   "gap": "缺产品路标专属实体+版本管理；WBS 排期为机械均摊、无任务依赖关系；立项 approve 与 DesignReview 投票节点未硬绑定(投票闭环存在但非立项必经)。",
   "severity": "med",
   "evidence": "维持 PARTIAL，但部分子论点应纠正。(a) 产品路标/线路图：grep roadmap|路标|线路图|路线图|产品规划|1-3年 在 oa-backend 零命中，确无专属实体与版本管理，DevProject 仅 techRoute 文本字段(DevProject.java:66)。(b) WBS：DevProjectController.generateWbsIfAbsent(:303-336) 确为按阶段数机械均摊排期(segStart=days*i/len)，DevWbsTask 无任务依赖字段，devproject.vue 渲染的是任务列表非真甘特/依赖图。(c) 技术委员会投票闭环子论点应部分翻案——DesignReviewController 确有完整投票闭环：open(:124)→vote 每人一票去重(:142-166)→conclude 自动判定(任一否决→未通过/任一有条件→有条件通过/否则通过, :175-215)并回写立项 reviewOpinion。但 DevProjectController.approve(:163-175) 立项本身仅记 reviewOpinion 文本、不强制走 DesignReview，两者解耦。综合仍为 PARTIAL。",
   "survives": true,
   "reNote": "对抗复验失败——尽力在代码中寻找反证后，三条子缺口全部属实，无法推翻。该领域[创新研发中心/产品开发部 · 产品规划与立项管理]的实现核心是 DevProjectController + DevProject/DevWbsTask/DesignReview/ReviewVote。逐条核验：\n\n(1) 缺产品路标专属实体+版本管理——属实。全后端 domain 无 roadmap/路标/产品路线/产品版本 实体；DevProject 仅有一个 productLine 字符串字段（产品线/目标市场），无路标对象、无版本表。前端唯一的\"版本管理\"命中是 rd/policy.vue 的\"制度版本管理\"（制度文档版本，与产品路标无关）。\n\n(2) WBS 排期机械均摊、无任务依赖——属实。DevProjectController.generateWbsIfAbsent() 按固定 6 阶段模板(WBS_STAGES)用 days*i/length 纯均摊切日期(第326-330行)；DevWbsTask 实体只有 seq 排序字段，无 predecessor/dependsOn 任何依赖字段，Repository 也只有按 seq 排序的查询。对比之下，同库的 DesignTask(设计研究中心)有 dependsOnId 且控制器强制\"前置未完成不能完工\"，CslTask 有 dependsOn——即\"任务依赖\"能力在代码库其它模块已存在，但产品开发部 WBS 偏偏没建，反证了缺口而非推翻。\n\n(3) 立项 approve 与 DesignReview 投票节点未硬绑定——属实。DevProjectController.approve()(第163-175行)仅校验 stage==\"评审中\" 即翻到\"已立项\"，全方法零引用 DesignReview/ReviewVote/conclusion；唯一与 review 相关的只是把请求体 opinion 写进 reviewOpinion 字段。投票闭环确实存在(DesignReviewController.vote/conclude 按\"任一否决→不通过\"自动判定)，但 conclude 只回写 p.reviewOpinion 备注，从不改 DevProject.stage、也不被 approve 检查——两条流程完全解耦，投票非立项必经。前端 devproject.vue 亦无依赖/路标/版本 UI，也未在客户端做投票门禁。判定 PARTIAL 成立。",
   "reEvidence": "后端控制器 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DevProjectController.java: approve() 第163-175行(仅 stage 校验，无 review 绑定)；generateWbsIfAbsent() 第316-335行(均摊排期 days*i/WBS_STAGES.length，无依赖)。\n实体 /Users/qiu/.../domain/DevWbsTask.java: 全文仅 seq 字段，无 dependsOn/predecessor。\n实体 /Users/qiu/.../domain/DevProject.java: 仅 productLine 字符串，无路标/版本字段。\n投票闭环 /Users/qiu/.../web/DesignReviewController.java: conclude() 第175-215行只回写 p.setReviewOpinion()，不改 stage、不被 approve 引用。\n反证(能力存在于他处但本模块未用): /Users/qiu/.../domain/DesignTask.java 有 dependsOnId；/Users/qiu/.../web/DesignTaskController.java 第30行\"前置未完成不能完工\"强制依赖校验；/Users/qiu/.../domain/CslTask.java 有 dependsOn。\n全库 grep roadmap/路标/产品路线 零命中；前端\"版本管理\"仅 oaModules.ts 第378行+rd/policy.vue 的\"制度版本管理\"(制度文档，非产品)。devproject.vue grep roadmap/版本/依赖/前置/甘特 零命中。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "2. 研发过程管理",
   "verdict": "PARTIAL",
   "gap": "问题/缺陷管理实体完全缺失；研发日报/周报自动汇总缺失；WBS 超期任务预警端点缺失。",
   "severity": "high",
   "evidence": "维持。(a) 问题管理：grep 问题登记|缺陷跟踪|issueTrack|defectTrack|ProblemRecord|IssueRecord 仅命中 AuditFinding(审计发现)，与研发无关，确无设计缺陷/试制/测试问题登记实体。(b) 研发日报/周报：grep 日报|周报|dailyReport|weeklyReport 仅命中 SewageProcessRun(污水)与 MealOrder(食堂)，研发域零实现。(c) 超期预警：DevWbsTask 有 planEnd(domain:44)，但 DevProjectController/DevDashboardController 全文无 overdue/逾期/超期扫描端点，确无 WBS 逾期扫描。任务进度填报+上卷(reportProgress:268-283)与技术评审节点(DesignReview)已实现，故非全空。",
   "survives": true,
   "reNote": "缺口属实，三项子缺口全部成立。无专用缺陷实体(仅ProductRequirement需求池reqType可取缺陷)，无研发日报周报自动汇总，无WBS超期预警端点(DevWbsTask有planEnd但DevProjectController无overdue端点，对照CslProject/DesignTask/RdMaintenanceTask兄弟模块均有超期预警)。",
   "reEvidence": "ProductRequirement.java:40; DevProjectController.java:59-283; DevDashboardController.java; DevWbsTaskRepository.java; CslProjectController.java:248; DesignTaskController.java:184; RdMaintenanceTaskController.java:155"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "3. BOM与设计文档管理",
   "verdict": "LOGIC_GAP",
   "gap": "研发 BOM 前端仍假数据、未接真多级树；物料编码自动生成+查重缺失；设计文档签审流转/意见批注缺失；文档发放回收+下游通知缺失；BOM 版本状态机未建模。",
   "severity": "high",
   "evidence": "维持。(a) rd/bom.vue 确为 settingListStore('rd-bom') 假数据页(bom.vue:4-5 硬编码曝气风机/造粒模盘)。真 BomItemController 含完整多级树/tree(:102) 与 MRP/mrp(:199)，但其消费者经 grep 仅 mfg/mrp.vue、mfg/issues.vue、budget/costcenters.vue、budget/bom.vue——无任一 rd/ 页接入，研发 EBOM 未真接多级树后端，语义错位坐实。(b) 物料编码自动生成+查重：grep materialCode|一物多码|查重|matCode 仅命中 Supplier/OpportunityDedup，研发物料编码防呆零实现。(c) DesignDocController 仅 CRUD，reviewStatus 为静态字段(:69-71)，无校对→审核→批准签审流转端点、无签审记录表、无意见批注。(d) 文档发放/回收+通知采购生产质量：grep 发放|回收|旧版 在 doc/design 域零命中。(e) BOM 版本状态机(草稿→已发布→已变更→废止)：BomItem 仅 signStatus(会签)无 version 状态机字段。",
   "survives": true,
   "reNote": "gap real - RD BOM page rd/bom.vue uses settingListStore mock not real tree, no material code gen or dedup, DesignDoc plain CRUD no signoff annotation distribution, BomItem no version state machine",
   "reEvidence": "rd/bom.vue:5 kaidiDeptView.ts:7 budget/bom.vue qhse.ts BomItem.java DesignDoc.java DesignDocController.java design/docs.vue"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "4. 设计变更管理",
   "verdict": "PARTIAL",
   "gap": "变更执行不落地更新 BomItem/DesignDoc 版本、不真触发下游单据；无结构化原值→新值变更历史与 BOM 状态快照(追溯仅文本追加)。",
   "severity": "med",
   "evidence": "维持，但初判低估了影响评估能力。EngineeringChangeController 实际比初判强：rd/eco.vue 已真接 /engineering-changes 后端(eco.vue:26,46,60)；assess(:134-151) 与 impact(:125-129) 做跨表只读聚合，analyzeImpact(:221-244) 真按受影响产品名匹配 BomItem(name/projectName 含)与在制 WorkOrder(排除已入库/已完工)，输出 affectedBomCount/wipWorkOrderCount——非纯文本声明。等级配审批链(chainFor:246-254 重大6签/一般4签/微小2签)+逐节点 approve(:177-198)已实现。但变更执行仍坐实缺陷：approve 末节点仅产出 'ECO-V'+id%90+10 字符串(:191)写进 impactReport 文本尾(:192-195)，未真 update BomItem/DesignDoc 的 version，未真改采购订单/生产工单/库存(注释自承'已通知...按新版执行'纯文本)。变更追溯：impactReport 仅追加文本(:195,209)，无原值→新值结构化历史表、无任意时间点 BOM 快照。",
   "survives": true,
   "reNote": "缺口属实。[创新研发中心/产品开发部·设计变更管理] 由 EngineeringChangeController(ECO) 实现，状态机 草稿→评估中→审批中→已执行/已驳回 齐全，但\"变更执行\"完全不落地：approve() 走到末节点只把 ECO 自身 status 置「已执行」，版本号是 String ver = \"ECO-V\"+(id%90+10) 这种由 id 派生的合成字符串，且仅以文本追加进 ECO 自己的 impactReport 字段。三点全部成立：(1)不更新 BomItem/DesignDoc 版本——bomRepo/workOrderRepo 在本控制器内只有 findAll() 只读，从无 .save()；BomItem 实体根本没有 version 字段，DesignDoc 虽有 version 但只有 DesignDocController 自己能写，无任何变更执行路径回写它。(2)不真触发下游单据——\"已通知采购/生产/质量按新版执行\"只是拼进文本，未创建/更新任何 WorkOrder、未走 TriggerRuleEngine（引擎里无 design-change/ECO/变更 触发链）。(3)无结构化原值→新值历史与 BOM 状态快照——无 ChangeHistory/ChangeLine/BomSnapshot 等实体，受影响 BOM 仅以\"涉及BOM：名1、名2\"拼成 impactReport 文本，追溯纯文本追加。另一条 DesignChangeOrder.implement() 同病：只改单据自身 fromVersion/toVersion，不回写任何 DesignDoc/BomItem，javadoc 宣称的\"受影响专业自动提醒\"清单实际未返回。扁平 DesignChange 更只是纯 CRUD。活体已端到端验证。",
   "reEvidence": "web/EngineeringChangeController.java:177-198 approve() 末节点执行块：ver=\"ECO-V\"+(Math.abs(e.getId().intValue())%90+10)，仅 e.setImpactReport(...+tail) 文本追加，无 bomRepo.save/workOrderRepo.save/docRepo 调用；行225/233 bomRepo.findAll()、workOrderRepo.findAll() 全程只读。domain/BomItem.java 无 version 字段(grep version 零命中)。domain/DesignDoc.java:30 有 version 但 grep 显示仅 web/DesignDocController.java 写它。service/TriggerRuleEngine.java grep 变更/ECO/designChange/bomItem 仅命中无关 import，无变更触发链。无 ChangeHistory/ChangeLine/BomSnapshot/VersionHistory 实体(find 零命中)。web/DesignChangeOrderController.java:191-207 implement() 仅 c.setToVersion(to) 改单据自身、不回写 DesignDoc/BomItem。活体 http://127.0.0.1:8091：ECO-1 走完 4 节点审批后 status=已实施? 实为\"已执行\"，impactReport=\"...新版本号 ECO-V11，已通知采购/生产/质量按新版执行...\"(纯文本)，而 GET /api/oa/bom-items/1 在执行前后完全一致(无 version 字段、status/signStatus 未变)。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "5. 样机试制与测试验证",
   "verdict": "PARTIAL",
   "gap": "样机库存借用/认证/归还流转台账缺失(仅报废动作)；CCC/CE/UL 产品安规送检认证缺失(现有仅 ISO 三体系)；测试缺陷→问题管理链路因问题管理缺失而断。",
   "severity": "med",
   "evidence": "维持。PrototypeOrderController 有试制工单状态机(计划→领料→试制中→完工/报废)、完工登记序列号(finish:157-176 serialNo)。但 (a) 样机库存借用/归还台账：仅有 scrap(:182) 报废动作，无借用/归还流转；grep 借用|归还|borrow|loan 仅命中 Archive/Vehicle/Staff(档案/车辆/证件)，非样机。(b) 第三方安规认证：CertificationController 经类注释(:22-30)与 STATUS 常量确为 ISO9001/14001/45001 三体系认证，grep CCC|安规|送检|检测机构|ProductCert 无产品安规认证实现。(c) 测试缺陷自动进入问题管理：因问题管理模块本身缺失(见模块2)而无法对接。",
   "survives": true,
   "reNote": "缺口属实，三条子缺口逐一核实后均无法推翻。(1) 样机库存借用/认证/归还流转台账缺失：PrototypeOrder 实体与 PrototypeOrderController 只实现试制工单状态机(计划→领料→试制中→完工，异常态 报废)，动作仅 issue-material/start/finish/scrap，无借用(借出/借入)、无认证、无归还(归还状态或动作)；完工只登记 serialNo，无库存借用流转台账。系统内现有的借还台账(ArchiveBorrow 档案借阅、StaffCredential 原件借出、AdminVehicleDispatch 派车归还)均不针对样机。(2) CCC/CE/UL 产品安规送检认证缺失：认证类实体仅 Certification(明确为 ISO9001/14001/45001+安全生产标准化/施工资质 三体系/管理体系认证)、QualCert(行政资质台账=企业/人员/荣誉资质，如施工总承包/注册建造师/ISO体系)、PersonnelCert(人员证件)。全后端 domain/web/service 与前端 src 对 CCC|3C|安规|型式试验|EMC|RoHS|UL认证|CE认证|强制性认证|送检认证|产品认证 grep 全部零命中；DevProject 仅有一个\"认证费\"预算数字，并非送检认证台账。(3) 测试缺陷→问题管理链路因问题管理缺失而断：无问题/缺陷管理模块(ProblemRecord|IssueTrack|问题管理|缺陷管理 grep 零命中)。QmsRecord 是 ISO9001 体系记录(不符合项/纠正预防措施)，与样机测试无关联；QcInspection 是制造中心 IQC/IPQC/FQC，其不合格路径回退到制造 WorkOrder 返工，不连样机试制测试也不连任何缺陷库；PrototypeOrder.testResult 仅一个扁平 合格/不合格/进行中 字段，无下游缺陷→问题流转。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/PrototypeOrder.java(状态机 计划/领料/试制中/完工/报废，仅 serialNo/testResult，无借用归还字段)；web/PrototypeOrderController.java(动作仅 issue-material/start/finish/scrap，第182-193行 scrap 是唯一异常动作，无 borrow/return/cert)；domain/Certification.java(第11-16行注释明确 ISO9001/14001/45001 三体系)；domain/QualCert.java + web/QualCertController.java(行政资质台账，certType=施工总承包/设计/监理/注册建造师/ISO体系，无 CCC/CE/UL)；web/QmsRecordController.java(ISO9001 不符合项/纠正预防措施，与样机无关)；web/QcInspectionController.java(第213-223行 IPQC不合格仅退回制造 WorkOrder 返工，不连样机/缺陷库)。grep 全库 CCC|安规|型式|EMC|RoHS|UL认证|CE认证|送检认证|产品认证 与 ProblemRecord|IssueTrack|问题管理|缺陷管理 均零命中(后端 domain/web/service + 前端 ofbiz-framework/plugins/modern-ui/app/src)。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "6. 研发物料与采购协同",
   "verdict": "LOGIC_GAP",
   "gap": "研发物料前端假数据无后端；研发物料库实体缺失；研发采购在线申请+转采购流程缺失；供应商送样/合格转量产管理完全缺失。",
   "severity": "high",
   "evidence": "维持。(a) rd/material.vue 确为 settingListStore('rd-material') 纯假数据页(material.vue:4-5 硬编码 PLC控制模块/膜组件样品)，无后端实体无审批。(b) 研发物料库(样品/手板/开发板)：无独立实体(rd 域无 RdMaterial/SampleMaterial 实体)。(c) 研发采购申请在线流程：无真流程端点，PrototypeOrder 领料仅登记 materialCost 不走采购转单。(d) 供应商样品管理：grep 送样|供应商样品|supplierSample|样品送检 全库零命中。",
   "survives": true,
   "reNote": "缺口基本属实。逐条核验：\n\n1) \"研发物料库实体缺失\" —— 属实。后端不存在任何专用研发物料实体（grep `class RdMaterial/DevMaterial/SupplierSample/...` 全 NONE FOUND）。前端 rd/material.vue 用 `settingListStore('rd-material', seed)`，走通用 `/api/oa/biz/rd-material`（BizRecord 表，dataJson blob 行级存储），只有裸 CRUD，无任何研发物料领域字段/逻辑。\n\n2) \"前端假数据无后端\" —— 仅此句措辞不严谨可部分反驳：它确有后端（BizRecord 通用台账，活体 GET 返回 code:0 data:[]，能增删改查持久化），并非纯前端假数据。但只是通用 blob CRUD，非专用研发物料库，所以\"无专用后端实体\"成立。\n\n3) \"研发采购在线申请+转采购流程缺失\" —— 属实。seed 里\"已转采购\"只是 select 自由文本选项，无转采购工作流、无 TriggerRuleEngine 联动、无与请购/采购单据的衔接。AdminRequisition 是行政办公物资领用（行政后勤），与研发采购无关；MrpController/BomItem 是制造侧 MRP，均不构成\"研发采购在线申请→转采购\"。\n\n4) \"供应商送样/合格转量产管理完全缺失\" —— 属实。Supplier 控制器是纯 CRUD，status 仅 合格/准入中/停用，无送样、无样品合格判定、无转量产状态机。QcInspection 虽有 IQC 来料检验关联供应商，但属制造质检追溯，非\"供应商送样→合格→转量产\"流程。活体探测 supplier-samples / sample-submissions / production-transfer / rd-purchase-requests 均 404。\n\n结论：4 条子缺口中 3 条（实体缺失、转采购流程缺失、送样/转量产缺失）确凿成立；仅\"无后端\"一词因 BizRecord 通用持久化而不够精确，不足以推翻整体缺口。判定 real=true。",
   "reEvidence": "前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/material.vue 第4行 `settingListStore('rd-material', [{matName,spec,purpose,applicant,project,status}])`；settingListStore 定义 src/oa/api/settingList.ts（走 /biz/{key} 通用 BizRecord）。\ndept映射: src/data/kaidiDeptView.ts —「研发物料与采购协同」status:\"built\" path:\"/rd/material\"。\n后端缺实体: oa-backend grep `class RdMaterial|SupplierSample|MassProduction|PurchaseRequest|RdPurchase` = NONE FOUND；仅 domain/MaterialIssue.java（制造工单领料，表 mfg_material_issue，与研发无关）。\n通用兜底后端: domain/BizRecord.java + web/BizRecordController.java(/api/oa/biz/{type})，仅 dataJson blob CRUD。\nSupplier 纯 CRUD: web/SupplierController.java 仅 list/get/create/update/delete，status 合格/准入中/停用，无送样/量产。\nQcInspection: domain/QcInspection.java 为制造 IQC/IPQC/FQC 质检追溯，非供应商送样转量产。\n活体(127.0.0.1:8091): GET /api/oa/biz/rd-material -> {\"code\":0,\"data\":[]}; 探测 rd-materials/supplier-samples/sample-submissions/production-transfer/rd-purchase-requests 全部 HTTP 404。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "7. 研发成本与预算",
   "verdict": "PARTIAL",
   "gap": "成本归集仅单源(RdExpense)+需手工置状态，未从工时/采购/报销多模块自动取数；标准成本为手填框架未从 BOM+工艺路线真算；目标成本法仅字段无核算引擎。",
   "severity": "med",
   "evidence": "维持。DevProjectBudgetController 预算行 CRUD+成本归集已建，但 aggregate(:131-151) 确仅从 RdExpense 单一来源(findByRdProjectId + status=已归集)按科目聚合，需手工置'已归集'，PrototypeOrder 的 laborHours/materialCost 未联动归集进预算。产品标准成本：StandardCostController 类注释(:34-36)明示'实际归集来源属甲方核算口径，当前为手填+服务端汇总框架'，recompute(:71-75) 仅 totalStandard=料+工+费(手填三项相加)，未从 BomItem 真算料+工艺路线工费。设计阶段成本预估/目标成本法仅 DevProject.targetCost 字段(domain:59)无核算逻辑。",
   "survives": true,
   "reNote": "尽力反驳但三条子缺口全部坐实，缺口属实(PARTIAL)。(1) 成本归集单源+手工置状态：RdExpense 仅由 RdExpenseController.create 人工创建、status 由请求体手填(默认待审核)，无任何来自工时/采购/报销的自动建单。唯一的自动归集 DevProjectBudgetController.aggregate(POST /{devProjectId}/aggregate) 只从 RdExpense(按 rdProjectId+status=已归集) 按 category 聚合回填，仍是单源；RdExpenseTraceController 同样只聚合 RdExpense。全仓 `new RdExpense()` 仅出现在 RdExpenseController 与 DataSeeder，ExpenseClaimController/CslTimesheetController/TriggerRuleEngine 均无任何写 RdExpense 的路径。值得注意：仓库里确实存在可用的多源回填范式(BomAnalysisController.backfillApply 从 MaterialIssue 领料单回填 BOM 实际量)，证明模式存在但未对 RdExpense 接线。(2) 标准成本手填框架：StandardCostController 构造器仅注入 StandardCostRepository+CostCenterRepository,不注入 BomItemRepository/工艺路线;料/工/费直接取请求体,服务端 recompute() 只做料+工+费求和与差异=实际−标准,无 BOM 展开、无工艺路线工时费率;类注释自承'当前为手填+服务端自动汇总的框架实现'。(3) 目标成本法仅字段：targetCost 只是 DevProject 实体字段,值由请求体原样写入(p.setTargetCost(Money.of(req.targetCost()))),无可承受成本(价格−利润)倒推、无组件分解核算引擎,DevDashboardController 甚至不引用它。",
   "reEvidence": "RdExpenseController.java:64-81 (人工create,status手填默认待审核); DevProjectBudgetController.java:131-151 aggregate 仅从 expenseRepo.findByRdProjectId 且 status=已归集 单源按 category 聚合; RdExpenseTraceController.java:90-146 仅聚合 RdExpense; grep `new RdExpense()` 只命中 RdExpenseController.java:69 + DataSeeder.java:2197; ExpenseClaimController 无 RdExpense 引用, TriggerRuleEngine 无 RdExpense/StandardCost/targetCost 自动创建; 对照存在的多源回填 BomAnalysisController.java:138-208(从 MaterialIssue 领料回填); StandardCostController.java:41-48(仅注入 StandardCostRepo+CostCenterRepo,无 Bom/Routing), :71-75 recompute 仅求和+差异; StandardCost.java:22 注释'当前实现为手填+自动汇总框架'; DevProject.java:58-59,169-174 targetCost 仅字段+注释'目标成本法,设计阶段成本上限'; DevProjectController.java:98,124 targetCost 原样 setter,无核算。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "8. 研发知识库",
   "verdict": "PARTIAL",
   "gap": "研发技术文档库专属实体缺失；竞品拆解报告/性能对比库缺失(仅市场情报)；可复用模块库(电路/结构/软件组件)完全缺失。",
   "severity": "med",
   "evidence": "维持。(a) 技术文档库：无研发专属实体，借用通用 Archive/ItKnowledge，非研发知识沉淀分类(技术规范/设计指南/checklist/经验教训)。(b) 竞品分析库：grep 竞品|competitor|拆解报告 仅命中 Intel/MarketIntel(市场情报)，非产品研发竞品拆解。(c) 标准化模块库：grep 标准化模块|reusableModule|moduleLibrary|可复用模块 全库零命中。专利对接(Patent)已存在为唯一落地子项。",
   "survives": true,
   "reNote": "缺口属实。研发知识库三个子能力均未实现专属实体。我尽力寻找反证但无法推翻：(1) 研发技术文档库专属实体缺失——后端仅有 DesignDoc(工程设计文档:可研报告/初步设计/施工图,服务设计研究中心,前端落在 /rd/bom 与 /design)与 ItKnowledgeArticle(明确是信息部·IT知识库,@RequestMapping /api/oa/it-knowledge);kaidiDeptView.ts 中\"研发知识库\"这一 block 被映射到 /knowledge/doccenter(知识社区模块下的通用树形文档中心),并非研发专属技术文档库实体。(2) 竞品拆解报告/性能对比库缺失——仅 Intel(统一情报中心)和 MarketIntel(市场情报)带\"竞品动态/竞争对手\"分类,但这是市场/商机情报线索,不是研发竞品拆解或性能对比数据,印证\"仅市场情报\"。(3) 可复用模块库(电路/结构/软件组件)完全缺失——前后端对 可复用/复用模块/组件库/电路/结构/软件组件/reusable/component-lib/teardown/benchmark 全量 grep 在 web/ domain/ repository/ service/ 及前端 src/ 下零命中。",
   "reEvidence": "后端无相关实体/控制器/仓储:`grep @RequestMapping web/*.java | grep -iE 'component|reus|teardown|competit|techdoc|knowledge|library|circuit|benchmark'` 仅返回 web/ItKnowledgeController.java:29 @RequestMapping(\"/api/oa/it-knowledge\")(IT部知识库)。domain/ItKnowledgeArticle.java:12 注释\"信息部·IT 知识库文章\"。domain/DesignDoc.java 注释\"design document produced by the design research center; docType 可研报告/初步设计/施工图/计算书/专项方案\"——工程设计非研发产品技术文档库。前端映射:/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts 中产品开发部 blocks 内 {\"name\":\"研发知识库\",\"status\":\"built\",\"path\":\"/knowledge/doccenter\",\"pageLabel\":\"文档中心\"}——指向通用知识社区文档中心(oaModules.ts:155 id 'knowledge'/key 'doccenter' kind:'tree')。竞品仅情报:domain/Intel.java:13 category 含\"竞品动态\";domain/MarketIntel.java intelType 含\"竞争对手\"——均为市场情报。前端 grep 可复用/复用模块/组件库/电路/结构/软件组件/reusable/teardown/benchmark 在 src/ 下零命中;后端 repository/ 同类 grep 零命中。rd 模块(oaModules.ts:362-405)40+ 子项中无研发技术文档库/竞品拆解库/复用组件库任一项。"
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "9. 与其他部门协同接口",
   "verdict": "PARTIAL",
   "gap": "跨部门协同多为单向只读聚合或文本声明；量产 BOM/图纸/工艺无真发布通道；研发采购接口空(模块6缺)；产品上市回流/售后对接缺失；非事件驱动接口。",
   "severity": "med",
   "evidence": "维持。ECO 执行'已通知采购/生产/质量'确为 EngineeringChangeController.approve(:193) 写进 impactReport 的文本，非真接口推送。采购部研发采购申请/物料清单接口因模块6(研发物料)缺失而空。生产/制造中心发布量产 BOM/图纸/工艺无真发布通道(DesignDoc 无发放端点)。售后改进需求虽可建 ProductRequirement(source 字段含售后)但无售后系统对接。研发费用证据链(RdExpenseTraceController)为单向只读聚合。整体协同靠人工同库读取，非事件驱动接口(TriggerRuleEngine 联动未覆盖研发→采购/生产链)。",
   "survives": true,
   "reNote": "Gap real. R&D cross-dept interfaces are read-only or text-only.",
   "reEvidence": "DesignDoc no release; BomItem signoff sets passed only; MRP read-only; ServiceTicket no ProductRequirement ref; TriggerRuleEngine no R&D branch."
  },
  {
   "area": "创新研发中心/产品开发部",
   "module": "11. 移动端应用",
   "verdict": "LOGIC_GAP",
   "gap": "移动端仅 summary 聚合，无移动审批工作流端点、无移动进度填报+照片上传、无移动文档权限端点；非真移动工作台。",
   "severity": "med",
   "evidence": "维持。MobileController 经 grep 全文仅一个端点 @GetMapping('/summary')(:58)，无任何移动审批/进度填报/照片上传/文档权限端点。grep 移动进度|手机填报|现场照片|mobileApprove|mobileProgress|photoUpload 在研发域零命中(仅 WorkMethodUsage/SewageWorkOrder 无关命中)。评审/变更/采购申请移动审批、手机进度填报+照片、移动文档权限均无专属端点。且 summary 类注释(:60-67)自承曾会把全库待办端给任意 USER，现已收口为'本人发起或本人当前办理'过滤(:75-79)。",
   "survives": true,
   "reNote": "缺口实质属实，但描述有一处不准确，需要分层说明。\n\n我尽力推翻，找到的最强反证：移动端并非\"仅 summary 聚合\"——除 /api/oa/mobile/summary（MobileController）外，还有两个独立移动端点且都在活体验证通过：\n1) MobileApprovalController @ /api/oa/mobile-approvals（GET，活体返回本人待办精简列表，经 WorkflowService.isCurrentHandler 过滤+自批闸，复用真审批引擎）；\n2) MobileCheckinController @ /api/oa/mobile-checkins（外勤打卡真 CRUD，geolocation 经纬度+属主收口）。\n所以描述里\"移动端仅 summary 聚合\"这句字面不成立。\n\n但缺口的三条实质指控逐条核对后成立：\n- \"无移动审批工作流端点(动作)\"：mobile-approvals 是只读队列(POST 活体返回 405)，没有移动端审批\"动作\"(同意/退回/转交)端点。前端 approval.vue/workbench.vue 点单据一律 router.push('/collab/handle') 跳到共享桌面办理页，由通用 WorkflowService/FormInstance 端点承接，移动侧无专属办理写端点。\n- \"无移动进度填报+照片上传\"：成立。workbench.vue 的\"进度填报\"Tab 里\"填报进度\"按钮只是 go('/goal/project360') 跳共享页，移动侧没有任何进度写端点；照片上传全链路缺失——MobileCheckin 实体无 photo/附件字段、checkin.vue 无任何 upload 控件、通用 FileController(multipart) 没接进任何移动页。\n- \"无移动文档权限端点\"：成立。无移动专属文档权限端点；通用 FileController/DocumentController 的对象级权限存在但非移动专属、也未接入移动工作台。\n\n结论：核心论断\"非真移动工作台\"成立(移动审批动作/进度填报写/照片上传/移动文档权限均缺，写动作一律外跳共享桌面页)，无法推翻；仅\"仅 summary 聚合\"这一措辞偏严(实有 mobile-approvals 读队列与 mobile-checkins 打卡 CRUD)。判 real=true。",
   "reEvidence": "后端: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/MobileApprovalController.java (仅 @GetMapping queue, 活体 POST=405); MobileController.java (仅 /summary 只读聚合); MobileCheckinController.java (打卡 CRUD, 无 photo/MultipartFile); domain/MobileCheckin.java (无照片/附件字段); FileController.java (通用 multipart 上传+对象级权限, 非移动专属、未接入移动). 前端: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mobile/approval.vue:53 handle() -> router.push('/collab/handle'); workbench.vue:192 填报进度 -> go('/goal/project360'); workbench.vue:122 openTodo -> /collab/handle; checkin.vue 无 upload 控件. 活体(127.0.0.1:8091): /mobile/summary 与 /mobile-approrovals(GET) 均 200, POST /mobile-approvals=405, /mobile-checkins=200。grep upload|photo|照片|MultipartFile 在 MobileCheckinController/MobileCheckin 全部 0 命中。"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "1. 政策与申报计划管理",
   "verdict": "PARTIAL",
   "gap": "政策到期自动下架(无 @Scheduled 处理 Policy 状态)、定期主动推送政策至申报人(无推送/订阅作业)、申报任务甘特图三项缺失。",
   "severity": "med",
   "evidence": "政策库 CRUD/分类/标签/匹配存在：PolicyController(web/PolicyController.java) 有 category/authority/tags/conditions/fundAmount/deadline/status 字段及 /policies/match 按企业画像标签命中匹配。BUT 三处缺口属实：(1)政策到期自动下架无调度——唯二的 @Scheduled 类 AlertScheduler.java(refreshCertExpiry 只刷 PersonnelCert) 与 IntegrationScheduler 均不触碰 Policy；AlertController.aggregate() 数据源为 PersonnelCert/Patent/ContractMilestone/Inventory/LabInstrument/SafetyCheck/Budget/FormInstance，无 Policy/PolicyApplication，政策『已截止』只能靠 PUT 人工置位(match 端点仅在查询时 skip 已截止，不改状态)。(2)推送为按需调 /policies/match，无定期推送/订阅作业；NotificationService 仅写站内 Message，无政策定向推送。(3)申报任务分解 DeclarationStepController 有步骤台账但无甘特图(甘特仅通用 goal/project.vue)。",
   "survives": true,
   "reNote": "缺口属实，三项均确认缺失（我已尽力推翻但证据反向成立）。\n\n1) 政策到期自动下架：全后端仅有两个 @Scheduled 方法——AlertScheduler.pushAlerts() 只刷新 PersonnelCert 证件到期状态，IntegrationScheduler.scanAndRun() 只跑外部同步台账；两者都不引用 policyRepo/Policy。Policy.status（可申报/已截止/草稿）只能由 PolicyController 的 create/update 手工设置。PolicyController.match() 虽在匹配时跳过\"已截止\"，但\"已截止\"这个状态没有任何作业根据 deadline 自动改写。task/ 与 service/ 目录无任何 policyRepo/已截止/deadline 处理。结论：无到期自动下架。\n\n2) 定期主动推送政策至申报人：所谓\"匹配推送\"只是 GET /policies/match（手工拉取式匹配器，按画像标签命中数+到期排序），属被动 pull，需用户/前端主动调用。后端无 PolicySubscription 实体、无 subscribePolicy/policyPush/pushPolicy、无 @PostMapping subscribe|push，无任何定时把政策推给申报人的作业。结论：无推送/订阅作业。\n\n3) 申报任务甘特图：唯一真实甘特图实现在 goal/project.vue（目标/项目管理模块的任务视图，含 list/kanban/gantt 三视图切换），不属于申报域。申报域页面 declaration.vue/declboard.vue/board.vue/declsteps.vue 均无 gantt/甘特/timeline 视图；declboard.vue 是只读 KPI 统计看板。policylib.vue 的 el-timeline 只是单条 PolicyApplication 的状态推进时间线（申报中→已受理→…），非跨任务时间轴甘特图。WorkPlan 实体仅有 period/status，无 start/end 日期支撑甘特。结论：申报域无甘特图。",
   "reEvidence": "后端 @Scheduled 只有2处且都不碰 Policy：oa-backend/src/main/java/com/kaidi/oa/task/AlertScheduler.java:72-80（只 refreshCertExpiry/scanOvertimeInstances，针对 PersonnelCert 与 FormInstance）、oa-backend/src/main/java/com/kaidi/oa/task/IntegrationScheduler.java:38-51（只 IntegrationExecutor.runPending）。Policy 状态写入仅在 oa-backend/src/main/java/com/kaidi/oa/web/PolicyController.java:101（create 默认\"可申报\"）与:122（update 手工设）；match 在:150 仅过滤\"已截止\"但不自动产生该状态。Policy 实体 oa-backend/src/main/java/com/kaidi/oa/domain/Policy.java:44-46 有 deadline/status 但无作业驱动。无推送/订阅：全后端 grep PolicySubscription|subscribePolicy|policyPush|pushPolicy|@PostMapping.*subscribe|push 均无；活体 GET /api/oa/policies/subscribe 与 /push 返回 400（未映射）。甘特图唯一实现 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/goal/project.vue:117,160,354,402（list/kanban/gantt），不在申报域。申报域页面 rd/declaration.vue、rd/declboard.vue、rd/board.vue、rd/declsteps.vue 全无 gantt/甘特/timeline；policylib.vue:499-511 的\"推进时间线\"是 el-timeline 单申报状态线（rd/policylib.vue）。WorkPlan 域 oa-backend/src/main/java/com/kaidi/oa/domain/WorkPlan.java:11 仅 period/status。活体登录 POST /api/oa/auth/login(admin/123456) 取 token 后 GET /api/oa/policies 返回 id=1\"高新技术企业认定\" status=\"申报中\" deadline=\"2026-08-31\"，证实状态为手工值、无自动下架作业。"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "2. 申报项目管理（全过程）",
   "verdict": "PARTIAL",
   "gap": "申报专项会签链未绑 WorkflowService、材料协同未绑申报+无外部专家安全链接、外部账号密码加密存储与政务平台对接缺、社保/个税/工程业绩自动采集缺、失败案例库缺。",
   "severity": "high",
   "evidence": "立项(Declaration/DeclarationStep)、条件自查自动取数(EligibilityCheckService 从 rd_expense/patent/personnel_cert/project 四仓取数判达标)、材料清单模板(DeclarationTemplateController)、自动采集步骤(DeclarationStepController.autoCollect 汇总研发费+IP)均在。BUT 多处缺口属实：(1)内部审核会签链未与 WorkflowService 绑定——grep 确认 WorkflowService.java 无 declaration 绑定，无『申报专员→部门→技术/财务/法务会签→高管』的申报 FormTemplate。(2)材料协同只有通用 CollabDocController(无 declaration 绑定/无外部专家安全链接，grep external/安全链接 零命中)。(3)外部提交『账号密码加密存储』缺——Declaration 实体仅 8 字段(name/program/authority/rdProjectId/amount/deadline/status/owner)，无 receiptNo/account/password 字段；EsignController 仅绑定 Contract(/api/oa/contracts 下)非申报，ExternalSystemConfigController 仅是对接系统名册无加密凭证，政务平台对接未落地。(4)HR(社保/个税)、工程业绩自动采集未在申报侧落地(EligibilityCheckService 仅 4 指标:研发费占比/IP数/科技人员占比/已完成项目数)。(5)失败案例库缺——grep 失败案例/案例库 在申报域零命中，Declaration 无 failReason 字段。",
   "survives": true,
   "reNote": "尽力推翻失败，缺口五项全部属实。申报域(创新研发中心/申报服务部 申报项目管理全过程)由 DeclarationController / QualDeclarationController / PolicyApplicationController / DeclarationStepController / ExpertController 五个控制器承载，但: (1)会签链未绑 WorkflowService——WorkflowService(含 countersignStatus/会签/并行同步)只注入 FormInstance/Task/Mobile/MobileApproval，五个申报控制器无一 import 或调用它，各自用私有内联状态数组(PolicyApplicationController.FLOW、QualDeclarationController.NEXT)做线性状态机，无真正会签；(2)材料协同未绑申报——DeclarationStep 的\"材料协同\"仅是 stepName 字符串枚举项，DeclarationStepController/DeclarationStep 全无 CollabDoc/协同模块引用；外部专家安全链接全树不存在(Expert 实体只有 name/field/org/title/phone/status，无 secureLink/token/临时链接字段)；(3)外部账号密码加密存储与政务对接缺——唯一政务相关是 ExternalSystemConfig(通用端点名册)+MockSyncAdapter，后者注释自承\"真实政务对接留 TODO/模拟阶段不实连\"，且 ExternalSystemConfig 无任何 account/password/credential/secret 字段，PasswordUtil 仅用于用户登录哈希；(4)社保/个税/工程业绩自动采集缺——唯一 autoCollect(DeclarationStepController.auto-collect/{id})只累加研发费用(RdExpense)+知识产权(Patent)件数，社保/个税/工程业绩在申报域代码零出现；(5)失败案例库缺——失败案例/落选案例/failureCase 全树为空，仅有的\"案例库\"属 Culture/Sentiment 等无关模块。判定 PARTIAL 准确。",
   "reEvidence": "web/QualDeclarationController.java:54-66 (私有 NEXT 状态机，无 WorkflowService); web/PolicyApplicationController.java:47 (私有 FLOW 数组); web/DeclarationController.java 全文 (纯 CRUD 无审批引擎); grep WorkflowService web/Declaration*.java web/Policy*.java web/QualDeclaration*.java web/Expert*.java = 空; web/DeclarationStepController.java:27,95-129 (autoCollect 仅 RdExpense+Patent，材料协同仅字符串); domain/Expert.java:22-38 (无 secureLink 字段); domain/ExternalSystemConfig.java 全文 (无 password/account/credential 字段); service/MockSyncAdapter.java:13,31 (政务对接 TODO/模拟不实连); grep \"社保|个税|工程业绩|失败案例|secureLink|安全链接\" 申报域 = 空"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "3. 申报后维护与跟踪",
   "verdict": "PARTIAL",
   "gap": "申报项目验收任务自动生成+验收材料审核缺(CompletionAcceptance 仅服务工程监理)；到账后未联动财务凭证入账/项目预算提取，仅生成机构付款单。",
   "severity": "med",
   "evidence": "维护任务自动滚动(RdMaintenanceTaskController.complete 按年度/季度自动生成下一期)、资金拨付跟踪(RdGrantDisbursementController 到账状态机+settle-agency 生成机构服务费付款单)、绩效后评估(DeclarationDashboardController/grant summary)都在。BUT 两处缺口属实：(1)申报侧验收管理缺——CompletionAcceptanceController 仅绑定 SupervisionProject(工程监理竣工验收，construct of /completion-acceptances)，无『科技计划/技改项目自动生成验收任务+验收材料编制审核』的申报验收实体。(2)到账联动不完整——settleAgency 仅在资金支付中心生成一张『申报服务费』待付付款单(Payment)，未联动财务凭证入账(Voucher)、未提取项目支出预算(Budget)，需求『自动通知财务入账、提取项目支出预算』未打通。",
   "survives": true,
   "reNote": "缺口属实，三个子点全部成立，无法推翻。(1) 申报项目验收任务自动生成缺失：DeclarationController 仅纯 CRUD；DeclarationStepController 步骤生命周期固定为 立项/材料协同/数据采集/内部审核/外部提交/进度跟踪/补正答辩/结果登记，仅 autoCollect 自动采集研发费用/知识产权，无验收任务生成；PolicyApplicationController 状态机止于 已结题(仅 advance/reject)，不派生验收任务。全库唯一的\"验收→自动联动\"是项目域(TriggerRuleEngine.ruleAcceptProject、ProjectController、CslProjectController)，与政府申报无关。(2) 验收材料审核确仅服务工程监理：CompletionAcceptance domain 注释与表名 completion_acceptance 明确写「工程监理部·竣工验收」，supervisionProjectId 为必填外键；CompletionAcceptanceController 路由 /completion-acceptances，/pass 动作回写父 SupervisionProject，与申报无任何关联。(3) 到账后未联动凭证入账/预算提取，仅生成机构付款单：RdGrantDisbursementController.receive() 仅累加 receivedAmount/回写到账日/推进状态，无凭证无预算；settleAgency() 仅在资金支付中心建一张 Payment(payType=申报服务费, 收款方=agencyName, 状态 待付) 即机构付款单，回填 paymentId，不建 Voucher、不动 Budget。grep 证实 declaration/grant 全部文件零 Voucher/Budget/预算/凭证 引用，BudgetController/VoucherController 也无 RD/申报引用。下游唯一可能出现的凭证是 PaymentService.autoVoucher 在 confirmPay 时生成，且为 借应付账款/贷银行存款(对外支付机构费),既非政府资金到账入账凭证,也非项目预算提取。",
   "reEvidence": "RdGrantDisbursementController.java:163-187 receive() 仅 setReceivedAmount/setReceivedDate/setStatus 无凭证预算；:196-228 settleAgency() 仅 new Payment(payType=申报服务费/payee=agencyName/状态待付)+回填paymentId+置已分配；DeclarationStepController.java:102-129 autoCollect 只采集费用/专利无验收；PolicyApplicationController.java:47,165-195 FLOW 止于已结题仅 advance/reject；CompletionAcceptance.java:11-21 注释+@Table(completion_acceptance) 工程监理部；CompletionAcceptanceController.java:32 @RequestMapping(/completion-acceptances)+:71-75 必填 supervisionProjectId+:131 /pass 回写监理项目；PaymentService.java:113-129 autoVoucher 借应付账款/贷银行存款(对外付款,非到账入账)；grep 证实 declaration/grant 文件零 Voucher/Budget/预算 引用，Budget/VoucherController 无 RD/申报引用。"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "4. 申报成果与档案管理",
   "verdict": "LOGIC_GAP",
   "gap": "无关联申报项目的成果库实体、无申报办结自动归档 TriggerRuleEngine 规则、无历史申报数据复制复用端点。",
   "severity": "med",
   "evidence": "(1)申报成果库无专属承载——TechAchievement(domain/TechAchievement.java) 是科技成果登记库，关联 rdProjectId/ipAssetId 而非 declarationId/policyApplicationId，且不承载资金到账凭证/荣誉奖牌/课题验收证书，非申报项目成果闭环；DataSeeder 把申报材料塞进通用 archive(category『申报成果』)系借用通用档案，非申报实体。(2)自动归档缺联动——TriggerRuleEngine.java 的 chain 方法仅 receipt.invoice/contract.toSeal/project.toArchive/seal.markUsed/supplier.admit 等，无『申报办结→自动打包推送资料室』规则(grep declaration/申报 在 TriggerRuleEngine 零命中)；归档须人工经 ArchiveSubmissionController 发起。(3)历史数据复用缺——Declaration/PolicyApplication/QualDeclaration 控制器均无 clone/copy/复用端点(grep clone/copy/复用 在申报域零命中)。",
   "survives": true,
   "reNote": "缺口属实，三条子断言逐条核验后均成立（最接近的实现是邻域功能，但都不满足该缺口的具体口径）：\n\n1) 「无关联申报项目的成果库实体」——成立。系统确有成果库实体 TechAchievement（domain/TechAchievement.java + TechAchievementController + 前端 techachieve.vue/achievement.vue），但它只挂 rdProjectId（研发立项）与 ipAssetId（知识产权），bindProject/bindIp 与仓储 findByRdProjectId 印证；实体内无任何 declarationId/policyApplicationId 字段（grep 申报/declaration/policy 于 TechAchievement.java 全空）。即成果库关联的是「研发项目」而非缺口所指的「申报项目」(Declaration/PolicyApplication)，无成果↔申报项目关联。\n\n2) 「无申报办结自动归档 TriggerRuleEngine 规则」——成立。TriggerRuleEngine 的归档规则 chainArchiveProject（ruleKey=project.toArchive）只由「项目」验收/结项/竣工/交付关键词触发，且只经 FormInstance/WorkflowService 路径；不存在以申报办结/已结题为触发的归档规则。申报生命周期（PolicyApplicationController 申报中→…→已结题；DeclarationController；DeclarationStepController）完全不走 WorkflowService/FormInstance/TriggerRuleEngine（这些控制器内无 .fire(、无 TriggerRuleEngine、无 new Archive(），故申报办结后无任何自动归档。\n\n3) 「无历史申报数据复制复用端点」——成立。DeclarationController/PolicyApplicationController/DeclarationStepController/DeclarationTemplateController/TechAchievementController 全量端点中无 copy/clone/reuse/duplicate/from-history 任何复制复用接口。最接近的 DeclarationTemplate（模板库）与 auto-collect（从关联 rd 项目汇总研发费/专利数）都不是「把往年某条申报数据复制到新申报」的复用，不能顶替。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa：\n- domain/TechAchievement.java（成果库实体；仅 rdProjectId/ipAssetId，无 declarationId）\n- web/TechAchievementController.java（bindProject/bindIp，端点仅 CRUD+transition，无 copy）\n- repository/TechAchievementRepository.java（仅 findByRdProjectId，无按申报查询）\n- service/TriggerRuleEngine.java:355 chainArchiveProject（ruleKey project.toArchive，只项目验收触发；ruleKeyFor() 无任何申报/结题键）\n- web/PolicyApplicationController.java（申报状态机 申报中→已受理→已立项→已拨付→已结题，advance/reject 无 .fire/归档）\n- web/DeclarationController.java、web/DeclarationStepController.java（auto-collect 仅汇总 rd 费用/专利，非历史申报复用）、web/DeclarationTemplateController.java（模板库，非复制端点）\n- grep 验证：PolicyApplication/Declaration 各控制器内无 TriggerRuleEngine/.fire(/new Archive/copy/clone/reuse/历史/复制/复用 命中。\n前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/（techachieve.vue/achievement.vue 接 /tech-achievements，无成果库↔申报关联、无历史申报复用按钮）。"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "7. 与其他部门接口",
   "verdict": "LOGIC_GAP",
   "gap": "8 部门对接仅落地 4 个数值指标，多数佐证材料(扫描件/社保/个税/纳税表/检测报告/工程业绩/资质证书等)无跨模块自动归集，资料室归档人工。",
   "severity": "high",
   "evidence": "EligibilityCheckService 自动取数仅 4 指标：财务研发费占比(rd_expense)、有效 IP 数(patent)、科技人员占比(personnel_cert)、已完成项目数(project)。需求列 8 个对接部门的全量数据项中，审计报告/高新产品收入/纳税申报表、证书扫描件/法律状态、社保记录/个税记录、检测报告、工程业绩/用户证明/现场照片、质量体系/安全标准化证书、营业执照/信用报告 等均无自动接入——grep 确认申报域控制器无引用 QmsRecord/SafetyCheck/Certification 等做附件级采集；资料室归档为人工(ArchiveSubmission)。表面有自动取数框架但覆盖面约一半且无附件级采集。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。申报服务部「与其他部门接口」声明 8 个对接部门（财务部/知识产权部/人力资源部/研发技术中心/工程项目部/质安部/综合部/资料室，见 kaidiDeptView.ts），但跨模块自动归集仅落地 4 个纯数值指标，且全部是数字/计数，不含任何佐证材料文件：\n\n1) EligibilityCheckService（活体已验 /api/oa/eligibility-checks?type=高企）只产出 4 项：研发费用占比、知识产权数量、科技人员占比、已完成项目数——每项是数字+来源文字串，无附件。\n2) DeclarationStepController.autoCollect（/api/oa/declaration-steps/auto-collect/{id}）只回 2 个数字的文字摘要「研发费用¥… + 知识产权…件」，把数据采集步骤置已完成，不拉任何扫描件。\n3) QualDeclarationController.gap 只匹配人员姓名/项目名列表（计数），仍无社保/个税/检测/资质件。\n\n佐证材料未跨模块归集：TaxFiling（/api/oa/tax-filings）与 TestReport（/api/oa/test-reports）均为独立台账，实体无 declarationId/rdProjectId 关联字段，控制器也只注入自身仓库；无任何控制器把申报/资格自查与 TaxFiling/TestReport/StaffDossierItem/File 等材料仓库做联结。DeclarationTemplate.requiredMaterials 仅是逗号分隔的材料「名称」静态清单，非实际归集的文件。\n\n资料室归档确为人工：ArchiveSubmissionController.create 需人工填 sourceDept/title；StaffDossierController.addItem 默认 sourceEvent=「手工上传」、autoArchived=FALSE，且全仓库 grep 不到任何 setAutoArchived(true) 调用（只有 seeder 置 FALSE），无申报材料自动流入档案。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/service/EligibilityCheckService.java(check()只组装4个数值CheckItem); oa-backend/src/main/java/com/kaidi/oa/web/EligibilityCheckController.java; oa-backend/src/main/java/com/kaidi/oa/web/DeclarationStepController.java(autoCollect仅汇总研发费用+专利件数2个数字); oa-backend/src/main/java/com/kaidi/oa/web/QualDeclarationController.java(gap只匹配人员名/项目名); oa-backend/src/main/java/com/kaidi/oa/domain/TaxFiling.java + web/TaxFilingController.java(独立/api/oa/tax-filings无declarationId); oa-backend/src/main/java/com/kaidi/oa/domain/TestReport.java + web/TestReportController.java(独立/api/oa/test-reports仅sampleId/taskId); oa-backend/src/main/java/com/kaidi/oa/domain/DeclarationTemplate.java(requiredMaterials仅材料名清单); oa-backend/src/main/java/com/kaidi/oa/web/StaffDossierController.java:192-193(sourceEvent默认手工上传/autoArchived=FALSE); oa-backend/src/main/java/com/kaidi/oa/web/ArchiveSubmissionController.java(create需人工填sourceDept); ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts(申报服务部interfaces列出8部门); 活体验证 POST/GET 8091 返回4项passedCount=4。"
  },
  {
   "area": "创新研发中心/申报服务部",
   "module": "8. 移动端应用",
   "verdict": "PARTIAL",
   "gap": "申报材料内审/维护任务确认(状态机)未纳入移动审批队列；无手机 push 通道做政策推送与截止/维护到期提醒(仅站内 Message)。",
   "severity": "med",
   "evidence": "移动工作台存在(MobileController /mobile/summary、MobileApprovalController /mobile-approvals)。BUT 缺口属实：(1)移动审批仅复用通用 FormInstance 办理人队列(MobileApprovalController 读 PENDING_STATUSES 的 FormInstance 且 isCurrentHandler)，而申报材料内审/维护任务确认走状态机(DeclarationStep.status / RdMaintenanceTask.status)非 FormInstance，二者未打通，未纳入移动队列。(2)无移动 push 通道——NotificationService.notify 仅向 MessageRepository 写站内消息，无 SMS/手机 push/订阅服务；政策推送、截止日/到期维护推送至手机均无专项通道。移动端为通用工作台复用，非申报场景定制。",
   "survives": true,
   "reNote": "缺口属实。两部分都成立。(1) 申报材料内审/维护任务确认未纳入移动审批队列：MobileApprovalController.queue() 唯一数据源是 FormInstanceRepository.findByStatusIn(待办/办理中/已退回)，只把工作流引擎的 FormInstance 投影为移动待办；而申报\"内部审核\"是 DeclarationStep 的独立 status 字段(待办/进行中/已完成,由 DeclarationStepController 管理)，维护任务确认是 RdMaintenanceTaskController 的 /{id}/complete 翻自身 status 到已完成——两者都是各自的独立状态机，从不创建 FormInstance(grep 确认 DeclarationStep/RdMaintenanceTask/QualDeclTask 均不实例化 FormInstance、也不调 NotificationService)，故结构上不可能出现在移动审批队列里。(2) 无手机 push 通道：NotificationService.notify() 仅落库 Message(站内消息)，全后端 grep 不到任何 deviceToken/FCM/APNs/JPush/getui/umeng/SMS/email/web-push(VAPID/serviceWorker) 基础设施；唯一的 WebSocket(WebSocketConfig/CollabSocketHandler, /ws/collab/**)是协同文档编辑用，非推送；AlertScheduler.pushAlerts() 每小时跑也只写站内 Message；政策推送只有 GET /policies/match 拉取式、维护到期只有 GET /rd-maintenance-tasks/alerts/due 拉取式，均无主动 push；前端移动模块(mobile/approval.vue)也无 serviceWorker/Notification API/订阅代码。判定 PARTIAL 准确。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/MobileApprovalController.java:45,77 (唯一注入 FormInstanceRepository，queue 仅遍历 findByStatusIn 的 FormInstance); oa-backend/src/main/java/com/kaidi/oa/web/DeclarationStepController.java:27-28,87,123 (内部审核为 DeclarationStep.status 独立状态机，无 FormInstance); oa-backend/src/main/java/com/kaidi/oa/web/RdMaintenanceTaskController.java:124-134 (/{id}/complete 仅翻自身 status，独立状态机); oa-backend/src/main/java/com/kaidi/oa/domain/RdMaintenanceTask.java:49-50 (status 字段待办/进行中/已完成); oa-backend/src/main/java/com/kaidi/oa/service/NotificationService.java:9-13,27-45 (仅 messageRepo.save，站内消息，无任何 push 通道); oa-backend/src/main/java/com/kaidi/oa/config/WebSocketConfig.java:25-27,54 (WebSocket 仅 /ws/collab/** 协同文档); oa-backend/src/main/java/com/kaidi/oa/task/AlertScheduler.java:72-112 (pushAlerts 只经 notifications.notify 写站内 Message); oa-backend/src/main/java/com/kaidi/oa/web/PolicyController.java:145,170 (政策仅 GET /match、/profile 拉取式无 push); grep 全后端 deviceToken|fcm|apns|jpush|getui|umeng|webpush|VAPID|sms|short-message 零命中; 前端 ofbiz-framework/plugins/modern-ui/app/src 内 serviceWorker|Notification(|pushManager|requestPermission 零命中，mobile/approval.vue 无推送代码。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "4. 费用与预算控制",
   "verdict": "PARTIAL",
   "gap": "无 IP 域专用预算编制(申请/维持/诉讼分类)；缴费无自动扣减 IP 预算+超支预警；无含被引用次数的投入产出分析。",
   "severity": "med",
   "evidence": "IpAssetController.java(web/IpAssetController.java) 有完整费用归集：addFee/scheduleFees 按案件登记申请费/代理费/年费/复审费，feeSummary(/{id}/fees/summary) 按费用类型+成本中心(costCenter)归集汇总——这部分需求(费用归集/分摊成本中心)是 MET 的。但预算侧确实缺失：BudgetController/Budget.java 是通用 element(人工费/材料费…)预算，无知识产权年度/季度预算编制，更无按申请/维持/诉讼分类预算；payFee() 只生成 Payment + 累加 totalCost，全程没有任何 budget 扣减或超支预警（grep deduct/扣减/ipBudget 在 IP 控制器零命中）；IpInsightController.bi() 出授权率/费用趋势/部门排名，但无'投入金额 vs 授权数 vs 被引用次数'的投入产出分析（grep 投入产出/被引用/citation 在 IP 域零命中）。初判成立。",
   "survives": true,
   "reNote": "缺口属实。IP域确有可观的费用台账与缴费联动(IpAsset/IpFee/payFee生成付款单+回写totalCost+年费分级到期预警)，但缺口描述的三项专项能力均未实现：(1)无IP专用预算编制——Budget实体的element字段只有人工费/材料费/机械费等通用成本要素，无申请/维持/诉讼分类，无任何IP预算实体或编制端点；LitigationCase也无预算字段。(2)缴费(payFee)只生成付款单并回写资产累计费用totalCost，完全不触碰任何Budget记录，无预算自动扣减，也无任何超支(预算占用)预警——feeAlerts只是按dueDate做的\"到期\"分级提醒而非预算超支预警。(3)无含被引用次数的投入产出分析——citeCount/citedBy仅存在于CultureCase(文化案例)与ItKnowledgeArticle.useCount(IT知识),与专利无关；IpInsight的/bi看板只有授权率/法律状态分布/费用趋势,无投入产出ROI且无专利被引指标。三项均找不到实现，无法推翻。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/Budget.java:35(element通用成本要素,doc列出人工费/材料费等,无IP分类); oa-backend/src/main/java/com/kaidi/oa/web/BudgetController.java:40-46(只按project/element/companySubject/year过滤,无IP linkage,grep patent/知识产权零命中); oa-backend/src/main/java/com/kaidi/oa/web/IpAssetController.java:379-419(payFee仅生成Payment+置已缴+回写totalCost,grep budget/预算/超支零命中=无扣减无超支预警); IpAssetController.java:446-479(feeAlerts是dueDate到期分级,非预算超支); oa-backend/src/main/java/com/kaidi/oa/domain/LitigationCase.java(无预算字段); citeCount/citedBy仅见web/CultureCaseController.java:86,201 与 domain/ItKnowledgeArticle.java:46(useCount),均非IP域; oa-backend/src/main/java/com/kaidi/oa/web/IpInsightController.java:82-163(/bi看板只有授权率/法律状态/费用趋势,无投入产出ROI无被引指标,其budget字段=RdProject.getBudget透传第274/302行); 前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/ipinsight.vue grep 被引/引用/投入产出/预算编制 全部零命中。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "5. 合规与审计追溯",
   "verdict": "PARTIAL",
   "gap": "强制复核未做提交前流程门禁(review 仅可选留痕)；商业秘密类电子证据链(接触人员/访问/下载记录)完全缺失。注：'未记录IP'一条系初判错误——全站写审计已含 clientIp。",
   "severity": "med",
   "evidence": "模块整体 PARTIAL 维持，但初判中'操作日志未记录IP地址(仅operator/time)'这一条是错误的，必须纠正：config/AuditLogInterceptor.java 是全站统一写审计拦截器，CorsConfig.java:32 注册到 /api/oa/**，对一切 POST/PUT/PATCH/DELETE(含 ip-assets 写)在 afterCompletion 落一条 OperationAuditLog，字段含 operator/operatorId/operatorRole/method/path/statusCode/clientIp(clientIp() 取 X-Forwarded-For 首段或 remoteAddr)/occurredAt，且 sha256 哈希链不可篡改、控制器无删改端点(OperationAuditLogController 只读+/chain/verify)。所以'人/时/IP'三要素齐全。其余两条 gap 成立：IpAssetController 的 /{id}/review 是可选留痕，advance() 状态机只校验 stage 流转、不强制'提交前必须有复核事件'，无流程门禁；IpAsset/IpAssetEvent 无商业秘密接触人员/访问时间/下载记录字段，且 OperationAuditLog 只审计写不审计读(GET 排除)，电子证据链缺失。",
   "survives": true,
   "reNote": "尽力推翻后仍无法翻案，缺口属实(PARTIAL 成立)。逐条核验两个子命题：\n\n【A 强制复核未做提交前流程门禁——半成立，核心成立】IpAssetController(web/IpAssetController.java) 的状态机 STAGE_FLOW 确实结构性强制 提案→内部审核→代理委托→官方提交：提案只能去[内部审核,已撤回](L72)，无法跳过\"内部审核\"节点直达官方提交，这点算一道流转门禁。但真正的\"复核动作/意见\"是 POST /{id}/review(L271-279, eventType=内部复核)，它与状态机完全解耦——advance(L215-243) 只校验 STAGE_FLOW 成员，没有任何\"必须先存在内部复核事件才能离开内部审核/进入官方提交\"的前置校验。即可以 内部审核→代理委托→官方提交 全程不调用 /review。L270 注释自称\"提交前强制复核节点的意见记录\"，但代码层面并不强制。故\"review 仅可选留痕、强制复核未做真正提交前门禁\"成立。\n\n【B 商业秘密类电子证据链(接触人员/访问/下载记录)完全缺失——成立】(1) 统一审计 OperationAuditLog/AuditLogInterceptor 明确只记写请求 POST/PUT/PATCH/DELETE(WRITE_METHODS L45-46, L73)，GET/HEAD/OPTIONS 读请求一律不留痕(\"避免日志爆量\")——即查看/访问/下载这类读事件根本不入审计。(2) FileController /stream 下载口(L107-139) 只做属主鉴权，不写任何访问/下载记录。(3) IpAsset/IpAssetEvent 事件流仅覆盖状态流转/编号登记/缴费/内部复核(IpAssetEvent.java L17)，无接触人员/访问/下载维度。(4) ArchiveBorrow 借阅工作流属于档案知识中心而非知产/研发域，且是申请-审批-借出-归还的正式借阅流程，不是涉密电子文档的细粒度访问/下载留痕。全站确无\"谁访问/下载了哪份商业秘密文档\"的电子证据链。\n\nnote 修正项确认正确：写审计确含 clientIp(OperationAuditLog.clientIp + canonicalOf 参与哈希链)，故\"未记录IP\"系初判错误一说成立，但不影响 PARTIAL 总判。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/IpAssetController.java(STAGE_FLOW L71-80; advance L213-243 仅校验状态机无复核前置; /review L267-279 与状态机解耦); oa-backend/src/main/java/com/kaidi/oa/config/AuditLogInterceptor.java(WRITE_METHODS L45-46, L73 仅写请求留痕、读不审计; clientIp L129/L219-228); oa-backend/src/main/java/com/kaidi/oa/domain/OperationAuditLog.java(clientIp 字段 L67-68 含IP); oa-backend/src/main/java/com/kaidi/oa/web/FileController.java(/stream L107-139 下载仅鉴权无访问留痕); oa-backend/src/main/java/com/kaidi/oa/domain/IpAssetEvent.java(eventType 仅流转/编号/缴费/内部复核 L17 无访问下载); oa-backend/src/main/java/com/kaidi/oa/web/ArchiveBorrowController.java(档案借阅工作流，非知产域访问留痕); grep 全域 domain/web 无 accessLog/downloadLog/接触人员/访问记录 实体"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "6. 研发费用归集与证据链自动化",
   "verdict": "LOGIC_GAP",
   "gap": "无 ERP/财务自动归集(领料/工时/折旧/审批单→RdExpense)；无研发工时在线填写+按项目人员月份自动分摊；证据链为只读聚合视图而非加计扣除/高企复审场景的一键打包导出。",
   "severity": "high",
   "evidence": "RdExpenseController.java create/update 为纯手工录入，全库无任何代码自动写 RdExpense(领料 MaterialIssue 与 RdExpense/RdProject 无关联，grep rdProject/rdExpense 在 MaterialIssue 零命中；无折旧/审批单/工时→RdExpense 的同步逻辑)。研发工时无在线填写实体——CslTimesheetController 虽有'录入+hours×rate 自动算成本+按人/角色汇总'，但绑定的是 CslProject(设计研究中心)，不是 RdProject，且无'按项目/人员/月份自动分摊'。EvidenceController(/rd-projects/{id}/evidence-chain) 与 RdExpenseTraceController 只做只读聚合(项目+费用+专利+申报合并成 JSON 返回),非'一键打包导出'(grep 打包/zip/bundleExport 在全 web/ 零命中)。三项'自动'核心均缺。",
   "survives": true,
   "reNote": "缺口属实，三条子主张全部成立，无法推翻。(1) 无 ERP/财务自动归集：RdExpense 全库只在两处被创建——DataSeeder(种子数据，第2197/2208行)与 RdExpenseController(纯手工 CRUD)。service/ 下没有任何控制器/服务把领料/工时/折旧/审批单转成 RdExpense；TriggerRuleEngine 整文件零 RdExpense 引用，其全部下游联动规则为 payment.create / receipt.invoice / contract.effectivate / contract.toSeal / project.create / project.accept / project.toArchive / seal.markUsed / supplier.admit，没有任何 rd.expense.collect 之类规则。(2) 无研发工时在线填写+按项目人员月份自动分摊到 RdExpense：CslTimesheet/CslTimesheetController 确实存在工时在线填写，但它属于\"设计研究中心\"咨询人工成本归集，只把 hours×rate 算成 CslTimesheet.laborCost 并按项目/按人聚合(projectSummary)，从不写入 RdExpense；且全无\"按月份分摊\"逻辑(grep 月份/按月/分摊/prorat 在 csl/rd 控制器零命中)。(3) 证据链=只读聚合而非一键打包导出：RdExpenseTraceController 自身 docstring 明写\"纯只读聚合…仅 GET\"，前端 rdexpensetrace.vue 只有表格展示+刷新，无任何导出/下载/打包按钮。高企复审场景由 EligibilityCheckService/Controller 提供，但同样是\"纯只读聚合：不引入新实体、不写库\"的达标自查清单，不产出可下载的加计扣除/高企复审打包文件(grep 导出/下载/打包/export/blob/xlsx 在三页面零命中)。",
   "reEvidence": "后端：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdExpenseController.java(纯手工 CRUD，create 第64-81行、update 第84-98行均靠请求体录入)；/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdExpenseTraceController.java(第21-30行 docstring \"纯只读聚合…仅 GET\")；/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/CslTimesheetController.java(工时填写+laborCost 计算+projectSummary 聚合，第90-97/144-185行，从不 new RdExpense)；/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/EligibilityCheckService.java(第34行 \"纯只读聚合：不引入新实体、不写库\")；/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java(第676-686行 ruleKeyFor 全部下游规则，无 rd 归集)。grep 证据：'new RdExpense'/'rdExpenseRepo.save' 仅命中 DataSeeder.java:2197/2208 与 RdExpenseController.java:69/80/97；TriggerRuleEngine.java 对 RdExpense/研发费用 零命中；CslTimesheetController.java/RdExpenseController.java/RdExpenseTraceController.java 对 月份/按月/分摊/prorat 零命中。前端：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/datacenter/rdexpensetrace.vue(第7行注释\"只读聚合\"，模板仅表格+刷新)，对 导出/下载/打包/export/blob/xlsx/pdf 零命中；annualreport.vue 的\"研发费用加计扣除表\"是 settingListStore mock 列表，非打包导出。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "8. 制度版本与修订记录",
   "verdict": "LOGIC_GAP",
   "gap": "制度无版本控制/修订历史/历史版本留存；无发布前三级审批流；无审批通过自动归档+通知。",
   "severity": "med",
   "evidence": "全库无部门'制度'版本控制实体(grep 制度版本/制度发布/regulationVersion/publishApproval 在 web/+domain/ 零命中)。PolicyController/Policy.java 与 PolicyApplicationController 都是'申报政策库/申报工作流'(authority=科技/工信，category=资质/资金)，与部门规章制度无关。Archive 仅有一个固定 category='制度文件' 的归档分类，无版本号序列/修订历史/历史版本留存，无'部门负责人→法务→高管'发布审批流，无审批通过自动归档+通知。初判成立。",
   "survives": true,
   "reNote": "缺口属实。知识产权部\"制度版本与修订记录\"所要求的三项能力——版本控制/修订历史/历史版本留存、发布前三级审批流、审批通过自动归档+通知——均未实现。唯一相关的是前端页 rd/policy.vue（标题\"制度版本管理\"），它只是 MasterDataPage 纯增删改查台账，由 settingListStore('rd-policy') 写入通用 biz_record 表。该行只有一个扁平 version 文本字段（如\"V3.2\"）和 status 文本字段，BizRecordController.update 直接 setDataJson 原地覆盖，既无版本表、无历史版本追加、无历史留存；也没有任何审批动作（更谈不上三级审批），更没有审批通过后的自动归档/通知联动。后端 Policy/PolicyController 是政府申报政策库（带匹配器），ComplianceObligationController 是法规义务台账，二者均与\"内部制度版本控制\"无关且同样无版本/审批/归档逻辑。系统内真有版本/审批/归档能力的是 CollabDoc(历史版本数组+/versions)、FertRecipe/EngineeringChange(版本状态机)，但都属其他领域，未接入制度管理。",
   "reEvidence": "前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/policy.vue (settingListStore('rd-policy'), 列\"当前版本\"仅静态文本, 仅new/edit/delete); api/settingList.ts(走/biz/{type}通用CRUD); data/oaModules.ts:378(制度版本管理->/rd/policy). 后端: web/BizRecordController.java(纯CRUD, update原地覆盖dataJson, 无版本/审批/归档); web/PolicyController.java + domain/Policy.java(政府申报政策库, 无版本/修订/审批); web/ComplianceObligationController.java(/api/oa/compliance-obligations 法规义务台账,无approve/version/历史/归档). 对照真实现: domain/CollabDoc.java:42(历史版本JSON数组)+web/CollabDocController.java:178(GET /{id}/versions); web/FertRecipeController.java(版本控制状态机); web/EngineeringChangeController.java(审批链->版本号). 部室映射: data/kaidiDeptView.ts 知识产权部 duty含\"5.知识产权制度管理\". grep 三级审批/发布前/审批通过自动归档/历史版本 在后端无任何命中绑定到制度域。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "9. 标准申请辅助",
   "verdict": "LOGIC_GAP",
   "gap": "无标准申请填表模板化字段；无草案/编制说明附件；无各阶段耗时自动计算与提醒。",
   "severity": "med",
   "evidence": "全库无标准申请模板化实体(grep 起草单位/计划编号/编制说明/地方标准.*申请/standardName 在 web/+domain/ 仅命中污水排放标准档与品牌项目'计划编号'等无关字段)。无预置'标准名称/起草单位/技术内容/计划编号'结构化字段，无草案/编制说明附件上传，无'提交→受理→审查→报批→发布'各阶段预计耗时自动计算与提醒。初判成立。",
   "survives": true,
   "reNote": "对抗复验失败，缺口属实。链「9.标准申请辅助」对应「技术标准申请」功能，唯一实现是前端 rd/standard.vue（oaModules key=standard, path=/rd/standard），且无任何后端控制器/实体支撑（仅有不相关的 StandardCostController 标准成本台账）。逐条核验三项子缺口全部成立：(1)无模板化字段——standard.vue 只是扁平 MasterDataPage，6 个固定字段(name/stdType/level/applicant/stage/status)，无模板选择驱动填表；现有 DeclarationTemplate 实体注释明确是「政府项目申报(高新技术企业/科技型中小企业...)」专用，且 standard.vue 完全未引用它。(2)无草案/编制说明附件——standard.vue 无附件字段，其唯一渲染器 MasterDataPage.vue 仅支持 text/textarea/number/select/date 五种字段类型，根本没有 file/upload 类型；grep 命中的「编制说明」在 design/reports.vue（无关页面）。(3)无各阶段耗时自动计算与提醒——standard.vue 只有静态 stage 下拉，无 createdAt/时间戳，全库 grep 标准阶段耗时/elapsed/duration/提醒/超期 零命中。IP 域控制器(IpAsset/IpInsight/Patent)也均无标准申请相关逻辑。",
   "reEvidence": "前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/standard.vue (L5-22 仅 6 个简单字段, 用 settingListStore 纯前端持久化, 无模板/附件/耗时); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/masterdata/MasterDataPage.vue (L26 type 仅 text|textarea|number|select|date; L242-254 渲染分支无 file/upload; 全文无 upload/duration/remind); ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts (L377 key=standard path=/rd/standard). 后端: oa-backend/src/main/java/com/kaidi/oa/domain/DeclarationTemplate.java (L12-20 注释明确为政府项目申报模板, 非标准申请); 无 StandardController/StandardApplication 实体; oa-backend/.../web/StandardCostController.java 为标准成本台账, 与标准申请无关. 全库 grep「标准.*草案|标准.*编制说明|标准.*耗时|stageElapsed|阶段耗时」零命中。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "10. 技术合同登记",
   "verdict": "PARTIAL",
   "gap": "无技术合同专用字段(技术金额/登记状态)与技术交易统计；无创新技术方案/承诺书自动生成；合同与知识产权产出无关联。",
   "severity": "med",
   "evidence": "Contract.java type 仅 经营/成本/采购合同，无技术合同专用字段(grep 技术合同/技术交易/承诺书/创新技术方案 全库零命中)，无技术金额/登记状态字段，无技术交易统计分析。Contract 有 projectId 可关联研发项目，但无与知识产权产出(IpAsset)的关联，也无自动生成登记材料。初判成立。",
   "survives": true,
   "reNote": "Gap confirmed. Technical contract registration not implemented. Contract entity only has generic fields, no tech amount or registration status. No tech transaction statistics. No scheme or commitment letter generation. No contract to IP linkage. TechAchievementController registers achievements not contracts, does not cover this.",
   "reEvidence": "Contract.java has no tech amount or registration status field; Patent.java has no contractId; ContractController has no stats endpoint; grep for tech-contract terms returns zero; rd module has no tech contract registration page."
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "11. 预算与计划管理",
   "verdict": "PARTIAL",
   "gap": "无研发/IP 年度季度预算表编制+自动汇总各项目部门+历史对比；无实际费用自动扣减预算+超支预警的 IP 域闭环；年度立项表/科技人员名单与费用归集自动关联未成体系。",
   "severity": "med",
   "evidence": "BudgetController/Budget.java 为通用预算 vs 实际，create() 仅在单条 actual>budget 时置'超支'，无跨项目/部门自动汇总、无历史年度对比、无 IP 域(专利年费/代理费)实际费用自动扣减预算的闭环(IpAssetController.payFee 不触碰任何 Budget)。RdMaintenanceTask 是资质年报/复审到期任务，非研发立项表/科技人员名单维护+费用归集关联。初判成立。",
   "survives": true,
   "reNote": "尽力推翻后，缺口大部分被证伪，但其核心\"未实现\"的两点确实站得住，PARTIAL 判定成立。逐条核：\n\n【已实现，可推翻的部分】\n1) \"实际费用自动扣减预算+超支预警闭环\"——R&D 域确有闭环：DevProjectBudgetController.aggregate 从 RdExpense(rdProjectId 匹配、status=已归集)按科目自动聚合实际成本回填 actualAmount，summary 算逐科目/项目级执行率并标记 overBudget(act>bud)；BizBudget.occupy 报销联动扣减预算余额、超预算返 409 预警、force 强占、release 释放、board 看板 >=90%预警/>100%超支；通用 Budget create 时 actual>budget 自动置\"超支\"。auto-deduct+超支预警闭环存在。\n2) \"年度立项表/科技人员名单/费用归集自动关联未成体系\"——已成体系：EligibilityCheckService 把 RdProject(立项)+RdExpense(费用归集)+PersonnelCert(科技人员名单)+Patent(IP) 四库自动取数联动出高企/科技型中小企业自查清单；RdExpenseTraceController 自动串\"研发立项-费用-凭证\"证据链；IpInsightController.projectMatrix/project-detail 自动串\"研发项目→IP/成果/申报\"。自动关联确成体系。\n\n【未实现，推不翻的部分(故 real=true)】\n- \"历史对比/同比环比\"：全 web/、service/ grep 同比|环比|去年|上年|yoy|历年对比 零命中，R&D/IP 预算无任何历史年度对比逻辑(IpInsight.feeTrend 只是 IP 年费按年汇总趋势、byYear 只是 IP 资产按申请年分组，均非预算历史对比)。\n- \"研发/IP 年度季度预算表编制+自动汇总各项目部门\"：DevProjectBudget 是逐项目按科目预算行(无 year/quarter 周期维度)；通用 Budget 有 year/period(年度/季度/月度)但非 R&D/IP 专属、且不做跨项目/部门自动汇总；BizBudget 有 period+orgUnit 但属经营费用域(投标/差旅/市场)非研发/IP。没有一张\"研发/IP 年度+季度预算表\"同时具备周期维度+跨项目跨部门自动汇总+历史对比。DevDashboard.byProductLine 仅按产品线汇总当期预算/实际(无年度季度周期、无历史对比)。\n\n结论：缺口的\"自动扣减闭环\"与\"立项/人员/费用自动关联\"两点其实已实现(描述偏严)，但\"年度季度预算表+历史对比\"这一核心子项确缺，PARTIAL 判定整体成立，缺口属实。",
   "reEvidence": "关键文件(均为绝对路径)：\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DevProjectBudgetController.java — aggregate(从 RdExpense 自动归集实际成本) + summary(执行率/超预算预警，逐科目与项目级)；CATEGORY_MAP 把 RdExpense 类别映射到预算科目。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/BizBudgetController.java — occupy(扣减+超预算409预警+force强占) / release / board(>=90%预警/>100%超支)。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/BudgetController.java — 通用预算有 year+period(年度/季度/月度)字段，actual>budget 自动置\"超支\"，但无跨项目/部门汇总、无历史对比、非R&D专属。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/EligibilityCheckService.java — RdProject+RdExpense(已归集)+PersonnelCert(科技人员)+Patent(IP) 四库自动取数联动判定，证伪\"未成体系\"。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdExpenseTraceController.java — \"研发立项-费用-凭证\"自动串证据链。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/IpInsightController.java — bi/inventory/project-matrix 跨 IpAsset+RdProject+Declaration+IpFee+TechAchievement 聚合；feeTrend 仅年费趋势、byYear 仅按申请年分组，均非预算历史对比。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DevDashboardController.java — byProductLine 按产品线汇总当期预算/实际(无周期维度、无历史对比)。\n- 前端 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/devbudget.vue(项目级预算+成本归集+执行率页) 与 rd/annualreport.vue(科技年报填报，纯 setting 列表，无预算编制/历史对比)。\n活体验证(127.0.0.1:8091)：dev-dashboard 返回 byProductLine 跨项目预算汇总；ip-insights/bi 返回 feeTrend(空，因无种子)。grep 全后端 同比|环比|去年|上年|yoy|历年对比 在 web/、service/ 零命中——证实无任何预算历史对比逻辑。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "12. 年报与统计填报辅助",
   "verdict": "LOGIC_GAP",
   "gap": "无填报类型预设模板+企业基础数据自动填充；无填报数据逻辑一致性校验；无历年对比与趋势分析。",
   "severity": "med",
   "evidence": "全库无按填报类型(工程勘察设计年报/经开区统计/火炬报表)预设表格模板+自动填充企业基础数据的实现(grep 火炬/经开区/年报模板/annualReport 仅命中 RdMaintenanceTask 注释)。RdMaintenanceTask 仅是'年报填报/复审'到期提醒+周期滚动的任务台账，不含表格模板、不自动填充人员/营收/研发投入/IP数、无填报数据校验(研发费用与项目匹配/工时总和范围)、无历年对比趋势。初判成立。",
   "survives": true,
   "reNote": "缺口属实。该链路对应的专属功能\"科技年报填报\"在前端是 rd/annualreport.vue（oaModules.ts 中 key=annualreport, kind='list', path=/rd/annualreport），仅是一个 settingListStore 通用键值持久化的 CRUD 列表，字段=报表名称/报送年度/报送对象/关键指标/填报状态/负责人，全部手工录入。三项要求均无实现：1) 无填报类型预设模板、无企业基础数据自动填充——create 表单只有静态 select 选项，DeclarationTemplate.bodyTemplate 虽含 {企业名称}{申报年度}{研发投入} 占位符与 autoCheckRules，但后端无任何控制器读取/渲染 bodyTemplate 或执行 autoCheckRules（grep getBodyTemplate/getAutoCheckRules 仅命中实体 getter，无消费方），且其属政府项目申报而非年报填报；2) 无填报数据逻辑一致性校验，全程无校验逻辑；3) 无历年对比与趋势分析，annualreport 是单年平表，IpInsightController 的 byYear/feeTrend 只针对 IP 资产费用且无同比/趋势对比，与填报数据无关。",
   "reEvidence": "前端：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/annualreport.vue（settingListStore('rd-annualreport',...) + MasterDataPage 通用 CRUD，无模板/校验/趋势）；模块定义 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:384（kind:'list'）。后端：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DeclarationTemplateController.java（仅 list/get/create，bodyTemplate 与 autoCheckRules 仅存储从不执行）；/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/DeclarationTemplate.java（占位符仅注释说明，无渲染逻辑）；grep getBodyTemplate/getAutoCheckRules 全后端无消费方。IpInsightController.java 的 byYear/feeTrend 仅 IP 资产费用聚合，非填报数据年度对比。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "13. 资料归档中心",
   "verdict": "PARTIAL",
   "gap": "全文检索为 contains 包含匹配非真索引；会议纪要无自动生成待办+跟踪+责任人；科研信誉加分文件无专项标签分类。",
   "severity": "med",
   "evidence": "ArchiveController.list 的 keyword 过滤是 list.stream().filter(contains(title/tags/summary/fileName)) 内存包含匹配，非真全文索引；category 为固定枚举(项目档案/合同档案/申报成果/制度文件/会议纪要/技术资料)，无'科研信誉加分文件'专项标签分类(仅通用 tags 字段)。MeetingMinuteController 仅 CRUD，MeetingMinute 有 decisions(JSON 串)但无 actionItem，无根据纪要内容自动生成待办+跟踪完成+责任人关联。初判成立。",
   "survives": true,
   "reNote": "缺口为复合 PARTIAL，三条子项中两条确凿未实现，整体属实。子项1(全文检索为contains非真索引)措辞被推翻：资料归档中心有真FTS5全文索引(FullTextSearchService.java 用 SQLite FTS5 trigram 虚表+bm25排序+snippet高亮，前端 archive/globalsearch.vue 调用)，仅 ArchiveController.list 的副 keyword 过滤是 contains。但子项2(会议纪要无自动待办+跟踪+责任人)与子项3(科研信誉加分文件无专项标签)无法推翻，均确实缺失，故缺口成立。",
   "reEvidence": "1) 真索引(反证子项1措辞): /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/FullTextSearchService.java L110-118 建 FTS5 trigram 虚表 fts_index；L262-276 用 `fts_index MATCH ?` + `bm25(fts_index)` 排序 + `snippet(...)` 高亮；会议纪要也进了索引(L153-155)。前端 ofbiz-framework/plugins/modern-ui/app/src/oa/api/search.ts L38/67 与 oa/pages/archive/globalsearch.vue 走该引擎。contains 仅在 ArchiveController.java L84-86。2) 会议纪要无待办/责任人(证子项2): domain/MeetingMinute.java 仅 title/content/status/decisions(自由文本 TEXT)，无 owner/assignee/责任人/到期字段；web/MeetingMinuteController.java create/update 仅落库不生成任务；WorkflowService 的待办全是 FormInstance 审批流，与纪要无关；domain 下无 ActionItem/MinuteTask 实体；种子 DataSeeder.java L763 把\"行动项与责任人\"塞进 content 纯文本。3) 无科研信誉加分专项标签(证子项3): grep 科研信誉|信誉加分|科研诚信|诚信加分 全后端+前端零命中；ArchiveCategory.java 只有通用类别(项目/合同/知识产权档案等)，Archive.tags 为逗号分隔自由串无专项分类逻辑。"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "14. 工作交接与知识沉淀",
   "verdict": "PARTIAL",
   "gap": "交接清单缺系统账号/关键联系人/文件路径结构化字段与一键导出；大事记时间轴(关联文档)无任何实现。",
   "severity": "med",
   "evidence": "Handover.java 字段为 handoverPerson/receiver/dept/handoverType/items(单文本)/status/handoverDate，items 是单文本无常用系统账号/关键联系人/文件路径的结构化字段，HandoverController 无一键生成清单导出。大事记时间轴全库无实现(grep 大事记/chronicle/majorEvent/重大事件/时间轴 在 web/+domain/ 零命中；PolicyApplication 的 timelineJson 是申报内部状态时间线，非按时间轴记录项目获批/专利授权/标准发布的大事记)。初判成立。",
   "survives": true,
   "reNote": "缺口属实。我尽力寻找实现但两个子项都确认未实现。【子项1：交接清单结构化字段+一键导出】Handover 实体(oa-backend/.../domain/Handover.java)仅 7 个字段(handoverPerson/receiver/dept/handoverType/items/status/handoverDate)，其中\"交接事项\"是唯一的单一自由文本 textarea，无系统账号/关键联系人/文件路径任何结构化子字段；前端 handover.vue 创建表单(第19-27行)也仅此 textarea。HandoverController 与 handover.vue 均无任何导出端点/按钮(grep 确认\"NO export in handover.vue\")。【子项2：大事记时间轴(关联文档)】块14\"工作交接与知识沉淀\"在 kaidiDeptView.ts 中映射到 /knowledge/doccenter(文档中心)。doccenter.vue 确有 el-timeline 与 CSV 导出，但 timeline 是单文件的\"版本历史(版本号/上传人)\"，CSV 导出的是\"文档清单\"——均非\"大事记(按时间罗列重大事件并关联文档)\"。全后端 domain 无任何 chronicle/memorabilia/keyEvent/大事 字段(grep 返回空)。两点描述与代码完全吻合，PARTIAL 判定成立。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/Handover.java (仅 items 自由文本，无结构化字段); oa-backend/src/main/java/com/kaidi/oa/web/HandoverController.java (无导出端点); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/hr/handover.vue (表单第19-27行仅 items textarea，无导出按钮); ofbiz-framework/plugins/modern-ui/app/src/oa/api/governance.ts (Handover 接口字段=后端7字段); ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts (知识产权部 block[13]\"工作交接与知识沉淀\"→path=/knowledge/doccenter); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/knowledge/doccenter.vue (第626行 el-timeline 实为单文件版本历史，第295/509行 exportCsv 导出的是文档清单，均非大事记时间轴); 全 domain 目录 grep chronicle/keyEvent/大事 返回空"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "15. 查网与外部信息监控",
   "verdict": "LOGIC_GAP",
   "gap": "无定期查网任务调度提醒；查网内容无分类存档与共享 engine；与 CrawlJob 采集框架未打通。",
   "severity": "med",
   "evidence": "全库无 @Scheduled/cron 任何调度(grep @Scheduled/cron/每周一 在 web/+service/+config 零命中)，故无'每周一三五'定期查网任务提醒机制。查网内容无专门实体；MarketIntel 是市场部情报台账(区域/商机转化)，CrawlSource/CrawlJob 是招投标'公共资源交易中心'采集框架，二者均未与知识产权查网(政策/竞争对手/申报通知分类存档+共享)打通。初判成立。",
   "survives": true,
   "reNote": "gap confirmed",
   "reEvidence": "rd/ipmonitor.vue is a settingListStore mock"
  },
  {
   "area": "创新研发中心/知识产权部",
   "module": "16. 知识库与决策支持",
   "verdict": "PARTIAL",
   "gap": "竞争对手监控无 API 导入对手专利商标+技术分类对比+侵权/避空提示；内部知识库(无效宣告/侵权判决/布局策略)无专门存储与检索。",
   "severity": "med",
   "evidence": "IpInsightController.bi() 的高层看板(授权率按类型/法律状态分布/有效维持数/费用趋势/部门排名)+inventory+project-matrix 真实跨 IpAsset/RdProject/Declaration/IpFee/TechAchievement 五表聚合，BI 这条 MET 成立。但竞争对手监控无后端 API 导入与技术分类对比/侵权避空提示逻辑(全库无 competitor 导入实现，仅前端 ipmonitor 的 settingListStore 假数据)；内部知识库(无效宣告案例/侵权判决/布局策略文档按技术关键词检索)无专门存储与检索实体。初判成立。",
   "survives": true,
   "reNote": "competitor monitoring and the IP knowledge base are both unimplemented; only a manual CRUD list exists",
   "reEvidence": "ipmonitor is manual CRUD and no IP knowledge endpoint exists"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "1. 样品全流程管理",
   "verdict": "LOGIC_GAP",
   "gap": "条码/二维码/RFID 唯一标识与全程追溯完全缺失；样品生命周期只覆盖检测三态，缺领用/归还/处置轨迹与批量/扫码；留样管理(周期/复检提醒/货架位/到期提示)全缺，实体无相关字段。",
   "severity": "high",
   "evidence": "维持初判。LabSample 实体(domain/LabSample.java)字段仅 sampleNo/sampleName/sampleType/source/receiveDate/testItems/status/assignee/createdAt——无任何条码/二维码/RFID 字段，无留样字段(留样周期/复检提醒/冰箱货架位/到期处置)。全仓 grep barcode|qrcode|二维码|条码|rfid 仅命中 FraudReport/SewageEquipment，与实验室无关；grep 留样|retain 仅命中档案中心(Archive*)，无实验室留样实体。status 取值仅 待检/检测中/已出报告/复检(LabSampleController 注释+lab.ts SAMPLE_STATUSES 印证)，只在 TestTaskController.applySample/genReport 内随检测自动从 待检→检测中→已出报告 流转——缺 入库→领用→归还→处置(销毁/留样/退样)轨迹；无批量/移动端扫码端点。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。我从实体、控制器、仓库、前端页/API、全库 grep、活体接口五个维度彻查，均未找到任何相关实现。(1) 唯一标识/条码/二维码/RFID/追溯：全缺。LabSample 实体仅有 sampleNo(纯文本编号字符串)，无 barcode/qrCode/rfid 字段，无扫码接口、无追溯接口。全库 grep barcode|qrcode|rfid|二维码|条码|扫码|scan|trace 在 lab/sample 范围内零命中（命中的扫码/二维码/RFID 全部属于其他模块：SewageEquipment 设备二维码、AdminVisitor 门卫通行码、EhsHazard/Rectification scan-overdue、MonitorService scan、FraudReport 举报渠道，均与样品无关）。(2) 样品生命周期只覆盖检测态：LabSample.status 枚举写死为 待检/检测中/已出报告/复检（见 api/lab.ts:34 SAMPLE_STATUSES 与控制器注释），确为\"检测三态/四态\"，完全没有领用(borrow/领用)/归还(return/归还)/处置(dispose/disposal)的轨迹字段或操作接口——这些词在 archive(档案借阅)、mfg(物料领用) 模块有，但 lab 样品域零命中。无批量/扫码登记。TestTask.java:19 注释声称\"样品的收样→处置由 LabSample.status 承接\"，但 status 枚举里根本没有\"处置\"这个值，属注释与实现不符的空头声明。(3) 留样管理：全缺。不存在留样实体/控制器（grep 留样|retentionSample|sampleDisposal 零命中），LabSample 无留样周期、复检提醒、货架位(shelf/库位)、到期提示(expiry)任一字段。lab 域有 expiryDate 的是 Reagent(试剂耗材)而非样品留样，性质不同。lab/pages 目录仅 instruments/methods/reagents/reports/samples/tasks 六页，无留样页。活体接口 GET /lab-samples 返回 11 条，字段键与源码完全一致，运行时也无任何额外字段。三项指控逐条成立。",
   "reEvidence": "后端实体 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/LabSample.java（字段仅 id/sampleNo/sampleName/sampleType/source/receiveDate/testItems/status/assignee/createdAt，无任何条码/RFID/留样/领用归还处置字段）；控制器 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/LabSampleController.java（仅基础 CRUD，无扫码/追溯/留样/生命周期端点）；仓库 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/repository/LabSampleRepository.java（仅 findByStatus）；前端 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/api/lab.ts:33-34（SAMPLE_STATUSES=['待检','检测中','已出报告','复检']）与 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/lab/samples.vue（8 个普通列，无条码/货架位/到期/处置列）；全库 grep barcode|qrcode|rfid|二维码|条码|扫码|留样|retention|shelf|领用|归还|处置 在 lab/sample 域零命中；活体 GET /api/oa/lab-samples 返回字段键=['id','sampleNo','sampleName','sampleType','source','receiveDate','testItems','status','assignee','createdAt']，与源码一致，运行时无额外字段。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "2. 实验任务与检测流程",
   "verdict": "PARTIAL",
   "gap": "仪器接口自动采集(天平/色谱/光谱)无实现；关键结果值可经 PATCH 改写、无锁定；OOS/OOT 偏差转「偏差处理」后无调查→复检→放行审核闭环、仅置态；方法强制关联未硬校验(methodNo 可空)。",
   "severity": "med",
   "evidence": "维持初判。TestTaskController 有任务派发(create 可 relatedTo 关联研发项目/批次/委托)、方法库(TestMethodController 国标/行标/企标/SOP+sopFile)、结果录入(POST /{id}/record)、复核双人闭环(POST /{id}/review 校验复核人≠检测人)、出报告联动(POST /{id}/report 生成 TestReport 并推进样品态)。但:(a)数据采集仅手动 resultValue 字符串，grep 天平/色谱/光谱/自动采集 无仪器接口;(b)关键数据可改——record 后 PATCH /{id} 仍可直接覆写 resultValue(TestTaskController:147)，无录入即锁;(c)偏差仅置态:record 里 judge=OOS偏差时 setStatus(偏差处理)，之后无调查/复检/放行子流程;(d)方法未强制关联:applyMethod 容忍 methodNo 为 null，create/record 均不校验方法必填。",
   "survives": true,
   "reNote": "缺口属实。实验室「实验任务与检测流程」(后端 TestTaskController/LabInstrumentController/TestReportController/QmsRecordController) 四条子项逐一核实，全部成立：\n\n1) 仪器接口自动采集(天平/色谱/光谱)无实现：LabInstrumentController 纯手工 CRUD(name/model/assetNo/calibrationDate/status)，无串口/Modbus/socket/采集端点；「天平/色谱/光谱」仅出现在 DataSeeder 当静态种子名；TestTaskController.record() 要求人工传入 resultValue，无任何设备喂数通道。\n\n2) 关键结果值可经 PATCH 改写、无锁定：TestTaskController.update()(PATCH /{id}) L147-150 对 resultValue/judge 直接 setter 赋值，全程无状态守卫——即便任务已是「已复核」「已出报告」也能被静默改写。唯一的锁仅在 TestReport(L97「已签发」后 409)，那是另一实体，不保护底层 TestTask 原始结果。\n\n3) OOS 转「偏差处理」后无调查→复检→放行闭环、仅置态：record() 命中 OOS偏差时只 setStatus(\"偏差处理\")(L197)；与偏差实体 QmsRecord 无任何关联，QmsRecordController 是纯 CRUD + 自由文本 status(开放/整改中/已关闭)，无调查→复检→放行审核链，OOS 事件未接 WorkflowService/TriggerRuleEngine；「OOT」全库零命中(grep 命中皆为 Boot/root)。\n\n4) 方法强制关联未硬校验(methodNo 可空)：applyMethod()(L292) 显式容忍 methodNo==null||isBlank() 仅置空 methodName 返回；create() 只校验 detectItem(L99)，从不校验 methodNo——可零方法建任务并录结果。\n\n已尽力推翻但无法推翻：仅 TestReport 签发锁这一处部分覆盖「报告」层，不覆盖缺口所指的 TestTask 结果值层。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/TestTaskController.java(L96-126 create 仅校验 detectItem; L128-155 update PATCH 无锁直改 resultValue/judge; L179-199 record 仅置状态/手工传值; L292-302 applyMethod 容忍空 methodNo); oa-backend/src/main/java/com/kaidi/oa/web/LabInstrumentController.java(全文纯手工CRUD,无采集); oa-backend/src/main/java/com/kaidi/oa/web/QmsRecordController.java(纯CRUD,无调查→复检→放行链,无TestTask关联); oa-backend/src/main/java/com/kaidi/oa/web/TestReportController.java(L97/L120 仅报告层签发锁,非结果值锁); oa-backend/src/main/java/com/kaidi/oa/seed/DataSeeder.java(L2936/L2942 色谱/天平仅静态种子名)。grep 全库「OOT/串口/modbus/serial采集」对 lab/test 无实现命中。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "3. 设备与仪器管理",
   "verdict": "LOGIC_GAP",
   "gap": "无校准/维保到期自动推送、无证书/维保记录留档、无超期自动锁定预约；在线预约/扫码登记/利用率统计全缺；台账缺供应商/启用日期/校准周期(间隔)字段；维修未与实验仪器/费用/备件绑定。(注:nextCalibration 字段实际存在，初判该处措辞偏严)",
   "severity": "high",
   "evidence": "大体维持，修正一处证据偏差。LabInstrument 实体确有 calibrationDate/nextCalibration/location/manager/status(在用/维修/停用/待校准)——故初判「台账无校准周期字段」不准确(下次校准日字段存在)；但仍缺 supplier/启用日期/校准周期(间隔)字段。关键能力全缺:无 @Scheduled 校准到期推送(grep @Scheduled×lab/calib/instrument 零命中)；无校准证书/维保记录留档实体；无超期未校准自动锁定预约(status 由请求体手填，无派生锁定)；无在线预约/时长、扫码登记用时/运行状况/耗材更换、利用率统计(grep reservation/预约/利用率 在 lab 域零命中)；WorkOrder 维修未与 LabInstrument/费用/备件绑定。",
   "survives": true,
   "reNote": "缺口基本属实，仅其中一条子项(校准到期推送)措辞偏严应予纠正，但绝大多数子项确实未实现。我尽力反驳后的结论：\n\n可部分反驳的1项：「无校准到期自动推送」不成立——AlertController.aggregate() 第150-173行确实遍历全部 LabInstrument，依据 nextCalibration 计算并产出「仪器校准」预警(过期/待校准为 danger，30天内为 warning，停用/维修排除)，且 AlertScheduler.pushAlerts() 以 @Scheduled(fixedRate=3600000) 每小时重算推送到统一预警中心。故校准到期确有自动推送(note 自己也已提示此处偏严)。\n\n无法反驳、确实缺失的子项(缺口主体成立)：\n1) 维保到期自动推送：LabInstrument 无维保/保修日期字段，预警源里只有校准、无维保——缺失。\n2) 证书/维保记录留档：LabInstrument 无证书/附件/维修记录字段，也无关联实体；RdMaintenanceTask 是资质/项目年报复审任务(申报服务部)，与仪器无关，不能算留档——缺失。\n3) 超期自动锁定预约：全后端/前端无 reservation/booking 任何实体或端点，无预约可锁——缺失。\n4) 在线预约/扫码登记/利用率统计：后端与 lab 前端 grep 预约/booking/reservation/扫码/qr/利用率/utilization 全部零命中——全缺。\n5) 台账缺字段：LabInstrument 仅 name/model/assetNo/calibrationDate/nextCalibration/status/location/manager/createdAt，确无 供应商/启用(购置)日期/校准周期(间隔)——确认缺失。\n6) 维修未与实验仪器/费用/备件绑定：WorkOrder 不引用 instrument，无任何把 仪器+维修费用+备件 绑定的修理实体(TestTask.instrumentId 只是检测执行单关联仪器，非维修)——确认缺失。\n\n结论：判定 LOGIC_GAP 成立(real=true)。仅建议把描述中「无校准到期自动推送」改为「无维保到期自动推送(校准到期已有预警推送)」以更精确，但这不改变缺口整体属实。",
   "reEvidence": "后端 LabInstrument 实体(oa-backend/src/main/java/com/kaidi/oa/domain/LabInstrument.java) 仅含 id/name/model/assetNo/calibrationDate/nextCalibration/status/location/manager/createdAt，无 supplier/启用日期/校准周期/证书/维保/附件字段。控制器(web/LabInstrumentController.java) 仅 list/get/create/update/delete 纯 CRUD，无预约/扫码/利用率/锁定逻辑。校准推送实存：web/AlertController.java 第150-173行产出「仪器校准」预警，task/AlertScheduler.java 第72-80行每小时 @Scheduled 重算。维修无绑定：grep WorkOrderController/WorkOrder 对 instrument 零命中；reservation/booking/usage/util 实体与端点全后端零命中。RdMaintenanceTask(domain/RdMaintenanceTask.java) 为资质年报复审任务、与仪器无关。前端 oa/pages/lab/instruments.vue 仅复用 MasterDataPage 做台账 CRUD，列与字段同后端，无预约/扫码/利用率；grep 预约/扫码/qr/利用率在 lab 前端目录零命中。TestTask.instrumentId(domain/TestTask.java:50) 仅检测任务关联仪器，非维修绑定。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "4. 试剂耗材与库存管理",
   "verdict": "PARTIAL",
   "gap": "危险品双人双锁/领用审批/使用余量登记/废弃处置记录未实现(仅普通出库)；库存盘点(周期/扫码/盘盈盘亏报表)全缺；领用关联实验任务仅传字符串，无强校验与回链。",
   "severity": "med",
   "evidence": "维持初判。ReagentController 有档案 CRUD(category 危险化学品/标准品/常规试剂/耗材、casNo、spec、batchNo、expiryDate、storageCondition、supplier、sdsFile)、入库(/inbound)、领用出库扣减并不足报409(/outbound)、低库存+过期预警(/alerts 含临期/逾期/缺货分级)。但 outbound 仅普通扣减:无危险品双人双锁、无领用审批流、无使用余量登记、无废弃处置记录；无库存盘点(周期/移动端扫码/盘盈盘亏报表)端点；领用 relatedTask 为自由字符串(StockMoveRequest.relatedTask)，不校验、不回链 TestTask。",
   "survives": true,
   "reNote": "缺口属实。实验室「试剂耗材与库存管理」后端 ReagentController 全部端点仅为：list/get/create/update/delete + inbound(入库) + outbound(领用出库) + alerts(低库存/过期预警)，无任何更深机制。逐项核对均未实现：(1) 危险品双人双锁——Reagent 实体只有 category 文本(可填\"危险化学品\")和 sdsFile 链接，无双人/双锁字段、无锁状态机、无双人复核逻辑；(2) 领用审批——outbound 直接扣减 stockQty，无审批闸、无审批实体、无状态流转，是纯减法；(3) 使用余量登记——除就地 stockQty 外无任何余量字段、无逐次领用明细记录；(4) 废弃处置记录——无处置端点/实体(HazWasteManifest 属 EHS 危废、LabSample 属样品处置，均非试剂处置)；(5) 库存盘点(周期/扫码/盘盈盘亏报表)——全缺，无盘点控制器/域/扫码/差异报表，唯一 AdminStockMove 属行政后勤领料非实验室试剂；(6) 领用关联实验任务仅传字符串、无强校验与回链——完全坐实：relatedTask 字段全后端仅出现在 StockMoveRequest record 声明(第132行)一处，outbound 方法既不读取也不校验(无 TestTask 比对)、不持久化、不回链，连出库动作本身都不落事务流水(stockQty 就地改写，operator 也未存)。判定 PARTIAL 准确。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa/web/ReagentController.java(端点仅 8 个，line 132 StockMoveRequest 含 relatedTask，line 151-167 outbound 仅扣减不用 relatedTask)；domain/Reagent.java(无双人/双锁/余量/处置/盘点字段)；repository/ReagentRepository.java(仅 findByStatus/findByCategory)。grep 全后端 relatedTask 仅命中 ReagentController.java:132 一处。web/ 目录无 stocktake/count/盘点/disposal 控制器(AdminStockMove 属行政后勤)。前端 ofbiz-framework/plugins/modern-ui/app/src/oa/api/lab.ts(line 132-151 试剂 API 仅 list/create/update/delete/inbound/outbound/alerts)，oa/pages/lab/reagents.vue(领用对话框 relatedTask 为可选纯文本输入，无任务下拉/校验，无盘点/审批/处置/双锁 UI)。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "5. 报告与数据输出",
   "verdict": "PARTIAL",
   "gap": "附件(谱图/照片/原始记录)按项目/样品归档+全文检索未实现；保存期限合规无机制；对外数据导出无实际接口或取数链路(仅注释声明)；审批仍单点 sign，非 WorkflowService 多级。(注:报告结构化体与签发锁定实际已实现，初判该两处偏严)",
   "severity": "med",
   "evidence": "维持 PARTIAL 但修正两处子断言。TestReport 实为结构化:含 sampleId/sampleNo/sampleName(applySample 自样品冗余)+detectItem+methodNo+conclusion+tester/reviewer/signer+template——故初判「报告未含完整样品信息+检测项目+方法+结果结构化体」不成立。签发 POST /{id}/sign 记签名人/签发日，置「已签发」并锁定(后续 PATCH/DELETE 一律409)，签发即锁定已实现。但仍缺:附件(谱图/照片/原始记录)按项目/样品归档+全文检索(grep 附件/谱图/全文 零命中)；保存期限合规无机制；对外数据导出无 export 端点(grep export/导出 零命中)，仅注释声明；审批仍单点 sign，非走 WorkflowService 检测人→复核人→批准人多级。",
   "survives": true,
   "reNote": "缺口属实(且初判注释正确)。我尽力推翻但四条子主张均站得住：(1)附件归档+全文检索——TestReport/LabSample 实体均无任何附件/谱图/照片/原始记录字段(fileId/attachment 全无)，StoredFile 实体只有 name/contentType/size/data/uploader，没有 bizType/refType/module 这类多态外键无法挂到报告或样品；FullTextSearchService.reindexAll() 只索引 11 类(事项FormInstance/公告/讨论/调查/纪要/合同/供应商/客户/公司/文档DocFile/协作文档CollabDoc)，完全不含 TestReport/LabSample，按项目/样品全文检索附件不存在。(2)保存期限合规——retention/保存期限 机制只在 ArchiveSubmission.retentionDueDate(档案中心)里有，实验室报告/样品域零保存期限字段与到期逻辑。(3)对外数据导出——TestReportController 无任何 produces/ResponseEntity/byte[]/CSV/Excel/download 流式导出端点；活体探测 /api/oa/test-reports/1/export 返回 404、无专用 Export/DataOutput 控制器；RdProject/Patent/Declaration/DataCenter 控制器均不引用 TestReportRepository，所谓\"供研发/知识产权/申报取用\"仅是 Controller/实体 Javadoc 注释声明(§5 数据输出)，无实际取数链路。(4)审批——签发仅 POST /{id}/sign 单点电子签名置\"已签发\"，不经 WorkflowService/FormInstance 多级流转，TestReportController 完全不 import WorkflowService。初判注释亦正确：报告结构化体(reportNo/conclusion/template/tester/reviewer/signer 等完整字段)与签发锁定(issueStatus=已签发后 update/delete/void 均 409)确已实现，故 PARTIAL 判定准确。",
   "reEvidence": "web/TestReportController.java(无 export/WorkflowService/attachment，仅单点 sign 第136行)；domain/TestReport.java(字段无 attachment/fileId/retention)；domain/LabSample.java(无附件/保存期限字段)；domain/StoredFile.java(第25-51行仅 name/contentType/size/data/uploader，无 bizType/refType 多态外键)；service/FullTextSearchService.java(第133-188行 reindexAll 只索引 FormInstance/Announcement/Discussion/Survey/MeetingMinute/Contract/Supplier/Customer/CompanySubject/DocFile/CollabDoc 共11类，无 TestReport/LabSample)；活体 GET /api/oa/test-reports/1/export=404、无 Export/DataOutput 控制器；RdProject/Patent/Declaration/DataCenter 控制器均未引用 TestReportRepository。retention 机制仅见 domain/ArchiveSubmission.java:85 retentionDueDate(档案中心，非实验室)。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "6. 质量管理与合规",
   "verdict": "PARTIAL",
   "gap": "ELN 电子实验记录本(含修改历史版本)完全缺失、无实体；核心原始值不可删除未强制；电子签名未达 21 CFR Part 11(无数字证书/手写板、签名未绑定数据哈希)；内部审核自动抽取+审核报告无实现。(已建并翻案:统一操作审计——全局拦截器自动记录写操作 操作人/时间/IP/动作+不可篡改哈希链+链校验端点)",
   "severity": "high",
   "evidence": "部分翻案:审计追踪子项被推翻。初判称「审计追踪未自动挂接——OperationAuditLog 仅由自身控制器写」实测错误:config/AuditLogInterceptor 经 CorsConfig.addInterceptors 全局注册到 /api/oa/**，对一切 POST/PUT/PATCH/DELETE 在 afterCompletion 自动落 OperationAuditLog(operator/operatorId/operatorRole、occurredAt、method/path/resourceType/resourceId、statusCode、clientIp)，续 SHA256 哈希链(prevHash→hash，含 /chain/verify 校验端点)，连被授权拒绝(401/403)的越权写也留痕。活体已验证:POST /api/oa/lab-samples 后 /operation-audit-logs 立刻出现 operator=系统管理员/operatorId=1/role=ADMIN/method=POST/status=200/ip=127.0.0.1+完整哈希。但其余子项仍缺:ELN(目的/步骤/原始数据/计算/结论+修改历史版本)无实体(grep eln/实验记录本 零命中)；核心原始值不可删除未强制(TestTask resultValue 可改/任务可删)；电子签名仅 signer 字符串+置态，未达 21 CFR Part 11(无手写板/数字证书、签名未绑定数据哈希)；内部审核按比例自动抽取+生成审核报告无实现。",
   "survives": true,
   "reNote": "尽力推翻失败，缺口属实(PARTIAL 判定成立)。实验室确实建了检测全流程(LabSample/TestMethod/Reagent/TestTask/TestReport)，但缺口点名的四个合规内核全部缺失:\n\n1) ELN电子实验记录本(含修改历史版本)——完全无实体/控制器/仓储/前端。全库 grep Eln/Notebook/Experiment 零命中;最接近的 TestTask 把 resultValue 存成单个可改字段，无任何 version/history 表(其它模块如 CollabDoc 有 versionsJson、WorkMethod 有 version 字段，唯独实验数据没有)。\n\n2) 原始值不可删除/不可改未强制——TestTaskController.record()(第191行 t.setResultValue)与 PATCH update()(第147行)都就地覆盖 resultValue，无不可变闸、无改前快照、无\"已复核即锁值\"。原始检测值在出报告前可被静默改写且无改动留痕。\n\n3) 电子签名未达 21 CFR Part 11——TestReport.sign() 与 ContractEsign.sign() 都只存明文 signer 姓名字符串+日期;无 signatureHash/dataHash/certThumbprint/手写板字段(全 domain grep 零命中)，签名未绑定数据哈希、无数字证书、无手写采集。ContractEsign 流水号是本地占位 ESIGN-{eid}-{millis}。\n\n4) 内部审核自动抽取+审核报告无实现——QmsRecord(内部审核)是扁平手工 CRUD(type/title/finding/status);AuditDashboardController 自注\"无独立实体\"，无抽取/报告生成逻辑。\n\n翻案项(统一操作审计 OperationAuditLog+AuditLogInterceptor+哈希链+/chain/verify)确实已建且真实，但它只是通用 HTTP 写操作留痕，不提供 ELN 版本、原始值不可变或 Part 11 签名，无法替代上述四点，故缺口不被推翻。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa:\n- web/TestTaskController.java:179-199(record 就地覆盖 resultValue 无不可变)、128-155(PATCH 同样可改)\n- web/TestReportController.java:129-155(sign 仅存明文 signer+date，无 hash/cert)\n- domain/TestReport.java:55-69(字段仅 tester/reviewer/signer/signDate，无 signatureHash/dataHash)\n- domain/TestTask.java:68(resultValue 单字段，无 version/history)\n- web/EsignController.java:96-117 + domain/ContractEsign.java(serialNo 本地占位，无数据哈希绑定)\n- web/QmsRecordController.java(内部审核纯手工 CRUD，无抽取)\n- web/AuditDashboardController.java:26(自注\"无独立实体\")\n- 翻案对照(已实现):domain/OperationAuditLog.java + config/AuditLogInterceptor.java + web/OperationAuditLogController.java:120-147(/chain/verify 哈希链校验)\n- grep 全证伪:domain/ web/ repository/ 内 Eln|Notebook|Experiment|signatureHash|dataHash|certThumbprint|手写|digitalCert 全部零命中;repository/ 无 eln/version/history/revision 仓储\n前端 ofbiz-framework/plugins/modern-ui/app/src/oa:\n- pages/lab/ 仅 instruments/methods/reagents/reports/samples/tasks.vue，无任何 ELN 页\n- api/lab.ts 仅 lab-samples/lab-instruments/test-methods/reagents/test-tasks/test-reports，无 ELN 端点"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "7. 预算与成本核算",
   "verdict": "LOGIC_GAP",
   "gap": "实验室专属成本归集(耗材单价×数量/设备按时费率/人工工时×成本率/委外测试费)全缺；预算控制(部门/项目/单次实验超预算预警或冻结)未覆盖 lab；成本报表未按检测委托单/时间段出实验成本分析。",
   "severity": "med",
   "evidence": "维持初判。全仓 grep labCost|实验成本|检测委托|usageFee|设备使用费 在 lab 域零命中；TestTask/TestReport/Reagent 均无成本字段或成本归集逻辑。试剂 outbound 仅扣数量、不计单价×数量金额；仪器无按时费率使用费；无人工工时×成本率；无委外测试费归集进检测委托单。预算控制命中的均为 LogisticsBudget/MarketBudget/Budget 其它域，对 TestTask/检测委托单无任何预算冻结或超预算预警。无按检测委托单/时间段出实验成本分析报表端点。",
   "survives": true,
   "reNote": "缺口属实。实验室(lab/§2.3)是一个功能完整的运营模块（检测样品 LabSample、仪器设备 LabInstrument、检测任务 TestTask、检测方法库 TestMethod、试剂耗材 Reagent、检测报告 TestReport，前端 6 个页面 + 全套 CRUD/状态机/出入库/预警），但完全没有任何成本核算与预算控制能力，描述的四大缺口逐项核实均不存在实现：(1) 实验室专属成本归集——LabSample/LabInstrument/TestTask 四个域实体均无任何单价/数量×单价/时费率/工时/成本率/委外测试费字段；Reagent 出入库注释明确写“库存量为数量（非金额），用 double 承接”，只扣数量不计金额，无耗材单价。(2) 预算控制（部门/项目/单次实验超预算预警或冻结）未覆盖 lab——统一 Budget 实体只有 projectId/companySubject/element 维度，无实验室/检测委托单关联，BudgetController/ProjectCostControlController/CostCenterController 全文 grep 无任何 lab/实验室/检测引用。(3) 成本报表未按检测委托单/时间段出实验成本分析——全仓 grep“成本分析/cost-analysis/按委托单”仅命中 FinancingController（融资，与 lab 无关）与 AuthInterceptor，无 lab 成本报表。工时×费率的成本归集仅存在于 ProductionReport（制造）、CslTimesheet（设计）、StandardCost（标准成本）等其他域，未复用到 lab。结论 real=true。",
   "reEvidence": "代码侧：oa-backend/src/main/java/com/kaidi/oa/domain/LabSample.java(无成本字段) / LabInstrument.java(无时费率字段) / TestTask.java(字段仅 tester/result/judge/reviewer，无 hours/rate/cost/fee) / Reagent + web/ReagentController.java(注释“库存量为数量（非金额）”，inbound/outbound 仅增减数量不计金额) / domain/Budget.java(维度仅 projectId/companySubject/element，无 lab 关联)。grep 全后端“实验室成本/lab cost/检测委托.*成本/实验室.*预算”零命中；“成本分析/cost-analysis/按委托单”仅命中 FinancingController 与 AuthInterceptor(均非 lab)。前端：ofbiz-framework/plugins/modern-ui/app/src/oa/api/lab.ts(LabSample/TestTask/Reagent 接口均无金额/成本字段) 与 data/oaModules.ts:502-513(lab 子菜单为 检测样品/仪器设备/实验检测任务/检测方法库/试剂耗材/检测报告，无成本或预算页)。活体(127.0.0.1:8091, admin token)：GET /api/oa/lab-cost、lab-costs、lab/cost、lab-budget、cost-analysis/lab 均 404；test-tasks/cost、lab-samples/cost、reagents/cost 为 400(路径变量误解析，非真实成本端点)。"
  },
  {
   "area": "创新研发中心/实验室",
   "module": "8. 安全与环境（EHS）",
   "verdict": "LOGIC_GAP",
   "gap": "危废联单属运营管理中心域、未接入实验室废弃物(生物废物分类/暂存位/环保台账对接)；化学品领用无 SDS 阅读确认门；安全巡检未项化到实验室专项(灭火器/洗眼器/通风橱)、无巡检计划生成；微小事故借通用 EHS、无实验室事故专表与上报入口。",
   "severity": "med",
   "evidence": "维持初判。危废联单 HazWasteManifestController 类注释明确归属「运营管理中心·工业废水运营」，按 产生→暂存→转移→处置 流转、未接入实验室废弃物(生物废物分类/暂存位/对接环保台账)。化学品领用 ReagentController.outbound 无 SDS 阅读确认门(虽有 sdsFile 字段存档，但出库不要求确认已阅读)。安全巡检 SafetyCheckController 为通用 安全/质量/环境 巡检，未项化到实验室专项(灭火器/洗眼器/通风橱)，无巡检计划自动生成。事故 EhsIncidentController/SafetyCheck 为通用质安部事故/隐患整改闭环，无实验室微小事故(化学品泄漏/灼伤)专表与上报入口。",
   "survives": true,
   "reNote": "尽力推翻但无法推翻——缺口四个子项全部属实。后端确有 EHS 与试剂相关控制器，但均为通用/运营域，未项化到实验室专项：\n\n(1) 危废联单确属运营管理中心域。HazWasteManifestController 类注释明写\"运营管理中心·工业废水运营，需求 §6 危废全流程电子联单 + 污泥外运/处置费用\"，wasteType 为自由文本（HW17 等工业危废码示例），无生物废物分类枚举；store 步登记的 storageLocation 是通用暂存库位、非实验室专项暂存位；sync-epb 环保台账对接也是运营口径。实验室前端模块仅 instruments/methods/reagents/reports/samples/tasks 六页，无任何废弃物页面，未接入。\n\n(2) 化学品领用无 SDS 阅读确认门。Reagent.sdsFile 仅是一个存储链接字段；ReagentController.outbound(领用) 只做库存扣减+不足 409，全代码库 grep 不到 sdsRead/sdsConfirm/sdsAck/阅读确认 任何确认门逻辑或字段。\n\n(3) 安全巡检未项化到实验室专项、无巡检计划生成。SafetyCheck 实体只有通用 type(安全/质量/环境) 与自由文本 item，无灭火器/洗眼器/通风橱等实验室专项项化，无 checklist 模板；全库 grep 不到巡检计划/inspectionPlan/generatePlan/周期巡检 生成逻辑（仅 ServiceTicket 把\"定期巡检\"当作无关的服务类型标签）。\n\n(4) 微小事故借通用 EHS、无实验室事故专表与上报入口。EhsIncidentController 是通用\"质安部·事故与事件管理\"，incidentType 自由文本，无实验室事故专表，无 lab 域上报入口；实验室前端无事故页。\n\n四个子项均找不到对应实现，缺口成立 real=true。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/HazWasteManifestController.java:25-33(类注释定域\"运营管理中心·工业废水运营\"),59(wasteType自由文本),119-131(store通用库位);\noa-backend/src/main/java/com/kaidi/oa/domain/HazWasteManifest.java:38(wasteType无生物分类),53-54(storageLocation通用);\noa-backend/src/main/java/com/kaidi/oa/web/ReagentController.java:151-167(outbound领用仅扣库存无SDS门);\noa-backend/src/main/java/com/kaidi/oa/domain/Reagent.java:64-65(sdsFile仅链接字段);\noa-backend/src/main/java/com/kaidi/oa/web/SafetyCheckController.java:56-59(item自由文本无项化),全文无计划生成;\noa-backend/src/main/java/com/kaidi/oa/domain/SafetyCheck.java:33(item单一自由文本字段);\noa-backend/src/main/java/com/kaidi/oa/web/EhsIncidentController.java:36-38,68-71(通用事故表,无lab专表/入口);\n前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/lab/ 仅 instruments/methods/reagents/reports/samples/tasks 六页,无废弃物/巡检/事故页;\ngrep 全库无 灭火器/洗眼器/通风橱/生物废物/SDS阅读确认/巡检计划/inspectionPlan 任何命中(ServiceTicket 的\"定期巡检\"为无关服务类型标签)。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "1. 项目全生命周期管理",
   "verdict": "PARTIAL",
   "gap": "结项后归档/知识沉淀仅注释无联动；项目无独立档案库自动归集全过程文档；甘特图为前端渲染。状态机/逾期预警/优先级评分为真。",
   "severity": "med",
   "evidence": "CslProjectController.accept() (line 219-246) 验收通过仅 setStage(\"已结项\")+setProgress(100)，注释『自动触发归档/知识沉淀（业务语义）』(line 221) 无任何落库联动——无写入 Archive、无知识库调用。CslProject 实体(全字段已读)无 document/attach/archiveId 字段，无 csl 文档与立项件/成果/评审意见的自动归集。grep 全局确认 ArchiveController/Archive 实体无 csl 引用、TriggerRuleEngine 无 csl.* 规则。生命周期状态机(商机→立项审批→执行→结项验收→已结项)、按类型匹配审批流程名、WBS逾期预警 (overdueAlerts) 确为真实实现。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口三点全部属实。(1) 结项后归档/知识沉淀仅注释无联动：CslProjectController.accept()（第223-246行）验收通过仅 setStage(\"已结项\")+setProgress(100)，第221行 Javadoc 写\"自动触发归档/知识沉淀（业务语义）\"但无任何 Archive/ArchiveSubmission/ItKnowledgeArticle/CultureCase/AutomationLog 落库；该控制器构造器（第50-58行）根本未注入任何档案/知识仓库；全仓 grep \"知识沉淀\" 仅命中此注释。DesignProjectService.advance()（第76-92行）推进到\"已完成\"同样不建档案，DesignProjectController 也未注入 ArchiveRepository。对比之下工程项目 ProjectController.chainArchiveProject()（第355-376行）才是真联动（建 Archive+留痕），设计/咨询域恰恰缺这套。(2) 无独立档案库自动归集全过程文档：DesignDocController 只是手工文档登记台账（\"已归档\"仅一个枚举状态值，非自动归集），全后端无\"档案归集/项目档案库\"自动归集逻辑。(3) 甘特图为前端渲染：唯一甘特实现在 goal/project.vue（第160-414行）的 ganttRows computed + CSS gp-gantt__bar 纯前端绘制，无后端甘特模型/端点；design/wbs.vue 根本无甘特，只是普通表格。缺口同时承认\"为真\"的状态机/逾期预警/优先级评分确已实现，核对无误。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/CslProjectController.java:221-246 (accept 仅置 stage/progress，注释称自动归档但无落库); CslProjectController.java:50-58 (构造器未注入任何档案/知识仓库); oa-backend/src/main/java/com/kaidi/oa/service/DesignProjectService.java:76-92 (advance 到\"已完成\"无归档联动); oa-backend/src/main/java/com/kaidi/oa/web/DesignProjectController.java:47-55 (未注入 ArchiveRepository); 对照 oa-backend/src/main/java/com/kaidi/oa/web/ProjectController.java:355-376 (chainArchiveProject 真建 Archive+AutomationLog，仅工程项目域有); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/goal/project.vue:160-414 (ganttRows computed + gp-gantt__bar 纯前端渲染); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/wbs.vue (无甘特，纯表格); grep \"知识沉淀\" 全仓仅命中 CslProjectController.java:221 注释。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "2. 咨询报告编制管理",
   "verdict": "PARTIAL",
   "gap": "无结构化章节/框架模板与强制维度填写；多人协同/批注靠通用 CollabDoc 非内嵌；无评审格式导出端点。审核流/估算联动为真。",
   "severity": "med",
   "evidence": "CslReport 实体(已读全字段)仅 title/reportType/editor/reviewer/auditor/approver/reviewStage/version/locked/estimateTotal/summary/esign——无 section/chapter 实体，grep 'section|chapter|章节' 在 web/Csl*+domain/Csl* 零命中。无标准化模板/强制维度(技术可行性/市场分析/投资估算/风险评估)填写机制。create()/update() 只存 summary 单字段。无导出符合评审格式的端点。多级审核(编制→复核→审核→批准→签发锁定)+CslReportReview 留痕+投资估算明细价格库联动(addEstimate priceItemId 取 PriceItem 基准价) 确为真实实现。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但三条子主张均成立。咨询报告编制模块的承载是 CslReport + CslReportReview + CslEstimateItem，后端控制器 CslReportController 端点全集为：CRUD、submit/reject/sign(四级审核状态机)、/reviews、/estimates(价格库联动)。其中审核流(编制→复核→审核→批准→签发锁定，版本+1，电子签名留痕)与估算联动(priceItemId 取人材机基准价 + 自动回算 estimateTotal)确为真，与缺口\"审核流/估算联动为真\"一致。但三条缺陷逐一验证为真：(1)无结构化章节/框架模板与强制维度填写——报告正文仅一个自由文本字段 summary(前端\"编制说明\"3行 textarea)，全后端无 CslSection/CslChapter/ReportSection 实体或仓库，无章节/大纲/框架模板，无任何强制维度校验，create 仅校验 title 非空；(2)多人协同/批注非内嵌——唯一\"协同\"是 CslReportReview 的审核动作级 comment(提交/退回/签发时附意见)，并非章节级共同编辑或正文内嵌行内批注，domain/控制器内\"在线协同编制\"仅为 javadoc 口号；(3)无评审格式导出端点——CslReportController 及全后端无任何 export/print/download/pdf/docx 映射(grep csl-report×export/print/pdf/docx 退出码1，无全局 export 控制器)。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa/domain/CslReport.java(正文仅 String summary，L58-59)；web/CslReportController.java(端点全集见 L71-286，无 export；create 仅 title 非空校验 L95-97)；domain/CslReportReview.java(comment 为审核动作级批注 L37-38)。前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/reports.vue(L243 编制说明 textarea；无章节/模板/导出按钮)。grep 确认：domain/repository 下仅 CslReport/CslReportReview/CslEstimateItem/CslProject/CslTask/CslTimesheet，无 Section/Chapter 实体；grep -rniE \"csl-report.*(export|print|pdf|docx)\" 退出码1，web/ 下无 export 控制器。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "3. 专家库与人力资源协同",
   "verdict": "PARTIAL",
   "gap": "专家档案字段缺(年限/评审经历)、无多维检索；无团队组建/智能推荐/负载调配；无产值分配/绩效积分；专家评审抽取/邀请/打分全缺。",
   "severity": "high",
   "evidence": "Expert 实体(已读)仅 name/field/org/title/expertType/phone/status——无从业年限/评审经历/经验等级字段。ExpertController(已读)仅 list/get/create，list 只按 expertType 单维过滤，无按专业领域/地区/经验等级多维检索。grep '抽取|随机|评审邀请|invite|random|draw' 在 Expert/Csl 零命中——无从专家库抽取评审专家、无在线评审邀请、无打分记录(CslReportReview 是报告内部四级审核非专家库抽取)。grep '推荐|负载|recommend|load' 零命中——无团队组建/智能推荐/负载调配。产值/绩效仅 CslTimesheet 注释文字，无产值分配规则配置与自动计算、无积分制评估。工时人工成本归集(CslTimesheet laborCost=hours×rate)为真。",
   "survives": true,
   "reNote": "尽力推翻后仍无法推翻，缺口属实(PARTIAL 判定准确)。逐条核验[设计研究中心/咨询可研院]链[3.专家库与人力资源协同]：\n\n1) 专家档案字段缺(年限/评审经历)——属实。domain/Expert.java 仅 8 个字段(id/name/field/org/title/expertType/phone/status/createdAt)，无从业年限、无评审经历/履历，前端 rd/experts.vue 的 createFields 也只这几项。\n\n2) 无多维检索——属实。ExpertRepository.java 只有 findByExpertType 一个查询方法；ExpertController list 仅支持 expertType 过滤；前端 experts.vue 用 MasterDataPage 的 search-keys 做客户端关键字模糊筛(name/field/org/expertType)，无服务端多维/分面检索。\n\n3) 无团队组建/智能推荐/负载调配——属实。全仓 grep 未见任何 expert 团队组建、智能推荐、负载/资源调配 的端点/实体/页面。\n\n4) 无产值分配/绩效积分——基本属实(此项是唯一有边缘覆盖处，但仍不成立)。存在 CslTimesheet(工时×单价=人工成本，按人/角色归集)与前端 /design/resource「设计资源与绩效管理」，但这是工时人工成本归集，并非\"产值分配规则引擎\"，也无\"绩效积分\"体系；CslTimesheet.role 注释虽称\"用于产值分配规则\"，但代码里并无分配规则实现，且该模块挂在 规划设计部，不属本链(咨询可研院)的专家库。\n\n5) 专家评审抽取/邀请/打分全缺——属实。无从专家库抽取/邀请/打分的逻辑。CslReportReview 确有 score 字段，但那是咨询报告内部四级审核链(编制→复核→审核→批准)的留痕，与 Expert 专家库无任何关联，不构成\"专家评审抽取/邀请/打分\"。\n\n结论：该链对应导航块「专家库与人力资源协同」(kaidiDeptView.ts 中明确标注，built，path=/rd/experts)实质只是一个最小化专家主数据列表，描述中列举的高级能力全部缺失，PARTIAL 判定准确。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/Expert.java(仅name/field/org/title/expertType/phone/status，无年限/评审经历); oa-backend/.../repository/ExpertRepository.java(仅 findByExpertType); oa-backend/.../web/ExpertController.java(list 仅 expertType 过滤，无抽取/邀请/推荐/团队). 前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/experts.vue(MasterDataPage 客户端关键字检索); src/oa/api/governance.ts:73-78(listExperts/createExpert 仅 /experts). 映射: src/data/kaidiDeptView.ts 咨询可研院「专家库与人力资源协同」->/rd/experts(专家库). 边缘相关(不成立的反证): oa-backend/.../web/CslTimesheetController.java + domain/CslTimesheet.java(工时人工成本归集，非产值分配/绩效积分，且挂规划设计部 /design/resource); oa-backend/.../web/CslReportController.java + domain/CslReportReview.java(score 字段属报告四级审核链，与专家库无关). 全仓 grep 团队组建/智能推荐/负载调配/专家抽取/专家邀请/绩效积分 均无命中。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "4. 知识管理与成果沉淀",
   "verdict": "PARTIAL",
   "gap": "自动归档无联动、双维度标签未结构化、AI知识图谱/语义匹配/关联推荐缺失、外部库接入缺失、通用多版本/分权缺失。",
   "severity": "med",
   "evidence": "结项自动归档至知识库无联动(同模块1，ArchiveController/TriggerRuleEngine 无 csl)。Document 实体 grep 'tag|主题|属性|topic' 零命中——无『主题+属性』双维度结构化标签字段。knowledge/map.vue 存在但为前端静态概览(无后端图谱实体/语义匹配/关联推荐端点)。无国标库/白皮书/政策法规库接入实现。多版本并存仅 CslReport.version(报告内退回递增)，无 Document 通用版本机制与公共库/项目库分权。",
   "survives": true,
   "reNote": "尽力推翻失败，缺口属实(PARTIAL)。设计研究中心「知识管理与成果沉淀」链确有基础归档能力，但缺口描述的 5 个高阶点全部确认缺失/未达标：\n\n1) 自动归档无联动——属实。自动归档触发器只对【项目】验收存在(TriggerRuleEngine.java:355 chainArchiveProject / ruleKey \"project.toArchive\")；设计交付物(DesignDoc/设计变更)无任何 archive 联动，DesignDocController、DesignChangeOrderController 从不写 ArchiveRepository。资料室 ArchiveSubmissionController.approve 是「人工在线提交→审核通过才落档」的手工流程(:136-181)，不是交付物办结驱动的自动归档。\n\n2) 双维度标签未结构化——属实。Archive.tags 是单一逗号分隔字符串(Archive.java:46，且 approve 时实际拿来存档案编号而非标签 :166)；libmgr.vue「分类标签」是落到 settings 的扁平单维列表；map.vue tagCloud 是硬编码静态数组。无第二维度、无结构化标签实体。\n\n3) AI知识图谱/语义匹配/关联推荐缺失——属实。后端 grep knowledgeGraph/图谱/语义匹配/semanticMatch/关联推荐/cosineSimilarity/embedding 零命中。knowledge/map.vue「知识地图」只是静态主题树(mapTree 写死 4 类)+硬编码标签云+mock 生成的 docRows，无图谱边、无语义、无推荐引擎。\n\n4) 外部库接入缺失——属实。rss.vue 订阅源 URL 全是硬编码 feed.example.com，文章来自 mock.ts，只把 feeds[] 存进 settings KV，从不真实抓取。CrawlJob/CrawlSource 属于统一情报中心(政府采购/招标情报)，且抓取数为模拟比例(screened≈60%、newIntel≈40%)，与设计中心外部知识/标准规范库无关。\n\n5) 通用多版本/分权缺失——属实。DesignDoc 仅一个 version 字符串(DesignDoc.java:30-34)，无版本历史链；唯一的版本列表在 doccenter.vue(独立文档协作模块)。鉴权只有全局 AuthInterceptor 按角色 default-deny(ADMIN/APPROVER)+档案 secLevel 派生审批层级(ArchiveLifecycleService.approvalLevelOf)，无知识条目级细粒度共享/分权。\n\nculture/casebank.vue 有真后端案例库(CRUD+评审+引用)但为通用经验案例库、单维分类、不绑设计中心、无上述高阶能力，不能推翻缺口。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java:333-375(只有 project.accept→project.toArchive 自动归档，无设计交付物分支); web/ArchiveSubmissionController.java:136-181(人工提交-审核-落档，非自动联动); domain/Archive.java:46(tags 单字符串)+web/ArchiveSubmissionController.java:166(tags 存的是 code); domain/DesignDoc.java:30-34(单 version 字段); web/DesignDocController.java、web/DesignChangeOrderController.java(无 archiveRepo 引用)。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/knowledge/map.vue:66-104,145-179(静态主题树+硬编码标签云+mock docRows); knowledge/rss.vue:36-38,79-92(feed.example.com 硬编码 URL+mock 文章+settings 持久化，无抓取); knowledge/libmgr.vue:389-398,586(扁平单维分类标签存 settings); oa/pages/culture/casebank.vue(通用案例库，不绑设计中心)。grep 全后端 knowledgeGraph|图谱|语义匹配|semanticMatch|关联推荐|embedding|cosineSimilarity = 零命中。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "5. 市场经营与招投标管理",
   "verdict": "PARTIAL",
   "gap": "客户画像/满意度/复购缺字段；商机→CSL立项无打通；投标知识库未建；合同与csl-project未直接绑定。",
   "severity": "med",
   "evidence": "Customer 实体 grep 'private' 结果仅 id/name/type/contact/phone/address/status——无 satisfaction/画像/loyalty/复购 字段。grep 'csl|cslProject' 在 Opportunity*(web+domain) 零命中——商机→csl-project 无自动转化打通。投标知识库(归档过往投标文件/报价策略)无专用实现。合同与 csl-project 无直接绑定字段(CslProject 无 contractId，合同域无 cslProjectId)。",
   "survives": true,
   "reNote": "努力推翻未果，缺口四点基本属实。逐点核查：\n\n1) 客户画像/满意度/复购缺字段 —— 大体属实。domain/Customer.java 仅有 name/type/contact/phone/address/status 六个字段，无行业/标签/画像/满意度聚合/复购(repurchase)/续约维度；CustomerController 无任何画像或复购统计端点(仅基础 CRUD)。全后端 grep \"复购/repurchas/画像/portrait/续约/续单\" 零命中。唯一可辩护点：满意度分散存在于 CustomerComplaint.satisfaction(回访满意度1-5)、ServiceTicket.satisfaction、Survey(满意度调查)，所以\"满意度\"并非彻底为零，但它不是挂在 Customer 画像上、也没有客户级满意度聚合，且复购/画像确实完全缺失——这一子点不足以推翻。\n\n2) 商机→CSL立项无打通 —— 完全属实。OpportunityController 只有 /{id}/convert-bid(商机→投标台账)，无 convert-csl/转立项端点；CslProjectController.create 只接受 ProjectRequest(client 为纯字符串)，无 opportunityId 入参；domain/CslProject.java grep \"opportunity/customerId/bidId/contractId\" 全部零命中。商机与 csl-project 之间无任何代码级回链或转换路径。\n\n3) 投标知识库未建 —— 属实。bid 相关仅 Bid/BidBond/BidDecision/BidDeposit/BidTask(台账/保证金/评审/任务)，无投标知识库/案例库/标书模板域或控制器；grep \"投标知识/案例库/标书模板/TenderKnowledge/bid.*knowledge\" 零命中(知识库类仅 ItKnowledgeArticle/CultureCase/LitigationCase，均非投标域)。\n\n4) 合同与 csl-project 未直接绑定 —— 完全属实。domain/Contract.java 字段为 projectId(指向通用 project)/parentId/companySubject 等，无 cslProjectId；Contract 域 grep \"csl\" 零命中；CslProject 也无 contractId。两者无任何外键级直绑(只能凭 client 名称/contractAmount 字符串巧合对应)。\n\n结论：四点中 2/3/4 完全成立(找不到任何实现)，1 部分成立(满意度有零散承载但客户画像与复购确缺)，整体 PARTIAL 判定准确，无法推翻。",
   "reEvidence": "domain/Customer.java(仅6字段,无画像/复购/满意度); web/CustomerController.java(纯CRUD,无画像/复购端点); domain/Opportunity.java + web/OpportunityController.java(仅convert-bid,无convert-csl,165行); domain/CslProject.java(无opportunityId/contractId/customerId,client为String); web/CslProjectController.java(create仅收ProjectRequest,client字符串); domain/Contract.java(有projectId/parentId,无cslProjectId); domain目录下bid类仅BidBond/BidDecision/BidDeposit/BidTask,无投标知识库; grep全后端\"复购/repurchas/画像/投标知识/案例库\"零命中; 前端 oaModules.ts:516-530 design模块projects映射CslProject; oa/pages/design/consult.vue 无csl/合同/商机/知识库引用"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "6. 财务管理与成本核算",
   "verdict": "PARTIAL",
   "gap": "多层级预算/科目表/报销归集/超预算预警缺；成本仅人工一项无直接/间接成本分摊；无多种收入确认；无产值奖金；BI无部门损益/客户贡献/穿透。",
   "severity": "high",
   "evidence": "无多层级预算体系/标准化预算科目表接入 CSL，CslProject 仅单一 budgetAmount，grep 'csl' 在 Budget*/Expense* 零命中——ExpenseClaim 未绑 csl-project，报销无归集到项目预算科目、无超预算预警。CslTimesheet 仅归集人工成本(laborCost)一项，无直接成本(差旅/外协/采购)与间接成本分摊。无成本法/节点法收入确认。产值分配/奖金核算仅注释无实现。CslDashboardController(已读)BI 仅 ProjectPnl(合同额-人工成本)/byType/byStage/ReportProgress——无部门损益表/客户贡献/穿透查询。",
   "survives": true,
   "reNote": "缺口判定 PARTIAL 成立，无法推翻为已实现。针对设计研究中心/咨询可研院（csl-*、design-* 控制器）这个具体领域的财务与成本核算链，逐条核验：\n\n【描述中被夸大、其实已实现的部分（说明本域并非一无所有）】\n- 报销归集：ExpenseClaimController 全套报销单状态机（草稿→已提交→已报销/已驳回），提交时按 budgetId/项目+费用类型解析预算并把金额计入 actualAmount、含在途(inFlight)勾稽。\n- 超预算预警：ExpenseClaimController.doSubmit 超额抛 409；BudgetController 自动置「超支」；ProjectCostControlController /alerts 分级（关注/超支预警/严重超支）。这些确实存在。\n- 多层级预算：ProjectBudgetLine(项目/WBS/成本要素 + 状态机)、Budget(年度/季度/月度 + companySubject)、BranchBudgetLine(机构/年度/收入·成本·费用口径/科目) 都有，多层级预算并非缺失。\n- 穿透：CostAuditTraceController 提供 by-supplier/by-project/by-subject 汇总 + /drill 下溯到合同/结算/发票/付款源单据，是真实的钻取/穿透。\n- 收入确认：ProjectController.generateAcceptanceVoucher 在验收阶段生成「收入确认凭证」(借应收账款/贷主营业务收入，幂等防重复入产值)，存在一种收入确认。\n\n【但 PARTIAL 的承重缺口确实存在（故 real=true）】\n1. 本域成本仅人工一项、无直接/间接成本分摊：CslTimesheet/CslDashboard 与 DesignProject/DesignTask 的 actualCost 全部来自 工时×费率 的人工成本，csl-*/design-* 控制器内 grep「间接/分摊/overhead/allocat」零命中。间接费分摊只存在于其它域(OpsCostAllocation 按水量分摊、ProjectCostControl 有「间接费」要素)，本设计/咨询域未接入。\n2. 无多种收入确认：仅验收一次性确认一种方式，无完工百分比法等多种确认方式。\n3. 无产值奖金：CslTimesheet/Controller 仅注释「为产值考核提供依据」，全仓 grep「产值奖金/bonus/奖金」无任何奖金计提/分配引擎。\n4. BI 无部门损益/客户贡献：BusinessBiController.businessOverview 无部门维度、无客户贡献维度；CslDashboard 只有按项目/类型/阶段的盈亏，无「部门损益」「客户贡献」分析。\n\n结论：描述里若干清单项被夸大（报销归集/超预算预警/穿透/单一收入确认其实已建），但该域「成本仅人工无直接间接分摊 + 无产值奖金 + BI无部门损益/客户贡献」三项承重缺口属实，PARTIAL 判定无法推翻。",
   "reEvidence": "/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/CslTimesheetController.java (仅 hours×rate 人工成本, projectSummary 只归集人工); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/CslDashboardController.java (ProjectPnl=合同额−人工成本, 无间接成本/无客户贡献/无部门损益); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/CslTimesheet.java:17-19 (注释「产值考核」但无奖金计提); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DesignProjectController.java:238-284 + domain/DesignProject.java:57-60 (actualCost 由工时回写, 仅 budgetOver 预警, 无成本分摊); grep「间接/分摊/allocat/overhead」对 Csl*/Design* 控制器零命中; 对比 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/OpsCostAllocationController.java(按水量分摊) 与 ProjectCostControlController.java:77-78,300-326(含「间接费」要素+distribute分摊) 证明分摊能力存在于他域而本域未接入; 反向证据(描述过头处): ExpenseClaimController.java:144-249(报销+预算归集+超预算409)、ProjectCostControlController.java:357-383(分级超预算预警)、CostAuditTraceController.java:221-294(/drill 穿透下溯)、ProjectController.java:137-176(验收收入确认凭证)。活体 8091: GET /api/oa/csl-dashboard 与 /api/oa/branch-pnl/board 均 code:0 返回但无客户贡献/部门损益字段。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "7. 合规风控与审计追溯",
   "verdict": "PARTIAL",
   "gap": "立项风险评估/量化预警未接入CSL；报告提交无合规预检；CslProject(及无报告时的task/timesheet)仍可物理删除。审核留痕证据链为真。",
   "severity": "med",
   "evidence": "立项风险评估未接入 CSL：CslProject 无风险日志/分析模型/量化预警字段(实体已读全字段确认)；RiskAssessment 属法务合规域独立存在。CslReportController.submit() (line 158-181) 仅按 STAGES 推进 reviewStage，无任何合规校验(投资估算编制规范/章节完整性)，grep '合规|compliance|预检' 在 Csl 零命中。核心数据不可删仅 CslReport(locked) 与已确认 CslTimesheet 受保护；CslProject.delete() (line 141-153) 仅在有报告时拦截、否则物理删除并级联删 task/timesheet；CslReportReview 电子证据链留痕为真。",
   "survives": true,
   "reNote": "缺口属实，PARTIAL 判定准确。逐条核验：(1) 立项风险评估/量化预警未接入：CslProjectController 的 submit/approve/reject 全是纯状态机流转，无任何风险评估或预警闸口；仅有的 scoreOf 是商机优先级初筛启发式、overdueAlerts 是只读逾期扫描，二者都不是风险量化也不进审批闸；CslProject 实体无 risk 字段；CSL 无 service 层；WorkflowService/TriggerRuleEngine 对 CSL 零引用。(2) 报告提交无合规预检：CslReportController.submit 仅校验环节索引后推进，无任何合规预检；全部 CSL 控制器 grep risk/compliance/precheck 均无命中。(3) CslProject 可物理删除：delete 仅当已有报告时拦截，无报告即 projectRepo.deleteById 物理删，并级联物理删 task/timesheet；实体无 @SQLDelete/@Where/deleted 软删标记。(4) task/timesheet 物理删除：CslTaskController.delete 直接 taskRepo.deleteById；CslTimesheetController.delete 仅拦“已确认”状态后 timesheetRepo.deleteById。(5) 审核留痕证据链为真：logReview 在 submit/reject/sign 每次落 CslReportReview，按 createdAt 排序，与缺口描述一致。我尽力从 service/引擎/软删/实体字段四个方向找反证均落空。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa：web/CslProjectController.java(submit L158-170/approve L176-187 纯状态机无风险闸；delete L141-153 物理删+级联物理删task/timesheet；scoreOf L324-346/overdueAlerts L258-293 非风险评估)；web/CslReportController.java(submit L158-181 无合规预检；logReview L319-330 留痕真)；web/CslTaskController.java(delete L136-144 taskRepo.deleteById)；web/CslTimesheetController.java(delete L134-142 timesheetRepo.deleteById)；domain/CslProject.java(无 risk/deleted 字段)。grep 证实：CSL 控制器无 risk/compliance/precheck、无 WorkflowService/TriggerRuleEngine/Alert 引用，service 目录无 CSL 文件，CSL 实体无 @SQLDelete/@Where/deleted。"
  },
  {
   "area": "设计研究中心 / 咨询可研院/咨询可研院",
   "module": "8. 与其他部门的接口要求",
   "verdict": "MISSING",
   "gap": "五个部门接口(申报/知产/实验室/财务其余项/人力)与 csl 的自动数据流转端点全部缺失；TriggerRuleEngine 无 csl.* 联动规则。",
   "severity": "med",
   "evidence": "grep 'csl|cslProject' 在 Declaration*/Patent*/Lab*(web+domain) 全部零命中。申报服务部:无从报告抽取关键结论(投资规模/经济效益/可行性结论)的端点。知识产权部:无评估方法/模型转专利、无原始数据证据对接。实验室:无 csl↔lab 检测需求/报告回传链。财务部:仅人工成本(CslTimesheet)打通，预算/报销/收款开票/成本分摊未联动(模块6已证)。人力资源部:人员档案/工时/绩效/培训自动取数缺失。TriggerRuleEngine grep csl 零命中——部门间数据自动流转整体未建。",
   "survives": true,
   "reNote": "缺口属实。设计研究中心/咨询可研院(CSL)模块由 5 个控制器组成(CslProject/CslReport/CslTask/CslTimesheet/CslDashboard)，全部自包含，与五个部门(申报Declaration/知产Patent/实验室Lab/财务Payment-Invoice/人力HR-PersonnelCert-HealthRecord)之间不存在任何自动数据流转端点；TriggerRuleEngine 也没有任何 csl.* 联动规则。\n\n证据明细：\n1) TriggerRuleEngine.fire() 仅按关键词 付款/报销/用印/收款/验收/供应商/合同/立项 匹配，写入 7 个硬编码下游(Payment/Invoice/Contract/SealUse/Project/Archive/Supplier)，从不读写任何 Csl* 实体；ruleKeyFor() 枚举的 ruleKey 全集为 payment.create / receipt.invoice / contract.effectivate / contract.toSeal / project.create / project.accept / project.toArchive / seal.markUsed / supplier.admit，无任何 csl.* 键。\n2) WorkflowService.java 对 csl 零引用(grep 空)，CSL 状态机变更根本不进入联动引擎——CSL 的 submit/approve/accept 等都是控制器内直接改 stage 字段，未经过 FormInstance/WorkflowService。\n3) 5 个 CSL 控制器对 declaration/patent/labsample/labinstrument/payment/invoice/healthrecord/personnelcert/certification 全部零 import / 零引用。反向亦然：上述五部门控制器对 csl 零引用。\n4) CslProjectController.accept() 的 Javadoc 写\"自动触发归档/知识沉淀\"，但方法体只做 setStage(已结项)+setProgress(100)，既不建 Archive 也不调 TriggerRuleEngine——属空头注释，无实现。\n5) 唯一存在的跨模块读取是 CSL 内部：CslReportController.addEstimate 读 PriceItemRepository(人材机价格库)取单价，CslDashboardController 聚合 csl_project/csl_timesheet/csl_report；均不涉及五部门接口。AuthInterceptor 里的 csl 仅是 URL 鉴权前缀登记，非数据流转。",
   "reEvidence": "service/TriggerRuleEngine.java:100-148(fire仅8类关键词)、676-689(ruleKeyFor全集无csl.*); service/WorkflowService.java(grep csl 零命中); web/CslProjectController.java:223-246(accept只改stage/progress,无归档实现,与第36行Javadoc\"自动触发归档\"不符); web/CslReportController.java(仅import PriceItem做价格库联动); web/CslDashboardController.java(仅聚合csl自身三表); grep declaration/patent/lab/payment/invoice/healthrecord/personnelcert/certification on web/Csl*.java 全空; 反向 grep csl on 五部门控制器全空; config/AuthInterceptor.java:95-96,167(仅URL鉴权前缀登记)"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "2. 图纸与文档全生命周期管理",
   "verdict": "LOGIC_GAP",
   "gap": "缺:版本历史表(每改生成新版本行+旧版本归档可查);草稿→校对→审核→批准→发布状态机+发布后锁定;在线协同/文件冲突检测/CAD-Revit属性提取;图纸对外分发接收记录+电子签章+防伪二维码;红线批注审签汇总;图内文字/图签全文检索。仅有变更驱动的 toVersion 递增是局部覆盖。",
   "severity": "high",
   "evidence": "反驳后维持。DesignDocController(/api/oa/design-docs) 只有单个 version 字符串字段 + reviewStatus 四态枚举(编制中/校审中/已批准/已归档),CRUD 直接覆盖,无任何状态机推进端点、无强制流转、无发布后锁定。grep version/revision: domain/ 无 DocVersion/Revision 实体、repository/ 无对应仓库——确无'每次修改生成新版本+旧版本归档可查'的版本历史表。collision/BIM/在线协同 全代码零命中。EsignController 仅作用于 /api/oa/contracts+ContractEsign(合同),图纸侧无电子签章/二维码/分发接收记录。全文检索仅按 reviewStatus 字段过滤,无图内文字/图签检索。唯一可翻案的边角:DesignChangeOrderController.implement() 走变更时强制 fromVersion→toVersion +0.1 并返回受影响专业提醒清单——这是'变更驱动的版本递增+联动通知',但只覆盖变更场景,非完整版本历史/审签发布锁定,不足以推翻 LOGIC_GAP。",
   "survives": true,
   "reNote": "缺口属实。设计研究中心的\"图纸与文档全生命周期管理\"在后端只有一个扁平 DesignDoc 实体(domain/DesignDoc.java)+纯 CRUD 控制器(web/DesignDocController.java)，前端是一张通用 MasterDataPage 表(oa/pages/design/docs.vue)，没有任何描述中要求的生命周期机制：\n\n1. 版本历史表：DesignDoc 只有单个 version 字符串字段(行30)，PUT update 直接覆盖(DesignDocController.java:89 d.setVersion)。没有 *_doc_version 历史表、没有\"每改生成新版本行+旧版本归档可查\"。全库 grep versionHistory/DocVersion/docVersion 零命中；唯一的 fromVersion/toVersion 只在另一个实体 DesignChangeOrder 上，且只是该变更单自身记两个字符串字段，不为 DesignDoc 生成历史行——正如描述所说仅是\"变更驱动的 toVersion 递增的局部覆盖\"。\n\n2. 草稿→校对→审核→批准→发布状态机+发布后锁定：reviewStatus 只是普通字符串(编制中/校审中/已批准/已归档)，create/update 无任何状态流转校验或锁定逻辑(DesignDocController.java:69-71,91 直接赋值)，没有 submit/approve/publish/lock 端点。活体探测 /design-docs/1/{submit,approve,publish,lock} 全部 404。注意:有状态机的 DesignChangeOrderController(草稿→评估中→审批中→已批准→已实施)是\"设计变更单\"，不是图纸文档本身；DesignReview 实体表名 rd_design_review、挂在 DevProject 下，是研发技术评审，与图纸校审无关。\n\n3. 在线协同/文件冲突检测/CAD-Revit属性提取：DesignDoc 无相关字段或端点，零实现。\n\n4. 对外分发接收记录+电子签章+防伪二维码：/design-docs/1/distributions 404；无任何 distribution/signature/QR 关联到设计文档(系统里 ContractEsign/EsignController 仅服务合同)。\n\n5. 红线批注审签汇总：/design-docs/1/annotations 404，无 annotation/redline 实体关联设计文档。\n\n6. 图内文字/图签全文检索：FullTextSearchService.reindexAll() 索引的 11 类(公告/讨论/调查/事项/纪要/合同/供应商/客户/公司/文档/协作文档)不含 DesignDoc，设计图纸根本未进全文索引。",
   "reEvidence": "domain/DesignDoc.java:24-38 (扁平字段, 单 version 字符串, reviewStatus 普通字符串); web/DesignDocController.java:58-94 (纯 CRUD, update 直接覆盖 version/reviewStatus, 无状态机/锁定); repository/DesignDocRepository.java (仅 findByReviewStatus, 无历史查询); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/docs.vue (通用 MasterDataPage, version/状态均为自由输入); ofbiz-framework/plugins/modern-ui/app/src/oa/api/design.ts:35-46 (仅 list/create/update/delete); service/FullTextSearchService.java:126-191 (reindexAll 索引 11 类不含 DesignDoc); domain/DesignChangeOrder.java:74-77 + web/DesignChangeOrderController.java:199-203 (fromVersion/toVersion 仅变更单自身字段, 非 DesignDoc 版本历史); 活体 http://127.0.0.1:8091: GET /design-docs 返回 8 条扁平记录(version=V2.0 静态字符串), /design-docs/1/{versions,history,submit,approve,publish,lock,annotations,distributions} 全部 404。"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "4. 设计协同与接口管理",
   "verdict": "PARTIAL",
   "gap": "缺:BIM自动碰撞检查/碰撞报告/协调会议闭环;外部设计院安全门户+访问日志+外协质量评估;设计完成→施工招标、设计选型→采购预询价的 TriggerRuleEngine 自动联动;混凝土量/窗地比超限预警(仅含钢量已做)。提资+含钢量预警为已覆盖部分。",
   "severity": "high",
   "evidence": "反驳后维持 PARTIAL,但发现初判低估。提资闭环是真实现:DesignInterfaceController 状态机 待提交→已提资(submit 落 submittedDate+资料版本)→已接收(confirm 落接收人) + /alerts 逾期分级预警。更重要:'含钢量超限自动预警'已实现——DesignProjectController.buildBoard()/alerts() 计算 steelOver(steelActual>steelLimit)并产出'指标超限/高'预警(初判把它当'除含钢量外'的缺项,实则含钢量这一项是做了的)。但 BIM/碰撞/collision/clash 全代码零命中,确无碰撞检查与协调会议闭环。TriggerRuleEngine.java 经 grep design/设计/图纸/提资 零命中,硬编码规则只有 payment/contract/project/seal/supplier 五类,确无'设计完成节点触发施工招标''设计选型推采购预询价'的自动联动接线。混凝土量/窗地比预警确缺。",
   "survives": true,
   "reNote": "缺口属实，PARTIAL 判定准确。已覆盖部分(提资闭环+含钢量预警)确实存在，但四项所列缺失功能在前后端均无任何实现。1) BIM碰撞检查/碰撞报告/协调会议闭环：全库零匹配 bim/碰撞/collision/协调会议；唯一的 DesignReviewController 属创新研发中心(挂 DevProject 的技术评审投票节点)，非规划设计部的BIM协调会议。2) 外部设计院安全门户+访问日志+外协质量评估：无门户控制器/域、无访问日志、无外协质量评估；\"外协\"命中均为预算成本要素字符串，\"设计院\"命中均为 DataSeeder 专家单位字符串。3) TriggerRuleEngine 设计→施工招标 / 设计选型→采购预询价 自动联动：引擎仅 9 条硬编码 ruleKey(payment.create/receipt.invoice/contract.effectivate/contract.toSeal/project.create/project.accept/project.toArchive/seal.markUsed/supplier.admit)，无任一设计下游联动；配置规则种子里也无相关条目。4) 混凝土量/窗地比超限预警(仅含钢量已做)：DesignProject 实体只有 steelLimit/steelActual 两字段(域注释虽提\"混凝土量/窗地比\"但无对应字段)，DesignAlert 仅产出三类预警且\"指标超限\"完全基于 steelActual>steelLimit。",
   "reEvidence": "已覆盖(与PARTIAL一致): /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DesignInterfaceController.java(submit/confirm 提资闭环+/alerts逾期); DesignProjectController.java:290-294(含钢量超限预警)。\n缺口证据: (a) grep -rli 'bim|碰撞|collision|clash|协调会议' 后端前端=空。(b) DesignReviewController.java:26-38 注释明示属\"创新研发中心/产品开发部·技术评审\"，挂 DevProject，非设计协调会议。(c) 'design.*bid|设计.*招标|选型.*采购|预询价|设计完成.*施工' 全库零匹配；TriggerRuleEngine.java:676-686 ruleKeyFor 仅 9 条键，无设计联动。(d) DesignProject.java:63-66 仅 steelLimit/steelActual，无 concrete/window/floor 字段；DesignProjectController.java:253-296 DesignAlert 仅 任务超期/成本超支/指标超限(钢)三类。(e) '设计院/外协' 命中均为成本要素或专家单位字符串(BudgetController.java:24, CslEstimateItem.java:16,31, DataSeeder.java:3243-3247)，非外部设计院门户。"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "5. 设计资源与绩效管理",
   "verdict": "PARTIAL",
   "gap": "缺:设计人员能力库(专业/擅长/职称/出图速度/变更率)+按能力匹配;质量效率四考核指标(一次审签通过率/变更率/按时交付率/客户满意度);个人/部门绩效看板;按合同额/工作量比例分专业分阶段的产值自动分配。工时成本归集+成本对预算超支预警实为已实现(纠正初判)。",
   "severity": "med",
   "evidence": "反驳后维持 PARTIAL,但初判对'工时侧未关联预算'的判断不成立、应纠正。工时管理与成本归集是真实现:CslTimesheetController 录入即按 hours×rate 自动算 laborCost(BigDecimal.multiply→Money.of),/project/{id}/summary 按人/角色汇总产值归集依据(PersonRow:person/role/hours/laborCost),已确认/草稿成本分列;CslProject 有 budgetAmount;前端 pages/design/resource.vue 正是接这套口的'设计资源与绩效'页。DesignProjectController.board/alerts 又独立做了 actualCost vs budget 的 budgetOver 超支预警——即'人工成本对比预算预警'设计侧已落地(初判称工时侧未关联预算,与代码不符)。但确缺:能力库(grep capability/能力库/出图速度 零命中)、按能力匹配任务、四质量效率考核指标(grep 一次审签通过率/按时交付率/客户满意度/变更率 在设计域零命中,命中均属 culture/service-ticket 等他域)、个人/部门绩效看板。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但无法证伪——该缺口的四项核心能力在前后端均无实现。\n\n[设计研究中心/规划设计部] 该链的\"设计资源与绩效管理\"在系统里实际落地的只是【工时管理+人工成本归集+预算超支预警+项目P&L】，恰是缺口描述中已被纠正为\"已实现\"的部分；缺口主张的四项扩展能力确实缺失：\n\n1) 设计人员能力库(专业/擅长/职称/出图速度/变更率)+按能力匹配——不存在。无任何设计中心能力库实体；现存 StaffCredential/PersonnelCert/Expert 是HR证书库/专家库，字段为证书类型/有效期/锁定借用态等，没有\"出图速度/变更率/擅长\"字段，也无\"按能力匹配派工\"逻辑(grep 能力库/出图速度/drawingSpeed/matchByCapability 在设计上下文零命中)。\n\n2) 质量效率四考核指标(一次审签通过率/变更率/按时交付率/客户满意度)——设计上下文不存在。这些词仅出现在无关模块(mfg/quality制造质量、itservice、crm/complaint客诉、culture/assessment文化考核、ops运营)；\"变更率/changeRate\"全库零命中。DesignReviewController/DesignChangeController/DesignChangeOrderController 只有 CRUD+状态机(申请/审批中/已实施/通过/退回)，没有把评审结果或变更单聚合成\"按设计师的一次通过率/变更率\"的任何统计端点。\n\n3) 个人/部门绩效看板——不存在。唯一的看板 CslDashboardController 是项目级经营看板(合同额−已确认人工成本=毛利/毛利率、按类型/阶段分布、报告进度)，不是按人/按部门的绩效看板；CslTimesheetController 的 byPerson 汇总只累加 hours 与 laborCost(=hours×rate)，没有绩效指标。\n\n4) 按合同额/工作量比例分专业分阶段的产值自动分配——不存在。contractAmount 仅被 CslDashboard 用于算项目毛利、被 CslProjectController 做字段读写；没有任何\"按专业系数×阶段比例×合同额\"把产值自动分摊到人的逻辑(grep 分专业分阶段/phaseRatio/disciplineRatio/产值比例 零命中)。CslTimesheet.java 里\"role 用于产值分配规则\"只是注释，无对应实现。",
   "reEvidence": "关键文件与证据:\n- 前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/resource.vue 第7行自述:\"原'设计资源与绩效'假数据页已改接真后端 /csl-timesheets\"——即原绩效页被改成纯工时/成本页。页面只有工时填报、人工成本占合同额、按人产值归集(仅累加laborCost)，无四KPI/无能力库/无产值分配。\n- oaModules.ts:523 模块项 label='设计资源与绩效' 但 path='/design/resource' 指向上述工时页。\n- oa-backend .../web/CslTimesheetController.java: projectSummary 的 PersonRow 只含 person/role/hours/laborCost，无任何绩效或产值分配字段。\n- oa-backend .../web/CslDashboardController.java: 仅项目级毛利看板(ProjectPnl/Overview)，无个人/部门绩效维度。\n- oa-backend .../service/DesignProjectService.java: recalcProject 汇总 actualHours×rate→actualCost、budgetUsageRate 算预算执行率(此为缺口已承认的\"已实现\"部分)；无能力匹配/KPI/产值分配。\n- DesignReviewController.java / DesignChangeController.java / DesignChangeOrderController.java: 仅 CRUD+状态机，无 passRate/changeRate/byPerson 聚合端点。\n- 全库 grep: \"变更率/changeRate\" 零命中；\"一次审签/firstPass/按能力匹配/产值分配(分专业分阶段)\" 在设计上下文零命中；满意度/通过率/按时交付率仅命中 mfg/itservice/crm/culture/ops 等无关模块。\n- StaffCredential.java/PersonnelCert/Expert.java: 字段为证书类型/专业/有效期/锁定借用态/职称证等，非设计师能力画像(无出图速度/变更率/擅长)，无按能力匹配派工。"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "6. 设计标准与知识库",
   "verdict": "MISSING",
   "gap": "全部缺失:标准图集与设计说明模板库(一键引用+参数适配);国标/行标/地方法规库(更新+检索关联);典型问题/负面清单自动推送;优秀案例库(图纸/计算书/BIM按类型检索)。",
   "severity": "med",
   "evidence": "反驳后维持 MISSING。grep standardAtlas/图集/规范库/knowledgeBase/负面清单/案例库/designStandard 在设计域全部零命中;命中项均属他域(ContractTemplate/CultureCase/ItKnowledgeArticle/StandardCost/DeclarationTemplate 等)与设计标准库无关。domain/ 无任何设计图集/设计说明模板/国标行标法规/典型问题(负面清单)/优秀案例 实体,web/ 无对应控制器。四子功能确为零实现。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实。设计研究中心(规划设计部)模块确无\"设计标准与知识库\"链/页面，四项子能力全部缺失。前端 design 模块 oaModules.ts(516-531)的10个子菜单是:设计文档/设计变更/设计资源绩效(工时)/咨询项目全生命周期/WBS/咨询报告/经营分析看板/设计项目与任务(§1)/设计变更管理(§3)/专业间提资(§4)——没有任何\"标准/图集/规范库/案例库/负面清单\"。后端 Design* 控制器(DesignDoc/Change/ChangeOrder/Project/Task/Review/Interface)与对应 domain 全文 grep 图集/案例库/国标/行标/地方法规/负面清单/设计标准/Atlas 均零命中。逐项核对:①标准图集与设计说明模板库(一键引用+参数适配)=无;②国标/行标/地方法规库=无(StandardCost 是成本标准非设计法规;lab/methods.vue 的国标/行标是检测方法库,属实验室且未接入设计模块);③典型问题/负面清单自动推送=全站无;④优秀案例库(图纸/计算书/BIM按类型检索)=无(案例库仅 culture 的 CultureCase 与 LitigationCase 有,均非设计域)。活体 8091 探测 design-standards/design-atlas/design-cases/design-regulations/design-templates/design-negative-list/standard-atlas/case-library 八个端点全部 404。",
   "reEvidence": "前端模块定义:/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:516-531(design 模块10子菜单,无标准/知识库项)。设计页面目录:.../src/oa/pages/design/(仅 docs/changes/resource/projects/wbs/reports/bi/planning/changeorder/interfaces.vue)。设计API:.../src/oa/api/design.ts(仅 /design-docs、/design-changes)。后端:oa-backend/src/main/java/com/kaidi/oa/web/Design*.java 与 domain/Design*.java 对图集/案例库/国标/行标/地方法规/负面清单 grep 零命中;StandardCost 为成本标准。活体探测:8091 上 8 个候选端点(design-standards/atlas/cases/regulations/templates/negative-list、standard-atlas、case-library)全部返回 404。"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "7. 合规与审计追溯",
   "verdict": "PARTIAL",
   "gap": "剩余缺口:查看/下载等读操作不被审计(仅写请求留痕);设计图纸/计算书/变更单的合规数字签名+可信时间戳(Esign 仅合同);按项目/时段自动生成设计过程审计报告。写操作的操作人/时间/IP+不可篡改哈希链已由全局 AuditLogInterceptor 实现(推翻'无采集')。",
   "severity": "high",
   "evidence": "推翻初判核心论断'审计表未被任何设计动作写入/有表无采集'——该论断不成立。AuditLogInterceptor 是全局 HandlerInterceptor,在 CorsConfig.java:32 经 registry.addInterceptor(auditLogInterceptor).addPathPatterns('/api/oa/**') 真实注册;afterCompletion 对一切 /api/oa/** 的写请求(POST/PUT/PATCH/DELETE)自动落 OperationAuditLog,采集 operator/operatorId/operatorRole/method/path/resourceType/resourceId/statusCode/clientIp(含 X-Forwarded-For)/occurredAt,且用 sha256(prevHash+规范化字段)续不可篡改哈希链,OperationAuditLogController 提供 /chain/verify 从创世逐条复算校验。设计侧 design-projects/design-tasks/design-change-orders/design-interfaces/design-docs 的增删改一律被该拦截器自动采集——'修改/分发/删除'写动作的操作人/时间/IP 留痕成立,且不可篡改要求(发布版本/变更审批不可改)由哈希链满足。故非 LOGIC_GAP。但仍未达标:GET 被显式排除(WRITE_METHODS 仅四写法),'查看/下载'读动作不留痕;设计图纸/计算书/变更单的《电子签名法》数字签名+可信时间戳缺失(EsignController 仅合同域);按项目/时段自动生成设计过程审计报告(版本轨迹/审批流程/外发记录)无端点。初判末三条(合同模板库/物料成本核算/合同履约提醒)确系粘贴串入,非本部门职责。",
   "survives": true,
   "reNote": "缺口属实，判定 PARTIAL 准确，三条剩余缺口逐条成立，无法推翻。写侧已实现部分（操作人/时间/IP+不可篡改 SHA-256 哈希链）确由全局 AuditLogInterceptor 落实，但描述声称未实现的三项均确缺：(1) 读操作（查看/下载 GET）不被审计；(2) 设计图纸/计算书/变更单无数字签名+可信时间戳，Esign 仅绑合同；(3) 无按项目/时段自动生成的设计过程审计报告。",
   "reEvidence": "读不留痕：config/AuditLogInterceptor.java:46 WRITE_METHODS=Set.of(\"POST\",\"PUT\",\"PATCH\",\"DELETE\")；afterCompletion 行72-75 对非写方法（GET/HEAD/OPTIONS）直接 return，不落任何 OperationAuditLog。注释行45明言\"读请求 GET/HEAD/OPTIONS 不留痕\"。CorsConfig.java:32-33 仅注册 auditLogInterceptor + authInterceptor 两个拦截器，SecurityHeadersFilter 不做任何审计/落库，全库无第二套读审计。\n\nEsign 仅合同：domain/ContractEsign.java + web/EsignController.java（@RequestMapping(\"/api/oa/contracts\")）整套电子签/盖章仅服务合同。design 实体无签名/时间戳/哈希字段——domain/DesignDoc.java 字段仅 id/name/projectName/docType/version/designer/reviewStatus/issueDate/createdAt；domain/DesignChangeOrder.java 字段（id..code..approvalChain..decisionNote..implementedDate..createdAt）同样无 signature/hash/trustedTimestamp。grep 排除 contract 后无任何 design 域的 sign/数字签名/可信时间戳实现。\n\n无设计过程审计报告：grep \"设计过程审计/design audit report/审计报告/过程审计\" 在 web/、service/、domain/ 全无命中（唯一\"审计报告\"字样在 seed/DataSeeder.java:2092 的高企申报材料清单字符串，无关）。web/DesignChangeOrderController.java:233 ledger() 仅是变更单按来源/等级的只读聚合，非\"设计过程审计报告\"且不覆盖图纸/计算书/查看下载行为。web/OperationAuditLogController.java 仅提供 list/by-operator/by-resource/chain-verify 查询，无按项目/时段自动生成审计报告端点。"
  },
  {
   "area": "设计研究中心/规划设计部",
   "module": "8. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "缺自动联动:工程量清单/技术规格书自动推成本采购部招标;创新点自动推知识产权部申请专利;材料检测需求自动派实验室+报告回流验证;变更指令/会审纪要/竣工图自动同步工程管理部;设计审批通过自动触发后续系统操作;短信/APP双通知;定时备份+多版本恢复。跨部门均为人工字段引用。",
   "severity": "med",
   "evidence": "反驳后维持 PARTIAL。TriggerRuleEngine.java 经 grep design/设计/图纸/提资 零命中,硬编码下游联动仅 payment.create/receipt.invoice/contract.effectivate/contract.toSeal/project.create/project.accept/project.toArchive/seal.markUsed/supplier.admit 九条,均非设计域;PatentController 存在但 web/Design*.java、service/Design*.java grep patent/专利/创新点 零命中,确无'创新点自动推知识产权部'触发。材料检测自动派实验室+报告回流、设计变更/会审/竣工图自动同步工程管理部、审批通过自动触发后续(设计域)、短信/APP双通知、定时备份多版本恢复——设计侧均未接线。可挂靠的真联动:DesignChangeOrder 按等级自动生成会签审批链(含成本部/甲方代表)是部门内审批联动,但非'跨部门系统自动推送'。跨部门多为字段引用(consultRef/contractCode/projectName)而非事件驱动自动联动。",
   "survives": true,
   "reNote": "缺口属实。设计研究中心/规划设计部的\"与其他部门接口\"在代码里确为人工字段引用+各模块独立状态机，描述中列举的全部自动联动均未实现。逐条核验：(1) 工程量清单/技术规格书自动推成本采购部招标——无；DesignChange/DesignChangeOrder/DesignInterface 控制器均不引用 BidRepository/采购，TriggerRuleEngine 的 7 条硬编码链(payment/seal/invoice/contract/project/supplier，外加合同→用印、项目→档案)无一条以设计单据为触发或以招标为下游。(2) 创新点自动推知识产权部申请专利——无;无任何 design→Patent 写路径，DesignReviewController.conclude 通过后仅把评审意见写回本模块的 DevProject.reviewOpinion，不创建 Patent。(3) 材料检测需求自动派实验室+报告回流验证——无;设计侧不引用 LabSample/TestTask/TestReport。(4) 变更指令/会审纪要/竣工图自动同步工程管理部——无;DesignChangeOrder.implement 仅把状态置\"已实施\"+版本号+0.1，affectedDisciplines 只是一个存储字符串字段，\"受影响专业自动提醒\"按其自身注释(189行)只是\"返回体里带清单，前端据此提示通知\"，不产生任何跨部门记录。(5) 设计审批通过自动触发后续系统操作——无;设计单据走各自控制器的私有状态机(approve/implement/conclude)，不经 FormInstance/WorkflowService.finalize，因此根本不进入 TriggerRuleEngine.fire。(6) 短信/APP双通知——全仓 grep 短信/sms/双通知/appPush 在 service|web 下零命中。(7) 定时备份+多版本恢复——无 @Scheduled、无 backup/多版本恢复实现。可配置规则引擎(RuleConfig/applyConfiguredRules)虽存在，但其动作仅 notify(写一条\"知会\"留痕)或留痕，不创建专利/招标/实验室等真实下游实体，且仍依赖 FormInstance 办结触发——设计单据并不走该路径。",
   "reEvidence": "web/DesignInterfaceController.java(纯状态机:待提交→已提资submit→已接收confirm，无任何下游写,/alerts仅只读聚合);web/DesignChangeOrderController.java:191-207 implement仅置\"已实施\"+版本号,189行注释明示\"受影响专业自动提醒\"只是返回体清单供前端提示;web/DesignChangeController.java(仅 save 本实体);web/DesignReviewController.java:205-213 conclude仅回写本模块DevProject.reviewOpinion,不建Patent;service/TriggerRuleEngine.java:100-148 仅7条硬编码链(无design/patent/bid-from-spec/lab),applyConfiguredRules:704-735 配置规则动作仅notify留痕;service/WorkflowService.java:562 仅FormInstance办结时调triggerRuleEngine.fire(设计单据不走此路径);grep web/service 下 PatentRepository/BidRepository/LabSampleRepository 均不被任何 design 控制器引用;grep @Scheduled|备份|backup|短信|sms 在 service|web 下零命中;活体 GET /api/oa/automation-logs(129行)targetTypes={payment,ruleconfig,inventory,invoice,contract,seal_use,project,bid,archive,supplier}——无 patent/lab/sample/design-change/engineering 任何设计接口下游类型;前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/interfaces.vue 注释自述\"专业间互提资料\"为手工录入(fromDiscipline/toDiscipline/dataItem 手填)。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "1. 监理规划与准备工作管理",
   "verdict": "MISSING",
   "gap": "缺岗位职责与签字权限配置、监理人员执业资格证按项目关联及有效期预警、监理规划/细则在线编制(模板引用+版本受控+总监审核发布)、检测设备台账(校准证书+领用归还)、图纸会审/设计交底纪要(问题清单跟踪)。",
   "severity": "high",
   "evidence": "SupervisionProject.java 主档确有 chiefSupervisor/supervisionUnit/stage(施工准备...) 等字段，但全模块4个子功能的承载实体均不存在：(a) 无监理机构岗位职责/签字权限配置（仅一个 chiefSupervisor 文本字段，无专监/监理员岗位与签字权限表）；(b) Certification.java 是公司级三体系认证/施工资质（无 personnelId/supervisionProjectId 关联），PersonnelCert.java 仅 personName/dept/certType 通用人员证书，二者都不是按监理项目关联的监理人员执业资格预警；(c) 无监理规划/细则在线编制+模板引用+版本受控+总监审核发布实体；(d) 无检测设备(回弹仪/经纬仪)台账+校准证书+领用归还实体；(e) 无图纸会审/设计交底纪要+问题清单实体。",
   "survives": true,
   "reNote": "缺口属实。工程监理部\"监理规划与准备工作管理\"这一功能簇未实现：5个子项无一作为专门功能落地。前端映射(kaidiDeptView.ts)把该 block 直接指向通用占位页 path:\"/goal/project\"(pageLabel\"项目/任务\")，无专属监理规划页。逐项核验：(1)岗位职责与签字权限配置——全仓无任何 controller/domain/页面/字段(jobDuty/signAuth 概念不存在)；(2)执业资格证按项目关联及有效期预警——PersonnelCert(域+控制器)存在且 AlertScheduler.refreshCertExpiry 有到期分级刷新，但 PersonnelCert 域只有 personName/dept/certType/certNo/issuer/issueDate/expireDate/status，没有 projectId 字段，完全没有\"按项目关联\"这一半能力(只有人，没有挂到监理项目)；(3)监理规划/细则在线编制(模板引用+版本受控+总监审核发布)——彻底缺失，无规划文档实体、无模板引用、无版本受控、无总监审核发布工作流，SupervisionProject 仅是裸 CRUD；(4)检测设备台账(校准证书+领用归还)——LabInstrument 仅有 calibrationDate/nextCalibration 两个日期字段，无校准证书附件字段、无领用/归还(checkout/return)记录或端点，且属实验室中心实体并未绑定监理项目；(5)图纸会审/设计交底纪要(问题清单跟踪)——无任何会审/交底实体、控制器或页面，全仓唯一命中是 DataSeeder.java 第2601行一条无关的 QMS 种子记录字符串。综合：5子项中3项完全无实现，2项(执业证、检测设备)仅有部分通用台账而缺失需求点明的\"按项目关联\"\"校准证书+领用归还\"等关键能力，且整 block 仍指向通用项目页占位。缺口成立。",
   "reEvidence": "前端映射: ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts —— 工程监理部 blocks 中 {\"name\":\"监理规划与准备工作管理\",\"status\":\"built\",\"path\":\"/goal/project\",\"pageLabel\":\"项目/任务\"}(通用占位)。\nPersonnelCert 域无 projectId: oa-backend/src/main/java/com/kaidi/oa/domain/PersonnelCert.java 字段仅 id/personName/dept/certType/certNo/issuer/issueDate/expireDate/status/createdAt。\nPersonnelCertController: oa-backend/src/main/java/com/kaidi/oa/web/PersonnelCertController.java 只有 type/status 过滤，无 project 关联。到期刷新: oa-backend/src/main/java/com/kaidi/oa/task/AlertScheduler.java:144 refreshCertExpiry()。\nLabInstrument 域无校准证书/领用归还: oa-backend/src/main/java/com/kaidi/oa/domain/LabInstrument.java 字段仅 name/model/assetNo/calibrationDate/nextCalibration/status/location/manager/createdAt；LabInstrumentController.java 无 checkout/return 端点。\n监理域控制器全集仅: SupervisionProjectController.java(裸CRUD+overview驾驶舱) / SupervisionInspectionController.java / SupervisionLogController.java / MeasurementPayment / CompletionAcceptance —— 无规划编制/会审/交底/岗位职责控制器。\n监理前端页仅: oa/pages/supervision/{acceptance,inspections,logs,measurement,projects}.vue —— 无 planning/review/disclosure 页(design/planning.vue 经核为规划设计部§1设计项目页，非监理)。\n关键词全仓 grep(监理规划/监理实施细则/图纸会审/设计交底纪要/岗位职责签字权限) 在源码中无功能实现命中，仅命中 kaidiDeptView 构建产物字符串与 DataSeeder.java:2601 一条无关 QMS 种子记录。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "2. 施工准备阶段监理",
   "verdict": "MISSING",
   "gap": "四个子功能(资质审查含有效期预警/方案报审多级签认链/测量复核含不合格触发整改/开工条件核查表+开工令)全无实体与流程。",
   "severity": "high",
   "evidence": "逐一核查：施工单位资质审查、施工组织设计/专项方案报审(施工方→专监→总监多级签认链)、测量放线成果复核、开工条件核查+开工令——均无对应 domain 实体与控制器。SupervisionInspection.inspectType 固定为「旁站/巡视/平行检验/监理通知」(domain 注释+前端 TYPES 常量证实)，容纳不下方案审查的多级签认链；WorkflowService 也无对应表单模板接入。",
   "survives": true,
   "reNote": "缺口属实。工程监理部\"2.施工准备阶段监理\"的四个子功能(资质审查含有效期预警/方案报审多级签认链/测量复核含不合格触发整改/开工条件核查表+开工令)在前后端都没有专属实体与流程。监理域后端只有5个控制器(SupervisionProject/SupervisionInspection/MeasurementPayment/CompletionAcceptance/SupervisionLog)，分别覆盖监理项目主档、施工过程质量控制(旁站/巡视/平行检验/监理通知)、计量支付(投资控制)、竣工验收、通用监理记录——没有一个对应施工准备阶段。kaidiDeptView 把\"施工准备阶段监理\"这个 block 直接映射到 /supervision/logs(通用\"监理记录\"列表页)，该页字段仅 项目/类型/内容/发现问题/处理状态/监理工程师/日期，四个子功能全无。\"施工准备\"在代码里只作为 SupervisionProject.stage 的6个枚举值之一(施工准备/基础/主体/装饰安装/竣工验收/缺陷责任期)存在，不是任何功能实体。对四个子功能逐一排查：(1)资质审查有效期预警——QualCert+QualCertController 确实有到期分级预警，但它属于\"行政·资质管理办\"管理本公司/人员自有资质，不是监理在开工前审查\"施工方资质/人员/设备\"，与 SupervisionProject 无关联也不构成开工闸门；(2)方案报审多级签认链——无施工组织设计/专项方案报审实体或多级签认 workflow；(3)测量复核含不合格触发整改——唯一含\"测量\"的是 MeasurementPayment(计量支付，完全是投资控制概念)，无测量放线复核实体；SupervisionInspection 的不合格触发整改属于施工过程质量控制(第3块)，不是准备阶段测量复核；(4)开工条件核查表+开工令——无开工条件核查或开工令实体；唯一\"开工\"字样在 EhsWorkPermitController(EHS作业票有效期校验)，属不同领域不同概念。",
   "reEvidence": "后端监理域全部控制器(grep @RequestMapping)：/api/oa/supervision-projects, /api/oa/supervision-inspections, /api/oa/measurement-payments, /api/oa/completion-acceptances, /api/oa/supervision-logs——无资质审查/方案报审/测量复核/开工令任何端点。实体目录(domain/)：SupervisionProject/SupervisionInspection/MeasurementPayment/CompletionAcceptance/SupervisionLog，均非准备阶段四子功能。前端 src/oa/pages/supervision/ 仅 acceptance.vue/inspections.vue/logs.vue/measurement.vue/projects.vue，无 preparation/qualification/scheme/commencement 任何页面。kaidiDeptView.ts:7 工程监理部 blocks 中 {\"name\":\"施工准备阶段监理\",\"status\":\"built\",\"path\":\"/supervision/logs\",\"pageLabel\":\"监理记录\"} —— 整块只指向通用监理记录列表。logs.vue 字段：projectName/logType/content/problem/handleStatus/supervisor/logDate，无四子功能任何字段。SupervisionProject.java:67-68 与 SupervisionProjectController.java:106 证实\"施工准备\"仅是 stage 枚举默认值。grep 全后端\"资质审查|方案报审|测量复核|开工令|开工条件\"在监理域零命中(QualCert 归行政资质办，EhsWorkPermit 归 EHS)。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "3. 施工过程质量控制",
   "verdict": "LOGIC_GAP",
   "gap": "材料复验自动送检、隐蔽工程影像/坐标/时间戳门禁、旁站计划自动生成+移动打卡、平行检验仪器采集+偏差预警、整改线上派单全缺，属表面有逻辑空。",
   "severity": "high",
   "evidence": "工序验收/整改闭环主线确有承载且逻辑自洽：SupervisionInspectionController 的 /{id}/close 整改闭环动作含状态机(无需整改/待整改→已复核闭环)、幂等(已闭环 409)、defaultRectify 按结论(整改/不合格/停工→待整改)自动派生，inspections.vue 有完整 CRUD+闭环 UI。但需求要求的自动化全空：(a) 材料进场验收实体不存在，无自动触发实验室送检——QcInspection 是 mfg_qc_inspection(IQC/IPQC/FQC 制造检验,关联供应商/工单/序列号)，与监理材料报验无关且不向 LabSample 联动；(b) SupervisionInspection 无影像/坐标/时间戳字段，隐蔽工程无强制门禁；(c) 无旁站计划自动生成+移动打卡；(d) 无平行检验仪器自动采集+偏差预警(content 为自由文本);(e) 整改为手工录入非线上派单。TriggerRuleEngine 无任何 supervision/material/inspect 规则。",
   "survives": true,
   "reNote": "缺口属实。工程监理部\"施工过程质量控制\"在后端仅有 SupervisionLog 与 SupervisionInspection 两个纯 CRUD 实体/控制器，前端 supervision/inspections.vue 是一张手填表单（手动下拉选旁站/巡视/平行检验/监理通知，手填部位与内容，手点\"闭环复核\"改状态）。我尽力反驳但五项自动化能力逐条确认全缺：①材料复验自动送检——全库无任何复验/送检实体、字段或触发逻辑，TriggerRuleEngine 里零条 supervision 联动，\"平行检验/隐蔽工程\"只是 inspectType/logType 的枚举字符串和种子文本；②隐蔽工程影像/坐标/时间戳门禁——SupervisionInspection 与 SupervisionLog 实体均无 photo/image/attach/lat/lng/坐标/gps 任何字段，更无门禁校验，Evidence/LabInstrument 也无 supervision 关联；③旁站计划自动生成+移动打卡——无任何计划生成器，MobileCheckin 是移动工作台的通用外勤打卡（上班/外勤/拜访/下班），与监理旁站计划零关联，不存在\"计划自动生成→移动端按计划打卡\"链路；④平行检验仪器采集+偏差预警——平行检验只是一种自由文本记录类型，无仪器数据采集字段、无阈值/偏差/预警判定逻辑（偏差预警仅 BizPlanController 营销计划里有，与监理无关）；⑤整改线上派单——整改是 rectifyStatus 一个状态字段，由 /{id}/close 手动复核翻转，不派发 WorkOrder、不经任何规则引擎下游联动。属\"表面有逻辑、深水自动化全缺\"，判定 LOGIC_GAP 成立。",
   "reEvidence": "后端：oa-backend/src/main/java/com/kaidi/oa/web/SupervisionInspectionController.java（纯CRUD+手动/{id}/close，无送检/坐标/派单）、domain/SupervisionInspection.java（字段仅 part/content/conclusion/rectifyStatus，无photo/lat/lng/instrument）、web/SupervisionLogController.java 与 domain/SupervisionLog.java（同为纯CRUD，无geo/影像字段）、service/TriggerRuleEngine.java（grep 无任何 supervis/复验/旁站/平行/隐蔽 联动）、domain/MobileCheckin.java + web/MobileCheckinController.java（通用外勤打卡，与监理无关联）。前端：ofbiz-framework/plugins/modern-ui/app/src/oa/pages/supervision/inspections.vue（手填表单，inspectType 手动下拉，闭环靠 ElMessageBox 手填复核结果）、src/data/oaModules.ts:534-543（supervision 模块仅 logs/projects/inspections/measurement/acceptance 五个 list 页，无复验/旁站计划/仪器采集/派单入口）。验证命令：grep -rniE \"复验|送检|隐蔽工程影像|旁站计划|偏差预警|geofence|派单\" 监理相关文件与实体均为空，仅 DataSeeder.java 含若干文本字符串。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "4. 施工进度控制",
   "verdict": "MISSING",
   "gap": "进度计划报审、进度跟踪与偏差预警(S曲线/阈值自动推送总监建设单位)、进度滞后分析三个子功能 0 实现。",
   "severity": "high",
   "evidence": "全库搜索无施工进度计划报审/S曲线/偏差预警/滞后分析实体：ScheduleEvent.java 是通用日程(title/type/startTime/owner)，BizPlanController 是业务/经营计划，均非施工进度。无 progressPlan/schedulePlan/scurve/偏差预警 任何代码，无承载页(oaModules supervision 仅 logs/projects/inspections/measurement/acceptance 5 项)。",
   "survives": true,
   "reNote": "缺口属实。工程监理部\"施工进度控制\"的三个子功能(进度计划报审、进度跟踪与偏差预警含S曲线/阈值推送总监及建设单位、进度滞后分析)在前后端均0实现。后端 supervision 域(SupervisionProject/SupervisionInspection/SupervisionLog/MeasurementPayment/CompletionAcceptance)只覆盖监理项目主档、质量安全旁站巡视平检、监理日志、计量支付、竣工验收——无进度计划基线、无计划vs实际、无S曲线、无阈值偏差预警推送、无滞后分析。前端 supervision 页仅 projects/logs/measurement/acceptance/inspections 五页,oaModules.ts 监理菜单也只这五项,无进度控制入口。kaidiDeptView.ts 工程监理部里\"施工进度控制\"虽标 status:\"built\",但 path 是通用 /goal/project(pageLabel 项目/任务)——只是重定向到通用WBS任务页(goal/project.vue 仅 import Project/ProjectTask 的普通任务列表),属占位重定向而非真实现。别处的相邻功能(ProjectCostControlController 的 SPI进度滞后属成控部挣值法、BizPlanController 偏差预警属经营计划、SentimentController 阈值推送属舆情)均不在监理域、不覆盖此三子功能。",
   "reEvidence": "后端控制器: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SupervisionProjectController.java (overview只汇总inspections/payments/acceptance,无进度); SupervisionInspectionController.java; SupervisionLogController.java。领域: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/SupervisionProject.java (字段无任何进度计划/基线/百分比); SupervisionInspection.java (注释明示=施工过程质量控制,旁站/巡视/平检)。前端页: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/supervision/ 仅 projects.vue/logs.vue/measurement.vue/acceptance.vue/inspections.vue。模块菜单: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:534-543 仅5个子项无进度。关键证据(占位重定向): /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts 工程监理部块内 {\"name\":\"施工进度控制\",\"status\":\"built\",\"path\":\"/goal/project\",\"pageLabel\":\"项目/任务\"} —— 重定向到通用任务页 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/goal/project.vue(import Project,ProjectTask 的普通WBS列表,无S曲线/偏差/报审)。活体探测(127.0.0.1:8091,admin token): GET /api/oa/supervision-projects/1/progress=404, /api/oa/supervision-progress=404, /api/oa/schedule-plans=404,而 /api/oa/supervision-projects/1/overview=200(证明服务在跑且进度端点确不存在)。全库 grep \"进度计划报审/S曲线/阈值推送总监/进度滞后分析\" 在 supervision 域零命中;唯一阈值推送命中是 SentimentController(舆情),唯一SPI进度滞后命中是 ProjectCostControlController(成控部挣值法),均不属监理且不覆盖此三子功能。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "5. 投资控制（工程计量与支付）",
   "verdict": "PARTIAL",
   "gap": "计量依据未与工序验收/合同单价自动联动(纯手工录)，变更与签证管理(关联变更单/工程量确认/超比例预警)与索赔管理两子功能无承载。",
   "severity": "med",
   "evidence": "工程款支付核心到位且算法正确：MeasurementPaymentController /{id}/approve 录核定金额→自动算核减(Money.sub)、校验核定≤申报；/{id}/issue 支付证书 payable=核定-质保金-预付款抵扣(不小于0)、须先已核定、防重复签发(409)，金额全 BigDecimal(Money 收口)。但计量依据未联动：declaredQty 为自由文本、declaredAmount 手工录，控制器无任何 inspect/工序验收/合同单价/unitPrice/工程量引用，确为纯手工核定额。变更与签证管理、索赔管理两子功能无监理侧承载(ContractChange 是合同中心通用变更，无工程量确认/超比例预警/影像；无 claim 实体)。",
   "survives": true,
   "reNote": "缺口属实，三条子项全部成立，无法推翻。1) 计量纯手工：MeasurementPaymentController.create/update 中 declaredQty 为自由文本 String（如\"砼浇筑320m³\"）、declaredAmount 为手填 Double，approve 仅记录手填 approvedAmount；全链路无 PriceItem(合同单价)、无 SupervisionInspection(工序验收，该实体本身也只有结论/整改字段、无工程量与单价)联动；grep 在 measurement 控制器/实体/前端对 PriceItem、unitPrice、priceItemId、合同单价、工序验收 命中数为 0；前端 measurement.vue 表单(第198-209行)全是手工输入框。2) 变更与签证管理：supervision 模块(oaModules.ts 534-543)子菜单仅 监理日志/监理项目/监理记录/计量支付/竣工验收 五项，无变更签证页；全后端\"签证\"仅 DataSeeder.java:1373 一条用章种子(\"现场签证单\")，非结构化管理；EngineeringChange 是研发中心产品 ECO(表 rd_engineering_change)，DesignChange 是设计中心设计变更，ContractChange 是合同中心变更终止，均非监理域的工程量确认/签证；全库无\"超比例/over-ratio/工程量确认\"任何预警逻辑。3) 索赔管理：grep \"索赔/claim\" 仅命中 ExpenseClaim(财务费用报销)，与工程索赔无关，无任何工程索赔实体/控制器/页面。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/MeasurementPaymentController.java (declaredQty=String/declaredAmount=Double 手工, approve 手填 approvedAmount, 无 PriceItem/inspection 引用); domain/MeasurementPayment.java (无 unitPrice/priceItemId/inspectionId 字段); domain/SupervisionInspection.java (仅 conclusion/rectify 字段, 无工程量/单价); domain/EngineeringChange.java(表 rd_engineering_change, 研发ECO); web/DesignChangeController.java(设计研究中心); seed/DataSeeder.java:1373(唯一\"签证\"=用章种子)。前端: ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts 第534-543行(supervision 仅5子页, 无变更签证/索赔); src/oa/pages/supervision/measurement.vue 第60-66、198-209行(form 全手工录入, 无单价/验收选择); src/oa/pages/supervision/ 目录仅 logs/projects/inspections/measurement/acceptance.vue。grep 验证: 全后端\"超比例/工程量确认/over-ratio\"命中0; \"索赔/claim\"仅 ExpenseClaim(费用报销)。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "6. 安全生产管理",
   "verdict": "PARTIAL",
   "gap": "安全方案审查、安全教育交底+特种作业证预警、安全事故上报+应急预案、重大隐患自动停工四项缺失或仅手工；安全检查台账非监理专属。",
   "severity": "med",
   "evidence": "SafetyCheck.java 确有安全检查与隐患整改闭环承载(code/type/location/projectId/level/finding/rectifyStatus/dueDate)，但是通用 EHS 检查台账(挂在统一EHS模块,无 supervisionProjectId 关联,非监理专属)。其余四项核查为缺失或仅手工：无安全专项方案审查实体(临时用电/吊装/消防报审)；无安全教育交底+特种作业证预警(PersonnelCert 通用且无交底记录关联)；无安全事故上报+应急预案流程；重大隐患「自动」停工无规则引擎承载(仅 SupervisionInspection 可手工录结论=停工)。",
   "survives": true,
   "reNote": "缺口属实(PARTIAL)。我尽力反驳，但工程监理部/设计研究中心的\"安全生产管理\"链确有多项关键能力缺失或非监理专属，证据压倒性。逐项核：\n\n1) 安全方案审查(安全专项方案+专家论证)：缺失。全仓仅 DesignDoc 有\"专项方案\"作为文档类型走通用 reviewStatus(可研/初设/施工图/计算书/专项方案)，无安全专项方案审查+专家论证的专门流程。grep \"方案审查/专家论证\" 仅命中 DesignDocController/DataSeeder 的设计文档场景。\n\n2) 安全教育交底+特种作业证预警：交底=缺失(grep \"安全教育/交底/三级教育/班前/安全培训\" 零命中，唯一\"交底\"是 IpAssetController:155 的专利技术交底书，无关)。特种作业证预警=半自动且非监理专属：PersonnelCert 支持\"特种作业证\"类型，AlertController.aggregate() 按 status(即将到期/已过期)聚合\"证件预警\"(状态字段驱动,无定时算期作业把 expireDate 翻成状态)，EhsBoardController.certKpi(L202-217)按 expireDate+30d 算到期 KPI——但都属统一EHS中心,且 PersonnelCertController 自身只有 CRUD 无 alert 端点。\n\n3) 安全事故上报+应急预案：事故上报=已实现(EhsIncidentController 快速上报+按等级算法定上报截止日 computeDeadline+调查→整改→结案状态机+一键生成CAPA+/alerts/report 法定到期预警,非手工)；但应急预案=缺失(grep \"应急/预案/演练\" 仅命中 FavoriteController:59 收藏夹里一个字符串名\"应急预案与演练记录\"和\"应急管理厅\"发证机构名,无应急预案/演练实体/控制器)。\n\n4) 重大隐患自动停工：缺失。EhsHazard 有完整闭环状态机(待整改→整改中→待复查→已闭环)+逾期扫描(scanOverdue 仅落\"已逾期\")+CAPA升级+风险值红/橙/黄/蓝分级,但对\"重大/红\"隐患无任何自动停工触发；TriggerRuleEngine 无安全相关规则；SupervisionInspection 的\"停工\"只是 conclusion 取值,defaultRectify 仅把整改默认态置\"待整改\",不级联停工。grep \"停工/停产/stopWork/suspend\" 全部命中点均无自动停工逻辑。\n\n5) 安全检查台账非监理专属：属实。SafetyCheck/EhsHazard/EhsIncident/EhsWorkPermit 均归属\"统一EHS\"中心(前端 oaModules.ts:344 ehs 模块 + oa/pages/ehs/*),工程监理模块(oaModules.ts:533 supervision)子项仅\"监理日志/监理项目/监理记录(旁站/巡视/平检)/计量支付/竣工验收\",无任何安全生产管理子模块;supervision 页面 grep 安全/应急/停工等仅命中 inspections.vue 的\"停工\"结论标签。\n\n可反驳的部分仅：事故上报确已实现(超手工)、证件预警有日期 KPI——这正是判 PARTIAL 而非 FAIL 的原因。但缺口点名的 安全方案审查、安全教育交底、应急预案、重大隐患自动停工 四项中四项实质缺失，且安全检查台账确非监理专属，描述准确，缺口成立。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa/web/: EhsIncidentController.java(事故上报+法定到期预警,已实现) EhsHazardController.java(隐患闭环+逾期扫描,无自动停工 scanOverdue L255-278) EhsWorkPermitController.java(危险作业票) PersonnelCertController.java(仅CRUD,无alert) AlertController.java(L103-113证件预警按status,L175-184安全隐患按SafetyCheck) SafetyCheckController.java SupervisionInspectionController.java(L156-162 \"停工\"仅默认整改态,无级联) WorkMethodController.java(工法,非安全方案审查) DesignDocController.java(专项方案=设计文档类型) QhseDashboardController.java(L102重大隐患仅计数) EhsBoardController.java(L202-217证件到期KPI)。service/TriggerRuleEngine.java(无安全/停工/隐患规则)。前端 ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:533-545(supervision 五子项无安全生产管理)、:344-356(ehs 统一中心承载全部安全功能)；oa/pages/supervision/* 无安全页。grep \"应急/预案/演练\" 零业务实现(仅 FavoriteController:59 字符串)；grep \"安全教育/交底\" 零命中(IpAssetController:155 技术交底无关)。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "7. 监理文件与报告自动化",
   "verdict": "LOGIC_GAP",
   "gap": "自动汇总当日事件、月报自动生成、通知单电子签名+签收闭环、报告一键提数、语音/模板录入全部缺失，属表面有逻辑空。",
   "severity": "high",
   "evidence": "监理日志(SupervisionLog: logType/content/problem/handleStatus + logs.vue)与监理通知(SupervisionInspection inspectType=监理通知)确有手工承载页，逻辑自洽。但需求明确的自动化全缺：日志无『自动带入当日验收/巡视/旁站/问题整改事件』聚合代码、无总监一键汇总；无监理月报自动汇总生成(无 month report 聚合端点/导出)；监理通知单无自动编号+电子签名+施工方签收回复闭环(SupervisionInspection 无 signature 字段，经 grep 确认零电子签名)；专题报告无一键提数填充；无语音/模板录入。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实。工程监理部后端只有 3 个控制器(SupervisionLog/SupervisionInspection/SupervisionProject)+MeasurementPayment+CompletionAcceptance，均为纯 CRUD+状态流转。已实现的\"自动化\"只有两处，且都不匹配本链 5 项诉求：(a) GET /supervision-projects/{id}/overview 是按项目维度的子表计数/金额汇总驾驶舱，不是按日的事件汇总；(b) POST /supervision-inspections/{id}/close 是整改复核闭环，不是通知单签收闭环。逐项核验 5 个声称缺失的能力，前后端全部零命中：1)自动汇总当日事件——SupervisionLogRepository 仅有 findByHandleStatus，无任何日期范围/按日分组查询；2)月报自动生成——全仓 supervision 范围内\"月报/monthly\"零命中，无 @Scheduled/cron，无报告生成端点；3)通知单电子签名+签收闭环——\"监理通知\"只是 SupervisionInspection.inspectType 的一个枚举值，实体无 signature/signedAt/signedBy/签收/acknowledge 任何字段，更无签收状态机；竣工/计量上的 signer/certifier 仅是自由文本姓名，非电子签名；4)报告一键提数——\"一键/提数/generate report\"零命中，无跨源取数生成报告端点；5)语音/模板录入——\"语音/voice/模板录入\"前后端零命中。前端 5 个 supervision 页(logs/inspections/projects/measurement/acceptance.vue)对 5 个关键词同样零命中。属\"表面有逻辑空\"，无法推翻。",
   "reEvidence": "后端控制器(纯CRUD)：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SupervisionLogController.java、SupervisionInspectionController.java、SupervisionProjectController.java。仅有的两处\"自动化\"不匹配：SupervisionProjectController.java:162 /{id}/overview(项目级子表汇总，非当日事件汇总)、SupervisionInspectionController.java:139 /{id}/close(整改闭环，非通知签收闭环)。Log 仓库无按日查询：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/repository/SupervisionLogRepository.java(仅 findByHandleStatus)。实体无签名/签收字段：domain/SupervisionInspection.java(监理通知仅为 inspectType 枚举值)、domain/SupervisionLog.java。grep 证据：全仓 supervision 范围\"月报/monthly\"\"一键/提数/generate-report\"\"语音/voice/模板录入\"\"@Scheduled/cron+report\"均零命中；signer/certifier 仅 CompletionAcceptance.java:65 与 MeasurementPayment 的自由文本姓名。前端：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/supervision/*.vue(5页)对 月报/当日/汇总/签名/签收/一键/提数/语音/模板录入 全部零命中。service/WorkflowService.java 与 TriggerRuleEngine.java 未引用 supervision/监理。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "8. 竣工验收与档案管理",
   "verdict": "PARTIAL",
   "gap": "监理档案数字化(全过程文件自动组卷/案卷目录/电子移交)完全缺失；预验收问题清单与整改记录未结构化关联。",
   "severity": "med",
   "evidence": "竣工预验收+正式验收+状态联动到位且实现良好：CompletionAcceptanceController acceptType(预验收/正式竣工验收)、/{id}/pass 动作含 @Transactional，正式验收通过时联动把 SupervisionProject 置『已竣工』+阶段『缺陷责任期』，防重复(409)。实体含 pendingIssues+rectifyStatus 字段但二者为自由文本，预验收问题清单与整改记录未结构化关联(非独立条目表，无逐条整改跟踪)。监理档案数字化子功能完全缺失：无文件自动组卷/案卷目录/电子移交端点(reportNo 仅一个归档号文本字段，无组卷逻辑，Archive 模块未接监理全过程文件)。",
   "survives": true,
   "reNote": "对抗复验后无法推翻，缺口属实。竣工验收主体已建（CompletionAcceptance CRUD + /{id}/pass 联动监理项目置已竣工/缺陷责任期；SupervisionInspection 旁站巡视的逐条 rectifyStatus 闭环），但缺口描述的两项具体能力确实缺失：(1) 监理档案数字化——全过程文件自动组卷、案卷目录、电子移交在全后端无任何实现。grep 组卷/案卷目录/电子移交/卷内目录/自动组卷/移交清单 命中为零；仅有的\"案卷\"字样是 CompletionAcceptance.reportNo 注释(\"案卷号\"，纯 String 字段) 和 ArchiveSubmission.archiveScope 的枚举值(\"案卷级\"，仅是范围标签)，均非功能。ArchiveSubmissionController.approve() 只是逐份资料生成一条通用 Archive 记录的\"单文件归档\"流，不会把某监理项目的全过程文件(旁站/巡视/平行检验/监理通知/计量/验收)聚合组卷，无案卷目录生成，无电子移交包/接口；ArchiveController 仅 list/get/create 三个通用端点，无组卷/移交端点；ArchiveLifecycleService 只算保存到期日/编号/借阅分级。HandoverController 是 HR 离职/调动/轮岗工作交接，与档案电子移交无关。(2) 预验收问题清单与整改记录未结构化关联——CompletionAcceptance.pendingIssues(遗留问题清单) 与 rectifyStatus 都是纯 String，无任何外键指向结构化整改记录；Rectification 域只有 findingId 关联 AuditFinding(审计监察域)，全代码无 acceptanceId/inspectionId 之类链接；SupervisionInspection 有自己的 rectifyStatus 闭环但不回链 CompletionAcceptance；前端 acceptance.vue 的遗留问题就是单个自由文本 textarea，无逐条问题清单、无逐条整改跟踪。两域结构上完全割裂。PARTIAL 判定成立。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/CompletionAcceptance.java(L52-56 pendingIssues/rectifyStatus 均为纯 String, L67 reportNo 注释\"案卷号\"); oa-backend/src/main/java/com/kaidi/oa/web/CompletionAcceptanceController.java(只有 CRUD + /{id}/pass, 无组卷/移交/结构化整改); oa-backend/src/main/java/com/kaidi/oa/domain/SupervisionInspection.java(自身 rectifyStatus 闭环, 无 CompletionAcceptance 回链); oa-backend/src/main/java/com/kaidi/oa/web/ArchiveSubmissionController.java(L136-181 approve 仅逐份落一条通用 Archive, 非项目级组卷/案卷目录/电子移交); oa-backend/src/main/java/com/kaidi/oa/web/ArchiveController.java(仅 list/get/create); oa-backend/src/main/java/com/kaidi/oa/service/ArchiveLifecycleService.java(仅到期日/编号/借阅分级); oa-backend/src/main/java/com/kaidi/oa/domain/Rectification.java(L35 findingId 仅关联 AuditFinding); oa-backend/src/main/java/com/kaidi/oa/web/HandoverController.java(HR 工作交接, 非档案电子移交)。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/supervision/acceptance.vue(L170-172 遗留问题为单一自由文本 textarea, 无结构化问题清单/整改关联, 无组卷/案卷目录/电子移交)。grep 全后端 组卷/案卷目录/电子移交/卷内目录/自动组卷/移交清单 无功能性命中。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "9. 合规与审计追溯",
   "verdict": "LOGIC_GAP",
   "gap": "无符合监理规范的电子签名(数字证书/手写板)+GPS、无影像水印+部位检索、无对外只读审计查询导出端口。",
   "severity": "high",
   "evidence": "OperationAuditLogController 提供通用系统审计日志(by-operator/by-resource/chain/verify)可对操作留痕兜底，但达不到监理规范要求：(a) 全库 grep 确认监理关键动作(验收结论/计量确认/通知单签发/整改复核)无符合规范的电子签名(无手写板/数字证书)与 GPS 位置；(b) 无影像资料管理实体，无水印(时间/地点/拍摄人/部位)与按部位/时间检索；(c) OperationAuditLog 非面向建设单位/审计机构的只读查询导出端口(无 export 端点、无质量验收/计量支付/整改闭环记录的对外只读口径)。",
   "survives": true,
   "reNote": "缺口属实。三项专为工程监理域要求的合规/审计能力均未实现。(1) 监理电子签名+GPS：SupervisionInspection/SupervisionLog 域对象只有 inspector/supervisor 纯文本字段，无任何数字证书、手写板签名图、签名流水或经纬度/GPS 字段；全库 grep signaturePad/手写/数字证书/signatureImage 零命中（唯一 \"signature\" 命中是 MoneyParser，与签名无关），GPS(lat/lng) 只存在于无关的移动打卡 MobileCheckin 模块，监理记录创建接口(InspectionRequest)也无定位入参。(2) 影像水印+部位检索：监理前端 inspections.vue 连照片/影像上传都没有(无 upload/附件/image)，更无水印；part 仅为自由文本(如\"3层②~⑤轴砼浇筑\")，无按部位的影像检索；watermark/水印 命中全在无关的档案库 archive/library.vue、知识库 libmgr.vue、FilePreview.vue 及 ArchiveLifecycleService 的借阅密级注释里。(3) 对外只读审计查询导出端口：存在通用只读防篡改审计日志 OperationAuditLogController（哈希链 verify），但它(a)只有 5 个 GET 查询端点，无任何导出端点(无 csv/export/produces/ResponseEntity 文件流)，(b)非监理域专用、也非\"对外\"，且受 SENSITIVE_READ_PREFIXES 门槛(ADMIN/APPROVER)，不构成对外只读查询导出口。三项要求均找不到实现。建议保留该缺口，仅对(3)可注明已有内部通用审计查询底座但缺导出与对外只读视图。",
   "reEvidence": "域对象无签名/GPS/水印字段：oa-backend/src/main/java/com/kaidi/oa/domain/SupervisionInspection.java(字段仅 inspector/part/content 等)、domain/SupervisionLog.java(字段仅 supervisor/content)。监理写接口无定位/签名入参：web/SupervisionInspectionController.java InspectionRequest record(L66-71)。GPS 仅在无关模块：domain/MobileCheckin.java(lat/lng)。监理前端无影像上传/水印/签名/导出：grep inspections.vue/acceptance.vue 全部零命中(仅 el-empty 文案)。监理目录 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/supervision/ 仅 acceptance/inspections/logs/measurement/projects 五页。审计日志无导出端点：web/OperationAuditLogController.java 仅 @GetMapping 列表/详情/by-operator/by-resource/chain/verify(L51-120)，无 export/csv/produces；类注释 L18-27 明确\"只读、刻意不提供删改\"，受 SENSITIVE_READ_PREFIXES 门槛。watermark 命中全在档案/知识/预览域：FilePreview.vue、archive/library.vue、knowledge/libmgr.vue、service/ArchiveLifecycleService.java:77(借阅密级注释)。"
  },
  {
   "area": "设计研究中心/工程监理部",
   "module": "10. 与其他部门的接口要求",
   "verdict": "LOGIC_GAP",
   "gap": "六类接口(规划设计/咨询可研院/实验室/申报服务部/施工方/建设单位)仅静态弱外键，无自动取数/自动推送/外部门户提交；引擎无监理/材料联动规则。",
   "severity": "high",
   "evidence": "六类接口仅有静态弱外键沾边：SupervisionInspection.designDocId 关联 DesignDoc(规划设计部图纸)、SupervisionProject.projectId/contractId 关联 Project/Contract，均为存外键不强约束(domain 注释自述『弱关联』)。无任何自动取数(如据实验室检测报告自动判材料合格)、无自动推送(月报/支付证书推建设单位)、无外部门户/APP 供施工方建设单位提交。TriggerRuleEngine 经核实硬编码规则仅 payment/contract/project/seal/supplier，无 supervision/material/measurement 规则，跨部门联动空缺。",
   "survives": true,
   "reNote": "缺口属实。设计研究中心/工程监理部对\"与其他部门的接口\"（规划设计/咨询可研院/实验室/申报服务部/施工方/建设单位六类）确实只做了静态弱外键/自由文本字段，无任何自动取数、自动推送或外部门户提交；规则引擎也无监理/材料联动规则。我尽力寻找反证但未能推翻。关键点：(1) SupervisionProject 实体注释自认 projectId/contractId 与 Project、Contract「弱关联（仅存外键，不强约束）」，owner(建设单位)/constructor(施工方) 为纯文本；(2) 设计立项页 planning.vue 的「来源/咨询可研院」是静态下拉、「可研报告号」是手填文本，无从咨询院取数；(3) SupervisionInspection.designDocId 直接由请求体写入（第92/112行），不向设计文档系统自动拉取；(4) 唯一的外部对接框架 IntegrationController+MockSyncAdapter 是明示的模拟通道「不实连任何外部系统」，且为通用同步，未接任何一类监理接口；所有 Supervision*/Design* 控制器内无 RestTemplate/WebClient/HttpClient/外部 URL 调用，无对外提交门户；(5) TriggerRuleEngine 仅 7 条硬编码 ruleKey(payment/receipt/contract/project/seal/supplier) + 通用可配置规则，无监理或材料联动规则。注意：存在的 DesignInterface 实体是设计内部\"专业间提资\"(建筑→结构)，与缺口所指六类跨部门外部接口是两回事，不构成反证。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/SupervisionProject.java:16-17,36-49（弱外键自述+纯文本建设单位/施工方）; oa-backend/src/main/java/com/kaidi/oa/web/SupervisionProjectController.java（全 CRUD，无外部 HTTP/取数/推送）; oa-backend/src/main/java/com/kaidi/oa/web/SupervisionInspectionController.java:92,112（designDocId 由请求体直写，无自动取数）; oa-backend/src/main/java/com/kaidi/oa/service/MockSyncAdapter.java:9-37（明示模拟通道，不实连外部，TODO 真适配器）; oa-backend/src/main/java/com/kaidi/oa/web/IntegrationController.java（通用同步框架，未绑定监理六接口）; oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java:676-686（7 条硬编码 ruleKey，无监理/材料联动）; ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/planning.vue:73,303-304（来源静态下拉/可研报告号自由文本）; ofbiz-framework/plugins/modern-ui/app/src/oa/pages/design/interfaces.vue:11-12（DesignInterface 为设计内部专业间提资，非跨部门外部接口）"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "1. 销售与合同管理",
   "verdict": "PARTIAL",
   "gap": "缺项目化销售主线：销售订单未自动生成项目编号并关联设备清单/技术参数/交付现场；Contract 无对应字段；无按项目跟踪销售进度的状态链；无关联历史项目成本的报价单实体。",
   "severity": "high",
   "evidence": "Contract.java（domain/Contract.java）字段仅 code/name/type/partyA/partyB/amount/projectId/companySubject/signDate/status/paidAmount/invoicedAmount/custodian/parentId，无设备清单/技术参数/交付现场字段。无独立报价单(Quote)实体，PriceItem 为价格主数据非按设备类型快速生成报价。TriggerRuleEngine 仅做合同生效→用章→项目立项→档案级联，销售订单不自动生成项目编号关联设备清单，无『技术确认→排产→发货→安装→验收』按项目跟踪。维持初判。",
   "survives": true,
   "reNote": "缺口属实。制造管理中心/环保设备制造中心缺项目化销售主线，四项子缺口全部成立：(1) 无销售订单实体——后端无 SalesOrder 控制器/实体/repo（仅 DesignChangeOrder/MaintOrder/MealOrder/PrototypeOrder/WorkOrder，均非项目化销售订单），更无\"销售订单自动生成项目编号\"逻辑；TriggerRuleEngine 只在项目验收时生成档案、按项目名/编号匹配已有 Project，不从销售单据创建带编号的项目；Project 实体本身也无 code/项目编号字段。(2) Contract 实体无设备清单/技术参数/交付现场任何对应字段（仅 code/name/type/partyA/partyB/amount/projectId/companySubject/signDate/status/paidAmount/invoicedAmount/custodian/parentId）。(3) 无按项目跟踪销售进度的状态链（销售进度/sales progress/销售状态 全零匹配）。(4) 无关联历史项目成本的报价单实体——\"报价\"仅出现在 CRM Opportunity 阶段标签(方案报价)与 BidTask 任务类别(报价测算)，均非报价单实体且不挂历史成本；MfgProjectCostController 仅做实际vs标准成本只读对比，不产出报价单。前端 mfg 模块 14 个子菜单(生产工单/库存/发货售后/MRP/领料/报工/质量/项目成本归集等)也无项目化销售主线页或报价单页。对抗性推翻失败。",
   "reEvidence": "Contract.java(domain) 字段无 equipment/设备/techSpec/技术参数/deliverySite/交付/现场/清单 —— grep 零命中；后端 web/ 无 Sales*/Quotation* 控制器，grep salesOrder/销售订单 零命中；TriggerRuleEngine.java:347-376 仅项目验收→档案，:479-482 按项目名/编号匹配已有 Project（不创建编号）；Project.java 无 code/项目编号字段；销售进度/sales progress 全局零匹配；报价 仅 Opportunity.java:15 阶段\"方案报价\"与 BidTask.java:13,34 任务类别，非报价单实体；MfgProjectCostController.java 为只读成本归集对比，无报价单产出；前端 oaModules.ts:465-484 mfg 子菜单与 pages/mfg/ 目录均无销售主线/报价单页。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "2. 技术设计与BOM管理(EBOM/MBOM)",
   "verdict": "PARTIAL",
   "gap": "①设计任务未由合同签订自动生成；②BomItem 无 EBOM/MBOM 区分字段、无版本号，BOM 版本控制缺失；③参数化选型生成 BOM 子项完全无实现；④图纸发放车间电子签名+版本确认未见端点。",
   "severity": "high",
   "evidence": "DesignTaskController/DesignProjectService 对 contract/合同/自动生成 零命中；TriggerRuleEngine 合同生效后仅级联用章，无 chainCreateDesignTask，设计任务仍手工建（projectId 手填）。BomItem.java 仅有 parentId(多级)+unitUsage+signStatus，无 EBOM/MBOM 区分字段、无版本号字段。参数化配置(按流量/扬程/功率自动选型生成BOM子项)全代码无命中。图纸发放车间电子签名+版本确认无对应端点（BomSignoff 是会签链非图纸发放确认）。维持初判。",
   "survives": true,
   "reNote": "无法推翻，缺口属实。逐条核验制造管理中心/环保设备制造中心的「技术设计与BOM管理(EBOM/MBOM)」链，四项分缺口全部成立：①设计任务非由合同签订自动生成——ContractController 不引用 DesignTask/DesignProject，DesignTaskController 不引用合同，TriggerRuleEngine 无任何创建设计任务的规则（全库 grep 合同签订→生成设计任务 零命中），设计任务靠 DesignTaskController 人工建。②BomItem 实体确无 EBOM/MBOM 区分字段（无 bomType）、确无版本号字段（无 version/bomVersion），全库 grep EBOM/MBOM/bomType/bomVersion 零命中；现有 BomItem 是投标工程量清单BOM(bidQty vs actualQty 比对+多级上卷+MRP展开+五签会签)，非工程/制造BOM，无版本控制。③参数化选型生成BOM子项 完全无实现（grep 参数化选型/选型生成/configurator 零命中）。④图纸发放车间电子签名+版本确认 无端点（grep 图纸发放/发放车间/车间签收/releaseDrawing 零命中）。注意:存在多个易被误认的近邻实现但均不对位——FertRecipe(生物质肥料制造中心)有配方版本状态机+生效通知车间，但属肥料配方非设备EBOM/MBOM；DesignChangeOrder.implement 仅在变更实施时对图纸做 version+0.1 留痕，是设计变更工作流非图纸发放签收；TestReport/ServiceTicket/CslReport 有电子签名但均非图纸发放场景。",
   "reEvidence": "domain/BomItem.java(21-175 无bomType/无version字段,仅bidQty/actualQty/unitUsage/signStatus); web/BomItemController.java(投标量比对+/tree上卷+/mrp展开+/{id}/sign五签,CreateBomItemRequest 无type/version入参); domain/DesignTask.java + service/DesignProjectService.java(设计任务为人工WBS分解,立项→方案→初设→施工图状态机,与合同无联动); service/TriggerRuleEngine.java(七条ruleKey:payment.create/contract.effectivate/project.create/project.accept/seal.markUsed/supplier.admit/ruleconfig:*,无一创建DesignTask); web/FertRecipeController.java(配方版本控制+approve通知车间,属肥料制造非设备EBOM/MBOM); web/DesignChangeOrderController.java(implement 仅版本+0.1留痕,非图纸发放签收); 全库grep:EBOM/MBOM/bomType/参数化选型/图纸发放/合同签订→设计任务 均零命中"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "3. 生产计划与排程(MRP/MPS/APS)",
   "verdict": "PARTIAL",
   "gap": "缺项目化主生产计划 MPS(按项目编制设备生产节点+甘特图)；缺车间排程 APS(有限能力排程/拖拽/负荷率/插单模拟)。仅有 MRP 净需求与齐套。",
   "severity": "high",
   "evidence": "MrpService.java 仅做多级 BOM 展开毛需求、冲减库存/在制/在途算净需求并给采购/生产建议(纯只读不落库)。无 MPS 实体(按项目编制下料→焊接→机加工→涂装→组装→调试生产节点+甘特图项目级进度)；无 APS 排程引擎(按车间/产线/设备/人员有限能力排程、拖拽调整、负荷率、紧急插单模拟)。WorkOrder.java 仅 planQty/plannedDate/status/workshop，无排程能力。维持初判。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。制造管理中心仅实现 MRP 净需求计算，确无项目化 MPS(设备生产节点+甘特)与车间 APS(有限能力/拖拽/负荷率/插单模拟)。后端 MrpController(/api/oa/mrp) 仅 /products(列 BOM 顶层) 与 /run(算逐物料净需求，Javadoc 明言\"运算不落库,纯只读计算\")；MrpService/WorkOrderController/WorkPlanController 对 schedul/排程/排产/capacity/负荷/甘特/插单/工作中心/finite-capacity 零命中。前端 mfg 模块 submenu(oaModules.ts) 列工单/库存/MRP/车间报工等13项，无 MPS/APS 任何入口；mfg.ts/mfgExec.ts/mrp.ts API 无排程类端点。全库唯一\"甘特\"出现在 DevWbsTask.java(研发WBS阶段)与 goal/project.vue(目标管理通用任务甘特)，均非制造中心的设备生产节点 MPS，也无负荷率/拖拽/插单 APS。判定 PARTIAL 准确。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/MrpController.java(仅/products+/run净需求,L18-23 Javadoc\"按多级BOM展开毛需求...算出净需求与采购/生产建议\",L69-74\"运算不落库纯只读计算\"); oa-backend/src/main/java/com/kaidi/oa/service/MrpService.java(无schedul/capacity/负荷/甘特/插单命中); oa-backend/src/main/java/com/kaidi/oa/web/WorkOrderController.java 与 WorkPlanController.java(无排程/有限能力/工作中心命中); ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:465-483(mfg submenu无MPS/APS项); ofbiz-framework/plugins/modern-ui/app/src/oa/api/{mfg.ts,mfgExec.ts,mrp.ts}(无排程端点); 全库\"甘特\"仅 oa-backend/.../domain/DevWbsTask.java:17,29(研发WBS) 与 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/goal/project.vue:117,160,354(目标管理通用任务甘特),非制造排程。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "4. 采购与供应商管理",
   "verdict": "LOGIC_GAP",
   "gap": "①无采购申请/PO 实体，MRP→采购申请不自动，PO 不能关联项目/任务号归集成本；②Supplier 过薄无资质/评价/合格名录；③外协管理完全无；④外购件 IQC 无采购到货自动触发闭环(QcInspection 可手填 IQC 但不与采购单联动)。",
   "severity": "high",
   "evidence": "全代码搜 PurchaseOrder/PurchaseRequisition/采购申请/采购订单仅命中 MrpService 注释一处，无采购申请/PO 实体——MRP 结果只返回建议不生成采购单，无法关联项目/任务号归集成本。Supplier.java 仅 name/creditCode/category/contact/phone/bankName/bankAccount/status，无 ISO/环保认证/业绩资质、无质量/交期/价格评价记录、无合格供应商名录。外协/subcontract/outsourc 在 web/domain 无制造外协实体(仅 Budget/ExpenseClaim 等费用文本字段命中)。IQC 仅 FeedstockBatch(生物质原料)+QcInspection 有 IQC 类型(可登记外购件来料检验)，但无采购到货自动触发 IQC 闭环。维持初判。",
   "survives": true,
   "reNote": "缺口属实，四条子项全部成立，未能推翻。①无采购申请/PO 实体：domain/web 里只有 WorkOrder/MaintOrder/MealOrder/DesignChangeOrder/PrototypeOrder 等，无 PurchaseOrder/PurchaseRequisition；AdminRequisition 是对库存出库的「物资领用申请」(出库流水 stockMoveId)，非向供应商下达的采购申请。MrpService/MrpController 只算净需求并返回文本建议(action=\"建议采购\"/\"建议生产\")，MrpController 注释明写「运算不落库（纯只读计算）」，采购在途(inTransit)需调用方手动传入因「无独立单据表」——故 MRP→采购申请不自动、无 PO 可关联项目/任务号归集成本。②Supplier 过薄：仅 name/creditCode/category/contact/phone/bank/status，无资质证书/有效期/评分；唯一「评价」是 QcInspectionController.supplierQuality() 的 IQC 合格率只读聚合，非落库评价；status 只是「合格/准入中/停用」free string，非带准入闸的合格名录(MarketQualification 是市场部自家投标资质库，与供应商无关)。③外协完全无：全库 外协 命中仅预算成本要素字符串「外协费」与成本归类，无外协订单实体/流程/控制器。④IQC 无采购到货自动触发闭环：QcInspection 无 PO/到货单关联字段，IQC 记录纯手工 create；/judge 状态机仅把不合格 IPQC 退回生产工单，无任何「采购到货→自动建 IQC」触发。TriggerRuleEngine.ruleAdmitSupplier 仅在审批办结时把供应商置「合格」或新建一条，属准入状态翻转，救不了上述任一条。",
   "reEvidence": "domain/AdminRequisition.java(物资领用/出库非采购); service/MrpService.java:33-35,52-57,218-228(只输出文本建议action,不建单据); web/MrpController.java:22-24,66-74(运算不落库,inTransit需手传因无单据表); domain/Supplier.java:15-107(无资质/评价/名录字段); web/SupplierController.java(仅CRUD+信用代码查重); web/QcInspectionController.java:89-129(IQC手工create无PO字段),174-228(/judge仅退回WorkOrder,无采购到货触发),280-300(supplier-quality只读聚合); domain/QcInspection.java:36-92(无poNo/采购到货关联字段); domain/MarketQualification.java:12-26(市场部投标资质库,非供应商); grep 外协 仅命中 Budget/CslEstimateItem/ProjectCostControlController 成本要素字符串(无外协订单实体); service/TriggerRuleEngine.java:416-448(ruleAdmitSupplier 仅置合格/新建,非资质评价/采购联动)"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "5. 生产执行与车间管理",
   "verdict": "PARTIAL",
   "gap": "①领料无限额/超领审批；②物料条码/批次追溯字段缺；③在制品按工序数量/位置跟踪缺；④生产异常拍照上报+通知+闭环无端点。报工/工单/IPQC 链扎实。",
   "severity": "med",
   "evidence": "MaterialIssueController.java 仅校验物料名必填+数量>0，无按工单 BOM 限额校验、无超领审批(grep 限额/超领/quota/limit 零命中)。MaterialIssue.java 无批次/条码/二维码字段，无贵重物料批次追溯。无 WIP-by-process 在制品实体(grep 在制品/wip 仅命中 MrpService 在制供给计算与 EngineeringChange 影响分析，非按工序数量/位置跟踪)。生产异常管理(现场拍照上报+通知责任人+闭环时长)无对应端点(DataCenter 的命中无关)。ProductionReport(报工)+WorkOrder+QcInspection(IPQC 返工)链扎实。维持初判。",
   "survives": true,
   "reNote": "尽力推翻但缺口属实(PARTIAL 判定成立)。生产执行主链(报工 ProductionReportController / 工单 WorkOrderController / 齐套检查 / IPQC QcInspectionController)确实扎实,但4条子缺口全部坐实:\n\n① 领料无限额/超领审批——属实。MaterialIssueController.create/update 仅校验 qty>0 与有限数(nzFinite),无 BOM 配额上限、无库存可领量校验、无超领审批闸。ProductionReportController 的 kitting() 仅为开工前只读预警(无 BOM 时还直接视为齐套放行),并不在领料写口拦截。\n\n② 物料条码/批次追溯字段缺——属实(就环保设备制造链而言)。MaterialIssue.java、WorkOrder.java 域对象均无 batchNo/barcode/serialNo 字段。系统里确有批次追溯,但属于\"生物质肥料制造中心\"(FeedstockBatch 原料批次、FermentBatch 发酵批次,逆向溯源)与\"行政后勤食材\"(FoodBatch),都不是本缺口指向的设备制造 WorkOrder/MaterialIssue 链。QcInspection 虽带 batchNo/serialNo,但那是 IPQC 记录(缺口已认其扎实),非领料/在制品流转。\n\n③ 在制品按工序数量/位置跟踪缺——基本属实。ProductionReport 记录每工序完工/合格/不良数量(工序数量维度部分存在),但无独立 WIP 实体、无在制品位置/工位字段,无法按位置跟踪在制品。\n\n④ 生产异常拍照上报+通知+闭环无端点——属实。无任何生产异常控制器;MonitorExceptionController 属内控/审计监察域(规则命中转审计发现),与车间生产异常无关。所有生产实体均无 photo/附件字段,无通知触发,无车间异常闭环处置端点。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/MaterialIssueController.java (create/update 仅 qty>0+nzFinite,无超领/限额/审批); oa-backend/src/main/java/com/kaidi/oa/domain/MaterialIssue.java + domain/WorkOrder.java (无 batchNo/barcode/serialNo 字段); oa-backend/src/main/java/com/kaidi/oa/domain/ProductionReport.java (有 process/qty/qualifiedQty/scrapQty,但无 WIP 位置/工位字段); oa-backend/src/main/java/com/kaidi/oa/web/ProductionReportController.java (kitting 仅只读预警,无 BOM 时直接放行); grep '生产异常|拍照|production.?exception|shopfloor' web/*.java domain/*.java 命中 0; MonitorExceptionController.java 属审计监察域非生产; 批次追溯仅在 domain/FeedstockBatch.java(生物质肥料中心)/FermentBatch.java/FoodBatch.java(食堂),非设备制造链; QcInspection.java 带 batchNo/serialNo 但属 IPQC 记录。前端 ofbiz-framework/plugins/modern-ui/app/src/oa 下 grep '生产异常|拍照上报|批次追溯|条码|超领' 命中 0。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "6. 库存管理",
   "verdict": "LOGIC_GAP",
   "gap": "①多仓库/货位仅 location 字符串、无危险品库区；②无批次/序列号字段，库存侧追溯断裂；③仅有安全线状态标志，无补货建议/呆滞提醒；④盘点管理完全无。",
   "severity": "high",
   "evidence": "InventoryItem.java 多仓库/多货位仅靠 location 字符串，category 有原料/半成品/成品/辅料但无库结构/货位精细/危险品库区。无批次号/序列号字段(序列号 trace 靠 QcInspection.serialNo，库存侧断裂)。InventoryItemController 仅在 quantity<safetyStock 时置『低于安全线』状态，无自动生成补货建议、无呆滞物料(>180天)提醒(grep 180/dead/replenish 零命中)。盘点(周期/扫码盘点、盘盈盘亏报表、审批调账)全代码搜盘点/盘盈/盘亏仅命中 SoftwareLicense，库存侧无。维持初判。",
   "survives": true,
   "reNote": "缺口属实。制造管理中心\"库存管理\"模块的承载实体就是 InventoryItem，前端页 mfg/inventory.vue 直接走 listInventory/createInventory（api/mfg.ts），后端 InventoryItemController(/api/oa/inventory) + InventoryItem 实体。逐条复核四点全部成立：\n\n①多仓库/货位/危险品库区：InventoryItem 仅有一个 location 字符串字段（domain/InventoryItem.java:37），前端列就叫\"库位\"（inventory.vue:12）。无仓库实体、无货位结构、无危险品库区字段。全库 grep domain/ 下 warehouse/危险品库/hazardZone/库区 只命中 FoodBatch（食品制造中心，另一模块），与本模块无关。\n\n②批次/序列号：InventoryItem 实体无 batchNo/serialNo/lotNo 等任何批次或序列号字段（实体仅 id/materialName/category/spec/unit/quantity/safetyStock/location/status/createdAt）。活体 GET /api/oa/inventory 返回 keys 完全一致，库存侧无批次追溯。注：AdminStockMove 有 batchNo、FeedstockBatch 有 batchNo，但分属\"行政后勤物资流水\"\"生物质原料到货批次\"两个独立模块，不挂在制造库存 InventoryItem 上，库存侧追溯确实断裂。\n\n③补货建议/呆滞提醒：仅有 status 标志（正常/低于安全线/超储），由 quantity<safetyStock 自动派生（Controller:83-87）。无任何 reorder/replenish 建议生成、无呆滞/stagnant 计算。活体 /api/oa/inventory/replenish 仅因匹配 /{id} 报 400，无真实端点。\n\n④盘点管理：完全无。后端无盘点实体/控制器/端点（活体 /api/oa/stocktake = 404；/inventory/stocktake 的 400 是被 /{id} 路由吞掉的解析失败而非真端点）。前端 pages/mfg/ 下 grep 盘点/盘盈/盘亏/stocktake 零命中。InventoryItemRepository 仅 findByCategory 一个方法。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/InventoryItem.java:25-41 (字段全集：materialName/category/spec/unit/quantity/safetyStock/location/status/createdAt — 无 batchNo/serialNo/危险品库区/仓库)；oa-backend/src/main/java/com/kaidi/oa/web/InventoryItemController.java:54-90,130-138 (CRUD 仅 status 由 quantity<safetyStock 派生，无补货/呆滞/盘点端点)；oa-backend/src/main/java/com/kaidi/oa/repository/InventoryItemRepository.java (仅 findByCategory)；ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mfg/inventory.vue:5-23 (列与表单字段=后端字段，无批次/盘点/危险品库区)；活体 GET /api/oa/inventory 返回 keys=['id','materialName','category','spec','unit','quantity','safetyStock','location','status','createdAt']，/api/oa/stocktake -> 404。排除项：FeedstockBatch/AdminStockMove/FoodBatch 的 batchNo 字段属其它模块，不挂 InventoryItem。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "8. 发货与现场安装调试",
   "verdict": "MISSING",
   "gap": "§8 整段无制造侧承载：无发货计划与拣货/装箱、无现场接收确认、无安装调试任务派发、无性能验收与移交。",
   "severity": "high",
   "evidence": "全代码搜发货/拣货/装箱/shipment/shipping/picking/packing 仅命中 DataSeeder/Money，无发货计划/拣货/装箱单/发货更新库存触发物流实体。无现场接收确认(扫序列号确认+上传照片签收单)实体。无安装调试任务派发(发货后自动生成安装调试任务、指派工程服务、记录调试参数)——安装调试字样散落 Financing/Sewage/Maint/Qualification 与制造侧 §8 无关。CompletionAcceptance 属工程监理(supervisionProjectId)非制造发货验收。整段 §8 制造侧无承载。维持初判。",
   "survives": true,
   "reNote": "缺口属实。制造管理中心(环保设备制造中心)的生产生命周期止于「已入库」(成品入成品库),其后再无任何制造侧出库发货/安装调试/性能验收/移交承载。逐条核验§8四要素均缺失：(1) 无发货计划与拣货/装箱——无任何 deliveryPlan/拣货/装箱/packingList/发货单/发运 实体或控制器;InventoryItem 只有 inbound 入库,无销售出库发货动作;(2) 无现场接收确认——无到货签收/现场接收实体;(3) 无安装调试任务派发——制造侧无安装/调试任务实体,『调试/试压』仅作为车间报工的工序选项(PROCESS_OPTIONS=下料/焊接/机加工/涂装/组装/调试/试压)和售后维修报告文本,非现场安装调试派单;(4) 无性能验收与移交——无设备性能验收/交付验收实体。前端 mfg 模块有 delivery 项但『发货与售后』(delivery.vue)实为 aftersales.vue 的再导出——一个售后维修服务工单闭环(报修→派单→到场→领备件→完工→关闭+SLA),与§8出库发货无关。试图反驳时考察的三个疑似承载全部证伪:CompletionAcceptanceController(竣工验收)属工程监理部(验收 SupervisionProject 而非设备性能);HandoverController(移交)是人事工作交接(离职/调动/轮岗);ServiceTicket 是售后报修。",
   "reEvidence": "制造侧控制器全集及其映射(均无发货/安装):/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/WorkOrderController.java(/api/oa/work-orders,状态机止于待生产/生产中/已完工/质检中/已入库,第29行;入库联动仅自动建成品库存,无发货)、ProductionReportController.java(报工/齐套)、MaterialIssueController.java(领料)、InventoryItemController.java(/api/oa/inventory,无销售出库发货)、MrpController.java、BomItemController.java、MfgProjectCostController.java。前端 mfg 模块定义:/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:470-483(delivery 项 path=/mfg/delivery)。发货页实为售后再导出:/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mfg/delivery.vue(仅 import AfterSales 并渲染)→ aftersales.vue(售后服务工单:报修/派单/到场/领备件/完工/关闭,状态流待派单→已派单→处理中→已完成→已关闭)。证伪的三个疑似承载:CompletionAcceptanceController.java(@RequestMapping /api/oa/completion-acceptances,工程监理部竣工验收,联动 SupervisionProject 置已竣工)、HandoverController.java(/api/oa/handovers,人事离职/调动/轮岗交接)、domain/ServiceTicket.java(售后报修字段 deviceName/faultDesc/repairReport/partsCost/satisfaction)。精确 grep 发货计划|拣货|装箱|发运单|到货签收|现场接收|安装调试|性能验收|设备移交 命中数=2 且全为假阳(Money.java 注释把 Double 比喻为『装箱』;Reagent/AdminSupply 的 outbound 是耗材领用)。mfgExec.ts:55 PROCESS_OPTIONS 含『调试/试压』但为车间报工工序选项,非现场安装调试派发。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "9. 售后服务与运维管理",
   "verdict": "PARTIAL",
   "gap": "①远程运维(物联网实时监控+异常自动报警生成工单)未实现；②质保期限/维保合同/到期提醒缺，underWarranty 仅布尔；③MaintOrder 为预防性保养未与售后维保合同打通。报修闭环+备件扎实。",
   "severity": "med",
   "evidence": "远程运维/IoT/物联网在制造侧仅 ServiceTicket.serviceType 枚举值『远程运维』一处文字，无对接物联网平台实时监控风机电流/PH/压力、无异常自动报警生成工单(物联网命中的 FermentBatch 是生物质中心)。ServiceTicket.java 质保仅 underWarranty 布尔，无质保期限/维保合同实体/到期提醒/定期巡检换滤料药剂执行/续签提醒。MaintOrder.java 为设备故障维修工单(equipmentId/fault/downtimeHours/partsReplaced)非维保合同。报修派单+维修闭环+备件 partsCost 扎实。维持初判。",
   "survives": true,
   "reNote": "缺口属实，三条子项全部成立，无法推翻。售后链由 ServiceTicket(domain/web) + mfg/aftersales.vue 承载，报修→派单→处理→领备件(原子扣库存)→客户签名完工→满意度关闭+SLA 的闭环与备件管理确实扎实，但三条短板真实存在：①远程运维仅为下拉字符串标签(mfgExec.ts SERVICE_TYPES 含\"远程运维\")，无任何物联网/传感器/实时采集实体或 ingest 端点，无实时监控面板；ServiceTicket 只能经 POST /service-tickets 人工\"客户报修\"创建(全仓 grep `new ServiceTicket` 仅手工控制器)；唯一定时器 AlertScheduler 只扫人员证照到期+表单超时，从不碰 ServiceTicket，更无异常自动报警生成工单；MonitorRule/MonitorException 是审计内控监控(大额付款/超预算)与设备 IoT 无关。②ServiceTicket.underWarranty 确为 `Boolean=TRUE` 单一布尔，前端就是一个 el-switch；无质保期限日期、无维保合同实体、无到期提醒，mfg 域 grep warrantyMonths/warrantyUntil/维保合同/质保期均零命中。③MaintOrder 仅持 equipmentId→内部 MfgEquipment(生物质厂自有设备)，无 contractId、不关联 ServiceTicket 或任何维保/质保合同，确属内部预防性保养，与售后维保合同未打通。判定 PARTIAL 准确。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/ServiceTicket.java:70 (private Boolean underWarranty = Boolean.TRUE; 无质保期/合同字段); web/ServiceTicketController.java(全程手工 CRUD+状态机,无 IoT/自动生成); domain/MaintOrder.java:34 (仅 equipmentId,无 contractId); web/MaintOrderController.java(只关联 MfgEquipment); task/AlertScheduler.java(仅扫证照+表单超时,不碰售后); domain/MonitorRule.java+MonitorException.java(审计内控监控,非设备IoT)。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mfg/aftersales.vue:221 (质保内=单一 el-switch); src/oa/api/mfgExec.ts:183 (SERVICE_TYPES 含\"远程运维\"仅字符串)。佐证: grep 全后端 warrantyMonths/warrantyUntil/maintContract/维保合同/质保期/物联网/传感器/telemetry/sensor/realtime 在 mfg 域零命中; grep `new ServiceTicket`/ticketRepo.save 仅出现在手工 ServiceTicketController。SewageEquipmentController.java:398 newOrder 是污水运营域按 runHours 的 PM 扫描生成 SewageWorkOrder,既非 IoT 实时驱动也不属环保设备制造售后域。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "10. 成本核算与财务集成",
   "verdict": "PARTIAL",
   "gap": "①成本归集缺制造费用分摊/外协/安装调试费用；②在制品成本无实现；③销售成本与收入匹配缺(且 §8 发货缺)；④mfg→财务凭证未自动触发；差异未拆量差/价差。",
   "severity": "med",
   "evidence": "MfgProjectCostController.summary 实际成本=直接材料(MaterialIssue)+直接人工(ProductionReport)+售后成本(ServiceTicket.partsCost)三项，无制造费用分摊、无外协费用、无安装调试费用归集。无在制品成本(约当产量法/实际投料)实现。无销售成本与收入匹配(发货确认收入自动结转、个别计价/移动加权平均)——且 §8 发货本就缺。Voucher 存在但 TriggerRuleEngine 无 mfg→凭证自动联动(仅付款/发票级联)。差异 variance=实际−标准为总额口径，注释虽写『量差/价差口径』但 StandardCost/MfgProjectCost 均无 priceVariance/qtyVariance 字段拆分。维持初判。",
   "survives": true,
   "reNote": "尽力推翻但未能推翻——缺口5个分项全部属实，PARTIAL判定成立。逐项核验：\n\n①成本归集缺制造费用分摊/外协/安装调试：MfgProjectCostController.summary() 实际成本只 = 直接材料(MaterialIssue领料) + 直接人工(ProductionReport报工laborCost) + 售后成本(ServiceTicket备件)，无制造费用分摊、无外协、无安装调试三项。ProductionReport实体只有laborCost(=laborHours×laborRate)，连overhead字段都没有。StandardCost虽有overheadCost字段但是手填台账值(StandardCostController注释明确写\"当前为手填+服务端自动汇总的框架实现\"，\"料/工/费的实际归集来源…属甲方核算口径\"未实现)。代码里\"外协\"全部命中在Budget/ProjectCostControl(项目造价口径)，非制造成本归集。→缺口属实。\n\n②在制品(WIP)成本无实现：全工程无WIP/在制品/workInProcess实体或控制器，\"在制品位置\"仅是FermentBatch.java一个字段注释。→缺口属实。\n\n③销售成本与收入匹配缺(且§8发货缺)：唯一收入凭证由ProjectController.generateAcceptanceVoucher在项目验收时生成，且只记收入一腿(借应收账款/贷主营业务收入)，没有配比的销售成本分录(无 借主营业务成本/贷库存商品)。无任何制造产品的发货/销售出库/销售订单/shipment/delivery实体(domain下grep ship|deliver|sales|outbound零命中)。WorkOrder\"已入库\"只建成品InventoryItem，不结转成本、不触发销售。→缺口属实。\n\n④mfg→财务凭证未自动触发：自动凭证(existsBySourceTypeAndSourceId)仅两种sourceType——\"payment\"(PaymentService放款)与\"acceptance\"(ProjectController验收)。WorkOrderController对\"已入库\"只fireInventory建库存+写AutomationLog，绝无凭证。MaterialIssue/ProductionReport/WorkOrder均无→Voucher联动。→缺口属实。\n\n⑤差异未拆量差/价差：MfgProjectCost只算单一 variance=实际−标准(docstring挂了\"量差/价差口径\"字样但无任何拆解)；StandardCost.recompute也只算 variance=actual−总标准；BomAnalysis只算单一cost overrun。全工程grep不到 stdQty×stdPrice vs actualQty×actualPrice 的量差/价差分解。→缺口属实。\n\n综上5项全部找不到实现，real=true。",
   "reEvidence": "web/MfgProjectCostController.java:79-149 (实际成本=材料+人工+售后，无制造费用分摊/外协/安装调试；variance只是actual-standard单值，line133-139); domain/ProductionReport.java:36-78 (只有laborCost，无overhead/制造费用字段); web/StandardCostController.java:34-36,70-75 (注释自承\"手填+框架实现\"，overheadCost为台账值非分摊引擎); web/WorkOrderController.java:151-179 (已入库只建InventoryItem+AutomationLog，无凭证、无成本结转); web/VoucherController.java:74-95 (凭证纯手工CRUD草稿→审核→过账，无mfg自动来源); service/PaymentService.java:113-129 (autoVoucher仅sourceType=\"payment\"); web/ProjectController.java:145-178 (generateAcceptanceVoucher仅sourceType=\"acceptance\"，且只记借应收账款/贷主营业务收入，无配比COGS分录); WIP: 全工程仅 domain/FermentBatch.java:51 \"在制品位置\"字段注释，无WIP实体/控制器; §8发货: domain下 grep ship|deliver|sales|outbound|发货 在制造域零实体命中; 量差/价差分解: 全工程 grep stdQty/actualPrice/priceVar/qtyVar 零命中真实拆解逻辑。"
  },
  {
   "area": "制造管理中心/环保设备制造中心",
   "module": "11. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "六对口模块都在但与制造中心间无显式自动取数/数据交接：设计→生产采购、实验室→QC/批次、监理→发货验收、申报数据汇集、专利/可研回链均未打通，仍靠人工。",
   "severity": "med",
   "evidence": "六个对口模块(设计/实验室/监理/申报/知识产权/咨询可研)各自存在，但 TriggerRuleEngine 级联仅覆盖合同→用章→项目→档案，无设计 BOM/工艺自动流入生产采购(BomItem 靠人工建，MRP 读 BomItem 但 BOM 非由设计输出自动落库)、无实验室复检/性能报告自动回挂 QC/批次、无监理验收回挂发货验收(§8 缺)、无设备技术参数/检测报告自动汇集给申报、无专利/可研选型回链。是『模块都在但接口未自动打通』。维持初判。",
   "survives": true,
   "reNote": "Gap is real. The six cross-department manufacturing interfaces have no automatic data fetch or handoff; they rely on manual string fields or have no linking entity, and existing automation is intra-manufacturing or read-only R&D only.",
   "reEvidence": "TriggerRuleEngine.java 7 chains untouched; QcInspection.java no sampleId; QcInspectionController.java:111-112 manual batchNo/workOrderNo; SupervisionInspectionController.java:92 manual designDocId; DesignDocController/BomItem.java no procurement link; DeclarationDashboardController.java:53-63 R&D-only; grep procurement only MealOrderController; grep shipment no entity."
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "1. 原料采购与供应商管理",
   "verdict": "PARTIAL",
   "gap": "采购/收购计划实体与端点缺失；供应商准入资料（检测报告/无害化证明）无文件附件登记字段。检验扣重与事后供应商评估已 MET。",
   "severity": "med",
   "evidence": "FeedstockBatchController.java 已强实现到货检验扣重扣价状态机（inspect 端点：水分/杂质超标按超出比例自动算 deductWeight/settleWeight/settleAmount，重金属超标强制拒收，扣重≥30%自动降级）+ FeedstockBatch.batchNo 唯一批次号+sourceOrigin 溯源 + /supplier-eval 按供应商聚合拒收率/水分波动/杂质做事后评估。FermentBatchController.charge 还按 arrivalDate FIFO 消耗合格/降级原料批次。但初判三处缺口经核实成立：(a)无任何 ProductionPlan/采购计划/收购计划实体或端点（grep MPS/生产计划/采购计划 仅命中 FermentBatch 单批次），无按生产计划+库存+季节性生成采购计划、无秸秆收购窗口期锁定；(b)Supplier.java 字段仅 name/creditCode/category/contact/phone/bankName/bankAccount/status，无检测报告/无害化证明附件或 fileId 字段。",
   "survives": true,
   "reNote": "无法推翻，缺口属实（PARTIAL 判定正确）。该链确有两块未实现，而 MET 两块已确认存在。\n\n1) 采购/收购计划实体与端点缺失——属实。制造中心后端域实体仅 FeedstockBatch(到货批次)、FermentBatch、FermentLog、MfgEquipment、FertRecipe/ChargeOrder；无任何 PurchasePlan/ProcurementPlan/FeedstockPlan/PurchaseOrder/收购计划 实体或控制器。FeedstockBatch 是\"已到货批次\"台账(有 grossWeight/arrivalDate/检验结算)，不含计划量/计划到货期/采购单概念，不构成采购计划。其余 *Plan 实体均无关：WorkPlan(工作计划)、BizPlan(经营计划)、FundPlan、BrandPlan、AdminRequisition(办公物资领用申请+定额审批，非原料采购)。全后端无 procure/purchase/收购/acquisition 路径映射；前端 mfgBiofert.ts 端点仅 feedstock/recipe/ferment/equipment/maintenance，无采购计划页；\"采购\"仅作为 kaidiDeptView.ts 里的静态部门接口标签出现。\n\n2) 供应商准入资料无文件附件登记字段——属实。Supplier 实体字段=id/name/creditCode/category/contact/phone/bankName/bankAccount/status，无检测报告/无害化证明/附件/fileId/attachment 任何字段；SupplierController 的 Create/Update 请求体同样无文件关联。Certification 实体是公司级体系认证(ISO9001/14001 等)，无供应商外键、无文件字段，不等同供应商准入资料附件。\n\n3) MET 两块已确认：检验扣重——FeedstockBatchController.inspect 按标准水分自动算 deductWeight/settleWeight/settleAmount 并走 合格/降级/拒收 状态机；事后供应商评估——/supplier-eval 按供应商聚合批次数/拒收率/平均水分/平均杂质/累计结算额。",
   "reEvidence": "domain/Supplier.java(无附件/检测报告/无害化字段,仅基础工商+银行+status); web/SupplierController.java(Create/UpdateSupplierRequest 同字段集,无文件关联); domain/FeedstockBatch.java(到货批次,无计划量/计划期/采购单); web/FeedstockBatchController.java(CRUD+inspect 扣重扣价状态机[MET]+/supplier-eval 评估[MET],无计划端点); domain/Certification.java(公司体系认证,无供应商外键无文件字段); 域内无 *Procure*/*Purchase*/*Acquisition*/收购计划 实体或控制器(ls domain/ + grep 全 web/ RequestMapping 无 procure/purchase/收购 路径); 前端 ofbiz-framework/plugins/modern-ui/app/src/oa/api/mfgBiofert.ts(端点仅 feedstock/recipe/ferment/equipment/maint,无采购计划); src/oa/pages/mfg/(feedstock/fermentation/inventory/mrp/equipment/reporting,无采购计划页); src/data/kaidiDeptView.ts(采购仅为静态部门接口标签)"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "2. 生产计划与发酵工艺管理",
   "verdict": "PARTIAL",
   "gap": "MPS 主生产计划实体与跨批次产能/排产/发酵周期整体编排缺失；仅单发酵批次任务单。工艺管理子功能 MET。",
   "severity": "med",
   "evidence": "发酵工艺子功能确已 MET：FermentBatch 是完整发酵任务单（配方配比/起始日期/目标温度含水率/翻抛频率/预计出料日期 + 状态机 待投料→投料完成→发酵中→待腐熟检测→已出料/异常），FermentLog 逐日逐班记录堆体温度/含水率/pH/氧含量/翻抛次数并自动超限预警，/maturity 端点录种子发芽指数对 targetGermIndex 判腐熟合格闸。但 MPS 缺口成立：FermentBatchController 端点仅 create/charge/logs/maturity/trace（单批次生命周期），无任何按销售预测/订单+库存+原料供应制定月/周生产计划的实体；grep 产能/排产/forecast/月周计划 在制造域零命中。",
   "survives": true,
   "reNote": "缺口属实。制造管理中心/生物质肥料制造中心确无 MPS 主生产计划实体，也无跨批次产能/排产/发酵周期整体编排能力；现状仅为「单发酵批次任务单」。工艺管理子功能（配方/投料/过程监控/腐熟判定）确已实现，与判定中「工艺管理 MET」一致，故整体 PARTIAL 成立。我已尽力寻找反证（BizPlan、WorkOrder、ProductionReport、MRP、ScheduleEvent、前端 mfg 菜单全查）均无法推翻。",
   "reEvidence": "1) domain/FermentBatch.java 第14行明确「一条 FermentBatch 代表一个发酵批次」，字段只有单批的 startDate/expectEndDate(=起始+周期)/trough/status，无周期产能/需求来源/排产位次等 MPS 结构。2) web/FermentBatchController.java 端点全为单批操作（@RequestMapping /api/oa/ferment-batches；GET list、POST、PATCH、DELETE、/{id}/charge、/{id}/logs、/{id}/to-maturity、/{id}/maturity、/{id}/trace），无任何列表级排产/产能负荷/跨批次编排接口。3) domain/WorkOrder.java 为通用单条生产工单（productName/planQty/plannedDate/status 五态机），仅有 plannedDate 单字段，无 MPS 计划期/需求联动/产能均衡。4) domain/ProductionReport.java 为车间工序报工（§5 执行层），非计划层。5) 全后端+前端 grep「MasterSchedule|MPS|主生产计划|排产|产能负荷|生产排程|发酵周期编排|批次排程|gantt」无任何制造 MPS 命中（仅 DevWbsTask 研发WBS、goal/project.vue 目标甘特，均不相关）。6) 前端 data/oaModules.ts 第470-483行 mfg 菜单：生产工单/库存/发货/配方设备/MRP物料需求计划/工单领料/车间报工/质量追溯/售后/项目成本/原料检验/配方投料/发酵任务与工艺/设备维护——无 MPS/排产/产能/发酵周期编排入口；「发酵任务与工艺」即单批+工艺，MRP 为下游物料净需求而非 MPS 主排产。"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "4. 车间生产执行",
   "verdict": "PARTIAL",
   "gap": "设备实时运行参数（电流/转速/干燥介质温度）关联工单无承载；包装管理（规格/有效期/喷码贴标）整体缺失；通用在制品按批次+位置管理薄弱（InventoryItem 无批次号）。",
   "severity": "med",
   "evidence": "工单+报工已实（WorkOrder + ProductionReport：工序/产量/合格/不良/工时/人工成本回写工单 actualQty 推进状态机）。但三处缺口经核实全部成立：(a)MfgEquipment.java 字段仅 runHours/maintCycleHours/lastMaintHours 等累计/保养字段，无电流/转速/干燥介质温度等实时运行参数字段、无与工单的参数关联表；(b)包装管理零承载——grep 包装规格/25kg/吨袋/喷码/贴标/有效期/shelfLife/expiryDate 在 domain/ 全无真实命中，无包装规格/成品有效期/喷码贴标实体；(c)InventoryItem.java 无 batchNo 字段、半成品位置仅 location 自由文本，通用在制品按批次+位置承载薄弱。",
   "survives": true,
   "reNote": "real gap confirmed",
   "reEvidence": "WorkOrder has no runtime params, InventoryItem has no batchNo, no packaging entity"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "5. 质量检验与追溯",
   "verdict": "PARTIAL",
   "gap": "无 NY525/NY884/GB20287 限值表与有机质/总养分/活菌数/重金属自动判合格逻辑，标准对标自由文本、判定靠人工；原料检验无蛔虫卵死亡率/粪大肠菌群专属字段。",
   "severity": "med",
   "evidence": "QcInspection 三类检验（IQC/IPQC/FQC）+ /judge 状态机 + /trace 序列号追溯 + /supplier-quality 评价均已实。但成品检验自动对标缺口成立：QcInspectionController.java（314行）grep NY525/NY884/GB20287/限值/standardLimit/autoJudge/活菌数/有机质/总养分 全部零命中；QcInspection.standardRef 与 inspectData 均为自由文本字段，/judge 端点是操作员手动选「合格/不合格」（result 入参），无任何标准限值表对有机质/总养分/活菌数/重金属的自动判合格逻辑。原料检验亦无蛔虫卵死亡率/粪大肠菌群专属字段。",
   "survives": true,
   "reNote": "缺口属实。生物质肥料质量检验与追溯（链5/§7）落在 QcInspectionController + QcInspection：判定端点 /judge 的 result（合格/不合格）由请求体人工传入，standardRef 和 inspectData 全是自由文本，无任何限值表、无实测值与标准阈值的自动比对。全后端 grep NY525/NY884/GB20287（含带空格变体）零命中；无 SpecLimit/QualitySpec/StandardLimit/LimitTable 等限值实体。唯一的\"自动判\"在 FeedstockBatchController.inspect()，但它仅靠人工录入的 heavyMetalFail 布尔开关强制拒收 + 水分/杂质扣重比例（≥30%自动降级），并非按限值表计算；FertRecipe/FeedstockBatch 虽带 organicPct/totalNutrientPct/viableBacteria，但只是配方目标/原料记录，无成品实测值对限值的合格判定逻辑（grep organicPct/totalNutrient/viableBacteria 的 [<>] 比较在 web/ 与 service/ 均为空）。原料检验无蛔虫卵死亡率、粪大肠菌群专属字段：grep 蛔虫/粪大肠 在 domain/web/seed 全部零命中，这两个字段在实体里根本不存在。判定确实靠人工、标准对标确为自由文本，缺口成立。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa/web/QcInspectionController.java（judge() L174-228 result 人工传参、standardRef/inspectData 自由文本，无限值比对）；domain/QcInspection.java（standardRef/inspectData 为 String，无限值/活菌/养分/重金属判定字段）；web/FeedstockBatchController.java（inspect() L143-202 仅 heavyMetalFail 布尔强制拒收 + 水分/杂质扣重比例判降级，无限值表）；domain/FertRecipe.java、domain/FeedstockBatch.java（organicPct/totalNutrientPct/viableBacteria 仅为目标/记录字段）。grep 证据：NY525/NY884/GB20287 在 web/*.java domain/*.java seed/DataSeeder.java 零命中；蛔虫/粪大肠 在 domain/web/seed 零命中；SpecLimit/QualitySpec/StandardLimit/LimitTable 实体不存在；organicPct/totalNutrient/viableBacteria 的 [<>] 阈值比较在 web/ service/ 为空。"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "6. 库存管理",
   "verdict": "LOGIC_GAP",
   "gap": "通用库存无批次号/保质期有效期/到期前3月预警/FIFO/移动扫码收发流水；FIFO 仅在原料批次域局部实现，成品保质期与包装物库零承载。",
   "severity": "high",
   "evidence": "InventoryItem.java 字段仅 materialName/category/spec/unit/quantity/safetyStock/location/status，确证无 batchNo、无 expiryDate/shelfLife 保质期字段、无到期预警逻辑；InventoryItemController.java 仅做安全库存高低状态判定，无 FIFO、无移动扫码出入库收发流水。FIFO 仅在 FeedstockBatchController/FermentBatch.charge 按 arrivalDate 对原料批次实现，未覆盖需求所指通用库存（半成品/成品/包装物）；成品 12-24 月保质期、到期前 3 个月预警、包装物库均无承载。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。通用库存实体 InventoryItem（/api/oa/inventory，制造管理中心库存模块）字段仅 materialName/category/spec/unit/quantity/safetyStock/location/status/createdAt——既无批次号(batchNo)、无保质期/有效期(expiryDate/shelfLife)、无 FIFO 消耗游标、无扫码收发流水。预警侧 AlertController/AlertScheduler 对 InventoryItem 只产「低于安全线」库存预警，完全没有临期/到期预警，更没有到期前3月窗口（证件预警窗口是 WARN_WINDOW_DAYS=30天，且不作用于库存）。FIFO 仅在原料批次域 FeedstockBatch/FermentBatchController 按 arrivalDate 局部实现（粪污易腐败），与缺口描述完全一致。成品保质期：WorkOrderController.fireInventory 把工单成品写入通用 InventoryItem(category=成品/location=成品库)，结构上无任何批次/保质期/生产日期字段可承载，零承载。带 batchNo/expiryDate 的 FoodBatch 属于行政后勤·食材域，不是生物质肥料成品库；带 batchNo/expireDate 的 AdminStockMove 属于行政物资库存流水，亦非制造中心通用库存。包装物库无任何专用实体/控制器，零承载。扫码：barcode/scan 命中只在 AdminVisitor(访客)、Sewage(污水设备)等无关域，库存无扫码收发链。推翻失败，缺口成立。",
   "reEvidence": "domain/InventoryItem.java(L25-41 字段全集,无 batchNo/expiryDate/FIFO); web/InventoryItemController.java(CRUD 仅安全线状态机,无批次/保质期/扫码); web/AlertController.java(L139-147 InventoryItem 只产低于安全线预警,无临期); task/AlertScheduler.java(L37 WARN_WINDOW_DAYS=30 仅证件,不及库存); web/WorkOrderController.java(L151-166 成品入 InventoryItem 无批次/保质期字段); domain/FeedstockBatch.java(L24-26 FIFO 仅原料批次域); domain/FoodBatch.java(L27/51 batchNo+expiryDate 属食材域非肥料成品); domain/AdminStockMove.java(L55-57 batchNo/expireDate 属行政物资非制造库存); repository/InventoryItemRepository.java(仅 findByCategory,无任何按批次/到期查询)"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "7. 设备维护与能源管理",
   "verdict": "PARTIAL",
   "gap": "能源消耗管理完全缺失：无电耗/燃料/水耗逐班记录实体或端点、无能耗分摊至生产批次、无单位产品能耗与行业标准对标；SewageEnergyLog 属水务域不可复用。设备维护子功能 MET。",
   "severity": "med",
   "evidence": "设备台账+预防性维护+故障报修闭环已实（MfgEquipment 保养周期到点提醒 + MaintOrder 保养/维修工单 finish 回写设备状态与保养计数）。但能源消耗管理完全缺失成立：grep 能耗/电耗/燃料/水耗/kWh/energyKwh 在 MfgEquipment/MaintOrder 及制造域控制器零命中；SewageEnergyLog 存在但归属水务/污水运营域（SewageEnergyLogController，表名 sewage_），非本生物质肥料制造中心，无电耗/燃料/水耗逐班记录、无能耗分摊至生产批次、无单位产品能耗计算与行业对标。",
   "survives": true,
   "reNote": "缺口属实。尽力推翻后仍无法找到制造管理中心(生物质肥料制造中心)的能源消耗管理实现。彻查结论：\n\n1) 制造域设备维护子功能确实 MET：domain/MfgEquipment.java(累计运行时runHours/保养周期maintCycleHours/上次保养lastMaintHours，到点提醒预防性保养) + domain/MaintOrder.java + web/MaintOrderController.java(待保养列表一键生保养工单)。MfgEquipment 的 Javadoc 虽写\"需求 §7 设备维护与能源管理\"，但实体里只有维护字段，零能源字段。\n\n2) 能源消耗管理完全缺失：\n- 实体层：domain/Mfg*.java、Ferment*.java(FermentBatch/FermentLog 只记温度/含水率/pH/氧含量/翻抛次数，是工艺监控非能耗)、Feedstock*.java、Food*.java、ProductionReport.java(只有laborHours/laborRate/laborCost)、WorkOrder.java、MaterialIssue.java —— grep power|kwh|fuel|燃料|electricity|steam|蒸汽|煤|天然气 全部命中为空。无电耗/燃料/水耗逐班记录实体。\n- 端点层：全后端唯一能耗端点是 /api/oa/sewage-energy-logs(web/SewageEnergyLogController.java)，属城镇污水运营/运营管理中心(ops)水务域，不可复用。无任何 mfg 能耗端点。\n- 分摊：web/MfgProjectCostController.java 项目成本归集只有\"直接材料(领料)+直接人工(报工)+售后成本\"三项，无能源/制造费用成本项，能耗未分摊至生产批次/项目。\n- 对标：无单位产品能耗(kWh/吨产品)计算，无行业标准对标。\n\n3) 前端同样佐证：grep 能耗/电耗/kwh/fuel(排除水务)仅命中 ops/reagent.vue、ops/performance.vue、ops/process.vue(全为污水运营\"药剂与能耗\"台账)及 admin/vehicle.vue(车辆油耗)，制造模块(mfg)无任何能耗页面。\n\nSewageEnergyLog 属水务域且字段绑定treatedWater(处理水量)/reagentName(药剂)，与肥料制造的批次能耗模型不匹配，确不可复用。PARTIAL 判定正确——维护半边已实现，能源管理半边从0缺失。",
   "reEvidence": "domain/MfgEquipment.java(仅维护字段,doc提§7能源管理但无能源字段); domain/MaintOrder.java + web/MaintOrderController.java(维护MET); domain/FermentBatch.java + domain/FermentLog.java(工艺监控温度/含水率/pH/氧含量,非能耗); domain/ProductionReport.java(仅laborHours/laborCost); web/MfgProjectCostController.java:30-34(成本归集仅直接材料+直接人工+售后成本,无能源项); web/SewageEnergyLogController.java:36(唯一能耗端点/api/oa/sewage-energy-logs属水务域); domain/SewageEnergyLog.java(treatedWater/reagent水务字段,不可复用). grep power|kwh|fuel|燃料|蒸汽|煤|天然气 在 domain/Mfg*.java Ferment*.java Feedstock*.java Food*.java ProductionReport.java WorkOrder.java MaterialIssue.java 全部为空。前端 ops/reagent.vue、ops/performance.vue、ops/process.vue 均为污水运营域,mfg模块无能耗页。"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "8. 环保与安全（EHS）管理",
   "verdict": "PARTIAL",
   "gap": "发酵废气（氨气/硫化氢/臭气排放口超标预警）专属实体缺失；废水渗滤液肥料自厂专属承载缺失（Sewage 属水务客户域）；职业健康缺岗位粉尘浓度监测与劳保发放专属记录。通用隐患/危废/安全巡检有承载。",
   "severity": "med",
   "evidence": "统一 EHS 域提供通用承载（EhsHazard 隐患/风险评分整改闭环、EhsObjective 含「排放达标率」KPI、HazWasteManifest 危废联单、SafetyCheck 安全巡检、HealthRecord 职业健康），可部分覆盖固废/安全巡检/职业健康的通用面。但发酵专属缺口成立：grep 氨气/硫化氢/臭气/排放口/emission/粉尘/渗滤液 在 EHS 域实体零专属命中——无氨气/硫化氢/臭气浓度监测排放口超标预警实体；废水渗滤液产生量/处理量/外排达标无肥料自厂专属承载（Sewage 域为水务客户非自厂）；职业健康无粉碎/筛分/造粒岗位粉尘浓度监测、无劳保用品发放记录专属字段（劳保仅命中 AdminSupply 行政耗材域）。",
   "survives": true,
   "reNote": "尽力推翻后，缺口属实，PARTIAL 判定准确。生物质肥料制造中心 EHS 链的三项专属承载逐一核查均不存在，只有通用替代物：\n\n(1) 发酵废气(氨气/硫化氢/臭气排放口超标预警)专属实体——确缺。全部 mfg_/ehs_/health_ 表中无任何废气/排口/浓度监测实体。FermentLog(mfg_ferment_log)只采集堆体温度/含水率/pH/氧含量/翻抛/环境温度，超限预警仅针对温度+5℃和含水率±10%，与废气无关；FermentBatch 里 NH3/CO2 仅出现在自由文本\"腐熟检测备注\"字段，非结构化排口监测+超标预警实体；SewageProcessRun 的氨氮是出水水质(水务域)，不是废气。\n\n(2) 废水渗滤液肥料自厂专属承载——确缺。SewageSludgeRecord 类注释明写\"城镇污水运营·污泥处置/外运联单\"，属水务客户运营域；无任何制造中心自厂持有的渗滤液/液肥/沼液承载实体。\n\n(3) 职业健康岗位粉尘浓度监测+劳保发放专属记录——确缺。HealthRecord(health_record) 的 hazardFactor 仅作为\"粉尘\"标签存在，本质是定期体检台账(examType=上岗前/在岗/离岗,result=正常/复查)，无浓度数值、无检测点、无超标阈值，不是粉尘浓度监测记录；劳保发放仅有 AdminSupply 的\"劳保用品\"分类 + AdminStockMove 通用出库领用，无按岗位/人员的劳保发放专属记录实体。\n\n通用隐患(EhsHazard)/危废(SewageSludgeRecord wasteType=危废)/安全检查(SafetyCheck)确有承载——正是缺口判 PARTIAL 而非完全缺失的原因，描述精准。",
   "reEvidence": "域表清单(grep @Table): EHS=ehs_capa/ehs_hazard/ehs_incident/ehs_objective/ehs_work_permit/health_record/safety_check；制造=mfg_equipment/mfg_feedstock_batch/mfg_ferment_batch/mfg_ferment_log/mfg_fert_recipe/mfg_maint_order/mfg_material_issue/mfg_production_report/mfg_qc_inspection/mfg_recipe_ingredient/mfg_service_ticket；污水=sewage_energy_log/sewage_equipment/sewage_process_run/sewage_sludge_record/sewage_work_order。\ndomain/FermentLog.java:40-65 仅 temperature/moisturePct/ph/oxygenPct/turnTimes/ambientTemp，无废气字段。\ndomain/FermentBatch.java:85 \"腐熟检测备注(NH₃/CO₂浓度...)\" 为自由文本注释，非实体。\ndomain/SewageProcessRun.java:53 进/出水氨氮(mg/L) 属水质而非废气。\ndomain/SewageSludgeRecord.java:13 注释\"城镇污水运营·污泥处置/外运联单\"=水务域。\ndomain/HealthRecord.java:11-44 职业健康为体检台账(hazardFactor/examType/result/nextExamDate)，无浓度/检测点/阈值字段。\ndomain/AdminSupply.java:11-19 \"劳保用品\"仅为行政物资分类，配 AdminStockMove 通用出库，无岗位级劳保发放专属实体。\n全库 grep 废气/氨气/硫化氢/臭气/exhaust/emission/粉尘浓度/concentration/劳保发放/渗滤液/leachate 均无命中专属承载。"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "9. 销售与客户管理",
   "verdict": "MISSING",
   "gap": "销售订单、发货管理、农化服务三大子功能整体缺失，客户档案缺土壤/作物/用肥字段，无销售分析；仅客户薄壳+售后工单。",
   "severity": "high",
   "evidence": "grep SalesOrder/salesOrder/发货/deliveryNote/shipment/物流单号/测土/施肥/NPK/农化 在 domain/ 与 web/ 全部零命中，证实：无按客户定制配方/NPK 比例的销售订单实体、无订单与生产计划库存联动；无发货单/扫码出库/物流单号/拼车运输；无测土配方/施肥指导/效果跟踪农化服务实体。Customer.java grep soilType/土壤/作物/cropType/用肥 零命中，客户档案无土壤类型/作物种类/用肥习惯字段。现存仅 Customer 薄壳 + ServiceTicket 售后工单。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。需求(requirements/_req_slices/09_制造管理中心__生物质肥料制造中心.txt 第29-30行)明确定义\"9.销售与客户管理\"含5子功能：客户管理(记录土壤类型/作物种类/用肥习惯)、订单管理(销售订单按NPK定制、与生产/库存联动)、发货管理(生成发货单/扫码出库/拼车/物流单号)、农化服务(测土配方/施肥指导/效果跟踪)、销售分析。逐项核查：(1)后端 Customer 实体仅 name/type/contact/phone/address/status 6字段薄壳，完全无 土壤/作物/用肥 字段；(2)全后端无 SalesOrder/Shipment/农化 任何 domain/repository/controller；(3)前端 mfg 全部页面 grep 销售订单/销售分析/发货管理/农化服务/测土/施肥/土壤/作物/用肥 = 0 命中；(4)菜单\"发货与售后\"(delivery.vue)仅9行 re-export aftersales.vue，后者是纯售后工单流(报修→派单→处理→完工→关闭+备件领用)，并非发货管理；(5)生物质肥料中心深水API(mfgBiofert.ts)显式仅覆盖§1原料到货/§2发酵/§3配方/§7设备维护，无§9销售。唯一\"销售订单/SalesOrderItemFact\"命中在 services/api.ts，是遗留 OFBiz 数据中心实体字典 mock(指向 OFBiz order__findorders 页面)，非本平台功能模块。现状=描述所言\"仅客户薄壳+售后工单\"，三大子功能(销售订单/发货/农化服务)整体缺失，客户档案缺农业字段，无销售分析。",
   "reEvidence": "域实体 Customer 薄壳: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/Customer.java (仅 name/type/contact/phone/address/status，无 soil/crop/fertilizer 字段)。控制器同样薄: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/CustomerController.java (仅基础CRUD)。\"发货与售后\"实为售后工单 re-export: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mfg/delivery.vue 第4行 import AfterSales from './aftersales.vue'；aftersales.vue 注释\"售后服务工单闭环：客户报修→派单→处理→完工→关闭\"。mfg 模块定义: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts 第464-485行，14个子项无一为 销售订单/发货管理/农化服务/销售分析。生物质肥料深水API范围: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/api/mfgBiofert.ts 第2行\"§1原料到货检验/§2发酵工艺/§3配方管理/§7设备维护\"。需求原文: /Users/qiu/Desktop/ERP/requirements/_req_slices/09_制造管理中心__生物质肥料制造中心.txt 第29-30行。后端无 SalesOrder/Shipment 实体或仓储(grep domain/repository 仅 WorkOrder/MaintOrder/MealOrder/PrototypeOrder/SewageWorkOrder/DesignChangeOrder/OpsMaintOrder，无 SalesOrder/Shipment/Delivery)。"
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "10. 成本核算与财务集成",
   "verdict": "PARTIAL",
   "gap": "发酵周期固定成本分摊无专属逻辑；差异仅总差异，量差/价差/效率差未分解；制造域无自动生成会计凭证的业财一体闭环。成本归集与标准成本对比 MET。",
   "severity": "med",
   "evidence": "制造成本归集已实：MfgProjectCostController./summary 按项目自动归集直接材料（MaterialIssue 领料）+直接人工（ProductionReport 报工人工成本）+售后成本，与 StandardCost 标准成本对比给 variance/varianceRate，金额一律 Money/BigDecimal。但三处缺口成立：(a)差异仅 variance=实际−标准 的总差异口径，ProjectCostRow 无量差/价差/效率差分解字段；(b)无发酵周期专属成本分摊逻辑（无场地/翻抛/监测固定成本按发酵周期分摊）；(c)业财一体未闭环——grep Voucher/凭证 在 MfgProjectCost/MaterialIssue/FeedstockBatch/ProductionReport 控制器零命中，本中心采购/销售发票/费用/收付款无自动生成会计凭证的联动链。",
   "survives": true,
   "reNote": "Gap is real; all three sub-claims confirmed unimplemented.",
   "reEvidence": "FermentBatchController.java has no cost-allocation or voucher code; StandardCostController and MfgProjectCostController compute only variance=actual-standard; only auto-voucher sites are PaymentService and ProjectController, neither in manufacturing."
  },
  {
   "area": "制造管理中心/生物质肥料制造中心",
   "module": "11. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "无实验室 LIMS 数据自动流入 QC/原料检验、无配方菌种创新自动推送 IP 建专利、无环保排放/认证自动汇入申报；仅有通用手工同步队列，跨部门数据自动对接靠人工录入桥接。",
   "severity": "med",
   "evidence": "存在通用外部对接框架（IntegrationController + DataSyncLog + IntegrationExecutor：手工/批量执行同步任务、入队队列），但它是通用同步台账（source/target/entity/direction），非自动数据流。缺口成立：实验室检测数据无自动流入 QC——QcInspection.inspectData 为手填自由文本，无 LabSample/LabInstrument→QcInspection 的自动取数链；配方/菌种创新无自动推送知识产权部建专利（FertRecipe 与 IpAsset/Patent 无联动）；环保排放/认证文件无自动汇入申报。当前各模块靠人工录入桥接，「ERP 直接接收 LIMS 数据」与跨部门数据自动对接未实现。",
   "survives": true,
   "reNote": "Gap is real - none of the three named cross-department auto-flows exist.",
   "reEvidence": "QcInspection written only by QcInspectionController; FertRecipe.approve writes only AutomationLog not Patent; Declaration/Certification manual-only; TriggerRuleEngine has 7 chains none matching; MockSyncAdapter is a stub."
  },
  {
   "area": "工程管理中心/质安部",
   "module": "1. 质量管理体系 (质量目标考核/文件记录控制/内审/管理评审/CAPA/供方质量)",
   "verdict": "PARTIAL",
   "gap": "质量目标自动采集(生产/实验室/售后联动)、QMS 文件与记录控制(版本/废止/保存期限)、年度内审计划+内审员检查表闭环、管理评审输入自动汇总、供方来料合格率自动统计与限制采购名单 五项缺失；仅 CAPA 与目标手工台账已落地。",
   "severity": "high",
   "evidence": "维持 PARTIAL。逐条核实：(a) 质量目标自动采集——EhsObjectiveController 只有手动 POST /{id}/collect(web/EhsObjectiveController.java:125)，service/TriggerRuleEngine.java(771行) grep ehs|objective|hazard|capa|incident 命中 0，确无从生产/实验室/售后自动取数。(b) 文件与记录控制——grep 质量手册|程序文件|文件版本|保存期限|作业指导书 只命中 Archive/Document 通用档案，无 QMS 体系文件版本/废止提醒/保存期限实体。(c) 内审——QmsRecord 仅 type/title/finding/dueDate/status 扁平字段(domain/QmsRecord.java)，grep 年度内审|内审计划 0 命中，无内审计划/内审员检查表/不符合项闭环。(d) 管理评审——grep 管理评审|managementReview 0 业务实体。(e) 供方质量——domain/Supplier.java 仅 name/creditCode/category/contact/bank/status，无来料合格率/交货及时率/限制采购名单字段。CAPA 这一项其实做得很强(EhsCapa 待分析→措施中→待验证→已闭环全状态机 + 隐患/事故 escalate-capa + /stat 分类统计)，但 6 子项中 5 项确为缺口。",
   "survives": true,
   "reNote": "尽力推翻后仍无法整体推翻，缺口属实(PARTIAL 判定成立)。逐项核验五项\"缺失\"：\n\n(1) 质量目标自动采集(生产/实验室/售后联动) — 真缺。EhsObjective/EhsObjectiveController 有目标台账+达成率自动算+超差自动预警(applyAttainment 落档 达标/预警/超差/待采集)，但实际值靠 POST /ehs-objectives/{id}/collect 手填 actualValue，dataSource 只是文本说明字段，不存在从生产/实验室/售后自动取数的联动。手工台账，自动采集确缺。\n\n(2) QMS 文件与记录控制(版本/废止/保存期限) — 真缺。全后端无 QMS 受控文件版本/废止/保存期限实体或接口；grep 命中的 version/作废/保存期限均属无关模块(DesignDoc/DischargeContract/Content/Invoice/TestReport/ArchiveSubmission 档案)，非质量体系文件控制。\n\n(3) 年度内审计划+内审员检查表闭环 — 真缺。无审核计划/检查表(checklist)控制器；QmsRecord 虽有 type=\"内部审核\" 但只是扁平台账记录(create/update/delete)，无计划编排与检查表闭环。\n\n(4) 管理评审输入自动汇总 — 真缺。QhseDashboardController 只是对 SafetyCheck+QmsRecord 的计数/比率只读看板，非\"管理评审输入\"结构化汇总(目标达成/内审/供方/投诉打包)；活体探 /management-reviews 返回 404。\n\n(5) 供方来料合格率自动统计与限制采购名单 — 半实现(唯一可证伪点)。QcInspectionController GET /qc-inspections/supplier-quality 确实按供应商自动聚合 IQC 来料检验送检量/合格量/合格率并排序(合格率低者靠前)，活体返回 200。但\"限制采购名单\"那一半不存在：该聚合不回写 Supplier 实体/状态，SupplierController 无任何因合格率限制采购或合格供方名录机制。\n\n综合：5 项中 4 项确缺，第 5 项仅\"自动统计\"半边落地、\"限制采购名单\"仍缺；claim 自述\"仅 CAPA 与目标手工台账已落地\"基本准确。整体 PARTIAL 缺口成立，无法推翻。",
   "reEvidence": "web/QmsRecordController.java(纯手工CRUD台账,类型含内部审核/管理评审/供方质量评价但无自动化); domain/EhsObjective.java+web/EhsObjectiveController.java(目标达成率自动算+超差预警,但 /{id}/collect 手填 actualValue,dataSource 仅文本,无生产/实验室/售后取数); web/QhseDashboardController.java(SafetyCheck+QmsRecord 计数/比率只读看板,非管理评审输入汇总); web/QcInspectionController.java:280-300 supplierQuality()(供应商 IQC 合格率自动聚合,确实存在,但不回写 Supplier); web/SupplierController.java(纯主数据CRUD,无限制采购/合格供方名录); 活体 /api/oa/qc-inspections/supplier-quality=200、/ehs-objectives=200、/management-reviews=404、/internal-audits=404; grep 全后端无 内审计划/检查表/QMS文件版本废止保存期限/限制采购名单 实现。"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "2. 安全生产管理 (安全目标责任书/危险源辨识JSA-HAZOP/隐患排查/安全培训/安全投入/作业许可/事故管理/应急管理)",
   "verdict": "PARTIAL",
   "gap": "1)安全目标与责任书: 公司-部门-班组在线签订责任书/到期自动续签提醒 无实体。2)危险源辨识与风险评估(JSA/HAZOP 危险源数据库 按区域/岗位/设备/作业活动)缺——EhsHazard 是'已发现的隐患'非'危险源源头库'。3)安全培训与教育(三级教育/特种作业复训/培训记录/成绩)缺。4)安全投入管理(培训/劳保/安全设施费用归集+财务联动)缺。5)应急管理(应急预案/演练计划与记录/应急物资台账)缺(grep '应急预案/演练' 0 业务命中)。",
   "severity": "high",
   "evidence": "隐患排查治理: domain/EhsHazard.java + web/EhsHazardController.java(/api/oa/ehs-hazards) 真整改闭环 待整改→整改中→待复查→已闭环(复查不通过 verify pass=false 退回并清整改日)，applyRisk() 风险值=可能性×后果自动落档 红≥15/橙≥10/黄≥5/蓝，scan-overdue 逾期自动落档+预警，活体实测 5×4→20→红。作业许可: domain/EhsWorkPermit.java + web/EhsWorkPermitController.java(/api/oa/ehs-work-permits) 全生命周期 草稿→气体检测→审批中→已批准→作业中→已关闭，submit() 强制监护人+动火/受限空间强制 gasTested、start() 有效期窗口校验、alerts/expiry 有效期预警。事故管理: domain/EhsIncident.java + web/EhsIncidentController.java(/api/oa/ehs-incidents) 上报→调查→整改→结案，computeDeadline() 按等级自动算法定上报截止日，alerts/report 到期预警，结案一键生成 CAPA，directLoss 用 Money(BigDecimal)。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。工程管理中心/质安部 安全生产管理只建了 6 个 EHS 实体(EhsObjective/EhsHazard/EhsWorkPermit/EhsIncident/EhsCapa + 扁平 SafetyCheck)，对应前端 ehs 模块仅 7 项导航(安全检查隐患/三体系认证/质量体系/EHS看板/隐患排查治理/危险作业许可/事故事件管理)。逐条核验描述里的 5 个缺口全部成立：(1)EhsObjective 是 QHSE 目标值/实际值/达成率考核记录，控制器端点只有 list/get/create/patch/delete/collect采集/board，无任何 责任书签订(公司-部门-班组在线签订)或到期自动续签提醒逻辑(grep responsib|signOff|renew|续签|责任书 在 EhsObjectiveController 零命中)，无实体支撑。(2)EhsHazard javadoc 自述为\"排查发现的隐患\"走整改闭环(待整改→整改中→待复查→已闭环/已逾期)，确实是'已发现隐患'而非'危险源源头库'；不存在按区域/岗位/设备/作业活动建库的 JSA/HAZOP 危险源数据库实体(grep JSA|HAZOP|hazardSource 在 domain/web/service 零命中)；唯一的 RiskAssessment 实体表名 legal_risk_assessment，是法务合规的企业风险库(战略/运营/财务/法律/合规风险)，非 EHS 危险源辨识。(3)安全培训与教育(三级教育/特种作业复训/培训记录/成绩)无实体无控制器(grep 三级教育|安全培训|复训|training 全零命中；StaffCredential/PersonnelCert/QualCert 只是把'特种作业证'当证照类型登记，非培训复训管理)。(4)安全投入管理(培训/劳保/安全设施费用归集+财务联动)无实体(grep 安全投入|劳保费|SafetyInvest 零命中；AdminSupply 只是把'劳保用品'当物资分类，非费用归集)。(5)应急管理(应急预案/演练计划与记录/应急物资台账)无实体无业务(grep 应急预案|演练|drill|emergency 在 EHS 域零命中；EhsIncident 仅事故/未遂/工伤上报-调查-整改-结案，不含应急预案演练)。判定 PARTIAL 准确：作业许可(EhsWorkPermit)、隐患排查(EhsHazard)、事故管理(EhsIncident)三项已建，但责任书续签、JSA/HAZOP危险源库、安全培训、安全投入、应急管理五项确缺。",
   "reEvidence": "后端域: oa-backend/src/main/java/com/kaidi/oa/domain/ 仅 EhsObjective.java(ehs_objective,QHSE目标考核)/EhsHazard.java(ehs_hazard,隐患整改闭环,javadoc明确'排查发现的隐患'非源头库)/EhsWorkPermit.java/EhsIncident.java(ehs_incident,事故管理,无应急演练)/EhsCapa.java/SafetyCheck.java。控制器: web/EhsObjectiveController.java 端点 GetMapping/PostMapping/PatchMapping/DeleteMapping/{id}/collect/board，无责任书/续签端点。RiskAssessment 实体表名 legal_risk_assessment(法务风险库,非EHS危险源)。前端: ofbiz-framework/plugins/modern-ui/app/src/data/oaModules.ts:344-355 ehs 模块仅7导航无培训/应急/责任书；api/ehsDeep.ts:3 仅包 /ehs-hazards,/ehs-work-permits,/ehs-incidents,/ehs-capas,/ehs-objectives,/ehs-board。全域 grep 三级教育|安全培训|复训|应急预案|演练|drill|emergency|安全投入|JSA|HAZOP|hazardSource|责任书|续签 在 domain/web/service 业务字段零命中(命中均为 特种作业证/劳保用品 等证照与物资分类的文本误报)。"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "3. 职业健康管理 (职业病危害因素识别/职业健康监护/PPE管理/作业场所监测)",
   "verdict": "LOGIC_GAP",
   "gap": "承载台账有但关键自动逻辑空: 1)'系统自动提醒到期体检'无——nextExamDate 只存字段，无到期扫描/预警端点。2)'禁忌症人员自动调岗提醒'无。3)职业病危害因素清单'定期检测+超标自动预警并启动整改'无。4)个人防护用品(PPE)管理(按岗位标准配置/领用更换周期/超期未换提醒/特殊PPE检测)整类缺失。5)作业场所监测(粉尘/噪声/照度/温湿度定期监测+超标预警+关联整改/物联网对接)缺。HealthRecordController 仅 list/get/create，无 update/到期逻辑。",
   "severity": "med",
   "evidence": "职业健康监护: domain/HealthRecord.java + web/HealthRecordController.java(/api/oa/health-records，活体 11 条) 有 hazardFactor(粉尘/噪声/化学品)、examType(上岗前/在岗/离岗)、result(正常/复查/疑似职业病)、nextExamDate、status(正常/待复查/重点监护)。",
   "survives": true,
   "reNote": "缺口属实。逐条复核5个子项均未实现，无法推翻：\n\n[1 体检到期自动提醒] HealthRecord.nextExamDate 仅为 String 字段。全后端 grep 仅命中 domain 实体、HealthRecordController.create()(只写入)、DataSeeder(只播种)——从未被解析为日期、从未与今天比较、从未扫描。HealthRecordRepository 仅 findByStatus，无任何日期/到期查询。平台级预警聚合 AlertController.aggregate() 扫描8个来源(PersonnelCert/Patent/ContractMilestone/InventoryItem/LabInstrument/SafetyCheck/FormInstance/Budget)，HealthRecord 不在其中；唯一的 @Scheduled 到期扫描 AlertScheduler 只刷新 PersonnelCert 到期态，从不触碰 HealthRecord。无任何体检到期端点。\n\n[2 禁忌症人员自动调岗提醒] HealthRecordController 无 update，全代码无任何逻辑依据 result=疑似职业病/status=重点监护 触发调岗/预警；grep 禁忌症/调岗 在 web/domain/service 无命中。\n\n[3 危害因素清单 定期检测+超标自动预警+启动整改] 仅 EhsHazard.type 字符串枚举含\"职业健康\"一项(隐患整改台账)，无危害因素清单实体、无定期检测记录、无超标自动预警、无由检测触发 CAPA。MonitorService/MonitorRule 是财审引擎(大额付款/超预算/应收逾期/供应商集中)，与职业病危害因素检测无关。\n\n[4 PPE管理] 整类缺失：无 PPE/防护用品/劳保 的实体/控制器/仓储。唯一\"劳保\"命中是 AdminSupply(通用行政用品目录的一个\"劳保用品\"分类字符串)，无按岗位标准配置、无领用更换周期、无超期未换提醒、无特殊PPE检测。\n\n[5 作业场所监测 粉尘/噪声/照度/温湿度+超标预警+关联整改/IoT] 无任何对应实体/控制器/仓储。grep 粉尘/噪声/照度/温湿度/物联网/IoT 仅命中无关误报(如数字解析注释里的\"噪声\"指 number noise)。\n\n承载台账确实存在(HealthRecord 实体+列表/详情/新增)，但所有关键自动逻辑(到期扫描/调岗提醒/超标预警/整改联动)及 PPE、作业场所监测两整类均未实现。判定 LOGIC_GAP 成立。",
   "reEvidence": "web/HealthRecordController.java(仅 list/get/create，无 update、无到期扫描); domain/HealthRecord.java:40 nextExamDate 为 String; repository/HealthRecordRepository.java(仅 findByStatus); grep nextExamDate 全后端仅命中 domain/controller-create/DataSeeder; web/AlertController.java:98-210 aggregate() 8来源不含 HealthRecord; task/AlertScheduler.java:144-168 refreshCertExpiry() 只刷 PersonnelCert，无 HealthRecord; web/EhsHazardController.java(隐患整改台账，type 枚举含\"职业健康\"但无危害因素检测/PPE/作业场所监测); service/MonitorService.java:99-107(财审规则:大额付款/超预算/费用临近/应收逾期/供应商集中，与职业健康无关); 无任何 PPE/防护用品/粉尘/噪声/照度/温湿度 命名的 domain/web/repository(grep 仅误报 AdminSupply\"劳保用品\"分类与注释\"噪声\")"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "4. 环境保护管理 (环保合规义务清单/排污许可/三废管理/环境风险应急/环保税费)",
   "verdict": "MISSING",
   "gap": "质安部口径的企业自身环保管理基本无: 1)环保合规义务清单(水气声渣土 法规清单/新法规推送/合规差距评估)缺。2)排污许可管理(许可证信息/许可排放量/自行监测方案/监测结果上传/超标预警/季报年报执行报告)缺。3)三废管理中本企业'废气有组织无组织排放源/治理设施运行参数'、'废水产生处理外排监测 COD氨氮pH'缺(现有水质实体是代运营客户的，非自厂)。4)环境风险源识别+环境应急预案+演练+应急物资缺。5)环保税自动计算/治理费用归集缺。",
   "severity": "high",
   "evidence": "仅 domain/ComplianceObligation.java(法务·外规内化通用合规义务库 category 含'环保'，无环保专项逻辑)。危废联单 domain/HazWasteManifest.java(ww_ 前缀)与水质 WaterExceedEvent/DischargeBill 等属'运营管理中心·工业废水运营'业务线(对外受纳客户废水代运营)，非质安部对'本企业自有生产'的环保合规。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但无法证伪：质安部口径\"本企业自身环保管理\"的5项全部找不到实现。现有看似相关的实体全部不命中：(1)WaterExceedEvent/DischargeContract/Sewage*/WaterQualityRecord/DischargeBill/WaterAlertRule 均明确标注为\"运营管理中心·工业废水代运营\"(客户业务)，正是缺口排除的\"代运营客户的，非自厂\"；(2)ComplianceObligation 是法务合规通用义务库(category含环保但无水气声渣土法规清单/新法规推送/合规差距评估)；(3)EhsHazard/Incident/WorkPermit/Capa/Objective/Board 是通用安全(隐患/事故/危险作业票/CAPA)，无环保排放/许可/应急内容；(4)RiskAssessment 是法律/战略通用风险，非环境风险源；(5)TaxFiling 只有增值税/所得税/印花税，无环保税。逐项缺失全部grep验证为空。HazWasteManifest 仅覆盖危废(三废中的渣)且挂运营·污泥外运，不含本企业废气有组织/无组织排放源·治理设施参数，也不含废水COD/氨氮/pH自监测。",
   "reEvidence": "grep全库(oa-backend与前端app/src)结果：『排污许可|许可排放量|自行监测方案|执行报告』=0命中；『环境应急|应急预案|应急演练|应急物资』仅2个无关字符串(web/FavoriteController.java:59 收藏文档名\"应急预案与演练记录\"；非实体)；『环保税|环境保护税|envProtectionTax|pollutionTax』=0；『有组织|无组织|废气排放源|治理设施』仅 seed/DataSeeder.java:2900 一条labSample名\"厂界无组织废气气样\"(化验样品，非排放源管理)。前端 oa/pages/ehs/ 仅 board/capa/cert/command/hazard/incident/objective/permit/qms/safety.vue(全为安全质量页，无环保页)；全前端 grep『排污许可|环保合规义务清单|环境风险源|环境应急预案|环保税|自行监测方案|执行报告』=0。控制器 WaterExceedEvent.java/DischargeContract.java 头注释自证范围=\"运营管理中心·工业废水运营\"=代运营。TaxFiling.java taxType 注释列举税种无环保税。无任何 DischargePermit/EmissionSource/EnvEmergency/EnvTax 实体或控制器。"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "5. 安全设施管理 (消防/防雷防静电/气体检测报警器/通风设施 定期检查维保记录)",
   "verdict": "MISSING",
   "gap": "消防设施(灭火器/消火栓/报警器)、防雷防静电、气体检测报警器、通风设施的'设施台账+定期检查计划+维保记录+到期提醒'整类无对应实体与接口。",
   "severity": "med",
   "evidence": "grep '灭火器/消火栓/气体检测报警/防雷/通风设施' 在 domain+web 0 命中。仅通用 web/WorkOrderController.java、web/OpsMaintController.java(MaintOrder)，无安全设施专项台账/定期检查计划/维保记录。EhsWorkPermit 的 gasResult 是作业前气体检测，非'气体检测报警器设施'的维保。",
   "survives": true,
   "reNote": "缺口属实。质安部\"安全设施管理\"（消防/防雷防静电/气体检测报警器/通风设施 的\"设施台账+定期检查计划+维保记录+到期提醒\"）整类无对应实体与接口。我尽力推翻但无法成立：(1) 后端 domain/ 下无任何 Facility/Fire/Alarm/Ventilation/Lightning 安全设施实体，repository 里安全相关只有 SafetyCheckRepository，全代码库 grep \"安全设施/消防设施/防雷设施/气体检测报警器\" 在 domain/web/repository 零命中。(2) 唯一相关的 SafetyCheck 实体/SafetyCheckController 是\"隐患排查\"语义——字段为 type(安全/质量/环境)、result(合格/隐患/不合格)、level(隐患等级)、rectifyStatus(整改状态)，是一次性检查记录，没有\"设施作为台账资产(型号/位置/安装日期/有效期)+按设施滚动的周期检查计划+绑定设施的维保记录+设施有效期到期提醒\"四件套。(3) 存在维保计划\"计划+到期生成工单\"模式的 OpsMaintPlan/OpsMaintOrder 仅服务于工业废水 SewageEquipment，MaintOrder 仅服务于制造 MfgEquipment，均非 EHS 安全设施，且与消防/防雷/气体/通风无任何关联。(4) EhsWorkPermit 里的\"气体检测\"是动火/受限空间作业票的前置检测步骤，不是气体检测报警器设施台账。(5) 前端 /ehs/safety(safety.vue) 即 SafetyCheck 的 CRUD 列表(检查单号/检查地点/检查项/隐患等级/整改状态)，无设施台账/计划/维保/到期提醒。组织视图元数据更暴露了名实不符：块名\"安全设施管理\"标 status:\"built\" 但 pageLabel 实为\"安全检查隐患\"。",
   "reEvidence": "后端无实体/接口证据：ls domain|grep -iE \"Facility|Fire|Alarm|Ventil|Lightning\" 空；ls repository|grep 安全相关仅 SafetyCheckRepository.java；grep -rln \"安全设施|消防设施|防雷设施|气体检测报警器\" domain/ web/ repository/ 零命中。SafetyCheck 实体语义=隐患排查：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/SafetyCheck.java(字段 type/result/level/finding/rectifyStatus/dueDate)、控制器 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SafetyCheckController.java(/api/oa/safety-checks 纯CRUD，无台账/计划/维保/提醒)。维保计划模式仅限工艺设备：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/OpsMaintPlan.java(equipmentId→SewageEquipment) 与 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/MaintOrder.java(equipmentId→MfgEquipment)。EhsWorkPermit 的\"气体检测\"是作业票步骤：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/EhsWorkPermit.java:54-57。前端页面=隐患列表：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/ehs/safety.vue(列 code/type/location/item/level/rectifyStatus)。组织视图名实不符：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts 内 {\"name\":\"安全设施管理\",\"status\":\"built\",\"path\":\"/ehs/safety\",\"pageLabel\":\"安全检查隐患\"}。DataSeeder 仅有一条 safetyCheck(\"EHS-2026-0008\",...,\"消防器材配置与有效期检查\") 演示数据，非台账实体。"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "6. 体系认证与外部审核 (认证证书管理/外部审核管理/合规性评价)",
   "verdict": "PARTIAL",
   "gap": "1)外部审核管理(认证机构/客户/政府审核计划/审核前准备任务分配/审核中不符合项在线整改跟踪/审核报告归档)无专项实体。2)合规性评价(每年组织/QHSE法规符合性检查/生成评价报告/不符合项自动转入CAPA)无——EhsCapa.sourceType 枚举含'合规性评价'但无合规性评价实体作为触发源、无自动转 CAPA 链路。Certification 仅 list/get/create，无复评任务工作流。",
   "severity": "med",
   "evidence": "认证证书: domain/Certification.java + web/CertificationController.java(/api/oa/certifications，活体 7 条) 覆盖 ISO9001/14001/45001/安全生产标准化/施工资质，deriveStatus() 按 expireDate 读时派生 有效/即将到期/已过期; web/EhsBoardController.java certKpi() 实现'到期前6个月(180天)自动提醒复评'(活体 expiringSoon=1/expired=2)。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。逐项核验：\n\n(1) 外部审核管理（认证机构/客户/政府审核计划、审核前任务分配、审核中不符合项在线整改跟踪、审核报告归档）——无专项实体。全后端 grep「外部审核/ExternalAudit/外审/审核计划/AuditPlan/认证机构/certBody/监督审核/换证/复评任务/surveillance」仅命中 EhsCapa.java 的枚举注释与 StaffCredential.java 一句备注；对 domain/ 搜 auditPlan/auditOrg/certBody/nonconformity 零命中。现有 QmsRecord 仅内审/管评/不符合项扁平台账，Rectification/AuditFinding 属审计监察部（内审发现→整改），QualDeclaration 是资质申报/续期（PersonnelCert+费用+任务），均非「认证机构外审计划+审核前后全流程」实体。\n\n(2) 合规性评价——无实体，无自动转 CAPA 链路。ComplianceObligation 只是合规义务库（登记/状态/到期预警 alerts/due），不是「每年组织 QHSE 法规符合性检查→生成评价报告」的评价实体。自动建 CAPA 仅存在于 EhsIncidentController（sourceType=事故）与 EhsHazardController（sourceType=隐患）两处；「合规性评价」仅作为 EhsCapa.java 注释里的枚举字符串出现，无任何代码把它作为触发源 set/落库，更无自动转 CAPA。TriggerRuleEngine 对 capa/compliance/审核 零引用。\n\n(3) Certification 仅 list/get/create + 读时 deriveStatus 投影，无复评/换证/监督审核任务工作流。\n\n故 PARTIAL 判定成立。",
   "reEvidence": "无外部审核实体：grep 全后端「外部审核/ExternalAudit/审核计划/AuditPlan/认证机构/certBody/监督审核/复评任务」仅命中 domain/EhsCapa.java（枚举注释）与 domain/StaffCredential.java:19（一句备注）；domain/ 搜 auditPlan/auditOrg/certBody/nonconformity 零命中。\nCertification 仅 list/get/create：/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/CertificationController.java（@GetMapping list、@GetMapping/{id} get、@PostMapping create，外加只读 deriveStatus，无复评/工作流端点）。\n无合规性评价实体+无自动转 CAPA：唯二自动建 CAPA 在 /web/EhsIncidentController.java:212（c.setSourceType(\"事故\")）与 /web/EhsHazardController.java:228（c.setSourceType(\"隐患\")）；「合规性评价」仅出现在 /domain/EhsCapa.java:14、:36 注释，无代码设置该 sourceType；/repository/EhsCapaRepository.java 只有 findByStatus/findBySourceType/findBySourceTypeAndSourceId；service/TriggerRuleEngine.java 对 capa/compliance/合规/审核 零引用。\n合规义务相关实体 /domain/ComplianceObligation.java 与 /web/ComplianceObligationController.java 是义务库（登记/到期预警 alerts/due），非「合规性评价」评价实体。"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "7. 培训与资质管理 (培训计划与执行/人员资质管理/外来人员管理)",
   "verdict": "PARTIAL",
   "gap": "1)培训计划与执行(年度月度培训计划/在线报名/二维码人脸签到/考核成绩/培训记录自动归档个人档案)缺——grep '培训计划/签到/三级教育' 0 业务命中。2)人员资质'到期前自动推送培训复证任务'缺(PersonnelCertController 无到期预警/复证推送端点，grep alert/expir 0 命中)。3)外来人员管理只有访客出入证，缺承包商/临时作业人员安全教育记录、与门禁系统联动'未培训禁止入场'。",
   "severity": "med",
   "evidence": "人员资质: domain/PersonnelCert.java + web/PersonnelCertController.java(/api/oa/personnel-certs，活体 12 条) certType 含安全员证/特种作业证/建造师，status 与 expireDate 自洽; domain/StaffCredential.java(/api/oa/staff-credentials 200) 注册/职称/岗位证书+占用锁(建造师在建项目期间证不可二次占用 lockState/lockedProject)。外来人员: domain/AdminVisitor.java(访客出入证)。",
   "survives": true,
   "reNote": "缺口属实，三部分基本成立，无法推翻（仅第2部分有一处\"被动到期预警已存在\"的细化需指出）。1) 培训计划与执行：后端无任何培训计划/考核/签到的 controller 或 domain（web 目录无 Training*/SafetyEdu* 等；grep 培训计划/年度培训/月度培训/在线报名/人脸签到/二维码签到/三级安全教育 在后端 0 业务命中）。前端仅有一个通用台账页 admin/training.vue（课程/讲师/对象/日期/学时/考核结果6列），由 settingList 键值表持久化，属\"行政后勤中心\"而非\"工程管理中心/质安部\"，且无在线报名、无二维码/人脸签到、无考核成绩流程。StaffDossierController 虽设\"培训记录\"大类并纳入完整度必备清单，但条目 sourceEvent 默认\"手工上传\"，是手工归档而非由培训/考核事件自动归档，不满足\"培训记录自动归档个人档案\"。2) 人员资质到期自动推送复证培训任务：PersonnelCertController 仅 list/get/create/update/delete，无任何到期/预警/复证端点（已逐行读全文确认）。grep 复证/recert/续证/换证 0 命中。需指出：AlertScheduler 每小时确实扫描 PersonnelCert 按 expireDate 重算 即将到期/已过期，AlertController.aggregate() 也确实把它折叠成\"证件预警\"项进聚合预警流——所以\"被动到期预警/状态刷新\"是存在的。但二者均未对到期证件调用 notifications.notify、未创建任何\"复证培训\"任务（notify 只对超时审批实例触发），所以\"自动推送培训复证任务\"这一具体能力确实缺失，仅有只读预警标记。3) 外来人员管理：AdminVisitorController 仅访客预约→确认→通行码→扫码签到→签退工作流（AdminVisitor 实体字段=访客/公司/身份证/被访人/通行码/签到签退），无承包商/临时作业人员安全教育记录实体或端点，无与门禁系统联动\"未培训禁止入场\"逻辑。grep 承包商/外协(仅预算费用科目命中)/临时作业/进场培训/入场教育/安全交底 0 业务命中。综上 PARTIAL 判定成立。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/PersonnelCertController.java (全文仅CRUD，无到期/复证端点); oa-backend/src/main/java/com/kaidi/oa/task/AlertScheduler.java:144-168 (仅刷新证件状态，未对到期证件notify或建复证任务，notify仅用于超时实例line112); oa-backend/src/main/java/com/kaidi/oa/web/AlertController.java:104-113 (证件到期仅折叠为只读\"证件预警\"feed项); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/admin/training.vue:1-36 (通用settingList台账,无报名/签到/考核流程,挂行政后勤中心); oa-backend/src/main/java/com/kaidi/oa/web/StaffDossierController.java:52,175,192 (培训记录大类存在但sourceEvent默认\"手工上传\"=手工归档非自动); oa-backend/src/main/java/com/kaidi/oa/web/AdminVisitorController.java:1-60 + domain/AdminVisitor.java (仅访客通行码签到流,无承包商安全教育/门禁未培训禁入); grep 培训计划/人脸签到/二维码签到/三级安全教育/复证/recert/承包商安全教育=0业务命中"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "8. 数据分析与报告 (QHSE仪表盘/统计报表/趋势分析)",
   "verdict": "PARTIAL",
   "gap": "月/季/年周期报表自动生成与政府监管格式导出、隐患/事故/职业健康时序趋势分析 缺失；仅实时快照聚合。",
   "severity": "med",
   "evidence": "维持 PARTIAL。EhsBoardController/QhseDashboardController 均为只读当下快照聚合(计数/比率，byType/byCategory/byRiskLevel)，grep 趋势|trend|timeSeries|月度报表|季度报表|periodicReport 在 EHS/QHSE/Qms/SafetyCheck 控制器 0 命中——确无周期报表生成+政府格式导出(安全生产事故统计表/排污许可执行报告)、确无按时间下钻的隐患/事故/体检异常率时序趋势。仪表盘类型/部门维度有，时间维度弱。",
   "survives": true,
   "reNote": "Gap confirmed. QHSE data analysis is real-time snapshot only. No periodic (month/quarter/year) auto report generation, no government regulatory export, no hazard/incident/health time-series trend.",
   "reEvidence": "QhseDashboardController.java and EhsBoardController.java are point-in-time aggregations with no date bucketing. ReportDefinitionController safety source has no time/date dimension. Only @Scheduled is AlertScheduler.pushAlerts (hourly alerts). Live probes: /qhse-dashboard/trend=404, /ehs-board/trend=404, /qhse-dashboard/export=404.</parameter>\n</invoke>\n"
  },
  {
   "area": "工程管理中心/质安部",
   "module": "9. 与其他部门的接口要求 (生产/实验室/采购/HR/设备/环保设备/法务/申报 跨部门取数)",
   "verdict": "MISSING",
   "gap": "需求要求的跨部门'自动取数'接口几乎全缺: 1)生产制造中心质量数据(合格率/不良品)→质量目标 不自动取(TriggerRuleEngine 无 EHS 联动，grep 0)。2)实验室检测数据/环境监测/职业病危害因素检测→质量统计 不自动取。3)采购供应商质量评价/安全资质 不联动。4)HR员工档案(岗位/入离职)→职业健康 不联动、培训持证不回写个人档案。5)设备部特种设备台账/安全设施维保 不联动。6)法务合规义务库共享/事故法律应对协同 无打通。均为各自孤立台账，无自动数据流。",
   "severity": "med",
   "evidence": "EhsHazard/EhsIncident/EhsWorkPermit 均有 projectId 字段可关联工程项目(弱跨模块引用)。EhsCapa.sourceType 含'客户投诉'等可手填来源。认证证书可供申报(Certification 与 §申报 间无自动链)。",
   "survives": true,
   "reNote": "缺口基本属实。质安部的「跨部门自动取数」接口在质量目标/质量统计这条主线上确实缺失，未能推翻。逐条核验：1) 生产质量(合格率/不良品)→质量目标:不自动取——属实。EhsObjective(质量安全目标)只有手工 POST /ehs-objectives/{id}/collect 录实际值，applyAttainment 仅按手填 actualValue 算达成率/超差预警；EhsObjectiveController/EhsObjective.dataSource 只是自由文本标签,无任何逻辑读它去拉数；全仓没有任何 service 同时引用 QcInspectionRepository 与 EhsObjectiveRepository;TriggerRuleEngine.java 通读 7 条硬编码链(payment/seal/invoice/project/supplier/contract)+可配置规则,grep 对 EHS/质量目标/合格率/QcInspection 全 0,确无下游联动写质量目标。2) 实验室检测/环境监测/职业病危害因素→质量统计:不自动取——属实,无代码把 LabSample/WaterQuality/HealthRecord.hazardFactor 汇入 QmsRecord/EhsObjective。4) HR员工档案→职业健康不联动、持证不回写个人档案——属实,HealthRecordController 是孤立 CRUD(personName/dept/post 全自由文本,无 User/HR 外键),PersonnelCert/Certification 无回写个人档案逻辑。5) 设备特种设备台账/安全设施维保不联动——属实,MfgEquipment/SewageEquipment/MaintOrder 与 EHS 无打通。6) 法务合规义务库共享/事故法律应对协同——属实,ComplianceObligation/LitigationCase 与 EhsIncident 无联动。唯一需纠偏的反例(部分,不足以推翻):第3点采购供应商质量评价并非完全孤立——QcInspectionController 有真实跨模块逻辑:/qc-inspections/supplier-quality 按供应商名聚合 IQC 来料检验合格率(生产质量→供应商质量评价视图),且 IPQC 判不合格+返工会原子地把关联 WorkOrder 退回「生产中」触发返工,/trace 跨检验+工单+售后做序列号质量追溯。但这些是按字符串名的只读按需聚合,不回写 Supplier 台账、不拉安全资质、更不喂入质量目标,属「质量域内/质量→供应商视图」而非缺口主张的「质量目标/质量统计自动取数」。综合:缺口主张的核心(自动数据流入质量目标与质量统计、HR/设备/法务/实验室/环境打通)成立,real=true。",
   "reEvidence": "TriggerRuleEngine.java(7硬编码链+applyConfiguredRules,对EHS/质量目标/QcInspection grep全0); EhsObjectiveController.java:124-134 collect仅手填actualValue, :198-230 applyAttainment仅算手填值, dataSource(:64,:87)为自由文本无读取逻辑; EhsObjective.java:66/175-179 dataSource纯getter/setter; EhsBoardController.java/QhseDashboardController.java均为EHS域内只读聚合(SafetyCheck/QmsRecord/EhsHazard等),不跨生产/实验室/HR/设备/法务取数; HealthRecordController.java:53-75孤立CRUD无User外键; 全仓grep无service同时引用QcInspectionRepository+EhsObjectiveRepository; @Scheduled仅IntegrationScheduler/AlertScheduler,均不触及EHS/质量/health的自动取数。部分反例:QcInspectionController.java:280-300 /supplier-quality按供应商聚合IQC合格率, :213-223 IPQC不合格返工退回WorkOrder, :241-268 /trace序列号质量追溯——真实但仅质量域/只读,不写质量目标。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "1. 资料分类与档案库管理",
   "verdict": "PARTIAL",
   "gap": "无虚拟档案库实体/接口：ArchiveCategoryController 仅维护分类，无『按年度/部门/保密等级/保存期限维度建库(对应实体库房/密集架/电子存储区)』的任何实体或端点。存储位置管理完全缺失：Archive.java 无库房号/密集架排号/列号/层号/盒号字段，无条形码/二维码/RFID(全仓 grep 仅 EHS 模块 SewageEquipment/HazWaste 有 storageLocation/二维码，资料室无)，电子档仅 fileUrl/storedFileId 无云存储ID维度。metaFields 为逗号串，ArchiveCategory.java 类注释明确『仅作归档申请表单的提示用途，不强约束』。维持 PARTIAL。",
   "severity": "med",
   "evidence": "ArchiveCategory.java 实现多级分类(parentId)、保存期限规则(retentionType 永久/定期 + retentionYears)、归档编号前缀(codePrefix)，归档审核通过时按 ArchiveLifecycleService.computeRetentionDue 自动算到期日；ArchiveBoardController.retentionAlerts 做到期分级预警(已到期/紧急≤30/临近≤90/关注)。这三项确实 MET。",
   "survives": true,
   "reNote": "缺口属实。资料室档案体系只覆盖「分类+保存期限规则」(ArchiveCategory)、在线归档审核(ArchiveSubmission)、借阅(ArchiveBorrow)、评论(ArchiveComment)、看板聚合(ArchiveBoard)，共6个控制器，但完全没有『按年度/部门/保密等级/保存期限维度建库』映射到物理实体库房/密集架/电子存储区的实体或端点，也没有任何存储位置字段(库房号/排号/列号/层号/盒号)、条形码/二维码/RFID、以及电子档的云存储ID维度。我尽力试图推翻，但每一条都被代码证实，无法找到任何实现。",
   "reEvidence": "1) Archive.java(domain/Archive.java) 全字段：id/category/title/sourceType/sourceId/fileName/fileType/fileSize/uploader/archiveDate/tags/summary/accessLevel/fileUrl/storedFileId/createdAt——无任何库房号/密集架/排号/列号/层号/盒号字段。2) 对 domain/Archive*.java web/Archive*.java service/Archive*.java grep `库房|排号|列号|层号|盒号|架号|密集架|shelf|warehouse|storageLocation|cloudStorageId|ossKey|bucket` 与 `barcode|条形码|qrcode|二维码|rfid` 均 0 命中(exit 1)。3) 全仓 grep `storageLocation|密集架|RFID` 只命中 web/HazWasteManifestController.java、domain/HazWasteManifest.java、domain/SewageEquipment.java(均为 EHS)，资料室 0 命中——与缺口描述完全一致。4) 6个 archive 控制器 RequestMapping：/archives /archive-categories /archive-submissions /archive-borrows /archive-comments /archive-board，无任何「库房/存储区/虚拟档案库」端点；ArchiveBoardController.java:23 自述『无实体跨表聚合』。5) ls domain/ 无 shelf/warehouse/box/location/storage/vault/repository/library/cabinet/rack 任何实体类。6) StoredFile.java grep `cloud|oss|bucket|s3|minio|云` 0 命中，电子档无云存储ID维度。7) ArchiveCategory.java:22 注释原文『仅作归档申请表单的提示用途，不强约束』，且 metaFields 为逗号串，正如缺口所引。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "2. 资料归档与接收",
   "verdict": "PARTIAL",
   "gap": "自动归档接口仅一条：TriggerRuleEngine 只有 chainArchiveProject(ruleKey=project.toArchive,项目验收→项目档案)，无合同/财务报表/员工档案自动归档。批量导入文件夹结构/高速扫描仪集成/OCR建索引全缺(grep 无 ocr/批量导入)。归档交接清单+双方电子签名确认缺(ArchiveSubmission.java 无 handover/接收人/清单字段)。条形码/二维码打印缺。维持 PARTIAL。",
   "severity": "med",
   "evidence": "ArchiveSubmissionController 实现在线归档申请(create 必填 title/sourceDept)+归档审核(approve/reject/resubmit 状态机 待审核/已归档/已退回)+审核通过自动生成『前缀-年度-4位流水』档案编号并落正式 Archive(@Transactional)。这三项 MET。",
   "survives": true,
   "reNote": "缺口属实。我作为对抗复验员尽力推翻，但四条子主张全部成立，无法证伪。(1) 自动归档触发链确实仅一条：全后端唯一从工作流自动写入 Archive 的路径是 TriggerRuleEngine.chainArchiveProject(ruleKey=project.toArchive，第355-378行)，仅由 ruleAcceptProject(项目验收/结项/竣工/交付)触发；TriggerRuleEngine 的7条硬编码链中只有 project.accept 喂档案，无合同/财务报表/员工(HR)档案的自动归档。其余 new Archive() 均为手工(ArchiveController.create、ArchiveSubmissionController.approve)或种子(DataSeeder)。(2) 批量导入文件夹结构/高速扫描仪集成/OCR建索引全缺：grep ocr|barcode|scanner|批量导入|文件夹结构|扫描仪 在后端 Java 仅命中假阳性(OFBiz 弃用静态/生成 JSON、AllocRow 子串、SewageEquipment 的设备二维码/RFID)，无任何档案 OCR/扫描仪/批量导入实现。(3) 归档交接清单+双方电子签名确认缺：ArchiveSubmission.java 无 handover/接收人/清单/签名字段(仅 title/category/secLevel/reviewer/reviewOpinion/archiveCode 等)；Handover.java 是员工离职/调动/轮岗工作交接实体，与档案交接无关且自身无清单/签名；全后端 signature 概念仅存在于 TestReport/ServiceTicket/CslReport(实验/服务域)，归档流程零电子签名。(4) 条形码/二维码打印缺：approve 只生成文本 archiveCode(前缀-年度-流水号)，从不产出可打印条码/二维码。归档流程本质是手工在线提交+审核状态机(待审核→已归档/已退回)+单条项目验收自动链。维持 PARTIAL 判定正确。",
   "reEvidence": "TriggerRuleEngine.java:355-378 chainArchiveProject (唯一自动归档链,ruleKey=project.toArchive); TriggerRuleEngine.java:684 ruleKeyFor 仅 \"项目归档\"->project.toArchive 一条档案规则; ArchiveSubmission.java:27-87 全字段无 handover/receiver/checklist/signature; Handover.java:18-38 为员工工作交接(handoverType=离职/调动/轮岗交接)非档案交接且无签名/清单; ArchiveSubmissionController.java:136-181 approve 仅生成文本 archiveCode 无条码/二维码; ArchiveLifecycleService.java:58-61 buildArchiveCode 输出纯文本编号; grep barcode|ocr|scanner|批量导入|扫描仪 后端命中均为 OFBiz 弃用静态文件/AllocRow 子串/SewageEquipment 设备 RFID 等假阳性,无档案OCR/扫描/批量导入; signature 仅 TestReport.java:60/ServiceTicket.java:75/CslReport.java:61(实验/服务域,与归档无关)"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "3. 电子文件管理",
   "verdict": "PARTIAL",
   "gap": "版本控制缺失：Archive.java 无 version/现行/作废字段(grep version/版本/现行/作废 on Archive* 空);DocumentController.java 第51行 uploadMeta 恒置 setVersion(1)，无版本历史(CollabDoc 的 versionsJson 属文档协作另一模块)。水印/防篡改缺(grep 水印/watermark/防篡改 空)。OCR 可搜索缺。PDF/A 长期保存格式转换缺。批量下载/转移/改元数据缺。维持 PARTIAL。",
   "severity": "med",
   "evidence": "ArchiveController.list 全文检索对 title/tags/summary/fileName 做 contains，正文/元数据检索算 MET。",
   "survives": true,
   "reNote": "缺口属实。我尽力反驳但无法推翻，证据如下：\n\n【版本控制确缺】Archive.java（domain/Archive.java，全187行）字段只有 id/category/title/sourceType/sourceId/fileName/fileType/fileSize/uploader/archiveDate/tags/summary/accessLevel/fileUrl/storedFileId/createdAt——无 version/现行/作废/parentId/历史版本 任何字段。ArchiveController.create() 也不写任何版本字段。grep version/版本/现行/作废 在 Archive*.java 上确为空。\n\n【DocFile 版本是死值】DocumentController.java:50 uploadMeta() 恒置 setVersion(1)；该控制器只有 GET + POST /upload-meta 两个端点，无 PUT/PATCH/DELETE，无重新上传升版逻辑；全仓 grep 确认 DocFile.version 仅被 setVersion(1) 赋值一次，从不自增。CollabDoc 的 versionsJson（CollabDoc.java:42 历史版本JSON数组）确属\"文档协作\"另一模块（doccollab），与资料室档案无关。资料室/档案 无任何 *Version/*History 实体或仓库（find 为空）。\n\n【水印/防篡改：仅前端CSS叠加，后端零实现】唯一\"水印\"实现是前端 library.vue 的 CSS 伪元素叠加层（watermark 计算属性 + arc-preview__wm），属可视化遮罩，下载原件经 storedFileId 直取即绕过，不构成防篡改。后端 FileController/下载链路 grep watermark/水印/stamp/hash/sha256/digest 全空——无服务端水印嵌入、无文件完整性校验。ArchiveLifecycleService.java:77 的\"电子档需水印保护\"只是一句 Javadoc 注释，无对应代码。\n\n【OCR 缺】全仓 grep ocr/tesseract/可搜索/searchablePdf/extractText 中，唯一 extractText 在 AiService.java:157，是从 Anthropic API 响应 JSON 里取 content[].text，与扫描件 OCR 无关。\n\n【PDF/A 长期保存转换缺】grep pdfa/pdf-a/toPdfA/长期保存/itext/pdfBox/aspose 全空。\n\n【批量下载/转移/改元数据缺】DocumentController 与 ArchiveController 均无 batch-download/transfer/updateMeta 端点；Archive 无 PUT/PATCH（无改元数据），DocFile 同。\n\n故 版本控制、服务端水印/防篡改、OCR、PDF/A、批量操作 五项均确缺，PARTIAL 判定成立。",
   "reEvidence": "domain/Archive.java:22-57(字段无version/现行/作废); web/DocumentController.java:50(setVersion(1)恒值)及全控制器仅GET+upload-meta无PUT/PATCH; domain/DocFile.java(version字段仅被setVersion(1)赋值,从不自增); web/ArchiveController.java:99-128(create不写版本/无PUT/PATCH); service/ArchiveLifecycleService.java:77(水印仅Javadoc注释非实现); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/archive/library.vue:110,291(水印仅前端CSS伪元素叠加,非服务端嵌入/防篡改); service/AiService.java:157(extractText仅解析Anthropic响应JSON非OCR); grep watermark/ocr/pdfa/防篡改/批量下载/transfer 后端全空; domain/CollabDoc.java:42(versionsJson属doccollab协作模块,非资料室档案)"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "4. 实体档案管理",
   "verdict": "MISSING",
   "gap": "入库上架(扫码录位/移动端上架)、档案盒/卷管理(盒内文件清单+盒号位置绑定)、温湿度监控报警、档案破损修复记录与褪色虫蛀预警、销毁鉴定审批流程+实体销毁拍照视频留证+电子彻底/逻辑删除+销毁证明——五项子功能全部无任何实体或接口。仅 ArchiveBoardController.retentionAlerts 一条到期『预警』提示。维持 MISSING。",
   "severity": "high",
   "evidence": "全仓 grep 库房/密集架/盒号/排号/层号/barcode/条形码/RFID/销毁/destroy/温湿度/修复 在 domain/Archive*、web/Archive* 下均无承载;仅 ArchiveCategory/ArchiveBoard 注释里出现『鉴定销毁预警』字样(只是到期提示)。",
   "survives": true,
   "reNote": "缺口属实。工程管理中心/资料室的实体档案管理五项子功能全部无实现。档案域共6个控制器(Archive/ArchiveSubmission/ArchiveBorrow/ArchiveBoard/ArchiveCategory/ArchiveComment)+5个实体，我逐一通读，无任何字段或接口覆盖这五项：(1)入库上架/扫码录位——Archive、ArchiveSubmission 均无 locationCode/shelf/库位/扫码字段，无上架接口；(2)档案盒/卷管理——无档案盒实体、无 boxNo/盒号/盒内清单字段，ArchiveSubmission.archiveScope(全宗/案卷级/文件级)仅是文本标签非盒位绑定；(3)温湿度监控报警——全档案域无 temperature/humidity 字段(温度字段仅存在于无关的 FermentLog 发酵域)；(4)破损修复记录+褪色虫蛀预警——无修复/破损/褪色/虫蛀实体或字段，ArchiveBorrow.returnCheck(完好/缺页/污损)只是归还时一次性检查文本备注，非修复记录也非状态监测预警；(5)销毁鉴定审批+拍照视频留证+电子删除+销毁证明——ArchiveSubmission 状态机仅 待审核/已归档/已退回，无销毁态，无销毁审批接口、无 DELETE/彻底删除接口、无留证(照片/视频)、无销毁证明。整个档案域唯一涉及销毁的代码就是 ArchiveBoardController.retentionAlerts(只读到期预警)，正是描述里已点名的那一条。前端也无任何档案上架/盒管理/温湿度/修复/销毁页面。维持 MISSING 成立。",
   "reEvidence": "控制器: oa-backend/src/main/java/com/kaidi/oa/web/ArchiveController.java、ArchiveSubmissionController.java、ArchiveBorrowController.java、ArchiveBoardController.java(retentionAlerts 仅只读到期预警，58-78行)；实体: oa-backend/src/main/java/com/kaidi/oa/domain/Archive.java(字段仅 category/title/fileName/accessLevel/storedFileId 等，无库位/盒/温湿度/修复/销毁)、ArchiveSubmission.java(状态机 待审核/已归档/已退回，无销毁态)、ArchiveBorrow.java(returnCheck 仅归还检查备注)。grep 全 web/domain/service 对 销毁/destroy/鉴定/破损/修复/褪色/虫蛀/温湿度/库位/货架/盒号/扫码/上架 仅命中 ArchiveBoardController 注释与无关域(FermentLog.temperature、HazWasteManifest.storageLocation)。前端 ofbiz-framework/plugins/modern-ui/app/src 对 档案盒/扫码录位/移动端上架/温湿度/破损修复/褪色/虫蛀/销毁鉴定/销毁证明/实体销毁 全部零命中。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "5. 借阅与利用管理",
   "verdict": "PARTIAL",
   "gap": "电子借阅未实现获批后在线预览不可下载/截图、下载生成加密带水印PDF+7天有效期自动失效+全程日志(grep watermark/加密pdf/7天/有效期自动失效 空，仅 borrowType 状态字段)。实体借阅无扫码出入库。借阅统计仅 ArchiveBoardController.stats 按类别/状态计数，无借阅次数/热门档案排行榜/部门借阅统计。预约与续借完全缺(ArchiveBorrow.java 无 reserve/renew 字段，grep 资料室借阅域无)。维持 PARTIAL。",
   "severity": "med",
   "evidence": "ArchiveBorrowController 实现借阅申请(create 取 Archive 密级派生 approvalLevel)+分级审批(approve/reject)+电子&实体借出(lend，非在线预览须登记 dueDate)+归还检查(giveBack 登记 returnCheck 完好/缺页/污损)+逾期催还(ArchiveBoardController.overdueBorrows 按 dueDate 标红)，状态机逻辑闭环，MET。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。资料室借阅域只有\"状态机+密级分级审批+逾期催还\"，缺口列举的进阶能力确实全部缺失。后端 ArchiveBorrow.java 仅 18 个字段（id/code/archiveId/archiveTitle/secLevel/borrower/borrowerDept/borrowType/purpose/applyDate/dueDate/returnDate/approvalLevel/status/approver/approveOpinion/returnCheck/createdAt），borrowType 仅为标签字符串（在线预览/电子下载/实体借出），无 reserve/renew/qr/borrowCount 任何字段。ArchiveBorrowController 仅 create/approve/reject/lend/return 状态流转。\\n\\n逐条核对：\\n1) 电子借阅\"获批后在线预览不可下载/截图、下载生成加密带水印PDF+7天有效期自动失效+全程日志\"——后端 grep watermark/加密pdf/7天/有效期自动失效 全空；lend() 里所谓\"有效期\"只是校验 dueDate 字符串非空（实体借出/电子下载须填预计归还日），并非自动失效机制；无加密PDF生成（后端无 PDFBox/iText，命中项仅前端静态打包产物）、无下载日志、无防截图。前端 library.vue 确实有\"水印\"，但只是 CSS 旋转叠加层（--wm content）+ FilePreview 的 watermark prop（纯展示），且 downloadControlled() 与 FilePreview 的\"下载原文件\"链接直接下载原件——与\"不可下载\"相悖，且不生成加密水印PDF、无7天失效。\\n2) 实体借阅无扫码出入库——grep 扫码/qr/出入库 在 archive 域全空。\\n3) 借阅统计——仅 ArchiveBoardController.stats 按类别/状态计数 + security.vue 按\"密级\"聚合借阅次数；无按档案的借阅次数/热门档案排行榜、无部门借阅统计。\\n4) 预约与续借完全缺——无 reserve/renew 字段或端点。\\n维持 PARTIAL 成立。",
   "reEvidence": "后端实体 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/ArchiveBorrow.java（18字段，无 reserve/renew/qr/borrowCount）；控制器 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ArchiveBorrowController.java（仅状态机，lend() 第143-146行只校验 dueDate 非空，非自动失效）；仓储 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/repository/ArchiveBorrowRepository.java（仅 findByStatus/ArchiveId/Borrower）；看板 /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ArchiveBoardController.java（stats 仅按类别/状态计数，无借阅次数/热门排行/部门统计）。前端：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/archive/library.vue（第110/138-149/279-287行：水印仅CSS叠加层，downloadControlled 直下原件、无加密PDF/7天失效）；borrow.vue（仅状态机，无预约/续借/扫码）；security.vue（第44-48行仅按密级聚合借阅次数，非档案级排行/部门统计）。grep 验证：后端域内 watermark/水印/加密/7天/有效期自动失效/reserve/renew/续借/预约/扫码/qr/出入库/借阅次数排行 全部为空（命中项均在 Reagent/License/Visitor 等无关模块或前端静态打包产物 pdf.worker/vendor-element-plus）。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "6. 保密与权限管理",
   "verdict": "LOGIC_GAP",
   "gap": "细粒度权限(单档/文件夹的可见/预览/下载/打印/改/删/授权,按部门/岗位/项目组动态授权)无：grep acl/permission/可下载/可打印/grantee/授权 on Archive* 空，ArchiveController 仅 isConfidential 密级粗粒度(含『密』即仅 ADMIN/APPROVER)。脱敏与遮挡(身份证号/银行账号自动脱敏)在档案侧无(grep 脱敏/mask/遮挡 on Archive* 空，仅 StaffDossier 域有 idCardMasked)。维持 LOGIC_GAP。",
   "severity": "high",
   "evidence": "config/AuditLogInterceptor.java 第46行 WRITE_METHODS=Set.of(POST,PUT,PATCH,DELETE)，第73行 if(!WRITE_METHODS.contains(method))return —— 注释明确『读请求 GET/HEAD/OPTIONS 不留痕，避免日志爆量』。需求6要求对档案的查询/预览/下载/打印均记录操作人/时间/IP/操作类型保存≥6个月，正是读访问留痕，当前完全不记。承载(哈希链 OperationAuditLog)有但档案读访问留痕逻辑空。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。彻查档案/资料室全部实体与控制器后确认：(1) 无细粒度权限——Archive/DocFolder/DocFile 实体均无任何 ACL/grantee/可见/预览/下载/打印/改/删/授权 字段，更无按部门/岗位/项目组的动态授权；ArchiveController 仅有 isConfidential(accessLevel 含『密』→仅 ADMIN/APPROVER 列表过滤+详情403)这一粗粒度密级控制，对所有非机密档案一律全员可见，对所有机密档案一律仅两个全局角色，无法做到单档/单文件夹粒度或按动作区分。FolderController 是完全公开的目录树(无任何鉴权)。所谓\"权限/授权\"命中均为他义：ArchiveBorrow 是借阅审批流(按密级派生审批级别,非档案对象级 ACL)；FileController 的属主校验属通用 File 模块(仅上传者本人/ADMIN),非按部门/岗位/项目组动态授权且不覆盖 Archive 域；RdGrantDisbursement 的 grant 是科研经费拨付,与权限无关。(2) 无档案侧脱敏遮挡——grep 脱敏/mask/遮挡/身份证/银行账号 命中全部在 Archive 域之外(StaffDossier/UserController/BankReconciliation 等),Archive*/Doc*/Folder*/File* 控制器与实体内零命中,身份证号/银行账号自动脱敏在档案内容侧确实不存在。维持 LOGIC_GAP。",
   "reEvidence": "web/ArchiveController.java:46-59 (isConfidential 仅含『密』即 ADMIN/APPROVER 粗粒度) 与 :78-97 (列表剔除+详情403)；domain/Archive.java:50 accessLevel 为唯一访问控制字段、无任何 grantee/动作级 ACL；domain/DocFolder.java:13-23 仅 id/name/parentId 无 ACL；domain/DocFile.java:15-40 无 ACL/可见/打印字段；web/FolderController.java:26-46 目录树完全公开无鉴权；脱敏命中(grep desensit/脱敏/mask/遮挡)仅出现在 web/StaffDossierController.java、web/UserController.java、web/BankReconciliationController.java、domain/StaffDossier.java 等 Archive 域外文件，Archive*/Doc*/File* 控制器与实体 grep 脱敏/mask/遮挡/身份证/银行账号 EXIT=1 零命中；ArchiveSubmission.sourceDept(:43)仅为来源部门溯源元数据非授权范围；RdGrantDisbursement 为科研经费拨付与 ACL 无关。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "7. 合规与审计支持",
   "verdict": "PARTIAL",
   "gap": "无档案维度专门审计报告与一键导出(哈希链是全局写审计，非档案归档合规/借阅/销毁/权限变更四维报告)。电子签名+可信时间戳完全无(grep signature/timestamp on Archive*/ArchiveBorrow* 空)。电子档案自动备份(本地+异地/云)+备份策略可配+灾难恢复演练记录无(grep 备份/backup/灾难恢复/异地 on Archive* 空)。永久档案自动转 PDF/A、XML 长期格式+定期可读性检查无。维持 PARTIAL。",
   "severity": "med",
   "evidence": "AuditLogInterceptor 不可篡改哈希链(sha256(prevHash+规范化字段)，chainLock 串行续链)对写操作做审计追踪，部分覆盖归档/借阅/销毁(到期)/权限变更写动作。",
   "survives": true,
   "reNote": "缺口属实。我作为对抗复验员尽力在前后端彻查，无法推翻这条 PARTIAL 判定——四项专门能力确实都未实现。资料室实有：security.vue 的借阅访问留痕台账(按密级聚合)、monitor.vue+ArchiveBoardController 的三块聚合(保存期到期/鉴定销毁预警、借阅逾期催还、统计概览)、以及全局哈希链审计 OperationAuditLog(通用写审计，非档案维度)。但缺口所列四项均缺：(1)无「归档/借阅/销毁/权限变更」四维专门合规审计报告，更无一键导出——看板只给临时统计/预警，无 export/审计报告端点，security.vue 仅覆盖借阅+权限单一视角且无导出；(2)电子签名+可信时间戳完全无；(3)自动备份(本地+异地/云)+备份策略可配+灾难恢复演练记录完全无；(4)永久档案自动转 PDF/A、XML 长期格式+定期可读性检查完全无。PARTIAL 成立。",
   "reEvidence": "grep 在所有 Archive*(后端 domain/web/service + 前端 oa/pages/archive/*.vue, oa/api/archives.ts)上：signature|timestamp|签名|时间戳|签章 => 0 命中；backup|备份|灾难|异地|disaster|cloud|容灾 => 0 命中；PDF/A|PDFA|长期格式|可读性|format migration => 0 命中。导出/审计报告类：全库 grep archive ∩ (export|report|audit|signature|timestamp|backup|pdfa) 仅命中 AuthInterceptor 路径白名单，无任何 export/审计报告控制器；\"销毁\" 仅出现在 ArchiveBoardController.java:27/51 的保存期到期预警注释，并非销毁维度报告。ArchiveBoardController 仅 3 个只读端点 /retention-alerts /overdue-borrows /stats，无四维合规报告、无导出。OperationAuditLog 字段为 operator/method/path/resourceType+sha256 哈希链，是全局通用写审计，无档案维度。前端 archive 目录9个页面(board/borrow/categories/globalsearch/library/monitor/search/security/submission)，对四项关键词 grep 全 0 命中。"
  },
  {
   "area": "工程管理中心/资料室",
   "module": "8. 与其它部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "8 个部门接口仅项目一条自动归档。法务(合同/诉讼/知识产权)、监理(图纸/验收/监理日志版本归档)、财务(凭证/账簿/报表)、人事、知识产权(专利商标著作权)、质安(质量/安全/特种设备)、申报服务部(证书检测报告)均未实现自动获取/自动归档/版本现行有效。人事侧：StaffDossierController.java 仅 import StaffDossierItemRepository/StaffDossierRepository，不引用 ArchiveRepository——其『归档』是员工档案册内部概念，不写入资料室 Archive 库。维持 PARTIAL。",
   "severity": "med",
   "evidence": "TriggerRuleEngine 实现项目验收→项目档案一条自动通道(chainArchiveProject，ruleKey=project.toArchive)。",
   "survives": true,
   "reNote": "缺口属实。资料室对 8 个部门接口仅实现\"项目\"一条自动归档，其余 7 个部门(法务/监理/财务/人事/知识产权/质安/申报服务部)均无自动获取/自动归档/版本现行有效的实现。我尽力从四个方向寻找其它部门的自动归档路径(直写 ArchiveRepository、ArchiveSubmission 自动喂入、service 层归档链、版本机制)，全部落空。\n\n具体证据链：\n(1) 全后端唯一向资料室 Archive 库自动写入的联动是 TriggerRuleEngine.chainArchiveProject()(ruleKey=project.toArchive)，仅在项目验收/竣工(验收/结项/竣工/交付)办结时触发，正是描述中的\"项目一条\"。service 层全局搜索 chain*Archive 只此一个，没有 chainArchiveContract/Supervision/Voucher 等对应其它部门的链。\n(2) new Archive()/archiveRepo.save 的全部写入点只有 4 处：DataSeeder(造种子)、ArchiveController(手工 create 端点)、ArchiveSubmissionController.approve(人工提交归档申请→审核通过落档)、TriggerRuleEngine.chainArchiveProject(项目链)。前两者非自动、第三者是人工申请制(new ArchiveSubmission() 仅在 create() 手工 POST 产生，无任何部门控制器自动喂入)。\n(3) 8 个部门控制器(LegalConsult/SupervisionInspection/SupervisionLog/Voucher/Patent/Certification/Declaration/SafetyCheck/QmsRecord)对 Archive/archiveRepo/ArchiveSubmission/归档/资料室/档案库 零引用——它们完全没有自动归档接线。\n(4) 人事侧确认：StaffDossierController 只 import StaffDossierItemRepository/StaffDossierRepository，从不引用 ArchiveRepository；其 addItem 写入的是 StaffDossierItem(员工档案册内部条目)，且硬编码 it.setAutoArchived(Boolean.FALSE)、sourceEvent 默认\"手工上传\"，不写入资料室 Archive 库。StaffDossierItem 上虽有 autoArchived 字段，但 JavaDoc 措辞为\"可由相应流程自动归档\"(aspirational)，无任何事件流调用置 true。\n(5) 全后端搜索\"现行有效\"/版本归档/版本机制——零命中，无版本现行有效实现。\n维持 PARTIAL。",
   "reEvidence": "service/TriggerRuleEngine.java:355-378 (chainArchiveProject 唯一自动归档链, ruleKey=project.toArchive, 仅项目验收触发); service/TriggerRuleEngine.java:122-124,347-348 (验收关键词→chainArchiveProject 调用点); web/ArchiveSubmissionController.java:81-104,156-171 (ArchiveSubmission 仅手工 POST create + approve 人工审核落档, new ArchiveSubmission 全项目唯一产生点); web/StaffDossierController.java:8,57(只注入 StaffDossier*Repository 无 ArchiveRepository),178-199(addItem 写 StaffDossierItem 且 line193 硬编码 setAutoArchived(FALSE)); domain/StaffDossierItem.java:16,45-46 (autoArchived 字段+JavaDoc 仅\"可由流程自动归档\"措辞, 无实调用); grep 确认 LegalConsult/Supervision*/Voucher/Patent/Certification/Declaration/SafetyCheck/QmsRecord 控制器对 Archive/归档/资料室/档案库 零引用; grep \"现行有效\"/\"版本归档\" 全后端零命中"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "2. 专利管理（侧重工程领域）",
   "verdict": "PARTIAL",
   "gap": "本单元Patent为薄CRUD；研发中心IpAsset套件补足了申请流程/法律状态/年费但仍缺IPC结构化分类标签与许可/转让/质押转化运营；交底书新颖性评估决策、中间文件管理、国知局同步、证书扫描件均无。",
   "severity": "med",
   "evidence": "本单元口径专利页 = PatentController(/api/oa/patents) + Patent.java，确系薄CRUD：Patent仅11字段(name/type/patentNo/applicant/inventors/rdProjectId/applyDate/status/feeDueDate/annualFee/createdAt)，update只覆盖给定字段，无技术交底书新颖性/创造性评估决策、无受理/初审/实审/补正/意见陈述中间文件、无国知局同步、无证书扫描件、无年费周期自动测算、无IPC/许可转让质押。更丰富的IpAsset套件(IpAssetController 611行)确实存在且覆盖了部分子项——stage状态机(提案→…→已授权)、法律状态LEGAL_STATUSES自动联动推进、IpFee年费台账scheduleFees按授权日+(n-1)年自动排程并分级预警feeAlerts、payFee联动资金支付中心+回写totalCost、IpAssetEvent不可删事件链。但即便IpAsset也确缺：domain/IpAsset.java字段表无ipcClass/license/transfer/pledge/tag字段(仅techField+productLine两个自由文本，注释自称'用于侵权分析'但无结构化IPC分类)，无许可/转让/质押转化运营。且IpAsset属研发创新中心口径，非本单元'专利页'。初判PARTIAL成立。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但无法成立——静态读码+全量grep+活体三重验证都证实所列子项确缺。(1) Patent(工程域专利单元,活体15条)确为薄CRUD：仅 id/name/type/patentNo/applicant/inventors/rdProjectId/applyDate/status/feeDueDate/annualFee/createdAt 12字段,无任何流程/转化/分类。(2) RD中心 IpAsset 套件(IpAsset+IpAssetEvent+IpFee+IpAssetController+IpInsightController)确实补足了申请流程状态机(stage:提案→…→已授权)、法律状态线(legalStatus)、官方编号/证书号、年费/期限台账+缴费联动+分级预警+费用归集+BI——但缺口正是承认了这部分。(3) 缺口逐项核对全部成立：IPC结构化分类号——全库无 ipc/分类号 字段(仅匹配到 ipCount 等无关词);许可/转让/质押转化运营——无任何实体/端点,活体 POST ip-assets/{id}/license|transfer|pledge 全部404,\"许可\"命中项均为软件席位许可(SoftwareLicense)与资质证(QualCert),与专利运用转化无关;交底书新颖性评估决策——无 novelty/可专利性/查新决策(查新报告仅存在于 WorkMethod 工法,非专利新颖性评估);中间文件管理——无 officeAction/审查意见/中间文件实体(NONE);国知局同步——\"国家知识产权局/国知局\"仅作为付款单收款方字符串与清单口径名出现,无任何对接/同步逻辑;证书扫描件——certNo 仅为裸字符串,无 StoredFile/扫描件/附件引用(QualCert 才有扫描件字段)。(4) 需求 Request.MD 第54行明确要求知识产权\"运用转化\"及全生命周期,证明这些是真实预期功能而非臆造。综上 PARTIAL 判定准确,缺口为真。",
   "reEvidence": "domain/Patent.java(12字段薄CRUD,无IPC/转化/文件) + web/PatentController.java(纯CRUD,无转化端点) | domain/IpAsset.java:69-75(applyNo/publicNo/grantNo/certNo均为String,无IPC字段、certNo无扫描件引用) | web/IpAssetController.java(流程状态机STAGE_FLOW+年费台账+缴费联动,但无许可/转让/质押/中间文件/国知局同步) | web/IpInsightController.java:181,397(国知局仅作清单口径名与付款收款方) | 全库grep:'ipc/分类号'无专利分类号命中、'许可/质押/transfer/license'仅命中SoftwareLicense席位与QualCert资质、'中间文件/officeAction/审查意见通知'=NONE、'新颖性/查新决策'仅在WorkMethod | 活体127.0.0.1:8091: GET /api/oa/patents 返回12字段; POST ip-assets/1/{license,transfer,pledge} 与 patents/1/license 全部HTTP 404 | requirements/Request.MD:54(专利工法办\"专利挖掘/申报\"),:54+:355链6要求IP\"运用转化\"全生命周期"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "3. 工法与专利的协同挖掘",
   "verdict": "PARTIAL",
   "gap": "无专利数据库(incoPat/智慧芽)对接、无在线查新/相似专利检索；技术成果库无全文检索复用入口(FTS引擎不索引IP/工法/成果)。",
   "severity": "med",
   "evidence": "创新点联动已实现(WorkMethod.patentId+bindPatent冗余patentName，IpInsight project-matrix把RdProject下挂IP/成果/申报关联起来)，故'协同挖掘'非全缺。但查新与检索整块确缺：grep incopat/智慧芽/查新/novelty/相似专利 无任何专利库对接；service/FullTextSearchService.java与seed/FtsIndexRunner.java经grep确认完全不索引patent/workMethod/techAchievement(grep patent|workMethod|工法|专利|techAchievement 零命中)；SearchController同样不覆盖。技术成果库TechAchievement有CRUD与状态机但无按关键词全文检索复用入口。初判PARTIAL成立。",
   "survives": true,
   "reNote": "缺口属实，三项专利-工法协同挖掘能力确实未实现，无法推翻。(1) 无任何外部专利数据库对接：全后端 grep RestTemplate/WebClient/HttpClient/OkHttp/HttpURLConnection/feign 零命中，不存在 incoPat/智慧芽/PatSnap 的 API 客户端、密钥或查询。前端 rd/ipmonitor.vue 里的\"智慧芽预警\"只是 settingListStore('rd-ipmonitor', [...]) 的静态 mock 种子字符串(手维列表)，并非真对接。(2) 无在线查新/相似专利检索：全后端无任何带 search/novelty/similar/查新/检索/相似 的 @GetMapping/@PostMapping(仅 SearchController 的通用 FTS)。\"查新报告\"仅作为 WorkMethodApplication 的必备材料清单标签(REQUIRED_MATERIALS=申报书/工法文本/查新报告/应用证明/经济效益证明)存在，是文档勾选项而非检索引擎。Patent 域无 novelty/similarity 字段。(3) FTS 引擎不索引 IP/工法/成果：FullTextSearchService 只索引 11 类(事项/公告/讨论/调查/纪要/合同/供应商/客户/公司/文档/协作文档)，根本未注入 PatentRepository/WorkMethodRepository/TechAchievementRepository/IpAssetRepository，技术成果库(TechAchievementController 仅有登记/状态机/证书+关联，无检索复用入口)。PatentController/WorkMethod/TechAchievement 均为基础 CRUD+状态机，三项协同挖掘能力均缺失。判定 PARTIAL 准确。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/PatentController.java(纯CRUD,无查新/相似/外联); oa-backend/src/main/java/com/kaidi/oa/web/SearchController.java + service/FullTextSearchService.java(reindexAll 仅索引11类,无Patent/WorkMethod/TechAchievement/IpAsset 注入); oa-backend/src/main/java/com/kaidi/oa/web/TechAchievementController.java(登记+状态机+证书,无FTS复用入口); oa-backend/src/main/java/com/kaidi/oa/web/WorkMethodController.java:366-367(查新报告仅为REQUIRED_MATERIALS清单标签); oa-backend/src/main/java/com/kaidi/oa/domain/Patent.java(无novelty/similarity字段). 前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/ipmonitor.vue:5(智慧芽预警为settingListStore静态mock种子,非真对接). 全后端 grep RestTemplate|WebClient|HttpClient|okhttp|feign 零命中; grep novelty|similar|查新|检索 的Mapping零命中(SearchController除外)."
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "4. 申报材料与文档管理",
   "verdict": "PARTIAL",
   "gap": "无按申报要求自动打包/合并PDF/一键导出或在线提交；无模板更新通知；文档版本控制仅工法整体粗粒度，无文档级每改新版+提交锁版。",
   "severity": "med",
   "evidence": "模板库DeclarationTemplate存在；附件/材料齐备清单已实现(WorkMethodApplication.materials '名:0/1'格式 + missingMaterials校验，进入材料提交强制5类必备材料齐全)。但自动生成申报包确缺：grep pdfbox/itext/mergePdf/申报包/合并pdf 在web/service/domain无真实PDF打包实现(唯一命中是WorkMethodApplication.java域注释提及materials)，无一键导出/在线提交。模板更新自动通知相关人员未见。文档级版本控制仅靠WorkMethod.version(create置1、upgrade整体复制正文+1)粗粒度承载，无申报书/工法文本逐文档每改生成新版+提交前锁版。初判PARTIAL成立。",
   "survives": true,
   "reNote": "缺口属实，三条子主张全部成立，无法推翻。模块实体为 WorkMethod(工法，专利工法办)+WorkMethodApplication(申报)。(1)无自动打包/合并PDF/一键导出/在线提交：全后端无 PDFBox/iText 依赖，WorkMethmethod/Declaration/Patent 三组控制器内零 produces=application/pdf、application/zip、byte[]、OutputStream、/export、/package、/merge、/download 端点；申报材料 materials 字段只是\"名:0/1\"齐备标志位，advanceApplication 进\"材料提交\"时仅 missingMaterials() 校验5类材料是否打勾，并不真正抓取/合并文件成包。(2)无模板更新通知：DeclarationTemplateController 仅 GET/POST CRUD（连 PUT 都没有），无任何 模板通知/订阅/notify 机制。(3)版本控制确为工法整体粗粒度：version(Integer)+parentId 挂在 WorkMethod 主实体上，/upgrade 时整条工法旧版标记\"已废止\"、整体复制生成 V+1，是方法级粗粒度；九大正文要素 contentFeature…contentBenefit 均为可随意改写的 @Lob 普通字符串，无文档级每改新版、无 @Version/fileVersion/docVersion、无提交锁版。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/WorkMethodController.java(全23端点无导出/打包，第414-427行 patchApplication 直接覆盖 materials 字符串，第723-744行 missingMaterials 仅解析0/1标志位，第577-629行 upgrade 整条工法升版); oa-backend/src/main/java/com/kaidi/oa/domain/WorkMethod.java(第120-125行 version/parentId 工法级版本); oa-backend/src/main/java/com/kaidi/oa/domain/WorkMethodApplication.java(第52-57行 materials 注释\"材料名:0/1\"); oa-backend/src/main/java/com/kaidi/oa/web/DeclarationTemplateController.java(仅 list/get/create，无更新通知). 全库 grep PDDocument/PDFMergerUtility/itext/pdfbox/application,zip/byte[]/模板通知/订阅 均无命中。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/workmethod.vue grep 打包/合并/pdf/导出/export/在线提交/锁版/lock 全部无命中，仅工法整体 V{{row.version}} 展示。"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "5. 申报进度与预警",
   "verdict": "PARTIAL",
   "gap": "无年度申报计划实体与完成率跟踪；工法侧官方法定时限仅手填deadline，未按法定规则(实审3年/补正2月)自动推算。",
   "severity": "med",
   "evidence": "进度看板/官方时限/超期预警已建(WorkMethodDashboard progress停留天数+超期flag、deadline-alerts、cert-alerts证书到期6月预警；IpAsset feeAlerts分级)。但申报计划确缺：无年度专利/工法申报计划(数量/类型/责任部门/预算)实体——grep 申报计划/annualPlan/filingPlan/完成率在本域无命中。法定时限自动推算确缺：domain/WorkMethodApplication.deadline是普通String手填字段(行50 private String deadline，advanceApplication里a.setDeadline(req.deadline())直接取请求体)，未按'实审请求申请日起3年/补正答复发文日起2个月'法定规则自动推算；IpFee.feeType虽含'实审请求/补正答复'枚举但autoDueForYear只按授权日+yearNo推算年费，不实现这两类法定期限的规则化推算，且IpFee属IpAsset口径非本单元工法。初判PARTIAL成立。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实(PARTIAL 判定准确)。两条子缺口均成立：\n\n【子缺口1：无年度申报计划实体+完成率跟踪】成立。\n- domain 目录的计划类实体(BizPlan/BrandPlan/FundPlan/OpsMaintPlan/RepaymentPlan/WorkPlan)无一是\"申报/工法年度计划\"。grep `AnnualPlan|DeclarationPlan|annualTarget|planCount|年度申报|年度计划` 在该域(Declaration*/WorkMethod*/Patent/IpAsset)零命中(仅 Brand/EHS 等无关控制器出现)。\n- DeclarationDashboardController(/api/oa/declaration-dashboard)和 WorkMethodDashboardController(/api/oa/work-method-dashboard)确有看板，但只是对\"实际已发生记录\"的描述性聚合：通过率(已决做分母)、ROI、各状态分布、停留天数。没有\"年度计划目标数\"作为分母，因此不存在\"计划数 vs 实际完成数 = 申报计划完成率\"这一跟踪。AuditDashboard/OpsKpi/BizPlan 等有 completionRate，但都是别的域，且都不是申报计划。\n\n【子缺口2：工法侧 deadline 仅手填，未按法定规则(实审3年/补正2月)自动推算】成立。\n- WorkMethodApplication.deadline 为普通 String，JavaDoc 写\"法定/约定答复期限…到期自动预警\"，但赋值处只有手填：WorkMethodController 第423行 patch `a.setDeadline(req.deadline())`、第461行 advance `a.setDeadline(req.deadline())`，无任何按官方状态/级别推算期限的逻辑。\n- 全后端 grep `plusYears(3)|plusMonths(2)|实质审查|实审请求自动|补正答复自动` 无任何\"申请日+3年=实审 / 通知日+2月=补正\"的规则。WorkMethodController 唯一的日期自动算是第476行证书有效期 today.plusYears(8)(证书有效期，非申报法定时限)。\n- 专利/IP 旁证同样缺：IpAssetController.autoDueForYear / 第362行 grant.plusYears(n-1) 只自动算\"年费\"到期日；IpFee 注释虽称\"法定期限节点(补正答复/实审请求/优先权期限)dueDate 由系统按期限模板自动计算\"，但代码无该模板——这些节点 dueDate 实际仍走手填 req.dueDate()，autoDueForYear 对无 yearNo 的法定节点返回 null。\n\nWorkMethodDashboardController 的 deadline-alerts(第170-193行)正是基于这条手填 deadline 做预警，前提数据非法定推算，进一步印证 PARTIAL：预警机制在、但法定时限自动推算与年度计划完成率两个能力确缺。",
   "reEvidence": "WorkMethodController.java:423 `if (req.deadline() != null) a.setDeadline(req.deadline());`(手填) 与 :461 `a.setDeadline(req.deadline());`(advance 仍手填)；:476 唯一日期自动算是证书有效期 `m.setCertExpireDate(today.plusYears(8).toString())`。WorkMethodApplication.java:50/133 deadline 仅普通 String + setter。WorkMethodDashboardController.java:170-193 deadline-alerts 直接读 a.getDeadline()。IpAssetController.java:316/362/597 autoDueForYear 仅 `grant.plusYears(yearNo-1)` 算年费，对法定节点(补正答复/实审请求)无推算、回落 req.dueDate()。IpFee.java:15-17 注释声称法定期限节点自动算但无对应代码。grep 全 oa-backend 无 `plusYears(3)`/`plusMonths(2)`/实审或补正法定推算规则；grep `AnnualPlan|DeclarationPlan|annualTarget|planCount` 在申报/工法域零命中。DeclarationDashboardController.java(/api/oa/declaration-dashboard)与 WorkMethodDashboardController.java 仅做实际记录的通过率/ROI/状态分布/停留天数聚合，无\"年度计划目标→完成率\"跟踪。"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "6. 费用与预算管理",
   "verdict": "LOGIC_GAP",
   "gap": "工法totalCost仅置0无台账录入回写，ROI投入端死；预算控制整块缺失；政府资助管理无与工法/专利的对接(资助窗口提醒/到账关联)。",
   "severity": "med",
   "evidence": "确认死逻辑：grep setTotalCost 在工法侧仅2处命中，均为BigDecimal.ZERO——WorkMethodController.java:158(create)与:618(upgrade)。无任何工法费用台账实体(domain目录无workMethodFee/methodfee/wmfee)，无端点录入申请费/代理费/年费/查新费/奖励费并回写totalCost。WorkMethodDashboard roi()里invest=totalCost(常年0)+奖励，故ROI投入端只剩奖励、费用恒0。预算控制整块缺(无年度总预算/各类型预算/超预算预警)。政府资助管理缺：RdGrantDisbursementController与PolicyApplicationController经grep均不引用patent/workMethod/ipAsset，无资助窗口期提醒/到账关联工法专利。注：IpAsset侧IpFee台账+payFee回写totalCost是真实现的，但工法侧totalCost无来源，故工法ROI投入端死。初判LOGIC_GAP成立。",
   "survives": true,
   "reNote": "缺口属实。三个子断言逐一核实后均成立，无法推翻。\n\n(1) 工法 totalCost 投入端死 —— 属实。grep `setTotalCost` 全仓只有 4 处：WorkMethodController.java:158(create 置 ZERO)、:618(upgrade 置 ZERO)、IpAssetController.java:150/410(那是专利/IP资产侧，跟工法无关)。WorkMethod 没有任何费用台账子表(repository 下只有 Application/Event/Review/Reward/Usage 五张子表，无 Cost/Fee)，也没有任何端点向 WorkMethod.totalCost 累加。addUsage(WorkMethodController.java:512-550) 只回写 totalSaving(产出端)，从不碰 totalCost。WorkMethodDashboardController.roi():216-233 把 `Money.nz(m.getTotalCost())` 当投入分母，但该值恒为 0，ROI 投入端确实是死的(只有 reward 被合成进 invest，查新费/评审费/申报费完全无录入口)。注意：专利/IP 资产侧(IpAsset+IpFee)反而有真实费用台账回写(IpFee→IpAsset.totalCost)，但本缺口针对的是工法侧,工法侧确无。\n\n(2) 预算控制整块缺失 —— 属实。WorkMethodController/Dashboard/Reward、domain/WorkMethod.java 内 grep `预算|budget|Budget` 零命中；反向 grep 所有 Budget*/DevProjectBudget*/ProjectCostControl* 控制器内 `methodId|工法|workMethod` 也零命中。工法/专利办没有任何预算额度、预算占用、超预算控制。\n\n(3) 政府资助无与工法/专利对接 —— 属实。资助子系统(Policy/PolicyApplication/Declaration/RdGrantDisbursement)确实存在且 RdGrantDisbursement 有 expectedDate/receivedDate/receivedAmount/paymentId(到账追踪)，但它只挂在 RdProject(Declaration.rdProjectId)/policyApplicationId/projectName(自由文本) 上。双向 grep 确认：资助侧实体/控制器内 `methodId|patentId|workMethod` 零命中；WorkMethod/Patent 侧 `policy|declaration|grant|资助|fund|到账` 零命中。即资助窗口提醒与到账关联均未对接工法/专利。前端 workmethod.vue 也仅把 totalCost 当只读展示字段，无费用录入/预算/资助表单。",
   "reEvidence": "web/WorkMethodController.java:158,618 (totalCost 仅置 ZERO); web/WorkMethodController.java:512-550 addUsage 只回写 totalSaving 不碰 totalCost; web/WorkMethodDashboardController.java:206-236 roi() 用恒为0的 m.getTotalCost() 作投入分母; repository/ 下工法子表仅 Application/Event/Review/Reward/Usage 无 Cost/Fee; 反例对照 web/IpAssetController.java:410 (专利侧有真实费用台账回写, 工法侧无); 预算: WorkMethod 全域 grep 预算/budget 零命中, Budget*/ProjectCostControl* 控制器 grep methodId/工法 零命中; 资助对接: domain/Declaration.java 仅 rdProjectId、domain/RdGrantDisbursement.java 仅 policyApplicationId/projectName, 双向 grep methodId/patentId↔policy/grant/资助 均零命中; 前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/workmethod.vue totalCost 仅只读展示"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "7. 奖励与考核管理",
   "verdict": "PARTIAL",
   "gap": "无专利/工法KPI绩效考核报表；专利侧无奖励联动；奖励分配仅等比例，不支持自定义贡献比例。",
   "severity": "med",
   "evidence": "工法奖励链完整(WorkMethodRewardController generate按级别STANDARD自动算应发→approve生成资金支付中心待付单→markPaid发放，全程留痕)。但绩效考核确缺：grep OpsKpiController.java 不引用工法/专利/patent/ip(零命中)，未将申请量/授权量/应用量纳入部门个人KPI生成考核报表。专利授权触发奖励仅工法侧有——PatentController/Patent无任何奖励联动字段或端点。发明人排序/贡献比例确为等比例：WorkMethodReward.allocate()用pctEach=100/n等分末位补差，不支持按贡献比例自定义录入。初判PARTIAL成立。",
   "survives": true,
   "reNote": "缺口属实，三条子项全部成立，无法推翻。(1) 无专利/工法KPI绩效考核报表：WorkMethodDashboardController 仅有 overview/progress/roi/cert-alerts/deadline-alerts，IpInsightController 仅有 bi/inventory/project-matrix，全是工法/IP的状态-成本-ROI聚合，没有任何按个人/部门的绩效考核(KPI)报表；项目内 KPI 控制器只有 OpsKpiController(水质/生产)与 QhseDashboardController(安全/质量)，与专利工法办无关。WorkMethodController 无任何 KPI/绩效 端点。活体探测：/work-methods/kpi→400、/work-method-rewards/kpi→400、/work-method-dashboard/performance→404，而 /work-method-dashboard/overview 与 /roi →200。(2) 专利侧无奖励联动：PatentController 是纯 CRUD(名称/类型/状态/年费/发明人)，无奖励生成、无付款单联动、无分配；前端 patent.vue 经 grep 完全没有 奖励/reward/绩效/考核/贡献 任何字样。奖励能力只挂在 WorkMethod(工法)，专利(Patent)侧完全没有。(3) 奖励分配仅等比例、不支持自定义贡献比例：WorkMethodRewardController.allocate() 写死 pctEach=100/n 等分(末位吸收余差)，GenerateRequest 只接收 (methodId, overrideAmount)，无任何按完成人传比例的入参；前端 wmreward.vue 只读展示后端算好的等分 allocation，可变操作仅 approve/reject/markPaid，无自定义贡献比例输入框。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/WorkMethodRewardController.java (allocate() 第204-237行 pctEach=100/n 等分; GenerateRequest 第79行仅 methodId+overrideAmount); oa-backend/src/main/java/com/kaidi/oa/web/PatentController.java (纯CRUD, 无奖励/KPI); oa-backend/src/main/java/com/kaidi/oa/web/WorkMethodDashboardController.java (仅 overview/progress/roi/cert/deadline, 无绩效考核); oa-backend/src/main/java/com/kaidi/oa/web/IpInsightController.java (仅 bi/inventory/project-matrix). 前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/wmreward.vue (alloc() 第38-43行仅拆显示, 无自定义比例输入); ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/patent.vue (grep 奖励/reward/绩效/考核/贡献 零命中). 活体: /api/oa/work-methods/kpi→400, /work-method-dashboard/performance→404."
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "8. 成果应用与推广",
   "verdict": "PARTIAL",
   "gap": "无年度推广计划与推广活动记录实体；无面向全员的IP/工法查询门户(权限/技术要点/案例/在线提问)。",
   "severity": "med",
   "evidence": "项目应用登记+应用效益统计已实现(WorkMethodController addUsage关联projectId、累计applyCount/totalSaving、上传evidence；Dashboard roi/overview汇总)。但推广任务管理确缺：grep 推广/宣贯/作业指导书/promotion 在本域无命中(命中全在Brand/Culture无关模块)，无年度推广计划与推广活动记录(时间/地点/参与人数/效果评估)。知识共享门户确缺：无面向全员的专利/工法查询门户(权限控制/技术要点/应用案例/在线提问)，BlogController/DiscussionController为通用知识社区非本域门户。初判PARTIAL成立。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。专利工法办/WorkMethod 全域仅 6 个实体(WorkMethod 主记录、WorkMethodApplication 申报、WorkMethodReview 评审、WorkMethodReward 奖励、WorkMethodUsage 应用登记、WorkMethodEvent 审计事件)，无任何\"年度推广计划\"或\"推广活动记录\"实体。WorkMethodUsage(wm_usage)是\"某项目部把某已批准工法应用于某工程项目的一次登记(savedCost/shortenDays)\"，属功能8·应用跟踪的逐次应用台账，不是年度推广计划，也不是推广活动(培训/示范/内部推介会)记录。WorkMethodEvent 是不可删审计流水。grep 命中的\"推广活动/案例库\"全部属于完全不同的模块——MarketCampaign(品牌推广部·市场推广)与 CultureCase(文化建设·案例库)，均未与工法域挂接。第二部分\"面向全员的IP/工法查询门户(权限/技术要点/案例/在线提问)\"同样不存在：无 portal/门户/全员只读端点，工法读口反而被 SENSITIVE_READ_PREFIXES 收为 ADMIN/APPROVER(与全员门户相反)；无任何 Question/Qa/在线提问 实体或端点；4 个工法前端页(workmethod/wmdashboard/wmreward/techachieve.vue)对 推广/门户/全员/在线提问/portal/promotion 零引用。kaidiDeptView.ts 中\"成果应用与推广\"块被映射到 path:\"/rd/board\"(创新看板)，是占位复用看板，并非专门的推广计划+门户实现。应用跟踪那半确实有，但推广计划+全员门户那半确实缺失，与 PARTIAL 判定一致。",
   "reEvidence": "实体清单(仅6个,无推广/门户/提问)：oa-backend/src/main/java/com/kaidi/oa/domain/ 下 WorkMethod.java / WorkMethodApplication.java / WorkMethodReview.java / WorkMethodReward.java / WorkMethodUsage.java / WorkMethodEvent.java；repository 同样仅这6个。WorkMethodUsage.java:12-23 注释自述\"工法应用登记…代表某项目部把某已批准工法应用于某工程项目的一次登记\"——是应用台账非推广计划。控制器 oa-backend/src/main/java/com/kaidi/oa/web/WorkMethodController.java(750行,端点仅 台账CRUD/状态机/评审/申报/usages/upgrade/events，无 promotion/portal/question 端点)、WorkMethodDashboardController.java(仅 overview/progress/cert-alerts/deadline-alerts/roi，无推广)。grep 全后端\"推广计划|推广活动|PromotionPlan|推广门户|查询门户|IP门户|在线提问|技术要点|案例库\"仅命中 MarketCampaignController/CultureCaseController/SentimentController 等无关模块。前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/rd/{workmethod,wmdashboard,wmreward,techachieve}.vue 对 推广/门户/全员/在线提问/portal/promotion 零命中。kaidiDeptView.ts 中\"专利工法办…成果应用与推广\"块 path:\"/rd/board\",pageLabel:\"创新看板\"(占位映射)。"
  },
  {
   "area": "工程管理中心/专利工法办",
   "module": "10. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "批准未自动归档档案中心；发明人信息未从HR取数；专利侵权监控/许可合同/工法争议无后端对接(前端ipmonitor/ipgov为mock页)；技术中心查新/工艺/试验数据未结构化接入。",
   "severity": "med",
   "evidence": "财务接口已通(payFee/奖励approve生成Payment联动资金支付中心)；研发接口已通(rdProjectId双向关联+IpInsight project-matrix)。但确认四处缺口：(1)资料室/档案接口缺——WorkMethodController/IpAssetController grep archive/归档/Archive 零命中(仅一处注释提project档案)，批准时工法文本/证书/申报材料未自动归档到档案中心。(2)HR接口缺——StaffDossierController grep 发明人/完成人/inventor 零命中，发明人部门岗位未从HR自动取数。(3)法务风险部接口缺——无侵权监控/许可合同/争议处理对接控制器(grep ipmonitor/侵权监控后端零命中；前端ipmonitor.vue/ipgov.vue存在但无任何后端@RequestMapping支撑，系Setting-store mock页)，LitigationCase不引用patent/ip。(4)技术中心查新报告/工艺参数/试验数据未结构化接入。初判PARTIAL成立。",
   "survives": true,
   "reNote": "Gap real, PARTIAL. Four sub-claims hold.",
   "reEvidence": "WorkMethodController, IpAssetController, TriggerRuleEngine, ipmonitor.vue, ipgov.vue."
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "1. 成本基础数据管理",
   "verdict": "PARTIAL",
   "gap": "标准成本未拆分(标准BOM用量定额×标准工艺工时定额×标准费率)、无版本管理；价格库无采购价自动同步联动；无可配置多级分摊规则；无中标清单导入及超支决策建议/利润亏损分析。注：BOM会签(BomItemController /{id}/sign 五签链)已实现，但不填补本模块命名缺口。",
   "severity": "med",
   "evidence": "domain/StandardCost.java 仅有 materialCost/laborCost/overheadCost 三项金额总额 + totalStandard/actualCost/variance，无标准BOM物料用量定额、无标准工艺路线工时定额、无标准人工费率/制造费率的拆分实体或版本管理字段。web/PriceItemController.java 是纯 CRUD（list/get/create），无任何「从采购模块自动同步最新采购价」端点（grep 自动同步/syncPrice/priceSync 零命中），PriceItem 实体 priceType 含『历史中标价』仅为枚举值非联动。多级分摊规则无配置实体（OpsCostAllocationController 是运营中心工业废水按水量占比分摊，非成控部可配置多级分摊规则）。中标清单导入比对仅靠 BomItem.bidQty 手填 + BomAnalysisController.costCompare 量价比对，无导入端点（grep 中标清单/导入 零命中），无『超支原因判断是否可继续执行/利润亏损项分析』决策建议。",
   "survives": true,
   "reNote": "尽力推翻但失败：缺口属实(PARTIAL)。该模块仅有基础台账CRUD框架，四项命名能力全部确认缺失。(1)标准成本未按\"标准BOM用量定额×标准工艺工时定额×标准费率\"拆分——StandardCost实体只有扁平的materialCost/laborCost/overheadCost三个手填字段，recompute()只做相加，无用量定额/工时定额/费率的乘法分解；实体Javadoc自认\"当前实现为手填+自动汇总框架\"。无任何version/版本字段，无版本管理。(2)价格库PriceItem/PriceItemController仅基础CRUD，无sync/同步/采购价/purchasePrice逻辑；唯一关联CslReportController是反方向(用户手动选priceItemId把基准价拉进估算明细)且需手动选择，非采购价自动同步。(3)无可配置多级分摊规则——OpsCostAllocationController是运营中心(废水)按水量占比的写死单维分摊，无规则实体、无多级、与成本控制部不是同一模块。(4)无中标清单导入(grep 中标清单/bidList/import 零命中)；BomAnalysisController.costCompare只算 overrun=actualCost-bidCost 的数值对比，无决策建议/利润亏损分析，且bid量是手填或从领料回填非清单导入。会签链(BomItem.signStatus五签)确为另一独立能力，不填补本命名缺口。",
   "reEvidence": "domain/StandardCost.java(L35-47仅materialCost/laborCost/overheadCost扁平字段,无定额×费率分解,无version;L21-22 Javadoc自认\"手填+自动汇总框架\"); web/StandardCostController.java(recompute L71-75只做料+工+费相加; rollup/rollup-tree只读聚合); repository/StandardCostRepository.java(仅findByPeriod,无version查询); domain/PriceItem.java + web/PriceItemController.java(仅CRUD,无sync/采购价); web/CslReportController.java L262-277(反方向手动选priceItemId拉基准价,非自动同步); web/OpsCostAllocationController.java L68-132(废水域按billedVolume占比写死单维分摊,无可配置规则/多级); web/BomAnalysisController.java L58-102(costCompare仅算overrun数值,无决策建议/利润亏损分析); grep 中标清单/bidList/importBid/利润亏损/超支决策/版本管理 全零命中。"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "2. 合同管理模块",
   "verdict": "LOGIC_GAP",
   "gap": "核心承重项(税率自动带出不含税/税额、金额大小写校验、供应商准入去重共用、甲乙方信息自动带入接线、附件类型/日期预审+提交锁定回退、补充协议增量累加、合同级直接成本归集)均缺，维持LOGIC_GAP。需修正初判口径：合同预算审核的『提交后锁定/驳回回退方可改』状态机其实已由 ContractBudgetReviewController(submit→锁定, reject→reopen回草稿) 实现，且合同级成本可经 CostAuditTraceController(by-supplier/project/subject+drill) 与 ProjectCostControlController.rollup 间接归集——这两点初判未给credit，但属于预算审核单/项目rollup而非合同正文/附件预审，故不翻案。",
   "severity": "high",
   "evidence": "承重缺口全部坐实：domain/Contract.java 无 taxRate/含税/不含税/税额字段；ContractController.create 的 CreateContractRequest 无税率字段、无金额大小写自动校验。供应商准入去重/共用缺失：SupplierController/Supplier 仅有 status(合格/准入中/停用)枚举，无去重或几家公司共用逻辑。甲方/乙方信息自动带入未接线：create 只收 companySubject 字符串原样存库，CompanySubject 实体虽有 legalPerson/creditCode 但 create 无任何按主体回填法人/身份证/开户的带入逻辑。附件预审全缺：grep 附件/预审/签订日期校验/回退锁定 在 ContractController 零命中。补充协议靠 parentId/parentId 串联(Contract.parentId、ContractChange)，但无『金额仅填新增减+原合同自动累加减』逻辑(ContractChange 记 amountBefore/amountAfter 全量覆盖而非增量累加)。合同执行成本直接归集(合同级PO/入库/发票/运费)缺失。",
   "survives": true,
   "reNote": "尝试推翻失败，缺口属实(LOGIC_GAP 成立)。逐项对抗核验合同管理模块7个承重项，绝大多数在合同正文(domain/Contract.java + web/ContractController.java)上确实不存在：(1)税率自动带出不含税/税额——Contract 实体仅有 amount 一个金额字段，无 taxRate/amountExclTax/taxAmount；税额派生只在独立的 Invoice/TaxFiling 实体上，合同正文无;(2)金额大写校验——全仓 grep 大写/amountInWords/chineseAmount 零命中;(3)甲乙方自动带入接线——create 接收 partyA/partyB 裸字符串，无从供应商/客户主数据自动带入(createSub 的甲乙倒换是另一功能);(4)附件类型/日期预审+提交锁定回退——Contract 实体根本没有任何附件字段，无附件预审(『预审』命中的是另一实体 ContractBudgetReview);(5)补充协议增量累加——ContractChangeController 第113-114行 contract.setAmount(amountAfter) 是绝对覆盖而非多份补充协议增量累加;(6)合同级直接成本归集——成本归集只在项目/供应商/主体聚合层(CostAuditTrace/ProjectCostControl)，合同正文无直接成本科目。唯一部分实现的是(7)供应商去重：SupplierController 确有 creditCode 查重(create/update 均拒重复统一社会信用代码)，但合同 partyB 是自由文本无供应商外键，『准入去重共用/接线』的『共用』部分仍缺。claim 自述的两点修正(预算审核状态机 submit锁定/reject-reopen 确在 ContractBudgetReviewController 实现、合同成本可经 rollup 间接归集)经核验属实且自洽——但二者属预算审核单/项目rollup而非合同正文/附件预审，不构成翻案，claim 不给 credit 的口径正确。综上无法翻案，维持 real=true。",
   "reEvidence": "domain/Contract.java:21-50 仅字段 id/code/name/type/partyA/partyB/amount/projectId/companySubject/signDate/status/paidAmount/invoicedAmount/custodian/parentId——无 taxRate/不含税/税额/大写/附件字段。web/ContractController.java grep taxRate|大写|partyA.*supplier|带入 零命中。web/ContractChangeController.java:113-114 `contract.setAmount(c.getAmountAfter())` 绝对覆盖非增量累加。web/CostAuditTraceController.java:25-35 自述『无新建实体的跨模块只读聚合』按供应商/项目/主体汇总(非合同级直接成本归集)。web/ContractBudgetReviewController.java:182-273 submit(草稿→待成控审核锁定)/reject(→已驳回)/reopen(→草稿) 状态机确在『预算审核单』实体而非合同正文。web/SupplierController.java:54-58,87-92,113-117 creditCodeExists 查重已实现(部分命中第7项)，但 Contract.partyB 为自由文本无供应商FK故『共用接线』仍缺。全仓 grep 金额大写/amountInWords 零命中。"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "3. 物料清单（BOM）差异自动核算",
   "verdict": "PARTIAL",
   "gap": "差异仍为合并量价一维，缺价格/用量/损耗/替代料/工艺路线五维分解公式、缺差异原因标签库、缺红黄绿阈值推送、缺差异下钻源单据、缺月末差异分摊+借贷会计分录。",
   "severity": "high",
   "evidence": "多维差异模型确缺：grep 用量差异/价格差异/损耗差异/替代料差异/工艺路线差异/priceVariance/qtyVariance 在 web、domain 零命中。仅 BomAnalysisController.costCompare 给一维合并超支(overrun = actualQty×unitPrice − bidQty×unitPrice)，MfgProjectCostController 注释提『量差/价差口径』但代码只算 variance=实际−标准总额，无分项公式。varianceReason 零命中——无差异原因在线标记+原因标签库。无红黄绿灯阈值预警推送生产/采购。无差异下钻至工单/采购单/领料单/入库单源单据(BomAnalysisController 仅有 backfill 从领料回填 actualQty)。grep 差异分摊/会计分录/红黄绿 零命中——月末差异按标准成本比例分摊+借贷分录全缺(VoucherController 有借贷凭证但未与BOM差异分摊接线)。",
   "survives": true,
   "reNote": "缺口属实。BOM 差异核算的核心实现 BomAnalysisController.costCompare() 只产出按项目的合并量价一维差异：bidCost=Σ(bidQty×unitPrice)、actualCost=Σ(actualQty×unitPrice)、overrun=actualCost−bidCost、overItems 计数。投标价与实际价用的是同一个 unitPrice，所以这本质只是「用量差」一维金额，根本没有把单价拆出来；五维分解（价格/用量/损耗/替代料/工艺路线）全部缺失。逐条核对缺口五点：①五维分解公式——不存在，全库 grep priceVar/usageVar/lossVar/损耗/替代料/价差量差 在差异核算路径上零命中；姊妹端点 StandardCost 仅 variance=actual−(料+工+费) 总差异，MfgProjectCostController 文档注释写「量差/价差口径」但代码只算 variance=actual−std 一个合并数（注释与实现不符，纯总差异）；②差异原因标签库——不存在，varianceReason/差异原因库/reasonCode/reasonCatalog 全库零命中；③红黄绿阈值推送——BOM 差异本身只有 overrun>0→「超量/超支」二态布尔，无红黄绿三级、无推送；分级阈值仅存在于另一条链 ProjectCostControlController.alerts（关注/超支预警/严重超支，且是预算执行口径，不是 BOM 差异）；④差异下钻源单据——BOM 差异行无法钻到领料/工单源单据明细（仅 backfill 把领料聚合回填 actualQty，CostAuditTraceController.drill 是合同/结算/发票/付款维度，与 BOM 差异无关）；⑤月末差异分摊+借贷会计分录——不存在，无任何把 BOM/标准成本差异结转、月末分摊并生成 Voucher 借贷分录的代码，VoucherController 与 variance/差异 零交集。活体复验：cost-compare 实返字段仅 {bidCost,actualCost,overrun,overItems}，无任何分解维度；探测 variance-decompose/variance-reasons/variance-allocation/variance-voucher 等端点全部 HTTP 400（无映射）。PARTIAL 判定成立。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/BomAnalysisController.java:65-92 (costCompare: bidCost=bidQty×unitPrice, actualCost=actualQty×unitPrice, overrun=actualCost−bidCost, 同一 unitPrice 故仅用量一维); BomAnalysisController.java:46-50 (ProjectCostCompare 记录只有 bidCost/actualCost/overrun/overItems 四字段); domain/BomItem.java:38-59 (无 standardPrice/actualPrice/loss/substitute/routing 字段); web/MfgProjectCostController.java:133-136 (variance=actual−std 单一合并差异, 注释34行称\"量差/价差\"实则未拆分); web/StandardCostController.java:71-75 (variance=actual−总标准, 无价量分解); web/ProjectCostControlController.java:357-383 (分级阈值仅预算执行口径, 非BOM差异); web/CostAuditTraceController.java:221-294 (drill 仅合同/结算/发票/付款维度, 不下钻BOM差异源单据); web/VoucherController.java (与 variance/差异 零关联, 无差异结转分录); 全库 grep varianceReason/差异原因库/priceVar/usageVar/lossVar/差异结转/差异分摊生成凭证 零命中; 活体 GET /api/oa/bom-items/cost-compare 实返仅 {bidCost,actualCost,overrun,overItems}, 探测 variance-decompose/variance-reasons/variance-allocation/variance-voucher 端点全部 HTTP 400 无映射"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "5. 采购成本控制",
   "verdict": "MISSING",
   "gap": "采购订单实体/控制器、采购价格监控预警、采购变更成控审批、采购节约额、招标比价自动推荐最低价、到货成本(运费/关税/装卸)核算与价差，整组缺失。",
   "severity": "high",
   "evidence": "全域确认无采购订单：domain/ 与 web/ 下 grep -i purchase 零文件，grep PurchaseOrder/采购订单/采购单价 在所有 .java 正文零命中。无采购价 vs 标准成本/历史价/上次采购价自动对比预警。无采购变更需成控审批。无采购成本节约额((标准价−实际价)×采购量)计算。无在线比价录各家报价自动推荐最低价中标(BidController/BidDecisionController 是投标/不投标投标决策与商务标任务，非采购比价定标)。无到货成本核算(含运费/关税/装卸)——grep 到货成本/运费/关税/装卸/freight/landed 仅 WorkflowService 一处无关命中。",
   "survives": true,
   "reNote": "缺口属实。采购成本控制这一整组在后端(/api/oa/* 凯迪ERP)确实未实现，无法推翻。逐项核查：(1) 采购订单实体/控制器——domain/、repository/、web/ 三处均无 PurchaseOrder/Procurement/Sourcing 任何文件；253个实体里没有采购订单单据实体（仅 Contract 有 type='采购合同' 字符串、LogisticsExpense 有 category='采购' 标签，都不是采购订单业务单据）。(2) 采购价格监控预警——无。(3) 采购变更成控审批——无（EngineeringChange 审批链里出现\"采购\"只是工程变更ECO的一个审批节点名，非采购变更）。(4) 采购节约额——全库 saving 只命中 WorkMethod 工法/QC节约，与采购无关。(5) 招标比价自动推荐最低价——Bid*/BidDecision 控制器是公司\"投标\"(去中标拿合同)，非\"招标比价选供应商\"；grep lowest/最低价/比价/推荐/供应商报价 在 Bid* 全部零命中。(6) 到货成本(运费/关税/装卸)核算与价差——freight/tariff/关税/装卸/运费/landed 在 web/domain/service 全部零命中。前端 kaidiDeptView 把\"成本控制部·采购成本控制\"标 status='built' 指向 /budget/costcompare(量价比对)，但该页 costcompare.vue 注释明写是\"投标成本 vs 实际成本\"的通用成本超支比对(复用 MfgProjectCost/StandardCost/BOM 量价差异)，是张冠李戴的通用成本差异页，不含任何采购订单/价格监控/节约额/最低价推荐/到货成本能力。api.ts 里的 procurement 块是已弃用 OFBiz 实体浏览器配置(entityName: Requirement/Vendor/Quote、pageId 指向 order__/ap__ 旧屏)，非凯迪后端实现。",
   "reEvidence": "后端无采购订单: oa-backend/src/main/java/com/kaidi/oa/{web,repository,domain}/ 下 grep -i 'purchaseorder|procurement|sourcing' 全部零文件。最相关的现有实现都不是采购: web/ProjectCostControlController.java(/api/oa/project-budget-lines, WBS预算+EVM+预警,项目成控非采购)、web/MfgProjectCostController.java(/api/oa/mfg-project-costs, 实际vs标准成本量差价差)、web/BidController.java+BidDecisionController.java(公司投标非招标比价选供应商)。6项专用能力零命中: grep -rn -i 'freight|tariff|关税|装卸|运费|landed|招标比价|最低价|lowest|采购节约|采购价格监控|采购订单' web/ domain/ service/ 仅命中 WorkflowService 的英文单词 'landed'(指待办落到节点)和无关的 WorkMethod totalSaving。前端: ofbiz-framework/plugins/modern-ui/app/src/data/kaidiDeptView.ts 成本控制部\"采购成本控制\"block path=/budget/costcompare;该页 src/oa/pages/budget/costcompare.vue:2 注释='量价比对：投标成本 vs 实际成本'(非采购);src/services/api.ts:723 procurement 块为弃用OFBiz配置。"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "6. 成本报表与决策支持",
   "verdict": "PARTIAL",
   "gap": "降本增效跟踪表、成本趋势预测(下期材料/人工/费用)、环比/同比专门口径缺失；可配置组合报表已具备。",
   "severity": "med",
   "evidence": "降本增效跟踪表缺失：grep 降本/增效/节约跟踪/改善项目/baseCost/基期 零命中（StandardCost/MfgProjectCost 的『节约』仅为 variance 符号标志，非改善项目记录+基于标准/基期算降本金额）。成本趋势预测缺失：grep forecast/预测 与成本相关仅 ProjectCostControlController EVM 的 EAC(完工预测=BAC/CPI)，非『基于历史成本+未来生产计划预测下期材料/人工/费用』。期间对比环比/同比缺专门口径：grep 环比/同比/QoQ/YoY/期间对比 零命中。注：ReportDefinitionController 支持白名单数据源(合同/付款/预算/投标…)按维度/度量任选组合出报表，对应§6末项『任选数据模块组合形成需求数据报表』已实现，与PARTIAL一致。",
   "survives": true,
   "reNote": "缺口属实。我尽力反驳但无法推翻：成本控制部「成本报表与决策支持」中明确点名缺失的三项确实都没有实现。(1) 降本增效跟踪表——成本控制域内不存在任何降本/节约追踪表或端点；全系统唯一带 saving/ROI 的是 WorkMethodDashboardController(/api/oa/work-method-dashboard/roi、/overview)，但它属于「工程管理中心·专利工法办」，按 WorkMethod 实体聚合工法投入产出比，与成本控制部的降本增效跟踪是不同概念，不构成实现。(2) 成本趋势预测(下期材料/人工/费用)——全系统唯二的 forecast 是 ProjectCostControllerEVM 的 EAC(完工预测=BAC/CPI，单一项目完工点预测)与 FundPlan 的预测期末余额(期初+流入-流出)，均非按期分桶的下期材料/人工/费用趋势预测；不存在任何月度/分期成本时间序列与外推。(3) 环比/同比——全后端零实现，grep「同比/环比/mom/yoy/momRate/yoyRate」仅命中 DataSeeder 的演示文案，无任何同环比计算逻辑。所有成本聚合(project-summary、cost-audit by-supplier/project/subject、mfg-project-costs/summary、BusinessBi business-overview)都是静态时点快照，无期间对比。可配置组合报表(ReportDefinitionController, /api/oa/report-definitions)确已具备——与缺口让步一致。判定 PARTIAL 准确。",
   "reEvidence": "后端代码：ProjectCostControlController.java(L385-431 EVM/EAC=完工预测，非下期趋势；L433-470 project-summary 为静态时点汇总，无 trend/mom/yoy)、CostAuditTraceController.java(by-supplier/project/subject 全为时点聚合)、MfgProjectCostController.java(summary 标准vs实际差异，无时间序列)、BusinessBiController.java(business-overview 静态快照)、WorkMethodDashboardController.java(saving/ROI 属专利工法办 /work-method-dashboard，非成本控制部降本跟踪)、ReportDefinitionController.java(可配置报表，已具备)。grep 全后端「环比/同比/降本/momRate/yoyRate/forecast材料/下期」无命中(同比仅出现在 DataSeeder.java:824 演示文案)。前端 oa/pages/budget/* 仅 projectcontrol.vue 有 EAC 完工预测，无趋势预测/降本表/环比同比页。活体验证(127.0.0.1:8091)：/project-budget-lines/project-summary 返回 ok；/project-budget-lines/cost-trend 与 /forecast 返回 400、/cost-audit/trend 返回 404，证实无趋势预测端点。"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "7. 合规与审计追溯",
   "verdict": "PARTIAL",
   "gap": "多种存货计价方法(移动平均/FIFO/个别计价)可选+分摊规则可配置变更需审批 缺失；成本调整原因登记字段缺失；审计追溯按供应商/项目/主体汇总下钻已具备。",
   "severity": "med",
   "evidence": "存货计价方法配置全缺：grep valuation/移动平均/先进先出/个别计价/valuationMethod 在成本域零命中(FIFO 仅 FermentBatch 发酵投料口径，非存货计价配置)，成本分摊规则无可配置且变更需审批的实体。成本调整原因字段未见：StandardCost 无 reason/修订原因字段，OperationAuditLog(hash链不可篡改操作日志)只记 operator/method/path/status 通用写请求，无『标准成本修订/差异手工分摊/预算修改』的业务原因登记。注：审计接口子项已实现——CostAuditTraceController 以供应商/项目/主体为单位汇总已签合同/已结算/已开票/已支付/应付未付，并 /drill 下溯至源单据(合同/结算/发票/付款)，落地『可上溯或下溯至源头』，与PARTIAL一致。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但找不到实现。三项具体缺失逐条核实：\n\n(1) 多种存货计价方法可选(移动平均/FIFO/个别计价): InventoryItem 实体(domain/InventoryItem.java)只有 materialName/category/spec/unit/quantity/safetyStock/location/status，无任何 valuationMethod/计价方法字段；InventoryItemController 增改接口的 CreateInventoryItemRequest 也无该入参。全后端 grep \"计价方法/存货计价/移动平均/个别计价/加权平均/valuationMethod/costingMethod\" 零命中。唯一的 FIFO 出现在 FeedstockBatch/FermentBatchController，是发酵投料\"按到货日期升序消耗原料批次\"的硬编码消耗顺序(粪污易腐败)，并非可选的存货计价口径，且不可切换。\n\n(2) 分摊规则可配置+变更需审批: 全后端 grep \"分摊规则/allocationRule/分摊变更\" 零命中。StandardCostController 的料/工/费为手填，rollup/rollup-tree 仅做按成本中心上卷只读聚合，无分摊规则配置实体、无规则变更走审批的逻辑。\n\n(3) 成本调整原因登记字段: StandardCost 实体仅有自由文本 note 字段(活体返回如 note=\\\"原材料涨价导致超支\\\")，无结构化的\"成本调整原因/adjustReason/调整前后值/调整审批\"登记字段；update 接口直接覆盖 actualCost 等不留调整原因轨迹。全后端 grep \"成本调整/调整原因/adjustReason/costAdjust\" 零命中。\n\n(4) 审计追溯按供应商/项目/主体汇总下钻: 缺口描述本身已承认\"已具备\"，非缺口点(budget/audittrace.vue 等存在)。\n\n结论: PARTIAL 判定准确——审计下钻已有，但存货计价方法可选+分摊规则可配置变更审批+成本调整原因登记三项确缺。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/InventoryItem.java(无valuationMethod字段); web/InventoryItemController.java(CreateInventoryItemRequest无计价方法入参); domain/StandardCost.java(仅note自由文本，无成本调整原因/调整轨迹); web/StandardCostController.java(料工费手填+只读上卷，无分摊规则配置/变更审批)。FIFO仅出现于domain/FeedstockBatch.java与web/FermentBatchController.java，为发酵投料硬编码消耗顺序非可选存货计价。全后端grep\"计价方法|存货计价|移动平均|个别计价|加权平均|valuationMethod|costingMethod|分摊规则|allocationRule|成本调整|调整原因|adjustReason\"零命中；前端 ofbiz-framework/plugins/modern-ui/app/src 同样零命中。活体 GET /api/oa/standard-costs 返回项含\"note\":\"原材料涨价导致超支\"(自由文本)，无结构化调整原因字段；GET /api/oa/inventory 返回项无计价方法字段。"
  },
  {
   "area": "工程管理中心/成本控制部",
   "module": "8. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "供应商合同前置条件判定、多部门并行会签流(税率/条款/承兑/研发费)、进度款工程+财务双核、采购PO/到货成本接口(随模块5缺失而断)、仓库余额与财务结转/差异凭证接口，均未落地；条款比对/计量支付为相邻能力但不等同。",
   "severity": "med",
   "evidence": "具体接口编排子项确未落地：供应商合同前置条件(安责险购买+施工主合同已签由资料室判定)——grep 安责险/施工主合同/前置条件 零命中(资料室仅有归档/借阅控制器)。合同会签多部门并行(财务核税率/法务核条款/金融核承兑比例/创研核研发费)无专门会签流——grep 承兑零命中(命中均为竣工『验收』非『承兑』)，ClauseCompareController 仅做合同草稿vs模板条款偏差+风险级别比对(触及法务核条款但非多部门并行会签流)。进度款审核双核(工程中心核现场进度+财务核出入库/发票附件)缺失——MeasurementPaymentController 是工程监理部计量支付(申报→监理核定核减→支付证书)，非成控部进度款双核流。采购部PO价/到货成本接口因模块5缺失而断。仓库出入库余额、财务成本结转/差异分摊凭证接口未与成控接线。",
   "survives": true,
   "reNote": "缺口属实（PARTIAL 成立，无法推翻）。成控部\"与其他部门的接口要求\"列的 5 项接口，逐项核验后 4 项确缺、1 项仅为通用引擎+装饰性并行知会，未达需求所指的阻断式落地：\n\n1) 供应商合同前置条件判定——不成立的实现。SupplierController 仅做统一社会信用代码查重；ContractController/ContractBudgetReviewController 全文无 supplier/合格/准入/资质/前置 任何引用，建合同/预算审核时不校验供应商合格状态。确缺。\n\n2) 多部门并行会签流(税率/条款/承兑/研发费)——部分。WorkflowService 确有可执行的并行会签能力(approvalParallelGroups + CountersignVote 票决 + 合成\"并行会签@\"同步节点，要求每个并行审批人同意才 join)，且 TemplateSeedData 种了\"采购合同会签\"(法务部+财务部并行)与\"供应商准入会签\"(质量部+财务部并行)。但：种子里这两组并行成员 type 是\"协同/知会\"(isCcNode)，按 approvalParallelGroups(line 848-853)非审批节点会被剔除、达不到≥2 审批阈值，故不会被收敛为真正阻断式并行审批，只是 CC 自动放行；且无任何流把\"税率/条款/承兑/研发费\"这一具体四签作为阻断会签人接线。引擎在、相邻采购会签在，需求所指的特定四签阻断流不在。\n\n3) 进度款工程+财务双核——不成立的实现。MeasurementPaymentController 只有单一监理 approve(工程核定)→issue 出证，无财务二审。SettlementController 虽有双人复核，但是结算单的两个匿名 slot，未按工程/财务角色定型、也未挂接 MeasurementPayment。确缺。\n\n4) 采购PO/到货成本接口——确缺。domain 无 PurchaseOrder/PO/goods-receipt 实体，无控制器；成本归集 rollup 的 committed 直接取自 Contract，actual 取自 MaterialIssue/ProductionReport/ExpenseClaim，全程无 PO→到货→成本接口(与\"随模块5缺失而断\"吻合)。\n\n5) 仓库余额与财务结转/差异凭证接口——确缺。InventoryItemController 纯 CRUD(仅安全库存状态派生)；VoucherController 独立 GL 状态机；唯二自动生成凭证在 PaymentService(付款→借应付/贷银行)与 ProjectController，均非由仓库余额/库存差异驱动，无结转/差异凭证接口。\n\nreviewer 关于\"条款比对/计量支付为相邻能力但不等同\"的剔除正确：ClauseCompareService、MeasurementPayment 确实存在但不是所指接口。综上 PARTIAL 判定成立。",
   "reEvidence": "后端绝对路径证据：\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SupplierController.java（仅 creditCode 查重，无合格状态对外门禁）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ContractController.java 与 ContractBudgetReviewController.java（无 supplier 合格/准入/资质 任何引用，建合同/审核不校验供应商前置条件）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/WorkflowService.java:830-872 approvalParallelGroups/hasApprovalParallel（并行会签真执行，但 line 848-853 仅 type≠CC 的审批节点计入、需≥2 才收敛）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/seed/TemplateSeedData.java:401-437(purchaseContract: legalDept type=协同 + financeDept type=知会，parallels=[legalDept,financeDept]) 与 :330-352(supplier-access: qualityDept+financeDept 知会并行)——并行成员均为 CC 型，非阻断审批；无税率/承兑/研发费四签流\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/MeasurementPaymentController.java:147-193（仅监理单审 approve→issue，无财务二核）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SettlementController.java:165-217（双人复核是两个匿名 slot 的结算单，非工程/财务角色定型，未挂 MeasurementPayment）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ProjectCostControlController.java:206-298 rollup（committed 取自 contractRepo.findByProjectId，无 PO/到货接口）\n- domain 目录无 PurchaseOrder/PO/GoodsReceipt 实体（仅 Policy/PolicyApplication 命中 grep \"Po\"）\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/InventoryItemController.java（纯 CRUD）与 VoucherController.java（独立 GL 状态机）无互联；自动凭证仅 PaymentService.java:117 与 ProjectController.java:163，均非库存余额/差异驱动\n前端：/Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src 仅 oa/api/projectcost.ts 与 oa/pages/supervision/measurement.vue 接线，未暴露上述 5 接口。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "1. 工艺运行管理",
   "verdict": "LOGIC_GAP",
   "gap": "但初判的核心缺口全部坐实：grep PLC/SCADA/自动采集/趋势曲线/历史回放/频率电流/联锁 在污水域零命中——无对接 PLC/SCADA 自动采集进出水水质与工艺段参数(溶解氧/污泥浓度/回流比/水位/压力)、无设备运行状态(启停/频率/电流)采集、无秒级/分钟级存储与趋势/回放；grep 调控指令/泵频/曝气量/加药量下发/变更前后值 在污水域零命中(命中均为 IP/工法/设计变更域)——无工艺调控指令在线下发及变更前后值留痕与超限自动联锁(WaterAlertRule.autoCloseValve 是来水阀门切断，非厂内泵频/曝气/加药调控)；AiController 仅通用 complete/draft/classify/summarize/risk，AiService 无 sewage/曝气/工艺优化——无AI优化建议与采纳反馈；SewageProcessRunController 仅 daily-report，无 weekly/monthly/自定义模板。本质是手工台账派生，非自动采集与在线调控，LOGIC_GAP 成立。",
   "severity": "high",
   "evidence": "SewageProcessRunController/SewageProcessRun 是手工录入的工艺运行台账：进出水水质(COD/氨氮/总磷)、溶解氧、MLSS、进出水量都靠 RunRequest 前端传入，后端只自动派生去除率、达标判定(limitsOf 默认 GB18918一级A)、报警分级(紧急/重要/一般)、超标说明，并提供 /alerts 异常预警聚合与 /daily-report 跨台账(工艺+能耗)日报。这些派生逻辑是真实存在的且活体可调(返回 code:0)。",
   "survives": true,
   "reNote": "尽力反驳后无法推翻，缺口属实。城镇污水运营·工艺运行管理的实现本质是\"手工台账派生\"，非自动采集与在线调控。逐条坐实：(1) 无PLC/SCADA自动采集——SewageProcessRunController.create/update 的所有进出水水质(COD/氨氮/总磷)与工艺段参数(dissolvedOxygen溶解氧/mlss污泥浓度/inflow/outflow)均由前端 RunRequest 手工传入(单据号 GYTZ-=工艺台账)，后端只自动派生去除率/达标判定，无 ingest/telemetry/SCADA/PLC 端点，无秒级/分钟级存储、无趋势曲线、无历史回放。(2) 无设备运行状态(启停/频率/电流)采集——SewageEquipment 仅有 runHours/startStopCount/downtimeHours/faultCount 累计计数器(由工单状态机回写)，无 frequency(频率/Hz)、current(电流/A)字段，更无实时采集。(3) 无厂内工艺调控指令在线下发——WaterAlertRule.autoCloseValve 明确是\"进水阀\"(§1 工业废水来水水质预警，WaterExceedEvent.valveAction)，针对排污企业来水，并非厂内泵频/曝气量/加药量调控；全域无调控指令下发、无变更前后值留痕、无超限工艺联锁。(4) 无AI优化建议与采纳反馈——AiService/AiController 仅通用 complete/draft/classify/summarize/risk，无 sewage/曝气/工艺优化场景，无采纳反馈闭环。(5) 报表仅 /daily-report——无 weekly/monthly/自定义模板端点(OpsKpiController.TrendPoint 是按月的生产产量计划vs实际趋势，非实时水质/工艺参数趋势曲线)。LOGIC_GAP 成立。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/SewageProcessRunController.java(RunRequest 第78-82行手工传 dissolvedOxygen/mlss 等，仅 /daily-report 无周月报); oa-backend/src/main/java/com/kaidi/oa/domain/SewageProcessRun.java(工艺台账实体，无频率/电流/实时采集字段); oa-backend/src/main/java/com/kaidi/oa/domain/SewageEquipment.java(仅累计计数 runHours/startStopCount/faultCount，无 frequency/current 遥测); oa-backend/src/main/java/com/kaidi/oa/domain/WaterAlertRule.java 第51-52行+web/WaterAlertRuleController.java 第182行(autoCloseValve=进水阀切断，§1来水域，非厂内工艺调控); oa-backend/src/main/java/com/kaidi/oa/service/AiService.java + web/AiController.java(仅 complete/draft/classify/summarize/risk 通用场景，无污水/工艺优化与采纳反馈); grep PLC/SCADA/频率/电流/泵频/曝气量/加药量/趋势曲线/历史回放/联锁/调控指令/变更前后 在污水域零命中。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "2. 设备管理",
   "verdict": "PARTIAL",
   "gap": "备件管理缺位坐实：SewageWorkOrder 仅 sparesUsed(String 文本)+spareCost(BigDecimal)，grep 扣库/采购申请/库存/领用 在 SewageEquipment/OpsMaint 控制器零命中——无独立备件库(安全库存/最低库存)、无维修领用自动扣库、无低于安全库存预警生成采购申请、无与采购模块联动；runHours 靠 EquipmentRequest 人工填写(update 直接 setRunHours)，非自动累计运行时长；绩效分析无能耗占比维度、无大修/更新/淘汰决策建议。PARTIAL 成立。",
   "severity": "med",
   "evidence": "SewageEquipmentController + OpsMaintController 覆盖度比初判更高：按工艺段建档(processSection)、二维码(qrTag 扫码查档)、故障报修(扫码+照片 photoRef)→派工→维修→完工状态机、预防性维护按运行小时自动扫描生成保养工单(pmScan)与按日历周期生成(generateDue)、完工自动回写设备累计停机/故障次数、绩效分析 /performance 给出 MTBF/MTTR/完好率(availability)/运转率(utilization)/维修成本(BigDecimal)。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。逐条核验城镇污水运营·设备管理后，备件管理的每一项断言都得到代码坐实：\n\n1) 备件仅文本+成本，无独立备件库：SewageWorkOrder 只有 sparesUsed(String 文本) + spareCost(BigDecimal=ZERO)；并行的工业废水 OpsMaintOrder 同样只有 sparePart(String) + cost(BigDecimal)。两个维护实体都没有备件物料表、无安全库存/最低库存/再订货点字段。\n\n2) 无维修领用自动扣库：在 SewageEquipmentController.finish()(行235-264) 和 OpsMaintController.finish()(行254-279) 里，完工只 setSparesUsed/setSpareCost(或 setSparePart/setCost)，对库存零操作；grep setQuantity|扣减|deduct|consume 在两个控制器零命中。\n\n3) 无低于安全库存预警生成采购申请、无与采购联动：grep inventory|stock|扣库|领用|采购申请|requisition|safetyStock|InventoryItem 在 SewageEquipmentController/OpsMaintController/MaintOrderController 全部零命中。唯一带 safetyStock 的是制造中心 InventoryItem(物料库:原料/半成品/成品/辅料，非备件库)，且其 InventoryItemController 在 quantity<safetyStock 时仅把 status 置「低于安全线」做标记，并不生成采购申请，更与污水设备维护无任何引用关系。全库搜「采购申请/生成采购」只命中 MealOrderController(食堂采购建议) 与 ReportController(注释)，均与备件无关。\n\n4) runHours 人工填写非自动累计：SewageEquipment.runHours 由 EquipmentRequest.runHours 经 update()(行117 e.setRunHours(req.runHours())) 直接覆盖写入；create() 也是直接取 req.runHours()。没有任何按运行时段累计运行时长的逻辑。\n\n5) 绩效分析缺能耗占比/大修淘汰决策：SewageEquipmentController.performance() 的 PerfRow 仅含 runHours/downtime/faultCount/availability/utilization/mtbf/mttr/repairCost；OpsMaintController.reliability() 仅 mtbf/mttr/repairCost。grep 能耗占比|energyRatio|大修|overhaul|淘汰|scrap|更新决策 在两控制器零命中。\n\nPARTIAL 判定成立。",
   "reEvidence": "domain/SewageWorkOrder.java:74-77 (sparesUsed String + spareCost BigDecimal，无库存字段); web/SewageEquipmentController.java:235-264 finish() 只回写备件文本/成本无扣库, :105-123 update() 第117行 e.setRunHours(req.runHours()) 人工覆盖, :331-389 performance()/PerfRow 无能耗占比无大修淘汰决策; domain/OpsMaintOrder.java:60-67 (sparePart String + cost BigDecimal); web/OpsMaintController.java:249-279 finish() 无扣库, :296-357 reliability() 仅 mtbf/mttr/cost; domain/InventoryItem.java(制造物料库,非备件库,与污水设备零引用); web/InventoryItemController.java:83-118 低于安全线仅置status不生成采购申请。grep 证据：inventory|stock|扣库|领用|采购申请|requisition|safetyStock|InventoryItem 在 SewageEquipmentController/OpsMaintController/MaintOrderController 全部零命中；setQuantity|扣减|deduct|consume 在两维护控制器零命中；能耗占比|大修|overhaul|淘汰|scrap 在两控制器零命中。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "3. 水质检测与实验室管理",
   "verdict": "PARTIAL",
   "gap": "但仍非全 MET：grep 采样计划/采样任务/sampling 零命中——无按规范生成采样任务/指派采样人/移动端记录点位样品编号；grep 质控/平行样/空白样/标准样 零命中——无质控管理与偏差自动计算；GB18918 自动对比标红判定在工艺台账(SewageProcessRun.limitsOf)而非检测台账(TestTask.judge 是手填合格/不合格，WaterQuality result 靠规则判但非对照 GB18918 国标值)；检测项目未显式枚举 COD/氨氮/总磷/总氮/SS/溶解氧/污泥浓度/微生物镜检(detectItem 自由文本)，无 LIMS 自动导入/批量导入。故由 MISSING 上调为 PARTIAL。",
   "severity": "high",
   "evidence": "初判 MISSING 过重，应翻案为 PARTIAL：实验室检测域真实存在。TestTaskController(/api/oa/test-tasks) 把样品(LabSample)、检测项目(detectItem)、检测方法(TestMethod)、仪器(LabInstrument)、检测人串成执行单，record 录入结果值+判定(合格/不合格/OOS偏差)、review 检测→复核双人闭环(复核人≠检测人)、genReport 生成 TestReport(草稿态，含 tester/reviewer/signer)。这覆盖了需求的『检测数据录入(手工)』与『检测报告自动生成+电子签名(signer)归档』两大项。另 WaterAlertRuleController.ingest 实现在线读数→落 WaterQualityRecord→按企业规则自动判定 COD/氨氮/总磷/pH→超限自动登记 WaterExceedEvent，已是『检测/在线数据→达标判定→预警』的自动闭环。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。逐条对抗复核四个子主张均成立：(1) 无采样计划/采样任务：全仓(后端+前端)grep 采样/sampling 零命中(仅 DataSeeder 一条无关 followup \"点位\"误命中)，无采样计划/任务的 domain 或 controller，LabSample 也只是收样登记(sampleNo/sampleType/source/status/assignee)，没有采样点位、指派采样人、移动端样品编号采集字段。(2) 无质控管理与偏差自动计算：质控/平行样/空白样/标准样/加标/RPD/相对偏差 在前后端全部零命中。(3) GB18918 自动对照标红判定确实只在工艺台账侧：SewageProcessRunController.limitsOf()(行49-58)硬编码 GB18918 一级A/一级B/地方标准阈值，applyValues()(行157-169)自动比对出水 COD/氨氮/总磷 → 超标/预警/达标；而检测台账 TestTask.judge 是纯手填——record()(行187-197)judge 默认\"合格\"或取客户端传值，只校验属于 合格/不合格/OOS偏差 三选一，从不与任何标准限值计算(standardLimit 仅是供参考的文本字段)；WaterQualityRecord.result 同样是客户端直接写入的自由文本(行73 r.setResult(req.result()))，未对照 GB18918。(4) 检测项目未枚举、无 LIMS/批量导入：TestTask.detectItem 是非空校验的自由 String，前端 lab.ts 只枚举了 SAMPLE_TYPES/SAMPLE_STATUSES/TASK_JUDGES，没有 COD/氨氮/总磷/总氮/SS/溶解氧/污泥浓度/镜检 的检测项枚举；LIMS/批量导入/自动导入/镜检 全部零命中。四点全部坐实，PARTIAL 判定合理(确有 TestTask 全流程+方法库+报告链等部分实现，故非 MISSING)。",
   "reEvidence": "SewageProcessRunController.java:49-58 limitsOf() 硬编码GB18918阈值；行157-169 applyValues()自动判超标(工艺台账侧,非检测台账)。TestTaskController.java:187-197 record() judge 手填、仅三选一校验、无国标对照；行99-101 detectItem 仅非空校验(自由文本)。WaterQualityRecordController.java:73 result 客户端直写自由文本。domain/TestTask.java:73-77 standardLimit/judge 均为手填文本字段。domain/LabSample.java 无采样点位/采样人/移动采集字段。ofbiz-framework/plugins/modern-ui/app/src/oa/api/lab.ts:33-34,183 仅枚举样品类型/状态/判定,无检测项枚举、无导入函数。全仓 grep 采样/sampling/质控/平行样/空白样/标准样/LIMS/批量导入 在 oa-backend 与 modern-ui/app/src 下零有效命中。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "4. 药剂与能耗管理",
   "verdict": "PARTIAL",
   "gap": "缺口坐实：SewageEnergyLog 只按日记 powerKwh/reagentKg/单价，无库存账(无入库/出库/库存预警字段)；ReagentController(/api/oa/reagents)是实验室试剂耗材库(含 inbound/outbound/低库存预警)但不与污水药剂联动；grep 提升泵/曝气/搅拌/脱水/峰谷/分工艺段电耗 在 EnergyLog 零命中——无分工艺段电耗计量与峰谷统计；无加药推荐量与实际vs推荐差异分析；无与电力系统对接自动取数；成本归集仅电费+药费(applyMeasures)，维修费/污泥处置费分散在 OpsCostAllocation(maint+sludge+hazwaste)，无人工费/管理费，未汇成统一吨水完全成本与预算对比。PARTIAL 成立。",
   "severity": "med",
   "evidence": "SewageEnergyLogController 真实实现：日台账自动派生吨水电耗(powerKwh/water)、吨水药耗(reagentKg*1000/water)、电费(powerKwh×powerPrice BigDecimal)、药剂费、吨水成本(元/m³)；/cost/summary 按月归集水量/电耗/药量/电费/药费/合计与加权吨水成本；/alerts/energy 以全期吨水电耗均值为基线做单耗偏离预警(>15%预警/>30%异常)。金额一律 BigDecimal。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实。我额外排查了缺口描述未提及的相邻文件（SewageProcessRunController/SewageEquipment/OpsCostAllocationController/Reagent），均无法填补所列子能力，缺口描述的每一条都在代码里得到验证：\n\n1) 无药剂库存账：SewageEnergyLog.java 仅有 powerKwh/reagentKg/单价及自动派生的 unitPower/unitReagent/各项 cost，无任何入库/出库/库存量/库存预警字段；SewageEnergyLogController 只有 CRUD + cost/summary（按月归集）+ alerts/energy（吨水电耗偏离均值预警），无库存动作。grep 药剂入库/出库/reagentStock 在污水域零命中。\n\n2) Reagent(/api/oa/reagents, 表 lab_reagent)注释明写\"实验室·试剂耗材与库存管理\"，inbound/outbound/minStock 低库存预警只服务实验室，与污水药剂无任何联动（ReagentController 内 grep sewage/污水/加药/dosing 零命中）。\n\n3) 无分工艺段电耗与峰谷统计：grep 提升泵/曝气/搅拌/脱水电耗、峰谷/分时电价/sectionPower/TOU 在整个 src/main/java 业务域零命中（仅命中无关的 toUser/touched/toUpperCase）。SewageEquipment 有 processSection 字段但仅用于设备保养，不计电耗。\n\n4) 无加药推荐量与实际vs推荐差异：grep 推荐量/recommendedDose/建议投加/dosingRecommend 全零命中。\n\n5) 无与电力系统对接自动取数：唯一\"水电表自动算用量\"命中是 AdminDormController 宿舍水电费，与污水工艺电耗无关；无 SCADA/抄表/电力系统对接。\n\n6) 成本归集不全：SewageEnergyLogController.costSummary 仅电费+药费合计与加权吨水成本；维修/污泥/危废费在 OpsCostAllocationController 另算（maint+sludge+hazwaste 按账期归集再按水量分摊），两者未合并；无人工费/管理费(grep laborCost/overheadCost/人工费/管理费零命中)，无统一\"吨水完全成本\"，无预算对比(仅 costSummary 注释口头声称\"供预算对比取数\"，无 budget 字段/无 variance 计算)。\n\nPARTIAL 判定成立，无法推翻。",
   "reEvidence": "/Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/SewageEnergyLog.java (字段仅 treatedWater/powerKwh/powerPrice/reagentKg/reagentPrice + 派生 unitPower/unitReagent/powerCost/reagentCost/unitCost，无任何库存/入出库字段); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SewageEnergyLogController.java (applyMeasures 仅电费+药费，costSummary 仅这两项归集+加权吨水成本，alerts/energy 仅吨水电耗偏离均值，无库存/峰谷/分段/推荐量/预算对比); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/Reagent.java:21 (@Table lab_reagent，注释\"实验室·试剂耗材与库存管理\"，与污水无联动); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/OpsCostAllocationController.java:56 (CostBreakdown 仅 maintCost/sludgeCost/hazwasteCost/total，无人工/管理/电费/药费，无吨水完全成本，无预算对比); grep 提升泵/曝气/脱水电耗·峰谷·加药推荐·药剂入出库·人工费/管理费 在 src/main/java 业务域全零命中"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "6. 安全环保与合规",
   "verdict": "PARTIAL",
   "gap": "为通用 EHS 而非污水专项坐实：grep 巡检路线/inspectionRoute/检查项/扫码打卡 零命中——无含有限空间/化学品/电气/消防的污水巡检路线与扫码打卡/隐患拍照专表；grep 排污许可/discharge permit 零命中——无排污许可管理(许可排放量/监测频次/执行报告提交日期提醒)；grep 应急预案/演练 在污水域零命中(命中为 CostAuditTrace/Favorite/Seeder)——无应急预案(停电/进水冲击/暴雨)在线管理与演练记录、突发环境事件上报；无废气除臭/噪声/化验废液处置记录；HealthRecord 为通用职业健康，未绑定污水接害岗位体检与劳保发放。PARTIAL 成立。",
   "severity": "med",
   "evidence": "EHS 域成体系：EhsHazardController(隐患登记→整改→复查→闭环状态机+逾期预警)、EhsCapa/EhsIncident/EhsWorkPermit(工作票)/EhsObjective/SafetyCheck 等通用 EHS 控制器存在且可用。",
   "survives": true,
   "reNote": "尽力推翻后,PARTIAL 仍成立。EHS 域确有部分污水专项块,但缺口列举的核心专项功能确实零实现:\n\n【已被我推翻的局部点(给对方纠错)】\n1) \"无受限空间/电气/消防的污水巡检相关风险作业\" — 部分不成立:EhsWorkPermit(domain/EhsWorkPermit.java + 前端 ehs/permit.vue)PERMIT_TYPES=['动火作业','受限空间','高处作业','吊装作业','临时用电','动土作业'],含气体检测(gasTested/gasResult O2/可燃气/有毒气)、监护人、有效期窗口,正是有限空间/动火/电气类高风险作业票。\n2) \"无化验废液处置记录\" — 不成立:ops/hazwaste.vue 危废全流程电子联单 WASTE_TYPES 含'化验室废液'及各类污泥,产生→暂存→转移→处置,带环保危废平台同步(sync-epb),处置费按单价×转移量归集运营成本。\n\n【仍坐实的缺口(无法推翻)】\nA) 巡检路线/扫码打卡/隐患拍照专表:无 Route/Patrol 实体;SewageWorkOrder=设备保养/维修工单(MTTR),其\"扫码\"仅指PM扫描生成保养工单+faultDesc故障照片photoRef,非\"含有限空间/化学品/电气/消防检查项的巡检路线+逐点扫码打卡\";MobileCheckin=通用GPS外勤考勤(上班/外勤/拜访/下班),非污水巡检路线。grep 巡检路线/inspectionRoute/检查项 在污水域零命中。\nB) 排污许可管理:grep 排污许可/discharge permit/许可排放量/监测频次/执行报告 全栈零命中。DischargeContract(ww_discharge_contract)是纳管协议/计费合同(按水量/COD/阶梯计价),非排污许可证台账(许可排放量/监测频次/执行报告提交日期提醒)。\nC) 应急预案/演练:应急预案/演练/突发环境事件 在污水+EHS+ops 前后端零命中(全栈命中仅 Favorite/CostAuditTrace/culture/projectcost,与污水无关);无停电/进水冲击/暴雨预案在线管理与演练记录、突发环境事件上报。\nD) 废气除臭/噪声:grep 废气/除臭/噪声 在污水运营域零专表(噪声仅作 HealthRecord.hazardFactor 枚举值出现)。\nE) HealthRecord(health_record):通用职业健康(hazardFactor 含化学品/噪声枚举,examType 上岗前/在岗/离岗),未绑定污水接害岗位,且无劳保/劳动防护用品发放台账(grep 劳保/PPE 零命中)。",
   "reEvidence": "后端域实体目录 oa-backend/src/main/java/com/kaidi/oa/domain/ 仅 ItInspection/QcInspection/SupervisionInspection,无任何 Route/Patrol/InspectionRoute 实体。\noa-backend/src/main/java/com/kaidi/oa/domain/SewageWorkOrder.java:13-21,49 — 设备保养/维修工单(预防性保养/故障维修,MTTR,photoRef 仅故障照片),非污水巡检路线。\noa-backend/src/main/java/com/kaidi/oa/domain/MobileCheckin.java:12-20,36-37 — 通用移动外勤GPS打卡(上班/外勤/拜访/下班),非污水巡检扫码打卡。\n排污许可: grep 排污许可/discharge permit/许可排放量/监测频次/执行报告 全栈(oa-backend + modern-ui/app/src)零命中;DischargeContract.java:12-31 仅纳管/计费合同;grep permit/许可/监测频次/排放量 in DischargeContract.java+WastewaterClient.java 零命中。\n应急预案/演练: grep 应急预案/演练/突发环境/进水冲击/暴雨/停电 在 oa-backend + ehs/ops 前端零污水命中(命中文件仅 FavoriteController/CostAuditTraceController/culture/mock.ts/projectcost.ts/hr/fields.vue,均非污水应急)。\n废气除臭/噪声: grep 废气/除臭/噪声 无污水运营专表。\nHealthRecord.java:11-16,32 — 通用职业健康(health_record),hazardFactor=粉尘/噪声/高处作业/化学品/振动/无,未绑定污水接害岗位;grep 劳保/劳动防护/PPE 零命中(无发放台账)。\n局部反例(对方判句中\"通用EHS\"过头处): oa-backend/.../domain/EhsWorkPermit.java:13,33-58 + 前端 ehs/permit.vue:16 PERMIT_TYPES 含受限空间/动火/临时用电+气体检测;ops/hazwaste.vue:3-5,20,75 危废电子联单含'化验室废液'+环保平台同步。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "7. 生产计划与调度",
   "verdict": "MISSING",
   "gap": "全部坐实：grep 水量预测/inflow forecast 在污水域零命中(命中为 FundPlan/MarketIntel/ProjectCostControl)——无基于历史/天气/管网的24小时进水量预测与提升泵运行策略；无工艺运行方案预设(低/高浓度/冲击负荷对应曝气/回流比/加药量)与系统自动推荐；HandoverController 是离职/调动/轮岗交接(handoverType=离职交接/调动交接/轮岗交接)，非值班交接班；SewageProcessRun.shift 仅白班/夜班标签，无交接班实体(运行状态/设备/待办交接)与移动端签名确认。MISSING 成立。",
   "severity": "med",
   "evidence": "无可翻案的实现。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。城镇污水运营的\"生产计划与调度\"三项核心能力均未实现：\n\n1) 24小时进水量预测 + 提升泵运行策略：全后端 grep forecast/预测/24小时/管网/天气/降雨/提升泵策略 在污水域零命中。命中的均为他域——FundPlan(资金计划与预测,结算中心)、MarketIntel(市场情报趋势预测)、ProjectCostControl(EAC完工预测/挣值)、WaterTrace(\"remediation recommendation\"水质溯源整改建议)。DataSeeder唯一\"用水量预测\"命中是一条 DesignChange 记录的变更原因(\"用户用水量预测偏差\")，非功能实现。\n\n2) 工艺运行方案预设(低/高浓度/冲击负荷→曝气/回流比/加药量)+系统自动推荐：SewageProcessRun 实体(domain/SewageProcessRun.java)只是\"工艺运行台账\"——记录某日某班次的实际进出水量/COD/氨氮/总磷/溶解氧/MLSS，控制器(web/SewageProcessRunController.java)仅自动算去除率、达标判定(达标/预警/超标)、报警分级、跨台账拼日报。无任何方案预设字段、无 recommend/推荐逻辑、无浓度档位→工艺参数映射。前端 process.vue / opsSewage.ts 同样无这些关键词。\n\n3) 值班交接班：Handover 实体(domain/Handover.java)注释明确 handoverType ∈ 离职交接/调动交接/轮岗交接，是人事岗位移交，非值班交接班。无交接班实体(运行状态/设备/待办交接)、无移动端签名确认。SewageProcessRun.shift 仅\"白班/夜班/中班\"标签字段，不是交接实体。\n\n附带：前端 ops/dispatch.vue 虽命名\"生产计划与调度\"，但实现为\"处理费自动计算/账单批量出账\"(/discharge-bills)，是计费聚合，进一步坐实\"生产计划与调度\"调度内核缺失。MISSING 成立。",
   "reEvidence": "后端: src/main/java/com/kaidi/oa/domain/SewageProcessRun.java (仅台账字段,无forecast/scheme/recommend); src/main/java/com/kaidi/oa/web/SewageProcessRunController.java (仅去除率/达标判定/报警分级/日报聚合,line 137-201 applyValues 无推荐逻辑); src/main/java/com/kaidi/oa/domain/Handover.java line 11-14 (handoverType=离职/调动/轮岗交接,非交接班). 前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/ops/dispatch.vue line 2-4 (实为§8处理费自动计算/discharge-bills); ops/process.vue 与 oa/api/opsSewage.ts 均无预测/方案/推荐/交接班关键词. 反证(命中的他域forecast/recommend): web/FundPlanController.java+domain/FundPlan.java(资金预测), web/MarketIntelController.java line220(情报趋势预测), web/ProjectCostControlController.java line49/397(EAC完工预测), web/WaterTraceController.java line53(remediation recommendation). grep 全后端 forecast/预测/24小时/管网/天气/降雨/曝气/回流比/加药量/冲击负荷/提升泵策略 在污水运营域零命中."
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "8. 绩效与成本分析",
   "verdict": "PARTIAL",
   "gap": "缺污水运营专属 KPI 口径坐实：OpsKpi 偏制造工单产量(planQty/actualQty/workshop)，无吨水电耗/吨水药耗/污泥处置成本占比/安全事故数/预算执行率的统一月度/季度绩效看板；grep 成本对标/降本增效/节能技改/同区域 零命中——无与本厂历史最优或同区域同类水厂的成本对标与排名；无降本增效跟踪(节能技改项目改造前基期对比实际节约额)。PARTIAL 成立。",
   "severity": "med",
   "evidence": "OpsKpiController(/api/oa/ops-kpi)给出水质达标率(WaterQualityRecord result==达标占比)、生产工单产量/完成率/按车间分布/产量趋势；OpsCostAllocationController 按账期归集维修+污泥+危废成本并按计费水量分摊到各企业算毛利率；SewageEnergyLog /cost/summary 给月度吨水成本。",
   "survives": true,
   "reNote": "尽力反驳后无法推翻，PARTIAL 成立。可证伪的部分确实证伪了：污水专属 KPI 与跨模块绩效看板其实存在——SewageEnergyLogController.costSummary 按月归集 吨水电耗(unitPower)/吨水药耗(unitReagent)/吨水成本(unitCost)+加权吨水成本；OpsCostAllocationController/SewageSludgeController 按月/按方式归集污泥处置净成本；前端 ops/performance.vue「运营绩效成本(KPI看板)」跨模块自动取数(设备完好率/MTBF/维修成本+加权吨水成本+污泥净成本+工艺异常预警)成屏。OpsKpi 确为制造口径(planQty/actualQty/workshop，活体已验)，但污水侧另有专属看板，故「无污水专属 KPI」一说被部分证伪。但 PARTIAL 的三条核心理由我无法推翻，均确缺实现：(1) 不存在把吨水电耗/吨水药耗/污泥处置成本占比/安全事故数/预算执行率合在一张的统一月度/季度看板——安全事故数(EhsBoard.IncidentKpi)与预算执行率分散在互不相连的别处看板，performance.vue 内 grep 安全/事故/预算/执行率 零命中；且仅有月度聚合，无季度口径。(2) 成本对标/排名(对本厂历史最优或同区域同类水厂)：全后端+前端 grep 对标/benchmark/同区域/历史最优/排名 零命中(唯一命中是 ArchiveBorrow「比对标红」催还，无关)。(3) 降本增效/节能技改 改造前基期对比实际节约额：grep 降本增效/节能技改/基期/节约额/baseline/saving 零命中，无任何对标或节约额实体与逻辑。后两项是判定 PARTIAL 的实质依据，代码确无，无法证伪。",
   "reEvidence": "已实现侧(证伪部分缺口框架)：oa-backend/src/main/java/com/kaidi/oa/web/SewageEnergyLogController.java#costSummary(L158-188，CostRow 含 unitPower/unitReagent/unitCost) 与 #energyAlerts；OpsCostAllocationController.java(L68-132 月度污泥/维修/危废成本归集分摊)；SewageSludgeController.java#costSummary(L202-237 污泥净成本)；前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/ops/performance.vue(L19-55 跨模块 KPI 看板) + api/opsSewage.ts。制造口径确证：OpsKpiController.java(planQty/actualQty/workshop)，活体 http://127.0.0.1:8091/api/oa/ops-kpi 返回 byWorkshop=一号车间/二号车间。缺口属实侧(无法推翻)：全仓 grep '对标|benchmark|Benchmark|同区域|历史最优|降本增效|节能技改|基期|节约额|baseline|saving' 在 oa-backend/src/main/java/com/kaidi/oa 仅命中 ArchiveBorrowController.java/ArchiveBorrow.java(语义为「比对标红」催还，无关)；在 ops 前端页 0 命中。performance.vue grep 安全/事故/incident/预算/budget/执行率 0 命中(无统一安全+预算+成本对标看板)；无季度聚合，无成本对标排名，无节能技改基期-实际节约额跟踪。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "9. 报表与外部对接",
   "verdict": "PARTIAL",
   "gap": "坐实：grep 环保厅/住建局/政府报表/法定报表/污染物排放 零命中——无内置各省市法定报表模板(城镇污水处理厂污染物排放自动监测数据报表/运营月报)自动取数生成与在线填报上报；ReportDefinition 的 SOURCES 白名单为 Contract/Payment/Budget/Bid 等业务实体，不含污水台账；ExternalSystemConfig.adapter 缺省 mock，仅登记名册，grep 智慧水务/城市大脑/国发平台/省平台/环保在线 零命中——无与环保在线监测平台实时上传进出水水质、无智慧水务/城市大脑集成；内部报表无推送管理层邮箱/企业微信。PARTIAL 成立。",
   "severity": "high",
   "evidence": "ReportDefinitionController 是可配置报表系统(选源实体/维度/度量/过滤/图表，真实跑数)，SewageProcessRun /daily-report 与 SewageEnergyLog /cost/summary 提供内部生产/成本取数；ExternalSystemConfigController 提供外部对接系统名册 CRUD。",
   "survives": true,
   "reNote": "缺口属实。城镇污水运营中心确实没有\"各省市法定报表模板自动取数生成+在线填报上报\"，也没有与环保在线监测/智慧水务/城市大脑/省平台的实时集成，内部报表也无推送管理层邮箱/企业微信。我尽力找反证只找到相邻但不构成反驳的能力：(1) SewageProcessRunController 的 /daily-report 确实做了跨台账(工艺运行+药剂能耗)自动取数、按 GB18918 算去除率/达标率，但这是内部\"工艺日报\"，不是法定报表模板，也不是运营月报，更无上报通道；(2) WaterExceedEventController 的 transition \"上报\" 动作只把 reportedEpb 置 true 并向 handleLog 追加文本\"已上报环保局\"，纯内部状态标记，既不生成法定报表也不向任何外部系统上传。其余三项白名单/对接均坐实缺口。结论：PARTIAL 成立，缺口为真。",
   "reEvidence": "1) 全仓零命中(后端 oa-backend/src + 前端 modern-ui/app/src，java/ts/vue)：环保厅/住建局/政府报表/法定报表/智慧水务/城市大脑/国发平台/省平台/环保在线/自动监测数据报表/排污许可证执行报告/实时上传 全部 0 hits；\"在线填报\" 唯一命中在 domain/DevWbsTask.java(研发WBS自报)与污水无关。\n2) ReportDefinitionController.java SOURCES 白名单(第124-244行)硬编码为 contract/payment/budget/bid/opportunity/invoice/safety/instance/project，不含任何污水/水质台账；活体 GET /api/oa/report-definitions/schema 返回 ['contract','payment','budget','bid','opportunity','invoice','safety','instance','project'] 证实。\n3) ExternalSystemConfig.java 注释明言\"仅登记、模拟阶段不实连，真实外部连接留 TODO\"；MockSyncAdapter.java sync() 体内全是 TODO(真实外部对接)且只标记成功回填\"【模拟通道】…未实连外部系统\"；活体 GET /api/oa/external-systems 仅返回 [('用友财务T+','财务T+','mock')]，无任何环保/水务/政务平台、adapter 均为 mock。\n4) WaterExceedEventController.java transition() 的 \"上报\" 分支(第122-129行)仅 e.setReportedEpb(true)+appendLog \"已上报环保局\"，无报表生成、无外部上传。\n5) SewageProcessRunController.java /daily-report(第248-295行)是内部工艺日报跨台账聚合，非法定报表/运营月报/在线上报；ReportController.java 只有 /overview 一个只读端点。\n6) 前端 ops 页面(src/oa/pages/ops/*.vue)无法定报表/月报/上报/监测平台 UI，process.vue 仅\"生成工艺日报\"对话框。"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "10. 移动端应用",
   "verdict": "PARTIAL",
   "gap": "为通用 OA 移动工作台而非污水专用坐实：summary 只折叠 FormInstance 待办与 AlertController 通用预警，无移动巡检扫码查设备/记录运行参数/填污水巡检专表；无离线操作与网络恢复后同步；无手机端工艺流程图/关键参数/报警实时监控；工单接单/完工填报(SewageEquipment work-orders、OpsMaint orders)未做成独立移动工单页；移动审批为通用 FormInstance 流程，未绑定药剂采购/维修领料/预算外支出污水场景。PARTIAL 成立。",
   "severity": "med",
   "evidence": "MobileController(/api/oa/mobile/summary)聚合本人待办、平台预警、项目数等移动工作台首屏，按角色剥离敏感预警。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实。移动端模块(oaModules.ts:613-620 id:'mobile' 移动工作台)仅3个菜单项，全是通用OA：workbench/checkin/approval，无任何污水专项移动功能。\n\n逐条核对描述子项，全部坐实：\n1) 无移动巡检扫码查设备/记录运行参数/填污水巡检专表：全前端 grep 扫码/二维码/scan，命中的只有 opsSewage.ts 的 pmScan(=服务端 PM 预防性维护批量扫描，非手机扫码)和 qrTag(=设备实体上的存储字段)。equipment.vue/process.vue/maint.vue/dispatch.vue/reagent.vue 对 扫码/二维码/mobile/移动 命中数为 0。checkin.vue 里\"现场巡检\"只是输入框 placeholder 示例文字，非真功能。\n2) 无离线操作与网络恢复后同步：grep 离线/offline/navigator.onLine/网络恢复 在 oa/pages 下唯一命中是 utils/ycollab.ts(协同文档 yjs)，与移动污水无关；移动三页均无离线缓存/重发同步逻辑。\n3) 无手机端工艺流程图/关键参数/实时报警监控：process.vue grep svg/流程图/实时/realtime/websocket/setInterval/监控 命中 0。\n4) 工单接单/完工填报未做成独立移动工单页：污水工单后端确有状态机(opsSewage.ts equipApi report/dispatch/start/finish；/ops-maint/orders 待派工→处理中→已完工)，但承载它们的是桌面 list 页 ops/equipment.vue、ops/maint.vue、ops/dispatch.vue(均在 ops 运营中心模块、kind:'list'、大量 el-table/el-dialog 桌面表单)，全部挂在 /ops/* 而非 /mobile/*；移动模块下无任何工单接单/完工页。\n5) 移动审批为通用 FormInstance、未绑定药剂采购/维修领料/预算外支出污水场景：MobileApprovalController 只 import/读 FormInstance(findByStatusIn(PENDING_STATUSES) 当前办理人=本人)，全文无 sewage/reagent/领料/预算外/采购 任何绑定；前端 approval.vue 直接跳 /collab/handle 走通用审批引擎。\n\nworkbench.vue 头注释自述\"统一移动工作台…全部门访问…聚合既有后端端点…不新增后端纯前端聚合\"，import 的是 budget/ehs/masterdata/projects/costing/rd 等通用 api，0 处 import opsSewage/sewage/工艺/药剂/工单。PARTIAL 成立。",
   "reEvidence": "前端 oaModules.ts:613-620 移动模块仅 workbench/checkin/approval 三项；oa/pages/mobile/workbench.vue(通用聚合,无污水import) approval.vue(跳/collab/handle通用审批) checkin.vue(外勤打卡,\"巡检\"仅placeholder)；ops 桌面页 oa/pages/ops/{equipment,maint,dispatch,process,reagent}.vue(kind:'list' @ /ops/*,非/mobile/*,无扫码/流程图/实时/离线)；oa/api/opsSewage.ts(pmScan=服务端PM扫描,qrTag=存储字段)；后端 web/MobileApprovalController.java(仅读FormInstance,无sewage绑定) MobileController.java/MobileCheckinController.java(无污水/工单/药剂端点)"
  },
  {
   "area": "运营管理中心/城镇污水运营中心",
   "module": "11. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "未见与各部门的结构化数据契约坐实：无环保设备制造中心设备技术资料/备件型号/维保手册回流(SewageEquipment.supplier 仅文本，无外部资料接口)；无实验室委外检测原始数据接口；无采购部药剂/备件/维修外包合同订单联动(备件库本身缺失，DischargeContract 无采购/备件字段)；grep 申报服务部/绿色项目/环保合规证明/减排/削减COD 在污水域零命中(命中为 RD/IP/Declaration 域)——无向申报服务部输出处理水量/削减COD/减排量与环保合规证明；无向法务风险部推送环保处罚事件(WaterExceedEvent 仅 reportedEpb 标记，无跨法务域推送)；资料室自动归档运营记录/检测报告/设备档案未见专门联动。PARTIAL 成立。",
   "severity": "med",
   "evidence": "存在同模块内跨表自动取数联动：WaterAlertRule.ingest→WaterQualityRecord→WaterExceedEvent→DischargeBill(追偿账单)；OpsCostAllocation 跨 OpsMaintOrder+SewageSludgeRecord+HazWasteManifest+DischargeBill 归集分摊；TestTask→TestReport 联动。",
   "survives": true,
   "reNote": "尽力推翻但失败：缺口属实。城镇污水运营域确有完整深水功能（设备台账+PM维护+水质+超标事件+纳管合同+处理费账单+能耗/污泥/工艺运行），但缺口针对的是\"与各部门的结构化数据契约/接口\"——这一层在污水域全部缺失，逐条坐实：(1)无环保设备制造中心接口：SewageEquipment.supplier 仅 String 文本字段，无 model/manual/备件型号回流接口；javadoc 里\"MfgEquipment\"仅是\"区别于制造设备\"的说明性注释，非真实数据关联；grep MfgEquipment/维保手册/设备技术资料 在污水控制器零命中。(2)无备件库：domain/ 下无任何 spare/备件 实体；维修工单的 sparesUsed/sparePart 仅为 String 自由文本+spareCost 金额，不挂任何备件库存或采购订单。(3)无采购部联动：DischargeContract 无 procure/采购/purchaseOrder 字段；Reagent.supplier 同样仅文本，无采购合同/订单联动。(4)无实验室委外检测原始数据接口：污水控制器中 委外/外检/outsourc/检测原始 零命中。(5)无向申报服务部输出：申报服务部/绿色项目/环保合规/减排/削减COD 在污水域全部零命中，命中均落在 RD/IP/Declaration 域（IpInsightController 等）。(6)无向法务风险部推送环保处罚：WaterExceedEvent 仅有 reportedEpb 布尔标记，\"上报\"动作（WaterExceedEventController:126）只 setReportedEpb(true)，不创建任何跨法务域记录/不推送。(7)资料室自动归档运营记录/检测报告/设备档案未见：TriggerRuleEngine 的 chainArchiveProject 仅对 sourceType=\"项目\" 自动归档，无对水质/检测/设备/运行记录的归档联动；污水控制器中 archive/归档 零命中。(8)无外部对接框架接入：DataSyncLog/ExternalInterface 在污水控制器零命中。PARTIAL 判定成立。",
   "reEvidence": "domain/SewageEquipment.java:supplier 为 String，无 manual/备件型号字段，\"MfgEquipment\"仅出现在类注释中作区分说明；domain/SewageEquipment.java 无任何制造中心接口字段。domain/ 目录下无 spare/备件 实体（ls 验证 NONE）。web/SewageEquipmentController.java:244 setSparesUsed(String)、:245 setSpareCost；web/OpsMaintController.java:262 setSparePart(String) 均为自由文本，无库存/采购订单关联。domain/DischargeContract.java 无 procure/采购/purchaseOrder/备件 字段（grep 零命中）。domain/WaterExceedEvent.java:reportedEpb boolean；web/WaterExceedEventController.java:126 e.setReportedEpb(true) 是\"上报\"动作的全部实现，无跨法务域推送。service/TriggerRuleEngine.java:355-375 chainArchiveProject 仅对 sourceType=\"项目\" 归档；污水域无归档联动。grep 申报服务部/绿色项目/环保合规/减排/削减COD 在污水控制器零命中，全部落在 web/IpInsightController.java 等 RD/IP 域。grep DataSyncLog/ExternalInterface 在污水控制器 NONE。grep 委外/外检/outsourc/检测原始 在 SewageProcessRunController/WaterQualityRecordController NONE。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "1. 排污企业（客户）管理",
   "verdict": "LOGIC_GAP",
   "gap": "但深水缺口确凿且仍致命：valveAction 确为纯标志(setValveAction(boolean))无自动关阀执行；无声光/短信/APP推送(仅 reportedEpb 布尔位)；无流量计/在线监测硬件采集通道；无独立企业月/季服务报告生成与推送(全项目无该端点)。维持 LOGIC_GAP。",
   "severity": "high",
   "evidence": "WastewaterClient.java 实体字段仅 name/industry/dischargeType/contractNo/dailyVolume/pollutant/serviceStatus/owner —— 无环评批复/排污许可证/排水许可/排水规律(时段流量波动)，无环评报告/管网图上传字段(File关联也无)。来水接入唯一入口 WaterAlertRuleController.ingest 是手工 POST 单条读数(IngestRequest)，无流量计瞬时/累计自动采集、无 pH/COD 在线设备实时上传。反驳中确有部分被低估：WaterAlertRule 实现了每企业纳管阈值(codLimit/ammoniaLimit/tpLimit/phMin/phMax)+warnRatio 预警比例+autoCloseValve；ingest 自动判定达标/预警/超标并自动登记 WaterExceedEvent(severity 分级/exceedRatio/状态机/handleLog)，WaterExceedEventController 还有暂停纳管→追偿(联动生成 DischargeBill 追偿账单)→上报→闭环状态机与追责看板——比初判'仅入库登记valveAction标志'强。",
   "survives": true,
   "reNote": "缺口属实，四项深水子缺口逐条在代码中坐实，无法推翻。(1) valveAction 确为纯标志：WaterExceedEvent.valveAction 是普通 Boolean，全项目唯一赋值点 WaterAlertRuleController.java:182 `event.setValveAction(rule!=null && Boolean.TRUE.equals(rule.getAutoCloseValve()))`，domain javadoc 自述为\"是否触发关阀建议\"，无任何阀门/设备执行代码（modbus/mqtt/OPC/PLC/SCADA/closeValve/actuator/relay 全项目搜索仅命中无关的 collab/websocket/sync 文件）。(2) 无声光/短信/APP推送：SmsClient/sendSms/aliyun/jpush/getui/FCM/声光/蜂鸣 全项目零命中；超标\"报警\"只是 setStatus(\"已报警\")+追加 handleLog 文本(WaterAlertRuleController.java:183-185)，两个控制器都未注入任何 Notification/Message/Alert 服务；reportedEpb 仅由人工\"上报\"transition 翻成 true(WaterExceedEventController.java:126)，是状态布尔位非外发通道。(3) 无流量计/在线监测硬件采集通道：所谓\"在线读数\"入口 POST /water-alert-rules/ingest 接收人工 JSON(IngestRequest 手填 cod/氨氮/pH/总磷/inspector)，非设备喂数；DischargeBillController.java:91-92 明文承认水量按 dailyVolume×天数\"估算\"，注释\"流量计逐日数据接入前的合理口径\"，反证硬件通道不存在。(4) 无独立企业月/季服务报告生成与推送：枚举六个废水控制器全部路由(WastewaterClient/WaterQualityRecord 纯CRUD、WaterAlertRule CRUD+ingest、WaterExceedEvent 列表/详情/transition/dashboard、WaterTrace /trace)，无任何按企业周期生成或推送服务报告的端点；全项目\"月/季+report\"仅命中 DischargeBillController(账单链 /generate 生成处理费账单非服务报告)与 StoredFile.java(javadoc 示例文件名\"季度报告.pdf\")，无 serviceReport/月报/季报 端点。维持 LOGIC_GAP。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/domain/WaterExceedEvent.java:55-56,71,165-171 (valveAction/reportedEpb 纯布尔字段，无执行); oa-backend/src/main/java/com/kaidi/oa/web/WaterAlertRuleController.java:182-185 (valveAction 唯一赋值=标志位; 报警仅 setStatus+handleLog 文本，无推送/无 Notification 注入); oa-backend/src/main/java/com/kaidi/oa/web/WaterAlertRuleController.java:126-167 (ingest 入口为人工 JSON IngestRequest，非硬件采集); oa-backend/src/main/java/com/kaidi/oa/web/WaterExceedEventController.java:122-128 (上报=仅置 reportedEpb=true，无外发); oa-backend/src/main/java/com/kaidi/oa/web/DischargeBillController.java:91-92 (注释自述水量为估算，流量计数据\"接入前\"); 六个废水控制器路由清单(grep @*Mapping)无任何 report/月/季/push 端点; 全项目 grep modbus|mqtt|OPC|PLC|SCADA|closeValve|actuator|sendSms|aliyun|jpush|声光|服务报告|月报|季报 仅命中无关基础设施文件与 StoredFile javadoc 示例文件名。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "2. 工艺运行管理（分质分流与预处理）",
   "verdict": "LOGIC_GAP",
   "gap": "需求§2 的分质分流配置、各预处理单元逐参数监控、生化/膜深度处理参数、异常知识库均无建模。维持 LOGIC_GAP。",
   "severity": "high",
   "evidence": "SewageProcessRun.java 是单张厂级聚合台账(plant/shift/进出水量+COD/氨氮/总磷+DO+MLSS+去除率+达标判定)，控制器 SewageProcessRunController 只有 CRUD+alerts+daily-report。grep 分质分流/破氰/膜通量/UF/RO/微电解/气浮/混凝/污泥膨胀/膜污染 在 web 与 domain 零命中(仅 DataSeeder/DesignProject 噪声)。无各预处理单元(中和/气浮/混凝/微电解/破氰/还原池)的 pH/ORP/加药量/液位建模；生化 ORP/回流比/污泥龄/SV30 无；膜系统 UF/RO 进出水压力/膜通量/CIP 周期无；工艺异常处置知识库(含历史案例推荐)无任何承载实体。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。需求 §2「工业废水运营中心·工艺运行管理（分质分流与预处理）」要求四块建模：分质分流配置（按企业废水特性配预处理线路+各调节池/预处理单元进水来源/水量/水质）、各预处理单元逐参数监控（中和池/气浮/混凝/微电解/高级氧化/破氰池等的 pH/ORP/流量/加药量/液位/反应时间）、生化+膜深度处理参数（回流比/营养盐/污泥龄/沉降比、UF/RO 进出水压力/产水率/膜通量/CIP/回用率）、工艺异常处置知识库（异常事件+推荐方案+案例库）。这四块在前后端均无任何建模。\n\n现存的看似相关代码全部是「城镇污水运营中心（§1）」的别域实现，不能顶替工业废水 §2：\n1) domain/SewageProcessRun + web/SewageProcessRunController + 前端 ops/process.vue 的类注释明写「城镇污水运营·工艺运行管理」，模型是单条扁平日台账，只有进出水量+COD/氨氮/总磷进出+DO+MLSS+去除率+GB18918达标判定；没有「单元」「线路」「膜」「知识库」概念，无法承载分质分流与逐单元逐参数监控。\n2) domain/WastewaterClient 只是排污企业客户主档（行业/排放类型/污染物），无工艺建模。\n3) domain/SewageEquipment 虽有 processSection 枚举（预处理/生化/深度处理字样），但它是设备资产台账（运行小时/MTBF/保养），只命名工艺段、不监控任何工艺参数（无 ORP/液位/反应时间/膜通量/产水率）。\n\n判定维持 LOGIC_GAP 成立。",
   "reEvidence": "需求原文：requirements/_req_slices/15_运营管理中心__工业废水运营中心.txt:8-9（## 2. 工艺运行管理（分质分流与预处理）：分质分流管理/预处理单元监控/生化系统监控/深度处理与回用/工艺异常处置知识库/工艺报表）。\n\n现存别域实现（均为城镇污水§1，非工业废水§2）：\n- oa-backend/src/main/java/com/kaidi/oa/domain/SewageProcessRun.java（类注释第12行「城镇污水运营·工艺运行管理」；字段仅 inflow/outflow/codIn/codOut/ammoniaIn/Out/tpIn/Out/dissolvedOxygen/mlss/codRemoval/ammoniaRemoval/tpRemoval/standard/status/alertLevel）\n- oa-backend/src/main/java/com/kaidi/oa/web/SewageProcessRunController.java（第28行注释「城镇污水运营·工艺运行管理」；limitsOf 仅 GB18918；无单元/线路/膜/知识库端点）\n- oa-backend/src/main/java/com/kaidi/oa/domain/WastewaterClient.java（仅客户主档）\n- oa-backend/src/main/java/com/kaidi/oa/domain/SewageEquipment.java（设备资产台账，processSection 仅命名工艺段不存参数）\n- ofbiz-framework/plugins/modern-ui/app/src/oa/api/opsSewage.ts（第1-7行注释「城镇污水运营中心」）\n- ofbiz-framework/plugins/modern-ui/app/src/oa/pages/ops/process.vue（注释「工艺运行管理：日台账录入进出水水质」，仅 COD/氨氮/总磷/DO/MLSS）\n\n缺失验证：对 ORP/膜通量/产水率/回用率/调节池/中和池/气浮/混凝/微电解/破氰/还原池/污泥龄/沉降比/分质/回流比/营养盐/异常知识库 在 oa-backend/src 与前端 src 全量 grep，零相关命中；唯有的「分流」命中是 service/WorkflowService.java:1133/1164 的审批「按主体分流」路由，与污水工艺无关。ops 页目录无任何工业废水分质分流/预处理单元/膜系统页面。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "5. 水质检测与实验室管理",
   "verdict": "LOGIC_GAP",
   "gap": "废水专属采样计划生成、特征污染物结构化录入、逐样达标判定+超标触发整改、质控管理均缺。仅电子签名一项成立(不足以翻案)。维持 LOGIC_GAP。",
   "severity": "high",
   "evidence": "LabSample.java 为扁平 CRUD(sampleNo/sampleName/sampleType/source/testItems/status)，无 LIMS 批量导入、无特征污染物(六价铬/总氰/挥发酚/镍铜锌)结构化字段。grep 加标/平行样/六价铬/总氰/挥发酚/GB8978/采样计划/质控/标准样 全项目零命中。出水达标判定只在 SewageProcessRun 按 GB18918 判工艺出水(非逐样检测数据对比 GB8978/纳管标准)。质控(标准样/加标回收/平行样自动算偏差)零实现。唯一沾边的是 TestReportController.sign 实现电子签名签发(待签发→已签发锁定)，但报告本身无水质结构化指标，且未与废水语境绑定。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。我尽力寻找反证：确实发现了比缺口承认的更厚的实验室子系统（TestTaskController 检测任务 record/review 双人闭环 + TestReportController 电子签名签发即锁定 sign/void），这与缺口\"仅电子签名一项成立\"的让步一致。但缺口点名的四项核心逐条核对全部成立：\n\n(1) 废水专属采样计划生成——缺失。全仓 grep 采样计划/samplingPlan/采样任务/采样点位/移动采样 后端+前端零命中，无 SamplingPlan 实体/控制器/端点，无按排污企业/工艺段/出水/污泥生成采样任务，无移动端点位录入。\n\n(2) 特征污染物结构化录入——缺失。WaterQualityRecord 仅 4 个写死数值列(codValue/ammoniaValue/phValue/tpValue)；TestTask 只有单个自由文本 detectItem + 单个 resultValue，非结构化多污染物面板。grep 六价铬/总铬/总氰/挥发酚/镍/铜/锌/特征污染物 在后端与前端业务代码零命中，无批量导入端点。\n\n(3) 逐样达标判定+超标触发整改——缺失。WaterQualityRecordController.create:69-73 与 update:84-93 直接 setResult(req.result()) 原样透传，前端 quality.vue:23 result 是人工 select(达标/超标/预警)；TestTaskController.record:187-197 的 judge 直接取 req.judge()，从不把 resultValue 与 standardLimit 做任何比较(standardLimit 仅作为字符串存储字段，从未参与比较表达式)，无 GB8978/GB18918 自动对标、无超标自动标红、无整改工作流触发。唯一存在自动达标判定的 SewageProcessRunController 是城镇污水\"工艺运行台账\"(进出水浓度去除率)，非实验室水质检测样品域。TriggerRuleEngine/WorkflowService 对 water/lab/超标/整改 零联动。\n\n(4) 质控管理——缺失。grep 平行样/加标回收/空白样/标准样/质控样/质控偏差/回收率/RPD/relativeDeviation 在后端与前端零业务命中(仅 ErpDataTable/PDF 渲染噪声)，无任何质控实体或偏差计算。\n\n维持 LOGIC_GAP 成立。",
   "reEvidence": "后端纯透传无判定：oa-backend/src/main/java/com/kaidi/oa/web/WaterQualityRecordController.java:69-73(create setResult 原样存)、:84-93(update 同样直写)；domain/WaterQualityRecord.java 仅 4 个固定数值列+1 个 String result。\n人工录入：modern-ui/app/src/oa/pages/ops/quality.vue:23 result 字段 type:'select' options ['达标','超标','预警']。\nTestTask 判定为手填非自动：oa-backend/.../web/TestTaskController.java:118-119(create 直存 standardLimit/judge)、:187-197(record 取 req.judge() 校验枚举但从不比对 resultValue 与 standardLimit；仅 OOS偏差 转\"偏差处理\")；standardLimit 在全文件仅出现在 record/字段定义(:92,:171)，无任何 parseDouble/比较表达式。\n电子签名(缺口已承认的唯一成立项)：web/TestReportController.java:136-155 sign 签发即锁定、:97-99/:120-122 已签发不可改删——确实实现，与缺口让步一致。\n采样计划：grep 采样计划|samplingPlan|采样任务|采样点位|移动采样 在 oa-backend 与 modern-ui/app/src 零命中。\n特征污染物：grep 六价铬|总铬|总氰|挥发酚|镍|铜|锌|特征污染物|characteristicPollutant 在业务代码零命中(仅 DataSeeder 种子串)。\n质控：grep 平行样|加标回收|空白样|标准样|质控样|回收率|RPD|relativeDeviation|spikeRecovery 后端+前端零业务命中。\n自动判定属相邻域(非本链)：web/SewageProcessRunController.java:141-178 applyValues 对工艺运行台账(进出水)自动算去除率/达标/报警，按 limitsOf(standard) 比对——但这是城镇污水工艺运行台账，非实验室水质检测样品。\n联动引擎无 water/lab 整改：service/TriggerRuleEngine.java 与 service/WorkflowService.java grep water|废水|超标|exceed|lab|sample|整改|rectif 仅命中通用合同/表单 label 管线，无水质超标→整改联动。\n组织映射：modern-ui/app/src/data/oaModules.ts:441-462 运营管理中心(ops)\"水质检测\"链=/ops/quality(纯CRUD人工下拉)+/ops/trace；实验室(lab)为独立中心(:502)。需求原文 requirements/_req_slices/15_运营管理中心__工业废水运营中心.txt:17-18 明确\"5.水质检测与实验室管理\"需采样计划生成/特征污染物/达标自动判定+超标触发整改/质控四项。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "7. 安全环保与合规",
   "verdict": "PARTIAL",
   "gap": "通用 EHS 隐患闭环在(故 PARTIAL 而非 MISSING)，但废水专属巡检/化学品双锁/排污许可证/应急预案演练均缺。维持 PARTIAL。",
   "severity": "med",
   "evidence": "EhsHazard.java 为通用质安隐患(type/category/location/riskScore/rectifyMeasure/verifier 闭环)，无废水专属巡检路线/检查项配置(化学品存储/有限空间/应急池)与移动端扫码打卡(grep 有限空间/应急池/双人双锁/MSDS 在 web 零命中，仅 DataSeeder/Favorite 噪声)。化学品 MSDS 仅文件字段、双人双锁/领用审批未建模。排污许可证管理(许可排放量/监测频次/执行报告提交日期提醒)无实体。应急预案在线管理/演练记录/突发环境事件上报流程无。HealthRecord.java 实体存在(职业健康)但未接入本运营单元。",
   "survives": true,
   "reNote": "尽力推翻但失败：缺口属实，PARTIAL 判定正确。通用 EHS 隐患闭环确实存在(SafetyCheckController rectifyStatus 待整改→整改中→已闭环 + EhsHazard/EhsCapa/EhsIncident/EhsBoard/EhsObjective 一整套控制器)，所以不该是 MISSING；但四项废水专属子能力逐一彻查后确认全缺：(1)废水专属巡检——只有通用 SafetyCheck(type=安全/质量/环境，location 自由文本)，唯一\"巡检\"是 SewageEquipment 注释里的 PM 预防性保养扫描(设备保养工单)，不是 EHS 安全巡检；(2)化学品双锁——零命中，Reagent 危化品档只有 casNo/sdsFile/单人 inbound-outbound，无双人/双锁监管，\"双人\"命中全是 Settlement 财务复核与 TestTask 检测复核，与化学品保管无关；(3)排污许可证——排污许可/排放许可零命中，EhsWorkPermit 是危险作业票(动火/受限空间+气体检测+监护人，性质完全不同)，DischargeContract/DischargeBill 是废水处理费纳管计价合同/账单(商务侧)而非环保许可证；(4)应急预案演练——实体/控制器零命中，仅 CostAuditTrace 的财务 drill 下钻(英文同名词无关) 与 FavoriteController:59 一条硬编码 mock 字符串\"应急预案与演练记录\"(收藏列表展示串，无实体无 CRUD)。故维持 PARTIAL。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa：web/SafetyCheckController.java(通用EHS隐患闭环，type∈安全/质量/环境，rectifyStatus 待整改/整改中/已闭环)；web/EhsWorkPermitController.java + domain/EhsWorkPermit.java(危险作业票=动火/受限空间，非排污许可证)；domain/Reagent.java(危化品档=casNo/sdsFile/minStock，无双人双锁)；domain/SewageEquipment.java:14-18(唯一\"PM 巡检\"为预防性保养，非安全巡检)；domain/DischargeContract.java:14 与 domain/DischargeBill.java:13(纳管处理费计价合同/账单，非环保许可证)；web/FavoriteController.java:59(硬编码 mock 串\"应急预案与演练记录\"，无实体)。grep 全库 排污许可|排放许可|dischargePermit=0 命中；化学品双锁|双锁|dualControl(废水/化学品语境)=0 命中；应急预案|应急演练 实体/控制器=0 命中。前端 ofbiz-framework/plugins/modern-ui/app/src 对 排污许可/化学品双锁/废水巡检/应急演练 grep=0 命中。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "9. 报表与外部对接",
   "verdict": "PARTIAL",
   "gap": "政府监管报表模板、在线监测平台实时上传、外部系统对接、一键导出推送均缺；仅通用对接框架+reportedEpb 标志成立。维持 PARTIAL。",
   "severity": "high",
   "evidence": "无环保局/住建局监管报表模板：grep 环保局/住建局/运营月报/危废台账/排污许可执行报告 全项目仅命中 WaterExceedEvent 的 reportedEpb 上报标记。与环保部门在线监测平台(国发/省平台)实时上传进出水数据接口无：通用 IntegrationController/ExternalSystemConfigController/DataSyncLogController 框架存在但 grep water/sewage/在线监测/国发/省平台 在这些文件零命中，未连任何废水数据源。与排污企业 ERP/MES、智慧园区平台对接无。内部报表(SewageProcessRunController.daily-report、WaterExceedEventController.dashboard、SewageSludgeController.cost/summary)能聚合但无一键导出上报/推送邮箱企业微信。",
   "survives": true,
   "reNote": "缺口属实。对抗复验后无法推翻：工业废水运营中心「报表与外部对接」链中，政府监管报表模板、在线监测平台实时上传、真实外部系统对接、一键导出/推送四项均确实未实现，仅存在通用对接框架(mock)与 reportedEpb 状态标志。具体：(1) 政府监管报表模板缺失——全 .java 中 grep 政府监管报表模板/环保报表/排污许可/排放报表/监测日报月报 全部为空，ReportDefinition/Report 控制器无任何 EPB/废水/水质报表定义。(2) 在线监测实时上传缺失——唯一的\"在线监测\"入口是 WaterAlertRuleController.ingest，是人工 POST 录入读数落 WaterQualityRecord 并做内部阈值判定，无任何外部监测平台入站数据流，无 HJ212/数采仪/国控省控协议。(3) 外部对接只有通用 mock 框架——MockSyncAdapter 是默认且唯一适配器，sync() 明确不实连任何系统(注释\"不实连，直接标记成功\"，政务网关仅在 TODO 里)，无 EPB/政务专用适配器。(4) 一键导出/推送缺失——全代码无任何 wastewater/water/report 域的 export/push/upload 端点；WaterExceedEventController 的\"上报\"动作只 setReportedEpb(true)+追加日志\"已上报环保局\"，纯状态标志零外部传输。判定与描述完全吻合，维持 PARTIAL。",
   "reEvidence": "web/WaterExceedEventController.java:122-128 \"上报\"动作仅 e.setReportedEpb(true)+appendLog(\"已上报环保局\")，无外部传输；dashboard 里 reportedEpb 只用于计数。service/MockSyncAdapter.java:26-37 sync() 注释明示\"当前为模拟实现：不实连，直接标记成功并回填说明\"，政务网关对接列在 TODO；systemType()=\"mock\" 为 IntegrationExecutor 的 defaultAdapter(IntegrationExecutor.java:61,146)。web/WaterAlertRuleController.java:138-197 ingest 为人工录入读数+内部阈值判定，非外部平台实时上传。全仓 grep 政府监管报表模板/环保报表/排污许可/一键导出/一键推送 与 export/push/upload 端点(针对 water/report 域) 均为空(仅 FileController.upload、AdminSupply/Reagent outbound 等无关项)。ReportDefinition/Report 控制器无 epb/环保/排污/监测/废水/水质 报表定义。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "10. 移动端应用",
   "verdict": "PARTIAL",
   "gap": "移动端为通用工作台，废水专属移动巡检/离线同步/实时监控/工单移动接单/危废联单移动入口均缺。维持 PARTIAL。",
   "severity": "med",
   "evidence": "MobileController.java 仅一个 /summary 通用聚合端点(待办数/预警数/项目数+前5条预览)，无废水专属：无扫码查看设备信息/记录运行参数/上报故障的移动巡检表，无离线操作网络恢复同步，无手机端工艺流程图/各企业来水实时监控。SewageWorkOrder.java 有 photoRef(扫码上报留存)与待派工→已派工→维修中→已完工状态机，但 SewageWorkOrderController 端点非移动专属、未接入 /api/oa/mobile。危废电子联单(SewageSludgeRecord 状态机)有 Web 入口但无移动扫码/打印联单入口。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。移动端确为通用工作台，废水专属移动巡检/离线同步/实时监控/工单移动接单/危废联单移动入口均缺。证据链：(1) 移动模块在 oaModules.ts 第613-621行仅3个子项——workbench(portal聚合)/checkin(通用外勤打卡)/approval(通用移动审批)，无任何废水专属页。(2) MobileController.java 类注释自述\"Mobile work-bench aggregation 移动工作台后端聚合\"，summary 端点只聚合本人待办/平台预警/项目数，纯通用，零废水维度。(3) MobileCheckin 是通用外勤打卡(上班/外勤/拜访/下班)+geolocation回填，不是废水现场巡检；checkin.vue 中\"现场巡检\"仅作为\"拜访对象/事由\"输入框的placeholder示例文字出现，非真实巡检功能。(4) 离线同步缺失——全前端 grep 无 IndexedDB/serviceWorker/sync-queue/navigator.onLine。(5) 实时监控缺失——ops/与mobile/页面 grep 无 WebSocket/EventSource/SCADA/在线监测。(6) 工单移动接单缺失——SewageWorkOrder/WorkOrder 控制器是普通桌面CRUD台账，ops/dispatch.vue 是桌面处理费计费页，均无移动接单/抢单。(7) 危废联单 HazWasteManifestController 有完整产生→暂存→转移→处置桌面状态机，但无任何移动入口。废水后端能力(危废联单/污泥/水质/设备工单)与桌面ops页确实存在，但都未接入移动端做废水专属移动化。维持 PARTIAL 判定正确。",
   "reEvidence": "前端移动页目录 /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/mobile/ 仅含 workbench.vue/checkin.vue/approval.vue；模块定义 src/data/oaModules.ts:613-621(mobile仅3子项)；后端 oa-backend/src/main/java/com/kaidi/oa/web/MobileController.java(通用聚合,类注释行23-29)、MobileCheckinController.java+domain/MobileCheckin.java(通用外勤打卡非巡检)、WorkOrderController.java+domain/SewageWorkOrder.java(桌面工单CRUD无移动接单)、HazWasteManifestController.java(桌面状态机无移动入口)；离线同步 grep(IndexedDB/serviceWorker/navigator.onLine)在 src 下零命中废水移动场景；实时监控 grep(WebSocket/EventSource/SCADA)在 ops/与mobile/页面零命中。"
  },
  {
   "area": "运营管理中心/工业废水运营中心",
   "module": "11. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "仅财务一条链真打通，其余 5 类接口缺(epbSynced/reportedEpb 等为标志位非真实取数)。维持 PARTIAL。",
   "severity": "med",
   "evidence": "财务成本/收款链真实打通：DischargeBillController 生成账单+收款状态机+逾期催收，WaterExceedEventController 追偿动作联动生成 DischargeBill(claimBillId 回填)，SewageSludgeController.cost/summary 已结算口径归入运营成本供财务取数——这部分成立。但其余跨模块接口为口径提及无真实取数：与实验室特征污染物原始数据结构化接口不存在(LabSample 无该字段)；采购药剂/备件/维修外包合同联动无(SewageWorkOrder.spareCost 仅本地金额)；申报服务减排贡献/环保合规证明自动取数无(grep 减排/COD削减/绿色制造/环保专项 零命中)；法务排污合同审核/处罚/追偿对接无；档案室运营记录/检测报告自动归档无。",
   "survives": true,
   "reNote": "Gap is real. Only the finance interface truly fetches cross-table data; the other six required interfaces (equipment manufacturing, lab, procurement, declaration, legal, archive) are absent or are boolean flags such as epbSynced and reportedEpb. PARTIAL stands.",
   "reEvidence": "epbSynced and reportedEpb are boolean flags only (HazWasteManifestController:195, WaterExceedEventController:126). MockSyncAdapter is the sole SyncAdapter and admits no real connection; IntegrationExecutor defaults to it. The eleven ops and water controllers import only their own ops entities and never Lab, Purchase, Supplier, Archive, Declaration, Legal, Voucher, or Payment. The discharge bill finance chain is not wired to TriggerRuleEngine."
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "1. 市场信息与商机管理",
   "verdict": "PARTIAL",
   "gap": "RPA真联网抓取+落MarketIntel行；竞争对手结构化档案(技术/报价/历史中标)及投标时对手对比；特殊项开标/下浮率/分维度中标汇总专用统计。",
   "severity": "med",
   "evidence": "维持初判。已建情报域比初判想象更全(MarketIntelController 有台账CRUD + 一键转商机回链留痕 to-opportunity + 区域市场分析 /analysis/region 真聚合情报/项目/竞争对手/政策条数与金额规模；CrawlSourceController+CrawlJob 有采集源台账与运行批次记录)。但初判三处缺口属实：(a) CrawlSourceController.java:89-121 run() 确为模拟，注释明说 no real network crawling，fetched=10+(nanoTime%31)/screened=fetched*0.6/newIntel=screened*0.4，只落 CrawlJob 计数行不写任何 MarketIntel 真情报行；(b) 竞争对手分析仅 MarketIntel.intelType=\"竞争对手\" 标签计数(MarketIntelController.java:233 competitorCount++)，无对手技术/报价/历史中标结构化档案实体，投标侧 BidController/BidDecisionController 无对手对比调用；(c) 市场项目分析仅 region 维度，无特殊项开标记录筛选/下浮率汇总/分公司类型-金额-项目类型中标汇总表等专用统计。",
   "survives": true,
   "reNote": "缺口三个子项全部属实，未实现。子项①RPA真联网抓取+落MarketIntel行：CrawlSourceController.run() 是纯模拟（Javadoc明确\"no real network crawling is performed\"，fetched 用 System.nanoTime()%31 造10..40随机数，screened/newIntel 按比例派生），crawl路径内无任何 HttpClient/RestTemplate/WebClient/Jsoup/URL；且 run() 只写一条 CrawlJob 计数记录，完全不创建任何 MarketIntel 行（grep 证实 CrawlSourceController 不引用 intelRepo/MarketIntel）。子项②竞争对手结构化档案(技术/报价/历史中标)+投标时对手对比：domain/ 下无任何 Competitor/对手 实体；唯一的\"竞争对手\"是 MarketIntel.intelType==\"竞争对手\" 的自由文本情报行，只在 regionAnalysis() 里被 competitorCount++ 计数，没有技术能力/对手报价/历史中标的结构化字段，也无投标时对手对比功能（\"历史中标\"grep命中均在 PriceItem 价格库，与对手无关）。子项③特殊项开标/下浮率/分维度中标汇总专用统计：投标统计只有最朴素的中标率——BusinessBiController.biddingStat() 返回 BiddingStat(bidCount,wonCount,winRate)，BranchPnlController 按机构算 winRate=bidWon/bidTotal；全仓无\"下浮率\"投标统计（下浮/discountRate 仅命中 DischargeContract 排水定价，与招投标无关）、无开标(开标)统计端点、无分维度(按项目类型/区域)中标汇总报表。",
   "reEvidence": "web/CrawlSourceController.java:82-121 run() 模拟抓取（\"no real network crawling is performed\"，fetched=10+(nanoTime+kw*7)%31），不写 MarketIntel；domain/CrawlJob.java:11-17 \"No real network crawling is performed\"。grep 确认 crawl 路径无 HttpClient/RestTemplate/WebClient/Jsoup/URL，且 CrawlSourceController 不引用 intelRepo/MarketIntel。domain/ 下无 Competitor 实体；web/MarketIntelController.java:210-256 competitorCount 仅按 intelType==\"竞争对手\" 计数，无结构化对手档案字段、无投标对手对比。web/BusinessBiController.java:125-282 biddingStat 仅 bidCount/wonCount/winRate；web/BranchPnlController.java:122-132 仅机构级 winRate。下浮率仅见 web/DischargeContractController.java、domain/DischargeContract.java（排水定价，非招投标）。无开标统计/分维度中标汇总端点。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "2. 市场推广与活动策划(AI)",
   "verdict": "LOGIC_GAP",
   "gap": "缺资料→多平台推广文案(海报/朋友圈)专用AI编排；缺数据报表→营销复盘结论/优化建议专用AI编排；campaign页无AI入口。",
   "severity": "med",
   "evidence": "维持初判。MarketCampaignController.java 全文仅活动台账CRUD(theme/campaignType/budget/leads/status)零AI引用；前端 crm/campaign.vue 只调 /market-campaigns，无任何 /api/oa/ai 引用(全前端AI端点消费者仅 appdev/aiassist.vue 一处通用页)。AiService/AiController 只有通用 draft/classify/summarize/risk/complete 五个裸场景，systemFor() 无多平台推广文案(海报/朋友圈)生成、无数据报表→营销复盘结论/优化建议的场景化编排；grep 全后端 海报/朋友圈/复盘/多平台 无市场推广AI封装命中。AiService 消费者仅 AiController 一家，无任何业务控制器接入AI做场景落地。",
   "survives": true,
   "reNote": "缺口属实，未能推翻。逐条核验：(1) campaign页确无AI入口——/oa/pages/crm/campaign.vue 是纯 MasterDataPage CRUD 壳，仅接 /market-campaigns，全文 grep 无 ai/生成/文案/海报 任何引用；后端 MarketCampaignController 也是纯增删改查，无任何 AI 端点。(2) 多平台推广文案(海报/朋友圈)专用AI编排——不存在。系统确有统一 AI 层(AiController /api/oa/ai/* + AiService 调 Anthropic Messages API)，但只有 5 个通用场景 complete/draft/classify/summarize/risk，draft 仅一句通用系统提示\"企业办公写作助手\"，无多平台/海报/朋友圈结构化编排；全库 grep 海报|朋友圈|多平台 只命中无关的 ContentPiece 注释和 Voucher.poster(记账凭证录入人)字段。(3) 营销复盘结论/优化建议专用AI编排——不存在；无任何端点把 campaign 指标/报表数据喂给 AI 产出复盘或优化建议，summarize/risk 都是手工粘贴文本的通用场景。全前端唯一的 AI 消费页是 appdev/aiassist.vue(路由 /appdev/aiassist，挂在\"应用定制平台\"模块下的通用 AI 助手)，与 campaign 无任何关联、不预载活动数据、campaign 页也不链接到它。试图推翻的最强反证(已有通用 /ai/draft + 通用助手页)不成立：通用、手工、跨模块的助手页不等于\"campaign 页 AI 入口\"，也不等于\"多平台文案/营销复盘的专用编排\"。",
   "reEvidence": "campaign.vue 无AI: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/crm/campaign.vue(纯MasterDataPage,仅/market-campaigns CRUD); 后端纯CRUD: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/MarketCampaignController.java(无AI端点); 统一AI层仅5通用场景: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/AiController.java + /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/AiService.java(systemFor仅complete/draft/classify/summarize/risk,draft为单一通用提示,无海报/朋友圈/多平台/复盘编排); 全前端唯一AI页且与campaign无关: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/appdev/aiassist.vue(路由/appdev/aiassist,oaModules.ts第98行挂在appdev模块); grep 海报|朋友圈|多平台|营销复盘 全库无营销专用AI编排命中(仅 ContentPiece 注释与 Voucher.poster 无关项)。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "3. 招投标管理",
   "verdict": "PARTIAL",
   "gap": "投标标书在线协同+版本+批注；Bid用印哈希字段与用章中心联动；中标通知书自动归档；丢标原因案例库；报价明细自动取成本测算(直/间接费/利润/税金)。",
   "severity": "high",
   "evidence": "维持初判。已建比初判更全：BidDecisionController 有决策会(技术/商务/成本/法务意见字段)+决策通过自动生成6项标准投标任务清单(/decide)；BidBond/BidDeposit 管保证金缴退；BidController.chainWinBid 中标自动建项目台账+总包合同草稿。但初判缺口全部属实：(a) 投标文件在线协同编制+版本控制+在线批注无实体(grep 标书/BidDoc 仅命中 BidDecision 任务模板字符串)；(b) Bid.java 仅 id/projectName/.../bidAmount/deposit/status，无 seal/用印/文件哈希字段，EsignController 只服务合同(/api/oa/contracts下)不服务投标；(c) 中标通知书自动归档缺失——chainWinBid 只建合同草稿HT-B{id}，TriggerRuleEngine Archive 自动创建只对项目归档(:365)；(d) 丢标原因案例库缺失(Bid 无 loseReason，grep 丢标/案例库仅命中 Culture 模块)；(e) 报价明细自动取成本测算未见——BidDecision \"报价测算(关联成本测算)\" 仅一行模板字符串，bidAmount 手填。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。招投标基础全流程确已实现（Bid CRUD + 决策会 BidDecision + 任务清单 BidTask + 保证金 BidDeposit/保函 BidBond + 中标自动联动建项目台账与总包合同草稿 chainWinBid），故整体判 PARTIAL 合理。但描述列举的 5 个进阶子特性逐条核查后全部缺失：(1) 标书在线协同+版本+批注——无任何标书文档协同/版本/批注实体或接口，全库 grep 仅命中无关任务名字符串；(2) Bid 用印哈希字段与用章中心联动——Bid 实体无 sealHash/seal 字段，Seal/SealUse 域无 bidId 关联，零联动；(3) 中标通知书自动归档——chainWinBid 只建 Project+Contract，不生成/归档任何中标通知书到档案中心；(4) 丢标原因案例库——Bid 无 lossReason 字段，无案例库实体/接口，\"未中标/废标\"仅是状态枚举值不带原因采集；(5) 报价明细自动取成本测算(直/间接费/利润/税金)——Bid 仅存一个平铺 bidAmount，无报价行项、无直接费/间接费/利润/税金拆解、无对 StandardCost 的自动取数，唯一相关命中是 BidDecisionController 第59行任务模板里的字面串\"报价测算（关联成本测算）\"，那只是生成一条待办任务名，并非任何计算逻辑。",
   "reEvidence": "后端：oa-backend/src/main/java/com/kaidi/oa/domain/Bid.java（字段仅 projectName/bidNo/tenderee/projectType/controlPrice/bidAmount/deposit/bidMethod/status/bidDate/openDate/opportunityId/projectId/owner/orgUnit/createdAt——无 sealHash、无报价明细、无丢标原因、无标书文档）；oa-backend/src/main/java/com/kaidi/oa/web/BidController.java（chainWinBid 第158-192行只建 Project+Contract 草稿，无中标通知书归档、无 archive 调用、无 seal 联动）；oa-backend/src/main/java/com/kaidi/oa/web/BidDecisionController.java:59（\"报价测算（关联成本测算）\"仅为 TASK_TEMPLATE 静态字符串生成待办，非计算）；oa-backend/src/main/java/com/kaidi/oa/domain/BidDecision.java、BidTask.java、BidBond.java、BidDeposit.java（全字段已列，均无相关特性）。前端：ofbiz-framework/plugins/modern-ui/app/src/oa/api/bids.ts（Bid 接口无对应字段、无对应端点）；同目录 oa/pages/bidding/board.vue、ledger.vue（仅看板+台账 CRUD/详情，无协同/批注/版本/通知书/案例库/成本测算明细）。grep 全库 sealHash/标书协同/版本批注/丢标案例/直接费间接费利润税金在 bid 上下文均零命中（仅命中 DataSeeder/MarketQualification/foreign-cert 模板/kaidiDeptView 等无关文本）；Seal/SealUse 域 grep bidId/标书/投标 为空。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "4. 客户关系管理(CRM)",
   "verdict": "PARTIAL",
   "gap": "客户主档结构化字段(信用等级/营业执照/关键联系人生日职务偏好)；分级驱动合同审批权限联动；交付/验收事件自动触发满意度问卷；客户流失(6月无互动)自动预警扫描。",
   "severity": "high",
   "evidence": "维持初判。已建比初判更全：CustomerCreditController 真授信分级(待审/生效/冻结/已过期状态机+/utilization 按合同应收实时算占用率+/alerts/expiry 授信到期预警)；CustomerComplaintController 投诉状态机+满意度回访打分+/satisfaction/summary；CustomerVisitController 互动记录。但初判缺口属实：(a) Customer.java 仅 name/type/contact/phone/address/status 六字段，缺信用等级/A-B-C-D分级/营业执照/关键联系人(生日/职务/偏好)，分级靠旁挂 CustomerCredit 单表，ContractController 创建/审批不读 CustomerCredit 等级(无分级驱动审批权限联动)；(b) 满意度未在项目交付/验收后自动触发——SurveyController 手工建问卷+vote，TriggerRuleEngine 项目验收(:332)只置 phase=验收+建项目档案不触发问卷，Complaint 满意度是投诉关闭回访分非交付触发；(c) 客户流失预警(超6月无互动/新合同)完全缺失(grep 流失/churn/lastContact 无客户侧命中，无 lastContact 扫描任务)。",
   "survives": true,
   "reNote": "缺口属实（PARTIAL 判定成立）。我尽力推翻但代码只支持其中一小部分，四项具体增强中三项确缺、一项仅半实现：\n\n(1) 客户主档结构化字段 = 半实现。信用等级(grade A/B/C/D)确有，落在独立实体 CustomerCredit；但「营业执照」「关键联系人生日/职务/偏好」在任何客户实体与前端页面都不存在。基础 Customer 实体只有 name/type/contact/phone/address/status 六个字段；前端 customer.vue 也只有联系人等基本列。全树 grep license/营业执照/birthday/生日/职务/偏好/preference 在 Customer 域零命中（license 命中全在 Supplier/Seal/SoftwareLicense 等其他模块）。\n\n(2) 分级驱动合同审批权限联动 = 未实现。CustomerCredit 在全树仅被自己的 domain/repository/controller 引用，ContractController 对 credit/grade/信用 零引用；全树搜「审批权限」与 grade↔approval 联动零命中。CustomerCreditController 只做授信档案 CRUD/状态流转/占用率/到期预警，与合同审批权限无任何挂钩。\n\n(3) 交付/验收事件自动触发满意度问卷 = 未实现。TriggerRuleEngine 确实在表单办结时识别「验收/交付/竣工/结项」，但下游动作只是把 project.phase 置为「验收」并自动在档案库生成一条项目档案记录，不创建任何 Survey/满意度。满意度仅作为投诉关闭时人工回填的回访分(1-5)存在于 CustomerComplaintController，属投诉驱动而非交付/验收事件驱动。\n\n(4) 客户流失(6月无互动)自动预警扫描 = 未实现。唯一的定时扫描 AlertScheduler 只扫人员证照到期(refreshCertExpiry)和在办表单超时滞留(scanOvertimeInstances)，完全不碰 customer/visit。CustomerVisit/CustomerComplaint/Customer 三个 Repository 在 task/ 与 service/ 中仅被 FullTextSearchService（搜索建索引）引用，无任何调度器/服务按 last-interaction/180天/半年做流失扫描。grep churn 命中 AlertScheduler 是注释「neither duplicate nor churn rows」的假阳性。",
   "reEvidence": "已实现部分：oa-backend/.../domain/CustomerCredit.java(grade A/B/C/D 信用分级) + web/CustomerCreditController.java(授信CRUD/状态流转/utilization/alerts/expiry)；web/CustomerComplaintController.java(投诉状态机 + close 时人工回填 satisfaction 1-5 + GET /satisfaction/summary 按分类汇总)；web/CustomerVisitController.java(拜访纪要 + GET /reminders 跟进提醒)。\n\n缺失证据：\n- 结构化字段缺：domain/Customer.java 仅 name/type/contact/phone/address/status；全树 grep -i license/营业执照/birthday/生日/职务/偏好/preference 在 Customer 域零命中；前端 oa/pages/masterdata/customer.vue 仅联系人等基本列，crm.ts 无相关字段。\n- 分级驱动审批缺：grep CustomerCredit 全树仅 domain/repository/web 三个自身文件；web/ContractController.java grep credit/grade/信用 零命中；全树「审批权限」零命中。\n- 交付触发问卷缺：service/TriggerRuleEngine.java:330-367 验收/竣工办结只置 project.phase=验收 并生成档案记录；全树 grep (deliver|验收|交付)∩(survey|满意度|问卷) 无自动建问卷。\n- 流失扫描缺：task/AlertScheduler.java 只扫 PersonnelCert(refreshCertExpiry)与 FormInstance(scanOvertimeInstances)；CustomerVisitRepository/CustomerComplaintRepository/CustomerRepository 在 task/ 与 service/ 仅被 FullTextSearchService 引用；全树无 180天/半年/lastVisit 客户无互动扫描（180/6月命中全为证照/资质到期预警）。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "5. 客户跟进与转化(AI)",
   "verdict": "LOGIC_GAP",
   "gap": "缺按行业/需求生成跟进话术+报价单初稿的CRM内AI编排；缺AI整理沟通记录提炼需求/异议点的专用功能(visit不接AI)。",
   "severity": "med",
   "evidence": "维持初判。前端 crm/visit.vue、opportunity.vue、marketintel.vue 均无 /api/oa/ai 引用(全前端AI端点消费者仅 appdev/aiassist.vue 通用页)。无按客户行业/需求自动生成跟进话术/报价单初稿的专用编排——AiService 只有通用 draft 场景(systemFor draft 仅企业办公写作助手通用提示)，无CRM行业话术/报价单初稿封装，无控制器把客户/商机数据喂入AI；无AI自动整理客户沟通记录提炼需求/异议点的专用功能——CustomerVisitController 拜访记录不接 summarize。均需走裸通用 ai 端点，无场景落地。",
   "survives": true,
   "reNote": "缺口属实(部分基础设施存在但缺口的核心断言成立)。我尽力推翻但推翻不掉。存在的是一个通用的、独立的、纯手工复制粘贴的\"AI助手\"页(appdev/aiassist.vue),底层AiService确实接了真LLM(Anthropic Messages API,含未配Key优雅降级)并暴露 /ai/draft(话术起草) /ai/summarize(提炼) /ai/classify(情感)。但缺口断言的三件具体事在代码里全部不成立:(1)\"CRM内AI编排\"——没有任何CRM页面(opportunity.vue/visit.vue/complaint.vue)import或调用 /ai/* ;前端全仓只有 aiassist.vue 一处调用 /ai/ 端点。opportunity.vue 的 addFollow、visit.vue 的 save 都是纯CRUD,不触AI。后端 AiService 除 AiController 外没有注入到任何控制器,不存在一个\"读客户行业/商机/沟通记录→自动编排prompt→生成跟进话术\"的编排端点。(2)\"报价单初稿\"——PriceItemController 是纯CRUD,全后端只有 AiController 引用 AiService,没有任何AI驱动的报价单初稿生成。(3)\"AI整理沟通记录提炼需求/异议点的专用功能(visit不接AI)\"——visit/followup 记录无任何AI入口;只有通用 /ai/summarize 需用户手工把文本粘进文本框,没有面向沟通记录、按需求/异议点结构化输出的专用功能。通用助手页≠缺口所指的\"CRM内AI编排\"与\"专用功能\",缺口正是精确地把这层区分点出来,代码予以证实。",
   "reEvidence": "前端:ofbiz-framework/plugins/modern-ui/app/src/oa/pages/crm/visit.vue(save 纯CRUD,无AI), .../crm/opportunity.vue:97-114(addFollow 纯CRUD,无AI), .../appdev/aiassist.vue(唯一调用 /ai/* 的页面,通用手工文本框);grep \"/ai/\" 全 src 仅命中 aiassist.vue。后端:web/AiController.java(/ai/complete|draft|classify|summarize|risk) 与 service/AiService.java(Anthropic Messages API+降级)构成通用AI层;但 grep \"AiService\" 仅命中 AiProperties/AiController/AiService 三文件——AiService 未注入任何业务控制器。web/OpportunityFollowupController.java(纯CRUD,无AI/话术/报价)、web/CustomerVisitController.java、web/PriceItemController.java(纯CRUD,无AI报价单初稿)。domain/OpportunityFollowup.java 无任何AI/话术/异议字段。结论:CRM内AI编排、报价单初稿生成、沟通记录提炼需求/异议点专用功能均未实现,仅有独立通用AI助手。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "6. 经营合同管理",
   "verdict": "PARTIAL",
   "gap": "经营合同原生挂WorkflowService多节点审批链(经营部→法务→财务→分管→总经理)；里程碑按应付款/应开票日自动提醒端点；合同签订自动推送资料室归档联动。",
   "severity": "high",
   "evidence": "维持初判。已建比初判更全：ContractController 有 draft-from-template 起草、create-sub 分包派生(分包不超总包成本控制)、EsignController 电子签/外部盖章流水、ClauseCompareController 条款比对、TriggerRuleEngine 合同生效后链式自动生成待用印单(chainCreateSealUse)。但初判缺口属实：(a) 经营合同审批未走指定链(经营部→法务→财务→分管领导→总经理)——ContractController.status 手填普通字段(草稿/履约中/已结算/已终止/已生效)，update() 直接 setStatus 不调 WorkflowService；合同生效只能靠手工另建合同会签审批单 FormInstance 走通用引擎(ruleEffectivateContract:248)，经营合同实体本身未原生挂多节点审批链；(b) 合同执行节点自动提醒(应付款日/应开票日)缺失——ContractMilestoneController 仅 list+create 两端点，无 reminder/overdue/upcoming，AlertController 只对已手工置逾期的里程碑报警；(c) 合同签订后自动推送资料室归档未联动——TriggerRuleEngine Archive 自动创建只对项目归档(:365)，合同生效链只到用印单。",
   "survives": true,
   "reNote": "PARTIAL 判定属实——三项里只有第1项已实现，第2、3项确实缺失。\n\n(1) 多节点审批链【已实现】：经营合同走通用 WorkflowService 状态机审批，链路由 FormTemplate 的 flow.nodes JSON 定义。seed-templates/proj-exec.json 的「项目成本合同会签审批单」就是多节点审批链(审批节点串：总公司成本会计→分公司成本会计→法人→集团成本会计→集团小公司财务负责人，外加 法务部经理/经营部/财务部负责人 等知会节点)；staff-fin.json 的「总部合同审批表单」链：发起者部门主管→董事长→CEO(信息中心/档案室 知会)。WorkflowService.java 是逐节点推进的通用引擎(submit→advance 同意 nodeIndex+1→末节点后置已办结)。所以\"经营合同挂 WorkflowService 多节点审批链\"这一项成立——只是节点标签并非字面的「经营部→法务→财务→分管→总经理」，而是更丰富/不同的等价链。\n\n(2) 里程碑按应付款/应开票日自动提醒端点【缺失】：domain/ContractMilestone.java 仅有 dueDate/amount/status 三个业务字段，没有独立的「应付款日」「应开票日」字段。唯一涉及里程碑的预警是 AlertController.aggregate() 第129-137行，它只在 m.getStatus()==\"逾期\"(人工置位)时产出一条「履约预警」，并不像 ArchiveBoardController/BidDepositController 那样按日期窗口(daysTo<=7 紧急/<=15 临近)自动算提醒。没有任何按应付款日/应开票日计算的里程碑提醒端点(/due-soon /reminders /upcoming 等均无)。\n\n(3) 合同签订自动推送资料室归档联动【缺失】：TriggerRuleEngine.java 里合同办结的链式联动是 ruleEffectivateContract→合同置「已生效」→chainCreateSealUse(自动生成「待用印」用印单)，下游是用章中心，不是档案库。自动建档案记录的 chainArchiveProject(ruleKey=project.toArchive)是由「项目验收/竣工」触发(ruleAcceptProject)，不是合同签订触发；不存在 contract.toArchive 联动。表单链里虽有「档案室/集团公司资料员」节点，但那只是审批流内的被动「知会」抄送，并不会从合同自动生成 Archive 台账记录。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/web/ContractMilestoneController.java(仅 list/create，无提醒端点); oa-backend/src/main/java/com/kaidi/oa/domain/ContractMilestone.java:24-32(仅 contractId/name/dueDate/amount/status，无应付款日/应开票日); oa-backend/src/main/java/com/kaidi/oa/web/AlertController.java:129-137(里程碑仅按 status==\"逾期\" 出预警，非按日期窗口); oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java:248-303(合同生效→用印，无归档)、:332-375(归档 chainArchiveProject 由项目验收触发，ruleKey=project.toArchive); oa-backend/src/main/resources/seed-templates/proj-exec.json(项目成本合同会签审批单 多节点审批链); oa-backend/src/main/resources/seed-templates/staff-fin.json(总部合同审批表单 链); oa-backend/src/main/java/com/kaidi/oa/service/WorkflowService.java(通用逐节点审批引擎)"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "8. 经营数据分析与报表",
   "verdict": "PARTIAL",
   "gap": "专用投标分析(丢标原因/投入产出比/按行业-报价区间中标率分布)；客户分析(贡献度毛利/流失率/满意度趋势)；合同分析(逾期未回款/即将到期质保金/变更统计)；经营业绩考核自动评分对接绩效。",
   "severity": "med",
   "evidence": "维持初判。已建比初判更全：BusinessBiController /reports/business-overview 跨模块经营总览(含 BiddingStat 整体winRate、ContractStat 金额/已付/已开票)；BranchPnlController /board 区域经营看板按机构算新签合同额/回款额/中标率/费效比/损益(部分覆盖按区域)。但初判缺口属实：(a) 投标分析报表——biddingStat(:264)只产出整体winRate，无丢标原因统计(Bid 无 loseReason)、无投入产出比、无按行业/报价区间中标率分布(BranchPnl 仅 region 维度)；(b) 客户分析报表(贡献度毛利/流失率/满意度趋势)无专用聚合(grep 无市场侧命中)；(c) 合同分析报表(逾期未回款/即将到期质保金/变更统计)无专用端点——contractStat 只汇总金额，AlertController 仅对手工置逾期里程碑报警；(d) 经营业绩考核自动评分对接绩效未见(grep 业绩考核/考核得分/绩效评分仅 Culture 模块命中)。",
   "survives": true,
   "reNote": "缺口属实(PARTIAL正确)。市场部/经营部「经营数据分析与报表」存在通用聚合，但描述里的四项专用分析均未实现。已建的只是分散的通用/操作型能力：(1)BusinessBiController.biddingStat() 只产单一整体中标率；BranchPnlController 产各分公司中标率(bidWon/bidTotal)；bidding/board.vue 产中标率+按状态分布——三者都没有丢标原因分析、投入产出比(ROI)、也没有\"按行业×报价区间\"的中标率分布。(2)客户侧：CustomerComplaintController 有 /satisfaction/summary(按投诉分类的解决率+平均满意度快照，非趋势)，customercredit.vue 是授信管理，design/bi.vue 的毛利是设计研究中心项目盈亏(合同额−人工成本，属另一域)——没有客户贡献度毛利、流失率、满意度趋势这套客户分析。(3)合同侧：ContractMilestoneController 有里程碑状态(待履约/已完成/逾期)及\"质保到期\"里程碑类型，ContractChangeController/changes.vue 是变更台账(CRUD)，cockpit 仅显示 overdueMilestones 计数——没有\"逾期未回款\"应收分析、没有\"即将到期质保金\"专项、没有\"变更统计\"聚合分析。(4)经营业绩考核自动评分对接绩效：全后端唯一的\"自动评分\"是 CultureAssessmentController./score(项目文化考核)，与经营业绩/绩效无关；不存在经营业绩考核自动评分对接绩效。结论：四项专用分析都缺，PARTIAL 判定成立。",
   "reEvidence": "后端 BusinessBiController.java biddingStat() 仅 winRate=wonCount*100/decided(单值)；BranchPnlController.java:132 winRate=bidWon*100/bidTotal(只按机构，无行业/报价区间维度)；bidding/board.vue 注释\"投标规模、中标率、按状态分布\"。客户分析仅 CustomerComplaintController.java:208 /satisfaction/summary(分类快照非趋势)，customercredit.vue=授信管理，design/bi.vue 毛利=设计中心项目盈亏。合同分析仅 ContractMilestoneController(里程碑状态/质保到期类型) + ContractChangeController/changes.vue(变更台账CRUD)，无逾期未回款/即将到期质保金/变更统计专项。自动评分仅 CultureAssessmentController.java:28 /score(项目文化考核)。活体探测(127.0.0.1:8091, admin token)：/reports/bid-analysis、/reports/customer-analysis、/reports/contract-analysis、/reports/performance-score 全部 404；/bids/analysis、/bid-decisions/analysis 返回 400(被当作{id}路径变量，证明无该分析端点)。business-overview 实跑只回 {bidCount:16,wonCount:10,winRate:76}。全后端 grep \"经营业绩|业绩考核|自动评分\"(经营语境)无命中。"
  },
  {
   "area": "市场部 / 经营部/市场部 / 经营部（对接办事处分公司、市场开拓、招投标）",
   "module": "10. 协同与接口要求",
   "verdict": "PARTIAL",
   "gap": "报价自动取成本测算；法务投标合规审核流；项目进度反向驱动合同状态；申报服务部取经营业绩接口；合同/投标/中标通知书自动归档资料室。",
   "severity": "med",
   "evidence": "维持初判。已建部分联动属实：财务接口完整(TriggerRuleEngine 付款/发票回写合同 paidAmount/invoicedAmount，PaymentService.confirmPay)，MarketPlanService 经营计划自动从合同台账取新签合同额/回款额。但初判缺口属实：(a) 报价自动取成本测算未实现——Bid.bidAmount 手填，BidDecision 报价测算仅任务模板字符串，无拉取直接费/间接费/利润/税金；(b) 法务投标合规审核未接——grep 投标合规/合规性审核仅命中 BidDecisionController 的 legalOpinion 一个决策会意见字段，无独立合规审核流；(c) 项目进度(工期完成比例)反向影响合同状态未见——grep 工期完成/进度→合同状态仅命中 CslDashboard，ContractController.status 不被项目进度驱动；(d) 申报服务部取经营业绩接口未见——MarketQualification 有业绩案例子库但 Declaration 侧无主动取经营业绩的跨模块调用；(e) 合同/投标/中标通知书自动归档资料室未见(Archive 自动创建只对项目归档)。",
   "survives": true,
   "reNote": "缺口属实，PARTIAL 判定成立。该条描述含 5 个子接口，逐一彻查后只有 1 个真正实现，其余 4 个缺失或仅半成品，故\"部分实现\"的缺口成立，无法推翻。\n\n1) 报价自动取成本测算——未实现。投标报价(bidAmount)只能由\"商机金额\"自动带出(OpportunityController.convertBid:179-180 用 o.getAmount() 同时灌 bidAmount/controlPrice)，与\"成本测算\"无任何打通。StandardCostController(标准成本料/工/费台账)、PriceItemController(人材机价格库)都是独立台账，没有任何代码把成本测算结果回灌进投标报价。BidDecisionController 只存一段自由文本 costOpinion，并生成一条手工任务\"报价测算（关联成本测算）\"，没有数值自动流转。\n\n2) 法务投标合规审核流——半成品。BidDecisionController 投标决策会有 legalOpinion 字段(技术/商务/成本/法务四方意见)，但只是单条记录上存一段法务意见，不是路由到法务的审核\"流\"(无 WorkflowService 流转、无合规闸/审批态)。\n\n3) 项目进度反向驱动合同状态——未实现。ProjectController.advance 推进到\"验收\"时只生成收入确认凭证(只读取 contract.amount)，从不写 contract.setStatus(...)；ContractMilestoneController 不回写合同状态；无任何 service 把项目进度/里程碑完成→合同状态。合同状态只由客户端请求或办结链(合同→已生效)设置。\n\n4) 申报服务部取经营业绩接口——已实现(唯一成立的子项)。QualDeclarationController.gap (GET /{id}/gap) 从项目库(已完工/竣工/验收项目)取经营业绩、从 HR 证件库取注册人员，算缺口；活体验证返回 matchedPerformances:9 + matchedProjectNames。另 MarketQualificationController.match 也聚合业绩案例。\n\n5) 合同/投标/中标通知书自动归档资料室——基本未实现。全库唯一的自动归档是 TriggerRuleEngine.chainArchiveProject，仅在\"项目验收\"时触发、sourceType=\"项目\"；没有由合同签订/生效、投标递交、中标通知书触发的自动归档。MarketQualification 里\"中标通知书\"只是手工录入的业绩案例类别。\n\n5 项里 4 项缺失或半成品，PARTIAL 判定正确。",
   "reEvidence": "关键证据(均为绝对路径):\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java — 联动引擎只有 项目验收→档案(chainArchiveProject:355-378, sourceType=\"项目\")、合同生效→用印、商机/中标→项目合同等链；无 合同/投标/中标通知书自动归档，无成本测算→报价，无进度→合同状态。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/OpportunityController.java:179-180 — convertBid 用商机金额 o.getAmount() 灌 bidAmount/controlPrice(报价来自商机，非成本测算)。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/StandardCostController.java、/web/PriceItemController.java — 成本测算/价格库为独立台账，无任何向投标报价的写出。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/BidDecisionController.java:85-132 — legalOpinion/costOpinion 仅为决策会上的存档意见字段，非审核流；TASK_TEMPLATE 含\"报价测算（关联成本测算）\"为手工任务。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ProjectController.java:97-176 — advance 到验收只 generateAcceptanceVoucher(只读 contract.amount)，全程无 contract.setStatus。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ContractMilestoneController.java — 里程碑独立，无回写合同状态。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/QualDeclarationController.java:308-375 — gap 端点取项目库业绩+HR人员证件(唯一真正实现的\"取经营业绩接口\")。\n- 活体 http://127.0.0.1:8091 GET /api/oa/qual-declarations/1/gap 返回 {\"matchedPerformances\":9,\"matchedProjectNames\":[\"靖州供水…\",\"岳阳城乡污水…\"…]} 证实业绩取数生效。"
  },
  {
   "area": "市场部 / 办事处/办事处",
   "module": "5. 费用与预算控制",
   "verdict": "PARTIAL",
   "gap": "无备用金/借款/核销闭环实体与端点：无法做员工预借款、备用金台账、借支后凭报销冲销核销的资金周转管理。报销与商机的关联为软外键(opportunityId 可空、无引用完整性约束)，非强约束归集。",
   "severity": "med",
   "evidence": "尽力反驳后维持初判。费用/预算控制主体确实健全：MarketExpenseController(/api/oa/market-expenses) 全状态机 草稿→待审批→已批准→已报销，submit 命中预算算超预算预警、reimburse 回写预算已用额度(MarketBudgetService 驱动)；MarketBudget/MarketExpense/ExpenseClaim/MarketBudgetController 齐备，category 与预算科目同口径(差旅/招待/办公/市场活动)。但「备用金管理(借款/核销)」确实缺失：对 web/domain/service/resources/前端 全树 grep 备用金|imprest|petty|预借|周转金|借款单 均无对应实体或端点。误命中均为无关项——'借款/还款'全部属于 FinancingController/Financing/RepaymentPlan(公司对外融资，非员工备用金)；'备用金'唯一出现在 DataSeeder.java:2865 voucher('提现备用金') 一条凭证描述字符串，非备用金管理功能。报销关联确为软字段：MarketExpense.opportunityId / projectId 均为可空 Long、无 FK 强约束(domain/MarketExpense.java:41-42)，ExpenseClaim 仅有 projectId 无商机字段。",
   "survives": true,
   "reNote": "缺口属实。市场部/办事处「费用与预算控制」链只有费用报销+预算台账，没有备用金/借款/核销闭环。涉及实体：MarketExpense(market_expense)、MarketBudget(market_budget)、BranchBudgetLine(branch_budget_line)、BranchAsset(branch_asset)、BrandExpense(brand_expense)。MarketExpense 状态机仅 草稿→待审批→已批准→已报销/已驳回，控制器端点仅 create/update/submit/approve/reimburse/delete——无「已借款/已核销」态、无预借款发放、无备用金台账、无借支冲销核销。reimburse 仅回写预算 usedAmount，不存在预支-报销冲抵逻辑。全仓 grep 备用金|借款|借支|预借|核销|冲销|imprest|advance 在所有 branch/market/brand 控制器与实体中零命中；唯一相关命中 RepaymentPlan/Financing/Settlement 属金融办融资域(融资本息还款)，与员工预借款无关。商机关联确为软外键。",
   "reEvidence": "无备用金/借款/核销实体与端点：MarketExpenseController.java(端点仅 list/get/create/submit/approve/reimburse/delete，状态机 草稿→待审批→已批准→已报销，无借支/核销/冲销动作)；domain/MarketExpense.java、domain/MarketBudget.java、domain/BranchBudgetLine.java、domain/BranchAsset.java、domain/BrandExpense.java 均无 advance/loan/writeoff 字段或状态。reimburse 仅回写 MarketBudget.usedAmount(无冲抵)。软外键证据：domain/MarketExpense.java:42 `private Long opportunityId;` 为裸 Long，无 @ManyToOne/@JoinColumn/ForeignKey；MarketExpenseController.java:85 create 直接 e.setOpportunityId(req.opportunityId()) 不校验商机存在性。全仓 grep 备用金|借款|借支|预借|核销|冲销|imprest|advance 在 web/Branch*、web/Market*、web/Brand* 与对应 domain 中零命中；RepaymentPlan/Financing/Settlement 属金融办融资域(domain/Financing.java 注释:银行贷款/融资租赁；domain/RepaymentPlan.java:还本付息计划)，非员工备用金借款。"
  },
  {
   "area": "市场部 / 办事处/办事处",
   "module": "7. 协同办公与流程审批",
   "verdict": "LOGIC_GAP",
   "gap": "公文发布后无签收/已读回执机制：办事处无法对某条公文执行'签收确认'，总部也无法查询某公文哪些机构/人已签收(只能发不能确认)。日报与周报无类型字段区分，靠 WorkPlan.period 文本约定，无法按日报/周报维度强制区分、过滤或考核。",
   "severity": "med",
   "evidence": "尽力反驳后维持初判。公文「签收」逻辑确实缺失：domain/Announcement.java 全字段仅 id/category(新闻|公告)/title/content/author/top/publishedAt/publishRange，无 readBy/ack/签收回执/已读记录字段；AnnouncementController(/api/oa/announcements) 仅 list/get/create(POST)/update(PUT)/delete，无任何 /ack /sign /read /receipt 端点——办事处能收到公文但系统无法记录'是否已签收/谁已签收'。全树 grep 签收|签阅|readReceipt|readBy|ackBy|confirmRead 仅命中无关项(SewageSludgeRecord 污泥外运签收、DataSeeder 安全隐患文本'签收回执')。日报vs周报无类型区分：domain/WorkPlan.java period 为自由文本(注释示例 本周/本月/本季)，无 reportType/kind/日报|周报 枚举或字段；无 Report.java 实体(仅 ReportController 做跨模块实时聚合、ReportDefinition 报表定义)。全树 日报|周报 命中均无关(MealOrderController'当日报餐'指报餐份数、SewageProcessRunController'工艺日报'指水量水质能耗聚合台账)。",
   "survives": true,
   "reNote": "缺口属实，两半均成立，无法推翻。【第一半：公文签收/已读回执缺失】确认缺失。发布实体 Announcement.java 字段仅 category/title/content/author/top/publishedAt/publishRange，无任何签收/已读/回执字段。AnnouncementController.java 仅有 GET(列表/详情)、POST(创建)、PUT(编辑)、DELETE(撤回)，无\"签收确认\"写接口，也无\"某公文哪些机构/人已签收\"查询接口——只能发不能确认，与缺口描述完全一致。后端全库无\"公文\"实体，无 AnnouncementReceipt/ReadRecord/readBy 之类已读跟踪表；CollabDoc/Document/Message 控制器同样无 签收/回执/已读未读 机制。全库唯一的\"签收\"是 SewageSludgeRecord 污泥外运联单签收(状态机+签收时间)，与公文/公告回执无关。【第二半：日报/周报无类型字段】确认缺失。WorkPlan.java 仅有自由文本 period 字段(注释\"本周/本月/本季\")与 status，无 reportType/planType/类型枚举字段。WorkPlanController 的 create/update 把 period 当任意字符串接收，无类型约束、无日报/周报维度强制区分。前端 goal/plan.vue 第40-52行代码注释自证缺口所述\"文本约定\"绕法：明写\"后端 WorkPlan 不单独存类型，这里从 period/标题派生\"，靠 text.includes('日报')/正则字符串匹配判型，新建时把 [日报] 前缀 tag 写进 period 落库回读命中。纯客户端字符串约定，服务端无任何强制区分/过滤/考核维度。",
   "reEvidence": "后端: 1) domain/Announcement.java(全文105行)字段仅 category,title,content,author,top,publishedAt,publishRange，零签收/已读字段。2) web/AnnouncementController.java(全文117行)仅 list/get/create(POST)/update(PUT)/delete，无签收确认接口、无已读查询接口。3) domain/WorkPlan.java(全文90行)仅 title/owner/ownerId/period/status/content，period 自由文本，无类型字段。4) web/WorkPlanController.java create/update 接收 period 任意串(L111 默认\"本周\")，无类型枚举/约束。5) grep 全库无 公文 实体、无 AnnouncementReceipt/readBy/read-receipt；唯一\"签收\"在 domain/SewageSludgeRecord.java(污泥外运)与本缺口无关。前端自证: 6) ofbiz-framework/plugins/modern-ui/app/src/oa/pages/goal/plan.vue L40-52: L41\"// 后端 WorkPlan 不单独存类型，这里从 period/标题派生\" L42\"// 新建时把类型写进 period 前缀 tag（如 [日报] ...），落库后回读即可命中。\" L46-52 planTypeOf() 用 text.includes('日报'/'周报'/'月报') 派生类型; L182 taggedPeriod=`[${form.value.planType}]...` 把类型当前缀塞进 period。这正是缺口所称\"靠 WorkPlan.period 文本约定，无法按日报/周报维度强制区分\"的实锤。"
  },
  {
   "area": "市场部 / 分公司/分公司",
   "module": "8. 经营数据分析",
   "verdict": "PARTIAL",
   "gap": "确凿缺口仍在:(1)现金流量表全 Java 后端 0 命中——仅 static/generated/pages/accounting__CashFlowStatement*.json 是已弃用 OFBiz 旧屏的页面定义元数据(legacy-screen,无 Java 控制器,grep -rln Java 层 NONE),非活 API;(2)资产负债表同理仅 accounting__BalanceSheet*.json 旧屏残留,无 Java 实现;(3)客户贡献度无专门按客户营收/毛利聚合排名的接口(只有商机维度报表+授信占用风控);(4)成本分析(项目毛利)散在 ProjectCostControlController(EVA/CPI/EAC/EAC完工预测)未汇入分公司看板;(5)经营预测实际比初判更弱——Opportunity.probability 仅作存储字段与报表度量,无任何控制器做漏斗加权或下季度合同额/回款的预测计算(FundPlanController 的 forecastBalance=期初+流入-流出 是资金计划算术,非合同/回款预测模型)。",
   "severity": "med",
   "evidence": "维持 PARTIAL,反驳后多数子项仍缺。已落地部分确认:损益表(利润表)+区域经营看板真实存在于 web/BranchPnlController.java——GET /board 以 OrgBranch 每机构为维度聚合新签合同额/回款额/中标率/费用执行率/费效比(每万元合同额经营费用)/利润(收入−成本−费用),GET /statement/{branchId} 出单分公司损益表(逐科目预算vs实际),活体 /api/oa/branch-pnl/board 返回结构化 code:0。客户贡献度弱可辩:web/ReportDefinitionController.java 的 opportunity 报表源含 customerName 维度+amount/probability 度量(可配置透视出按客户聚合),CustomerCreditController GET /utilization 按客户名聚合合同应收占用——但均非'按客户营收/利润贡献排名'的专用接口。",
   "survives": true,
   "reNote": "缺口属实，PARTIAL 判定准确。该模块\"经营数据分析\"确有部分 Java 落地（BranchPnlController 分公司损益看板、BusinessBiController 跨模块经营 BI、FinanceDashboardController 财务多维看板），但 claim 列出的 5 条具体缺口逐条复核全部成立，无法推翻：(1)现金流量表——com/kaidi/oa 全层 0 命中，仅 static/generated/pages/accounting__CashFlowStatement*.json 旧屏元数据 + ofbiz-framework 下 groovy/.class，非活 API；(2)资产负债表同理仅 accounting__BalanceSheet*.json 旧屏残留，无 Java 实现；(3)客户贡献度无按客户营收/毛利排名的接口——唯一客户级聚合是 CustomerCreditController.utilization（合同额−已回款=应收/授信占用，按占用率排序，是风控视图非贡献度排名），grep byCustomer/客户贡献/客户营收 全空；(4)成本/项目毛利散在 ProjectCostControlController（EVA/CPI/SPI/EAC + /project-summary 成本看板）未汇入分公司看板——BranchPnlController 的\"成本\"取 contract.invoicedAmount 占位（其 javadoc 自陈\"无独立成本归集表时的过渡\"），并未引用 ProjectCostControl 毛利；(5)经营预测确实更弱——Opportunity.probability 仅作存储字段+报表度量，ReportDefinitionController 聚合只支持 count/sum（第349行\"measure must be count or sum\"），连\"金额×概率\"加权漏斗都算不出，无任何控制器做漏斗加权或下季合同额/回款预测；FundPlanController.applyForecast 就是期初+计划流入−计划流出的资金计划算术（第119-125行），非合同/回款预测模型；MarketIntelController 的\"趋势预测\"只是 javadoc 注释非真算法。",
   "reEvidence": "现金流/资负仅旧屏:oa-backend/src/main/resources/static/generated/pages/accounting__CashFlowStatement--e5b169a.json、accounting__BalanceSheet--afcac1cd.json(+Comparative/Pdf/Csv 变体)与 ofbiz-framework/build/classes/groovy/main/org/apache/ofbiz/accounting/reports/CashFlowStatement.class,BalanceSheet.class;grep cashflow|balancesheet 在 com/kaidi/oa 下 0 命中。客户贡献度缺:web/CustomerCreditController.java:240-280 仅 /utilization 按占用率排序(应收占用=合同额−已回款,风控口径),无营收/毛利排名;grep byCustomer/客户贡献/客户营收 web/*.java 全空。项目毛利未汇入分公司:web/BranchPnlController.java:118 cost=Money.add(cost,ct.getInvoicedAmount())占位,javadoc(第36行)自陈\"履约成本口径占位...无独立成本归集表时的过渡\",未引用 web/ProjectCostControlController.java:396-470 的 EVA/CPI/EAC/project-summary。经营预测弱:web/ReportDefinitionController.java:348-350 \"measure must be count or sum\"(只 count/sum,无加权乘积),probability 仅第198行作 sum 度量;web/FundPlanController.java:119-125 applyForecast=Money.sub(Money.add(opening,planInflow),planOutflow);web/OpportunityController.java 全篇无任何 probability 加权或预测计算。反证(支撑PARTIAL非NONE):web/BranchPnlController.java(分公司损益看板:收入−成本−费用/中标率/费用执行率/费效比)、web/BusinessBiController.java(跨模块经营BI overview)、web/FinanceDashboardController.java(合同/资金/往来/凭证四维看板)均为真活 Java 端点。"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "1. 银行账户与资金池管理",
   "verdict": "PARTIAL",
   "gap": "缺账户余额字段及每日同步、可用/冻结/在途显示、低于备付金预警、资金归集(实时/定时/限额留存上划)与下拨、归集下拨流水与内部往来凭证、银企直连真实余额查询/明细下载/电子付款/回单、账户状态与授权人员字段。",
   "severity": "high",
   "evidence": "BankAccount.java (domain) 字段仅 id/accountName/bankName/accountNo/companySubject/currency/purpose——无 balance/availableBalance/frozenAmount/在途/minReserve/账户状态(正常/冻结/销户)/授权人员。BankAccountController 纯 CRUD,无余额同步/预警接口。grep 备付金/availableBalance/frozenAmount/归集/上划/下拨/sweep 在资金域全部命中 0(归集命中的是 Rd/Sewage 等无关控制器)。资金池为 FundPoolController.java 内存聚合(合同 invoicedAmount - 已付 payment),非真实账户余额;无资金归集/下拨/流水/内部往来凭证自动生成。MockSyncAdapter.java 第26-37行明示 TODO 未实连银企直连,仅标记成功。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口属实，无法推翻。彻查银行账户/资金池/结算相关全部域与控制器，证实该链的核心能力大面积缺失，且代码自身注释明确承认未实做。\n\n1) 账户余额字段 + 可用/冻结/在途显示：BankAccount 实体(domain/BankAccount.java)仅有 accountName/bankName/accountNo/companySubject/currency/purpose 六个纯文本字段——零余额字段。grep 全仓 availableBalance/frozenBalance/inTransitBalance/currentBalance 及中文\"可用余额/冻结余额/在途资金\"在银行账户域内零命中（仅 BrandPlan/BrandProject 预算域有\"可用余额\"，与银行账户无关）。每日余额同步无任何实现。\n\n2) 低于备付金预警：grep \"备付金/限额留存/reserveAmount\" 全仓零命中。\n\n3) 资金归集(实时/定时/限额留存上划)与下拨、归集下拨流水、内部往来凭证：grep \"资金归集/归集上划/资金下拨/fundSweep/fundAllocation/internalTransfer/内部往来凭证/归集凭证/下拨凭证\" 全仓零命中。FundPoolController 只是只读聚合(按 companySubject 把 contract.invoicedAmount 减 payment 已付额算 balance)，根本不是真实账户余额，也无任何归集/下拨写操作。\n\n4) 银企直连(真实余额查询/明细下载/电子付款/回单)：代码自身注释三处明确承认未实做——SettlementController.java:36\"银企直连(余额/明细/支付/回单自动取数)标注为外部对接项，本控制器不实做\"；BankReconciliationController.java:28\"银企直连为外部对接项，先支持手工/导入登记\"；BankReconciliation.java:17\"银企直连自动取数为外部对接项，本表先支持手工/导入登记\"。\n\n5) 账户状态与授权人员字段：grep BankAccount 域内\"账户状态/授权人员/授权人/accountStatus/authorizedPerson\"零命中。\n\n判定 PARTIAL 准确：仅有银行账户主数据 CRUD(BankAccountController) + 资金计划 FundPlan(期初/计划流入流出/预测期末) + 银行对账 BankReconciliation(手工登记差额) + 资金池只读聚合，描述中列举的余额体系/预警/归集下拨/银企直连/账户状态授权人全部缺失。",
   "reEvidence": "domain/BankAccount.java(仅6文本字段,无余额/状态/授权人); web/BankAccountController.java(纯CRUD); web/FundPoolController.java(只读聚合,非真实账户余额); domain/FundPlan.java(计划值非实时余额); domain/BankReconciliation.java:17 + web/BankReconciliationController.java:28 + web/SettlementController.java:36(注释自承银企直连\"不实做/仅手工导入\"); grep全仓 availableBalance/frozenBalance/inTransitBalance/fundSweep/fundAllocation/internalTransfer/reserveAmount/authorizedPerson/accountStatus 及中文\"备付金/资金归集/资金下拨/内部往来凭证/账户状态/授权人员\"在银行账户域内全部零命中"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "2. 付款结算管理",
   "verdict": "PARTIAL",
   "gap": "缺按金额/类型/对象可配置多级审批流(部门→财务→结算中心→资金总监→高管)、会签加签转审、批量付款(工资/供应商/Excel导入+总额预算校验)、支付指令发送(银企直连/网银+成功失败处理中状态+失败重试)、回单自动获取/关联/批量下载打印、代收代扣管理、申请时自动校验预算余额与合同付款条件。",
   "severity": "high",
   "evidence": "Payment.java 实体无 receipt/instruction/payStatus 字段(仅 status=待付/已付/已驳回)。PaymentService.confirmPay 是单步确认(待付→已付+合同回写+自动凭证),非多级会签/加签/转审;grep 审批流程/多级/会签/加签/转审/approvalFlow 在 PaymentController/PaymentService/SettlementController 命中 0。WorkflowService.java 第576-577行仅在通用 tag 分支返回字符串'生成待付付款单',未把 Payment 接入审批引擎。grep 批量付款/代发/代收代扣 全模块命中 0。grep 回单/指令/instruction/receipt 命中的是 SettlementController 文档注释(标注未实做)+FormTemplate 字段名+MockSyncAdapter,无真实支付指令/回单实现。create 时不校验预算余额/合同付款条件。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口判定 PARTIAL 属实，无法推翻。逐项核验付款结算的 7 项能力：仅前 2 项存在，后 5 项确实缺失（多为明文标注的\"外部对接，未实做\"桩）。\n\n已实现(2/7)：①按金额/类型可配置多级审批流——WorkflowService.activeChain/chooseCaseTarget 支持按 dataFields 数值/字符串/AND-OR 复合条件分支，前端有 payment-apply.ts + src-branch/hq/group-small-payment 多链模板；②会签/加签/转审——WorkflowService.advance 的「转交/加签」真改派(closeTasks+addTask+assigneeOverride)，「会签/或签」配额(countersignQuorum/recordVoteAndCheck)及并行审批同步节点。\n\n确实缺失(5/7)：③批量付款(工资/供应商/Excel导入+总额预算校验)——后端前端全域 grep \"批量付款/payroll/Excel/批量支付\" 零命中，PaymentController 仅单条 create/pay/reject；④支付指令发送(银企直连/网银+成功/失败/处理中状态+失败重试)——MockSyncAdapter.sync 是桩(TODO+\"不实连，直接标记成功\")，SettlementController/BankReconciliationController/前端均明文\"银企直连为外部对接项，本控制器不实做\"，无支付指令实体/状态机/重试；⑤回单自动获取/关联/批量下载打印——同属未实做的银企直连桩，仅手工对账登记；⑥代收代扣管理——全域 grep \"代收/代扣/withhold\" 零命中；⑦申请时自动校验预算余额与合同付款条件——PaymentService/Controller 无任何 Budget/预算/付款条件引用，create 仅校验 payeeName 与 amount>0。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/PaymentController.java(仅 create/pay/reject，无批量/无预算校验，L70-105); service/PaymentService.java(create 只置待付，无预算/合同条件校验); web/SettlementController.java L36-39 注释\"银企直连…本控制器不实做\"; web/BankReconciliationController.java L28\"银企直连…为外部对接项\"; service/MockSyncAdapter.java L26-37(sync 桩，TODO\"组报文…查询/推送付款指令与回单\"未实现，仅\"标记成功\"); service/WorkflowService.java(转交/加签 L498-522、会签配额 L1858-1997、条件分支 L1136-1208 —— 仅这两项支撑已实现部分)。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/payment/reconciliation.vue L6\"银企直连自动取数为外部对接项，此处手工/导入登记\"; settlement.vue L309\"银企直连为外部对接项\"。全域 grep 证据: 后端/前端对 批量付款·payroll·Excel导入·代收·代扣 均零命中。"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "3. 收款结算管理",
   "verdict": "PARTIAL",
   "gap": "缺到款认领(待认领池/按合同号发票号付款方模糊匹配/关联应收单)、逾期催收自动化(自动提醒/催款函生成/催收过程记录)、退款处理(走付款审批+关联原收款单)、应收单从销售合同/开票申请自动生成。",
   "severity": "high",
   "evidence": "应收存在于 ArApController.java(ArApItem 应收/应付登记+核销+逾期汇总 /summary),但为手工登记;grep 自动生成应收/应收单/从合同生成 在 web 命中 0,无从销售合同/开票申请自动生成。grep 到款/认领/待认领/claim 在结算域命中 0(认领命中的是 ExpenseClaimController 报销,非到款认领),无银行到款待认领池/模糊匹配建议/关联应收。grep 催收/催款/dunning 命中的是 BidDeposit/Task/Discharge,非应收催收;ArApController.summary 仅静态算 arOverdue,无自动催收提醒/催款函/催收记录。grep 退款/refund 命中的是 BidDeposit/BidBond,无走付款审批关联原收款单的退款。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口属实。判定 PARTIAL 成立：收款结算的\"双人复核工作流\"和\"资金风控\"确有实现(SettlementController + ArApController 应收应付往来/核销/逾期汇总)，但缺口点名的 4 项专有能力在后端 Java 源与前端 payment 页面里均查无实现——\n\n1) 到款认领(待认领池/按合同号发票号付款方模糊匹配/关联应收单)：完全没有。无 Receipt/收款单 domain，Payment 实体是纯出账(payType 仅 进度款/货款/保函/费用报销)。grep 认领|待认领|认领池|模糊匹配 在 Java 源仅命中 NodeAssigneeResolver 的 workflow assignee \"unclaimed\"，与到款认领无关。\n\n2) 逾期催收自动化(自动提醒/催款函生成/催收过程记录)：付款/结算中心内无。唯一的催收代码在 DischargeBillController(排污账单/EHS 域)，是只读的逾期分级(催收/严重/坏账风险)，无催款函生成、无催收过程记录。ArApController.summary() 只算应收逾期合计(只读聚合)，无任何自动化(无 @Scheduled、无提醒、无催款函、无过程台账)；AlertScheduler 里无应收催收逻辑。\n\n3) 退款处理(走付款审批+关联原收款单)：收款侧无。refund 仅存在于 BidDepositController/BidBondController(投标保证金/保证金退还，招投标域)，且非\"走付款审批+关联原收款单\"；因无收款单 domain，也不存在可关联的\"原收款单\"。\n\n4) 应收单从销售合同/开票申请自动生成：未实现。ArApItem 仅能经手工 POST /api/oa/ar-ap-items 创建；无任何 service/trigger 自动生成。TriggerRuleEngine.ruleCreateReceivableInvoice 在\"收款/到账/回款\"办结时自动生成的是一张\"待开\"销项【发票草稿】(Invoice)，而非【应收单】(ArApItem)，且触发源是收款确认表单而非\"销售合同/开票申请\"——与缺口描述的对象与来源都不符。",
   "reEvidence": "关键文件:\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/SettlementController.java (结算单CRUD+双人复核+risk-check，无认领/催收/退款)\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/Payment.java (纯出账实体，无收款/退款概念)\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/PaymentController.java (仅 create/pay/reject，无 refund/claim 端点)\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/ArApController.java (应收应付往来:create/update/writeoff/summary，应收单仅手工POST创建；summary 第184-212行逾期为只读聚合，无催收自动化)\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/TriggerRuleEngine.java 第197-242行 ruleCreateReceivableInvoice：收款办结自动生成的是\"待开\"Invoice发票草稿，非ArApItem应收单\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DischargeBillController.java 第199-223行：唯一的\"逾期催收\"在排污账单(EHS域)，只读分级无催款函/过程记录\n\n否定性证据(grep Java 源):\n- 认领|待认领|认领池|模糊匹配 → 仅 NodeAssigneeResolver(workflow 无关)\n- 催收|催款|催款函|dunning → 仅 DischargeBillController(排污域)\n- 退款|refund → 仅 BidDepositController/BidBondController(招投标保证金域)\n- 应收单|autoGenerate|autoCreate|fromContract|fromInvoice → 0 命中\n- 无 Receipt/收款单 domain；domain 目录无 receipt/collection 实体\n- 前端 src/oa/pages/payment/ 仅 settlement/fundpool/ledger/reconciliation/financing/repayment 等，grep 认领|催收|催款|退款|待认领|模糊匹配 → settlement.vue 0 命中，仅 fundpool.vue 出现\"应收\"(只读聚合监控)"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "4. 内部结算管理",
   "verdict": "LOGIC_GAP",
   "gap": "缺内部往来记账(分子公司交易自动生成应收/应付往来)、内部对账(每月自动对账单+各公司在线确认+差异调整申请)、内部计息(上存活期/占用贷款利率自动计息+自定义利率与计息周期+利息清单/内部费用凭证)、内部结算规则配置(成本价/市场价/协议价计价+按收入/人数/面积分摊)。",
   "severity": "high",
   "evidence": "SettlementController.java 仅有通用结算单(settleType 可取'内部'标签),无内部结算专有逻辑。四子功能全缺:(1)grep 内部往来记账/自动生成应收应付往来 无;(2)grep 内部对账/在线确认/差异调整 在 Settlement 域命中 0(BankReconciliationController 是银行对账非内部对账);(3)grep 计息/interest/利息 在结算域命中 0,命中的 FinancingController/RepaymentPlan 是融资借款的还款本息(principal*monthlyRate*term),与资金池上存/占用资金按活期/贷款利率自动计息无关;(4)grep 协议价/市场价/成本价/分摊/allocation 命中的是 StandardCost/AdminSupply 等,无内部计价与按收入/人数/面积分摊规则。维持 LOGIC_GAP。",
   "survives": true,
   "reNote": "缺口属实。内部结算管理的四项核心能力在前后端均未实现，无法用现有代码推翻。逐项核对：(1) 内部往来记账(分子公司交易自动生成应收/应付往来)——不存在。SettlementController 仅有手工 CRUD + 双人复核，settleType 虽含\"内部\"但无任何\"分子公司交易自动生成 AR/AP\"的联动逻辑；ArApController 是通用应收应付手工登记+手工核销，并无内部交易自动生成。grep\"内部往来记账/自动生成应收/分子公司交易\"零命中(仅 Settlement.java 一行注释把\"内部往来对象\"作为对手方标签)。(2) 内部对账(每月自动对账单+在线确认+差异调整申请)——不存在。仅有 BankReconciliation/reconciliation.vue 的\"银行对账\"(银行余额 vs 账面余额)，不是公司间内部对账，且无每月自动生成对账单、各公司在线确认、差异调整申请流程。(3) 内部计息(上存活期/占用贷款利率自动计息+自定义利率与计息周期+利息清单/内部费用凭证)——完全不存在。grep 计息/上存/占用贷款/活期/存款利率/贷款利率/按月计息/计息周期/利息清单 全部零命中；唯一的 rate 字段是 Financing.rate(对外融资年化利率)，与资金池内部计息无关。(4) 内部结算规则配置(成本价/市场价/协议价计价+按收入/人数/面积分摊)——不存在。grep 协议价/成本价/转移定价/按人数分摊/按面积分摊/按收入分摊 零命中；现有计价仅 DischargeContract 废水处理费计价规则，现有分摊仅 OpsCostAllocationController 按\"计费水量占比\"把环保运营成本分摊到排污企业，二者均非公司间内部转移定价/收入·人数·面积分摊。活体 8091 探测 internal-settlements/intercompany/interest-accrual/settlement-rules/current-account/internal-reconciliations 全部 404。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/SettlementController.java(仅\"内部\"结算类型+双人复核+风控,无往来自动记账/计息), web/ArApController.java(通用AR/AP手工登记+核销,非内部自动生成), web/OpsCostAllocationController.java(按水量占比分摊环保成本,非内部转移定价/收入·人数·面积), domain/BankReconciliation.java(银行对账非内部对账), domain/Settlement.java:40(仅注释提\"内部往来对象\"). 前端: app/src/oa/pages/payment/settlement.vue(只接 /settlements 双人复核), app/src/oa/pages/payment/reconciliation.vue(银行对账). grep 全仓: 计息/上存/占用贷款/活期/interestRate/计息周期/利息清单/内部往来记账/内部对账/协议价/成本价/按人数分摊/按面积分摊 均零命中(domain目录仅 BankReconciliation/Settlement/InternalControlMatrix). 活体: 6 个内部结算相关端点全 404."
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "5. 资金计划与预测",
   "verdict": "PARTIAL",
   "gap": "缺基于历史+销售回款计划+采购付款计划的未来 7/30/90 天资金流入流出与净头寸自动预测、计划执行监控(实际vs计划差异表+偏差阈值预警)、计划外支付强制特殊审批(财务总监+总经理)、分子公司上报后的结算中心汇总平衡逻辑。",
   "severity": "med",
   "evidence": "FundPlanController.java 的 applyForecast 仅单期算术:预测期末=期初+计划流入-计划流出(第120-125行),非基于历史/销售回款计划/采购付款计划的 7/30/90 天卷积预测;grep 净头寸/netPosition/资金预测/资金缺口 全模块命中 0;FundPlan 有 actualInflow/actualOutflow 字段但 grep 差异/偏差/执行监控/计划外/variance 在 FundPlanController 命中 0——无计划vs实际差异表自动生成、无偏差阈值预警、无计划外支付强制特殊审批。各公司上报+汇总平衡为手工 CRUD,无汇总平衡逻辑。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口属实。结算中心确有 FundPlan 域(domain/FundPlan.java + web/FundPlanController.java + repository/FundPlanRepository.java + 前端 payment/fundplan.vue)，但只是「按期间手工登记期初/计划流入/计划流出，后端用一行算术 forecastBalance=期初+计划流入-计划流出」的单期 CRUD 台账，描述里 4 项实质能力全部缺失：\n\n1) 基于历史+销售回款计划+采购付款计划的未来 7/30/90 天流入流出与净头寸自动预测——无。forecastBalance 只是对人工录入的单期金额做加减，没有从历史推算、没有拉取销售回款计划(RepaymentPlan/回款)或采购付款计划、没有 7/30/90 天滚动窗口、没有\"净头寸\"概念。代码里其它\"回款\"逻辑(BizPlan/MarketPlanService/BranchPnlController)都是经营计划 KPI(新签合同额/回款额)，与资金流预测无关。\n\n2) 实际vs计划差异表+偏差阈值预警——无。实体仅有 actualInflow/actualOutflow 供人工填，没有任何计算出的差异(variance)字段、差异表、阈值(threshold)或预警(alert)逻辑(grep 在 FundPlan 相关代码零命中)。\n\n3) 计划外支付强制特殊审批(财务总监+总经理双签)——无。无\"计划外/unplanned/特殊审批\"路由；总经理/总监 命中仅是 NodeAssigneeResolver 里的通用职级关键字兜底，并非针对计划外支付的 CFO+GM 双签规则。FundPlan 在任何 service/trigger/workflow 中零引用。\n\n4) 分子公司上报后结算中心汇总平衡逻辑——无。每条计划有 companySubject 字段，但没有把分子公司上报汇总(consolidate/汇总/平衡)成结算中心平衡视图的接口或服务。\n\n判定 PARTIAL 准确。",
   "reEvidence": "关键证据文件(绝对路径)：\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/FundPlanController.java —— 第119-125行 applyForecast()：forecastBalance = openingBalance + planInflow - planOutflow，仅此一行算术；无 7/30/90/历史/回款计划/付款计划/净头寸/差异/阈值/汇总/计划外审批。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/FundPlan.java —— 字段仅 openingBalance/planInflow/planOutflow/forecastBalance/actualInflow/actualOutflow/status；无差异字段、无阈值字段。\n- /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/repository/FundPlanRepository.java —— 仅 findByStatus/findByPlanType/findByPeriod，无汇总查询。\n- /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/payment/fundplan.vue —— 纯 MasterDataPage CRUD，列只到 forecastBalance；无差异表/预警/汇总/特殊审批 UI。\n\ngrep 验证：\n- `grep -rn \"FundPlan\" service/ seed/` 在 service 与 seed 目录零命中 → FundPlan 未接入任何引擎/触发/联动/种子。\n- FundPlanController/FundPlanRepository 内 grep \"7/30/90|未来.*天|回款计划|付款计划|净头寸|差异|variance|偏差|阈值|threshold|alert|预警\" 全部零命中。\n- \"回款\" 命中均在 BizPlan/MarketPlanService/BranchPnlController(经营计划 KPI，非资金预测)。\n- \"计划外/特殊审批/unplanned\" 在 web/service/domain 零命中；\"总经理/总监\" 仅 NodeAssigneeResolver.java:271-272 通用职级兜底。"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "6. 资金风险控制",
   "verdict": "PARTIAL",
   "gap": "缺付款对象/用途黑白名单、头寸风险预警(实时可用余额低于安全备付金+预测缺口提前预警)、汇率风险(外币余额收支监控/锁汇/远期结售汇套保记录)、合规性检查(黑名单/外汇规定/授权范围)、把 risk-check 强制接入付款创建链路实现拦截/升级审批。",
   "severity": "med",
   "evidence": "SettlementController.riskCheck(/risk-check,第256-304行)仅覆盖 2/5 项:大额支付(>阈值默认100万→高风险)与重复付款(同收款方同金额近7天)。grep 黑名单/白名单/blacklist 在付款用途命中的是 AuthInterceptor/Qual 等无关项,无付款对象/用途黑白名单。grep 头寸/净头寸/备付金 命中 0,头寸风险预警依赖账户余额而 BankAccount 无余额字段。grep 汇率/锁汇/套保/远期结售汇 命中的是 ProductionReport,无外币汇率风险与套保记录。无合规性检查(收款账户黑名单/外汇规定/授权范围)。/risk-check 文档自述'不落库纯只读分析',PaymentController.create 不调用 risk-check,未在付款链路强制拦截/升级。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口属实，原 PARTIAL 判定正确，无法推翻。资金风控只实现了 risk-check 中的两项（大额阈值 LARGE_AMOUNT、近7天同收款方同金额重复付款），且 risk-check 是独立只读端点，从未被付款创建链路调用。描述五项：1) 付款对象/用途黑白名单——无，Payment 实体无名单/币种/用途字段，全库唯一黑名单是 RdServiceAgency.status 与付款无关；2) 头寸风险预警（可用余额低于安全备付金+预测缺口）——无，FundPool 仅净现金聚合，FundPlan 仅算预测期末余额，无备付金阈值与缺口预警；3) 汇率风险（外币监控/锁汇/远期结售汇套保）——零，currency 仅被动标签；4) 合规性检查（黑名单/外汇规定/授权范围）——均无；5) 强制接入付款创建链路——未做，PaymentService.create 仅置待付保存。",
   "reEvidence": "SettlementController.java lines 240-304: riskCheck only does LARGE_AMOUNT and DUPLICATE_PAYMENT. PaymentService.java lines 59-67: create never calls risk-check, only sets pending and saves. PaymentController.java lines 69-93: create has no risk gate. domain/Payment.java lines 21-51: no currency/list/purpose fields. FundPoolController.java lines 59-104: only net-cash aggregation. FundPlanController.java lines 119-125: only forecast end-balance. Grep for blacklist/forex/hedge/safety-reserve found no payment-related hits; only RdServiceAgency.java:63."
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "7. 报表与统计分析",
   "verdict": "LOGIC_GAP",
   "gap": "缺资金日报/月报(昨日余额/今收今支今余、收支汇总/账户余额分布)、现金流量表(直接法/间接法+经营/投资/筹资三分类)、账户余额分析(按银行公司分布+识别闲置长期低余额账户建议销户)、资金集中度分析(归集比例/内部结算比例/资金池使用效率)、利息分析(内部利息收支/外部贷款利息)、票据分析(余额/到期分布/贴现成本)。",
   "severity": "med",
   "evidence": "有 FinanceDashboardController.java 多维 KPI 看板(合同/资金/往来/凭证)与 ArApController.summary,但需求 6 张专表全缺:grep 现金流量/资金日报/资金月报 全模块命中 0;grep 经营活动/投资活动/筹资活动 命中 0(无直接法/间接法现金流量表);账户余额分析/资金集中度分析依赖 BankAccount 余额字段而该字段不存在;grep 计息/利息分析 在结算域 0;票据分析(余额/到期/贴现)无。ReportDefinitionController 与 seed 中'资金'命中的是部门名'资金结算部'与专项资金描述,非资金日报/月报报表预置。维持 LOGIC_GAP。",
   "survives": true,
   "reNote": "缺口基本属实。资金支付中心/结算中心存在大量 CRUD 与看板（FinancingController、FundPoolController、FundPlanController、FinanceDashboardController、SettlementController），但缺口所列的「7.报表与统计分析」六类资金/司库报表中，五类完全无实现，第六类仅有边角重叠：(1) 资金日报/月报(昨日余额/今收今支今余/收支汇总/账户余额分布)——全后端+前端 grep 零命中，无端点无页面；(2) 现金流量表(直接法/间接法+经营/投资/筹资三分类)——零命中；(3) 账户余额分析(按银行/公司分布+识别闲置长期低余额账户建议销户)——根本不可能：domain/BankAccount.java 只有 accountName/bankName/accountNo/companySubject/currency/purpose 六字段，无任何余额字段，无此类端点/页面；(4) 资金集中度分析(归集比例/内部结算比例/资金池效率)——零命中；(5) 利息分析(内部利息收支/外部贷款利息)——仅 FinancingController GET /financings/cost/summary 做了「融资成本分析」(逐笔本金/应还利息/综合成本率/加权成本率)，只覆盖外部融资利息成本一个侧面，无内部利息收支，且定位是融资成本而非司库利息分析报表；(6) 票据分析(余额/到期分布/贴现成本)——零命中，唯一的「票据」只是 Financing.financingType 的一个枚举值，无票据余额/到期/贴现成本分析报表。前端 payment 页面仅 board/byinvoice/financing/financing-cost/fundplan/fundpool/ledger/reconciliation/repayment/settlement，无任何上述报表页；对全部专有术语(现金流量/资金日报月报/余额分布/资金集中度/归集比例/票据分析/利息分析/闲置账户/建议销户/直接法/间接法/今收今支)的前后端 grep 均零命中(除域内 CRUD 文档串)。结论：六类报表里五类零实现、一类(利息)仅边角部分重叠，核心司库统计报表整体缺失，缺口成立。",
   "reEvidence": "domain/BankAccount.java 无余额字段(仅6个字段);全后端grep 现金流量/集中度/归集/票据分析/利息分析/闲置/销户/直接法/间接法/今收今支 在 payment/fund/settlement 域零命中;web/PaymentController.java(仅CRUD+pay/reject)、web/FundPoolController.java(/fund-pool 按主体汇总contract/invoiced/outflow/balance)、web/FundPlanController.java(资金计划期初/计划流入流出/预测期末)、web/FinanceDashboardController.java(合同/资金/往来/凭证KPI看板)、web/SettlementController.java(复核+风控)均无六类司库报表端点;唯一近似 web/FinancingController.java GET /financings/cost/summary(融资成本分析:本金/利息/综合成本率/加权成本率)只覆盖外部融资利息;前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/payment/ 仅 board/byinvoice/financing/financing-cost(接 /financings/cost/summary)/fundplan/fundpool/ledger/reconciliation/repayment/settlement,无日报/月报/现金流量表/账户余额分析/资金集中度/票据分析页;前端全 src grep 上述专有术语零命中;ReportController/BusinessBiController/ReportDefinitionController 亦无相关关键词。"
  },
  {
   "area": "支付中心 / 结算中心/资金支付中心 / 结算中心（资金保障·结算复核）",
   "module": "8. 与其他部门接口要求",
   "verdict": "PARTIAL",
   "gap": "缺银企直连真实适配器(余额/明细/支付/回单)、票交所电子票据接口、收款/利息/票据会计凭证与银行对账单/余额调节表成体系、HR工资表批量代发、销售回款认领与催收数据接口、分子公司内部往来确认与账户余额查询接口。",
   "severity": "med",
   "evidence": "外部对接为 MockSyncAdapter.java 桩,第27-32行注释明示银企直连(余额/明细/支付/回单)与财务T+/ERP/政务均为 TODO 未实连;票交所电子票据接口 grep 无任何实现。会计凭证仅 PaymentService.autoVoucher 自动出付款类 1 种(借应付账款/贷银行存款,第113-130行);收款/利息/票据凭证、银行对账单(BankReconciliation 仅手工/导入登记)、余额调节表未成体系。批量代发(HR工资表)、到款认领/催收(销售)、内部往来确认/账户余额查询(分子公司)等部门级接口对应模块 2/3/4 缺口,多数缺。维持 PARTIAL。",
   "survives": true,
   "reNote": "缺口属实。该模块只有\"外部对接框架的骨架\"(ExternalSystemConfig 名册CRUD + DataSyncLog 台账 + IntegrationExecutor 调度 + SyncAdapter 接口)，没有任何一个真实适配器；六类具体接口要么明确标注\"不实做/外部对接项\"，要么完全不存在。逐条核验：(1)银企直连真实适配器(余额/明细/支付/回单)——`grep \"implements SyncAdapter\"` 全仓只命中 MockSyncAdapter 一个,其 sync() 为空操作并带 `TODO(真实外部对接)` 注释(组报文走专线查询/推送付款指令与回单未做);SettlementController 类注释直言\"银企直连(余额/明细/支付/回单自动取数)标注为外部对接项,本控制器不实做\";BankReconciliationController 类注释\"银企直连(自动取银行流水)为外部对接项,本控制器先支持手工/导入登记\"。(2)票交所电子票据接口——无任何实现,仅 TemplateSeedData 里一个表单下拉静态选项\"承兑汇票\"字符串。(3)收款/利息/票据会计凭证与银行对账单/余额调节表成体系——VoucherController 是独立凭证状态机,BankReconciliationController 只做 diff=bankBalance-bookBalance 手工登记,二者无任何联动:无从收款/利息/票据自动生成凭证、无银行对账单导入喂入对账、无余额调节表,不成体系。(4)HR工资表批量代发——无工资/薪酬/payroll 控制器,HR 域仅 HealthRecord/PersonnelCert/StaffCredential/StaffDossier;全仓无 batchPay/批量代发。(5)销售回款认领与催收数据接口——Payment/Invoice/CustomerCredit 中无认领/claim/核销;唯一\"催收\"在 DischargeBillController(排水水费逾期分级预警),与销售回款认领接口无关。(6)分子公司内部往来确认与账户余额查询接口——仅 Settlement 上一个 settleType=\"内部\" 枚举值,无往来确认工作流、无内部账户余额查询接口。",
   "reEvidence": "oa-backend/src/main/java/com/kaidi/oa/service/MockSyncAdapter.java(唯一SyncAdapter实现,sync()空操作+TODO真实外部对接:银企直连组报文走专线查询/推送付款指令与回单未做); oa-backend/src/main/java/com/kaidi/oa/service/SyncAdapter.java(接口注释\"当前仅提供MockSyncAdapter,真实银企/财务/政务对接各自实现待补\"); oa-backend/src/main/java/com/kaidi/oa/web/SettlementController.java:36(类注释\"银企直连(余额/明细/支付/回单自动取数)标注为外部对接项,本控制器不实做\"); oa-backend/src/main/java/com/kaidi/oa/web/BankReconciliationController.java:28(类注释\"银企直连(自动取银行流水)为外部对接项,先支持手工/导入登记\",diff仅手算); oa-backend/src/main/java/com/kaidi/oa/web/VoucherController.java(独立凭证状态机,无与对账/收款/票据联动); oa-backend/src/main/java/com/kaidi/oa/web/ExternalSystemConfigController.java(仅外部系统名册CRUD,adapter默认\"mock\"); oa-backend/src/main/java/com/kaidi/oa/service/IntegrationExecutor.java:146(resolveAdapter找不到真适配器一律回退defaultAdapter=mock); grep验证:全仓 implements SyncAdapter 仅MockSyncAdapter;无payroll/批量代发控制器(web/下HR仅HealthRecord/PersonnelCert/StaffCredential/StaffDossier);Payment/Invoice/CustomerCredit无认领/核销;票交所/ECDS零实现(仅seed静态字符串\"承兑汇票\")"
  },
  {
   "area": "财务部/支付中心",
   "module": "1. 总账与会计凭证管理",
   "verdict": "PARTIAL",
   "gap": "科目无多维辅助核算字段;科目启停无审批;无凭证模板;无自动/自定义结转损益;无期末处理与结账前自动检查;账簿查询(总账/明细账/科目余额表/多栏账/辅助核算余额表)与原始凭证穿透全缺。",
   "severity": "high",
   "evidence": "VoucherController.java 有完整制单→审核→过账→红冲状态机(audit/post/unaudit/reverse,过账后不可改/删只能红冲,红冲生成反向负额凭证并标记reversed)+审核前借贷科目齐备/金额>0校验,确为真实核心。AccountController.java 科目支持 parentCode/level 多级、category(资产/负债/权益/成本/损益)、direction。但初判所列缺口全部坐实:Voucher 实体(domain/Voucher.java)仅 debitAccount/creditAccount 两个字符串,无 部门/项目/客户/供应商/成本中心 任何辅助核算维度字段;AccountController 无启停审批(无 status/审批);全仓 grep 无 凭证模板/计提折旧摊销结转损益模板/自动结转损益/期末调汇/结账前检查/试算平衡/总账/明细账/科目余额表/多栏账/穿透 任何实现(命中仅 Account/Voucher 文档注释)。",
   "survives": true,
   "reNote": "缺口属实。我尽力推翻但无法成立——已建的只是「会计科目CRUD + 记账凭证状态机(草稿→已审核→已过账+红冲冲销)」，缺口列举的7项功能在前后端均无实现：(1)科目无多维辅助核算字段——Account实体仅 code/name/category/direction/parentCode/level/balance/createdAt，无客户/供应商/项目/部门等辅助核算维度；(2)科目启停无审批——Account无 enabled/status 字段，AccountController 只有基础CRUD，grep enable/disable/toggle 返回 NONE，未接审批流；(3)无凭证模板——无 VoucherTemplate 实体/控制器(现有 Contract/Declaration/Form Template 与凭证无关)，凭证新建为纯手工录入；(4)无自动/自定义结转损益——全后端无 结转损益/carryForward 实现(唯一「结转/穿透」命中在 BomItemController:194 是制造BOM自顶向下展开，与财务无关)；(5)无期末处理与结账前自动检查——无 period/closing 控制器或端点；(6)账簿查询全缺——VoucherRepository 仅 findByStatus/findByReversalOf/existsBySourceTypeAndSourceId，无总账/明细账/科目余额表/多栏账/辅助核算余额表的聚合查询端点；(7)原始凭证穿透全缺——财务域无账→原始凭证的穿透链路。PARTIAL 判定准确。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/Account.java(字段仅8个无辅助核算/无enabled), AccountController.java(纯CRUD无启停审批端点), domain/Voucher.java(状态机+红冲,无模板/结转), web/VoucherController.java(audit/post/reverse状态机,无账簿查询/无结转/无期末), repository/VoucherRepository.java(仅3个方法无账簿聚合)。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/api/finance.ts(accounts/vouchers仅基础+状态机动作), oa/pages/finance/accounts.vue(MasterDataPage纯科目CRUD), oa/pages/finance/vouchers.vue(凭证状态机表格,无模板/无账簿/无穿透)。反证检索: grep VoucherTemplate/凭证模板/结转损益/carryForward/科目余额表/明细账/多栏账/trialBalance/穿透 in oa-backend/src/main/java → 唯一命中为 BomItemController(制造BOM,非财务)。无 Ledger/Period/Closing 控制器。"
  },
  {
   "area": "财务部/支付中心",
   "module": "2. 应收账款管理",
   "verdict": "PARTIAL",
   "gap": "应收单未从销售合同/发票自动生成;无收款单独立建模与自动核销引擎、预收/超额;无坏账计提(账龄比例法/个别认定法→信用减值损失/坏账准备凭证)。",
   "severity": "high",
   "evidence": "ArApController.java 应收应付往来核算确实建模:create 校验类型/往来单位/金额,关联 contractId/invoiceId 字段,POST /{id}/writeoff 核销引擎(累加已核销、未核销=金额-已核销、全核销→已结清/部分→部分核销、超额409拒绝),/summary 含按 dueDate 逾期口径的账龄汇总。但应收单为手工 create(无从销售合同/发票自动生成、无项目履约进度/合同确认收入触发);收款未独立建模为收款单(核销只是 writeoff 累加金额,无按订单/按发票自动核销引擎、无预收/超额收款独立处理);grep 全仓无 坏账/信用减值/坏账准备 任何计提逻辑(账龄比例法/个别认定法均无)。",
   "survives": true,
   "reNote": "缺口属实。应收应付确有基础建模(ArApItem域+ArApController:登记/手工核销/状态流转未核销→部分核销→已结清/账龄逾期汇总),但缺口点名的三项进阶能力确实全部缺失,与PARTIAL判定一致。1) 应收单未自动生成:全工程内 new ArApItem 仅出现在 ArApController.create 这一手工POST端点;TriggerRuleEngine 的收款联动(ruleCreateReceivableInvoice)生成的是\"待开发票草稿\"(Invoice),不是应收单(ArApItem),销售合同/发票均无任何路径自动派生应收单。2) 无收款单独立建模与自动核销引擎/预收/超额:无独立\"收款单\"实体;writeoff端点是纯手工核销(调用方传金额),无自动匹配引擎;预收(advance)未建模;超额核销被显式409拒绝(line167-169)而非作为\"超额/预收\"处理。3) 无坏账计提:全后端无账龄比例法/个别认定法/信用减值损失/坏账准备凭证生成;/summary 仅做未核销与逾期口径汇总,不计提准备金;唯一\"坏账\"字样是 DischargeBillController 排污费催收的文字等级标签(催收/严重/坏账风险),与减值计提无关。前端 ArApPanel.vue 同样只有手工核销,无坏账/账龄比例/预收UI。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/domain/ArApItem.java (AR/AP域,仅手工核销字段); web/ArApController.java (create 手工登记 line71-103; writeoff 手工核销 line154-175,超额409 line167; summary 仅逾期汇总 line185-212; 无坏账/账龄比例/预收/自动生成); service/TriggerRuleEngine.java line197-239 ruleCreateReceivableInvoice 生成的是Invoice而非ArApItem; grep 'new ArApItem' 仅命中 ArApController.create。web/DischargeBillController.java line207-224 \"坏账风险\"仅为催收文字标签。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/finance/ArApPanel.vue line180 仅手工核销提示,无坏账/账龄比例/预收。全仓grep 账龄比例法/个别认定/信用减值损失/坏账准备/自动核销引擎 均无命中。"
  },
  {
   "area": "财务部/支付中心",
   "module": "3. 应付账款管理",
   "verdict": "PARTIAL",
   "gap": "应付单未从采购合同/发票自动生成;发票状态/账期跟踪薄弱;其他应付款仅手填。",
   "severity": "med",
   "evidence": "应付与应收共用 ArApController.java(arApType=应付),纯手工 create,虽有 contractId/invoiceId/dueDate 字段,但无从采购合同/发票自动生成应付单的取数逻辑(无采购模块联动)。发票状态字段存在但无账期跟踪机制(仅 /summary 的逾期口径)。其他应付款=手填 partyName/relatedRef。",
   "survives": true,
   "reNote": "缺口属实，PARTIAL 判定成立。应付确有专门模块（ArApController/ArApItem/ArApPanel.vue），支持手工登记、核销状态机（未核销→部分核销→已结清）、超额核销 409 拦截、以及 /summary 的逾期口径汇总——所以不是\"完全没有\"，但缺口描述的三条具体短板逐条核实全部成立：\n\n1) 应付单未从采购合同/发票自动生成——属实。全后端唯一 `new ArApItem()` 只出现在 ArApController.create（纯手工 REST 建单）。无 service、无 TriggerRuleEngine 规则、无 @Scheduled、InvoiceController/ContractController/ContractMilestoneController 均无任何代码生成 ArApItem。contractId/invoiceId 是可空手填关联，前端 ArApPanel.vue 连这两个字段都不绑定，只有一个自由文本 relatedRef（\"合同号或发票号\"）。进项(应付性质)发票更不会派生应付单——InvoiceController.applyContractDelta 显式把进项排除在回写之外(L65-67)，只是\"不混入应收\"，没有任何补偿性应付生成。\n\n2) 发票状态/账期跟踪薄弱——属实。Invoice 实体只有状态(待开/已开/已认证/作废)+issueDate，无 dueDate/账期字段、无任何账龄逻辑。账期/逾期只存在于另一个 ArApItem 上(dueDate + /summary 的 apOverdue)，且仅是\"逾期 vs 未逾期\"单桶口径(isOverdue=dueDate<today, L237-248)，非 30/60/90 真账龄分桶报表，确属\"薄弱\"。\n\n3) 其他应付款仅手填——属实。全部经 ArApPanel.vue 对话框/ArApController.create 手工录入。\n\n无法推翻。",
   "reEvidence": "后端: oa-backend/src/main/java/com/kaidi/oa/web/ArApController.java (L71-103 create 唯一手工建单; L184-212+237-248 summary 单桶逾期); oa-backend/src/main/java/com/kaidi/oa/domain/ArApItem.java (有 dueDate/contractId/invoiceId 但靠手填); oa-backend/src/main/java/com/kaidi/oa/domain/Invoice.java (无 dueDate/账龄); oa-backend/src/main/java/com/kaidi/oa/web/InvoiceController.java (L65-67 进项不回写也不生成应付); 全仓 grep \"new ArApItem\" 仅命中 ArApController。前端: ofbiz-framework/plugins/modern-ui/app/src/oa/pages/finance/ArApPanel.vue (L38-63 建单表单只手填 partyName/relatedRef自由文本/amount/dueDate，无\"从合同/发票生成\"动作); src/oa/pages/finance/payable.vue; src/oa/api/finance.ts (L132-154 createArAp 手工 POST)。"
  },
  {
   "area": "财务部/支付中心",
   "module": "4. 研发费用管理",
   "verdict": "PARTIAL",
   "gap": "无三口径核算/加计扣除标记/资本化区分;无工时分摊;无委托研发80%与境外1/3校验;无自动归集与合规预警;无结题后自动结转。",
   "severity": "high",
   "evidence": "RdExpenseController.java + domain/RdExpense.java 确认:category 为 free-text(人工费/直接投入/折旧费用/无形资产摊销/设计费/其他),仅 amount/occurDate/voucher/status(待审核/已归集/已驳回)。无三口径(会计/税务加计扣除/高新认定)、无加计扣除标记字段、无资本化vs费用化区分;无工时填报审核与薪资社保按工时占比分摊;无委托研发80%/境外1/3校验;无领料/折旧/无形资产摊销自动归集;无合规校验预警;无结题后自动结转(费用化→管理费用-研发费用、资本化→无形资产)。",
   "survives": true,
   "reNote": "缺口属实。逐条核验研发费用管理(链4)的七项专项能力，均未实现，仅有基础 CRUD + 一个预算执行归集。\\n\\n1) 三口径核算：RdExpense.java 实体只有单一 amount + 自由文本 category(人工费/直接投入/折旧费用/无形资产摊销/设计费/其他)，没有会计核算/高新研发/加计扣除三口径的金额分列。缺。\\n2) 加计扣除标记：全后端 grep 加计/超扣/deduct 在研发语境零命中；RdExpense 无可加计标志位。缺。\\n3) 资本化区分：RdExpense 与 DevProjectBudget 都无 资本化/费用化/capitaliz 字段。缺。\\n4) 工时分摊：无工时→成本分摊；唯一的「工时单」仅是 voucher 自由文本串，无工时数/费率/分摊引擎。缺。\\n5) 委托研发80%与境外1/3校验：grep 委托研发/境外/0.8/1/3 在研发语境零命中(0.8 命中全是 WaterAlertRule 预警比例和文化考核打分)。缺。\\n6) 自动归集与合规预警：仅 DevProjectBudgetController.aggregate 从 RdExpense(status=已归集)按科目聚合实际成本回填预算行 + summary 超预算预警——这是「预算执行 vs 实际」的归集与超预算预警，不是加计扣除可扣除额归集，也无委托/境外超限的税务合规预警。专项合规口径缺。\\n7) 结题后自动结转：RdProjectController 纯 CRUD，stage(立项/研发中/结题/验收)只是自由字段写入，无状态机、无 TriggerRule、无结题→无形资产/费用结转；唯一的「结转」命中是 DataSeeder 里一条硬编码凭证种子串。缺。\\n\\n另注：EligibilityCheckService 是「高企/科技型中小企业认定」的达标自查(研发费用占比/知识产权数/科技人员占比/已完成项目数)，与加计扣除税务核算无关，不构成本缺口的实现。",
   "reEvidence": "RdExpense 实体(单 amount+文本 category，无加计/资本化/三口径字段): /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/RdExpense.java；RdExpenseController 纯 CRUD: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdExpenseController.java；RdExpenseTraceController 只读按类型汇总证据链，无加计/合规口径: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdExpenseTraceController.java；DevProjectBudgetController.aggregate/summary 仅做预算执行归集+超预算预警(非税务加计合规): /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/DevProjectBudgetController.java:131-192；RdProjectController 纯 CRUD 无结题状态机/结转: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/RdProjectController.java；EligibilityCheckService 是高企认定自查非加计扣除: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/service/EligibilityCheckService.java；前端 grep 加计扣除/资本化/费用化/三口径/工时分摊/委托研发/境外研发/结题结转 在 modern-ui/app/src 零命中。"
  },
  {
   "area": "财务部/支付中心",
   "module": "5. 费用报销管理",
   "verdict": "PARTIAL",
   "gap": "无发票验真查重(税局平台/号码防重/OCR);无借款管理;移动端拍照上传发票缺失;多级/预算外审批未专配。",
   "severity": "med",
   "evidence": "ExpenseClaimController.java 确有强实现:草稿→已提交→已报销/已驳回状态机,doSubmit 做预算校验(剩余=预算额度-已用-在途,超预算409),/budget-check 提交前探针,reimburse 计入预算 actualAmount 并回写超支状态——这部分扎实。但缺口坐实:grep 全仓无 发票验真/查验平台/OCR/查重/重复报销 任何实现;无借款管理(差旅/备用金借款申请审批还款核销、逾期工资扣除);移动端拍照上传发票无落地;预算外特殊审批/多级审批未专配(依赖通用引擎)。",
   "survives": true,
   "reNote": "尽力反驳后仍无法推翻：该费用报销缺口属实(PARTIAL判定成立)。专用报销模块(ExpenseClaimController + finance/expense.vue)确实存在并有预算/超预算校验+状态机，但缺口描述列的4项短板逐条核实3项铁证缺失、第4项措辞准确：\n\n1) 无发票验真查重(税局/号码防重/OCR)——属实。InvoiceController(web/InvoiceController.java)仅基础CRUD；Invoice实体number字段无唯一约束，InvoiceRepository只有findByProjectId、无existsByNumber/findByNumber/去重查询；全仓grep验真/查重/防重/税局/OCR在发票相关代码零命中；invoice.vue为纯主数据CRUD。\n\n2) 无借款管理——属实。finance/payment全部页面及任何控制器/domain对借款/借支/loan/advance/预借/备用金零命中；无借款实体、无借款核销冲抵报销。\n\n3) 移动端拍照上传发票缺失——属实。MobileController(web/MobileController.java)只是待办/预警计数聚合端点，无任何photo/camera/OCR/发票上传。\n\n4) 多级/预算外审批未专配——基本属实(措辞准确)。专用ExpenseClaim走扁平单步审批(草稿→已提交→已报销/已驳回，仅一个核准/驳回动作)，ExpenseClaimController与expense.vue均不调用WorkflowService/FormInstance工作流引擎、无多级节点。引擎侧虽存在通用reimburseTemplate(部门主管→财务审核→总经理三级)和conditionalExpenseTemplate(条件分支≥1万走总经理/<1万直通)，但这些是独立表单引擎目录里的演示模板，并未与专用报销单据绑定，故描述\"未专配\"准确。\n\n结论：4项中3项无任何实现、第4项措辞精确，缺口不成立的反证未能找到。",
   "reEvidence": "后端：oa-backend/src/main/java/com/kaidi/oa/web/ExpenseClaimController.java(扁平状态机:草稿→已提交→已报销/已驳回，submit/reimburse/reject/budget-check，无工作流引擎调用，无多级节点)；domain/ExpenseClaim.java(无step/node/level/approver字段)；web/InvoiceController.java(仅CRUD，number无防重)；domain/Invoice.java(number无@Column unique)；repository/InvoiceRepository.java(仅findByProjectId，无existsByNumber/去重)；web/MobileController.java(仅summary计数聚合，无发票拍照上传)。前端：ofbiz-framework/plugins/modern-ui/app/src/oa/pages/finance/expense.vue(单步核准/驳回，无template/workflow/多级/OCR/拍照)；oa/pages/masterdata/invoice.vue(纯MasterDataPage CRUD，无验真/查重/OCR)。引擎(独立未绑定)：oa/engine/templates/baohan.ts的reimburseTemplate(部门主管→财务审核→总经理)与templates/index.ts的conditionalExpenseTemplate(amountGate分支≥1万→gm)。grep全仓借款/loan/advance/预借/备用金在finance与payment页面零命中；验真/税局/OCR在发票相关代码零命中。"
  },
  {
   "area": "财务部/支付中心",
   "module": "6. 税务管理",
   "verdict": "PARTIAL",
   "gap": "无增值税抵扣链与申报表;无销项/进项发票自动开具/OCR/验真/认证/抵扣台账;无税控/电子税务局对接;无所得税/其他税种计算;无一键申报与税务风险预警。",
   "severity": "high",
   "evidence": "TaxFilingController.java 有真实计算:应纳税额=计税依据×税率 服务端 BigDecimal 重算(不信前端),状态机 待申报→已申报→已缴款(file/pay),/summary 按税种汇总。但仅单笔 base×rate,无增值税 销项-进项-转出-应纳 抵扣链;无销项发票从销售订单/应收单自动开具、无税控盘/电子税务局对接(开票/作废/红冲);进项无OCR/验真/勾选认证/抵扣台账;无申报表(主表附表一~四);无所得税季度年度/递延;无印花/房产/个税专项计算;无一键申报缴税接口;无税务风险预警(税负率/发票异常/进销项不匹配)。",
   "survives": true,
   "reNote": "缺口判定为 PARTIAL，属实。我尽力反驳但只能证明\"部分已实现\"，无法推翻 PARTIAL 本身——其枚举的各项缺失确实成立。\n\n已实现（构成 PARTIAL 而非 MISSING 的部分）：(1) TaxFilingController 提供税务申报登记，支持增值税/企业所得税/附加税/个税/印花税/城建税多税种，taxBase×taxRate 服务端 BigDecimal 重算应纳税额，状态机 待申报→已申报→已缴款，/file、/pay 动作及 /summary 按税种汇总——这部分覆盖了\"所得税/其他税种计算\"的基础计算。(2) InvoiceController 提供发票主数据，区分 进项/销项，amount/taxAmount/total，状态 已开/已认证/作废，销项开具回写合同应收。\n\n确属缺失（与缺口描述逐条吻合）：\n- 无增值税抵扣链/抵扣台账：全库唯一的\"抵扣\"是 MeasurementPaymentController 的预付款/质保金抵扣与 FeedstockBatch 的扣重，与增值税进项抵扣无关；grep 无 inputTax/outputTax/vatPayable/netVat/留抵 任何进销项轧差算应纳增值税的逻辑。TaxFiling 与 Invoice 之间无任何关联（TaxFilingRepository 只有 findByStatus/findByTaxType/findByPeriod）。\n- 无发票自动开具/OCR/验真/认证：Invoice 的\"已认证\"仅是手填状态字符串，InvoiceController 只有 CRUD，无 OCR、无验真、无自动开具端点。\n- 无税控/电子税务局对接：全库无外部税务接口。\n- 无一键申报：/file 是逐条手动状态翻转，非按抵扣台账聚合生成的一键增值税申报表。\n- 无税务风险预警：grep 无任何税务风险预警逻辑。",
   "reEvidence": "后端: /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/TaxFilingController.java (仅 CRUD+file/pay/summary，无抵扣/一键/预警); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/web/InvoiceController.java (仅 CRUD，无 OCR/验真/认证端点/自动开具); /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/TaxFiling.java; /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/domain/Invoice.java; /Users/qiu/Desktop/ERP/oa-backend/src/main/java/com/kaidi/oa/repository/TaxFilingRepository.java (无进销项关联查询)。前端: /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/finance/tax.vue (仅税种×税率登记表单); /Users/qiu/Desktop/ERP/ofbiz-framework/plugins/modern-ui/app/src/oa/pages/masterdata/invoice.vue (仅发票主数据 CRUD)。grep 全后端 inputTax/outputTax/vatPayable/留抵/一键申报/税务风险/发票验真 = 0 命中；\"抵扣\"命中全部来自 MeasurementPaymentController(预付款/质保金抵扣) 与 FeedstockBatch(扣重)，与增值税进项抵扣无关。DeclarationController = 政府科技项目申报(高新/专精特新)，非税务申报。"
  },
  {
   "area": "财务部/支付中心",
   "module": "7. 资产管理",
   "verdict": "PARTIAL",
   "gap": "无资产增减变动审批;无盘点;无新租赁准则;无减值测试;折旧无批量自动计提与部门/成本中心分摊;无购置合同/发票影像。",
   "severity": "med",
   "evidence": "FixedAssetController.java 实现资产卡片(原值/年限/折旧方法/部门)+ 月折旧计提 POST /{id}/depreciate(月折旧=原值/(年限×12) BigDecimal,累计折旧累加、净值=原值-累计、末月不超提、达原值置已提完),/summary 折旧汇总。但折旧为按资产逐张手动触发,无按月批量自动计提、无按部门/成本中心分摊;无资产增减变动审批(采购入库/在建转固/报废/出售/盘亏);无盘点(任务/扫码/盘盈盘亏报告);无新租赁准则(使用权资产/租赁负债/利息摊销);无减值测试与减值准备;无购置合同/发票影像。",
   "survives": true,
   "reNote": "尽力推翻未果，缺口属实，PARTIAL 判定准确。固定资产模块确有实现但仅为基础卡片台账+单资产直线折旧，缺口所列 6 项子能力逐一核实均缺失。已实现部分：FixedAsset 实体（原值/累计折旧/净值/月折旧额/年限/直线法/状态）+ FixedAssetController 8 个端点（list/get/create/update/delete/单资产 POST /{id}/depreciate 月计提/summary），前端 finance/asset.vue 提供卡片 CRUD + 逐条「计提折旧」按钮。但缺口所有子项确缺：①资产增减变动审批——asset 全部代码 0 处引用 WorkflowService/TriggerRuleEngine/审批，create/dispose/transfer 都是裸 CRUD 无审批流；②盘点——无盘点实体/端点/字段（仅会议标题与知识库模板名出现\"盘点\"字样，无关）；③新租赁准则——无使用权资产/租赁实体（\"租赁\"仅 DataSeeder 供应商名）；④减值测试——asset 域 0 处 impairment/减值 字段或逻辑；⑤批量自动计提+部门/成本中心分摊——折旧严格单资产、单月、手动逐条触发，无批量/期末一键计提端点、无定时自动计提、无 costCenter 字段，department 字段存在但从不参与折旧费用分摊（所有\"分摊\"逻辑都在 LogisticsBudget/AdminSupply/ItBudget 等无关控制器）；⑥购置合同/发票影像——FixedAsset 无任何附件/影像字段或上传端点。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa/web/FixedAssetController.java（仅 list/get/POST/PATCH/DELETE/POST{id}/depreciate/GET summary 8 端点；29-31 行注释明确折旧为单资产按月计提；grep WorkflowService|TriggerRuleEngine|审批 命中 0）；domain/FixedAsset.java（字段无 impairment/减值/costCenter/盘点/lease/附件，仅 department 字符串且 controller 从不据此分摊）；repository/FixedAssetRepository.java（无 batch/impairment/stocktake 查询）；web/ 目录仅 FixedAsset/ItAsset/IpAsset/BranchAsset 四个 asset 控制器，无 disposal/transfer/change/stocktake/impair 控制器。前端 ofbiz-framework/plugins/modern-ui/app/src/oa/pages/finance/asset.vue（仅卡片 CRUD + 逐条计提折旧按钮，无批量计提/盘点/减值/审批/影像上传 UI）+ src/oa/api/finance.ts:106-129（API 仅 list/create/update/delete/depreciateAsset 单资产）。\"分摊\"全部命中在 LogisticsBudgetController/AdminSupplyController/ItBudgetController，与资产折旧无关。\"盘点\"命中为 meeting/mockData.ts 会议标题与 knowledge/mock.ts 模板名，\"租赁\"命中为 DataSeeder 供应商名。"
  },
  {
   "area": "财务部/支付中心",
   "module": "8. 成本核算与管理",
   "verdict": "PARTIAL",
   "gap": "成本数据未自动采集归集;无四种成本计算法引擎;差异仅总差异无三差异拆解;无按动因可配置分摊规则自动执行。",
   "severity": "med",
   "evidence": "StandardCostController.java(389行)/CostCenterController.java/BudgetController.java 存在标准成本与成本中心建模,但成本数据靠手填录入,无从采购(材料成本)/生产项目(工时产量)/报销(间接费)自动采集归集的系统级取数;无品种法/分批法/分步法/作业成本法计算引擎;差异分析无 用量/价格/效率 三差异拆解(仅总差异);无按动因(工时/产量/收入/人数/面积)可配置分摊规则每月自动执行。",
   "survives": true,
   "reNote": "尽力反驳后，缺口判定 PARTIAL 成立。该模块确实存在成本核算控制器群，且我推翻了缺口描述里\"第1点(未自动采集归集)\"——自动归集是真实实现的；但缺口的核心承重短板(四种成本计算法引擎、三差异拆解、可配置动因分摊规则)确实找不到实现，无法推翻。逐条结论：\n\n(1) 自动采集归集——【缺口此点不成立/已实现】。ProjectCostControlController.rollup(POST /api/oa/project-budget-lines/rollup)真实跨模块自动归集：领料MaterialIssue→材料费、报工ProductionReport→人工费、已审批ExpenseClaim→其他直接费、已签合同Contract→committed，按成本要素回填WBS预算行(L206-298,@Transactional)。另有 MfgProjectCostController.summary(按项目归集料/工/售后)、OpsCostAllocationController(按账期归集维修/污泥/危废)、BomAnalysisController.backfillApply(从领料回填actualQty)。故\"未自动采集归集\"被推翻。\n\n(2) 四种成本计算法引擎——【缺口属实，找不到实现】。全代码无可选成本计算法引擎(标准成本法/作业成本法/分批法/分步法，或FIFO/加权平均/个别计价)。StandardCost是固定的料+工+费标准成本台账，无方法切换。DischargeContract的pricingMode(按水量/COD/组合/阶梯)是对客户计费、非产品成本计算法；DevProject.targetCost仅一个\"目标成本法\"字段非引擎。无 costMethod/valuationMethod 选择逻辑。\n\n(3) 三差异拆解——【缺口属实】。所有差异都只算总差异：StandardCost.recompute 仅 variance=actual−standard；MfgProjectCost 仅 variance=actual−standard;ProjectCostControl 仅 exposure−budget。BomAnalysis 的 overrun=actualQty×unitPrice − bidQty×unitPrice——量价两端用同一 unitPrice，本质是纯量差、无价差维度，仍是单一总差。无价差(priceVar)+量差/用量差(usageVar)+效率差(efficiencyVar)的三差异分解。\n\n(4) 按动因可配置分摊规则自动执行——【缺口基本属实，仅\"可配置\"缺失】。自动执行的动因分摊是存在的：OpsCostAllocationController 按\"计费水量\"动因把总成本自动分摊到各排污企业(L108-125)；ProjectCostControlController.distribute 按\"预算占比\"动因自动分摊回填(L301-326)。但这些动因是硬编码的，没有让用户挑选动因/配置分摊规则的实体或引擎(无 allocationRule/driver 配置表)，故\"可配置\"这一限定确实未实现。\n\n综合：缺口的四条短板里，第1条被我推翻(自动归集已实现)，但第2、3条完全未实现、第4条\"可配置\"未实现，均为承重短板。PARTIAL 判定整体成立。",
   "reEvidence": "后端 oa-backend/src/main/java/com/kaidi/oa：\n- web/StandardCostController.java L70-75(recompute: totalStandard=料+工+费; variance=actual−standard 单一总差)、L136-336(按成本中心 rollup/rollup-tree 上卷)\n- domain/StandardCost.java L41-47(仅 totalStandard 与 variance 两字段，无量差/价差/效率差字段)\n- web/ProjectCostControlController.java L206-298(rollup 自动归集 MaterialIssue/ProductionReport/ExpenseClaim/Contract 回填 WBS)、L301-326(distribute 按预算占比动因硬编码分摊)、L387-431(EVM 仍只给 CV/SV 总差)\n- web/MfgProjectCostController.java L80-149(自动归集料/工/售后 + variance=actual−std 单一总差)\n- web/OpsCostAllocationController.java L69-132(按账期自动归集 + 按计费水量动因硬编码分摊)\n- web/BomAnalysisController.java L58-102(cost-compare: bidCost与actualCost同用 unitPrice→纯量差无价差)、L138-208(backfillApply 从领料自动回填 actualQty)\n- web/CostAuditTraceController.java(成本上溯下溯钻取)\n- domain/DischargeContract.java L47 / service/DischargeBillService.java L25(pricingMode 四模式属客户计费非成本计算法)\n活体验证(127.0.0.1:8091)：GET /api/oa/standard-costs/rollup 返回各成本中心仅 totalStandard/actualCost/variance(单一总差)，无三差异字段；GET /api/oa/mfg-project-costs/summary 返回 totalVariance 单一口径。全仓 grep 无 costingMethod/valuationMethod/作业成本法/分批法/分步法/priceVar/qtyVar/三差异/可配置分摊规则 引擎实现。"
  },
  {
   "area": "财务部/支付中心",
   "module": "9. 财务数据处理与合规管理(AI)",
   "verdict": "LOGIC_GAP",
   "gap": "无发票OCR落地;无报销合规自动校验;无报表/预算AI初稿pipeline;财务AI三项均为通用提示词补全,无专用数据上下文绑定。",
   "severity": "med",
   "evidence": "AiController.java + service/AiService.java 确认仅为通用 LLM 透传:complete/draft/classify/summarize/risk 五个端点,统一调 Anthropic Messages API,scenario 仅改系统提示语气,未配 Key 时优雅降级。无任何财务专用链路:无发票 OCR 识别落地(无图像/文件解析管道)、无报销单据合规性自动识别输出结构化校验结果、无财务报表/预算分析初稿自动生成 pipeline(未绑定真实凭证/报表数据上下文)。表面有 AI 能力,财务三项辅助逻辑空。",
   "survives": true,
   "reNote": "缺口属实。财务AI三项均无专用落地实现。我尝试推翻但代码反证缺口成立：(1) 全平台AI能力收口于单一通用层 AiService(service/AiService.java)+AiController(web/AiController.java)，仅5个通用场景 complete/draft/classify/summarize/risk，systemFor() 的系统提示是通用角色描述(企业办公写作助手/舆情分类/摘要/风险识别)，完全没有绑定财务专用数据上下文——正是描述所说\"通用提示词补全\"。(2) AiService 在全代码库只被注入1处(AiController)，无任何财务/发票/报销/报表/预算控制器 import 或调用它(grep web/Invoice* web/Expense* web/Report* web/*Budget* web/Finance* web/Voucher* web/Declaration* 零命中)。(3) 无发票OCR：无 tesseract/ocr 关键字，InvoiceController.create 直接接收客户端手填字段(number/amount/taxAmount)，无 MultipartFile/@RequestPart 上传识别端点。(4) 报销\"合规\"只是确定性数值预算校验(doSubmit/budgetCheck：剩余=预算-已用-在途，超支抛409)，非AI合规自动校验。(5) 无报表/预算AI初稿pipeline：ReportController/ReportDefinitionController/各Budget控制器均不触碰AI。",
   "reEvidence": "service/AiService.java:61-108 通用 complete()；142-154 systemFor() 仅通用提示词无财务上下文绑定；web/AiController.java:28-77 仅5个通用端点；AiService 全库唯一注入点=AiController(grep 'private final AiService' 仅命中 web/AiController.java)；web/InvoiceController.java:97-130 create 接收手填字段、无 MultipartFile/OCR；web/ExpenseClaimController.java:228-249 doSubmit 为确定性预算数值校验(超预算409)非AI合规；财务控制器(Invoice/Expense/Report/Budget/Finance/Voucher/Declaration)零 AiService 引用；全库无 ocr/tesseract/发票识别 命中。"
  },
  {
   "area": "财务部/支付中心",
   "module": "10. 资金与出纳管理",
   "verdict": "PARTIAL",
   "gap": "无日记账(现金/银行/流水自动生成);对账无逐笔自动勾对与余额调节表/未达账项;无现金管理;无票据管理;无资金调拨;银企直连未真实对接。",
   "severity": "high",
   "evidence": "BankReconciliationController.java 银行对账确有:diff=银行余额-账面余额 后端自动算,0→已对平否则未对平,文档明确标注银企直连(自动取流水)为外部对接项未实做。FundPlanController.java 仅资金计划/预测(期初+计划流入-计划流出),FundPoolController 为资金池。但缺口坐实:无现金/银行日记账(每日收支明细、银行流水自动生成);对账无逐笔自动勾对(按金额/日期/摘要)与余额调节表/未达账项(仅总额差);无现金管理(盘点/限额预警);无票据管理(支票/汇票领用核销作废);无资金调拨(上划下拨审批+内部往来凭证);银企直连(余额/明细/支付/回单)仅 ExternalSystemConfig 框架+MockSyncAdapter 明确标注未实做。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "财务部/支付中心",
   "module": "11. 预算管理(财务预算)",
   "verdict": "PARTIAL",
   "gap": "无预算编制流程与五类分类;无多版本;无预算调整审批+历史;无滚动预算;无月季年执行报告与偏差阈值预警。",
   "severity": "med",
   "evidence": "BudgetController.java 仅 list/get/create(无 update/delete 端点),create 时 actual>budget 自动置超支,element/period(年度/季度/月度)分类。ExpenseClaimController 提供报销时预算校验(剩余=额度-已用-在途、超预算409)是真实控制点。但无预算编制流程(自上而下下达/自下而上部门填报、收入/成本/费用/资本/现金流分类);无多版本(初稿/修订/批准);无预算调整申请审批+调整历史;无滚动预算(按月季滚动未来12月);执行分析仅 FinanceDashboard 看板,无月季年执行报告与偏差阈值自动预警。grep 命中的预算编制均为其它域(分公司经营/WBS项目/合同预算)非财务总预算。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "财务部/支付中心",
   "module": "12. 财务报表与合并报表",
   "verdict": "MISSING",
   "gap": "无四张法定报表自动生成;无自定义管理报表;无合并报表与抵消分录;无报表附注;无财务比率分析。看板≠财务报表。",
   "severity": "high",
   "evidence": "全仓 grep 资产负债表/利润表/现金流量表/所有者权益/合并报表/抵消/流动比/速动比/净利率/周转率/balance.?sheet/income.?statement/cash.?flow 仅命中 ContractController(无关)与 seed。FinanceDashboardController.java 文档自述为『财务多维看板(只读聚合)』,把合同/资金/往来/凭证四类台账客户端汇总成看板维度——非财务报表。无任一法定报表自动生成;无管理报表自定义格式;无集团合并报表(内部交易抵消/抵消分录/多准则);无报表附注;无财务比率分析与同环比。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "财务部/支付中心",
   "module": "13. 财务合规与审计",
   "verdict": "LOGIC_GAP",
   "gap": "操作日志无单据字段级修改前后diff(有哈希链但不含请求体);角色无岗位/科目/金额权限粒度;关键操作无二次授权;无审计只读导出底稿;无多准则配置;无电子会计档案归档。",
   "severity": "high",
   "evidence": "OperationAuditLogController.java + domain/OperationAuditLog.java + AuditLogInterceptor 确比初判更强:有不可篡改 sha256 哈希链(prevHash 串链+/chain/verify 逐条复算校验篡改/插删)、只读无删改端点、记 operator/operatorId/role/method/path/resourceType/resourceId/statusCode/clientIp。但实体注释明确『不含敏感请求体』,确无字段级修改前后内容 diff——初判此点坐实。RoleController.java 仅 list(无任何写),SysRole 仅 id/name/code,无岗位(出纳/应收/应付/总账/税务/CFO)菜单/科目/金额权限粒度;过账(VoucherController.post)/红冲(reverse)无二次授权(仅角色门槛);无审计只读账号导出凭证账簿底稿;无多会计准则切换科目映射;无电子会计档案专项归档。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "财务部/支付中心",
   "module": "14. 与其他部门接口要求",
   "verdict": "PARTIAL",
   "gap": "工资/生产工时/项目进度→凭证三条接口未自动化;多数专业接口为关键词匹配+Mock非系统级取数;结算银企直连未真实对接;各分子公司报表/往来/预算汇总无合并机制。注:付款与项目验收两条凭证自动生成路径真实存在。",
   "severity": "med",
   "evidence": "复核发现确有真实系统级凭证自动生成路径(初判『非系统级凭证自动生成』需收窄):PaymentService.confirmPay 在付款放款同事务自动生成记账凭证(借应付账款/贷银行存款,按(sourceType=payment,sourceId)幂等防重复入账)、ProjectController 项目验收自动生成凭证(sourceType=acceptance 幂等)、TriggerRuleEngine 项目联动凭证。但初判列举的具体接口仍未实现:工资表→费用入账/代扣代缴、生产工时→在制品成本、项目进度→收入确认 三条均无自动凭证;采购/销售/生产/HR 多为表单关键词匹配+MockSyncAdapter,非系统级取数;结算中心付款指令/回单/银行流水银企直连(SettlementController/BankReconciliation 均标注外部对接未实做);各分子公司财务报表/内部往来对账/预算执行报告汇总无合并机制(见模块12 MISSING)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "1. 融资管理（融资主体与额度/授信管理/金融机构关系管理）",
   "verdict": "LOGIC_GAP",
   "gap": "授信使用率自动监控/接近限额预警缺失；按金融机构/融资品种统计授信使用缺失；金融机构关系管理(档案/合作历史/审批效率/客户经理/分级评价)完全无实体无页面。",
   "severity": "high",
   "evidence": "维持初判。Financing.java 仅有 creditLimit 静态字段（domain/Financing.java:37），FinancingController 无授信使用率监控/接近限额预警、无按金融机构或品种(流贷/固贷/银承/信用证)统计授信使用的端点。全仓 grep '金融机构' 仅命中 AuthInterceptor 注释、CustomerCreditController(那是市场部客户授信，非银行档案)，无金融机构实体、无银行/券商/信托/租赁档案、无合作历史/审批效率/客户经理/定期评价分级。前端 payment/financing.vue 是纯 CRUD 列表，creditLimit 仅一个录入数字框，无机构关系页。CustomerCredit 模块是对'客户'授信(应收风控)，与对集团/子公司的'银行授信'方向相反，不可充数。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "2. 融资申请与审批流程（融资申请/审批流程/方案比选）",
   "verdict": "LOGIC_GAP",
   "gap": "融资审批未接 WorkflowService；无分级审批流/会签加签转审/在线留痕；无集团政策与授信充足性自动校验；融资方案比选(多机构报价/IRR-XIRR择优)完全缺失。",
   "severity": "high",
   "evidence": "维持初判。WorkflowService.java 与 TriggerRuleEngine.java grep financing/融资/RepaymentPlan 零命中；TriggerRuleEngine 已知 ruleKey 仅 payment.create/receipt.invoice/contract.effectivate/contract.toSeal/project.*/seal.markUsed/supplier.admit(service/TriggerRuleEngine.java:676-686)，无任何融资审批联动。融资 status 是前端自由下拉(financing.vue:41 options 含'申请中/审批中...')由 PATCH 任意改值，未接审批引擎——无按金额/品种/风险等级配置的金融办初审→财务→风控→高管/董事会流，无会签/加签/转审/在线留痕。create 时也不校验集团政策/授信额度充足性(FinancingController.create 仅校验 lender 非空)。方案比选/XIRR：FinancingController.java:331 注释明确'XIRR 精确内部收益率列为后续'，grep XIRR/比选 无实现，无多机构报价综合成本测算择优。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "3. 融资合同与提款管理（融资合同台账/提款管理/费用管理）",
   "verdict": "MISSING",
   "gap": "无融资合同台账实体/页面；无提款管理流程；无费用管理；FinancingController 把'授信额度+本金+还款方式'合并在一条 Financing 记录上代替不了合同台账与提款台账。",
   "severity": "high",
   "evidence": "维持初判。无独立融资合同台账：Contract.java grep financing/融资/提款/贷款/drawdown 零命中，无贷款人/还款方式/担保方式/提款条件/费用明细/扫描件/版本管理字段。提款管理：全仓 grep 提款/drawdown 仅命中 Financing.java 注释'amount 为提款金额'，无提款申请→审批→到账流程、无分批提款、无自动扣减合同剩余额度、无到账推送财务/结算。费用管理：grep 承销费/顾问费/手续费/担保费/评级费/律师费 全仓零命中，无费用归集至合同、无计入综合成本。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "4. 还本付息与债务管理（还款计划自动生成/到期预警/债务台账/还本付息执行）",
   "verdict": "PARTIAL",
   "gap": "无全口径债务台账多维统计与带息负债规模/成本率自动计算；预警仅系统列表，无邮件/短信推送、逾期无自动升级上报。",
   "severity": "med",
   "evidence": "维持初判。已到位部分属实且做得扎实：FinancingController.schedule 按 4 种还款方式(等额本息/等额本金/到期一次/按期付息到期还本)自动生成 RepaymentPlan(buildPlans:177-229)，payRepayment 确认还款时生成资金支付中心待付付款单 Payment(payType=融资还款，金额=本金+利息)并回填 paymentId、全清则置'已结清'(250-282)，maturityAlerts 分级预警逾期/紧急(<=7)/临近(<=15)/关注(296-317)。缺口属实：债务台账无全口径多维统计——无按融资品种/金融机构/期限结构/利率水平统计债务余额、无带息负债规模与带息负债成本率自动计算(FinancingRepository 仅 findByStatus)；预警仅系统内列表，grep JavaMailSender/SmsClient/sendEmail/sendSms 全仓零命中无邮件短信推送；逾期无自动升级上报逻辑(alerts 只打 level 标签，无升级动作)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "5. 融资成本分析与决策支持（成本测算/结构分析/投融资平衡/融资大屏）",
   "verdict": "PARTIAL",
   "gap": "XIRR/IRR 未实现；无市场基准利率对比识别高成本；无融资结构多维可视化图表；投融资平衡未联动投资项目；无融资大屏/驾驶舱穿透。",
   "severity": "med",
   "evidence": "维持初判。成本测算口径仅 利息合计/本金(costSummary:333-356)给逐笔与加权综合成本率，XIRR/IRR 动态精确计算 FinancingController.java:331 注释'列为后续'未实现；无对比市场基准利率识别高成本融资。融资结构分析：grep 期限结构/利率分布/品种占比/融资结构 在 payment 前端目录零命中，无多维可视化图表(financing-cost.vue 仅三张数字卡+一张明细表)。投融资平衡：FundPlanController.applyForecast 仅 期初+计划流入-计划流出(FundPlanController.java:120-125)，FundPlan domain 无投资项目关联字段，未联动投资项目测算资金缺口/盈余。融资大屏/驾驶舱:grep 融资大屏/驾驶舱/穿透 零命中无实现。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "支付中心 / 金融办/金融办（贷款融资）",
   "module": "7. 与其他部门接口要求（财务/结算/成本/法务/经营/子公司/银行外部）",
   "verdict": "PARTIAL",
   "gap": "仅'还款→付款单'一条真实接口；银企直连无实际 data 流(授信查询/贷款/还款指令/余额查询)；与成本/法务/经营/子公司的融资域联动均缺失。",
   "severity": "med",
   "evidence": "维持初判。仅一条真实联动：payRepayment 还款→生成资金支付中心待付付款单 Payment(FinancingController.java:261-270)，打通结算/支付链。银企直连仅配置框架：ExternalSystemConfig 是通道配置(domain/ExternalSystemConfig.java)，SyncAdapter 抽象层当前仅 MockSyncAdapter，注释明确'模拟通道，不实连外部'(service/SyncAdapter.java:12)，无真实授信额度查询/贷款申请/还款指令/账户余额查询的 data 流——MockSyncAdapter:30 只是注释描述未来怎么组报文。成本控制部融资成本归集、法务风险部合同法律审核联动、经营部客户信用、子公司融资/担保申请汇集均未从融资域打通(无对应跨域端点)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "1. 合同全生命周期管理",
   "verdict": "PARTIAL",
   "gap": "履约异常自动推法务的跨模块触发缺失；电子签无文件哈希防篡改(仅回执号)；合同附件全文检索与按金额区间分级查阅权限未实现。",
   "severity": "med",
   "evidence": "维持初判。ContractController(/api/oa/contracts) 只有 type=经营/成本/采购 + status=履约中/已结算/已终止 的元数据CRUD+分包派生；ContractMilestoneController 仅记 待履约/已完成/逾期 状态字段，无任何'逾期未付款→自动推送法务'的跨模块触发。TriggerRuleEngine.fire 只在表单审批办结时按 tag(付款/用印/收款/验收/供应商/合同/立项) 联动，无 milestone逾期/履约异常→法务 的事件键(grep 法务/逾期/履约 在 TriggerRuleEngine 零命中)。电子签 EsignController.seal 仅回填 externalSealRef(外部盖章回执号) 并置'已盖章'，ContractEsign 实体无任何文件哈希/指纹字段(全库 grep hash/digest/sha256/指纹/防篡改 无合同文件指纹实现)，注释自承'真对接后续接入，先手工回填占位'。全文检索 FullTextSearchService 确有索引合同(title=name,body=合同号+甲乙方)，但只索引合同元数据非附件/扫描件正文，且无按金额区间分级归档与敏感合同分级查阅权限。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "2. 合规管理",
   "verdict": "PARTIAL",
   "gap": "合规检查清单+自动自查任务分发、内置合规风险规则库自动预警、监管报送台账与超期预警 三项均缺失。",
   "severity": "high",
   "evidence": "维持初判。ComplianceObligationController(合规义务库) 实现了外规内化为内部义务的登记/状态流转/到期分级预警，是外规内化库的良好实现；但(a)无合规检查清单按业务领域配置+定期自动生成自查任务分发(无 checklist/自查任务实体)；(b)合规风险规则库自动预警缺失——RuleConfig/TriggerRuleEngine 是通用联动引擎，无内置'单笔超预算30%/制裁名单交易/无许可证经营'等规则(grep 制裁/sanction/超预算 在引擎零命中)；(c)监管报送管理缺失，grep 监管报送/报送 仅命中 MockSyncAdapter.java 第31行一句关于政务网关的注释，无报送台账/截止日期/超期预警实体。违规事件可由 FraudReportController 兜底。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "3. 合规审核与风险预警(AI)",
   "verdict": "LOGIC_GAP",
   "gap": "合同条款合规AI审核生成风险报告(现状为纯文本模板偏差比对)、法规更新库+自动diff对比+合规要点推送 均未实现。",
   "severity": "high",
   "evidence": "维持初判。确有真实AI层:AiService 调 Anthropic Messages API，AiController 暴露 /ai/risk(企业风险识别助手 system prompt)等端点。但需求要的两件具体事都未闭环:(a)合同条款合规审核→风险报告:实际的条款比对走 ClauseCompareService，其类注释明确'纯文本规则实现(关键词定位+数值抽取)，不依赖LLM'，输出只是模板偏差清单(缺失/新增/修改/一致 + 高/中/低)，比的是模板偏差而非合规风险，不出'风险条款/合规漏洞风险报告'；通用 /ai/risk 只是把 prompt 透传给 LLM 做风险提示，非结构化的合同条款合规审核报告工作流。(b)AI自动对比法规更新→提醒业务部门:完全缺失，无法规版本库/diff/推送(grep 法规版本/法规更新/北大法宝/威科 零命中)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "4. 知识产权管理与保护",
   "verdict": "PARTIAL",
   "gap": "知识产权侵权监控、被侵权应对、商业秘密密级管理(接触日志/离职提醒)、IP许可转让合同特殊审批 四项均缺失。",
   "severity": "med",
   "evidence": "维持初判。IpAssetController(611行) 是扎实的IP台账+申请流程状态机+年费/期限台账+缴费联动资金支付+法律状态+生命周期事件审计，覆盖台账与年费需求；但侵权监控(疑似线索登记+侵权评估+发律师函/投诉/诉讼决策)缺失——grep 侵权 全库仅命中 IpAsset.java 第44/57行两句注释('用于布局与侵权分析'的产品线字段说明)，无侵权线索/评估实体。被侵权应对(外部指控案件登记+应对策略)缺失。商业秘密密级管理缺失——grep 商业秘密/密级 仅命中 Archive*(档案密级:公开/内部/秘密/机密/绝密)，是通用档案密级非IP配方/工艺/客户名单密级+接触人员访问日志+离职保密提醒。IP许可/转让/共同开发合同特殊审批(许可范围/地域/royalties)无专门实现。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "5. 诉讼与仲裁管理",
   "verdict": "PARTIAL",
   "gap": "律所/律师独立档案、案件费用归集+财务联动、法律文书在线归档全文检索、关键期限(举证/开庭/上诉)自动提醒 均缺失。",
   "severity": "med",
   "evidence": "维持初判。LitigationCaseController 有案件登记、阶段流转(诉前调解→…→执行→已结案)、结案、按角色/结果的统计与胜诉率，是案件管理的良好实现；但(a)律所/律师独立档案缺失——LitigationCase 实体上 lawyer/lawFirm 为纯字符串字段，无专业领域/收费标准/历史胜诉率/代理合同的独立档案实体(domain 下 grep 律所/律师档案 仅命中 LitigationCase.java 自身)；(b)案件费用管理缺失，grep 律师费/案件费用/诉讼费/保全费 全库零命中，无费用归集+财务联动预算控制；(c)法律文书仅靠 remark 字段，无起诉状/答辩状/判决书在线归档全文检索；(d)关键期限提醒缺失:仅单个 keyDate 字符串，advance() 只是手动推进阶段，无举证/开庭/上诉期限自动预警。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "6. 法律咨询与内部服务",
   "verdict": "PARTIAL",
   "gap": "法律意见书在线审批签发归档、法务知识库(常见问答/案例/审核要点检索)、培训管理(计划/参训/考核) 均缺失。",
   "severity": "med",
   "evidence": "维持初判。LegalConsultController 实现了法律咨询工单 CRUD+分派(assign)+答复(reply,回填法律意见置已答复)的闭环；但(a)法律意见书(重大项目/新业务出具+在线审批/签发/归档)缺失，grep 法律意见书/意见书 全库零命中；(b)法务知识库无专属实现——工单无'常见问题知识库自动解答'，无典型案例/审核要点/法规解读按关键词检索的知识库实体；(c)培训管理缺失，grep 培训 命中的是资质申报/员工档案/IT预算等无关模块，无合规/合同/IP培训计划+参训+考核实体。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "8. 制度与授权管理",
   "verdict": "PARTIAL",
   "gap": "制度库(在线库/版本受控/合规审核发布/阅读记录留痕)、制度修订废止流程、管理授权登记+超授权拦截预警 全部缺失。",
   "severity": "high",
   "evidence": "维持初判。制度库完全缺失:grep 制度库/阅读记录 仅命中 Rectification.java 第66行一句备注示例('制度修订/流程优化'文字)，Policy/PolicyApplication 实体是政府申报政策库非公司制度/流程/标准在线库，无版本受控+法务合规审核发布+员工查阅阅读记录留痕，制度修订与废止流程亦缺。授权管理完全缺失:grep 签署限额/超授权/授权额度/审批限额 仅命中 SoftwareLicenseController(软件许可席位'不超授权数量'校验，是软件license非管理人员合同签署/费用审批/投标授权限额)，无超授权自动拦截或预警。印章管理有 Seal/SealUse 控制器覆盖。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "9. 与其他部门的接口要求",
   "verdict": "PARTIAL",
   "gap": "供应商黑名单+合同发起自动校验、客户涉诉自动预警、竞业限制/劳动纠纷协同、诉讼赔款入账与保函联动、申报合规性审查对接 均缺失。",
   "severity": "med",
   "evidence": "维持初判。采购供应商黑名单校验缺失——Supplier 仅 status=合格/准入中/停用，无黑名单值，无合同发起时自动校验(grep 黑名单 命中的 RdServiceAgency 是研发服务机构状态、HtmlSanitizer 是XSS黑名单，均非供应商)。客户涉诉信息自动预警缺失——CustomerCreditController 是应收占用风控，全文无 涉诉/诉讼 引用。员工竞业限制管理缺失(grep 竞业 全库零命中)、劳动纠纷案件协同未见专属。财务侧诉讼赔款罚款入账/保函保证金与法务联动未见专门对接(BidBond/BidDeposit 是投标保证金，非诉讼保函联动法务)。申报合规性审查(无违法违规证明)未见对接。合同法务审核条款 走通用审批可部分覆盖。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部 / 法务风险部/法务合规中心（legal）/ 合同中心（contract）/ 审计监察（audit）",
   "module": "10. 外部数据接口",
   "verdict": "LOGIC_GAP",
   "gap": "企查查/天眼查/国家企业信用公示、裁判文书网、北大法宝/威科先行法规库、人行/第三方征信 四类真实外部采集适配器全部缺失，仅 MockSyncAdapter 占位。",
   "severity": "high",
   "evidence": "维持初判。对接框架(IntegrationController/IntegrationExecutor/SyncAdapter/ExternalSystemConfig/DataSyncLog)是通用占位:service 下仅 SyncAdapter.java(接口)+MockSyncAdapter.java(模拟)两个实现，IntegrationExecutor.resolveAdapter 注释自承'模拟阶段统一回退 mock，真实适配器接入后自然分派'，无任一专用真实采集适配器。grep 企查查/天眼查/裁判文书/北大法宝/威科/征信/涉诉 在 web 与 service 全部零命中。CrawlSource/CrawlJob 是招投标情报采集(政府采购平台等 sourceType)，非法务外部数据源。企业信用信息查询、裁判文书网检索、法规库自动更新、征信评分 四类外部接口全部缺失。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "1. 审计计划与资源管理",
   "verdict": "PARTIAL",
   "gap": "缺年度审计计划(按风险/重要性定项目)及审批流；缺审计人员资源池(资质/专长/可用时间)与排程冲突检查；缺审计项目预算(差旅/外聘/软件)及费用报销关联；立项无审批门控。维持 PARTIAL。",
   "severity": "med",
   "evidence": "AuditProjectController.java + domain/AuditProject.java 仅有项目立项 CRUD：字段只有 name/auditType/auditee/leadAuditor/period/findings/status，create 默认 status=计划，无任何审批门控（无 WorkflowService 接入）。全后端 grep 年度审计计划/风险等级排序/资源池/排程冲突/审计预算/差旅外聘软件费 均无实现；无审计人员资质·专长·可用时间表，无排程冲突检查，无项目预算与费用报销关联。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "2. 审计项目实施管理",
   "verdict": "PARTIAL",
   "gap": "8 子功能仅 2 项达标(发现登记+沟通确认)。缺审计通知签收/方案与程序库/资料收集跟踪/工作底稿(复核·版本·模板)/审计证据管理/审计报告自动生成。维持 PARTIAL。",
   "severity": "high",
   "evidence": "仅 AuditFindingController.java 落地审计发现登记(自动编号 AF-yyyy-NNN)+沟通确认(feedback/confirm)+根源分析+确认后自动派生整改任务。AuditFinding 域含 factBasis/violatedRule/amountInvolved/severity 等发现要素。但全后端无审计通知书/被审计单位签收(grep 审计通知/签收 0 命中相关控制器)、无审计方案与标准程序库、无资料收集请求与上传状态跟踪、无工作底稿(grep 底稿仅 AuditFinding docstring 提及非独立实体/版本/组长复核)、无审计证据管理(水印/防篡改哈希/全文检索)、无审计报告自动生成。EvidenceController.java 经核实为 /api/oa/rd-projects 的研发证据链(立项-费用-知识产权-申报)非审计证据。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "5. 经济责任审计（离任审计）",
   "verdict": "LOGIC_GAP",
   "gap": "有承载页但核心逻辑全空：纯 setting-store 假数据手填。缺自动触发立项/指标体系/ERP 自动采集/自动评价生成。维持 LOGIC_GAP。",
   "severity": "high",
   "evidence": "前端 audit/economic.vue 用 settingListStore('audit-economic', [...]) 键值表纯前端 CRUD，硬编码 mock 假数据(张语嫣/某分公司经理)，列只有 auditNo/target/post/auditType/period/status。后端 grep 离任 0 命中；经济责任 仅命中 AuditProject 的 auditType 枚举值与 DataSeeder 种子，无任何专属实体/逻辑。无依据人事任免文件自动触发、无内置评价指标体系、无从 ERP 采集数据(收入/利润/资产损失/违规处罚)、无据数据自动评价与复核。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "6. 舞弊风险监测与调查",
   "verdict": "PARTIAL",
   "gap": "举报+处理流程+调查记录达标(约半)。缺舞弊专属预警规则/自定义比对模型/按案独立调查空间对象级隔离/证据加密；二维码仅为渠道枚举值无真实扫码入口。维持 PARTIAL。",
   "severity": "med",
   "evidence": "FraudReportController.java 实现举报登记(FR-yyyy-NNN,匿名隐去举报人)+分配调查+追加调查记录(保密)+结案/驳回闭环；FraudReport.reportChannel 枚举含「二维码」(故举报渠道字段层面存在二维码,纠正初判'入口缺'为渠道值存在但无真实扫码落地页)。但 MonitorService.java 五种规则(大额付款/超预算/费用临近限额/应收逾期/供应商集中)为通用持续监控非舞弊画像；无'同一供应商价格异常波动''员工个人账户与公司账户异常往来'等舞弊专属规则；无审计人员自定义数据比对模型(考勤vs门禁/报销vs行程单);写口仅全局 ADMIN/APPROVER 门槛(见 docstring),无按案的独立调查空间对象级隔离,无证据加密存储。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "8. 审计数据分析（CAATs）",
   "verdict": "MISSING",
   "gap": "整模块未实现交互式 CAATs：缺在线取数(过滤/抽样)/模型库(本福特/趋势/比率/关联方/重复付款/价格对比)/可视化/连续审计。MonitorService 规则扫描不等同 CAATs。维持 MISSING。",
   "severity": "high",
   "evidence": "全后端 grep 趋势分析/比率分析/关联方/价格对比/散点/分析模型/抽样/连续审计/本福特(benford) 在 audit 模块 0 命中。命中的 SettlementController 仅有结算中心拟付款风控的'重复付款'拦截(同收款方同金额近7天)——是单条硬编码付款前闸非审计 CAATs，不在审计模块、无数据提取/抽样/模型库/可视化。其余命中(MarketIntel/ItServiceTicket 的'趋势分析')是别中心看板文案。无审计人员在线提取 ERP 数据(过滤/抽样)、无分析模型库、无可视化分析、无高频连续审计。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "9. 审计档案与知识库",
   "verdict": "MISSING",
   "gap": "四子库全缺：审计档案库/审计发现库/审计程序库/法规制度库均无实现。维持 MISSING。",
   "severity": "med",
   "evidence": "全后端 grep 审计档案/审计程序库/审计发现库/法规制度库 0 命中(仅 ItKnowledgeController/ItKnowledgeArticle 命中,经核实为信息中心 IT 知识库非审计)。无按年度+类型自动归档的审计档案库(项目底稿/报告/证据/整改记录)、无审计发现库(历史问题检索复用)、无各业务循环标准审计程序库、无内置法规制度库快速查阅。底稿模块本身缺失(见模块2)使档案库无源可归。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "10. 合规与质量保证",
   "verdict": "PARTIAL",
   "gap": "四子项仅权限隔离达标。缺独立质量复核/审计人员独立性(利益冲突)自动校验/审计委员会报告自动生成器。维持 PARTIAL。",
   "severity": "med",
   "evidence": "权限隔离部分达标：OperationAuditLogController 哈希链不可篡改留痕+SENSITIVE_READ_PREFIXES 门禁；FraudReport 举报权限隔离。但全后端 grep 利益冲突/独立性(independence) 仅命中 WorkflowService/NodeAssigneeResolver 的英文 'independent/independently'(算法描述)与审批自批闸,非审计人员独立性管理;无审计人员与被审计单位利益冲突/曾任职/亲属关系自动校验提示更换。无独立质量复核(指定复核人查程序/证据/底稿规范性记录意见)实体或端点。AuditDashboardController 仅跨表内存聚合概览(在审/待整改/完成率/风险分布),docstring 提'审计委员会报告'但无季度/年度报告自动生成器。被审计单位不可查底稿因底稿模块缺失无从校验。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "内控部/审计监察部",
   "module": "11. 与其他部门接口要求",
   "verdict": "PARTIAL",
   "gap": "接口仅打通财务/结算少数对象。多数被审计部门(采购/销售/生产/人力/法务/申报/各业务自评)数据未通用接入审计侧取数。维持 PARTIAL。",
   "severity": "med",
   "evidence": "CostAuditTraceController.java(/api/oa/cost-audit) 跨模块只读聚合合同/结算/发票/付款并支持上下溯钻取,MonitorService 读 payments/budgets/expense-claims/ar-ap-items 供规则扫描——接口仅覆盖财务/结算少数对象且服务于监控/成本追溯。IntegrationController(/api/oa/integrations)经核实为通用 DataSyncLog 同步任务队列框架(source/target/entity/direction),非审计侧取数。无会计凭证/账簿/科目余额/固定资产卡片;无采购供应商主数据/订单/入库单/发票全量;无销售客户/订单/出库/收款;无生产工单/领料/工时/废品;无人力员工档案/薪酬/考勤/绩效/劳动合同;无银行流水/票据台账/内部拆借;无合同台账/诉讼/合规处罚到审计侧;无申报材料/补贴;无内控自评问卷与整改反馈统一对接。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "1. 宣传计划与预算管理",
   "verdict": "PARTIAL",
   "gap": "通用 Supplier 缺品牌专属档案(资质/合作历史/报价/服务质量评价)与比价/招标。计划与项目预算 MET。",
   "severity": "med",
   "evidence": "计划/项目/预算核心确为完整 MET：BrandPlanController 有计划审批状态机(草稿→审批中→已批准→执行中→已完成)+预算总额/占用/可用余额聚合(/{id}/budget)；BrandProjectController 立项占用计划预算并做超额校验，报销审批通过累加 spentAmount 并联动生成资金支付中心待付付款单(domain Payment, @Transactional)。但供应商子项确缺品牌侧承载：domain/Supplier.java 仅 name/creditCode/category/contact/phone/bankName/bankAccount/status，无广告/媒体代理/印刷/视频供应商的资质/合作历史/报价/服务质量评价字段，亦无比价/招标流程端点。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "3. 媒体关系管理",
   "verdict": "LOGIC_GAP",
   "gap": "媒体库台账亦无独立实体；媒体沟通记录/投放管理/媒体简报三项采集与效果对比逻辑全空。",
   "severity": "med",
   "evidence": "全域搜索 domain/ 与 repository/ 无任何 Media/Press/Journalist 实体或控制器(ls domain|grep ^Media/^Press 空；'媒体'命中均为 BrandExpense.costType/BrandProject 等业务文本里的'媒体投放费'字样，非档案实体)。无媒体沟通记录(采访/发稿/邀请+定期联系提醒)实体，无媒体投放管理(版面/时段/费用/排期+阅读量/转载量效果对比)实体，无媒体简报自动抓取分类逻辑。CrawlSource/CrawlJob 属统一情报中心(sourceType=政府采购平台/公共资源交易中心，产出 newIntel 招投标情报)，与媒体关系无任何接线。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "4. 活动策划与执行",
   "verdict": "PARTIAL",
   "gap": "嘉宾/物料/现场管理三子功能仅以 EventTask.category 占位，无对应数据结构与采集逻辑。",
   "severity": "med",
   "evidence": "BrandEventController 活动立项/任务分解/状态机/总结评估(实际 vs 预算 costVariance, /{id}/board 进度逾期聚合)确实 MET。但嘉宾确无独立实体：domain/EventTask.java 仅 name/category(场地/物料/嘉宾/媒体/现场执行/其他)/assignee/dueDate/status/remark，'嘉宾'仅是 category 字符串占位，无嘉宾名单/电子邀请函/出席确认统计结构；无活动物料清单/制作进度/库存/领用实体(MaterialIssue 属制造领料)；无现场签到(二维码/人脸)/照片视频上传/流程实时记录(MobileCheckin 是员工外勤打卡，无 eventId/嘉宾关联)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "5. 舆情监测与危机管理",
   "verdict": "LOGIC_GAP",
   "gap": "舆情自动抓取缺失、预警无主动 push、危机预案未建模，自动采集与预案联动逻辑空。",
   "severity": "high",
   "evidence": "SentimentController 仅手动 POST create 录入(SentimentRequest)，无任何抓取入口；CrawlSource/CrawlJob 是情报中心招投标抓取(产出 newIntel)，未写入 SentimentRecord(零接线)。alerts 端点仅按情感='负面'+敏感词/热度阈值做只读分级查询排序，无主动推送：service/ 与 ws/ 全域 grep 'sentiment' 为空，无 WebSocket/通知 push。危机应对预案无独立实体：CultureCaseController 是项目知识案例库(经验教训/复盘)，非危机事件库/口径/发言人/行动步骤预案；处置仅靠 SentimentRecord.measure 自由文本，无触发时快速调用预案。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "6. 品牌资产管理",
   "verdict": "MISSING",
   "gap": "品牌标识/品牌应用审核/荣誉资质库(品牌侧)/宣传物料库存 四子功能均无对应实现。",
   "severity": "med",
   "evidence": "全域无品牌标识(LOGO/标准色/标准字/形象图规范+授权版本下载)实体或控制器(grep 品牌标识/标准色/logo规范/VI规范 空)；无品牌应用审核(名片/PPT/背景板合规提交审核)流程；CultureAwardController 是项目评优/激励(安全考核资格校验+奖金发放)，非对外宣传用的荣誉资质库(颁发机构/时间/证明文件)，缺品牌侧承载；'宣传物料'仅在 CultureGoal 文本中出现，无宣传册/手册/礼品/纪念品的库存/领用/补货专用实现(InventoryItem/MaterialIssue 属制造与库存域)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "8. 协同与接口",
   "verdict": "PARTIAL",
   "gap": "申报服务部/经营部/技术研发部/人力资源部四条协同接口缺自动联动，仅财务、法务两条落地。",
   "severity": "med",
   "evidence": "财务接口已落地：BrandProjectController 报销审批通过联动生成资金支付中心待付付款单(domain Payment, payType=宣传费用, @Transactional)。法务接口已落地：ContentReviewService 审核级链 level-2='法务'，内容发布前法务合规审核进流程。其余四条均无自动取数：BrandDashboardController 只读聚合仅限内部品牌模块(预算/发布日历/活动进度/舆情)，不拉申报/经营/研发/人力数据；TriggerRuleEngine 中 brand/content/sentiment/culture 关键字零下游规则，无跨部门自动联动。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部 / 宣传部/品牌推广部 / 宣传部",
   "module": "9. 移动端应用",
   "verdict": "LOGIC_GAP",
   "gap": "内容审核/活动签到承载错位，舆情推送与发布日历移动视图缺自动联动/专用承载。",
   "severity": "med",
   "evidence": "内容审核承载错位：MobileApprovalController 是只读聚合通用 FormInstance 待办队列(按当前办理人过滤)，不读 ContentController(content-pieces 审核状态机)/CultureStoryController(culture-stories 审核)的内容/文案/设计稿审核流，二者各自独立无对接。活动签到错位：MobileCheckin 是员工上班/外勤/拜访/下班自助打卡(含经纬度隐私收口)，无 eventId/嘉宾确认联动。舆情实时推送无实现：SentimentController.alerts 仅只读分级查询，service/ws 全域无 sentiment push。发布日历无移动端专用承载(仅 BrandDashboard /calendar 通用聚合)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部/项目文化",
   "module": "2. 项目宣传与故事挖掘",
   "verdict": "PARTIAL",
   "gap": "缺 PublicityTask 任务下达与完成跟踪实体；缺独立分类素材库实体与全文检索；缺简报/月刊自动汇总生成并推送全员/客户。已实现：故事采集(图文/短视频 mediaUrls)+多级审核状态机(项目负责人→文化部→[法务]→发布)+渠道发布+故事奖励回写项目文化预算。",
   "severity": "med",
   "evidence": "尝试反驳后维持。(1) 无 PublicityTask 实体：grep 全库无 PublicityTask；唯一带『宣传任务』字样的 BrandProject.java/BrandProjectController.java 是品牌推广部把『一场展会/一篇报道』当作有预算的独立项目立项（状态机 立项/执行中/已完成/已取消 + 计划预算占用 + 报销联动），并非『为项目部配宣传员、下达周报/专访/纪实任务并跟踪完成情况』的任务实体；CultureGoal 仅有 targetStoryCount/targetArticleCount 目标数量值，非任务下达跟踪。(2) 无独立素材库：活体 GET /api/oa/brand-materials、/material-library 均 404；CultureStory 仅有 mediaUrls 字段（分号分隔 URL），无按项目/时间/类型分类的素材实体，CultureStoryRepository 只有 findByStatus/findByProjectCode/findByCategory，无全文检索方法；统一 FTS5(FullTextSearchService) 注入 11 个 repo（事项/公告/讨论/调查/纪要/合同/供应商/客户/公司/文档/协作文档），不含 CultureStory。(3) 无简报/月刊自动汇总推送：channel 字段可取『项目简报』只是字符串枚举值；CultureStoryController 无任何汇总生成/推送端点，活体 POST culture-stories/monthly|briefing|newsletter 均 405（落到 /{id} 模式），grep 月刊/简报 仅命中该字符串字面量。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部/项目文化",
   "module": "6. 项目文化资产归档",
   "verdict": "MISSING",
   "gap": "缺项目完工自动打包文化资产归档；缺文化年报自动生成；缺数字展厅/文化墙(地图/时间轴)。整模块零实现。",
   "severity": "med",
   "evidence": "尝试反驳后维持。整模块无承载：domain/ 与 web/ 下无任何 culture-archive/asset/yearbook 实体或控制器，grep 文化档案/文化年报/资产归档/打包归档 全库无命中；活体 GET /api/oa/culture-archives、/culture-yearbook、/culture-assets 均 404。无『完工后自动打包文化资产(宣传稿/照片/视频/案例/评优/调查)归档至文化档案库』，无『文化年报自动生成』，无『数字展厅/文化墙(地图/时间轴)』。注意 CultureAwardController 的 honor-wall(荣誉墙) 属需求模块4评优激励的历年表彰展示，非模块6的项目文化数字展厅。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "品牌推广部/项目文化",
   "module": "7. 移动端应用",
   "verdict": "PARTIAL",
   "gap": "缺随手拍即时上传至素材库（无现场拍照上传实体/端点，且素材库本身不存在）；缺活动扫码签到自动统计参与人数（actualAttendees 手填，MobileCheckin 是外勤打卡）；故事投稿/评优申报/满意度问卷仅响应式复用通用 web 端点，无专门移动端表单。",
   "severity": "med",
   "evidence": "尝试反驳后维持。(1) 无随手拍即时上传素材库：活体无 brand-materials/material-library 端点(404)，无现场拍照即时上传实体/端点。(2) 无活动扫码签到：BrandEvent.actualAttendees 注释明确为『已总结时回填』总结手填值，无 EventTask 或活动级扫码签到记录；MobileCheckin.java 注释为外勤打卡(checkinType=上班/外勤/拜访/下班 + lat/lng GPS)，是外勤定位打卡非活动扫码签到。(3) 故事投稿/评优申报/满意度问卷无专门移动端表单：分别复用通用 web 端点 POST culture-stories、culture-awards、culture-surveys/{id}/responses(匿名)，靠响应式 Web 复用，MobileController 仅 /summary 聚合首页待办/预警，无这些专门移动表单端点。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "3. 资质维护与延续",
   "verdict": "PARTIAL",
   "gap": "年检/年报自动任务+在线填报、延续历史复用、变更流程+前后留痕、动态核查一键导出核查报告、升级条件常态监控 五项均无承载，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "QualCertController(/api/oa/qual-certs) 有台账CRUD+状态机(有效/即将到期/已过期/延续中/已撤销 advance)+使用记录+到期分级预警(6/3/1月/15天)；QualDeclarationController 的 declType 支持'延续/变更'类型且 /{id}/gap 能算升级缺口。但逐条核对初判缺项：(1)年检/年报无自动任务生成与在线填报端点；(2)延续无历史数据自动复用；(3)无企业名称/地址/法人变更的变更流程与变更前后信息留痕(QualCert.update 直接覆盖字段,无变更单/前后快照)；(4)无动态核查一键导出全部证明材料+生成核查报告;(5)升级'还差多少'仅在 QualDeclaration/{id}/gap 按申报单算一次,非对企业指标的常态监控。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "5. 业绩管理（资质相关）",
   "verdict": "LOGIC_GAP",
   "gap": "独立业绩库深度结构(质量评定/获奖/证明文件)、关键指标自动提取、跨资质业绩查重、业绩证明人记录 全缺，初判 LOGIC_GAP 准确。",
   "severity": "high",
   "evidence": "找到 MarketQualification 域含'业绩案例'category(field专业领域/amount项目规模/可上传证明 via remark)+ /qualifications/match 按专业聚合可用业绩；QualDeclaration/{id}/gap 与 EligibilityCheckService 会从 project 库读已完工项目当业绩。但这不是独立业绩库结构：MarketQualification 字段只有 name/field/amount/grade，无开竣工时间/质量评定/获奖/中标通知书等结构化字段；无按资质标准自动提取关键指标(建筑面积/处理能力)；无业绩查重(跨资质重复使用检测,grep 查重命中均在 OpportunityDedup 商机域,非业绩)；无业绩证明人(甲方联系人)字段。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "6. 资质使用与投标支持",
   "verdict": "PARTIAL",
   "gap": "投标资质自动检索已部分实现(故由 MISSING 升 PARTIAL)，但 ZIP/PDF一键打包、监管平台真伪验证接口、电子证照二维码 三项确无，仍不达标。",
   "severity": "high",
   "evidence": "初判 MISSING'四子功能全无实现'被部分推翻：①投标资质条件自动检索确有承载——MarketQualificationController(/api/oa/qualifications)的有效期判级+usable可投标标志+/match 按专业领域检索可用业绩与证书，StaffCredentialController 的在建锁定能显示证书剩余可用性，EligibilityCheckController 给定申报类型自动检索是否达标。但②资质+人员证书+业绩一键导出ZIP/PDF打包：全局 grep ZIP/打包仅命中 FraudReport/SewageEquipment 无关项，无导出端点；③对接全国建筑市场监管平台真伪验证接口：无；④电子证照(二维码验证链接)管理：无。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "7. 合规与风险预警",
   "verdict": "MISSING",
   "gap": "资质红线监控、黑名单/失信定期查询、挂靠风险社保校验 整模块无承载，初判 MISSING 准确。",
   "severity": "high",
   "evidence": "全库搜索：红线监控/失信/黑名单/被执行/信用中国/挂靠 在行政资质域均无承载。'失信/黑名单'仅命中 service/SyncAdapter.java(外部对接框架占位,非资质红线)；'挂靠/社保一致'仅命中 OrgBranchController(分支机构,非人员社保校验)；'红线'命中 rd/agencies.vue(研发服务机构,无关)。无注册人员数量不足/安全事故/行政处罚/未按时年报的自动预警推送管理层，无失信被执行人定期自动查询，无人员社保与注册单位一致性校验。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "8. 报表与决策分析",
   "verdict": "PARTIAL",
   "gap": "资质全景图/到期日历/证书标准差距/业绩统计/申报ROI 五张决策报表均无聚合页，仅零散预警JSON，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "找到 QualCert/alerts/expiry、StaffCredential/alerts、MarketQualification/alerts/expiry、ArchiveBoard/stats、AlertController 等零散预警与统计端点；hr/stats.vue 是按部门人数/在岗率的人力统计页(非资质)。但初判所列资质报表均无专属聚合页：无资质全景图(图形化按板块分类展示等级有效期,grep 资质全景/全景图 无命中)；无资质到期日历(未来12月日历视图)；无人员证书按类型/专业/等级 vs 资质标准差距统计；无业绩统计；无申报成本ROI(申报费用 vs 中标额,QualDeclFee 只记费用不关联中标额)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "9. 移动端应用（资质）",
   "verdict": "PARTIAL",
   "gap": "资质专属移动功能(证书查询专页/扫码借出/现场业绩上传)无独立承载，仅响应式间接覆盖，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "前端 mobile 页仅 approval.vue/checkin.vue/workbench.vue；MobileController 是待办/预警/项目数的通用工作台聚合。无资质/人员证书查询专页、无现场证书借出扫码登记、无项目现场业绩(验收报告/照片)手机上传。资质查询/预警接收仅靠整站响应式(responsive.css)间接覆盖 PC 页。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "11. 招聘与人才管理",
   "verdict": "MISSING",
   "gap": "招聘四项AI能力全无，recruit 页为占位 CRUD，初判 MISSING 准确。",
   "severity": "high",
   "evidence": "hr/recruit.vue 是 MasterDataPage 包装的 settingListStore('hr-recruit') 假数据 CRUD 列表(岗位/部门/人数/渠道/候选人/状态)，零 AI 能力。存在通用 AiController(/api/oa/ai/draft|complete|classify) 走 AiService 调 LLM，但未接入招聘场景：无简历关键词/岗位匹配度筛选+初筛报告、无面试话术/笔试题库按岗位生成、无HR提问建议、无入职资料/岗位说明/员工手册AI初稿。grep 简历/招聘/初筛 在后端无招聘AI承载。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "12. 人事流程与档案联动",
   "verdict": "LOGIC_GAP",
   "gap": "承载页与字段齐备但无真自动归档引擎(TriggerRuleEngine 不覆盖HR事件)，入职/转正/调岗/离职/续签自动联动缺失，初判 LOGIC_GAP 准确。",
   "severity": "high",
   "evidence": "StaffDossierController(/api/oa/staff-dossiers)有一人一档(工号唯一)+档案条目归档(9大类)+完整性检查+证件到期预警+离职封存(/archive 置已离职收窄权限)；StaffDossierItem 含 autoArchived/sourceEvent 字段。但关键自动联动缺失被证实：TriggerRuleEngine 只有'项目验收/竣工→自动生成项目档案'一条联动(project.toArchive)，无任何 staff/dossier 联动；新建条目 sourceEvent 默认'手工上传'、autoArchived 默认 false。入职不自动建档归档offer/登记表/合同，转正/调岗/晋升通过不自动归档，离职封存仅是手动 /archive 动作非流程完成自动触发，劳动合同到期只有预警无自动续签+旧合同关联归档。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "13. 档案利用与HR业务支持",
   "verdict": "PARTIAL",
   "gap": "人事档案多条件秒级检索、人事档案借阅审批授权、在职/收入/离职证明自助开具、批量导出 四项均缺，初判 PARTIAL 准确。",
   "severity": "high",
   "evidence": "StaffDossierRepository 仅 findByEmployeeNo/findByDossierStatus，无姓名/工号/身份证/部门/岗位/学历/证书类型多条件组合检索；ArchiveBorrowController 是面向 Archive(综合档案)域的借阅审批，无针对 staff-dossier 的人事档案借阅审批+临时查阅有效期；grep 在职证明/收入证明/离职证明 全库零命中(命中项为 itasset/dept 无关文件)，无证明材料自助申请+模板提取+电子签章+下载；无审计/申报批量导出员工档案端点。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "14. 档案全生命周期管理",
   "verdict": "PARTIAL",
   "gap": "实体档案(库房/盒号/RFID/条码定位/温湿度)、销毁执行+留痕闭环 缺失，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "ArchiveCategory(分类元数据)+ArchiveSubmission(在线归档申请→审核 approve 自动生成'前缀-年度-4位流水'归档编号+按 ArchiveLifecycleService 算保存到期日+落正式 Archive)+ArchiveBoard/retention-alerts(保存期限到期预警)到位。但实体档案管理无承载：grep 库房/密集架/盒号/RFID/条形码/温湿度/盘点 在档案域零命中(仅 DataSeeder/SoftwareLicense/SewageEquipment 无关)；销毁仅有到期预警，无销毁审批执行动作+销毁记录留痕闭环(ArchiveBoard 只列 retention-alert,无 destroy 端点)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "15. 档案利用（借阅与下载）",
   "verdict": "PARTIAL",
   "gap": "在线预览动态水印、禁截图/打印、借阅热度分析 三项缺失，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "ArchiveBorrowController 状态机(待审批→已批准→借阅中→已归还/已驳回)+按密级 ArchiveLifecycleService.approvalLevelOf 分级审批+lend/return 出库归还+ArchiveBoard/overdue-borrows 逾期催还到位。但电子档案在线预览PDF/图片自动加水印(用户名/时间/IP)无实现——ArchiveLifecycleService 仅注释提到'电子档需水印保护',isRestricted 返回布尔,无实际水印渲染；无禁截图/打印控制；无档案借阅次数/热门排行/部门活跃度热度分析(ArchiveBoard/stats 仅按状态/类别计数,非热度排行)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "16. 档案安全与权限",
   "verdict": "PARTIAL",
   "gap": "档案域访问/下载读操作日志、预览/下载动态水印、档案文件哈希存证、通用敏感字段脱敏 缺失；系统级哈希链审计是相邻能力但非档案域落地，初判 PARTIAL 准确。",
   "severity": "med",
   "evidence": "密级定义(公开/内部/秘密/机密/绝密)+分级权限(approvalLevelOf)+PII脱敏(StaffDossier.mask 身份证 410****1234)到位。操作日志维度部分推翻又部分维持：存在系统级 OperationAuditLog+AuditLogInterceptor 哈希链防篡改(verifyChain 创世逐条复算 sha256,不可删改)——这是真存证机制；但 AuditLogInterceptor 只对 WRITE_METHODS(POST/PUT/PATCH/DELETE)落库,GET 读/预览/下载不留痕,故档案域'访问/下载/借阅'专项操作日志未落地；无预览/下载动态水印；无重要电子档案逐份哈希值存证(哈希链是审计日志链,非档案文件 digest)；脱敏仅身份证场景,无银行账号等通用脱敏。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "17. 电子劳动合同",
   "verdict": "LOGIC_GAP",
   "gap": "电子签为商务合同域非HR劳动合同；劳动合同模板、第三方签平台真集成+实名认证、批量发起、签后自动归档 均缺，初判 LOGIC_GAP 准确。",
   "severity": "med",
   "evidence": "EsignController 挂在 /api/oa/contracts 下，面向商务合同 Contract(ContractEsign 含 party 甲方/乙方、外部盖章回执),非劳动合同；其 seal 端点自述'真对接法大大/上上签后续接入,先手工回填'。hr/econtract.vue 是 settingListStore('hr-econtract')假数据 CRUD(姓名/合同类型/期限/签署状态)。无劳动合同/劳务/实习协议模板管理(含法务条款)、无第三方电子签平台真实集成与员工手机实名认证、无新员工批量发起入职合同签署、无签署后自动归档至个人电子档案。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "18. 员工自助服务",
   "verdict": "MISSING",
   "gap": "我的档案查看、纠错申请、个人信息自助更新审核、证书自助上传审核 整模块无员工自助入口，初判 MISSING 准确。",
   "severity": "med",
   "evidence": "无'我的档案'员工本人登录查看入口——StaffDossierController 是HR侧管理端,无按当前登录用户取本人档案的 self 端点;grep 我的档案/纠错申请/自助/个人信息更新 在前端仅命中 itasset/dept 无关文件。无发现错误发起纠错申请、无个人信息(联系方式/紧急联系人/学历)在线更新经HR审核、无员工自行上传新证书经HR审核归档的自助流程。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 综合部/资质管理办 / 综合部（人事档案）/ 资料室",
   "module": "20. 移动端应用（档案）",
   "verdict": "MISSING",
   "gap": "档案专属移动功能(借阅申请/证明自助打印/我的档案/扫码盘点/材料上传)全无独立承载，初判 MISSING 准确。",
   "severity": "med",
   "evidence": "前端 mobile 页仅 approval/checkin/workbench；MobileController 通用工作台聚合。无手机端档案借阅申请、无手机端在职/收入证明自助打印(后端连证明功能本身都无)、无'我的档案'手机查看(连Web自助入口都无)、无档案员扫码盘点实体档案(连实体档案管理都无)、无新员工手机上传身份证/学历证照片。仅整站响应式间接覆盖。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 信息部/信息中心（信息部）",
   "module": "1. IT资产管理（硬件/软件/设施）",
   "verdict": "PARTIAL",
   "gap": "硬件资产缺 serialNo/warranty/barcode-QR；资产生命周期缺调拨/报废/维修工单流转与折旧自动计算与扫码盘点；IT 采购无专属申请→审批→订单→入库→关联预算→供应商专链。软件台账完整。",
   "severity": "med",
   "evidence": "ItAsset.java (domain) 字段仅 assetNo/name/category/spec/holder/dept/purchaseDate/status/location/createdAt — 确无 serialNo(序列号)/warranty(保修期)/barcode或QR(条码二维码)。ItAssetController.java 仅 CRUD，status 是普通枚举(在用/闲置/维修/报废)，无调拨/报废/维修工单流转端点、无折旧计算。前端 assets.vue 同样只有一个 status 下拉，无序列号/保修/条码/盘点/折旧字段。尝试翻案：IpAsset/IpAssetEvent 经核实是『知识产权资产』(专利/商标/软著, 表 ip_asset) 而非 IT 硬件，含 stage/legalStatus 全生命周期但与 IT 资产无关，不能挪用。WorkOrder 是制造生产工单(表 work_order)非资产维修工单。软件台账 SoftwareLicense.java(表 it_software_license) 确实完整：licenseType/seats/assignedSeats/activationKey/expiryDate/annualFee+到期预警+超许可预警。IT 采购无专属流，仅通用 AdminRequisitionController(/api/oa/admin-requisitions) 兜底。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 信息部/信息中心（信息部）",
   "module": "2. 系统运维与监控",
   "verdict": "PARTIAL",
   "gap": "缺日志管理中心(系统/安全/操作日志按级别关键字检索+合规留存)；缺备份与恢复(策略/成功失败状态/恢复演练记录)；巡检无每日/每周自动报告；缺高可用与容灾(集群/双机热备/异地容灾/故障切换/容灾演练)；告警无短信/邮件外发。",
   "severity": "med",
   "evidence": "ItMonitorController.java + ItMonitorItem/ItInspection 实现监控项阈值配置+巡检读数自动评估(正常/告警/故障)+回写最近态+overview/alerts 看板，确为系统健康监控。但告警仅在系统内标态(alerted=true / lastStatus，/alerts 端点返回清单)，evaluate() 只算 result 无任何短信/邮件外发通道。/inspect 是逐条人工/单点录读数，无每日/每周自动生成巡检报告端点。全仓 grep 无 backup/恢复/容灾/disaster/集群/双机热备 任何实体或控制器(domain 目录无对应类，web 目录无对应端点)，日志中心仅有内部 OperationAuditLog/AuditLogInterceptor(操作审计)非 IT 系统/安全日志集中检索中心。尝试翻案未果。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 信息部/信息中心（信息部）",
   "module": "4. 网络与信息安全",
   "verdict": "MISSING",
   "gap": "整块缺失：网络拓扑管理、安全设备管理、漏洞与补丁管理、安全事件与应急响应、权限与账号审计台账+HR离职自动禁用联动、数据安全(加密/脱敏/DLP/导出审批)、安全培训(演练/考试)。仅有被动的『停用即失效』登录校验。",
   "severity": "high",
   "evidence": "全仓精确 grep + domain 目录通览：无 topology/拓扑/VLAN/IP段/firewall/防火墙/VPN/IDS/IPS/上网行为 任何实体或控制器；无 vuln/漏洞/patch/补丁 实体；无 secevent/安全事件/应急响应 实体(EhsIncident 是 EHS 安全生产事故非信息安全事件)；无 account-audit/权限审计台账；无 DLP/数据脱敏/加密/数据导出审批 实体；无安全培训/钓鱼演练/安全考试 实体。web 目录 grep api/oa/(backup|topology|network|firewall|vuln|patch|sec-event|account-audit) 零端点。HR 离职自动禁用账号：AuthService 仅登录时拒 isEnabled=false，UserController.enabled 为手动标志，TriggerRuleEngine 无任何 IT/账号联动规则，Handover/StaffDossier 无 IT 账号字段或自动禁用逻辑。前端 itservice.vue 『IT服务与安全』标签下仅工单请求类型含『权限申请/账号开通』(工单分类)，无任何安全管理实体支撑。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 信息部/信息中心（信息部）",
   "module": "6. 与其他部门接口要求",
   "verdict": "LOGIC_GAP",
   "gap": "5 条部门接口大多缺自动联动：HR 入离职/岗变与 IT 账号开通/禁用/调权无自动触发(仅被动停用即失效)；采购部 IT 设备采购无专属入口；法务风险部信息安全合规/数据隐私无 IT 对接；业务部门系统需求/数据质量整改无承载。",
   "severity": "med",
   "evidence": "TriggerRuleEngine.java(办结后下游自动联动引擎)经核实仅含用印/合同/投标类业务规则键，无任何 IT/账号/HR 联动规则。HR 入离职/岗变→IT 账号开通/禁用/调权：Handover.java 与 StaffDossierController 无 IT 账号字段，StaffDossier 离职仅置档案『已离职』封存态(第41行)不触发 IT 账号禁用；UserController.enabled 纯手动；无自动触发链。采购部 IT 设备采购无 IT 专属入口(仅通用 AdminRequisitionController 兜底)。法务风险部信息安全合规/数据隐私无 IT 侧对接(无安全合规实体可挂)。各业务部门系统需求/数据质量整改无 IT 承载件。表面有 User/Handover/AdminRequisition 等承载件，但跨部门自动联动逻辑基本为空。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 信息部/信息中心（信息部）",
   "module": "7. 移动端应用",
   "verdict": "PARTIAL",
   "gap": "无 IT 专属移动能力：服务工单缺移动接单/拍照反馈专用流；资产盘点缺扫码盘点(无扫码接口+无 ItAsset barcode 字段)；监控告警缺手机推送(无 push 通道)；IT 审批仅通用兜底未专门绑定。",
   "severity": "med",
   "evidence": "MobileController.java grep 无 it-ticket/it-asset/it-monitor/工单/盘点/scan 任何 IT 集成。无 IT 专属移动接单/拍照反馈流(ItServiceTicket 实体本身无 photo/screenshot 字段，移动端无专用端点)。资产扫码盘点缺失：ItAsset 无 barcode 字段，全仓无扫码接口，前端 IT 页无扫码(仅 admin/visitor 与 audit/fraud 有 scan 相关，与 IT 无关)。监控告警手机推送缺失：无 push 通道，ItMonitor 告警仅系统内 alerted 标态。审批可经通用 mobile-approvals 兜底但未见与 IT 采购/权限申请专门绑定。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "1. 非生产性物资管理（办公/劳保/清洁用品）",
   "verdict": "PARTIAL",
   "gap": "缺『采购计划与申请』整条子链：各部门在线提交物资采购申请(品名/数量/用途/预算)→系统汇总生成采购计划→审批后转采购执行。无采购申请实体/端点，无采购计划汇总，入库未与采购计划挂钩。",
   "severity": "med",
   "evidence": "AdminSupplyController.java(316行)实现物资分类档案(规格/单位/参考单价/安全库存/批次)、入库登记(inbound)、出库领用(outbound)、低库存预警(/alerts/low-stock)、批次有效期预警(/alerts/expiry)、费用分摊(/cost/allocation 按部门归集出库金额)；AdminRequisitionController.java实现领用申请+定额控制(AdminQuotaService.evaluate 超定额→待审批→approve/reject)+issue出库级联。但全后端无『采购申请/采购计划/采购执行』链：grep 采购|purchase|procure 在 web/Admin*.java、web/Logistics*.java、domain/Admin*.java 仅命中 AdminVehicle 的 purchaseDate(车辆购置日期，非采购流程)。入库 inbound 是手工登记数量/金额/供应商，非由部门采购申请→汇总采购计划→审批驱动。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "2. 日常行政工作优化（AI整理会议纪要/公文/周报月报/决策待办）",
   "verdict": "LOGIC_GAP",
   "gap": "缺四条专用自动流水线：①会议纪要AI自动整理→提取关键信息生成文档→自动发送到指定位置(无发送/自动端点)；②固定格式公文AI自动生成并优化(无公文模板套用)；③多部门周报/月报AI自动汇总(后端零承载)；④决策纪要/待办/跟进节点自动整理并同步(无 minute→todo 自动派生)。",
   "severity": "med",
   "evidence": "AiController.java 仅5个通用端点：/complete、/draft、/classify、/summarize、/risk，底层统一走 AiService 调 LLM，无任何专用流水线。MeetingMinuteController.java(97行)只有 list/create/update(PATCH 改标题/正文/状态/decisions)/delete，无 ai/自动整理/自动发送端点，content 由前端传入并 HtmlSanitizer.sanitize，非AI提取关键信息生成。全后端 grep 周报|月报|weeklyReport 零命中。无 minute→待办自动派生逻辑(decisions 是手填字符串字段)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "3. 培训学习（AI生成岗位培训题库/学习资料/定制化学习路径）",
   "verdict": "LOGIC_GAP",
   "gap": "AI生成岗位培训题库、学习资料与定制化学习路径逻辑完全空；承载页存在但无后端 AI 生成与学习路径能力。",
   "severity": "med",
   "evidence": "全后端 grep 题库|questionBank|学习路径|learningPath|培训题|岗位培训|学习资料|courseware 在 web/domain/service 零有效命中(仅 FavoriteController.java 把『学习资料』当作收藏夹名称字符串常量，与培训无关)。无任何培训/题库/学习路径控制器或实体。training.vue 仅为 settingListStore mock 台账，不调 AI 生成题库、不生成学习资料、无定制化学习路径算法。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "4. 车辆管理（通勤/公务车）",
   "verdict": "PARTIAL",
   "gap": "缺①违章管理(违章记录登记并通知责任人)；②通勤班车管理(固定线路班车排班/实时位置/乘客统计)；加油费用仅归还时记，无独立油卡/维修/保养/年检/罚款费用台账。",
   "severity": "med",
   "evidence": "AdminVehicleController.java(403行)实现车辆档案(车牌/品牌/座位/保险/年检/保养到期/里程)、用车申请→派车(冲突检测 overlaps)→出车(depart)→归还(自动算里程与百公里油耗)、到期分级预警(/alerts/expiry 保险/年检/保养)、用车费用分摊(/cost/allocation)。但 ReturnRequest 仅含 endOdometer/fuelLiters/fuelCost/tollFee/parkingFee，无违章罚款字段；全后端 grep 违章|violation 零命中，无违章实体/端点/通知责任人；grep 班车|shuttle|commute 零命中，无通勤班车排班/位置/乘客统计；无独立油卡/维修/保养费用台账(费用仅在归还时一次性记 fuelCost/tollFee/parkingFee)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "5. 宿舍管理",
   "verdict": "PARTIAL",
   "gap": "缺①维修报修(住宿员工在线报修故障描述/拍照→派工→维修确认闭环，宿舍专用)；②宿舍检查(定期卫生/安全巡检记录评分/隐患/整改跟踪)。水电费工资扣除标记符合需求。",
   "severity": "med",
   "evidence": "AdminDormController.java(348行)实现宿舍资源台账(楼栋/房间/床位/设施/入住数)、入住/退宿审批工作流(assignRoom 占床/checkout 释床)、水电费录入自动计费(recordUtility 用量×单价)、结清标记(settle，settleMethod 默认『工资扣除』符合需求)、入住率概览(/occupancy)。但全控制器无报修端点：grep 报修|派工|拍照|photo 在 dorm 零命中；LogisticsTicketController.java 是通用后勤工单(报修/用车/保洁/投诉)，非宿舍专用、无拍照/派工闭环。grep 宿舍检查|卫生巡检 在 dorm 零命中，无定期巡检评分/隐患/整改实体。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "6. 保洁与绿化",
   "verdict": "LOGIC_GAP",
   "gap": "缺①保洁排班(每日/每周区域+频次+签到打卡)；②清洁物资领用与保洁排班联动；③卫生巡检(打分/拍照/不合格整改)；④绿化养护(绿植租摆/浇水施肥修剪计划/病虫害)。",
   "severity": "med",
   "evidence": "四子功能全无专用实现：grep 保洁排班|cleaningShift 零命中(无排班实体/签到打卡端点)；清洁物资虽可走 AdminSupply 物资模块但无与保洁排班联动；grep 卫生巡检|hygieneInspect 零命中(无打分/拍照/整改);grep 绿化养护|绿植|租摆|施肥|修剪|病虫害 零命中(无绿化实体)。仅靠 LogisticsTicketController 通用工单(类型含『保洁』)兜底，无排班+巡检+绿化养护核心逻辑。FeedController 的 grep 命中为无关误报(targeted grep 为空)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "7. 安保与门禁",
   "verdict": "PARTIAL",
   "gap": "5子功能仅访客管理落地。缺②安保巡逻(电子巡更点二维码/NFC+扫码签到+路线+异常拍照)；③监控管理(设备台账+录像调阅申请审批+调阅记录)；④出入管理(工卡/人脸门禁记录+外来车辆登记+大件物品带出审批)；⑤安保事件(偷盗/打架/消防闭环)。",
   "severity": "med",
   "evidence": "AdminVisitorController.java(193行)仅落地访客管理：预约(POST)→确认(confirm 生成通行码)/拒绝(reject)→签到(checkin)/签退(checkout)→verify 校验+onsite 在场。门禁记录仅出现在文档注释里描述访客预约，非员工工卡/人脸门禁记录实体。全后端 grep 巡更|巡逻点|patrolPoint|录像调阅|surveillance|门禁记录(实体)|安保事件|securityIncident|偷盗|打架 零有效命中。访客通行码为系统6位数字串(verify端点)，非需求二维码但功能等价。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "8. 接待与会务服务",
   "verdict": "PARTIAL",
   "gap": "缺①周期会议预订；②接待申请(部门申请接待客户/级别/人数/行程/餐饮住宿→后勤安排车辆/餐饮/会议室/礼品)；③接待费用(餐饮/住宿/礼品关联接待任务分摊部门)；④会务服务(席卡/茶歇/签到表/设备调试/现场人员)。",
   "severity": "med",
   "evidence": "仅会议室管理落地：MeetingController.java(177行)实现会议室预订+冲突检测(hasRoomConflict，事务原子 check-then-act)。grep 周期|recurr 在 Meeting 零命中，无周期会议预订。全后端 grep reception|接待申请|receptionTask|席卡|茶歇|teaBreak|placeCard 无接待实体(MealOrderController 的『接待餐』仅为食堂备餐份数统计字段 receptionPortions，非接待申请/费用/会务任务)。无接待费用分摊、无会务服务(物料/设备调试/现场人员)实体。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 办公室/行政后勤中心（凯迪 ERP+OA · admin 模块）",
   "module": "9. 快递与收发管理",
   "verdict": "MISSING",
   "gap": "三子功能全缺：①收件登记(门卫登记收件人/快递公司/单号→自动通知收件人取件)；②寄件申请(在线申请→审批→打印面单→费用归集部门)；③快递统计(月度各部门寄件费用/收件数量成本分摊)。",
   "severity": "med",
   "evidence": "全后端 grep express|快递|寄件|收件登记|mailRoom|parcel|courier|waybill|面单|取件 完全零命中(web/ 与 domain/ 均无)。无收件实体、无寄件工作流、无面单打印、无费用归集、无月度统计聚合端点。整模块无承载控制器与实体。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 后勤/行政后勤中心（客餐接待·员工保障）",
   "module": "1. 食堂管理",
   "verdict": "PARTIAL",
   "gap": "缺①卫生与安全检查模块（每日留样记录/餐具消毒记录/卫生检查表在线填写+拍照上传，无实体无端点）；②成本核算只算食材费，缺人均成本(食材+燃料+人工)/对比餐标/福利费归集/按部门分摊餐成本。",
   "severity": "med",
   "evidence": "维持初判。报餐/订餐/统计/采购建议/菜单/评价/最受欢迎齐全（web/MealOrderController.java、web/CanteenMenuController.java），但两处缺口属实：①卫生与安全检查（留样/餐具消毒/卫生检查表+拍照）全项目零实现——grep 留样/消毒/卫生检查/sanitation/disinfect 在 canteen 系列控制器与实体内零命中；唯二命中是 web/FeedController.java:128『正文消毒』(XSS 净化注释)与 seed/DataSeeder.java:2522『管道试压及冲洗消毒』(施工 BOM 条目)，均与食堂无关；EHS 的 SafetyCheck 是安全检查非食堂卫生。②成本核算：web/MealOrderController.java purchaseSuggestion (L230-275) 仅做食材成本概算=菜品单价×总份数(L261)，无人均成本=食材+燃料+人工三项合算、无对比餐标、无费用归集福利费或按部门分摊；MealOrder.deptName 字段存在但无任何分摊运算端点。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 后勤/行政后勤中心（客餐接待·员工保障）",
   "module": "4. 报表与看板",
   "verdict": "PARTIAL",
   "gap": "缺车辆使用率/油耗趋势/维修费排行专项视图；缺人均餐费+食材损耗率+最受欢迎菜品的食堂成本合并报表；缺满意度各季度趋势与投诉分类统计。",
   "severity": "med",
   "evidence": "维持初判。后勤成本看板 web/LogisticsDashboardController.java 做了预算执行率/科目占比/食材库存临期/服务KPI，但三项专项报表缺口属实：①车辆运行报表——web/AdminVehicleController.java 仅 /cost/allocation (L340-369) 按部门归集油费+过路+停车并按总成本降序，无车辆使用率、无油耗趋势(逐期变化)、无按车维修费排行；fuelPer100km 仅在归还时单条算(L252)不汇总成趋势。②食堂成本报表——/popular (CanteenMenuController L181-208) 有最受欢迎菜品但分散在菜单端点，无人均餐费(成本核算本身缺，见模块1)，无食材损耗率(FoodBatch 有『已报损』状态与 /scrap 端点 L155-161 但无损耗率计算报表)，三项无合并报表。③满意度趋势——无各季度得分变化、无投诉分类统计端点(grep 季度/quarter/投诉分类 在后勤域零命中)。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "行政 / 后勤/行政后勤中心（客餐接待·员工保障）",
   "module": "5. 移动端应用",
   "verdict": "LOGIC_GAP",
   "gap": "移动端缺本模块全部手机自助专属页(报餐/用车查派/报修拍照/访客二维码/满意度问卷/入住退宿)；快递通知功能完全不存在(无实体无端点)；访客仅有文本通行码非二维码且非移动自助。",
   "severity": "med",
   "evidence": "维持初判。移动专属页仅 3 个：oa/pages/mobile/{approval,checkin,workbench}.vue——approval 是审批、checkin 是外勤 GPS 打卡(接 /api/oa/mobile-checkins)、workbench 是工作台，grep 报餐/订餐/用车/报修/访客/二维码/满意度/快递/入住 在 workbench.vue 零命中。本模块要求的手机自助流程均无移动专属页：报餐手机预订取消、用车查派车状态、报修拍照传(LogisticsTicket 实体/控制器无 photo/附件字段)、访客手机预约生成二维码(AdminVisitorController 有 passCode 文本码 L106/genPassCode L187 但无二维码生成且非移动自助页)、满意度手机填、入住/退宿手机提交。admin 桌面页(canteen/visitor/vehicle/dorm.vue)挂 /admin/* 桌面路由非移动自助。快递通知全项目零实现：grep 快递/express/取件/包裹/parcel/courier 唯一命中 service/FullTextSearchService.java:335 是 FTS5 短语查询注释，非业务功能，无实体无端点。",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "工程业务流程：查网→制作标书→开标→领取中标通知书→签订总包合同→施工前准备→施工图审查→材料等分包合同→办理施工许可证→季度考评→竣工备案→资料存档",
   "verdict": "LOGIC_GAP",
   "gap": "链条存在多处断裂，非端到端打通：(1) 三个环节完全无承载——施工图审查、办理施工许可证、季度考评（后端 0 命中，仅前端表单 radio 字段或部门名），点进去无台账/无流程/无状态。(2) 两个环节仅以字段/状态弱表达——领取中标通知书(仅 Bid.status=中标，无通知书实体)、开标(仅 openDate 字段，无开标/评标记录)。(3) 竣工备案缺『备案』动作(只有竣工验收，无报建备案号/状态)。更关键的是自动联动严重不连续：service/TriggerRuleEngine 的下游触发矩阵只覆盖 付款/用印/收款/验收/供应商/合同/立项 七类关键词(L115-134)，唯一贯通的工程自动链是 Bid 中标→自动建 Project+总包合同草稿→合同办结生效→自动待用印(BidController.chainWinBid + ruleEffectivateContract/chainCreateSealUse)，以及链尾 验收→归档(chainArchiveProject)。中间『总包合同→施工前准备(监理项目)→分包合同→许可证→考评→竣工备案』各环节之间没有任何自动流转：监理项目/分包合同均靠人工录 contractId/projectId 建立关联，缺失的三环节更无从联动。整链是『首尾两段各自有真自动联动 + 中段大量人工或空缺』的拼接，而非一条端到端贯通且自动联动的工程业务流。",
   "severity": "high",
   "evidence": "查网（招标信息采集）:有；制作标书:有；开标:部分；领取中标通知书:部分；签订总包合同:有；施工前准备:部分；施工图审查:缺；材料等分包合同:有；办理施工许可证:缺；季度考评:缺；竣工备案:部分；资料存档:有",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "合同流程：供应商入库→系统取模板合同(IT维护)→线上填写→自动化比对→合约部在线审核→进入OA审批→通知合同专员下载/上传盖章→电子签自动进入盖章系统",
   "verdict": "LOGIC_GAP",
   "gap": "两处真正断链:(1)『合约部审核→进入OA审批』缺失——合同草稿/审核结果不会自动提交为 FormInstance 进 WorkflowService,ContractBudgetReview.approve 直接改写合同状态绕过审批引擎,而 TriggerRuleEngine 的合同生效规则依赖另行人工发起的 FormInstance,链路不自动衔接;(2)『电子签自动进入盖章系统』缺失——EsignController.sign 已签后不级联生成/推进 SealUse,seal 端点自述为对接项仅手工回填回执号,ContractEsign 与 SealUse 两套用印数据彼此孤立。次要:模板比对未与起草自动串接(draftBody 未落库、比对靠手工粘贴)、通知对象是发起人而非合同专员、缺下载/上传盖章件的附件接口、合约部审核实为成控预算审核而非条款合规审核。各单点引擎(供应商准入/模板取用/条款比对引擎/成控审核/合同生效→自动建待用印)均已实现,但端到端自动联动在 OA审批入口 与 电子签→盖章 两处断开。",
   "severity": "med",
   "evidence": "供应商入库:有；系统取模板合同(IT维护更新):部分；线上填写:有；自动化比对:部分；合约部在线审核:部分；进入OA审批:缺；通知合同专员下载并上传盖章电子合同:部分；电子签自动进入盖章系统(用印联动):部分",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "资金确认：项目部向甲方请款 → 财务资金到账确认 → 开票 → 应付(应收)入账",
   "verdict": "PARTIAL",
   "gap": "链体前三环(到账办结→自动开票草稿→开具回写合同应收 invoicedAmount)真打通且有幂等+留痕；但需求字面的『入账』缺自动生成总账记账凭证与应收/应付(ArApItem)往来台账：开票回写只停在合同 invoicedAmount，VoucherController 与 ArApController 与发票之间无级联(InvoiceController 不引用 voucherRepo/arApRepo)，记账凭证与往来款须人工补录。另：『请款』无独立实体/台账，靠通用审批+收款表单承载，且 待开→已开 的开具是人工动作而非全自动。注意需求把收款链尾写成『应付入账』(实际应为应收/收入入账)，系统也只做了合同侧应收回写。\"",
   "severity": "med",
   "evidence": "项目部向甲方请款(发起请款/收款审批单):部分；财务资金到账确认(办结触发):有；开票(到账→自动生成销项发票):有；应付(应收)入账(发票回写台账/总账凭证):部分",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "资料流程：项目部(发起)→办事处→资料室→工程中心→法务→董事长→档案室。在本系统中由「表单模板多节点串行流转(FormTemplate.flowSchemaJson)+ WorkflowService.advance 逐节点推进 + TriggerRuleEngine 办结后下游联动 + 资料室在线归档状态机(ArchiveSubmission)」共同承载；前端 archive 档案知识中心模块承载资料室/档案库。",
   "verdict": "PARTIAL",
   "gap": "缺两处端到端打通：(1) 无任何单一模板按需求精确串起全 7 节点顺序——办事处环节在资料/印签流程链上完全缺位(办事处节点只存在于付款/调动类其它模板)，且需求顺序『资料室→工程中心→法务→董事长』与实模板顺序(资料室→质安/成控→工程中心→财务→法人→董事长知会)不完全对齐；(2) 终端『档案室』在印签链上仅是知会节点，办结只 fire seal.markUsed，不自动落 Archive——自动归档(chainArchiveProject)只挂在 project.accept(验收/竣工)，印签资料办结到档案库之间无自动联动，资料入库要靠 ArchiveSubmissionController 人工二次提交审核。整链各环节零件齐备(模板节点+串行流转引擎+资料室落档状态机俱在)，但未被组装成需求所述的单一连贯自动链。",
   "severity": "med",
   "evidence": "项目部(发起):有；办事处:部分；资料室:有；工程中心:有；法务:有；董事长:有；档案室:部分",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "流程驱动/自动触发：表单办结(条件生成) → WorkflowService.finalize → triggerDownstream → TriggerRuleEngine.fire(规则矩阵) → 创建/回写真实下游实体(付款/发票/合同/项目/用印/供应商/档案) + AutomationLog 留痕 + 可配置规则补充触发；前端 /datacenter/automation 留痕页 + /appdev/ruleconfig 规则配置页承载。",
   "verdict": "PARTIAL",
   "gap": "自动触发骨架真实且端到端打通(办结→fire→真写下游实体+留痕+可配置规则+幂等/失败态)，但需求点名的三条规范化/自动化下游流程未接入条件自动触发矩阵：成本风险检查完全缺失(仅有手工成本对比报表)；生产排程/MRP 仅手工 POST 调用、办结不自动排程或生成工单；财务记账只在受闸人工放款 confirmPay 处自动记凭证，办结本身不自动记账(钱权分离设计使然)。现有 7 条链覆盖的是合同/付款/发票/项目/用印/供应商/档案这一行政-资金侧闭环，与需求强调的制造侧『成本风险→生产排程→财务记账』链不重合。AI 化为 0(无 AI 决策介入触发)。",
   "severity": "med",
   "evidence": "办结触发点接线 (finalize→fire):有；规则引擎真实下游联动 (TriggerRuleEngine):有；幂等+失败留痕+可配置规则:有；前端承载页+留痕可见:有；成本风险检查自动触发(规范化/AI化):缺；生产排程自动触发 (MRP/工单):缺；财务记账自动触发:部分",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "跨模块数据自动采集（申报条件自查自动取数 + 研发费用归集证据链自动化）",
   "verdict": "PARTIAL",
   "gap": "读取侧（自查取数+证据链组装）确为真跨模块自动聚合，端到端前后端打通且活体可验；但写入侧未自动化：rd_expense 由人工 POST 录入，voucher 仅自由文本字符串而非财务 Voucher 实体外键，无任何代码路径把财务凭证/付款自动归集为研发费用，TriggerRuleEngine 也未把本链纳入办结自动联动。即\"自动从财务/HR/IP/项目提取数据生成达标清单\"成立，但\"研发费用归集证据链自动化\"只做到证据链自动展示，归集动作本身仍是手工。",
   "severity": "med",
   "evidence": "申报条件自查·跨模块自动读数（财务研发费用/HR人员证件/知识产权/项目 四库取数）:有；自动生成达标/不达标清单（含差距与数据来源）:有；研发费用归集证据链自动组装（项目→费用→凭证引用，按类型汇总）:有；研发费用数据本身自动从财务模块采集（而非人工录入）:缺；办结后下游自动联动写回（TriggerRuleEngine）覆盖本链:缺",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "BOM差异自动核算: 工单领料(MaterialIssue,实际成本原始凭据) → 按物料名/项目聚合回填 BOM 项 actualQty(BomAnalysis.backfill) → 量价差异核算 cost-compare(投标量价 vs 实际量价 → 超支/超量,自动算) → 标准成本台账 StandardCost(料+工+费=标准, 实际−标准=差异,服务端自动算) → 成本中心上卷 rollup/rollup-tree → 前端承载: 量价比对(costcompare.vue)/工程量比对(bom.vue)/标准成本(standardcost.vue)/领料回填面板(mfg/issues.vue)",
   "verdict": "PARTIAL",
   "gap": "『差异自动核算』的『自动』仅指公式自动运算(overrun=实际−投标、variance=实际−标准在读/写时自动计算),整链可读出真实超支数(活体 totalOverrun=59850)。但『实际成本/实际量的自动取数』未真正打通: (1) 标准成本 actualCost 纯人工手填,控制器 javadoc 自承是『框架实现』,料/工/费实际归集来源(生产工单/工时/费用分摊)留给甲方口径未实现; (2) BOM 实际量虽有『从领料自动回填』端点+UI,但触发是手动按钮而非引擎驱动,且活体 material-issues 表为空(matched 0/14),回填无数据可吃,当前超支全靠人工填的 actualQty; (3) TriggerRuleEngine/WorkflowService 对本链零引用,既无办结后自动联动也无 AutomationLog 留痕,与项目其它 7 条正规自动链不同档次。即:核算公式自动✓,数据自动流入✗,引擎联动✗。",
   "severity": "med",
   "evidence": "BOM/工程量清单台账(标准成本基线: bidQty×unitPrice):有；标准成本台账(料/工/费拆分 + 标准成本=料+工+费,自动算):有；实际成本/实际量 自动归集(从生产/领料自动取数,而非手填):部分；差异/超支 自动核算(实际−标准 → variance/overrun):有；自动联动(办结后下游自动触发 / TriggerRuleEngine 引擎驱动):缺；前端承载页 + 跳转:有",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  },
  {
   "area": "逻辑链",
   "module": "三系统数据打通（OA / 财务T+ / ERP 数据共享 + 支付中心写入财务 + 做账数据共享）",
   "verdict": "PARTIAL",
   "gap": "平台『内部』三类数据打通已端到端落地且经活体验证：(1) 统一数据中心跨模块聚合/治理读真数据；(2) 财务多维看板跨台账做账数据共享；(3) 支付中心结算自动写入财务记账凭证（借应付/贷银行，事务内幂等），并由 TriggerRuleEngine 提供办结→下游财务单据的自动联动。对『外部异构系统』的对接也搭好了完整骨架（DataSyncLog 台账 + 状态机执行器 + 适配器接口 + 外部系统名册 + 5 分钟定时拉起 + 前端执行/配置页），状态机/幂等/回写均活体可跑。唯一断点：实连真实『财务T+/外部ERP』的同步通道未实现——仅有 MockSyncAdapter 模拟成功（显式『未实连外部系统』+ TODO），故跨系统这一环是框架在跑、真实数据不出入外部系统。需求所指若是『凯迪平台内 OA/财务/ERP 一体化共享』则已满足；若严格要求与第三方用友T+/独立ERP 真实双向同步，则该环为缺。\",\n\"severity\":\"med\"",
   "severity": "med",
   "evidence": "统一数据中心：跨模块数据共享/总览（DataCenter）:有；做账数据共享：财务跨台账聚合读（FinanceDashboard）:有；支付中心写入财务：付款结算→自动生成记账凭证:有；流程驱动入账联动：办结→下游财务单据（TriggerRuleEngine）:有；三系统对接同步机制：DataSyncLog 台账 + 执行器 + 适配器 + 定时拉起:有；真实外部连接：实连 财务T+ / 外部ERP 的同步通道:缺",
   "survives": true,
   "reNote": "复验失败默认保留",
   "reEvidence": ""
  }
 ]
}