QiuSWandClaude Opus 5
c14f5f528b
normalizeOrderUnknownFailure replaced the agent's message with a canonical sentence, so the diagnostic #210 added never reached the database. Across the 61 PURCHASE_ORDER_PAYMENT_REPEATED failures on production between 2026-09-07 and 09-11, not one carried paymentBackAttempts or consecutivePaymentSamplesAfterBack, which left three very different causes indistinguishable: the Back never left the payment activity, the page rendered slower than the ~1.1s window the agent allows, or the page was already the order page and no marker matched. Those need different fixes, and there was no way to tell which one to make. The canonical sentence stays authoritative and leads the message — agent text is free-form and the wording per error code has to stay stable — but the agent evidence is now appended behind it, flattened to one line (control characters and U+FEFF removed, whitespace collapsed) and truncated to the column's 1000 runes with the canonical part kept whole. The sibling "failed" branch already stored agent text verbatim, so this adds no new trust assumption. That branch also only wrote the failure onto the task, never the attempt, so every attempt it produced carried a NULL error_code and was invisible to attempt-level statistics — the spec-panel failures on production are exactly that. It now writes both. This restores observability only; it does not reduce how often PAYMENT_REPEATED happens. Tuning the agent's sampling window is deliberately left out until the next production failure shows real values. Wiki updated first: Android-Agent-API-Contract@ba259178. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NTDbDcwbDw1TSAcE6wfh2F
generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件) wiki_page: Home wiki_url: https://git.ilapage.cn/OPC/goauto/wiki/Home wiki_revision: b1b1b343917e66288f4282bc6b3b90ea4ff3cca0 synchronized_at: 2026-09-04T11:29:34Z
GoAuto 文档中心
GoAuto 使用 Gitea 工单记录单次任务的完整过程，使用 Gitea Wiki 维护长期事实，使用 Git 保存源码、迁移、测试、版本绑定资料和 Wiki 的本地镜像。标准任务不再重复建立 Wiki 任务归档。
建议阅读顺序
- 项目档案：项目目标、建设基线、交付单元和当前阶段。
- 产品需求总览：长期需求状态、工单、原型和当前采集闭环。
- 架构与代码地图：请求怎样跨服务端、Web 和 Android 流动。
- 业务规则与术语：重要状态和不能破坏的规则。
- 本地开发与验证：怎样启动、测试和真机验证。
- 常见修改指南：常见修改入口、风险和停止条件。
- 故障排查：出现错误时按什么顺序检查。
- 开发工作流：完整建单、设计门禁、实施和验收流程。
- 部署与运维：当前线上拓扑、Agent HTTP 例外、发布验证和回滚。
专题资料：
事实来源
| 信息 | 唯一事实来源 |
|---|---|
| 单次任务需求、讨论、方案变化、实现、测试、提交、阻塞和验收 | Gitea 单元工单 |
| 长期产品需求、架构、业务规则、开发规范、契约和操作说明 | Gitea Wiki |
| 跨服务端与 Android 的共享接口 | Wiki 的 Android-Agent-API-Contract 页面 |
| 源码、迁移、版本绑定分析、本地 HTML 原型和规则 JSON | Git 仓库 |
| 核心长期文档的离线副本 | Git 仓库 docs/ 中的 Wiki 只读镜像 |
| 外部交互原型 | QuantUX 链接、App ID 和对应工单记录 |
本地映射 Markdown 不是编辑入口。只有长期事实变化时才执行：修改 Wiki → 读取确认 → 导出核心 docs/ → 检查一致性 → 提交镜像。无长期文档影响的任务完全跳过 Wiki 同步。既有任务归档和 docs/task/ 只作历史兼容；仅在用户明确要求专项快照时创建或导出。
权威源与事实边界
文档或界面与实现冲突时，依次以可执行代码与自动化测试、已批准的共享契约和决策、当前长期 Wiki、旧设计稿、注释/UI 文案/历史示例为准。
“当前实现”必须能在指定提交上复核；“目标契约”表示尚待实施或验收的目标，不能用来宣称现有能力。基线或差距审计需记录 commit、核验日期、证据路径、范围、不在范围和证据不能证明的内容。
五分钟检查
git status --short --branch
python dev_scripts/harness.py check --strict
python -m unittest discover -s tests -v
.\scripts\verify.ps1 -Component all
预期结果是工作区范围明确、治理结构和 Wiki 工具单元测试通过，并且受影响的交付单元验证通过；只有本次修改了长期 Wiki 时才另跑 sync --check。具体环境、分组件命令和真机范围见本地开发与验证。
同步与归档
# 仅当长期事实变化时：单向导出并检查核心文档
python dev_scripts/harness.py sync
python dev_scripts/harness.py sync --check
# 仅当用户明确要求专项历史快照时
python dev_scripts/harness.py archive 43 "升级 DevHarness 文档基线"
python dev_scripts/harness.py export
凭据只通过 GITEA_TOKEN 环境变量提供，不写入配置、日志、工单、Wiki 或文档。