QiuSWandClaude Opus 5
e6f533b71e
Adding SYBSession to migrations.Migrate was not enough. Schema reaches an
existing database only through a version-local file; with the previous
version already recorded in sys_migration, Migrate never re-ran and the
table simply never appeared. The unit tests build a fresh database every
time, so they stayed green while the real database was missing a table —
which surfaced as "Error 1146: Table 'goauto.syb_session' doesn't exist"
on the first import attempt.
server/.gitignore was hiding these files. go-admin ignores version-local
because it is where generated local migrations land, but every GoAuto
migration belongs in version control; the existing ones had been forced
in with `git add -f`. Un-ignoring *.go there also recovers four migrations
that were never committed at all — 1786700000000 through 1786700300000,
covering the base schema, device registration, heartbeat and collection
execution. A fresh clone could not have built a working database.
Guard the class of mistake rather than just this instance:
- migrations.VerifyTables checks every model's table after migrating and
names what is missing along with the fix.
- The migrate command runs it, so the failure lands at migrate time
instead of at the first request that needs the table.
- initDB no longer discards migrateModel's error. Upstream had
`_ = migrateModel()` followed by an unconditional "初始化成功", so a
failed migration reported success and the launcher believed it.
Also records the two-step rule in Common-Changes: a new model needs both
the model registration and a new version file.
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 或文档。