LWLT-AIBOT/archive/project-history/2026-08-28/findings-pre-compression-shared-plan-visitor-export.md

当前关键发现

2026-08-28 — 名单容量提示（已完成）

• 15:44 日志证明独立团 25 人只物化 16 位，保存前阻断；其余缺行/投影码均为连锁证据。
• 0.5.156 将两类行数码映射为 erp_passenger_count_limit_exceeded，主提示含 25/16 和对象类型，原码只留技术详情。
• 仍为 no_erp_write=true；未重试历史任务、访问 ERP、重载或重启。

2026-08-28 — 名单确认覆盖必写与明确成功终结（已完成）

• 两次真实运行都已取得父表单 ERP 明确成功响应；ERP 最终 25 行及领队联系人也被独立只读证据确认正确，但 raw HTML 与 hydrated 页面逐行比较先后产生假阴性，说明写后逐行读取不适合作为名单成功门禁。
• 业务负责人确认：full_replace + confirmed=true 就是明确写入授权，插件不得因 ERP 当前值与附件相同而生成 passenger_import_no_changes；所有附件指定序号都必须进入原生覆写集合。
• 未确认时，任一目标序号已占用（包括同值）仍要求覆盖确认；确认后继续执行游客与领队完整写前投影，父表单 ERP 明确返回成功即完成，不再写后逐行回查或自动对账。
• 该例外只属于 passenger_list_import。其他生命周期 action 仍必须完成写后回查；名单没有取得明确成功响应时仍不宣称成功、不自动重提。
• 扩展和平台最低版本推进到 0.5.155；历史任务不修改、不回查、不重试，运行态重载仍需用户另行授权。

2026-08-28 — 名单领队联系人严格来源与写入边界（已完成）

• 真实模板只读结构核验确认：第一行是团信息，第二行是完整 14 列表头，共 25 条数据；恰好一行备注严格为领队且该行姓名、电话齐全。核验未输出或归档个人值。
• 联系人来源必须与正文data.leader分离：正文领队仍是查单/候选补充事实；只有 canonical TSV 中唯一严格领队行才生成嵌套 passenger_list.leader_contact={sequence,name,phone}。
• 解析、Schema、平台和扩展都独立核对 leader_contact 与 TSV 的序号、姓名、电话和备注关系。无标记却携带结构、多标记、缺值、篡改或超长值均在浏览器访问/保存前阻断。
• ERP 目标控件是 jj_lianxiren（联系人/领队人）和 jj_dianhua（电话）。sj_lianxiren/sj_dianhua 属于接送联系人保护字段，只快照恢复，不接受本次名单领队投影。
• 原生 DaoRuDones 可能改变父表单，因此适配器在调用前冻结四字段，游客行合并后先恢复全部快照，再按存在的 leader_contact 覆盖两个目标控件；无标记时四字段保持原状。
• 保存前要求目标两字段和全部游客行精确投影；失败时恢复父表单和游客行。保存后 fresh GET 只回传姓名/电话的脱敏哈希匹配事实，不记录明文。
• 该阶段版本为工作簿规范化器 v1.1.0、Program parser v1.0.5、生命周期契约 v2.9、扩展 0.5.152、五 Skill 0.5.124、运营 DOCX 0.5.122。8786 已在用户授权下重启并加载当时控制面源码；后续真实运行已证明名单与领队联系人保存成功，当前扩展由下一节推进至 0.5.153。

2026-08-28 — 名单确认覆盖行英文名写前纠正（已完成）

