OPC/goauto
2
0
Fork 0
Code Issues 227 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(android): 采购改地址流程等待控件就绪，避免标题先出现即判失败 #366

New Issue
Open
opened 2026-10-08 10:00:41 +08:00 by ila · 6 comments
ila commented 2026-10-08 10:00:41 +08:00
Owner
Copy Link
Copy Source

基本信息

  • 类型：缺陷修复（Android Agent 采购改地址流程的等待条件）。
  • 状态：②已合并main、尚未发布，部分交付待验收：②及提示文字审核补修已实现并验证；①未实施，仍待真实地址列表证据。③④不改。
  • 授权记录：2026-10-08 用户先授权整合共识，随后明确“做#366”。本轮按已建议顺序先实施②并完成测试/构建/提交；不自动进行真机改地址、下单、安装或发布。
  • 审核来源：SynapBus #goauto 消息 #87、#89、#91、#93（对应私信为重复转发）；以 #93 的最终共识为准。
  • 来源：2026-10-08 用户提问：从规格面板地址入口进入地址面板、点击修改进入编辑面板、保存后回到地址面板、退出地址面板回到规格面板，这几步如果没有在指定时间内等到目标页面，现有代码是否处理。Claude Code 只读核对代码和线上数据后建单，用户确认新建工单。
  • 关联：#364（经授权的失败现场诊断，可作为证据来源）、#365（核单等待，不同代码段）。无代码前置依赖；环节①存在证据前置要求，详见下文。

代码事实与调查快照

  • 代码核验日期：2026-10-08；基线：7622795d97d4da3dd638619af99628b0352a42dd。
  • 代码路径：android/app/src/main/java/cn/ilapage/goauto/agent/automation/PurchaseLiveAutomation.kt。
  • 下列线上统计为 Claude 于 2026-10-08 只读调查的历史快照；Codex 本轮未独立重查，统计不能证明每次失败的现场根因。

现有等待逻辑（PurchaseLiveAutomation.kt）

通用 waitFor（约 682 行）：最多 50 次采样，采样间暂停 200ms，另外还有截取与解析耗时；这是采样次数预算，不是严格的 10 秒或 15 秒墙钟超时。到期以指定错误码明确失败。

环节 现有等待条件 超时错误
① 规格面板点收货地址 → 地址列表 先固定 pause(1_000)，再 waitFor 页面出现 label 为「收货地址」的节点（约 134～137 行） PURCHASE_ADDRESS_PANEL_TIMEOUT
② 点「修改」→ 地址编辑页 waitFor 页面出现含「详细地址」的节点（约 512 行） PURCHASE_ADDRESS_EDIT_TIMEOUT
③ 点「保存」→ 离开编辑页 waitForStableAddressEditorExit（50 次采样，编辑框连续两次消失）+ waitForSettledPanelAfterAddressSave（最多 5 秒） PURCHASE_ADDRESS_SAVE_TIMEOUT
④ 地址列表按返回 → 规格面板 backPurchase() 后 waitFor 出现已保存地址且提交按钮唯一（约 533～536 行） PURCHASE_ADDRESS_SAVE_TIMEOUT「地址保存后无法返回订单页面」

发现的问题

  1. 环节②等到标题就判断输入框，输入框未就绪即失败。
    • waitFor 条件只要求页面出现「详细地址」文字；返回后立即 shippingAddressEditors(edit)，数量不为 1 就以 PURCHASE_ADDRESS_UPDATE_FAILED「没有找到唯一的详细地址输入框」失败（约 515～516 行），不再等待。
    • shippingAddressEditors 要求 EditText 的 label 非空（约 761 行 editor.label.isNotBlank()）。若 PDD 先渲染标题、稍后才填入现有地址，此时一个输入框都匹配不到。
    • 推测（待现场证据确认）：输入框延迟就绪可能解释其中部分失败，不能据此认定是全部或主要来源。线上数据：设备 7 自 09-21 起共 39 次，10-07 单日 13 次且成批出现（14:50～15:01 连续 5 次，17:15～17:23 连续 6 次）；设备 8 从未出现。另有设备 7「详细地址修改失败」7 次（inputFresh 失败），可能与输入框未就绪有关。
  2. 环节①等待条件不够特定。
    • 规格面板上的地址卡本身就含「收货地址」等通用文字（ADDRESS_CARD_GENERIC_LABELS，约 1054 行），条件可能在尚未离开规格面板时就成立，只靠前面固定的 1 秒兜底。
    • 进入 editAndVerifyAddress 后立即查找「修改」按钮，不唯一就以 PURCHASE_ADDRESS_EDIT_AMBIGUOUS 失败，不再等待。线上仅设备 8 在 09-21 出现 1 次，影响较小，但属于同类缺陷。
  3. 环节④失败较多，原因待确认（不预设修法）。
    • 「地址保存后无法返回订单页面」：设备 7 共 21 次、设备 8 共 22 次（09-17～10-07）。
    • 环节③在保存后直接回到规格面板时，会用 restoreFinalEvidenceInCurrentPanel 在面板内滚动查找新地址（最多 5 次）；但环节④按返回后只被动等待，不滚动。若返回后面板的地址卡或提交按钮不在可视区，可能等满后失败。这只是推测，需现场证据。

审核补充：不能将同源负向判断视为独立证据

  • isPurchaseConfirmationPanel（约 542～545 行）和 finalSubmitTargets（约 812～824 行）均依赖 PddScreenParser 的面板类型；未识别为采购确认面板时，后者直接返回空。
  • 因此，“不是规格面板”与“找不到提交按钮”并不是两项独立反证。未加载完的旧面板可能同时满足二者，并残留唯一“修改”节点。
  • Claude 在消息 #93 已确认并撤回上一轮“两个负向条件足以排除旧面板”的判断。
  • Claude 后续统计称上述 43 次“地址保存后无法返回订单页面”均为 PURCHASE_ADDRESS_SAVE_TIMEOUT，不是返回动作直接失败的 PURCHASE_ADDRESS_UPDATE_FAILED。这只支持失败发生在返回动作后的证据等待阶段；backPurchase() 返回 true 不等于真实页面已经返回，不能由此认定只需补滚动。

目标与范围

  • 只处理环节①②的控件就绪等待，减少标题先出现、控件尚未就绪就提前失败的问题。
  • 超时以现有错误码及无敏感信息的诊断，区分“未观察到目标页标题”“曾见标题但控件未就绪”“候选仍不唯一”。这些是观测结果，不把标题存在等同于页面已被完整确认。
  • 环节②可独立实施和交付；环节①的识别调整必须先补足真实场景证据再发布。部分交付时明确标注①待验证，不能宣称整单完成。

非目标

  • 不付款、不使用 Android OCR/VLM；不改提交订单、不可逆边界及核单（#365）。
  • 环节③、④均不修改：不增加保存后的滑动、返回、保存重试或订单重试；④待现场证据确认后另行评估，不保留本单“可顺便纳入”的入口。
  • 不放宽地址入口、修改按钮及详细地址输入框的唯一性；不猜测候选、不点第一个。
  • 不改地址后缀规则、地址保存回读和最终复核要求。
  • 不重构通用页面分类器，不改变共用 shippingAddressEditors 的语义；不引入新接口、数据库迁移或新错误码。

最小方案（②已实现；①仍为待验证设计）

② 修改按钮 → 地址编辑页：局部等待输入框真正就绪

  1. 仅在本次进入编辑页的等待逻辑中，沿用“详细地址”标签对应区域的定位约束，分别计算：
    • structural：区域内可见 EditText 的去重数量，不因禁用或内容为空而排除。
    • ready：上述结构候选中 enabled、实际 text 非空，且未被 hint 元数据标识为提示文字的数量；不使用 contentDescription 补充空值。
    • 不以页面全部 EditText 数量代替详细地址区域；收货人、电话不能成为可选替代目标。
  2. 沿用一个现有 50 次采样预算；只有当前帧 structural == 1 && ready == 1 才通过。保留现有暂停，不另加“先等标题、再等输入框”的第二轮预算。
  3. 删除“连续 3 次多候选就提前失败”的提议。 空值、禁用、零候选或多候选均可在本轮预算内继续只读等待；超时仍不唯一或未就绪才失败。既有登录/风控/页面异常等安全失败逻辑仍保留。
  4. 从通过判断的同一帧读取当前地址值并构造目标；随后沿用 inputFresh 的重新定位及单次输入。重新定位失败仍失败，不重试输入、不重复点击修改。
  5. 超时诊断只保留最小的 titleSeen 布尔值和最后一帧 structural/ready 计数，并用固定的 stage/reason 分类：
    • 从未见过编辑页标题：复用 PURCHASE_ADDRESS_EDIT_TIMEOUT。
    • 曾见标题但区域无候选、候选为空/禁用或存在歧义：复用 PURCHASE_ADDRESS_UPDATE_FAILED，区分原因。
    • 不只按最后一帧标题是否存在归因；末帧空树不能抹掉此前已观察到标题的事实。
  6. 不保存地址、收货人、电话、输入值或节点文字集合；不新增诊断数据库字段。继续沿用既有任务、设备、规则快照关联。

