基于现有 Admin 的改造计划

版本：2026-09-28 / v1.13。用户要求制定改造计划、完整核对清单和功能清单。本页定义实施工作基线，不作为实现或部署完成证明；当前已有入口、Console 价格路由、内容后端、Admin 栏目表单及 Site 全栏目消费者的局部实现，实际完成度与验证结果见代码基线与实施进度。既有 ADM-P01–09 主计划仍为任务主账，本页细化执行批次，不增加另一套重复任务。

最新范围决定：员工管理、角色与权限配置（AF-E05）暂缓，首批从 30 项调整为 29 项。 不新增岗位、工作区授权扩展或专门员工权限矩阵，不以这些工作阻塞公共内容、Site 与 Console/Site 使用流程。现有登录、客户与管理端隔离、已开放接口鉴权继续保留；已存在代码与历史验证不删除。员工部分恢复实施另行安排，不自动放入 B4。

当前执行方式：逐平台串行交付，顺序为 Site → Console → Admin 公共业务 → Studio → Commerce → Drama。 先完成当前平台可操作的完整流程，再进入下一个平台。Admin/Core/Contracts 是当前平台的必要依赖，随平台补齐；不再另开横跨所有平台的权限、诊断或测试专项。原 B0–B5 保留范围和历史映射，不再表示执行顺序。

2026-09-29 提交方式：各平台在所属项目仓库本地提交、本地合并，跨项目依赖核对完成后统一推送；本次不走 PR。Site 旧 PR #7 与 #9 已关闭，关闭不代表合并或上线。原目录未提交状态及当前服务数据须保留，Core 本轮 Site 阶段无服务端代码增量，不制作空提交。执行记录见 coordination/site-delivery/collaboration/README.md。

目标与明确边界

在现有 Admin 真实模式上保留客户、销售目录、价格、订单、待核对和审计，增加统一入口、可授权工作区、公共模型内容和 Site 固定栏目管理。让 Console 与 Site 消费同一来源的已发布模型内容，同时保留 Core 的唯一商业事实。

• 统一入口的目标工作区为公共管理、Site、Studio、Commerce、Drama；首批在同一 Admin 工程承载公共管理和 Site。Studio 原后台按模块继续使用与接入，独立页面仍自行验证授权；Commerce/Drama 随产品真实能力接入。未接入的工作区不显示为可进入。
• 统一入口不要求所有产品合成一个部署包。首批公共管理与 Site 共用现有 Admin；后续产品可保留独立后台，通过登记入口和受控身份交接进入，目标服务仍独立授权。只有真实接通后才开放空间。
• Console 是公开内容与客户自助端，不新增 Console 管理员工作区；供应后台首期独立，无卡片、导航或 SSO 集成，ADM-P07.03 继续后置。
• Core 保持身份、账户、目录、价格、权益、订单和账本的事实责任；产品持有自身对象；网关持有供应事实。内容入口统一不代表全部内容搬进 Core。
• 首批采用固定栏目表单与结构化内容，不先做任意页面搭建器、在线商务线索系统或全套营销平台。不开启未确认的周期订阅和商业政策。
• 开发按一位开发者的小批次串行主线组织；真实岗位和运营分工在上线前登记，不因权限场景存在就默认三位维护者的职责已分配。

基座复用与功能拆分决策

工作区是管理职责与权限范围，不等于新增一个应用。新增菜单须同时具备页面、责任服务、接口授权和结果回读；占位页面或登记配置不能计为接入完成。

功能归属与后台承载规则

按“谁持有事实、谁执行动作、谁使用界面”确定归属；不能仅按内容出现在哪个平台分配后台。

因此，入口数量与服务数量分别管理：首批一个员工入口承载公共管理与 Site；后续可进入独立产品后台。无需先拆成多个 Admin 工程，也不强制把所有产品后台合并。每次新增独立后台，在对应工作包写清拆分理由、维护责任和接口边界，再按原 CK 验证，不新建一套权限真值。

交付物与可追踪关系