• 用户提供的两次平台时间线证明手工附件上传已生效：同一 .xls 均被接受并规范化为 25 行，只走 Program；第一次按设计在第 1、2 行覆盖确认处停止，第二次确认覆盖后到达 ERP 原生解析，但在父表单保存前以 passenger_native_projection_mismatch:1.english_name,2.english_name 停止，两次均明确 no_erp_write=true。
• 只读核对工作簿哈希与运行记录一致；前 24 个英文名均为 ASCII 逗号加空格，第 25 个全角逗号会被生产规范化器转换。因此第 1、2 行不是源格式特例；失败恰好对应原来已占用的覆盖目标行。
• 原生解析失败后控件已恢复，无法再直接读取瞬时旧值；结合失败范围，最强解释是 DaoRuDones 覆盖已占用行时没有可靠刷新 pinyinxm。实现按防御性方式修复，不把推断冒充 ERP 保存证据。
• 0.5.151 在原生解析后只遍历 merge.changed_sequences：把 canonical NAME 按原生规则去空白后写回该行英文名控件；既有电话纠正、未变更行快照恢复、完整写前投影、明确响应和保存后 fresh requery 全部保留。
• 平台最低扩展版本、mapping、风险登记、release gate 和缓存键已同步；旧 0.5.150 ZIP 归档，新 ZIP SHA-256 为 51529ca531f1767b4938292c1f8a637f510efa5df5d28d386711854c5f56495f。
• 定向 lifecycle 52/52；规定全量门禁为仓库治理 9/9、控制面 121/121、legacy 244/244、TypeScript 和 build 全绿。当前源码尚未重载到 Chrome，也没有重试真实任务或触发 ERP 保存。
• 先前 AgentBus OSS 地址被 DNS 私网/保留地址判定拒绝是另一条下载边界问题；本轮平台手工附件成功不等于该 AgentBus 网络问题已修复。

2026-08-27 — 运营指令表示例合并与精简（已完成）

• 桌面 DOCX 是较旧契约上的运营改稿：示例值和删减方向有效，但其中两项名单仍为正文 TSV，不能反向覆盖已完成的 Excel 附件等待与 Program-only 契约。
• 18 项示例已按桌面版更新；散拼子单补回当前必填的人数：15+1，两项名单改为相同定位信息加 Excel 附件，LLW-261101A-A 按用户确认保留。
• 运营表已移除 before_snapshot、内部字段、AI 模式名、OSS、内部 action/映射和回查实现等释义；这些约束仍保留在 Skill、release gate、控制面说明和代码中。
• 当前发布基线为扩展 0.5.150、五 Skill 0.5.123、运营 DOCX 0.5.121。新版由活动 Markdown 单一源生成，共 12 页，逐页检查无字体或布局缺陷。
• 仓库治理 9/9、TypeScript、控制面 121/121、legacy 244/244、build 和 diff 全绿；运行态、ERP 与外部渠道均未改变。

2026-08-27 — 名单 Excel 附件 Program-only 改造（已完成）

