QiuSWandClaude Opus 5
c86e98d0cb
The repo already layered file defaults under environment overrides, on both the backend (settings.yml < GOAUTO_*) and the frontend (.env.production < process.env). What was missing was a translator for production: config.yaml only ever existed for the PowerShell launchers, so a packaged binary read none of it and had no database credentials either — SYB was inheriting an existing gap, not creating one. The server now reads config.yaml itself, between settings.yml and the environment. Lookup is GOAUTO_CONFIG, then ./config.yaml, then beside the executable, so a packaged binary works wherever it is started. An absent file is not an error: containers supply everything through the environment. Scalars are read by YAML type and coerced, so an unquoted all-digit password cannot take startup down over a quoting detail. This removed the need for a Read-SybConfig in PowerShell: the launcher just hands over the path it already knows, rather than reimplementing a YAML parser. The server also serves the built frontend when dist is present, which is what .env.production's empty VUE_APP_BASE_API already assumes. The history fallback is restricted to non-API GETs, and is not installed at all without dist, so development 404s stay 404s. Precedence is mutation-tested: applying the local file after the environment instead of before makes the layering test fail. Not verified: the PowerShell change and any Windows deployment — both need a run on the Windows side. 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 或文档。