PINF_MANAGEMENT/docs/EXECUTION_PLAN_ADMIN.md

后台管理系统执行计划（独立项目）

目标

• 建立独立的后台管理系统，用于对现有 App 数据进行 CRUD 管理。
• 仅使用管理员角色，不做多角色权限体系。
• 当前阶段不考虑软删除与审计日志。

范围与边界

• 后台管理系统前端单独开发，不在本仓库落地。
• 本仓库后端若需补齐管理能力，只新增接口，不影响现有 App 侧接口。
• 以“可用、稳定、可维护”为交付标准，优先覆盖核心数据。

里程碑与阶段

阶段 0：需求与字段确认

• 交付物：管理端功能清单、字段字典、角色定义（仅管理员）。
• 重点确认：哪些数据允许删除、哪些字段允许编辑、是否需要导出。

阶段 1：接口盘点与差距分析

• 交付物：现有 API 清单与管理端需求映射表。
• 结论预期：当前接口以“用户本人”为作用域，管理端需要跨用户访问能力。

阶段 2：管理端 API 设计

• 交付物：管理端 API 规范。
• 约定：统一路径前缀建议为 /api/admin/*。
• 约定：统一分页字段 page、per_page，统一筛选方式（query）。

阶段 3：后端能力补齐（如需）

• 交付物：管理员鉴权、跨用户 CRUD、内容管理写接口、缓存失效策略。
• 风险控制：只新增接口，不改动现有用户侧行为。

阶段 4：管理端前端工程建设（独立仓库）

• 交付物：登录、用户、宝宝、成长、预约、内容、聊天管理页面。
• 规范：统一分页、筛选、详情展示、表单校验。

阶段 5：联调与验收

• 交付物：联调清单、验收记录、问题关闭清单。
• 重点：权限隔离、分页与筛选稳定性、关键字段一致性。

风险与对策

• 风险：管理端操作可能影响 App 侧数据一致性。
• 对策：操作前确认字段范围，新增接口遵循现有模型与数据约束。

回滚方式

• 仅为文档规划与外部系统开发，不影响现有运行。
• 若后端新增管理端 API，可通过禁用蓝图注册或环境开关关闭。

交付物清单

• 管理端执行计划文档（本文件）。
• 管理端 API 文档（见 docx/API_REFERENCE.md）。
• 项目说明（见 docx/PROJECT_OVERVIEW.md）。