2 Commits

Include renames

Author	SHA1	Message	Date
qyqy	f7a666fb5a	fix(env)+docs: 按架构师第二轮纠正 mypy 根因（环境版本）；补场外/推广域表登记 ... 架构师第二轮答复里有一条技术纠正是对的，我原归因错了： - 我原判断"184 个 mypy 错是因为缺 SQLAlchemy 2.0 类型信息"——**方向对了一半、结论反了**。 SQLAlchemy 2.0 自带 py.typed，根本不需要 sqlalchemy2-stubs（那是 1.4 用的）。 - 实测复现矩阵（决定性证据）： SQLAlchemy 2.0.34 + mypy 1.14.1 → 173 错（我原来的环境） SQLAlchemy 2.0.34 + mypy 1.20.2 → 173 错 SQLAlchemy 2.0.52 + mypy 1.14.1 → 6 错 SQLAlchemy 2.0.52 + mypy 1.20.2 → 3 错 ⇒ 主因是 SQLAlchemy 的**补丁版本**（173→6），mypy 版本是次因（6→3）。 - 已把环境升到 SQLAlchemy 2.0.52 + mypy 1.20.2（均在 pyproject 约束内）， mypy 从 184 降到 **3 个错**（剩下的 3 个全在同事的 offsite 文件里，非本线代码）。 - 没有把 sqlalchemy2-stubs 写进依赖（采纳架构师明确要求）。 - 交接文档已重写该条，并留下"两个反面教训"：不要装 1.4 的存根包；补丁版差异会造成量级差异， 若要门禁稳定需把 SQLAlchemy 钉到具体补丁版（属公共约定，未擅自改）。 按架构师裁决补文档（他裁定：不动 docs/00，另立登记）： - 新增 docs/28-场外与推广域数据表登记.md：17 张表逐表登记（表名/来源迁移/归属域/当前行数）， 并做规则 8 的**两向边界核对**——场内代码零引用这 17 张表（config.py 里的 offsite_ 只是配置项名）、 场外代码零写场内交易表 - docs/08 审计口径更新为「场内 51 + 场外/推广 17 = 68」，并新增"第四种坏状态" （alembic_version 已指向新 revision 但表没建）的处置说明 - 澄清一个易误读点：audit_schema.py 的期望集合是**动态推导**的（读 baseline_generated.sql + 扫描 alembic/versions/*.py），表数 51→68 是自动结果，**没有人手工改期望值**； 代价是只增不减（DROP 表会报 missing 假失败） 测试：3 failed（1 既有 + 2 环境相关）/ 1218 passed；文档守卫 35 份无重号； mypy 3 错（180 文件）；结构审计 68 张表通过。	2026-09-11 20:00:56 +08:00
qyqy	f1b8cb859a	docs: 新增《接手文档 · NL_develop 这条线（给架构师）》 ... 面向"接手维护"而非"review"的第三份文档，与另两份分工明确： - 交付说明 → review 用（我动了你什么、为什么） - 评审意见回复 → 对照你的评审意见 - **本文** → 接手维护用（起点在哪、有哪些坑、哪些待裁决） - 给下一位开发者 → docs/superpowers/handoff/… 内容要点： - §1 三条最要紧的结论：① 两台机器不是同一套环境（附三处实测证据）并由此立下两条硬纪律 （环境相关结论必须带环境限定、禁止硬编码 Milvus 字段名）；② **表数已从 51 变 68** （同事 11 个迁移新建 17 张 offsite_*/promotion_* 表），而 docs/00 基线与 docs/02 未更新 —— 已提示、未擅自改不可变基线；③ 测试 3 failed 均非代码缺陷（附证据） - §2 环境口径（含 Docker Desktop 不常驻、mypy 不可比的实测根因） - §3 分支与提交 + 两个可回退的备份分支 - §4 交付清单（8 项，含状态与位置） - §5 必须知道的 5 个坑（Milvus 读一致性与字节截断、config_release 整版本替换、 两个 outbox 不能混、审计表无 agent_type 列） - §6 待你裁决的 3 件事（白名单补发归属、接线归属、两处文档让号） - §7 建议你拍板的两件事（文档体系口径、docs/00 是否补 17 张新表） - §8 接手后先跑的 5 条自检命令 - §9 四份文档的分工表（防止读串）	2026-09-11 19:32:19 +08:00