chore: refine production-readiness execution plan

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
2026-02-08 19:47:28 +08:00
parent 86d8e1dd94
commit 3126ed5e64

View File

@@ -1,64 +1,98 @@
# Implementation Plan: v1 Creator 路由恢复与闭环验证
# Implementation Plan: 生产部署能力补齐(数据源统一、隔离强化、双侧审计)
**Branch**: `[current-working-branch]` | **Date**: 2026-02-07 | **Spec**: 会话需求(修复 `/v1/t/:tenantCode/creator/*` 404
**Input**: 用户需求:开始修复 Creator 路由缺失问题,恢复 Portal 创作者中心 API 可用性并完成回归验证。
**Branch**: `[prod-readiness-hardening]` | **Date**: 2026-02-08 | **Spec**: 会话需求(评估并补齐生产部署能力
**Input**: 用户要求按 4 项标准补齐生产部署能力:
1) 前端数据来源后端接口/渲染;
2) 用户/租户数据隔离完备;
3) 超级管理员后台可审计;
4) 租户管理侧可审计。
## Summary
当前 `backend/app/http/v1/creator.go` 仅保留 `GrantCoupon` 方法,但注释块包含大量与该方法签名不匹配的 `@Router` 声明,导致 `atomctl gen route` 未生成任何 `/v1/t/:tenantCode/creator/*` 路由。计划将按“前端真实调用路径 -> 后端服务能力 -> 控制器显式方法”逐项恢复最小改动修复随后通过路由生成、Go 测试与关键 API 冒烟验证闭环。
当前评估结果为:
- #1 前端数据来源:未完全达标(存在硬编码业务数据页面);
- #2 用户/租户隔离:基础机制已具备,但依赖服务层手工加租户条件,仍有遗漏风险;
- #3 超管审计已具备audit_logs 表 + 超管查询页面/API
- #4 租户侧审计:未达标(仅有 audit 类通知,不等同审计日志查询能力)。
本计划目标是在最小风险下将以上 4 项全部提升为可上线状态:
- 去除生产路径硬编码业务数据;
- 强化多租户隔离“可证明性”(代码约束 + 负向测试);
- 保持并补强超管审计覆盖;
- 增加租户管理侧可审计能力(租户范围审计日志查询 API + 页面);
- 建立可审签发布证据链route/swagger/test/UI flow/evidence/archive
## Technical Context
**Language/Version**:
- Backend: Go (Fiber + GORM-Gen)
- Frontend reference: Vue 3仅用于接口映射不改前端
- Backend: GoFiber + GORM-Gen
- Frontend: Vue 3 + Viteportal/superadmin
**Primary Dependencies**:
- `atomctl gen route`(路由生成)
- `backend/app/services`Creator/Tenant/Coupon 服务)
- `backend/app/http/v1/dto`Creator 与 TenantMember DTO
- Backend: `backend/app/http/v1`, `backend/app/http/super/v1`, `backend/app/services/*`, `backend/database/models/*`
- Frontend: `frontend/portal/src/views/*`, `frontend/portal/src/api/*`, `frontend/superadmin/src/views/superadmin/*`, `frontend/superadmin/src/service/*`
- Generators: `atomctl gen route`, `atomctl swag init`
**Storage**: PostgreSQL使用现有 schema 与 seed 数据)
**Storage**:
- PostgreSQL`audit_logs` 已存在,必要时补索引/查询优化)
**Testing**:
- `cd backend && env GOCACHE=$PWD/.gocache GOTMPDIR=$PWD/.gotmp go test ./...`
- API 冒烟:`/v1/t/:tenantCode/creator/orders` 等关键路径不再 404
- Backend: `cd backend && env GOCACHE=$PWD/.gocache GOTMPDIR=$PWD/.gotmp go test ./...`
- Frontend Build/Lint:
- `npm -C frontend/portal run build`
- `npm -C frontend/portal run lint`
- `npm -C frontend/superadmin run build`
- `npm -C frontend/superadmin run lint`
- Frontend功能验收页面流:
- 超管审计日志查询流
- 租户管理侧审计日志查询流
- 用户“我的点赞/收藏/订单”等后端数据回填流
**Target Platform**: Linux 本地环境backend: `127.0.0.1:18080`
**Target Platform**:
- Linux 部署环境Web + API
**Project Type**: Web backend API
**Project Type**:
- Web applicationfrontend + backend
**Performance Goals**:
- 本次以功能恢复为目标,不新增性能指标
- 审计日志列表接口在常规分页20条下 p95 <= 300ms预发基准
- 不引入明显回归(核心列表接口不劣化)
**Performance Measurement Protocol**:
- 测量接口:`/super/v1/audit-logs` 与新增租户审计列表接口。
- 测量条件:`page=1&limit=20`,默认排序(`created_at desc`),不带 keyword。
- 样本规则:预热 10 次后连续采样 50 次,统计 p95。
- 证据输出:写入 `docs/release-evidence/<date>.md` 的“性能基线”小节。
**Constraints**:
- 不手改任何 `*.gen.go`
- 控制器保持薄层(参数绑定 -> services.* -> 返回
- 路由参数使用 `camelCase`,数值 path 参数使用 `:id<int>`
- 仅做最小修复,不做与问题无关重构
- 禁止手改 `*.gen.go`(路由/文档生成文件仅通过工具生成)
- 控制器保持薄层(bind -> services -> return
- 使用 `as any` / `@ts-ignore` / `@ts-expect-error`
- 缺陷修复最小化,不做无关重构
**Scale/Scope**:
- 仅修复 `backend/app/http/v1/creator.go` 路由缺失问题
- 影响生成文件:`backend/app/http/v1/routes.gen.go`(通过生成器更新
- 更新回归记录:`docs/test-matrix.md`
- 覆盖 portal + superadmin + backend v1/super v1 审计与隔离相关模块
- 覆盖上线阻塞项P0与并行优化项P1
## Constitution Check
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
-控制器薄层:方法将仅负责绑定和调用 service
- ✅ 生成文件规范:仅通过 `atomctl gen route` 更新路由生成文件。
-事务与数据访问边界:不在 controller 做任何 DB 操作。
-验证要求:包含 `go test ./...` + 关键页面流 API 冒烟证据。
-符合后端分层Controller 不直接做 DAO CRUD统一走 `services.*`
-符合生成文件约束:路由与 Swagger 仅通过 `atomctl` 生成
-符合多租户前缀规范:`/v1/t/:tenantCode/*`
-覆盖前后端联调验收要求:前端页面流 + `go test ./...`
- ✅ 计划包含任务拆解、依赖、验收标准、风险项、责任归属与里程碑
## Project Structure
### Documentation (this feature)
### Documentation (this phase)
```text
docs/
├── plan.md # 当前计划(本文件)
── test-matrix.md # 回归记录更新
├── plan.md # 当前执行计划(本文件)
── release-evidence/<date>.md # 验收证据模板与执行结果
└── plans/<date>.md # 阶段完成归档
```
### Source Code (repository root)
@@ -66,79 +100,195 @@ docs/
```text
backend/
├── app/http/v1/
│ ├── creator.go # 本次主要修复文件
── routes.gen.go # 由 atomctl 生成
├── app/http/v1/dto/
│ ├── routes.manual.go
── routes.gen.go # 生成文件(勿手改)
│ ├── user.go
│ ├── creator.go
── creator_report.go
│ └── tenant_member.go
└── app/services/
├── creator.go
── creator_report.go
├── tenant_member.go
── coupon.go
── (new) audit_logs.go # 若新增租户侧审计接口
├── app/http/super/v1/
│ ├── audit_logs.go
├── routes.manual.go
── routes.gen.go # 生成文件(勿手改)
├── app/services/
── audit.go
│ ├── order.go
│ ├── content.go
│ ├── coupon.go
│ ├── tenant*.go
│ └── super.go
└── docs/
├── docs.go # 生成文件(勿手改)
├── swagger.yaml # 生成文件(勿手改)
└── swagger.json # 生成文件(勿手改)
frontend/portal/
── src/api/creator.js # 仅用于接口映射核对
frontend/
── portal/
│ └── src/
│ ├── api/
│ ├── router/index.js
│ └── views/
└── superadmin/
└── src/
├── router/index.js
├── service/
└── views/superadmin/
```
**Structure Decision**: 使用现有后端 v1 模块结构,控制器集中恢复,服务层复用现有能力,不新增新模块
**Structure Decision**: 在现有目录内增量修复,不新增独立子项目;优先复用现有 service 与 DTO确保变更可控
## Plan Phases
### Phase 1 — 路由映射与控制器设计
- 依据 `frontend/portal/src/api/creator.js` 提取全部 `/creator/*` 调用
- 将调用映射到现有 service 方法Creator/Tenant/Coupon
- 为每个 endpoint 设计独立 controller 方法与准确 `@Router/@Bind`
### Phase 1 — 前端数据源统一P0
目标:满足“前端业务数据必须来自后端接口/渲染”
- 基于 router 生成“生产页面 -> 数据来源(API/mock/static)”清单
- 替换生产路径中的硬编码业务数据示例Portal 用户侧业务列表)
- 处理 Superadmin demo 数据风险:默认禁入生产菜单/路由(必要时移出生产构建入口)。
### Phase 2 — 控制器实现与路由生成
- 重写 `backend/app/http/v1/creator.go`:一条路由一个方法,去除“多路由堆在单方法注释”反模式
- 执行 `atomctl gen route`,确认 `routes.gen.go` 产出完整 `/v1/t/:tenantCode/creator/*` 注册项
### Phase 2 — 用户/租户隔离强化P0
目标:把“依赖人工自觉加条件”改为“可验证、可回归”
- 梳理关键服务order/content/coupon/tenant/wallet过滤点
- 对高风险路径补足 query-time tenant/user 约束。
- 增加跨租户越权负向测试并形成隔离矩阵证据。
### Phase 3 — 回归验证与文档更新
- 运行 `go test ./...`
- 用 token 对至少以下接口冒烟:
- `GET /v1/t/:tenantCode/creator/orders`
- `GET /v1/t/:tenantCode/creator/contents`
- `GET /v1/t/:tenantCode/creator/settings`
- 将修复结果与证据补充到 `docs/test-matrix.md`
### Phase 3 — 审计能力补齐(超管 + 租户P0
目标:满足 #3/#4 审计要求
- 超管侧:盘点并补齐关键操作 `Audit.Log` 覆盖。
- 租户侧:新增租户审计查询 API + 页面,附角色权限控制。
- 完成 route 生成与 Swagger 生成,确保接口可见且可调试。
### Phase 4 — 验证、证据与发布门禁P0
目标:形成可审签的上线证据。
- 执行 backend 全量测试与双前端 build/lint。
- 执行前端页面流验收并按模板记录证据。
- 输出发布门禁检查单Pass/Fail + 证据路径)。
- 阶段通过后归档 `docs/plan.md``docs/plans/<date>.md`,并清空 `docs/plan.md`
## Tasks
- [ ] T1 `frontend/portal/src/api/creator.js` 提取 endpoint 清单并建立 service 映射
- [ ] T2 `backend/app/http/v1/creator.go` 实现 creator 核心接口apply/dashboard/contents/orders/settings/payout/withdraw
- [ ] T3 `backend/app/http/v1/creator.go` 实现成员与邀请相关接口members/invites/join-requests/review
- [ ] T4 `backend/app/http/v1/creator.go` 实现优惠券相关接口list/get/create/update/grant
- [ ] T5 `backend/app/http/v1/creator.go` 实现报表相关接口reports/overview 与 reports/export
- [ ] T6 执行 `atomctl gen route` 并确认 `/creator/*` 路由已注册
- [ ] T7 执行 `go test ./...`,修复由本次改动引入的问题
- [ ] T8 执行 Creator 关键接口冒烟并记录结果
- [ ] T9 更新 `docs/test-matrix.md` 记录 Creator 修复闭环结果
- [ ] T1 建立“生产部署能力差距台账”(含 router->页面->数据来源盘点)
- [ ] T2 替换 Portal 生产路径中的硬编码业务数据来源
- [ ] T3 下线或隔离 Superadmin demo 数据路由(防止进入生产流量路径)
- [ ] T4 建立后端隔离审计清单order/content/coupon/tenant/wallet
- [ ] T5 对高风险服务补充 tenant/user query-time 约束(最小改动)
- [ ] T6 增加跨租户越权测试用例并纳入回归
- [ ] T7 盘点超管关键操作审计埋点,补齐缺失 `Audit.Log` 调用
- [ ] T8 设计并实现租户侧审计日志查询 API租户范围、权限受控
- [ ] T9 执行 `cd backend && atomctl gen route` 并校验新增路由注册
- [ ] T10 实现租户管理侧审计页面(筛选、分页、时间范围、动作类型)。
- [ ] T11 补充审计相关 API 注释与字段定义operator/action/target/detail
- [ ] T12 执行 `cd backend && atomctl swag init` 并校验 Swagger 产物更新。
- [ ] T13 执行 backend 全量测试 `go test ./...`
- [ ] T14 执行 portal/superadmin build + lint。
- [ ] T15 创建并冻结验收证据模板:`docs/release-evidence/<date>.md`
- [ ] T16 执行前端页面流验收并填充证据模板(含截图/日志/结论)。
- [ ] T17 汇总发布门禁清单并形成 Go/No-Go 结论。
- [ ] T18 阶段完成后归档 `docs/plan.md``docs/plans/<date>.md`,并清空 `docs/plan.md`
## Dependencies
- T1 -> T2/T3/T4/T5(先映射后编码
- T2/T3/T4/T5 -> T6代码落地后生成路由
- T6 -> T7/T8先确认路由注册再跑测试与冒烟
- T7/T8 -> T9测试证据写入文档
- T1 -> T2/T3/T4/T7(先冻结缺口,再实施
- T4 -> T5 -> T6 -> T13隔离设计先行测试跟进
- T7 -> T8 -> T9 -> T10先有后端能力与路由再接前端
- T8 -> T11 -> T12接口定义后再生成 Swagger
- T2/T3/T10 -> T14/T16前端改造完成后再构建与页面验收
- T15 -> T16 -> T17证据模板先行
- T9/T12/T13/T14/T16 -> T17发布结论依赖完整证据链
- T17(Go) -> T18仅 Go 才归档No-Go 不归档)
## Owner Roles (RACI-lite)
> 说明:每个任务必须有唯一 DRIDirectly Responsible Individual与一个 Approver。
| Role | 主要职责 |
|------|----------|
| Tech Lead (Overall) | 统筹范围、顺序、风险与里程碑审签 |
| Backend Lead | 隔离强化、审计后端能力、生成流程与后端验证 |
| Frontend Portal Owner | Portal/租户侧页面改造与联调 |
| Frontend Superadmin Owner | Superadmin 生产路径治理与联调 |
| QA Owner | 回归用例、页面流验收、证据完整性审查 |
| Release Owner | 发布门禁、Go/No-Go 会议与归档执行 |
## Task Accountability (DRI / Approver)
| Task | DRI | Approver |
|------|-----|----------|
| T1 | Tech Lead | QA Owner |
| T2 | Frontend Portal Owner | Tech Lead |
| T3 | Frontend Superadmin Owner | Tech Lead |
| T4 | Backend Lead | Tech Lead |
| T5 | Backend Lead | QA Owner |
| T6 | QA Owner | Backend Lead |
| T7 | Backend Lead | Tech Lead |
| T8 | Backend Lead | Tech Lead |
| T9 | Backend Lead | Tech Lead |
| T10 | Frontend Portal Owner | QA Owner |
| T11 | Backend Lead | Tech Lead |
| T12 | Backend Lead | Tech Lead |
| T13 | Backend Lead | QA Owner |
| T14 | Frontend Superadmin Owner | QA Owner |
| T15 | QA Owner | Release Owner |
| T16 | QA Owner | Release Owner |
| T17 | Release Owner | Tech Lead |
| T18 | Release Owner | Tech Lead |
## Execution Schedule (10 Working Days)
> 计划周期10个工作日。发生阻塞时顺延不压缩验证与证据阶段。
| Day | Focus | 任务 | Primary Owner | 协作方 | 当日退出标准 |
|-----|-------|------|---------------|--------|--------------|
| D1 | 基线与证据机制冻结 | T1, T4(启动), T15 | Tech Lead, Backend Lead, QA Owner | Release Owner | 差距台账冻结;隔离清单初版;证据模板落盘 |
| D2 | 前端数据源整改Portal | T2(Portal核心页面) | Frontend Portal Owner | Backend Lead | 生产路径硬编码业务数据改为 API 拉取 |
| D3 | 前端生产路径治理Superadmin | T2(收尾), T3 | Frontend Superadmin Owner | Tech Lead | demo 路由完成隔离且不进入生产入口 |
| D4 | 隔离约束补强(一) | T5(order/content) | Backend Lead | QA Owner | 关键查询改为 query-time 约束,完成自检 |
| D5 | 隔离约束补强(二)+ 负向测试 | T5(coupon/tenant/wallet), T6 | Backend Lead, QA Owner | Tech Lead | 跨租户负向测试覆盖核心场景并通过 |
| D6 | 审计覆盖补漏 + 租户审计API开发 | T7, T8(启动) | Backend Lead | Frontend Portal Owner | 审计补漏清单清零;租户审计 API 代码完成 |
| D7 | 路由生成与后端可调用性 | T9, T8(联调收口) | Backend Lead | Tech Lead | `atomctl gen route` 完成且新增路由注册可见 |
| D8 | 租户审计前端与接口文档定义 | T10, T11 | Frontend Portal Owner | Backend Lead, QA Owner | 租户审计页面接通后端;注释字段定义完成 |
| D9 | 文档生成 + 构建测试 | T12, T13, T14 | Backend Lead, Frontend Superadmin Owner | QA Owner | Swagger 产物更新go test 与双前端 build/lint 可复现 |
| D10 | 页面流验收与发布评审 | T16, T17, T18(条件触发) | QA Owner, Release Owner | 全员 | 页面流证据齐全Go/No-Go 结论明确Go 时完成归档与清空 |
## Milestones
- **M1 (D3 End): 前端生产数据源统一完成**
Exit Criteria: 生产路径无硬编码业务记录数据demo 路由已隔离。
- **M2 (D5 End): 多租户隔离强化完成**
Exit Criteria: 高风险服务完成 query-time 约束;跨租户负向测试通过。
- **M3 (D9 End): 双侧审计能力与生成链路完成**
Exit Criteria: 超管审计补漏完成;租户审计 API + 页面可用route/swagger 生成成功。
- **M4 (D10 End): 发布门禁与归档完成**
Exit Criteria: 测试、构建、页面流证据与门禁结论完整Go 时归档并清空活动 plan。
## Acceptance Criteria
1. `backend/app/http/v1/routes.gen.go` 中存在并注册 `/v1/t/:tenantCode/creator/*` 对应路由
2. `GET /v1/t/:tenantCode/creator/orders` 不再返回 404认证通过前提下
3. `go test ./...` 通过(若有历史失败,需明确标注非本次引入)
4. `docs/test-matrix.md` 新增 Creator 路由修复结果与可复现命令
1. 前端生产路径不再存在硬编码业务数据列表(允许 UI 常量,不允许业务记录数据常量)
2. 用户/租户隔离具备可回归证据:跨租户访问负向测试通过,关键接口均有 tenant/user 约束
3. 超级管理员后台审计可用:可按租户、操作者、动作、时间筛查审计日志
4. 租户管理侧审计可用:租户管理员可查询本租户审计日志,且无法查看其他租户数据
5. 新增/调整审计 API 后,必须完成 `atomctl gen route` 且路由注册可验证。
6. 新增/调整审计 API 后,必须完成 `atomctl swag init` 且 swagger 产物与接口一致。
7. 若涉及前端改动,必须完成页面流验收;同时完成 backend `go test ./...`
8. 发布门禁清单全部通过后方可标记“具备生产部署能力”;且需执行归档到 `docs/plans/<date>.md` 并清空 `docs/plan.md`
## Risks
- **DTO 不匹配风险**:部分接口需复用 `tenant_member` DTO可能出现绑定字段不一致。
- 缓解:按现有 service 签名逐项对齐 `@Bind`
- **风险1前端替换数据源引发页面空态/交互回归**
- 缓解:逐页替换 + 空态兜底 + 页面流测试
- **路由冲突风险**:新增 `/creator/*` 可能与其他路径发生顺序/匹配冲突。
- 缓解:依赖生成器产出并通过启动日志核对注册项
- **风险2隔离强化引发历史“宽查询”行为变化**
- 缓解:先补负向测试,再做最小修复,避免大规模重构
- **权限语义偏差风险**Controller 恢复后可能暴露 service 内已有“仅租户主”限制,导致与前端预期不一致。
- 缓解:先恢复 404 问题;权限语义差异单独记录为后续优化项
- **风险3审计日志增长导致查询性能下降**
- 缓解:按测量协议验证 p95必要时补复合索引并复测
- **风险4租户侧审计权限定义不清**
- 缓解实现前冻结角色矩阵owner/admin/member验收时执行越权测试。
- **风险5证据缺失导致 Go/No-Go 争议**
- 缓解:统一证据模板、固定路径、固定 DRI/Approver 审核链。
## Complexity Tracking