LightVela Nightly Insight

CloudAgent / Hermes 底座在继续变厚，
但对外产品叙事和正式闭环还没同速收敛。

本次看板基于 2026-06-21 晚间对 git.woa.com/wisp/mono2 的最新远端抓取， 以 origin/master@9ca3d0bb、origin/gitops@ba99a55d 和全部远端分支为事实基线。 本地 /Users/junweicao/LightVela/workbuddy/mono2 只作为 fetch 缓存，不把脏工作区当作真相。

抓取时间 2026-06-21 CST 远端 refs 已 fetch --prune master / gitops / branches / Wiki 文档联合评估 Cloudflare Pages 单页发布目标
66
总体评分 / 100

最近两天的远端主线更像“把云端 Agent 平台做稳”，不是“把外部产品故事讲新”。 如果只看底座，这轮并不弱；如果看正式付费闭环、公开内容 freshness、场景差异化，仍然偏早。

今晚主结论

  • 本轮不属于“没有 fresh cloud-Agent 证据”。session-event recovery、Hermes import、worker actions、workspace recovery 都在继续向主干和 GitOps 推进。
  • 产品基础设施并非空白。前端已经具备套餐、订阅、pass 新购/续费/销毁、微信支付中转、实名、影子账号绑定等路径，但最近新增证据主要仍停在测试环境、runtime flag 和环境发布层。
  • 搜索发现机制已从“缺失”升级到“可用”，但 changelog、套餐话术、公开 claim 没有同步 6 月 18 日之后的主干变化，外部认知会落后于内部代码。
master 头部
6/21

9ca3d0bb 合入产品页 chrome fallback；同一波次还包含账号页 ID 恢复、共享营销外壳、Hermes import 非交互化。

gitops 头部
6/20

ba99a55d 已把 shanghai-workers 的 workers-hermes-importer 推到 GitOps，同时推动北京测试与生产 service-gateway secrets。

远端项目分支
729

已排除 origin/HEAD、master、gitops 和 promote/release 自动分支。

>14 天分支
537

说明分支库存已明显进入需要治理的区间，但它只是风险信号，不直接证明个人或流程失职。

近 7 天活跃分支
63

活跃探索仍在继续，说明项目没有停，但新鲜推进高度集中在少数作者和基础设施主线。

源码 / 发布 / 环境分层

这次刻意把 master、gitops、测试环境和正式生产拆开看，避免把“代码已合”误判成“已上线”。

origin/master：最新源码信号

源码层继续推进
  • !1734 / 9ca3d0bb 把 /agents、/account 的 Suspense fallback 改成产品 chrome，解决硬刷新时营销导航闪烁。
  • !1731 / 15624103 抽出共享 ProductHeaderShell/ProductFooter，把 landing、account、settings 收到同一产品壳层。
  • !1723 / 243548df 恢复 service-gateway 的 COS credentials，直接指向 Hermes import 上传 URL 所需的生产级密钥路径。
  • !1708 / ddaca1f5 把 worker-action 的 not_found 归一成稳定空状态，减少诊断中心和恢复中心的误报。
  • !1703 / 31b4387a 只动用户提示，不改发送链路，补足微信新绑定场景下自动任务 test-send 的恢复指引。

origin/gitops：交付与环境信号

交付层仍以基础设施为主
  • !1725 / b768f176 已把 service-gateway 的 COS credentials 推到 shprod / sgprod GitOps，说明 master 合入后还能继续走正式环境。
  • !1724 / eee779f4、!1722 / 10944a27 把同一能力先送到 beijing-sandbox 验证。
  • !1727 / ba99a55d 在 shanghai-workers 新增并 pin 住 workers-hermes-importer，Hermes 导入已经开始成为可交付工作负载。
  • 当前可见的 GitOps 新增几乎都围绕导入、恢复、worker actions、service-gateway env reload，不是营销页或正式商业化外显功能。