• 用户明确两类名单业务不走 AI，只走 Program parser；功能范围不包含 AI Prompt、AI parser、Shadow 或 Auto 附件解析。
• 当前 business_parser_settings 默认 AI 且允许四模式，名单 route 没有硬性 program-only 约束；全局紧急 AI 回退也会覆盖全部 route。实现必须在 route、设置和任务快照边界固定两类名单为 Program，不能只依赖当前数据库配置。
• 样例为旧版二进制 WPS .xls，单 Sheet A1:N27：标题/航班元数据行、14 列表头、25 条名单。年龄与有效期含公式，日期同时有文本与序列值，电话可能是数值，英文姓名出现全角逗号；解析必须按数据处理并转换为 canonical 13 列。
• 14→13 的核心转换为 英文姓名→NAME、护照号码→证件号码、自动补 证件类型=护照、签发日期→签发日；年龄忽略。非空身份证号码当前无护照名单目标，必须失败关闭或进入人工确认，不能静默丢弃。
• 当前手工/API 只有文本；AgentBus 类型虽有 attachments，处理函数忽略它且附件-only 帧被拒绝。当前 task_artifacts 强制 execution-bound，只适合 ERP 输出；OSS 上传为 public-read，不能保存护照名单输入。
• 当前 Chrome 路由读取页面现有游客行数作为 expected_passenger_count，operation plan 与 planPassengerMerge() 都拒绝行数/序号超过该值。样例 25 人用于默认 16 行独立团会被错误阻断，故需把“当前行数”改为合并基线而非业务上限，并以 native import 后实际生成/保存行 fresh requery 为准。
• 既有 partial merge、占用行覆盖确认、未指定行恢复和 canonical TSV 复用价值仍成立；动态扩展必须保留这些保护，不能直接把原始 Excel 交给 DaoRuDones。
• 控制面已有 AES-256-GCM encryptBytes/decryptBytes，但名单解析完成前只需要内存中的原始工作簿和数据库中的加密 canonical TSV；按数据最小化原则无需持久化原始文件字节。新输入附件表可仅保存 hash/类型/大小、脱敏校验状态和加密规范文本，失败文件只留元数据。
• Fastify body limit 已按 ARTIFACT_MAX_BYTES 放大，手工页面可沿用 JSON base64 上传而无需再引入 multipart；服务端仍必须严格解码、核对声明大小/hash，并限制一个名单文件。
• 初始 agent_session_messages 可以在任务等待附件期间保持 queued；附件到齐后只需原子解锁任务为 parse_queued。附件-only 续接不应伪造新的用户正文，claim 时从加密输入附件表读取 canonical TSV 并仅拼给 Program parser。
• 为避免多个 queued turn 的顺序歧义，awaiting_attachment 阶段只接受附件续接；普通文本补充仍提示先发文件。Program 真正运行后如缺订单定位字段，再使用现有 awaiting_user_input 文本会话。
• AgentBus 入站附件预计沿用 payload.attachments[] 的 name/content_type/size/url/sha256 形态；下载必须 HTTPS、限制重定向/大小、校验 hash，并拒绝本机、私网和保留地址。附件-only 帧须有显式 task_id 或同渠道同会话唯一 waiting task。
• 当前实现已把上述约束落到迁移 014、手工/API、AgentBus、TaskService 和解析 claim：原始工作簿只在内存中存在；数据库只保存附件元数据、校验状态、加密 canonical TSV，解析完成或终止后立即清除规范文本。
• 两个名单 route 的任务快照、设置 mutation、紧急 AI 回退和一次性重解析均受机器注册表的 program_only 策略约束；非名单 route 保持原四模式行为。
• Chrome 端以 max(页面当前游客行数, 附件最高序号) 扩行并保留未指定行、覆盖确认与 fresh requery；16/31 只保留为独立团/散拼子单初始基线，5000 是唯一行数技术上限。
• 真实模板只读验证结果为表头第 2 行、25 条数据、规范化 13 列；没有把文件名、单元格值或工作簿字节写入活动仓库、日志、fixture 或发布物。
• 名单链路发布时基线为运营 DOCX 0.5.120；当前运营 DOCX 已由后续示例合并与精简任务推进到 0.5.121。运行态迁移、扩展重载与真实 ERP 保存仍需另行授权。

2026-08-27 — 历史任务手动与批量删除（已完成）

• 修改前已有 DELETE /api/tasks/:taskId、TaskService.hardDeleteTask() 和详情区删除按钮，但 /history 卡片没有行级删除、复选框或批量服务端契约。
• 新增 POST /api/tasks/bulk-delete，请求为 1–100 个不重复 task_ids。服务层在一个事务中按组织和稳定顺序锁定全部目标；任一任务缺失（包括其他组织的不可见目标）即返回 task_not_found 并整批回滚。
• 单删复用批量事务核心。FK 子记录级联删除，task-scoped audit_events 与 outbox_events 同事务显式清理；删除前冻结关联附件元数据，提交后通过现有 TaskArtifactStore.cleanup() 清理 OSS 对象。
• 历史页每张卡片增加复选框和独立删除按钮；工具条支持“选择本页”和删除所选。筛选、重置和翻页清空选择，服务端刷新裁掉当前页外选择。
• 单删和批删共享二次确认。若任务已确认或进入插件流程，会显示涉及数量并声明插件停止只是尽力而为、已经发生的 ERP 写入不会撤回；删除期间相关控件统一锁定。
• 删除成功后清理列表、运行态、详情、overlay 和回执队列等本地缓存，并用当前页面会话 tombstone 阻止在途旧同步短暂恢复已删卡片，再刷新服务端权威分页。
• 并行名单附件 WIP 写入前，仓库治理 9/9、TypeScript、页面语法、历史删除定向回归、完整控制面 99/99、build 和相关 diff 通过；其后历史删除定向复跑仍通过。当前全局门禁另受名单 WIP 的缺失 workbook 源文件、两项动态游客行红灯及扩展源码/ZIP 暂时不同步影响，均不属于删除回归。
• 用户随后明确授权重启；新服务 PID 29562 已成为 8786 唯一监听者，数据库、Schema、迁移 014 和 4/4 AgentBus 渠道均 ready。仅以未认证随机假 ID 探测删除路由，返回 401 而非 404；未删除真实数据、未读取 .env 内容、未部署。