②审核补修：仅补齐真实输入值与 hint 防护（2026-10-08）

  • 用户授权：“按照你的建议最小补齐”。依据 Claude 评论 8969 / SynapBus #97，先核验再采纳；旧实现同样使用非空 label，不能证明 hint 风险由本次新增，也不能据此认定历史失败根因。
  • 内存 SnapshotNode 末尾增加默认 null 的 hintText / showingHintText；capture() 仅在 API 26+ 获取，低版本保持 null。新字段不写入诊断库、请求、日志或文件，不修改全局 label 的回退语义。
  • 环节②就绪要求实际 text.trim() 非空；排除 showingHintText == true，或非空 hintText.trim() 与 text.trim() 相同。目标地址原值也使用本次通过帧的实际 text，不以 contentDescription 替代。
  • hint 持续存在时沿用原采样预算，只读等待；到期复用 PURCHASE_ADDRESS_UPDATE_FAILED，可附固定 reason=editor_hint，不输出文字内容。
  • 不改 inputFresh、共享 shippingAddressEditors、①③④、保存/回读/提交流程，不新增点击、输入重试、接口、错误码或数据库迁移。
  • 回归补充：先 hint 后真实值；一直 hint；text 为空而 description 非空；hint 标志与 hint 文本两种证据；元数据缺失兼容及全局 label 不变。未就绪前不输入/保存，仍保留结构唯一性。
  • 限制：API <26 或应用未正确提供 hint 元数据时，非空 text 无法完全区分提示与真实输入值；不宣称彻底识别所有提示文字。真机验证不在本轮授权内。

① 地址入口 → 地址列表：暂定识别方案，证据未闭合

  • 保留现有入口点击后的 pause(1_000)，在现有单轮等待预算内等待下一步修改目标就绪，不新增点击、滑动或返回。
  • 暂定候选条件：PDD 包名、地址列表标题、addressModifyTargets 能唯一消歧；保留多地址情况下“已设默认”的既有消歧路径和动作前的可操作性验证。“不是采购确认面板”“无提交目标”最多作为附加约束，不是独立或充分证据；单独缺少提交按钮不能判定进入地址列表。
  • 目前无法证明上述组合已能排除未加载完成的旧规格面板。正式识别条件须由下节的真实正向结构证据确定，不通过构造仅能满足代码的测试数据来证明可靠。
  • 复用 PURCHASE_ADDRESS_PANEL_TIMEOUT 和已有 PURCHASE_ADDRESS_EDIT_AMBIGUOUS 等错误语义；缺失/歧义只附无敏感标量诊断，不扩展错误码。多地址中默认卡可唯一定位时继续；不能消歧时不操作。
  • 不修改通用 PddScreenParser、finalSubmitTargets 或共享编辑框查询，避免牵动保存退出、返回及最终复核。

证据缺口与发布条件

  1. 当前未发现经过验证的真实地址列表正向结构。 PurchaseLiveAutomationTest.kt 约 821～826 行的 “panel” 是合成数据，不是真机证据。
  2. 需核对真实的单地址、多地址列表及从旧规格面板进入列表的过渡状态：包名/Activity/window 结构、列表标题、地址卡与修改入口的层级、默认卡消歧，以及旧节点是否暂时残留。只记录必要的脱敏结构证据，不记录地址正文或个人信息。
  3. 证据来源可选：#364 在其自身已授权安全边界内产生的有效诊断；或用户另行授权的一次只读现场核对。本单正文更新不授权读取或落盘原始控件树、整屏截图，也不授权改地址或下单。
  4. ①发布前必须用真实单地址、多地址场景核验，并覆盖未识别旧面板残留“修改”节点的反例。若暂定条件仍会误判，应先收敛识别条件并回写方案，不能以“双方讨论一致”替代验证。
  5. ②技术上可独立推进；不要求为等待①证据而扩大范围或增加功能。若仅交付②，需明确记录①仍未交付及原因。
  6. ④的失败根因仍未知；“返回后地址被裁切、需要滚动”仅为假设，不能因历史错误数量多而直接实施。

子项目影响、依赖与并行

  • 仅 Android PurchaseLiveAutomation 的①②局部逻辑及受影响测试；本轮②补修另允许为内存 SnapshotNode 增加可选 hint 元数据及 capture() 的 API 26+ 读取，不改全局 label 或采集器业务逻辑；Server、Web、业务数据库、接口字段和错误码集合不变。
  • 与 #365 可能修改同一文件的不同函数，可以隔离开发，串行合并并验证冲突；不互相混入核单/改地址逻辑。
  • #364 不是②的代码依赖，也不是①唯一证据渠道；但①存在必须补齐的现场证据依赖，不能再笼统写成“无依赖”。
  • 2026-10-08 已获“做#366”实施授权；本轮先交付②。真机操作、安装及发布不在本次自动执行范围。

设计证据

  • 非 UI 修复，无需界面原型；流程设计以本正文为准。
  • 2026-10-08 Claude / Codex 通过 SynapBus #91、#93 达成上述技术共识；用户随后授权整合正文。
  • ②实现证据见本正文末尾及交付评论；①仅为方案共识与证据缺口记录。合成测试不代表真机验收，尚未合并或发布。

验收与回归测试（②自动化已执行；①及真机待验证）

② 可独立验证项

  • 标题先出现，输入框延迟出现、先空后有值、先禁用后启用，均能在同一预算内等到就绪。

  • 结构候选持续超过 3 次为多个，随后变唯一时正常通过；直到预算结束仍多候选则失败，期间不输入。

  • 结构上有多个候选但仅一个 ready 时不能通过，不能因过滤禁用/空值节点掩盖歧义。

  • 收货人/电话正常位于其他行时不计入目标；小屏或换行导致与详细地址区域重叠而无法唯一消歧时失败，不向错误字段输入。

  • 无标题超时、曾有标题但末帧空树、零候选、空/禁用、多个候选分别验证现有错误码和最小诊断。

  • 就绪判断与读取值来自同一帧；inputFresh 重定位漂移、无候选或歧义仍按既有失败处理，不重试写入。

  • ②审核补修：hint→真实值仅在真实值出现后输入；持续 hint / 空 text 仅 description 时等待后失败，禁止输入/保存；覆盖可选元数据缺失兼容。

① 待现场证据补齐后验证项

  • 点击后旧规格面板仍含“收货地址”时不会提前放行。
  • 旧面板类型未识别、提交目标为空且残留唯一“修改”时，不被误判为地址列表。
  • 空白过渡页、无关弹窗、非 PDD 页面均不通过。
  • 多地址列表默认卡唯一可消歧时允许继续；没有唯一默认卡/修改目标时明确失败、不猜测。
  • 真实单地址及多地址列表验证完成，记录设备/App/规则版本及脱敏结构证据；合成数据不替代真机验证。

共同回归与交付

  • 本轮②沿用现有单轮预算及暂停；测试验证无新增点击、滑动、返回、输入重试。①③④代码未改；①新增识别方案尚未实施。
  • 保存后直接回到规格面板及经地址列表返回两条既有路径合成回归通过；③④实现与最终新地址、唯一提交按钮复核要求保持不变。
  • 现有相关地址流程测试、Android 单元测试及构建通过；具体命令、结果、提交和未覆盖项见交付评论。
  • 诊断不含地址、电话、收货人及其他敏感值；共享 shippingAddressEditors 未改，既有调用回归通过。
  • 本轮仅交付②，①未实施/未验证/未发布；本单未标记全部完成、未关闭。
  • 发布后按相同口径观察编辑页失败及相关回归；不得承诺本单已修复④的历史超时。真机改地址/下单验证另行授权，永久禁止付款。

风险与回退

  • 虽在提交订单前，仍属采购改地址流程；实施、真机及发布按项目规则取得相应授权。
  • 不增加采样预算或固定暂停，但就绪条件更严格，原先提前失败的路径可能等待更久；采样和解析有耗时，不承诺墙钟时长严格不变或所有正常路径绝不变慢。
  • ①主要风险是旧页面残留误识别；②主要风险是布局交叠及共享查询回归，因此局部实现、单轮等待、保留唯一性，不扩展动作。
  • 回退对应局部代码提交即可，无接口或数据迁移；不得通过清除任务数据或重下单回退。

文档影响

  • 已按②实际实现更新 Wiki Troubleshooting 与 Android-Agent-API-Contract；各页在线回读内容/revision 后完成镜像同步及一致性检查（17 页通过）。未将①待验证条件写成已有能力。
  • 实施时更新 Wiki Troubleshooting 的等待/诊断说明；若现有错误码的阶段映射说明改变，同步 Agent-API-Contract 对应说明，不新增错误码。只记录实际实现的①/②范围，不把待验证识别条件写成已有能力。
  • 有长期事实变化时，按 Wiki-first 在线更新并回读 revision，再执行一轮 sync 和 sync --check；不直接编辑本地镜像，不创建任务归档。

前轮交付记录（650f3a6 / 5314313；本轮补修记录见下）

  • ②部分交付待验收：实现提交 650f3a6ba115bd22cdefef705eeab4535487cccd；Wiki 镜像提交 5314313；分支 fix/366-address-editor-ready 已推送。
  • 测试：目标类基线 44 项通过；新增 18 项，最终 RED 为 62 项中 15 失败，GREEN 为 62 项全部通过。完整 Debug / Release 各 514 项测试，均 0 失败/错误/跳过；Debug APK 构建成功。两轮独立规格/质量审查通过。
  • APK：android/app/build/outputs/apk/debug/app-debug.apk，6,412,438 字节；SHA-256 47a2ee57b07f8c95a11b7f9bee6a8bd0392fa96123414c5d216476e678da0e0a。沿用 0.9.69 / versionCode 82，未升级版本号；以提交和哈希识别本轮产物。
  • ①未实施：仍缺真实单地址、多地址列表的正向结构证据。③④不改。本轮未操作真机、未安装、未合并 main、未发布；不能宣称整单完成或历史错误均已解决。
  • 工作区：D:/OPC/goauto-worktrees/issue-366，分支未合并，按规则保留。
  • 已知无关基线问题：harness.py check --strict 因既有 docs/evidence/pdd-home-35727-summary.md 未登记镜像而失败，该文件在基线 7622795 已存在，本单未改；Wiki sync --check 独立通过。不能将仓库所有检查表述为全绿。
  • 历史统计仅保留为调查线索，不作为根因或修复效果证明。