环境区分
beijing-sandbox 仍是大量计费、service-gateway、vibebase 和身份链路的主要试验场； shprod / sgprod 这轮可确认的正式动作主要是 service-gateway secrets 续接； 公开前台产品页虽有源码更新，但看不到同级别的“正式生产功能闭环已收口”证据。
master ≠ 上线
仓库根 AGENTS.md 已明确：正式发布真源是 gitops，而不是 master。 所以这次评分里，凡是只在 master 看见、没在 gitops 看见的信号，都按“已实现但未证明正式收敛”处理。
当前最大错觉风险
这轮很容易被“前端壳层统一 + GitOps 有动作”误导成整体产品闭环已经成熟。实际上最新远端证据更像是平台稳定性、恢复能力和环境 wiring 在补完，而不是外部产品体验已整体翻新。

四大目标评分

评分只是抓重点的工具，真正要盯的是“新鲜证据在哪、缺口在哪”。

1. 产品能力迭代

72 / 100
  • 有 fresh cloud-Agent 证据，不应标成“无迭代”。6bb3350a 明确修复 ChannelGateway session-event recovery，避免旧 run 重放和 runtime ownership 误判。
  • 243548df、ba99a55d 连起来看，Hermes import 已经从“内部恢复动作”走向“需要上传 URL + worker workload + GitOps pin”的平台能力。
  • 前端主干已具备套餐、订阅、pass 新购/续费/销毁、微信支付中转、实名、影子账号绑定入口；2a597c07 把付费前端路径合到 master，但默认仍受 runtime flag 限制。
  • 73182f06 把 shadow BasicAuth sync、retry API、持久化和账号页观测链路落到 master，身份与影子账号路径不是概念稿。
风险不在“没有基础设施”，而在“最近新增证据更多停在测试环境、协议、secret、worker 和 runtime gate 层”。正式商业化闭环仍缺同等级的新鲜生产证据。

2. 运营能力

59 / 100
  • 搜索发现机制已经不是空白。6/15-6/17 的主干记录显示：静态 SEO 页、多语言 URL 前缀、route-specific metadata、description、hreflang 和 docs 搜索都已进入源码主线。
  • 公开内容面也不算缺失：/about、/docs、/changelog、FAQ、配置教程、法律页都可见。
  • 问题在 freshness loop。changelog-page.tsx 最后一次实质更新停在 2026-06-11，当前还只讲云存储、成就、企业微信，没有覆盖 6/18 之后的 CloudAgent/Hermes 导入、恢复和账号路径变化。
  • 套餐对外表达也有漂移：当前 plan-catalog.ts 讲的是 Free / Plus / Max，而旧文档与部分外部叙事仍沿用另一套阶段话术，容易让运营内容落后于真实代码结构。
已有 SEO 工程能力，但“主页信息、产品更新、文档、claim 与代码同步”的运营闭环还没有跑起来。现在更像一次性修站，而不是持续更新系统。

3. 场景探索

54 / 100
  • 用户可见的旧一波场景证据还在：云存储、成就、企业微信、网页内对话、自动任务、记忆、文档和设置页导引。
  • 但最新 6/20-6/21 的主干变化主要是产品 chrome 统一、账号信息恢复、导入/恢复链路稳定化、worker-action 状态收敛。
  • 这些变化对“平台是否能长期在线”很关键，但还没有被包装成新的差异化使用场景，例如主动服务、跨工具工作流、迁移/恢复体验、模板化 Agent 或多 Agent 协同。
  • 从 Wiki 的《功能与场景地图》看，下一阶段想要的竞争力是“个人专属云端智能管家”；而远端最新代码仍更多处于工程底座与可维护性层。
这轮需要明确标记：很多工作还停留在 engineering-only，并没有转化为“用户一眼能感知的新场景”。场景能力仍是下一阶段的真正基础盘。

4. 内部协作机制

68 / 100
  • 项目级规则路径是完整的：仓库根 AGENTS.md 已写明先读根规范、再读子服务 AGENTS、再读 .agents/skills/、再读代码。
  • 前端 frontend/AGENTS.md 进一步约束了 OpenSpec、计划门禁、预览环境、分支前缀和质量门禁，说明 Agent-native 协作意识已经进入显式文档。
  • 发布规则也清楚：根 AGENTS 明确 master 只管源码，gitops 才是 Argo live source，这对判断“是否正式发布”非常关键。
  • 但分支库存偏大且集中度高：729 个项目分支里 537 个已超过 14 天，作者聚合又明显集中在少数人，说明协作机制虽在形成，治理压力也在上升。