2026-08-27 — AgentBus 渠道配置删除（已完成）

• 原渠道目录只有创建、启停、改名和 key 轮换，没有删除 API 或 UI；数据库迁移已经预先定义了硬删除语义：tasks.channel_id ON DELETE SET NULL 保留历史任务，agentbus_deliveries.channel_id ON DELETE CASCADE 清理该渠道持久化回执，加密 key 随 user_channels 行删除。
• AgentBusChannelService.delete() 现在在组织范围事务内锁定目标、验证存在性、记录 agentbus_channel.deleted 审计（含关联任务数和移除回执数），再删除配置；其他组织的 UUID 与不存在目标统一返回 channel_not_found。
• DELETE /api/channels/:channelId 使用现有管理员 same-origin、会话和 CSRF mutation 门禁；事务成功后由 manager reload 停止旧 listener 并只为仍启用渠道重建连接。
• 旧 reload() 会把并发期间的新 reload 请求直接合并到旧 Promise，理论上可能以旧渠道快照结束。现在 manager 用 reloadRequested 循环完整重放并发 mutation，单测证明在途 reload 期间追加请求会执行第二次目录读取。
• 完整旧环境变量仍存在时，ensureLegacyChannel() 会自动重建 legacy-env。公开渠道模型因此增加 deletable；API 对仍由环境托管的兼容渠道返回 channel_managed_by_environment，页面显示禁用的“环境托管”按钮。移除环境配置并重启后，遗留数据库行可正常删除。
• 页面删除前明确二次确认：连接停止、服务端 key 与该渠道全部持久化回执记录（包括未发送回执）移除、历史任务保留、操作不可撤销；成功后本地目录立即移除该行，脚本缓存键更新为 20260827-agentbus-channel-delete-1。
• 定向 61/61、TypeScript、页面语法、完整控制面 99/99 与 build 通过。仓库治理 3 个红灯均来自暂挂人数发布链尚未同步的 0.5.119 DOCX、扩展源码 0.5.149/清单 0.5.148 和 Skill 源/0.5.121 包；本次未触碰该发布收敛工作。
• 本轮没有读取 .env、调用真实渠道 API、删除配置、重启或部署。

2026-08-27 — 独立团人数分类解析修复（已完成）

• 根因是 Program parser 把报告值归一化为 8+1占+1不占+1 后，四段前置校验仍要求全为纯数字；同时 lifecycle 可执行映射漏了已有标准 target pax.child_no_bed。
• 报告输入现精确生成成人 8、占床儿童 1、不占床儿童 1、领队 1 四个 action。标签倒序按标签归类；旧三段和旧四/五段纯位置格式保持兼容。
• 双标签格式只允许中间两段恰好各有一次“占/不占”；重复或半标注、坏分隔符、负数/小数、超安全整数和全零继续 program_invalid_value，不 Auto fallback、不生成 operation、不派发插件或写 ERP。
• 只写用户能确定的类别；报告四段不生成 pax.infant=0。需要清零必须明确写“婴儿改为0”，该显式 target 仍按现有宽修改能力进入人工复核。
• ERP 活动字段由 Schema/new-order 路径确认是 ertrenshu。operation plan、平台能力目录和 lifecycle adapter 已加入 pax.child_no_bed → ertrenshu，同一表驱动覆盖写前快照、非负校验、原生表单设值和 fresh requery；Schema 结构不变。
• 业务登记、Prompt、更新 Skill/契约、运营模板、mapping、扩展说明和 release gate 已统一为成人/占床儿童/不占床儿童/领队四类，并继续标记 SGL/TWN 与四类人数待授权 ERP 实写复测。
• 当前版本为 Program v1.0.4、Prompt v1.8-independent-headcount-categories、扩展 0.5.149、五 Skill 0.5.122、运营 DOCX 0.5.119；发布清单已登记当前制品和哈希，旧制品日期化归档。
• DOCX 已按 Documents 工作流重建并检查全部 15 页；五个 Skill 通过官方 validator，ZIP/Skill 包与源码逐文件一致。规定门禁最终为仓库治理 9/9、TypeScript、控制面 117/117、legacy 244/244 和 build 全绿。
• 未修改或重试报告任务，未调用 AI、派发插件、访问/写入 ERP、重载扩展、重启服务、部署或外发；运行态加载仍需用户另行授权。