每条链路均可追踪为：来源页面/对象 → AF 功能 → ADM-P 或产品任务 → 责任仓与 API → CK 核对项 → 执行证据。执行时在 progress 与 coordination/admin-refactor-plan.json 记录状态及证据；主计划不累积运行日志。原 32 项商业任务加 6 项 P09 任务仍为 38 项，AF 和 CK 不计为新主任务。

现有代码采用方式

Admin 当前 src/main.tsx 在构建时区分真实模式和 demo。改造以 src/real/entry.tsx、src/real/router.tsx 为运行入口：从真实 router 拆出外壳、工作区登记与各区导航，按功能组织新增页面；src/app/shell.tsx 是演示路径，不能仅修改该文件就声称真实后台已升级。

沿用 src/real/client.ts、auth.tsx、业务 API、BFF 白名单、员工能力查询、写入结果核对和身份变化清缓存机制。新服务接入显式 API 适配与授权白名单，不增加任意目标代理。保留已有路径或提供兼容重定向，首页变为管理入口后，已保存的客户、价格、订单深链继续可达。

下表将现有代码与剩余工作对应，作为领取执行切片时的核对入口。代码存在只证明可继续复用；运行完成度仍以 progress 中的证据为准。

旧入口兼容纳入 B1 的 AF-E03/E04/E06，不只验证已登录时可以打开 URL。实施时在前端和 BFF 复用同一目标路径校验，完整目的地保存在服务端登录事务；身份交接仍使用 Core 已登记的入口，不为每个业务对象登记一个登录地址。回调、未知结果手动恢复及重新发起登录均恢复已校验目的地，旧事务没有新字段时兼容原入口。只接受真实已接入路由、合法对象 ID 和已支持的筛选参数；拒绝外域、路径变体、额外参数及恢复页循环。目的地校验不授予任何业务权限，登录后仍由页面与执行接口分别校验。

Site 首次接入的实施顺序固定为：契约及后端验证 → BFF 与授权 → 固定栏目表单 → 受权预览及发布历史 → Site 全栏目消费 → 内容导入与切换 → 开放工作区。各环节可用隔离联调入口验证，正式导航只有在所开放功能完整接通后才启用。

界面沿用现有 OceanWay 品牌、组件与 shadcn 采用规则。设计交付聚焦五条操作旅程：员工选空间；模型关联并发布到两端；Site 编辑并回退；从产品任务定位公共客户/订单后返回；旧模块迁移后的异常恢复。每条旅程包含字段、身份、权限、正常/空/失败/冲突状态，不先开展无关视觉重做。

原批次的范围映射

B0–B5 继续用于 AF/CK 与 ADM 主任务追踪，不再作为串行执行队列。B0 的版本、接口、写入方检查只在当前平台涉及的范围执行；复用已有结果，不反复盘点全仓。

完整范围仍为 64 AF / 104 CK，首批仍为 B1–B3 的 29 项。平台阶段验收与首批联合验收分开：Site 可先形成独立交付；涉及两端的 AF/CK，须待 Console 配套通过后才算整项完成，不能把未完成端标为不适用。

逐平台实施顺序与退出条件

公共经营总览、待办、公告、账号/邮件配置归 Admin；提示词/模板和媒体资源归 Studio；帮助/教程的客户呈现归 Console。积分、订阅、促销、邀请/CDK、支付、外部存储与备份等原条件扩展保留在所属平台后续工作包，不在当前平台中无界扩展，也不从完整范围删除。完整 AF 主归属登记在本机台账 platform_delivery，共享能力的跨平台子项仍分别验收。

当前 Site 工作包按以下顺序结束：

1. 可访问入口：启动当前真实 Admin/Site，沿用已接通服务和现有登录；列出阻止运营操作的具体缺口，不重复搭建。
2. 现有内容迁入：从当前源码提取十类栏目和模型素材；核对数量、稳定 ID、来源和差异，真实商业值缺失单列，不编造。
3. 后台编辑与官网展示：逐栏目完成保存、预览、发布、官网回读；解决实际字段/布局/链接/手机问题。Studio 只补本阶段引用所需接口，不展开完整后台。
4. 发布与回退交付：核对撤回、历史回退及旧静态来源切换，复用已验证的恢复和鉴权；只有新改动或真实失败才补相应测试。
5. 提交平台结果：给出实际入口、可操作功能、逐项通过/未通过、遗留项、切换/回退说明。216 未验证时明确仅本地交付，不声称上线。