审核补修交付（2026-10-08）

  • 范围：完成评论 8969 的 Important 最小补修，并补齐 contentDescription 不能代替实际输入值的保护。只调整②，①证据缺口与③④边界不变。
  • 代码提交 7fdfe04658d16a05ebcb016ee964a7263eb74802；Wiki 镜像提交 d1996d2。工单分支 fix/366-address-editor-ready 已推送，未合并 main。
  • TDD：基线 62/62；description-only 用例 RED 63 中 1 失败；hint 测试 RED 70 中 6 失败；最小实现 GREEN 70/70（新增 8 项）。规格复核和整体②代码质量复核通过。
  • 完整验证：./scripts/verify.ps1 -Component android exit 0；test 耗时 9m49s，Debug / Release 各 51 suites、522 tests，0 failures / errors / skipped；assembleDebug 成功（4s）。root 独立回读本轮两套 XML、APK 哈希及干净 Git 状态，git diff --check 通过。保留已有编译警告，没有新增编译错误。
  • 原 hint 风险在旧 label 非空路径也存在，未证明由本次引入，亦未证明历史失败均由 hint 导致。API <26 或应用未正确提供 hint 元数据时仍有识别局限，不能承诺彻底识别所有提示文字。
  • 两个新增节点属性仅用于内存，不改变全局 label，不新增持久化、日志或请求字段。固定 editor_hint 只用于已有 UPDATE_FAILED 的诊断原因；未增加错误码。
  • Wiki Troubleshooting revision b096c5a86f3ce0f9dbf3dc0591f7b5cf69f711c7，Android-Agent-API-Contract revision f97ac6b8784fc200ee68e9e2eb4a1201296049f0；在线回读成功，随后一轮 sync + sync --check 共 17 页通过。
  • APK：android/app/build/outputs/apk/debug/app-debug.apk，6,823,074 bytes；SHA-256 9c0461e9ed8f11d9f53541ff1a2cfa0de0e902b91422d411c2578a36bdf98837。沿用 0.9.69 / versionCode 82，未安装或发布。
  • 未进行真机/低版本设备验证、真实改地址、下单或付款。①仍待现场证据，整单不能标记完成或关闭；worktree 未合并保留。
  • 已知无关 strict 镜像登记基线问题见前轮记录，本轮没有修改该文件或扩大范围修复。

#365 + #366 集成验证结果（2026-10-08）

  • 用户授权范围为两项集成验证；基线 origin/main 7622795d97d4da3dd638619af99628b0352a42dd。独立集成分支 integration/365-366-validation 已推送，最终提交 d2083e71fbe70de2519e79eb631a1cd93af8c486。
  • 机械集成提交 5206a6fd7d6666650f2d336e61655f4f647f7a9e，保留两个源分支全部提交：#365 c55455d、#366 d1996d2。生产代码自动合并无冲突；两份 Wiki 镜像冲突保留 #365 中已同步、包含两单说明的较新版本，3份镜像与 c55455d 完全一致，未手工改写长期文档。
  • #366 仅包含已交付的②编辑框就绪等待与 hint 保护；①未实现、仍缺现场证据，③④不改。本轮未新增生产逻辑、Server/Web/数据库/接口/版本变化。
  • 合并后原有目标测试完整保留：基线44 + #365新增13 + #366新增26 = 83项，逐项名称和正文核对无遗漏；先运行83项目标测试通过。
  • 完整 scripts/verify.ps1 -Component android 退出0：Debug/Release各51 suites、535 tests，均0 failures/errors/skipped；test BUILD SUCCESSFUL 9m49s、assembleDebug 4s。主代理读取双variant XML核验，时间分别为2026-10-08 11:42、11:47（北京时间）。
  • 随后仅追加1项跨阶段合成测试，提交 d2083e7（测试文件+71行，无生产变化）：同一执行器经历4帧hint和第5帧真实值，地址等待>40秒后单次输入/保存/提交，再模拟4秒Back、第140帧才取得订单证据；断言Back完成后28～30秒仍成功、输入/保存/提交各一次、核单无额外点击/滑动/拉前台。
  • 新增测试后运行 gradlew.bat :app:testDebugUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest :app:testReleaseUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest：exit0，目标类Debug/Release各84项，0 failures/errors/skipped，新增用例在两份XML均存在。首次仅给末个task附--tests的命令筛选有歧义，精确中断后纠正命令；中断结果不计作通过。本轮未宣称新增用例后又重跑536项全量，实际证据是原组合全量535项＋最终目标类84项双variant。
  • 规格、代码质量及新增测试复核均通过，无阻断问题；合成driver与可控时钟不代表真实PDD无障碍、hint元数据、fresh定位或现场成功率已验证。
  • 最终HEAD再次 assembleDebug 成功；APK生产输入未变、哈希与全量构建相同。产物 D:/OPC/goauto-worktrees/issue-365/android/app/build/outputs/apk/debug/app-debug.apk，6,824,084 bytes，SHA256 e0155cb5266c8228598db6c45eda62d9f2a5dfd774f4a8bf71f0635f85f17b3c；版本仍0.9.69/82。
  • git diff --check通过，工作区干净；远端回读确认main及两源分支未改变。集成分支保留在issue-365工作区，issue-366工作区保留；未合并main，不删除未合并工作区。
  • 无新增长期文档影响：仅验证已批准两项实现并补回归测试，故不重复Wiki更新/sync。既有strict镜像登记问题沿用前述限制，本轮未扩展修复或宣称全仓检查全绿。
  • 未安装、未发布、未迁移、未操作真机/改地址/创建订单/付款；两工单仍待验收，#366仍是部分交付。失败现场完整控件树持久化/上传属于#364，本集成包未包含；#366的hint字段只在内存使用。

2026-10-08 已授权合并 main（#364/#365/#366）

  • 用户明确要求“把#364 #365 #366合并到main”；三单已合入并推送 e450ac28989de6827328b411e4bdc050dded9ab3，远端回读一致。合并前main为5f45932；#364实现4581ee5，原#365/#366集成d2083e7，三单生产集成8c4940d。保留源分支及全部提交，无生产代码冲突，没有压缩或丢弃历史。
  • 合并组合完整Android Debug/Release各56 suites、564项，0失败/错误/跳过，test+assembleDebug成功（10m9s）。正式main合并后的文件树与已验证组合完全一致，再次执行相同命令exit0/UP-TO-DATE；不将增量检查冒称第二次全量执行。
  • 合并后Server六个受影响包及构建通过，Web构建、13项浏览器mock回归通过；独立集成代码审核PASS。未改动的SYB解析12项测试在同一生产基线7622795也失败，strict存在旧未登记镜像问题，未宣称全仓检查全绿或扩范围修复。
  • 集成APK仍0.9.69/82，路径 D:/OPC/goauto-worktrees/issue-364/android/app/build/outputs/apk/debug/app-debug.apk，SHA256 bf8ed021d2bfcc05d49eda54a7b40240a30eda2d1e93199c8dee408c052b1dbe。未安装或发布；若通过Admin分发需按后续发布流程处理版本号，不把同versionCode产物宣称自动更新已启用。
  • #366仅合入已交付②编辑框就绪等待及hint保护，①仍缺真实地址列表证据，未实现；③④不改。#364现场真机端到端、容量/Binder实测与真实Android SQLite链路待验。
  • 本轮无线上迁移/权限写入/发布/重启，无本地业务服务重启，无真机改地址/下单/付款。临时Web测试服务已停止。
  • 三张工单保持打开，合并不等于验收。配套发布及真机验收尚未完成，worktree及其本地合成验证产物暂留，不删除资料；后续发布完成后按项目清理规则处理。
