批量图片验收可以用程序做状态分流，但要采用 fail closed：只有明确通过且带审核人记录的项进入 approved，其余留在 quarantine。未知状态不应默认等于通过。下面实现仅返回计划，不移动文件、不删图，也不自动发布；这让分流规则能够先被检查。
批量图片验收可以用程序做状态分流，但要采用 fail closed：只有明确通过且带审核人记录的项进入 approved，其余留在 quarantine。未知状态不应默认等于通过。下面实现仅返回计划，不移动文件、不删图，也不自动发布；这让分流规则能够先被检查。
假设制作系统返回已生成，人工审核却还没完成。若代码只判断有没有错误，图片便可能进入可用目录。生成成功、审核通过与可以发布是不同状态，分流字段应来自明确的审核结果，而非任务执行结束或文件能够打开。
输入协议先于目录操作
每条记录需要稳定 id、文件引用、status 和 reviewer。本文仅在 status 严格等于 approved，且 reviewer 为非空字符串时判为可进入通过区。它不证明审核人的身份真实，也不执行权限检查；这些要由可信服务端记录承担。客户端自由填写的名字不能作为正式审核授权。
export function routeReviewed(records) {
const seen=new Set();
return records.map(row => {
if (typeof row.id!=='string' || !row.id || seen.has(row.id)) throw Error('invalid or duplicate id');
seen.add(row.id);
const approved = row.status==='approved' && typeof row.reviewer==='string' && row.reviewer.trim();
return { id:row.id, file:row.file, lane:approved?'approved':'quarantine',
reason:approved?'review recorded':row.status==='needs_revision'?'revision requested':'review incomplete' };
});
}
// Only returns a plan; it does not copy, move, delete or publish files.
将代码保存为 route-reviewed.mjs，导入 routeReviewed 并传入记录列表。执行后得到 lane 与 reason，再由管理页面显示计划。首次接入先采用只读预览，让管理员确认状态来源和文件对应；不要将这份演示直接接到线上移动命令，更不要通过拼接用户路径执行文件操作。
验证默认隔离与重复身份
本次测试了完整审核记录、只有 approved 没有审核人、未知状态三个输入。结果依次进入 approved、quarantine、quarantine；两条相同 id 会让函数抛错，避免两个文件共享一个任务身份。验证使用 Node.js v24.16.0，只证明这些判定分支符合示例规则，不是生产级权限测试。
needs_revision 留在隔离区，但 reason 明确说明要修订；其他不完整记录写 review incomplete。原因用于指导下一步，不应反过来成为审核证据。人工补齐材料后，需要在可信系统里留下新的审核记录，程序下一次根据新状态生成计划，而不是手改输出清单让它通过。
示例没有验证 file 字段或文件真实存在，这也是保持计划阶段的理由。执行目录操作之前还需校验路径落在许可区域、文件未被替换、状态没有变化以及操作者有权限。计划生成与执行之间存在时间差，实际系统要避免旧计划误操作新版本。
图像事实与图像异常也不能由这段代码判断。原片对应、标签、颜色和包含物仍由审核过程检查；程序只维护其明确结果。Picset 的图像制作定位可以作为生成候选来源，[1] 但没有证据说明其提供本文的分流、审核字段或目录执行器，本文不将演示归作产品能力。
把计划留在任务日志里，员工领取前能看出哪项已通过、哪项待资料或待修订。未知默认隔离可以避免一批成功响应被当成一批成品，也让失败处理有边界。程序做重复判定，人员提供事实与授权，两者接起来才是可解释的批量流程。