 Vicky
|
8b261b71de
|
feat: 08 后台四个页面的菜单与权限点落库 + 契约文档收口
为什么：内容治理 / 订单与权益 / 数据看板这三个页面的菜单此前刻意留空——
3-3 时页面还没做，菜单先落库会让前端动态路由指向不存在的组件。页面这一轮做完了，
把菜单（id 20–25，含组件路径）、权限点与超管授权按幂等写法补进 sql/data-phase1.sql，
刷新后台即生效，不需要清缓存重新登录。
- sql/data-phase1.sql：新增 3 个目录 + 3 个菜单，超管菜单授权 20–25；可重复执行
- docs/api-phase1.md：08 行由「仅剩后台页面（3-4）」改为「已实现」；
新增「2.9 后台前端页面（已实现）」，列出五个页面的路由 / 组件路径 / 依赖权限点 / 覆盖接口
|
2026-10-15 13:29:18 +08:00 |
|
|
Vicky
|
d67d9daf8c
|
feat: 08 数据看板落地（总览 + 转码看板，只读）
为什么：
1) 前面几块把用户、内容、播放、交易、媒资的数据都落库了，运营需要一个地方一次看完，
否则每个指标都要去查库或翻后台列表。
2) 看板最容易出的问题是"数字看起来对但口径不清"，所以每个指标都在代码注释和
docs/api-phase1.md 里写死口径（时间范围、统计维度），前端 tooltip 直接复用。
3) 取不到数据源的指标（DAU、CDN 流量成本、商店订单金额）一律返回 null 并在 notes 里
说明缺什么、怎么补 —— 不用 0 冒充，避免运营拿假数字做判断。
4) 站在接入层做只读聚合而不是新建模块：它跨六个域取数，建模块只会把依赖再摊开一层，
而它只读不写，放在 admin-api 改动面最小。
|
2026-10-15 13:03:58 +08:00 |
|
|
Vicky
|
1fb8427f28
|
feat: 08 创作者与内容审核落地（入驻审核 / 内容提交审核 / 定时发布 / 分集定价）
为什么：
1) 内容是创作者供的，必须有一条可管控的供给链路：创作者入驻要审、内容提交要审、
审核通过才能真正上架 —— 否则平台无法对内容和主体负责。
2) 审核不能绕过状态机。内容提交审核通过后，是顺着短剧状态机
SUBMIT → APPROVE → PUBLISH 推上去，而不是直接写 status 字段，
这样审核记录与操作日志都不会缺环。
3) 定时发布（publish_at 到点自动上线）同样走状态机，并且做成幂等任务：
重复执行不会把已上线的剧再推一次。
4) 定价落在 is_free / unlock_coin 上，与权益表解耦：改价立即影响播放与下载判定，
但已购用户的权益不受影响，不会因为改价把用户买过的东西收回去。
5) 补齐 PM 草稿未做的部分：5 个权限点 + 3 条后台菜单（含前端组件路径）+ 超管授权（幂等），
以及后台定价页需要的价格读取接口 GET /admin/prices。
|
2026-10-15 12:51:40 +08:00 |
|
|
Vicky
|
7e730fbbca
|
feat: 08 订单与权益落地（金币解锁 / 权益判定生效 / 补发回收 / 对账）
为什么：
1) 第一阶段要能真正收到钱，而收钱方式是金币解锁分集。本提交把钱包、金币流水、
权益、订单四样打通，客户端可以解锁并立刻播放，不再只是展示。
2) 权益判定此前只是端口占位（一律视为未解锁）。交易模块用 @Primary 提供实现后，
播放入口与下载入口的付费判定同时生效 —— 两条链路一行没改。
3) 钱的事必须可追溯、可幂等：所有金币变动都带幂等键并写 coin_ledger，
余额与流水同事务；订单每次状态流转都写 order_event（月分区），支付争议可回溯。
4) 后台要能兜住线上问题：补发（重复提交幂等）、退款（回收权益 + 扣回金币，
余额不足时留人工跟进备注）、人工补币（先校验用户存在，避免给不存在的用户建钱包）、
手动对账（默认每天 04:20 自动跑前一天）。
5) 09 商店支付按约束只做端口预留：StoreVerifier 未接入时明确报"尚未配置"，
宁可不收钱也不产生假订单。
|
2026-10-15 12:26:27 +08:00 |
|
|
Vicky
|
af1dc48494
|
feat: 06 互动与内容治理落地（评论 / 点赞 / 举报 / 敏感词 / 审核留证）
为什么：
1) 产品侧要先把内容治理闭环跑通才能谈上线：评论可发布、可翻页、可删除，
违规内容能在后台被审核与驳回，举报要有工单可追溯。本提交把这套补齐。
2) 审核不能只靠人肉：敏感词按 BLOCK/REPLACE/REVIEW 三档处置，
机审通过即发布（可配置为 PRE_REVIEW 全部先审后发），人审与机审的结论
都写进 content_audit_record，争议时可回答"当时凭什么放行/驳回"。
3) 举报处理必须与处置打通：结论成立会联动驳回被举报评论，并可选同时封禁被举报用户，
避免"工单处理完了但违规内容还挂着"。
4) 顺带修复一个真实缺陷：user_favorite / content_like 上有唯一索引，而全局配置会把
deleteById 改写成逻辑删除，导致取消收藏/点赞后旧的 deleted 行仍占位，
再次收藏或点赞直接撞唯一索引报错。关系类数据没有留证价值，改为显式物理删除，
并补了"取消后再来一次"的回归自测。
|
2026-10-15 12:03:32 +08:00 |
|
|
Vicky
|
b3179fc836
|
refactor: 后端标识统一为 FruitShorts，并落地 05 离线下载
为什么：
1) 产品已定名 FruitShorts，但后端仍是 reelshort 系列标识 —— Java 包 com.reelshort、
模块名与 jar 名 reelshort-*、spring.application.name、配置前缀 reelshort.*，
这些会出现在启动日志、命令行和 IDE 里，与产品名不一致。本次整体替换为 fruitshorts，
数据库连接名上一轮已改名，保持不变。
2) 第一阶段下一批第 1 步（05 离线下载）要求把下载授权（设备绑定/有效期/吊销）、
下载任务与断点续传、配额与过期清理、仅 Wi-Fi 规则做成完整接口，本提交一并落地。
3) 顺带修复：schema-phase1.sql 里 playback_ticket / order_event 仍按普通表定义唯一索引，
表分区化之后重跑脚本必定报错（分区表的唯一索引必须包含分区键）。改为在本脚本里就
按分区表定义，并验证脚本可重复执行。
|
2026-10-15 11:44:26 +08:00 |
|
|
Vicky
|
a4aa749cc6
|
feat: 初始化短剧服务端（管理后台 API + 客户端 API）
Spring Boot 3.2 / MyBatis-Plus / PostgreSQL，7 个 Maven 模块；含认证鉴权、内容与媒资管理、操作日志，以及客户端 /app/** 接口。
|
2026-10-14 18:02:47 +08:00 |
|