2026-08-27 — 09:32 下单错误已定位并修复为严格双哈希门禁

• TASK-20260827013256-D06X1n4 为 AgentBus、team_order_create、Program revision 3 / v1.0.3、automatic；解析和客户/产品/人员唯一匹配均通过。
• 页内 liveSubmitApproved() 在网络前比较受保护字段指纹时阻断：current protected business fields do not match the approved preflight。结果明确记录 submit_safety.live_submit_attempted=false、native_request=null、server_response=null、requery=null、side_effects=[]；没有向 ERP 发出本次保存请求。
• Chrome 扩展后台的原始证据进一步确定了时间边界：预检调用前表单 protected hash 与被拦截的原生请求 protected hash 都是 5f3d…；SubmitInfoForm() 返回后的当前表单则是 a5f4…，字段数仍为 822。说明 ERP 原生函数在生成请求时同步规范化了浏览器表单；旧代码只保存调用前 form hash，随后错误地拿它校验调用后 form。
• 0.5.148 保留两套互不替代的批准证据：原生函数返回后的 post-intercept form hash 用于正式动作前的当前表单校验，被拦截的 native request hash 用于正式 DoInfoJH Ajax 放行校验。两处任一漂移仍在网络前阻断，没有降低哈希强度。
• 独立的状态分类缺陷也已修复：页内结果现在明确记录 network_request_attempted；只有实际调用原生 Ajax 才进入写边界。后台对经过严格证据函数确认的网络前阻断回退为 blocked/no-write，未知或断连仍保持 uncertain。
• 控制面只允许在“既有结果与纠正结果均含同一零网络页内证据、执行编号/连接一致、attempt 仍待回查”的条件下把 reconciliation 收敛为 no-write。报告任务已通过该门禁变为 blocked / prewrite_blocked / write_attempted=false / no_erp_write=true / queue_released=true，并同步纠正扩展本地副本；没有自动重试或 ERP 写入。
• 当前源码/发布基线为扩展 0.5.148；运行中的 Chrome 仍是 0.5.147，未获单独重载授权，因此新逻辑尚未进入浏览器运行态。

2026-08-27 — 全自动化按钮陈旧显示已修复

• 最新 AgentBus 任务 TASK-20260827011515-VRWFVAc 是 team_order_create / Program / Program；解析事件固定记录 automation_enabled=true、confirmation_mode=automatic，任务随后完成写入与回查。数据库组织开关当前也是 true。
• 因而本次不是 AgentBus 绕过门禁：执行端读取了数据库权威值。页面按钮显示“关闭”来自旧标签页的本地状态；此前开关由受控后台方法改变并重启服务，而页面只在登录/整页加载时读取设置，EventSource 自动重连和既有 30 秒刷新均未同步该值。
• syncAutomationSettings() 现合并并发读取，并与用户 PUT 切换串行；EventSource open、30 秒后台刷新、页面重新可见和窗口聚焦都会重新读取 /api/settings/automation。解析策略页的自动化提示也随同重绘。
• 页面缓存键更新为 app.js?v=20260827-automation-state-sync-1。8786 的静态服务已直接提供新版 HTML/JS，无需服务重启；已打开的旧页面仍需刷新一次。
• 仓库治理 9/9、TypeScript、控制面 96/96、legacy、build、diff、运行态 ready 和已提供脚本检查全部通过。本轮没有修改组织开关、解析策略或任务，没有重启、调用 AI、派发插件或访问 ERP。

