一页结论
Oria 目前的状态不是“没有项目管理”，也不是“文档不够多”。更准确的判断是：团队已经具备很强的需求生产能力和研发执行吞吐，但管理系统还没有形成足够强的上下文保真机制。PM repo、Linear、GitLab 都在运转，却没有被一个稳定的身份索引、状态账本、决策账本和发布账本串起来。
这会导致一个隐蔽但昂贵的问题：每个局部看起来都合理，PRD 很细、Linear 有状态、MR 合并很快、代码也在发版；但跨过一个节点后，原始目标、范围取舍、冻结后变更、验收口径、上线版本和遗留项就开始丢失。项目越快，漂移越快。
docs/ 下文件数，文档资产很丰富release.md / systems/*/latest.md 记录ORI-* 能在 PM repo 直接反查到ORI-* 但 PM repo 反查不到，另一类更严重，是大变更连 ORI-*、Linear URL、PM 文档链接都没有。结果是 PM 看板、PRD、Linear issue、MR、tag、线上版本可能各自正确，但不能合成一个可审计的产品事实。
数据源与可信度
| 来源 | 已采集内容 | 限制 | 可信判断 |
|---|---|---|---|
| PM Git repo | /Users/admin/workspace/oria/pm 文件结构、文档内容、meta、git log 180 天 | 能证明文档架构与沉淀情况；不能单独证明 Linear 当前状态和线上真实版本 | 高 |
| Linear | 通过 Linear 插件读取 Oriaxyz team 的 projects、issues、labels、cycles、statuses，并与 PM Git / code Git 的 ORI-* 交叉比对 | 状态切片以插件返回的当前快照为准；长描述有截断，但足够判断容器、状态和链接模式 | 高 |
| Git code repo | 本地 34 个代码 repo 当前 checkout 的 git history、tag、Linear ID；另以全 refs 口径扫描 31 个唯一 code repo 的 4,409 个 commit；GitLab group oria 807 个 MR | 本地 checkout 与远端 refs 口径不同，报告中分别标注；GitLab MR 窗口按 created_at 覆盖 2026-04-10 至 2026-07-09 | 高 |
更新说明：本版纳入 Linear 直接数据、全量 commit/MR 反推和 PM repo 架构审计，将重点从“工具是否接入”调整为“跨工具上下文是否保真”。
应然模型：不是三套工具，而是一条事实链
PM 仓库的制度文档已经定义了清晰分工：GitLab 是正式产品文档主库，Linear 是需求/缺陷/迭代/优先级协作平台，飞书 Wiki 是跨角色共享入口。需求生命周期从 idea、triage、backlog、prd_draft、prd_review、prd_frozen、in_delivery 到 released/cancelled/archived，并要求生命周期变化记录到 meta.yaml.status_history。
这套设计方向是对的，但还少了一层“操作系统”能力：每个需求必须有稳定身份，每次状态变化必须有原因，每次范围变化必须有变更记录，每个 MR 必须回指需求和决策，每次上线必须落到系统版本账本。否则 Git、Linear、GitLab 只是三个各自正确的局部系统，不会自动生成一个可信的整体事实。
| 账本 | 应该回答的问题 | 当前主要断点 |
|---|---|---|
| 身份账本 | 这个需求在 PM repo、Linear、MR、release 中分别是谁？ | ORI-* 没有成为 PM repo 与代码提交的共同主索引 |
| 状态账本 | 现在处于哪个阶段，谁负责，为什么进入下一阶段？ | stage 与 lifecycle 并存，status_history 覆盖不足 |
| 决策账本 | 评审时决定了什么，谁同意了什么，哪些不做？ | meetings/ 与 changes/ 没有成为常规产物 |
| 发布账本 | 实际上线了什么版本，包含哪些 issue/MR，遗留和回滚是什么？ | 代码 tag 存在，但 PM repo 没有系统 latest/release 回写 |
上下文漂移地图
下面不是流程图，而是上下文最容易失真的位置。Oria 现在的问题不是某一个节点坏掉，而是每个节点都只把自己需要的上下文带到下一站，没有强制把“为什么、改了什么、验收了什么、上线了什么”回写成共同事实。
| 节点 | 当前证据 | 漂移方式 | 后果 |
|---|---|---|---|
| Portfolio / Roadmap | Linear projects 已覆盖多语言、流程系统、风控、内控内审、Onchain、AI 测试等；ROADMAP.md 仍停留在早期 Web/App 叙事 | 项目容器在 Linear 更新，战略叙事和取舍理由没有同步更新 | 团队知道“现在在做什么”，但不稳定知道“为什么现在做、哪些被推迟、代价是什么” |
| 需求入口 | Linear Triage 当前只看到 1 个 issue；同时存在 trashed/canceled legacy project 和项目级 issue | 想法可能直接变成 project/backlog，或者被取消后只留下状态，没有保留充分的输入、拒绝理由和复用边界 | 后续新需求容易重复讨论，历史否决无法成为组织记忆 |
| PRD / 方案 | PM repo 有 246 个 Markdown、158 个 HTML，验收 出现很多；但 domain 需求 meetings/changes/release.md 为 0 | 方案正文很细，但评审结论、冻结后变更、验收结果没有变成独立对象 | PRD 会被持续改写，读者难以判断“原方案、评审后方案、上线方案”的差异 |
| 拆票 / Cycle | Cycle 7 issue count 从 26 增至 38，scope 从 33 增至 45；Week Plan 被建成 issue | 计划本身被对象化了，但 scope 变化的业务原因、代价和替换关系没有自动回写 | 周期完成率可以看见，周期承诺如何变化却不够透明 |
| 开发交接 | 代码 90 天 commit subject 展开后出现 63 个不同 ORI-*，PM docs 候选文件只能反查到 2 个 | 研发执行链路围绕 Linear ID 运转，产品知识链路没有使用同一主键 | 从代码能找到任务号，但不一定能回到完整需求、变更和验收口径 |
| MR / Review | 2026-04-10 至 2026-07-09 抓取 807 个 GitLab MR：782 merged、25 closed；349 个有任一锚点，458 个无锚；459 个大变更 MR 中 198 个无锚 | MR 的身份在 branch/title/description/notes/commit 中都不稳定；不少大 MR 描述很细，但缺需求来源和验收口径 | 执行效率高，但需求偏差、验收口径和跨服务影响不容易在 review 节点被拦住 |
| 质量 / 验收 | GitLab group 项目层面 0 个要求 pipeline 成功才可合并，0 个要求 discussions resolved；PM repo 中测试报告记录极少 | 质量信息停在个人自测、CI marker 或局部对话，没有成为项目状态的一部分 | “可以合并”和“可以上线”之间缺少明确门槛 |
| Release / 复盘 | 代码仓有 110 个 tag、15 个仓有 release-like tag；PM repo 真实 release.md、docs/systems/*/latest.md 为 0 | 技术版本存在，产品版本事实没有接住；Linear Released 也没有自动生成 release ledger | 上线后无法稳定回答版本范围、遗留项、回滚口径和用户可见变化 |
从代码倒推的漂移
这部分按用户真实执行链路反向看：不是从 PM repo 问“哪些需求在做”，而是从代码 commit 和 GitLab MR 倒推管理系统是否能承接真实交付。反向追踪分两层：第一层看“带 ORI-* 的代码能否回到 PM/Linear”；第二层看“没有任何 ORI-*、Linear URL、PM 文档链接的大变更有多少”。后一层是本次补充后更关键的发现。
原先只追 ORI-* 会漏掉最危险的一类事实：代码已经发生了重大产品/系统变化，但它没有进入任何可追溯身份。也就是说，不只是“有 Linear ID 但 PM 断链”，还有“大变更绕过 Linear/PM 身份系统”。
ORI-* 的代码事项能在 PM docs 反查两类漂移必须分开看
| 漂移类型 | 量化证据 | 含义 |
|---|---|---|
| 有 ORI，但 PM 断链 | 代码 90 天 commit subject 展开出 63 个不同 ORI-*，PM docs 候选文件只命中 2 个；329 / 335 次 commit mention 无法从 PM 反查 | Linear 记录和研发执行存在，但产品上下文、变更和发布事实没有回到 PM repo |
| 无 ORI / 无 Linear / 无 PM 锚点 | 全 refs 4,409 commits 中只有 951 个带任一管理锚点；995 个大变更中 782 个无锚 | 这类变化甚至不能从管理系统知道“应该去哪里查”，只能事后从 git log 和 diff 反推 |
| MR 层无锚 | 807 个 GitLab MR 中 458 个无锚；459 个大变更 MR 中 198 个无锚 | review 节点没有稳定承接需求来源、验收口径和发布影响 |
| 反向追踪指标 | 结果 | 解释 |
|---|---|---|
| PM docs 候选文件命中 | 2 / 63 | 只有 ORI-178、ORI-291 能从 PM docs 候选文件中反查到；其余 61 个没有 ORI 锚点 |
| 受影响 commit mention | 329 / 335 | 绝大多数带任务号的代码提交无法用任务号回到 PM 上下文 |
| PM release/latest 命中 | 0 | 已交付事项无法通过 PM repo 找到上线范围、遗留项和系统最新状态 |
| 高频样本 Linear 状态 | 前 10 个高频 ORI 精确查询均存在，且均为 Released | Linear 不是主要缺失点；缺的是 Linear Released 与 PM 产品上下文、发布账本之间的回写 |
高频代码 ORI 反查样本
| ORI | 代码信号 | Linear 状态样本 | PM repo 反查结果 | 管理含义 |
|---|---|---|---|---|
ORI-293 | 28 次 commit mention，集中在 core-service，Portfolio PnL API | Released | PM Markdown / meta 未命中 | 已发布后端能力在 PM repo 无产品版本落点 |
ORI-116 | 20 次，跨 adm-bff / admin-web，运营后台邮箱登录 | Released，Linear 描述含 GitLab PRD 链接 | 代码 ID 在 PM repo 未命中 | Linear 有文档链接，但 PM repo 无法用 ORI 反查该需求 |
ORI-265 | 20 次，跨 oria-web / user-service / bff，PIN/Passkey | Released | 未命中 | 跨端/跨服务安全体验变更没有进入 PM 状态账本 |
ORI-84 | 17 次，跨 5 个 repo，H5/Web 首页重塑 | Released | 未命中 | 高影响前台体验变更缺少统一发布说明 |
ORI-110 | 16 次，跨 bff / kyc-service-go / oria-web / gateway-go | Released | 未命中 | KYC 这类合规链路更需要决策/验收留痕 |
ORI-111 | 16 次，与 ORI-110 共同出现在 KYC shorthand commit 中 | Released | 未命中 | 成对需求在代码中联动交付，但 PM repo 不能按任一 ID 反查上下文 |
ORI-295 | 10 次，跨 7 个 repo，repo 上下文治理 | Released | 未命中 | 连“上下文治理”本身也没有回到 PM repo，说明问题是系统性的 |
无锚大变更：最近 UI/UX 调整不是个案
本轮补充的关键修正是：不能只扫 UI/UX 关键词，也不能只扫 ORI-*。全量 commit/MR 分析按文件路径、扩展名、变更规模、跨模块范围和 churn 识别产品/系统影响。结果显示，无锚大变更不是偶发，而是当前交付系统的默认风险。
最近 UI/UX 调整的精确证据
| 对象 | 事实 | 锚点情况 | 管理含义 |
|---|---|---|---|
oria-web!181 | 2026-07-08 merged，标题 feat(web): mobile UI rework across account, grow, holdings & funding；source branch fix/mobile-style-tweaks，target dev；79 files，+3,766 / -1,780 | MR title、description、source branch、commit messages 均无 ORI-*、Linear URL、PM docs 链接、closing refs 或 release/decision doc | review 能看到实现范围，但无法直接看到需求来源、设计决策、验收口径、上线说明 |
oria-web commit 1f769006 | 同一变更进入 origin/dev；覆盖 account/KYC/security、signup、bills、deposit、funding、grow、holdings、overview、withdraw、mobile nav、BottomSheet、ResponsiveDialog、MiddleTruncate 等 | commit body 为空，无任何管理锚点 | 如果不从 git diff 反查，PM/Linear 无法知道这些流程在同一次移动端 UI 调整中被一起改过 |
ORI-299 | Linear 中存在 oria UI/UX 整体重构 epic，2026-06-26 创建，2026-07-07 Released；描述覆盖 21 页，子票 ORI-300 至 ORI-304、ORI-307 多数 Released | ORI-299 无 documents / attachments；ORI-299/300/301/302/303/304/307 在 PM Markdown/YAML 中无命中；oria-web!181 和 1f769006 没有反链到 ORI-299 | Linear 有高层薄记录，但 PM repo 没有需求对象，代码/MR 也没有稳定回链；这不是“完全没有 Linear”，而是三套系统没有闭环 |
不是 UI 专属问题
| 证据 | 类型 | 规模 | 为什么应进入管理系统 |
|---|---|---|---|
oria-web!181 / 1f769006 | 前端 UI/体验 | 79 files / 5,546 churn | 多条核心用户流程的移动端交互和组件抽象重做 |
oria-web!128 | 前端产品体验 | 87 files / 7,177 churn | H5 styles、amount precision、page titles，涉及 wallet、transactions、grow、holdings |
admin-web!36 | 后台 UI/操作台 | 67 files / 14,992 churn | 删除 demo/verify，涉及 KYC、login、withdraw、yield 操作面 |
yield-service-go!22 | 后端业务规则 | 101 files / 12,779 churn | fundraising、subscribe、deploy、recall、settle 生命周期调整，直接影响理财产品交付事实 |
oria_kmp commit ee2beb16 | 移动端 | 909 files / 107,915 churn | 界面文本国际化与钱包功能同时进入，风险远超普通 fix |
tokenized-web!11 | 前端/钱包集成 | 131 files / 5,898 churn | Privy embedded wallet 与 apps/packages/deploy/docs 多模块变更，需要发布与验收口径 |
ORI-299 这个 epic，但 PM repo 没有相应产品事实，关键 MR/commit 也没有回链。更广泛地看，前端、后端、移动端、agent/tools 都存在无锚大变更。问题不是“漏了一个 UI ticket”，而是代码事实没有被强制纳入需求、变更、验收和发布账本。
PM 仓库现状
meta.yaml 缺少 lifecycle架构合理性判断
PM repo 的目标架构是合理的：它不应该简单按 Linear 状态搬目录，而应该按业务领域和业务动作组织需求，用 meta.yaml.lifecycle 表达状态；需求目录回答“为什么做、做什么、范围和变更是什么”，docs/systems/{system} 回答“当前线上是什么、哪个版本包含哪些需求”。这套设计比传统 todo/doing/done 文档目录更适合长期维护，也更适合金融产品的审计和回溯。
实际问题不在“架构方向错”，而在“架构承诺没有被执行成约束”。现在 PM repo 同时扮演长期知识库、需求规格库、项目状态镜像、发布事实账本、原型资产库和研究资料库，但没有把 canonical / generated / archive / reference 分清楚。读者看到的是大量文档，而不是一个能回答“当前事实是什么”的产品管理系统。
| 架构层 | 设计目标 | 实际状态 | 风险 |
|---|---|---|---|
| 业务域需求层 | docs/domains/{domain}/{action}/{requirement} 固定归属，状态写 meta | 14 个 domain 需求已创建，但很多只有 brief/prd/prototype，缺少 meetings/changes/release 子对象 | 需求能被写出来，但进入交付后的决策和变更没有对象化 |
| 旧协作层 | 旧 triage/backlog/spec 交付完成前不迁移，完成后拉 last version 快照 | spec 261 个文件、backlog 102 个、triage 25 个，仍是主要资产区；旧 spec/README.md 仍保留“进入 Todo 后从 backlog 移到 spec”的口径 | 旧目录位置仍在表达状态，新旧生命周期口径并存 |
| 系统状态层 | docs/systems/{system}/latest.md 与 releases 维护线上事实 | docs/systems 只有 README，真实 latest/release 记录为 0 | PM repo 无法回答“线上现在是什么版本、包含哪些需求” |
| 元数据层 | meta 作为 Linear、系统、生命周期、发布归属的索引 | 57 个 meta 中只有 15 个 lifecycle，13 个 status_history，13 个 linear，2 个 linear_id；13 个有 target_release 字段但非空值为 0；system 命名存在 app/web/admin-console、app-client/web-client、web-app/admin 等多套口径 | 仓库无法被稳定机器读取，也无法自动校验漂移 |
| 生成/参考资料层 | 研究、原型、生成报告为辅助材料，不替代当前事实 | HTML 原型、研究报告、superpowers spec、正式 PRD 混在 docs 主树 | 新成员和 agent 难以判断哪个文件是权威正文，哪个只是过程材料 |
文档资产分布
仓库经历过一次从旧目录 triage/backlog/spec 到新目录 domains 的治理迁移。迁移方向清楚，但新旧并存造成了两套口径：旧目录以位置表达阶段，新目录以 meta.yaml.lifecycle 表达阶段。实际执行中，两套都没有完全闭环。
STATUS.md 和旧目录 README 仍在延续路径即状态的管理方式，而新架构要求路径表达业务归属、状态写入 meta。两者同时存在时，团队很容易在“我要找当前需求状态”与“我要找业务域知识”之间来回切换，agent 也很难判断哪个文件是事实源、哪个只是历史视图。
新 domains 目录采用情况
| 指标 | 结果 | 含义 |
|---|---|---|
带 meta.yaml 的需求目录 | 14 | 新目录体系已经开始使用 |
含 brief.md | 12 / 14 | 需求入口材料基本具备 |
含 prd.md | 11 / 14 | PRD 生产能力较强 |
含 pages.md | 2 / 14 | 页面/状态清单没有成为稳定中间层 |
含 meetings/changes/release.md | 0 / 14 | 评审、变更、发布闭环未沉淀 |
PM 仓库暴露的管理问题
- 产物偏前置：brief/prd/prototype 很多，release/latest/change/meeting 很少，说明系统擅长把想法推进到方案，但不擅长记录方案进入交付后的真实变化。
- 状态字段混乱：制度要求
lifecycle，但 57 个 meta 中有 42 个缺少 lifecycle，39 个仍使用旧stage，44 个缺少status_history；13 个 meta 有target_release字段但非空值为 0。 - Linear 链接不可用：15 个 meta 有
linear或linear_id字段，但不少只是 project 名、空 issue 列表或TBD；只有 4 个 meta 文件直接出现ORI-*。PM Markdown/YAML 全量也只有 26 个不同ORI-*，无法支撑“Git 文档和 Linear 状态互为索引”。 - 路线图滞后：
ROADMAP.md仍大量停留在 2026-04/05 的 App/Web 版本规划，而 GitLab 代码侧 2026-07 仍在高频交付 KYC、提现、后台、钱包、tokenized 等工作。 - 生成物和人工事实混在一起：原型 HTML、研究报告、superpowers spec、正式 PRD、状态镜像都在
docs/里，但缺少“canonical / generated / archive / reference”的边界。新成员或 agent 进入时，需要靠搜索和经验判断哪些文件代表当前事实。 - 迁移策略有原则但无完成条件：规则说旧目录交付完成后拉 last version 快照，但没有自动识别“已交付但未迁移/未回写 systems”的清单。于是旧目录会长期停留，变成永久兼容层。
- 需求层和系统层没有桥：一个需求可能影响 web、app、bff、core、kyc、notification 等多个系统，但 PM repo 没有稳定记录 requirement → systems → release 的映射。跨服务需求越多，越需要这张桥表。
Linear 链路现状
PM 协作规范把 Linear 定义为需求、缺陷、迭代、优先级的唯一协作平台；直接读取 Linear 后可以确认：Linear 已经是团队真实协作中心之一。它承载项目组合、cycle、issue 状态流、标签和一部分 GitLab 文档链接。问题不在于是否使用 Linear，而在于 Linear 的真实协作状态没有被 PM Git 与 GitLab release 体系稳定接住。
ORI-*ORI-*ORI-*Linear 直接观察
| 维度 | 观察 | 管理含义 |
|---|---|---|
| Projects | 当前可见项目包括「多语言支持」「流程系统」「风控系统」「内控内审合规」「Onchain MVP」「AI 无人测试体系」「运营&客服体系」等；也有多个 trashed / legacy 容器，如早期邀请返佣、数据分析、多端分发等 | Linear 已经承担 portfolio 容器，但存在历史项目、项目级 ticket、执行 issue 混杂，需要定期清理项目层级 |
| 状态模型 | 状态包括 Triage、Backlog、Todo、In Progress、In Review、Done、Released、Canceled、Duplicate | 区分 Done 与 Released 是正确方向；但如果没有 release ledger，Released 会退化为人工标签，而不是可审计事实 |
| 标签体系 | 当前只有 7 个 label：Week Plan、praxis、Infra、Epic、Feature、Improvement、Bug | 类型标签有了，但缺少业务域、系统、风险级别、发布面、客户影响等维度，portfolio 分析主要依赖标题和人工理解 |
| 当前 Cycle | Cycle 8 当前范围为 22 issues / scope 24，周期为 2026-07-07 16:00 UTC 到 2026-07-14 16:00 UTC | 已经有 cycle 节奏，但 PM Git 的 ROADMAP / STATUS 没有同步反映当前 cycle |
| 上一 Cycle | Cycle 7 完成 21 issues / scope 26；issue count 从 26 增到 38，scope 从 33 增到 45 | 有明显 cycle 内扩容，说明 WIP 和临时插单需要被显式管理 |
| 状态切片 | 可见 Triage 仅 1 个（ORI-170）；In Progress 包括 ORI-232 / ORI-231 / ORI-359 / ORI-230 / ORI-335 / ORI-336 / ORI-337；In Review 包括 ORI-318 与多张财务底座票；Backlog 中含 Referral V3.1、KYC 优化、最小充值金额、全站暂停、App 版本管理、风控/流程系统拆分票 | Linear 状态流比 PM Git 更接近当前真实交付面 |
| Released / Canceled | Released 中有 Referral V1、墨西哥信贷资产 V1、H5/Web 首页、KYC、Pilot 标签等；Canceled / Duplicate 中有 Referral V2、风控系统/流程系统早期项目级 issue 等 | Linear 对完成/取消记录较完整，但 PM Git 缺少对应 release note 和 cancellation/change 记录 |
| 计划对象 | Linear 中存在 Cycle 2 到 Cycle 6 的 Week Plan issue | 把周计划对象化是有价值的，但如果周计划和功能/缺陷 issue 混在同一层级，统计时需要明确排除或单独聚合 |
| UI/UX epic | ORI-299「oria UI/UX 整体重构」存在于 Linear，2026-06-26 创建、2026-07-07 Released，描述覆盖 21 页，并拆出 ORI-300 至 ORI-304、ORI-307 等子票 | Linear 有高层拆票能力；但该 epic 无 documents / attachments，PM repo 无对应需求对象，关键 MR/commit 也没有回链到该 epic |
| 观察 | 管理含义 |
|---|---|
代码 commit/MR 中 ORI 很活跃，例如 ORI-318、ORI-359、ORI-295 等 | 研发已经把 Linear 当作工作单号，但 PM 文档没有跟上 issue-to-requirement 映射 |
STATUS.md 声明“真源在 Linear”，但多数表格 Linear 列为空 | 状态索引不能可靠回答“这个需求在 Linear 哪个 issue / project / cycle” |
| Linear issue 描述里有 GitLab 文档链接，例如 ORI-335 直接链接 admin dashboard 的 Brief / PRD / Pages | 从 Linear → PM Git 的单向链接已经开始形成，但 PM Git → Linear 的反向链接仍明显不足 |
| 一些 Linear project 由早期 issue 演进而来，旧 project 被 canceled 或 trashed | 团队在快速寻找正确抽象层，这是正常演化；但需要一个“promotion rule”：什么时候 issue 升级为 project，旧 issue 如何关闭，迁移后的上下文放在哪里 |
代码仓库与交付现状
oria group 项目Commit 活动
本地当前 checkout 口径下，34 个 code repo 90 天合计 2,481 commits，30 天合计 1,360 commits。为了避免只看当前分支漏掉已经进入远端 origin/dev 的变更，本轮又用全 refs 口径扫描 31 个唯一 code repo：2026-04-10 至 2026-07-09 共 4,409 commits，其中 689 个带 ORI-*，951 个带任一管理锚点；995 个大变更里 782 个无锚。
| 分类 | commit 信号 | 无锚风险 |
|---|---|---|
| frontend/UI | 1,274 个相关 commit，354 个大变更 | 271 个 frontend/UI 大变更无锚，占 76.6%；最近 oria-web!181 属于此类 |
| backend/API | 1,795 个相关 commit，覆盖 BFF、core、yield、wallet、KYC 等 | 多个资金、计息、KYC、结算相关大变更没有稳定回写 release/PM 上下文 |
| agent/tools | 1,155 个相关 commit | agent 工具会放大执行吞吐，若无 PM/Linear 锚点，会把组织知识进一步碎片化 |
| mobile/KMP | 69 个相关 commit | oria_kmp 出现 909 files / 107,915 churn 的 UI + 钱包功能无锚大变更 |
MR 活动
GitLab group 近全量窗口抓取 807 个 MR，其中 782 merged、25 closed。349 个 MR 有任一管理锚点，458 个无锚；459 个大变更 MR 中 198 个无锚。锚点类型互有重叠：269 个出现 ORI-*，144 个出现 Linear URL，102 个出现 PM/docs 线索，50 个出现 closing/refs，81 个出现 release/decision doc 线索。说明 GitLab 上下文本身不是空白，但还没有成为强制协议。
| 项目/类型 | MR 数 | 锚点率 / 无锚大变更 | 管理信号 |
|---|---|---|---|
| frontend/UI | 245 | 44.5% / 78 | 用户可见变化最密集，UI/UX、资金页、持仓、Grow、后台操作台都在这里漂移 |
| backend/API | 393 | 47.3% / 84 | BFF、yield、core、wallet、KYC 的规则变化需要更强发布账本 |
| agents/tools | 162 | 30.3% / 36 | 工具链和 agent 迭代快，但进入 PM/Linear 的比例更低 |
oria/oria-web | 180 | 45.0% / 56 | 前端交付高频，是需求变化最敏感端；oria-web!181 是典型无锚大 MR |
oria/bff | 113 | 46.0% / 24 | BFF 承载大量需求集成与规则变更 |
oria/oria-agents | 60 | 1.7% / 18 | AI/agent 能力进入工程体系，但上下文锚点极薄 |
oria/admin-web | 53 | 39.6% / 17 | 后台能力近期在扩张，操作台变更需要验收与权限回归记录 |
oria/yield-service-go | 53 | 35.9% / 17 | 理财核心域仍高活跃，生命周期、计息、结算变更不能只留在 diff |
代码仓库管理信号
- 高吞吐：本地 code repos 当前 checkout 90 天合计 2,481 commits，30 天合计 1,360 commits；全 refs 口径 90 天为 4,409 commits，说明研发执行非常活跃。
- 项目面偏宽：GitLab 有 37 个项目，其中 31 个未归档；本地 34 个 code repo 中 23 个 30 天有活动，portfolio WIP 偏宽。
- 质量门禁弱：多数 repo 有 CI marker，但 GitLab 项目设置层面 0 个要求 pipeline 成功、0 个要求 discussions resolved 才可合并。
- GitLab issue 不是主入口：37 个项目合计 open GitLab issues 只有 9，说明 issue 管理大概率集中在 Linear；这进一步要求 Linear 数据必须可审计。
- 版本技术痕迹存在：本地代码仓合计 110 个 tag，15 个仓有 release-like tag，说明不是完全没有发版纪律；断点在于这些技术版本没有被 PM repo 的系统 latest / release note 接住。
- MR 上下文包不稳定：807 个 MR 中 458 个无锚，459 个大变更 MR 中 198 个无锚。review 人能看到代码变化，却不一定能快速看到需求原文、冻结后变更和验收口径。
问题诊断
P0 缺少跨工具的上下文账本
制度上是 Git 文档、Linear 状态、GitLab 交付三权分立；实际缺少统一 join key 和强制回写点。从代码倒推，最近 90 天有 335 次 commit mention 指向 63 个不同 ORI-*，但其中 61 个无法在 PM docs 候选文件中直接反查，覆盖 329 次 commit mention。进一步扩大到全 refs 4,409 个 code commit 后，只有 951 个带任一管理锚点，995 个大变更里 782 个无锚。研发执行并没有稳定围绕同一身份系统运转，需求、任务、MR、release 之间的上下文需要人脑拼接。
P0 无锚大变更绕过产品管理系统
oria-web!181 / 1f769006 在 2026-07-08 完成移动端 account、grow、holdings、funding、withdraw、KYC/security 等 UI/UX 重构，79 files / 5,546 churn，但 MR 和 commit 均无 ORI-*、Linear URL、PM docs 或 release/decision doc。Linear 中虽有 ORI-299 UI/UX 整体重构 epic，但它没有 documents/attachments，PM Markdown/YAML 也无法命中 ORI-299/300/301/302/303/304/307。这说明问题不是单个 ticket 漏写，而是大变更缺少强制入账机制。
P0 PM 仓库对象边界不清，架构承诺没有落地
PM repo 的新架构设计其实很先进：domain 目录管需求，systems 目录管线上状态，meta 管生命周期，meetings/changes/release 管过程事实。但实际仓库仍是旧路径状态、新 domain 结构、研究资料、原型、生成 spec、历史规划混合存在。读者看到的是大量文档，不是一个清晰的当前事实系统。
P0 发布事实没有成为一等对象
代码仓有 tag，Linear 有 Released 状态，但 PM repo 没有真实 release.md、docs/systems/{system}/latest.md、releases/{version}.md。这意味着“已发布”更多是协作状态，不是可审计事实。对于资金、KYC、风控、账务类产品，缺少上线范围、验收人、遗留项、回滚口径，会直接影响复盘和风险控制。
P1 Cycle 计划在变，但变化成本没有被显式管理
Cycle 7 从 26 issues / scope 33 扩到 38 issues / scope 45，最后完成 21 issues / scope 26。插单和扩容在创业团队里正常，但必须记录“新增了什么、替换了什么、为什么值得、哪些承诺顺延”。否则 cycle 看起来只是完成率问题，本质上的 portfolio trade-off 没有被看见。
P1 Review 节点主要审代码，不稳定审上下文
807 个 MR 中 458 个无锚；459 个大变更 MR 中 198 个无锚。很多 MR 描述能说明实现内容，却不提供需求来源、决策记录、验收口径和发布影响。MR 合并速度很快，说明执行效率高；但如果 MR 模板不要求需求链接、变更说明、测试证据、发布影响，review 很容易只判断代码是否能合并，而不是判断它是否仍符合产品目标。
P1 Portfolio WIP 过宽，且分类维度太薄
31 个未归档 GitLab 项目、23 个近 30 天活跃本地 code repo、多个核心服务同时高频变化。Linear label 只有 Feature / Improvement / Bug / Infra / Epic / praxis / Week Plan，缺少业务域、系统、风险级别、客户影响、发布面等维度。团队能推进很多事，但管理层很难快速看出资源被哪些业务目标占用。
P2 治理规则领先于自动化执行
文档架构、协作规范、需求层级这些规则本身质量不低，甚至已经意识到 systems/latest、changes、status_history 的必要性。真正缺的是 schema check、link check、release check、Linear sync check、MR context check。没有自动化，规则会在高压交付下自然失效。
P2 Agent/AI 提升了吞吐，也放大了上下文债务
Linear 中已有 praxis、AI 无人测试体系、MCP Agent Service、Entity Wiki 等项目，代码侧也有 oria-agents 的高 MR 活动。AI/agent 会让需求拆分、代码生成、MR 处理更快，但也会更依赖结构化上下文。如果 PM repo 和 Linear 没有统一账本，agent 会更频繁地基于局部事实工作。
建议方案
30 天：建立上下文保真协议
- 定义唯一身份规则：每个可交付需求必须有 PM requirement id、Linear issue/project id、owner、systems、lifecycle、status_history；PM repo 禁止新增
stage。 - 冻结新旧双轨：新需求只进入
docs/domains，旧spec/backlog/triage只作为 legacy/reference，不再承载新增需求。 - 建立 PM repo schema/link check：检查
meta.yaml是否有可用 Linear ID、PRD 是否链接 Linear、Released/Canceled 是否有 release/cancellation 记录。 - 更新 MR 模板：必填 Linear issue、PM doc、变更类型、测试证据、发布影响；冻结后需求如果没有
changes/记录，review 需要明确说明。 - 建立无锚大变更拦截规则：MR 超过 20 files、churn 超过 500、或触达
src/app/features/ API / migrations / deploy 时，必须有ORI-*或 PM requirement 链接；UI-only、refactor、cleanup 也不例外。 - 立即回填
ORI-299：在docs/domains/product-platform/ui-ux-rebuild/oria-uiux-v3建需求对象，链接ORI-300至ORI-304、ORI-307、oria-web!181、commit1f769006，补设计范围、验收、遗留和 release 记录。 - 建立最小 release ledger：先从当前线上事实开始，为核心系统补
docs/systems/{system}/latest.md，不追求一次性补完历史。 - 把
docs/planning/STATUS.md从人工表改成生成物，来源为 Linear + PM meta + GitLab MR/release。
60 天：重整 PM 仓库的信息架构
- 明确四类区域：canonical requirements、system state、generated reports、archive/reference。让读者一眼知道哪些文件代表当前事实。
- 为 HTML / prototype / shipping artifacts 增加来源声明：它是 canonical source、generated view、prototype，还是 archive；禁止多个文件同时自称权威源。
- 把旧
triage/backlog/spec的仍活跃需求迁移或挂索引；不活跃内容进入 archive，并保留旧链接。 - 定义 issue → project promotion rule：什么条件下 Linear issue 升级为 project，旧 issue 如何关闭，PM repo 如何记录迁移。
- 统一
systems枚举和命名：例如 app、web、h5、admin-console、bff、core-service、kyc-service、notification-service，作为 meta 和 release note 的共同词表。 - 扩充 Linear label/taxonomy：domain、system、risk、customer-impact、release-surface、process-artifact，避免所有分析都靠标题识别。
- 建立每周 portfolio review 生成报告：新增/关闭需求、cycle scope change、WIP、blocked、延期、已上线未回写、无 owner、无 Linear 链接。
90 天：把管理质量变成自动门禁
- 把 roadmap 改成 Now / Next / Later / Parked，并与 Linear project/cycle 自动对齐。
- 为核心 repo 开启分层合并门禁：pipeline 成功、必要讨论解决、必要 review role 通过；先覆盖
oria-web、bff、core-service、wallet-service-go、kyc-service-go。 - 把
Released状态和 Git tag / deployment / PM release note 绑定：没有 release ledger 的 issue 不能关闭为 Released。 - 把“无锚大变更”纳入合并门禁和周报：每周列出无
ORI-*的大 MR、大 commit、dev→main rollup，让它们要么补票，要么明确标记为纯技术维护。 - 梳理 repo portfolio：明确 active / maintenance / archived / experiment 四类，减少团队默认关注面。
- 建立项目健康 dashboard：cycle burn、scope change、issue aging、MR lead time、release frequency、defect reopen、需求变更率、无 PRD/无 release 的交付项。
- 为 agent 工作建立上下文入口：每个 repo 或系统都有可读的 service/domain index，agent 开始任务时能找到需求、系统、发布和约束。
证据索引
| 证据 | 位置 |
|---|---|
| PM 仓库核心规则 | /Users/admin/workspace/oria/pm/README.md、/Users/admin/workspace/oria/pm/docs/foundation/document-architecture.md |
| 协作流程与 Linear 字段规则 | /Users/admin/workspace/oria/pm/docs/foundation/collaboration-guide.md |
| PM 新旧架构双轨证据 | /Users/admin/workspace/oria/pm/docs/spec/README.md、/Users/admin/workspace/oria/pm/docs/planning/STATUS.md、/Users/admin/workspace/oria/pm/docs/domains/**/meta.yaml |
| 路线图与状态镜像 | /Users/admin/workspace/oria/pm/docs/planning/ROADMAP.md、/Users/admin/workspace/oria/pm/docs/planning/STATUS.md |
| 新 domains 需求样本 | /Users/admin/workspace/oria/pm/docs/domains/**/meta.yaml |
| Linear 项目、issue、label、cycle 数据 | Codex Linear plugin：list_projects、list_issues、list_issue_labels、list_cycles、search、fetch issue:ORI-299 |
| GitLab 项目与 MR 元数据 | glab api groups/oria/projects、glab api groups/oria/merge_requests；MR subagent 按 created_at 分页抓取 807 个 MR，并补 commits、changes、notes |
| 代码到 PM 的 ORI 反向追踪 | 34 个非 PM git repo 当前 checkout 的 90 天 git log --format=%H%x09%cI%x09%s，匹配并展开 ORI-* 后反查 pm/docs |
| 全量 commit 无锚扫描 | 31 个唯一 code repo 的全 refs git log，窗口 2026-04-10 至 2026-07-09；按路径、扩展名、files、churn、子系统分类识别大变更 |
| 最近 UI/UX 大变更核验 | /Users/admin/workspace/oria/oria-web commit 1f769006、GitLab oria/oria-web!181、Linear ORI-299、PM repo 精确搜索 ORI-299/300/301/302/303/304/307 |
| 本地代码 repo 统计 | /Users/admin/workspace/oria/*/.git，排除 pm、docs、本地 worktree / jam 临时目录 |