分支年龄只是风险信号，不是责任认定。它提醒的是“分支收口、MR 收敛、规则沉淀和角色负载”可能出现瓶颈，而不是单点归因。

产品基础设施完成度

这一段专门覆盖计费、账号、套餐、订阅、pass 生命周期、支付、身份和影子账号路径。

能力面 当前判断 远端证据 今晚结论
套餐 / packages / plans 结构已在，商业化未收口 frontend/src/domain/plan-catalog.ts 已定义 free / plus / max；PlanSelectPage 可从 /subscriptions/current 和 /subscriptions/checkout 读取与确认套餐。 已有产品结构，但对外仍是“免费体验 + Coming Soon”的过渡态，正式商业化表达未完成。
订阅 / subscription 接口路径齐，近两天无新证据 http-repositories.ts 使用 /subscriptions/current 与 /subscriptions/checkout；session-context 会后台 hydrate 当前订阅。 链路在代码层存在，但最近远端增量不在 subscription 服务本体，可信度更多来自既有代码，不是 fresh rollout。
pass 资源生命周期 覆盖相对完整 前端已对接 /v1/passes、order、order-url、renew/price、renew/order、renew/order-and-pay、delete；账号页明确处理 active / isolated / expired。 这是当前基础设施里相对完整的一段，也是后续真正做套餐闭环的可复用底座。
支付 / billing / trade 北京测试继续收口 2a597c07 把付费前端路径合入 master 但默认关；608da469 说明 trade 的 getPrice / pipeline / db_job 支持刚在 6 月 17 日补齐，北京测试仍是核心验证面。 不是“没有支付能力”，而是“还没有看到正式生产稳定闭环的新鲜证据”。
账号 / 实名 能力在增厚，生产面未完全证实 account-page.tsx 已承载实名状态、重新认证、同步失败展示与套餐信息；2026-06-21 还恢复了 account ID 可见性。 账号面越来越像正式产品页面，但仍夹杂大量“为基础设施联调服务”的状态展示与兼容逻辑。
影子账号 / shadow 主干已具备，环境启用仍谨慎 73182f06 把 BasicAuth sync、retry API、DB migration、腾讯云 transport 全部落到 master，且明确要求不要默认开启。 影子账号路径已具备产品化前提，但仍明显属于“能力准备完成、开关与环境验证未完全放开”的阶段。
公开生产可证实度 仍偏弱 本轮 GitOps 可确认的新鲜正式动作主要是 service-gateway 和 workers-hermes-importer，不是计费正式闭环。 如果要给运营或管理层一句话：产品基础设施已成形，但“商业化与正式环境已稳定开闸”的证据今天还不够硬。

运营与公开内容漂移

这里关心的不是“有没有页面”，而是“搜索发现、首页信息、更新日志、文档和 claim 是否与代码同步”。

已具备的发现机制

  • 静态 SEO 页已入主干，包含多语言 URL 前缀与 route-specific metadata。
  • Docs 搜索、文档侧边栏、FAQ、配置教程已存在。
  • 公共导航已稳定指向 /docs、/about、/changelog。

明显的 freshness 漂移

  • changelog-page.tsx 最后实质更新停在 6 月 11 日。
  • 公开 changelog 仍停留在云存储、成就、企业微信，没有覆盖 6/18 之后的 Hermes 恢复与导入能力。
  • 套餐文案、产品 claim 和内部代码结构已经开始分叉。

今晚判断

  • LightVela 已经有“可被搜索发现”的工程框架。
  • 但还没有形成“主干一变，公开内容就同步更新”的运营机制。
  • 如果不补这一步，外部认知会长期滞后于真实进展。

分支年龄与开发者视角

只基于远端分支事实，不拿本地分支和本地脏工作区混算。分支年龄是风险信号，不是责任归因。

