跳到主要内容

Codex 评审结论（L3 §14–16）

总评​

BLOCK，先修 §15/§16 再写 §17–29。承接 L2 §8 方向对、多数 dn_* 表映射真实；但 MCP 权限表名、Webhook ACK 语义、交付记录是否已有消费确认三处会误导后续。

必修 blocking​

  1. §16 MCP 权限表名错误且机制混写：实际是 dn_mcp_api_key + sys_api_perms；MCP 中间件只校验 X-API-Key / 状态 / 过期 / 日限额，未接 api_perms 权限隔离。（mcp_api_key_model_gen.go、api_perms_model_gen.go、mcp_apikey_middleware.go、apiperms_middleware.go）
  2. §16「Webhook 无 ACK」不准：实际有 /v1/webhook 返回传输层 received，但无业务消费确认 / 无反馈落库。须拆清 ACK / 确认 / 反馈三层。（webhook_logic.go、webhook.api）
  3. §15 dn_push_log 说成「消费确认」过度声称：真实字段只有推送状态 / HTTP 状态 / retry_count / 错误 / 耗时 / 消息 id，无消费确认字段；与 §16「消费确认是缺口」自相矛盾。（push_log_model_gen.go）
  4. §15「标准化记录=status=1」过窄：status=1 已标准化待分发、status=2 已分发，均为标准化后记录。（raw_news_model_gen.go）
  5. §16 失败重试缺口判断对、但更精确：FindPending 查 status=0 and retry_count<3，失败直接 status=2、不回 pending 也不自增。（push_log_model.go、push_message_job.go、push_consts.go）

建议 non-blocking​

  1. §14 MySQL「dn_* 表」→「业务表多为 dn_，权限/系统表含 sys_」。
  2. §15 来源表字段为 source/status/category/std_config/tags，无明确授权维度 → §17 写「授权维度待补」，非现行已具备。
  3. §15「缺维度即不可交付」是好约束但非现行代码事实 → 标 L3 目标校验 / 不变量。
  4. §15 Feedback/Evidence 中文正文统一叫「反馈与运行证据」，英文只作括注，降黑话感。

亮点​

  1. §15 多数存储映射真实（raw_news / raw_news_direct / raw_news_history / agent_execution / llm_call_log / push_log / crawler_source / subscriber / event_category）。
  2. §16 最小契约忠实承接 L2 §8，未过早冻结字段 schema。
  3. §15「运行证据 vs 下游反馈」按来源分开是对的，支撑后续可观测与反馈闭环。