每阶段只有一个当前平台。跨仓修改须能指向该平台的一项具体用户动作；不得以“共用基础”为由重新展开全平台专项。确实被外部配置、来源资格或未确认业务阻断时，明确被阻断的动作和需要的输入，保留待验状态，再处理可执行平台；不以增加局部测试消耗等待时间。

每个工作包的交付格式

领取工作时引用现有 AF、CK 和 ADM-P 编号，按以下顺序形成一个可评审交付：

1. 列出现有代码/接口与差距，固定当前及目标写入方；标明复用、改造或新增。
2. 将查询、编辑、审核、发布、撤回、删除分别列为动作，填写对象/字段/工作区权限、方法与路径、契约版本和失败恢复方式。
3. 完成所需契约、服务、BFF、真实页面及消费者；能独立交付的切片先完成，依赖不齐的入口保持关闭。
4. 按对应 CK 收集正向、拒绝、冲突、失效及恢复证据，回归受影响的原商业和产品流程。
5. 登记旧入口处置、数据切换、回退步骤和维护责任；满足该模块全部退出条件后才开放。

每包都记录界面负责人、服务负责人、验收人和运营使用人，允许由同一人承担，但不能以仓名代替实际交接。依赖尚未确定时填写缺口及其阻断的动作；工期在盘点后估算，验收状态不随预计日期自动变化。

用户提到的“216”作为待核实的目标环境标识，归入 CK-B01、CK-R04/R05：先登记其实际地址、服务/契约版本、数据库与数据范围、配置开关、测试身份和回退点，再执行适用清单。现有本机隔离环境证据不能替代 216 的验收，也不能据此判断其容量是否满足要求。

216 的验收分成两种结论，分别记录：功能适用性验证首批真实登录、权限、内容发布、Console/Site 读取和回退；运行承载验证现有共存服务、CPU/内存/磁盘余量、数据库连接、缓存、日志、备份和重启恢复。测试前冻结预计员工同时操作数、公开读取负载、延迟/错误阈值及撤回传播时限，记录实测值和停止条件；没有负载目标或实际测试只能记录“待核实”，不能认定机器够用。容量测试使用隔离数据和合成请求，不以真实付费生成充当后台压测。核对继续归入 CK-B01/B08、CK-R04–07，不新增编号。

首批菜单与操作归属

首批只开放已接通真实服务且当前员工有权使用的菜单。工作区登记不等于可用入口；分组名称是目标信息架构，旧商业路径保留兼容。

员工能力按动作分配：内容编辑可保存草稿；源审核人员决定作品是否可公开；目标发布人员只能向获授权平台发布；商业管理员维护客户和价格；授权管理员分配权限。同一员工可以兼任，角色名称不直接替代接口能力校验，也不代表已安排团队岗位。

权限分工与最小验证身份

以下能力分工保留为后续设计参考；员工配置及专门岗位矩阵目前暂缓，不作为首期门槛。现有接口鉴权继续生效。这不是新增一套硬编码角色，也不预先指定团队成员。默认不继承其他列权限；兼任须显式授权。

源公开资格是独立管理动作，最终授权设计须能限制普通内容编辑直接批准敏感来源。现有接口若把保存与公开资格放在一起，须在当前平台开放源审核动作前拆分语义或保留对应服务端能力检查；不以表单复选框代替审核分权。Studio 作品仍由 Studio 审核，目标发布人仅能引用获准版本。

平台交付记录

统一采用上方平台顺序，不再维护第二套执行队列。每次交付只报告：当前平台、用户能完成的动作、实际访问入口、必要验证结果、未完成项及下一平台。

代码实现、可运行本地交付、目标环境部署分别记录，不能相互替代。记录的验收项须能对应原 AF/CK；同一变更的验证通过后即推进，不因累计测试数量或材料数量增加而声称交付进展。低风险文案/排序修改通过实际预览核对，涉及鉴权、计价、状态变化及迁移才运行对应必要检查。

跨仓职责与接口交付

