QiuSWandClaude Opus 5
7edb4e7b9f
Stage 2. Completes the path from the SYB API to the archive. sybimport.Sync pages a date range day by day and folds each detail line through the existing idempotent ApplyDetail. The paging loop is driven by listTotal, never by the list response's own total, which live data confirmed is the page's row count rather than the filtered total. A day whose completeness cannot be proven — a short page, a total that drifted while paging, a detail response missing an order — stops the run instead of reporting a partial import as a whole one. Rows already written stay: they are idempotent on (order_code, detail_id), so a re-run overwrites. sybimport.Connect reuses the cached session and only discards it when SYB explicitly says it is invalid. Caching the numeric user id alongside the cookies is required, not incidental: session validation calls /am/user/get?id=, and a wrong id comes back as a business error rather than a logout, so cookies alone can never be revalidated. The import endpoint is single-flight and detached from the request context, so closing the tab cannot abandon a half-finished range. It reads only; no SYB write endpoint is reachable from GoAuto. The page swaps its "no import entry" warning for a date-range dialog that warns when the span is wide — a single week held over 7000 orders — and reports partial progress when a run fails midway. Verified: go build, go vet, go test ./... all pass. The drift check was mutation-tested. Not verified: the MySQL migration for syb_session, and any browser walkthrough. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件) wiki_page: Home wiki_url: https://git.ilapage.cn/OPC/goauto/wiki/Home wiki_revision: e054c1907f06dc9f579287d57cb289317ad54e27 synchronized_at: 2026-08-19T01:22:14Z
GoAuto 文档中心
GoAuto 使用 Gitea 工单记录任务过程，使用 Gitea Wiki 维护长期开发文档，使用 Git 保存源码、版本绑定资料和 Wiki 的本地镜像。
建议阅读顺序
- 项目档案：项目目标、建设基线、交付单元和当前阶段。
- 产品需求总览：长期需求状态、工单、原型和当前采集闭环。
- 架构与代码地图：请求怎样跨服务端、Web 和 Android 流动。
- 业务规则与术语：重要状态和不能破坏的规则。
- 本地开发与验证：怎样启动、测试和真机验证。
- 常见修改指南：常见修改入口、风险和停止条件。
- 故障排查：出现错误时按什么顺序检查。
- 开发工作流：完整建单、设计门禁、实施和验收流程。
专题资料：
事实来源
| 信息 | 唯一事实来源 |
|---|---|
| 任务状态、讨论、阻塞、需求变化和验收过程 | Gitea 单元工单 |
| 长期产品需求、架构、业务规则、开发规范、操作说明和任务归档 | Gitea Wiki |
| 跨服务端与 Android 的共享接口 | Wiki 的 Android-Agent-API-Contract 页面 |
| 源码、迁移、版本绑定分析、本地 HTML 原型和规则 JSON | Git 仓库 |
| 核心长期文档的离线副本 | Git 仓库 docs/ 中的 Wiki 只读镜像 |
| 外部交互原型 | QuantUX 链接、App ID 和对应工单记录 |
本地映射 Markdown 不是编辑入口。长期文档固定顺序是：修改 Wiki → 读取确认 → 导出核心 docs/ → 检查一致性 → 提交镜像。任务归档默认只保存在 Wiki，只有用户明确要求时才导出到 docs/task/。
五分钟检查
git status --short --branch
python dev_scripts/harness.py sync --check
python -m unittest discover -s tests -v
.\scripts\verify.ps1 -Component all
预期结果是工作区范围明确、所有 Wiki 映射一致、Wiki 工具单元测试通过，并且受影响的三端验证通过。具体环境、分组件命令和真机范围见本地开发与验证。
同步与归档
# 从 Wiki 单向导出核心文档
python dev_scripts/harness.py sync
# 只检查一致性
python dev_scripts/harness.py sync --check
# 创建 Wiki 任务归档草稿，不自动导出本地
python dev_scripts/harness.py archive 43 "升级 DevHarness 文档基线"
# 仅在用户明确要求时导出任务归档
python dev_scripts/harness.py export
凭据只通过 GITEA_TOKEN 环境变量提供，不写入配置、日志、工单、Wiki 或文档。