205 lines
31 KiB
Markdown
205 lines
31 KiB
Markdown
# 当前关键发现
|
||
|
||
## 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 快照](archive/project-history/2026-08-26/findings-pre-compression-global-parser-automation.md)；此前完整生命周期与解析研究见同日及 2026-08-25 的 archive/project-history/。归档只供追溯，不定义当前规则。
|