2026-08-27 — 微信信封修复已加载，全自动化已开启

• 用户对“重启 8786”和“开启组织全自动化”两项均明确授权。切换前只读确认 automation_enabled=false，且没有 parse/ERP 在途任务。
• 已通过 TaskService.setAutomationEnabled() 的同一事务方法把开关设为 true，并写入 organization.automation_enabled 审计；未直接绕过控制面审计语义。
• 已优雅停止旧服务 PID 76113，用标准 pnpm run dev 启动 PID 84022。8786 只有一个监听，cwd 为项目根目录；数据库、Schema、迁移 013 与 4/4 AgentBus 渠道 connected/session ready。
• 运行态复核：组织全自动化为 true，18/18 parser route 均为 Program revision 3。未来合法的新手工或 AgentBus 任务会共用 Program 与自动确认安全门禁。
• 报告任务仍保持 awaiting_confirmation / manual / parser AI 且未确认；本轮没有重解析、确认、派发、AI 调用或 ERP 访问/写入。

2026-08-27 — AgentBus 微信信封 AI 回退已修复（源码）

• 用户提供的新任务日志证实 AI 在重启后仍被调用。只读定位到 TASK-20260827004712-_PGgTzg：任务来源为 AgentBus，但快照为 business_route_id=null、parser_mode=ai、revision 0、AI affinity；parse decision 同样记录 route null/configured AI。与此同时数据库 18/18 route 均仍是 Program revision 3，因此不是策略被切回 AI。
• 加密原文的脱敏结构是 New WeChat message、Conversation:、Text: <业务指令>，后接当前登记字段。旧 resolver 对完整信封 unresolved，因为 Conversation / Text 不是业务标签；任务在快照阶段按兼容策略安全固化为 AI。
• 146 条 AgentBus 任务的只读聚合中，144 条使用这一严格微信信封，修复前 146/146 unresolved；按已证实信封解包后 142 条命中登记 route、4 条继续 unresolved。没有输出或归档原文值。
• 新 extractAgentBusBusinessText() 位于 AgentBus source adapter：仅当首行精确为 New WeChat message、第二行非空 Conversation:、第三行 Text: 时，才把 Text: 同行值与后续行交给 TaskService。近似、缺字段或空正文保持规范化后的原包装。
• 不把传输标签注册为业务字段，也不放宽 Program 对未知语法的失败关闭。解包正文仍使用同一 route resolver、任务级模式快照、parser orchestrator 和 operation validator。
• 报告任务原文用新代码只读离线重放：信封成功解包、route exact=team_order_create、Program v1.0.3=agent_parse_passed、action=team_order_create、无 fallback。
• 定向 AgentBus/parser 33/33、仓库治理 9/9、TypeScript、完整控制面 96/96、legacy 全量、build 与 diff 均通过。适配器随后已在用户授权重启后进入运行态。
• 没有重试/修改报告任务，没有创建、确认、派发任务，没有调用 AI、访问/写入 ERP、切换解析模式或修改组织自动化开关；未读取 .env 内容。

2026-08-27 — 8786 已加载全局解析与自动化修复

