lzf_0626
d28ccdd88c
产出 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：场外基金运营流程独立，不得写入场内交易表）。