 lzf_0626
|
4d8edb4b7f
|
chore: 号段一致性自检固化为 tools 脚本并纳入门禁；AGENTS.md 更新主分支口径、Agent/工具清单与测试基线
|
2026-09-12 12:29:20 +08:00 |
|
|
lzf_0626
|
244f03917b
|
回复 ZSY 的底座扩展确认；登记 docs/00 的一处已知偏差；更新 AGENTS.md 过期口径
## 对 ZSY 三件事的核实与裁决（docs/33-ZSY底座扩展确认-回复.md）
1. **访客身份**：`data_scope="public"` 我扫了全平台 26 个消费点，对未知值的行为一致
fail closed（6 处 `== "all"` 判假、1 处 `!= "all"` 会要求 customer_ids 非空否则 403、
1 处显式白名单直接拒），**安全，不用改**。但有一条硬约束必须先确认：全平台有
**72 处 `int(context.user_id)`，只有 3 处做了防御**——若访客的 sub 不是纯数字，
其中"权限被拒时要写审计"的路径会把本该 403 的情况变成 500。已要求他确认
sub 为纯十进制数字、且 visitor 分支复用同一套 `jwt.decode`（含 isdecimal 校验），
而不是另写第二个鉴权入口。
2. **客服 Agent**：`allowed_roles` 扩集合与确定性安全路由可接受；`recalls_customer_memory`
是新声明字段，已要求**默认值必须是 True**（否则会静默关掉所有既有 Agent 的记忆召回，
界面看不出来、只表现为回答变差）。品牌名（南方科技 → 奶龙基金责任有限公司）属业务
口径，已上报项目方定，不由技术侧拍板。
3. **current_customer_id**：**他的判断正确**。我独立实测 information_schema：
`EXTRA=''` 且 `GENERATION_EXPRESSION=''`，配合 baseline_generated.sql 无 GENERATED
子句、seed_profile_demo.py 的注释、profile_repository.py 用原生 SQL 显式写入，
四处一致 ⇒ `docs/00` 第 783 行"生成列"的描述是错的。处置：按真实 schema 映射成
普通可空列、**不改 docs/00**（规则 1）、**不补迁移**（DDL 本身正确，为让文档成真而加
生成列会改变既有列语义，违反规则 4）、但**必须登记这处偏差**。
另：他删了两个死代码文件（含一处硬编码 Milvus 字段名，违反 AGENTS.md §E），方向认同，
但要求他在 PR 里附上两条 git grep 的实际输出以证明"全仓唯一引用是它自己的单测"。
## 落实我在回复里承诺的两件事
- `docs/08-数据库结构审计基线.md` 新增"六、已知文档偏差"，逐条登记上述偏差（含四处
证据与处置口径），并注明发现方式；
- `AGENTS.md` 环境口径新增 `MILVUS_LOCAL_URI` 的坑：配了会让健康检查与部分检索指向
本地 Milvus Lite 文件，出现"健康检查正常、实际查的是另一个库"；并注明 `milvus-lite`
属本地开发依赖，应放 `optional-dependencies` 而非主依赖。
## 顺带更新 AGENTS.md 的过期口径
- 表数 68 → **89**（场内 51 + 场外/推广 17 + 投顾 21），并注明投顾那 21 张的登记文档待补；
- 测试基线从"1034 passed / 1 failed"改为实测值：ruff 干净 / mypy 228 文件 0 错 /
1207 passed 0 failed / integration 99 passed，并指向 docs/32；
- mypy 那条从"本机 181 错、双方不可比"改成可操作的判据：先对版本，根因是某一侧虚拟环境
没满足 pyproject 的 sqlalchemy>=2.0,<3 / mypy>=1.14,<2；并写明**不要装 sqlalchemy2-stubs**
（那是给 1.4 的，2.0 自带 py.typed，装了反而按 1.4 API 报一批新错）。
文档守卫：42 份无编号冲突。
|
2026-09-12 11:27:28 +08:00 |
|
|
lzf_0626
|
76e87a33a7
|
更新 AGENTS.md 的表数口径：51 → 68（场内 51 + 场外/推广 17）
合并袁聪那 17 张表后，本文件仍写"52 张含 alembic_version = 51 张业务表"，与
tools/audit_schema.py 实测的 68 张对不上。改为写明构成，并指向
docs/28-场外与推广域数据表登记.md —— 否则下一个人看到 68 会误以为是有人绕过基线
偷偷建表（audit_schema 的期望值是从迁移动态推导的，不是手写清单）。
核验命令里的 .\.venv\Scripts\python.exe 一并改成 python，与本节"各用本机可用的那个"
的口径一致（架构师环境是 conda）。
|
2026-09-11 20:24:39 +08:00 |
|
 qyqy
|
928d0bcea3
|
chore: 按评审恢复 5 份文档、审计补 agent_type、修订环境口径
评审意见落地（§3.3 驳回删除 / §3.1 审计补充 / §1.4 解释器 / §2 编号）：
- docs/04、06、10、13、99 全部恢复（评审：删除收益为零、保留成本同样为零）；
AGENTS.md 改为"保留但仅作历史参考"并列入 D 类，ARCHIVE 归档说明加作废声明
- 治理审计补留痕：interaction_audit.detail 增加 agent_type 与 governance_rewrite
（治理层会改写对外输出，事后必须能追溯到是哪个 Agent 触发的；不改表结构，detail 是 JSON 列）
新增 tests/unit/service/test_agent_persistence_audit.py 锁住该契约
- AGENTS.md 修订环境口径：解释器各用本机可用的那个（.venv 被 gitignore、不进仓库）；
config_release 与 Milvus schema 均属环境数据、不随代码合并，相关结论必须带环境限定；
测试基线 1034；mypy 数字双方不可比（本机未装 sqlalchemy2-stubs，报错集中在模型层）
- docs/26 JWT 文档：因 21 已被风控迁移清单占用而改名，PR 描述里会单独说明
|
2026-09-11 18:42:46 +08:00 |
|
|
qyqy
|
96a6e01634
|
docs: 交接文档与 AGENTS.md 同步到合并后状态
- 交接文档 §0/§5/§6 重写：分支改为 NL_develop、测试基线 1013、已知问题逐条标注当前状态、
Git 段改为已推送 + PR 注意事项（5 份文档删除/26 号新增/字段映射三处跨分支决策）
- AGENTS.md 入口指向与基线数字同步：工具名改 search_knowledge、生效版本 id=216、
测试 1013、mypy 181（含归属说明）、新增 Agent 与文档编号现状
|
2026-09-11 15:41:49 +08:00 |
|
 wangjianlong_0626
|
e4c4099aaa
|
wip: 客服Agent + RAG + 画像收尾（基于 6516ccb）
|
2026-09-11 14:46:40 +08:00 |
|
|
Codex
|
b1497fd2c6
|
chore: initialize project repository
|
2026-09-09 21:55:37 +08:00 |
|