group_fqcd_jr

28 Commits 12 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
lzf_0626	89f889b350	feat: 图投影对账（数据层）并补运维工具，第 2 步收尾与既有 `ProjectionReconciliationService` 的分工（两者互补，不是重复实现）： · 那个服务做事件层对账：哪些投影事件还没投递、需要重放； · 本次新增的是数据层对账：投递完成之后，图里的内容与权威画像是否一致（投影漏投、记忆失效后未清理、图库故障都会造成漂移）。实现 `ProfileGraphProjectionService.reconcile_customer`： · 从 user_facts 与持仓算出"应有的边"，从图中读出"实际的边"，求差集得到 missing （画像有、图里没有）与 orphaned（图里有、画像已无）； · 图是投影、MySQL 是唯一真相，因此差异一律以画像为准：missing 补写、orphaned 删除，而不是反过来去改画像； · `repair=True` 时修复，并修复后重新核对再回报——不凭"操作没报错"就宣布修好了； · 删除边前对关系名做白名单校验：关系名读自图中既有边，属外部数据，必须过白名单才允许拼进 Cypher。新增 tools/reconcile_graph.py：支持单客户与 `--all`、可选 `--repair`，退出码可直接用于巡检。顺带修掉一处日志噪音：读边时原用 `coalesce(t.tag_key, t.product_code, ...)`，会引用当前图中尚不存在的属性名，Neo4j 每次执行都抛 UnknownPropertyKeyWarning，把日志刷成噪音。改用 `properties(t)` 后在应用侧按键取值，功能不变、日志干净。实测（人为制造漂移再修复）： · 初始对账一致=True、应有 2 条 / 实际 2 条； · 删掉图中的 HAS_GOAL 边后一致=False，缺失被准确报出； · repair=True → 已修复=True、一致=True、缺失为空； · 复验一致=True，图中恢复 HAS_GOAL 与 PREFERS 两条关系； · tools/reconcile_graph.py 单客户与 --all 均 EXIT=0，输出无警告； · ruff 通过、mypy 112 文件无错。	2026-09-10 21:55:03 +08:00
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

Author

SHA1

Message

Date

lzf_0626

89f889b350

feat: 图投影对账（数据层）并补运维工具，第 2 步收尾

与既有 `ProjectionReconciliationService` 的分工（两者互补，不是重复实现）：
· 那个服务做**事件层**对账：哪些投影事件还没投递、需要重放；
· 本次新增的是**数据层**对账：投递完成之后，图里的内容与权威画像是否一致
  （投影漏投、记忆失效后未清理、图库故障都会造成漂移）。

实现 `ProfileGraphProjectionService.reconcile_customer`：
· 从 user_facts 与持仓算出"应有的边"，从图中读出"实际的边"，求差集得到 missing
  （画像有、图里没有）与 orphaned（图里有、画像已无）；
· 图是投影、MySQL 是唯一真相，因此差异一律**以画像为准**：missing 补写、orphaned 删除，
  而不是反过来去改画像；
· `repair=True` 时修复，并**修复后重新核对**再回报——不凭"操作没报错"就宣布修好了；
· 删除边前对关系名做白名单校验：关系名读自图中既有边，属外部数据，
  必须过白名单才允许拼进 Cypher。

新增 tools/reconcile_graph.py：支持单客户与 `--all`、可选 `--repair`，退出码可直接用于巡检。

顺带修掉一处日志噪音：读边时原用 `coalesce(t.tag_key, t.product_code, ...)`，会引用当前
图中尚不存在的属性名，Neo4j 每次执行都抛 UnknownPropertyKeyWarning，把日志刷成噪音。
改用 `properties(t)` 后在应用侧按键取值，功能不变、日志干净。

实测（人为制造漂移再修复）：
· 初始对账 一致=True、应有 2 条 / 实际 2 条；
· 删掉图中的 HAS_GOAL 边后 一致=False，缺失被准确报出；
· repair=True → 已修复=True、一致=True、缺失为空；
· 复验 一致=True，图中恢复 HAS_GOAL 与 PREFERS 两条关系；
· tools/reconcile_graph.py 单客户与 --all 均 EXIT=0，输出无警告；
· ruff 通过、mypy 112 文件无错。

2026-09-10 21:55:03 +08:00

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