Operations platform

OCTest → OCTest_Ops 迁移计划

先把现在散落在 OCTest 内容站里的内部 ops/admin 页面盘清，再给出明确迁移顺序，让 OCTest 继续聚焦 public content site，OCTest_Ops 成为真正的内部运维控制台。

查看当前看板返回概览
Issue #1 deliverable

迁移范围先收口到 5 个 ops-facing surfaces

这次先不盲目复制整个 OCTest 前端，而是把最明确属于 internal operations 的页面单独列出来，配上 supporting modules 和迁移阶段。

这样后面每个 follow-up issue 都能围绕一个清晰页面簇推进，不会继续把 OCTest 当作临时 ops 容器。

Phase 1 inventory

候选迁移页面与模块映射

先把页面、目标归属、支撑模块和优先级说清楚。

当前 OCTest 路由Ops 目标归属阶段优先级现状判断支撑模块
/operationsOCTest_Ops dashboard + source-health/jobs pagesPhase 2P0已有 source health 基础，适合先迁source-health adapter, dashboard view model, ops shell
/review-queueOCTest_Ops review workflow pagePhase 2P0需在 Ops 端补内容审核队列 UIcontent-review adapter, audit logging, ACL
/releasesOCTest_Ops release visibility pagePhase 2P1适合接在 review queue 之后迁releases adapter, release batch tables
/sourcesOCTest_Ops source governance pagePhase 2P0与 source health 同域，建议并入同一导航簇source registry adapter, source health detail tables
/blog/[slug]/provenanceOCTest_Ops provenance inspectorPhase 2P1文章页保留轻量 reader-facing provenance，深挖工具迁入 Opsprovenance adapter, replay trace, source article lookup

Migration principles

迁移原则

  • • 先在 OCTest_Ops 复建可用页面，再收缩 OCTest 内部入口，不反着做。
  • • OCTest 保留面向读者的轻量体验，内部排障、观测、审核和 release 工具统一落到 Ops。
  • • 迁移时优先搬 data adapters 与页面壳层，不把内容站的视觉和路由习惯原样复制过来。
  • • 每迁完一个面板，都要明确 OCTest 侧是删除、降级还是仅保留跳转。

Cut-over rule

OCTest 侧保留边界

保留在 OCTest 的应该是 reader-facing experience，例如文章内容页和轻量 provenance 信号。

迁入 OCTest_Ops 的应该是 internal observability、review、release、governance 和 provenance 深挖工具。

这条边界写清楚后，后面新需求就不会继续默认落回 OCTest。

Follow-up queue

建议后续拆分 issue

让 parent migration issue 变成可连续推进的实施队列。

ID建议实施项优先级
ops-01把 `/operations` 明确拆成 `/dashboard/source-health` + `/dashboard/jobs` 的落地页面Done
ops-02补 review queue 页面，并接 audit loggingDone
ops-03补 sources 页面，承接 source governance / registry 视图Done
ops-04补 release batches 页面Done
ops-05补 provenance inspector 页面，并让 OCTest 文章页只保留轻量入口Done
ops-06盘 internal data adapters，明确 move / duplicate / keep shared / redesign dispositionP0