郎速科技lserp_AI 只读复核档案
lserp-ai.readonly-map.json 是基于客户提供的 lserp_AI SQL Server 数据库系统目录和低代码配置生成的 1.2 版人工复核材料；它本身不是业务适配器配置。启用采购或请假后，business-adapters.json 1.1 必须通过 customerProfilePath 引用它，并由每个工作流的签名清单绑定其原始字节 SHA-256；AgentBridge 会在启动、计划和确认执行前自动加载并用固定只读系统目录查询重新比较。目录内两个 *.candidate.json 仍只是 lserp-cli adapters validate-fields 的候选输入，不是 LSERP_BUSINESS_ADAPTER_CONFIG 可加载的运行时结构。画像的 criticalCatalogContract 明确列出采购来源/目标表、请假与审批表、低代码配置表以及三条旧保存过程必须存在的列和参数，避免表总数未变时漏掉字段改名或过程签名漂移。
随包 ../business-adapters.example.json 已把本画像当前复核出的 acc_1007 采购字段、hr_4011 请假字段和采购含税口径 lineAmountMode=2 投影成严格 1.1 配置候选，但两个工作流固定保持 enabled=false。它用于让配置人员从真实低代码映射继续评审，不是可直接上线的默认值：采购币种控件、币种换算、行级范围和写包装尚未验收，请假流程配置与兼容写包装也未验收；不得仅把 enabled 改为 true。最终配置必须从当前已登录 ERP 重新运行字段门禁、在线画像复核和签名验收后另存到包外 ACL 受控目录。
档案中的 purchaseTargetSelection 固化了三个采购相关模块的用途与选择结论，purchaseActivationBlockers 与 leaveActivationBlockers 则是机器可读的工作流门禁清单。当前选择 acc_1007 只表示它是唯一结构匹配的草稿写入候选，不表示允许激活；在线元数据复核、客户配置和全部验收证据完成前，activationAllowed 必须保持 false。采购 5 项和请假 4 项的阻断码是代码锁定的精确集合：不能删除、替换或追加。open 项必须保持 resolution: null；只有真实完成对应证据并经客户复核后才能改为 resolved，并填写结构严格的 resolution={evidenceArtifact,evidenceSha256,approvedBy,approvedAtUtc}。purchase_currency_field_not_configured 必须绑定最终 field_mapping；其余采购阻断项和全部请假阻断项必须绑定本工作流的 write_integration。其 SHA-256 必须与本次 RSA 签名验收清单中的精确原始制品哈希一致，不是自由填写的文本证明；画像中采购选定模块或请假模块也必须与清单 moduleCode 逐字一致。只要当前工作流任一阻断项仍为 open，签发脚本和 ERP 启动/计划/执行门禁都会拒绝；采购全部关闭后还必须把选择状态同步改为 selected_and_activation_approved 且 activationAllowed=true。请假可独立批准，不要求采购同时完成，反之亦然。
实施人员不应直接编辑这些字段。最终字段映射、只读契约证据和 Windows 写集成报告齐备后，使用已登录客户 ERP 的内置管理员运行 lserp-cli adapters prepare-profile-activation <purchase|leave>；命令会绑定当前账套、子系统、模块、源码提交、商用包和运行配置，重新执行只读关键目录复核，并只用新建文件语义输出未签名候选。原画像不会覆盖，数据库不会修改，写命令也不会注册。候选仍须交给 New-WorkflowAcceptanceEvidence.ps1 在线复核和 RSA 签名。
实库核验还发现：服务器引擎虽为 SQL Server 2022，但 lserp_AI 数据库兼容级别是 100（SQL Server 2008 语义），因此库内不能使用 OPENJSON、ISJSON、TRY_CONVERT 或 THROW。AgentBridge 现在会在调用前读取 sys.databases.compatibility_level：低于 130 时，由受信任 ERP 进程用严格 Newtonsoft JSON 先验解析；普通读取和请假写入只传固定白名单标量，采购明细则由 XmlWriter 编码成固定结构、限量且再次校验的 XML 行集，不接受模型原始 XML。采购和请假均已有固定兼容写分派，但缺少严格运行配置、数据库 V2 就绪证据或 TrustedPeople 签名验收时不会注册命令；采购草案内部两道审核开关仍固定为 0，当前仍无法写入。兼容级别无法确认时同样失败关闭。
它明确记录了三类结果：
PUR_5001是采购订单主从单据，可作为来源单候选。acc_1007是唯一满足现有采购适配器“bill + 主从字段”门禁的采购发票候选；但币种字段没有在p_systembillInfo/p_systembillDetail暴露，且来源订单字段存在历史命名歧义，因此保持不可启用。acc_1002是“采购发票登记”基础档案菜单，适合导航和只读诊断，不能绕过采购发票主从写入契约。hr_4011的请假字段已经能与现有 leave 适配器语义对齐。流转类别控件保存的是p_systemdlltabflowtype.id；其旧天数/岗位联动仍指向已经不存在的 3195-3200，而当前流程步骤使用 3629-3634。Agent 当前返回有效候选并在不唯一时追问，不能沿用这段失效配置自动选路。lserp-ai.workflow-read.compat100.draft.sql是能被兼容级别 100 解析的只读过程审查草案。它以SET NOEXEC ON开头、内部审核开关固定为0，所以不能部署也不能被调用；正式脚本必须由客户 DBA 另行生成。lserp-ai.workflow-write.leave.compat100.draft.sql是请假创建/提交的强类型事务写审查草案，同样受NOEXEC和固定关闭审核开关保护。它派生员工姓名、部门、岗位和天数，调用原p_BaseSave70/p_baseApply，并要求幂等、审计、事务证据和 Outbox 同事务完成；未签署前不会注册成可用写命令。
实库过程签名确认 p_BaseSave70 的保存确认参数当前默认值为 0；草案仍显式传入固定 @comfirmFlag = 0，从而把“只创建草稿、不隐式确认”的语义绑定在客户包装合同中，不依赖未来可能漂移的过程默认值。
lserp-ai.workflow-write.purchase.compat100.draft.sql是采购发票创建的固定标量加 XML 行集审查草案。它同时固定关闭 DBA 审核和采购行级范围审核，复核目标币种字段、签字币种换算、采购订单快照和可用量后，才会调用 WinForm 同一条P_BillSavePr70保存链生成未提交草稿；ERP 网关已有精确分派，但只要配置、V2 就绪证据、Windows 验收或 TrustedPeople 签名任一缺失，命令就不会注册。
安全边界：本档案只含对象名、模块编号、字段名和配置摘要；生成时没有读取业务单据行，没有执行存储过程，没有执行 INSERT/UPDATE/DELETE/DDL，也没有写回数据库。正式启用仍必须在客户 Windows ERP 进程中运行：
Agent 的内置管理员身份已收紧为 user_id=1 且员工名称精确为 管理员，不再继承旧客户端仅按显示名放行的行为。只读过程、请假写包装和采购写包装采用同样的成对判断；名称为“管理员”但 ID 不是 1 的账号仍必须通过对应菜单权限和业务范围门禁。若客户需要委派其他配置管理员，必须设计独立签字授权，不得复制或放宽该名称判断。
lserp-cli adapters inspect purchase acc_1007
lserp-cli adapters inspect leave hr_4011
lserp-cli adapters validate-fields purchase --input acc-1007.purchase.fields.candidate.json
lserp-cli adapters validate-fields leave --input hr-4011.leave.fields.candidate.json
lserp-cli adapters revalidate-profile --input lserp-ai.readonly-map.json
lserp-cli adapters prepare-profile-activation purchase --input lserp-ai.readonly-map.json --field-mapping acc-1007.purchase.fields.final.json --read-evidence purchase.read-evidence.json --write-evidence purchase.write-evidence.json --runtime-sha256 <SHA256> --source-commit <COMMIT> --package-sha256 <SHA256> --output lserp-ai.purchase.approved-candidate.json
最后一条命令只能由当前已登录 ERP 的内置管理员执行。它只运行代码内固定的一批 DB_NAME/SERVERPROPERTY/sys.* 系统目录结果集，比较数据库身份、兼容级别、用户对象计数、Agent 对象状态，以及档案声明的关键对象、列和过程参数；目录成员最多读取 100000 条，超限、缺少第二结果集、重复或格式异常都会失败关闭。它不会读取业务行、调用存储过程或执行写入。输出只包含档案 SHA-256、关键目录契约是否匹配、稳定漂移码、总阻断项数量，以及采购/请假各自的 approved/openBlockerCount/openBlockerCodes，不回显画像证据正文、当前数据库名、对象名、字段名、参数名或计数。命令级 activationAllowed 与 registrationReady 始终固定为 false；即使某个工作流 approved=true，该结果也不能单独启用写命令。签发脚本只接受本次工作流 approved=true/openBlockerCount=0，并且只允许 Agent 支撑对象部署引起的非关键计数/状态变化；运行门禁锁定批准状态、数据库身份、兼容级别和关键目录契约。只有画像哈希进入 RSA 签名工作流清单、与最终运行配置及 V2 就绪行共同通过，并在每次运行时复核仍匹配时，才满足完整门禁中的画像一项。
请假候选应在当前 ERP 管理员会话中通过字段门禁；仍需继续完成只读过程与写链路验收。请假写草案会把 ERP user_id 与只读上下文返回的当前员工再次绑定，只接受 p_SubsysPurviewTab.hrPurview 中菜单 16629 的完整编辑标记；16629| 只读标记必须拒绝。创建与提交分别以账套、子系统、用户、命令和幂等键获取事务级 sp_getapplock，防止多个 ERP/桌宠进程同时插入同一幂等请求。客户库当前仍没有这些 Agent 对象，草案也保持 SET NOEXEC ON 和审核开关为 0，因此上述加固不会造成任何实际写入。
采购候选刻意把物理列 acc_mphhscm_currency 写入 currencyCode：该列存在于主表，但没有暴露在 acc_1007 的低代码主表控件配置中，所以当前 validate-fields purchase 应以 mapped_field_not_exposed 或 mapped_field_not_found 失败关闭。字段检查会区分主表控件 visible=1（显示）与单据明细 isVisible=1（隐藏）这两套相反的旧框架语义，并把宽度为 0 或受字段权限隐藏的列排除在候选和注册范围外。只有客户配置人员正确暴露币种字段，并由财务/DBA 签字确认币种换算后，才可生成新的人工复核包。在此之前，不要把 acc_1007 写入 LSERP_BUSINESS_ADAPTER_CONFIG 的启用配置；不要把基础档案菜单 acc_1002 当成采购发票主从写入目标。
虽然 acc_1007 当前“来源单”配置只有物料类别和自身单据管理，没有采购订单来源，但两个现存数据库对象给出了可交叉验证的业务证据：Proc_GetScmMainBillInfo 和 Scm_ScminvoiceMoneyView 都用 acc_lphhscm_ScmPoid = scm_lpo_id 跟踪采购订单明细；acc_lphhscm_ScmPrid 则标注为“申请id”。因此兼容草案中的 purchase.open_sources 已改为固定、限量的只读候选查询，返回采购系统单据号、人工单号、明细 ID、单位、原币含税单价、税率、汇率和扣除现有有效发票占用后的剩余数量。它不仅复核采购订单菜单权限，还要求每一条返回行的组织、部门和采购员精确命中当前账套、子系统、ERP 用户的一条有效签字范围；范围表缺失、空表、过期、哈希无效或元组不匹配都会失败关闭，内置管理员也不绕过。这样不可写的采购订单不会先泄露给 AstrBot/MiniMax。草案继续受 SET NOEXEC ON 和 @customer_dba_reviewed = 0 双重锁定，不能因此启用采购写入。
采购订单币种来自 P_CurrencyType，而目标发票主表的物理币种列沿用 P_BaseMixInfoTab(Tag='L000101')。只读证据显示的 1→22、2→23、3→24 只是候选换算，不能硬编码为生产规则。兼容只读草案的 resolve_currency 现在只返回已存在有效签字映射的来源币种 ID；它可以精确接受来源字典的 ID/代码/名称，也可以接受发票 OCR 常见的目标字典 ID/编号/名称（例如“人民币元”），但后者仍必须先通过同一条已审批映射反查，映射缺失或失效时固定返回 purchase_currency_crosswalk_not_approved。这样后续 open_sources 和写包装始终接收采购订单使用的来源币种 ID，不会把目标字典 ID 误传给来源单查询。acc_1007 明细公式将 amount * price 作为含税金额，所以该客户的正式匹配配置必须使用 lineAmountMode = 2；单位或汇率缺失、同一发票命中多个汇率时均应失败关闭。
采购订单配置还明确暴露了组织、部门和采购员字段。基础 Agent 架构脚本现会创建默认空的 p_agent_purchase_row_scope，正式写包装要求来源单的组织、部门和采购员与当前账套、子系统、ERP 用户组成一个有效期内、带签字证据哈希的精确元组。该表不支持 NULL 或通配符，管理员也不绕过；客户未审批并填充范围时，写过程固定返回 purchase_row_scope_denied。这只建立了可执行的失败关闭机制，并不替客户决定谁能看哪些采购单，所以 purchase_row_scope_not_approved 仍保持打开。
ERP 网关只从固定客户包装过程异常中提取代码仓库白名单内的稳定业务码，并使用本地固定中文说明返回桌宠；SQL Server 原始异常、对象名、行号、连接信息和业务值不会向 AstrBot/MiniMax 透传。未知错误统一返回 workflow_database_error。因此币种字段缺失、换算未审批、精确采购范围未授权和请假权限/冲突可以被桌宠准确说明，同时不扩大数据库信息泄露面。
WinForm 保存链已经从源码和实库过程定义交叉验证：GetDetailRecord 先把明细写入 ACC_billscmInvoicelistPIDHxtab_temp，BillSave 再调用 P_BillSavePr70，由 P_BillSavePr70_3 生成正式单号、迁移明细并执行 ERP 保存副作用。因此采购兼容草案不会直接写最终主从表。目标临时明细的数量、单价、税率和汇率只有两位小数，候选合同会提前拒绝更高精度，避免旧保存链静默舍入。当前 acc_1007 保存事件不会自动提交；98/99 事件属于后续流转，桌宠创建动作也只允许生成草稿。
过程层结论
数据库目录中可以看到旧的通用过程（包括请假界面实际使用的 p_BaseSave70 和 p_baseApply），但没有 AgentBridge 固定调用的就绪、只读和强类型写包装过程。这些旧过程自身的参数契约不足以证明当前桌宠请求的账套/用户/模块权限、输入指纹、幂等占用、业务审计和事务证据，因此只能由固定客户包装过程调用，不能直接暴露为自然语言工具。
客户实施时应在 DBA 评审下，用固定参数化过程包裹现有 ERP 保存入口；先完成只读契约探针，再完成 SQL 事务、持久化幂等、权限复核和 Windows 集成验收。未完成前，AgentBridge 必须保持只读/导航/诊断能力，写命令不注册。