feat(B批收尾): B1门禁可信/B7-1菜单环防护/B2空值守卫/B7-2分页/B7-3字段清洗/B3空态/B4索引key/B5-3 comment三集合选A新建schema(漂移清零)/B6清理+admin配置+changelog

reports/comment-collections-decision.md

@@ -0,0 +1,51 @@
+# 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 标注破坏性变更。