lzf_0626
d28ccdd88c
答复 NL_develop 第二轮：批准整改，纠正 mypy 归因，裁定 docs/00 不动
产出 docs/NL_develop评审回复-架构师答复.md（可直接转给对方）。三条核实结论：
1. docs/21 在我这边本来就重号（21-JWT密钥管理与轮换.md + 21-风控业务第二版迁移
清单.md），tools/check_authoritative_docs.py 当前就是失败的 —— 我此前只跑
ruff/mypy/pytest，没跑到文档守卫。对方的让号顺手修好了这个既有故障，
故批准 docs/26 与 docs/27 两处让号。
2. 对方的 mypy 归因需要纠正。他说主因是缺 SQLAlchemy 2.0 类型信息；我这边
mypy 1.20.2 + SQLAlchemy 2.0.52 + 未装 sqlalchemy2-stubs → 0 错，而
pyproject.toml 约束是 sqlalchemy>=2.0,<3 / mypy>=1.14,<2。SQLAlchemy 2.0 自带
py.typed，sqlalchemy2-stubs 是给 1.4 用的，装了反而按 1.4 的 API 报错（他自己也
观察到"还会换一批新错"）。真实根因是他的 .venv 没满足 pyproject 约束。
3. 他的迁移警告对我不适用。我这边 alembic current = heads = 20260911_risk_rule_index
（单一 head，只有我自己的迁移），schema audit 报 51 business tables —— 即"表没建、
版本号也没跑"，与他那边"版本号跑了、表没建"是两种不同的坏状态。合并后我必须补跑
alembic upgrade heads。
裁定：
- 补发配置（customer_service:faq 加 query_customer_profile）归我做；
- memory_sync_outbox / GraphProjectionWorker 消费端归我（生产者在他那边）；
- 两处让号批准；
- docs/00 不动，另立文档登记场外/推广域 17 张表，并更新 docs/08 审计基线口径
（依据 AGENTS.md 规则 8：场外基金运营流程独立，不得写入场内交易表）。
2026-09-11 19:40:17 +08:00
..
2026-09-11 16:51:52 +08:00
2026-09-09 21:55:37 +08:00
2026-09-11 15:25:45 +08:00
2026-09-09 21:55:37 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-09 21:55:37 +08:00
2026-09-09 21:55:37 +08:00
2026-09-11 14:08:55 +08:00
2026-09-10 15:55:54 +08:00
2026-09-09 21:55:37 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 18:18:00 +08:00
2026-09-09 23:40:35 +08:00
2026-09-09 23:40:35 +08:00
2026-09-09 23:40:35 +08:00
2026-09-09 23:40:35 +08:00
2026-09-09 23:40:35 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 18:18:00 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 18:18:00 +08:00
2026-09-11 09:49:21 +08:00
2026-09-10 18:35:52 +08:00
2026-09-10 21:36:23 +08:00
2026-09-11 14:47:08 +08:00
2026-09-11 14:47:08 +08:00
2026-09-10 15:55:54 +08:00
2026-09-11 16:51:52 +08:00
2026-09-11 19:40:17 +08:00
2026-09-09 21:55:37 +08:00