新增 API 至少覆盖内容列表/详情、草稿保存及并发校验、模型关联验证、预览、发布/撤回/回退、操作结果查询、目标发布状态、匿名已发布投影、Site 栏目和新闻选编。确切方法、路径、DTO 与错误码由 B0 在 Contracts 和责任仓冻结，不在本计划虚构已存在端点。原商业接口不因内容改造改变含义；权限与公开投影由服务端验证。

内容与发布的最小数据约束

首批提供手动发布、撤回与版本回退；内容到期若启用，必须保证读取时不再展示过期版本。跨平台操作不承诺分布式原子事务：逐目标记录结果，可识别部分成功并对未完成目标重试。预览受授权；公开端只读已发布投影，不能依赖普通客户 BFF 会话来给匿名访客读取私有接口。

公开站点可使用有效快照提升可用性，但撤回、源私有化和到期规则优先。B0 明确缓存失效、版本查询、撤回标记与最大传播时间；B2/B3 通过实际故障测试验证。Site 的构建快照与浏览器读取必须采用一致版本策略，回退不能重新暴露已被撤回的源内容。

Studio 作品进入 Site 的依赖工作包

这条链路属于 AF-S04 的 B3 依赖，不必等待 B4 全部管理界面迁移。当前栏目契约和 Admin 选编代码已区分 static_public 与 studio_public，Studio 固定版本来源、引用保存及跨端失效已有局部联验证据。以下仍是整条链路的交付要求；按 progress 区分已有证据与未验范围，不能把局部实现当成整项验收，也不重复新建相同接口。

在第 6 步通过前，可继续管理经核对的静态公开素材，但不将其验收替代 Studio 跨平台引用。发布后的源资格检查与目标展示处置仍是持续责任；不能承诺收回用户已下载的媒体字节，也不能据此省略前台失效清理。

静态内容导入与旧功能切换

先盘点 Console 的 explore-catalog.ts、higgs-reference.json、精选 ID 和说明文案，以及 Site 的 content.js、动态快照和相关内联文案。B0 记录条数、稳定 ID、引用、来源和当前发布状态；B2/B3 导入经核对的内容，保留 reference 来源说明，不导入为 OceanWay 售价。

首批内容迁移必须逐字段、逐交互核对；结构化字段已保存不代表旧前台体验已迁移。以下项目归入原有 AF/CK，不新增一套任务：

每类内容执行：dry-run 差异 → 可重复导入 → 编辑回读 → 预览 → 小范围发布 → 两端版本核对 → 切换读取 → 退出对应源码写入。新闻、协议示例和主题样式分别处理：新闻保留来源与人工规则；可执行协议生成仍走代码验证；外观不要求全部后台化。

每个 Studio 模块登记旧入口、新入口、来源/目标写入方、切换时间、数据迁移与回退步骤。可以暂时在两个界面访问同一授权服务，但不能形成两个服务各自写同一业务事实；新入口验收后按模块停写或跳转旧入口，回退也必须保持单一写入方。旧数据库不直接覆盖新产生的数据。

尚需在执行节点冻结的事项

本计划已给出默认实施顺序与前端承载方式，以下为具体实施输入，不要求暂停本次文档交付。各项由开发负责人组织设计与证据核对，涉及实际岗位、商业政策或生产地址时再使用真实业务输入。

首批验收与交接

先通过完整核对清单中的基线和授权项，再以一张模型卡跑通编辑、关联、两端预览/发布、本人价格读取、更新、撤回、回退；随后覆盖 Site 栏目、原商业回归和故障场景。每项证据关联实际版本和环境。

首批交付必须区分：文档明确、代码实现、真实接口接通、数据导入、旧入口切换、运行验收和部署。已存在的测试通过记录不能替代本次新增工作区及发布链路的验证。初始审视发现的 Console 价格路由缺口和错误状态误判已纳入 B2，已有局部修复证据；上线前仍以当前真实路由回归，不能只单测旧组件或沿用历史结果。

发布包包含启用的 AF 清单、对应 CK 结果、契约/应用版本、数据迁移与回退脚本、环境配置、未开放功能和维护手册。生产发布不由本计划编写完成自动触发；本轮交付仅为可执行的改造计划与清单。