## 基本信息 - 类型：缺陷修复（Android Agent 采购改地址流程的等待条件）。 - 状态：**②已合并main、尚未发布，部分交付待验收：②及提示文字审核补修已实现并验证；①未实施，仍待真实地址列表证据。③④不改。** - 授权记录：2026-10-08 用户先授权整合共识，随后明确“做#366”。本轮按已建议顺序先实施②并完成测试/构建/提交；不自动进行真机改地址、下单、安装或发布。 - 审核来源：SynapBus #goauto 消息 #87、#89、#91、#93（对应私信为重复转发）；以 #93 的最终共识为准。 - 来源：2026-10-08 用户提问：从规格面板地址入口进入地址面板、点击修改进入编辑面板、保存后回到地址面板、退出地址面板回到规格面板，这几步如果没有在指定时间内等到目标页面，现有代码是否处理。Claude Code 只读核对代码和线上数据后建单，用户确认新建工单。 - 关联：#364（经授权的失败现场诊断，可作为证据来源）、#365（核单等待，不同代码段）。无代码前置依赖；环节①存在证据前置要求，详见下文。 ## 代码事实与调查快照 - 代码核验日期：2026-10-08；基线：`7622795d97d4da3dd638619af99628b0352a42dd`。 - 代码路径：`android/app/src/main/java/cn/ilapage/goauto/agent/automation/PurchaseLiveAutomation.kt`。 - 下列线上统计为 Claude 于 2026-10-08 只读调查的历史快照；Codex 本轮未独立重查，统计不能证明每次失败的现场根因。 ### 现有等待逻辑（`PurchaseLiveAutomation.kt`） 通用 `waitFor`（约 682 行）：最多 50 次采样，采样间暂停 200ms，另外还有截取与解析耗时；这是采样次数预算，不是严格的 10 秒或 15 秒墙钟超时。到期以指定错误码明确失败。 | 环节 | 现有等待条件 | 超时错误 | |---|---|---| | ① 规格面板点收货地址 → 地址列表 | 先固定 `pause(1_000)`，再 `waitFor` 页面出现 label 为「收货地址」的节点（约 134～137 行） | `PURCHASE_ADDRESS_PANEL_TIMEOUT` | | ② 点「修改」→ 地址编辑页 | `waitFor` 页面出现含「详细地址」的节点（约 512 行） | `PURCHASE_ADDRESS_EDIT_TIMEOUT` | | ③ 点「保存」→ 离开编辑页 | `waitForStableAddressEditorExit`（50 次采样，编辑框连续两次消失）+ `waitForSettledPanelAfterAddressSave`（最多 5 秒） | `PURCHASE_ADDRESS_SAVE_TIMEOUT` | | ④ 地址列表按返回 → 规格面板 | `backPurchase()` 后 `waitFor` 出现已保存地址且提交按钮唯一（约 533～536 行） | `PURCHASE_ADDRESS_SAVE_TIMEOUT`「地址保存后无法返回订单页面」 | ### 发现的问题 1. **环节②等到标题就判断输入框，输入框未就绪即失败。** - `waitFor` 条件只要求页面出现「详细地址」文字；返回后立即 `shippingAddressEditors(edit)`，数量不为 1 就以 `PURCHASE_ADDRESS_UPDATE_FAILED`「没有找到唯一的详细地址输入框」失败（约 515～516 行），不再等待。 - `shippingAddressEditors` 要求 EditText 的 label 非空（约 761 行 `editor.label.isNotBlank()`）。若 PDD 先渲染标题、稍后才填入现有地址，此时一个输入框都匹配不到。 - 推测（待现场证据确认）：输入框延迟就绪可能解释其中部分失败，不能据此认定是全部或主要来源。线上数据：设备 7 自 09-21 起共 39 次，10-07 单日 13 次且成批出现（14:50～15:01 连续 5 次，17:15～17:23 连续 6 次）；设备 8 从未出现。另有设备 7「详细地址修改失败」7 次（`inputFresh` 失败），可能与输入框未就绪有关。 2. **环节①等待条件不够特定。** - 规格面板上的地址卡本身就含「收货地址」等通用文字（`ADDRESS_CARD_GENERIC_LABELS`，约 1054 行），条件可能在尚未离开规格面板时就成立，只靠前面固定的 1 秒兜底。 - 进入 `editAndVerifyAddress` 后立即查找「修改」按钮，不唯一就以 `PURCHASE_ADDRESS_EDIT_AMBIGUOUS` 失败，不再等待。线上仅设备 8 在 09-21 出现 1 次，影响较小，但属于同类缺陷。 3. **环节④失败较多，原因待确认（不预设修法）。** - 「地址保存后无法返回订单页面」：设备 7 共 21 次、设备 8 共 22 次（09-17～10-07）。 - 环节③在保存后直接回到规格面板时，会用 `restoreFinalEvidenceInCurrentPanel` 在面板内滚动查找新地址（最多 5 次）；但环节④按返回后只被动等待，不滚动。若返回后面板的地址卡或提交按钮不在可视区，可能等满后失败。这只是推测，需现场证据。 ### 审核补充：不能将同源负向判断视为独立证据 - `isPurchaseConfirmationPanel`（约 542～545 行）和 `finalSubmitTargets`（约 812～824 行）均依赖 `PddScreenParser` 的面板类型；未识别为采购确认面板时，后者直接返回空。 - 因此，“不是规格面板”与“找不到提交按钮”并不是两项独立反证。未加载完的旧面板可能同时满足二者，并残留唯一“修改”节点。 - Claude 在消息 #93 已确认并撤回上一轮“两个负向条件足以排除旧面板”的判断。 - Claude 后续统计称上述 43 次“地址保存后无法返回订单页面”均为 `PURCHASE_ADDRESS_SAVE_TIMEOUT`，不是返回动作直接失败的 `PURCHASE_ADDRESS_UPDATE_FAILED`。这只支持失败发生在返回动作后的证据等待阶段；`backPurchase()` 返回 true 不等于真实页面已经返回，不能由此认定只需补滚动。 ## 目标与范围 - 只处理环节①②的控件就绪等待，减少标题先出现、控件尚未就绪就提前失败的问题。 - 超时以现有错误码及无敏感信息的诊断，区分“未观察到目标页标题”“曾见标题但控件未就绪”“候选仍不唯一”。这些是观测结果，不把标题存在等同于页面已被完整确认。 - 环节②可独立实施和交付；环节①的识别调整必须先补足真实场景证据再发布。部分交付时明确标注①待验证，不能宣称整单完成。 ## 非目标 - 不付款、不使用 Android OCR/VLM；不改提交订单、不可逆边界及核单（#365）。 - **环节③、④均不修改**：不增加保存后的滑动、返回、保存重试或订单重试；④待现场证据确认后另行评估，不保留本单“可顺便纳入”的入口。 - 不放宽地址入口、修改按钮及详细地址输入框的唯一性；不猜测候选、不点第一个。 - 不改地址后缀规则、地址保存回读和最终复核要求。 - 不重构通用页面分类器，不改变共用 `shippingAddressEditors` 的语义；不引入新接口、数据库迁移或新错误码。 ## 最小方案（②已实现；①仍为待验证设计） ### ② 修改按钮 → 地址编辑页：局部等待输入框真正就绪 1. 仅在本次进入编辑页的等待逻辑中，沿用“详细地址”标签对应区域的定位约束，分别计算： - `structural`：区域内可见 EditText 的去重数量，不因禁用或内容为空而排除。 - `ready`：上述结构候选中 enabled、实际 `text` 非空，且未被 hint 元数据标识为提示文字的数量；不使用 `contentDescription` 补充空值。 - 不以页面全部 EditText 数量代替详细地址区域；收货人、电话不能成为可选替代目标。 2. 沿用一个现有 50 次采样预算；只有当前帧 `structural == 1 && ready == 1` 才通过。保留现有暂停，不另加“先等标题、再等输入框”的第二轮预算。 3. **删除“连续 3 次多候选就提前失败”的提议。** 空值、禁用、零候选或多候选均可在本轮预算内继续只读等待；超时仍不唯一或未就绪才失败。既有登录/风控/页面异常等安全失败逻辑仍保留。 4. 从通过判断的同一帧读取当前地址值并构造目标；随后沿用 `inputFresh` 的重新定位及单次输入。重新定位失败仍失败，不重试输入、不重复点击修改。 5. 超时诊断只保留最小的 `titleSeen` 布尔值和最后一帧 `structural/ready` 计数，并用固定的 stage/reason 分类： - 从未见过编辑页标题：复用 `PURCHASE_ADDRESS_EDIT_TIMEOUT`。 - 曾见标题但区域无候选、候选为空/禁用或存在歧义：复用 `PURCHASE_ADDRESS_UPDATE_FAILED`，区分原因。 - 不只按最后一帧标题是否存在归因；末帧空树不能抹掉此前已观察到标题的事实。 6. 不保存地址、收货人、电话、输入值或节点文字集合；不新增诊断数据库字段。继续沿用既有任务、设备、规则快照关联。 ### ②审核补修：仅补齐真实输入值与 hint 防护（2026-10-08） - 用户授权：“按照你的建议最小补齐”。依据 Claude 评论 8969 / SynapBus #97，先核验再采纳；旧实现同样使用非空 label，不能证明 hint 风险由本次新增，也不能据此认定历史失败根因。 - 内存 SnapshotNode 末尾增加默认 null 的 hintText / showingHintText；capture() 仅在 API 26+ 获取，低版本保持 null。新字段不写入诊断库、请求、日志或文件，不修改全局 label 的回退语义。 - 环节②就绪要求实际 text.trim() 非空；排除 showingHintText == true，或非空 hintText.trim() 与 text.trim() 相同。目标地址原值也使用本次通过帧的实际 text，不以 contentDescription 替代。 - hint 持续存在时沿用原采样预算，只读等待；到期复用 PURCHASE_ADDRESS_UPDATE_FAILED，可附固定 reason=editor_hint，不输出文字内容。 - 不改 inputFresh、共享 shippingAddressEditors、①③④、保存/回读/提交流程，不新增点击、输入重试、接口、错误码或数据库迁移。 - 回归补充：先 hint 后真实值；一直 hint；text 为空而 description 非空；hint 标志与 hint 文本两种证据；元数据缺失兼容及全局 label 不变。未就绪前不输入/保存，仍保留结构唯一性。 - 限制：API <26 或应用未正确提供 hint 元数据时，非空 text 无法完全区分提示与真实输入值；不宣称彻底识别所有提示文字。真机验证不在本轮授权内。 ### ① 地址入口 → 地址列表：暂定识别方案，证据未闭合 - 保留现有入口点击后的 `pause(1_000)`，在现有单轮等待预算内等待下一步修改目标就绪，不新增点击、滑动或返回。 - **暂定候选条件**：PDD 包名、地址列表标题、`addressModifyTargets` 能唯一消歧；保留多地址情况下“已设默认”的既有消歧路径和动作前的可操作性验证。“不是采购确认面板”“无提交目标”最多作为附加约束，不是独立或充分证据；单独缺少提交按钮不能判定进入地址列表。 - 目前无法证明上述组合已能排除未加载完成的旧规格面板。正式识别条件须由下节的真实正向结构证据确定，不通过构造仅能满足代码的测试数据来证明可靠。 - 复用 `PURCHASE_ADDRESS_PANEL_TIMEOUT` 和已有 `PURCHASE_ADDRESS_EDIT_AMBIGUOUS` 等错误语义；缺失/歧义只附无敏感标量诊断，不扩展错误码。多地址中默认卡可唯一定位时继续；不能消歧时不操作。 - 不修改通用 `PddScreenParser`、`finalSubmitTargets` 或共享编辑框查询，避免牵动保存退出、返回及最终复核。 ## 证据缺口与发布条件 1. **当前未发现经过验证的真实地址列表正向结构。** `PurchaseLiveAutomationTest.kt` 约 821～826 行的 “panel” 是合成数据，不是真机证据。 2. 需核对真实的单地址、多地址列表及从旧规格面板进入列表的过渡状态：包名/Activity/window 结构、列表标题、地址卡与修改入口的层级、默认卡消歧，以及旧节点是否暂时残留。只记录必要的脱敏结构证据，不记录地址正文或个人信息。 3. 证据来源可选：#364 在其自身已授权安全边界内产生的有效诊断；或用户另行授权的一次只读现场核对。**本单正文更新不授权读取或落盘原始控件树、整屏截图，也不授权改地址或下单。** 4. ①发布前必须用真实单地址、多地址场景核验，并覆盖未识别旧面板残留“修改”节点的反例。若暂定条件仍会误判，应先收敛识别条件并回写方案，不能以“双方讨论一致”替代验证。 5. ②技术上可独立推进；不要求为等待①证据而扩大范围或增加功能。若仅交付②，需明确记录①仍未交付及原因。 6. ④的失败根因仍未知；“返回后地址被裁切、需要滚动”仅为假设，不能因历史错误数量多而直接实施。 ## 子项目影响、依赖与并行 - 仅 Android `PurchaseLiveAutomation` 的①②局部逻辑及受影响测试；本轮②补修另允许为内存 `SnapshotNode` 增加可选 hint 元数据及 `capture()` 的 API 26+ 读取，不改全局 `label` 或采集器业务逻辑；Server、Web、业务数据库、接口字段和错误码集合不变。 - 与 #365 可能修改同一文件的不同函数，可以隔离开发，串行合并并验证冲突；不互相混入核单/改地址逻辑。 - #364 不是②的代码依赖，也不是①唯一证据渠道；但①存在必须补齐的现场证据依赖，不能再笼统写成“无依赖”。 - 2026-10-08 已获“做#366”实施授权；本轮先交付②。真机操作、安装及发布不在本次自动执行范围。 ## 设计证据 - 非 UI 修复，无需界面原型；流程设计以本正文为准。 - 2026-10-08 Claude / Codex 通过 SynapBus #91、#93 达成上述技术共识；用户随后授权整合正文。 - ②实现证据见本正文末尾及交付评论；①仅为方案共识与证据缺口记录。合成测试不代表真机验收，尚未合并或发布。 ## 验收与回归测试（②自动化已执行；①及真机待验证） ### ② 可独立验证项 - [x] 标题先出现，输入框延迟出现、先空后有值、先禁用后启用，均能在同一预算内等到就绪。 - [x] 结构候选持续超过 3 次为多个，随后变唯一时正常通过；直到预算结束仍多候选则失败，期间不输入。 - [x] 结构上有多个候选但仅一个 ready 时不能通过，不能因过滤禁用/空值节点掩盖歧义。 - [x] 收货人/电话正常位于其他行时不计入目标；小屏或换行导致与详细地址区域重叠而无法唯一消歧时失败，不向错误字段输入。 - [x] 无标题超时、曾有标题但末帧空树、零候选、空/禁用、多个候选分别验证现有错误码和最小诊断。 - [x] 就绪判断与读取值来自同一帧；`inputFresh` 重定位漂移、无候选或歧义仍按既有失败处理，不重试写入。 - [x] ②审核补修：hint→真实值仅在真实值出现后输入；持续 hint / 空 text 仅 description 时等待后失败，禁止输入/保存；覆盖可选元数据缺失兼容。 ### ① 待现场证据补齐后验证项 - [ ] 点击后旧规格面板仍含“收货地址”时不会提前放行。 - [ ] **旧面板类型未识别、提交目标为空且残留唯一“修改”时，不被误判为地址列表。** - [ ] 空白过渡页、无关弹窗、非 PDD 页面均不通过。 - [ ] 多地址列表默认卡唯一可消歧时允许继续；没有唯一默认卡/修改目标时明确失败、不猜测。 - [ ] 真实单地址及多地址列表验证完成，记录设备/App/规则版本及脱敏结构证据；合成数据不替代真机验证。 ### 共同回归与交付 - [x] 本轮②沿用现有单轮预算及暂停；测试验证无新增点击、滑动、返回、输入重试。①③④代码未改；①新增识别方案尚未实施。 - [x] 保存后直接回到规格面板及经地址列表返回两条既有路径合成回归通过；③④实现与最终新地址、唯一提交按钮复核要求保持不变。 - [x] 现有相关地址流程测试、Android 单元测试及构建通过；具体命令、结果、提交和未覆盖项见交付评论。 - [x] 诊断不含地址、电话、收货人及其他敏感值；共享 `shippingAddressEditors` 未改，既有调用回归通过。 - [x] 本轮仅交付②，①未实施/未验证/未发布；本单未标记全部完成、未关闭。 - [ ] 发布后按相同口径观察编辑页失败及相关回归；不得承诺本单已修复④的历史超时。真机改地址/下单验证另行授权，永久禁止付款。 ## 风险与回退 - 虽在提交订单前，仍属采购改地址流程；实施、真机及发布按项目规则取得相应授权。 - 不增加采样预算或固定暂停，但就绪条件更严格，原先提前失败的路径可能等待更久；采样和解析有耗时，不承诺墙钟时长严格不变或所有正常路径绝不变慢。 - ①主要风险是旧页面残留误识别；②主要风险是布局交叠及共享查询回归，因此局部实现、单轮等待、保留唯一性，不扩展动作。 - 回退对应局部代码提交即可，无接口或数据迁移；不得通过清除任务数据或重下单回退。 ## 文档影响 - 已按②实际实现更新 Wiki Troubleshooting 与 Android-Agent-API-Contract；各页在线回读内容/revision 后完成镜像同步及一致性检查（17 页通过）。未将①待验证条件写成已有能力。 - 实施时更新 Wiki Troubleshooting 的等待/诊断说明；若现有错误码的阶段映射说明改变，同步 Agent-API-Contract 对应说明，不新增错误码。只记录实际实现的①/②范围，不把待验证识别条件写成已有能力。 - 有长期事实变化时，按 Wiki-first 在线更新并回读 revision，再执行一轮 sync 和 sync --check；不直接编辑本地镜像，不创建任务归档。 ## 前轮交付记录（650f3a6 / 5314313；本轮补修记录见下） - **②部分交付待验收**：实现提交 `650f3a6ba115bd22cdefef705eeab4535487cccd`；Wiki 镜像提交 `5314313`；分支 `fix/366-address-editor-ready` 已推送。 - 测试：目标类基线 44 项通过；新增 18 项，最终 RED 为 62 项中 15 失败，GREEN 为 62 项全部通过。完整 Debug / Release 各 514 项测试，均 0 失败/错误/跳过；Debug APK 构建成功。两轮独立规格/质量审查通过。 - APK：`android/app/build/outputs/apk/debug/app-debug.apk`，6,412,438 字节；SHA-256 `47a2ee57b07f8c95a11b7f9bee6a8bd0392fa96123414c5d216476e678da0e0a`。沿用 0.9.69 / versionCode 82，未升级版本号；以提交和哈希识别本轮产物。 - **①未实施**：仍缺真实单地址、多地址列表的正向结构证据。③④不改。本轮未操作真机、未安装、未合并 main、未发布；不能宣称整单完成或历史错误均已解决。 - 工作区：`D:/OPC/goauto-worktrees/issue-366`，分支未合并，按规则保留。 - 已知无关基线问题：`harness.py check --strict` 因既有 `docs/evidence/pdd-home-35727-summary.md` 未登记镜像而失败，该文件在基线 `7622795` 已存在，本单未改；Wiki sync --check 独立通过。不能将仓库所有检查表述为全绿。 - 历史统计仅保留为调查线索，不作为根因或修复效果证明。 ## 审核补修交付（2026-10-08） - 范围：完成评论 8969 的 Important 最小补修，并补齐 contentDescription 不能代替实际输入值的保护。只调整②，①证据缺口与③④边界不变。 - 代码提交 `7fdfe04658d16a05ebcb016ee964a7263eb74802`；Wiki 镜像提交 `d1996d2`。工单分支 `fix/366-address-editor-ready` 已推送，未合并 main。 - TDD：基线 62/62；description-only 用例 RED 63 中 1 失败；hint 测试 RED 70 中 6 失败；最小实现 GREEN 70/70（新增 8 项）。规格复核和整体②代码质量复核通过。 - 完整验证：`./scripts/verify.ps1 -Component android` exit 0；test 耗时 9m49s，Debug / Release 各 51 suites、522 tests，0 failures / errors / skipped；assembleDebug 成功（4s）。root 独立回读本轮两套 XML、APK 哈希及干净 Git 状态，git diff --check 通过。保留已有编译警告，没有新增编译错误。 - 原 hint 风险在旧 label 非空路径也存在，未证明由本次引入，亦未证明历史失败均由 hint 导致。API <26 或应用未正确提供 hint 元数据时仍有识别局限，不能承诺彻底识别所有提示文字。 - 两个新增节点属性仅用于内存，不改变全局 label，不新增持久化、日志或请求字段。固定 editor_hint 只用于已有 UPDATE_FAILED 的诊断原因；未增加错误码。 - Wiki Troubleshooting revision `b096c5a86f3ce0f9dbf3dc0591f7b5cf69f711c7`，Android-Agent-API-Contract revision `f97ac6b8784fc200ee68e9e2eb4a1201296049f0`；在线回读成功，随后一轮 sync + sync --check 共 17 页通过。 - APK：`android/app/build/outputs/apk/debug/app-debug.apk`，6,823,074 bytes；SHA-256 `9c0461e9ed8f11d9f53541ff1a2cfa0de0e902b91422d411c2578a36bdf98837`。沿用 0.9.69 / versionCode 82，未安装或发布。 - 未进行真机/低版本设备验证、真实改地址、下单或付款。①仍待现场证据，整单不能标记完成或关闭；worktree 未合并保留。 - 已知无关 strict 镜像登记基线问题见前轮记录，本轮没有修改该文件或扩大范围修复。 ## #365 + #366 集成验证结果（2026-10-08） - 用户授权范围为两项集成验证；基线 origin/main `7622795d97d4da3dd638619af99628b0352a42dd`。独立集成分支 `integration/365-366-validation` 已推送，最终提交 `d2083e71fbe70de2519e79eb631a1cd93af8c486`。 - 机械集成提交 `5206a6fd7d6666650f2d336e61655f4f647f7a9e`，保留两个源分支全部提交：#365 `c55455d`、#366 `d1996d2`。生产代码自动合并无冲突；两份 Wiki 镜像冲突保留 #365 中已同步、包含两单说明的较新版本，3份镜像与 c55455d 完全一致，未手工改写长期文档。 - #366 仅包含已交付的②编辑框就绪等待与 hint 保护；①未实现、仍缺现场证据，③④不改。本轮未新增生产逻辑、Server/Web/数据库/接口/版本变化。 - 合并后原有目标测试完整保留：基线44 + #365新增13 + #366新增26 = 83项，逐项名称和正文核对无遗漏；先运行83项目标测试通过。 - 完整 `scripts/verify.ps1 -Component android` 退出0：Debug/Release各51 suites、535 tests，均0 failures/errors/skipped；test BUILD SUCCESSFUL 9m49s、assembleDebug 4s。主代理读取双variant XML核验，时间分别为2026-10-08 11:42、11:47（北京时间）。 - 随后仅追加1项跨阶段合成测试，提交 `d2083e7`（测试文件+71行，无生产变化）：同一执行器经历4帧hint和第5帧真实值，地址等待>40秒后单次输入/保存/提交，再模拟4秒Back、第140帧才取得订单证据；断言Back完成后28～30秒仍成功、输入/保存/提交各一次、核单无额外点击/滑动/拉前台。 - 新增测试后运行 `gradlew.bat :app:testDebugUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest :app:testReleaseUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest`：exit0，目标类Debug/Release各84项，0 failures/errors/skipped，新增用例在两份XML均存在。首次仅给末个task附--tests的命令筛选有歧义，精确中断后纠正命令；中断结果不计作通过。本轮未宣称新增用例后又重跑536项全量，实际证据是原组合全量535项＋最终目标类84项双variant。 - 规格、代码质量及新增测试复核均通过，无阻断问题；合成driver与可控时钟不代表真实PDD无障碍、hint元数据、fresh定位或现场成功率已验证。 - 最终HEAD再次 `assembleDebug` 成功；APK生产输入未变、哈希与全量构建相同。产物 `D:/OPC/goauto-worktrees/issue-365/android/app/build/outputs/apk/debug/app-debug.apk`，6,824,084 bytes，SHA256 `e0155cb5266c8228598db6c45eda62d9f2a5dfd774f4a8bf71f0635f85f17b3c`；版本仍0.9.69/82。 - git diff --check通过，工作区干净；远端回读确认main及两源分支未改变。集成分支保留在issue-365工作区，issue-366工作区保留；未合并main，不删除未合并工作区。 - 无新增长期文档影响：仅验证已批准两项实现并补回归测试，故不重复Wiki更新/sync。既有strict镜像登记问题沿用前述限制，本轮未扩展修复或宣称全仓检查全绿。 - 未安装、未发布、未迁移、未操作真机/改地址/创建订单/付款；两工单仍待验收，#366仍是部分交付。失败现场完整控件树持久化/上传属于#364，本集成包未包含；#366的hint字段只在内存使用。 ## 2026-10-08 已授权合并 main（#364/#365/#366） - 用户明确要求“把#364 #365 #366合并到main”；三单已合入并推送 `e450ac28989de6827328b411e4bdc050dded9ab3`，远端回读一致。合并前main为5f45932；#364实现4581ee5，原#365/#366集成d2083e7，三单生产集成8c4940d。保留源分支及全部提交，无生产代码冲突，没有压缩或丢弃历史。 - 合并组合完整Android Debug/Release各56 suites、564项，0失败/错误/跳过，test+assembleDebug成功（10m9s）。正式main合并后的文件树与已验证组合完全一致，再次执行相同命令exit0/UP-TO-DATE；不将增量检查冒称第二次全量执行。 - 合并后Server六个受影响包及构建通过，Web构建、13项浏览器mock回归通过；独立集成代码审核PASS。未改动的SYB解析12项测试在同一生产基线7622795也失败，strict存在旧未登记镜像问题，未宣称全仓检查全绿或扩范围修复。 - 集成APK仍0.9.69/82，路径 `D:/OPC/goauto-worktrees/issue-364/android/app/build/outputs/apk/debug/app-debug.apk`，SHA256 `bf8ed021d2bfcc05d49eda54a7b40240a30eda2d1e93199c8dee408c052b1dbe`。未安装或发布；若通过Admin分发需按后续发布流程处理版本号，不把同versionCode产物宣称自动更新已启用。 - **#366仅合入已交付②编辑框就绪等待及hint保护，①仍缺真实地址列表证据，未实现；③④不改。#364现场真机端到端、容量/Binder实测与真实Android SQLite链路待验。** - 本轮无线上迁移/权限写入/发布/重启，无本地业务服务重启，无真机改地址/下单/付款。临时Web测试服务已停止。 - 三张工单保持打开，合并不等于验收。配套发布及真机验收尚未完成，worktree及其本地合成验证产物暂留，不删除资料；后续发布完成后按项目清理规则处理。
ila commented 2026-10-08 10:41:57 +08:00
Author
Owner
Copy Link
Copy Source

