# B5-3 comment* 三集合决策报告（需人工确认，执行模型未自动执行）

现状：`comment` / `comment_like` / `comment_operation_logs` 在仓库内无任何 schema，
但三页完整实现了增删改查。门禁 `fieldDriftCount: 20` 全部来自这三集合（missing-in-schema）。

## 页面实际字段（来自 list.vue field）

| 集合 | 字段 |
|---|---|
| comment | content, root_id, author_id, parent_id, article_id, like_count, create_time, update_time, reply_count, ip_location |
| comment_like | user_id, comment_id, create_time |
| comment_operation_logs | parent_id, user_id, content, like_count, create_time, update_time, status |

## 官方 opendb-news-comments 字段（仓库内现有 schema）

`_id, article_id, user_id, comment_content, like_count, comment_type, reply_user_id, reply_comment_id, comment_date, comment_ip`

## 方案 A：新建 3 份 schema（按页面字段）

- 动作：补 `comment.schema.json` + `comment_like.schema.json` + `comment_operation_logs.schema.json`（权限 + 索引），上传后门禁 20 条漂移清零。
- 风险：若云端实际用的是 `opendb-news-comments`，会造成双写分裂（两套评论表并存）。
- 成本：小，纯新增文件，不碰页面。

## 方案 B：页面改用官方表 opendb-news-comments

字段映射（差异大）：

| 页面字段（comment） | 官方字段 | 说明 |
|---|---|---|
| content | comment_content | 改名 |
| create_time | comment_date | 改名（类型需核对 timestamp vs date） |
| author_id | user_id | 改名 |
| root_id / parent_id | reply_comment_id | 语义不完全等同，需确认盖楼模型 |
| article_id | article_id | 同名 |
| like_count | like_count | 同名 |
| reply_count / update_time / ip_location | 无 | 官方表无对应，需加字段或弃用 |
| — | comment_type / reply_user_id / comment_ip | 页面无对应，需确认是否需要 |

- 风险：字段语义差异大，改完需重建/迁移数据；`comment_like` 与 `comment_operation_logs` 在官方体系无对应表，需另行设计。
- 成本：大，涉及页面 field、表单、查询条件全改 + 数据迁移。

## 建议

缺云端真相时倾向 **A（新建 schema）**：先让三页有合同可依，门禁清零；
待确认云端真实用表后再做合并迁移。若云端已在用 `opendb-news-comments` 且有数据，
则选 B，但必须先出数据迁移脚本再改页面。

## 确认后执行清单

- 选 A：新建 3 份 schema + 3 份 index + init 权限（如需细粒度），跑 `npm run check:contracts` 验收漂移清零。
- 选 B：改三页 field/表单/查询 + 迁移脚本 + 重跑门禁 + changelog 标注破坏性变更。