lzf_0626
6516ccb385
相对第一版 46fc976 的完整变更。组员迁移对照表见 docs/20。
一、对外契约对齐 docs/05（破坏性，共 4 处，组员需按 docs/20 调整）
1) 配置发布端点改为文档规定的复数资源名：submit→validations、
approve→reviews（需 body decision）、activate→activations、
rollback→rollbacks；第一版这 4 个动词式路径 docs/05 从未定义过。
2) 错误码由 8 个笼统码改为 15 个具体语义码（FORBIDDEN→AGENT_PERMISSION_DENIED、
UNAUTHORIZED→AUTHENTICATION_REQUIRED、CONFLICT→RESOURCE_VERSION_CONFLICT、
RESOURCE_NOT_FOUND→RUN_NOT_FOUND/SESSION_NOT_FOUND 等），
输入类错误状态码 400→422。
3) POST /api/v1/agent-runs 与 GET /api/v1/agent-runs/{run_id} 统一为
{data, meta} 信封（data 内字段名与语义未变）。
4) 错误响应体统一为 {error:{code,message,retryable,field_errors}, meta:{trace_id}}，
不再返回 FastAPI 默认的 {"detail": ...}。
二、数据库基线与约束
新增 39 张表的基线迁移（链根）与联合唯一键纠偏（4 张表、删 8 增 4，幂等收敛）；
撤下 config_release 的双人复核 CHECK（应用层已允许自审，审核节点保留，
自审如实写入 reviewer_id）；记忆 active key 生成列与唯一键；
activate 开始记录 supersedes_release_id 使版本链可追溯。
docs/00 基线未修改，未重命名或删除任何表与字段。
三、修复会静默出错或无报错的缺陷
- 跑完集成测试后平台会静默失去生效配置：清理只删自己创建的版本，却没有恢复被它
顶成 superseded 的原生效版本，且审计一并删除因而完全无痕，表现为所有工具被拒
但没有任何报错。已修清理逻辑并加恢复。
- Worker 单轮异常导致进程退出；记忆抽取调用方的“事务已开始”异常；
召回缓存丢失 degraded 标记；连接时区未生效导致 created_at/updated_at 差 8 小时；
.env 与 os.getenv 密钥来源分裂导致“没有可用的已批准模型端点”。
- 记忆信号识别漏判与跨键误命中；SSE 未带 Accept 的协商行为。
四、功能补齐
记忆链路 P1/P2/P3（抽取、受控词表、召回与缓存、生命周期级联及投影事件）、
fin_* 场内交易只读 ORM 层、agent_intent_config 状态流转并在运行期真正生效、
限流（Redis 固定窗口、故障一律放行）、游标校验、trace_id 中间件、
示例业务 Agent fund_query_demo 与一键端到端验证脚本，以及审计/指纹/迁移状态工具。
五、文档与验证
新增 docs/19（业务 Agent 接入实操）、docs/20（第一版迁移指南）与 docs/evidence 证据；
docs/01/02/06/08/09/17 同步实现现状。
验证结果：ruff 通过、mypy 103 文件无错、unit+contract 447 passed、
integration 29 passed、acceptance_check --production 7 PASS、
demo_agent_e2e 9/9 PASS（含失败关闭反证）。
4.0 KiB
数据库结构审计基线
一、审计工具
tools/schema_fingerprint.py 读取 MySQL information_schema 中每张表的字段名、类型、可空性、
默认值、额外属性、字符集、排序规则和生成表达式，并输出 SHA-256 指纹。2026-09-09 起指纹
同时覆盖索引与唯一键（STATISTICS）以及外键（KEY_COLUMN_USAGE + REFERENTIAL_CONSTRAINTS），
因为只对字段做指纹无法发现约束漂移。它不读取业务行数据，支持 --out 直接落 UTF-8 文件。
tools/audit_constraints.py 做三向比对：docs/00 声明的唯一键 ↔ 库实际唯一索引、
ORM 映射 ↔ 库列名（生成列单独归类为 note）。任一不一致返回非零退出码，可纳入提交前检查。
tools/audit_schema.py 仍负责表名与列存在性比对，与上述两个工具互补。
二、历史指纹记录
2026-09-09 在补建会话表前保存了 49 张既有表指纹；迁移 20260909_session 之后再次比对，
49 张既有表全部一致，新增 svc_conversation_session。随后新增 api_request_receipt，
该表是公共 HTTP 幂等回执，不能替代 request_idempotency。
三、2026-09-09 约束纠偏
tools/generate_baseline_sql.py 旧实现只按规则列里的"唯一"字样逐字段生成 UNIQUE KEY，
无法表达 docs/00 中的 唯一键 (a, b) 写法，导致四张表的联合唯一键被拆成两个单列唯一键：
| 表 | 纠偏前（错误） | 基线要求 |
|---|---|---|
fin_market_price |
UNIQUE(product_id)、UNIQUE(trade_date) | UNIQUE(product_id, trade_date) |
fin_nav_history |
UNIQUE(product_id)、UNIQUE(nav_date) | UNIQUE(product_id, nav_date) |
fin_holding |
UNIQUE(customer_id)、UNIQUE(product_id) | UNIQUE(customer_id, product_id) |
sys_customer_assignment |
UNIQUE(customer_id)、UNIQUE(employee_role) | UNIQUE(customer_id, employee_role) |
后果：场内日线与净值每产品只能存一行、持仓每客户只能有一个产品，属结构性阻断。
四张表在纠偏时均为 0 行，故纠偏无数据风险。迁移 20260909_constraint_fix 删除 8 个错误
唯一键、新增 4 个联合唯一键；docs/00 基线文档未做任何修改，纠偏的是库与生成器。
验证证据（docs/evidence/）：
20260909-before-constraint-fix.sql：纠偏前 52 张表SHOW CREATE TABLE全量快照；20260909-fingerprint-before.json与20260909-fingerprint-after.json：纠偏前后结构指纹；- 两份指纹的差异恰好 4 张表（上表四张），其余 47 张结构未变；
tools/audit_constraints.py：约束差异由 12 条降为 0。
四、既有库对齐（方案 A）
基线表补入 Alembic 链首（20260909_baseline_schema）后，按库的来源分三种情况：
| 库状态 | 特征 | 操作 |
|---|---|---|
| 空库 | 无 alembic_version 记录、无业务表 |
alembic upgrade head，全量建出 51 张业务表 |
| 由 Alembic 建起 | alembic_version 已位于链上 |
直接 alembic upgrade head；Alembic 不会重跑祖先迁移，无需 stamp |
| 手工或脚本建库 | 有业务表但 alembic_version 为空 |
直接 upgrade 会重建已有表而失败，必须先 alembic stamp <当前结构对应版本>，再 upgrade head |
tools/migration_state_check.py 只读诊断这三种状态：读取迁移链 head、alembic_version 记录与
业务表数量，并按结构特征（生成列、联合唯一键、代表性表）由新到旧推断库实际所处版本，输出可执行
的建议命令。三种状态均已实测：空库判定正确；jr 库判定为"已在 head、无需操作"；手工库场景
（建表后清空版本记录）提示 stamp 到 20260909_memory_active_key，按其建议执行后 upgrade head
无任何 Running upgrade 输出，即未误重建表。
五、边界
数据库约束仍以 docs/00-新数据库基线设计.md 为业务权威。指纹与约束审计只证明结构一致，
不替代状态机、并发语义和跨存储投影（Milvus/Neo4j）的业务验收。