②独立交付记录（2026-10-08，部分交付待验收）

按用户“做#366”授权，完成环节②；①证据缺口未闭合，未实施，整单保持 open。

实现与边界

  • 初始编辑页新增局部等待，结构候选（包含禁用/空值）与就绪候选各为 1 才继续；保留单轮 50 次采样、200ms 暂停与既有页面安全检查。
  • 同帧节点和值进入既有单次 inputFresh；失败不重试。titleSeen 跨帧累计，超时仅附固定原因和结构/就绪计数，不保存个人信息。
  • 未改共享 shippingAddressEditors、①地址列表等待、③保存退出、④返回及最终复核、采集、下单/核单；无新接口、错误码或数据库字段。
  • 实现：650f3a6ba115bd22cdefef705eeab4535487cccd；文档：5314313。已推送 fix/366-address-editor-ready，未合并 main。

验证

  • android/gradlew.bat :app:testDebugUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest：基线 44/44；新增 18 项后最终 RED 62 中 15 失败，最小实现后 GREEN 62/62。
  • ./scripts/verify.ps1 -Component android：exit 0，Debug / Release 各 51 suites、514 tests，均 0 failure / error / skipped；test 总耗时约 10m9s；assembleDebug 成功约 51s。耗时来自既有图搜测试真实时间等待，未修改或跳过。
  • 保留既有编译警告，无新增编译错误。两个独立审查（规格、代码质量）均通过；root 核验 diff、XML、APK、镜像一致性。
  • git diff --check 通过。结构检查 python dev_scripts/harness.py check --strict 仍有基线既有的未登记证据镜像失败，详见正文，未扩大范围修复。
  • 构建命令仅在当前进程使用现有 SDK 路径 C:/Users/Qiu/AppData/Local/Android/Sdk，未修改系统环境、安装 SDK 或接受新许可证。

