Complaint Data Platform
Internal complaint workflow.
internal complaint operations platform
一个内部投诉运营平台，把微信、支付宝投诉和多业务线权限收进同一个工作台。运营先在云文档里整理和同步投诉数据， 系统再用统一主表做总览、产品洞察、下钻和分享报告；具备绑定台账的行可以发起支付平台回复或处理动作。
业务量级 / Operational Scale
已确认接入 5 条内部业务线，业务访问来自权限组到业务线的映射，不在页面公开业务线名称。
微信和支付宝投诉统一为 `channel` 字段，分析、下钻和分享报告从同一张投诉主表读取。
`complaint_records` 承接跨业务线、跨渠道查询；旧微信/支付宝表保留兼容，不作为新的分析口径。
运营编辑、自动保存、本地草稿、在线 presence 和乐观锁都围绕云文档链路完成。
用户可属于多个权限组，最终业务线权限取并集；无业务线权限的账号不能进入业务页面。
多商户配置、导入台账、在线处理、周月分析和审计日志分开落表，避免共享商户投诉串回。
未写具体投诉记录数，因为未找到可安全引用口径；页面只展示已确认的结构量级。
Screens
Scope
5 条业务线共用工作台，业务访问来自用户所在权限组的业务线并集。
云文档保存编辑现场，显式同步后才写入 `complaint_records` 统一主表。
Univer 云文档支持自动保存、本地草稿、在线编辑 presence 和版本冲突保护。
应用容器内跑 Nginx、Node.js 和前端静态资源，PostgreSQL 独立容器。
Architecture
按业务线路由的 React 工作台
所有业务页挂在 `/:biz/*` 下，前端根据 `allowedBizs` 控制业务线切换、侧栏入口和无权限跳转。
Express 统一解析业务线
后端在 `GET/POST /api/:biz/...` 入口解析业务线，再进入投诉、分析、云文档、商户配置和审计路由。
PostgreSQL 统一主表
`complaint_records` 用 `biz + channel` 统一微信和支付宝投诉，旧表保留兼容，分析只读主表。
Univer JSON 与显式同步
云文档保存表格内容、版本号、签名和在线会话；同步行时再标准化字段并写入投诉主表。
商户配置、导入台账和在线动作
微信/支付宝配置按业务线隔离，自动录入写云文档，回复/完结动作依赖导入台账绑定第三方投诉单。
容器化发布与审计边界
发布脚本负责镜像构建、迁移和容器重建；操作日志、API 日志、指标快照和告警事件单独落表。
Workflow
用户通过本地登录或 SSO 进入，后端返回业务目录、权限组和可访问业务线。
运营创建云文档，手工导入或自动补拉的数据先落成可编辑的 Univer 表格。
自动保存提交完整文档内容，`contentRevision + contentSignature` 阻止旧基线覆盖新内容。
点击同步后，后端校验表格行并转成 `biz + channel` 投诉记录，更新主表和行数。
在线处理先查导入台账或绑定记录，再执行支付平台回复、完结、反馈或图片上传。
总览、产品洞察、周/月分析和分享报告从统一主表读取，分享页保存当时的统计快照。
Timeline
横向滚轮、拖动或点击里程碑；选择项会更新下方详情和进度。
2024-10-24
人工分析记录成为系统数据
迁移中出现 analysis notes 模型，说明运营复盘已经成为平台需要长期保存和检索的业务对象。
01 / 10 · 业务数据形态
时间线整理自本地文档、Prisma 迁移、代码结构和提交记录，未包含主机、凭据或生产数据。
Notes
- 技术栈来自本地 `package.json`、Dockerfile、compose 和 Prisma schema。
- 时间线以迁移目录日期、README、Developer Guide、runbook 和近期提交记录为准。
- 页面只使用生产入口或本地虚拟数据截图，不展示真实投诉正文、订单号、用户数据或生产连接信息。