Commit Graph
3 Commits
Author SHA1 Message Date
lzf_0626 7635014d9e feat: 画像→图投影打通(按类型写标签,读写对齐;补删除客户端)
第 2 步(Neo4j)主体,三件事:

1. 新增 app/service/graph_model.py:图模型的**单一来源**。
   节点标签与主属性名会被拼进 Cypher(Neo4j 的标签不能用参数占位),因此必须来自受控常量,
   绝不能是调用方传入的字符串——否则就是 Cypher 注入;同时读服务与投影侧必须就"客户节点
   长什么样"达成一致。此前两边各写各的(投影写 :Entity{entity_id}、读服务查
   :Customer{customer_id}),结果写进去的关系永远读不出来。
   另用 RELATION_SEMANTICS 补上"谁指向谁"的方向校验:底座已有关系白名单(8 种),
   但白名单只约束关系名,不约束方向,这里补上,避免把 TRADED 写成 Customer→Tag。

2. 改 app/worker/graph_projection_worker.py:按 payload 的 source_type/target_type 写具体标签,
   投影前校验关系方向。标签与属性名全部取自 graph_model,调用方传不进任意字符串。

3. 新增 app/service/profile_graph_projection_service.py:把画像事实投影成节点与关系,
   并补上此前缺失的**投影删除客户端**(销户或记忆失效时 DETACH DELETE,同时清悬挂边)。
   只投影 user_facts(与画像同源),不直接读原始记忆——否则同一件事在画像与图里会有两种说法。
   图库故障一律返回 degraded 而不抛异常:投顾推荐可以暂时没有图,但不该因为图挂了
   导致画像更新失败。

背景(核查发现):MemorySyncOutbox 与 GraphProjectionWorker 此前是**孤儿代码**——表建了、
worker 也实现了(含幂等、重试、死信、MERGE),但没有任何代码往 outbox 写、也没有任何地方
实例化这个 worker,整条图投影链路从未接上过。这正是图中只有 Neo4j 自带 Person/Movie
示例数据的根因。本次把"画像 → 图"这条链路接通;领域事件驱动的投影仍待接入(worker 已修好可用)。

实测验证:
· 投影客户 9001 → relations=1,随后 neighbors(PREFERS) 直接读到
  {'tag_key': 'preference:risk_level=稳健型'} —— 写后读通,标签已对齐;
· delete_customer → 关系归零(degraded=False),重新投影恢复为 1,再次投影仍为 1(幂等);
· 图中标签为 Customer/Tag、关系为 PREFERS;早先探针残留的 Entity 节点已清理;
· ruff 通过、mypy 112 文件无错。
2026-09-10 21:43:39 +08:00
lzf_0626 6516ccb385 feat: 第二版——接口契约对齐 docs/05,修复静默故障与数据库基线
相对第一版 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(含失败关闭反证)。
2026-09-10 15:55:54 +08:00
Codex b1497fd2c6 chore: initialize project repository 2026-09-09 21:55:37 +08:00