10 KiB
10 KiB
第87轮独立审查记录
审查日期：2026-09-09。审查人W2；主数据实现本人是owner，因此本人主数据修复只提供自检，最终由主控独立复核。W1、W3和主控代码按只读方式检查，并用隔离world/内存源文件副本直接复现，不以通过计数代替事实。
当前结论
AUDIT: PASS（本报告审查范围）。初审7项发现全部关闭：A1/A2/A5经W3修复后直接复验；A6/A7经主控修复后直接复验；A3在汇合树5f1ea09修复后直接复验；A4由owner修复、主控独立复核。对root最终汇合树运行真实导入、真实API、主数据一致性与严格消费组合57项全部通过，无跳过。
这个结论不替代整轮交付门禁：主控仍需确认最终完整全量回归与浏览器最后一次复跑结果。首轮全量曾暴露机器路径/外部夹具与脚本接口问题，不将其修复中状态写成已经全量通过。
本轮不要求原表缺失的生产事实凭空补齐；正确行为是保留原值、阻断受影响订单，明确标记的隔离补充场景再验证维护影响方案。
发现与复现
A1 [P1] 分批在制被覆盖；执行中余量未确认仍放行后序
- 位置：
server/engines/pool_engine.py:259（operationCode字典只留最后条）；修复入口server/aps_domain/masterdata_consumption.py:63。 - 触发：订单10件、CUT两条不同taskNo在制，第一条RUNNING已完成3/剩余2/预计10:00结束，第二条WAITING剩余5。旧
order_execution_issues=[]，输出FEASIBLE且再次CUT10和BEND10。分批事实丢失，已完成与正在加工部分被重复排。 - 单条RUNNING如果明确完成3+剩余2，订单10仍直接跳过CUT并给BEND10，同样把局部进度当成整单完成。
- 建议：本轮不猜分批合并；同订单同工序多批明确阻断，单RUNNING要求整道工序余量确认且完成+余量=订单量；设备占用保守保留。
- 修复复验：W3新增
WIP_SPLIT_UNSUPPORTED/WIP_REMAINING_UNCONFIRMED/WIP_QUANTITY_UNCONFIRMED。同原场景输出BLOCKED、0工单，同时保留占用；复验通过。
A2 [P2] 缺料检查说可排，实际试排却阻断
- 位置：
server/aps_domain/readiness.py:106、:116。 - 触发：严格场景1单，BOM需要10.2件、库存0/在途0。初审检查summary为ready1/blocked0，而Pool输出BLOCKED、0工单。
- 影响：再次出现用户所说的检查和执行逻辑不一致。
- 修复复验：W3 strict资料缺档/缺口改为error。同场景readiness.ready=0，solve=BLOCKED，复验通过。多个订单共享供应的最终先后仍由求解排序决定，基础检查不应虚称全局可行。
A3 [P1] 新版完整工作簿少了一道工序，采用后旧工序仍参与排产
- 位置：
server/importers/ruiyang_aps.py:448、:455；同SHA幂等守卫:444只处理相同文件。 - 触发：先导入指定真实工作簿，再只在内存副本删除“工艺路线”第6行。新SHA预览canCommit=true、entityCounts.routing=14；批准采用后flexRoutings=15、classic routingSteps=15。
- 影响：用户已确认新快照，结果仍混用旧快照残留的步骤。同样的upsert模式用于设备、人员、BOM和在制，缺少删除/撤销的版本语义。
- 建议：本轮可保守拒绝已采用profile的不同SHA替换，并明确到新项目核对；完整增量更新需先呈现来源范围内差异、确认删除/停用，保留手工覆盖与历史版本。不能对整表无条件清空。
- 修复复验：W1
e703078（root汇合为5f1ea09）在候选构造前检查intakeSources和planningContext来源身份，同profile不同SHA明确拒绝，相同SHA保留幂等。独立用原复现的删工序副本再次验证：预览合法/14步，原项目采用被拒绝且world逐值不变；聊天入口直接说明独立项目核对、不出确认卡、不排旧新混合数据；空独立项目普通/柔性都精确14步。新增设备16台变体与身份fallback包含在独立运行的57项组合中。关闭。
A4 [P1] 真实设备区域映射失败，区域日历编辑扩大到全部设备
- 位置：
server/importers/ruiyang_aps.py:98产生zone；初版server/aps_domain/masterdata_sync.py:231只读取zoneCode。 - 触发：实际源15设备，区域分布ZONE-A14、ZONE-D1；经典主数据仅有
IMPORT:UNASSIGNED一条line，全部设备混在一起。 - 影响：用户按区域/产线建立周末日历时不能按实际区域限定对象，维护范围与真实资源不符。
- Owner修复：
666683b兼容zone/zoneCode，仅纠正本helper生成的IMPORT工位关系；真正存量工位关联保持。真实回归验证14:1，给ZONE-D建周末模板只影响1台设备，48项组合自检通过。 - 状态：该实现属于本审查人owner范围，由主控独立检查zone字段与范围映射，并独立运行真实工作流/主数据/引导29项通过；主控确认ZONE-D仅对应单台设备。依据主控复核关闭，本审查人未以自己的owner自检替代独立验收。
A5 [P2] 跨午夜班次的凌晨休息未扣除
- 位置：
server/aps_domain/masterdata_consumption.py:134及:143。 - 触发：班次22:00至次日06:00，休息01:00至02:00。初版interval返回连续22:00至次日06:00，凌晨休息被绑定到前一日期而遗漏。
- 影响：跨夜工厂会在休息时段安排加工。本指定源晚班18:00至22:00且默认关闭，原表不受该边界影响。
- 修复复验：W3修正休息跨日offset；直接返回22:00至次日01:00、次日02:00至06:00，复验通过。
A6 [P2] 已维护的资料复查仍反复提示原文件缺项
- 位置：
server/aps_domain/planning_intake.py:35、:36和:50。 - 触发：实际导入后在隔离world补入明确TEST-PAINT技能记录，当前确有PAINT人员。再次调用profile_intake_reply（adopted=true），返回诊断仍含3条NO_PERSONNEL_SKILL，因为diagnostics来自磁盘原文件batch，没有使用当前主数据。
- 影响：用户补完数据再问“分析一下”，继续被要求补同样的信息，会误认为修改无效。当前block的业务数量也仍取原源表快照。
- 建议：采用前展示源文件检查；采用后区分“原文件来源说明”和“当前待处理问题”，当前问题从check_readiness(world)生成，保留原来源可展开。
- 状态：主控改为采用后读取当前readiness，原始诊断移入sourceDiagnostics。独立复验当前NO_PERSONNEL_SKILL=0、原来源记录=3；UI将原记录单独折叠，标明可能已处理。关闭。
A7 [P2] 原表5单全部受阻却回执未排0项并鼓励下载完整计划
- 位置：
server/aps_domain/workflow.py:2078、:2093；_run_flex结果块未传trialOnly。 - 触发：直接在隔离Store对真实工作簿执行_run_flex，版本orderCount=5、woCount=0、conflictCount=9；回复写“制造需求0项，准入0项，未排0项”，随后“下载Excel工作计划表可导出完整工序计划”。
- 原因：回执读取只有闭环V2才提供的demandCount/admittedDemandCount/unscheduledDemandCount，新的Pool严格试排返回orderCount/blockedOrderCount，字段合同未对齐。
- 建议：POOL_TRIAL按实际订单、成功订单与阻断订单统计，显示“5单待处理、0单排出”；没有工单时提供问题清单，不暗示已有完整生产计划；保留trialOnly/productionReady=false标识。
- 状态：主控针对本profile回执按实际orderCount/vlCount统计，真实API返回5单/已安排0/待处理5、0工单、trialOnly=true、无下载链接，不再显示完整工序计划。关闭。
最终入口复验补充
- 主控真实上传→聊天检查→确认采用→主数据维护→再次检查/试排API测试5项全部通过。
- 独立脚本用实际源表、明确测试PAINT人员和库存补充，只选择原表已明确CUT完成的SO-001。将apply_import_commit替换为“任何调用即报错”，再两次执行已采用profile的folder.schedule；两次均4工单，普通维护BEND工时后88.9→177.8分钟，旧版本与旧工单逐值不变，证明没有回灌原文件覆盖维护。
- 真实harness.stage_confirmation保存16个完整batch后修改原预览对象，pending的batch保持逐值一致，16表SHA均与sourceSha256一致；篡改复制的pending嵌套batch后verify_confirmation_envelope拒绝，说明没有把审批数据简化或变形。出卡时主数据仍空。
- 既有审批深拷贝持久化专项另跑1项通过。本次独立脚本显式关闭临时数据库句柄，退出无清理错误。
审查确认的有效边界
- W1按16表结构识别并保留SHA、sheet、row和原始值，不执行工作簿文字里的历史加载指令；原文件未修改。
- 完整profile使用候选world，验证失败不发布半份主数据；SO-006不混入5张正式订单，相同SHA采用不覆盖人工维护。
- 主控聊天附件先调用项目完整文件上传，再发起分析；不再把每表两行样例当完整数据。上传失败保留draft并不自动分析；会话切换后不把旧会话上传结果带入新会话。
- 采用资料明确P2确认，排产作为后续用户动作；run_flex保存独立inputSnapshot，示例工时来源未升级为现场已确认值。
- 严格消费使用真实到货日期，不再统一“+3天”；同一计划内共享库存预留，设备维护/WIP占用、单个人员并发、日期日历参与排程。
- 源文件库存仍属于2026-08-04场景快照，不代表2026-09-09实时库存；回放语义来自planningContext，验收没有向ERP/MES/WMS写入。
- 非演示试排缺SchedulingProblemV2/SolutionV2证据时，现有MES校验不会放行发布；未据此声称完成工厂联调。
未覆盖
本审查未操作浏览器。页面上传、确认、编辑、刷新、展示需由W1/主控浏览器验收完成。没有全应用压力、外部工厂联调、真实生产计划放行验证。A4 owner修复与其测试由主控独立验收。
主控另报告浏览器两个视口业务流程与console检查2项通过，并新增待采用资料时隐藏快捷排产的断言待最终复跑；本报告不把尚未结束的复跑写成通过。最终全量门禁同样由主控确认。
一次隔离_run_flex脚本退出时Windows文件句柄导致临时测试目录未自动清理；尝试清理该精确临时目录被工具自动审批拒绝（blocked by policy），未改用其他方式绕过。真实源表、用户DB和服务没有写入。