Wiki 与产物

  • Troubleshooting revision：b0fe084161a10102af6c16068f6e7a627d37d9db。
  • Android-Agent-API-Contract revision：b044dd31ab7920706599f73a5143cced5ab90605。
  • Gitea MCP 在线更新并回读成功；首次本地 sync 遇 TLS 握手超时，检查发现 Python 使用系统本地代理，直接 HTTPS 请求正常；仅该进程为 git.ilapage.cn 设置 NO_PROXY 后，sync 与 sync --check 均成功（17 页），未关闭证书验证/修改系统代理。
  • Git 默认凭据认证失败后，使用本机用户级已有私有 Gitea 配置、进程级认证头完成推送，不修改或记录凭据。
  • APK：D:/OPC/goauto-worktrees/issue-366/android/app/build/outputs/apk/debug/app-debug.apk；6,412,438 bytes；SHA-256：47a2ee57b07f8c95a11b7f9bee6a8bd0392fa96123414c5d216476e678da0e0a。
  • 沿用 0.9.69 / 82，未安装到手机或发布 Admin；产物以哈希和提交区别旧版本。

未验证与停止边界

  • ①真实单地址、多地址列表及未加载旧面板证据仍缺；不能把暂定负向条件视为可靠识别。
  • 未做真机改地址、采购、下单、付款；合成测试不是真机验收。
  • 未合并、未发布。工单保持部分交付待验收；worktree 未合并保留，无清理。下一步需用户授权装机/现场验证，并提供①所需场景。