• 用户明确授权“重启项目”；结合上轮交付边界，本轮授权目标精确为正式控制面 127.0.0.1:8786，未停止独立 8765 解析适配器或其他本机服务。
• 重启前旧服务 PID 41546、启动器 PID 41533，使用标准 pnpm run dev；/health/live 与 /health/ready 均正常，数据库、Schema、迁移 013 和 4 个 AgentBus 会话 ready。
• 已向旧服务发送 TERM，并确认端口释放及旧进程树退出；随后以相同标准入口启动。新服务 PID 76113、启动器 PID 76096，只有一个 8786 监听，进程 cwd 为 /Users/inmanx/Documents/lwltAPI。
• 新实例 /health/ready 返回 ok=true，数据库与 Schema ready，必需迁移为 013_business_parser_modes，4/4 AgentBus 渠道 connected 且 session ready。
• 正式页面已实际提供 cache key app.js?v=20260826-global-parser-automation-1；获取到的脚本包含“所有来源的新任务解析通过后”文案，证明本次全局解析/自动化源码已由运行服务加载。
• 重启记录同步后，仓库治理 9/9、TypeScript、控制面 95/95、legacy 全量、build 与 git diff --check 均通过。首次并行门禁留下一个无输出的 AgentBus 测试子进程，已终止并用 AgentBus 11/11、控制面串行 95/95 明确复证；不属于运行服务故障。
• 本轮只执行受控重启和只读健康检查；没有读取 .env 内容，没有创建/确认/重试任务、调用 AI、派发插件、访问/写入 ERP、修改 route 模式或组织全自动化开关。

2026-08-26 — 解析策略与全自动化全局生效（已完成）

已证实的根因

• 用户观察到手工输入会遵循解析策略，而 AgentBus 仍走 AI。调查必须拆成两层：route/mode 快照，以及解析通过后的自动确认/执行。
• ParserOrchestrator.parse() 本身不检查任务来源，只读取任务快照中的 route_id、configured_mode 和 engine_affinity；AI / Shadow / Auto / Program 四模式没有 AgentBus 专用旁路。
• createTask() 与 ingestMessage() 创建新任务时都调用同一个 resolveParserModeSnapshot()，写入同一组 parser 字段；AgentBus listener 也把原样 payload.text、配置组织 ID 和 source=agentbus 交给同一 TaskService 与 parse queue。已排除 AgentBus INSERT 或 listener 直接硬编码 AI。
• 实际来源偏差发生在快照之前：旧 resolver 只看原始文本首个非空行。未识别就固化为 route_id=null / mode=ai / engine_affinity=ai。手工模板首行通常是当前指令；历史 AgentBus 文本 143/143 没有当前指令行、141 条带普通包装且后续字段高度结构化，因此表现为渠道始终走 AI。
• 组织全自动化则有直接来源特判：shouldAutomaticallyConfirm() 同时要求 source=agentbus。这使手工任务即使开关开启也永远保留人工确认，与用户要求的全局语义冲突。
• 迁移 013 把旧任务固化为 AI affinity 只是历史保护，不解释新任务，也不应被本次修复回写；全局化只影响未来新任务/新会话。

当前实现与安全边界

• 全消息 route resolver 现在对手工与 AgentBus 共用：
  • 任意行存在唯一已登记指令（含登记别名或唯一一字符纠错）即可确定 route/mode 快照；
  • 没有指令时，字段签名必须至少包含两个不同标签，所有标签都能在候选 route 中唯一解析，并满足该 route 的定位/业务必填标签，最终只能剩一个候选；
  • 多 route、未知标签、不完整签名、两类名单对象以及无恢复状态的取消/恢复等天然歧义保持 unresolved/ambiguous，不猜测。
• 单号替代客户+日期的既有业务规则继续用于签名必填判断；order_update_shared_plan 的完整单号仍可替代出发日期。没有新增业务字段或 ERP 引用。
• 全消息中的嵌入指令只决定 route 快照；Program parser 不静默删除未知前置自然语言。额外包装仍返回 program_unsupported_syntax，Program 下失败关闭，Auto 只按既有技术 allowlist 整体回退 AI。
• 字段签名只为“已经确定是新任务”的输入选 route，不改变等待补充会话的归属。detectBusinessDirective() 仍只把明确业务指令当作新动作，避免完整字段补充被拆成新任务。
• 组织全自动化现在只依赖 needsInput=false、blocked=false 和组织开关；手工与 AgentBus 的合法解析结果使用同一自动确认路径。缺资料、阻断、歧义、插件失败和 ERP 不确定仍停止。
• 来源仍保留在任务信封中用于 UI、渠道 accepted/result 和审计，但不再覆盖 parser 或 confirmation mode。
• operation Schema、ERP mapping、Chrome 扩展写前门禁、单次提交与 fresh requery 均未改变；本次不需要扩展版本或 ZIP。