指标 值 解释
总项目分支 729 排除 origin/HEAD、origin/master、origin/gitops 和 promote / release 自动分支后的远端池。
> 14 天 537 说明大量分支没有在两周内收口或清理，后续会影响评估面、排障面与环境噪声。
> 30 天 249 一个月以上库存已不算“正常遗留”，需要专项治理与归档策略。
近 7 天活跃 63 说明项目仍在高速推进，但推进火力明显集中在少数人和少数基础设施主线。
最近活跃样本 作者 年龄 信号
codex/product-route-chrome-fallback skipzhang 0 天 产品页刷新 fallback 与导航体验收口
codex/frontend-shared-agents-chrome skipzhang 0 天 营销页 / 账号页 / Agent 页共享产品外壳
codex/cloudagent-session-event-recovery skipzhang 0 天 ChannelGateway 事件恢复与 run_id 归属修正
automation优化 pablozhong 1 天 自动任务微信 test-send 恢复文案
codex/gitops-service-gateway-cos-creds skipzhang 1 天 service-gateway 生产 secret 发布
frontsandbox/agents-chrome-preview skipzhang 0 天 预览面跟进最新产品外壳
陈旧分支样本 作者 年龄
test2 skipzhang 55 天
skipzhang_working skipzhang 54 天
feat/i18n-fill-missing-translations erichuyuehu 53 天
feature/global-realname-wall-env skipzhang 53 天
playground/sandbox-sg skipzhang 53 天
singapore-sandbox skipzhang 53 天
作者聚合 总分支 >14 天 近 7 天
skipzhang 540 403 47
pablozhong 55 40 3
walkercao 29 17 5
sarahzzhang 22 18 0
cassidyshi 16 8 3
erichuyuehu 13 10 1
当前 git-only 视角能拿到 merge request 编号，例如 !1734、!1731、!1727、!1725， 但拿不到 reviewer、assignee、未解决评论和 CI 细粒度状态，因此本次 branch view 只做到作者聚合和源码/GitOps 信号分层。

下一步聚焦

不是建议清单越长越好，而是挑最能影响下个阶段判断的三件事。

1. 把“基础设施已在”变成“正式闭环已证实”

  • 优先追 trade / payment / subscription / user/auth 在正式环境的 GitOps 证据，而不是只补前端壳层。
  • 需要一条更硬的事实链：定价可见、下单可走、续费可复验、isolated/destroy 可回收。

2. 建立公开内容 freshness loop

  • 把 changelog、首页 claim、docs 更新节奏和近期远端主线绑定，避免 CloudAgent / Hermes 新能力继续只存在于 MR 和内部口径。
  • 当前最适合外化的不是“又改了样式”，而是“恢复、导入、长期在线、账号链路稳定化”的用户价值表达。

3. 让恢复 / 导入能力长成场景能力

  • Hermes import、recovery center、worker actions 已经有平台底座，可以继续长成“迁移上云”“故障自愈”“工作区恢复”的用户可见方案。
  • 如果这一步不做，CloudAgent 的真实优势仍会停留在工程团队内部可感知。

4. 用分支治理给协作机制减压

  • 729 个项目分支、537 个超 14 天分支已经足以影响判断清晰度。
  • 即便不做大清理，也建议先建立“过期分支收口 / 失效 playground 分支归档 / 预览分支回收”的轻量规则。

本次扫描证据

用于保证这个 cockpit 是“有来源的判断”，不是空口评述。

远端 refs / commits

  • origin/master@9ca3d0bb、origin/gitops@ba99a55d
  • 6bb3350a ChannelGateway session-event recovery
  • 243548df service-gateway COS credentials
  • ddaca1f5 worker-action empty status
  • 2a597c07 sandbox paid billing runtime flag
  • 73182f06 shadow BasicAuth sync loop

代码与文档落点

  • frontend/src/domain/plan-catalog.ts
  • frontend/src/repositories/http-repositories.ts
  • frontend/src/pages/marketing/account-page.tsx
  • frontend/src/pages/marketing/changelog-page.tsx
  • AGENTS.md、frontend/AGENTS.md
  • Wiki: 《LightVela 日会进展对齐》《功能与场景地图》《运营增长规划》《内部协同机制》
本页结论默认遵守四个宪法目标：产品能力迭代、运营能力、场景探索、内部协作机制。 本次最重要的判断不是“项目有没有在动”，而是“最近两天的新增价值主要沉在平台底座与环境 wiring；要让 LightVela 进入下一阶段，需要把这些底座继续转译成正式闭环和用户能感知的场景能力。”