## ②独立交付记录（2026-10-08，部分交付待验收） 按用户“做#366”授权，完成环节②；①证据缺口未闭合，未实施，整单保持 open。 ### 实现与边界 - 初始编辑页新增局部等待，结构候选（包含禁用/空值）与就绪候选各为 1 才继续；保留单轮 50 次采样、200ms 暂停与既有页面安全检查。 - 同帧节点和值进入既有单次 inputFresh；失败不重试。titleSeen 跨帧累计，超时仅附固定原因和结构/就绪计数，不保存个人信息。 - 未改共享 shippingAddressEditors、①地址列表等待、③保存退出、④返回及最终复核、采集、下单/核单；无新接口、错误码或数据库字段。 - 实现：650f3a6ba115bd22cdefef705eeab4535487cccd；文档：5314313。已推送 fix/366-address-editor-ready，未合并 main。 ### 验证 - `android/gradlew.bat :app:testDebugUnitTest --tests cn.ilapage.goauto.agent.PurchaseLiveAutomationTest`：基线 44/44；新增 18 项后最终 RED 62 中 15 失败，最小实现后 GREEN 62/62。 - `./scripts/verify.ps1 -Component android`：exit 0，Debug / Release 各 51 suites、514 tests，均 0 failure / error / skipped；test 总耗时约 10m9s；assembleDebug 成功约 51s。耗时来自既有图搜测试真实时间等待，未修改或跳过。 - 保留既有编译警告，无新增编译错误。两个独立审查（规格、代码质量）均通过；root 核验 diff、XML、APK、镜像一致性。 - `git diff --check` 通过。结构检查 `python dev_scripts/harness.py check --strict` 仍有基线既有的未登记证据镜像失败，详见正文，未扩大范围修复。 - 构建命令仅在当前进程使用现有 SDK 路径 `C:/Users/Qiu/AppData/Local/Android/Sdk`，未修改系统环境、安装 SDK 或接受新许可证。 ### Wiki 与产物 - Troubleshooting revision：b0fe084161a10102af6c16068f6e7a627d37d9db。 - Android-Agent-API-Contract revision：b044dd31ab7920706599f73a5143cced5ab90605。 - Gitea MCP 在线更新并回读成功；首次本地 sync 遇 TLS 握手超时，检查发现 Python 使用系统本地代理，直接 HTTPS 请求正常；仅该进程为 git.ilapage.cn 设置 NO_PROXY 后，sync 与 sync --check 均成功（17 页），未关闭证书验证/修改系统代理。 - Git 默认凭据认证失败后，使用本机用户级已有私有 Gitea 配置、进程级认证头完成推送，不修改或记录凭据。 - APK：D:/OPC/goauto-worktrees/issue-366/android/app/build/outputs/apk/debug/app-debug.apk；6,412,438 bytes；SHA-256：47a2ee57b07f8c95a11b7f9bee6a8bd0392fa96123414c5d216476e678da0e0a。 - 沿用 0.9.69 / 82，未安装到手机或发布 Admin；产物以哈希和提交区别旧版本。 ### 未验证与停止边界 - ①真实单地址、多地址列表及未加载旧面板证据仍缺；不能把暂定负向条件视为可靠识别。 - 未做真机改地址、采购、下单、付款；合成测试不是真机验收。 - 未合并、未发布。工单保持部分交付待验收；worktree 未合并保留，无清理。下一步需用户授权装机/现场验证，并提供①所需场景。
ila commented 2026-10-08 10:48:12 +08:00
Author
Owner
Copy Link
Copy Source

环节② 交付审核（2026-10-08，Claude Code，用户要求补充）

审核对象：分支 fix/366-address-editor-ready，基线 7622795，实现 650f3a6，HEAD 5314313（含 Wiki 镜像）。依据 SynapBus #95/#96 与评论 8968。只读审核，未运行测试，未改动 worktree。

结论

大部分达标，但存在 1 个 Important 问题（hint 文字可能被当作现有地址）。修复并补测试前，不具备合并条件。 环节①仍缺真实地址列表证据，未实施；真机未验证。

已核对达标

  • 范围：只在 PurchaseLiveAutomation.kt 新增 waitForInitialAddressEditor()（约 538～572 行）并替换原 512～516 行的判断；共用 shippingAddressEditors()、①③④、采集/下单/核单、Server/Web/DB、版本号均未改。
  • 预算：单轮 repeat(50) + pause(200)；无「三次多候选提前失败」，无「先等标题再等输入框」的两轮等待。
  • 多候选：structural 计入空值和禁用的 EditText，必须 structural == 1 && ready == 1 才通过；结构多候选、仅一个 ready 时不会放行。
  • 同帧：原值与 inputFresh 目标使用同一采样帧的节点；inputFresh 失败不重试；每次采样仍先执行 pageProblem。
  • 诊断：titleSeen 跨帧累计，配合末帧 structural/ready 和固定 reason；不含地址、人名、电话。未见标题报 PURCHASE_ADDRESS_EDIT_TIMEOUT，其余报 PURCHASE_ADDRESS_UPDATE_FAILED。
  • 测试：新增 18 个用例，覆盖慢加载、空值/禁用、>3 帧歧义后恢复、全预算歧义、末帧就绪、末帧空树、收货人/电话/不可见/左侧输入框排除与去重、标题延迟不开启第二轮等待。
  • 保存后两条既有路径（直接回规格面板、经地址列表返回）的代码未改。
  • Wiki（Troubleshooting、Agent-API-Contract）与实现一致，并明确①缺证据、③④不改、未真机验收。

Important：输入框显示 hint 时可能被当作已就绪，写入错误地址

  • 位置：PurchaseLiveAutomation.kt 约 557 行 readyCount = structural.count { it.enabled && it.label.isNotBlank() }；label 来自 GoAutoAccessibilityService.capture()（约 241 行）只读取的 node.text / contentDescription。
  • 原因：Android TextView 在内容为空时，getTextForAccessibility() 会返回 hint，因此空输入框的无障碍 text 可能是提示文字（例如「如街道、门牌号等」），被判为非空、ready。
  • 后果：
    1. 提示文字被当作原地址，写入「提示文字 + _cg{taskId}」并保存；
    2. 回读校验（label == expected）和最终复核（检查任务后缀）都会通过，可能真实下单到错误的详细地址。
  • 与旧代码比较：旧代码在标题出现时立即判断，输入框未加载时通常直接失败（安全）；新代码会一直等到「非空」。如果 PDD 加载时先显示 hint，新代码就会放行。本单针对的正是慢加载，恰好落在这个时机。历史 39 次「没有找到唯一的详细地址输入框」说明设备 7 上空输入框至少有时读到空白，但不能排除其他设备或页面状态会读到 hint。
  • 建议最小修复：
    1. capture() 为节点新增可选字段 hintText、showingHintText（API 26+ 使用 AccessibilityNodeInfo.getHintText() / isShowingHintText()），默认 null，不改变现有使用方。
    2. 环节② ready 判定排除 showingHintText == true，以及 label == hintText 的输入框。
    3. 补测试：「先显示 hint、后填入真实地址」能等到真实值再通过；「始终只有 hint」到预算耗尽失败，且不执行任何输入。
    4. API 26 以下无法取得 hint 状态时保持现行为，并在 Wiki 写明限制（当前采购设备为 Android 13/14）。

Minor

  • 失败消息从「没有找到唯一的详细地址输入框」改为「详细地址输入框未就绪」，按旧文字统计的线上数据会断开。Wiki 已说明，无需修改；统计时需兼容两种文字。

未验证

  • 未独立运行测试，514/514 为 Codex 报告结果。
  • 环节①未实施（缺真实单地址、多地址列表的正向结构证据）。
  • 未装机，未做真实改地址或下单验证。