测试与性能

• 新回归先准确暴露 3 个缺口：嵌入指令无法路由、完整字段签名无法路由、manual automation 被拒绝。
• 回归现固定：
  • 嵌入唯一指令能拿到 route，但未知包装仍失败关闭；
  • 无指令且完整唯一的登记字段签名可 Program 解析；
  • 歧义/单标签不路由；
  • 多动作仍返回 program_multiple_actions；
  • manual 与 AgentBus 在组织开关开启时都自动确认，缺资料/阻断/开关关闭仍不自动；
  • 两个新任务入口各调用同一个模式快照函数，AgentBus listener 不丢来源或回执路由。
• 全消息初版对 500 行名单逐行计算编辑距离，虽未超 250ms P95 门槛但墙钟约 848ms。现在按登记指令长度 ±1 过滤候选行，字段签名最多检查 64 个标签；同一性能测试墙钟约 22—29ms。
• 页面 app.js 语法及 parser/control-plane/AgentBus 定向套件 79/79 已通过；仓库治理 9/9、TypeScript 检查、完整控制面 95/95、legacy 全量、build 和 git diff --check 也全部通过。
• 确定性 parser 版本已递增为 ltjt-program-parser-v1.0.3，gold corpus 已加入来源中性字段签名和包装失败关闭样例。

文档与版本同步

• 根 README、控制面 README、设计入口、业务登记、操作台开关提示和生命周期测试说明已统一为“所有来源”；页面 app cache key 已更新。
• 运营输入合同仍推荐首行业务指令。曾短暂修改模板说明，复核治理规则后已撤回；活动 Markdown SHA-256 恢复为发布清单登记的 45b3893e86959d86235ebfc8b34cec4be519624b245ce188e6c52efb61404443，无需重建 DOCX。
• 当前脱敏 corpus 没有未登记历史 AgentBus 旧标签真值；v1.0.3 只对当前登记指令/标签做保守兼容。未登记旧标签不会被猜测为 Program 成功。

当前发布与执行边界

• 当前 Chrome 扩展/制品基线为 0.5.148；本轮新增预检后 form/native request 双哈希与网络前零写分类修复。8786 静态页面已指向该最低版本，但运行中的 Chrome 扩展仍为 0.5.147，需用户另行授权重载。
• 五个业务 Skill 为 0.5.121，Agent Prompt 为 ltjt-agent-prompt-v1.7-lifecycle-date-rollover；当前控制面程序解析器随本次源码变更为 ltjt-program-parser-v1.0.3。
• 18 项运行态曾核验全部为 Program、revision 3，组织全自动化当时关闭；本轮不读取秘密或管理员数据，不假定当前数据库状态未变，也不会自动切换设置。
• 无年份月日规则：新建、三类修改、酒店安排变更及取消/恢复按任务日期取下一次发生日；明确年份保持不变，名单等完整年份契约未放宽。
• 生命周期仍要求精确对象/引用、唯一状态、页面身份、ownership、保存前停止、明确服务端响应和 fresh requery；不确定写入不得自动重试。
• 散拼母团无子单提示只有 resolved kind、ERP 明确无子单数据、提交入口缺失三项同时成立才触发。

安全、验证与归档

• 本轮没有创建、确认、重试或派发真实任务，没有调用真实 AI，没有访问/写入 ERP，没有读取 .env，没有重载扩展、重启 8786、部署或外发。
• 当前 Codex 任务没有附加运行服务的 app terminal；未改用进程环境或秘密补证。
• 活动服务未在本轮重启，因此源码修复要在用户另行授权重启 8786 后才进入运行态；本轮也未改变任何 route 模式或组织全自动化开关。
• 本次压缩前的完整发现已按相同 SHA-256 冻结到 全局解析/自动化 findings 快照；此前完整生命周期与解析研究见同日及 2026-08-25 的 archive/project-history/。归档只供追溯，不定义当前规则。