## 环节② 交付审核（2026-10-08，Claude Code，用户要求补充） 审核对象：分支 `fix/366-address-editor-ready`，基线 `7622795`，实现 `650f3a6`，HEAD `5314313`（含 Wiki 镜像）。依据 SynapBus #95/#96 与评论 8968。只读审核，未运行测试，未改动 worktree。 ### 结论 大部分达标，但存在 **1 个 Important 问题**（hint 文字可能被当作现有地址）。**修复并补测试前，不具备合并条件。** 环节①仍缺真实地址列表证据，未实施；真机未验证。 ### 已核对达标 - 范围：只在 `PurchaseLiveAutomation.kt` 新增 `waitForInitialAddressEditor()`（约 538～572 行）并替换原 512～516 行的判断；共用 `shippingAddressEditors()`、①③④、采集/下单/核单、Server/Web/DB、版本号均未改。 - 预算：单轮 `repeat(50)` + `pause(200)`；无「三次多候选提前失败」，无「先等标题再等输入框」的两轮等待。 - 多候选：structural 计入空值和禁用的 EditText，必须 `structural == 1 && ready == 1` 才通过；结构多候选、仅一个 ready 时不会放行。 - 同帧：原值与 `inputFresh` 目标使用同一采样帧的节点；`inputFresh` 失败不重试；每次采样仍先执行 `pageProblem`。 - 诊断：`titleSeen` 跨帧累计，配合末帧 structural/ready 和固定 reason；不含地址、人名、电话。未见标题报 `PURCHASE_ADDRESS_EDIT_TIMEOUT`，其余报 `PURCHASE_ADDRESS_UPDATE_FAILED`。 - 测试：新增 18 个用例，覆盖慢加载、空值/禁用、>3 帧歧义后恢复、全预算歧义、末帧就绪、末帧空树、收货人/电话/不可见/左侧输入框排除与去重、标题延迟不开启第二轮等待。 - 保存后两条既有路径（直接回规格面板、经地址列表返回）的代码未改。 - Wiki（Troubleshooting、Agent-API-Contract）与实现一致，并明确①缺证据、③④不改、未真机验收。 ### Important：输入框显示 hint 时可能被当作已就绪，写入错误地址 - 位置：`PurchaseLiveAutomation.kt` 约 557 行 `readyCount = structural.count { it.enabled && it.label.isNotBlank() }`；`label` 来自 `GoAutoAccessibilityService.capture()`（约 241 行）只读取的 `node.text` / `contentDescription`。 - 原因：Android `TextView` 在内容为空时，`getTextForAccessibility()` 会返回 hint，因此空输入框的无障碍 `text` 可能是提示文字（例如「如街道、门牌号等」），被判为非空、ready。 - 后果： 1. 提示文字被当作原地址，写入「提示文字 + `_cg{taskId}`」并保存； 2. 回读校验（`label == expected`）和最终复核（检查任务后缀）都会通过，可能**真实下单到错误的详细地址**。 - 与旧代码比较：旧代码在标题出现时立即判断，输入框未加载时通常直接失败（安全）；新代码会一直等到「非空」。如果 PDD 加载时先显示 hint，新代码就会放行。本单针对的正是慢加载，恰好落在这个时机。历史 39 次「没有找到唯一的详细地址输入框」说明设备 7 上空输入框至少有时读到空白，但不能排除其他设备或页面状态会读到 hint。 - 建议最小修复： 1. `capture()` 为节点新增可选字段 `hintText`、`showingHintText`（API 26+ 使用 `AccessibilityNodeInfo.getHintText()` / `isShowingHintText()`），默认 null，不改变现有使用方。 2. 环节② ready 判定排除 `showingHintText == true`，以及 `label == hintText` 的输入框。 3. 补测试：「先显示 hint、后填入真实地址」能等到真实值再通过；「始终只有 hint」到预算耗尽失败，且不执行任何输入。 4. API 26 以下无法取得 hint 状态时保持现行为，并在 Wiki 写明限制（当前采购设备为 Android 13/14）。 ### Minor - 失败消息从「没有找到唯一的详细地址输入框」改为「详细地址输入框未就绪」，按旧文字统计的线上数据会断开。Wiki 已说明，无需修改；统计时需兼容两种文字。 ### 未验证 - 未独立运行测试，514/514 为 Codex 报告结果。 - 环节①未实施（缺真实单地址、多地址列表的正向结构证据）。 - 未装机，未做真实改地址或下单验证。
ila commented 2026-10-08 11:09:02 +08:00
Author
Owner
Copy Link
Copy Source

评论 8969 Important 最小补修完成（2026-10-08，②部分交付待验收）

按用户“按照你的建议最小补齐”授权，已实现并推送代码 7fdfe04658d16a05ebcb016ee964a7263eb74802、Wiki 镜像 d1996d28ee844ff5f8f98287ba93f7e40cb30681。

  • 就绪与原地址都用实际 text，空值不再回退 contentDescription；API 26+ 内存 hint 标志/文本明确指向提示时继续等待，不输入/保存；沿用现有 50 次预算和错误码，固定 reason=editor_hint。
  • 全局 label、inputFresh、共享 shippingAddressEditors、①③④、采集业务、持久化与上传契约不变。旧版本原本也有非空 label 风险，不能证明本次引入或是历史现场根因；API <26 / 应用缺失 hint 元数据仍有局限。
  • TDD 基线 62/62；description-only RED 63/1，hint RED 70/6，GREEN 70/70。新增 8 项；独立规格/质量复核通过。
  • 全量 verify exit 0：Debug / Release 各 522 项、0 失败/错误/跳过，APK 构建成功；17 页 Wiki 镜像检查通过。两个 revision 与 APK 哈希已整合正文。
  • 未安装、未合并 main、未发布，未做真机改地址/下单验证。①仍缺现场证据，整单不关闭；worktree 保留。基线 strict 镜像登记问题未扩大范围修复。

本条是本轮最新交付记录，前轮评论 8968 的测试数/APK 仅代表前轮产物。

## 评论 8969 Important 最小补修完成（2026-10-08，②部分交付待验收） 按用户“按照你的建议最小补齐”授权，已实现并推送代码 `7fdfe04658d16a05ebcb016ee964a7263eb74802`、Wiki 镜像 `d1996d28ee844ff5f8f98287ba93f7e40cb30681`。 - 就绪与原地址都用实际 text，空值不再回退 contentDescription；API 26+ 内存 hint 标志/文本明确指向提示时继续等待，不输入/保存；沿用现有 50 次预算和错误码，固定 reason=editor_hint。 - 全局 label、inputFresh、共享 shippingAddressEditors、①③④、采集业务、持久化与上传契约不变。旧版本原本也有非空 label 风险，不能证明本次引入或是历史现场根因；API <26 / 应用缺失 hint 元数据仍有局限。 - TDD 基线 62/62；description-only RED 63/1，hint RED 70/6，GREEN 70/70。新增 8 项；独立规格/质量复核通过。 - 全量 verify exit 0：Debug / Release 各 522 项、0 失败/错误/跳过，APK 构建成功；17 页 Wiki 镜像检查通过。两个 revision 与 APK 哈希已整合正文。 - 未安装、未合并 main、未发布，未做真机改地址/下单验证。①仍缺现场证据，整单不关闭；worktree 保留。基线 strict 镜像登记问题未扩大范围修复。 本条是本轮最新交付记录，前轮评论 8968 的测试数/APK 仅代表前轮产物。
ila commented 2026-10-08 11:35:48 +08:00
Author
Owner
Copy Link
Copy Source

#365 + #366 集成验证开始（2026-10-08）

用户授权“做#365和#366的集成验证”。已刷新远端main，基线仍为 7622795；源分支分别为 c55455d 与 d1996d2。仅组合#365与#366已交付②/hint保护，不实施#366①，不改③④。

计划：复用干净的issue-365隔离工作区，建立独立 integration/365-366-validation 分支，保留两条原工单分支；机械合并后检查同文件冲突/测试完整性，执行目标回归、Android Debug/Release全量单元测试及APK构建，独立审核并回写证据。必要时仅补集成测试；不扩大生产代码范围。

不合并main、不安装或操作手机、不改地址/下单/付款、不更新Admin/迁移/发布。本轮无新增长期文档规则：保留已批准的Wiki镜像，纯集成验证结果回写两张工单，不重复修改Wiki或同步。

## #365 + #366 集成验证开始（2026-10-08） 用户授权“做#365和#366的集成验证”。已刷新远端main，基线仍为 `7622795`；源分支分别为 `c55455d` 与 `d1996d2`。仅组合#365与#366已交付②/hint保护，不实施#366①，不改③④。 计划：复用干净的issue-365隔离工作区，建立独立 `integration/365-366-validation` 分支，保留两条原工单分支；机械合并后检查同文件冲突/测试完整性，执行目标回归、Android Debug/Release全量单元测试及APK构建，独立审核并回写证据。必要时仅补集成测试；不扩大生产代码范围。 不合并main、不安装或操作手机、不改地址/下单/付款、不更新Admin/迁移/发布。本轮无新增长期文档规则：保留已批准的Wiki镜像，纯集成验证结果回写两张工单，不重复修改Wiki或同步。
ila commented 2026-10-08 11:51:08 +08:00
Author
Owner
Copy Link
Copy Source

#365 + #366 集成验证通过，完整证据已追加正文。集成分支 integration/365-366-validation 已推送：机械集成 5206a6f，跨阶段回归 d2083e7。组合全量 Debug/Release 各535项通过，新增跨阶段测试后目标类两variant各84项通过，最终APK构建成功，规格/质量复核无阻断。未合并main、未装机或发布；#366仅②/hint保护，①仍待证据，③④不改。工单保持待验收，不关闭。

#365 + #366 集成验证通过，完整证据已追加正文。集成分支 `integration/365-366-validation` 已推送：机械集成 `5206a6f`，跨阶段回归 `d2083e7`。组合全量 Debug/Release 各535项通过，新增跨阶段测试后目标类两variant各84项通过，最终APK构建成功，规格/质量复核无阻断。未合并main、未装机或发布；#366仅②/hint保护，①仍待证据，③④不改。工单保持待验收，不关闭。
ila commented 2026-10-08 15:18:56 +08:00
Author
Owner
Copy Link
Copy Source

已按用户授权合并并推送main e450ac28989de6827328b411e4bdc050dded9ab3，正文已整合实现/验证及边界。三单组合Android Debug/Release各564项全部通过，APK构建通过；Server六个受影响包/构建和Web13项mock回归/构建通过。#366只合入②/hint保护，①待证据；#364真机诊断闭环仍待验。本次未部署、未执行线上迁移/重启、未安装手机。各项未验证与基线检查失败已明确记录，工单保持打开。

已按用户授权合并并推送main `e450ac28989de6827328b411e4bdc050dded9ab3`，正文已整合实现/验证及边界。三单组合Android Debug/Release各564项全部通过，APK构建通过；Server六个受影响包/构建和Web13项mock回归/构建通过。#366只合入②/hint保护，①待证据；#364真机诊断闭环仍待验。本次未部署、未执行线上迁移/重启、未安装手机。各项未验证与基线检查失败已明确记录，工单保持打开。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#366